スクラムの5つのイベント完全解説｜スプリント計画・デイリー・レビュー・レトロスペクティブの目的と進め方

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

スクラムの5つのイベントが形骸化する根本原因は、「各イベントの目的を理解せず、形だけをなぞること」にあります。 結論から言えば、スクラムの5つのイベントはそれぞれ「検査と適応」という経験主義サイクルの特定の場面を担っており、目的に沿った進め方ができるかどうかで、チームの生産性と自己管理力が大きく変わります。たとえばデイリースクラムを「上位者への進捗報告の場」として運用してしまうと、開発者の自己管理が育たず形だけのスクラムになっていきます。本記事では、スクラムガイド2020をもとに、5つのイベントの目的・タイムボックス・進め方・よくある失敗を1本にまとめます。

5つのイベント全体像｜スプリントを器に4つのイベントが収まる

スクラムには、スプリントという固定期間の中に4つのイベントが収まる構造があります。スプリント自体も1つのイベントであり、計5つです。これらのイベントはすべて「検査（Inspection）と適応（Adaptation）の機会」として意図的に設計されており、省略は許可されていません。

イベント	タイムボックス（4週間スプリント）	目的
① スプリント	最長4週間（器）	価値あるインクリメントを生み出す固定期間
② スプリントプランニング	最大8時間	スプリントゴールを決め、実行計画を立てる
③ デイリースクラム	15分（毎日）	スプリントゴールへの進捗を検査し計画を調整する
④ スプリントレビュー	最大4時間	成果を検査しステークホルダーのフィードバックを得る
⑤ スプリントレトロスペクティブ	最大3時間	チームの進め方を振り返り改善策を決める

① スプリント（Sprint）｜他の4イベントを内包する”器”

スプリントとは

スプリントは、スクラムにおける最小限の繰り返し単位となる固定期間です。他の4つのイベントはすべてこのスプリントの中で行われます。スクラムガイド2020では「スプリントは短いプロジェクト」とも表現されており、各スプリントには目的（スプリントゴール）・期限（終了日）・費用見積もり（チームのキャパシティ）があります。

スプリントの長さ

スプリントの長さは最長1か月（4週間） と定められており、一度決めたら期間中は変更しません。一般的には1〜2週間のスプリントを採用するチームが多く、スプリントが短いほど変化への対応力が高まります。前のスプリントが終わったら間を置かず、次のスプリントが始まります。

スプリント中に守るべき4つのルール

スプリントが始まったら、以下の原則を守ります。

1. スプリントゴール達成を危うくする変更はしない — スプリント中の大幅な方向転換は禁止です
2. 品質を落とさない — 完成の定義（DoD）の基準は下げられません
3. プロダクトバックログは必要に応じて洗練する — 詳細化・優先度変更は継続して行えます
4. スコープはPOと交渉可能 — 技術的な難しさが判明した場合、何を作るかをPOと再交渉できます

② スプリントプランニング（Sprint Planning）｜Why・What・Howの3トピックで計画を立てる

目的とタイムボックス

スプリントプランニングは、スプリント開始時に行う計画イベントです。タイムボックスは4週間スプリントで最大8時間、2週間スプリントなら最大4時間が目安です。スクラムチーム全員（プロダクトオーナー・スクラムマスター・開発者）が参加します。

3つのトピックで進める

スクラムガイドでは、スプリントプランニングで「Why・What・How の3トピック」を扱うことが定められています。

トピック	問い	担う主体
Why（なぜ）	このスプリントはなぜ価値があるのか？	PO が提案 → チームで確定
What（何を）	このスプリントで何が完成できるか？	開発者がキャパシティを見て選択
How（どう）	選んだ成果物をどうやって完成させるか？	開発者が計画

このプランニングで生まれるスプリントバックログは、「スプリントゴール（Why）＋選んだバックログ項目（What）＋実行計画（How）」で構成されます。

スプリントプランニングのポイント

• プロダクトバックログを事前に洗練しておく：プランニング当日に「バックログが未整理で議論できない」事態を防ぐため、事前のリファインメントが重要です
• スプリントゴールは1文で表現する：「〇〇機能を完成させてユーザーが△△できるようにする」という形で、テーマの一貫性を持たせます
• 開発者は過去のベロシティを参考に選択する：直前2〜3スプリントの完了実績（ベロシティ）を参照し、今回の選択量を決めます

