無料ブログはココログ

マリリンさんにサーバントリーダーシップのコツを学ぶ

本橋 麻里さん(以下、敬愛をこめてマリリンさん。リンク先はWikipedia)がTVで話題になっています。8年かけて、日本に女子カーリングのオリンピックメダルをもたらしました。

マリリンさんのサーバントリーダーシップ

その行動はまさにサーバントリーダーシップ([#benkyoenkai] 古くて新しいサーバントリーダシップ)でした。

TVいわく、実力があるのにリザーブに回った。夜間に氷の状態を確認していた。5万円でも良いからと企業をまわった。

なんでもやったマリリンさんですが、技術力も超一流だそうです。なのに「私が」を追い求めないことで、大きな成果を得ることができたのでしょうか?

そこには、サーバントリーダーシップを実践する上でのコツがある様に思います。

1.大志を抱く

選手ですから自分の成長も考えていたでしょう。でもそれだけでなく、日本のカーリングを盛り上げてオリンピックのメダルを取るという大きな目標があったので、マリリンさんはサーバントリーダーシップを発揮できたのだと思います。

2.チームの能力を最大限に発揮する

自分が日本のカーリングを引っ張っていくと決めても、トップダウンのやり方ではうまくいきませんでした。「かなわないな」と思った海外チームの笑顔でした(カーリング・本橋麻里、バンクーバー五輪で「あぁ、かなわないな」と感じた瞬間 (1/2) 〈AERA〉|AERA dot. (アエラドット) )。

あの「もぐもぐタイム」や「そだね」はマリリンさんのめざす「笑顔のカーリング」をもらたして、チームの能力を最大限に発揮したのだと思います。

3.ゴールのためならなんでもする

とはいえ、マリリンさんはなんでもやり過ぎのような気がしませんか?(カーリング女子、本橋麻里の献身 深夜にストーンを投げ氷の感触を把握)そこには単に夢を抱くだけでなく、優先順序に基づく合理的な判断があったのだと思います。

オリンピック選手なのに格好悪いとか、チームの犠牲になっているとか、そんな考えは無いのだと思います。ゴールをとにかく達成したい。そのために必要なことを実行する。それだけだったのだと思います。

ソフトウェア開発に当てはめる

ソフトウェア開発に当てはめてみましょう。承認欲求や給料といったものも大切ですが、それを超えるチーム、組織、業界、コミュニティ、といったより大きな目線で目標を立て、チームの能力を最大限に発揮させるように、なんでもしないといけないでしょう。

そのためには、技術や情報を共有するしくみづくりや、技術力を向上させるために自分の仕事を譲ることや、逆に雑用と感じる作業を分担することもあるかもしれません。しかし、それは犠牲になるのではありません。大きな志の実現に向けて「何としてでもやり遂げる」強い気持ちで実践するのだと思います。

おわりに

マリリンさんの行動から、サーバントリーダーシップのコツを学びました。

TVで見せたマリリンさんの涙。表情も輝いていて、私には苦しみから解放されたというよりは大きな目標を達成した喜びの涙に見えました。

サーバントリーダーシップは大志を抱く人に、より大きな喜びをもたらす方法なのだと思います。

このエントリーをはてなブックマークに追加

暗黙知は帳簿と運用に眠る - 業務理解に向けて - #benkyoenkai

年忘れLT宴会<第60回IT勉強宴会>に参加しました。最も刺激を受けたのは杉本さんのLTでした。

暗黙知

同じお客様の開発を何度かすると「なるほど」と過去のことが理解できることがあります。与えられた仕様(要件)を満たすソフトウェアを開発する中で、その背景にある暗黙知が得られた瞬間です。

もちろん、最初の開発でもある程度は暗黙知を得ることはできます。仕様についてそれはなぜかを質問することです。納得できる詳しい説明や、これまでそうしてきたからなど、色々な回答が得られます。

しかし、暗黙知の全体像に関しては、開発を一通り終えて、実際の運用がうまく回り出して一通りの業務を近いするまで、なかなか得られません。

帳簿は暗黙知の中心

杉本さんのLTで紹介された開発では、帳簿(DB)が業務システムの中心で、運用で対応する部分も含めて業務システム開発します。そのような開発に於いては、業務分析やデータモデリングを追求することで、業務を明確にして暗黙知をシステムに取り込んでいくのでしょう。

それはソフトウェアのプログラミングだけでなく、帳簿(DB)はもちろんのこと、運用を含めた暗黙知を明確にしないと教務システムはうまく開発できないという示唆だと思いました。

おわりに

SRA Advent Calendar 2017に「効率的なモデリングをマネージメントする」(ここにも転載:その1その2その3)という記事を書きました。これに運用はほとんど考慮されていません。

これまで、いわゆる業務系とは異なる開発をしていながらも、IT勉強宴会で色々勉強をさせていただいてきましたが、どこかモヤモヤするものがありました。それが運用であったことに気付くことができたのは、今回の大きな収穫でした。

IoT関係で運用と言うと、UIがらみを除くとクラウドのアーキテクチャ設計とその運用設計がそれに当たります。クラウドでは新しいサービスが続々と出てきますので、それが開発を一通り経験しないとわからない理由だったのかと腑落ちした次第です

LT中のアジャイルウォーターフォールに関しては、主語が大きくて気になりますが、それを上回る刺激を受けました。ありがとうございました。

このエントリーをはてなブックマークに追加

効率的なモデリングをマネージメントする その3 - 開発標準を素直に実施しない -

SRA Advent Calendar 2017 23日目からの転載です)

はじめに

まじめにやっているのにうまくいかない。標準なんだからその通りにやればいいじゃないか。そう思われるかも知れません。

しかし開発標準で守らないといけないことには幅があり、それなりの自由度があります。きちんと理解した上で適切にモデリングすれば、効率的なモデリングが可能になります。

開発標準

開発標準は成功したプロジェクトを参考に、良いプロセスの実施が容易な様に、実施すべき各作業とその確認方法を定めたものです。開発者を支援して、一定のレベルへの底上げや組織的な改善を可能にします(その反面、さまざまな罠もあります。標準は諸刃の剣)。

モデリングをする際にも、ある時はガイドやノウハウ集として使えますが、時には収集したデータの正常範囲を定めるなど、モデリングや実装の作業を制限します。

開発標準を良く読む

大切なのは開発標準を良く読むことです。開発標準には以下のようなことが書かれていると思います。

  • 全体の構成と考え方(ガイド)
  • 守らないといけないルール(制約)
  • 一般的な方法(ガイド)

ガイドに当たる部分はうまくいったプロジェクトで行われた一般的な開発の方法や作業が書かれています。制約に当たる部分は守らないといけないルールで、作業だけでなく何らかのメトリクス(尺度)が定められているでしょう。作業のエビデンス(照査)となるデータの収集が必要です。レビューやテストの項目数や時間など一定の量が必要になり、作業が制約を受けるでしょう。

開発標準には多くの役立つことや勉強になることが書かれていますが、必要なことが全て書かれている訳ではありません。書かれていることに従って、それだけをコツコツ実施しても、必ずしもうまくいくとは限りません。

リスクが工数に見合うだけ低減するなら、下記のようなモデリング作業の変更が必要になります(同程度でも実施します)。

 
増やす
 
      必要なモデリングを追加します。多くの場合、設計作業の追加はあまり禁止されていません。  
 
前倒し
 
     よりリスクが低減するなら後工程の作業を前倒しします。一部詳細化したり、プロトタイピングの実施など、本格的な実装でなければ許容されるでしょう。  
 
分解
 
       モデリング作業を分解し、調査、整理、考えるといった作業を前倒しします。会議内で(モブ)モデリングしても良いでしょう。  

大切なのは、予め計画してステークホルダーと合意を得ておくことです。また、開発中であっても必要が生じたら、面倒がらずに計画を変更することも重要です。
前回の「効率的なモデリングをマネージメントする その2 - モデリングの戦略 -」を参考にしてください。

逆らっても徒労に終わることが多い

若気の至りで開発標準に抗議したこともありますが、逆らっても徒労に終わることが多いです。開発標準は必要な作業の抜けを防ぐ目的で組織として決めたものです。個別のプロジェクトに対してテーラリング以外の変更を要求しても、許容する権限が担当者にありません。

逆に制約だけを守れば、意外と自由度があるものです。ガイドを読んでしっかり活用することで得られることも多いでしょう。

とはいえ、どのような標準も使っていれば時代遅れになるもので、改善案は提案してください。パイロットプロジェクトで確認することも必要ですので、改訂には複数年かかるでしょう。

開発標準のフィールドで走り回れ

多くの競技にはコートのような活動領域が決められていて、競技者はその範囲を有効に使いながら、敵を攻略します。

開発標準は縦にだけ動けるサッカーゲームの様に、典型的ないわば「型」を示したものです。定められたフィールドからはみ出さない程度に、右に左にゴールに向けて戦略的に攻撃ください。

おわりに

効率的なモデリングをマネージメントする方法を3回に分けて説明しました。以前はうまく開発できていた人が、プロジェクトが変わると急にトラブルに巻き込まれる。そんな姿を見たくありません。

開発標準と改善活動はフィットするプロジェクトにはとても効果的です。しかし、それぞれの作業がなぜ必要なのかをきちんと理解しなければ、典型的なプロジェクト以外に応用がききません。

何が制約であり、なぜそのようにするかを理解すれば、開発標準を味方につけられます。そして、自由なフィールドを手に入れて様々な実施方法ととることができます。

釣りは「ぼーっ」としていては釣果が出ないそうです。常に「ああかな」「こうかな」と状況を見極めて必要な行動が必要だそうです。ソフトウェア開発でもいつもリスクを見極めてダイナミックに適切な対応をとることが、リスクと戦う効率的な方法だと思います。


「だから、あなたがたは気をつけていなさい。」マルコによる福音書/ 13章 23節(日本聖書協会 新共同訳)

このエントリーをはてなブックマークに追加

効率的なモデリングをマネージメントする その2 - モデリングの戦略 -

SRA Advent Calendar 2017 15日目からの転載です)

