プロダクトバックログリファインメントの定義と運用事例（2024 Advent Calendar 4日目）

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の4日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

本記事ではプロダクトバックログリファインメントの定義と自分たちのプロジェクトでの運用を紹介します。

プロダクトバックログリファインメントの定義

プロダクトバックログリファインメント（以下、リファインメント）は、チーム内のコミュニケーションの核となるイベントです。リファインメントは英語のrefinementで洗練することという意味です。日常では馴染みのない言葉ですが、改良する、ブラッシュアップするという意味で使われます。

ではリファインメントでは何をブラッシュアップするのでしょうか。その対象はプロダクト開発をするにあたりチームで取り組むべきことです。開発の現場では開発者がやるべきことはストーリーやタスクと呼ばれますが、そのやるべきことをここではアイテムと呼びます。アイテムをエピック、フィーチャー、ストーリー、タスクに分類する方法もあるものの、アイテムの説明をすれば十分であるためここでは触れません。

アイテムは「ユーザーはXのためにYができるようにする」というユーザーストーリーで記述されることが一般的です。プロダクトオーナーがユーザーストーリーの形でアイテムを記述し、開発チームがそのアイテムを実現するのがスクラムチームです。時にはプロダクトオーナーと開発チームが一緒になってアイテムを考えることもあるでしょう。

しかし、機能開発はわからないことだらけです。このようにきちんとアイテムを作成しても「では開発者は具体的に何をすればいいのか」は誰も答えてくれません。また良いエンジニアとは言われたものを言われた通りに作るのではなく、なぜそれを作るのかという背景を知った上でどうやって作るのがベストかという設計、実装を自分でハンドリングする人たちです。

そこでリファインメントを実施するのです。あるアイテムを選んで具体的にどう実装するのか、不明点があればどのような調査が必要なのかを明らかにします。メンバーは自分たちの持てる知識と経験を総動員してフラットに議論します。メンバー間の認識齟齬がなくなり、迷いなく作業が開始できる状態になればリファインメントは完了です。

リファインメントとは洗練やブラッシュアップの意味だと書きました。リファインメントは私にとって細分化というイメージが近いです。アイテムという未知の塊を取り上げ、リファインメントを通じて何が不明なもので何をすれば実現できるかを明らかにするプロセスだと捉えています。

機能開発をするにあたり、アイテムは10や20など複数作られます。これらのアイテムを格納したものはプロダクトバックログと呼ばれます。プロダクトバックログ内の各アイテムはプロダクトオーナーが決定した優先度順に並べられているため、開発チームは一番上からアイテムを選んで作業を進めます。

自分たちのプロジェクトでのリファインメントの運用法

次に、自分たちのプロジェクトでのリファインメントの運用方法を紹介します。

このプロジェクトではAという社内機能を作ります。この機能を実現するために仮に15のアイテムが必要だとします。リファインメントでは、プロダクトオーナーが次に実現してほしいアイテムをピックアップします。そのアイテムを開発チームが着手可能な状態にするためにリファインメントを実施します。すると実装タスクだけではなく、不明点があるために調査タスクも必要なことが頻繁にあります。アイテムを着手可能なものに分割したものをタスクと呼び、特に調査タスクをスパイクと呼びます。

自分たちのチームではスパイクをプロダクトオーナーが着手するものとエンジニアが調査するものに分けました。

前者のスパイクは主にユーザーとして機能を使う社内チームや法務、セキュリティチームなどの他チームへの確認です。またエンジニアの質問から決まっていない仕様があることがわかれば、これもプロダクトオーナーのスパイクとしてタスク化していました。開発者向けのスパイクは、既存のコードの調査やコード、データベースの設計、また実現可能性を調べる技術的な調査、SRE・インフラチームとの相談、確認がメインです。

スパイクの完了は調査が終わって実装タスクを作成できるとわかった時点としました。

