タスク見積の失敗から学ぶ、見積のシミュレーション法

プロジェクトマネージャーが「51日で完了します」と報告する。その数字で顧客にコミットする。44日目にチームが納品する。結果オーライだが、それは偶然だ。見積りは1週間ずれていた。今回は安全な方向にたまたま倒れただけだ。

次は2週間以上遅延する可能性もある。

問題は見積スキルではない。問題は、点で見積もっていることであり、リスクが可視化されないことだ。複数パターンを検討し、リスク判断できないところに弱点がある。

平均値の罠

PERT（Programme Evaluation and Review Technique）は標準的な手法だ。PMBOK第7版でも紹介されている。タスクごとに楽観値・最頻値・悲観値の3点見積りを集め、期待値を計算する。1950年代から使われている手法であり、見積り者に「不確実性を考えろ」と強制する点で優れている。

だがPERTには構造的な死角がある。タスクが並行して走る場合、PERTは最長パスに沿って期待値を合計する。一見合理的だが、ここに落とし穴がある。どのタスクが長引くかによって、最長パスは変わるのだ。

シンプルな依存関係ネットワークを考えてみよう：

要件定義 → 設計 → バックエンド ─┐
                → フロントエンド ─┤→ 結合 → テスト

バックエンドとフロントエンドは設計後に並行して走る。PERTは期待値が長い方（バックエンド）を選んで合計する。だが現実には、フロントエンドが長引いてクリティカルパスになることもある。PERTにはそれが見えない。1つのパス、1つの数字、1つの（偽りの）確実性。この6タスクプロジェクトで計算すると、次のようになる。

• PERTの単純合計は51.5日。
• モンテカルロ法の平均は41.1日。

10日の差がある。誰かの見積りが悪かったのではない。PERTが並行パスの所要時間を二重計上している。この10日間は、実際の作業に対応しない幻の工数だ。

モンテカルロ法とは

考え方はシンプルだ。1つの答えを計算するのではなく、プロジェクトを何千回もシミュレーションする。

各シミュレーションでは、すべてのタスクの所要時間を確率分布からランダムに抽出する（PERTと同じ3点見積りを使う）。依存関係は守られる。結合はバックエンドとフロントエンドの両方が終わるまで始まらない。そしてプロジェクト全体の所要時間を記録する。

10,000回のシミュレーション後、手元にあるのは1つの数字ではなく、分布だ。そしてこの分布は、根本的に違う問いに答える。

• PERTが答える問い：「何日かかるか？」
• モンテカルロ法が解く問い：「木曜日までに終わる確率は何％か？」

クライアントの質問「45日で納品できますか？」に答える

同じ6タスクプロジェクトを10,000回シミュレーションした結果が、次のチャートだ：

ヒストグラムはすべての可能な結果を表している。緑の線がステークホルダーの問い「45日」だ。

答え：82%の確率。

悪くはないが、安心もできない。だが、正直な会話ができる。「45日で納品できる確率は82%です。95%の信頼度が必要なら48日。五分五分でよければ41日が妥当（中央値）です。」

これらの縦線はコミットメントレベルだ：

P85が最適解だ。 コミットできるだけの信頼度がある。かつ、遅すぎもしない。幻のバッファで資源を浪費しない。

PERTの「幻の工数」がビジネスに与える影響

ではPERTの見積り（51.5日）付近でコミットするとどうなるか？

10,000回のシミュレーションのすべて（1回の例外もなく）がそれより前に完了する。100%だ。

絶対に外さない期日に聞こえるが、実態は無駄だ。P85の45.5日で十分な信頼度が得られるのに、約6日間の幻の工数がコミットメントに練り込まれている。

SIerの文脈でこれが何を意味するか。見積が妙に膨らんでいれば、競合に案件を取られる。社内プロジェクトなら、Q2で出せるものがQ3に「念のため」にずれる。近年、バッファを取りすぎるスケジュールに経営者は厳しい目を向ける。我々の経験では、オフショア開発チームから出てきた6ヶ月という見積を精査したところ、1ヶ月で完了できることが判明した。実際、実行したら1ヶ月以内に完了した。

幻の工数はPERTの構造的な限界から生まれる。期待値を1つのクリティカルパスに沿って合計するが、クリティカルパスは固定ではないのだ。

ゴールポストは動かさず、クリティカルパスを動かそう

これがシミュレーションが提供する、点の見積手法では出せない2つ目の洞察だ。

決定論的クリティカルパス分析は1つの直線的なパスを出す：要件定義→設計→バックエンド→結合→テスト。バックエンドがクリティカル。フロントエンドは違う。以上。

モンテカルロ法はそれが85%の場合にしか正しくないと教えてくれる。

残りの15%のシミュレーションでは、フロントエンドが長引いてボトルネックになる。結合はバックエンドではなくフロントエンドを待つ。クリティカルパスが動くのだ。

15%のシミュレーションでクリティカルになるタスクは、決定論的分析では文字通り見えないリスクだ。フロントエンドのチームリードが休暇に入っても、誰も問題視しない。フロントエンドは「クリティカルパスにない」から。しかし、現場ではこういうことはよくある話だ。そして7回に1回、それが原因で遅延する。

属人化の問題がここにも現れる。「クリティカルパスにないから大丈夫」という判断自体が、特定の1本のパスだけを見ている属人的な判断なのだ。シミュレーションはそれを可視化する。

いつ、どちらを使うか（ツールの選択）

すべてのプロジェクトにシミュレーションが必要なわけではない。判断基準はこうなる。

PERTで十分な場合：

• タスクが直列（並行パスがない）
• クリティカルパスが明白で安定している
• コミットメントではなく整合性チェックが目的
• 感で見積もっていた習慣を変えたいとき

モンテカルロ法が力を発揮する場合：

• 並行パスがある — クリティカルパスがシミュレーションごとに変わりうる
• ステークホルダーが見積ではなく信頼度を求めている
• タイムラインに基づく契約・財務上のコミットメントがある
• 見積りが非対称（楽観値と悲観値の幅が偏っている）— 分布の形が重要
• リスク分析が必要な局面、もしくはマルチベンダー構成のとき

覚えておくべきこと：並行パスがない場合、PERTとモンテカルロの平均は一致する。その場合、モンテカルロ法の価値は「分布」そのものだ。PERTのガウス近似では推測でしかない、P85やP95が得られることにある。

実際に試してみる

モンテカルロ・モジュールはオープンソースで、PythonライブラリとしてもREST APIとしても利用できる。uv コマンドを使って簡単にローカルサーバーを立ち上げられるよう設計されており、レポジトリをクローンして、すぐに使い始められる。Pythonコードを少し書くか、FastAPIアプリを立ち上げて確認でき、データはローカルのSQLiteに保存される。MITライセンスなので、既存の商用プロダクトに組み込むことも可能。

• Python: from app.montecarlo.core import simulate_schedule
• API: POST /montecarlo/simulate — タスクリストからのステートレスシミュレーション
• API: POST /montecarlo/scenarios — シナリオの保存と比較

ソース：github.com/lemur47/logic

名前の通り、3点見積は「点」でしかない。分布が重要だ。問いは「何日かかるか？」ではなく「どれだけ確信があるか、そしてより高い確信のためにいくら払うか？」だ。もう「間に合う・間に合わない」という古典的で失敗や摩擦の原因となる問いは今日ここで捨てていこう。

この記事はCognition as Codeシリーズの一部です— PMOの意思決定ロジックを実行可能なコードとして具現化する取り組み。モンテカルロ・モジュールはSprint 6で、PERT、EVM、Bayesian、TCOモジュールとともに開発・検証されました。