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

2022年1月11日

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

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

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

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

プロダクトバックログアイテム

次は、プロダクトバックログアイテムを見ていきます。

先ほど説明した通り、スクラムではプロダクトバックログアイテムの書き方などは決められていません。

どんな書き方をしてもいいのですが、よく使われるのはユーザーストーリーです。

XP由来で、誰々として何ができると、それは何のためです、というのを簡単に書いたものですね。

右側にある絵はケント・ベックのやつですけど、意図的な制約、領域の制約がある、というのが肝だったりします。

ユーザーストーリーをどう扱うのかというと、Card、Conversation、Confirmationとよく言われます。

ストーリーをカードに書いて、見積もりとかメモも一緒に書く。物理的な制約もあるでしょう。

それらをもとプロダクトオーナーと会話をすると、会話からもっと細かい情報が引き出されるはずです。それを受け入れテストで正しく実装されてるか確認しましょう。

つまり、単にフォーマットに従って書けばいいかというと、それは些細な話で、会話から引き出されるところが非常に重要になってきます。

ユーザーストーリーについて、これらが満たされるとよい特性として、他によく言われるのがIndependent、Negotiable、Variable、Esitmable、Sized Right、Testableなどです。

ただし全てのプロダクトバックログアイテムがこれらを全部満たせるかというとそんなことはなくて、順番が上のものは満たさなくてはいけないけれど、下のものはどうせすぐやるわけでもないのでとりあえず放っておいて大丈夫です。

で、どういうふうに書いたらいいんですかってすごい聞かれるんですけど、本当に大事なのはですね、そもそもどういう課題を解決しようと思っているのか、です。規模感や必然性や、そういう議論を誘発するのが重要で、その会話なしに共通理解は生まれないわけです。

プロダクトオーナーがプロダクトバックログアイテムを書いて、開発者に投げ込んで、あとよろしくね、という類のものではなくて、会話が必要なんです。

重要なのは共通理解で、これを形成できるように話さなきゃいけないし、話す時間をとってくださいね、というのが肝だったりします。

もちろんユーザーストーリーだけじゃなくって、ユーザーストーリーの他に受け入れ基準を書いたり、そもそも解決したい課題を書いたり、WindowsなのかiOSなのかAndroidか、プラットフォームを書いたり、KPIを書いたりですね、必要に応じて自分たちで情報を足していけばいいので、フォーマットを決めたからこれ全部埋めてください、というものではないということです。

これは避けたいプロダクトバックログアイテムの例

ちょっと避けたいプロダクトバックログアイテムの例を見ておくと、「○○機能が欲しい、なぜなら○○機能がないから」というものがあります。そりゃそうでしょうというやつですね。

ソリューションがないのは分かるけど、それを作りたい理由があるはずなので、それを教えてくれという話です。こういうのはつらい。

それから画面単位のプロダクトバックログアイテム。これは最初にプロトタイプとかモックを作ると、こういうプロダクトバックログアイテムを作りがちなんです。

しかしこれは良くないアプローチです。画面には通常多くの要素が入っていて、1スプリントで完成させるには大きすぎることが多いんですね。

例えば「検索画面」と言ってもいろんな項目が入っているわけです。それをばらして考えると、必須のものとそうじゃないものがだいたい混在していて、一気に作ろうとするととても時間がかかるので、こういうのはよくないということですね。

デプロイを自動化したい、みたいなプロダクトバックログアイテムも気持ちは分かります。ですが、本当に解決したい課題はデプロイにかかる時間が長すぎるのか、手順を頻繁に間違えてしまうのか、デプロイ職人がいないとデプロイできないのか、などの理由があるはずで、そこが分かるとフルに自動化しなくても解決できるかもしれないですよね。

なので、本当に解決すべき課題とは何かを表現するのが理想です。

プロダクトバックログアイテムの「お手入れ」

次は、プロダクトバックログアイテムをお手入れの話をしていきたいと思います。

