Tweet

「この開発プロジェクトは中止！」の基準
プロジェクトの状態を評価する：パート1（後編）

IBM新技術プログラムディレクター
Kurt Bittner

2007/4/19

前のページ｜1　2｜

◆ 技術存続能力の評価と総プロジェクトコストの見積もり

　理論上、予想されるコストの見積もりは、履歴コストデータに基づく母数推定モデルから得られるが[注2]、手元にあるプロジェクト関連の入手可能なデータが不足するということは、プロジェクトコストの推測とデータの計画のために小さいながらもシステムを象徴するような部分の構築が必要になるのが普通だ。これは、複数の象徴的なシナリオの選択と、それを実現するソフトウェアの開発に役立つ。システムの大量の機能を「もみ消す」必要があっても、通常はこうすることでプロジェクトの技術関連の複雑な部分の仮定が正しいかどうか確認できる。母数推定モデルがあっても、早い時期にプロトタイピングを行うことが母数推定値の確認に役立つ。

　このような早い段階でのプロトタイピングから、2つの重要な結果が生まれる。プロジェクトが技術的に実現可能なことの質的評価と、プロジェクトのスケジュールとコストに関する量的評価だ。早い時期のプロトタイピングから得られる未加工データは、大体の場合が最低1つの推定モデルに送られてコスト情報を導き出す。複数のモデルを使うのは、推定値をクロス確認するのに有益な方法だが、これらのモデルから得られる予測が大幅に異なるのは、自分の仮定をもっと慎重に分析しなくてはならないしるしだ。

　前編の図3はプロジェクトで予想されるリスク曲線を示しているが、リスクは最初の「推敲」フェイズでピークに達し、その後は低下していく。この曲線が目指すべき理想的なリスクのプロファイルを示していることに注意したい。これは、積極的かつ果敢にリスクを管理しない限り実現できない。リスクの数を減らし、その深刻度を低下させる単純な時間の経過に不思議なことは1つもない。

　リスクをコントロールするためには、どのようなリスクに直面し、それをどのように緩和する見通しなのかを感じる必要がある。多くのプロジェクトはプロジェクトの初期段階でリスクを一覧にするのが普通だが、重要な管理ツールとして活用しなければ、このリスクの一覧はほとんど役立たない。リスクを一覧にするだけでは不十分で、これらのリスクを全体のプロジェクト計画の中で繰り返し割り当てから、反復計画の中で反復に伴うリスクの緩和作業計画を立てる。リスクを反復に割り当てる最初の段階では、プロジェクト活動の詳細な計画を立てる必要はない。当面はリスクを反復に割り当てるだけで構わない。そうすれば、十分早いタイミングでリスクに対処できているかどうかの感覚はつかめる。リスクを反復に割り当てるときは、必ず大きいリスクを反復の初期に割り当てたい。このようなマッピングを行うには、直面する可能性のあるリスクを理解するだけにしても「方向付け」フェイズでの何らかの探究作業が必要になる。

　これらのリスクをマッピングし、これらのリスクへの対処に必要な作業を何らかの知識に基づいて推測すると、反復ごとに必要なリソースが感覚的に分かるようになる。繰り返しになるが、目標はプロジェクトの人員配備に関する大まかなロードマップを用意することであり、詳細な計画を立てることではない。この人員配備モデル（「モデル」の響きが重過ぎるなら「マップ」でよい）は、コストのタイミングを確立することで見積もり全体に情報を提供する。

◆ プロジェクトの存続能力の判断

　財政的存続能力は2段階のプロセスになるのが普通だ。最初に、製品化に要する時間を要因として考慮する。特定の期間内にソリューションを市場に提供できないのではプロジェクトを完了する価値がない場合もある。製品化に要する時間の要件を満たせれば、提案されているソリューションのNPVは計算できる。NPVがマイナスだとプロジェクトを遂行する価値はない。NPVがプラスの場合は、これより高い価値のあるプロジェクトへの投資と競合しないことが条件になるものの、そのプロジェクトを遂行する価値はある。［注3］

　目標へのリスクの加味は主観的になる傾向があり、予測の変動を高める、つまり「許容誤差」を広げることで最良の結果が得られる。このフェイズにおける見積もりの大半は、実際には非常に主観的で、大きく外れる可能性がある。予測に関する質問で最も大切なのは「正確なのか？」ではなく、「各値の幅はどの程度なのか？」だ。もう1つの方法として、予測の変動には、NPVの計算の中でプロジェクトの必要収益率を引き上げれば対応できる。通常、期待されるケースと最悪のケースの値を判断するには多数のシナリオを分析する。プロジェクト遂行の判断は、最悪のケースのNPVが許容範囲内に収まっているかどうかで決まることが多い。

　一度ソリューションを導入したら、実績を評価するものとして予想NPVが重要になってくる。

