フレームワーク活用ガイドひとことで言うと#
スプリントの最後に、実際に動く成果物をステークホルダーの前でデモし、フィードバックをもらうスクラムイベント。得られたフィードバックを次のスプリント以降のバックログに反映させる。
押さえておきたい用語#
- インクリメント（Increment）
- スプリントで完成したDoDを満たす動作可能な成果物のこと。スプリントレビューでデモする対象。
- フィードバックループ（Feedback Loop）
- 成果物に対するステークホルダーの反応を次の計画に反映する循環の仕組みのこと。レビューの本質的な目的。
- バックログリファインメント（Backlog Refinement）
- レビューで得たフィードバックをバックログアイテムとして整理・優先順位付けする作業を指す。
- ステークホルダー（Stakeholder）
- プロジェクトに影響を与える、または影響を受けるすべての関係者のこと。外部視点を持ち込む重要な存在。
スプリントレビューの全体像#
こんな悩みに効く#
- 作ったものがユーザーのニーズとズレていたことに後から気づく
- ステークホルダーが開発の進捗を把握できていない
- チームが「作って終わり」になり、プロダクトの価値を意識していない
基本の使い方#
スプリントで完成した成果物のデモを準備する。
- 「完了の定義（DoD）」を満たしたアイテムだけをデモ対象にする
- スライドではなく、実際に動くプロダクトを見せることが原則
- デモのシナリオ（操作手順）を事前に用意しておく
ポイント: 未完成のものをデモすると、議論が「これからやること」に流れてしまう。完了したものだけ見せる。
フィードバックをくれる適切な人を招待する。
- プロダクトオーナー、スポンサー、エンドユーザー代表など
- 開発チームだけで閉じない。外部の視点を入れることが目的
- 招待者に事前に「何をデモするか」を伝えておくと効率的
ポイント: ステークホルダーの参加がないスプリントレビューは意味がない。参加しやすい時間帯を選ぶ。
動くプロダクトを見せて、率直なフィードバックをもらう。
- 開発者がデモを行い、ステークホルダーが実際に触る時間も設ける
- 「良かった点」「改善すべき点」「新たに欲しい機能」を引き出す
- フィードバックはすべて記録する（判断は後で行う）
ポイント: 批判を恐れない。厳しいフィードバックこそプロダクトを良くする。
フィードバックをもとに、プロダクトバックログを見直す。
- 新たに見つかったニーズをバックログアイテムとして追加する
- 既存アイテムの優先順位を再評価する
- 次のスプリントの方向性をステークホルダーと確認する
ポイント: フィードバックをすべて次のスプリントでやる必要はない。優先順位をつけて計画的に取り込む。
具体例#
準備: 2週間のスプリントで完成した「ダッシュボード機能」と「CSV出力機能」のデモシナリオを作成。テスト環境にデプロイ済み。
参加者: PO、営業部長（スポンサー）、営業担当3名（エンドユーザー）、開発チーム5名。計10名。
デモ: ダッシュボードの操作をデモした後、営業担当に実際に触ってもらう。
フィードバック:
| フィードバック | 種類 | 優先度 |
|---|---|---|
| 月別のフィルタが欲しい | 新規要望 | 高 |
| グラフの色が見づらい | 改善要望 | 中 |
| CSVのフォーマットが使いやすい | 好評 | — |
| ダウンロード速度が遅い | 改善要望 | 中 |
バックログ更新: 「月別フィルタ」を新アイテムとして追加（優先度:高）。次スプリントで最優先で取り組むことをPOとステークホルダーが合意。
結果: レビューで得た「月別フィルタ」を次スプリントで実装したところ、営業部の利用率が45%→78%に急増。ユーザーの声を直接聞くことの価値を実感。
背景: 東京・大阪・ベトナムの3拠点チーム12名。対面レビューが難しい中、オンラインでの効果的なレビュー手法を模索。
工夫:
- Zoomで画面共有しつつ、Miroの「フィードバックボード」に参加者がリアルタイムで付箋を貼る
- デモは録画してSlackで事前共有。レビュー本番は議論に集中
- 各SHに「1人3枚以上のフィードバック付箋」を依頼
フォーマット（60分）:
| 時間 | 内容 |
|---|---|
| 0-5分 | スプリントゴールの達成状況報告 |
| 5-25分 | ライブデモ（SHが質問しながら） |
| 25-40分 | Miroでフィードバック記入→グルーピング |
| 40-55分 | 上位3テーマを議論 |
| 55-60分 | 次スプリントの方向性確認 |
結果: オンラインでもSH1人あたり平均4.2枚のフィードバックが集まり、対面時の3.8枚を上回る成果。事前動画共有により、レビュー本番の時間を議論に集中できた。
背景: 創業150年の酒蔵がEC機能をリニューアル。開発はベンダーに外注。過去のリニューアルでは「完成品を渡されても使えない」と現場から不満が出た。
改善: 2週間ごとのスプリントレビューに蔵元の女将（事務担当）、出荷担当者、直営店スタッフを招待。開発ベンダーが実際に動く画面を見せながらデモ。
レビューでの発見（抜粋）:
| スプリント | 発見 | 対応 |
|---|---|---|
| Sprint 2 | 「商品名が正式名と違う」（女将指摘） | マスタデータ修正ルールを策定 |
| Sprint 4 | 「出荷伝票の印刷ボタンがわからない」（出荷担当） | ボタンの配置とサイズを変更 |
| Sprint 5 | 「限定品の在庫表示が直感的」（直営店スタッフ） | 好評な在庫UIを全商品に適用 |
成果:
| 指標 | 前回リニューアル | 今回（レビュー導入） |
|---|---|---|
| リリース後の修正要望 | 28件 | 5件 |
| 現場スタッフの満足度 | 2.5 | 4.6（5点満点） |
| EC売上（リリース3ヶ月後） | 前年比+8% | 前年比+35% |
結果: 現場スタッフをレビューに巻き込んだことで、リリース後の修正要望が82%削減。「自分たちの意見が反映されている」という実感がEC運用への積極性につながった。
やりがちな失敗パターン#
- パワポでの報告会にしてしまう — スライドで「やったこと」を説明するだけでは、レビューではなくプレゼン。動くプロダクトを実際に触ってもらうことが大切
- ステークホルダーが不参加 — チーム内だけで「レビューしました」と言っても、外部からのフィードバックがなければ意味がない。必ず外部のステークホルダーを呼ぶ
- フィードバックを記録しない — 良い意見が出ても記録していないと忘れてしまう。その場で書記を決めて、全フィードバックを記録する
- フィードバックをすべて次スプリントに入れようとする — 要望を全部受け入れるとスコープが崩壊する。POが優先順位をつけて計画的に取り込む
よくある質問#
Q: スプリントレビューとレトロスペクティブ（振り返り）の違いは何ですか？ A: スプリントレビューは「何を作ったか（成果物）」をステークホルダーに見せてフィードバックを得る場です。レトロスペクティブは「どう作ったか（プロセス）」をチーム内で振り返り改善する場です。参加者も目的も異なるため、同じセッションに混ぜず別々に開催することが重要です。
Q: スプリントレビューに呼ぶステークホルダーはどう選べばよいですか？ A: 「このスプリントで作ったものに影響を受ける人・意思決定できる人」を基準に選びます。全マネジャーを呼ぶのではなく、機能Aに関係するPOや顧客担当、機能Bに関係する営業担当など機能単位で呼ぶ人を変えても構いません。形式的な全員参加より、関係する人が深く関与できる環境を優先してください。
Q: オンライン開催でスプリントレビューを効果的にするコツは何ですか？ A: 画面共有ではなくステークホルダー自身に操作してもらう「ハンズオンデモ」が効果的です。テスト環境のURLを事前に共有し、参加者自身が触れる状態にしておくことで主体的なフィードバックが引き出せます。また、Miroなどのオンラインホワイトボードでフィードバックを付箋に書き出す時間を設けると意見が可視化されます。
Q: スプリントレビューで出たフィードバックはどう取り込むべきですか？ A: POがすべてのフィードバックをバックログに追加し、次のスプリントプランニング前に優先順位付けを行います。「全部次スプリントに入れる」はNGです。Now/Next/Laterの3区分で分類し、Today（今スプリント修正）→Next Sprint→Backlogに振り分けることで、スコープが崩壊しません。
まとめ#
スプリントレビューは、チームが作った成果物をステークホルダーに見せてフィードバックを得る、アジャイル開発の核心的イベント。動くプロダクトをデモし、率直なフィードバックを集め、バックログに反映することで、プロダクトの方向性を常に正しく保てる。形式的な報告会にせず、対話の場にすることがポイント。