チームで育てるプロダクトバックログ。効果的に管理・運用するには？ ─ ”とはいえ”シリーズ #10「プロダクトバックログ編」（後編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。

「スクラムガイドにはこう書いてあるし、ブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこない時、ここでのお話が何か一つでもヒントになれば幸いです。

第10回のテーマは「プロダクトバックログ」です。後編では、プロダクトバックログをチームで管理・運用する方法や、プロダクトゴールとの効果的な紐づけ方などについてお話します。

前編はこちら

プロダクトバックログをチームのコラボレーションのきっかけにしよう ─ ”とはいえ”シリーズ #10「プロダクトバックログ編」（前編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにア…

redjourney.jp

プロダクトゴールって何のためにあるの？

新井：
「プロダクトゴール」は2020年版のスクラムガイドから登場した新しい話題ですから、その分難しさもありますよね。

中村：
「プロダクトゴール」の概念、私は好きなんですよね。

スクラムチームが、ただバックログを上から片付ければいいということじゃなくて、「プロダクトがどうなればいいのか」「ユーザーが3ヶ月後にどんなことができたらいいのか」といった「外側」に目線を向けられるようになったと思うんです。

スクラムチームが最初からプロダクトゴールを分かっていることって実はあまりなくて、プロダクトオーナーも何となく上から聞いた程度でしか知らなかったりする。

それを自分たちでちゃんと言語化しよう、知っている人を探しに行こう、という機会が生まれたんじゃないでしょうか。「みんなで考えよう」という場面が増えた気がします。

新井：
「ゴール」が存在するということがすごく大事ですよね。

部分を積み上げればゴールに辿り着けるかというと、そうではありません。機能の寄せ集めじゃなくて、ゴールを達成するために作っているのがインクリメントですから、それを強く意識してほしいなと思います。

中村：
組織の構造によっては、スクラムチームとプロダクトオーナーや開発者とで所属する箱が違っていることがあります。あるいは、プロダクトオーナーとは別にビジネスサイドの人が関わっていることもあります。

そういうとき、プロダクトゴールは共通の用語として使えます。

「プロダクトゴール」があって、それを実現するための粗めの「ロードマップ」があって、そのロードマップを実現するための「プロダクトバックログ」がある、というように、具体的に話ができるようになります。

新井：
共通のコミュニケーションツールになるということですよね。

プロダクトバックログアイテムの独立性を担保するには？

参加者コメント：
一つのプロダクトバックログを複数のスクラムチームで開発する場合、プロダクトバックログアイテム（PBI）の独立性が重要になると思います。PBIの独立性を担保する工夫は何かありますか？

中村：
直接の答えにはならないかもしれませんけど、複数のチームでリファインメントをして、お互いに開発者目線で検査してみたらいいんじゃないかな。

新井：
絵を描きながらディスカッションして、抜け漏れを確認したり、整理しなおしたりできるといいですね。

グレーゾーンっていうのかな、解釈に幅があるようなところは、やっぱり「会話」しないとギャップが埋められないと思います。

中村：
実際に1スプリント、2スプリントやってみると、独立していないものがあれば気がつくと思います。気づいたことがあったら、次のスプリントから意識していけばいいんじゃないでしょうか。

新井：
ふりかえりやレビューをしながら、それぞれのチーム内でナレッジを蓄積していくのがよさそうですね。

それと、完全に独立できるものとできないものがあると思います。独立できないものを無理にさせようとすると、「仕事のために仕事している」みたいな変な感じになっちゃうのではないでしょうか。

中村：
不自然になっちゃいますよね。最近はあまり言われなくなりましたけど、バックログを分割するためのINVESTとかね。

※INVESTとは
良いプロダクトバックログアイテムとされる6つの原則。I（Independent：独立している）、N（Negotiable：交渉可能である）、V（Valuable：価値がある）、E（Estimable：見積もり可能である）、S（Small：小さい）、T（Testable：テスト可能である）。

「すべて独立していなくてはいけない」というよりは「そうなっている方が仕事しやすいよ」というだけなので、どうしてもできなければそれを考慮した上でプランニングすればいいだけだと思います。

新井：
独立性が高い方がもちろんいいでしょうけど、それには熟練の技が必要だったりしますから、経験主義に立ってレベルアップしていくのがいいかな。

プロダクトゴールとプロダクトバックログを効果的に関連づけるには？

新井：
みんなでホワイトボードの前に集まって、絵を描きながら、陣取り合戦みたいなことをしてみたらどうでしょうか。

活字だけでロジカルに分解しようとしても、なかなか埋められない部分があります。落書きしながら、重なる部分や空白地帯を会話で埋めていってほしいと思います。そういう会話がすごく大事なんじゃないでしょうか。

中村：
文字や構造化されたものだけでは分からないニュアンスが、分かるかもしれませんね。

プロダクトバックログアイテムをどのように収集すればいい？

中村：
プロダクトバックログをどういう風にして集めるのか、スクラムガイドには書かれていませんよね。

新井：
既にリリースされているプロダクトなら、お客様または利用者からいろんな声がサポートデスクに入っていたりすると思うので、そういうところから持ってきてもいいですよね。

もしビジネス的なゴールがあるなら、それをブレイクダウンするような形でプロダクトゴールを設定して、プロダクトゴールからプロダクトバックログアイテムを出していく感じになるでしょうし、仮説検証するのでもいいですし、方法はいくつかありますね。

中村：
自分たちで見つけられることももちろんあるでしょうけど、チームの外の人たちがタネを持っていることもあります。

プロダクトオーナーやスクラムチームがひたすら考えるよりは、コラボレーションを生むための活動をしてみるといいですね。

例えば、カスタマーサービスの方と話をして、どんな声が多いか、それはなぜかを聞いてみる。時にはセールスの方と話をして、どんな反応が返ってきているのかを聞いてみたり、ステークホルダーの方と「どうなりたいのか」といった話をしたり。

新井：
外は情報の宝庫なのに、なかなか取りに行かないかもしれませんね。分かった気になってしまうのかな。積極的に、インタビューやアンケートをしてみるといいと思います。

ちょっと突っ込んだ質問をされても、データや根拠があればより説得力のある話ができますよね。

中村：
2020年版のスクラムガイドを見ても、最近のスクラムチームはゴール志向に変わってきていると感じます。

達成するものは何か、それによるアウトカムは何か。それを達成しようとするなら、自分たちの中だけでは難しいこともあります。

機能横断的でありつつも、外とのコラボレーションもある方がいいと思います。

新井：
フィードバックサイクルを回すためにも、コラボレーションしながらやれるといいですね。