スプリントプランニング：効果的なSprintプランニングミーティングの進め方

スプリントプランニングは、アイデアのBacklogをチームが実際に実行できる明確なコミット済み計画へと変えるイベントです。うまく行えば2時間以内で終わり、チームは意欲的になります。うまくいかないと午後まで引きずり、誰も信頼しないリストが生まれます。

スプリントプランニングとは何か

スプリントプランニングはScrumにおいてタイムボックス化されたイベントであり、開発チーム・Product Owner・Scrum Masterが各Sprintの開始時に集まり、何を完了させるか・どのように行うかを決定します。このミーティングは2つのアウトプットを生み出します。Sprintゴール（「なぜ」）とSprint Backlog（そのゴールを達成するためにチームが選択した具体的な項目）です。

スプリントプランニングはより広いアジャイル手法フレームワークの中に位置します。Sprintは短い固定期間のサイクル（通常1〜4週間）であり、チームが動作するソフトウェアまたは完成したインクリメントを定期的に届けるリズムを提供します。スプリントプランニングは、各サイクルが前提ではなく意図を持って始まる方法です。

Scrum Guideはすべてのスプリントプランニングセッションに2つの核心的な問いを定義しています。このSprintにProduct Backlogから何を届けられるか、そして選んだ作業をどのように行うかです。この2つの問いは、Scrumコミュニティがしばしば「パート1：何を」「パート2：どのように」と呼ぶミーティングの2つのパートに直接対応しています。

うまく進められたスプリントプランニングミーティングは、スコープについて具体的であり、キャパシティについて正直であり、次の2週間にチームが一丸となれるSprintゴールに根ざしています。

重要なポイント

• Scrum Guideは1ヶ月のSprintに対してスプリントプランニングに最大8時間を割り当てており、短いSprintに対しては比例して短縮されます（Scrum Guide, 2020）。
• 明確なSprintゴールを設定したチームは、SprintのコミットメントをすべてDeliverできる可能性が2.5倍高いとされています（State of Agile Report 第17版, 2024）。
• 効率的に実施した場合、スプリントプランニングは2週間Sprintの作業時間の約**5%**を消費します（Scrum.orgコミュニティデータ, 2024）。

スプリントプランニングが重要な理由

スプリントプランニングがなければ、チームはアドホックな優先順位付けに陥ります。最も重要な作業ではなく、最も大きな声で求める人に基づいて作業が選ばれます。スプリントプランニングは、作業が始まった後ではなく始まる前に共有のコミットメントを生み出すことでこのパターンを打破します。

メリットは測定可能な形で現れます。明確なSprintゴールを持つチームはSprintの途中で方向変更が少なくなります。このサイクルで「完了」がどのような状態かについて全員がすでに合意しているためです。（スプリントプランニング中に適切に行われた）キャパシティ計画は、チームが過度にコミットすることを防ぎます。これはSprintが失敗する最大の単一原因です。また、この儀式自体が心理的安全性を構築します。チームが一緒にコミットすると、最終日まで隠すのではなく早期にブロッカーを表明する可能性が高まります。

スプリントプランニングは日常業務とプロダクトRoadmapの間に直接のつながりも生み出します。各Sprintゴールはより大きな戦略的目標に対応すべきです。チームがすべてのSprintの開始時にその接続を明示的に述べられると、作業はタスクリストではなく進捗のように感じられます。

ウォーターフォール手法から移行するチームにとって、スプリントプランニングはアジャイルデリバリーがどのように異なるかを示す最も明確な証明であることが多いです。上から渡される6ヶ月計画ではなく、チーム自身が次の2週間を形作ります。合意している内容を完全に把握しながら。

スプリントプランニングの2つのパート

Scrum Guideはスプリントプランニングを2つの異なる会話に構成しています。ほとんどの失敗したスプリントプランニングミーティングは、パート1が真に解決される前にパート2に直行してしまうことで崩壊します。

パート1：何をするか？（Sprintゴールとアイテムの選択）

