🎬 シナリオ
MOps（Marketing Ops/販促システム）チームは「配送遅延時に自己解決できる問い合わせチャットボット」機能を開発中で、2週間スプリントでアジャイル開発を回っている。これまでエンジニア3名体制だったが、今週から中途入社のジュニアエンジニア1名が新たにチームに加わり、4名体制になった。あなたはこのチームのエンジニアで、新体制で迎える最初のスプリント（Sprint 13）のプランニングMTGのファシリテーションを任された。
直近3スプリント（3名体制時）の実績ベロシティは以下の通り。
| スプリント | 完了ポイント | 備考 |
|---|---|---|
| Sprint 10 | 24pt | 特記事項なし |
| Sprint 11 | 30pt | 特記事項なし |
| Sprint 12 | 15pt | メンバー1名がインフルエンザで4日間不在 |
プロダクトオーナーからは、次スプリントの候補として以下のバックログアイテムが提示されている（見積もりは既にプランニングポーカーで完了済み）。
| ID | アイテム内容 | 見積もり | 優先度（PO指定） |
|---|---|---|---|
| S1 | 配送業者API連携タイムアウト時のリトライ処理（先スプリントからの繰越。外部ベンダー側の仕様確認待ちで最終日にブロックされた） | 5pt | 最優先（繰越） |
| S2 | 配送遅延理由の自動判定ロジック（配送状況APIと連携） | 13pt | 高 |
| S3 | 誤った追跡番号を表示する本番バグの修正（CSに週5件クレーム発生中） | 2pt | 緊急 |
| S4 | マイページからのチャットボット起動導線追加 | 5pt | 中 |
| S5 | チャットボット応答のログ基盤整備（技術負債・PO未評価、エンジニア提案） | 8pt | エンジニア提案 |
| S6 | 新メンバー向け開発環境構築・コードベース理解タスク | 3pt | 必須（体制維持のため） |
| S7 | チャット履歴画面のUIリニューアル（デザイン部門要望） | 5pt | 低 |
| S8 | 配送遅延理由自動判定ロジックの管理画面（S2に依存） | 5pt | 高 |
さらに、次スプリント中に以下の事情があることが分かっている。
- 新メンバーのオンボーディングのため、エンジニア1名がスプリント中の稼働時間の約20%程度をメンタリングに充てる見込み
- スプリント中日に全社セキュリティ研修（半日、全員参加必須）がある
📝 課題
あなたのタスク: 次スプリント（Sprint 13）のプランニング資料を作成してください。以下を含めること。
- 次スプリントの目標ベロシティを、直近3スプリントの実績と今回特有の事情（新メンバー加入・メンタリング負荷・全社研修）を踏まえて算出し、その根拠を示す
- バックログアイテムのうち、目標ベロシティの範囲内で積み込むタスクの一覧を優先度に沿って決定する（依存関係がある項目、新メンバー向けタスクの扱いにも触れる）
- 積み込まなかった項目について、なぜ見送ったかを一言ずつ添える
🔍 ヒント（段階的開示）
取り組む前のヒント
- ベロシティは単純平均だけで決めない。異常値（インフル欠勤などの特殊要因があったスプリント）をどう扱うかを明示する
- 新メンバーの加入を「頭数が増えた分、単純にキャパシティが純増する」と捉えない。新メンバー自身の最初のスプリントの生産量はオンボーディングタスクにほぼ吸収されること、既存メンバーのメンタリング時間はその分ほかのタスクに使えなくなることの両方を考慮する
- 繰越タスク（S1）は必ず最優先で積む
- 緊急バグ（S3）のように、POの優先度指定にかかわらず事業影響が大きいものは優先して積む判断が必要になる場合がある
- 依存関係のあるタスク（S8はS2に依存）は、依存元が完了予定でも、容量の限界であれば見送ってよい
- 新体制・見積もりの不確実性が高い場面では、目標ベロシティを使い切らずに、あえて余白（バッファ）を残す判断もありうる
📚 背景知識・用語解説
ベロシティ（Velocity）とは、スクラムチームが1スプリントあたりに完了できるストーリーポイントの実績値のことです。過去の実績をそのまま次回の目標にするのではなく、次スプリント特有の事情を加味して補正するのが基本的な考え方です。
チーム編成が変わるときのベロシティの考え方は特に注意が必要です。メンバーが増えると直感的には「キャパシティが増える」と考えがちですが、新メンバーの最初のスプリントには次の2つのマイナス要因が同時に発生します。
- 新メンバー自身の立ち上がりコスト: 最初のスプリントは、開発環境構築やコードベースの理解に時間の大半を使うため、通常の生産性を出せません。むしろ「オンボーディングタスクそのもの」を1つのバックログアイテムとして明示的に積むほうが実態に近くなります。
- 既存メンバーのメンタリング負荷: 新メンバーの質問対応やレビューに時間を割く分、既存メンバーが通常こなせるはずだった作業量が目減りします。
不確実性が高いときのバッファの考え方も重要です。通常のスプリント計画では目標ベロシティにできるだけ近づけて積み込みますが、今回のように「新体制での初回」「見積もり前提が変わりやすい」場面では、目標ベロシティを使い切らずに数ポイントの余白を意図的に残す判断も選択肢になります。バッファを残すことで、メンタリングが想定以上にかかった場合や、新メンバーのオンボーディングが計画より長引いた場合にも、チーム全体の計画が破綻しにくくなります。
✅ 模範解答
目標ベロシティの算出
| 項目 | 値 | 備考 |
|---|---|---|
| Sprint 10 実績 | 24pt | 特記事項なし |
| Sprint 11 実績 | 30pt | 特記事項なし |
| Sprint 12 実績 | 15pt | インフル欠勤による異常値として扱う |
| ベース平均（Sprint 12除く、3名体制） | 27pt | (24+30)/2。異常値を除外した既存3名分の平均 |
今回特有の事情による補正
| 事情 | 影響 | 補正 |
|---|---|---|
| 新メンバー1名加入 | 最初のスプリントの生産量はオンボーディングタスク（S6, 3pt）にほぼ吸収される。純粋な追加キャパシティとしては見込まない | 別枠として+3pt（通常バックログ容量には加算しない） |
| 既存メンバー1名がメンタリングに稼働の約20%を充当 | 1人あたり平均生産量 27pt÷3名=9pt のうち約20%（約2pt）が新メンバー対応に使われる | ベース平均から−2pt |
| 全社セキュリティ研修（半日・全員参加、10営業日換算） | 4名×0.5日÷（4名×10日）=2.5%相当の稼働減 | ベース平均から−1pt（端数切り上げ） |
新メンバー向け別枠（S6専用） = 3pt
合計の目標ベロシティ = 27pt
積み込みタスク一覧（Sprint 13）
| 順位 | ID | アイテム内容 | ポイント | 積算（通常枠24pt中） | 積み込み判断 |
|---|---|---|---|---|---|
| 1 | S1 | 配送業者API連携リトライ処理（繰越） | 5pt | 5pt | 繰越タスクとして最優先で確保 |
| 2 | S3 | 誤追跡番号表示バグの修正 | 2pt | 7pt | POの優先度は「緊急」表記。CSに週5件クレームが発生している実害を優先し、ポイントの小ささにかかわらず先に積む |
| 3 | S2 | 配送遅延理由の自動判定ロジック | 13pt | 20pt | POの優先度「高」。S8の依存元でもあり、S8を積む場合はS2の完了が前提になる |
| — | — | 通常枠の残り | — | 残り4pt | S4（5pt）は残り枠に収まらないため積まない。ここで意図的にバッファとして残す |
| 別枠 | S6 | 新メンバー向け環境構築・コードベース理解タスク | 3pt | 別枠3pt | 新メンバー専任タスク。通常枠とは別に確保し、通常枠の積算には含めない |
依存関係の扱い: S8（自動判定ロジックの管理画面、5pt）はS2に依存しているが、S2完了後でも通常枠の残り4ptには収まらないため、今回は積み込まない。S2自体は完了予定のため、依存関係上はS8を次スプリント冒頭から着手できる状態になる。
見送った項目とその理由
| ID | アイテム内容 | ポイント | 見送り理由 |
|---|---|---|---|
| S8 | 自動判定ロジックの管理画面 | 5pt | 依存元S2は今回完了予定だが、通常枠の残り4ptに収まらない。S2完了後、次スプリント冒頭から着手できるようPOと合意する |
| S4 | チャットボット起動導線追加 | 5pt | POの優先度「中」。通常枠の残り4ptにわずかに収まらず、新体制初回スプリントのバッファを優先したため見送り |
| S5 | ログ基盤整備（技術負債） | 8pt | エンジニア提案でPO未評価。新体制の立ち上げを優先するため見送るが、無期限の先送りにはせず、次々回以降のスプリントで固定の技術負債対応枠を設けることをチームに提案する |
| S7 | チャット履歴画面のUIリニューアル | 5pt | POの優先度「低」。事業影響も軽微なため、新体制で不確実性が高い今回は真っ先に外す対象 |
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| メンバー増加分をそのまま目標ベロシティに加算する | 新メンバーの立ち上がりコストとメンタリング負荷を無視すると、初回スプリントから過剰な積み込みになる | 新メンバーの生産量は別枠のオンボーディングタスクとして扱い、既存メンバーのメンタリング負荷は既存キャパシティから差し引く |
| 異常値の混ざった実績をそのまま平均する | インフル欠勤などの特殊要因を含めた平均は、新体制の実態を反映しない | 異常値を要因ごとに切り分け、ベースの平均から除外する |
| 目標ベロシティに達するまで機械的に埋め尽くす | 不確実性が高い状況でも余白なく積むと、少しの想定外で即座に未達になる | 見積もり前提が崩れやすい状況（体制変更直後など）では、意図的にバッファを残す判断を選択肢に持つ |
| 依存関係のあるタスクの依存先を、容量オーバーを承知で無理に積む | 依存元の完了が遅れた場合に依存先も共倒れでブロックされ、未達リスクが二重に積み上がる | 容量に収まらない依存タスクは見送り、依存元の完了確認後に次スプリントで着手する計画にする |
| 技術負債を「今回は見送り」で終わらせる | POが優先度評価をしないまま放置され続け、いつまでも積まれない | 見送る際は次回以降の対応枠（固定スロットやPOへの評価依頼）をセットで合意する |
🏆 実務での使いどころ
チーム編成が変わる直後のスプリント計画は、エンジニアがPM/PdM的な判断力を最も試される場面の1つです。「人が増えたから多く積める」という直感的な思い込みを避け、立ち上がりコストとメンタリング負荷を定量的に補正する姿勢は、将来テックリードやEMとしてチームを編成・運営する際に直接活きます。また、不確実性が高い状況で意図的にバッファを残すという判断は、「目標を達成できるかどうか」だけでなく「チームが持続的に成果を出し続けられるか」を考える視点につながります。この判断をエンジニアリードやPOに説明できる形で残しておくことは、未達が発生した際にチームを守る材料にもなります。
🚀 次のステップ
今回は新体制でのベロシティ補正とバッファの持たせ方を扱いましたが、次のPM-推進のテーマ（3-2 進捗可視化）では、このSprint 13が実際に進行した想定でバーンダウンチャートを作成し、「バッファ4ptがどう使われたか」「新メンバーのオンボーディングが計画通りだったか」を可視化する練習に進みます。今回見送ったS8（S2への依存タスク）が次スプリントでスムーズに着手できたかどうかも、振り返りの材料にしておくと次回の演習がスムーズになります。