プロダクトバックログDeep Dive。スクラムのプロダクトバックログをどう作成し、手入れし、スプリントに投入するべきか（中編）。Regional Scrum Gathering Tokyo 2022
代表的なアジャイル開発手法の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ブラウザで見える、スマホで見える、印刷できる、という感じに分けることができそうです。
それから、入力パラメータで分割。「ホテルの空き情報を知ることができる」というプロダクトバックログアイテムを分割すると、日程を指定して空き情報を知ることができる。部屋のサイズを指定して知ることができる。価格の範囲を指定して知ることができる。みたいに分ければ、とりあえず日程だけの検索で申し込んでもらえればいいのでは、ほかの部分は後回しにしましょう、と言えそうです。
あとはCRUDで分割。追加、更新、削除ですね。宿泊対象の部屋を追加、更新、削除できるとしたら言ったらそれぞれに分割する、というのもあります。
ただし、Ruby on Railsなどを使っているとCRUDは全部1日できるよね、というケースもありますので、あくまでも例としてはこういう分け方もあります、ということです。
それから人の役割ですね。利用者の役割によって分割する。
それからブラウザとか入力デバイスのバージョンで分割する。
こんな感じで、あの手この手で意味のある単位で分割をするというのが肝ですね。
プロダクトバックログの並べ替え
次は、プロダクトバックログの並べ替えの話です。
並べ替えには非常にシンプルな原則があります。いくつかの観点を組み合わせて並べ替えをするのがポイントです。
スクラムガイドは、並べ替えをしなさい、としか言ってないんですけど、一般的には価値の高いものは上に行きます。
それから、なるべくリリースまでの時間が短くなるような並び順にします。
そしてリスクが最小になるように。例えば、機械学習を使ってこういうことをやりたいんだ、というプロジェクトの場合、そこが駄目だったら後続のスプリントをやる意味すらなかったりするので、そういうリスクのあるやつを先にやることでリスクが最小になったりします。
ですので、リスクが大きいものが上に行く。
将来の無駄を避けるために、先に入力画面とかデータ登録機能を作った方が楽だよね、みたいな理由で先にすることもあるでしょう。
もちろん、プロダクトバックログアイテムの大きさや発生するコストとかによっても並び順が変わります。
お金がかからなくて、ほどほどの価値のものを先にしよう、とか、お金がすごいかかるけど価値もまあまあ高いというのをどうしよう、とか、みたいな感じで並び替えていく。
価値だけじゃなく、複数の要素を組み合わせてプロダクトバックログアイテムを並び替えていただく必要があります。
ログイン機能は先に作るべき？
ちょっと重要な話なんですけど、ログイン画面やログイン機能って、だいたい作るじゃないですか。開発の段取りを考えると画面遷移上の導線になるので、ログイン機能は先に作りたくなるんですね。
まずログインして、その後にこういうのが表示されて、次にこういうことをやっていきますよ、と考えるとログイン画面を先に作りたくなるんですけど、これはちょっと考えた方がいいですよね。
例えば第1スプリントでログイン機能を作りましたと。ステークホルダーを呼んでスプリントレビューに招待しました。さあデモします。
Webブラウザを開いて、IDパスワードを入れて送信ボタンを押してログインします。以上です。となったら、それはアホですかと。
特に初期のスプリントレビューは、プロジェクトの方向性が正しいのか、みたいな、何か検証したい課題があるはずなんです。そこにログイン画面だけを見せても意味ないかもしれないですよね。
ログイン機能を作るとどんなリスクが減るのか、どんな価値が生まれるのか、どんなフィードバックが欲しいのか、と考えると、開発側の都合でログイン機能を先に作るのはちょっとナンセンスだということになります。
≫続きます：次のページでは、初期のプロダクトバックログの作り方、分割してどんどん小さなプロダクトバックログアイテムが増えたらどうするのか、など会場からの質問に答えます。
関連記事
あわせて読みたい
プロダクトバックログDeep Dive。スクラムのプロダクトバックログをどう作成し、手入れし、スプリントに投入するべきか（後編）。Regional Scrum Gathering Tokyo 2022
≪前の記事
プロダクトバックログDeep Dive。スクラムのプロダクトバックログをどう作成し、手入れし、スプリントに投入するべきか（前編）。Regional Scrum Gathering Tokyo 2022
