🎬 シナリオ
MOps（Marketing Ops/販促システム）チームは「検索キーワードサジェスト機能」（検索窓に入力中のキーワード候補をリアルタイム表示する機能、社内の検索基盤チームが提供するAPIを利用）を開発中で、2週間スプリントでアジャイル開発を回っている。現在はエンジニア5名体制。あなたはこのチームのエンジニアで、次のスプリント（Sprint 23）のプランニングMTGのファシリテーションを任された。
直近3スプリント（5名フル稼働時）の実績ベロシティは以下の通り。
| スプリント | 完了ポイント | 備考 |
|---|---|---|
| Sprint 20 | 38pt | 特記事項なし |
| Sprint 21 | 41pt | 特記事項なし |
| Sprint 22 | 19pt | メンバー1名が家族の事情で急遽1週間不在 |
プロダクトオーナーからは、次スプリントの候補として以下のバックログアイテムが提示されている（見積もりは既にプランニングポーカーで完了済み）。
| ID | アイテム内容 | 見積もり | 優先度（PO指定） |
|---|---|---|---|
| T1 | 検索基盤APIのレスポンス遅延時のタイムアウト・フォールバック処理（先スプリントからの繰越。外部の検索基盤チーム側の仕様確定待ちで最終日にブロックされた） | 8pt | 最優先（繰越） |
| T2 | サジェスト候補のクリック率計測ログ実装 | 13pt | 高 |
| T3 | IME変換中に誤ったサジェスト候補が表示される本番バグの修正（CSに週8件問い合わせ発生中） | 3pt | 緊急 |
| T4 | サジェスト候補の並び順アルゴリズム改善（マーケ部門要望、A/Bテスト設計は完了済み） | 8pt | 中 |
| T5 | サジェスト管理画面（候補の手動除外設定。T2のクリック率ログ基盤に依存） | 5pt | 高 |
| T6 | 技術基盤刷新プロジェクトへの引き継ぎ資料作成・ペアオンボーディング対応（体制上必須） | 3pt | 必須（体制維持のため） |
| T7 | サジェストUIのダークモード対応 | 5pt | 低 |
| T8 | 検索窓プレースホルダーテキストのA/Bテスト実装（エンジニア提案） | 3pt | エンジニア提案 |
さらに、次スプリント中に以下の事情があることが分かっている。
- リードエンジニア1名が、2週間前から決定していた全社的な「検索基盤刷新プロジェクト」への協力のため、次スプリントを含む今後2スプリントの間、稼働の約50%をそちらに割く予定（チームからの離脱ではなく、あくまで一時的な兼務）
- スプリント中日に全社四半期振り返り会（半日、全員参加必須）がある
📝 課題
あなたのタスク: 次スプリント（Sprint 23）のプランニング資料を作成してください。以下を含めること。
- 次スプリントの目標ベロシティを、直近3スプリントの実績と今回特有の事情（リードエンジニアの50%兼務・全社振り返り会）を踏まえて算出し、その根拠を示す
- バックログアイテムのうち、目標ベロシティの範囲内で積み込むタスクの一覧を優先度に沿って決定する（依存関係がある項目、引き継ぎタスクの扱いにも触れる）
- 積み込まなかった項目について、なぜ見送ったかを一言ずつ添える
🔍 ヒント（段階的開示）
取り組む前のヒント
- ベロシティは単純平均だけで決めない。異常値（家族の事情による欠員などの特殊要因があったスプリント）をどう扱うかを明示する
- 「50%兼務」は「メンバーが1人減る」のとは異なる。頭数は変わらないが、そのメンバーの生産量が単純に半分になる、という形で補正する
- 繰越タスク（T1）は必ず最優先で積む
- 緊急バグ（T3）のように、POの優先度指定にかかわらず事業影響が大きいものは優先して積む判断が必要になる場合がある
- 依存関係のあるタスク（T5はT2に依存）は、依存元を先に積めるかどうかで扱いが変わる
- 兼務による見積もりの不確実性が高い場面では、目標ベロシティを使い切らずに、あえて余白（バッファ）を残す判断もありうる
- 前回（Day013）は「新メンバー加入」による立ち上がりコストのパターンだったが、今回は「既存メンバーの一時的な稼働配分変更」であり、補正の考え方が異なる点に注意する
📚 背景知識・用語解説
ベロシティ（Velocity）とは、スクラムチームが1スプリントあたりに完了できるストーリーポイントの実績値のことです。過去の実績をそのまま次回の目標にするのではなく、次スプリント特有の事情を加味して補正するのが基本的な考え方です。
チームメンバーが一時的に兼務するときのベロシティの考え方は、「新メンバーが加わるとき」とは異なる補正が必要です。
- 新メンバー加入の場合は、頭数は増えても「立ち上がりコスト」と「既存メンバーのメンタリング負荷」という2つのマイナス要因が同時に発生し、実質的な純増はほぼ見込めません。
- 一方、既存メンバーの一時的な兼務（今回のように稼働の50%を他プロジェクトに割く場合）は、そのメンバー自身の生産性が落ちるわけではなく、単純にチームに使える時間が半分になるという比較的シンプルな引き算で補正できます。ただし、そのメンバーがリードエンジニアのように設計判断やレビューの中核を担っている場合、時間の減少以上にチーム全体の意思決定速度が落ちるリスクがある点は見積もりに現れにくいため、プランニングの場で言葉にして共有しておく必要があります。
不確実性が高いときのバッファの考え方も重要です。兼務の影響がどの程度チームの意思決定速度に及ぶかは、実際にスプリントが始まってみないと分からない部分があります。このような場面では、目標ベロシティを使い切らずに数ポイントの余白を意図的に残す判断も選択肢になります。
✅ 模範解答
目標ベロシティの算出
| 項目 | 値 | 備考 |
|---|---|---|
| Sprint 20 実績 | 38pt | 特記事項なし |
| Sprint 21 実績 | 41pt | 特記事項なし |
| Sprint 22 実績 | 19pt | 家族の事情による欠員という異常値として扱う |
| ベース平均（Sprint 22除く、5名フル稼働時） | 40pt | (38+41)/2=39.5pt→端数切り上げ |
今回特有の事情による補正
| 事情 | 影響 | 補正 |
|---|---|---|
| リードエンジニア1名が稼働の50%を兼務に割く | 1人あたり平均生産量 40pt÷5名=8pt のうち50%（4pt）が兼務先に割かれる | ベース平均から−4pt |
| 全社四半期振り返り会（半日・全員参加、10営業日換算） | 5名×0.5日÷（5名×10日）=5%相当の稼働減。40pt×5%=2pt | ベース平均から−2pt |
新メンバー加入のケース（Day013）とは異なり、今回は「別枠」を作らず、引き継ぎタスク（T6）も含めて単一の目標ベロシティ34ptの中で優先順位を判断する。T6が新メンバーの立ち上がりのような繰り返し発生するコストではなく、今回のスプリント限りの単発タスクであるため。
積み込みタスク一覧（Sprint 23）
| 順位 | ID | アイテム内容 | ポイント | 累計（目標34pt中） | 積み込み判断 |
|---|---|---|---|---|---|
| 1 | T1 | 検索基盤APIタイムアウト・フォールバック処理（繰越） | 8pt | 8pt | 繰越タスクとして最優先で確保 |
| 2 | T3 | IME変換中の誤サジェスト表示バグ修正 | 3pt | 11pt | POの優先度は「緊急」表記。CSに週8件問い合わせが発生している実害を優先し、ポイントの小ささにかかわらず先に積む |
| 3 | T6 | 技術基盤刷新PJへの引き継ぎ資料作成・ペアオンボーディング | 3pt | 14pt | 体制維持のための必須タスク。兼務初回のこのタイミングで対応しないと、後続スプリントで差し込みタスクとして割り込み、計画をさらに崩す |
| 4 | T2 | サジェスト候補のクリック率計測ログ実装 | 13pt | 27pt | POの優先度「高」。T5の依存元でもあり、T5を積む場合はT2の完了が前提になる |
| 5 | T5 | サジェスト管理画面（候補の手動除外設定） | 5pt | 32pt | POの優先度「高」。T2が今回完了予定で、残り容量7ptに収まるため積み込み可能 |
| — | — | 残り | — | 残り2pt | T4（8pt）・T8（3pt）はいずれも収まらないため積まない。ここで意図的にバッファとして残す |
依存関係の扱い: T5（サジェスト管理画面、5pt）はT2（クリック率計測ログ実装）に依存しているが、T2はこのスプリント内で完了予定であり、かつT2完了後の残り容量（34−27=7pt）にT5（5pt）が収まるため、今回は積み込む判断とした。仮にT2の完了が見込めない、または残り容量が5pt未満だった場合はT5を見送るべきだった点は、プランニングMTGの場で明示しておく。
見送った項目とその理由
| ID | アイテム内容 | ポイント | 見送り理由 |
|---|---|---|---|
| T4 | サジェスト候補の並び順アルゴリズム改善 | 8pt | POの優先度「中」。A/Bテスト設計は完了済みで着手自体は可能だが、残り2ptには収まらない。兼務初回であるこのスプリントはバッファを優先し、次スプリント冒頭での着手をPOと合意する |
| T7 | サジェストUIのダークモード対応 | 5pt | POの優先度「低」。事業影響も軽微なため、兼務初回で不確実性が高い今回は真っ先に外す対象 |
| T8 | 検索窓プレースホルダーテキストのA/Bテスト実装 | 3pt | エンジニア提案でPO未評価。優先度の高い項目を優先したため見送るが、小粒で着手しやすいため次スプリントの「隙間タスク」候補として残しておく |
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 兼務による稼働減を「頭数が変わらないから」という理由で見積もりに反映しない | 実際には稼働時間が半減しているため、これまで通りのベロシティを目標にすると初回から未達になる | 兼務率をそのまま稼働時間の減少率として控除する |
| 「新メンバー加入」と「既存メンバーの兼務」を同じ補正ロジックで扱う | 兼務は立ち上がりコストやメンタリング負荷が発生しないため、別枠管理をすると過剰に複雑な資料になる | 体制変化の性質（増員か、兼務か）を見極めたうえで、適した補正方法を選ぶ |
| 異常値の混ざった実績をそのまま平均する | 家族の事情による欠員などの特殊要因を含めた平均は、次スプリントの実態を反映しない | 異常値を要因ごとに切り分け、ベースの平均から除外する |
| 依存関係のあるタスクを「依存があるから」と機械的に一律で見送る | 依存元が完了見込みで容量にも余裕がある場合まで見送ると、着手できるはずの価値を先送りしてしまう | 依存元の完了見込みと残り容量の両方を確認したうえで、積むか見送るかを個別に判断する |
| 目標ベロシティに達するまで機械的に埋め尽くす | 不確実性が高い状況でも余白なく積むと、少しの想定外で即座に未達になる | 見積もり前提が崩れやすい状況（体制変更直後など）では、意図的にバッファを残す判断を選択肢に持つ |
🏆 実務での使いどころ
チームメンバーの一部が他プロジェクトへ一時的に兼務するという状況は、新メンバー加入と並んでスプリント計画を狂わせやすい典型パターンです。特にリードエンジニアやテックリード格のメンバーが兼務する場合、稼働時間の減少幅以上にチームの意思決定速度が落ちるリスクがあるため、単純な引き算だけでなく「今回は判断待ちが増えるかもしれない」という定性的なリスクも言葉にしてチームで共有しておくことが重要です。この判断力は、将来テックリードやEMとして複数プロジェクトにまたがるメンバーのアサインを調整する際に直接活きます。また、依存関係のあるタスクを一律に見送るのではなく、依存元の完了見込みと残り容量を個別に確認して判断する姿勢は、優先順位付けの精度を高めるうえで欠かせません。
🚀 次のステップ
今回は既存メンバーの一時的な兼務によるベロシティ補正を扱いましたが、次のPM-推進のテーマ（3-2 進捗可視化）では、このSprint 23が実際に進行した想定でバーンダウンチャートを作成し、「バッファ2ptがどう使われたか」「リードエンジニアの兼務が意思決定速度にどの程度影響したか」を可視化する練習に進みます。今回見送ったT4（並び順アルゴリズム改善）が次スプリントでスムーズに着手できたかどうかも、振り返りの材料にしておくと次回の演習がスムーズになります。