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

The Rational Edgeより：さまざまな理由から、反復型アプローチに強い思い入れのあるソフトウェア開発者が、従来の「ウォーターフォール」方法論に根差したクライアントに対応しなくてはならないケースは頻繁にある。本稿は、Rational Unified Processへの移行でこのような組織を支援する方法について解説する。

[Rose Ritchie（IBM認定シニアプログラムマネジャー）, Bernie Michalik（IBM認定シニアITアーキテクト），＠IT]

　反復型開発テクニックの支持者（特にRational Unified Processと関連するソフトウェア開発の反復手法修得に何年も費やしてきた現場のエンジニアやコンサルタント）は、なぜウォーターフォールが現在もソフトウェア開発組織に幅広く浸透しているのかを落ち着いて考えもせず、従来の手法（「ウォーターフォール」）を批判することが多い。以前から、われわれがクライアントから設計と構築を依頼されたITソリューションのプロジェクトプランを考えるときは、最初はウォーターフォール型アプローチを使ってスタートするプロジェクトが多かった。これらのソリューションは、新しいアプリケーションの開発と、新しいインフラの構築によって成り立っていた。

　いずれにせよ、ウォーターフォール型アプローチでスタートするのは、以下のようなもっともな理由があるためだ。

• ウォーターフォールはこれまでもうまくいっていた
• ほかのウォーターフォールプロジェクトから一部の資産を再利用できる
• チーム（つまり、われわれのクライアントのスタッフ）がウォーターフォール型アプローチに慣れている
• 開発開始前に設計作業をすべて終えておきたいという考えがチームにある
• チームが、ウォーターフォールに固執するほかのチーム（具体的には、ソリューション全体のインフラの設計と構築を行うチーム）と協力する方向にある

　たとえこれらの理由があっても、このようなプロジェクトではRational Unified Process（RUP）を使う方が、ウォーターフォールを利用するより理にかなっている。どの場合でも、われわれはプロジェクトプランと全体のアプローチを変更して反復手法を採用することができた。本稿はこの経験に基づき、1つのアプローチから別のアプローチへと移行するための手法を手順を追って解説する。