実装タスクはエンジニアにとって主にコードを書くことです。しかし、コードを書き終えたら完了としたわけではありません。開発者同士のコードレビューに加えて、開発環境でプロダクトオーナーに受け入れテスト（動作確認）を実施してもらいました。この受け入れテストが完了し、マージ、デプロイをした後に完了としました。

スパイクか実装タスクかに関わらず、どちらもこれができれば完了だとする完成の基準をプロダクトオーナーが事前に決めています。エンジニアが作成したスパイクであればエンジニアが完了基準を決めることもあります。経験上、事前に完了基準を決めていないスパイクは完了したと思っても実装タスクの着手時点でどうするべきかまだ迷ってしまったり、あれもこれもと調査が続いてしまっていつまでも完了しないという事態がよく発生します。

アイテムに紐づくタスクが全て完了すればアイテムを完了扱いとします。スクラムでは完了したアイテムをプロダクトインクリメントと呼びます。プロダクトインクリメントについては別の記事で詳述します。

ストーリーポイントでタスクの大きさを見積もる

自分たちのプロジェクトでは各タスクに対して工数の見積もりをし、アイテムの大きさは各タスクの工数を合計したものとしました。タスクの見積もりはストーリーポイントという手法を用いることが一般的です。

ストーリーポイントの見積もりではプランニングポーカーをしました。プランニングポーカーには以下のような特徴があります。まず、スクラムチーム全員が参加することです。非エンジニアの方で具体的な実装について知らない方も含めて全員が参加します。次に、あるタスクを選んで「このタスクは自分なら何ポイントかかると思う」と心の中で見積もりをして、そのポイント数をメンバー全員が一斉に開示することです。

一番小さいポイントを挙げた人と一番大きいポイントを出した人に見積もりの理由を聞き、全員で議論をして再見積もりをします。そこで全員の意見が一致すれば見積もりは完了です。この見積もりを自分たちは「ポイントを振る」と呼んでいました。

一番小さいポイントを振る人は簡単に実装する方法が見えていることがあります。また、一番大きいポイントを振る人は他の人が考慮外のことを避けられてないこととして挙げてくれます。ポイントを降り始めた頃はメンバー間でポイントの大小がなかなか揃いませんでした。このため、スプリントを1度実施していくつかのタスクを完了させることで、ポイントの基準となるアイテムを選んで、これは1ポイントくらい、これは2ポイント、3ポイントとメンバー間でポイントあたりのタスクの大きさの認識を合わせることができた。また自分たちのプロジェクトでは文言の変更だけなど一瞬で終わるタスクは0ポイントとしました。

なお、ポイントは時間で算出するものではありません。1つのタスクを2人のペアで取り組んでも1人で取り組んでもポイントが増減したりはしません。「自分がやるならこれくらいかかる」と想像してプランニングポーカーでポイントを提示し、みんなの議論で認識を合わせて再度見積もりをします。チーム内で認識が揃っていたらそれで十分なのです。社内の人から「結局リリースはいつになるの」と聞かれることがあれば、その際は直近2スプリントで消化したポイント数合計を2で割ったもの（ベロシティ）と残りの全てのアイテムのポイント数を合計したものから予想リリース日を算出して「この日前後です」と伝えます。

この時注意するべきことは、リリース日の予想精度は高くないとも伝えておくことです。不測の事態があればポイントが増えてしまうからです。残念なことにアイテムが減ってポイント数が大きく減ることはなく、したがってリリースが予想より大幅に前倒しになることはありません。アジャイルの教科書的には後回しにできることはリリース日の後にやるのがベストです。これを「スコープを削る」といいます。しかし、開発現場やビジネスの現場にアジャイルの考え方が浸透した現在では、最初から「最小限の機能でリリース」が求められるためスコープがほぼ固定されて削れるところがなかなかないからです。

開発全体を通してのポイントは増えたり減ったりするため、毎スプリントの終わりごとにリリース予測日をチームで確認していました。

リファインメントの意義とその効果

