不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する：パート2（前編）：The Rational Edge

The Rational Edgeより：ソフトウェア開発プロジェクトの健全性とスケジュールを保証するには、ライフサイクルの中間フェイズでどの部分を評価すべきなのだろうか？ プロジェクトの健全性を客観的に評価するためのリスクの一覧やバックログといった各種プロジェクト成果物の使い方について説明する。

» 2007年07月19日 12時00分 公開
[Kurt Bittner，IBM新技術プログラムディレクター]

　本稿は、ソフトウェア開発プロジェクト管理の一貫としての評価戦略を解説する3回シリーズの第2回である。本シリーズの第1回「プロジェクトの状態を評価する：パート1」（翻訳記事「プロジェクトのはじめに計画を立てるのは無謀」）では、プロジェクトの健全性を評価するメカニズムとしての評価の概念を紹介し、「方向付け」フェイズにおいてプロジェクトの健全性評価に役立つ具体的な評価値について解説した。第2回は、「メインとなる」開発作業である「推敲」と「構築」の両フェイズの評価に焦点を当てる。

ALT 本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。

　推敲と構築の両フェイズには、同様の評価アプローチへとつながる多数の類似点がある。いずれのフェイズも、主眼はシステムに望まれる機能を漸次インプリメントして増やしていく実行イメージの作成だ。両フェイズの最大の違いは、それぞれが取り組むリスクの違いに起因している。推敲フェイズは、ソリューションのアーキテクチャに影響を与える技術リスクに取り組むが、構築フェイズはプロジェクトの大半の作業をスケジュールや予算どおりに終わらせる際のリスクに対処する。このような違いから、両フェイズにおける評価アプローチの重点の置き方も若干変わってくる。

推敲フェイズ

推敲フェイズ最大の焦点は、「方向付け」フェイズにおける見積もりの基盤に利用される基本技術アプローチの検証と、将来的なソリューションの提供を保証するために必要な技術的詳細の補充だ。検証済みの安定したアーキテクチャに基づいて既存システムに比較的小さい機能強化しか加えないプロジェクトが通常そうであるように、技術的なリスクが低ければ、推敲フェイズはかなり短縮することが可能で、提案中の変更が既存アーキテクチャを壊さないことの確認だけに評価をとどめることもできる。ScrumやXtreme Programmingといった特定の「アジャイル」アプローチにこれに相当するフェイズがないのは、このような理由からだ。これらの手法は、アーキテクチャのリスクが低く、アーキテクチャの変更はすべて通常の開発作業から明らかになる、と暗黙、もしくは明示的に仮定している。

　技術アプローチが妥当であり、「方向付け」フェイズで出ただいたいのスケジュールやコストデータの適性が維持されていることを検証する新たなシナリオ（シナリオとは、ユースケースを通じた「スレッド」、つまり基本的な流れと、場合によっては別の流れとを組み合わせたもの）を実装するのが、推敲フェイズにおける典型的な開発作業だ。計画の観点から見た場合の推敲と構築の両フェイズにおける最大の違いは、作成するシナリオの選択である。推敲フェイズにおいては、リスクに応じてその選択が決まる。つまり、シナリオはリスクに対応可能であるとの理由から選択される。

　技術的に困難だがやりがいのある問題群を解決すると、選ばれたソリューションが技術的に妥当であることの確実性を高めるだけでなく、ソリューションが抱えていて、解決せずに放置するとプロジェクトの脅威となり得る問題を解決する可能性も高い。技術的リスクを排除すれば、貴重な経験と情報が得られ、プロジェクトの残りの部分に関する見積もりや計画の信頼性が大幅に高まる。これは、構築フェイズにおける評価を検討する際の重要な要因となる。

　また、人員配備の観点で見た場合の推敲と構築の両フェイズにおける最大の違いは、推敲フェイズがソリューションの中の技術的なリスクの調査に少人数のチームを使うことだ。推敲フェイズがこのような調査特性を持つことは、残りの作業完了に向けたプロジェクトチームの増強も考えられる構築フェイズまでは、プロジェクトの人員配備と、それに関するコストが拡大傾向にないことを意味する。

推敲フェイズにおける評価

　上述のように、推敲フェイズの最大の目的は技術リスクの削減だ。その結果、同フェイズにおける評価値は、技術的なリスクが本当に低下するかどうかの判断に重点が置かれることになる。図1は、効果的に管理されたプロジェクト（実線）と予想される進展（点線）の典型的なリスクプロファイルを示している。反復の境界は図中の縦線で示されている。

ALT 図1 反復プロジェクトの予想リスクプロファイル

　プロジェクト初期の最初もしくは2回目の反復では、プロジェクトチームがビジネスリスクの発見作業を続けているため、プロジェクトの原動力となっているニーズをもっと詳細に探求していく中で実際には全体のリスクが上昇すること、そして彼らが別の代替ソリューションを検討する中で技術的なリスクが発見されることに注意したい。これ以降で線が下を向くのは、技術的なリスクに重点を置いているためだ。曲線のカーブが一段落する転換点は、技術的なリスクがほぼ排除された推敲フェイズの最後と構築フェイズの最初に対応している。

　プロジェクトの最初の方の段階で進展を評価することも重要だ。図2は、プロジェクトのライフサイクル全体で予想される進展のプロファイルを示している。

ALT 図2 プロジェクトの予想進展図（クリックすると拡大）

