プロダクトバックログをチームのコラボレーションのきっかけにしよう ─ ”とはいえ”シリーズ #10「プロダクトバックログ編」（前編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。

「スクラムガイドにはこう書いてあるし、ブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこない時、ここでのお話が何か一つでもヒントになれば幸いです。

第10回のテーマは「プロダクトバックログ」です。前編では、プロダクトバックログの粒度や内容、整理の仕方などについてお話します。

プロダクトバックログアイテムって、どんなことを書けばいい？

中村：
今日は、スクラムガイドの「スクラムの作成物」「プロダクトバックログ」「確約（コミットメント）：プロダクトゴール」の3つの項目についてお話していきます。

3つ目の「プロダクトゴール」は、2020年版のスクラムガイドから導入された概念ですね。

スクラムガイドを読んでみると、最初のページだけでも一時間くらい話せそうで（笑）、気になるキーワードが幾つもありますよね。

例えば、「創発的」という言葉の意味とか、「リファインメント」についてもサラッと書かれていますけど、具体的にはどういうことなのか？　とか。

「プロダクトバックログ」の最後の段落には、「作業を行う開発者は、その作業規模の評価に責任を持つ」とありますが、つまり「見積もりは自分たちがするんだよ」ということですよね。
とはいえ、実際はどういうことなのか？　考えさせられます。

新井：
短い文章の中にいろいろな要素が詰まっていますよね。

さて、プロダクトバックログアイテムにはどのようなことを書くのか？　というと、端的に言えば「必要なものを必要なだけ書きましょう」ということでしょうか。

スクラムガイドには「説明・並び順・サイズなどの詳細を追加する」とありますから、この辺りは最低限必要な要素かな。

中村：
最近はあまり言われなくなりましたが、一時期はユーザーストーリーを使って書いてみるという方法がありましたよね。
誰が・何を・なぜほしいのか？　みたいなことを書くところから会話が始まるといいよね、っていう。

あとは、いわゆる受け入れ基準ですよね。なにが実現できたらプロダクトバックログアイテムとして完成なのか、というところ。

新井：
そういったことが書いてあると、エンジニア側もユーザーストーリーに寄っていくというのかな、機能の開発ではなくて、お客様が喜ぶことにフォーカスできますよね。

中村：
ビジネス上の数字がどんな風に変わればうれしいの？　といった観点で書いているチームも多いです。
例えば、ECサイトならカートの挿入率が○パーセントプラスになったらうれしい、といった感じですね。
ここ数年は、定量的な計測データの話も付け加えることが多いですね。

新井：
項目数が多いほど良いわけではなくて、多すぎると続かなくなっちゃったりもするので、削ぎ落とす部分は削ぎ落として、本当に大事なものを残すという考え方は大事かな。

チーム内で暗黙の了解になっているようなものまで書いてしまうと、逆にオーバーヘッドになってしまうので、要らないものは書かなくていいというのもポイントですね。

中村：
プロダクトオーナーが最初からびっしりプロダクトバックログを埋め込む必要はないですよね。

「こんなことがしたい」っていうタイトルだけ書くような感じで良くて、そこから開発者と一緒に会話をしながら、必要な体験やそれを実現する機能、受け入れ基準を見つけていけばいいと思います。

新井：
プロダクトバックログアイテムをきっかけに、会話ができるといいですよね。

活字にするのはもちろんいいと思いますが、それがあるから大丈夫ということではなく、プラスアルファでコラボレーションをするための会話が必要ですよね。チームで行間を埋めてほしいです。

中村：
むしろ、そうした会話のためにプロダクトバックログアイテムがあるくらいの位置づけの方がいいかもしれませんね。

プロセスカイゼンなどのタスクもプロダクトバックログに入れていい？

中村：
プロダクトバックログは「スクラムチームが行う作業の唯一の情報源」ですから、ふりかえりで出たカイゼンタスクもプロダクトバックログに入れる方がいいですね。

新井：
ただ、ふりかえりで出てきたタスクって、ユーザーストーリー的に書くのが難しかったりしますよね。

暗黙の了解になっているようなことなら、あえてユーザーストーリーのフォーマットに則ることはないと思います。

中村：
カイゼンする内容を端的に書くのもいいですし、もう少し深く「それによって誰が・どううれしいの？」といった開発者にとってのメリットについて話してみるのもいいですね。

新井：
開発者が精神的に楽になる、リードタイムが減る、全体の作業量を考えれば元が取れる、といった説明が加わることで、プロダクトオーナーやステークホルダーも理解しやすいと思いますし、優先度を判断する材料にもなりますよね。

中村：
フィードバックを得られやすくなりますね。