Day 040 — PM-計画: 見積もり手法（三点見積もり）

2026-09-28 (Mon) 🟢 Junior PM-計画（計画・WBS） 成果物: 三点見積もり表＋パス別の完了確率＋締め切りの引き直し＋バッファと判断日＋事業部長向け1ページ報告

🎬 シナリオ

Day030 で WBS を作った「福袋オンライン抽選予約」（応募受付 12/20（日）10:00 開始。プレスリリース・SNS 広告で告知済み）の続き。今日は 9/28（月）。キックオフは 11/9（月）。

💬
チームリード「開発完了の締め切りは 12/9（水）。12/10〜12/15 が QA の総合テスト、12/16〜18 が本番リハーサル。キックオフから 12/9 までは稼働 22日。担当者の見積もりを足すと決済・抽選系が 20日、受付・負荷系が 17日。2日余るから大丈夫だね」
🏢
EC事業本部長「12/20 は絶対に動かせない。10/2（金）の定例で、間に合う確率を一言で教えてほしい。足りないなら、何を諦めればいいかも」

あなたは「2日余る」が何%の話なのかを確かめるため、担当者それぞれに楽観値 O・最頻値 M・悲観値 Pを出してもらった（単位: 担当者の稼働日）。

パスA（E1 = あなた: 決済・抽選系。上から順に1人で進める）

WBS作業パッケージ単一OMPP の理由（担当者のコメント）
2.3決済状態遷移の設計3236決済代行の仕様書に無い挙動が見つかると問い合わせ待ち
3.3オーソリ確保（応募時）21.525決済代行のテスト環境（sandbox）が不安定だと止まる
2.2抽選ロジックの設計3236第2・第3希望の繰り越しルールでマーケと揉めると延びる
3.2抽選ロジックの実装4349公平性の検証で偏りが出たら作り直し
3.4/3.5本会計・オーソリ取消3238sandbox 依存。取消失敗時のリトライが仕様不明
3.6未決済の無効化・繰り上げ当選223748時間タイマーと繰り上げの連鎖。初めて作る種類
4.3決済状態遷移の全パターンテスト3238sandbox 依存。パターン数が多い

パスB（E2: 受付・負荷系）

WBS作業パッケージ単一OMPP の理由
2.1応募フォームの設計21.523デザイナーと並行。大きな不確実性なし
2.5アクセス集中対策の設計3236待機列の方式選定
3.1応募フォームの実装3235—
3.8アクセス集中対策の実装4349CDN 設定変更はインフラ担当の承認が要る
3.7重複応募検知の実装3237本人確認情報の突合ルールが法務確認次第
4.5負荷試験2238インフラ担当の負荷試験枠が取れないと最悪2週間待ち

その他の事実（演習シナリオ上の設定値）

項目値出所
応募受付期間12/20 10:00 〜 12/27 23:59実測 告知済み
抽選・当選発表12/28（月）12:00実測 マーケと合意
本会計の期限12/30（水）12:00。未決済なら当選無効 → 繰り上げ当選実測 Day030 の要件
オーソリ有効期間60日（12/20 のオーソリは 12/28 の本会計まで有効）実測 代行仕様書（シナリオ上の値。実物は要確認）
1.0 要件定義10月中に完了し、11/9 以降のパスに乗らない仮定
他の作業パッケージ2.4/2.6/3.9/4.1/4.2/4.4/5.x は QA・デザイナー・リードが並行で持つ仮定
E1 の R1 支援12/10〜12/14 のうち3日は総合テスト・リハーサル支援仮定
福袋の在庫合計5種類で 3,000個実測 企画書
過去5件の「実績 ÷ 単一見積もり」1.12 / 1.35 / 1.08 / 1.25 / 1.41実測 振り返り記録

📝 課題

