プロダクトバックログの作成方法 – 利用目的と使い方、管理方法の解説

はじめに

スクラムを推進するために作成する「プロダクトバックログ」について解説します。
プロダクトバックログは、プロダクトを開発するために必要な機能をまとめ、優先順位をつけたものです。
作成にあたりスクラムチームや顧客など幅広いステークホルダーが関与しますが、管理責任者はプロダクトオーナー1人です。
このプロダクトバックログについての説明と、実際に作成する流れについて説明します。

プロダクトバックログのフォーマットについてはサンプルを用意しているので参考にしてください。

プロダクトバックログとは

プロダクトバックログの使い方

プロダクトバックログとは、実装する機能を開発順で並べた一覧です。
プロダクトバックログの行ごとの機能をPBI（プロダクトバックログアイテム）と呼びます。

開発作業は、最も優先度の高いPBIから順にスプリントへ渡して実装します。
スプリントは受け取ったPBIを開発向けに分解してスプリントバックログを作成します。

図でいうとNo1の機能からスプリントに渡します。
スプリント１回で実装できる作業量をベロシティと言いますが、そのベロシティとプロダクトバックログの規模を見比べながら、どこまで開発するのか計画を立てます。

PBIの規模が大きすぎると、どこまでスプリントで実装すればよいか判断が難しくなるため、その場合はPBIを細分化するとよいでしょう。

上記の図にあるスプリントバックログについては、別記事「スプリントプランニング」を参考にしてください。

プロダクトバックログの目的

プロダクトのロードマップ

スクラムチームだけでなく、顧客や経営者などステークホルダー全体が「既に実装完了された機能」「これから実装される機能」を理解するための資料として使用されます。
このプロダクトバックログをもとに、何をどの順番で実装していくのか計画を立てます。

また新たに実装すべき機能を発見したり、開発の順番を変更するような場合、このプロダクトバックログを見ながら調整を進めます。

開発規模を把握する

プロダクトバックログに記載した規模を合計するとプロジェクト全体の開発規模になります。
PBIの追加や変更が発生した場合、全体規模の変動を把握する場合にも使用します。
もし規模が予算を超える場合は、優先度の低いPBIを廃止したり縮小することもあります。

全員で必要機能を洗い出す

PBIは特定メンバだけで考えるのではなく、スクラムチーム全体で考えます。
それにより重要なPBIが漏れることを抑止します。
必要と思われる機能に気づいたら追加していく場所、それがプロダクトバックログになります。

プロダクトオーナーの役割

プロダクトバックログの作成を理解するには、プロダクトオーナーの役割を理解する必要があります。
スクラムの役割については、別記事「スクラム全体解説」を参考にしてください。

プロダクトオーナーの特徴は次のとおり。

• プロジェクトごとに１名（0名、複数名はNG）
• プロダクトの結果責任を持つ
• プロダクトの価値を最大化する
• プロダクトバックログを管理し、作業順を決定する

プロダクトオーナーはプロダクトに責任を持つのですが、プロダクトバックログはスクラムチーム全体で作成します。
優先順の決定はプロダクトオーナーに決定権があります。

注意点として、プロダクトオーナーは開発チームに相談することはできますが、指示・命令など開発作業に干渉することは出来ません。

プロダクトバックログの作成方法

プロダクトバックログの作成はプロジェクトによって様々です。
ここでは、よく使用される作業の流れを説明します。

プロダクトゴールの設定

プロジェクトのビジョンやミッションを達成するため、どのようなプロダクトを作成するのかゴール設定をします。
このゴールに到達するために必要となる機能がプロダクトバックログとして表現されます。

プロダクトゴールの設定でよく利用されるのが「インセプションデッキ」です。
インセプションデッキは「アジャイルサムライ」と呼ばれる書籍に含まれるテンプレートで、10個のトピックスから構成されています。

サンプルはアジャイルサムライのサポートページから取得できます。

10個のトピックス

インセプションデッキは次の10個のトピックスで構成されています。
このインセプションデッキの作成ポイントは別記事「インセプションデッキの作成ポイントの解説と注意点」でも解説しているので参考にしてください。

