なぜ我々はスクラムで「リファインメント」をするのか

Agile Advent Calendar 2024・めぐろLT Advent Calendar 2024 2日目の記事です。

複雑なドメインや曖昧な要件など、多くのリスクが存在しているSaaS開発において、変化に柔軟に対応しプロダクトの価値を高め続けられるよう、手戻りを減らすためのリファインメントの型化を実施しました。この経験を通じて得た知見をご紹介します。

サクッと読みたい方はこちらのスライドもどうぞ。

背景

2022年に、新たなSaaSを作るプロジェクトが始まりました。しかしながら、当時は本当にお客様にとって価値が提供できるのか、仮説が正しいか確証が持てていない状態でした。そのため、先行導入頂いたお客様にフィードバックを得ながら、共同で仮説検証を進めることになりました。

アジャイルに開発を進めていくためにスクラムチームを構築し、要求の変化に機敏に対応し、持続的に発展可能な体制を構築しました。

リファインメントの悩み

しかし、リファインメントはスクラムガイド2020年版にはわずかにしか載っておらず、具体的にどのようなことをするかはスクラムチームに委ねられています^[1]。今回は、私たちのスクラムチームにおける「リファインメントの現在地」について4つの観点にわけて紹介します。

1. なぜ実施するのか？

なぜリファインメントを実施するのか？ですが、スクラムガイド2020年版に書かれている内容をまず確認してみましょう。

1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。^[1:1]

「透明性」とは、経験主義のスクラムの3本柱である「透明性」、「検査」、「適応」のうちの1つです。「透明性」があってはじめて「検査」が可能になり、その結果をもとに「適応」が可能になります。

リファインメントは、プロダクトバックログアイテムの選択に必要な「透明性」を獲得することを通じて、不確実性に向き合うスクラムの哲学を実現するために実施していると私たちは解釈しています。

2. 何を話し合うのか？

次に、私たちがリファインメントで話し合っている内容について紹介します。

2-1. プロダクトバックログアイテムの優先順位を決定

まず最初にプロダクトバックログアイテムの優先順位を決定しています。リファインメントでは、まずプロダクトゴールを再確認し、プロダクトゴールに対する進捗の共通理解を形成します。また、必要に応じてゴールの変更やブラッシュアップも実施しています。

そして、認識がそろったらゴールを元に、優先度順にプロダクトバックログアイテムの並び替えを行います。1～2回後のスプリントでやることを明確にし、スクラムチーム全体で優先順位の認識を揃えています。

この取り組みにより、誰もが上位のプロダクトバックログアイテムを選択できる状態を目指しています。

2-2. 上位のプロダクトバックログアイテムのブレイクダウンと明文化

2つ目が、上位のプロダクトバックログアイテムのブレイクダウンと明文化です。具体的には次の項目を記載し明文化しています。

• このアイテムの価値
• やらないこと
• ブロッカー
• 議事録の内容
• 受け入れ基準
• 受け入れテスト観点

具体的に話している内容についてご紹介します。

このアイテムの価値・やらないこと・ブロッカー

まずは共通理解を形成するために必要な基本的な事項として、このプロダクトバックログアイテムをやることでプロダクトにどのような価値が生まれるのか、逆にこのアイテムではやらないことは何か、そしてブロッカーは何があるかを明文化しています。

この内容については2〜3スプリント前には記入しています。
理由としては議論が十分にされてない状態でプランニングに持ち込まれるのを防ぐためです。議論を詰め切らないでプランニングに持ち込まれてスプリントが始まってしまうと、開発者の理解が不十分のまま実装が開始され、手戻りが発生しやすくなります。

ディスカッションの議事録

このプロダクトバックログアイテムに関わるすべてのディスカッションを議事録として記録しています。議事録を残すことで、リファインメントに参加できなかった人にも背景が理解できるようになったり、数年後に見返した際にも当時の意思決定の経緯がわかるようにしています。

当時の背景や状況を知ることができないと、すでに動いているものが絶対視され、新しい意見が取り入れにくくなります。議事録を残すことで説明責任を果たし、過去の意思決定を振り返りやすくなり、新しい意見を取り入れることができるようにしています。

受け入れ基準

プロダクトバックログアイテムについてある程度の共通理解が形成されたら、受け入れ基準を記載します。受け入れ基準とはスクラムガイド2020年版に記載されている「完成の定義」とは異なります。スクラムガイドに記載されている「完成の定義」は、「プロダクトの品質基準」なので、すべてのプロダクトバックログアイテムに共通して適用されるものです。^[1:2]