あなたのタスク: 10/2 の定例で事業部長に出す見積もりの資料一式を作ってください。

  1. 三点見積もり表: 13件それぞれの期待値 E と標準偏差 σ
  2. パス別の完了確率表: 各パスの E・σ、50%／85%／95% の日数、22日以内の確率。2本とも間に合う確率も
  3. 締め切りの引き直し: 13件すべてが本当に 12/9 までに要るのか。作業ごとに「本当に要る時点」を書き、リリースを分けた場合の確率を出し直す
  4. σ の足し方の点検: 同じ原因で一緒に遅れる作業は無いか。あるなら確率がどう変わるか
  5. バッファと判断日: 担当者に渡す目標、バッファの量と置き場所、「この日までにここが終わっていなければ、これを諦める」判断日
  6. 事業部長向け1ページ報告: 「一言で」の答えと、事業部長に決めてほしいこと
  7. 採らなかった案: 2つ以上、理由と判断が変わる条件つき

🔍 ヒント（段階的開示）

ヒント1: 「2日余る」は何%の話か
全員が最頻値以下で終わる前提の話。1件ずつの E は M より大きくなる（P の側に裾が長い）。13件分の差を足すとどうなるか。
ヒント2: 合計の σ の出し方
σ を足すのではなく、分散（σ²）を足してから平方根（各作業が独立なら）。独立でないなら？
ヒント3: 2本のパスの合流
両方が間に合う確率 = 2つの確率の掛け算（独立なら）。片方が 80% でも、もう片方が 12% なら？
ヒント4: P の理由を読み比べる
「作業が難しい」から来る P と、「誰かを待つ」から来る P がある。後者は見積もりを増やすより、予約・前倒しで潰せないか。
ヒント5: 12/20 10:00 に本当に要るのは何か
抽選は応募の締め切り後、繰り上げ当選は本会計の期限の後。重複応募の突合は、応募時でなければいけないか。
ヒント6: 目標とバッファ
担当者に E や P を目標として渡すと何が起きるか（パーキンソンの法則）。
ヒント7: 別の方法で検算
過去の「実績 ÷ 見積もり」の比率を使うと、三点見積もりと別の方法で同じ数字を確かめられる。

📚 背景知識・用語解説

📐
三点見積もり（PERT）: 1つの作業に O・M・P を付け、所要時間を β 分布とみなして E = (O + 4M + P) / 6、σ = (P − O) / 6 で近似する。1950年代末の米海軍ポラリス開発の PERT が始まり。PMBOK ガイド第6版 §6.4.2.4 は三角分布 (O+M+P)/3 と β 分布の2つを並べて示す（三角分布の方が E は大きく出る）。
なぜ要るか: 所要時間は早い側には限りがあり、遅い側には長く伸びる。M をいくら足しても E の合計より小さい。単一見積もりの合計は「半分以上の確率で遅れる計画」になりやすい。
一次資料: Malcolm, Roseboom, Clark, Fazar, "Application of a Technique for Research and Development Program Evaluation", Operations Research 7(5) 646–669, 1959（DOI、書誌を Crossref で確認 参照日 2026-09-28）
➕
合計の σ と確率: 独立なら分散が足し算。合計 σ = √(σ₁² + σ₂² + …)。作業が多いと合計はおおよそ正規分布に近づき、E + 1.04σ で 85%、E + 1.64σ で 95%。同じ原因で一緒に遅れる作業は σ そのものの足し算に近くなる。独立として計算すると 85% の日を楽観側に置く。
🔀
合流の偏り（merge bias）: 並行する2本のパスが合流する点では「両方が間に合う確率」は掛け算。一番長いパス1本だけで確率を出す古典的な PERT はここで楽観側にずれる。
一次資料: MacCrimmon & Ryavec, "An Analytical Study of the PERT Assumptions", Operations Research 12(1) 16–37, 1964（DOI、参照日 2026-09-28）
🧠
計画の誤謬と参照クラス予測: 人はうまくいく筋書きをもとに所要時間を見積もり、過去の似た作業が遅れたと知っていても過小に見積もる。対策は、似た過去案件の「実績 ÷ 計画」の分布で補正すること。
一次資料: Buehler, Griffin, Ross, "Exploring the 'planning fallacy'", JPSP 67(3) 366–381, 1994（DOI）／ Flyvbjerg, "From Nobel Prize to Project Management: Getting Risks Right", Project Management Journal 37(3) 5–15, 2006（DOI）いずれも参照日 2026-09-28
⏳
パーキンソンの法則と学生症候群 → プロジェクトバッファ: 仕事は与えられた時間いっぱいに膨らむ（Parkinson, The Economist, 1955）。Goldratt『Critical Chain』（1997）は、個々の作業の安全余裕は使い切られて消えるので、余裕は作業から外してパスの最後にまとめて置き、その減り方で管理することを提案した。P や 85% の日を担当者の締め切りにすると、確率の計算が意味を失う。

