スクラム運用実務ガイド：デイリースクラム・スプリントレビュー・レトロスペクティブの設計と回し方

「導入した」で終わり、「回っている」にならない

多くのチームは、デイリースクラム・スプリントレビュー・スプリントレトロスペクティブという名前の会議をカレンダーに置いた時点で「スクラムを導入した」とみなす。だが実際に起きやすいのは、デイリースクラムがスクラムマスターやPMへの状況報告会になり、スプリントレビューが完成していない画面を見せる社内デモになり、レトロスペクティブが「特に問題ありませんでした」で数分終わる、という形骸化である。3つのイベントは名前をつけて時間を確保するだけでは機能しない。それぞれに目的・時間枠・参加者・検査対象が定められており、そこからズレるほど本来の役割を果たさなくなる。

この記事は、スクラムの原典であるスクラムガイド（2020年版）の記述に基づき、3つのイベントを設計する手順と、よくある形骸化パターンへの対処を扱う。ツールの操作方法ではなく、イベントそのものの運用設計が対象になる（ボード側の設計は「Jiraのボード運用実務ガイド」を参照）。

土台：スクラムチームの役割とスプリントの定義

スクラムチームは3つの役割で構成される。プロダクトオーナーはプロダクトの価値最大化に責任を持ち、プロダクトバックログの優先順位を決める。スクラムマスターはスクラムが正しく機能するよう支援し、障害を取り除く。開発者は各スプリントで使える状態のインクリメントを作る責任を持つ。3つの役割は上下関係ではなく、それぞれ異なる責任範囲を持つ1つのチームである。

スプリントは1か月以下の固定期間で、前のスプリントが終わった直後に次のスプリントが始まる。この中でスプリント計画・デイリースクラム・スプリントレビュー・スプリントレトロスペクティブという4つのイベントが行われる。スプリント計画は別テーマとして扱い、この記事では残る3つ（進捗を毎日検査するデイリースクラム、成果を検査するスプリントレビュー、進め方自体を検査するレトロスペクティブ）を対象にする。

3つのイベントが存在する理由は、スクラムが経験主義（透明性・検査・適応の3本柱）に基づいているからである。重要な決定は成果物の状態に基づいて行われ（透明性）、その状態を頻繁に検査し（検査）、許容範囲を外れていれば早期に調整する（適応）。デイリースクラムはスプリントバックログを、スプリントレビューはインクリメントとプロダクトバックログを、レトロスペクティブはチームの進め方そのものを検査する。対象が違うだけで、役割は「検査と適応の場を強制的に作る」ことで共通している。

デイリースクラム：状況報告会にしない設計

デイリースクラムの目的は、スプリントゴール達成への進捗を検査し、必要に応じてスプリントバックログを適応させることである。時間枠は15分で、スプリントの長さに関わらず変わらないとスクラムガイドに明記されている。

参加者は開発者が中心である。スプリントバックログの項目に実際に取り組んでいるプロダクトオーナーやスクラムマスターがいれば、その人は開発者として参加する。進捗を「聞く側」として同席するのではなく、進捗を検査する当事者として加わる立て付けになっている。

デイリースクラムの構造・進め方自体は開発者が選ぶとされている。「昨日やったこと・今日やること・障害になっていること」という3つの質問形式は広く使われている一手法だが、スクラムガイドが唯一の型として定めているわけではない。スプリントゴールへの進捗に焦点を当て、翌日の作業計画を作れる形式であれば、順番に発言する形でも、タスクボードを見ながら話す形でも構わない。

形骸化する典型パターンは2つある。1つは、スクラムマスターやPMが司会をして「進捗どうですか」と1人ずつ確認する状況報告会になること。検査の主語が開発者からPM側に移り、スプリントゴールではなく個々のタスク消化率が話題の中心になりやすい。もう1つは、話題がスプリントバックログと無関係な雑談や個別の技術相談に流れ、15分を超えて長時間化することである。対処は、進行を開発者に戻すこと、話題が個別相談に入ったら「後で関係者だけで」と切り分けることの2つになる。

