🎬 シナリオ
MOps（Marketing Ops/販促システム）チームは「レコメンドバナー配信ロジック刷新」プロジェクトを進行中。ECサイトのトップページ・商品詳細ページに表示されるレコメンドバナーの配信を、外部の広告配信SaaS「AdBoost」のAPIへ切り替える大型案件で、2週間スプリントでアジャイル開発を回っている。現在はフロントエンド2名・バックエンド3名・QA1名の計6名体制。あなたはこのチームのエンジニアで、次のスプリント（Sprint 27）のプランニングMTGのファシリテーションを任された。
直近3スプリントの実績ベロシティは以下の通り。
| スプリント | 完了ポイント | 備考 |
|---|---|---|
| Sprint 24 | 52pt | 特記事項なし |
| Sprint 25 | 55pt | 特記事項なし |
| Sprint 26 | 24pt | 決済リンク機能の本番障害が発生し、原因調査・復旧対応にチーム総出で3日間を費やした |
プロダクトオーナーからは、次スプリントの候補として以下のバックログアイテムが提示されている（T5を除き、見積もりはプランニングポーカーで完了済み）。
| ID | アイテム内容 | 見積もり | 優先度（PO指定） |
|---|---|---|---|
| T1 | バナー表示速度モニタリング実装（前スプリントからの繰越。AdBoost側の障害でテスト環境が一時利用不可になり完了できなかった） | 5pt | 最優先（繰越） |
| T2 | レコメンドバナー配信ロジックのAdBoost API接続（今回プロジェクトのメイン機能） | 21pt | 高 |
| T3 | 既存バナー画像URLのクロスサイトスクリプティング（XSS）脆弱性パッチ（外部セキュリティ診断で指摘済み。法務部門から是正期限が設定されている） | 5pt | 緊急 |
| T4 | バナークリック率のダッシュボード集計（T2のAPI接続完了が前提） | 8pt | 高 |
| T5 | AdBoost従量課金モデル移行に伴う実装方針の検討（先週判明した料金体系変更。影響範囲が未見積もり） | 未見積もり（スパイク扱い） | 高 |
| T6 | バナー表示のA/Bテスト用フラグ実装（マーケ部門要望） | 8pt | 中 |
| T7 | バナー管理画面のUI微修正 | 5pt | 低 |
| T8 | バナー配信ログのフォーマット統一（エンジニア提案） | 3pt | エンジニア提案 |
さらに、次スプリント中に以下の事情があることが分かっている。
- フロントエンドエンジニアのAさんが、以前から承認済みの有給休暇（家族旅行）を3日間取得予定
- バックエンドエンジニアのBさんが、通院のため事前承認済みの有給休暇を2日間取得予定
- T5（AdBoost従量課金モデル対応の検討）は、そのままでは実装工数を見積もれない状態。バックエンドエンジニアのCさんが2日間のタイムボックスで調査し、影響範囲と対応方針を明らかにする「スパイク」として扱う必要がある
📝 課題
あなたのタスク: 次スプリント（Sprint 27）のプランニング資料を作成してください。以下を含めること。
- 次スプリントの目標ベロシティを、直近3スプリントの実績と今回特有の事情（2名の有給休暇・スパイクタスクの扱い）を踏まえて算出し、その根拠を示す
- バックログアイテムのうち、目標ベロシティの範囲内で積み込むタスクの一覧を優先度に沿って決定する（依存関係がある項目、見積もり不能なスパイクタスクの扱いにも触れる）
- 積み込まなかった項目について、なぜ見送ったかを一言ずつ添える
- スパイク（T5）の結果次第で計画が変わりうる項目がある場合、それを確定コミットと条件付き（ストレッチ）コミットに分けて明示する
🔍 ヒント（段階的開示）
取り組む前のヒント
- ベロシティは単純平均だけで決めない。異常値（本番障害対応などの特殊要因があったスプリント）をどう扱うかを明示する
- 事前承認済みの有給休暇は、緊急の欠員とは性質が異なるが、「使える人日が減る」という点では同じように控除の対象になる。日数ベースで機械的に計算する
- 見積もり不能なタスク（スパイク）は、無理にポイントを付けてバックログに混ぜない。タイムボックスとして別枠でキャパシティを確保する
- 繰越タスク（T1）は必ず最優先で積む
- 緊急パッチ（T3）のように外部からの是正期限がある項目は、POの優先度ラベルだけでなく期限そのものを根拠に優先順位を判断する
- 依存関係のあるタスク（T4はT2に依存）は、依存元を今回のスプリント内で完了できる見込みかどうかで扱いが変わる
- スパイクの結果によって後続の計画に影響が出る可能性がある場合、コミットする項目を「確定」と「条件付き」に分けて説明できるようにしておく
- 前回（Day020）は「既存メンバーの一時的な兼務（稼働率50%）」による稼働減の補正だったが、今回は「事前承認済みの有給休暇（日数ベース）」＋「見積もり不能なスパイクタスクの扱い」という異なる論点が中心になる
📚 背景知識・用語解説
ベロシティ（Velocity）とは、スクラムチームが1スプリントあたりに完了できるストーリーポイントの実績値のことです。過去の実績をそのまま次回の目標にするのではなく、次スプリント特有の事情を加味して補正するのが基本的な考え方です。
事前承認済みの有給休暇の扱いは、緊急の欠員とは性質が異なります。緊急の欠員は「予期していなかった稼働減」ですが、事前承認済みの休暇は計画時点で既に分かっている情報です。とはいえ、ベロシティへの影響という観点では「そのメンバーが使える人日が減る」という点で同じであり、日数ベースで機械的に控除して目標ベロシティに織り込むのが基本です。前回（Day020）の「稼働の50%を兼務に割く」ケースは"率"で補正しましたが、今回のように休暇日数が明確な場合は"日数"で直接計算するほうが精度が高くなります。
確定コミットと条件付き（ストレッチ）コミットの分離も重要な考え方です。スパイクの結果次第で、後続タスクの見積もりが変わったり、優先順位が入れ替わったりする可能性がある場合、すべての積み込み項目を同じ確度で「必ずやります」と約束してしまうと、スパイクが想定より時間を要したときに「未達」という扱いになり、チームの心理的安全性を損ないます。あらかじめ「これは確定」「これはスパイクの結果次第で見送る可能性がある」と分けて合意しておくことで、後からの下方修正を計画の一部として扱えるようになります。
✅ 模範解答
目標ベロシティの算出
| 項目 | 値 | 備考 |
|---|---|---|
| Sprint 24 実績 | 52pt | 特記事項なし |
| Sprint 25 実績 | 55pt | 特記事項なし |
| Sprint 26 実績 | 24pt | 決済リンク機能の本番障害対応という異常値として扱う |
| ベース平均（Sprint 26除く） | 54pt | (52+55)/2=53.5pt→端数切り上げ |
今回特有の事情による補正
| 事情 | 影響 | 補正 |
|---|---|---|
| Aさん（フロントエンド）の有給休暇3日間 | 1人あたり平均生産量54pt÷6名=9ptに対し、10営業日中3日分（3/10×9pt=2.7pt）が不在 | 合計2.7+1.8=4.5pt→端数切り上げで−5pt |
| Bさん（バックエンド）の有給休暇2日間 | 1人あたり平均生産量9ptに対し、10営業日中2日分（2/10×9pt=1.8pt）が不在 | |
| T5スパイク（Cさんが2日間専任で調査） | 10営業日中2日分（2/10×9pt=1.8pt）のキャパシティを、ポイント化せずに別枠で予約 | 端数切り上げで−2pt |
T5は上記の2ptの中で「タイムボックス予約」として扱い、通常のバックログポイントには含めない。見積もり不能なタスクを無理にポイント化すると、達成率の解釈自体が歪んでしまうため。
積み込みタスク一覧（Sprint 27）
| 順位 | ID | アイテム内容 | ポイント | 累計（目標47pt中） | コミット区分 | 積み込み判断 |
|---|---|---|---|---|---|---|
| 1 | T1 | バナー表示速度モニタリング実装（繰越） | 5pt | 5pt | 確定 | 繰越タスクとして最優先で確保 |
| 2 | T3 | バナー画像URLのXSS脆弱性パッチ | 5pt | 10pt | 確定 | 法務部門からの是正期限という外部制約があるため、優先度ラベル「緊急」に加え期限そのものを根拠に最優先級で積む |
| 3 | T2 | レコメンドバナー配信ロジックのAdBoost API接続 | 21pt | 31pt | 確定 | POの優先度「高」かつ今回プロジェクトのメイン機能。T4の依存元でもある |
| 4 | T4 | バナークリック率のダッシュボード集計 | 8pt | 39pt | 確定 | T2が今回完了予定のため、依存関係上は積み込み可能。残り容量8ptに収まる |
| 5 | T6 | バナー表示のA/Bテスト用フラグ実装（マーケ部門要望） | 8pt | 47pt | 条件付き（ストレッチ） | 残り容量ちょうど8ptに収まるが、T5スパイクが延びCさんの稼働が圧迫された場合は最初に見送る対象として明示 |
| — | — | 別枠予約（T5スパイク・タイムボックス2日） | （2pt相当） | — | 別枠 | 結果は目標ベロシティには加算しない |
バッファをあえて残さなかった理由は、有給休暇2件が「日数」という確定情報で控除できており不確実性が低いこと、かつT5の不確実性についてはT6を条件付きコミットにすることで実質的な調整弁として機能させているためである。
依存関係の扱い: T4（ダッシュボード集計、8pt）はT2（AdBoost API接続）に依存しているが、T2はこのスプリント内で完了予定であり、かつT2完了後の残り容量（47−31=16pt）にT4（8pt）が収まるため、今回は積み込む判断とした。
見送った項目とその理由
| ID | アイテム内容 | ポイント | 見送り理由 |
|---|---|---|---|
| T7 | バナー管理画面のUI微修正 | 5pt | POの優先度「低」。事業影響も軽微なため、確定コミット39pt＋条件付き8ptで容量を使い切った今回は見送る |
| T8 | バナー配信ログのフォーマット統一 | 3pt | エンジニア提案でPO未評価。優先度の高い項目・条件付きコミットを優先したため見送るが、小粒で着手しやすいため次スプリントの「隙間タスク」候補として残しておく |
💡 なぜこう作るのか
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 事前承認済みの有給休暇を「もともと決まっていたことだから」と見積もりに反映しない | 実際には稼働人日が減っているため、これまで通りのベロシティを目標にすると初回から未達になる | 休暇日数をそのまま人日ベースで目標ベロシティから控除する |
| 見積もり不能なスパイクタスクに無理やりポイントを付けてバックログに混ぜる | 実態と乖離した見積もりが積み上がり、そのスプリントの達成率や次回以降のベロシティの解釈を誤らせる | タイムボックスで別枠管理し、通常のポイント集計の外に出す |
| 優先度ラベルだけで機械的に順序を決め、外部の期限制約（法務・コンプライアンス）を見落とす | 期限を過ぎた場合の事業上・法務上のリスクが計画に反映されない | 優先度ラベルに加えて、外部期限の有無を必ず確認し、期限を根拠として明示する |
| スパイクの結果次第で変動する項目を、他の項目と同じ「確定コミット」として扱う | スパイクが長引いた場合にその項目が一律「未達」扱いとなり、チームの心理的安全性を損なう | 確定コミットと条件付き（ストレッチ）コミットを分けて事前合意し、条件付き項目の判断基準も共有しておく |
| 異常値の混ざった実績をそのまま平均する | 本番障害対応などの特殊要因を含めた平均は、次スプリントの実態を反映しない | 異常値の原因を明示した上で、ベースの平均から除外する |
🏆 実務での使いどころ
事前承認済みの有給休暇や通院といった「あらかじめ分かっている稼働減」は、緊急の欠員よりも計画に織り込みやすい一方、見積もりに反映し忘れられがちな事情でもあります。日数ベースで機械的に控除する習慣をつけておくと、スプリント計画の説明責任を果たしやすくなります。また、見積もり不能なスパイクタスクをどう扱うかは、新しい外部API・新しい技術要素を扱うプロジェクトでは頻出の論点です。スパイクをポイント化せず別枠のタイムボックスとして扱い、その結果次第で変わる項目を条件付きコミットとして名指ししておく進め方は、将来テックリードやEMとして不確実性の高いプロジェクトの計画をチームや上位マネジメントに説明する際に直接活きます。
🚀 次のステップ
今回は事前承認済みの有給休暇の日数ベース補正と、スパイクタスクの別枠管理・条件付きコミットという考え方を扱いました。次のPM-推進のテーマ（3-2 進捗可視化）では、このSprint 27が実際に進行した想定でバーンダウンチャートを作成し、「T5スパイクの調査結果がどちらの分岐になったか」「その結果T6（条件付きコミット）が実行されたか見送られたか」を可視化する練習に進みます。見送ったT7・T8が次スプリントでどう扱われたかも、振り返りの材料にしておくと次回の演習がスムーズになります。