✅ 模範解答

0. 前提（カレンダー）

日稼働日（11/9 = 1日目）意味
11/30（月）15日目R1 の担当者目標（M の合計）
12/3（木）18日目パスA の判断日
12/9（水）22日目R1（応募受付）の開発完了
12/18（金）29日目。E1 は R1 支援3日を除き 26作業日目R2（抽選・決済確定）の開発完了

1. 三点見積もり表

パスWBS作業パッケージ単一OMPEσP の種類
A2.3決済状態遷移の設計32363.330.67作業
A3.3オーソリ確保21.5252.420.58待ち（sandbox）
A2.2抽選ロジックの設計32363.330.67合意
A3.2抽選ロジックの実装43494.671.00作業（作り直し）
A3.4/3.5本会計・オーソリ取消32383.671.00待ち（sandbox）
A3.6無効化・繰り上げ当選22373.500.83作業（初めて）
A4.3決済の全パターンテスト32383.671.00待ち（sandbox）
B2.1応募フォームの設計21.5232.080.25作業
B2.5アクセス集中対策の設計32363.330.67作業
B3.1応募フォームの実装32353.170.50作業
B3.8アクセス集中対策の実装43494.671.00承認待ち
B3.7重複応募検知の実装32373.500.83法務確認待ち
B4.5負荷試験22383.671.00待ち（インフラ枠）

単一見積もりは13件中11件が M と同じで、残る2件（3.6・4.5）は M より小さい。担当者は「いちばんありそうな数字」か、それより楽観的な数字を付けていた。

2. パス別の完了確率表（全部を 12/9 に出す、今の計画のまま）

単一の合計M の合計E の合計σ50%85%95%22日以内
パスA202124.62.2224.626.928.212%
パスB171820.41.8620.422.323.580%
2本とも0.12 × 0.80約10%
パスA: E = 3.33 + 2.42 + 3.33 + 4.67 + 3.67 + 3.50 + 3.67 = 24.58
σ = √(0.444 + 0.340 + 0.444 + 1.000 + 1.000 + 0.694 + 1.000) = √4.92 = 2.22
22日以内: z = (22 − 24.58) / 2.22 = −1.16 → 約12%　／　85% = 24.58 + 1.04 × 2.22 = 26.9
検算 導出: β-PERT から各作業を2万回引いて合計（Python、種 20260928）→ パスA 12.7%、パスB 79.9%、2本とも 10.0%
📉
結論: 「2日余る」は約10% の確率でしか起きない筋書き。単一見積もりの合計は、パスA では E より 4.6日短い。

3. 締め切りの引き直し（本当に要る時点）

WBS作業本当に要る時点理由リリース
2.1/3.1応募フォーム12/20 10:00応募そのものR1（12/9）
2.5/3.8/4.5アクセス集中対策・負荷試験12/20 10:00開始直後の集中R1
2.3/3.3決済設計・オーソリ確保12/20 10:00応募時にオーソリを取る（E 5.75日、11/16 ごろ完了）R1
3.7重複応募検知12/28 の抽選の前「1アカウント1回」はフォームで止まる。複数アカウントの突合は全応募が出そろってから抽選前にまとめる方が材料が多いR2 へ移す
2.2/3.2抽選ロジック12/28 12:00抽選は締め切り後R2（12/18、12/23 リリース）
3.4/3.5本会計・取消12/28 12:00当選発表と同時R2
4.3決済の全パターンテストR2 の前R2
3.6無効化・繰り上げ当選12/30 12:00本会計の期限の後に初めて動くR2。間に合わなければ手動