リファインメントはアイテムの内容と実現方法についてチームメンバー全員で認識をすり合わせる時間です。この取り組みを通して、「Aさんはaだと思っていたけど、Bさんはbだと思っていた」というスレ違いを減らしていきます。メンバー同士で徹底的に議論をする必要があるため、かなりタフな作業でした。変に気を遣ったり忖度して言うべきことをその場で言わないと認識齟齬により後から手戻りが発生してしまうため、しっかり話し切ることが重要なのです。この時はスクラムマスターのアドバイスのもとで2スプリント先のアイテムまでリファインメントをしていたため、アイテムとタスク数が多いことも拍車をかけていました。リファインメントが終わった後はみんなぐったりしていた記憶があります。

人によっては「会議が長い」と感じることでしょう。実際自分たちのプロジェクトでは3時間から5時間ほどかかっていました（今ならもっと短くできる自信はありますが、この時は全員がスクラム初心者だったため特に時間がかかってしまいました）。しかし、一たびスプリントが始まれば認識合わせの会議はほとんど必要ありません。リファインメントで事前に些細な疑問を解消したりや不明点を洗い出していたからです。リファインメントは不確実性の低減に確実に寄与しています。議論の場でやるべきことを判断できる情報がチーム内にあれば、その場で次の決断ができます。チーム内に判断材料がなければ、他チームに聞いたりドキュメントを読んだり実装やデータベースを調べるアイテムを作成するという決断ができます。別チームにちょっと聞くくらいの確認が必要なのであれば、「Slackで聞く」というタスクに分解する（次のアイテムのリファインメント中に裏でSlackでパッと聞いてしまうということもしていました）。これにより、タスクの着手忘れと、コードや他の成果物が出てきたからみんなが思っていたものと違うからやり直すという手戻りを防止できるのです。

この段階で開発者がプロダクトオーナーに仕様や方針、背景を確認することでスプリント中迷わずに作業を進めることができます。「スクラムは会議が多い」という批判は確かにあるものの、オンラインでもオフラインでも同じ場所に集まってで徹底的に細かい点まで話し合うことで認識違いを避けるという側面もあります。作業を進めるうちに不明点が出てきて話し合いが必要になれば、Slackに質問を投稿したりGatherでパッと聞きに行ったり（今ではGatherは使わずハドルでさっと集まっています）デイリースクラムで質問すれば良いのです。すると結果的に他の会議が減るのです。

リファインメントはスプリント開始前に実施するものとスプリント中に実施するものがあります。スプリントプランニング前のリファインメントではプロダクトオーナーを含めたメンバー全員が集まって実施します。一方スプリント途中のリファインメントは技術的な内容が多いです。このため、後者は不明点が出てきたらまず開発者だけでサッと集まって話し合い、仕様面等でわからないことがあれば適宜プロダクトオーナーに質問するというやり方を採用していました。

ただし、以下のようなケースではスプリント内のリファインメントであってもプロダクトオーナーも含めた全員が集まって実施していました。

スパイクのアイテムの後に実装のアイテムがあるとします。スパイクが完了した後、実装が想定より複雑であることが判明したとします。実装のアイテムのストーリーポイントを振り直したり、スプリントを跨いだりリリースが遅れるほど影響があれば、さらなる調査や実装の優先順位を変えるといった判断が必要になる。つまり、不確実性が低いから後回しにしていたけれど実際はわからないことだらけだったので早めに着手して不安を解消したいというケースです。自分たちのプロジェクトではプロダクトオーナーが開発者を信頼してくれていたため、開発者のアドバイスをもとにアイテムの優先順位を入れ替えてくれていました。

リファインメントにはチーム全員が協力して認識を合わせるというコミュニケーションとコラボレーション、また不確実性が大きいとわかったら着手する優先順位を入れ替えるという変化に対する柔軟な対応というアジャイル開発の重要な精神が詰まっているのです。

次回はスプリントプランニング、スプリントバックログ、スプリントの実施について説明します。