プロダクトバックログDeep Dive。スクラムのプロダクトバックログをどう作成し、手入れし、スプリントに投入するべきか（後編）。Regional Scrum Gathering Tokyo 2022

代表的なアジャイル開発手法の1つであるスクラムを構成する要素として「プロダクトバックログ」はもっとも重要なものの1つです。

プロダクトバックログは、プロダクトが目指す「プロダクトゴール」を含み、「スクラムチームが行う作業の唯一の情報源」とされています。

このプロダクトバックログとはどのようなもので、どう作成し、手入れをし、どのようにスプリントへ投入していくべきなのかを詳しく解説した、株式会社アトラクタ 吉羽龍太郎氏のセッション「プロダクトバックログDeep Dive」が、1月5日から7日まで行われたイベント「Regional Scrum Gathering Tokyo 2022」で行われました。

スクラムを実践していく上で欠かせない知識やノウハウが集約されたセッションの内容を、ダイジェストで紹介します。

（この記事は前編、中編、後編の3つに分かれています。いまお読みの記事は後編です）

プロダクトバックログの作り方

最後は、プロダクトバックログを作りましょう、という話です。初期のプロダクトバックログの作り方ですね。

プロダクトバックログアイテム自体はプロダクトゴールからの導出なので、まずはプロダクトゴールを考えましょう。

ゴールを決める前に詳細な機能の話をしても無意味なんです。なのでプロダクトビジョンもそうだしプロダクトゴールもそうなんですけど、誰にどんな価値を提供して、その結果どうなってほしいんだ、という、方向性の共通理解をみんなで作るというのが重要です。

その上でみんなでプロダクトバックログのアイテムの候補を考えてください。

最初に誰か1人、例えばプロダクトオーナーが全部プロダクトバックログアイテムを用意できるのであれば、それは「私考える人、あなたたち作る人モデル」なので、別にスクラムでフィードバックサイクルを回して作らなくてもいいじゃん、となるかもしれないですよね。

重要なのは、なるべく早く一番重要な仮説を検証できるように持っていくというのが理想型です。

初期のプロダクトバックログアイテムは、数がたくさんあっても無意味です。どうせ全部作ることはありません。

100個あっても、実際にリリースのときに実現されるのは10個～20個ぐらいなんじゃないですかね。全部作ることはまずないと。

新しいプロダクトバックログアイテムを見つけ方はたくさんあるので、時間を取ってやってください。

スプリントレビューからも新しいプロダクトバックログアイテムを見つけられるでしょうし、サポートへのリクエストとか、ユーザーインタビューとかログとか、マトリクス分析したりA/Bテストしたり。

開発者のペインからもプロダクトバックログの改善につなげられるはずなので、単に誰かが作ったプロダクトバックログアイテムをソフトウェアに変えるマシンになるんじゃなくて、限られた人的資源とか時間の中でどうやってプロダクトの価値を高くするのかを考えて、良いプロダクトバックログアイテムを作るところに時間を使ってください。

こんな風にプロダクトバックログを常にお手入れしてくださいね、というのが、お伝えしたい内容になります。

ということで僕の話はこれでおしまいです。ありがとうございました。

参加者との質疑応答

Q） プロダクトバックログが多くなりすぎると大変という話があったと思うんですが、一番上のアイテムを分割していくつかをスプリントに投入して、残りは後回しでいいや、となった場合に、小さいプロダクトバックログアイテムがどんどん増えていくと思うんです。

その一つ下のまだ大きいプロダクトバックログアイテムをまた分割すると、分割して小さくなって後回しになったアイテムがどんどん下に溜まっていく。結局小さいアイテムが100個以上に増えてしまうと。それはもう諦めて、どこかの段階で消していけばいいのでしょうか。

A）すごいいい質問です。ありがとうございます。やっぱもういいやってなったタイミングで、そういう小さくなったプロダクトバックログアイテムを捨てるのが肝ですね。

