🎬 シナリオ
MOps チームの「マイページ班」は、注文履歴から領収書 PDF を自分で発行できる機能を作っている。今は CS が1件ずつ手で作って送っている。昨年12月は 4,100件（通常月 2,300件、1件約6分）。
- 年末商戦の変更凍結 11/20〜1/6。リリース 11/19（木）、11/18 はリハーサル → 開発・テストの期限は 11/17（火）
- 今日は 10/16（金）終業後。残りは 10/19〜11/17 の 21稼働日（11/3 を除く）
- 体制: リード 佐々木さん、エンジニア 北川さん・森下さん・あなた、QA 戸田さん。PO 原田さん（CS 企画）
- 関係者: CS 部長 吉村さん、経理課長 森さん（インボイスの記載事項と写しの保存）
💬
佐々木さん（下書き）「残り20件。障害の週を除くと直近36稼働日で37件、1日約1件なので20稼働日、11/16 に終わり1日余ります。Green」
EM 松井さん「1日余るって、どのくらい確かなの？ 部長会には『11/19 に何が出せるか』を確率つきで出したい。月曜までに1枚にして」
EM 松井さん「1日余るって、どのくらい確かなの？ 部長会には『11/19 に何が出せるか』を確率つきで出したい。月曜までに1枚にして」
作業項目（20件、PO の優先順。出所はすべて「仮定（演習の設定）」）
| ID | 項目 | 状態 | 11/19 に必要か |
|---|---|---|---|
| W1 | PDF 生成の土台 | 開発中（分割済み） | 必要 |
| W2 | 注文履歴に「領収書」ボタン | 開発中（分割済み） | 必要 |
| R01 | 宛名・但し書きの入力 | 未着手 | 必要 |
| R02 | インボイスの記載事項（登録番号・税率ごとの合計と税額） | 未着手 | 必要 |
| R03 | 2回目以降は「再発行」と印字 | 未着手 | 必要 |
| R04 | 一部返品・キャンセル後の金額を反映 | 未着手 | 必要 |
| R05 | クーポン・ポイント利用時の領収金額 | 未着手 | 必要 |
| R06 | ギフト注文の宛名の初期値 | 未着手 | 必要 |
| R07 | 発行した領収書の写しを保存 | 未着手 | 必要 |
| R08 | CS の画面から発行状況を確認 | 未着手 | 必要 |
| R09 | 代引き・後払い（入金確認後に発行） | 未着手 | あれば良い |
| R10 | スマホアプリ内での表示 | 未着手 | あれば良い |
| R11 | 複数の注文をまとめて1枚 | 未着手 | あれば良い |
| R12 | 英語の領収書 | 未着手 | あれば良い |
| R13〜R18 | 会社名の候補・メール送付・回数上限・文面編集・ダッシュボード・電子署名 | 未着手 | 後で良い |
日別の完了件数（直近41稼働日、8/17〜10/16）
赤い棒は 9/7 の週（決済の障害対応に全員が入り0件）。合計 37件・1日あたり 0.90件。障害の週を除くと 36日で 37件（1.03件）。分布: 0件 14日・1件 18日・2件 8日・3件 1日。
分割の実績（着手前 → 終わったとき）
| 案件 | 着手前 | 終わったとき | 倍率 |
|---|---|---|---|
| 会員ランクの表示 | 12 | 16 | 1.33 |
| 配送日時のセルフ変更 | 15 | 19 | 1.27 |
| お気に入り一覧 | 10 | 14 | 1.40 |
📝 課題
あなたのタスク: 10/22 の部長会に出す「領収書セルフ発行の進捗」1枚を作ってください。
- 佐々木さんの予測の検算: 「20件 ÷ 1日1件」が置いている前提を列挙し、実績に置き換えると予測がどう変わるか
- 確率つきの予測: モンテカルロ法で (a) 全件が終わる日の 50%・85%、(b) 11/17 までに 85% で終わる件数。障害の週を入れるかの判断と理由
- 優先順位の線ごとの到達確率表: 約束する線（85%以上）・届けば出す線・凍結明けに回す線
- 報告1枚: 信号の決め方、部長会に判断を頼むこと、毎週の見直しの条件と期日
🔍 ヒント（段階的開示）
ヒント1
「1日1件」は平均。平均で計画すると、だいたい半分の確率で遅れる
ヒント2
未着手の18件は「まだ分割していない」件数。過去の案件では終わるまでに何倍になったか
ヒント3
障害の週を外すのは「この先21日間に障害対応は起きない」と仮定するのと同じ。過去41日で何回あったか
ヒント4
「いつ終わるか」と「期限までに何件終わるか」は同じシミュレーションの裏表。期限が動かせない今回はどちらが役に立つか
ヒント5
部長に頼むのは「頑張ります」の承認ではなく、線をどこに引くかの判断
ヒント6
件数で予測するとき、項目の大きさの違いはどこで吸収されているか。今後だけ極端に大きい項目があったら？
📚 背景知識・用語解説
📖
予測に使えるのは「すでに起きたこと」だけ: Scrum Guide 2020 は予測の道具を挙げた後に "Only what has already happened may be used for forward-looking decision making." と書く（scrumguides.org、参照日 2026-10-16）。平均という1つの数に縮めると、ばらつきという実績を捨てることになる。
| 用語 | 意味 | 今回の使いどころ |
|---|---|---|
| スループット | 単位時間あたりの完了件数。Kanban Guide v2025.5 は「件数そのもの」を数えるとする（kanbanguides.org） | 日別の完了件数41日分をそのまま使う |
| モンテカルロ予測 | 過去の1日分をランダムに引くのを繰り返し、何日かかったかを数万回集めて分布を作る | 50%・85% の日付／件数を読む |
| When / How Many | 件数を固定して日付を出す／日付を固定して件数を出す。How Many の 85% は「少なくともこの件数」という下限 | 期限が動かせないので How Many と線ごとの確率が主役 |
| カットライン | 優先順の「上から k 件目まで」ごとの到達確率。Magennis の Multiple Feature Cut Line Forecaster が同じ考え方 | 約束・届けば出す・凍結明けの3つの線 |
| 分割倍率 | 着手前の項目が作り始めると何件に割れるか | 未着手18件にだけかける（1.27〜1.40） |
🚧
件数で予測してよい条件: 過去と同じくらいのばらつきで項目を切っていること。今後だけ極端に大きい項目（R18 電子署名など）を入れると前提が崩れる。
✅ 模範解答
答えを見る前に、自分の検算表と線を引いた表を作ってから読み比べてください。数値はすべて Python で 2万回・乱数の種 20261016 で計算した導出値です。
1. 佐々木さんの予測の検算
| 前提 | 佐々木さん | 実績に置き換えると | 全20件が 11/17 までに終わる確率 |
|---|---|---|---|
| ① 速さは毎日同じ | 1日1件（平均） | 0件の日14日・3件の日1日のばらつきを使う | 72%（障害なし・分割なし） |
| ② 障害対応は起きない | 障害の週を除く | 41日中5日が0件 | 43%（分割なし） |
| ③ 残りは20件のまま | 20件 | 未着手18件 × 1.27〜1.40 → 合計 25〜27件 | 14%（障害なし） |
| ①〜③すべて実績に | — | — | 4%（50%: 11/30、85%: 12/7 → 凍結中なので実際は 1/7 以降） |
2. 確率つきの予測
リリースのバーンアップと予測の扇
緑の帯＝完了件数の 15〜85 パーセンタイル、緑の線＝中央値。灰の破線＝佐々木さんの直線（1日1件）。赤の帯＝分割後の全件数 25〜27件。水色の線＝約束の線（R10 まで、分割後 約15件）。
11/17 までに終わる件数の分布（How Many）
緑の棒＝85%以上の確率で到達する範囲（15件以上）。赤の線＝分割後の全件数の中央（26件）。
| 問い | 50% | 85% |
|---|---|---|
| (a) 全件（分割後 25〜27件）が終わる日 | 11/30 | 12/7 |
| (b) 11/17 までに終わる件数 | 19件以上 | 15件以上（着手済み2件を引いて 13 ÷ 1.33 ≒ 着手前の数え方で約10件） |
⚖️
障害の週は入れる。41日中5日の実績を「起きない」と仮定する根拠はない。外した数字も右列に併記し、障害が1回起きるかどうかで R12 が 87% と 65% に分かれることを部長会に見せる。
3. 優先順位の線ごとの到達確率表
| 線（ここまで） | 件数（分割前） | 11/17 までに終わる確率 | 85% の日付 | 障害の週を外すと | 区分 |
|---|---|---|---|---|---|
| R06 | 8 | 100% | 11/6 | 100% | 約束 |
| R07 | 9 | 99% | 11/10 | 100% | 約束 |
| R08（「必要」全部） | 10 | 97% | 11/12 | 100% | 約束 |
| R09 代引き・後払い | 11 | 93% | 11/16 | 99% | 約束 |
| R10 アプリ内表示 | 12 | 87% | 11/17 | 97% | 約束（ここまで） |
| R11 まとめて1枚 | 13 | 78% | 11/19 | 94% | 届けば出す |
| R12 英語 | 14 | 65% | 11/20 | 87% | 届けば出す |
| R13 | 15 | 51% | 11/25 | 79% | 凍結明け |
| R14 | 16 | 33% | 11/27 | 62% | 凍結明け |
| R15〜R18 | 17〜20 | 24%〜4% | 11/30〜12/7 | 51%〜14% | 凍結明け |
85% の日付が 11/18 以降のものは計算上の日付。凍結期間中は出せないので、実際は 1/7 以降。届けば出す線の作りかけは機能フラグで隠してリリースする。
4. 部長会に出す1枚
領収書セルフ発行 — 進捗報告（10/22 部長会）
信号: 約束の線（R10 まで）Green 87% 全20件 Red 4%
| 問い | 答え |
|---|---|
| 11/19 に何が出るか | 宛名・インボイス記載事項・再発行の印字・返品後の金額・クーポン/ポイント・ギフトの宛名・写しの保存・CS の確認画面・代引き/後払い・アプリ表示（12件、85%以上） |
| 届けば出すもの | まとめて1枚（78%）、英語（65%） |
| 凍結明け（1/7〜） | 会社名の候補・メール送付・回数上限・文面編集・ダッシュボード・電子署名（6件） |
| 予測の根拠 | 直近41稼働日の日別完了件数（障害対応の5日を含む）と過去3案件の分割倍率（1.27〜1.40）で2万回試算 |
| 前回の報告との違い | 下書きの「全20件 11/16、Green」は平均・障害なし・分割なしが前提。同じデータで確率にすると 4% |
判断を頼むこと: ① 約束の線を R10 までとすることの承認 ② R11 を上げたい場合は R09・R10 のどちらかと入れ替える（線より上の件数は増やさない）
信号の決め方: 約束の線の到達確率 85%以上 Green／50〜85% Yellow／50%未満 Red。毎週金曜に計算し直す。
| 日付 | 見るもの | 条件 | 動かし方 |
|---|---|---|---|
| 毎週金曜（10/23・10/30・11/6・11/13） | 約束の線の到達確率 | 85% を下回った | Yellow にし、翌週月曜に R10 を「届けば出す」へ下げる案を PO に出す |
| 同上 | 実際の分割倍率 | 1.40 を超えて割れた | 倍率を差し替えて計算し直す |
| 11/6（金） | 約束の線の到達確率 | 70% を下回った | 線を動かす最後の判断日。R10 を外す。以降は作りかけを増やさない |
| 11/13（金） | 届けば出す線 | R11・R12 に未着手がある | 着手しない。凍結明けへ |
試算ツール（ブラウザ内でモンテカルロを実行）
「実績」を動かすと、その10日分を実績に足し（件数をなるべく均等に配分）、残り件数から引き、期限までを11稼働日にして計算し直す（10/30 の見直しの練習）。その10日に終わった項目は線の上から順に消化したとみなす。試行 5,000回・JavaScript の乱数のため Python の値と ±2ポイント程度ずれる。
棒＝期限までに終わる件数の分布（緑＝線の件数以上に届いた試行）。
読み方クイズ
| 文 | 正しい？ |
|---|---|
| 「R10 まで 87%」は、12件のうち約87%（10件）が終わるという意味だ | |
| 平均の速さで出した日付は、おおよそ半分の確率で遅れる日付だ | |
| 試行回数を10万回に増やせば、予測の幅は大きく狭まる | |
| 「11/17 までに 85% で 15件以上」は、15件を下回る確率がおよそ15% ということだ | |
| 分割倍率は残り20件すべてにかけるべきだ |
💡 なぜこう作るのか
- 「いつ終わるか」より「何が出せるか」: 11/19 は凍結で動かせない。「12/7 です」は選べない答えで、部長が判断できるのは線の引き方だけ
- 全20件の Red も並べる: 約束の線だけ見せると「全部出る」と受け取られかねない。去年12月の「あと少し」はこの受け取り違いから始まった
- 障害の週を入れる案を主に: 外した数字のほうが見栄えはよいが根拠がない。両方を並べると障害対応の体制の話を部長会に持ち込める
- 85% を約束の基準に: 50% は半分外れる。95% にすると約束の線が R08 まで下がり、93% の R09 と 87% の R10 を外すことになる。85% はチームの決めごとで、科学的に正しい閾値という根拠はない
- 線を動かす最後の日を 11/6 に: 以降は残り7稼働日で、着手済みを終わらせる日数しかない
🔀 迷った他案と採らなかった理由
| 案 | 採らなかった理由 | 判断が変わる条件 |
|---|---|---|
| 平均の予測（20件 ÷ 1件/日）をそのまま出す | 同じデータで確率にすると 4%。「全部出る」と誤解される | — |
| ポイントのベロシティで予測 | 未着手18件は未見積もり。見積もり会に 4人×半日かかり、答えはほぼ変わらない見込み（検証していない） | 項目の大きさが過去と大きく違うとき |
| 三点見積もり（PERT）で項目ごとに積む | 20件それぞれの O/M/P が要る。Day054 は残り7件・中身が分かっている場面だった | 項目が少なく中身が分かっているとき |
| 障害の週を外した数字を主にする | 41日中5日の実績を「起きない」とする根拠がない | 障害対応を別チームが受け持つ体制になったとき |
| 人を増やして全20件を間に合わせる | 残り21日では立ち上げの時間で完了件数が減る側に働きやすい（Brooks の法則、Day041） | 同じコードの経験者が1か月以上入れるとき |
| 凍結の例外を申請して 11/30 に出す | 85% の日付は 12/7。例外をとっても届かない | — |
| 試行回数を10万回に増やす | 2万回と結果はほとんど変わらない。精度を決めているのは実績の短さ | — |
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 平均の速さで残り件数を割って日付を出す | おおよそ半分の確率で遅れる日付 | 分布で予測し、50% と 85% を並べる |
| 未着手の件数をそのまま残り件数にする | 作り始めると割れる（20件 → 25〜27件） | 過去の分割倍率をかける |
| 都合の悪い期間を外す | 楽観側にずれる | 両方計算し、外すなら理由を書く |
| 「全部の日付」だけを報告する | 期限が動かせないと部長は選べない | 線ごとの確率を出し、線の引き方を判断してもらう |
| 確率を1回出して終わる | 実績が増えれば予測は変わる | 毎週計算し直し、条件と最後の判断日を先に決める |
| 85% を「85% 終わる」と読む | 15% の確率で約束を外す | 外れたときの扱い（届けば出す線・機能フラグ）をセットで書く |
🏢 実務での使いどころ
- 使う局面: 期限が動かせないリリース（凍結・法令の施行日・提携先との公開日）の1〜2か月前に、経営層・他部署へ「何が出るか」を報告するとき。Day051 のスプリント内の進捗より長い期間を、外の人に向けて見せる
- 隣接する役割: PO には「線の上の件数は増やさず入れ替える」ルール、部長には確率と線、エンジニアには毎週金曜の件数の記録（チケットの完了日から自動で出せる）。法令の要件を持つ経理には、その要件（R02・R07）が線のかなり上にあることを示す
- 個人開発への転用: 完了したタスク数を日別に記録しておけば、同じ方法で「50% ならこの日、85% ならこの日」の2つの日付を出せる
➡️ 次のステップ
- 問い: 10/30 の見直しで、2週間の完了件数が 7件だった。線ごとの確率はどう動き、11/6 の判断を前倒しすべきか（上の試算ツールで「10/19〜10/30 の実績」を 7 にして確かめる）
- 問い: R18 電子署名を凍結明けの最初に入れるとき、件数で予測してよいか。分割して大きさをそろえる以外の手はあるか
- テーマ3-6「ステータスレポート作成」（Mid）で、今回の1枚を経営層向けの定型の報告に組み込む
🧭 扱わなかった範囲・検証していない点
- 数値はすべて演習の設定値（仮定）。表の確率は Python で 2万回・種 20261016 の導出値。試算ツールは JavaScript の別の乱数で ±2ポイント程度ずれる
- 41日・3案件という実績は短い。予測が安定するのに要る実績の量は扱っていない
- 日々の完了件数を互いに独立として引いている。「レビューが詰まった翌日にまとめて終わる」連続性があると、幅を狭く見積もっている可能性がある
- QA 1名のボトルネック（Day051 の主題）は今回の予測に入れていない。QA の重い項目（R02・R04）が並ぶ場合は楽観側にずれる
- インボイスの簡易インボイスの記載事項と「写しの保存」は国税庁「インボイス制度の概要」で確認（nta.go.jp、参照日 2026-10-16）。写しの保存期間と PDF 交付時の保存方法は未照合
- 一次資料: Scrum Guide 2020・Kanban Guide v2025.5（WebFetch で該当文を確認）。ActionableAgile ドキュメント・Magennis の講演は検索結果の要約経由で、本文は未取得