リファインメントとは？やり方や失敗例と改善のためのチェックリスト
アジャイル開発において、リファインメントはプロダクトバックログの整理や開発チームのコミュニケーション促進の意味でも重要なものです。
成熟したスクラムチームになるほど、リファインメントの中でプロダクトオーナー（PO）とチーム間でプロダクトバックログアイテム（PBI）の各項目に対する認識をしっかり合わせ、認識のズレがあれば議論で解消をすることで遅延のない開発を進捗させることができます。
今回は、スクラムの中でも重要なリファインメントについてあらゆる視点でまとめています。
Joe Justice「リファインメント改善のポイントとチェックリスト」も有効に使ってください！
この記事でわかること
- リファインメントとは？概要や目的が理解できる
- リファインメントのやり方がわかる
- リファインメントで改善できる問題や重要性がわかる
- リファインメントの失敗例や注意点が分かる
- リファインメント改善のポイントとチェックリストがわかる
リファインメントとは
アジャイルチームは、短い作業サイクルを繰り返し成果物を完成させます。
アジャイル開発のこの短い作業期間は「スプリント」です。
スクラムチームは、プロダクトバックログからスプリントで実施する作業を選択します。
プロダクトバックログは、プロジェクト中に完了しなければならない成果物を優先順位付けしたリストです。
リファインメントは、このプロダクトバックログを最新の状態に保ち、次のスプリントですぐに作業開始できるようにすることです。これはチーム間の認識のズレや、相互理解にも役立ちます。
日本語でリファインメントは、「バックログを洗練させる活動」と言われることが多いです。またリファインメントは、グルーミングと呼ばれることもありますが、同じ活動です。
概要
リファインメントでは、プロダクトバックログの優先度の高いアイテムを中心にチームで話し合います。
リファインメントは 1 回限りの作業ではなく、チームの間の継続的なプロセスです。
つまり、新たな発見に基づく新しいアイテムを追加したり、大きなアイテムを小さなアイテムに分割したり、不要なアイテムを削除することを意味します。
この記事では、リファインメントで確認すべきこと、よくある課題について紹介します。
リファインメントの目的
リファインメントの目的は、バックログを次のスプリントに備えることです。
- プロダクトバックログを整理する
- コミュニケーションの促進
プロダクトバックログを整理する
プロダクトバックログは、多くの意見から、複雑な情報で溢れている場合があります。これは、プロジェクトの混乱につながる可能性があります。 バックログを整理しておくと、より効率的になります
コミュニケーションの促進
プロダクトバックログが明確でないと、誤解につながる可能性があり、プロジェクトに悪影響を及ぼします。プロダクトバックログを改善することで、チーム内のコミュニケーションが活性化され、新機能、発見されたバグ、ユーザーのフィードバックなどに関して全員が同じ認識を持つことができます。
リファインメントの参加者と役割
Joe Justiceリファインメントはチームメンバー全員が参加することが理想です。それぞれの役割について確認していきましょう。
プロダクトオーナーの役割・やること
プロダクトオーナーは、プロダクトバックログを所有しており責任があります。つまり、リファインメントはプロダクトオーナーに責任があります。もちろんチームメンバーはプロダクトオーナーをサポートします。
プロダクトオーナーはまず、プロダクトビジョンを持つことから始まります。このビジョンについては、チームやすべてのステークホルダーと常に話し合ってください。
プロダクトオーナーの責任の例
下記は、リファインメントにおけるプロダクトオーナーの責任の例です：
- プロダクトビジョンの設定
- ペルソナの作成
- 準備完了の定義の作成・確認
- 完成の定義、受け入れ基準の作成・確認
- ユーザー ストーリーの作成
- ユーザーストーリーの価値、サイズの見積もり
- ユーザーストーリーの優先順位づけ
スクラムマスターの役割・やること
スクラムマスターは、リファインメントで話し合った内容を全員が理解できるようにすることです。理解を促進させるために重要な点は、透明性を保ち、必要に応じて教えることです。また、スプリントプランニングで予想される疑問や課題を確認しておきます
スクラムマスターの責任の例
下記は、リファインメントにおけるスクラムマスターの責任の例です：
- プロダクトオーナーのアクションをサポートする
- チームにリファインメントの重要性とやり方を教える
- 大きなアイテムをより小さな単位の作業に分割できないか検討する
- スプリントプランニングで予想される疑問や課題を確認する
開発者の役割・やること
開発者は、以前のスプリントでの学びを共有することや、必要な情報を取得し次のスプリントの作業に備えることです。
開発者の責任の例
下記は、リファインメントにおける開発者の責任の例です：
- リファインメントのアクションに参加し理解する
- 以前のスプリントでも学びや気づきから、改善点がないか確認する
- ユーザーストーリーのサイズを見積もり、スプリントで実行可能なサイズか確認する
- 大きなアイテムをより小さな単位の作業に分割できないか検討する
- スプリントプランニングで予想される疑問や課題を洗い出す
リファインメントで何を解決できるのか？
Joe Justice次からは、よくあるチームの課題に対して、リファインメントがどのように解決に役立つのか紹介していきます。
ありがちな開発チームのリリースの遅れの課題
開発チームのリリースの遅れの課題はなぜ起こってしまうのか？
リファインメントでどのように解決できるのか？
ビギナーチームによくある課題として、レビューした際に要求の実装が不十分または不適格ということがあります。レビューをパスできなかったアイテムはバックログに戻され、次のスプリントで再度実行することになります。つまり遅れが発生し、チームの生産性は落ちることになります。
解決方法
Joe Justice遅延が発生する原因と、リファインメントでの対処法を紹介しましょう。
遅れが発生する理由として、実装が不十分または不適格ということがありますが、これはなぜ発生してしまうのでしょうか。いくつか理由が考えられます。
【CASE1】チーム間の認識ズレ
プロダクトオーナーは”説明したつもり”で、実際に作業をするメンバーは”わかったつもり”のまま作業が進行してしまうことがあります。これは、リファインメントで適切なコミュニケーションを取ることで解決することができます。
【CASE2】プロダクトバックログ(ユーザーストーリー)の内容が不十分
作るべきアイテムが明確化されていない。サイズが正しく見積もられておらず、スプリントで完了できるサイズになっていないことがあります。リファインメントでは、プロダクトオーナーはビジネスの視点から、開発者は技術的な視点から確認し合いプロダクトバックログを適切にしていく必要があります。
【CASE3】完成の定義、受け入れ基準が不十分
完成の定義とは、インクリメント(成果物)が完了と見なされる前に、満たすべき基準のリストです。完了チェックリストのようなものです。通常、スプリントの終了時にこれらの基準を満たさない場合、その作業は完了と見なされません。
リファインメントでは、完了の定義と、必要であればアイテム特有の受け入れ条件について、事前に定義しておく必要があります。
リファインメントが重要な理由
リファインメントでは、チームメンバー間で知識が共有されるため、チームの効率が向上しますが、
リファインメントが適切でない場合、どのようなリスクがあるでしょうか？
- 共通の理解がなければ、間違ったことを実装して時間やコストを浪費し、正しく実装するためにやり直しのリスクがあります。
- 各アイテムのサイズを決めないと、スプリントで完成できなかったり、優先順位を誤ってしまいます。
- プロダクトバックログが優先順位順でない場合、それほど重要ではないアイテムに取り組んだり、重要なものを見落としたりするリスクがあります。
Joe Justiceアジャイルでは、これらのリスクをリファインメントで解消することにより、プロジェクトを成功に導きます。
経験値の高いスクラムチームと低いチームのリファイメント比較
| 経験値の高いチーム | 経験値の低いチーム | |
|---|---|---|
| 姿勢 | 主体的・積極的 | 受動的で受け身 |
| 意識・認識 | チームメンバー全員の認識が合致している | 解釈や認識のズレがある |
| 具体的な内容 | リファインメントの中で、POとチーム間でプロダクトバックログアイテム（PBI）の各項目に対する認識をしっかり合わせ、認識のズレがあれば議論で解消 | POからチームメンバーへのトップダウンになってしまい、認識にズレがあっても質問や議論が行われないまま開発がスタートしてしまう |
リファインメントはプロダクトオーナーに責任がありますが、これはプロダクトオーナーが全てを決定し指示をするということではありません。チームメンバー全員がプロジェクトの当事者として、リファインメントに参加することが重要です。
リファインメントの主なやり方・手順
プロダクトオーナーはチームに、プロダクトバックログアイテムについて紹介します。これらについて、開発者は自由に質問したり、技術的な視点も含めてチーム内で議論します。そしてプロダクトバックログアイテムを洗練させ適切にします。
プロダクトオーナーはチームに、プロダクトバックログアイテムについて紹介します。これらについて、開発者は自由に質問したり、技術的な視点も含めてチーム内で議論します。そしてプロダクトバックログアイテムを洗練させ適切にします。
プロダクトバックログアイテムに優先順位をつけます。優先順位の付け方にもさまざまなフレームワークが存在します。代表的なフレームワークには下記のようなものがあります。
- 価値と複雑さのマトリックス
- 狩野モデル
- MoSCoW法
Joe Justiceアジャイルでは、これらのフレームも活用しながら、チーム全体でなぜこの順番で実行するのか共通理解を持ちます。
リファインメントに必要な事前準備
プロダクトオーナーは、バックログアイテムについて顧客と会話し、アイテムの要件を明確にしておきます。また、そのアイテムが顧客にとって重要な理由を正しく説明できるようにする必要があります。
リファインメントの失敗の事例
- プロダクトバックログアイテムの完成度が低く基準も明確でない
- プロダクトバックログアイテムの優先順位が不適切
- プロダクトバックログアイテムの細分化が適切でない
- リファインメントの中で意思疎通をする為に必要な時間が足りていない
- リファインメント開催の頻度が適切でない
Joe Justiceこれらはよくある失敗のケースです。次からは改善の事例や、リファインメントでのチェック項目を紹介します。
リファインメントの改善の事例
Joe Justiceリファインメントの改善は、簡単にできることもありますので、事例をいくつか紹介します。
プロダクトバックログアイテムのテンプレート化で安定化
プロダクトバックログアイテムの準備はリファインメントの前に必要な作業になります。
成熟したチームであれば、開発ごとにプロダクトバックログアイテムのレベルにある程度のバラつきがあっても対応できるかもしれませんが、経験の浅いチームの場合は対応が難しい場合もあるでしょう。
より安定した解釈を得る為にも、プロダクトバックログアイテムをテンプレート化してみるのもおすすめです。
うまくいったプロジェクトというのは、プロダクトバックログアイテムの時点で精度が高い無駄のないプロダクトバックログアイテムを準備しているものです。
そうしたプロダクトバックログアイテムを資産として、ノウハウをテンプレート化するのはおすすめです。
リファインメント実施時間や頻度の見直し
リファインメントは、可能であれば、毎日15分間で開催してルーティン化したいところです。
頻度が増える事で、実装上の懸念点やより具体的な実装方法を確認する事ができるでしょうし、開発チームからも技術的な意見や質問も活発にでるかもしれません。
また、プロダクトオーナーの要求に関しても、より具体的なユーザーストーリー、背景を伝える事ができるなど、プロダクトオーナーと開発チームとの間でより具体的に認識を合わせる事もできるでしょう。
例えば2週間に1回30分の開催であれば、時間の中では確認できる事項も限られますので、プロダクトオーナーから開発チームへの一方通行の確認になってしまいがちです。
うまく行っているチームのリファイメントを取り入れてみる
自社内でスクラムチームで開発をしているのでしたら、うまく行っているチームというのがあると思います。
もし、自身の開発チームがうまく行っていないと感じたのなら、うまく行っているチームのリファインメントを参考に取り入れてみるのも良い改善に繋がりやすくおすすめです。
チームメンバーの中には、他のチームのリファインメントを取り入れる事に消極的なメンバーもいるかもしれませんが、「まずは試してやってみる。効果がなければまた考える」くらいの臨機応変さも開発チームには必要です。また、スクラムマスターのリードも大切になるでしょう。
リファインメント改善のポイントとチェックリスト
リファインメントは定期的に実施する必要があります。チェックリストの例を以下に示します。
これを使用して、リファインメントでプロダクトバックログの改善が必要か確認してみてください。
- プロダクトオーナーとチームメンバーでプロダクトバックログアイテムの認識は合っているか？
- プロダクトオーナーとチームメンバーの間で積極的に意見交換や意識の擦り合わせは出来ているか？
- プロダクトバックログアイテムの優先順位は正しいか？
- 不要なプロダクトバックログアイテムはないか？
- 割り込み作業により後回しになって見落としているアイテムはないか？
- 工数見積もりで完成までに1日以上かかる様な分割すべきプロダクトバックログアイテムはないか？
- プロダクトバックログアイテムの内容だけでなく、実装イメージまでの認識が合っているか？
- １スプリントの作業量のキャパは適正か？
- 以前のスプリントの学びから、変更や改善すべき点はないか？
リファインメントの注意点
リファインメントはやれば良いというものではありません。
Joe Justiceリファインメントはプロダクトバックログアイテムを伝達する場ではない点に注意しましょう。
本来リファインメントの目的は、双方向に議論をする事で、プロダクトバックログアイテムに対する認識のズレがないか擦り合わせを行い確認する場です。
- 開発チームからは、実装上の懸念点や技術的な具体的実装方法に対する意見
- プロダクトオーナーからは、受入条件やユーザーストーリー、対応内容などの意見
リファインメントは、こうした双方からの意見を議論する場であって、プロダクトオーナーからのユーザーストーリーや要求、PBIの内容の伝達の場ではありません。
成熟度の高いスクラムチームであれば、具体的な双方のトピックを双方向で議論できる様になりますが、若いチームでは内容伝達になりがちです。
是非、リファインメントの目的が果たせているかチェックしてみると良いでしょう。
リファインメントに関するFAQ｜教えてJoe！
- リファインメントで重要なポイントを教えてください
-
楽しむことを忘れないでください！そして毎日実施することがおすすめです。私はリファインメントカフェと呼んでおり、毎日コーヒーを片手に15分ほどチームでリファインメントを実施しています。
また最優先のプロダクトバックログアイテムは「準備完了の定義」を満たしていることを確認してください。
※準備完了の定義：プロダクトバックログアイテムの作業を開始する準備ができているかどうかを判断するために使用するリスト。 - プロダクトバックログアイテムで1日では終わらないアイテムは分割すべきでしょうか？分割する基準はありますか？
-
可能であれば分割を検討してください。
まずは、同時に完成させることができるよう分割できないか考えてみましょう。
分割の観点としては、下記を参考にしてみてください。
1)ペルソナ
2)価値(彼らが製品を使いたい理由)
3)バージョン(MVP、V2、V3など)
※実用最小限の製品(Minimum Viable Product、MVP) は、初期の顧客を満足させ、将来の製品開発に役立つ有効なフィードバックや実証を得られる機能を備えた製品のバージョンを指す。しかし、もちろん時には分割しきれない場合があります。その場合は、スプリントを跨いでしまう大きなアイテムがあっても構いません。分割することが目的となり、そこに大きな時間を割いてしまうのは良いことではありません。
- 依存関係のあるアイテムは優先されるべきですか？
-
依存関係がある場合、それらは通常優先されます。しかし、プロダクトバックログのユーザーストーリーは、ほとんどの場合依存関係はありません。
スプリントバックログには、より大きなユーザーストーリーを完了するためのタスクが含まれることもあり、タスクには依存関係がある場合があります。
エキスパートなスクラムマスターは、バックログを書き換えて、依存関係を減らしたり削除したりできます。非常に経験豊富なスクラムチームはタスクを使用せず、ユーザーストーリーとして直接作業に取り組んでいます。
まとめ
リファインメントは、チームメンバー間のコミュニケーションを促進させ、新たな気づきを得ることもあるでしょう。チーム全体の創造性と知識を活用するという大きな機会になります。これにより、作業負荷が軽減されたり、要件が改善され、製品が改善される可能性があります。
この記事では、リファインメントのチェックリストも紹介しましたので、まずはご自身のチームをチェックして、楽しく実りのあるリファインメントにしてください！