オーソリ有効期間が60日あるので成り立つ分け方。30日未満なら成り立たない。

リリース中身Eσ85%締め切り確率
R1 応募受付パスB から 3.7 を外したもの16.91.6618.622日（12/9）99.9%（検算 99.7%）
R2 抽選・決済確定パスA の7件24.62.2226.926作業日（12/18）74%（独立として）

4. σ の足し方の点検（sandbox の相関）

パスA の 3.3・3.4/3.5・4.3 は P の理由がすべて sandbox。不安定な週は3件そろって遅れる。この3件の σ は、独立なら √(0.34+1+1) = 1.53、一緒に動くなら 0.58+1+1 = 2.58。

パスAσ85% の日数26日以内
独立として2.2226.974%
sandbox の3件が一緒に動く3.0427.768%（検算 70%）
🔗
相関を無視すると、85% の日を約1日楽観側に置く。 R2 は実際には7割前後と見る。

5. バッファと判断日

パスA の順番を「… → 3.4/3.5 → 4.3 → 3.6」に入れ替え、3.6 を最後にする。
12/3（木）終業時点（E1 の18作業日目）で 3.4/3.5 が終わっていなければ、3.6 の自動化はやめ、手動の予備手順に切り替える。
方針R2 が 12/18 に間に合う確率 導出3.6 を自動化できる割合
3.6 を必ず自動化70%100%（ただし遅れる）
12/3 を判断日にする91%63%
最初から手動94%0%
判断日を 12/4 にする84%78%

sandbox 相関ありの β-PERT 乱数2万回。判断日を1日遅らせると 91% → 84%。12/3 が「自動化を残せる見込み」と「85% 以上」を両立できる最後の日。

手動の予備手順（E2 が R1 完了後に1日で準備）: 12/30 12:00 に未決済の当選者を CSV で抽出 → 当選無効にする運用スクリプト → 次点者へ繰り上げ通知を手動送信。在庫3,000個・未決済3% 仮定 なら約90件、CS 1名と E1 で半日。

担当者に渡す目標（M の合計）85% の日数プロジェクトバッファ（85% − M）締め切りまで
R1（E2）15日目 = 11/3018.63.6日（12/1〜12/4）さらに約3日
R2（E1）21作業日目 = 12/827.7（相関あり）6.7日3.6 を外せば 85% は 24.3
  • 担当者には M を目標として渡し、E や P は渡さない。余裕はパスの最後にまとめて PM が持ち、減り方を毎週見る（金曜の進捗可視化でバッファ消費グラフに）
  • 待ちから来る P を先に潰す（数字には入れていない）: 今週中にインフラの負荷試験枠を 11/27〜12/2 で予約／決済代行に 11〜12月の sandbox 保守予定を問い合わせ

6. 参照クラスでのクロスチェック

単一 × 1.25（過去5件の中央値）三点見積もりの E差
パスA25.024.60.4日
パスB21.320.40.8日

別々の2つの方法が同じ桁を出した。 もし三点の E が単一 × 1.05 程度なら、P の聞き方が甘かった疑いがある。

🧮 試算ツール（O・M・P を変えてみる）

パスWBS作業OMPEσ

正規近似での計算。模範解答の乱数検算とは1〜3ポイントずれることがある。判断日の方針（91%）は乱数でしか出せないので、ここでは「3.6 を外す／外さない」の両端だけを見る。

7. 事業部長への報告（10/2 定例・1ページ）

福袋抽選予約 — 12/20 に間に合う確率と、決めてほしいこと

12/20 10:00 の応募受付は 99% 以上で間に合います。

ただし「全部を 12/9 に仕上げる」今の計画のままだと、間に合う確率は約10%です。

何を変えたか

  1. 抽選・本会計・繰り上げ当選は応募締め切り（12/27）の後に動くので、2回に分けてリリースします。R1（応募受付）12/15 凍結、R2（抽選・決済確定）12/23 リリース
  2. 重複応募の検知は、応募時ではなく抽選前にまとめて行います（R2）
  3. 繰り上げ当選の自動化は12/3 時点の進み具合で判断し、遅れていれば手動手順（約90件・半日）で運用します
