スプリントレビューで困っていることとそのアプローチについて考えてみる

はじめに

はじめまして。フクロウラボという都内のベンチャー企業で働く vanilla.dev と申します。
現在の会社には、フロントエンドエンジニアとして入社し、現在はスクラム開発を行う開発チームでプロダクトオーナーを務めており、ざっと以下のようなことをしています。

• 開発ロードマップの策定

• ユーザーインタビュー

• ステークホルダーと協働し、開発優先度の決定

現在務める会社には明確にプロダクトマネージャーという職種がないので、エンジニアとして採用はされましたが、現在はプロダクトオーナーとして、プロダクトマネジメント領域の仕事をさせてもらっています。

スクラム開発をしていると、スプリントの最後にはスプリントレビューが待ち受けているとおもいます。
スプリントレビューで思ったようにコミュニケーションがとれない、などの悩みを抱えているプロダクトオーナーは多いのではないでしょうか。

かくいう僕もその一人で、プロダクトに関わるステークホルダーを大勢招集したはいいものの、あまり活発な議論ができずに、どうしたものかと悩んでいます。

悩みと、悩みに対する解決策を僕なりに考えてみようと思います。

スプリントレビューの目的がステークホルダーに伝わりきれていない

スプリントレビューで困っていることのはじめにこれを挙げます。
各所から大勢のステークホルダーをスプリントレビューに招待したはいいが、ステークホルダー自身がスプリントレビューの目的や振る舞いについてよくわかっておらず、どうしていいかわからない、というものです。
これは、僕自身も直面している大きな問題です。
組織全体までスクラム開発の目的やライフサイクル自体が伝わっていない、などの原因が考えられるが、プロダクトオーナーとして小さく始められることから考えたいですね。

解決策：事前説明会を開く

簡単にできそうなことはスプリントレビューの目的や期待する振る舞いについて、ステークホルダーに説明会を開くことです。
早ければ 15 分もあればできそうだし、事前に我々開発チームがステークホルダーに期待することを伝えるだけでだいぶ違いそうです。

以前、ユーザーストーリーマッピングのやり方や目的についてスクラムマスターが説明会を開いてくれたことがありましたが、説明会をした後は、ユーザーストーリーマッピングでステークホルダーと活発にコミュニケーションができました。

自分で言うのもあれですが、プロダクトオーナーは常に何かと忙しいので、プロダクトオーナー自身が説明会を開くのが厳しいのであれば、スクラムマスターに相談し、説明会の開催を依頼するのもいいかもしれないですね。

出席しているだけのステークホルダー

僕の務める会社では、スプリントレビューにはステークホルダーが 10 人くらい集まることも多いです。
10 人も集まれば、多種多様なロールの色々な権限のステークホルダーが集まります。
このときに問題になるのが、役員やマネージャークラスの権限の大きなステークホルダーのみが発言し、メンバークラスのステークホルダーの発言が少ないことです。

解決策 1 ：名指しで聞く

これが一番簡単ですぐできることかなと思います。
今までステークホルダー全員に向けて、「いかがでしょうか？」とざっくり聞いていたのですが、「〇〇さんはこの改修についてどう感じましたか？」と聞いてみるのが即効性があっていい気がします。

解決策 2 ：ステークホルダーと雑談の機会を増やす

上記で解決しない場合の解決策です。
スプリントレビューという公の場での発言がなかなかできないような方からの意見を聞きたいときはクローズドな場での意見交換の機会を増やすのがいいです。
プロダクトオーナーは、チームと会話するのと同じくらいステークホルダーと会話せよ、と言われているくらいなので、積極的にステークホルダーとの会話の機会を増やすのがいいと思います。
効果を得るには長いスパンで見る必要はあると思いますが、少人数のミーティングで軽くアイスブレイクの雑談を交えて関係値をコツコツ築きつつ、サービスに対するフィードバックを吸収できる機会を増やしていくのがいいのではないかと思います。

「いいと思います」しかフィードバックがもらえない

上記と併発した悩みではありますが、意見やフィードバックを求めても、このような回答しか返ってこない、というものです。
「いいと思います。」というざっくりとした回答では、強く賛成しているのか、仕方なく同意しているのかがわかりません。

解決策：Disagree & Commit

これは最近読んだ、O'Reilly から出版されている プロダクトマネージャーのしごと に書いてあったプラクティスです。Intel や Amazon でも使われているプラクティスのようです。

簡単にいうと、議論する時は立場も関係なく反対だったら反対（Disagree）を明確に主張して、でも、決まったら決まったことに従ってチームとして全力を尽くす（Commit）というものです。
判断を下すときには、参加者全員が具体的で積極的なコミットメントを示すような会議体にします。
質問や懸念点があったら共有し、ためらいがあるならやめておく、Yes ならコミットする、というとてもシンプルなものです。
Intel や Amazon も使っているからおれたちもやってみよう！と言いやすいのもいいかなと思います。

まとめ

スプリントレビューで悩んでいることとそれに対する解決策を書いてみました。
どれも簡単なものではありますが、簡単なことでもなかなかできていなかったりするものです。（事実僕がそうだったりします。）
クリティカルな悩みに対して、一番簡単にできて効力がありそうなものから初めてみるのがいいのではないでしょうか。
僕と同じく悩めるプロダクトオーナーに届けば嬉しいです。