メディア

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

» 2006年07月21日 12時00分公開

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

◆ 当初のプランとその理由

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

◆ RUPの方が理にかなう理由

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

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

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

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

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

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

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

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

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

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

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

◆ 変更点

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

・プロジェクト構造

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

・タイムボックス化

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

・リソースの利用

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

・早期開発

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

◆ 維持すべき点

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

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

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

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

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

◆ 結果

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

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

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

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

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

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

本記事は「The Rational Edge」に掲載された「Converting a project from a waterfall to an iterative approach」をアットマーク・アイティが翻訳したものです。

「The Rational Edge」バックナンバー

前のページへ 1|2 　　　　　　