🎬 シナリオ
MOps チームは、販促ポイントのキャンペーン設定をエンジニアのコード修正から、マーケが管理画面で設定できる形に移す（ポイントキャンペーン設定の管理画面化）。今日は 10/5（月）。
なぜやるのか（今の痛み）
| 項目 | 値 | 出所 |
|---|---|---|
| ポイントキャンペーンの件数 | 過去12か月で 108件（月平均9件） | 実測 チケット履歴 |
| 1件あたりのエンジニア工数 | 0.8人日（PointCampaignService に if 分岐を足してリリース） | 実測 作業記録の中央値 |
| 依頼から本番反映まで | 中央値 5営業日 | 実測 |
| コード内のキャンペーン分岐 | 41件（終わったキャンペーンも消されずに残っている） | 実測 grep |
| ポイントの付与確定 | 出荷から30日後。終わったキャンペーンでも確定待ちの付与予定が残ることがある | 実測 仕様 |
| 1人日の社内単価 | 5万円 | 仮定 |
締め切り: 1/1 初売りの6件を、マーケが 12/21〜12/28 に新画面で自分で設定する。逆算して開発完了は 12/4（金）、12/7〜12/18 は QA と旧ロジックとのシャドー比較。キックオフは 10/26（月）（チームは 10/23 まで別案件）。
体制とキャパシティ（10/26〜12/4 = 稼働 28日）
| メンバー | 役割 | 割り当て | 人日 |
|---|---|---|---|
| 佐藤 | バックエンド10年目。旧ポイントロジックの作者 | 40%（既存システムの保守・オンコール兼務） | 11.2 |
| 林 | バックエンド2年目 | 100% | 28.0 |
| 中村 | フロントエンド | 50% | 14.0 |
| 合計 | 53.2 | ||
見積もり会（10/2）: 3人の O / M / P（人日、お互いの数字を見ずに記入）
| WP | 作業パッケージ | 佐藤 | 林 | 中村 |
|---|---|---|---|---|
| 1 | ルール設定のデータモデル設計 | 2 / 3 / 5 | 2 / 3 / 6 | — |
| 2 | 既存のキャンペーン分岐の移植 | 3 / 5 / 8 | 6 / 12 / 25 | — |
| 3 | ルール評価エンジン | 5 / 7 / 12 | 5 / 8 / 12 | — |
| 4 | 二重付与の防止 | 2 / 3 / 6 | 1 / 2 / 3 | — |
| 5 | 管理画面: 一覧・作成フォーム | — | 4 / 6 / 9 | 5 / 7 / 10 |
| 6 | 管理画面: プレビュー（過去30日の注文での付与試算） | 4 / 8 / 20 | — | 3 / 4 / 6 |
| 7 | 承認フロー（マーケ作成 → 経理承認 → 有効化） | 3 / 4 / 7 | — | 3 / 4 / 6 |
| 8 | 旧ロジックとのシャドー比較と差分調査 | 3 / 5 / 12 | 2 / 3 / 4 | — |
| 9 | 結合テスト・性能テスト | 3 / 5 / 8 | 3 / 4 / 6 | — |
議事メモ（理由を話してもらった部分）
- WP2 — 佐藤「移すのは今も使っている分岐だけのつもり。たぶん14件くらい」／林「41件全部移すと思っていました。どれが使われているか僕には分からないので」
- WP4 — 佐藤「決済代行の Webhook はタイムアウトすると同じ通知を最大3回再送してくる。今の付与処理もそれで二重付与を起こした」／林「知りませんでした」
- WP6 — 中村「画面と API 呼び出しだけなら4日」／佐藤「過去30日は約120万明細。本番 DB にその集計を流すのは禁止。DWH に要る列が日次で入っていれば簡単だが、無ければ抽出から作る。P の20はそれ」
- WP8 — 林「比較スクリプトを書くだけなら3日」／佐藤「去年の在庫API移行のシャドー比較は見積もり3日に対して実績9日。差分が出るたびに1件ずつ調べた」
- WP1・3・5・7・9 — 前提はそろっていて、違いは「なんとなく」の範囲
💬
チームリード「3人の M を平均して足すと 46.5人日。キャパは 53.2 だから6.7人日余る。O・M・P も平均を取って PERT にかければいいよね。10/9 の部長会は『予定どおり』で出そう」
📣
販促企画部長「初売りは年間で一番大きいキャンペーン。直前まで自分たちで調整できるなら助かる。ただ、間に合わないなら早めに言ってほしい。その場合は今までどおりエンジニアさんに頼む」
🧾
経理課長「付与ポイントは将来の値引きの約束として負債に積む。有効化の前に経理が原資を確認できること、その確認に使う試算が出せることが条件」
📝 課題
あなたのタスク: 10/9（金）の部長会に出す見積もりの資料一式を作ってください。
- ずれの仕分け表: 食い違った作業ごとに原因を「前提」「知識」「経験」「ノイズ」に分け、それぞれどう解くか
- 合意後の三点見積もり表: O/M/P・E・σ、合計の E・σ、53.2人日以内の確率。チームリードの「平均」とも比べる
- 分散の内訳: 合計の σ² のうち、どの作業が何%か
- スパイク計画と分岐ルール: 調べれば幅が縮む作業と縮まない作業を分け、調査の中身・工数・期限と、結果ごとに何を削るかを先に決める
- 選択肢別の確率表: 今の計画／スコープを決めるだけ／スパイク＋分岐ルール／最初から削る。確率と、残せる機能を並べる
- 部長会向け1ページ: 一言の答えと、今決めてほしいこと
- 採らなかった案: 2つ以上、理由と判断が変わる条件つき
🔍 ヒント（段階的開示）
ヒント1: WP2 の2人は同じ作業を見積もっているか
片方は14件、片方は41件の移植を見積もっている。平均すると、どちらの世界にも存在しない数字になる。
ヒント2: 三点見積もりを平均すると何が縮むか
O と P も平均されて幅（σ）が縮む。WP6 の P=20 の理由（本番 DB に流せない）は、平均すると半分に薄まる。理由は消えていないのに。
ヒント3: 知識のずれと経験のずれ
知らなかった人が理由を聞いて納得すれば、知っている人の値で合意できる。経験のずれは、過去の実績（在庫API移行 3→9日）が手がかり。
ヒント4: 分散の上位を探す
合計の σ² を作業ごとに分ける。上位2〜3件で何割になるか。そこだけ手を打てば合計の幅はほとんど縮む。
ヒント5: スパイクが効く P と効かない P
「今は分からないが、調べれば数日で分かること」なら縮められる。「動かしてみるまで分からないこと」なら縮められない（バッファで持つ）。
ヒント6: 結果が出る前に決める
「調べてから考える」では価値が出ない。「結果がこうなら、これを削る」を先に合意するから、結果の日に会議なしで動ける。
ヒント7: 最初から削る案とも比べる
確率はそっちの方が高いかもしれない。そのとき何を失うか。間に合わないと何が起きる案件か。
📚 背景知識・用語解説
👥
複数人の見積もりをまとめる（Wideband Delphi・プランニングポーカー）: ①各自が匿名で見積もる → ②数字を並べ、ずれの大きい作業の理由を話す → ③もう一度各自で見積もる、を繰り返す（Boehm『Software Engineering Economics』1981、書籍）。プランニングポーカーは同じ考え方をカードで素早く行う（Grenning 2002・Cohn 2005、本文は未照合）。
なぜ平均しないのか: 平均は理由の無いばらつき（ノイズ）を消すには有効だが、理由のあるずれまで消す。グループで話し合ってから出した見積もりは、機械的な平均より楽観に偏りにくかった、という研究がある。
一次資料: Moløkken-Østvold & Jørgensen, "Group Processes in Software Effort Estimation", Empirical Software Engineering 9(4) 315–334, 2004（DOI）／ Moløkken-Østvold, Haugen, Benestad, "Using planning poker for combining expert estimates in software projects", JSS 81(12) 2106–2117, 2008（DOI）／ Jørgensen, "A review of studies on expert estimation of software development effort", JSS 70(1-2) 37–60, 2004（DOI）。書誌は Crossref で確認（参照日 2026-10-05）。要旨は記憶によるもので、本文の数値は照合・引用していない
なぜ平均しないのか: 平均は理由の無いばらつき（ノイズ）を消すには有効だが、理由のあるずれまで消す。グループで話し合ってから出した見積もりは、機械的な平均より楽観に偏りにくかった、という研究がある。
一次資料: Moløkken-Østvold & Jørgensen, "Group Processes in Software Effort Estimation", Empirical Software Engineering 9(4) 315–334, 2004（DOI）／ Moløkken-Østvold, Haugen, Benestad, "Using planning poker for combining expert estimates in software projects", JSS 81(12) 2106–2117, 2008（DOI）／ Jørgensen, "A review of studies on expert estimation of software development effort", JSS 70(1-2) 37–60, 2004（DOI）。書誌は Crossref で確認（参照日 2026-10-05）。要旨は記憶によるもので、本文の数値は照合・引用していない
ずれの4分類（見積もり会の進め方として作った整理）
| 分類 | 見分け方 | 解き方 |
|---|---|---|
| 前提 | 2人が「何を作るか」を違うものとして話している | 見積もりではなくスコープを決める。決めるのは PO・事業側 |
| 知識 | 片方だけが知っている制約がある。聞いた側が「知らなかった」と言う | 知っている人の値を採り、理由を表に残す |
| 経験 | 似た作業の実績を知っているかどうか | 過去の実績（参照クラス）で補正する |
| ノイズ | 理由を聞いても違いが出てこない | 平均してよい |
📊
分散の内訳: 独立な作業の合計では σ² が足し算になる。合計の σ² を作業ごとに分けると、どの作業が不確実性を作っているかが分かる。全部を細かく見積もり直すより、上位の数件に手を打つ方が効く。
🔦
スパイク（spike）: XP の言葉で、分からないことを調べるためだけの、時間を区切った作業（Beck『Extreme Programming Explained』、書籍）。成果物はコードではなく「分かったこと」。見積もりの幅は、決める・調べるをしたときだけ狭まる（不確実性のコーン。Boehm 1981・McConnell『Software Estimation』2006、書籍）。スパイクで縮められるのは「調べれば分かること」だけ。
🧩 ずれの仕分けクイズ
議事メモを読んで、ずれの原因を選んでください。
✅ 模範解答
1. ずれの仕分け表
| WP | ずれ（E） | 分類 | 根拠 | 解き方 | 合意した O / M / P |
|---|---|---|---|---|---|
| 2 移植 | 佐藤 5.2 / 林 13.2 | 前提 | 「使っている分だけ」vs「41件全部」 | スコープを決める。決まるまで2つを並べて持つ | 全部 6/12/25、使っている分 3/5/8 |
| 4 二重付与 | 佐藤 3.3 / 林 2.0 | 知識 | Webhook の最大3回再送 | 佐藤さんの値。再送仕様を設計メモに | 2 / 3 / 6 |
| 6 プレビュー | 佐藤 9.3 / 中村 4.2 | 知識 | 本番 DB 禁止。DWH に列があるかは不明 | 佐藤さんの値。P=20 の理由は調べれば分かる → スパイク | 4 / 8 / 20（スパイク前） |
| 8 シャドー比較 | 佐藤 5.8 / 林 3.0 | 経験 | 在庫API移行で 3日 → 9日 | 佐藤さんの値 | 3 / 5 / 12 |
| 1・3・5・7・9 | 差 1人日未満 | ノイズ | 理由を聞いても違いなし | O・M・P を平均 | 下表 |
2. 合意後の三点見積もり表
| WP | O | M | P | E | σ |
|---|---|---|---|---|---|
| 1 データモデル設計 | 2 | 3 | 5.5 | 3.25 | 0.58 |
| 2 移植（全部: 41件） | 6 | 12 | 25 | 13.17 | 3.17 |
| 2 移植（使っている分だけ、14件想定） | 3 | 5 | 8 | 5.17 | 0.83 |
| 3 評価エンジン | 5 | 7.5 | 12 | 7.83 | 1.17 |
| 4 二重付与の防止 | 2 | 3 | 6 | 3.33 | 0.67 |
| 5 一覧・作成フォーム | 4.5 | 6.5 | 9.5 | 6.67 | 0.83 |
| 6 プレビュー | 4 | 8 | 20 | 9.33 | 2.67 |
| 7 承認フロー | 3 | 4 | 6.5 | 4.25 | 0.58 |
| 8 シャドー比較 | 3 | 5 | 12 | 5.83 | 1.50 |
| 9 結合・性能テスト | 3 | 4.5 | 7 | 4.67 | 0.67 |
| やり方 | E の合計 | σ | 85% の工数 | 53.2人日以内 |
|---|---|---|---|---|
| リード案①: M の平均を足す | （46.5） | — | — | 「6.7人日余る」（確率になっていない） |
| リード案②: O・M・P を3人分平均して PERT | 49.7 | 3.28 | 53.1 | 86%（に見える） |
| 合意後・WP2 を全部移す | 58.3 | 4.80 | 63.3 | 14% |
| 合意後・WP2 を使っている分だけ（14件と仮定） | 50.3 | 3.70 | 54.2 | 78% |
📉
平均すると 86% に見える理由: ①WP2 で別々の作業（14件と41件）を混ぜた ②WP6・WP8 の P の理由（本番 DB 禁止・過去の ×3）を半分に薄めた。この2つで幅が 4.80 → 3.28 に縮み、数字だけが安心な側に寄った。今の計画（全部移す）のままなら 14%。
3. 分散の内訳（合計の σ² のうち何%か）
全部移す場合、WP2・WP6・WP8 の3件で分散の 84%。使っている分だけにすると WP6 の1件で 52%。残り6件をいくら細かく見積もり直しても、合計の幅はほとんど縮まない。
4. スパイク計画と分岐ルール
| WP | P/O | P の理由 | 調べれば分かるか | 扱い |
|---|---|---|---|---|
| 2 移植 | 4.2（林） | どの分岐が今も使われているか分からない | 分かる（ポイント台帳の12か月の付与実績・確定待ちを数える） | スパイク S1 |
| 6 プレビュー | 5.0（佐藤） | DWH に要る列が日次で入っているか分からない | 分かる（テーブル定義と更新ジョブを見る） | スパイク S2 |
| 8 シャドー比較 | 4.0（佐藤） | 差分が何件出るかは動かすまで分からない | 分からない | バッファで持つ。差分は「1件30分で切り分けられなければ課題管理表へ」 |
| 中身（10/26〜27、報告は 10/28 朝会） | 担当・工数 | 分かれ目 | 事前の見込み | |
|---|---|---|---|---|
| S1 | 41件を「12か月の付与実績あり」「確定待ちあり」「どちらも無し」に分類。無しは経理の確認を取って削除候補に | 佐藤 0.5・林 1.0 | 移植が 16件以下（A）／17件以上（B） | A: 60% 仮定 |
| S2 | DWH の注文明細に、判定に要る列（会員ランク・商品カテゴリ・支払方法）が日次で入っているか | 佐藤 1.0 | 入っている（Y）／いない（N） | Y: 50% 仮定 |
分岐ルール（結果が出る前に、部長会で合意しておく）
| 結果 | WP2 | WP6 プレビュー | WP7 承認フロー |
|---|---|---|---|
| A（16件以下） | 3 / 5 / 8 | Y: DWH で過去30日を集計（4 / 5.5 / 9） | 作る |
| B（17件以上） | 5 / 8.5 / 14 | N: 本番の読み取り専用レプリカから直近7日・1万明細を抽出し30日分に引き延ばす（4 / 6 / 10） | 初売りでは作らない。承認は今の稟議フォーム、有効化ボタンは管理者ロールのみ（0.5人日）。自動化は1月 |
S1・S2 はそれぞれ独立に分岐する（A/B × Y/N の4通り）。
5. 選択肢別の確率表
| 案 | 中身 | 53.2人日以内 導出 | 85% の工数 | 承認フローが初売りに | 30日試算が初売りに |
|---|---|---|---|---|---|
| 0 今の計画 | 41件すべて・全機能 | 17%（14%） | 63.8 | 100%（遅れる） | 100%（遅れる） |
| 1 スコープを決めるだけ | 使っている分だけ。スパイクなし | 64%（64%） | 56.5 | 100% | 100% |
| 2 スパイク＋分岐ルール | S1・S2 と分岐ルール | 88%（90%） | 52.8 | 60% | 50% |
| 3 最初から削る | 承認は稟議、試算は7日抽出 | 98%（99%） | 48.8 | 0% | 0% |
| 参考 2′ | スパイク＋プレビューの分岐だけ（承認フローは常に作る） | 73%（74%） | 54.9 | 100% | 50% |
β-PERT から各作業を4万回引いて合計（Python、乱数の種 20261005）。かっこ内は正規近似。スパイクの 2.5人日はキャパの内側に含めた。
| 案2 の分岐 | 起きる確率 仮定 | E | σ | 53.2人日以内 |
|---|---|---|---|---|
| A × Y | 30% | 49.3 | 2.70 | 90% |
| A × N | 30% | 49.8 | 2.75 | 86% |
| B × Y（承認は手動） | 20% | 49.3 | 2.91 | 89% |
| B × N（承認は手動） | 20% | 49.8 | 2.96 | 85% |
🧷
見込みが外れても確率がほとんど動かない: A の見込みを 30% / 60% / 80% と変えると、案2 は 87% / 88% / 88%、案1 は 53% / 64% / 70%（乱数）。分からない数字（14件くらい）に結果が左右されなくなるのが、スパイクと分岐ルールを組み合わせる価値。
- キャパの感度: キャパ 50人日なら案2 は 56%、51.8人日（佐藤さん 35%）なら 77%、56人日なら 98%。佐藤さんの 40% は計画の前提として部長会で確認する
- フロントエンドの偏り: 中村さんの 14人日に対し WP5（6.7）＋WP7（4.3）＋WP6 の画面部分（約4）＝約15人日。WP5 の一覧画面を林さんが持つ。合計工数の確率は人の入れ替えが自由な前提なので、この点検を別に行う
🧮 試算ツール（案を組み立てて確率と残る機能を見る）
WP2 の範囲:
WP7 承認フロー:
WP6 プレビュー:
A（16件以下）の見込み 60%
Y（DWH にある）の見込み 50%
佐藤さんの割り当て 40%（キャパ 53.2人日）
分岐ごとに正規近似した分布を、起きる確率で重ねて計算（混合分布）。模範解答の乱数とは1〜2ポイントずれることがある。スパイクなしで「B のときだけ」「N のときだけ」を選ぶと、結果が分からないので「作る」「30日分を作る」として扱う。
6. 間に合わなかったら何が起きるか（必要な確率の決め方）
| 項目 | 値 | 出所 |
|---|---|---|
| 初売りのキャンペーン | 6件 | 実測 販促企画部の計画 |
| 今までどおりエンジニアが実装 | 6件 × 0.8人日 = 4.8人日（12月に発生） | 導出 |
| マーケが失うもの | 直前の調整が自分でできない（反映まで5営業日） | 実測 |
間に合わなくても事故にはならず、今までどおりに戻るだけ。だから 99% を狙って機能を全部削る（案3）必要はなく、85% 前後で残せる機能を最大にする（案2）のが釣り合う。間に合わないと売上や法令に響く案件（Day040 の福袋の応募開始など）なら、案3 を選ぶ。
7. 部長会向け1ページ（10/9）
ポイントキャンペーン設定の管理画面化 — 初売りに間に合う確率と、先に決めてほしいこと
今の計画のままでは、12/21 の設定開始に間に合う確率は約2割です。
移すものを絞り、キックオフ直後の2日間の調査結果で削るものを先に決めておけば、約9割になります。
何を変えるか
- 移すのは「過去12か月に付与実績があるか、確定待ちの付与が残っている」分岐だけ。それ以外は経理の確認を取って削除
- 10/26〜27 に2つの調査を行い、10/28 に結果をお知らせします。結果に応じて下表のとおり進めます（会議なしで動けるよう、今日決めておきたい）
| 調査結果 | 初売りで使えるもの |
|---|---|
| 移す分岐が16件以下 | 承認フローも含めて全部 |
| 17件以上 | 経理の承認は今の稟議フォームで代用（自動の承認フローは1月） |
| DWH に必要なデータがある | 過去30日の注文での原資試算 |
| ない | 直近7日・1万明細からの試算（30日分に引き延ばした概算） |
間に合わなかった場合: 初売りの6件は今までどおりエンジニアが実装します（約5人日）。12/4 の開発完了時点でお知らせします。
決めてほしいこと（10/9）
- 販促企画部長・経理課長: 上の分岐ルールの承認。特に「17件以上なら初売りの承認は稟議で代用」を経理として受け入れられるか
- 経理課長: 付与実績も確定待ちも無い分岐の削除の確認（10/27 に一覧をお渡しします、30分）
- チームリード: 佐藤さんの割り当て 40% を 12/4 まで守ること（35% に下がると約77%）
🗂️ 検討した案と採らなかった理由
| 案 | 内容 | 判断 | 理由 | 判断が変わる条件 |
|---|---|---|---|---|
| スパイク＋分岐ルール | S1・S2 と分岐ルールを先に合意 | 採用 | 88%。承認フローは60%、30日試算は50%の確率で初売りに間に合う。見込みが外れても確率が動かない | — |
| 3人の O・M・P を平均（リード案） | 平均して PERT | 不採用 | 86% と出るが、別々の作業を混ぜ、P の理由を薄めた結果。全部移すなら実際は 14% | ずれがすべてノイズだった場合は平均でよい |
| 最初から削る（案3） | 承認は稟議、試算は7日抽出で確定 | 次点 | 98% で最も安全だが、初売りでの承認フロー・30日試算の可能性を最初から捨てる。間に合わなくても今までどおりに戻るだけの案件なので、ここまでの安全は要らない | 経理課長が「初売りは稟議で十分、7日抽出で十分」と言った場合 |
| スパイクを今週やる | キックオフ前の 10/12 の週で調べる | 不採用 | チームは 10/23 までお歳暮対応。2.5人日を抜くとそちらのスプリントゴールが危うくなる | お歳暮対応のスプリントに余力が出た場合（10/9 のレビューで確認） |
| WP8 もスパイクで縮める | 差分の件数を事前に調べる | 不採用 | 差分は新ロジックを動かすまで出ない。調べても分からない | 旧ロジックの誤付与の記録（問い合わせ履歴）がまとまっていれば、差分の多い分岐を先に絞れる |
| 人を足す | 他チームのバックエンドを1人借りる | 不採用 | 旧ロジックを知るのは佐藤さんだけで、立ち上がりに佐藤さんの時間を使う | 保守・オンコールを他の人が肩代わりでき、佐藤さんの割り当てを上げられる場合（こちらの方が効く） |
🧭 なぜこう作るのか
1
ずれを平均せず、原因で仕分けた。 見積もり会の目的は数字をそろえることではなく、数字のずれから、誰かだけが知っている前提・制約を表に出すこと。WP2 の「14件か41件か」は決めることだった。
2
平均の確率（86%）をわざと並べた。 計算は間違っていない。間違っているのは理由のあるずれまで平均したこと。「86% → 14%」の差を見せるとリードにも伝わる。
3
分散の内訳で手を打つ場所を絞った。 9件中3件で分散の 84%。残り6件を細かくしても確率はほとんど変わらない。
4
「調べれば分かる」と「動かすまで分からない」を分けた。 スパイクが効くのは前者だけ。
5
結果ごとに削るものを、結果の前に決めた。 結果の日に会議をすると数日溶ける。先に合意すれば 10/28 の朝会で動ける。
6
「最初から削る」と正直に比べた。 確率だけなら案3 が上。案2 を選んだのは、間に合わないときの損失が小さいから。必要な確率は、間に合わないときの損失で決まる。
🔀
別の判断もありうる: 経理課長が「初売りは原資が大きいので承認は今の稟議で慎重に」と言うなら、承認フローは最初から1月に回し、スパイクは S2 だけにする。確率は乱数で約 98% と案2 より高いが、承認フローを初売りで使える可能性は 0% になる。S1 の 1.5人日は移植本体の最初の作業に入れる。
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 理由を聞かずに複数人の見積もりを平均する | 前提・知識の違いまで平均され、幅が縮み、確率が安心な側に寄る | ずれの大きい作業だけ理由を話してもらい、4つに仕分ける |
| 声の大きい人・ベテランの数字に合わせる | 林さんの「41件全部」は、スコープ未決を示す情報だった | 匿名・同時に出す。ベテランの値を採るときも理由を書く |
| 全作業を同じ細かさで見積もり直す | 幅の小さい作業を細かくしても合計の幅は縮まない | 分散の内訳を出し、上位の数件に手を打つ |
| 「とりあえず調べます」でスパイクを始める | 結果の後に話し合うので数日溶ける。止める基準も無い | 時間を区切り、分かれ目と、分かれ目ごとに削るものを先に決める |
| 動かすまで分からないことにスパイクを当てる | 工数を使っても幅が縮まない | P の理由が「調べれば分かる」ものかを先に確かめる |
| どの案件でも 95% を目指す | 残せた機能まで削ってしまう | 間に合わないときの損失を先に書き、それに見合う確率を選ぶ |
🏢 実務での使いどころ
- エンジニアとして: 自分の数字が他の人と大きくずれたら、それは情報。「何を前提にしたか」を一言添えて出すだけで見積もりの質が上がる
- 司会として: プランニングポーカーで最大・最小の人に話してもらう目的は、前提を表に出すこと。話しても残る前提の違いは PO に決めてもらう
- PdM・事業側と: 分岐ルールは「この結果なら、この機能は後回し」という約束。削るものを決める権限のある人に先に合意してもらう
- 経営層へ: 「約2割 → 約9割」と、何を変えたら確率が変わるのかを1行で言う
転用できるテンプレート
ずれの仕分け表: 作業 | 各人の E | 分類（前提/知識/経験/ノイズ） | 根拠（議事メモ） | 解き方 | 合意した O/M/P
三点見積もり表: 作業 | O | M | P | E | σ | 分散の内訳（%）
幅の広い作業: 作業 | P/O | P の理由 | 調べれば分かるか | 扱い（スパイク/バッファ）
スパイク: 中身 | 担当・工数 | 期限 | 結果の分かれ目 | 事前の見込み（出所）
分岐ルール: 結果 | 各作業の見積もり | 削るもの・後回しにするもの
選択肢別の確率表: 案 | 確率 | 85% の工数 | 残せる機能の割合
必要な確率: 間に合わないと何が起きるか | 損失の大きさ | 選ぶ確率の水準➡️ 次のステップ
- テーマ1-3「スケジュール線表」: スパイク・分岐の判断（10/28）・開発完了（12/4）・シャドー比較・マーケの設定期間を線表に描き、人ごとの負荷も見る
- 明日（PM-リスク）: 「WP8 で差分が多く出る」「佐藤さんのオンコールが重なる」は登録簿に載せる項目。「P の理由」の列がそのまま下書きになる
- 自分への問い: 10/28 の結果が「B（23件）」で、佐藤さんが「うち8件は同じ型でまとめて移せる」と言ったら、WP2 をどう見積もり直すか。分岐ルールを変えるべきか
- 自分への問い: 全員の数字がほぼそろった作業は、本当に安心してよいか（ヒント: 全員が同じことを知らない場合）
🚧 扱わなかった範囲（この演習の限界）
- 合計工数とキャパの比較で確率を出した。前後関係とクリティカルパスは扱っていない（Day040 で2本のパスの合流を扱った。テーマ1-5 で詳しく）
- 作業同士は独立として計算した。WP2 と WP8（移植が多いほど差分も増える）には相関があるはずで、その分だけ楽観側にずれている
- スパイク結果の見込み（A 60%・Y 50%）は仮定。感度は上に示した
- スパイクの 2.5人日は移植・設計の最初の作業と重なる部分があるが、保守的に上乗せで計算した
- 付与ポイントの会計上の扱いは経理課長の発言として置いただけで、基準の条文は確認していない
- 件数・工数・単価・キャパはすべて演習シナリオ上の設定値
- 外部の一次資料は論文3点（書誌を Crossref で確認、参照日 2026-10-05。要旨は記憶によるもので本文の数値は照合・引用していない）と書籍（Boehm 1981・Cohn 2005・Beck・McConnell 2006）