nishida “とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。
「スクラムガイドにはこう書いているし、よくブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこなかったりということはありませんか？
そんな時、ここでのお話が何か一つでもヒントになれば幸いです。
今回も、前回に引き続き「スプリントレビュー」がテーマです。後編では、スプリントレビューの見せ方や進め方を中心にお伝えします。
前編はこちら
redjourney.jpスクラムガイドについて
スクラムは、複雑なプロダクトを開発・提供・保守するためのフレームワークです。1990年代初頭、Ken Schwaber と Jeff Sutherland によって開発されました。
スクラムに取り組む際の拠り所となるのが、スクラムの定義やルールを示した「スクラムガイド」です。2010年に最初のバージョンが発表され、その後アップデートが加えられながら進化し続けています。
全18ページ（2020年版）という小さなガイドですが、目的や理論から実践まで分かりやすくまとめられており、スクラムの本質が理解できるようになっています。
今回のテーマ「スプリントレビュー」について、スクラムガイドにはこのように解説されています。
スプリントレビューの⽬的は、スプリントの成果を検査し、今後の適応を決定することである。
出典：スクラムガイド
スクラムチームは、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対する進捗について話し合う。
スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成され、⾃分たちの環境で何が変化したかについてレビューする。この情報に基づいて、参加者は次にやるべきことに協⼒して取り組む。新たな機会に⾒合うようにプロダクトバックログを調整することもある。スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにする。
スプリントレビューは、スプリントの最後から 2 番⽬のイベントであり、スプリントが 1か⽉の場合、タイムボックスは最⼤ 4 時間である。スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多い。
…とはいえ、実際の現場では大変なことが様々あると思います。ガイド通りには進みませんし、そもそも書かれていないような事態も多々起こります。そうした「とはいえ」に、どのようにアプローチしていけばいいでしょうか。
話し手
中村 洋
Yoh Nakamura
株式会社レッドジャーニー
様々な規模のSIerや事業会社でのアジャイル開発に取り組み、今に至る。現在まで主に事業会社を中心に40の組織、80のチームの支援をしてきた。
「ええと思うなら、やったらよろしいやん」を口癖に、チームや組織が自分たちで”今よりいい感じになっていく”ように支援している。
※発表資料 「いい感じのチーム」へのジャーニー、チームの状況に合ったいろいろなタイプのスクラムマスターの見つけ方、アジャイルコーチが見てきた組織の壁とその越え方、など多数。
CSP-SM(認定プロフェッショナルスクラムマスター)・CSPO(認定プロダクトオーナー)
新井 剛
Takeshi Arai
株式会社レッドジャーニー 取締役COO
プログラマー、プロダクトマネージャー、プロジェクトマネージャー、アプリケーション開発、ミドルエンジン開発、エンジニアリング部門長など様々な現場を経て、全社組織のカイゼンやエバンジェリストとして活躍。現在はDX支援、アジャイル推進支援、CoE支援、アジャイルコーチ、カイゼンファシリテーター、ワークショップ等で組織開発に従事。勉強会コミュニティ運営、イベント講演も多数あり。
Codezine Academy ScrumBootCamp Premium、機能するチームを作るためのカイゼン・ジャーニー、今からはじめるDX時代のアジャイル超入門 講師
CSP(認定スクラムプロフェッショナル)、CSM(認定スクラムマスター)、CSPO(認定プロダクトオーナー)
著書「カイゼン・ジャーニー」、「ここはウォーターフォール市、アジャイル町」、「いちばんやさしいアジャイル開発の教本」、「WEB+DB PRESS Vol.111 見える化大作戦特集」
〔topic6〕フィードバックをたくさんもらうと対応が大変…
中村：
フィードバックをたくさんもらうのは決して悪いことではないですよね。それを取り入れるかどうかは、プロダクトゴールや事業の方向性に合わせてプロダクトオーナー（PO）を中心にスクラムチームが判断していけばいいと思います。
新井：
「対応が大変」と思っているのはなぜか？ と考えてみると、何か期待値が合っていないことがあるのかもしれませんよね。「フィードバックを受けて全部やらなくちゃいけない」「リリース間際でデスマーチ状態だ」とか。
「フィードバックはダメ出しではなくグッドインフォメーション」という価値観になれると良いのかな。そうなっていないとしたら、不協和の何かがあるというシグナルなのかもしれません。
中村：
チームが、ある考えに捉われていることもあるかもしれませんね。「偉い人からもらったフィードバックだから対応しなくちゃ」とか。
新井：
フィードバックした側は、案外一週間後には忘れていたりしますからね（笑）。
中村：
そもそもすべてのフィードバックに対応する必要はないということを、スクラムチームだけでなくその関係者たちにスクラムマスターが伝えていくのも1つのアプローチだと思います。
チームは一生懸命プロダクトを作ろうとしているので、自分たちだけではなかなか気づけないこともあります。
新井：
POやスクラムマスターとチームとの間に権威勾配がある状態は、スクラムチームの目指す姿とは距離があるかもしれませんね。
▶▶Message from coaches
- フィードバックはダメ出しではなくグッドインフォメーション。
- 「対応が大変」と感じるのはなぜか？ 背景にある不協和状態にアプローチしてみよう。
- そもそもすべてのフィードバックに対応する必要はない。チームメンバーが気づけない場合は、スクラムマスターが伝えよう。
〔topic7〕ユーザーに見せても反応がない
新井：
まずは、反応がない理由を知りたいですよね。
中村：
本当に関心がない場合もあるでしょうし、あるいは、スプリントレビューに呼ぶ人として適切でない場合もあるかもしれません。
スプリントプランニングの時点で、スプリントの内容に合わせて呼ぶ人をうまく設計できていないと、直前になって「誰に見せる？」という事態になってしまいます。
「みんな忙しいからあの人でいいか」と、全然ターゲットユーザーではない人に声をかけてしまうと、反応は薄いですよね。意外とこういうケースが多いのではないでしょうか。
新井：
レビューする側のスキルにも問題があるのかもしれません。機能だけを紹介しても、関心を持ってもらえませんよね。ユーザーが解決したい物語の中で使い方をデモできれば、ユーザーが持つ使い方のイメージとのギャップもフィードバックとしてあがってくるはずです。
例えば、エクセルのデモをするとしたら、関数などの機能をただ紹介するのではなく、「家計簿で使うなら…」という風にユーザーのストーリーに乗せて説明できると、反応はきっと違いますよね。
参加者コメント：
最初に作ったユーザーストーリーを見せる感じでしょうか？
中村：
その通りです。
チームの習熟度が上がっていくと、バックログアイテムはすごく小さくなるんですよね。
例えば、「画像のサイズを大きく見えるようにする」「ボタンのキャプションを変える」など、小さなことがバックログとしてできあがってきた場合、一つずつの機能を見せても反応は薄いと思います。
背景にあるストーリーは、「いろいろなところを変えて、ユーザーが商品を選びやすくなる」ということですよね。
ユーザーには細かい変更点を伝える前に一連の流れを体験してもらい、「前と比べてどうなりましたか？」と聞いてみるといいと思います。
「商品選びがしやすくなりました。画像が大きくなっているし、ボタンも押しやすくなっていますね」というようなフィードバックが得られれば、自分たちの仮説が合っていることも、ユーザーの課題が解決できていることも分かるので、いいと思います。
フィードバックは承認をいただくというものではないですよね。
新井：
計画通りに作れたかどうかという観点は、第一段階としてOKですが、そこからさらにどうやってプロダクトを良くしていくかの会話をすることが、スプリントレビューの本質だと思っています。前編のカレーの話ですね。そこにスクラムチームでフォーカスできるといいですよね。
▶▶Message from coaches
- スプリントプランニングの時点で、スプリントの内容に合ったレビュアーを設計しておこう。
- 個々の機能の紹介ではなく、ユーザーのストーリーに乗せてデモしてみよう。
- 「計画通りに作れたかどうか」で終わらせず、そこからさらにプロダクトの価値を高めよう。
〔topic8〕スプリントレビューで何もインクリメントができなかったから、スプリントレビューをスキップしたい
中村：
気持ちはわかりますけどね。
新井：
なぜこういう状況になったのか、チームで突きつめて話し合ってみるといいですね。
もしかしたら、目に見えるUIがないとスプリントレビューができないという思い込みがあるのかもしれませんし、あるいは、プロダクトバックログやユーザーストーリーが大きすぎる可能性もあります。
中村：
デモ的なものがないというよりは、恐らく本当にインクリメントが何も完成しなかったというシチュエーションだと思うんですけど、そういう時でも基本的にスプリントレビューをスキップしてはいけないと思っています。
スプリントレビューというのは、このインクリメントに価値があるのか、仮説に合っているのかを確認・検査するのと同時に、プロダクトゴールに対する進捗を検査する場でもあるんですよね。
インクリメントがなにもなかったとしても、スプリントを通してプロダクトの状況は変わっているわけだから、現状を確認・整理した上で、プロダクトゴールへの距離などをステークホルダーと話し合っておくとよいでしょう。その話をするために、スプリントレビューをスキップしてはいけないと思います。
他に何か問題がある場合も、スプリントレビューをすれば「ステークホルダーとして何かサポートできることはないか？」という話を引き出すチャンスでもあると思うんですよ。
チームの状況を伝えるチャンスでもあって、「実は忙しすぎて全然リファインメントできなかったんです」と伝えられれば、ステークホルダーから上層部に働きかけて、POが動きを取りやすくしてもらえるかもしれません。
新井：
「インクリメントができなかった」ということもグッドインフォメーションです。それにどう対処するか。どうやってスクラムの3つの価値観である、透明性・検査・適応のサイクルを回すか。スプリントレビューをスキップしてしまうと、プロダクトゴールに適応する機会を失ってしまいます。
中村：
スクラムのイベントには、いろいろなことに対する検査と適応のチャンスが用意されています。
その中でも、スプリントレビューはプロダクトゴールや自分たちのインクリメントに対する検査と適応の場なわけですよね。それを、「インクリメントがないから」とスキップしてしまうのは非常にもったいないです。
気持ちは分かりますが、これを機にステークホルダーとしっかり話をしましょう。
▶▶Message from coaches
- スプリントレビューはプロダクトゴールに対する検査と適応のチャンス。スキップするのはもったいない。
- ステークホルダーの関心を引き出したり、チームの状況を伝えるチャンスでもある。
- チームで話し合ったり、ステークホルダーと話す機会と捉えよう。
〔topic9〕計画通りのものがデモできたら、そこで会話が終わってしまう
新井：
これについては、これまでの話の中に解決のためのエッセンスが出てきていますよね。
計画通りに作るのは当たり前で、レビューはその先を考える場ですから、「 これは本当に自分達が作りたかったプロダクトなのか？」「このプロダクトをこのままリリースして、本当にユーザーが喜ぶだろうか？」という会話を、スクラムチームの中で発生させたいですね。
中村：
プロダクトゴールへの進捗検査をすることも大事です。プロダクトゴールという概念はスクラムガイド2020で新しくできたものなので、スプリントレビューでこの検査が抜けてしまう現場が多いように感じています。
新井：
ミクロとマクロ両方の視点を持てると良いですよね。プロダクトゴールはマクロ、個々の機能開発を考えることはミクロの視点になると思います。
行ったり来たりして思考するのは人間にとって負荷が大きいのかもしれませんが、重要なことです。
中村：
プロダクトゴールを示す、スプリントゴールを説明する、デモをする、一旦休憩した後、あらためてプロダクトゴールへの進捗を見る…と、場をしっかりと切り替えながらやっていくのも手ですね。
新井：
脳のスイッチをアジェンダで切り替えていくということですね。難しいことだからこそ、スクラムマスターが丁寧にファシリテートしていくのは大事だと思いますし、スクラムガイドにも要所要所でポイントとして描かれているんでしょうね。
中村：
いつまでもスクラムマスターがファシリテートを続けるのは良くないですが、良い作戦だと思います。
▶▶Message from coaches
- 計画通りにできるのは当たり前。スプリントレビューではその先にあるプロダクトの本質や価値について話そう。
- 自分たちが本当に作りたかったプロダクトになっているか？
- ユーザーが本当に喜ぶプロダクトになっているか？
- プロダクトゴールへの進捗検査も忘れずに。
- ミクロ（個々の機能）とマクロ（プロダクトゴール）の視点を切り替えながらスプリントレビューを進めよう。
- 最初の方はスクラムマスターが丁寧にファシリテートするのも良い作戦。
Q＆A
Q1
「スプリントレビューが進捗報告会になってしまう」という問題が、まさに私の現場で起きています。既に進捗報告会としての認識ができあがっているので、いきなり根本的なところにアプローチするのは難しいと思うのですが、すぐに実践できる取り組みがあったら教えてください。
新井：
おっしゃる通り、進捗報告会を一気に大改革するとなるとハードルが上がりますから、段階を経て取り組むと良いと思います。
既存のスプリントレビューはそのまま「進捗報告会」として行って、その「二次会」のような場を設けてはどうでしょうか。いわゆるスクラムガイドに書かれているスプリントレビューを行う場です。
また、「そもそもスクラムガイドにはどう書いてあるんだっけ？」という自主勉強会を、スプリントレビュー以外のところで開いてみるのもいいかもしれません。
中村：
私もまったく同じ意見です。
緩やかに進める方法として、「ここまでは報告会」「次はプロダクトを触ってもらう時間」というように、タイムボックスを区切ってやってみると良いと思います。
もう一つは、ルールの理解からしっかりと始める方法です。スクラムガイドは言わばルールブックですから、これを知ってから始めようというスタンスです。
実際にどう進めるかは質問者の方の社内での立場にもよると思いますが、例えば、著名なアジャイルコーチの本を示しながらスプリントレビューについて説明したり、その人を実際に会社へ招いて話をしてもらう方法もあります。
Q2
お話にあったような勉強会の場が既に設けられていますので、「スクラムガイドをみんなで読んでみよう」と、ジャブを打ってみよう（様子を見てみよう）と思いました。メンバーの反応を見ながら少しずつ取り入れていきたいです。
中村：
「スプリントレビューが進捗報告会になってしまう」という現場は、実は以前経験したことがあります。そのときは「 ロールプレイング」という手法で対応しました。
普段通りの進捗報告会の後で「ラーニングセッション」と我々が呼んでいる勉強会を開いて、スクラムガイドに書いてあるルール通りにスプリントレビューを行います。
仮に失敗しても、実際の進捗報告は終わっているので問題ないですし、一度経験することで次もやってみようという気持ちになりますよね。低リスクで実践できますので、こういった取り組みもおすすめです。
新井：
ぜひ、いろんな小さい実験をしてみてください。
今日はありがとうございました。皆さんが現場に持ち帰って、実践できるものがあったらうれしいです。
中村：
ありがとうございました。
次回もお楽しみに。
前編はこちら
参加者の方からのご感想
- ラジオ感覚でゆるく聞けてよかったです！次も聞いてみたくなりました。ありがとうございました。
- かなり具体的なテーマで有意義でした。
- カレーの例えがわかりやすかったです。
- 有意義な時間をありがとうございました。「あるある」と共感しながらゆるく聞けました。また参加させていただきます。
ご参加ありがとうございました！
関連情報
とはいえシリーズ他、アジャイルやスクラムの実践に役立つイベントを開催しています。
▼イベント開催予定はこちらをご覧ください。