ブログ

みなさんこんにちは、@ryuzeeです。

スクラムにおいてはフィードバックが重要です。プロセスに対するフィードバックはスプリントレトロスペクティブ、プロダクトに対するフィードバックはスプリントレビューを活用します。

今日はスプリントレビューについて、一般的な手順や注意点を紹介します。 なお、あくまで一般的な手順であることに注意してください。スクラムの基本は「透明性・検査・適応」です。自分たちで随時やり方を検査して、もっとうまくできるように適応していかなければ効果はあがりません。

スライドはこちらをご参照ください。

1. スプリントレビューの目的

まず最初にスプリントレビューの目的を再確認しておきましょう。 スクラムガイドの2020年版では、スプリントレビューを以下のように定義しています。

ざっくりまとめると、スプリントレビューの目的は、インクリメントを提示することでフィードバックや協力を引き出し、リスクを減らしプロダクトの価値の最適化を進めることです。 フィードバックを踏まえて、プロダクトバックログアイテムを追加したり削除したり順番を入れ替えたりして、限られた時間や予算の中で価値を最大にできるように向かう先を修正していきます。 つまり、スプリントレビューは単なる進捗報告会ではありません。

2. スプリントレビューの参加者

スプリントレビューの参加者は、スクラムチームと、そのプロダクトに関わるステークホルダーです。

ここで重要なのはステークホルダーです。ステークホルダー不在で、スクラムチームだけでスプリントレビューを行っても不十分です。

例えば、ステークホルダーには、顧客やユーザー、プロダクトマネージャー、企画、マーケティング、営業、サポート、QA、連携先システムの担当者、自分の部門のマネジメントの人などが含まれます。 いつも関係者全員を呼ぶのではなく、その時のスプリントゴールやプロダクト全体の進捗にあわせて、必要な時に必要な人を呼べば良いでしょう。 パフォーマンスが高くないチームが、忙しいステークホルダーを毎週呼んでデモを見せようとしたら、途中から来なくなってしまいます。

なお、これらのステークホルダーがスプリントレビューにどうしても来られない場合や、顧客やユーザーのフィードバックが必要な場合は、プロダクトオーナーを始めとしたスクラムチームは直接時間を取って訪問しフィードバックを貰っても構いませんし、そうすべきです。

3. スプリントレビューのアジェンダ（例）

実際にスプリントレビューのアジェンダがどのようなものになるのか見てみましょう。あくまで一例なので、組織やプロダクトに応じて変更を入れたり、スプリントレトロスペクティブでスプリントレビューのやり方自体も見直していってください。

1. チェックイン、目的の共有

• まず、簡単にスプリントレビューの目的やタイムボックスやワーキングアグリーメントを説明します（例えば、携帯電話をマナーモードにする、アプリの通知をオフにする、発言時以外はマイクをオフにする、など）
• 開発者にとってはステークホルダーとの数少ない接点なので、そのステークホルダーが初参加なのであれば、参加者がそれぞれ名前や役割などを自己紹介します

2. プロダクトとプロダクトゴールの紹介

• 初めて参加する人もいるので、プロダクトビジョンや誰向けのどんなプロダクトなのかを紹介します
• プロダクトゴールを説明します

3. プロダクトを取り巻く状況の共有

• プロダクトそのものの状況を共有します。この場で取り上げることが有効だと思えることなら何でも構いません
• たとえば、直近リリースした機能の利用状況、マーケットの変化、競合の特筆すべき動き、セールスパイプラインの状況、新規顧客の状況などが該当します

4. スプリントの概要の共有

• 今回のスプリントのスプリントゴールがどのようなもので、なぜそのゴールになっているのか、どのように重要なのか、誰にとって役に立つのかなどを説明します
• スプリントゴールを踏まえて、今回のスプリントで選択したプロダクトバックログアイテムを共有し、完成しているものは何かを説明します
• スプリント中に分かった大きな課題や状況の変化を共有します。ステークホルダーによってはそれによって大きな影響を受ける人がいるかもしれません。その場合はなんらかのフィードバックが得られるはずです

5. インクリメントのデモとフィードバック、Q&A

• デモをするのは完成したインクリメントです
• 必ずしもすべてのインクリメントのデモをしなければいけないわけではありませんが、透明性は信頼を醸成するので、重要なものについては確実に見せるようにします
• デモを誰がやるのかについて特に決まりはありませんが、プロダクトオーナーはイベントを進行したり議論に参加したりする必要があるので、開発者にやってもらった方が進めやすいかもしれません
• デモの説明や操作は作り手の視点よりも実際のユーザーの視点である方が好ましいと言えます。ステークホルダーもその視点で見るからです
• デモの操作をステークホルダーにやってもらってもよいでしょう
• スプリントレビューの参加者が自由に触れる環境を用意しておくのも良い手です（規模が大きい場合は、複数のデモ環境や端末を用意しておき、参加者が歩き回って触れるようにすることもあります）
• ステークホルダーによってはコンテキストが分からないこともあるので適宜補足しながら進めます
• ステークホルダーはデモに対して質問したり、フィードバックしたりします
• スクラムチームのメンバーは質問やフィードバックの内容を書き留めておき、あとで参照できるようにします

