前編「反復開発の『ここはぜひカバーしたいポイント』」では、反復開発への移行時に生じるであろう要検討のトレードオフについて解説した。中編となる今回主に、開発プロセスとプロジェクトの性質について解説する。「開発プロセス」を導入すればプロジェクトが成功するわけではない。
反復開発は、初期段階におけるリスク削減と価値創成とのバランスを計画的に取ると最も効率的になることが分かっている。つまり、反復ごとに重視するものに優先順位を付ければ、最大の価値を提供する中でビジネス、組織、プログラム、および技術にとって最大のリスクを示す機能の開発を選ぶことになる。しかし、これら2つの目的(最大のリスクと最大の価値)は必ずしも常にそろっているわけではなく、早期の価値創成か早期のリスク削減のいずれかの計画的選択が余儀なくされる。
リスクを削減すれば、既製品(COTS)の選択やアーキテクチャの安定性、そしてチームの効率に関するわれわれの理解など、技術選択の不確実性も減少する。これらの要因と論理的に正しい見積もりを行う力は直接関係しているため、不確実性の削減は見積もりとの食い違いも低減する。
早期のリスク削減と価値創成はプロジェクトの成功にとって重要であるため(図2参照)、適切な基準点を用意することが重要になる。RUPの4つすべてのフェーズが、適切なリスク削減の立証と価値創成の評価のためのプロジェクト成果物の評価が必要な管理マイルストーンで終わるのはこのためだ。例えば、推敲(すいこう)フェーズでは、できる限り多くの技術リスクを洗い出して安定したアーキテクチャを提供したい。チームは、いくつか選んだ実行可能なシナリオや、多くの重要技術やリスクの緩和を反映したリスク一覧と一緒に実行イメージアーキテクチャがあることも示す必要がある。このリスク削減は、可動コードの価値や早期の難しい判断を強行して作り出される価値とのバランスを取る必要がある。あるプロジェクトにとって適切なバランスがほかのものにとっても適切であるとは限らない。
・リスクベースマイルストーンのメリット
リスクベースのマイルストーンには以下のようなメリットがある。
利害関係者の見識。マイルストーンはプロジェクトを利害関係者の厳しい目にさらし、プロジェクトに新鮮な空気を送り込む。関係者の見識は、プロジェクトチームに見えないイベントや状況に対する指示や反応を提供する。
早期の価値創成。難しい判断を下したり、これらが適切な判断であることを実証するときに最大の価値が生まれる。これは、人間の創造性の表れとしてシステムの特性を反映する。これはまた、以下の図に示されるように、プロジェクトの早い段階で最大の革新があることも意味する。
早期失敗の防止。中には、間違った仮定を前提にしており、かなり早い段階から消える運命にあるプロジェクトもある。これらのプロジェクトが不運であることは明らかだが、プロジェクトの間違いに気付く前に膨大な金銭的損失を被ることは回避したい。リスクベースの反復は不良プロジェクトをライフサイクルの初期段階で明確にする。
生産性の改善。技術リスクを早い段階で洗い出すと、アーキテクチャも急速に安定する。これにより、プロジェクトの後半で不意打ちをくらわされる未知の技術的要因が減少し、一段と経済的な実践が可能になる。
見積もりとの食い違いの削減。見積もりに食い違いはつきものであり、食い違いは未知の要因やリスクに比例する。従って、リスクを早い段階で緩和すれば、見積もりとの食い違いも急速に減少する。
・トレードオフ
リスクベースのマイルストーンに移行する際には要検討のトレードオフが多数ある。
新しいプランニング方法論。リスクの緩和は自分が直面しているリスクに基づいて戦略を変更するときに機能する。従って、リスク主導のマイルストーンには、プランを現実に適応させる適応プランニングプロセスが必要になる。「計画には全く価値がないが、計画することは最も大切なことだ」といったアイゼンハワー米大統領の言葉を思い出していただきたい。進化する計画の受け入れに消極的な場合、リスクベースのマイルストーンは適さない。
適応プロセス。適応プランニング同様、プロセスにも適応が必要だ。もし自分のプロセスが過度に規定が多い場合は、図3の「革新」のステージにおいてチームの成功に必要な柔軟性が得られない。プロセスが多いと、革新が生まれることは少なくなる。後の「費用効率」ステージでは、より堅牢(けんろう)なプロセスが欲しくなっていく。
・アンチパターン
リスクベースのマイルストーンには以下のようなアンチパターンが関連してくる。
型にはまったプロセス。チームは、詳細に規定され、「反復可能」ながら、発見したリスクに対応する余地のないプロセスに従うことを余儀なくされる。
ドキュメント主導の追跡。リスクが特定され、リスク一覧に登録され、何らかの形のプロジェクト運営委員会で議論されて、チームが対応する場合でも、それはかなりの時間が経過してからとなる。適切に対応するための時間も予算もないと嘆くだけだったり、単にスケジューリングの都合だけで次期リリースまで延期するというなら、リスクを特定しても何の役にも立たない。
詳細な推測計画。プロジェクト全体の詳細な計画は早い時期で確立され、プロジェクトの残りの部分では追跡による計画に管理が集中する。
・推奨デフォルト
入念に定義され、リスク緩和に重点を置いたRUPの「方向付け」「推敲(すいこう)」「構築」、そして「推敲」の各マイルストーンの利用を推奨する。
Copyright © ITmedia, Inc. All Rights Reserved.