Product OwnerはProduct Backlogの上位項目を提示します。チームはスコープ・受け入れ基準・依存関係について質問します。協力してSprintゴール（このSprintがステークホルダーの視点から何を達成すべきかについての単一の簡潔な記述）を草案します。ゴールが設定されると、チームはそれを達成するProduct Backlog Items（PBI）を選択します。

パート1は、チームがSprintゴールに合意し、候補アイテムリストを持ったときに完了です。それだけです。その2つのアウトプットが存在するまで次に進まないでください。

パート2：どのようにするか？（タスクの分解とキャパシティの確認）

選択されたアイテムが揃ったところで、チームは各アイテムを具体的なタスクに分解します（通常それぞれ0.5〜2日の作業）。ここでキャパシティ計画が行われます。チームは実際の稼働状況を考慮した上で、タスクが利用可能なSprintの時間またはStory Pointに収まるかを確認します。収まらない項目はBacklogに戻されます。

パート2はSprint Backlogを生み出します。Sprintゴール＋選択された項目＋タスク分解です。これがチームの次のSprintの実行計画となります。

スプリントプランニングのアジェンダ（2時間のミーティング）

以下の表は2週間Sprintの2時間アジェンダを示しています。短いまたは長いSprintに対しては時間を比例調整してください。

2週間Sprintで2時間を超えた場合は、中断して原因を診断してください。よくある原因：ミーティング前にBacklog項目が精査されていなかった、アイテム選択に移る前にSprintゴールが合意されていなかった、詳細が不明な項目が多すぎた。

スプリントプランニングの進め方：ステップバイステップ

ステップ1：ミーティング前にキャパシティを計算する

誰かが着席する前に、Scrum Master（またはファシリテーター）はチームのSprintにおける利用可能キャパシティを計算します。これは「全員が10日間働くので1人あたり10日分のキャパシティがある」ではありません。ミーティング・休暇・オンコール業務、そしてフォーカスファクター（割り込みと比較したSprintの作業に費やす現実的な時間の割合）を考慮します。

シンプルなキャパシティ表（次のセクションで詳しく説明）は5分で作成でき、ミーティング中の40分間の議論を防ぎます。

ステップ2：BacklogアイテムがDefinition of Readyを満たすか確認する

アイテムをSprintで選択する前に、**Definition of Ready（DoR）**をパスする必要があります。DoRはBacklogアイテムがスプリントプランニングに入る前に満たすべき、チームが定義したチェックリストです。典型的な基準には以下が含まれます。

• 受け入れ基準が書かれており、チームが理解している
• 依存関係が特定されアンブロックされている（またはリスクが把握されている）
• アイテムが見積もられている（Story PointまたはTシャツサイジング）
• 1つのアイテムがSprint期間の半分を超えない

DoRを満たさないアイテムはBacklogでフラグが立てられ、Product Ownerに精査のために返されます。Sprint に取り込まないでください。

ステップ3：Sprintゴールを協力して草案する

Product OwnerがSprintゴールの草案を提案します。チームは言語を磨き、ビジネスが見たいものだけでなく、実際に作っているものを反映させます。良いSprintゴールは：

• 十分に具体的（Sprint終了時に達成したかどうかがわかる）
• 十分に柔軟（予期せぬことが起きた際に一部のPBIを入れ替えられる）
• 単一スレッド（Sprint1つにゴール1つ。複数のゴールはフォーカスを分散させる）

弱いSprintゴールの例：「オンボーディングフローを改善する」。強いSprintゴールの例：「新規ユーザーがサポートに連絡することなくアカウントを有効化し、最初の重要なアクションを完了できる」。

ステップ4：Product Backlog Itemsを選択する

Sprintゴールが合意されると、チームはBacklogの上位からゴールを最もよく支援するPBIを選択します。これはトップダウンの配布ではなく会話です。チームは質問し、スコープを交渉し、時には大きなアイテムをSprintに収まるよう小さく分割します。