③ デイリースクラム（Daily Scrum）｜15分で計画を調整する”自己管理の場”

目的とタイムボックス

デイリースクラムは、スプリントゴールに対する進捗を検査し、翌日以降の計画を調整するための15分のイベントです。毎日同じ時間・同じ場所で行います。主体は開発者であり、スクラムマスターは場を確保しますが強制参加ではありません。

旧「3つの質問」と2020年版の変化

スクラムの入門書でよく見る「昨日やったこと・今日やること・障害になっていること」という3つの質問は、スクラムガイドの旧バージョンで推奨されていた形式です。2020年版ではこの形式は廃止され、「開発者が自分たちにとって効果的な進め方を自由に決められる」とシンプルになりました。3質問を使うことは可能ですが、あくまで一例です。

旧バージョン（2017年版まで）	2020年版
昨日やったこと・今日やること・障害の3質問が推奨された	形式を開発者が自由に決められる（3質問は例示ではなく削除）
形式が固定されがちで儀式化しやすかった	「スプリントゴールに向けて今日どうするか」が本質と明示

デイリースクラムのポイント

• 問題の”解決”はデイリーでしない：問題を特定したら「そのあと別途」で議論します。15分を守ることで習慣化できます
• バーンダウンチャートを参照すると効果的：スプリントゴールへの進捗が可視化され、今日の調整判断がしやすくなります
• スクラムマスターはファシリテーターに徹する：答えを出すのではなく、チームの自律的な判断を引き出すように場を整えます

④ スプリントレビュー（Sprint Review）｜成果を”検査”して次の計画へ

目的とタイムボックス

スプリントレビューは、スプリントの終わりに完成したインクリメント（成果物）を検査し、プロダクトバックログを更新するイベントです。タイムボックスは4週間スプリントで最大4時間、2週間なら最大2時間が目安です。スクラムチームに加え、主要なステークホルダーもプロダクトオーナーが招待して参加します。

4つの内容で構成する

1. 達成状況の共有：スプリントゴールの達成度と完了・未完了の確認
2. インクリメントのデモ：実際に動くプロダクトをステークホルダーが確認する
3. フィードバックの収集：ステークホルダーの意見・要望・疑問を双方向で受け取る
4. プロダクトバックログの更新：フィードバックを踏まえ、次スプリント以降の優先度を見直す

スプリントレビューのポイント

• 完成の定義（DoD）を満たしたものだけを示す：「ほぼ完成」の状態では出しません。インクリメントは DoD を満たして初めてインクリメントと呼べます
• ステークホルダーをスプリント開始時点で招待する：当日に「予定が入った」では参加が得られません。カレンダーをスプリント開始時に押さえます
• 承認を求める場ではない：POがインクリメントを受け入れるかどうかの確認は、スプリント中に DoD との照らし合わせで行います

⑤ スプリントレトロスペクティブ（Sprint Retrospective）｜チームの”やり方”を改善する

目的とタイムボックス

スプリントレトロスペクティブは、スプリントレビューの後・次のスプリントプランニングの前に行うイベントです。タイムボックスは4週間スプリントで最大3時間。プロダクト（何を作るか）ではなく、チームのプロセス（どう進めるか）を改善する場です。スクラムチーム全員（PO・SM・開発者）が参加します。

5ステップで進める

ステップ	内容	目安時間（2週間スプリント）
① 場を設定する	心理的安全を確認。「発言は責任追及に使わない」と明示	5分
② データを収集する	KPT・Start/Stop/Continue などで付箋に書き出す	15分
③ 洞察を導出する	似た意見をグループ化し「なぜそうなったか」を掘り下げる	15分
④ 実行内容を決定する	ドット投票で上位2〜3個に絞り、誰が・いつまでに・何をするかを決める	10分
⑤ 終了する	前回の Try の実施状況を次回の冒頭で確認するルーティンへ	5分

フォーマットの使い分け

フォーマット	特徴	向く場面
KPT（Keep/Problem/Try）	シンプルで汎用性が高い	初回・定番として
Start/Stop/Continue	行動志向で具体的になりやすい	行動改善にフォーカスしたいとき
Fun/Done/Learn	ポジティブな面から入れる	心理的安全が低いチームに
Starfish	5段階（More of/Less of/Keep/Start/Stop）	細かいニュアンスを出したいとき

