フレームワーク活用ガイドひとことで言うと#
スプリントの開始時に、チーム全員で「今回のスプリントで何を達成するか（Why/What）」「どうやって実現するか（How）」を話し合い、合意するスクラムイベント。
押さえておきたい用語#
- スプリントゴール（Sprint Goal）
- 今回のスプリントで達成したい1〜2文で表現できるテーマのこと。チームの方向性を揃える羅針盤。
- スプリントバックログ（Sprint Backlog）
- スプリントゴール＋選択したアイテム＋タスク分解を合わせたスプリントの作業計画一式を指す。
- DoD（Definition of Done）
- アイテムが「完了」とみなされるための品質基準リストのこと。DoDを満たさないアイテムはカウントしない。
- キャパシティ（Capacity）
- スプリント期間中にチームが実際に作業に使える時間のこと。休暇や会議を除いた実効稼働時間。
スプリントプランニングの全体像#
こんな悩みに効く#
- スプリントで何をやるか毎回曖昧なまま始まってしまう
- 見積もりと実績が大きく乖離して、毎スプリント未完了が出る
- チームメンバーが「やらされ感」を持っていて、主体性がない
基本の使い方#
「このスプリントで何を達成したいか」をチームで合意する。
- プロダクトオーナーが、プロダクトバックログの上位アイテムの価値と背景を説明する
- チームで「このスプリントのテーマ（ゴール）」を言語化する
- スプリントゴールは1〜2文で表現できるくらいシンプルに
ポイント: スプリントゴールがないとただのタスク消化になる。「何のためにやるか」を共有することが大事。
スプリントゴールを達成するために必要なアイテムを選ぶ。
- プロダクトバックログの上位から順に、スプリントに取り込むアイテムを選ぶ
- チームのベロシティ（過去の実績）を参考に、取り込み量を判断する
- 「完了の定義（DoD）」を満たせるものだけを取り込む
ポイント: 無理して詰め込まない。未完了が出るよりも、確実に完了できる量を選ぶ。
選んだアイテムを具体的な作業タスクに分解する。
- 各バックログアイテムを「完了」にするために必要なタスクを洗い出す
- 各タスクの見積もり（時間 or ポイント）をチームで行う
- 誰がどのタスクを担当するか、大まかに決める
ポイント: タスクの粒度は1日以内で完了できるサイズが理想。大きすぎると進捗が見えにくい。
スプリントゴール、選択したアイテム、タスク分解の結果を「スプリントバックログ」として確定する。
- チーム全員が「このスプリントでこれを達成する」と合意していることを確認
- スプリントバックログをカンバンボードやツールに反映する
- 不明点や懸念事項があれば、このタイミングで解消しておく
ポイント: 全員が「自分たちの計画」として納得していることが最重要。押しつけではなく合意。
具体例#
スプリントゴール: 「カート離脱率を改善するための主要施策を本番リリースする」
アイテム選択: プロダクトバックログから以下を選択（チームのベロシティ: 30pt）
| アイテム | ポイント | 備考 |
|---|---|---|
| カート画面のUI改善 | 8pt | デザイン確定済み |
| ゲスト購入機能の実装 | 13pt | API設計レビュー済み |
| 送料の事前表示 | 5pt | 外部APIとの連携あり |
| 合計 | 26pt | バッファ込みで適切 |
タスク分解: 「ゲスト購入機能」を分解 → API設計（2h）/ DB設計（1h）/ バックエンド実装（8h）/ フロントエンド実装（6h）/ テスト（4h）/ コードレビュー（2h）
合意: チーム全員が「この量なら完了できる」と確認。不明点だった決済周りの仕様をPOに確認し、解消。
結果: スプリント終了時に3アイテムすべて完了。カート離脱率が42%→35%に改善し、スプリントゴールを達成した。
背景: 8名のバックエンドチーム。過去5スプリントでプランニングが毎回3時間超（目標2時間）。原因はバックログアイテムが未整理のままプランニングに臨んでいたこと。
改善策: スプリント中にリファインメントを週1回・1時間実施するルールを導入。プランニング前に次スプリントの候補アイテムが「Ready」状態であることを確認。
Before/After:
| 指標 | 改善前（5スプリント平均） | 改善後（5スプリント平均） |
|---|---|---|
| プランニング時間 | 3.2時間 | 1.8時間 |
| スプリント完了率 | 68% | 89% |
| プランニング中の仕様質問数 | 12件 | 3件 |
| チーム満足度 | 2.8 | 4.2（5点満点） |
結果: プランニング時間が44%短縮。リファインメントの導入でアイテムの理解が深まり、スプリント完了率が68%→89%に大幅改善した。
背景: 4名のWeb制作チーム。これまで社長が作業を割り振る形で、チームの主体性が低かった。「やらされ感」をなくすためにスクラムのスプリントプランニングを導入。
導入の工夫:
- 最初の3スプリントはスクラムマスター（外部コーチ）がファシリテーション
- ストーリーポイントではなくTシャツサイズ（S/M/L）で見積もり開始
- プランニングポーカーで全員の意見を引き出す
3ヶ月の変化:
| スプリント | プランニング時間 | ゴール達成 | メンバーの声 |
|---|---|---|---|
| Sprint 1 | 90分 | 部分達成 | 「自分たちで決められるのが新鮮」 |
| Sprint 3 | 75分 | 達成 | 「見積もりの精度が上がってきた」 |
| Sprint 6 | 60分 | 達成 | 「プランニングが楽しみになった」 |
結果: 6スプリント後、メンバーの主体性スコア（匿名調査）が2.1→4.3に向上。案件の納品遅延が月2件→月0件に改善。社長も「自分がボトルネックだった」と認識を改め、POとしての役割に集中するようになった。
やりがちな失敗パターン#
- プロダクトオーナーが一方的に決める — POがアイテムを「指示」し、チームが「はい」と受ける形になると、主体性が生まれない。チームが自分たちで「やれる量」を判断するのが正しい
- リファインメントをサボる — バックログアイテムが未整理のままプランニングに臨むと、内容の理解に時間がかかり、計画が終わらない。事前のリファインメントが必須
- 楽観的な見積もり — 「頑張ればできる」量を詰め込むと、毎回未完了が出てチームの士気が下がる。ベロシティの80%程度を目安にするのが安全
- スプリントゴールを設定しない — ゴールなしだとタスクの寄せ集めになり、スプリント中の優先判断ができない。ゴールがあることで「何を捨てるか」も決められる
まとめ#
スプリントプランニングは、スプリントの成果を最大化するための重要なイベント。Why（なぜやるか）→ What（何をやるか）→ How（どうやるか）の順にチーム全員で合意することで、「自分たちの計画」としてスプリントに臨める。事前のリファインメントとベロシティに基づく現実的な計画が成功のカギ。