nishida “とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。
「スクラムガイドにはこう書いてあるし、ブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこない時、ここでのお話が何か一つでもヒントになれば幸いです。
第10回のテーマは「プロダクトバックログ」です。前編では、プロダクトバックログの粒度や内容、整理の仕方などについてお話します。
中村 洋 Yoh Nakamura
株式会社レッドジャーニー
CSP-SM(認定プロフェッショナルスクラムマスター)・CSPO(認定プロダクトオーナー)
様々な規模のSIerや事業会社でのアジャイル開発に取り組み、今に至る。現在まで主に事業会社を中心に40の組織、80のチームの支援をしてきた。「ええと思うなら、やったらよろしいやん」を口癖に、チームや組織が自分たちで”今よりいい感じになっていく”ように支援している。
※発表資料 「いい感じのチーム」へのジャーニー、チームの状況に合ったいろいろなタイプのスクラムマスターの見つけ方、アジャイルコーチが見てきた組織の壁とその越え方、など多数。
新井 剛 Takeshi Arai
株式会社レッドジャーニー 取締役COO
CSP(認定スクラムプロフェッショナル)、CSM(認定スクラムマスター)、CSPO(認定プロダクトオーナー)
プログラマー、プロダクトマネージャー、プロジェクトマネージャー、アプリケーション開発、ミドルエンジン開発、エンジニアリング部門長など様々な現場を経て、全社組織のカイゼンやエバンジェリストとして活躍。現在はDX支援、アジャイル推進支援、CoE支援、アジャイルコーチ、カイゼンファシリテーター、ワークショップ等で組織開発に従事。勉強会コミュニティ運営、イベント講演も多数あり。
Codezine Academy ScrumBootCamp Premium、機能するチームを作るためのカイゼン・ジャーニー、今からはじめるDX時代のアジャイル超入門 講師
著書「カイゼン・ジャーニー」、「ここはウォーターフォール市、アジャイル町」、「いちばんやさしいアジャイル開発の教本」、「WEB+DB PRESS Vol.111 見える化大作戦特集」
スクラムは、複雑なプロダクトを開発・提供・保守するためのフレームワークです。1990年代初頭、Ken Schwaber と Jeff Sutherland によって開発されました。
スクラムに取り組む際の拠り所となるのが、スクラムの定義やルールを示した「スクラムガイド」です。2010年に最初のバージョンが発表され、その後アップデートが加えられながら進化し続けています。
全18ページ（2020年版）という小さなガイドですが、目的や理論から実践まで分かりやすくまとめられており、スクラムの本質が理解できるようになっています。
「プロダクトバックログ」および関連する箇所について、スクラムガイドにはこのように解説されています。
スクラムの作成物
スクラムの作成物は、作業や価値を表している。これらは重要な情報の透明性を最大化できるように設計されている。作成物を検査する人が、適応するときと同じ基準を持っている。
各作成物には、透明性と集中を高める情報を提供する「確約（コミットメント）」が含まれている。これにより進捗を測定できる。
- プロダクトバックログのためのプロダクトゴール
- スプリントバックログのためのスプリントゴール
- インクリメントのための完成の定義
これらの確約は、スクラムチームとステークホルダーの経験主義とスクラムの価値基準を強化するために存在する。
プロダクトバックログ
プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧である。これは、スクラムチームが行う作業の唯一の情報源である。
１スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。多くの場合、属性は作業領域によって異なる。
作業を行う開発者は、その作業規模の評価に責任を持つ。開発者がトレードオフを理解して選択できるように、プロダクトオーナーが開発者を支援することもできる。
確約（コミットメント）：プロダクトゴール
プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットになる。プロダクトゴールはプロダクトバックログに含まれる。プロダクトバックログの残りの部分は、プロダクトゴールを達成する「何か（what）」を定義するものである。
プロダクトとは価値を提供する手段である。プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある。
プロダクトゴールは、スクラムチームの長期的な目標である。次の目標に移る前に、スクラムチームはひとつの目標を達成（または放棄）しなければならない。
出典：スクラムガイド
…とはいえ、実際の現場ではガイド通りには進みませんし、そもそも書かれていないような事態も多々起こります。そうした「とはいえ」に、どのようにアプローチしていけば良いでしょうか。
プロダクトバックログアイテムって、どんなことを書けばいい？
中村：
今日は、スクラムガイドの「スクラムの作成物」「プロダクトバックログ」「確約（コミットメント）：プロダクトゴール」の3つの項目についてお話していきます。
3つ目の「プロダクトゴール」は、2020年版のスクラムガイドから導入された概念ですね。
スクラムガイドを読んでみると、最初のページだけでも一時間くらい話せそうで（笑）、気になるキーワードが幾つもありますよね。
例えば、「創発的」という言葉の意味とか、「リファインメント」についてもサラッと書かれていますけど、具体的にはどういうことなのか？ とか。
「プロダクトバックログ」の最後の段落には、「作業を行う開発者は、その作業規模の評価に責任を持つ」とありますが、つまり「見積もりは自分たちがするんだよ」ということですよね。
とはいえ、実際はどういうことなのか？ 考えさせられます。
新井：
短い文章の中にいろいろな要素が詰まっていますよね。
さて、プロダクトバックログアイテムにはどのようなことを書くのか？ というと、端的に言えば「必要なものを必要なだけ書きましょう」ということでしょうか。
スクラムガイドには「説明・並び順・サイズなどの詳細を追加する」とありますから、この辺りは最低限必要な要素かな。
中村：
最近はあまり言われなくなりましたが、一時期はユーザーストーリーを使って書いてみるという方法がありましたよね。
誰が・何を・なぜほしいのか？ みたいなことを書くところから会話が始まるといいよね、っていう。
あとは、いわゆる受け入れ基準ですよね。なにが実現できたらプロダクトバックログアイテムとして完成なのか、というところ。
新井：
そういったことが書いてあると、エンジニア側もユーザーストーリーに寄っていくというのかな、機能の開発ではなくて、お客様が喜ぶことにフォーカスできますよね。
中村：
ビジネス上の数字がどんな風に変わればうれしいの？ といった観点で書いているチームも多いです。
例えば、ECサイトならカートの挿入率が○パーセントプラスになったらうれしい、といった感じですね。
ここ数年は、定量的な計測データの話も付け加えることが多いですね。
新井：
項目数が多いほど良いわけではなくて、多すぎると続かなくなっちゃったりもするので、削ぎ落とす部分は削ぎ落として、本当に大事なものを残すという考え方は大事かな。
チーム内で暗黙の了解になっているようなものまで書いてしまうと、逆にオーバーヘッドになってしまうので、要らないものは書かなくていいというのもポイントですね。
中村：
プロダクトオーナーが最初からびっしりプロダクトバックログを埋め込む必要はないですよね。
「こんなことがしたい」っていうタイトルだけ書くような感じで良くて、そこから開発者と一緒に会話をしながら、必要な体験やそれを実現する機能、受け入れ基準を見つけていけばいいと思います。
新井：
プロダクトバックログアイテムをきっかけに、会話ができるといいですよね。
活字にするのはもちろんいいと思いますが、それがあるから大丈夫ということではなく、プラスアルファでコラボレーションをするための会話が必要ですよね。チームで行間を埋めてほしいです。
中村：
むしろ、そうした会話のためにプロダクトバックログアイテムがあるくらいの位置づけの方がいいかもしれませんね。
Message from coaches
- プロダクトバックログアイテムをチームのコラボレーションのきっかけにしよう。活字に頼りすぎず、行間を埋めるための会話を大切にしよう。
- 項目数が多くなりすぎないように、暗黙の了解になっていることなど要らないことは削ぎ落として必要最小限にまとめよう。
- 説明・並び順・サイズは最低限必要。加えて、受け入れ基準、定量的な計測データに基づいた実現目標などを盛り込むのもOK。
- 「誰が・何を・なぜほしいのか？」（ユーザーストーリー）や「何が実現できたらプロダクトバックログとして完成なのか」（受け入れ基準）、ビジネス上の数値目標（定量的な計測データ）をヒントに考えると、機能の開発にとどまらずユーザー目線でのアウトカムにフォーカスしやすくなる。
プロセスカイゼンなどのタスクもプロダクトバックログに入れていい？
中村：
プロダクトバックログは「スクラムチームが行う作業の唯一の情報源」ですから、ふりかえりで出たカイゼンタスクもプロダクトバックログに入れる方がいいですね。
新井：
ただ、ふりかえりで出てきたタスクって、ユーザーストーリー的に書くのが難しかったりしますよね。
暗黙の了解になっているようなことなら、あえてユーザーストーリーのフォーマットに則ることはないと思います。
中村：
カイゼンする内容を端的に書くのもいいですし、もう少し深く「それによって誰が・どううれしいの？」といった開発者にとってのメリットについて話してみるのもいいですね。
新井：
開発者が精神的に楽になる、リードタイムが減る、全体の作業量を考えれば元が取れる、といった説明が加わることで、プロダクトオーナーやステークホルダーも理解しやすいと思いますし、優先度を判断する材料にもなりますよね。
中村：
フィードバックを得られやすくなりますね。
Message from coaches
- プロダクトバックログは、チームとスプリントの透明性を高めるための大事な情報源。ふりかえりで出たプロセスカイゼンなどのタスクも入れておこう。
- ユーザーストーリーのフォーマットに合わせづらいときは無理に合わせなくてOK。
- そのカイゼンタスクがチームにどんな効果をもたらすのか、開発者視点でのメリットをプロダクトオーナーやステークホルダーと共有しよう。理解が深まり、フィードバックが得られる良いきっかけになるはず。