スプリント長さ別タイムボックス早見表

イベント	1週間スプリント	2週間スプリント	4週間スプリント
スプリントプランニング	最大2時間	最大4時間	最大8時間
デイリースクラム	15分×5日	15分×10日	15分×20日
スプリントレビュー	最大1時間	最大2時間	最大4時間
スプリントレトロスペクティブ	最大45分	最大1.5時間	最大3時間

タイムボックスは上限です。目的を達成した時点で終了して構いません。2週間スプリントでもレトロが1時間で十分な改善策を決められれば、1時間で終わらせるべきです。

スクラムの5イベント運用のメリット・デメリット

よくある失敗5選

① デイリースクラムが「報告会」になる 開発者ではなくマネージャーに向けた報告の場になると、自己管理が育たず形骸化します。スクラムマスターはファシリテーターに徹し、「スプリントゴールに向けて今日どうするか」を開発者自身が語る場にします。

② スプリントゴールを「バックログ項目の列挙」で表現する 「画面Aと機能Bと修正Cを完成させる」はゴールではなくリストです。「ユーザーが〇〇できるようにする」という一貫したテーマがあるゴールが、スプリント中の判断軸になります。

③ スプリントレビューが「デモで終わる」 ステークホルダーが視聴するだけで双方向のフィードバックが生まれないと、プロダクトバックログが更新されません。「次に優先すべきことは何か」を必ず問いかけます。

④ レトロスペクティブの Try が10個以上に膨らむ 意見がたくさん出るのは良いことですが、Try が多すぎると実行されません。ドット投票で上位2〜3個に絞り、スプリントバックログに追加して誰かに責任を持たせます。

⑤ タイムボックスを守らない 「もう少し議論したい」でスプリントプランニングが長時間になるとチームが疲弊します。タイムボックス終了前に「これで十分か」を確認し、不十分ならスプリント中に別途時間を設けます。

FAQ

Q1. 各イベントのタイムボックスは毎回使い切らなければいけないか？ いいえ。タイムボックスは上限です。デイリースクラムが10分で終わるなら10分で切り上げて構いません。時間を使い切ること自体が目的ではありません。

Q2. デイリースクラムの旧3つの質問は使ってはいけないか？ 使ってもかまいません。2020年版では形式を自由にしましたが、3質問は多くのチームで機能する実用的なフォーマットです。目的（スプリントゴールへの進捗確認と計画調整）が達成できれば、形式は問いません。

Q3. スプリントレビューとデモの違いは何か？ デモはスプリントレビューの一部です。レビューの目的は「インクリメントの検査」と「プロダクトバックログの更新」であり、デモはそのための手段です。デモで終わらず、フィードバックを受けてバックログを更新することがレビューの完成です。

Q4. スプリントレトロスペクティブの改善アクションは何個決めるべきか？ 2〜3個が推奨です。多く決めるより少なく確実に実行することを優先します。「全部やろうとして全部やらない」より「2つに絞って確実にやる」方が、チームの改善サイクルが機能します。

Q5. 1週間スプリントでも同じ5つのイベントをすべて行うか？ はい。ただしタイムボックスはスプリント長さに比例して短くなります（上表参照）。1週間スプリントでのスプリントプランニングは最大2時間、レトロスペクティブは最大45分が目安です。

まとめ｜5つのイベントは「検査と適応」の設計図

• スプリント（最長4週間）：他の4イベントの器。ゴール・期限・費用見積もりを持つ”短いプロジェクト”
• スプリントプランニング：Why（ゴール）→ What（選択）→ How（計画）の順で3トピックを扱う。ゴールを先に決める
• デイリースクラム（15分）：報告会ではなく、開発者が自分たちで計画を調整する場。形式は自由
• スプリントレビュー：デモで終わりではなく、フィードバックを受けてバックログを更新するまでが目的
• スプリントレトロスペクティブ：プロダクトではなくチームの「やり方」を改善。Try を2〜3個に絞って確実に実行

スクラムの5つのイベントは、「半月〜1か月に一度、チームが価値を届けながら自分たちの進め方を継続的に改善していく」仕組みの中核です。形式だけをなぞる状態を抜け出すには、各イベントの”なぜ”を理解することが最短ルートです。