スプリントプランニング（Sprint Planning）は、Scrum チームが各スプリントの冒頭に開く計画ミーティングです。3 つの問いに答えることが目的です：このスプリントで何をするか（スプリントゴール）、バックログからどの項目を入れるか（スプリントバックログ）、そしてそれぞれをどう作るか（タスク分解と方針）。 ミーティングが終わる頃には、チームは明確なスプリントゴールと実行可能なタスクリストを持って作業を始めます。
30 秒版
- 頻度：スプリントごとに 1 回。イテレーション初日に固定；
- 所要時間：2 週間スプリント → 最大 2 時間。1 週間スプリント → 1 時間；
- 参加者：Scrum チーム全員——開発者、プロダクトオーナー、スクラムマスター；
- 成果物：スプリントゴール 1 つ＋スプリントバックログ 1 式（実行可能なタスクに分解済み）；
- 合格基準：解散後、誰もが資料を見ずに「このスプリントではこれとこれをやる」と言えること。
スプリントプランニングの位置づけ
スプリントプランニング（1 日目）
↓
デイリースタンドアップ × 9 日
↓
スプリントレビュー（デモ）＋スプリントレトロスペクティブ
↓
次のスプリントプランニング
計画会はイテレーションの起点であり、前段の産物を消費します：プロダクトバックログと、前回レトロスペクティブの改善項目です。両者の関係はスプリントレトロスペクティブガイドを参照してください。
会前の準備（会議効率の半分を決める）
| 準備項目 |
担当 |
基準 |
| プロダクトバックログが並び替え済み |
プロダクトオーナー |
上位の候補項目が十分に明確。場で背景を説明する必要がない |
| 候補項目が整備済み |
プロダクトオーナー＋開発 |
上位 1.5〜2 倍容量分の項目が分解/見積もり済み |
| チーム容量を算出済み |
スクラムマスター |
休暇・会議・オンコールを差し引いた実人日 |
| 前スプリントの持ち越しを確定 |
開発 |
未完了項目：バックログへ戻すか本スプリントに入れるか。会議前に結論 |
| Definition of Done が準備完了 |
チーム |
「完了」の基準に全員が合意している |
整備されたバックログがないと、計画会は要求のすり合わせ会になります——これが会議超過の最も多い原因です。
アジェンダテンプレート（2 週間スプリント・2 時間の例）
| 時間 |
区分 |
行うこと |
| 0:00–0:10 |
ゴール設定 |
PO がこのスプリントで目指すビジネス成果を提示。チームの議論を経て一文のスプリントゴールに収束（例：「管理者がレポートをエクスポートできる」） |
| 0:10–0:50 |
項目選定 |
バックログの順に候補を確認：この項目を入れるか？ 容量と照らして減算し、満杯まで |
| 0:50–1:40 |
タスク分解 |
採用項目ごとに 0.5〜1 日粒度のタスクを切り出し、技術方針の要点を明記。見解が割れる技術リスクはその場で方針確定 |
| 1:40–1:55 |
リスクと依存 |
外部依存（サードパーティ API、デザイン、他チーム）、オンコール体制、既知バグの対応優先度 |
| 1:55–2:00 |
確認とコミット |
スプリントゴールと項目リストを読み上げ、全員確認。初日の着手タスクを明示 |
3 つの重要インプットの計算法
1. 容量（キャパシティ）
実人日 = メンバー数 × 営業日数 − 休暇 − 会議コスト − オンコール調整
例：5 人チーム、10 営業日、合計 3 日の休暇、定例会議が約 2 人日 → 45 − 3 − 2 = 40 実人日。
2. ベロシティ
直近 3〜5 スプリントで完了したストーリーポイントの平均または中央値を取ります（中央値のほうが変動に強い）。歴史のない新チームは容量から見積もります：1 人日 ≈ 1 の実作業単位。2 イテレーション回してからストーリーポイントに切り替えましょう。ベロシティの誤解については末尾の FAQ を参照。
3. 見積もり
- 定番はプランニングポーカー：全員が同時にカードを出し、開きの大きい項目は議論して再見積もり；
- 粒度の原則：8 ポイント超の項目はスプリントに入れる前に分割；
- ポイントが見積もるのは相対的な作業量であって工数ではありません。個人の評価には使わないこと。
よくある誤りと正し方
| 誤り |
結果 |
正し方 |
| 容量 100 %で計画を組む |
バッファゼロ。バグが 1 つ混ざっただけで崩壊 |
容量の 80 %で組む。予想外の欠陥と連携コストの分を残す |
| PO が会議中に口頭だけで要求を説明する |
会議が要求すり合わせ会になる |
会議前に項目を整備。会議では確認だけして講義しない |
| 項目を選ぶだけで分解しない |
「どう作るか」が開発中に初めて考えることになり、中盤で爆発 |
0.5〜1 日粒度まで分解し、技術方針を一度確認 |
| ゴールが項目リストであってビジネス成果ではない |
チームは「終わらせること」にのみ責任を持つ |
スプリントゴールはビジネス志向の一文でなければならない |
| 前スプリントのバグに優先度が付いていない |
予期しない欠陥で本スプリントの計画が乱される |
計画会で持ち越しバグの扱いを確定させる（次節参照） |
スプリント中のバグはどこへ置く？
計画会でよく飛ばされる論点：このスプリントでどの欠陥を扱い、誰のトリアージ機構が回っているか。会議で明確にしましょう：
持ち越しバグのリストと行き先（修正 / 降格 / クローズ）；
スプリント中に発生するバグの流れ：トリアージ → 深刻度判定（P0 は当日対応、P1 は本スプリントへ、P2 はバックログへ）。やり方はBug Triage ガイド；
バグレポートの入口を一つに：テスターやユーザーからの報告は再現手順、スクリーンショット、Console エラーを添えて届くようにする。グループチャットに散らさない。
3 つ目がスプリント速度の隠れたレバーです。コンテキストの揃ったレポートなら、開発者は追加質問なしで着手できます。BugCapturer のこの点でのやり方は——送信時に注釈付きスクリーンショット/録画、URL、ブラウザ環境、Console/Network エラーを自動添付し（診断機能参照）、レポートは Slack / Microsoft Teams チャネルへ自動投稿されるので、計画会での欠陥の判定はチャネル内のレポートを見て直接行えます。「そもそも何の問題？」を議論する時間を会議から消せます。
FAQ
Q：スプリントプランニングとはどんな会議ですか？
A：Scrum における各スプリント冒頭の計画会です。スプリントの範囲（何をするか）と方針（どうやるか）を決め、スプリントゴールとスプリントバックログを産出します。
Q：ビジネスアナリスト（BA）の視点でのスプリントプランニングとは？
A：BA が注視するのは要求のテスト可能性と受入基準です。採用項目が受入条件と明確な境界ケースを備えていることを担保し、外部ステークホルダーの要求をバックログ項目に翻訳します。
Q：計画会はどのくらいの長さにすべき？
A：経験則では、スプリント 1 週につき最大 1 時間。1 週間スプリントなら 1 時間、2 週間スプリントなら 2 時間です。超過するのは、たいてい会前の整備不足が原因です。
Q：リモートチームはどう開けばいい？
A：通常どおりビデオ通話＋共有ボード（Jira/Linear/Trello）。タスク分解の際はコラボレーションホワイトボードで並行して書くと、順番に読み上げるより約 2 倍速いです。
Q：スプリントの途中で「計画が小さすぎた」と気づいたら？
A：途中で項目を詰め込まないこと。記録して次の計画会で優先的に入れます。緊急のものは P0 トリアージの経路を通します。