スプリントレビュー、ステークホルダーやユーザーとどう関わればいい？─ “とはいえ”シリーズ #1「スプリントレビュー編」（前編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。

「スクラムガイドにはこう書いているし、よくブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこなかったりということはありませんか？
そんな時、ここでのお話が何か一つでもヒントになれば幸いです。

今回のテーマは「スプリントレビュー」です。前編では、スプリントレビューでのステークホルダーやユーザーとの関わり方を中心にお伝えします。

スクラムガイドについて

スクラムは、複雑なプロダクトを開発・提供・保守するためのフレームワークです。1990年代初頭、Ken Schwaber と Jeff Sutherland によって開発されました。
スクラムに取り組む際の拠り所となるのが、スクラムの定義やルールを示した「スクラムガイド」です。2010年に最初のバージョンが発表され、その後アップデートが加えられながら進化し続けています。
全18ページ（2020年版）という小さなガイドですが、目的や理論から実践まで分かりやすくまとめられており、スクラムの本質が理解できるようになっています。

今回のテーマ「スプリントレビュー」について、スクラムガイドにはこのように解説されています。

スプリントレビューの⽬的は、スプリントの成果を検査し、今後の適応を決定することである。
スクラムチームは、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対する進捗について話し合う。
スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成され、⾃分たちの環境で何が変化したかについてレビューする。この情報に基づいて、参加者は次にやるべきことに協⼒して取り組む。新たな機会に⾒合うようにプロダクトバックログを調整することもある。スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにする。
スプリントレビューは、スプリントの最後から 2 番⽬のイベントであり、スプリントが 1か⽉の場合、タイムボックスは最⼤ 4 時間である。スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多い。

出典：スクラムガイド

…とはいえ、実際の現場では大変なことが様々あると思います。ガイド通りには進みませんし、そもそも書かれていないような事態も多々起こります。そうした「とはいえ」に、どのようにアプローチしていけばいいでしょうか。

話し手

〔topic1〕スプリントレビューにステークホルダー（チーム外の人）を呼ぶのって、なかなか日程調整が難しい

中村：
フィードバックを得るためにステークホルダーに同席してもらうのが定石だけれども、実際はスケジュールの都合などでなかなか難しいということですね。

新井：
毎回同じステークホルダーを呼ぶ必要はなくて、スプリントによってゴールやカラーが違うと思いますから、それに合わせて誰を呼ぶかを変えていけるといいんじゃないでしょうか。
もし本当に誰も来られないとなると、スプリントレビューとしてのパワーはどうしても半減してしまいますが、それでもできることはあると思います。カレーライスに例えてお話してみましょうか（笑）

中村：
（笑）カレーライスですか？

新井：
はい。今回のスプリントゴールがカレーライスを作ることだったとして、「レシピ通り、計画通りに作れたからオッケーだよね」ということではないと思うんですよ。
あ、計画通りに作れたことは称え合いましょう。大事です。大事です。
その上で、チームメンバー、スクラムマスター、プロダクトオーナー（PO）も含めて、「自分たちが作りたかったカレーライスって、本当にこの味でいいんだっけ？」と確認することが必要です。

そこで、「いや、もっと香辛料を効かせたカレーライスじゃなくちゃいけないんじゃないか？」というような議論が、チームでできるかどうかですよね。ステークホルダーがいなくても、チームの中でそういう話し合いが自主的にできるとすごく良いなと思います。

中村：
なるほど。たしかにそうですね。
呼ぶことが難しいこと自体が、ある意味でフィードバックとも考えられます。
プロダクトに対する、ステークホルダーの関心や優先度の低さを示すシグナルだと思うので、POやチームのメンバーが、プロダクトの重要性をステークホルダーにもっと伝えていく必要があります。

ステークホルダーからのフィードバックがないことで起こりうる事態を、伝えてみるのもいいですよね。間違ったものを作ってしまう危険性があるとか、そういうリスクを伝えた上で、来てもらえないか打診してみてもいいと思います。

新井：
その現象のもとにある根本的な原因を探った上で、丁寧に対応することが大切ですね。
表面的な部分だけを見て、「ステークホルダーが参加しているからオッケー」と判断するのではなく、より本質的な部分に目を向ける必要がありそうです。

中村：
最初から来てもらえていないのか、それとも途中から来なくなったのかという点もヒントになるかもしれません。
もし以前は来てくれていたのだとしたら、自分たちのスプリントレビューの場に何か要因があるのかもしれません。その辺りも確認してみるといいと思います。

新井：
スプリントレビューの場が、ステークホルダーにとって本当に価値があると感じられているかどうか？　ということですね。

