🎬 シナリオ
MOps（Marketing Ops/販促システム）チームは2週間スプリントでアジャイル開発を回っている。あなたはこのチームのエンジニアで、次スプリント（Sprint 14）のプランニングMTGのファシリテーションを任された。
チーム構成はエンジニア4名（うち1名は来週から3日間、社内研修で不在）、デザイナー1名（このチームには週2日ジョイン）。
直近3スプリントの実績ベロシティ（完了したストーリーポイントの合計）は以下の通り。
| スプリント | 完了ポイント | 備考 |
|---|---|---|
| Sprint 11 | 34pt | 特記事項なし |
| Sprint 12 | 22pt | メンバー1名が5日間有給取得 |
| Sprint 13 | 31pt | 特記事項なし |
プロダクトオーナーからは、次スプリントの候補として以下のバックログアイテムが提示されている（見積もりは既にプランニングポーカーで完了済み）。
| ID | アイテム内容 | 見積もり | 優先度（POによる指定） |
|---|---|---|---|
| S1 | クーポン発行APIのレート制限対応（先スプリントからの繰越、着手済み） | 5pt | 最優先（繰越） |
| S2 | 会員ランク別クーポン配布バッチの実装 | 13pt | 高 |
| S3 | クーポン利用履歴画面のページネーション改善 | 3pt | 中 |
| S4 | 販促メール配信テンプレートの新規追加（3種） | 8pt | 中 |
| S5 | クーポンコード重複発行バグの修正（本番で週2件発生中） | 2pt | 緊急 |
| S6 | 管理画面の検索フィルタUI改善 | 5pt | 低 |
| S7 | 決済連携APIの障害時リトライ機構（技術負債・PO未評価） | 8pt | エンジニア側からの提案 |
| S8 | 会員ランク別クーポン配布バッチの管理画面（S2に依存） | 5pt | 高 |
さらに、次スプリント中に以下の固定タスクがあることが分かっている。
- 四半期に1度の全社インフラメンテナンス対応で、初日に半日相当の対応が発生する見込み（担当は持ち回りだが、今回はチームから1名アサイン予定）
- スプリント最終日は他チームとの合同レトロスペクティブがあり、通常のレトロより1時間長く確保する必要がある
📝 課題
あなたのタスク: 次スプリント（Sprint 14）のプランニング資料を作成してください。以下を含めること。
- 次スプリントの目標ベロシティを、直近3スプリントの実績と今回特有の制約条件（研修による不在、インフラ対応、合同レトロの延長）を踏まえて算出し、その根拠を示す
- バックログアイテムのうち、目標ベロシティの範囲内で積み込むタスクの一覧を優先度に沿って決定する（依存関係がある項目の扱いにも触れる）
- 積み込まなかった項目について、なぜ見送ったかを一言ずつ添える
🔍 ヒント（段階的開示）
取り組む前のヒント
- ベロシティは単純平均だけで決めない。異常値（有給取得などの特殊要因があったスプリント）をどう扱うかを明示する
- 「今回特有の制約」はチームの実働キャパシティを直接減らす。過去の平均ベロシティに対して、稼働日数の増減比などで補正する考え方を使うと説明しやすい
- 繰越タスク（S1）は必ず最優先で積む。新規タスクより優先して確保する
- 緊急バグ（S5）のように、POの優先度指定が「高」でなくても事業影響が大きいものは、ポイントが小さくても積む判断が必要になる場合がある
- 依存関係のあるタスク（S8はS2に依存）は、依存元が積めない場合は依存先も積めない。逆に依存元だけ積んで依存先を見送る、という判断もありうる
- POが優先度を明示していないエンジニア提案（S7の技術負債対応）は、積むかどうかの判断基準をチームとして持っておくと良い
📚 背景知識・用語解説
ベロシティ（Velocity）とは、スクラムチームが1スプリントあたりに完了できるストーリーポイントの実績値のことです。見積もりの単位（ストーリーポイント）はチーム固有の相対値であり、他チームと比較する指標ではなく、自分のチームの過去実績と比較して次の積み込み量を決めるために使います。
積み込み（プランニング）の基本的な考え方は次の通りです。
- 前スプリントからの繰越タスクを最優先で確保する（新規着手より優先。中途半端な作業を放置すると、仕掛かり在庫が増え続ける）
- 優先度の高い新規タスクを、目標ベロシティに達するまで順に積む
- 依存関係のあるタスクは、依存元・依存先の順序を守って積む（依存先だけ先に積んでも着手できない）
- 優先度が低くても、緊急度の高い障害・バグ対応は例外的に優先する
- 目標ベロシティを超えて欲張らない。プランニングの目的は「多く積む」ことではなく「実現可能な計画をチーム全員が合意して持つ」こと
ベロシティに基づく計画は、達成できなかった場合の学習材料にもなるという点も重要です。積みすぎて未達になった場合、それは「見積もりが甘かった」のか「特有の制約を見落としていた」のかをレトロスペクティブで振り返ることで、次回の見積もり精度が上がっていきます。
✅ 模範解答
目標ベロシティの算出
| 項目 | 値 | 備考 |
|---|---|---|
| Sprint 11 実績 | 34pt | 特記事項なし |
| Sprint 12 実績 | 22pt | メンバー1名が5日間有給。異常値として扱う |
| Sprint 13 実績 | 31pt | 特記事項なし |
| ベース平均（Sprint 12除く） | 32.5pt | (34+31)/2。有給による異常値を除外した平均を基準にする |
今回特有の制約による補正
| 制約 | 影響 | 補正 |
|---|---|---|
| エンジニア1名が3日間研修で不在（チーム4名・スプリント10営業日） | 全体稼働日の約7.5%減（3日÷4名÷10日相当） | 約2.5pt減 |
| インフラメンテナンス対応（初日半日、1名アサイン） | 軽微（0.5日分、研修不在ほどの規模ではない） | 約0.5pt減 |
| 合同レトロの延長（+1時間） | 開発時間への影響は僅少 | 補正なし（誤差の範囲） |
積み込みタスク一覧（Sprint 14）
| 順位 | ID | アイテム内容 | pt | 積算 | 積み込み判断 |
|---|---|---|---|---|---|
| 1 | S1 | クーポン発行APIのレート制限対応（繰越） | 5pt | 5pt | 繰越タスクとして最優先で確保 |
| 2 | S5 | クーポンコード重複発行バグの修正 | 2pt | 7pt | POの優先度は「緊急」表記。本番で週2件発生中の実害があり、ポイントは小さいが優先度指定より前に積む |
| 3 | S2 | 会員ランク別クーポン配布バッチの実装 | 13pt | 20pt | POの優先度「高」。S8の依存元でもあるため、S8を積むならS2を先に確保する必要がある |
| 4 | S4 | 販促メール配信テンプレートの新規追加（3種） | 8pt | 28pt | POの優先度「中」だが、目標ベロシティ29ptの残り枠（29−20=9pt）にちょうど収まる規模 |
見送った項目とその理由
| ID | アイテム内容 | pt | 見送り理由 |
|---|---|---|---|
| S8 | 配布バッチの管理画面 | 5pt | 依存元S2は今回完了予定だが、目標ベロシティの残り枠に収まらなかった。S4（締切が近いと事前ヒアリングで確認済み）を優先したため、次スプリント冒頭で着手する形にPOと合意する |
| S3 | 利用履歴画面のページネーション改善 | 3pt | POの優先度「中」。目標ベロシティに達した後の項目であり、業務影響も軽微なため次回以降に持ち越し |
| S6 | 検索フィルタUI改善 | 5pt | POの優先度「低」。今回のスプリントの制約（研修不在・インフラ対応）を踏まえると優先度の低い項目から真っ先に外すべき対象 |
| S7 | 決済連携APIのリトライ機構（技術負債） | 8pt | エンジニア提案でPO未評価。事業影響の緊急性がS5ほど高くないため、今回は見送り、次回プランニング前にPOへ優先度評価を依頼する（無期限の先送りにはしない） |
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 直近スプリントの平均をそのまま次の目標にする | 異常値（有給・障害対応など）が混ざったままの平均は、次スプリントの実態を反映しない | 異常値を要因ごとに切り分け、今回特有の制約は個別に補正して算出する |
| 繰越タスクを「もう始まっているから」と軽視して積み込み量に含め忘れる | 繰越タスクの分だけ新規タスクを積みすぎてしまい、結果的に未達になる | 繰越タスクは必ず最優先で目標ベロシティの枠に含めて確保する |
| POの優先度ラベルをそのまま順位として使い、実態の緊急度を確認しない | 「緊急」の実害があるバグより、ポイントの大きい「高」優先度タスクを先に積んでしまうことがある | プランニングの場でPOに実際の緊急度・締切を都度確認し、ラベルだけで機械的に順位付けしない |
| 依存関係のあるタスクの依存先だけを先に積んでしまう | 依存元が未完了のまま依存先に着手できず、手戻りやブロッカーが発生する | 依存関係マップをプランニング前に確認し、依存元→依存先の順序を守って積む |
| 目標ベロシティぴったりまで欲張って積む | バッファがなく、ちょっとした割り込みで即座に未達になる | 目標に対して数ポイント程度の余裕を残す、または割り込み発生時の対応方針を事前にチームで合意しておく |
🏆 実務での使いどころ
スプリントプランニングは、エンジニアがPM/PdM的な視点を最も頻繁に発揮できる場です。単に「タスクをこなす」のではなく、「限られたキャパシティの中で、事業影響の大きい順に何を確保するか」を毎回判断する練習になります。特に、POの優先度ラベルを鵜呑みにせず実際の緊急度を確認する姿勢、繰越・依存関係を踏まえた積み込み判断、技術負債を「声を上げるだけで終わらせない」仕組み化は、テックリードやEMを目指す上でも直接活きるスキルです。ベロシティの算出根拠を明文化しておくことは、スプリント未達が発生した際にチーム内で「見積もりが甘かったのか、外部要因だったのか」を冷静に振り返るための土台にもなります。
🚀 次のステップ
今回はベロシティに基づく積み込み判断を扱いましたが、次のPM-推進のテーマ（3-2 進捗可視化）では、このSprint 14が実際に進行した想定でバーンダウンチャートを作成し、「計画通り進んでいるか」「遅れが出ているならどこで巻き返すか」を判断する練習に進みます。今回積み込んだS2（13pt、最大のタスク）が遅延した場合にチームがどう動くべきかを考えておくと、次回の演習がスムーズになります。