はじめに
グロービスではアジャイル開発が推奨されていて、ほとんどのチームでスクラムでソフトウェア開発をしています。
スクラムを取り入れてから3年ほど経つので、僕がハマったスプリントレビューの課題と解決方法を書いていきます。
この記事で伝えたいこと
スプリントレビューの価値を高めるために、僕の失敗談をもとに有効なアプローチを知ってもらうこと。
初歩的な内容から罠っぽい内容まで、課題と解決策を書きました。
（後半にいくほど効果が高いと感じたアプローチを書いているので、ぜひ読んでください。）
注意事項
課題と解決策一覧にある「課題」部分は、個人や特定の役割に問題があるわけではありません。
問題があるのはあくまでプロセスなので、解決策もプロセス改善を書いています。
ぶちあたった課題と解決策一覧
1. インクリメント（成果物）がコレジャナかった
POがスプリントレビューにてコレジャナイことに気づいてしまうことがありました。
エンジニアとPOで認識があってないのは悲惨でした。
初期の頃の失敗ですが、当時は「スプリントレビューって地獄じゃん」と思ってしまいました。
課題
スプリントレビューで、POレビュー（受け入れ確認）してしまったこと。
解決策
スプリントレビューの前日までには、POレビューを終わらせておくこと。
POレビューが終わったもののみ、スプリントレビューを行うこと。
2. ステークホルダーが全然集まらなかった
課題
毎週ステークホルダー全員を招待していたため、
ステークホルダーとしては、集まったはいいけど自分にあんまり関係なかったわ・・と感じた（と思います）。
解決策
スプリントレビューの内容に合わせて、対象者を強調しました。
以下の様なイメージです。
「今回は○○をレビューするので、特にオペチーム参加お願いします！」
複数トピックがある場合は、ユーザーストーリーごとに、誰に見てほしいかを記載しています。
3. ステークホルダーがいない状態で、スクラムチームだけでスプリントレビューしていた
スクラムイベントの目的を忘れてしまったときに起こりがちだと思います。
とりあえずスクラムイベントを回したいという気持ちは危ないですね。
課題
スプリントレビューの目的の1つである、フィードバックの獲得ができなくなります。
解決策
スクラムの勉強会を行い、スプリントレビューの目的を再確認しました。
4. インクリメントが出せなかったのでスキップしつづけて、月に1回くらいのペースで開催していた
特に中~大きめの機能開発をするときに起きていました。
スプリントレビューは基本的にはスキップせずに、毎週開催していきたいですね。
課題
スプリントレビューの開催頻度が減り、フィードバックを受ける機会が減ること。
また、あまりにも期間が空きすぎるとステークホルダーからの信頼も失ってしまいます。
解決策
スプリントゴールを設定して、絶対にスプリントゴールを達成するようにチームとしてリソースを集中させました。
5. 専門用語で、システムに重きを置いた説明になっていたため、参加者が理解できない
課題
ステークホルダーは専門用語を知らない方が多いため、置いてけぼりになってしまうこと。
システムのレビューではなく体験のレビューをしたいのにできないこと。
解決策
専門用語は使わずに「体験に重きをおいたレビューにしよう」という話をチームで認識合わせをしました。
6. （リモートスプリントレビューにて）ステークホルダーがフィードバックをいいづらい雰囲気になっていた
zoom chatに全く投稿がないと、質問やコメントをするときに躊躇してしまう人が多かったです。
課題
ステークホルダーが発言のハードルを感じてしまうこと。
解決策
スプリントレビュー開始直後から、「内容に対して質問コメントあったらガンガン教えてください！」などガヤコメントを入れていきます。
実際にフィードバックをもらえたら、しっかりと感謝を伝えてすべて拾うようにしています。
もし拾いきれない場合は、スプリントレビュー終了後にslackなどから回答することもあります。
7. スプリントレビューでもらったフィードバックが的を得ていない
課題
ステークホルダーのそもそもの認識が合っておらず、的はずれなフィードバックが来てしまいました。
解決策
スプリントレビューの前置きに、プロダクト全体についての説明をしました。
また、デモを見せるときに特にレビューしてほしい部分を書くことで、的を得たレビューが増えました。
補足
4番のように、スプリントレビューのスキップが多いとステークホルダーもレビュー内容を忘れてしまうので、
毎週欠かさずスプリントレビューやることが大事だと感じました。
8. スプリントレビューはスクラムマスターがメインでやるものになっている
スクラムマスターがファシリテーションしてくれる場合、自分のパートだけ頑張ろうとしてしまうことがありました。
その結果、せっかくのフィードバックが拾えなかったことがありました。
課題
スクラムマスターがファシリテーションで忙しいときに、スクラムのチームメンバーがサポートに回っていないこと。
解決策
「スクラムチーム全員がスプリントレビューの主催者である」ので、チーム全員でスプリントレビューを運営していこうという認識合わせをチームで行いました。
9. リアリティのないUI・データを使ったため、ステークホルダーが利用シーンをイメージできなかった
エンジニアとしては英語UIやテストデータに慣れているものでも、初めて画面を見るステークホルダーにとってはテストデータはとてもわかりにくいものになります。
課題
ステークホルダーは主に日本人なのに英語UIを見せてしまったり、
テストデータを使っているため、本番環境をイメージするのが難しい状況でした。
解決策
データはなるべく本番に近いものを用意すること。
岸辺露伴先生のありがたいお言葉を置いておきます。
「『リアリティ』だよ! 『リアリティ』こそが作品に生命を吹き込むエネルギーであり『リアリティ』こそがエンターテイメントなのさ」
— ジョジョワールド (@jojo_mania_jojo) December 28, 2020
岸辺露伴
リアリティを言葉に出してきた人がいたら完全に露伴先生の影響受けてます。確実に。 pic.twitter.com/55cZAgIQd8
10. プレゼン・説明が大半を占めるようになってしまった
課題
プレゼンや説明だけでは、ステークホルダーから質の高いフィードバックを引き出すことはできません。
解決策
宮本茂式（と勝手に呼んでいる）スプリントレビューを行いました。
宮本茂式スプリントレビューとは
ステークホルダーに特に説明せずにデモを操作してもらい、それを観察することです。
スムーズにやりたいことができるかを観察します。
少し工夫している点としては、ステークホルダー自身がターゲットユーザーではない場合、ターゲットユーザーであればやりたくなるであろうシナリオを用意しています。
私はゲームを誰かにプレイしてもらうとき、意見を聞いたり、アンケートを取ったりしません。ただ、ゲームをプレイする彼らの目や表情を観察するだけです。彼らは笑っていますか？あるいは苛立っていますか？これは全くもって科学的な方法ではありませんが、そのように私は自分のゲームをテストするのです。
引用元: https://www.gamespark.jp/article/2007/05/09/12148.html
↑は宮本茂式ユーザーテストと呼ばれているそうです。
僕はゲームデザイナーの宮本茂さんを尊敬しているので、
ここから勝手に宮本茂式スプリントレビューと名前をつけました。
11. 操作する人と見ている人の比率が偏って、操作する人・発言する人がプレッシャーを感じてしまう
普通にプロダクトを使うときは、大勢の人が操作画面を見ていることはありません。
課題
プレッシャーを感じている状態で操作をしても、良いフィードバックは得られません。
解決策
バザー型にし、スプリントレビューの最後にフィードバックを集約させる形にしました。
グループ分けすることで、プレッシャーが少ない環境をつくることができました。
おわりに
スプリントレビューの失敗談をまとめてみました。
これからスクラムをやる方・すでにやっている方、なるべく同じ罠を踏まないように参考程度に読んでいただけたら幸いです。
注意事項にも書きましたが、人は憎まず、プロセス改善をやっていきましょう。
地味な解決策に見えるかもしれませんが、僕は泥臭く1つ1つしっかりやっていくことで楽しく盛り上がるスプリントレビューにつながると考えています。
参考文献
スーパーマリオのステージ1-1から学べるUX | UX MILK
スプリントレビュー - Large Scale Scrum (LeSS)