スクラムチームでスプリントレビューを取り入れた話
この記事はクラウドワークス Advent Calendar 2021 9日目の投稿です。
こんにちは、株式会社クラウドワークスでプロダクトオーナーをしているあんみなです🐰
クラウドテック という、主にフリーランスを対象とするエージェントマッチング事業を担当しています。
今回は私の所属するスクラムチームがスプリントレビューを取り入れた話をしたいと思います。
スクラム開発に関わる方はタイトルの時点で「スクラムなのにスプリントレビューやってなかったの？？？」と疑念を抱くかもしれませんが、正しいスクラムへの一歩を踏み出したのね！と温かい目で見ていただければと思います。
スプリントレビューを取り入れたきっかけ
私たちが課題に気づいたのは、スクラムを正しく運用しよう！という機運が高まった2021年の6月頃。
今思うと、それまではプランニングと振り返りをやってスプリントで開発している「なんとなくそれっぽい自称スクラムチーム」でした（自覚はなかった）。
「ちゃんとやる」ためにスクラムガイドをチームメンバーで読み合い、現状との差分をチームで洗い出した時に、スクラムイベントであるスプリントレビューを実施していないことが課題の一つということに気が付きました。
その時点では
大きい機能リリース時は資料を作ってビジネスサイド向けの説明会を開く
それ以外のリリース時はSlackで通知する
（大きい、大きくないも肌感覚）
という状態だったため、定期的な成果物の検査・振り返りの機会は存在しません。スプリントレビューとは何ぞや？の状態です。
バイブルであるスクラムガイドに立ち返ると、スプリントレビューが下記のように説明されています。
スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することである。スクラムチームは、主要なステークホルダーに作業の結果を提示し、プロダクトゴールに対する進捗について話し合う。
スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成され、自分たちの環境で何が変化したかについてレビューする。この情報に基づいて、参加者は次にやるべきことに協力して取り組む。新たな機会に見合うようにプロダクトバックログを調整することもある。スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにする。
スプリントレビューは、スプリントの最後から2番目のイベントであり、スプリントが1か月の場合、タイムボックスは最大4時間である。スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多い。
うーーーん・・・
「”作業の結果”って成果物のことで合ってる？」
「主要なステークホルダーってどこまでの範囲？」
「何が達成されたか説明するのって難しいなー」
メンバーそれぞれ色んな疑問があり、ましてやエンジニアは普段あまり関わらないステークホルダーとの直接の会話に緊張と不安も抱えていたと思います。
でもまずは型に沿ってやってみて、意義を実感しながら改善していこう！ということで、ひとまず実施に必要最低限な以下の制限を設けました。
自チームは月～金曜日の1週間スプリントなので、スプリント終盤で次のプランニング前に当たる木曜日に原則実施する
所要時間は最大1時間
ステークホルダーを呼ぶ必要があるため、プランニングでスプリントバックログアイテムを積む時に「成果物を見せるべきステークホルダー」を確認しておく
ステークホルダーに成果を見せづらいバックログアイテム（リファクタリング等）は対象外とし、まずは見せやすいものからスプリントレビュー対象とする
事前に対象の成果物をデモ環境にセットしておく
このあたりを先導してくれたスクラムマスターも、実は「ちゃんとスクラムをやる」となったタイミングで挙手をしてエンジニアから転身してくれたので、分からないことだらけの中ガツガツ進めてくださったことに本当に感謝しています！！
そんなスクラムマスターさいそん氏のAdvent Calenderもあるので、ぜひ覗いてみてください👀
未経験スクラムマスターがやったこと＋意識したこと
スプリントレビューの実施
初のスプリントレビューはクライアントの支払いサイトに関する機能改修だったため、ステークホルダーとしてクラウドテックの事業部長に参加いただき、スプリントレビューは以下の内容で進めました。
成果物の要件、解決したい課題の説明
レビューで見てもらう内容の説明
デモの実施
ステークホルダーのフィードバック
完成しなかった内容の説明
現在の進捗を踏まえての完了・リリース日の共有
派生するタスク/他の課題のばぶばぶ ※
※社内では、特に結論を求めない発散を目的とした会話を赤ちゃんの喃語になぞらえて「ばぶばぶ」と呼んでいます。
初回は内心ドキドキでしたが、ステークホルダーを交えることで今後の課題やどう活用していく予定かといった実装内容から膨らんだ会話もでき、チームでも周辺理解を深めることができました。
普段個別にやり取りしているステークホルダー、チームメンバーが同じ場にいる状況がすごく新鮮に感じたことも覚えています。
スプリントレビューに参加したステークホルダーからは
「成果物をもとにすり合わせできるのでイメージしやすい」
「リリース前に懸念がないか聞いてくれて安心できた」
「細かい仕様をその場で即確認できてスムーズ」
といったポジティブな反応をもらうことができ、及第点だったかと思います。
それ以降、現在に至るまで、機能によってサポートグループや企画チームなど様々なステークホルダーをアサインして原則1スプリントに1回実施しています（スプリントバックログアイテムに成果物として見えづらいものしかない場合は、実施しないこともあります）。
スプリントレビューをやってみて良かったこと
まだ半年の経験なので改善途中ではあるものの、既に以前ではできなかったこと、やりづらかったことが少しずつ解消されてきています。
その中でも特に多大なメリットを感じているポイントが以下の2点です。
1. 仕様変更の融通が利く
これまでは機能リリース後に周知を行っていたため、必然的にユーザーフィードバックをリリース後にもらう形になっていました。
使いづらい、オペレーションが変わって今の機能では使えない、といったネガティブなフィードバックがあった場合は、「後追い修正」として別スプリントで取り扱うことが多い状態でした。
そのため、機能修正に着手するまでに
ステークホルダーからのフィードバック・修正依頼
工数見積り
ステークホルダーへ優先順位と実装時期を周知
要件定義
という手順を踏む必要がありました。
その点、スプリントレビューを実施することで、ステークホルダー・開発チーム・POが同席する場でフィードバックを回収できるので、元の要件から大幅にずれが生じない限りはその場で仕様に盛り込めるようになりました。
これにより、機能修正までのリードタイムを短縮し、コミュニケーションコストもかからない状態を作ることができています。
2. リリースのタイミングを合意しやすい
「実装できていること」「この後実装すること」をステークホルダーと確認できるため、具体的なイメージを伴ってリリース時期の共通認識を取りやすくなりました。
例えば、当初2スプリントを予定していた実装が4スプリントかかりそうな場合、
「進捗が遅れていて、2週間延びそうです」
という説明だと、「また遅れるんじゃない？」と当然ステークホルダーは懸念を抱きます（実際に言われることもありました）。
POもどこまで出来上がっているか分かりづらい状態だったので、それを回収し非エンジニアのステークホルダーへ説明するのは正直とても大変でした。
現在はスプリントレビューで、
「今ここまでできていて、○○が残っているので、その実装と最終レビューで2スプリント追加になりそうです」
という具体的な説明ができるようになり、リリースタイミングの合意を採りやすくなりました。
期待値のずれをスプリントという短いサイクルで修正することで、後から大きな調整がかかる場合に比べて、ステークホルダー・スクラムチーム双方にとっての調整コストと心理的負担を軽減することができています。
また、開発チームから見えにくいステークホルダーの作業を踏まえてスケジュールを引けるようになったことも、リリースタイミングの図りやすさの一つです。
ひとえにリリースと言っても、機能によっては
操作方法を業務マニュアルに追記する
運用変更があったので今後使う可能性のある別部署にも事前告知しておく
顧客向けの告知メルマガを作成する
といったステークホルダー側のタスクが付随する場合もあります。
こういったスクラムチーム外のタスクも含めてその場で洗い出せるので、関係者が足並みを揃えてリリースに備えることができるようになりました。
まとめ
半年前にスクラム運用を見直し始めてから、私たちのチームは大きく変化を重ねてきました。
上記のスプリントレビューについても、変化の一部にすぎませんが、スクラムチームにとって貴重で偉大な経験となっていることは確かです。
運用と改善に積極的に関わってくれているスクラムチームメンバーをはじめ、開発運用の変化を理解し柔軟に対応いただいているステークホルダー、障壁を取り除き逐一サポートくださるマネージャー・PdMの皆様のおかげで、日々スクラムチームを成熟させることができています。
いつも本当にありがとうございます！
まだまだ発展途上なので（そして終わりなき道である）、これからも変化と改善を楽しみながら積み重ね続けていければと思います。
今回はスプリントレビューに焦点を当てて書きましたが、スクラムチーム全体の改善については株式会社クラウドワークスのエンジニアブログで触れているので、ぜひぜひご覧ください✨
「チームに「スクラム」を導入したお話」
この記事が気に入ったらサポートをしてみませんか？