Day 037 — PM-推進: スプリント計画の立て方

🎬 シナリオ

MOps チームは 「お歳暮ギフト対応（ラッピング・のし）」 を開発している。ギフト受付の開始は 11/2（月）10:00。カタログとメルマガで告知済みで、動かせない。リリース前の凍結は 10/28（水）。残りのスプリントは2回しかない。

• Sprint 19: 9/28（月）〜10/9（金）稼働10日 ← 今回計画するスプリント
• Sprint 20: 10/12（月・スポーツの日）〜10/23（金）稼働9日

体制はエンジニア4名（A・B: バックエンド、C: フロントエンド、D: フルスタック）と QA 1名（E）。2週間スプリント。

困っているのは、この4スプリント、毎回「計画の6割前後しか終わらない」こと。毎回、最終日に「ほぼ終わっている」項目が4〜6件残り、持ち越される。単発の障害や欠員ではない。

あなたはプランニングのファシリテーターを任された。

過去4スプリントの実績 実測

その他の実測値

Sprint 19 の在席予定: A・B・D は10日、C は 10/8–9 休暇（8日）。QA の E は 10/1 社外研修（9日）。

Sprint 19 の候補（PO の並び順・プランニングポーカー済み）

📝 課題

あなたのタスク: 月曜のプランニングで使う Sprint 19 の計画書 を作ってください。次の5点を含めること。

1. 持ち越しが続く原因の診断（表のデータから。「頑張りが足りない」「見積もりが甘い」で止めない）
2. 今回の予測量（pt）とその計算。「連休のせい」という PO の主張に数字で答える
3. スプリントゴール（1〜2文）と、それに対するスプリントバックログ（何を入れ、何を入れないか、理由）
4. QA の作業時間での検算と、同時進行の上限（WIP 上限）などの進め方のルール
5. 途中の見直し条件（何日目に何を見て、どうなっていたら何を削るか）

加えて、検討した計画案（採らなかった案）を2つ以上、理由と「判断が変わる条件」つきで残してください。

🔍 ヒント（段階的開示）

📚 背景知識・用語解説

ボトルネック（制約）: 流れ全体の速さは、いちばん詰まっている工程で決まる。エンジニア4人・QA 1人なら、QA を通った分しか「完成」にならない。ボトルネックでない人の空き時間は、ボトルネックを助けるのに使う。

✅ 模範解答

1. 持ち越しの原因の診断

(1) 連休の影響を除いても、完了量は計画の約3分の2で安定している

出所: 導出（実測値から計算）

PO の言うとおり、S18 の15ptは稼働日が7日しかなかったためで、1日あたりに直すと 2.14pt で、ふだんと変わらない。ただしそれは「このチームのふだんのペースは10日で約22pt」ということでもある。33ptは、この4回で一度も達成されていない量。連休は S18 の説明にはなるが、S15〜S17 の持ち越しの説明にはならない。

(2) 詰まっているのは QA

• 最終日に進行中だった 5・4・6・5件のうち、QA 待ちが 3・3・4・3件（毎回半分以上）
• QA 作業の見積もりは4回とも QA の作業可能時間を超えていた。しかも QA の見積もりは実績で1.2倍に膨らむ
• エンジニアの実装量に合わせて計画し、QA の時間を見ていなかった。pt では1人しかいない QA の詰まりは見えない

(3) 同時に着手しすぎて、1件が終わるまでにスプリントより長くかかっている

1件が終わるまで平均約12日、スプリントは10日。2日目以降に着手した項目は、平均的にはスプリント内に終わらない。これが「毎回9割で持ち越す」の正体。

2. Sprint 19 の予測量

ゴールに必要な項目は、幅の下限 18pt 以内に収める。下限なら、過去4回のどのペースでもゴールには届く。

3. スプリントゴール

1. 11/2 に最低限必要なのは、画面・金額・倉庫がつながっていること。部品が別々に9割できていても、つながっていなければ受付は始められない
2. 物流部は 10/19 からの研修に実物の CSV が要る。S19 で G5 を終えれば 10/9 に渡せて10日の余裕ができる
3. 金額計算（G2）は、誤りが出ると受付開始後に止めるしかない部分。先に通しで確認する

4. スプリントバックログ

5. QA の作業時間での検算

見積もり: タスク分解の結果 ／ 補正比 実測 ／ 合計 導出

割り込み予約 47h: 1稼働日あたりの割り込み（4.2・3.1・5.2・5.9h）の中央値 4.7h × 10日 導出。PO 案の QA = (6+10+10+8+20)×1.2 ≒ 65h、エンジニア = (2+14+30+16+40)×1.5 ≒ 153h（G4・G6 の時間見積もりはタスク分解の概算）。

