アジャイルを考える - Agile Tour Osaka 2011 -

去年は自宅で見ていたAgile Tour Osaka 2011ですが、今年はLTに出番がいただけたので朝から参加しました。講演を聞く中で、多くの刺激をいただくことができました。

１．インパクトのあった言葉

アジャイルを標榜しながらもチケット駆動開発で現場を改善しようとしている私にとって、最もインパクトのあった言葉は、

・アジャイル開発ができない理由として「制約」と言われるものは「解決すべき妨害事項」

・「守破離」と言われるが、「守」をせずに「破」をしてしまう

という@ryuzeeさんのお話でした。@ryuzeeさんのほか@smorisaki先生のお話にあったように、何かをするには説明責任が伴いますし、何かをせずにおくことも

・変化しなければ緩やかに滅びる、という背任！(@ryuzeeさん)

であるなら、安易にプロジェクトを進めるのではなく、解決すべき妨害事項が現時点においては制約であることを説明する必要があると思いました。

２．アジャイル開発導入への妨害リスト

私から見えている「妨害リスト」は以下のようなものだと思います。

契約
まずはこれでしょう。準委任でなく一括請負になる場合には、減価償却したいという場合があって、ちょっと厄介です。また、藤井さんの講演にあったように、信頼関係を築かないと始まりません。

多能工を増やせない
複雑で先進的なシステムの場合、すべてを把握・実現できる多能工ではなく、専門工になりがちです。いずれは多能工化したくとも、新しい技術を順次取り入れたり、新しい人が入るような状況だと、実現が困難になります。

システムの並行開発
連携する複数システムを並行して開発する場合など、あらかじめインタフェースを決めて開発します。インタフェース汎用的でない場合などは仕様が限定されてしまい、段階的にリリースする場合も、スコープの変更ではなくリスク低減が目的とされます。

危機感の共有
実は、組織やチーム内の合意形成が最も困難ではないかと思っています。様々なステークホルダーのいる中で、プロジェクトの目標は、価値、利益、信頼性、QOLなど様々ありますので、プロジェクトの問題点が共有でき、解決法としての合意が必要になります。

それぞれ程度の問題で、簡単な問題や長期的に効果が見込める問題であれば解決すべきでしょう。

しかし、現実を見ると目の前にはプロジェクトがありそこで求められていることは、アジャイルを実践することだけではありません。すぐに求められていることは、アジャイルを実践した先にあることなのだと思います。

２．アジャイル開発導入をあきらめてみる

アジャイルを一旦あきらめて、すぐに解決したい問題の観点で、各講演を見直すと、以下のような項目があがります。

任せること(設楽さん)
そのために細分化、見える化、自動化する。見える化は変化を検出可能にすること。チケットをうまく使えばできそうです。

説明すること(森崎先生)
事例とシミュレーションを組み合わせて説明する(Exsample scenario)。全てを実績で説明することが困難な場合、過去の実績と未来の予測を組み合わせて利用する方法です。メトリクスサーバをうまく利用できそうです。

見積もりと計画(藤井さん)
処理されるデータを中心に見積もるCOSMIC法は興味深いと思いました。ファンクションポイント法も表面的な機能だけでなく、内部のデータも見積もりに加える事例もあるようですので、分野によっては効果的だと思います。また、ベーム先生のアンカー留めスパイラルモデル(1994)は、マイルストーンをしっかり決めて守る事なのだと思います。この他にも、アジャイルＵＰ、ＡＭＤＤ、southernSCOPEといったキーワードは参考になると思います。

自己組織化(吉羽さん)
トップダウンの外科医チームのような組織は、構造化プログラミングされた巨大なプログラムだと思いました。頑張れば何とかなるかもしれませんが、外乱に強い安定した組織にするには、オブジェクトの能力が発揮できる自律分散型の組織が必要だと思いました。

これらは、成功したアジャイルにより得られるものではありますが、危機感の共有と工夫によってある程度実現できるのではないかと思っています。そして効率化していけば、その先にアジャイル開発に近いものが見えてくるのではないかと思っています。

謝辞

このように多くの刺激をいただけたAgile Tour Osaka 2011のスタッフのみなさま、発表者の皆様に感謝いたします。