「この開発プロジェクトは中止!」の基準/プロジェクトの状態を評価する:パート1(後編)The Rational Edge(2/2 ページ)

» 2007年04月19日 12時00分 公開
[Kurt Bittner,IBM新技術プログラムディレクター]
前のページへ 1|2       

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

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


[注2] 例:CoCoMo II、Coarse-grained Wide-band Delphi(世論ベースの評価)、そしてファンクションポイント分析(「ユースケースポイント」を含む)などのモデル。


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

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

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

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

「方向付け」フェイズにおける反復

 プロジェクトのビジネス面の存続能力を判断するには、1回の反復では足りない場合がある。通常、このようなことが起こるのは、プロジェクトの技術もしくは金融面の存続能力を判断する際に想定外の問題が発生するためだ。リスクに関するこれまでの説明に合わせると、プロジェクトに関連するビジネス上のリスクを緩和するには1回の反復では足りないかもしれない。


  通常、「方向付け」フェイズは「タイムボックス化」されている。つまり、このフェイズにはあらかじめ決まった期間(通常は1カ月)が割り当てられている。また、「方向付け」フェイズの反復は1回が普通だ。プロジェクト開始当初には、そうならないと仮定する理由はない。反復が進んで終わりに近づくと、探究を続けるための要領は十分に得ないが、プロジェクトを断念するほど決定的ではない結果になる場合もある。このような場合は、新たな反復に予算を割り当てて調査を完了する。


 筆者が就職して間もないときは、会社では最初のフェイズに「実行性調査」を持つプロセスが利用されていた。この目的は「方向付け」フェイズが果たすが、その内容はやや異なる。一般的に、プロジェクトの技術的実行性を探求するには何らかのプロトタイピングが絶対不可欠だが、古い「実行性調査」は主に机上の作業だった。



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

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


[注3] 実際のところ、プロジェクトの相互関係があるため、プロジェクトのポートフォリオはここで解説されているよりもやや複雑だが、いまはこのままにしておく。ポートフォリオの重要性については次回以降で再度解説する。


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

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

そのほかの評価

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

[参考文献]
本稿は、2006年にAddison-Wesleyから出版されたKurt BittnerとIan Spenceの共著による「Managing Iterative Software Development Projects」から転載した。


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


「The Rational Edge」バックナンバー
前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