スプリントレビューとは？進め方5ステップとアジェンダ例【2026年版】
アジャイル開発の手法としてメジャーな方法のひとつであるスクラム開発（新しいタブで開きます）。
そのスクラム開発で実施されるイベントの中に、「スプリントレビュー」と呼ばれるものが存在します。
フィードバック内容を今後のプロダクト開発に反映させていくことで、アジャイルのポイントである継続的な改善を実現していきます。
スプリントレビューはどのような位置づけのものであり、どのように進めると効果的なのでしょうか？
また、同じような取り組みであるスプリントレトロスペクティブとの違いを当記事で詳しく紹介します。
まず、スプリントレビューの要点を1枚にまとめると次のとおりです。
| 項目 | スプリントレビューの要点 |
|---|---|
| 目的 | スプリントの成果（インクリメント）をステークホルダーに示し、フィードバックを得てプロダクトバックログを調整する |
| 参加者 | スクラムチーム（プロダクトオーナー・スクラムマスター・開発者）＋ステークホルダー |
| タイミング | スプリントの終盤（スプリント内で最後から2番目のイベント。この後にレトロスペクティブ） |
| 時間の目安 | 1カ月スプリントで最大4時間。2週間なら1〜2時間、1週間なら30分〜1時間が目安 |
| 主なアウトプット | フィードバックの一覧と、それを反映して更新されたプロダクトバックログ |
| 混同しやすいイベント | スプリントレトロスペクティブ（こちらは「チームの仕事のやり方」をチーム内で振り返る場） |
スプリントレビューとは
スプリントレビューとは、スプリントの完了時にその成果をステークホルダーに紹介し、フィードバックを得るイベントのことです。スプリントレビューはスプリント期間中に実施する最後から2つ目のイベントとなります。
スプリントの概要や全体的な流れ、実施すべき各イベントについては以下の記事で詳しくご紹介しております。
関連記事①：アジャイル・スクラム開発の「スプリント」とは？意味とその特徴を解説（新しいタブで開きます）
以後の説明はスクラム開発の概要やスプリントについての理解を前提に進みますのでまずはスクラム開発のイベントや流れから確認したいという場合は以下の記事をご参照ください。
関連記事②：スクラム開発の流れとスクラムイベントについて丁寧に解説（新しいタブで開きます）
スプリントレビューの位置づけ
スプリントレビューは「スプリントの実施内容の共有と今後の方針検討」のために行われるものです。
スプリント期間中、スクラムチームはプロダクトに対して機能開発を進めていきます。
スプリントレビューでは、スプリントを経て完成した成果物（インクリメント）の内容についてスクラムチーム外の関係者であるステークホルダーに紹介し、確認してもらうことで、現在の取り組みがプロダクトゴールに正しく進むためのものとなっているか検査を行います。
スプリントレビューにおいて話し合われた結果を踏まえ、プロダクトゴールに向けたプロダクトバックログの見直しや次回のスプリント内容の検討を行います。
スプリントレビューを実施することでステークホルダーを含めて関係者間の意識を共通化し、プロダクトゴールへ向けてよりよい形で開発を進められるように調整を進めます。
スプリントレビューの目的と必要性
プロダクトの開発においては一般的なステークホルダーとして、プロダクトの利用者や開発のための資金提供者、社内の上司や他部門のメンバー、連携先のシステム担当者など、様々なメンバーが存在します。
これらのメンバーに対してプロダクトの開発状況を共有し、意見をもらうための場としてスプリントレビューを行います。
通常、ステークホルダーは他の業務を抱えており、日々のプロダクト開発に十分に関心を持つことは難しいでしょう。
ステークホルダーにプロダクトの開発状況を伝え、フィードバックをもらう機会としてスプリントレビューの場が有効となります。
スプリント完了時のタイミングでスプリントレビューを行い、関係者の認識を確認することにより柔軟な方針の変更が可能となるのです。
アジャイル型開発と比較されることが多いウォーターフォール型の開発では、一般的にこのような確認のタイミングは要件定義・開発など各フェーズの完了時のみとなります。
開発するプロダクトのスコープ全体に対して順番に各フェーズを進めていくウォーターフォール型開発では、動くシステムとして確認できるのは早くともテストのフェーズからでしょう。
仮にテストの時点で要件定義時から状況が変わり、プロダクトの機能にも変更が必要だと判明しても、全体のスケジュールを遅らせず、他機能への影響も考えながら該当機能だけを大きく変更するということは難易度が高い場合が多いでしょう。
スクラム開発においては、一度のスプリントの中で機能単位で要件定義・実装・テスト・リリースを行うため、スプリントレビューでも実際に動かせる成果物（インクリメント）に対するフィードバックが可能です。
「触ってみたらイメージと違った」「とてもいい機能だから、予定を変更して関連機能の開発優先度を上げた方がユーザーに喜んでもらえるのでは？」などのフィードバックを反映して次回以降のスプリントの方向性を柔軟に修正することもできます。
短いスパンで定期的にフィードバックを行い、プロダクトゴールに向けた改善を行える点は、スクラム開発のメリットです。
スプリントレビューとスプリントレトロスペクティブの違い
スクラム開発のフレームワークの中には「スプリントレビュー」と似ているイベントとして、スプリント完了時に実施する「スプリントレトロスペクティブ」と呼ばれるものも存在します。
両者はどちらもスクラムにおける重要なイベントとして位置づけられていますが、これらはどのような違いがあるのでしょうか。
この章で解説していきます。
スプリントレトロスペクティブとは？
スプリントレトロスペクティブとは、スプリント終了時に実施される「振り返り」のためのミーティングのことを指します。
スプリントレトロスペクティブの目的はスプリント期間中にチームメンバーが感じた課題や改善策を整理し、今後のスプリントに反映させていくことです。
これにより、チームを発展的に高めていくことを目指します。
スプリントレトロスペクティブの詳細については以下の記事で解説を行っております。併せてご覧ください。
関連記事：アジャイル開発におけるレトロスペクティブって何？効果的な振り返りの方法（新しいタブで開きます）
スプリントレビューとの違い
スプリントレトロスペクティブは、スクラムチーム内でスプリントの結果について話し合い、チームの活動を改善していくために行われます。
一方で、スプリントレビューの目的はスクラムチーム外であるステークホルダーに対して今回のスプリントの成果を伝え、フィードバックを得ることにあります。
よって、スプリントレビューとスプリントレトロスペクティブの大きな違いは参加するメンバーとその目的の違いにあります。
- スプリントレビュー：「ステークホルダーを含めたすべての関係者」により「スプリントの成果を共有し、プロダクトゴールに向かうための今後の方針」について話し合う
- スプリントレトロスペクティブ：「スクラムチーム内のメンバー」により「日々のスプリントを進めていく上で課題や障害を共有し、それらを改善する方法」について話し合う
両者の違いを表で整理すると次のようになります。
| 項目 | スプリントレビュー | スプリントレトロスペクティブ |
|---|---|---|
| 目的 | 成果物へのフィードバックを得て、プロダクトの方向性を調整する | チームの仕事のやり方を振り返り、改善する |
| 参加者 | スクラムチーム＋ステークホルダー | スクラムチームのみ |
| 主な話題 | インクリメントのデモ、市場の変化、今後の優先順位 | うまくいったこと・いかなかったこと、プロセスや協働の改善策 |
| 主なアウトプット | 更新されたプロダクトバックログ | 次のスプリントで実施する改善アクション |
| 実施順 | 先（スプリント内で最後から2番目） | 後（スプリント最後のイベント） |
スプリントレビューがプロダクトゴールに向けた関係者全員の会話の場であるのに対して、スプリントレトロスペクティブはチーム内において日々の作業を改善していくための取り組みといえるでしょう。
一般的にはスプリントレビューを実施した後、スプリントレビューの実施内容や実施結果も踏まえてスプリントレトロスペクティブを実施するケースが多いといえます。
スプリントレビューの進め方【5ステップ】
以下では、スプリントレビューの一般的な進め方を5つのステップに分けて紹介します。
ステップ1：レビューの日程・参加者を設定する
まず、スプリントレビューの場を設定するためにステークホルダーが参加できる日程を調整します。
スプリントレビューに参加するメンバーの予定を確保しやすくするためにも、毎月第 Ｘ 水曜日の XX 時からなど、定例として設定することも検討できるでしょう。
スプリントレビューの長さは、スプリント期間に応じて設定します。スプリントが1か⽉の場合、レビューは最⼤4時間程度が推奨されます。
スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多いです。
ステップ2：スプリントで開発した機能確認・デモ準備
スプリントレビューでは、今回のスプリントで開発した機能についてデモなどを行い紹介します。
スクラムチーム内で今回の開発内容がどのようなものであり、どのようなデモを行うのかを事前に確認しておくとよいでしょう。
スプリント中に開発したすべての要素について、十分に時間をかけてデモをすることはレビュー時間枠の関係で難しいこともあります。開発内容のうちどこを優先して確認するかも検討ポイントです。
ステップ3：アジェンダを作成して事前共有する
アジェンダを事前に共有しておくと、ステークホルダーが「今回は何を確認し、何に意見を求められるのか」を把握した状態で参加でき、当日のフィードバックの質が大きく変わります。
以下は、2週間スプリントを60分でレビューする場合のアジェンダ例です。自社の状況に合わせて調整してご活用ください。
| 時間 | 内容 | 主な担当 |
|---|---|---|
| 0〜5分 | スプリントゴールと本日のアジェンダの確認 | プロダクトオーナー |
| 5〜15分 | スプリント結果の共有（完成したバックログアイテム・完成しなかったもの） | 開発者 |
| 15〜35分 | インクリメントのデモ・操作体験 | 開発者 |
| 35〜50分 | フィードバックの収集・質疑応答 | 全員（プロダクトオーナーが進行） |
| 50〜60分 | 市場状況やリリース時期など今後の見通しの共有と、次スプリントへの方向づけ | プロダクトオーナー |
ステップ4：スプリントレビューの実施
スプリントレビューではステークホルダーに対してデモなどを実施することでスプリントの結果を紹介します。
このとき、一方的に内容を紹介するだけではなくフィードバックをもらえるように Q&A セッションを設けたり、デモ中に必要に応じて意見を出してもらったりすることがポイントとなります。
スプリントレビューの実施目的は、ステークホルダーからフィードバックをもらい今後の開発に生かすことにあります。
もし意見が出にくいようであれば、スクラムチーム側からステークホルダーに対して質問を行うことで意見を引き出すことも有効となるでしょう。
ステップ5：フィードバックを踏まえてプロダクトバックログを更新する
フィードバックの結果を受け、今後の開発内容を見直します。
具体的にはプロダクトバックログのアイテム追加・変更や、優先順位の見直しを行うことになります。
たとえば、連携先のシステムの開発状況が遅れており、連携機能の開発を遅らせる必要があるようなケースもあるでしょう。
フィードバック結果は、次回のスプリントプランニングへと生かします。
バックログの見直し・手入れの具体的な方法は、以下の記事で詳しく解説しています。
関連記事：バックログリファインメントとは？目的・進め方・タイミングを解説（新しいタブで開きます）
スプリントレビューのポイント
スプリントレビューのポイント
以下では、スプリントレビューを実施する上でのポイントをいくつか紹介します。
スプリントレビューはワーキングセッションとして行う
スプリントレビューはステークホルダーからフィードバックを得ることが目的の取り組みです。よって、単なるデモンストレーションの場とならないように注意する必要があります。
スプリントレビューは「ワーキングセッション」であるとして位置づけ、積極的に議論できるように質疑応答を意識した時間配分やファシリテーションを行うことがポイントです。
フィードバックは分類してとりまとめる
ステークホルダーから得られたフィードバック内容は、プロダクトゴールに向けた改善の要望、感想やコメントなど多種多様なものとなります。
これらを同じように取り扱うのではなく、内容に応じて「改善点」「コメント」などを分類したうえで「重要度」「期日」などの情報を付加することで、今後のスプリントにおける対応がしやすくなります。
プロダクトの紹介方法はデモに限らない
スプリントレビューにおいて、スプリント期間中の開発内容を紹介する方法は必ずしもデモンストレーションに限りません。たとえば、参加者が実際に操作できる環境を用意することも一案です。
また、開発中のプロダクトによっては物理的に体験できる環境を用意することも検討できるでしょう。
ポイントはステークホルダーのフィードバックを引き出すために、実際にユーザーが体験する形に近いようにプロダクトを紹介することです。
プロダクトの開発状況にもよりますが、デモンストレーションよりも実物を操作できた方がより具体的なフィードバックにつながりやすくなります。
スプリントレビューでよくある失敗と対策
スプリントレビューは「開催すること」自体は難しくない一方で、形骸化しやすいイベントでもあります。現場でよく見られる失敗パターンと対策を紹介します。
| よくある失敗 | 起きること | 対策 |
|---|---|---|
| 進捗報告会になっている | 資料の読み上げが中心となり、フィードバックがほとんど出ない | デモか実機操作を必須にし、「今回どこに意見が欲しいか」を冒頭で明示する |
| ステークホルダーが参加しない | 開発チームだけのレビューになり、方向修正のタイミングが遅れる | 定例化して日程を固定する。参加が難しい回は録画や非同期コメントで補完する |
| フィードバックが反映されない | 「言っても変わらない」とステークホルダーの意見が減っていく | フィードバックをその場でバックログ候補として起票し、次回レビューの冒頭で対応状況を報告する |
スパイスファクトリーの現場でのスプリントレビュー実践例
スパイスファクトリーは、アジャイル・スクラム開発の伴走支援を数多く行ってきました。その中で、1〜2週間スプリントでのスプリントレビューを標準的な形としており、現場で効果を実感している工夫がいくつかあります。
- デモ環境を前日までに共有し、当日はステークホルダー自身に操作してもらう（レビューを「見る場」ではなく「触る場」にすると、具体的なフィードバックが増える）
- フィードバックを「改善要望」「質問」「感想」の3つに分類してその場で記録する（改善要望には重要度を付け、プロダクトバックログ候補としてそのまま起票する）
- レビュー冒頭に前回フィードバックの対応状況を共有する（「意見を言えば反映される」という実感が、次のフィードバックを引き出す）
- 普段開発に関わらない方の参加をプロダクトオーナーから積極的に打診する（クライアントの上長や他部門の方に早い段階で触れてもらうことで、リリース直前の大きな方針転換を防ぐ）
こうした進め方を含むアジャイル開発の支援体制については、アジャイル・スクラム開発支援サービスのページで紹介しています。
スプリントレビューに関するよくある質問（FAQ）
スプリントレビューは誰が主催しますか？
プロダクトオーナーが中心となって開催・進行するのが一般的です。デモは開発者が行い、スクラムマスターはイベントが目的どおり機能するようファシリテーションを支援します。
時間はどのくらいが適切ですか？
スクラムの公式ガイドであるスクラムガイド（2020年版）（新しいタブで開きます）では、1カ月スプリントの場合で最大4時間とされています。スプリントが短い場合は通常もっと短くなり、2週間スプリントなら1〜2時間、1週間スプリントなら30分〜1時間が現実的な目安です。
スプリントレビューとスプリントレトロスペクティブはどちらを先に実施しますか？
スプリントレビュー→スプリントレトロスペクティブの順です。レビューで得たフィードバックやレビューの進行そのものの反省も材料に、レトロスペクティブでチームの仕事のやり方を振り返ります。
デイリースクラムとの違いは何ですか？
デイリースクラムはスクラムチーム内で毎日行う15分程度の進捗同期で、ステークホルダーは参加しません。スプリントレビューはスプリントごとに1回、ステークホルダーを交えて成果物へのフィードバックを得るイベントです。
リモート（オンライン）で実施するときのコツはありますか？
画面共有のデモだけで済ませず、検証環境のURLを事前に配布して参加者自身に操作してもらう、コメントをチャットやオンラインホワイトボードに書き込みながら進める、といった工夫でフィードバックの量が大きく変わります。
適切な振り返りがスクラム開発の質を高める
この記事では、スクラム開発において実施するイベントのひとつであるスプリントレビューについて、その実施方法やポイントについてご紹介しました。
スプリントレビューはスクラムの各イベントの中でも重要度の高いものであり、今後のプロダクト開発をより良い方向に向かわせるためのポイントとなる取り組みです。
スプリントレビューを含め、スクラム開発をうまく進めていくためには、アジャイル・スクラムに関する知見や経験が重要です。
スパイスファクトリーでは、これまで多数のお客さまのアジャイル・スクラムでのプロダクト開発を支援してまいりました。
アジャイル開発でプロダクトやサービスの開発を検討されている方は、アジャイル・スクラム開発支援サービスのページをご覧のうえ、お問い合わせからお気軽にご相談ください。
