ウォーターフォールから反復型への移行手順：The Rational Edge（2/4 ページ）

[Rose Ritchie,Bernie Michalik，＠IT]

当初のプランとその理由

　通常、当初のプランには、ソリューションの概要をクライアントに示すためのデザインフェーズが幾つも含まれていた。これらのプロジェクトではソフトウェアを複数回リリースするため、当初のデザインフェーズはソフトウェアの全体的なデザインをカバーし、それから各リリースにデザインフェーズを用意する。クライアントの要件が明確になり、デザインが構築作業を開始できるところまでくれば、各デザインフェーズも詳細になっていく。

RUPの方が理にかなう理由

　多数のプロジェクトでは、クライアントと一緒にウォーターフォールのプランを見直すと、以下をはじめとする多くの理由から、RUP指向のプロジェクトプランの方が理にかなうように思えてくる。

• クライアントは早く結果を見たがる

　中には、大規模なデザイン作業が完了するまで開発作業の開始を待てないクライアントもいる。彼らには要件が幾つかあり、実際に動作し、関係各所に早急に見せられるアプリケーションコードを見たいという考えがあった。

• クライアントは、最初のリリース期日までにすべての上位要件を提供しないし、できない

　クライアントが、葛藤（かっとう）や各種制約（例：決定事項が懸案中でしばらく決まらないなど）から、計画されたデザインフェーズの終了までにすべての要件を提供できない場合もあった。

• クライアントは、緻密（ちみつ）にコントロールされたプロジェクトスケジュールと予算を望む

　プロジェクトでは要件などの各側面に不確実性が伴うが、緻密にコントロールされたプロジェクトプランを要求するクライアントもいる。われわれのRUP型プロジェクトでは、各フェーズがタイムボックス化されていたため、プロジェクトのスケジュール、各フェーズに必要なリソース、そして各フェーズ終了時点のプロジェクトコストを正確に示すことができた。

• クライアントや開発者は、プロジェクト開始直後からリスクへの対処を考える

　実際に動作するアプリケーションコードをより早く提供することが、期限までにアプリケーションが納入されないリスクを緩和するのに一役買う、というクライアントもいた。われわれの開発チームにも、実際に動作するアプリケーションコンポーネント（特に新技術が関連するアプリケーションコンポーネント）をプロジェクトの早い段階で提供することがアプリケーション開発のリスク管理に役立った、という意見はあった。

• クライアントは、予算に変更があった場合にプロジェクトを切り上げられるようにしたいとも考える

　価値の高い機能をプロジェクトの最初に持ってくることで、RUP型アプローチは、確保できるだけの予算、あるいはプロジェクトに必要な最低限の予算で得られる価値を最大限に生かす柔軟性をクライアントに提供した。もしウォーターフォール型アプローチを採用して至ら、多数のバージョンを生み出す素晴らしいデザインが用意できても、実際にはバージョンを1つ用意する予算しか残らなかっただろう。

変更点

　プロジェクトプランをウォーターフォールからRUPに変更するに当たっては、以下のように多数の変更が行われた。

• プロジェクト構造

　プロジェクト構造の変更は重要だった。上位デザイン、全体デザイン、リリースデザイン、構築、テスト、導入、リリースを繰り返すウォーターフォールのフェーズから、推敲（すいこう）を何度も繰り返し、それからフェーズを何度も繰り返すRUPフェーズへの移行だった。これは反復可能で、移行フェーズも追加できる。

• タイムボックス化

　反復作業部分は、開始前にすべてタイムボックス化された。作業を完成させるために詳述や構築を反復する十分な時間がないと判断したら、作業を次の反復作業まで先延ばしにする。これは、フェーズを延長してデザイン、構築、テスト、あるいは導入を完成させるウォーターフォールプロジェクトにおけるフェーズへのアプローチと異なる。

• リソースの利用

　ウォーターフォール型アプローチでは、構築／テスト／導入フェーズまで残らないリソースがデザインフェーズにあった。RUP型アプローチでは、リソースを最後まで残しておく。プロジェクトによっては、1人でフェーズごとに異なる役割を担う場合もあった。

• 早期開発

　まだ詳述フェーズで、デザインが完成していなくても、アプリケーションのパーツの開発をすぐに始める場合がある。当初のウォーターフォールのプランでは、デザインが完了しないと開発を開始しなかったが、RUP型プロジェクトは、一部のコンポーネントの開発にかなり早期から着手するというリスクを取ることで価値を実現した。具体的には、ユーザーインタフェースのコンポーネントをプロジェクト開始後わずか数週間で開発する場合もあった。こうすることにより、アプリケーションのコンポーネントを頻繁に提示することが可能になり、クライアントが満足してくれた。そして、要件に対して同意を得られるようになった。さらに、アプリケーションの品質（つまり、構築中のアプリケーションがクライアントの要件に合致しているかどうか）を継続的に検証できるようにもなった。さらには、開発チームが未知の新しい技術に取り組みめるようにすることでリスクも低減した（これまで使ったことのない継続フレームワークの利用）。