1.はじめに

ソフトウェア開発は危険です。急に暴れることから、ある時は狼男、ある時は熊に例えられます。まじめにコツコツと働いていたのに、突然現れた狼男や熊によって計画が台無しになってしまいます。

混乱に陥ったプロジェクトを見てみると、混乱の原因は意外と明確です。しかも、当事者である若いメンバーから部門のマネージャに至るまで、だいたい答えられることも多いでしょう。しかし時すでに遅し、混乱を押さえるには仕切り直して計画や配員を見直さないとプロジェクトを立て直すことができないでしょう。

2.不確実コーンを細くする

社会の発展や競争の激化、ソフトウェア技術の進歩によってソフトウェア開発期間は短く、より多機能になり、見積もりの振れ幅を時間軸で示した不確実コーンは広く、短くなっています([#TiDD] 最近のソフトウェアを考えるとアジャイルに向かう

Photo

そこで、短い期間に区切って段階的に開発するアジャイル開発が増えてきています。 これば、不確実コーンを小さなコーンに分ける方法です。 アジャイル開発はUXを重視する場合や、まずはビジネスを開始したい場合には、実際の動作を見極めながらの方向性の変更や、必要なものからビジネスの支援が可能なので、とても効果的です。

しかし、必要な機能を分解できない場合や、イテレーション(スプリント)を複数回実施できないほど短期間の開発の場合には、効率的なモデリングでリスクを下げて不確実コーンを小さくする必要があります。

そこで求められるのは、戦略的な考え方です([#agileto2012] 『チェンジ!』の考え方 ~マネしやんと!~)。その時点で最も効果のあるポイントをのモデルを作成する必要があります(大規模開発の場合は、ランチェスターの法則(ランチェスターの法則と売り上げ、利益、利益率)に従って総力戦も可能ですが、重点の見極めは大切です)。

作成するモデルは、ドキュメントとして完成されたものでなくても、考える道具になり、ステークホルダーと共有できるなら、なんでも良いでしょう。以下にパターンに分けて説明しましょう。

2.1 全体が曖昧な場合

何かを作ってしまうと、それに引きずられて全体像が見えにくくなる場合がありますので、全体がぼんやりとしている時にわかる所から作り出すのは賢明ではありません。

全体像を抽象的な方向性でなく、具体的な構造を考えて実現可能性を高めます。具体的には、業務フロー、シーケンス図など全体の流れがわかるモデルを作成します。モデルを書いてみると、そこには業務の用語やデータが見えてくると思います。

2.2 抜けがあるような気がするとき

データをモデリングします。必要なデータを探してまとめます。ER図でも、オブジェクト図やクラス図でも、ただの一覧でも構いません。
次に見つけたデータがどこで作られ、どこで更新され、どこで削除されるかの説明を試みます。説明ができたなら不安が解消していると思いますが、精査したければやり過ぎないレベルでCRUDを書いてみても良いでしょう。

2.3 実装イメージがわかない、自信が無いとき

あまり経験の無い環境などで、自信が無いなら調べましょう。インターネット上の記事は大まかな知識や事例を知るには役立ちますが、最終的には公式ドキュメントで確認しましょう。

それでも不安が残ったり、わからない所がある場合はプロトタイプを作成します。プロトタイプは全ての実装ではなく、課題となっている所を抜き出して単純化したものですので、まさに「モデル」です。

3.モデリングのポイント

ここで示したモデリングの方法は、以下の3点を明確にするものです。

  • 全体のイメージ
  • データと関係
  • 関連ソフトウェアの詳細仕様

これらのモデリングを考える道具道具として使い、リスクを排除します。これによって不確実コーンを細くして、ソフトウェア開発の混乱を少なくします。

ここで注意しないといけないのは、前回(効率的なモデリングをマネージメントする その1 - モデリングの目的 -)に書いた様にモデリングの目的には様々あるものの、ここで挙げた方法は

  • 見つける、理解する
  • 整理する
  • 作り出す

といった目的が中心です。つまり、モデリングの全ての目的ではないのです。モデリングでリスクを低減するには、リスクそのものにポイントを絞ったモデリングが必要で、その他の目的を達成する際の参考になりますが、不十分なものです(プロトタイプと同じです)。しかし、それでも優先してモデリングすることが重要なのです。

4. おわりに

ここであげた効率の良いモデリングとは、義務としてドキュメントを早く仕上げるのではなく、個々のプロジェクトに特有のリスクを低減する方策としてモデリングです。このような視点でプロジェクトを実践すれば、より安定した開発を実現することができるでしょう。

モデリングは工程に関係なく、必要ならいつでも実施すべきです。「しかし、開発標準が、、、」と言われる方のために、次回は「[開発標準を素直に実施しない]()」ことについて説明します。

このエントリーをはてなブックマークに追加

効率的なモデリングをマネージメントする その1 - モデリングの目的 -

SRA Advent Calendar 2017 7日目からの転載です)

「どのようなモデリングをするか?」その答えは人や組織によって異なるでしょう。モデリングの進め方には様々な方法があり、その効果が異なるからです。

そもそもモデリングをなぜするか?を考えてみましょう。

モデリングの目的

プロセスモデリングが、伝える、実行する、議論する、改良する、管理する、支援する、自動実行する、 ことを目的とした様に、モデリングを行うと、以下のようなことが可能になります(「ソフトウェアプロセスもソフトウェアである」というメタファからすると先祖帰りです)。

● 伝達の道具
 - どのように実現するかを理解する
 - 現状を理解する

●協調作業の前提
 -  ルール
 - インタフェース

●思考・議論の道具
 - 仕様の理解
 - 実現方法の検討

●組織活動
 - 支援・改良
 - 管理

●実行基盤の実現
 - データベースの構築
 - 制約違反の検出

このようにモデリングには多くの目的があります。実際には、これらの複数の目的を考慮しながら、モデリング、レビュー、打ち合わせ、開発を実施します。その比率や順序はプロジェクトや組織によって異なるでしょう。

同じ目的でモデリングを行うとしても多くの手法がありますので、どのような戦略でモデリングを実施するかによってその効率は大きく変わります。

特に小規模なプロジェクトの場合は、必要と思われる全てのモデリングは不可能ですので、目的や方法の取捨選択やその組み立て方がプロジェクトの成否に大きく影響します。

次回は効率的なモデリングの戦略について述べます(効率的なモデリングをマネージメントする その2 - モデリングの戦略 -)。

このエントリーをはてなブックマークに追加

標準は諸刃の剣

標準と聞くと仕事を楽にするもの、組織に必要なもの、 あるいは、 面倒臭いもの、 厳しいもの、と考える方がおられるかも知れません。これはどちらも真っ当な意見で、標準には良い面があるものの、悪い面もあります。

標準の効果

ここで参考になるのはプロセスモデリングのゴールでしょう([#TiDD]失敗しないチケット駆動開発 - プロセスモデリングの視点から+告知 -)。標準を理解し、共通の行動を前提に改善し、必要な作業が行われているか管理し、ツールによる自動化やガイドできます。

つまり開発者を支援して、一定のレベルへの底上げや組織的な改善が可能になります。

思考停止の罠

組織活動に便利な標準ですが、思考停止に陥りがちです。厳しく管理することで標準に従うことに集中してしまい、より良いものを追求しなくなってしまいます。また、柔軟な開発ができなくなるので、 開発の負担になって生産性が低下してしまうこともあるでしょう。

より難しい問題は、技術者の成長を止めてしまうことです。実際に大規模開発でうまくやっていた人が、小規模で比較的自由な開発でプロジェクトをうまく管理できないこともあります。なぜその標準が必要なのかをキチンと理解していなかったのでしょう。

良い標準

このような問題が生じにくい標準を考えてみます。標準で全てを縛るのではなく、その重要度によって規則、推奨、参考情報に分けると良いでしょう。単純な共通化ではなく、判断条件と共に複数の選択肢を示します。

良い標準は学びになります。その標準がなぜ良いか、どのような条件で有効か、その理由が説明されているなら、標準に振り回されること無く、自ら判断して実施できるでしょう。

標準を活かすには

どんなに良い標準でも、言われるままに実施しているのでは仕事をこなしているだけです。確認が可能なら、きちんと原本を読んでください。思わぬ発見があるかも知れません。

標準はそれぞれの組織や業務に応じて決められたものですので、定められた制約を守らないといけません。反面、制約を守っていればそこに工夫の余地があります。ソフトウェア開発と同じです。

(参考)詳細設計書を後回しにした話:Win-Winプロセス(ウォータフォール編)

このエントリーをはてなブックマークに追加

決定をできるだけ遅らせる -「現場で役立つシステム設計の原則」深読み -

増田さんの「現場で役立つシステム設計の原則」に関して様々な議論があり、私も立食とコース料理 -「現場で役立つシステム設計の原則」批判の一考察 -を書いたあと、様々な議論をさせていただきました。私なりの本の読み方が見えてきたのでまとめておきます。

この本はアジャイル開発(以下アジャイル)がベースになっていると思います。特にリーンソフトウェア開発のプラクティスである「 決定をできるだけ遅らせる」(リーンを考える - 無駄と必要なアソビ -) の考え方が透けて見えます。

この考え方は上流工程をもつ従来の開発方法(ウォーターフォールと呼ぶとリリースが1回とか工程間で判定会議がいるとされることもあるのでこう表現します、以下、従来法)とは大きく異なる考え方です。

従来法の考え方

従来法で上流が重視されます。これは、ベーム先生の後工程になると修正工数が指数的に増えると発表されたからです(「要求は変化する。Boehm は間違っていた、と DeMarco が暴いた。」というYourdon のブログ:An Agile Way:オルタナティブ・ブログ)。後工程になれば修正が大変だからと上流工程で頑張ることで、開発のリスクを減らそうとした訳です。

話はそれますが、ベーム先生はその後の繰り返し開発やアジャイル開発につながるスパイラルモデル(リンク先はWikipedia)を提唱されたり、後述の「アジャイルと規律」を執筆されるなどアジャイル開発に貢献もされています。IEEE Softwareの紙面でケント・ベックさんとXPについて議論されていたので、からかわれたのじゃないでしょうか。

決定をできるだけ遅らせる

話を戻して「決定をできるだけ遅らせる」というのはYAGNI(You aren't gonna need it)に通じる考え方です。従来法とは逆に、変更の可能性を考慮して、どうしても決めないといけない時(最終責任時点)まで決定遅らせるというプラクティスです。

例えば車のドアのところのデザインがかわる可能性がある場合、ドア部分の金型を削ってしまわずに少し残しておくといった対処で、後から変更が生じた際に調整できるように決定を遅らせるというプラクティスです。すべての事を決定しておかずに余裕を持たす事で、選択肢を残せます。

従来法のソフトウェア開発に置いても、決めきれない内容はペンディング、TBD、TODOなどといって後回しにしたり、手軽な方式に仮決めしておきますよね。それを時間切れだからとあきらめてするのではなく、変更の可能性を意識して選択肢を残す目的で実施するようなイメージです。こうすることで多大な手戻りのリスクを減らします。

「現場で役立つシステム設計の原則」の深読み

このような視点で読むと、仮決めする際のデフォルトが示されているように思います。オブジェクト指向はこう理解して、こう言う風に考えるとうまくいく、短いイテレーションも乗り切れるよ。という風に読めてきます。

上記は私の勝手な忖度ですが、増田さんの講演資料にある批判に対する回答を読むと、増田さん自身も決定を遅らせる考え方をもたれていることがわかります(現場で役立つシステム設計の原則)。

この5ページの「すべてのカラムが Not Null は非現実的?」に対して「実際にやっている、特に困っていない、SQL のスキル+ IDE サポート」という回答からも、決定を遅らせるスタンスが感じられます。

批判を考える

このように考えた上で、この本に対して書かれている批判を考えると、とても良い指摘ではあるものの、「決定をできるだけ遅らせる」こととと対極にある「はじめのうちからしっかり作る」ことを勧められている様に思います。

もちろんリスクを減らす目的で決定をできるだけ遅らせているのであり、「はじめのうちからしっかり作る/設計する」方がリスクが減るのであれば、実施すべきでしょう。

kent4989さんのブログ勘と経験と読経でその方法が紹介されていました(アジャイルとデータモデル、DB進化設計のこと)。アジャイルにこだわるならイテレーションゼロで吸収する。それ以外なら前段階で供給開発、あるいは、RUPなどの反復開発手法の併用を勧められています。最近ではたなかこういちさんが、アジャイルでスタートアップも、軌道に乗ったらUPへ移行すべきときが来る、というものかもしれないと言われています。

2017/9/8追記
アジャイルにこだわる方法としてFDD(リンク先はWikipedia)もあります。
[#Agile] FDDはアジャイル開発、ハイブリッドアジャイルは、、
[#TiDD] 手分けするより助け合い - FDDとチケット駆動開発 -

2017/9/14追記
この本の特徴の一つは決定を遅らせる際のシンプルなデフォルトを示していることです。イテレーション(スプリント)をうまく回せるか不安だった方や、ベロシティ(開発速度)が上がらなくて困っていた方には、大いに参考になるでしょう。

その方法は独特です。批判の多くは一般的な方法を主張し、その良さを指摘したものです。批判の実践はこの本に書かれたシンプルさを損ないますので、どちらを優先すべきか良く判断すべきだと思います。

もし、批判を読んで今までの開発が不十分で問題だったと思われるなら、批判は一部だけを示したものですので、より広く検討して上述の実施方法などを検討する必要があるでしょう。

アジャイルにこだわるかの判断

批判を別にしてもアジャイルにこだわるべきかどうかは考えておく必要があります。平鍋さんのブログデータモデリングなきアジャイル開発は危ういか?では、プロジェクトや製品の文脈によって変わるとされていますし、上述のたなかこういちさんのブログでも「バックオフィス側の管理業務」など業務が大きな要素であることは間違いないと思います。

一方、ベーム先生の「アジャイルと規律」ではアジャイルの5つの重要要因として、規模、重要度、 変化の度合いといった業務に関わる要員のほか、人、文化が挙げられています。

人に依る違い

設計に関して渡辺さんが「システム設計と創造性」の中で“まずは「システムが扱う現実の全体をぼやーっと理解する」ことを目指せばよい”とされていて、私もそうしています。

しかし、ふと思い出すと小学生のことです。私は作文の時間の半分以上をあーでもない、こーでもないと書く内容を考えていました。成績は悪くはなかったのですが、私よりもできる人の中には、作文の時間にすぐに書き出す人もいました。設計でも同じ様に人によって作りながらの方がうまくいく人がいるかも知れません。

そう思うと、書籍アジャイルサムライに

と書かれていたことが設計にも言えるのではないかと思います。

おわりに

増田さんの本に関しては、上記のような視点でとても興味深く読ませていただきました。できれば、続編あるいは改訂版のような形で、アジャイルとリファクタリングによる進化のさせ方について、もっと書いていただければと思っています。

なお、個人的なアジャイル開発に関する考えは、[#Agile] アジャイル開発の課題と対策 その1に書いています。現場でスクラムやXPの様なタイムボックス型管理をしているアジャイル開発はしていませんが、いわゆるモダンアジャイルを実践しているつもりです。

2017/9/8追記

アジャイルマニュフェストはオブジェクト指向の有名人が集まって決めたので、なるほどと思いました、サブタイトルからもオブジェクト指向からの説明の方がしっくりくるかも知れません(私には書けませんが)。

これに関連して「アジャイルプロセスでは、本質的なデザインやアーキテクチャに関する意思決定をできるだけ遅らせることができます。」というマーチン・ファウラー氏の言葉を見つけてニワトリとタマゴの関係だと思いました。

このエントリーをはてなブックマークに追加


アジャイルジャパン大阪サテライト2017の感想

SS2017のポストイベントがなくなったので、 急遽スタッフとして参加しました。


(1)キーノート:シンアジャイル(Joshua Kerievsky)

モダンアジャイルについての説明。タイトルはAgileJapan2017のタイトルにあわせて変更されたようです(シン・ゴジラをまねた?)。

個人的にアジャイル開発のタイムボックス管理は、作業タイミングを固定化するので超短期開発にはフィットしないと思っていました。Kerievsky氏は早くからタイムボックスを守るよりも顧客のメリットを考えようと言われていたそうです(そのとおり!)。

提案する新しい4つの原則は従来のアジャイルマニュフェストに対応しながらも、顧客やソフトウェアの安全性に配慮したものでした。

講演概要
http://www.agilejapan.org/session.html#session01

Agile 2016の基調講演: モダンアジャイル
https://www.infoq.com/jp/news/2016/08/agile2016-modern-agile

チェンジビジョン/英和システム 平鍋さんの説明
https://anagileway.wordpress.com/2016/10/07/modern-agile-jp/


(2)ヴァル研究所 新井さんの講演

アジャイルを社内に広げる際の話。みんなが積極的になるように色々と工夫された中で、権限(部長)があるので、一部の活動が社内評価と連動するようにした。と言われていたので懇親会で質問させていただきました。

質問は、社内の仕組みと連動すると、義務感ややらされ感が出ると思うが、どのようにバランスをとられているか?

答えは、社員には積極的なできる人と、受身の人と両方いて受身の人も働いてもらわないといけない。ルールを決めても相手によって変えている。とのこと。

つまり、ルールはがちがちにせず、運用時に人を見て、たぶんチームによっても変えているのでしょう。エンジニアは、ついつい一貫性が気になりますが、個人個人を良く見ると言うことが重要だと思いました。

ちなみに、「上から見てなので、みんながどう思っているかはわからないですけどね。」と謙虚に言われていたのが印象的でした。


(3)コニカミノルタの久保さんによるエモイ話

人はなぜ生きているのか?それは人生を楽しむためである。

なぜ苦しみがあるのか?それは、いつかより人生を楽しめるからである。

いい人である必要は無い。人の顔色ばかり見る必要は無い。わかってあげるだけでいい。

そう、生きているだけで素晴らしい。

そう思いました。

このエントリーをはてなブックマークに追加

Node-REDから見えた未来 - 変わるもの、変わらないもの - SS2017 WG13

ソフトウェアシンポジウム(SS2017)では、前回紹介した論文発表のほか、ワーキンググループにも参加しました。

ワーキンググループでは各グループのテーマに沿って、参加者がそれぞれのポジションを発表して議論します。私が参加したのはWG13「ソフトウェア開発の現状と今後の発展に向けたディスカッション」で「Node-REDから見えた未来 - 変わるもの、変わらないもの -」を発表しました。

Node-REDは高機能なノード(モジュール)がたくさんあり、それらを組み合わせて高機能なシステムを効率的に開発できます。また、簡単にデバッグできるほか、デプロイが一瞬で、開発から確認の繰り返しを素早く実行できます。

このような環境を使っていると、面倒臭いことがなくなり、ソフトウェア開発に重要な作業を中心に実施する様になります。この重要なことはみなさん合意できますよね。という発表でした。

しかし、Node-REDのデモのインパクトが大きかったのか、Node-REDに対する質問で持ち時間が終わってしまいました。Node-REDを知ってもらえたので、良かったことにしておきます。

このエントリーをはてなブックマークに追加

Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点 - SS2017 -

ソフトウェアシンポジウム2017(SS2017)で経験論文の発表をしてきました。経験論文とは研究論文の様に新規性はないものの、事例報告の様に経験を報告するものですが、問題設定や結果・考察を整理してより有効性や信憑性を高めて論文にまとめたものです。

今回はVisual IoTツールと呼ばれているNode-REDのアンケート結果を報告しました。ソフトウェア開発にツールは欠かせませんが、その導入報告はあまりありません。上流のツールであれば、コンサルタントに依頼することもできるかも知れませんが、下流のツールは小さい規模から始めることが多く、導入経験は他の人にも役に立つと思ったからです。

発表ではNode-REDの基本、長所・短所の説明と共にデモもしました。基本的な Hello World のノードを入れ替えてPathをセットするだけで、そのビジネスロジック(文字列の代入)をそのままWebサービスにできる様子をお見せしました。

このようにNode-REDは確認しながら開発するので短期間に品質の高いソフトウェアを作ることができ、アンケートにもある様に非同期処理が簡単に扱えます。その反面、ある程度の規模になれば、データやアーキテクチャなどの設計をきちんとしておかないと複雑になってしまいます。

そういった知識を持ち、ふさわしいプロセスで開発しないとうまくいかないことがアンケートからわかりました。まとめると

  • ツールの知識やノウハウを共有 する
  • 特性を活かした設計を行う
  • 実装を繰り返して常に確認する
  • 主体的にプロセスを変更し、品質 を上流から作りこむ

となり、これは、モダンアジャイル

  • 人々を尊重する
  • 安全な状態を前提とする
  • 素早い実験と学習
  • 価値を継続的に届ける

の基本理念と対応していて、Node-REDの良い導入が開発のアジリティ(機敏さ)を高めると考えられます。詳しくは以下の論文を読んでください。
(実は最終原稿の段階でモダンアジャイルの基本理念と対応していることに気付いたので追加しました)

Node-REDから見えた未来 - 変わるもの、変わらないもの - SS2017 WG13 につづく

このエントリーをはてなブックマークに追加

より以前の記事一覧