どうせやらないと分かった時点で捨てる、というのはよくやる手ですし、本当に重要なプロダクトバックログアイテムなら、また後からちゃんと登場してくるものです。

ですからプロダクトバックログの中に全ての履歴とか全ての情報を含めておく必要はあんまりない、というのが個人的な意見です。

捨てずに別の場所に置いて、半年に1回くらい見ましょう、でも十分かもしれないですし。いずれにしても、プロダクトバックログアイテムが不要になったら、不要なアイテムは削除していくっていうのをやった方がいいと思います。

Q）プロダクトゴールを一つ置いたときに、例えば開発者のペインが発端でプロダクトバックログアイテムが生まれてきたとして、それは特定のプロダクトゴールに紐づくわけじゃないので、プロダクトゴールに向かっていくという位置づけにはできなくて、扱いにくくなるのかなと思ったのですが、それはどう考えたらいいんですか。

A）これもすごくいい質問なんですけど、確かにプロダクトゴールがベースにあり、それがスプリントゴールで踏み石になって実現されていくんですけど、だからといって例えば非機能とか、ミドルウェアのバージョンアップとか、リファクタリングとか、やらなきゃいけないことっていっぱいあって。

そういうのって全部スプリントゴールに関係ないからやっちゃいけないかっていうと、そんなことはないです。

そんなことしたらソフトウェアとして成り立たないので、あくまでもバランスの話なのかなって思います。

個人的には、根拠も別にないんですけど、いわゆるスプリントゴール直結のプロダクトバックログアイテムを7割。非機能とか、そのリファクタリングとか開発ツールとか、足回りに近いところに3割の時間を使う、と言う人もいて、僕も一定割合は足回りに時間を使った方がいいと思ってて、そういうバックログアイテムも入れた方がいいと思ってます。

逆にプロダクトオーナーが機能系のプロダクトバックログアイテムばかりをスプリントゴールに関係あるからって押しつけてきたら、めっちゃリスクが高くなると思うので、必ずしも全部がゴールに100％関係しなくてはいけないわけではない、というのが僕の解釈です。

スクラムガイドってそれなりに抽象度高くて、正面から受け止めると結構不自由というか、こういうときどうするの？ というところが多いと思うんですけど、普通に現実的に考えてこうだよねって考えていただいて、それをレトロスペクティブとかで、みんなで話していただいて、うまくいけば定着させればいいし、うまくいかなかったらやり方変えればいいのかな、と思います。

Q）バグチケットについて教えてください。バグチケットって結構小さくなりがちだったり、価値として書きにくい、というのがあると思うんですけど、そういう中でバグチケットの扱い方についてコツとかもしあったら教えてほしいです。

A）これもスプリントゴールに全部が結び付かなきゃいけないか、という話と似てるんですけど、バグはバグで直さなきゃいけないことが多いです。

ただ、必ずすぐ直さなきゃいけないわけではないので、バグもトリアージが必要だと思うんですね。

つまり放っておくと月額1億円ずつ損害が発生します、となればすぐ直すべきでしょうし、1年に1回こういう条件満たしたユーザーに限り起こるんだけどF5を押せば直ります、みたいなバグだったら多分直さなくていいと思うので、バグチケット全部に対応するのは、まずやめた方がいいのかなという気はしますね。

リスクが大きい、インパクトが大きいやつは早めのスプリントに入れたり、サービスが止まって致命的ですってなったら、今のスプリントをキャンセルして障害対応することもあると思います。

いずれにしても、どういうリスクやインパクトがあるのかを明らかにしていく。そこで関係ないやつは対応をしない、っていうのがいいのかなと思います。

司会）時間になりましたので本セッションは終了としたいと思います。ありがとうございました。

参考：【資料公開】プロダクトバックログ Deep Dive

関連記事

• ベロシティ Deep Dive。スクラムにおけるベロシティのアンチパターンと適切な使い方とは（前編）