さまざまな開発手法

アジャイル開発プロセス

　アジャイル開発プロセスでは1つの開発サイクルを小さく（1サイクルの要求を小さく）し、開発の各サイクルをプロジェクトが完了するまで反復します。問題を細分化し、段階的に開発を進めていきます。アジャイルプロセスの中には、XP、アジャイル統一プロセス（RUP）、SCRUM等のさまざまな方法論があります。

　例えばRUPにおいては、ただやみくもにサイクルを実行するのではなく、各サイクルを「方向付け」「推敲（すいこう）」「作成」「移行」という4つのフェーズに分類し、これらのフェーズを経てリリースにいたります。各フェーズは1つ以上の反復で構成されます。このように、短いスパンで成果物をリリースし、その都度評価を行うことにより、リスクを最小化しようとしたのがRUPのアジャイルプロセスです。

　このように書くと、前述の問題をきれいに解決する銀の弾丸に見えるアジャイル開発ですが、実際に反復型のアプローチを実行していくのは言うほど簡単ではありません。アジャイルでは以下の要素すべてが成り立たない限り、コミュニケーションコストだけが増大してプロジェクトは崩壊します。

・メンバー間の意思疎通
・問題の理解
・解決策の提案

　つまり、このプロセスはプロダクトオーナーに負担が掛かりやすいと言えます。開発者を用意してプロセスに乗せるだけで、希望したものができてくるということはありません。

　しかし、これは「アジャイルだから」という問題ではなく、アジャイルの本質を理解しないまま似非（えせ）アジャイルを実践することによる問題です。アジャイルプロセスの理解は、ウォーターフォールのそれよりもはるかに困難です。

統計・分析における開発現場の実態

　独立行政法人 情報処理推進機構（IPA）の統計（出典：『ソフトウェア開発データ白書　2008』）によると、実に95％以上のプロジェクトがウォーターフォール型のライフサイクルで開発されています。恐らく、ウォーターフォール型のプロセスの方が誰にでも理解しやすいこと、改修案件の場合など前回のプロセスがウォーターフォール型であったため、今回も同じプロセスを採用するという心理が働いたりすることが原因ではないかと考えられます。

　次に、ユーザーの要求仕様に関して、35％以上のプロジェクトは「あいまい」であり、30％以上のプロジェクトで「ユーザー担当者の要求仕様への関与が不十分」という統計もあります。

　その結果、QCDをすべて達成したと評価するプロジェクトは全体の2/3程度で、残りは品質、コスト、工期のいずれかの項目が計画通りに達成できなかったというデータもあります。このように、3つに1つのプロジェクトは、ウォーターフォールの当初の計画通りに進んでないということになります。つまり、プロジェクトの初期段階で完全な計画を立てるのは非常に難しいことが分かります。