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

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

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

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

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

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

プロダクトバックログDeep Dive

吉羽と申します。株式会社アトラクタという零細企業で、アジャイルコーチとかトレーニングとかをやっていたりします。

それから本を書いたりですね、そういうことをしております。大事なお話としてはですね、本買ってくださいっていうことですね。

最新というか直近の3冊がこれです。左側は2020年かな、プロダクトマネジメント ビルドトラップ本ってやつですね。それから去年の12月に「Team Topologies」という本を出しました。

今回はプロダクトバックログの話をするのですが、スクラムガイドの中で「プロダクトバックログ」という単語がどれぐらい登場しているかというのを抽出したのがこの表です。

スクラムガイド2020はボリュームが激減したので回数自体は減ってますけれども、たくさん登場します。それだけ大事だということですね。

プロダクトバックログとは、どうあるべきか

細かいところに入る前に、プロダクトバックログとはどうあるべきかを説明したいと思います。

まず良くないプロダクトバックログは、こんな感じです。荒野のプロダクトバックログというか、なんかもやっとしてて砂嵐が舞っていて。どこも目指せませんという、そんな感じになります。

これはどうかというとゴチャゴチャですよね。とりあえず何かいろいろあるんだけれどゴチャゴチャで、どこか一本抜いたら崩壊しそうだし、どこに何があるのかもよく分かりません。

ではどういうのがいいプロダクトバックログかというと、こういうのがいいプロダクトバックログですよね。

イメージとしてですね。庭なんですけど、大小さまざまな草木が常にお手入れされてる。これを維持しようと思ったら、例えば月1回朝から晩までメンテナンスするのでは駄目で、毎日コツコツちょっとずつメンテナンスしているんですね。

日々ちょっとずつお手入れをして、綺麗な庭園を保ち続ける。こういうのが理想のプロダクトバックログなのかなと。

これを前提に話を聞いていただければと思います。

プロダクトバックログとは何か？

まず基礎の基礎として「プロダクトバックログはなんぞや」を説明していきます。

スクラムガイド2020を見てみると、こんなふうに書いてあります。結構いろんなことが書いてあって凝縮されてるのでなかなか味わい深いのですけれど、ぜひ皆さんも1回読んでください。

これはスクラムガイドの記述を抜粋したものですが、「創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧」とあります。「創発的」というのが一つのポイントですね。

つまり最初に全部出せるものではなくて、後から後から出てくる。

そして「スクラムチームが行う作業の唯一の情報源」ともあります。隠れた他の作業なんかないぞ、ということです。

それから「プロダクトゴール」。「プロダクトゴールはプロダクトバックログに含まれる」。そして「プロダクトバックログアイテムは、そのプロダクトゴールを達成する『何か（what）』を定義するものである」とあります。

で、その「プロダクトバックログアイテムには、説明、並び順、サイズなどの要素が含まれ」ていて、「プロダクトオーナーが管理の責任を持つ」。

管理の責任を持つというのは作業をやらなくてはいけない、という意味ではなくて、最終的にどうなってもプロダクトオーナーの責任だということです。

そういう話なので、作業自体は他の人に委任しても構わないですが、責任は取らなくてはなりません。

そして、スプリントプランニングの時点で準備ができている、というようなことが書かれてます。

つまりプロダクトバックログとは何かというと、「プロダクトゴール＋プロダクトバックログアイテム」になります。

プロダクトゴールとプロダクトビジョン

「プロダクトゴール」は新しい要素です（新野注：「スクラムガイド 2020」から登場）。「プロダクトビジョン」はよく聞きますが、プロダクトゴールって多分みなさん聞いたことないですよね。

スクラムはけっこう独自の用語を使います。というのも、他の概念と混同されたくないので、例えばXPで「イテレーション」と呼んでるものを「スプリント」って呼んだりですね、違う名前を付けることをよくやるのです。

ではプロダクトゴールとは何だろうと、プロダクトビジョンとどう違うんだというのは、こんな感じになると思うんですね。

プロダクトビジョンというのは基本的に抽象的ですよね。根底となるような目的で、プロダクトそのもののあり方に近い、そういうのがプロダクトビジョンです。

こっちの方に行きたいなとか、こういうことを実現したいなとか、我々はこういう目的のためにやってるんですとか、比較的抽象度が高くなります。

一方でプロダクトゴールとは何かというと、プロダクトが達成しなければいけない計測可能なものですね。

かつ、特定の期間。つまり時間軸がある、というものになります。ある期間の中で計測可能な、数値で達成するぞ、というのがプロダクトゴールです。

なのでゴールは、達成すれば次のゴールへ行くこともありますし、途中でこのゴールをやめてゴールを変えたり、そういうこともあります。

ちなみにゴールは同時には一個しか立てられないと決まってます。

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