見込み締め切り
R1 応募受付99%（50%なら 12/2、85%なら 12/4 に開発完了）12/9
R2 抽選・決済確定91%（12/3 の判断を入れた場合）12/18

決めてほしいこと（10/9 まで）

  1. 12/23 の R2 リリースの承認: 応募期間中のリリース。R2 はバッチと管理画面だけで応募の画面・API に触れない。リリース後に応募の通し確認（10分）
  2. 繰り上げ当選を手動で行う場合の CS 1名の確保（12/30 午後、半日）

私たちが今週やること: インフラの負荷試験枠の予約（11/27〜12/2）、決済代行への sandbox 保守予定の確認

🗂️ 検討した案と採らなかった理由

案内容判断理由判断が変わる条件
分割リリース＋判断日R1/R2 に分け、3.7 を抽選前へ、3.6 は 12/3 に判断採用R1 99%、R2 91%。削るのは 3.6 の自動化だけで、63% の場合は残せる—
人を足す他チームから1人借りてパスA を分担不採用決済状態遷移は E1 の設計に依存し、分けられるのは 4.3 くらい。立ち上がりで最初の2週間はむしろ遅れる（Brooks の法則）決済代行の連携経験者を 11/9 から借りられる場合
1回のリリースのまま P で計画担当者の締め切りを P の合計（A 49日相当）で引く不採用22日に入らない。P を締め切りにすると余裕は使い切られる—
三角分布で見積もるE = (O+M+P)/3今回は不採用パスA は 28.2日で β 分布より 3.6日保守的。参照クラス（25.0）とずれるので、今回の M は信用できると判断参照クラスの比率が 1.4 超の案件が続く、または担当者がその種類を初めてやる場合
3.6 を最初から手動自動化をあきらめる次点94% で最も安全だが、自動化を残せる 63% の場合を捨てる。来年も福袋はある12/3 より前に sandbox 障害が1週間以上続いた場合は判断日を待たず手動へ
3.7 を応募時のままリアルタイムで重複を弾く不採用R1 が 99.9% → 80% に落ちる。抽選前の突合でも公平性は守れる法務が「応募時点で弾く必要がある」と判断した場合（10月中に確認）

🧭 なぜこう作るのか

1
最初に「2日余る」が何%かを出した。 三点見積もりの目的は E を出すことではなく、「間に合う」を確率の言葉に直すこと。「約10%」と言えれば「では何を変えるか」に進める。
2
P の理由を「作業」と「待ち」に分けた。 待ちから来る P は、予約・問い合わせ・前倒しで消せる。見積もり表は「どこに手を打てるか」の地図にもなる。
3
締め切りを作業ごとに引き直した。 一番効いた手は、バッファを積むことでも人を足すことでもなく、「その日に本当に要るのはどれか」を確かめて外すこと（R1: 80% → 99.9%）。
4
相関を点検した。 独立の前提だと 85% の日が約1日楽観側にずれる。同じ原因で遅れる作業は P の理由の欄を読み比べれば見つかる。
5
諦めるものを先に決め、判断日を置いた。 遅れが見えた日に議論せず動ける。判断日は「1日遅いと 91% → 84%」まで確かめて置いた。
6
目標は M、余裕はまとめて PM が持つ。 P や 85% の日を担当者に渡すと、余裕は使い切られる。
7
別の方法で検算した。 参照クラスと乱数の2つで、正規近似の数字が桁として正しいことを確かめた。
🔀
別の判断もありうる: 「応募期間中のリリースは避けたい」方針の会社なら、R2 も 12/15 凍結に含め、3.6 を最初から手動にし、公平性検証（4.2）の範囲を削る判断もありうる。その場合、事業部長には「12/23 のリリースを許すか、繰り上げ当選の自動化と公平性検証の一部を諦めるか」の二択として出す。

⚠️ よくある失敗パターン

