スプリントレビューで「何を検査するか」— “動くか？”から“価値があるか？”へ —
このメモは？
スプリントレビューが単なる「作ったものの動作を確認する場」になっていたりして「スプリントレビュー、意味あるのかな？」という声を時々聞きます
整理した今の考えは「絶対にこうしなければならない」というものではありませんが、いろいろなチームを見てきた中で、本来のスプリントレビュー、そしてスクラムの価値が出やすいのではないかと思っていることです スプリントレビューではよりなにに集中して検査すると効果的になるか？
スプリントレビューでは以下の3つのうちに「自分たちの仮説はどうか？/課題は解決するか？」と「プロダクトゴールはこの先はどうなりそうか？」の2つにより集中して検査すると、場がより効果的になると考えます。
1. その機能が想定通りできているか？ → これはスプリントレビュー前にスクラムチームで済ませておく
2. 自分たちの仮説はどうか？/課題は解決するか？ → 実際に使う人などステークホルダーに使ってもらい、それをチームが観察し、会話することで検査する
3. プロダクトゴールはこの先はどうなりそうか？ → ここまでの進み、フィードバックをもとにプロダクトゴールへの距離感、プロダクトバックログをアップデートする スプリントレビューを単なる「動作確認会」にせず、価値の検査と未来の方向の検査に集中すると効果的な場になると考えています。
1. その機能が想定通りか？
これはスクラムチームがスプリント中に責任を持って検査しておくことで、スプリントレビューの場でやることではないと考えています(プロダクトオーナーもスクラムチームの一員です)。 自分たちが完成した機能するソフトウェアをスプリントレビューで提示して後述の「自分たちの仮説はどうか？/課題は解決するか？」を検査するために集中します。
当たり前に動くかどうか自体はスクラムチーム(特に開発者)の責務ですが、スクラムチームが見落としていることにステークホルダーが気づくこともあります。
2.課題は解決できるか？
より大事なのは、スプリントのインクリメントが自分たちの仮説はどうか？/課題は解決するか？です。
スクラムチームはステークホルダーの反応や実際に触る様子を観察して、彼らと会話することで学ぶことでフィードバックを獲得します。ステークホルダーは、率直に「これなら課題が解決しそうだ」「まだ足りない」といったフィードバックをします。 このやり取りが、スプリントレビューの本来の価値の1つと考えています。
3.プロダクトゴールはどうなるか？
最後に検査すべきは、プロダクトがこの先どうなるかという方向性です。このスプリントのインクリメント、進み具合、わかったこと、得られたフィードバックを元にプロダクトゴールを検査します。プロダクトゴールへの距離、次に取り組むテーマや方向性、時にはプロダクトゴール自体を変えるかどうかといったことです。
プロダクトゴールの検査、ステークホルダーとスクラムチームとの会話で進んでいくことが多いです。
3つの観点の検査を表にまとめてみた
これらの3つの観点を、誰が、いつ、何をすべきか、以下にまとめました。
table:table
検査する観点 主な内容 誰が中心？ アウトプット
その機能が想定通りできているか？ 完成の定義の充足、動作確認、品質 スクラムチーム(スプリントレビュー前に完了しておく） 完成済みのインクリメント
自分たちの仮説はどうか？/課題は解決するか？ 利用者の課題への影響、仮説の検証 ステークホルダー(実際に使ってみる)＋チーム(観察する) フィードバック、インサイト(示唆)のヒント
プロダクトゴールはこの先はどうなりそうか？ プロダクトゴールの検査と方向性の更新 両者(ステークホルダー＋スクラムチーム) 調整されたプロダクトゴール、プロダクトバックログ
まとめ
もしスプリントレビューが「その機能が想定通りできているか？」を確認するだけの場にとどまるのではなく、作った機能が価値を生むのか、課題を解決するのか、そしてプロダクトゴールに近づいているのかを検査する場にすることこそが重要です。その視点を持ってスプリントレビューを進めていくと、本来のスクラムの価値が発揮されるのではないでしょうか。