6. 今後の見通しや直近のスプリントでやろうとしていることの共有

• プロダクトゴールに対する進捗や、特定のマイルストンに向けた着地の見通しなどを共有します
• 次回のスプリントの予定を共有します
• 必要に応じて、今回のスプリントレビューの内容や環境の変化などを踏まえてステークホルダーを交えて今後の予定を議論します。その結果としてプロダクトバックログを調整することもあります

7. まとめ

• スプリントレビューの内容を簡単におさらいします
• スプリントレビューの進め方自体に対するふりかえりを行い、次回より良いスプリントレビューを行うためのヒントを収集します

（8. お祝いをする）

• プロダクトゴールを達成したり、大きな成果を上げたりしたときにはお祝いするのもよいでしょう

4. スプリントレビューの事前準備

スプリントレビューのアジェンダの例を見ると、事前準備が必要であることが分かるはずです。 スプリントレビュー自体はフォーマルな会議ではないので、過度に準備しすぎてはいけませんが、準備をしなさすぎると、折角集まってくれたステークホルダーの時間をムダにし、フィードバックも得られなくなってしまいます。 準備の目安はおおよそ1時間程度と考えておくと良いでしょう。

主な準備の内容は以下のようなものです。

• プロダクトオーナーは事前にプロダクトバックログアイテムが完成しているかどうかを把握しておく
  • 完成したインクリメントがデモの対象となるので、プロダクトオーナーはあらかじめプロダクトバックログアイテムのそれぞれが完成しているのか完成していないのかを把握しておく必要があります（プロダクトオーナー自身が実物を確認して把握することが多いですが、作業自体は委任できます）。なおスプリントレビューの前日や当日にまとめてやろうとすると多くの場合は辛いことになります
• スプリントレビューでのデモ手順やシナリオの確認
  • デモ用の端末やデモ環境にプロダクトを入れて、動作するかを確認しておきます
  • また、複数人で連携してデモする場合には役割分担を決めておきます
• 最新のプロダクトバックログ
  • 適宜プロダクトバックログリファインメントをしていれば問題ないと思いますが、最新版を用意しておき、次のスプリントで検討している内容や今後の見通しなどを説明できるようにしておきます
• プレゼンテーションなどの簡単な説明資料の準備（必要であれば）
  • アジェンダ、プロダクトバックログの説明、この後の予定の共有などで資料があった方が良い場合は簡単に作っておきます。あくまで非公式な資料なので凝りすぎないようにします
• ステークホルダーの招集
  • これが非常に重要です。プロダクトオーナーはどのステークホルダーを呼ぶか判断して事前に調整しておいてください。頻繁に来てほしいステークホルダーの場合は最初に先の予定まで確保しておいて、不要な場合はキャンセル通知をするような運用が楽です。なお、通常はスプリントプランニングの時点で、スプリントレビューに誰を呼びたいかは明らかになるはずです

5. ステークホルダーへの質問（例）

スプリントレビューでは、ステークホルダーからの意見やフィードバックを貰います。 何も言わなくてもたくさんのフィードバックをくれる人と、そうでない人がいますので、状況を踏まえて定形的な質問パターンを使うのも良いでしょう。例えば以下のようなものです。

• ユーザーの課題を解決するか？
• 気に入ったか？
• いちばん気に入った箇所と、いちばん気に入らなかった箇所はなにか？
• プロダクトを成功させるために変えたらよいことがあるか？
• ビジョンはまだ有効か？
• 機能不足、過剰な機能があるか？
• 機能の間違いはないか？
• 見た目の調整が必要か？
• そう思うのはなぜか？

6. 良いスプリントレビューの特徴

良いスプリントレビューは見ていてわかります。 どのようなスプリントレビューがよいのか特徴を紹介します。

1. 利用者の体験をレビューしている

「●●機能」「■■機能」のような機能を主軸にしたレビューにすると、フィードバックの質が低下します。 つまり機能単体で見て、もっと色々なことができるようにしたい、もっとオプションを増やしたい、競合と比べて機能が少ないのでどうにかしたいといったフィードバックになったり、なんとなく「いい感じ」というようなフィードバックになったりします （酷いところだと、機能単位で見せて、本当に完成しているかを確認してマルバツを付ける謎の儀式になっていることもあります）。 これではプロダクトの将来に対して有益なフィードバックにならないのは言うまでもありません。

