アジャイル開発と反復開発の落とし穴：ソフトウェア開発の匠（4）（1/3 ページ）

匠Lab 代表取締役の萩本順三氏が、既存のソフトウェア開発プロセスにメスを入れる！

[萩本順三，匠Lab]

　前回「『現状のソフトウェア開発は間違っていないか？』（プロセス編）」では、ウォーターフォール開発の問題点と改善方法を示した。さて、前回お話ししたようにウォーターフォール開発は本来、いくらプロセス改善をしたとしてもイノベーティブな開発がしにくい。ならば、反復開発（*1）やアジャイル開発に変えてしまおう、といいたいところ。しかし、導入するのであれば、それぞれのプロセスの特徴と弱点をしっかりと知っておくことが必要である。

　ウォーターフォール開発からの乗り換えを考えている方々だけではなく、いまアジャイル開発や反復開発を実践している方たちにもぜひ一読してほしい。

（*1）反復開発とは例えばRUP（Rational Unified Process）やUP（Unified Process）のこと。

反復開発とアジャイル開発の違い

　反復開発とアジャイル開発は、繰り返し型開発という意味では同じように思われる。しかし、その考え方は大きく異なる。

　簡単にいうと、反復開発は管理重視型開発、アジャイル開発は価値重視型開発といえよう。

　ここでもう少し突っ込んで考えてみよう。管理重視とは、マネージャがしっかりと計画して、計画どおりに実施しているか進ちょくをトレースし、評価する仕組みを導入することである。そのために反復開発は官僚的になりがちで、それが開発者に嫌がられる傾向にある。このことは反復開発の大きな問題となる。

　だが、もっと深い問題がある。反復開発は、最初にソフトウェア化する意義をしっかりと議論する。議論を通じてビジネスモデリングを行い、ビジネス課題の理解を促進する。このような段階が「方向付け」と呼ばれ、必要に応じて「分析・設計・実装・テスト」を繰り返すことになる。この繰り返しには、プロトタイプやビジネス検証という意味も含まれている。

　このようにかっちりビジネス課題を理解したうえで、プロジェクト計画（反復計画）を策定していくため、反復開発は「計画重視型」さらには「価値固定型」といえる。ビジネスにおけるシステム価値の全体像を明確にし、その全体価値を守るように管理しながら、部分集合をユースケースドリブン（ユースケースを束ねるごとに開発をプランする）で開発するのだ（図1）。

図1　反復開発は、「計画重視型」「価値固定型」開発

　一方、アジャイル開発は、同じ繰り返し型開発であっても、反復開発とは異なり価値重視の印象がある。計画よりもむしろ開発するソフトウェアやソフトウェアが実現するビジネスの価値を重視している気がする。なぜそのように感じるかというと、反復開発よりもイテレーション（繰り返し）の期間が極端に短く（週単位）、計画よりも変化対応を大切にしており、さらに開発プロセス全体についても最小限の説明にとどめているからである（*2）。

（*2）これらは、「アジャイルソフトウェア開発宣言」（2001年2月に米国ユタ州にて採択）の「プロセス・ツールよりも個人と相互作用」「計画に従うよりも変化に対応」から、「どちらかというと価値を大切にすべき」と読み取れるのである。

　なぜアジャイル開発が計画重視より価値重視と考えるのか説明しよう。プロジェクト当初は、ビジネスの価値を証明するのが難しく、最初に立てた計画どおりにプロジェクトを進めても、ビジネス価値を向上させるのがなかなかできない。なぜなら、ビジネスの価値は計画で決められた「何をすべきか」よりも、実現方法の正しい選択・組み合わせによって、ビジネス価値が保証されるという本質があるからである。また、ビジネス価値を大きく高めるイノベーティブな要求は、実現方法からの突き上げによってハッキリすることが多いのだ。

　このことを、前回の「イノベーションから見たウォーターフォール開発」で使用した図に、文章を追加して説明しよう（図2）。

図2　アジャイル開発の価値主導の本質

　図2は、ウォーターフォール開発の最大の弱点として、2つの試行錯誤「Howの手探り」「Howからの突き上げ」ができないことを示している。

　そういう意味では反復開発も、計画主導のお化けであるウォーターフォール開発の親せきといってもよいかもしれない。しかし、反復を入れることでこの問題が緩和されているのは間違いない。

　アジャイル開発はまさに、「Howの手探りによる価値の保証」「Howからの突き上げによる価値の向上」という2つの試行錯誤を実現するために、短期間でイテレーションしていくのである。さらに、ビジネスの価値は状況によって変化するという問題についても敏感である。短期間でイテレーションさせながら「計画に従うよりも変化に対応」という宣言によって、計画に対する開発者の意識に柔軟性をもたらそうとしている。つまり、イテレーションを行いながら最適なプラン（やるべきこと）を探し出す、これぞまさに「Howの手探り」なのである（図3）。筆者は、この点にアジャイル開発の可能性を強く感じる。

図3　アジャイル開発は、「価値重視型」「価値拡大型」開発

なぜアジャイル開発は大規模開発から敬遠されるのか？

　残念ながら、このようなアジャイル開発の考えは、管理志向の強いマネージャやプロジェクトでは敬遠される。また、かっちりと契約を交わすようなビジネスからも敬遠されてしまう。このことは、アジャイル開発を積極的に大規模開発で使ってみようというチャレンジがなされない原因の1つと筆者は考えている。

　大規模システムでは、ビジネス価値が創出できないことよりも、計画が不明確な契約であるというリスクに対して敏感に反応するようである。企業経営的に安全策を取る傾向にあるために、本来あるべきチャレンジやイノベーションがおろそかにされるのである。そのため、実際には中身の薄い計画であるかもしれないというリスクや、ビジネスの価値が上げられないシステムを開発してしまうというリスク、IT不良財産を抱え込むというリスクなどを見逃してしまうのである。