私たちは「完成の定義」とは別に、プロダクトバックログアイテムごとに受け入れ基準を設けることで、アイテムごとの完成の共通理解を形成しています。

受け入れテスト観点

最後にシステム的な視点で、受け入れテスト観点を記載しています。品質保証するQAエンジニアもこの段階から巻き込むことでいわゆるシフトレフトを目指し、品質保証観点からの観点漏れを防止し、手戻りを防いでいます。

さらには、パターン洗い出しなどを行う過程で要件がより明確になり、開発者がプロダクトバックログアイテムに対する理解を深められるというメリットもあります。

2-3. 上位のプロダクトバックログアイテムの相対見積り

最後3つ目は、上位のプロダクトバックログアイテムの相対見積りです。私たちは、見積もりにあたりポイント投票を実施しています。投票をするという行為自体によって、開発者に懸念がないことを確認できます。また、プランニングポーカーによって同時に投票することで、個人の意思を可視化しています。

なお、私たちは8ポイント以上になった場合は分割を検討しています。
プロダクトバックログアイテムを適切なサイズにしブレイクダウンすることで、プロダクトバックログの肥大化を防止しています。

相対見積りを通じて、プランニングへ持ち込まれる前にスクラムチーム内で合意を形成し、手戻りを防ぐことを目指しています。

3. どのタイミングで実施するのか？

次に、リファインメントを実施するタイミングについて紹介します。私たちは2週間のスプリントを実施しているのですが、中間の9日目に1.5時間ほどリファインメントを実施しています。しかし、これとは別に毎日のデイリースクラムの後に15分ほどのリファインメントを実施しています。つまり、ほぼ毎日リファインメントの場を作っています。

理由としては、プロダクトバックログアイテムの情報の鮮度を保つためです。不確実性が高いプロダクトの性質上、様々な情報やお客様からのフィードバックが、毎日のようにスクラムチームに流れてきます。しかし、1週間後のリファインメントまで待つと情報の鮮度が落ちてしまいます。

ほぼ毎日の高頻度のリファインメントで、プロダクトバックログが新鮮な状態を確保しています。

4. ルールや意識はスクラムチームにどのように浸透させるのか？

最後に、これらの意識やルールをスクラムチームに浸透させるかについてご紹介します。私たちは、スクラムチームのルールである、Working Agreementを作成しています。これは、スクラムチームの価値観を明文化したドキュメントです。

ステークホルダー全員で合意した内容を書くようにし、スプリントボードと同様にいつでも、誰でも見られる場所に置いています。また、毎週定期的に見直しをして陳腐化を防ぐようにしています。

この取り組みにより、スクラムガイドにほとんど書かれていないリファインメントというイベントについて、スクラムチームの解釈を明確にしました。参考までに、私たちが設定している具体的なルールの例をご紹介します。

1. スクラムイベントのゴールやアジェンダ
   リファインメントを含むスクラムイベントについて、スクラムガイドに乗っている事項だけでなく、アジェンダやスクラムチームとしての解釈も載せています。
2. メンバーの役割と行動規範
   スクラムガイドに定められた役割以外も載せており、オーナーシップを持つ範囲を明確にしています。
3. 開発・レビュー・リリースの手順
   開発をスムーズにするため、レビューの基準やリリースを判断する基準などを明確にしています。
4. 意思決定における投票手法
   ポイント投票の方法や、意思決定時の投票手法について明文化しています。

これらの項目をスクラムチームの現状を常に反映したドキュメントとして維持し、スクラムチーム自体の透明性を高めることで、メンバー全員がオーナーシップ意識を持ち、ルールや意識を浸透させています。

まとめ

私たちは不確実性に向き合うスクラムチームにおいて「プロダクトバックログアイテムの選択に必要な透明性を獲得する」ためにリファインメントを実施しています。

これを踏まえリファインメントでは、プロダクトゴールを踏まえてプロダクトバックログアイテムの優先順位を決定し、上位のアイテムのブレイクダウンと明文化、相対見積りをしています。

また、リファインメントをほぼ毎日という高頻度で実施することを通じ、プロダクトバックログが新鮮な状態を確保しています。

これらの意識やルールをスクラムチームへ浸透させるためにWorking Agreementを活用し、スクラムチームの透明性を高めることを通じてオーナーシップ意識を持たせています。

リファインメントはスクラムガイドにはほとんど書かれていないイベントですが、スクラムの哲学と基礎を理解したうえで、スクラムチームやプロダクトの特性に合わせて工夫を加えることが重要です。

脚注

1. Ken Schwaber & Jeff Sutherland スクラムガイド2020年版