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

[Rose Ritchie,Bernie Michalik，＠IT]

ウォーターフォールでなくRUPでの作業を検討すべき時期

　ウォーターフォールでなくRUPでの作業を検討するタイミングは次のようなことがきっかけになる。

1. ウォーターフォール型アプローチでは、クライアントがさまざまな側面で問題を抱えている。例えば、デザイン作業の成果を見るタイミングがあまりにも遅過ぎるとのクライアントの指摘がある。あるいは、もっと柔軟性が欲しい、あるいはもっと早くリスクに対応したい、という苦情がクライアントから出るかもしれない。もしくは、単なるプロトタイプや実証コードではなく、実際に動作し、完成時にはアプリケーションの一部になるコンポーネントをプロジェクトの早い段階で見たい、という要望がクライアントにある場合は、RUPがこのような開発スタイルにフレームワークを提供する。
2. クライアントが現在少なくとも1種類のRationalツールを利用している。もしそうであるなら、彼らにはIBM Rationalソフトウェアと、それが実現するアプローチの価値がすでに分かっている。クライアントには、RUPを使えばこれらのツールの価値がさらに高まることを納得させることができる。
3. プロジェクトではソフトウェアの開発が重要な部分であることは明確であり、ソフトウェアはオブジェクト指向になっている。もし自分のプロジェクトが主にネットワークの見直しやサーバの整理統合プロジェクトがメインで、ソフトウェア開発の部分がほとんどない場合は、従来のウォーターフォール型アプローチを使い続ける方が良い場合もある。同様に、ソフトウェア開発の大半がスクリプトや手続き型言語ならば、従来の手法で十分かもしれない。
4. クライアントからは自分たちの一部要件が決まっていないことを伝えられていた。要因としては、未解決の問題、関連プロジェクトの未着手、あるいはそのほかの遅延や不確実性によってプロジェクトがあるフェーズからすべての要件を完全に集められないことが考えられる。

　以上の大半に当てはまるならば、プロジェクトにRUPの採用を検討すべきだ。

最優先事項

• RUP専門家の支援を得る

　ウォーターフォールからRUPへの移行はRUPの専門家が誘導してくれる。彼らにはRUPの利用経験があり、移行で出てくる課題の特定や考慮を支援してくれる。

• RUPと反復型開発の価値を学ぶ

　この移行を進めるに当たっては、「これは変化のための変化なのではないか？」のような疑問を投げかけられる場合がある。そこで、RUPを学び、既存の資産を活用し（ここもRUPの専門家が支援する）、資料（特にRUPの利用成功例のケーススタディー）に目を通す。

• IBM Rational統合ツールセットの活用

　RUPのフレームワークは、同プロセスでのツールの利用方法をツールの手本を介して説明する。Rationalツールとプロセスは別々でも利用可能だが、一緒に利用すれば1プラス1が3になり、極めて強力なものとなる。

• RUPの最優良事例を採用し、RUPの精神に身を委ねる

　プロジェクトプランを再構築するだけでは不十分だ。成功するためには、RUPの精神に身を委ね（Per Krollの記事、「The Spirit of RUP」を参照）、可能な限り最高の結果を出すべくRUPの最優良事例に従いたい。

• RUP型プロジェクトのインプリメンテーションを成功させるためには、自分のクライアントと、そのクライアントの文化を知ること

　すべてが自分たちの得られるメリットにつながるとしても、中にはRUPのすべて、もしくは一部のパーツを採用したがらないクライアントもいる。このようなことには十分注意をし、それぞれに合った形で採用を進める。

結論

　ウォーターフォールの開発手法が（少なくとも当初は）われわれのプロジェクトに採用されてきたことには幾つか理由がある。時折、われわれはウォーターフォール型アプローチに慣れたチームが応札して獲得したプロジェクトに遭遇することもある。ほかにも、プロジェクトを計画するIT専門家が、これまでの同様のプロジェクトに採用してきたものと同じアプローチを繰り返したことがある。さらにはクライアントが、暗に、もしくはカスタムメソッドを使ってすべてのプロジェクトをウォーターフォールで進めることもある。これらのケースでは、ウォーターフォールがある程度の問題を発生させ、クライアントがこのアプローチに固執すれば、だいたいの場合はこれを機能させるべくわれわれが悪戦苦闘することになる。

　例え優れたウォーターフォールのプランであっても、Rational Unified Processベースのプランに切り替えれば、もっと大きなメリットを得られるようになる。この移行を成功させるには、そのクライアントとプロジェクトが優れた移行候補者であることを示す手がかりを探す必要がある。もし手がかりがあるなら、先へと進む前に、変更を検討すべき点や、そのままにしておきたい点を知ることが後々役立つ。しかし、思慮分別のある変更を幾つか行えば、両方のプランの最も良い点を組み合わせ、もっと良い結果を出すプロジェクトが可能になる。