利用者の視点でレビューし、利用者が抱えている課題が本当に解決できそうなのか、もっとうまく解決できる方法はないのか、もっと使いやすくするにはどうするのか、現状で利用者にとって十分なのか、十分ではないとしたら何が足りないのかを議論できると、プロダクト自体に対するフィードバックの精度が上がります。

2. 建設的なフィードバックがたくさん集まる

ステークホルダーが謎の強権を持っていて一方的にああしたい、こうしたいと伝えるような場になってしまうと、ほかの人はフィードバックしにくくなります。 また、フィードバックによって自分たちの作業の増加に繋がる環境（謎のスコープ保証など）だと、フィードバック自体が個人にとっては有益でなくなるので、何も言わないか、対応が簡単なフィードバックだけしかしなくなります。

スプリントレビューでのフィードバックは、あくまでプロダクトをよくするための意見であり、命令でもなければ確定事項でもありません。 フィードバックに取り組むかどうか、いつやるかは最終的にはプロダクトオーナーの判断です。 それをスプリントレビューに参加するステークホルダーにも理解させておく必要があります。 あるチームでは、スプリントレビューの冒頭で、スクラムガイドの該当箇所を全体に向けて説明していました。 どんな種類のフィードバックが欲しいのか、貰ったフィードバックをどう扱うかを事前に説明しておくことで、その場の目的にあったフィードバックが得られやすくなります。

3. 参加者みんなプロダクトの中身に関心を持っている

こんなの当たり前だと思うかもしれませんが、そうでもない場合もあります。 たとえば、上から押し付けられた（どう考えても）イケてないアイデアを実現する責任をスクラムチームが負わされている場合や、人が足りずにスクラムチーム自体が寄せ集めの混成チームになっていている場合などです。 もしくはプロダクトが成功しようが失敗しようが自分に痛みがない場合も、プロダクトの中身に関心を持つのは大変かもしれません。

逆に自分たちが使いたいと思うようなプロダクト、実現したいビジョンに共感できるようなプロダクトであれば、みんな中身に関心を持つようになります。 中身に関心があればフィードバックの質も頻度も増えるので、プロダクトは良い方向に向かいます。

4. プロダクトの現状とこの先が分かる

ステークホルダーの関心事はプロダクト単体の話にとどまらず、プロダクトや機能のリリース時期、営業やマーケティングの方法、サポート体制の構築、収益などさまざまです。 つまり、アジャイルチームが持続可能なペースで進めていて、プロダクトの現状と今後の見通しが分かることで、ステークホルダーはスクラムチームの外側の仕事を進めやすくなります。逆にステークホルダーの状況がスクラムチームに伝わることで、それを踏まえてプロダクトバックログの並び順を変えたり、リリース戦略を考え直したりすることでできるようになります。 私たちは作る人、あなたたちはそこから先どうにかする人という関係性ではありません。

5. チームがこの場を良いものにするために協力しあっている

たまにスプリントレビューで、プロダクトオーナーがステークホルダーからの質問への回答で困っていたり、デモの途中で手順がわからなくなったりしているのに、ほかの人たちは黙ってみている状況に遭遇することがあります（晒し者です）。 もしくはスクラムチームの特定の人だけが延々と喋り続けていることもあります。 こういった状況はあまり健全ではないかもしれません。

スプリントレビューは忙しいステークホルダーを呼んで行うイベントなのでなるべく多くの成果が出るようにしたいので、そうなるように全員が協力するのが理想です。 誰かが困っていれば助け舟を出すのは当たり前で、黙っていてはいけません。 なお、スクラムチームが、素晴らしいものがスプリントで作れたと思えていれば、スプリントレビューでみんなで自慢してください。

6. 明るく楽しい

上からの命令で「アジャイル」のようなやり方を理由もわからずにやっているチームは、暗くてつまらないと思います。 暗くてつまらないチームや仕事で成果を出すのは難しいです。 前述の1〜5ができていれば、少しは明るく楽しく仕事ができるようになります。 またこれができているチームであれば、度合いの差はあっても1〜5はある程度できていると言えるでしょう。

7. スプリントレビューのアンチパターン

ここからはよくあるアンチパターンを見ていきましょう。

スプリントレビューをキャンセルする

そのスプリントで何も完成しなかった場合、スプリントレビューをキャンセルしたくなるかもしれませんが、スクラムではイベントをスキップしません。 何も完成しなかったというのも1つの重要な情報です。それによって今後の見通しが変わるかもしれないですし、その状況を解決するためのフィードバックが得られるかもしれません。また、インクリメントのデモはスプリントレビューの1要素に過ぎません。プロダクトゴールに対する進捗、環境の変化、今後の方向性について話し合うことはインクリメントの有無に関わらず重要です。 もちろん、今まで完成させたインクリメントを再度デモしても構いません。 このようなスプリントレビューは心苦しいかもしれませんが、そのような思いをしたくないのであればスプリントレビューでインクリメントを提示できるように、自分たちの進め方を改善しましょう。

