DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

前回は、プロジェクトの初期見積りは、わずかな手掛かりと過去の膨大なデータをもとに、「まだ見えていない部分」がどれくらいあるかを探り、「まだ見えていない部分」を類推してシステムの全体像をイメージした上で、その全体像に対して見積りを行う必要があることを考察しました。

しかし、それだけではまだ不十分です！「まだ見えていない部分」は、最終的に出来上がるシステムの全体像に潜んでいるだけではありません。システムを作り上げて行く過程、すなわちプロジェクトの実行段階にも潜んでいるのです！

【　プロジェクトの不確実性による影響を見積りに織り込む　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
世の中のシステム開発プロジェクトの成功確率は３０％程度だと言われています。プロジェクトが失敗する原因はさまざまですが、過去プロジェクトの統計をとってみたところ、７０％程度が失敗しているということが事実なのでしょう。当ブログの前回 【第２６回】まだ見えていない部分をどうやって見積りに含めるのか？ のキーメッセージは、「過去のデータを活用し、まだ見えていない部分を推測して、見積りに織り込む！」というものでした。そう、プロジェクトの７０％程度が失敗しているという事実も「過去のデータ」として活用する必要があるのです！

前回のブログの中でＰ子さんが気づいたように、修学旅行に保険証のコピーを持参する目的は、修学旅行中の不測の事態にそなえるためです。たとえば生徒が交通事故に巻き込まれた場合の対策として、病院に付き添うために先生を何人か多めに帯同させたり、病院に搬送するタクシー料金などもある程度見込んでおく必要があります。このような不測の事態に対する予備費用が修学旅行の予算に織り込まれているはずです。

システム開発プロジェクトのスケジュールや予算は、修学旅行に比べて大きいことが多いことから、不測の事態が発生する可能性も高く、不測の事態に備えるための予備費用も相当額必要なことは容易に想像できます。どれぐらいの予備費用を積むべきかを考えるにあたっては、システム開発プロジェクトの７割が失敗しているという過去のデータなどを活用して、これからスタートするプロジェクトの「まだ見えていない不測の事態」を想定する必要があるのです。

「プロジェクトの不確実性による影響を想定して、予備費用を見積りに含める必要がある！」

【　プロジェクトの不確実性：「既知の未知」と「未知の未知」に備える！　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・
では、「まだ見えていない不測の事態」をどのように想定して、見積りにのせるのでしょうか？「見積り」である以上、根拠も無くコストを積むわけにはいきません。根拠の無い予備費用を見積りにのせても、スポンサーに認めてもらえないでしょう。予備コストに根拠が無ければ、不測の事態に対する備えが十分かどうかわからず、常に不安にさらされながらプロジェクト運営をしなければならなくなります。それこそ、何一つ失敗が許されないガチガチのプロジェクト運営となり、かえって失敗の確率が高くなるかもしれません。

類推見積りを行う場合でも、パラメトリック見積り（係数見積り）を行う場合でも、過去のデータに照らして確実と思われる部分と、一応見積りに含めてはいるが自信の無い部分もあるはずです。誰しも自信の無い部分については、うまくいかなかったときのために見積りを多めに積みたいと思うはずです。

このような確実性の度合いを見積り反映するために用いる方法として、「三点見積り」という手法があります。「三点見積り」では、最可能値（最も起こる可能性のある作業に基づくコスト）、楽観値（最もうまく行くシナリオを想定した作業に基づくコスト）、悲観値（最悪のシナリオを想定した作業に基づくコスト）を一定の計算式に当てはめて、期待値を算出します。「三点見積り」の場合は、この期待値の中に不確実性に伴う振れ幅を加味していると見ることができます。最悪のシナリオを想定した追加コストを予備費用として、見積りに上乗せすることもあり得ます。

