🎬 シナリオ
MOps チームは 「お気に入り商品の値下げ通知」（お気に入りの商品が値下がりしたらメール／アプリで知らせる機能）を開発している。11/27（金）開始のブラックフライデー販促に合わせ、11/20（金）リリース、コードフリーズは 11/13（金）。2週間スプリント。今日 10/2（金）に Sprint 3 が終わった。体制はエンジニア3名＋QA 1名。
💬
PO「残りが 120→98→92→88。後ろにいくほど減りが鈍っていて、チームが失速しているように見えます。次から人を増やしてもらえませんか」
💬
EM「失速はしていないはず。ただし 11/13 に間に合う根拠を数字で見せてほしい」／CS部門長「配信停止リンクと頻度設定は問い合わせが出る前に入れたい」／マーケ部長「追加した機能は全部 BF で効くと思う」
数値はシナリオ上の設定（仮定）。「導出」は設定値からの計算。
| 時点 | 期間 | 稼働日 | 期末の総スコープ(pt) | 期間中の完了(pt) | 累計完了(pt) | 残り(pt) |
|---|---|---|---|---|---|---|
| S0 | – | – | 120 | – | 0 | 120 |
| S1 | 8/24–9/4 | 10 | 120 | 22 | 22 | 98 |
| S2 | 9/7–9/18 | 10 | 138 | 24 | 46 | 92 |
| S3 | 9/21–10/2 | 10 | 156 | 22 | 68 | 88 |
S3 の9月の連休は、チームが別の日に振替休日を取ったため稼働10日で数える、という設定。
| 期間中に追加されたスコープ（計36pt） | pt | 依頼元 | 追加 |
|---|---|---|---|
| 価格履歴グラフ | 8 | マーケ | S2 |
| 通知頻度の設定画面 | 6 | CS | S2 |
| 配信停止（オプトアウト）リンク | 4 | CS／法務 | S2 |
| アプリのプッシュ通知 | 10 | マーケ | S3 |
| 在庫復活通知 | 5 | マーケ | S3 |
| CS 向け管理画面 | 3 | CS | S3 |
| 残りのスプリント | 期間 | 稼働日 |
|---|---|---|
| S4 | 10/5–10/16 | 9（10/12 スポーツの日） |
| S5 | 10/19–10/30 | 10 |
| S6 | 11/2–11/13 | 9（11/3 文化の日） |
📝 課題
🛠️
あなたのタスク: 次の5点を含む「進捗レポート（1ページ）」を作ってください。
- 表からバーンダウン図とバーンアップ図を描く（バーンアップは「総スコープ」と「累計完了」の2本線）
- PO の「失速している」は正しいか。バーンダウンが何を隠したかを数字で説明する
- 1稼働日あたりの完了を出し、11/13 までに完了できる量の範囲（楽観・中央・悲観）を出す
- スコープ 156pt をいくつに絞るべきか計算し、追加6件のどれを後ろに送るか理由つきで決める
- 次のレビューから使う見直しのルール（何が起きたら誰に何を相談するか）を書く
🔍 ヒント（段階的開示）
ヒント1: 2本の線に分ける
バーンダウンは「残り」1本。完了が進んだ分とスコープが増えた分が相殺されて見える。総スコープと累計完了を別の線にすると何が見えるか。
ヒント2: 稼働日で割る
S4・S6 は9日。ポイントを1稼働日あたりに直してから、残り28日を掛ける。
ヒント3: 範囲は素直に
実績は3回分。最小〜最大で範囲を出す。確率分布に見せかけない。
ヒント4: 「後から足せるか」
追加6件を全部やる／やらないにしない。やらないと何が起きるか、後から足せるかで分ける。法令に関わるものは別扱い。
ヒント5: 人を増やす案
遅れの原因は速度かスコープか。人を足した直後に何が起きるか（ブルックスの法則）も考える。
📚 背景知識・用語解説
- バーンダウン: 縦軸「残りの作業量」。シンプルだが、縦軸が1本なのでスコープの増減と完了の進みが見分けられない。
- バーンアップ: 「累計完了」と「総スコープ」の2本。完了が総スコープに追いつく日が完了日。増えたことがそのまま見えるので、「遅れ」と「増えた」を分けて議論できる。
- ベロシティ: スプリントの完了ポイント。稼働日が違うと比べにくいので1稼働日あたりで扱う。
- スコープの天井: 「いまの累計完了」＋「期限までに完了できる量」。これを超える総スコープは間に合わない。足すなら同量を外へ。
📖
出典（参照日 2026-10-02）
- Scrum Guide 2020 — scrumguides.org/scrum-guide.html: バーンダウン／バーンアップ等は有用だが経験による確認の代わりにはならない、という趣旨の記述（原文を参照）。予測は約束ではない。
- Cohn『Agile Estimating and Planning』(2005)、書籍: バーンアップでスコープの増減を別の線にする考え方（本文は今回再確認していない）。
- Brooks『The Mythical Man-Month』(1975)、書籍: 遅れたプロジェクトに人を足すとさらに遅れる。
- 特定電子メール法（総務省）: 広告・宣伝を含むメールには受信拒否の方法の表示などが求められる。値下げ通知が該当するかは法務確認が前提（仮定）。
✅ 模範解答
1. バーンダウンとバーンアップ
バーンダウン（残り）— 120→98→92→88
バーンアップ — 赤: 総スコープ／緑: 累計完了／点線: 11/13（S6末）までの予測（悲観・楽観）／紫: 絞った後のスコープ 124
| 時点 | 総スコープ | 累計完了 | 残り |
|---|---|---|---|
| S0 | 120 | 0 | 120 |
| S1末 | 120 | 22 | 98 |
| S2末 | 138 | 46 | 92 |
| S3末 | 156 | 68 | 88 |
2. 「失速」ではない
| スプリント | 完了 | 稼働日 | 1稼働日あたり 導出 | 残りの減り | 追加スコープ |
|---|---|---|---|---|---|
| S1 | 22 | 10 | 2.20 | −22 | 0 |
| S2 | 24 | 10 | 2.40 | −6 | +18 |
| S3 | 22 | 10 | 2.20 | −4 | +18 |
🩺
残りの減りが −22→−6→−4 と鈍ったのは、完了が落ちたからではなく、追加が18ptずつ入ったから。完了は 22→24→22 で安定。「失速」ではなく「スコープが毎スプリント18ptずつ増えている」。人を増やす議論の前に、スコープの議論が要る。
3. 11/13 までに完了できる量
1稼働日あたり: 最小 2.20／最大 2.40／平均 2.267（68÷30日 導出）。残りの稼働日 9＋10＋9＝28日。
| 1日あたり | 28日で完了 | 11/13 の累計完了 | |
|---|---|---|---|
| 悲観 | 2.20 | 61.6pt | 129.6pt |
| 中央 | 2.267 | 63.5pt | 131.5pt |
| 楽観 | 2.40 | 67.2pt | 135.2pt |
156pt のままだと、残り 88pt のうち 11/13 までに終わるのは約62〜67pt。約21〜26pt が残る。中央値では S6 のあと約10.8日分（S7 を使い切って S8 に入る＝11/30〜12/1 頃）に食い込み、BF（11/27）に間に合わない。現状の増え方（1.8pt/日）が続くと実質の進みは 0.47pt/日で、ほぼ終わらない。
試算ツール（11/13 時点）
4. スコープの天井と判断
天井＝累計完了 68＋28日で完了できる量＝ 129.6〜135.2pt（中央 131.5pt）。156pt なので少なくとも 21〜26pt を外す。ぎりぎりを狙わず 124pt まで絞る（32pt を後ろへ）。
| 追加 | pt | 判断 | 理由 |
|---|---|---|---|
| 配信停止リンク | 4 | 残す | 広告・宣伝を含むメールになりうる。送ってから足すのは遅い（法務確認が前提）。後から足せない種類 |
| 通知頻度の設定画面 | 6 | 後ろへ | 初回は「1日1通まで」の固定ルールで代替できる。CS の懸念は固定ルールで当面しのげる |
| 価格履歴グラフ | 8 | 後ろへ | 通知の中核ではない。後から足せる |
| アプリのプッシュ通知 | 10 | 後ろへ | 最大の追加。メールだけでも値下げは伝わる。アプリ側の審査待ちも読めない |
| 在庫復活通知 | 5 | 後ろへ | 別機能。BF 後の次リリース候補 |
| CS 向け管理画面 | 3 | 後ろへ | 初回は SQL での調査で運用（エンジニアが当番） |
🎯
外す 32pt、残すのは 4pt。総スコープ 156−32＝124pt、残り 124−68＝56pt。28日の完了見込み 61.6〜67.2pt に対し、最悪でも約91%、中央で約88%、楽観で約83%の負荷。残る約5.6〜11pt が見積もりの外れや QA の戻りを吸収する余白。
5. 見直しのルール
| 条件 | 誰が | 何をする |
|---|---|---|
| 総スコープが 124pt を超える依頼が出た | PO | 同量を外に出す。外す先が決まらなければ EM に相談。その場で足さない |
| スプリント末の累計完了が中央の線（S4末 88.4／S5末 111.1／S6末 131.5 導出）を下回る | EM | 次のスプリント頭に残りの見積もりを見直す。悲観の線を下回ったら PO にスコープの追加削減を求める |
| 2スプリント連続で悲観の線を下回る | EM | フリーズ日の延期は選ばず、リリース範囲の縮小を経営会議に諮る |
| 毎スプリントレビュー | PO・EM | 図は必ずバーンアップ（2本線）。バーンダウンは補助 |
🧭 なぜこう作るのか
- バーンアップを主にする: PO の誤解は、バーンダウンが完了とスコープ増を1本に潰したことから生まれた。誰も責めずに「スコープは18ptずつ増えている」を図で見せる。
- 範囲で出す: 3回の実績では中央の1点を言い切れない。範囲を示し、それでも判断（124pt）が変わらないことを確認した。
- 余白を残す: 悲観でも91%に収まる量にした。余白がないと1回の QA の戻りで期限を割る。
- 「後から足せるか」で分ける: 機械的に全件外さず、法令に関わる配信停止は残す。
⚖️ 採らなかった案
| 案 | 採らなかった理由 | 判断が変わる条件 |
|---|---|---|
| バーンダウンだけで報告を続ける | スコープ増と完了が分からない | スコープがほぼ変わらない案件（増加が5%未満など）なら簡易さを優先 |
| 人を増やす（PO 案） | 立ち上がりに既存メンバーの時間を使う（ブルックス）。遅れの原因は速度でなくスコープ増 | 追加人員がこの領域を既に知っている場合 |
| 11/20 リリースを延ばす | BF 11/27 に間に合わず、機能の目的を失う | BF に間に合わせる意味が薄れた場合 |
| 累積フロー図（CFD） | 状態ごとの件数を記録しておらず作れない | 次のスプリントから状態別に記録すれば S6 頃から使える |
| 乱数による完了確率（モンテカルロ） | 実績3回では確率の数字が精密に見えるだけで根拠がない | 10回以上の実績が溜まったとき |
| QA を削って間に合わせる | 通知の誤送信は取り消せない | なし（外さない） |
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| バーンダウンが鈍ったら「速度が落ちた」と判断する | スコープ増でも同じ形になる | 完了とスコープを2本線にする |
| 稼働日の違いを無視してポイントをそのまま足す | 祝日のあるスプリントを過小評価する | 1稼働日あたりに直す |
| 予測を1つの日付で約束する | 外れたときに信用を失う | 範囲と前提を添える |
| 追加依頼を断らず全部入れる | 期限が静かに崩れる | 足すなら同量を外へ |
| 完了の定義が人によって違う | 累計完了がぶれ、図が意味を失う | QA 合格までを完了とそろえる |
💼 実務での使いどころ
スプリントレビューやステアリングで「間に合うのか」と聞かれる場面。経営層は日付と余白を見る。PO には追加の影響を責めずに図で見せられる。エンジニアには「期限に間に合う量」を逆算した根拠として渡せる。個人開発の週次振り返りにも使える。
✂️
扱わなかった範囲: 累積フロー図、確率予測、ポイント自体の水増し（インフレ）の検出、コストの進捗管理（EVM）。別の回で扱う。この回のデータは設定上の数字で、実測ではない。
➡️ 次のステップ
- 次の S4 末に、実際の累計完了を図に足して中央の線と比べる
- 状態別の件数を記録して累積フロー図を作る
- 「速度が落ちたと言われたときにどの記録を出すか」を自分のチームの場合で書き出す