🎬 シナリオ
MOps チームの「タイムセール班」は、タイムセール価格の予約と自動切替を作っている。マーケの価格担当が管理画面で「11/11 10:00〜12:00 にこの商品を 1,980円」と予約すると、時刻どおりに価格が切り替わり、終了時刻に戻る。今は担当者が深夜に手で書き換えている。
- スプリント S8: 10/1（木）〜10/15（木）、10/12（スポーツの日）を除き稼働 10日。今日 10/9（金）は7日目の終わり、残り 3日
- 10/15 のレビューでマーケの価格担当2名がステージングで予約を操作する（11/11 の本番設定に使えるかの確認）
- 体制: エンジニア4名（リード 岡田さん・西村さん・石井さん・あなた）、QA 1名（藤井さん）。1人1日 6時間
🎯
スプリントゴール: マーケが管理画面で予約したタイムセール価格が、指定時刻にステージングで自動で切り替わり、終了時刻に戻る。切替をまたいだカートも正しい価格で注文できる。
💬
岡田さん（リード）「残り 84時間。5人 × 3日 × 6時間 = 90時間あるから順調です」
中島さん（PO）「でもポイントは 28 のまま3日間動いていません。土日に出てもらえませんか」
EM 村田さん「どちらが正しいのか、今日中に1枚にまとめて。月曜朝のデイリースクラムで打ち手を決めたい」
中島さん（PO）「でもポイントは 28 のまま3日間動いていません。土日に出てもらえませんか」
EM 村田さん「どちらが正しいのか、今日中に1枚にまとめて。月曜朝のデイリースクラムで打ち手を決めたい」
スプリントバックログ（11項目・30pt、出所はすべて「仮定（演習の設定）」）
| ID | 項目 | pt | ゴール | 着手日 | 7日目の状態 |
|---|---|---|---|---|---|
| T1 | 予約テーブルとマイグレーション | 2 | 必要 | 1 | 完了（3日目） |
| T2 | 管理画面の予約登録フォーム | 5 | 必要 | 1 | QA中 |
| T3 | 切替バッチ（開始時刻に価格反映） | 5 | 必要 | 1 | レビュー待ち（5日目から。PR 1,400行、読めるのは岡田さんだけ） |
| T4 | 終了時刻に元の価格へ戻す | 3 | 必要 | 3 | レビュー待ち（6日目から） |
| T5 | 切替をまたいだカートの価格整合 | 5 | 必要 | 2 | 開発中（残り 10h） |
| T6 | 価格キャッシュの削除 | 2 | 必要 | 4 | QA待ち |
| B1 | 不具合: 時刻が UTC 表示 | 1 | 必要 | 5 | QA待ち |
| T7 | 予約の一覧・取消画面 | 3 | 不要 | 5 | 開発中（残り 8h） |
| B2 | 不具合: CSV 文字化け | 1 | 不要 | 6 | 開発中（残り 3h） |
| T8 | 監査ログ | 2 | 不要 | — | 未着手 |
| T9 | 重複予約の警告 | 1 | 不要 | — | 未着手 |
毎日の記録
| 日 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|---|---|
| 残り時間(h) | 240 | 222 | 200 | 176 | 150 | 128 | 104 | 84 |
| 理想線(h) | 240 | 216 | 192 | 168 | 144 | 120 | 96 | 72 |
| 残りポイント | 30 | 30 | 30 | 28 | 28 | 28 | 28 | 28 |
7日目の残り 84h の内訳
| 段階 | ゴール項目 | ゴール外 | 計 |
|---|---|---|---|
| 開発 | 10（T5） | 27 | 37 |
| レビュー | 7（T3 3・T4 2・T5 2） | 2 | 9 |
| QA | 23（T2 4・T3 6・T4 4・T5 6・T6 2・B1 1） | 8 | 31 |
| リリース準備 | 7 | 0 | 7 |
| 計 | 47 | 37 | 84 |
過去3スプリント: 完了 9・10・9件（約 0.93件/日）、最後の3日の完了 5・6・5件、サイクルタイムの 85パーセンタイル 4稼働日（28件）。
状態別の件数（各日の終業時点）
| 日 | 未着手 | 開発中 | レビュー待ち | QA待ち | QA中 | 完了 |
|---|---|---|---|---|---|---|
| 1 | 8 | 3 | 0 | 0 | 0 | 0 |
| 2 | 7 | 3 | 1 | 0 | 0 | 0 |
| 3 | 6 | 4 | 0 | 0 | 0 | 1 |
| 4 | 5 | 4 | 1 | 0 | 0 | 1 |
| 5 | 3 | 5 | 1 | 1 | 0 | 1 |
| 6 | 2 | 4 | 3 | 0 | 1 | 1 |
| 7 | 2 | 3 | 2 | 2 | 1 | 1 |
📝 課題
あなたのタスク: 村田さんに渡す1枚を作ってください。
- 3つのグラフの読み比べ表: 時間のバーンダウン・ポイントのバーンダウン・累積フロー図（上の状態別件数から自作）が何を測り、何を言い、何を見落とすか。岡田さんと中島さんのどちらが正しいか
- 経過日数つき仕掛かり一覧: 着手済み・未完了の項目を経過日数で並べ、85パーセンタイル 4日超えに印をつけ、月曜にどの順で手をつけるか
- 残り3日の検算と打ち手: 「90h ある」を段階別に検算。「やめる／寄せる／外す」で打ち手を書き、外すなら PO と交わす内容と判断の日時
- 次スプリントから見るグラフの提案: 何をやめ、何を足すか。やめて失うもの
🔍 ヒント（段階的開示）
ヒント1
84h と 90h の比較は「時間はどの段階にも回せる」前提に立っている。QA は藤井さん1人で 3日 18h
ヒント2
ポイントが平らなのは「止まっている」のか「完了の手前に溜まっている」のか。累積フロー図の帯の太さを見る
ヒント3
T3 は5日目からレビュー待ち。誰が読めるのか
ヒント4
経過日数が長い項目からか、完了に近い項目からか。両方を満たす順を考える
ヒント5
土日出勤で増えるのは誰の時間か
ヒント6
途中まで作った T7・B2 を「やめる」とき、どう扱うか。外すのは範囲か、テストか
📚 背景知識・用語解説
📖
スクラムはバーンダウンを必須にしていない: Scrum Guide 2020 は「Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows.」と書くだけ（Scrum Guide 2020、WebFetch で確認、参照日 2026-10-09）。デイリースクラムの目的は、スプリントゴールへの進捗を点検し、必要ならスプリントバックログを調整すること。グラフはそのための道具で、どれを見るかはチームが選んでよい。
3つのグラフが測っているもの
| グラフ | 測っているもの | 得意 | 苦手 |
|---|---|---|---|
| 作業時間のバーンダウン | 見積もった残り時間の合計 | チーム全体の手が空きそうか | 終わったかどうか。時間はどの段階にも回せるという暗黙の前提 |
| ポイントのバーンダウン | 完了した項目のポイント | ゴールに対して何が完了したか | 完了の手前で何が起きているか |
| 累積フロー図（CFD） | 状態ごとの件数の推移 | どこに溜まっているか（帯が太る場所） | 項目の大きさ、個々の遅れ |
流れの4指標（Kanban Guide）
Kanban Guide v2025.5（Vacanti・Coleman ほか、kanbanguides.org、WebFetch で確認、参照日 2026-10-09）の必須指標:
- WIP: 着手したが終わっていない項目の数
- スループット: 単位時間あたりの完了件数（数そのものを数える）
- Work Item Age（経過日数）: 着手から今日までの経過時間
- サイクルタイム: 着手から完了までの経過時間
🚧
時間は段階をまたいで回せない: 合計で足りていても、一番細い段階（ボトルネック）で足りなければ終わらない。経過日数が過去の 85パーセンタイルを超えた項目は「いつもより遅れている」項目で、デイリースクラムで最初に話す対象になる。
✅ 模範解答
答えを見る前に、自分の読み比べ表と仕掛かり一覧を作ってから読み比べてください。
1. 3つのグラフの読み比べ
作業時間（岡田さん）
ポイント（中島さん）
累積フロー図（自作）
破線＝理想線。CFD の色: 灰＝未着手、青＝開発中、黄＝レビュー待ち、橙＝QA待ち、紫＝QA中、緑＝完了。
| グラフ | 7日目に言っていること | 正しい点 | 見落としている点 |
|---|---|---|---|
| 作業時間 | 残り 84h、理想 72h から約 0.5日遅れ、90h に収まる | チーム全体の手は足りている | 84h のうち QA が 31h、QA の時間は 18h。ゴール項目の QA だけで 23h |
| ポイント | 3日目から 28pt のまま | 完了は T1 だけ。ゴールは何も確かめられていない | 止まってはいない。7件が完了の手前にいる |
| 累積フロー図 | 未着手は減り、レビュー待ち＋QA待ち＋QA中が 0→5件に太った。完了は1件のまま | 溜まっている場所はレビューと QA | どの項目が一番遅れているか（→ 経過日数で補う） |
⚖️
どちらが正しいか: どちらも一部だけ正しい。岡田さんの「手は足りている」は正しいが「順調」ではない。中島さんの「完了していない」は正しいが「止まっている」ではない。作業はレビューと QA の前で渋滞している。土日出勤で増えるのはエンジニアの開発時間で、渋滞している場所は広がらない。
クイズ: この事実はどのグラフで見えるか
| 事実 | あなたの判定 |
|---|---|
| チーム全体としては手が空きそうだ | |
| ゴールに必要な項目で完了したのは T1 だけ | |
| 完了の手前に項目が溜まっている | |
| T3 がいつもより大幅に遅れている | |
| チームは新しい項目を始め続けている | |
| 遅れている項目はすべてゴールに必要な項目 | |
| QA の時間が 5h 足りない |
2. 経過日数つき仕掛かり一覧（7日目終業時点）
赤い破線＝過去のサイクルタイムの 85パーセンタイル（4日）。緑の縁＝ゴールに必要な項目。
| 順 | ID | 状態 | 経過日数 | 4日超え | ゴール | 月曜の手 |
|---|---|---|---|---|---|---|
| 1 | T2 | QA中 | 7 | 超え | 必要 | 藤井さんが最初に終わらせる（残り 4h） |
| 2 | T3 | レビュー待ち（3日） | 7 | 超え | 必要 | 岡田さんが朝一でレビュー、西村さんが同席して読み方を覚える |
| 3 | T4 | レビュー待ち（2日） | 5 | 超え | 必要 | T3 の直後に同じ箇所として続けてレビュー |
| 4 | T5 | 開発中 | 6 | 超え | 必要 | 石井さんとあなたのペア（残り 10h → 13日中にレビューへ） |
| 5 | T6 | QA待ち | 4 | 境目 | 必要 | 藤井さんの手順書でエンジニアが実行 |
| 6 | B1 | QA待ち | 3 | — | 必要 | 同上 |
| — | T7 | 開発中 | 3 | — | 不要 | 止める |
| — | B2 | 開発中 | 2 | — | 不要 | 止める |
並べ方: 完了に近い段階から、同じ段階なら経過日数が長い順。開発中から手をつけると、レビューと QA の前の列がさらに伸びる。4日を超えた4件はすべてゴール項目。チームは新しい項目を始めて「手を止めない」状態を保ち、古い項目を前に進めていなかった。
3. 残り3日の検算と打ち手
| 段階 | ゴール項目の残り | ゴール外も含む | 使える時間 | 判定 |
|---|---|---|---|---|
| 開発・レビュー・リリース準備（エンジニア4名） | 24h | 53h | 72h | 足りる |
| うちレビュー（岡田さん） | 7h | 9h | 岡田さんの 18h の一部 | 足りるが取り合い |
| QA（藤井さん） | 23h | 31h | 18h | ゴールだけでも 5h 不足 |
スループットで見ても、過去の最後の3日の完了は 5〜6件。ゴールに残る6件は届くかどうかの境目。
| 種類 | 内容 | QA の残り（ゴール） | 余裕 |
|---|---|---|---|
| やめる | T8・T9 は始めない。T7・B2 は残り時間を書いてバックログへ戻し、今スプリントの QA に流さない | 23h | −5h |
| 寄せる | T6・B1・T4 の確認手順を藤井さんが 1h で書き、エンジニアが 7h 分実行。T3 のレビューに西村さんが同席 | 23 − 7 + 1 ＝ 17h | +1h（6%） |
| 外す（条件つき） | T5 を T5a「決済直前に価格を再計算して表示」3pt と T5b「切替をまたいで確定した注文の差額処理」2pt に分け、T5b を次スプリントへ | 17 − 3 ＝ 14h | +4h（22%） |
⏰
判断の日時と条件: 10/13（火）15:00 に T5 がレビューに出ていなければ「外す」を実行。15:00 は、外した後でも T5a の QA（3h）が 14・15日に入る最後の時刻。PO と確認すること: T5a で「表示と請求の価格が一致する」はゴールの文言を満たすか／T5b を S9 の最初に積み 11/11 の本番設定までに終えるか。
Scrum Guide は「Scope may be clarified and renegotiated with the Product Owner as more is learned.」とし、品質を下げないとしている（同上）。外すのは範囲で、テストではない。
Scrum Guide は「Scope may be clarified and renegotiated with the Product Owner as more is learned.」とし、品質を下げないとしている（同上）。外すのは範囲で、テストではない。
余ったエンジニアの約 41h は T7 の再開に使わず、T3 切替バッチの自動テストと T5 のペアに使う。土日出勤は増えるのが開発時間で、藤井さん1人の休日出勤は持続しない。行わない。
試算: 打ち手を組み合わせて段階別に検算する
QA（需要 / 使える時間）
エンジニア（需要 / 使える時間）
4. 次スプリントから見るグラフの提案
| 変更 | 内容 | 理由 | 失うもの・その補い |
|---|---|---|---|
| やめる | 作業時間の毎日の更新 | 「順調」に見えて渋滞を隠した。5人が毎日約 10分かけていた | 「手が足りるか」の確認 → 計画時だけ段階別に時間を見積もる |
| 足す | 経過日数チャート（85% 線 4日） | どの項目から手をつけるかが毎朝決まる | 85% 線は毎スプリント引き直す |
| 足す | ゴール項目だけの件数バーンアップ | ゴールに対して完了したかを見る | 大きさの違いは見えない → 5pt 以上は分割を先に検討 |
| 足す | WIP 上限: レビュー待ち＋QA待ち 合計3件まで | 上限に達したら新しく始めず、レビューかテストを手伝う | 一時的に手が空いたように見える。それでよい |
| 残す | ポイントのバーンダウン（PO 向け） | PO が慣れており、全体の完了量は見える | 単独では読まないと申し合わせる |
💡 なぜこう作るのか
- どちらが正しいかに先に答える: 村田さんは月曜朝に打ち手を決めたい。解説から始めると結論が埋もれる
- 累積フロー図を自作させた: 11件では帯は粗いが、「完了の帯が細いまま手前の帯が太る」形は見える。2つのバーンダウンの食い違いを1枚で説明できるのはこの図だけ
- 経過日数で順番を決める: 合計のグラフは遅れているかしか言わない。必要なのは誰が何から手をつけるか
- 合計の時間を段階別に割る: 90h ＞ 84h の計算は正しい。誤りは時間が段階をまたいで回せるという前提
- 「外す」に日時をつける: 金曜に外すと、月曜に T5 が順調なら要らない交渉になる
🔀 迷った他案と採らなかった理由
| 案 | 採らなかった理由 | 判断が変わる条件 |
|---|---|---|
| 時間のバーンダウンを信じて何もしない | QA で 5h、ゴール外を含めると 13h 不足 | QA が2名いる、または全員が QA の手順を持っている |
| 土日出勤（中島さん案） | 増えるのは開発時間で、渋滞は広がらない | 足りない段階が開発だった場合に、2日だけの例外として EM が判断 |
| 他チームの QA を借りる | 価格テスト環境の準備に約1日、残り3日の1/3 | T5 を外せないと PO が判断し、借りる人が価格テスト経験者 |
| 今すぐ T5 を外す | 月曜に順調なら不要な交渉と持ち越し | T5 の残りが 10h を超えて増えたと報告されたとき |
| QA を省いて T6・B1 を完了にする | 品質を下げない。キャッシュ削除の誤りは古い価格のまま売る事故 | 無い |
| T7 を再開して手を止めない | 次スプリントの QA 待ちを今から作る | WIP 上限を下回っているとき |
| 段階別に時間のバーンダウンを3本引く | 更新の手間が3倍、経過日数チャートで同じ判断ができる | 段階ごとの担当が完全に分かれた大きいチーム |
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 残り時間の合計と使える時間の合計を比べて「間に合う」 | ボトルネックの段階で足りないことが隠れる | 段階別に割って比べる |
| ポイントが平らなことを「止まっている」と読む | 渋滞を見逃し、人を足すなど的外れな手になる | 累積フロー図か状態別の件数を並べる |
| 手が空いた人が新しい項目を始める | 古い項目がさらに待たされ、WIP が増える | 完了に近い段階から手伝う。WIP に上限を置く |
| 範囲を外す代わりにテストを省く | 品質を下げて完了に見せる | 外すのは範囲。ゴールの文言と照らして PO と合意 |
| 打ち手を「様子を見て判断」で終える | 判断の機会が過ぎてから外すことになる | 判断する日時と条件を先に書く |
| 最終日に気づく | 打てる手が残っていない | デイリースクラムで経過日数を毎朝見る |
🏢 実務での使いどころ
- 使う局面: スプリントの半分を過ぎた頃、グラフどうしやメンバーの感覚が食い違ったとき
- 隣接する役割: QA やレビューが1人に集中するチームでは「手を止めない」優先が渋滞を生む。EM には段階別の検算を、PO には外す範囲と判断の日時をセットで渡す
- 個人開発への転用: 作業を「作った・確かめた・公開した」の3段階で数え、「作った」だけが増えるなら新しい機能を始める前に確かめる作業を片付ける
➡️ 次のステップ
- テーマ3-3「レトロスペクティブ運営」で、なぜ7日目まで気づかなかったかを振り返る
- 問い: T5 が 13日 15:00 にレビューに出たが大きな指摘で差し戻された。14日の朝に何を見て何を決めるか
- 問い: WIP 上限を 2件／5件にするとエンジニアの動き方はどう変わるか（上の試算で QA 時間とテスト移管を動かして確かめる）
- テーマ3-10「情報ラジエーターの設計」（Senior）で経過日数チャートを壁にどう出すかを扱う
🧭 扱わなかった範囲・検証していない点
- 数値はすべて演習の設定値（仮定）。85パーセンタイル 4日は過去28件からの設定で、ばらつきは大きい
- 累積フロー図から平均サイクルタイムを読む使い方（リトルの法則）は扱っていない（Day037 で扱った）
- スループットのモンテカルロ予測は扱っていない。3日・6件の判断では過去の最後の3日の件数で境目と分かったため
- エンジニアが QA 手順を実行したときの見逃し率は検証していない。T6・B1・T4 は影響範囲が狭く手順化しやすいという仮定
- 一次資料: Scrum Guide 2020、Kanban Guide v2025.5。いずれも WebFetch で確認（参照日 2026-10-09、要約ツール経由で該当文を引用）。CFD の起源や「90% 症候群」の出典は未照合のため名前を出していない