アジャイル開発に取り組むチームが「プロダクトとして何を作っていくのか」について、それぞれの役割を越えて理解を共通に保つ手段がプロダクトバックログです。「何を作るべきか」を単一のリストとして表現します。プロダクトバックログはチームの活動を駆動する最も重要なインプットでもあります。プロダクトバックログを適当に扱うと、プロダクト作りも適当なものになります。今回は、プロダクトバックログをどのように扱うか取り上げます。
プロダクトバックログとは
スクラムガイドにおいて「プロダクトに必要だと把握しているものをすべて順番に並べた一覧」と意味づけらています。その内容は具体的には「今後のリリースで実装するプロダクトのフィーチャ・機能・要求・要望・修正」が挙げられています。要求の一覧であり、機能の一覧でもあるというわけです。この両者をあわせ持つ一覧となると、その内容の表現や粒度には幅があることになります。
このあたりの自由度がかえって、「プロダクトバックログという情報をどのように扱えば良いのか」という悩みに繋がりやすいものです。この悩みに対する回答として、唯一の正解はありません。作るプロダクトの複雑さや理解度、チームの練度などを踏まえて決めるということになるわけですが、一つ認識しておくことがあります。それは、プロダクトバックログが空（から）になることは無い、ということです。
プロダクトバックログは、プロダクトのあるべき姿、こうしたいという方向性を写像したものと言えます。先程の定義でいう「要望」や「要求」、「機能」や「修正」は、その内容表現の精緻さに差はあるものの、「プロダクトをこうしたい」という点で目的が共通の情報です。
「プロダクトをこうしたい」という声は、プロダクトが存続し、運用され続ける限り、途絶えることが無いでしょう。ですから、プロダクトが生き続ける限り、プロダクトバックログにはプロダクトとして必要なことが充填され続けることになります。
このようにプロダクトは利用され、必要とされる限り、周囲の期待に応えることを通じて成長していくものです。プロダクトが成長していくということは、先立ってプロダクトバックログが存在するということです。この意味で「プロダクトバックログが空になることは無い」と言えるわけです。
そこで、「この機能リストを倒せば仕事として終わり」というものではない、という理解を関係者やチームの間で揃えておきましょう。受託開発の文脈では機能一覧とは「倒し切るべき対象 = プロジェクトの完了条件」と置かれることが多いため、この文脈と誤って混在して捉えてしまうと、「空になることを目指す」という誤った目標設定になりかねません。
こうした目標にしてしまうと、「プロダクトとしてどうあるべきなのか？」という視点が弱くなり（「この一覧を倒せば終わるゲーム」といった認識）、プロダクト作りにとって望ましい状態とは言えません。プロダクトの全体観として必要な判断と、目先の仕事を片付けることを優先する判断は必ずしも一致しません。
プロダクトバックログが腐る？！
ただし、こうした理解の下、プロダクトバックログを成長させながらプロダクト作りを進めていこうとすると、ある問題に突き当たります。それは、プロダクトバックログが「腐る」という状態です。具体的には、プロダクトバックログが膨大になったり（数百個が並ぶリスト）、中身が古くなってしまったゴミのようなものが混在したり、粒度が徹底的に異なっていって管理が煩雑なったりと手がつけられない状態を指します。
こうしてプロダクトバックログが腐ると、取りうる選択肢はだいたい「新しくリストを作り直す」です。その結果、それまで行ってきた調査や仮説検証での学びも一緒くたに過去に葬り去られ、リストも学びもゼロからスタートという状況になることは珍しくありません。これは、もったいないというか、結果的にプロダクト作りの歩みを遅くしたり、方向性を誤る要因にもなりかねません。
もちろん「必要なことであれば自ずとリストに再浮上するはずである」という考え方もあり、腐ったまま運用するよりは現実的かもしれませんが、それまで蓄積してきた学びは意識的に残したいところです。そこで、プロダクトバックログを構造化して管理するという選択が考えられます。
プロダクトバックログを構造化する
プロダクトバックログが腐る要因は、単一のリストで異なる粒度の情報を扱おうとするところにあります。ですから、中身が煩雑になる前に、プロダクトバックログを構造化して管理しようというのが作戦です。
大きく2つの方針があります。
意味的にスロットを分ける
一つは、「意味的にスロットを分ける」という方針です。スロットとは、入り口のことです。つまり、プロダクトバックログに至る入り口を分けようということです。例えば、プロダクトに関するアイデアレベルの情報。根拠のない「こうした方が良いのではないか」という思いつきや直観。こうしたものを排除するのではなく、いきなりプロダクトバックログに混ぜ込まないようにする。一旦、別のリストに入れておくようにするわけです。こうしたアイデアも、検証や適切な評価を行うことによって有望なものになりえる可能性があります。そうした活動を経てから、プロダクトバックログに移していく運用です。
プロダクトバックログの次のレベルの構造を持つ
もう一つは、「プロダクトバックログの次のレベルの構造を持つ」という方針です。通常、プロダクトバックログからスプリントでやるべきものを選別し、スプリントバックログを成します。実際のプロダクト作りでは、プロダクトバックログをある一定まとめた単位、「テーマ」のようなものが存在するはずです。外部サービスとの連携に伴う開発であるとか、決済機能の充実であるとか、おおよそある時期に「プロダクトをこうしたい」というまとまった機能群のことです。
もう一つは、「プロダクトバックログの次のレベルの構造を持つ」という方針です。通常、プロダクトバックログからスプリントでやるべきものを選別し、スプリントバックログを成します。実際のプロダクト作りでは、プロダクトバックログをある一定まとめた単位、「テーマ」のようなものが存在するはずです。外部サービスとの連携に伴う開発であるとか、決済機能の充実であるとか、おおよそある時期に「プロダクトをこうしたい」というまとまった機能群のことです。
こうしたまとまりをその他の比較的小粒の機能開発とともに、複数回のスプリントで片付けていくという状況があるかと思います。この複数回のスプリントに見合った（つまりテーマに対応した）バックログを設けるイメージです。このバックログを「ある段階（=複数回分のスプリント）において片付けたいバックログ」として、私は「ジャーニーバックログ」と呼んでいます。「ある段階」のことを一つの旅（ジャーニー）になぞらえています。
プロダクトバックログとジャーニーバックログ、ジャーニーバックログとスプリントバックログの間で、一つ一つの「プロダクトをこうしたい」という中身をより詳細にしていきます。この構造化の狙いはリストの分割とは別にもう一つ、情報の詳細さをコントロールするところにあります。こうして、様々な粒度の情報が混在するリストを管理する煩雑さを低減させるわけです。
冒頭で述べたように、プロダクトバックログの扱い方に唯一の正解はありません。本稿をもとにそれぞれのチームで、そのあり方の模索が進むことと期待します。