◆ そのほかの評価

　予想NPVが「方向付け」フェイズにおける最も重要な評価値であることに変わりはないが、資金を投入するプロジェクトではほかの評価値も検討する必要がある。

　■ 主観的評価には以下のようなものがある：

　顧客満足度。資金を出す組織が進展に満足しているか？

　士気。プロジェクトチームは進展に満足しているか？（少なくとも慎重に考えて）成功する自信はあるのか？

　■ 客観的評価には以下のようなものがある：

　絶対的な進展。予想されるタイムフレーム内でフェイズが完了するかどうかで評価する

　要件の安定性。プロジェクトの目標がフェイズの中で変更される割合で評価する。変更の多さはプロジェクトの目標がまだ流動的なことを意味し、それはNPVの見積もりが一部もしくは全部疑わしいことを意味する。

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

　リスクの安定性。プロジェクトのリスクが発見される量で評価する。何が分からないのかを知ることは難しいので、これも一部は主観的な評価だが、大きな新しいリスクがかなり頻繁に発見されるということは、先へ進められるほどソリューションやビジネスニーズを十分に理解していないのかもしれない。

　プロジェクトを順調に進めるには、プロジェクトを通じてデータを収集し、それを期待値と比較する必要がある。「方向付け」フェイズ終了後の評価ではデータは多くないが、フェイズを終了する前にデータ収集用のメカニズムを用意する必要がある。これらの評価は、どれも絶対値より傾向の方が重要だ。

• 手間。実際と予想
  
  
• 欠陥の発見と修正の傾向。実際と予想
  
  
• リスクの発見と緩和。実際と予想
  
  
• 未計画作業の特定とインプリメント。範囲の変更も含む
  
  
• 計画された作業のインプリメントとテスト。実際と予想

　これらのどれも予測値はかなり粗い。計画的作業のようなものは、シナリオを反復にマッピングするだけで十分だ。プロジェクトのその後のフェイズでこれらの評価値をどのようにするかは次回以降で説明する。

　まとめると、このように粗くはあるものの、これらの最初の評価は、プロジェクトの進展と状態を評価するためのフレームワークを提供する。このフレームワークは、プロジェクト全体を通じて、プロジェクトが順調に進んでいるかどうかの評価に利用される。

　プロジェクトに投資しないという判断も、引き渡す事業価値と技術の実行性を評価した上でのものであれば、「方向付け」フェイズの結果として完全に満足できるものであり、これを失敗と考えるべきでないことは指摘しておきたい。実際のところ、ほかのもっと価値のあるプロジェクトにリソースを割り当てられるようになるなら、プロジェクトには今後投資しないという判断も考え得る最善の結果かもしれない。

◆

　どのプロジェクトチームも、時間とコストを最小限に抑えてプロジェクトの成功率を拡大することを目標にしなくてはならない。この全体的な目標は、何らかの改善された機能を、希望の期間内に良好な品質と許容範囲内の事業価値を持たせて顧客に引き渡す、というビジネスの全体的な目標に結び付く。

　適切な評価値を利用することは、重要なものに関する明確な指標をチームメンバーに提示することにより、これらの目標達成に役立つ。明確な評価は、目に見える形でプロジェクトのパフォーマンスやプロジェクトの状態に結び付くものであり、チームによる製品投入を実際に成功へと導くのに役立つものだ。評価をシンプルにしておけば、チームが集中するのに役立つ。また、シンプルな評価にはほかにもいくつかメリットがある。これらは報告に関するオーバーヘッドを削減し、評価値の理解を容易にもする。適切なものを評価すれば健全なプロジェクトの行動が促進されるが、誤ったものを評価すると、時間やリソースが無駄になるだけでなく、重要なものがチームに誤って伝わってしまう。

　ライフサイクルのフェイズに応じて評価を変動させれば、注目することが非常に重要なタイミングで最も重要なリスクや問題に集中できるようになる。プロジェクトのリスクを徐々に低下させることが反復型アプローチの真価だというが、適切な評価値でこれを補えばチームがこれを実践できるようになる。

　「方向付け」フェイズでの評価は、主にプロジェクトの財政的および技術的な存続能力を確認することに重点を置き、それによりコストと全体のスケジュール、そして今後のプロジェクトにおけるリスクの緩和目標を確立する。財政的な存続能力は、市場のニーズと機会の分析に基づいて時間の経過に伴うキャッシュフローで表すが、技術的な存続能力は、代替技術アプローチを探求する最低1つのプロトタイプと、そのコストやメリットで評価する。このフェイズの最後までには、これらの探究から得られた情報が、プロジェクトの後半でこれが順調かどうか判断する評価フレームワークの基盤になる。

前のページ｜1　2｜

	Page1 「方向付け」フェイズで評価するもの
	Page2 技術存続能力の評価と総プロジェクトコストの見積もり

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）