【脱・エイヤー】三点見積もり（PERT法）で工数の根拠を出す4ステップ
「メンバーに見積もりを依頼しても、いつも『やってみないとわからない』とはぐらかされてしまう」
「バッファを積んだはずなのに、なぜか納期直前でいつも火を吹いてしまう」
「上層部から『見積もりの根拠を出せ』と詰められ、胃が痛い」
現場でプロジェクトを預かるPMやリーダーにとって、工数見積もりの不確実性は常に頭を悩ませる種です。これらを放置して、根拠のない「エイ！ヤー！」の見積もりを出し続けると、不透明な余裕が積み重なってコスト競争力を失うか、あるいは楽観的な予測が外れて現場がデスマーチに陥るかの二択になってしまいます。
今回は、エンジニアの頭の中にある不確実性を「見える化」し、チーム全員が納得感を持って進められる「三点見積もり（PERT法）」の具体的な導入ステップを解説します。
なぜ「1つだけの工数見積もり」は必ず外れるのか？
エンジニアに「これ、何日かかる？」と聞くと、たいてい「5日です」といった一つの数字が返ってきます。このように、幅を持たせずに一つの確定値だけで算出する方法を「一点見積もり」と呼びます。
しかし、その数字の裏側には、「順調にいけば3日だけど、あのライブラリがバグってたら10日はかかるかも……」というエンジニアの葛藤が隠れています。
結局、エンジニアは防衛本能で多めに答え、PMはそれを削ろうとする。この不毛な心理戦が、見積もりの精度を下げ、現場の不信感を生む最大の原因です。
三点見積もり（PERT法）の基本：3つの数字を再定義する
「1つだけの数字」では表現しきれない現場のリアルを、どうやってスケジュールに反映させるか。その解決策となるのが、不確実性を3つの視点で切り分ける「三点見積もり（PERT法）」です。
具体的には、一つのタスクに対して以下の3つの数字をメンバーに出してもらいます。
| 種類 | 略称 | 定義 |
|---|---|---|
| 楽観値 | O (Optimistic) | 最短日数。全てが完璧に、何のトラブルもなく進んだ場合。 |
| 最確値 | M (Most Likely) | 最も現実的な日数。特別なトラブルも幸運もなく、最も起こる可能性が高い場合。 |
| 悲観値 | P (Pessimistic) | 最長日数。想定されるリスク（技術トラブル、仕様不備など）が全て顕在化した場合。 |
なぜこの「3つの数字」を出すのが効果的なのか？
三点見積もりが優れている理由は、「不確実なものは、不確実なまま出していい」と許可を出す点にあります。
「最短」と「最悪」の両端を切り出すことで、エンジニアの心理的ハードルが下がり、結果としてよりリアルで精度の高いデータが集まるようになります。また、悲観値を共有することは、そのままチーム全体のリスク管理リスト（何に備えるべきか）に直結します。
【実践】現場で即機能させる4ステップ
では、具体的にどう導入していくか。実務的な4つのステップで進めます。
Step 1: リスクを分解して「三点」を聞き出す
単に「三点出して」と言うのではなく、ヒアリングの際にこう問いかけてみてください。
- 「トラブルが全くなかったら、最短でいつ終わる？（楽観値）」
- 「逆に、何が起きたら工数が2倍に膨らむかな？（悲観値）」
こう聞くことで、エンジニアの頭の中にある「懸念点」が具体的にあぶり出されます。
Step 2: 期待値（E）を算出する
3つの数字が出たら、以下の加重平均の式で「期待値」を算出します。
【Point】なぜ最確値を4倍するのか？ 単なる平均ではなく、確率統計的に「最も起こり得るケース（最確値）」に重みを持たせることで、現実的でありながらリスクも加味した「論理的な一本の数字」を導き出すためです。
Step 3: 標準偏差（σ）で「リスクの幅」を可視化する
さらに、見積もりのバラつき（不確実性の大きさ）を示す「標準偏差（σ）」を求めます。 現場の言葉に翻訳すると、「最悪の場合、予定から何日ブレる危険があるか」を示す指標です。
この値が大きいタスクほど、「今の段階では予測がつかない危険なタスク」であることが一目でわかります。
- 現場の目安： 標準偏差（σ）が期待値（E）の 20〜30%を超える ような場合は、PMとして注視すべき場所、あるいは先行して技術調査（スパイク）を入れるべき場所だと判断できます。
Step 4: 根拠としてステークホルダーに提示する
「なんとなく10日です」と言うのと、「三点見積もりで算出した結果、期待値は8.5日ですが、不確実性が高いため最大12日見ています」と言うのでは、説得力が全く違います。
根拠があるからこそ、無理な短縮要求に対しても論理的に交渉ができるようになります。
実践事例：難易度の高い「決済連携API」の開発
あるプロジェクトで、外部仕様が不透明な「決済API連携」を実装するケースを考えてみましょう。 現場では、よくこんなやり取りが発生します。
PM：「この決済APIの連携、どれくらいかかりそう？」
エンジニア：「うーん、ドキュメント通りにすんなりいけば3日で終わりますけど、認証方式ではまってサポートに問い合わせとか発生したら、最悪15日は飛びますね。まあ、普通の不具合修正くらいなら5日ってとこでしょうか……」
この会話から、3つの数字を抽出します。
| 指標 | 見積もり日数 | 根拠・想定される状況 |
|---|---|---|
| 楽観値 (O) | 3日 | ドキュメント通りに疎通が完了する |
| 最確値 (M) | 5日 | 軽微な不具合修正や、数回のQAを想定 |
| 悲観値 (P) | 15日 | 認証方式の急な仕様変更や、審査落ちが発生する |
従来の「1つだけの見積もり」では、エンジニアは心理的負担から「5日」と答えて遅延するか、多めに「10日」と答えてバッファを埋没させるかのどちらかになりがちです。しかし、三点見積もりを用いると以下のようになります。
- 期待値（E）： （3 ＋ 4 × 5 ＋ 15） ÷ 6 ＝ 約 6.3日
- 標準偏差（σ）： （15 － 3） ÷ 6 ＝ 2日
この計算結果は、単に「6日くらいで終わる」という意味ではありません。 「約6.3日という期待値をベースにしつつ、±2日程度の変動リスクを常に抱えている」という構造を可視化したものです。
これを受けたPMは、以下のような「攻めの管理」が可能になります。
- 基本は6.5日程度で線を引くが、不確実性が高いので 2日分の予備バッファを別枠で確保 する。
- 悲観値の最大要因である「審査落ち」を防ぐため、初日に先行して審査基準の調査・問い合わせ を行う。
規模が大きいほど精度が上がる「相殺の力」
三点見積もりは、細かいタスク管理用だと思われがちですが、実は規模が大きくなればなるほど、その真価を発揮します。
- 小規模（数日）： 個人の「不安」を吸い出し、遅延の兆候を早めに察知する。
- 中規模（数人月）： 「決済周りは悲観値が大きく振れているからシニアエンジニアをアサインしよう」といった戦略的な人員配置に役立つ。
- 大規模（何十人月〜）： 全機能の期待値を足し合わせることで、論理的な全体スケジュールを算出できる。
一点見積もりを積み上げると、全員が「余裕（バッファ）」を隠し持つため、全体のスケジュールが不必要に長くなりがちです。
一方で三点見積もりを使うと、「あるタスクはトラブルで遅れたが、別のタスクは順調で早く終わった」という具合に、現場のトラブルと幸運が打ち消し合う（相殺される）様子を計算に含めることができます。
統計学上の正規分布に基づけば、全タスクの期待値の合計に「標準偏差の2倍（2σ）」を加味することで、約95%の確率でその期間内に収まるという予測を立てられます。経営層に対し、データに基づいた精度の高いコミットが可能になるのは大規模プロジェクトならではのメリットです。
まとめ：三点見積もりを成功させる明日からのアクション
三点見積もりは、単なる計算手法ではありません。メンバーが抱えている「不安」を数字として表に出してもらい、それをチーム全体のリスクとして共有するためのコミュニケーションツールです。
導入にあたって、以下のチェックリストを意識してみてください。
- [ ] 「悲観値」を出すことを歓迎する： 悪い情報を早く出すことがチームへの貢献であるという文化を作る。
- [ ] 期待値（E）を共通言語にする： 個人の「勘」ではなく、論理的に導き出された期待値をベースに会話する。
- [ ] 「幅」をリスク管理に活かす： 標準偏差（σ）が大きいタスクは、早めにプロトタイプ検証を行うなどの対策を打つ。
- [ ] 定期的に再見積もりする： プロジェクトが進行し、不確実性が減った段階で数字を更新して精度を高める。
不確実性を隠さず、論理的にコントロールする。これができれば、現場の「ギリギリの戦い」は確実に減っていきます。まずは次の定例会議で、最も不安なタスクについて、メンバーから「三つの数字」を聞いてみることからはじめてみませんか？
あわせて読みたい：確保したバッファをどう管理する？
三点見積もりで可視化した「予備バッファ」を、個人のタスク内に隠さず、プロジェクト全体でどう安全に管理・消費していくか。これには、CCPM（クリティカルチェーン・プロジェクトマネジメント）の考え方が非常に役立ちます。
バッファの食いつぶしを防ぎたい方は、以下の記事も参考にしてください。納期遅延を防ぐCCPM｜バッファ共有の基本と遅延を立て直す4ステップ
