みなさんこんにちは。@ryuzeeです。
スプリントの最後に行うイベントの1つにスプリントレビューがあります。 先日自分がコーチとして見ていたスプリントレビューがとても良くて、なぜそう感じたのかを言語化してみました。 結果として、以下の6点が重要なポイントだと思ったので紹介したいと思います。
- 利用者の体験をレビューしている
- 建設的なフィードバックがたくさん集まる
- 参加者みんながプロダクトの中身に関心を持っている
- プロダクトの現状とこの先が分かる
- チームがこの場を良いものにするために協力しあっている
- 明るく楽しい
1. 利用者の体験をレビューしている
「●●機能」「■■機能」のような機能を主軸にしたレビューにすると、フィードバックの質が低下します。 つまり機能単体で見て、もっと色々なことができるようにしたい、もっとオプションを増やしたい、競合と比べて機能が少ないのでどうにかしたいといったフィードバックになったり、なんとなく「完成してそう」「いい感じ」というようなフィードバックになったりします（酷いところだと、機能単位で見せて、本当に完成しているかを確認してマルバツを付ける謎の儀式になっていることもあります）。 これではプロダクトの将来に対して有益なフィードバックにならないのは言うまでもありません。
利用者の視点でレビューし、利用者が抱えている課題が本当に解決できそうなのか、もっとうまく解決できる方法はないのか、もっと使いやすくするにはどうするのか、現状で利用者にとって十分なのか、十分ではないとしたら何が足りないのかを議論できると、プロダクト自体に対するフィードバックの精度が上がります。
2. 建設的なフィードバックがたくさん集まる
ステークホルダーが謎の強権を持っていて一方的にああしたい、こうしたいと伝えるような場になってしまうと、ほかの人はフィードバックしにくくなります。 また、フィードバックによって自分たちの作業の増加に繋がる環境（謎のスコープ保証など）だと、フィードバック自体が個人にとっては有益でなくなるので、何も言わないか、対応が簡単なフィードバックだけしかしなくなります。
スプリントレビューでのフィードバックは、あくまでプロダクトをよくするための意見であり、命令でもなければ確定事項でもありません。 フィードバックに取り組むかどうか、いつやるかは最終的にはプロダクトオーナーの判断です。 それをスプリントレビューに参加するステークホルダーにも理解させておく必要があります。 あるチームでは、スプリントレビューの冒頭で、スクラムガイドの該当箇所を全体に向けて説明していました。 どんな種類のフィードバックが欲しいのか、貰ったフィードバックをどう扱うかを事前に説明しておくことで、その場の目的にあったフィードバックが得られやすくなります。
3. 参加者みんながプロダクトの中身に関心を持っている
こんなの当たり前だと思うかもしれませんが、そうでもない場合もあります。 たとえば、上から押し付けられた（どう考えても）イケてないアイデアを実現する責任をスクラムチームが負わされている場合や、人が足りずにスクラムチーム自体が寄せ集めの混成チームになっていている場合などです。 もしくはプロダクトが成功しようが失敗しようが自分に痛みがない場合も、プロダクトの中身に関心を持つのは大変かもしれません。
逆に自分たちが使いたいと思うようなプロダクト、実現したいビジョンに共感できるようなプロダクトであれば、みんな中身に関心を持つようになります。 中身に関心があればフィードバックの質も頻度も増えるので、プロダクトは良い方向に向かいます。
4. プロダクトの現状とこの先が分かる
ステークホルダーの関心事はプロダクト単体の話にとどまらず、プロダクトのリリース時期、営業やマーケティングの方法、サポート体制の構築、収益などさまざまです。 つまり、アジャイルチームが持続可能なペースで進めていて、プロダクトの現状と今後の見通しが分かることで、ステークホルダーはスクラムチームの外側の仕事を進めやすくなります。逆にステークホルダーの状況がスクラムチームに伝わることで、それを踏まえてプロダクトバックログの並び順を変えたり、リリース戦略を考え直したりすることでできるようになります。
私たちは作る人、あなたたちはそこから先どうにかする人という関係性ではありません。
5. チームがこの場を良いものにするために協力しあっている
たまにスプリントレビューで、プロダクトオーナーがステークホルダーからの質問への回答で困っていたり、開発チームのメンバーがデモをしていて手順がわからなくなったりしているのに、ほかの人たちは黙ってみている状況に遭遇することがあります（晒し者です）。 もしくはスクラムチームの特定の人だけが延々と喋り続けていることもあります。 こういった状況はあまり健全ではないかもしれません。
スプリントレビューは忙しいステークホルダーを呼んで行うイベントなのでなるべく多くの成果が出るようにしたいので、そうなるように全員が協力するのが理想です。 誰かが困っていれば助け舟を出すのは当たり前で、黙っていてはいけません。
なお、スクラムチームが、素晴らしいものがスプリントで作れたと思えていれば、スプリントレビューでみんなで自慢してください。
6. 明るく楽しい
上からの命令で「アジャイル」のようなやり方を理由もわからずにやっているチームは、暗くてつまらないと思います。 暗くてつまらないチームや仕事で成果を出すのは難しいですね。 前述の1〜5ができていれば、少しは明るく楽しく仕事ができるようになります。 またこれができているチームであれば、度合いの差はあっても1〜5はある程度できていると言えるでしょう。
それでは。
みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
- 著者／訳者：Matt LeMay、 及川 卓也(まえがき)、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 有野 雅士
- 出版社：オライリージャパン
- 発売日：2020-03-19
- 単行本（ソフトカバー）：216ページ
- ISBN-13：9784873119090
- ASIN：487311909X
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
- 著者／訳者：David Scott Bernstein、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士
- 出版社：オライリージャパン
- 発売日：2019-09-18
- 単行本（ソフトカバー）：300ページ
- ISBN-13：9784873118864
- ASIN：4873118867