6. 進め方のルール（このスプリントで試す）

7. 途中の見直し条件

8. PO への説明（プランニングの冒頭で5分）

• 「連休のせい、は S18 については正しいです。ただ1日あたりにすると S18 はふだんどおりで、ふだんのペースが10日で約22ptなんです。33ptはこの4回で一度も終わっていません」
• 「持ち越しの半分以上は QA 待ちです。QA の作業は4回とも QA の時間を超えていました。PO 案だと QA 作業は約65h、QA の時間は約50hです」
• 「今回は 18pt でゴールを約束します。過去いちばん遅いペースでも終わる量です。余力が出たら G4・G7 に進みます」
• 「G6 は入れないのではなく、今回のスプリント中に分割して、10/9 のレビューで『11/2 に何件の届け先まで出すか』を決められる材料を出します」

9. リリースまでの見通し（10/9 のレビューで PO が決めること）

S20 の予測: 2.17 × 9日 ≒ 19.5pt（幅 17〜21pt）導出。余力枠に着手できなかった場合、S20 に残るのは G4 5 ＋ G7 3 ＋ G6 13 ＋ G8 3 ＝ 24pt で予測を超える。

🧭 なぜこう作るのか

⚖️ 検討した計画案と採らなかった理由

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

🏢 実務での使いどころ

「毎回持ち越す」チームは多いが、原因を見積もりの甘さや頑張りに求めると次も同じことが起きる。このシナリオの診断は、課題管理ツールとボードから取れる数字（完了 pt・稼働日・QA 待ち件数・同時進行件数・サイクルタイム）だけでできる。ファシリテーターがプランニング前に集計しておけば、「PO の希望」と「チームの感覚」の言い合いを、同じ表を見ながらの話し合いに変えられる。

• PO: 「約束はゴール、量は予測」と整理すると、「確実に届くもの」と「最大でどこまで行くか」を分けてステークホルダーに説明できる
• QA: ボトルネックの人の不足を計画の場で数字で示すと、エンジニアがテストを手伝う話を始めやすい
• 物流部・マーケ: 他部署の日付（研修 10/19、受付 11/2）を、ゴールの順番を決める根拠に使う

転用できるテンプレート

コピー診断: スプリント | 稼働日 | 計画pt | 完了pt | 完了pt/稼働日 | 最終日の進行中（うち○○待ち）
予測: 1日あたり完了pt × 稼働日 × 在席率 → 下限〜上限
ゴール: [何が] [どこまで] できる状態にする（1文）
バックログ: 順 | ID | pt | 区分（ゴール/余力枠/入れない） | 理由
検算: 詰まりやすい役割の 見積もり×実績比 ／ 作業可能時間
ルール: 同時進行の上限・上限に達したときの動き・完成の定義
見直し: 何日目 | 見るもの | こうなっていたら | 対応

➡️ 次のステップ

• Sprint 19 のレトロで、ゴール達成の有無・最終日の進行中件数・平均サイクルタイムを今回の数字（進行中5件前後・11.8日）と比べる（テーマ3-3 レトロの題材）
• バーンアップチャート（テーマ3-2）で「ゴールの18pt」と「余力枠込みの26pt」の2本の線を引くと、6日目の見直し判断にそのまま使える
• 自分への問い: 10/5 時点で割り込みが既に40h、G3 がまだ実装中だったら、何を PO に提案するか。ゴールの文をどこまで削ってよいか

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

• 在席率はエンジニアの休暇だけで補正し、QA の研修は QA の時間の検算に入れた。デザイナーはバックログに作業が無い前提で除外
• 割り込み予約47h は過去4回の1日あたり中央値から出した。割り込みそのものを減らす方法（当番制・CS への一次対応移管など）は扱っていない
• WIP 上限3件でサイクルタイム約5.7日は、完了ペースが変わらないという仮定つき。切り替えが減って上がることも、ペア作業で下がることもある。2スプリント試して実測で確かめる
• G6 の具体的な分割案は、PdM-要求のユーザーストーリー分割（テーマ4-2）の題材として残した
• 「実測」ラベルの数値はすべて演習シナリオ上の設定値で、実在企業のデータではない。外部の一次資料はスクラムガイド2020・Scrum Inc.・Mountain Goat Software・Little（1961）の4点
• Sprint 20 は予測量とリリースの見通しだけで、計画の中身は作っていない

🎯 自己評価

自分の回答

所要時間・気づき・メモ