プロダクトバックログのもう一つの構成要素として「プロダクトバックログアイテム」があります。

スクラムガイドはみなさんご存知の通り、細かいことについては全然書いてないので、プロダクトバックログアイテムの書き方も決められてません。一般的にはここでユーザーストーリーなどを使うケースが多いですね。

ユースケースを使うのは同僚の原田は好きですけれど、僕は書いたことはないです。僕はだいたいユーザーストーリーか、もしくは名前も何もない自分流のやり方なんかで書いてることもあります。

いずれにしても書き方は決まっていません。ただし最低限、順番が決まっていないといけないですし、中身も書かれていなければいけないし、見積もりも入っていなければいけません。

スクラムガイド2017だと「価値」という要素もありましたが、それは内容の中に含めるという話だと思います。それからユニークなIDがあると扱いやすかったりします。

プロダクトバックログの例

これはプロダクトバックログの例です。題材としては、ホテルの新規開業に向けてオンライン対応可能にすることがプロダクトゴールで、こんな感じでプロダクトゴールと、順番に並んだプロダクトバックログアイテムのセット、中身と見積もりも持っていて、並び順も分かっている。

こういうのがプロダクトバックログだというふうになります。

プロダクトバックログの管理方法。これもスクラムガイドでは何も管理方法を決めてないわけです。必要最低限しか決めてなくて、あとは自分たちで考えろ、というのがスクラムガイドのやり方なので、何も管理方法決まってないんです。

一般的なプラクティスとしてはスプレッドシートとか、情報カードとか、付箋紙とか、JiraとかBacklogとかRedmineとか専用ツールとかを使って管理するというのがよくあるパターンかなと思います。

どんなツールを使うかは状況に依存していて、例えば全員がオンサイトか、リモートか、大規模かワンチームか、などで変わってきます。慣れないうちは専用ツールじゃない方がやりやすかったりします。僕のおすすめはGoogleスプレッドシートですね。

プロダクトバックログは、誰でも末尾にプロダクトバックログアイテムを追加できると考えるのが普通なので、それができるツールの方がいいですし、アクセシビリティ、見やすさ、そういうことを考えてツールを選んでください。

ちなみに全項目を入力しようとすると死ぬので、本当に必要な項目だけを入れるのが鉄則で、そのためにもスプレッドシートとか自由度の高いツールを使うのがおすすめです。

スプリントでの作業の進め方

次はスプリントでの作業の進め方の話です。

プロダクトバックログを実際にインクリメントに変えていくときに、どうやって作業を進めていけばいいのか、という話です。

大原則として、スプリントゴールとかスプリントレビューから逆算をしないといけないわけです。なぜかというと、スクラムの基本はフィードバックサイクルなわけです。

ですので、プロダクトに対する定期的なフィードバックが成功することが非常に重要なわけです。

分業しまくって、動いてないものをずっと作り続けて、スプリントレビューで報告だけしても無意味なんです。動くもの実物を見て、それに対してフィードバックをかけていく、というのが何よりも重要です。

なので適切なスプリントゴールを設定し、そのゴールを達成していると思われるインクリメントをレビューで見せることを重視しなければいけない。

インクリメントを絶対見せるんだと、スプリントゴールを絶対に達成するんだと、これを軸に考えてプロダクトバックログを整理していく。

これが考えなくてはいけないことで、開発の事ばっかり考えるんじゃなくって、いかにフィードバックを受けるか、というところから考えていく必要があります。

もう一つの大原則が、準備ができているプロダクトバックアイテムだけをスプリントに投入しろ、ということです。

準備できてないプロダクトバックログアイテムスプリントに突っ込むと、スプリント中に何回もプロダクトオーナーに確認したり、着手したら想像以上に大きいことが分かってどうしようとなったり、プロダクトオーナーにできましたって見せたら、できてないって言われたり。ぐちゃぐちゃになりかねません。

結果的にスプリントごとのVelocityが不安定になって、今後の予測精度が下がる、ということが起こるわけですね。

なので、生煮えのプロダクトバックアイテムを食べるとお腹を壊します。準備ができているプロダクトバックログアイテムだけをスプリントに投入していくというのが、大原則になります。

ただしどこまで準備すれば適切なのかは、そのスクラムチームごとに変わります。検査と適用で、自分たちの良いラインというのを探していかなくてはいけない、ということになります。

この準備できてるよねというのを「READY」と言ったりしますが、READYの定義を決めているチームもあります。

あくまでプラクティスですが、こういう項目が用意されていれば、こういう準備ができていれば、このプロダクトバックログアイテムをスプリントに突っ込んでもいいよね、という基準というかベースラインを合意をしておく、というのはよくやる手だったりします。

スプリントへのプロダクトバックログアイテムの投入

