なぜプロジェクトの見積もりはいつも外れるのか

2026年2月22日

「このタスク？2週間くらいで終わるよ。」

3ヶ月後、タスクはまだ進行中。最初の見積もりが間違っていたわけではない — 不完全だっただけだ。そして「かかるはず」と「実際にかかった」の差こそが、プロジェクト失敗の温床になる。

この記事では、その理由を説明し、それを数式で証明し、再発を防ぐ無料ツールを紹介する。

教科書的な答え

PERT（Program Evaluation and Review Technique）は1950年代から存在する手法だ。考え方はシンプルで、1つの数値を当てずっぽうで出す代わりに、3つの数値を出す。

楽観値 (O): すべてが完璧に進む場合。ブロッカーもサプライズもなし。
最頻値 (M): 現実的なケース。過去の経験から、だいたいこのくらい。
悲観値 (P): マーフィーの法則。依存関係が壊れ、人が捕まらず、スコープが膨らむ。

期待値は加重平均で求める：

E = (O + 4M + P) / 6

標準偏差で見積もりの不確実性がわかる：

σ = (P - O) / 6

ここから信頼区間が導ける。2σ（95%信頼区間）で「95%の確率でこの範囲内に収まる」と言えるようになる。

これは有用だ。一点見積もりよりも確実に改善される。しかし実際には、まだ過小見積もりになる。常に。

なぜ教科書通りのPERTでは足りないのか

この式は、悲観値が現実的な最悪ケースをちゃんと捉えていることを前提にしている。しかし、ほとんどの場合そうはならない。理由はこうだ。

コミュニケーションコストを無視している

「2週間」と見積もったとき、想像したのは作業そのもの — コードを書く、スキーマを設計する、テストを実行する。30分の朝会が45分に伸びることは計算に入れていない。3人が命名規則について2日間Slackで議論し続けることも。承認ワークフローに会議が必要で、会議にはアジェンダが必要で、アジェンダには誰も書く時間がないドキュメントが必要だということも。

情報がチャット、メール、会議、チケット、立ち話と分散して流れる環境では、オーバーヘッドは足し算ではない。掛け算だ。引き継ぎのたびに誤解が生まれる可能性がある。コンテキストスイッチのたびに時間が失われる。

隠れた依存関係を無視している

タスクは孤立して存在しない。別チームがまだ開発中のAPIに依存している。セキュリティレビュー待ちでブロックされているDBマイグレーションに影響する。並行タスクが自分の実装先のインターフェースを変更するが、まだ誰も教えてくれていない。

こうした依存関係がバックログに記録されていることは稀だ。スプリントの途中で浮上し、それぞれが時間だけでなく分散を増やす — 悲観値に含めていなかった類の分散を。

ステークホルダーの利害不一致を無視している

これが最大の要因であり、最も定量化しにくい。

複数の企業やチームがプロジェクトに関わるとき、テーブルに持ち込まれるのは異なる「利害」だ。インセンティブだけではない — 利害だ。この区別は重要だ。

インセンティブは構造的なものだ。契約、KPI、課金モデルに組み込まれている。準委任契約のベンダーにはタイムラインを延ばすインセンティブがある。納期遵守で評価されるPMには見積もりにバッファを積むインセンティブがある。これらは観察可能で、ある程度交渉の余地がある。

利害はもっと広い。戦略的目標、政治的ポジショニング、リスク許容度、レピュテーション — 契約には書かれないが、あらゆる会議での行動を左右するものだ。あるチームは四半期目標のために速くリリースしたい。別のチームは、その機能が自分たちの領域を脅かすから遅らせたい。3番目のチームは、もう気持ちが次のプロジェクトに移っている。

同じプロジェクト。根本的に異なる利害。そしてこれらの利害が収束するまでにかかる時間 — 交渉、エスカレーション、回避策、妥協を通じて — これこそが、教科書の見積もりと現実のギャップだ。

多企業が関わるエンタープライズプロジェクト（SIer案件、オフショア開発、JV）では、この要因だけでタスクが数週間から数ヶ月に伸びることがある。

ギャップをモデル化する

標準PERTではこれらの要因を捉えられない。楽観値や最頻値は変わらないからだ。変わるのは悲観値のテール — しかも、見積もった本人が予見できなかった方向に膨らむ。

これをインサイトタグでモデル化する。現実の複雑性要因に基づいて悲観値を調整する、合成可能な乗数だ。

from pert import estimate_task, FRAGMENTED_COMMUNICATION, MULTIPLE_STAKEHOLDERS

# 教科書PERT
result = estimate_task(optimistic=5, most_likely=10, pessimistic=20)
# 期待値: 10.83日、95%信頼区間: [5.83, 15.83]

# 現実調整済みPERT
result = estimate_task(
    optimistic=5,
    most_likely=10,
    pessimistic=20,
    tags=[
        (FRAGMENTED_COMMUNICATION, 0.7),
        (MULTIPLE_STAKEHOLDERS, 0.6),
    ],
)
# 調整後の悲観値: 45.82日
# 期待値: 15.14日（教科書では10.83）

インサイトタグは楽観値や最頻値を変えない。テールを広げるだけだ。そして期待値は悲観値を含む加重平均なので、テールが広がれば期待値もシフトする。2週間のタスクが現実的には3週間のタスクになり、最悪ケースは3倍近くに膨らむ。

各タグには深刻度パラメータ（0.0〜1.0）があり、自分の状況に合わせて調整できる。2人チームでステークホルダーが1人？低い深刻度。5社が関わる規制対応ありのSIer案件？すべて高い深刻度。

メンタルモデル

教科書PERTが問うのは：「作業にどれだけかかるか？」

現実調整PERTが問うのは：「作業と、作業を取り巻くすべてに、どれだけかかるか？」

この2つの問いの差にプロジェクトスケジュールは殺される。見積もりを殺す変数 — コミュニケーションのオーバーヘッド、隠れた依存関係、利害の不一致 — は未知ではない。ただ、計算に入っていないだけだ。経験あるPMなら誰でも肌で感じている。それに数式を与えただけだ。

試してみる

PERTモジュールはオープンソースで無料で使える：

git clone https://github.com/lemur47/logic.git && cd logic
python examples/standalone/pert/pert.py

依存ゼロのスタンドアロンPythonモジュールとしても、logic APIの一部としても動作する。

3つの組み込みインサイトタグ（分散コミュニケーション、複数ステークホルダー、隠れた依存関係）は、日本のエンタープライズPMO環境での実際のコンサルティング経験から生まれたものだ。独自の乗数範囲でカスタムタグを作ることもできる — プロジェクトごとに機能不全の味は違う。

次のステップ

このツールはより良い見積もりを出す。しかし、より良い見積もりは、予測と結果のギャップから学んで初めて価値がある。そこで登場するのがベイズ更新だ — 実際のプロジェクト結果を使ってインサイトタグの乗数を時間とともにキャリブレーションし、見積もり精度を継続的に改善する。

これが次のロードマップ上のモジュールだ。フォローするなら：github.com/lemur47/logic。

PERTツールを試す

現実の調整がどう見積もりを変えるか、試してみてください。

PERTツールを試す →