アジャイル開発の落とし穴
●1．要求の根拠が分からない
アジャイル開発のプラクティスにはオンサイト顧客とあるが、オンサイトで顧客を置いたとしても、その人が企業のミッションに基づく正しい要求を出せるとは限らない。
筆者の推進する要求開発では、この問題を解決するために、トップ（オーナー）、IT担当、業務担当と、ロール（役割）を持つ人それぞれが参加する場を「コタツモデル」というメタファで表し、その場の中でビジネス戦略的視点（トップ）、業務視点（業務担当）、IT活用の視点（IT担当）によって要求を開発（開拓）する必要性を唱えている（図6）。
要求はあるものではなく､開発するものである。コタツモデルで要求を開発し、少なくとも現在においてはこの要求が正しいというものをビジネスの視点で合意してこそ要求の根拠が確立される。
アジャイル開発にもこのような取り組みが必要とされるのではないか？
●2．ストーリーはどうやって導き出すのか？
これも1と同じことであるが、ストーリーの根拠がオンサイト顧客という発想では問題が起こる。オンサイト顧客に振り回されることになったり、オンサイト顧客とは異なる意見を持つ顧客が現れたりしたときに悲惨なことになるだろう。業務をしっかりと把握するために（ユーザー企業が）“見える化”し、最終的にはToBe業務として覚悟するための場（チーム）がユーザー企業の中に必要とされる。
● 3．ビジネスの道に迷う
「要求の根拠が分からない」「ストーリーはどうやって導き出すのか」という問題は、結局のところビジネスの道に迷うことにつながる。アジャイル開発のプロジェクトは「木を見て森を見ない」傾向が出てくるだろう。これを解決しない限り、アジャイル開発は局所的なビジネスの価値はもたらせても、ビジネス全体としての価値をもたらすことはできない。ビジネス全体から狙いを定めてアジャイル開発を行う方法が必要である。
●4．場当たり的な開発になっていないか
場当たり的な開発とは、ここまで話してきたように、計画性の欠如からくるものである。システムの成長性をビジネスの視点で地図として描くような計画性が望まれる。本来アジャイルとはビジネスアジャイルのことであるとわたしは考えている。ビジネスの視点でシステムの戦略および成長性を含めて地図として表しておき（仮説的に骨組みを作成）、その肉となるビジネス、システムの部分を切り出してアジャイルに回すべきではないか。
●5．モチベーションは高まるが、エンジニアリングは？
アジャイル開発はモチベーションアップの天才である。だが、こうした設計やプロセスといったエンジニアリングを軽視している人たちが多いようにも思える。筆者から見たアジャイル開発とは、設計やプロセスなどのエンジニアリングの基礎知識を常識として持っている人が、それらエンジニアリングを最適な状態でシステム開発に適用し、プロジェクトを通して人間の心をもマネジメントしながら進めていく開発プロセスである。また、将来アジャイル開発は、このアプローチの仕方をビジネス開発という広い視点で適用すべきだと考える。よって、アジャイル開発において、設計やプロセスを捨てるような非常識なことがあってはならない。
さて、今回はここまでとしよう。このような両者の弱点を知り、ぜひ今後の開発に生かしてほしい。
ところで最近、デベロッパーサミットで「プロセスの心」という講演を行った。その中で、この連載に書いているようなことをお話ししたのであるが、途中からエンジンが掛かりっぱなしで、オーバーヒートするかのごとく熱く語ってしまった。
それだけ思い入れの強いプロセスという概念。皆さんにもこの原稿から、その思いが伝われば幸いである。
次回は、いよいよ第3巻（最終巻）「ソフトウェア開発の革命」。第1〜2巻で挙げた諸問題をどう解決するか、筆者なりの考えを述べる。
筆者紹介
株式会社 匠Lab 代表取締役社長
リコーソフトウエア株式会社 技術顧問
ケペル株式会社 フェロー
株式会社ニッポンダイナミックシステムズ フェロー
要求開発アライアンス 理事
萩本順三（はぎもとじゅんぞう）
2000年、ソフトウェアを人の思考に近い「もの」という単位で考えることで、分かりやすいソフトウェア開発を行えるというオブジェクト指向技術の企業、豆蔵を立ち上げ、ITアーキテクト、メソドロジィストとして経験を積む。現在は、ビジネスとITの可視化を行うための要求開発方法論を要求開発アライアンスメンバーとともに作成し、自らユーザー企業で実践しながら後進の指導に当たる。2008年7月、匠Labを設立し、IT業界のさらなる価値向上を目指す。
Copyright © ITmedia, Inc. All Rights Reserved.