　図2のグレーの領域は、考えられる進展観測結果の通常予想領域を表し、曲線は理想的な進展のプロファイルを表している。この図では「方向付け」フェイズ（最初の1?2回目の反復）にも何らかの進展はあるが、異なる技術アプローチをテストして洗練させるため、通常は大量の改訂が発生しても進展が速まらないことに注意したい。

削減リスクの評価

　プロジェクトの早い段階でリスクの一覧にまとめるのは一般的な手法だが、プロジェクトライフサイクルの最後までこの一覧を取っておくプロジェクトは減っている。最重要リスクに確実に重点を置くため、プロジェクトチーム関係者以外も交えて一覧を検討する際は、リスクを上位10種類ほどに絞れる。以下の表に例を示す。

開始時の優先度 リスク 軽減結果
1 ATMの過去バージョンのサポート 何らかの進展はあるものの、さらなる進展が必要。引き続き最優先課題とする
2 Keithの退任 引き継ぎ成功。削除
3 戦略、リソース、および環境のテスト リスクを良好に緩和。削除
4 思ったより（予想より）困難な可能性あり リスク管理に問題はないもよう。一覧には残し、優先度は落とす
5 O/Sプラットフォームの信頼性 一部に進展はあるものの、さらなる進展が必要。次回の反復では優先度を引き上げる
6 J2EEインフラストラクチャのスケーラビリティ
7 要件の内容 リスクを良好に緩和。削除
8 耐障害性 一部に進展あり。一覧に残し、優先度を引き下げる
9 耐改ざん性 リスクを良好に緩和。削除
10 印刷の柔軟性と信頼性 進展なし
上位10種類のリスクの例

　上位10種のリスクは、影響度（最も影響が低いものを1、最も影響が高いものを10とする10段階）に深刻度（最も深刻ではないものを1、最も深刻なものを10とする10段階）を掛けた値に基づき選択される。この数字はリスクのランキングや、プロジェクト全体のリスク低下度の評価にも利用される。効果的に管理されたプロジェクトの予想リスクプロファイル（時間の経過に伴うすべてのリスクの度合いの合計を示す）を図1に示している。

　何度か繰り返しても全体のリスクが低下しない場合は何かがおかしいということだ。チームがリスク削減に用いている戦略が効果的でないために作業を繰り返してもリスクが緩和されないのか、古いリスクを排除するよりも速く新たなリスクが生じてくるケースがほとんどだ。いずれの場合にも、アプローチを変えていく必要がある。技術的なリスクを緩和するための技術的な経験がチームに不足しているのかもしれないし、プロジェクトが反応するより速くビジネス環境が変化しているのかもしれない。いずれにせよ、一連の反復の中でリスクを緩和できないのは大幅なアプローチの変更が必要になっているしるしだ。

進展の評価

　進展は、これまでに実装され、テストに成功したシナリオの数で評価することができる。評価はシンプルなものにし、現実的な目的としてシナリオの複雑性は無視するのが最適だ。図2から分かるように、技術の問題が解決され、チームが共同作業の経験を得ていく中、進展を示す曲線は最初はゆっくりと上昇する。だが、プロジェクトが構築フェイズに入ると、プロジェクトにかなりの勢いがつき、反復の生産性が大幅に高まる。そして完了に近づくと、プロジェクトが仕上げに入り、進展の度合いが落ちていく。

　図2の進展を示すスムーズな曲線は、実装され、テストに成功したシナリオの積み重ねによって得られる。しかし、実際はこのようにスムーズな上昇曲線を描いて進展があることはめったにない。反復型アプローチを使うときは、何らかの改訂の必要が見込まれる。プロジェクトチームに反復や増分ソフトウェア開発の経験がない場合は特にだ。新しいアイデアはいろいろ試され、場合によっては却下されるが、情報が多いほど優れたソリューションが生まれる。従って図4にあるように、図2の曲線は全体の進展を示すものだが、実績を詳細に見ていけば全体の進展も明らかになる。

ALT 図4 進展に対する改訂作業の影響

　実際のところ、時間の経過に伴って改訂が増えるなど、最初に採用したアプローチ、あるいはチームのスキルに潜在的な問題があることを示唆する図4は極端な例だ。これは、実際に起こっていることをもっとうまく把握するために、全体の進展のほかに改訂についても評価することが重要な理由を解説している。進行中の作業は実際の開発作業で、シナリオが分析され、開発が行われ、テストも行われる。そして、インプリメントされたコードがテストに合格すれば進展が生まれる。一方、インプリメントされたコードが不足もしくは不完全である場合は改訂が発生し、インプリメントされたコードの一部が廃棄されたり、改訂が行われる。図5は、プロジェクトのライフサイクルにおいて予想される改訂の傾向を示している。

ALT 図5 プロジェクトのライフサイクルを通じた改訂の傾向

　改訂は初期フェイズでは重要だが、推敲フェイズの最後でアーキテクチャが確立すれば著しく重要度が低下することに注意したい。

　上述のように、改訂は間違った確認作業によって発生するのが一般的だが、要件の変化によっても生じる場合があり、欠陥はプロジェクト開始時から把握しておく必要がある。典型的な欠陥の傾向を図6に示す。

ALT 図6 プロジェクトのライフサイクルを通じた欠陥の傾向

　後編へ続く。

本記事は「The Rational Edge」に掲載された「Measuring Project Health -- Part II」をアットマーク・アイティが翻訳したものです。

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

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