では、スプリントにどういう風にプロダクトバックログアイテムを投入するか。

良くないのは一番上の例。ばかでっかい「XL」を一個、スプリントに投入すること。これは良くないですね。

なぜかというと、大きいほど見積もりが外れます。不確実性も高いので、何か不測の事態が起こるとスプリントレビューで見せるものが何もない、ということが起こります。

上から2番目の例。同じぐらいの大きさ「L」を二つ投入しましたと。これは1個目のアイテムに時間がかかりました、となった瞬間に2個目のアイテムを着手してもスプリント中に終わらないことが分かってしまうので、若干微妙だよねという感じになります。

なので3番目とか4番目の例ですね。サイズ「M」や「S」「M」「L」の混在を複数個スプリントに投入するのがいいのかなと思います。

逆に一番下の例みたいに、とにかく小さい「S」サイズのアイテムをいっぱい投入すると、これはスプリントゴールはなんじゃいという話なんですよね。よく分からんっていうことになるんで、こういうのもあんまりよろしくないということになります。

スプリントでの作業の進め方

スプリントにプロダクトバックログアイテムを投入するとなったら、次はどうやって作業を進めるかです。

これはよくない進め方の例です。6個のプロダクトバックログアイテムを用意して、1日目と2日目に設計すると、3日目から開発するぞと、8日目に結合して最終前日と最終日にテストする。

これは駄目です。テストで大きい問題が見つかると、見せるインクリメントがなくなってしまうという問題ですね。ミニウォーターホールは避けなければいけません。

次は、まとめてテストですね。設計と開発をプロダクトバックログアイテムごとに終わらせていくのですが、最後にまとめて結合してテストする。

これも結合のタイミングで問題が出たりテストのタイミングで問題が出るとスプリントゴールを達成できない可能性が高くなるということで、こういうやり方も避けなくてはいけない。

なので定石的なやり方として、なるべく仕掛かり、WIP（Work In Progress）の数を減らしていきましょう。

一個流しでもよくて、チームのサイズが小さければ一個流しでモブプログラミングでもいいですし、もうちょっとチームが大きいのであれば、同時に仕掛かるプロダクトバックログアイテムの個数を制限して、なるべくプロダクトバックログアイテム単位で、あるアイテムが終わったら次に、終わったらまた次に行く、というやり方で進めていかないと、スプリントレビューで困ったり達成できなくなってしまいます。

もちろんそのWIPを少なくして1個ずつ終わらせていっても、スプリント中に完成しなかったプロダクトバックログアイテムが出たらどうするのか。

単純に未完成として扱えばOKです。あと10分で終わりそうでも、あと1時間で終わりそうでも、完成してないものは完成してない。

定石としては、完成しなかったものはスプリント終了時に再見積もりしてプロダクトバックログに戻し、それをいつやるかはプロダクトオーナーの判断次第、ということになります。

その場合、スプリントゴールは達成できているからこのプロダクトバックログアイテムは完成してなくてもよくて、捨ててしまえ、という判断かもしれませんし、もしくは1スプリントで出来なかったのだから、もっと他に大事なアイテムを先にやった方がいいよね、という判断をするかもしれません。

間違っても自動的に次のスプリントに持ち越すような真似はしないでねということになります。

以上を踏まえると、プロダクトバックログアイテムの粒度には濃淡が必要だということになります。全部がすごく細かくても扱いにくいし、全部が大きくても扱いにくいし、一番右みたいな大小のグラデーションのあるプロダクトバックログアイテムになっている必要が出てきますね。

経験上、100を超える未完成のプロダクトバックアイテムがあると、もうメンテナンスが面倒くさくなったり大変になってきて、似たようなアイテムが複数入ってしまったり、3年間誰も触ってないものが出てきたりします。

一方で、プロダクトバックログアイテムが全部大きいと、それをスプリントに投入してもスプリントで完成しない、もしくはスプリントが一発勝負になりがちです。結果としてVelocityが不安定になって予測ができなくなります。

なのでこんな感じで、上ほど細かく下ほど荒い、という感じでやっていく必要があるわけです。

直近のスプリントで着手するものは、1スプリントで十分収まる大きさにして、下に行くにつれて粒度の大きいものが増えるという感じで、並べ替えて上に来るごとにだんだん手入れをする。

庭の手入れをするようにサイズを切り出していくことが必要です。

スプリントで着手するものは、1スプリントで十分収まる大きさにして、下に行くにつれて粒度の大きいものが増えるという感じで、並べ替えて上に来るごとにだんだん手入れをする。庭の手入れをするようにサイズを切り出していくというのが必要です。

≫続きます：次のページでは、プロダクトバックログアイテムの書き方、分割や並び替えをするときの考え方などが説明されます。

関連記事

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