ITプロジェクトの未来を、Best・Most Likely・Worstの3仮説で見える化する
itpjstudy
以前の回で、折れ線グラフなどで、過去のトレンドを追って行けば、未来予測ができるようになるというお話をしました。しかし、過去のトレンドだけでは、未来をひとつに絞ることが難しいことも多いです。そういった場合は、ひとつに絞る必要はありません。
多くの場合、Best Case（最良の仮説）、Most Likely Case（最も起こりやすい仮説）、Worst Case（最悪の仮説）の3つに分けます。未来予測・シミュレーションも、仮説のひとつですから、いくつか場合分けがあって当然なのです。
未来予測には“意思入れ”と”仮説”が入り込む
未来予測のためにシミュレーションをするときというのは、たいていスケジュール遅延が起きていて、プロジェクトがうまくいっていません。そのため、「このまま行くと、どうなるのだろう」と過去のトレンドから、着地予想をします。[詳しくは、別記事を参照]
下記は、システムテストにおいて、シナリオ完了予定に実績が追い付いていない事例です。このままだと、4週間（1か月）ほどの遅延になることが見込まれています。
そして、大きく遅延することが分かった場合は、色々な対策を打ってリカバリしようとします。下記のケースでは、3つの打ち手を実行して、なんとかスケジュール通りに完了させようとしています。
つまり、そこに「リカバリ」しようという意思が入ります。また、その効果には、期待も含めて「こうなるだろう」という仮説が入ります。
さて、ここからが本題です。
皆さんもご経験があると思いますが、これらの打ち手が期待通りの効果を発揮するのか分からない。そもそも、効果があるのかどうか確信が持てないことも多いです。そこで、いくつかのケースを準備することになるのです。
ITプロジェクトの未来を描く3つの仮説 | Best・Most Likely・Worst
細かく分けると、本当は3つ以上に分けられることが多いと思います。しかし、あまり細かすぎると、逆によく分からなくなるため、たいていは3つのケースにまとめます。
Best Case（最良の仮説）
すべてうまく行ったと仮定した場合のシミュレーションです。この例では、前述の3つの打ち手がすべて想定通りの効果を発揮したと仮定しています。
Most Likely Case（最も起こりそうな仮説）
打ち手をいろいろ考えるものの、実際には全部がうまく行くことは少ないです。今回は、パフォーマンス改善と不具合の解消は勝ち見込みがあるが、要員追加は社内事情もあって難しいと想定しています。そのため、当初の予定通りには収まらず、2週間遅れでシステムテストが完了するとシミュレーションしています。
Worst Case（最悪の仮説）
そして、重要なのが最悪の場合を想定しておくことです。この例では、すべての打ち手が期待通りに効果を上げられなかったと想定しています。そんなにダメなことは滅多にないだろうと思いたいですが、残念ながら、それなりの確率で、このWorst Caseに着地します。
なぜ3つの仮説が必要なのか | 楽観バイアスと意思決定の安定化
少なからぬ確率で、Worst Caseに着地するというお話をしました。これは、人間心理によるところも大きいと考えます。
リーダ
これ以上のテストの遅れは許されない。考えられるだけの対策はした。これでうまく行くはずだ。
大変なプロジェクトでは、皆、なんとか窮地を脱しようと懸命に考えています。そして、Best Caseになるように懸命に努力しているときには、打ち手の効果を大きく見積もりがちです。
チームメンバを鼓舞したり、マネジメントに最善を尽くしていると説明をしたりする過程で、ついつい「うまく行くはずだ」と自分自身を自ら洗脳してしまうこともあります。
そのため、シミュレーションのケースをひとつだけでなく、3つ考えることが重要なのです。Worst Caseまで含めて考えることで、「本当に打ち手は効果を発揮するのか？」と冷静に戻るきっかけを与えてくれます。
Worst Caseを仮説として持つ効果① | サプライズを防ぐ
前述したように、マネジメント報告の際に、ついポジティブに状況説明してしまうということは、よくあることだと思います。うまく行っていないと報告すると、自分のマネジメント能力が疑われますし、最悪、プロジェクトを止められてしまうかもしれないからです。
スケジュールが遅れていると聞いていますが、大丈夫ですか。既に大幅に予算を超過しているから、これ以上はダメですよ。
リーダ
（うまく行く可能性が高いと思ってはいるが、そうでない可能性もある。しかし、いまここで、うまく行かない可能性があると説明すると、プロジェクトを止められてしまうかもしれない。まずは止めないで、進むことが大事だ。）
リーダ
色々と対策を実施しているので、今回はうまく行きます。大丈夫です！
こうした場合、後日やっぱりうまく行かず、大幅に遅延。マネジメントにとっては、大きなサプライズとなることも多いです。しかし、3つのケースを用意して説明すると、説明も変わってきます。
リーダ
色々と対策を実施したので、今回はうまく行く可能性が高いと思っています。
しかし、〇〇が効果を発揮しない可能性もあり、その場合は、スケジュールの見直しが発生してしまいます。そうすると、Worst Caseまでコストが膨らむ可能性が出てきます。
もちろん、ケース分けをしたからといって、マネジメントが許してくれることは少ないです。ただ、「Most Likely Caseで着地すると思います。しかし、最悪の場合...」と説明すれば、Wort Caseも説明しやすくなるのではないでしょうか。
Worst Caseを仮説として持つ効果② | リスク対応がスムーズ
Worst Caseを考えることのメリットは、他にもあります。不測の事態の心構えができることです。Best Caseしか考えていないと、いざというときの対応が遅くなりますし、その結果、スケジュールやコストにも悪影響を与えます。
プロジェクトが大変なときは、目の前の作業に集中したいものです。また、色々なケースを想定して準備をしておく時間も勿体ないと思ってしまいます。
しかし、リスクヘッジは大事です。コストや作業負荷次第ではありますが、大きなリスクを回避するために、Worstを考えておくことは重要です。
不測の事態に備える例
| Worst Caseに陥った際の影響 | アクション |
|---|---|
| システムテスト完了が10月に間に合わない場合、4月カットオーバーが、5月カットオーバーに後ろ倒しになってしまう | システムテストの遅れが一定程度拡大したら、期末移行から期中移行への作業変更を検討開始する |
| 要件定義が1か月以上長引いた場合、ヨーロッパメンバが夏季休暇期間に入ってしまう | ヨーロッパメンバの夏季休暇期間を、予めずらしておき、要件定義遅延の影響を受けないようにする |
| システムテストの不具合が想定上に出た場合、残業では吸収できず、スケジュール遅延になってしまう | 最初の1カ月のテスト実施は、予め少なめにしておく。人員増強が必要となった場合でも、1か月あれば手配可能 |
今回は、未来予測をBest, Most Likely, Worstの3つのケースで考えるというお話をしました。大事なことは、シミュレーションは、仮説でしかないということ。未来予測をひとつしかしなければ、多くの場合、Best Caseで立てがちです。また、Worst Caseというのは、報告をためらいがちです。
そういう意味で、Best, Most Likely, Worstの3つのケースを考えるというのは、よくできてた方法だと考えます。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
