🎬 シナリオ
MOps（Marketing Ops/販促システム）チームは「商品レビューのなりすまし投稿対策」機能を開発中で、2週間スプリントでアジャイル開発を回っている。最近、同一人物が複数アカウントを使い分けて自社商品に高評価レビューを大量投稿する事例がCS部門から報告され、対策機能の開発が始まった。体制はバックエンドエンジニア2名・フロントエンドエンジニア1名・QA1名の計4名。あなたはこのチームのエンジニアで、次スプリント（Sprint 15）のプランニングMTGのファシリテーションを任された。
直近3スプリントの実績ベロシティ（完了したストーリーポイントの合計）は以下の通り。
| スプリント | 完了ポイント | 備考 |
|---|---|---|
| Sprint 12 | 28pt | 特記事項なし |
| Sprint 13 | 25pt | 特記事項なし |
| Sprint 14 | 11pt | バックエンドエンジニア1名が、決済基盤チームの障害復旧ヘルプに3日間出向 |
プロダクトオーナーからは、次スプリントの候補として以下のバックログアイテムが提示されている（見積もりは既にプランニングポーカーで完了済み）。
| ID | アイテム内容 | 見積もり | 優先度（PO指定） |
|---|---|---|---|
| R1 | 不正投稿判定ロジックのしきい値調整（前スプリントからの繰越。QA環境のテストデータ不足で検証が完了できなかった） | 3pt | 最優先（繰越） |
| R2 | レビュー投稿時の端末フィンガープリント収集実装（今回プロジェクトのメイン機能） | 13pt | 高 |
| R3 | 同一IPから短時間に大量投稿があるとレビュー一覧の表示が崩れる本番バグの修正（CS部門に週6件問い合わせ発生中） | 3pt | 緊急 |
| R4 | 不正判定履歴の管理画面表示（R2のフィンガープリント収集完了が前提） | 8pt | 高 |
| R5 | レビュー投稿フォームのUIリニューアル（デザイン部門からの要望。緊急性は低い） | 5pt | 低 |
📝 課題
あなたのタスク: 上記の情報をもとに、Sprint 15のスプリントプランニング資料を作成してください。ベロシティの算出根拠、積み込むアイテムとその理由、積み込まないアイテムとその理由を明記すること。
🔍 ヒント（段階的開示）
取り組む前のヒント
- 3スプリントの単純平均をそのまま使ってよいか考える。Sprint 14の11ptは体制減による一時的な異常値であり、そのまま平均に含めると次スプリントの見積もりが過小になりかねない
- 「優先度」欄の高低だけで積み込み順を決めない。繰越（前提が崩れると完了できない）・緊急（対応しないと実害が続く）・依存（前提タスクが終わらないと着手できない）という性質の違いを見る
- 依存関係のあるタスク（R4）を、前提タスク（R2）と同じスプリントに無条件で入れてよいか検討する
- 積み込み量とベロシティの間に意図的な余白（バッファ）を残すか、残すならどのくらいかを言語化する
📚 背景知識・用語解説
ベロシティ（Velocity）とは、1スプリントあたりにチームが完了できるストーリーポイントの実績値です。次スプリントの積み込み量を決める根拠になりますが、過去の数値をそのまま平均すると「体制減」「障害対応」などの一時的な異常値に引っ張られます。異常値が含まれるスプリントは、注記を見た上で「参考値として扱う」か「除外して算出する」かを判断する必要があります。
繰越タスク（Carryover）とは、前スプリントで完了できなかったタスクです。多くの場合、完了できなかった理由（外部要因かチーム内要因か）によって、次スプリントでの扱いが変わります。理由が解消されていない繰越タスクは、同じ理由で再び完了できない可能性を疑うべきです。
コミットメントとバッファ: スプリントの積み込み量をベロシティの100%ぴったりに合わせると、少しの見積もり誤差や割り込みで即座に未達になります。意図的な余白（バッファ）を残すことで、チームの持続可能なペース（Sustainable Pace）を守ります。
✅ 模範解答
ベロシティの算出根拠
| 項目 | 値 | 算出方法 |
|---|---|---|
| Sprint 12実績 | 28pt | 特記事項なし。参考値として採用 |
| Sprint 13実績 | 25pt | 特記事項なし。参考値として採用 |
| Sprint 14実績 | 11pt | バックエンド1名が3日間他チーム出向。体制減による異常値のため単純平均から除外 |
| ベース平均（Sprint 12・13の平均） | 26pt | (28+25)/2=26.5pt→端数切り捨て |
| 参考: Sprint 14を含めた3スプリント単純平均 | 21.3pt | 除外しない場合との比較用に併記 |
積み込み判断
| ID | 内容 | 見積もり | 積み込み区分 | 判断理由 |
|---|---|---|---|---|
| R1 | しきい値調整（繰越） | 3pt | 確定コミット | 繰越理由（テストデータ不足）はQA環境の整備待ちであり、チーム側で解消可能。最優先で完了させる |
| R3 | 表示崩れバグ修正（緊急） | 3pt | 確定コミット | CSに週6件の問い合わせが発生し続けており、放置コストが積み込みコストを上回る。優先度表記は「緊急」のみだが実質最優先扱い |
| R2 | フィンガープリント収集（メイン機能） | 13pt | 確定コミット | プロジェクトのメイン機能。ただし単体で13ptと大きく、スプリント後半に完了がずれ込むリスクを内包する |
| R4 | 不正判定履歴の管理画面表示 | 8pt | 見送り（次スプリント） | R2の完了が前提。R2自体がスプリント後半完了予定のため、同一スプリントに入れるとR2の遅延がR4の未着手に直結する。前提が崩れるリスクを取らず、次スプリントに明示的に送る |
| R5 | UIリニューアル | 5pt | 見送り | 優先度「低」かつ緊急性なし。デザイン部門には次々スプリント以降での検討を伝える |
バッファ7ptの用途は次の2つに絞って明記した。(1) R2が想定より早く終わった場合はR4に部分着手する、(2) スプリント中に緊急バグが新規発生した場合の受け皿にする。単なる余白ではなく、使い道を決めた余白として扱う。
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 異常値を含めたまま3スプリント平均をそのまま使う | 一時的な体制減が恒常的な実力として扱われ、積み込み量が歪む | 異常値の原因が解消済みかを確認し、除外するか参考値扱いにするかを判断する |
| 「優先度：高」のタスクを機械的に全部積む | 依存関係やリスクを見落とし、前提タスクの遅延が連鎖して両方未達になる | 依存関係を洗い出し、前提タスクの完了確度が低い依存タスクは次スプリントに送る |
| バッファを「念のため」で漠然と残す | スプリント中に割り込みが発生した際、バッファを使ってよいか毎回判断コストが発生する | バッファの用途をプランニングの時点で具体的に決めておく |
🏆 実務での使いどころ
スプリントプランニングはPdM・スクラムマスターだけの仕事ではなく、エンジニアがファシリテーションを担う場面が多くあります。特に「ベロシティの算出根拠」と「積み込まない理由」を明文化しておくと、スプリント終盤に未達が発生した際も「なぜその判断をしたか」を振り返りで説明でき、次のプランニングの精度向上につながります。依存関係の見極めは、実装者であるエンジニア自身が最も正確に判断できる領域でもあり、PdMやスクラムマスターに任せきりにしないことが重要です。
🚀 次のステップ
このSprint 15の積み込み計画をもとに、次はバーンダウンチャート（テーマ3-2 進捗可視化）でスプリント中の進捗を可視化してみましょう。特にR2（13pt・スプリント後半完了予定）の消化ペースが計画通りかどうかを、日次でどう追跡するかを考えてみてください。