• １．我々は、なぜここにいるのか
• ２．エレベーターピッチ
• ３．パッケージデザイン
• ４．やらないことリスト
• ５．ご近所さんを探せ
• ６．技術的な解決策を描く
• ７．夜も眠れない問題
• ８．期間を見極める
• ９．トレードオフ・スライダー
• １０．何がどれだけ必要か

トピックスは10個ありますが、全てを作成する必要はありません。
プロジェクト特性を考えながら必要に応じて作成します。

作成メンバ

インセプションデッキを作成するのは、スクラムチームだけでなくプロジェクトに関わる人であれば誰でも参加可能です。
幅広く参加してもらうことで、プロジェクトの目的など意見交換したり情報共有することができるため望ましいです。
むしろ顧客などのステークホルダーは、スクラムを進めていくための重要な役割を持つことになるので、プロジェクトの方向性を合わせるために必ず参加してもらいましょう。

ユーザストーリー

プロダクトバックログで管理すべき機能を顧客目線で洗い出す場合、ユーザストーリーを使用します。
価値の高いプロダクトを提供するには、開発者の立場で機能を考えるのではなく、顧客やユーザが考える「これがほしい」にフォーカスする必要があります。

このユーザストーリーでは、次の問いを行うことで機能の洗い出しを行います。
・What
　〇〇が、○○できるようになる。
・Why
　〇〇という課題がある。
・Value
　〇〇の価値がある。

＜サンプル＞
・What
　営業担当が、外出先で顧客情報を検索できるようになる。
・Why
　現状、スマホやタブレットでアクセスできないという課題がある。
・Value
　取引先との交渉が円滑に行えるため、受注量増加につながる。

上記によって出てきたスマホやタブレットでアクセスできる機能をプロダクトバックログに追加します。

リスト化と見積もり

必要な機能を洗い出したら、プロダクトバックログに記入してリスト化します。
そこでPBIごとの見積もりも検討して記入します。
見積もりといってもウォーターフォールで算出するような精度の高いものではなく、推測程度です。

スクラムは決まった見積もり方法がないためファンクションポイントを使うプロジェクトもあるようです。
しかし開発を進めていく中で機能内容は変わるため、見積もりに時間をかけても費用対効果は薄いです。

そこで使用されるのが相対見積もりです。
PBIの中から感覚的に規模感を出しやすく、かつ中央値くらいのアイテムを選択して規模を出します。
そのPBIと「大きい／小さい」を比較しながら規模を出します。
もちろん完全な精度ではないのですが、スクラムチームの経験値が高くなってくると「これくらいでできそうかな」という予測ができたり、過去の類似機能を参考にすることもできるため精度は上がっていきます。

この見積もりは開発チームが行います。
作り手が規模感を一番理解しているためであり、経験値を積むことで見積もり精度向上を期待できます。

優先度の設定

リスト化されたPBIの開発順の優先度を設定します。
スクラムは小さいリリースを繰り返してプロダクトを成長させていきます。
優先度の高い機能から実装し、実装が間に合わなくても優先度の低い機能であれば実装対象外にすることも考えられます。
早い段階で顧客などに動く機能を確認してもらいたいなどの理由で優先度を上げることもあります。

このように優先度設定は、価値ある機能を実装するために重要なものです。
そのため優先度を設定するのに開発チームの意見を参考にして良いですが、決定するのはプロダクトオーナーです。

受け入れ基準の設定

スプリントレビューでプロダクトオーナーがPBIのチェックを行うのですが、何をもって完成したのか判断するための基準を設定します。
ウォーターフォールでいう受入テスト項目と考えるとわかりやすいです。
この基準がないと完成の判断が曖昧になり、出来上がるプロダクトも中途半端な状態になることがあります。

また開発チームも何を目指して作ればよいか判断できないため、計画段階で受け入れ基準を設定します。

プロダクトバックログの管理方法

プロダクトバックログは作成したら完了ではなく、メンテナンスしていく必要があります。
開発作業を進める中で、新しい気づきにより機能を見直すことがあります。
スプリントプランニング、スプリントレビュー、振り返りであるレトロスペクティブの結果を受けて、PBIの追加、変更、削除や優先順位を変更することもあります。
またスプリント実行中、次に実行するプロダクトバックログの詳細化や見直しなどの作業を行います。

このようにプロダクトバックログを洗練することで、より良い機能の提供につなげます。