〔topic2〕スプリントレビューにユーザーを呼ぶのは（to Bの場合、セールス部門あたりが難色を示したりして）難しい

新井：
割とよくあるケースだと思いますが、かといって最初から諦めることはありません。「ダメだろうな」を前提にしない方がいいですね。

セールス部門のメンバーの中にも、心理的距離が近い相談しやすい人はきっといると思いますし、社内の利用部門など、なるべくエンドユーザーに近い人に実験的にユーザーの役割をお願いしてもいいですよね。案外積極的に参加してくれることがあります。

上層部の「鶴の一声」で解決してしまうこともありますよね。現場から見ると上層部とは距離感があるかもしれませんが、部長同士だと話が早いというようなことが結構ありますから、いろいろな手段を使ってアプローチできるといいですね。

中村：
セールス部門が難色を示すのには、きっと理由があるはずです。そこを掴むことで、何かヒントを得られることもあると思います。

例えば、「自分たちが会うのも苦労している人たちなのに、スプリントレビューに呼んでしまったら、次に会うのはもっと苦労することになる」という理由で、難色を示されたことが過去にありました。
よくよく聞いてみると、セールス部門はあるプロダクトを売り込んでいる最中で、そこで違う話をされるとユーザーである顧客の関心が逸れるから嫌だ、という事情が見えてきました。
こうしたセールス部門の事情を知っていれば、別のアプローチが考えられますよね。例えば、そのセールスがクロージングした後であらためて話をしてみよう、ということもできるわけです。

相手の関心事に注目することが大事です。新井さんの言うように、「どうせ聞いてくれないだろう」を前提にするのではなく、フラットに捉えられるといいと思います。

to B の顧客も、みんな同じではありません。新しいことが好きで実験的な試みに協力してくれる顧客も結構いたりしますから、セールス部門と普段から関係を築いて「協力してくれそうな方はいませんか？」といった話ができるといいですよね。

部門をまたいで何かを進めるには、普段から関係性を築いているかどうかがカギとなります。スプリントレビューへのユーザーの参加に難色を示されているという状況の裏には、「そもそも普段からセールス部門と話をしていない」という問題が隠れているかもしれません。

新井：
営業の人と一緒に客先訪問する時や、営業の人がお客様からの質問を持ち帰ってきた時など、丁寧に対応できるといいですね。そういう積み重ねによってセールス部門とデベロッパー部門の距離感が近づきますし、困ったときに助け合える関係性が築けます。

ユーザーへの対応を手厚くすれば、ユーザーがファンになってくれて、ファンが増えればセールス部門のエンゲージメントやライフタイムバリューが上がります。そんな風に、同じ目標に向かって一緒に取り組む視点が持てるといいんじゃないでしょうか。

〔topic3〕プロダクトオーナー（PO）が、スプリントレビューの場で初めて開発者が作ったものを見ることがある

中村：
こういうケースでも、やはり「なぜこうなっているんだろう？」と根本的な原因を考えてアプローチするといいですね。
例えば、POが忙しすぎてスクラムチームと一緒に活動できないのなら、より適任な人を選ぶように動くのも1つの手ではないでしょうか。

新井：
POがスクラムチームの活動にどのくらい時間を割けるのかを、見える化するのもいいですね。
キャパシティプランニングの視点を持つことで、解決に向けてより具体的な話ができるようになりますし、問題を引き起こしている背景が見えてきます。POの交代や代理POを立てるなどの方法も視野に入れやすくなると思います。

中村：
とても良いアイデアですね。アジャイル開発では「開発者がどれくらいの時間を使えるか」という文脈でキャパシティプランニングという言葉が出てきますが、POに関しても同じように考えられます。

「ユーザーのところへ会いに行く時間はあるのか」「未来のことを考える時間があるか」「インクリメントをちゃんと見る時間があるのか」というようなPOのキャパシティに関しては、なぜか無頓着になりがちです。そこを見える化すればPO自身も楽になるでしょうし、大変な時に声をあげやすいと思います。

初学者だと「POがスプリントレビューで初めてプロダクトを見る」という状況に違和感を持っていないこともよくあります。特に、POは企画部から来ていてチームメンバーは開発部、というように社内受託のような形になっている現場でスクラムに取り組んでいる場合なんかは、スクラムマスターや社外のアジャイルコーチが、本来のあり方を伝えていく必要もあるんじゃないでしょうか。

新井：
社内研修でもいいですし、そういうことがPOやチームメンバーに認知されると違ってくるでしょうね。