スプリントレビュー：デモ大会で終わらせない設計

スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することである。時間枠は1か月のスプリントに対して最大4時間で、スプリントが短ければ時間枠も通常より短くなるとされている（具体的な換算はこの後の章で扱う）。

参加者はスクラムチームと主要なステークホルダーである。開発チームだけで完結するデイリースクラムとの違いがここにあり、意思決定に関わる関係者を実際に呼ぶことが前提になっている。

形式面での指定も明確である。チームが達成内容をプレゼンテーションする場ではなく、ワーキングセッション形式で進める。プロダクトゴールへの進捗を討議し、環境変化（市場・タイムライン・予算・想定しうる機能等）を検証し、次に何をすべきかを協力して決める場である。この検証結果を受けてプロダクトバックログが調整されることもある。

形骸化する典型パターンは、完成していない機能や仕掛かり中の画面を見せる「デモ大会」になることである。完了の定義を満たしていない成果物を見せると、フィードバックの対象が見た目に偏り、本来検査すべき「プロダクトゴールへの進捗」からズレる。対処は、レビューに出すのは完了の定義を満たしたインクリメントに限ること、出たフィードバックをその場の雑談で終わらせずプロダクトバックログの項目として記録することである。

スプリントレトロスペクティブ：改善を「話す」で終わらせない設計

レトロスペクティブの目的は、品質と有効性を向上させる方法を計画することである。時間枠は1か月のスプリントに対して最大3時間で、スクラムチーム全体が参加する。

検査する対象は5つに整理されている。個人、相互作用、プロセス、ツール、そして完了の定義に関して、前回スプリントの状況を検査する。「うまくいったこと」「困ったこと」だけを話す進行だと、ツールや完了の定義といった対象が話題に上がらないまま終わりやすい。5つの対象を順に扱う進行にすると、抜け漏れが減る。

決定的なのは最後の一手である。スクラムチームは、最も効果の高い改善を特定し、次のスプリントバックログに追加できるとされている。話し合って終わりではなく、改善項目をタスク化し、次のスプリントで実行する対象に組み込むところまでがレトロスペクティブの範囲に含まれる。改善が言いっぱなしで消えるチームの多くは、この最後の一手を欠いている。

3イベントの目的・時間枠・参加者・検査対象

ここまでの内容を1つの表に並べ直す。

タイムボックスをスプリントの長さに合わせて計算する

スクラムガイドが明示する数値は「1か月のスプリントの場合」の上限で、それより短いスプリントではイベントは通常より短くなるとされているが、具体的な時間数までは定めていない。実務では、ガイドが示す1か月あたりの上限を基準に、スプリントの長さに比例させて割り当てる考え方が使われる。

以下は、4週間を1か月の目安とし、スプリントレビュー4時間・レトロスペクティブ3時間を基準に比例計算した数値である。スクラムガイドが定めた数値ではなく、比例計算による目安である点に注意して扱う。デイリースクラムは長さに関わらず15分のまま変わらない。

よくある形骸化パターンと、ズレの正体

3つのイベントで起きやすい形骸化を、原因とセットで整理する。

誰が何を決めるか：役割と権限の境界

3イベントの運用でしばしば曖昧になるのが、誰が最終的に決めるかである。スプリントレビューで出たフィードバックを受けてプロダクトバックログをどう調整するかは、最終的にプロダクトオーナーの判断になる。またスプリントの状況が大きく変わり、設定したスプリントゴールが意味を失った場合にスプリントを中止（キャンセル）できるのはプロダクトオーナーのみで、他の役割にその権限はないとスクラムガイドに明記されている。

レトロスペクティブで特定した改善についても、実行するかどうかを最終的に判断するのは開発者を含むスクラムチーム自身である。スクラムマスターは改善が実行される環境を整える役割であり、改善内容を上から決める立場ではない。役割ごとの責任範囲を運用ルールとして先に共有しておくと、イベントの場で権限の押し付け合いが起きにくくなる。

3イベントをつなぐ運用手順

ここまでを、スプリント内で踏む順序として並べ直す。