よくやるのはプロダクトバックログリファインメントですね。

これはイベントではなくて活動なので、定常的にやりましょう。もちろんイベント的にやってもいいんですけど、新規のプロダクトバックログアイテムを足したり見積もったりですね、いらないやつを削除したり見積もり直したり。

それから並び順が最新になっていることを確認したり。

それから次のスプリント、次の次のスプリントにはREADYのプロダクトバックログアイテムを投入しなきゃいけないということで、詳細を確認してREADYにする作業というのも必要でしょう。

上位にいて大きいサイズのプロダクトバックログアイテムは、分割しなくてはいけないですし。

こういうのがプロダクトバックログリファインメントでやる内容です。

開発する項目も多いし忙しいのでリファインメントに使える時間が全然ないんですと、よく言われますが、これは逆で、プロダクトバックログの手入れをしないから時間がなくなるんです。

生煮えのプロダクトバックログアイテムをスプリントに投入して、無理に作ろうとしてスプリントがぐちゃぐちゃになるから、手入れをする時間がなくなるのであって、ちゃんと手入れをしておけばいいはずです。

それから構造上、プロダクトオーナーはボトルネックになりやすいものです。開発者のスキルが上がってくると、一般的にそのプロダクトオーナーの部分がボトルネックになるんですね。

そうしたらプロダクトオーナーのサポート役を増やしてでも、そのプロダクトバックログアイテムを安定供給できるようにしていかなきゃいけないですね。

プロダクトバックログアイテムの分割

よくあるお手入れの一つが、プロダクトバックログアイテムの分割です。

さっきのホテルの予約の例で言うと、「利用者としてホテルの予約をキャンセルできる」というプロダクトバックログアイテムは、プレミアムメンバーだったらギリギリまで予約をキャンセルできる、一般客だったら24時間前までキャンセルできる、キャンセルしたらメールが飛ぶ、みたいに分割できそうです。

分割の利点は、分割するとそれぞれのアイテムが全く違う並びになるところです。

例えば、とりあえず一般客対応だけは真っ先にやらなくてはいけないけれど、メールはとりあえず送らなくてもいい。プレミアムメンバーはまだいないから将来でいい、など、順番がバラバラになる。そういうのが利点ですね。

分割はやり方がいっぱいあってですね、ここで紹介してるのは全部で10個ぐらいです。

はっきり言えるのは、いわゆる開発工程では分割するな、ということです。

このスプリントで設計をして次のスプリントで開発しますとか、ちょっと何言ってるか分かりません。

それから、このスプリントでHTMLのフォームの部分を作って、次のスプリントでサーバーサイド作りますとか。これも数珠つなぎでウォーターフォールみたいにスプリントごとの依存関係が生まれるのでよくないです。

ですから意味のある機能性を持った状態で分割をしなくてはいけません。

例えば、ワークフローのステップで分割する。

「ユーザーがホテルを予約できる」というのが分割前のプロダクトバックログアイテムだとすると、分割後はユーザーが部屋と日程を指定してホテルの予約を送信できる。ホテルの予約の際に本人確認が行われる。予約が終わったら確認メールがユーザーに届く。と、こんな感じです。

本人確認とか確認メールはあとのスプリントでもいいかもしれません。

それから、ビジネスルールで分割。

いずれにしても、意味のある単位が残っているということがポイントになってきます。

プラットフォームで分割する場合には、「予約状況を見ることができます」というプロダクトバックログアイテムを、Webブラウザで見える、スマホで見える、印刷できる、という感じに分けることができそうです。

それから、入力パラメータで分割。「ホテルの空き情報を知ることができる」というプロダクトバックログアイテムを分割すると、日程を指定して空き情報を知ることができる。部屋のサイズを指定して知ることができる。価格の範囲を指定して知ることができる。みたいに分ければ、とりあえず日程だけの検索で申し込んでもらえればいいのでは、ほかの部分は後回しにしましょう、と言えそうです。