Velocity（過去3〜5Sprintで完了した平均Story Point数）を選択の上限として使用します。Velocityを超えて選択しないでください。チームが1Sprintで平均32ポイントであれば、45ポイントを計画しないでください。

ステップ5：アイテムをタスクに分解する

選択された各PBIについて、チームは受け入れ基準を満たすために必要な具体的なタスクをリストアップします。タスクは進捗が日次で見えるほど小さくすべきです（おおよそ0.5〜2日ずつ）。この分解はまた隠れた複雑さも表面化させます。3ポイントに見えたストーリーが、組み合わせた見積もりがはるかに高い5つのタスクを明らかにすることがあります。

ストーリーのタスクリストが元の見積もりを大幅に超える場合、チームは再見積もり・ストーリーの分割・Backlogへの返却ができます。SprintのDay 8ではなく今その判断をする方が良いです。

ステップ6：コミットしてクローズする

チームが最終的なキャパシティ確認を行います。推定タスク工数の合計対利用可能なSprintキャパシティ。収まればチームはコミットします。収まらなければ、項目を取り出します（決して追加しません）。Scrum MasterがSprint Backlogをまとめ、Day 1にフォローアップが必要な未解決の質問や依存関係を記録します。

ここでのコミットメントは契約ではありません。現在知っていることを踏まえて、これらの項目は達成可能だとチームが心から信じているということです。この区別は重要です。特に過度な約束で痛い思いをしたチームにとっては。

キャパシティ計画：計算方法

キャパシティ計画はシンプルな計算ですが、フォーカスファクターを省略すると間違えやすいです。

計算式：

利用可能キャパシティ（ポイント）= 利用可能日数 × フォーカスファクター × 1日あたりのポイント数

フォーカスファクターは、ミーティング・メール・サポートチケット・その他の割り込みと比較して、各作業日のうちSprint作業に費やされる現実的な割合を表します。ほとんどのチームで0.6〜0.8の間です。新しいチームやサポート負荷が高いチームは低い方になる傾向があります。

2週間Sprint（10作業日）のキャパシティ表の例：

この例では、チームのVelocityの上限は53 Story Pointです。チームの過去のVelocityが40ポイントであれば、40を実際の上限として使用してください。Velocityは、人が利用可能であっても立ち往生したり予期せず複雑になったりする作業を考慮しています。

作業日数をそのままキャパシティの代わりに使わないでください。各自が10日間働く5人の開発者チームが50日分のSprintキャパシティを持つわけではありません。フォーカスファクターは計画を誠実にするために存在します。

チームタイプ別スプリントプランニング事例

作業分解構成図のアプローチは、大きなSprintアイテムをタスクレベルのコンポーネントに分解するのに有効です。特に複数の技術的サブタスクを持つストーリーがあるエンジニアリングおよびデザインチームに適しています。

スプリントプランニングのよくある失敗（と対処法）

スプリントプランニングのベストプラクティス

• タイムボックスを設定し守る。 2週間のSprintは2時間のプランニングミーティングが与えられます。ミーティングが時間オーバーするとき、それは作業量の問題ではなくプロセスの問題（精査が不十分なBacklog・不明確なゴール）を示しています。
• スプリントプランニング前にBacklogを精査する。 最良のスプリントプランニングミーティングは、アイテムがすでによく理解されているためほぼ簡単すぎると感じます。上位10〜15のアイテムを事前にグルーミングするSprintの途中の精査セッションを実施してください。
• Sprintゴールをwall（または共有ドキュメント）に書く。 誰かの記憶の中だけにあるゴールは3日目には意思決定の指針でなくなります。チーム全員が毎日見える場所に置いてください。
• 一貫した見積もりスケールを使う。 Story Point・Tシャツサイジング・理想日数のどれを使うにしても、1つを選んで複数のSprintに渡って使い続けることでVelocityの比較が意味を持ちます。
• 全Scrumチームのみ参加、それ以外は不参加。 スプリントプランニングはProduct Owner・Scrum Master・開発チームのためのものです。ステークホルダー・マネージャー・役員は参加者ではありません。彼らのインプットはProduct OwnerがミーティングにBacklog経由で持ち込みます。
• 新しいストリームにはプロジェクトライフサイクルの視点から始める。 新しいプロダクトやイニシアティブを開始するチームにとって、最初のSprintゴールをより広いプロジェクトライフサイクルに根ざすことで、このSprintがデリバリーの全体像とどうつながるかをチームが理解しやすくなります。
• レトロスペクティブで振り返る。 チームが常にSprintゴールを達成できない場合、それはスプリントプランニングの問題です。レトロスペクティブはデリバリーパフォーマンスと並べて計画の精度を検討すべきです。
• ScrumとKanbanのトレードオフについてクロストレーニングする。 両方の手法を理解しているチームはより良いスプリントプランニングの判断を下せます。特に、Sprintの構造が自分たちの作業タイプに本当に適しているかを判断するときに。