このように、ある特定の部分に対して、想定される最悪のシナリオに基づき設定した予備費用のことを「コンティンジェンシー予備」と呼びます。「コンティンジェンシー予備」は、それが必要となる最悪のシナリオが特定されていることから、プロジェクトの「個別リスク」に対する予備費用と考えると理解しやすいと私は思います。PMBOK第５版によると、「コンティンジェンシー予備は、ほとんどの場合、プロジェクトに影響する『既知の未知』に備えるための予算の一部とみなされる」と説明されています。（※１）

当ブログの 【第１３回】個別リスクとプロジェクト全体リスクという二つの視点 を思い出してください。プロジェクトの不確実性、つまりプロジェクト・リスクを考える際には、「個別リスク」とともに「プロジェクト全体リスク」という視点も必要です。「コンティンジェンシー予備」が「個別リスク」に対する予備費用だとすると、「プロジェクト全体リスク」に対する予備費用もあるはずです。「プロジェクト全体リスク」に対する予備費用は「マネジメント予備」であると私は考えています。PMBOK第５版によると「マネジメント予備は、マネジメント上のコントロールをする目的のプロジェクト予算であり、プロジェクトスコープ内の予期せぬ作業に備えるものである。マネジメント予備は、プロジェクトに影響を及ぼす『未知の未知』に備えるものである」と説明されています。不確実性のあるプロジェクトを成功に導くために必要な予備費用が、「マネジメント予備」であると考えられます。(※１）

この「マネジメント予備」をどの程度積む必要があるかは難しいところです。過去のプロジェクトの予算に対する実績コストの増減幅を分析し、どのプロジェクトにも一定の割合で「マネジメント予備」を積む方法もあります。また、プロジェクトを特定せず、その組織のシステム開発予算全体に対して、「マネジメント予備」を準備しておくというやり方もあります。

プロジェクトを成功に導くためには、「個別リスク」に備えるための「コンティンジェンシー予備」と「プロジェクト全体リスク」に備えるための「マネジメント予備」が必要であり、見積りに含める必要があるのです。しかし、現実のプロジェクトでは、リスクに対する予備費用を見積りにのせることはなかなか難しいようです。いくら過去のプロジェクトのデータを持ち出して、今回のプロジェクトでもこういう具体的なリスクがあるので、このくらいの予備費用を積む必要があると主張しても、全てのステークフォルダーが納得することはあまり期待できません。

私はその原因のひとつとして、プロジェクト・リスクに対する根強い誤解があるためだと考えています。往々にして、リスクは失敗の卵のように否定的なイメージでとらえられています。失敗するのはマネジメントが至らなかったせいなのだから、マネジメントさえしっかり行えばリスク（失敗）は顕在化せず、予備費用も不要だろうという論理に陥ってしまいかちです。

本来、プロジェクト・リスクは、プロジェクトの不確実性を示すものであり、失敗の卵ではありません。プロジェクトには独自性があり、その結果には自ずと振れ幅があるのです。プロジェクトの見積りは、その振れ幅の中のある期待値に対するコスト設定でしかなく、マネジメントの良し悪しに関わらず、期待値よりも悪い方にぶれることを想定した予備費用の設定は必ず必要です。プロジェクト・マネージャーは、信念を持って、「コンティンジェンシー予備」と「マネジメント予備」を見積りに含めるべきなのです。。。

とはいえ、見積りがステークフォルダーに認められなければプロジェクトはスタートできません。多くのプロジェクトが、不十分な予備費用設定のままスタートせざるを得ないのが現実ではないかと思います。しかし、プロジェクト・マネージャーは、「見積りが誤っているのだからプロジェクトが失敗するのは仕方がない」などと、あきらめてはいけません。そんなことではプロジェクトの成功確率は絶対にあがるわけがありません。そう、予備費用の設定が不十分な状態をコスト制約として、プロジェクトの制約条件として受け入れた状態で、プロジェクトをスタートさせるのです！

それでは、次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　Project Management Institute, Inc.(2013)『プロジェクトマネジメント知識体系ガイド（PMBOK®ガイド）』（第5版）Project Management Institute, Inc.