事前準備をしていない

スプリントレビューでは完成したインクリメントを参加者に見せて、フィードバックを得ることが非常に重要です。 そのためには、どのような手順でデモをするとよいかのシナリオを考えたり、どの箇所で意見を貰うかを考えたり、全体像を説明したりといった事前準備が必要です。

プロダクトオーナーがステークホルダーを招集していない

たくさんの時間とお金を使ったあとに、それがムダになるようなフィードバックを貰いたくないはずです。しかるべきステークホルダーを選んで適宜呼ぶようにしてください。いつも同じステークホルダーを呼ぶ必要はありません。プロダクトの状況やスプリントゴールに応じて、誰を呼ぶと効果的なフィードバックが得られるかを考えてください。 もしスプリントレビューにステークホルダー不在の状況が続くのであれば、スクラムマスターは手を打つべきです。

スライドやスクリーンショットでデモをしている

完成の定義を満たしていて、完成しているインクリメントをデモすることによってフィードバックを得るのが重要です。 これはスクリーンショットやプレゼンテーションでは代用できません。 実物が目の前にないと真剣に考えられないものですし、操作性や速度、細かい動きなどを伝えることもできません。 スプリントレビューでインクリメントを見せられるように、計画、実行していく必要があります。

完成していないものをデモしている

何も完成したものがない状態でも、なんとかスプリントレビューでフィードバックを貰いたいという気持ちは分かりますが、やめておいてください。 動いていないもの、中途半端なものを見せるとフィードバックの質も下がりますし、スクラムチームに対する信頼もなくなります。 スプリントレビューではスクラムチームが完成させたものを自慢するくらいの感じで進めるのが理想です。

雑なデモデータを使っている

これはスプリントレビューというより開発全体に言えるかもしれませんが、デモに使うデータは実際のプロダクトのデータになるべく似たデータを使うようにしましょう。 雑なデモデータを使うと、参加者の真剣さが阻害されて有効なフィードバックが得られなくなったり、適切なデータを使っていれば気づけたことを見逃したりしてしまう可能性があります。

完成したものと完成していないものをスプリントレビューで識別している

スプリントレビューは受け入れ確認の場ではありませんし、前述のとおり動かないもの、正しくないものを多くのステークホルダーに見せる意味もありません。なおステークホルダーが受け入れ可否を決めるわけではなく、それを決めるのはスクラムチームです。もしステークホルダーの承認のようなものがないと完成に至らないのだとすると、適切な権限委譲が行われていない可能性があります。

スプリントレビューが進捗確認会議になっている

全体の見通しの共有自体は重要であることは間違いありませんが、主目的はプロダクトの価値を高めるためにフィードバックを受けることです。もし進捗確認会議が必要なら、プロダクトオーナーとスクラムマスターあたりが別の会議を設けると良いと思います。

スプリントレビューがステークホルダーの承認イベントになっている

スプリントレビューはインクリメントを提示し、フィードバックを収集し、今後のプロダクト開発に活かすために行うものです。プロダクトについての意思決定はプロダクトオーナーにある程度委ねられていなければ、プロダクト開発は遅々として進みません。 組織のプロセス上どうしてもステークホルダーの承認が必要なら、スプリントレビューとは別の場所で行うようにしましょう。

最新の情報を使って今後の見通しなどの話し合いをしていない

ステークホルダーの一部、たとえばマーケティングや営業の人などは、ある機能がいつリリースされそうかということに対して強い関心を持ちますし、彼らの仕事はリリースに対する依存関係があることが多いです。見通しを共有しないとビジネス全体から見た最適化ができなくなってしまうので、短時間で良いので今後の見通しを話すようにします。

得られたフィードバックを記録しない

プロダクトの方向性や今後を適応するためにフィードバックを集めるので、あとで検討できるようにフィードバックは記録しておきましょう。記録するのは誰でも構いませんが、プロダクトオーナーは司会・進行を担ったり、議論の中心になったりすることが多いので、それ以外の人がよいでしょう。

フィードバックへの対応を約束してしまう

フィードバックを得ること自体はとても重要ですが、時間もお金も有限です。フィードバックにいつどのように対応するかについては、プロダクトの全体性を踏まえて考えなければいけません。したがってスプリントレビューでフィードバックを受けたときに「わかりました。次のスプリントで対応します！」のような約束はしないでください。

それでは。