失敗パターンなぜ問題か改善策
単一見積もり（または M）を足して「○日余る」と言う半分以上の確率で遅れる計画になるE と σ を出し「何%で間に合うか」で言う
σ を単純に足す／いつも分散を足すどちらかに決め打ちすると幅を見誤るP の理由から相関のある作業を見つけ、両方で計算して幅を示す
一番長いパスだけで確率を出す合流点で確率は掛け算になり楽観側にずれる合流点で「両方が間に合う確率」を出す
P を「想像できる最悪」にする／O と同じくらい小さくするE が不当に膨らむ／幅が消える「100回に1〜2回ある悪い場合」と聞き、P の理由を1行書いてもらう
P や 85% の日を担当者の締め切りにする余裕は使い切られる（パーキンソン）担当者には M、余裕はパスの最後にまとめる
足りない分を「頑張る」「残業」で埋める確率は変わらず判断が遅れる締め切りを引き直し、諦めるものと判断日を先に決める

🏢 実務での使いどころ

  • エンジニアとして: 「いつ終わる？」に「50%ならこの日、85%ならこの日」と答える習慣が信頼になる。P の理由を1行書いてもらうだけで、リスク登録簿の下書きができる
  • PdM・事業側と: 何を諦めるかを決めるのは事業側。エンジニアは「どれを外すと何%になるか」を数字で出す
  • 経営層へ: 「10回やって9回は間に合う計画です」と言い換える
  • スクラムでも: Day037 の「1稼働日あたりのベロシティの幅」から 85% の予測を出すのは、同じ考え方をスプリント単位にしたもの

転用できるテンプレート

三点見積もり表: WBS | 作業 | 単一 | O | M | P | E=(O+4M+P)/6 | σ=(P−O)/6 | P の理由 | P の種類（作業/待ち/合意）
パス別の確率表: パス | 単一の合計 | M の合計 | E の合計 | σ | 50%/85%/95% の日数 | 締め切り以内の確率 | 合流点での確率
締め切りの引き直し: 作業 | 本当に要る時点 | 理由 | 載せるリリース
バッファ: 担当者に渡す目標（M） | 85% の日 | バッファ量 | 判断日と、そこで諦めるもの
報告: 一言で（何%） | 何を変えたか | 見込みの表 | 決めてほしいこと（期限つき） | 自分たちがやること

➡️ 次のステップ

  • テーマ1-3「スケジュール線表」: R1/R2 と判断日（12/3）を依存関係つきのガントチャートに描く
  • 金曜（PM-推進 テーマ#2 進捗可視化）: R2 のバッファ 6.7日が毎週どれだけ減ったかを示すバッファ消費グラフを作る
  • 自分への問い: 「R1 が 99% なら、R1 のバッファを R2 に回せないの？」と聞かれたら、E2 が 12/1 以降に何をすれば R2 の確率が上がるか答えられるか（ヒント: 4.3 は E2 と QA でも進められる）
  • 自分への問い: 11/20 時点でパスA が予定より2日遅れていたら、判断日を早めるべきか。どの数字を見て決めるか

🚧 扱わなかった範囲（この演習の限界）

  • 人の割り当ては「パスA=E1、パスB=E2 が順番に進める」と単純化した。人の組み替えでパスの形が変わる話は、クリティカルチェーン（Senior）で扱う
  • 3.7 を抽選前に移す案は、法務の判断（応募時点で弾かなくてよいか）が前提。10月中の確認が必要
  • 乱数での検算は β-PERT を仮定した計算で、分布の形自体は確かめていない。sandbox の相関は「3件が完全に一緒に動く」極端な場合で計算した
  • 過去5件の比率・在庫3,000個・未決済3%・オーソリ有効期間60日は演習シナリオ上の設定値
  • EVM（出来高で進捗を測る方法）は扱っていない（テーマ1-6）
  • 外部の一次資料は論文4点（Malcolm ほか 1959・MacCrimmon & Ryavec 1964・Buehler ほか 1994・Flyvbjerg 2006。書誌を Crossref で確認、参照日 2026-09-28。本文の数値は引用していない）と書籍2点（PMBOK ガイド第6版・Goldratt『Critical Chain』）

🎯 自己評価

自分の回答

所要時間・気づき・メモ