さまざまな開発手法

開発プロジェクトに内在するリスク

　アジャイルソフトウエア開発という言葉が生まれて約8年が経過しました。その間、従来型であるウォーターフォール開発プロセスと対比して、さまざまな議論が繰り返されてきたのはご存じの通りです。

　本連載では、代表的な開発手法の紹介および、弊社プロダクトであるSIOS Applications（ProjectKeeper / SalesForceAutomation+）における事例を元に、その開発手法の選定に至るまでのプロセスを紹介します。

　開発手法は単純にウォーターフォールが悪い、アジャイルは良い、というものではなく、重要なのはプロジェクトを失敗させないことにあります。どのような開発手法においても、プロジェクトには必ずリスクが存在します。プロジェクト失敗の原因の多くは以下のようなものです。

・スケジュールの欠陥―強気過ぎるスケジュールは悪。予実の乖離（かいり）を生み出す。
・要求の増大（変更）―外的要因も影響し、時間の経過と共に要求は変わっていく。
・人員の離脱―見積もりの時点で、メンバー離職の可能性は大抵考慮されていない。
・仕様の崩壊―仕様はあいまいに作れるが、製品はあいまいに作れない。
・生産性の低迷―少人数チームでは平均値のブレが大きい。能力がマイナスに振れるリスク
（出典：『熊とワルツを』）

　これらのリスクが担保できるのであれば、開発プロセスがアジャイルでもウォーターフォールであっても構いません。それぞれのメリット・デメリットを検討した上、よりプロジェクトが成功しやすい開発プロセスを選択すべきです。

ウォーターフォール開発プロセス

　ウォーターフォール開発プロセスとアジャイル開発プロセスの根本的な違いは、実行可能なソフトウエア（ビルド）を単位として開発を反復するか否かにあります。ウォーターフォールプロセスは、従来のソフトウエア開発において最もポピュラーな開発プロセスであり、「要求分析」「設計」「実装」「テスト」「結合」を順序通りにこなしていきます。滝から水が落ちるように、前工程の成果物に基づき次の工程の作業を行い、前工程への手戻りを想定していません。

　このウォーターフォールプロセスは、開発の早い段階で要求が固定しており、ドキュメントレベルでの設計だけで正しい設計を得られること、つまり前の工程には間違いがないことが前提とされています。ちなみにこの手順は、建築等で適用されるプロセスを参考に作られています。

　しかし、ソフトウエア開発手法は、建築手法のように高度に成熟した分野ではありませんし、根元となる理論のようなものもありません。また、前述の通り開発の現場では要求は常に変化し、一通りの開発が完了した後でさえも変化が続くことになります。

　ユーザーのニーズは固定できず、例えばユーザーがほかのシステムにおける新しい機能を見れば、その機能を導入したくなるはずです。

・システムのユーザーは、自分自身がどんなシステムが欲しいのかを理解しておらず、さらに、要求を明確に伝えることができない。
・仮にすべての要求を明確にすることができたとしても、そのすべてを実装に落とし込むために必要な詳細には達しない。
・仮にすべての詳細を知ることができたとしても、通常それは複雑過ぎて、人間の理解の範囲を超えている。
・仮に人間がこのすべての複雑な要求を理解できたとしても、外的要因により要件は変化する。場合によっては、以前の決定事項を覆すこともある。
（出典：『Iterative and Incremental Development: A Brief History』）

　ユーザーは出来上がったシステムを目の当たりにして初めて、自分たちが望んでいないものを理解します。また、市場は常に流動しており、提案時には最先端の製品であったにも関わらず、開発完了時には市場の期待に沿っているとは限りません。ビジネスは常に変化していくものです。

　その結果、プロジェクトの実績を品質,コスト,工期（QCD）の視点から評価した結果、コストと納期は比較的順守されているものの、品質に関しては計画値に 達しないプロジェクトが20％以上にのぼり、QCDをすべて達成したと評価するプロジェクトは63％にとどまります（出典：『ソフトウェア開発データ白書　2008』）。

　ウォーターフォールプロセスをうまくコントロールし、リスクを担保できるプロジェクトが少なかったという数値の裏付けが、この値から導き出されます。そこで、このプロセスの弱点を克服すべく登場したのが反復開発を軸とするアジャイルプロセスでした。