〔topic4〕ステークホルダーからの過剰なフィードバック（鶴の一声）が、プロダクトゴールとは乖離している場合の対応

新井：
ステークホルダーからのフィードバックはありがたいことですが、昨日と今日で内容が違っていたり、インセプションデッキの内容やプロダクトゴールと全然違うフィードバックだったりするとチームが振り回されてしまいますよね。どう対応したらいいでしょうか。

中村：
フィードバックは一旦全部受け止めましょう。それをやるかやらないかはまた別の話です。
このことを、ステークホルダーにも伝えておくといいですね。

フィードバックがプロダクトゴールと違う場合でも、一旦バックログに入れた上で意思決定していくことが大事ではないでしょうか。そうすることをあらかじめチームとして決めておくんです。

一番避けるべきなのは、その場で議論を始めてしまうことです。組織ではいろんな関係性が相互作用しているので、一方的に「プロダクトの方針と違うので」と拒絶してしまうと、うまくいかないことが多いと思います。

新井：
私も、一旦受け止めるのがいいと思います。本当に必要なものであれば、バックログリファインメント（バックログアイテムを見直して優先順位を付けること）で優先度が上がってくるでしょうから、うやむやにするのではなく見える化した上で対応していけるといいですよね。

中村：
バックログリファインメントで、あらためてチームにとって価値がありそうだということになれば、ステークホルダーにもう一度来てもらって一緒に話をすればいいと思うんですよね。チームだけじゃなく、関係者を巻き込んでリファインメントすればいいんです。
そこで、そのフィードバックの背景について詳しく聞いてみると、自分たちには見えていないものが見えていたり、価値のある洞察が得られる場合もあります。

新井：
そこから、みんなで「プチ方向転換」をするのもアリですよね。

中村：
最初のチェックインで、プロダクトゴールとスプリントゴールの両方を共有して進めるのもいいかもしれません。ゴールと違ったフィードバックが来たとき、指摘しやすくなると思います。

新井：
そうですね。ステークホルダーからも「プロダクトゴールを見直さなくちゃならないね」とか「来週一時間くらい、POとスクラムマスターとステークホルダーでプロダクトゴールを見直そうか」という話ができれば、すごく建設的です。

参加者コメント：
フィードバックの投げ方を工夫して、ゴールと異なった意見が出ないようにするなど、できることはありますか？

中村：
話を広げすぎないための工夫としては、「今回はこのスプリントゴールなので、このスプリントゴールに関するフィードバックに絞ってください」という投げ方をしてみるといいですね。
「この時間まではスプリントゴールに対するフィードバックを、最後の5〜10分はプロダクトに関して最近気になっていることなどシェアしたい情報や質問をどうぞ」という説明もいいんじゃないでしょうか。

新井：
個人的には、基本的にフィードバックはどんなことでも発信してもらいたいですね。それを受け止めた上で取り入れるかどうかはまた別の問題なので、「意見が出ないようにする」というのは避けたいかな。

〔topic5〕ステークホルダーに見せるためのデモンストレーション用画面がない場合はどうすればいい？

新井：
画面がない＝デモができないという固定概念があるのかもしれませんね。
ビジネス側や企画部門、セキュリティ担当の方がステークホルダーの場合、画面を見せた方がたしかにフィードバックは得られやすいですが、見せ方で工夫できることはあるんじゃないでしょうか。

中村：
そうですね。動く画面が見せられなくても、例えば管理画面を操作して見せるのでもいいと思います。実際、そういう風に対応している現場もあります。

新井：
コンソール上で操作して見せる場合の注意点としては、見せる相手に合わせた工夫ができるといいと思います。
「エンジニアが黒と白の画面を見せながら説明しているけど、何を言っているのか分からない…」という状況になりがちなので、「これを打って、こういう回答が出ると成功です。では、やってみましょう」という風にストーリーを作って紹介すれば、見ている人たちが置いてけぼりになりません。

中村：
スクラムガイドから読み取れるのは、デモは必須ではないということです。
インクリメントとして完成していることは必要ですが、見せ方は静止画面やログファイルの結果でもいいわけですから、画面を見せるデモに捉われなくてもいいのではないでしょうか。まだまだ工夫する余地があると思います。

後編へ続きます。

スプリントレビュー、どんな風に進めればいい？─ “とはいえ”シリーズ #1「スプリントレビュー編」（後編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにア…

redjourney.jp

関連情報

とはいえシリーズ他、アジャイルやスクラムの実践に役立つイベントを開催しています。

▼イベント開催予定はこちらをご覧ください。

レッドジャーニー | Doorkeeper

redjourney.doorkeeper.jp