よくある質問

スプリントプランニングはどのくらいの時間をかけるべきですか？

Scrum Guideは1ヶ月のSprintに対して最大8時間を設定しており、短いSprintに対しては比例して短縮されます。2週間のSprintでは最大4時間ですが、準備が整ったチームは通常2時間以下で完了します。スプリントプランニングが常に長引く場合、原因はほぼ必ずミーティング前の精査が不十分なBacklog、またはミーティング開始前にチームが合意していないSprintゴールにあります。

Definition of Readyとは何ですか？

Definition of Ready（DoR）は、Product Backlog Itemがスプリントプランニングに入る資格を満たすためのチームが定義したチェックリストです。一般的なDoR基準には、書かれた受け入れ基準・Story Pointの見積もり・特定された依存関係・1Sprintに収まるスコープが含まれます。DoRはScrum Guideの概念ではありませんが、準備が整っていないストーリーを取り込むことを防ぐ広く採用された実践です。チームはレトロスペクティブでDoRに合意し、学びを得るにつれて更新します。

スプリントプランニングには誰が参加しますか？

必須の参加者はProduct Owner・Scrum Master・開発チーム全員です。Product OwnerはBacklog項目を提示し優先順位を付けます。開発チームは質問し、見積もり、アイテムを選択します。Scrum Masterはファシリテーションとプロセスのブロッカー除去を行います。マネージャー・ステークホルダー・顧客は参加しません。彼らのニーズはProduct OwnerがミーティングにProduct Backlogアイテムを通じて代表します。

スプリントプランニングとBacklog精査の違いは何ですか？

Backlog精査（Backlogグルーミングとも呼ばれる）は、Product Ownerとチームがスプリントプランニングで必要になる前に今後のBacklog項目をレビュー・見積もり・明確化する継続的な活動です。スプリントプランニングは各Sprintを開始する公式でタイムボックス化されたミーティングです。精査を準備作業、スプリントプランニングを意思決定ミーティングと捉えてください。精査を省略すると、スプリントプランニングで両方の作業を同時に行うことになります。それがセッションが長引き不確実なコミットメントを生む理由です。

チームが十分な作業にコミットできない場合はどうすべきですか？

チームのキャパシティが通常より低い場合（休暇・体調不良・競合する優先事項）、スプリントプランニングはそれを誠実に反映すべきです。より少ない項目を選択し、より小さなSprintゴールを設定し、Sprint開始前にステークホルダーに縮小したスコープを伝えてください。キャパシティが低いSprintにストレッチゴールや完成させられると信じていない項目を追加しないでください。完了するより小さなコミット済みスコープの方が、部分的にしか完了せずステークホルダーが実際に何が完了したのか不確かになる野心的なスコープより優れています。

---

効果的なスプリントプランニングとは、2週間にできるだけ多くの作業を詰め込むことではありません。正しい作業を選択し、それがなぜ重要かについて合意し、約束したことを届けられるという共有の確信を構築することです。スプリントプランニングがうまく機能すると、Sprintはほぼ自律的に進みます。まさにそうあるべき姿です。