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

[Rose Ritchie,Bernie Michalik，＠IT]

維持すべき点

　ウォーターフォールからRUPへの移行では多数の変更を行ったが、当初のプランをすべて捨てたわけではない。

　ほかの活動とのつながり。ウォーターフォールからRUPに移行したわれわれのプロジェクトではすべて、多数のサポートプロジェクトやサブプロジェクトが同時進行していた。オリジナルのウォーターフォールプロジェクトには、自分たちのプロジェクトの重要な作業を、クライアントのプロジェクトの重要な作業と合わせるクリティカルパスがあった。われわれはプロジェクトをRUPに移行する際、クライアントのプロジェクトの重要な作業に関連するスケジュールを書きとどめる、プロジェクトの新しい作業をこれらに合わせて設定した。

　役割分担と資源。われわれのプロジェクトでは、プロジェクトの構造が変化しても、役割分担と資源を常に維持した。同じ能力のある担当者に同じデザイン、開発、およびテストを任せたかったからだ。その上、アプリケーション開発とは関係のない一部の役割（インフラの開発など）もそのまま残した。

　成果物と各種マニュアル。われわれのウォーターフォールプロジェクトで制作予定だった多数のドキュメントは、RUP型プロジェクトでも制作予定だった。クライアントは、われわれのアプローチとは関係なく、重要な成果物（例：総合基本テスト計画）を同じように望んでいる。同様に、サーバやソフトウェアなどのセットアップ方法を詳細に伝えるドキュメントを、どのプロジェクトのインフラを構築するチームに対しても用意した。このことは、使うのがRUPであろうとウォーターフォールであろうと関係なく行った。

　必要な作業量。ソリューションを構築するための作業には、ウォーターフォールからRUPに移行したことで変化が見られたが、作業量としてはアプローチにかかわらずほぼ同じままとなっている。

結果

　ウォーターフォールからRUPに移行したことで次のようなことが分かった。

• クライアントが当初やりたいことをすべて把握していなくても、RUPは要件の管理や結果を出すことに役立った。変更は緻密に管理する必要があり、新しい要件を組み入れる新しいフェーズも追加された。変更点の管理には、タイムボックス化や複数反復が役立った。詳述フェーズにおける複数反復は、タイムボックスの関係で作業を1回の反復で完了できなかった場合に、クライアントが望めば作業を次回に回せることを意味する。同様に、予定より作業が増えそうなことに詳述フェーズで気づいた場合は、一部作業を次回に先延ばしすることで変さらに対応できる。あるいは、クライアントがさらなる追求に価値を見いだしているなら反復回数を増やすこともできる。もしクライアントに予算の都合がある場合は、回数を増やさないことも可能だ。だいたいの場合は、完了済みの反復作業からすでに大きな価値を得られているためだ。
• 構築フェーズにおける複数反復は、要件管理にも役立った。アプリケーションのパーツを反復法によって開発することで、反復ごとにクライアントに自分たちの要件を確認してもらうことができる。もしこのアプリケーションが思い描いたとおりでない場合は、次の反復で変更を加えることができる。これは領域管理にも役立った。
• RUPは、継続的な品質検証にも役立つ。各反復作業終了時にコードを納入したため、RUPによって早めにテストを開始できるようになり、それにより、プロジェクトの後半に入ってから大きな欠陥が発見されるリスクも減少した。
• ビジュアルなモデリングは、クライアントが自分たちの望むものを発見すること、そしてわれわれが彼らが望むものを理解することにも役立つ。間接的には、クライアントとの関係構築にも役立つ。彼らはより一体感を得られるようになり、アプリケーション開発の方向性を管理できているように感じ、これによりアプリケーションがスケジュールどおり完成し、必要なものがすべてそろっているという安心感が大きく高まる。
• コンポーネントアーキテクチャを利用すれば、スタンドアロンで機能するソフトウェアを初期テストの目的でクライアントに提供することができる。作業分担と作業割り当てで開発チームを支援する際にも有効だった。