プロダクトバックログとは？ 4つの項目、書き方の手順、メリットを紹介

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

プロダクトバックログとは、アジャイル開発のフレームワークの1つであるスクラム開発において、開発するシステムに必要な機能や改善が必要な項目などを優先度順に並べたリストのことです。スクラム開発における3つの作成物の一つとして定義されています。このプロダクトバックログを作成することで、スクラム開発の各スプリントで開発する機能などを明確化でき、ひいてはスプリントバックログやスプリントゴールの作成へとつながります。

プロダクトバックログとバックログは何が違うのか

一般的にバックログとは、未処理の作業や積み残しを指す言葉で、受注残や在庫などをバックログと呼ぶこともあります。IT業界では、実施する予定があるものの、何かしらの理由で未着手の状態である業務や案件を表す言葉として使われることが多いです。そのほかにも作業リストや課題リスト、会議の議事録などをバックログと表現することもあります。

一方でプロダクトバックログは、スクラム開発においてプロダクトを実現するために活用されるリストのことを指します。開発するシステムに必要な機能や修正すべきバグなどが、一覧で優先度順にまとめられているのが特徴です。

つまり、バックログは一般的にも使われる広義な言葉であり、プロダクトバックログはスクラム開発に限定されたバックログと捉えられます。また、スクラム開発ではプロダクトバックログのほか、各スプリントの作業項目を一覧にしたスプリントバックログも活用します。

プロダクトバックログと要件定義は何が違うのか

プロダクトバックログと要件定義はともに未処理の項目を扱うことから混同されることが多いですが、この両者には明確な違いがあります。

要件定義は、どのようなシステムを開発するのかを定義して必要な機能や要求条件を明確にしていくプロセスです。一方でプロダクトバックログは、システムに必要な機能などが優先度順に整理され、一覧にまとめられたリストのことです。つまり、要件定義はシステム開発の前提となるプロセスであり、プロダクトバックログは実際に開発すべき機能や作業項目などをより具体化したものであるといえます。

また、要件定義で明文化された内容は、基本的に開発の最後まで変わることはありません。その点、プロダクトバックログには開発途中で変化する可能性がある未処理の項目も含まれています。

プロダクトバックログの役割とは

プロダクトバックログは、チーム内外問わず、関係者一丸となって価値のあるプロダクトを創出するためのロードマップとして大きな役割を果たします。

プロダクトバックログは、開発チームだけではなくさまざまなステークホルダーが確認することも多いため、プロダクトバックログを見るだけで、「誰でもプロダクトの完成形をイメージでき、どのように開発が進んでいくのかが理解できること」が、プロダクトバックログを作成する上で重要になります。

プロダクトバックログを構成する項目

プロダクトバックログには、「フィーチャー」「バグの修正」「技術的負債」「知識の獲得」といった項目が含まれています。ここでは、これら4つの項目の内容についてご紹介します。

フィーチャー

フィーチャーとは、プロジェクトによって実現すべき、顧客から求められているプロダクトの具体的な機能のことです。顧客が必要としており価値を認識できる機能は、すべてこのフィーチャーに該当します。たとえ「ファイルの出力機能」といった、小規模な開発であってももれなくプロダクトバックログに追加する必要があります。

また、このフィーチャーを検討・整理する際には、後述する「ユーザーストーリー」というフレームワークで具現化するのが一般的です。

バグの修正

バグの修正は、文字どおり「修正すべきバグ」を記した項目です。バグの修正は優先度が高い業務なので、一般的にこの項目はプロダクトバックログの最上部に記されます。バグの規模感や緊急性はさまざまで、どのバグをどのタイミングで修正するのかを、誰が見てもわかるような状態で追加する必要があります。

ここで注意しなければならないのは、問題を指摘した時点で、その問題がバグなのかどうかを判断できない場合です。判断できない場合は当該問題を「技術的負債」として記すケースもあります。

技術的負債

技術的負債とは、将来的に修正や改善が必要になる技術的な問題を指します。システム開発では、開発スピードやリリースを優先した結果、問題が発生した際に一時的な対応をすることも少なくありません。そのような一時しのぎで対応した箇所への追加作業などが、技術的負債として蓄積されます。

また、技術的負債によって顧客に直接影響を与えるような問題が発生するケースは少ないため、この項目は「フィーチャー」や「バグの修正」と比較して優先順位が低くなる傾向にあります。しかし、借金の金利のように、放置していると雪だるま式に増えていき、返済が困難になってしまいます。技術的負債の負担を軽減するためには、日々少しずつでも対処し、解決に向けて動いていくことが大切です。

知識の獲得

知識の獲得とは、将来発生するであろう業務を達成するために必要な知識や情報を、新たに獲得することです。具体的には、新しい機能を実現するための事前調査や学習などが項目としてまとめられます。より詳細な情報収集や調査を必要とする場合には、プロトタイプの作成など、知識獲得タスクが別途作成されることもあります。

将来に備えるという意味で時間的な余裕があるため「技術的負債」と同様に、優先順位は低くなりがちですが、いずれ必要な知識であることには変わりありません。いざ必要となった際に慌てないためにも、スケジュール管理を行い、計画性を持って実施することが大切です。

プロダクトバックログの書き方

それでは実際にプロダクトバックログを作成するには、どのような手順で進めていけばよいのでしょうか。ここでは、プロダクトバックログの書き方をステップごとに詳しくご紹介します。

プロダクトオーナーとしての役割を認識する

具体的な手順に入る前に、前提としてプロダクトバックログの作成・更新を行う「プロダクトオーナー」について、しっかりと理解しておく必要があります。

プロダクトオーナーとは、スクラム開発における役割（ロール）の1つであり、プロダクト全体の責任者です。スクラムチームから⽣み出されるプロダクトの価値を最⼤化させることがプロダクトオーナーの使命であり、それを実現するためにプロダクトバックログの作成や更新を行います。

また、プロダクトの方向性や意思決定を明確にするためにも、プロダクトオーナーの役割を担うのは必ず1人です。そしてほかのチームメンバーには、プロダクトオーナーの意見を尊重する姿勢が求められます。

プロダクトオーナーが行う代表的な業務には、次のようなものが挙げられます。

• プロダクトゴールの策定
• プロダクトバックログの作成・更新
• PBI（プロダクトバックログアイテム）の作成・メンテナンス
• PBIの優先順位の決定
• スクラムマスターやステークホルダーとの連携や調整

プロダクトオーナーは、開発するプロダクトの結果に責任を持ちます。そのためには、ステークホルダーのニーズを事細かにくみ取った上で、プロダクトゴール、プロダクトバックログ、PBIとして、「誰が見てもわかる状態」で明示することがとても大切です。実際に開発を行うのはチーム内の開発メンバーであるため、必要に応じてスクラムマスターと協力し、スクラムチーム全体で開発における認識の齟齬が発生しないような意思伝達や指示が求められます。

このように、スクラム開発におけるプロダクトオーナーが担う役割は非常に重要なものです。プロダクトオーナー自身はもちろんのこと、チームメンバー全員がその役割を理解した上でプロジェクトを推進していくことが、スクラム開発成功のカギといえます。

以上を踏まえて、より具体的にプロダクトバックログの作成手順についてご紹介します。

プロダクトゴールを策定する

プロダクトバックログを作成していくにあたり、まずプロダクトゴールを策定する必要があります。

プロダクトゴールとは、スクラム開発でチームが達成すべき目標やプロダクトを通して実現したいビジョンのことです。プロダクトバックログは、このプロダクトゴールを基にして作成します。このとき、具体的な機能を取りまとめるプロダクトバックログから考えて、それを抽象化したものをプロダクトゴールに設定するといったように、作成順が逆にならないように注意が必要です。

そもそも、プロダクトバックログやプロダクトゴールは、アジャイル開発のフレームワークの1つであるスクラム開発の中で必要になるものです。スクラム開発には、「確約（Commitment）」「集中（Focus）」「公開（Openness）」「尊敬（Respect）」「勇気（Courage）」という5つの価値基準が設けられており、これらを実践することがスクラム開発の成功につながるとされています。

プロダクトゴールを策定することは、これらの価値基準のうち、「確約（Commitment）」と「集中（Focus）」の実践に大きく影響します。ゴールの策定により、チームとしてゴールに向かって全力で取り組むことを「確約」でき、加えて、ゴール達成に向けた作業への「集中」も生み出せます。このようにスクラムの価値基準を実践する上でも、プロダクトゴールの策定は非常に重要な意味を持ちます。

プロダクトゴールは、ステークホルダーがなんとなく頭の中で思い描いていることも多いです。そのため、ステークホルダーとの綿密な打ち合わせはもちろんのこと、前項でご紹介したように「誰が見てもわかる状態」で示すため、必要に応じて実現したいことを分解し、より具現化していくことが必要です。

プロダクトゴールをより明確化するためには、次のようなフレームワークを活用することも有効です。

フレームワーク	概要
リーンキャンバス	事業を構成する9つの要素を1枚の用紙にまとめることで、ビジネスモデルの全体像を俯瞰し、各要素の整合性がとれているかを確認できます。
ゴールデンサークル	物事を「WHY（なぜ）」→「HOW（どうやって）」→「WHAT（何が）」の順番で伝えることで、相手からの共感を得やすくなります。
インセプションデッキ	用意されている10個の質問に答えることで、プロダクトの存在意義や強み、作業の優先順位や作業量などを把握することが可能です。

PBIを作成する

プロダクトゴールを策定できたら、次はプロダクトバックログに追加していくPBI（プロダクトバックログアイテム）を作成します。PBIはプロダクトを開発するために必要な個々のアイテムを指し、プロダクトバックログはこのPBIを集結させたものであると捉えることもできます。

プロダクトバックログの管理はプロダクトオーナーの領域ですが、このPBIの追加はスクラムチームメンバーであれば誰でも行うことが可能です。むしろ、プロダクトオーナー1人ではアイテムの抜け漏れが発生するリスクがあり、PBIの追加作業はチーム全員で実施するのが望ましいといえます。

PBIを作成する際には、次の点に注意します。

• 専門用語を使用せず、誰でも理解できるような言葉を用いて記載する
• PBI間で優劣をつけるような詳細は記載しない（優先順位づけは後の工程で実施）
• PBIを実現するための具体的な方法は記載しない（方法の検討は開発メンバーの領域）
• 1回のスプリント内に収まる粒度で設定する
• ニーズを反映するため、ステークホルダーとも念入りに打ち合わせをする

また、PBIを考えるときは、「ユーザーストーリー」というフレームワークの活用が便利です。ユーザーストーリーとは「誰が」「どのような理由で」「何をしたいか」というかたちで、顧客のニーズを整理していくフレームワークです。例えば、次のようなフォーマットに当てはめて考えることで、より顧客のニーズを反映したPBIの作成が可能になります。

ユーザーストーリーの基本フォーマット
「ペルソナ（ユーザー・顧客）」として、「目的・結果（達成したいゴール）」を実現したい。 なぜなら、「理由（ユーザー・顧客にとっての価値）」があるから。

ストーリーポイントを算出する

PBIの作成後、各業務にどのくらいの工数が発生するのか、ストーリーポイントを算出します。ストーリーポイントとは、主にアジャイル開発において、各業務の難易度やコスト、労力などを見積もるために使用される測定単位のことです。よくある時間ベースの見積もりでは、スキルの差などにより、同じ業務でも担当者に合わせて見積もりが変動します。一方ストーリーポイントは、業務内容自体に焦点を当てるため、業務を担当する人によってポイントが変動することはありません。

また、ストーリーポイントによる見積もりでは、業務の複雑さ・チームのリソース量・不確実性やリスクなどが考慮されるため、それらを考慮しない時間ベースの見積もりと比較しても、より客観的かつ正確に見積もれます。測定者の経験や理解度による個人的な主観が入る余地をなくし、一貫性のある数値を算出することが可能です。

ストーリーポイントを算出するそのほかのメリットには、次のようなものが挙げられます。

• 業務やタスクを細分化でき、プロジェクトの管理がしやすくなる
• スプリントの期間内にチームが達成できる業務量を把握できる
• スプリント実施後に見積もりの数値を改善することで、今後の見積もり精度が向上する

実際にストーリーポイントを算出する際には、次のポイントに注意することで、より正確に算出できます。

• ポイントの見積もりにはフィボナッチ数列を使用する
• ストーリーポイントの基準を示したマトリクスを作成する
• プランニングポーカー会議を実施する

フィボナッチ数列

フィボナッチ数列とは、各数が先行する2つの数の合計である数列のことです。「1、1、2、3、5、8、13、21、34、55、89、144、233……」と続きます。このフィボナッチ数列では1つ前の数字と大きく離れるため、例えば8か9のどちらのポイントを採用すべきかで悩むといった、ストーリーポイントの見積もりに迷う場面を削減できます。

ストーリーポイントの基準を示すマトリクス

ストーリーポイントのマトリクスとは次のようなもので、タスクの評価基準を明確にし、一貫した見積もりを行うために役立ちます。

ストーリー ポイント	労力	時間	複雑性	リスク
1	非常に小さい	数分	低い	なし
2	非常に小さい	数時間	低い	なし
3	小さい	1日	普通	小さい
5	普通	数日	普通	小さい
8	大きい	数週間	高い	普通
13	非常に大きい	1か月	高い	大きい

プランニングポーカー会議

また、ストーリーポイントを算出する際、特に重要なのが「プランニングポーカー会議」です。プランニングポーカー会議を行うことで、メンバー間のスキルバイアスをなくし、全員が納得した上でストーリーポイントを算出できます。一般的には次のような手順で会議を進めます。

プランニングポーカー会議の実施手順

• 各メンバーにフィボナッチ数列の書かれたカードを1セット配布する
• チームでプロダクトバックログに関する質問をしながら、タスクを明確にする
• 各メンバーはタスクの見積もりを最も正確に反映したカードを提示する
• すべてのメンバーが提示した値が近ければ、見積もりを決定する
• 見積もりが異なる場合は、同意が得られるまでメンバー間で話し合いを行う

こうして算出したストーリーポイントは、次項のPBIの優先順位づけやプロダクトバックログの整理に活用されます。

PBIの優先順位づけを行う

続いてPBIに優先順位をつけます。スクラム開発では、優先順位が高いものから開発を進めていくため、この優先順位づけは重要なプロセスです。

PBIの優先順位づけはプロダクトオーナーの意思決定の下で実施され、責任もプロダクトオーナーが負います。よって、「プロダクトオーナーが優先順位を決めた基準について、説明ができない状態」は避けなければなりません。基準が明示できていない場合、スクラムチームで意思統一が難しくなったり、プロジェクトの進行における認識の齟齬が発生したりする可能性が非常に高くなります。また、優先順位を見直す場合のコストも増大します。

前述のストーリーポイントを基準に優先順位づけを行うのも一つの方法ですが、それ以外にも優先順位を決める基準や整理する方法はさまざまにあります。

モデルや手法	概要
狩野モデル	製品やサービスの特性が顧客満足度にどのような影響を与えるかを分析し、製品やサービス開発の優先順位を明確にするためのフレームワーク。
MoSCoW法	要件をMust（対応必須）、Should（対応すべき）、Could（できれば対応）、Won't（対応不要）という4つの分類で評価し、プロジェクトで対応する要件の優先順位を決める方法。
RICE	Reach（リーチ）、Impact（影響）、Confidence（信頼性）、Effort（労力）の4観点で点数評価して、優先度スコアを導き出します。
アイゼンハワーマトリクス	業務を「重要性」と「緊急性」の2軸で、それぞれの高低の判断から4つの領域に分類し、優先順位を整理する方法。重要性と緊急性の両方が高いと判断された業務は優先順位が高くなる。

どの手法や考え方を用いるのかは自由ですが、優先順位を決めた基準はしっかりと説明できるようにしておく必要があります。

また、PBIの粒度が大きすぎるために、優先順位づけに苦戦することも少なくありません。その場合はPBIを分割し、粒度を小さくすることで優先順位がつけやすくなります。PBIを分割する方法としては、次のようなものが挙げられます。

• ワークフローの段階で分割する
• 使用するプラットフォームで分割する
• 入力項目で分割する
• 操作方法によって分割する

ただし、細かく分割しすぎるとPBIの数が多くなり管理がしづらくなるということもあるので、チームの力量に合わせて、適切なサイズに分割することが大切です。

優先順位が高いPBIを詳細化する

最後に、前項で定めた優先順位が高いPBIに対して詳細化を行います。このPBIの詳細化を行うことで、各スプリントにおけるPBIを実現するためのタスクリストであるスプリントバックログへ、スムーズに反映できるようになります。

PBIを詳細化していく上では、以下のポイントに注意する必要があります。

• ユーザーストーリーはできる限り「INVEST」を満たすようにする
• 受け入れ基準を作成する
• 完了条件を定義し、チーム全員が理解する

それぞれ順番に解説します。

ユーザーストーリーはできる限り「INVEST」を満たすようにする

「INVEST」とは、ビル・ウェイク氏によって提唱されたユーザーストーリーの品質を評価する基準のことです。以下の各単語の頭文字を取ったものであり、アジャイル開発において世界的に広く使用されています。

単語	概要
Independent （独立している）	ほかのPBIと依存関係がなく、どのようなスケジュールでも実行できるように独立している。
Negotiable （交渉の余地がある）	ユーザーストーリーは機能を明示的に約束するものではなく、詳細はプロダクトオーナーと開発メンバーの交渉で決められる。
Valuable （価値がある）	タスク内容ではなく、顧客にとって価値があるものが書かれている必要がある。
Estimable （見積もり可能）	作業内容が想定でき、見積もりも可能な状態になっている必要がある。
Small （適正なサイズ）	見積もりやストーリーが把握しやすいよう、また、1回のスプリントに収まるように、適正なサイズ（小さい）である必要がある。
Testable （テスト可能）	ユーザーストーリーを達成できているかどうかを確認するテストの実施が可能である。

実際にPBIをスプリントへ投入したとき、これらの基準を満たしていないことによって、1回のスプリントでPBIが完了しないといったこともしばしば発生します。特に「Independent（独立している）」と「Small（適正なサイズ）」の視点は、プロダクトオーナーが見落としやすいポイントなので注意が必要です。

受け入れ基準を作成する

受け入れ基準とは、個々のPBIに設けられている「何をもってPBIの機能が完成したか」を確認するための基準です。受け入れ基準はプロダクトオーナーが作成し、1つのPBIに対して複数設けられます。開発メンバーがテスト基準として利用できるほど具体的で、誰が見ても確実にわかるように表現することが重要です。

完了条件を定義し、チーム全員が理解する

完了条件とは、すべてのPBIに共通で設けられている「PBIを完了状態（リリース可能な状態）にするための条件」です。受け入れ基準が機能要件のみに焦点を当てているのに対し、完了条件は機能要件・非機能要件・品質など、あらゆる面から条件を定義します。

具体的な完了条件としては次のようなものが挙げられます。

• 受け入れ基準を満たしている
• コードレビューが完了している
• ユニットテストが完了している

完了条件はすべてのPBIに共通で設けられるため、チーム全員が条件を理解することが重要であり、条件の定義を決める際もチーム全員で議論することが求められます。

プロダクトバックログをメンテナンスする方法

ここまでプロダクトバックログの作成手順をひととおりご紹介してきましたが、プロダクトバックログは一度作成して終わりではなく、状況に合わせて常にメンテナンスする必要があります。ここでは、プロダクトバックログのメンテナンス方法についてご紹介します。

1．優先順位を見直す

1つ目のメンテナンス方法は、PBIの優先順位の見直しです。これはプロダクトオーナーが責任を持って実施する必要がありますが、時間に追われて忙しいなどの理由から、意外とおろそかになりがちな作業でもあります。

よりよいプロダクトを開発するには、PBIの優先順位の見直しは必須です。限られた時間でそれらを効率的に行うには、まず優先順位の基準のメンテナンスを実施し、その上で変更の影響範囲内にあるPBIの優先順位を修正するのが効果的な方法といえます。

2．PBIのメンテナンスの流れ

優先順位の見直しと同時に、PBIの項目自体の追加・更新・削除といったメンテナンスも行う必要があります。

PBIの追加

PBIの追加は常に行われる可能性があります。例えば、顧客がプロダクトに対して何か新しい価値を求めているとき、ステークホルダーが新しいビジネス価値を生み出そうとしているときなど、その機会は非常に多いです。

また、PBIを追加するということは、何か新しい機能の開発が始まるということでもあります。そのため、PBIを追加した際には、どこかのタイミングでチーム全員に共有する場を設けることが重要です。

PBIの更新

開発を進める順番同様、PBIの更新も優先順位の高いものから順番に行われます。優先順位が高いものほど詳細に更新する必要があるため、更新作業自体の作業量も増えることには注意が必要です。

また、PBIの内容を更新した場合、優先順位の見直しも必要になることがほとんどです。PBIを更新する場合、プロダクトオーナーは更新する背景やその内容を十分に把握した上で、優先順位を判断する必要があります。

PBIの削除

PBIのメンテナンスでは、必要に応じてPBIを削除することも大切です。スクラムの概念上ではPBIが膨大になることは問題ありませんが、実情としてPBIが増えるにつれて必要コストも増大してしまうため、やはり定期的に削除して整理するのが好ましいといえます。

PBIの削除は一見簡単そうに見えて、その判断は難しく、誤って削除しないためにも細心の注意を払う必要があります。実施頻度としては高くないものの、顧客の状況の変化やチーム体制の変更があった際には、併せて削除するべきPBIがないかを確認することが重要です。

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

ここでは、ホテルの検索システムを例に挙げ、エピック（プロダクトに対する、より抽象的な要望）から実際に搭載するべき機能まで、プロダクトバックログの具体例をご紹介します。

【エピック】
「複数のホテルを検索・比較できるシステムを構築したい」 プロダクトバックログでは、このようなエピックをより具体的なユーザーストーリーに分割します。

【ユーザーストーリー】
「一般ユーザー」として「複数のホテルを検索・比較できるシステム」が欲しい。なぜなら、「予算内で、より良いホテルに宿泊したい」から。 さらに、ユーザーストーリーごとに搭載するべき機能を決定します。

【ユーザーストーリーのために搭載するべき機能】

• 目的地や日程、宿泊費を指定してホテルを検索できる機能
• ホテルの詳細情報やレビューを閲覧できる機能
• お気に入りのホテルを保存できる機能

この例では、ユーザーストーリーとして比較的シンプルな1つだけを挙げましたが、1つのエピックから複数のユーザーストーリーや機能が生まれることも珍しくありません。それらをステークホルダーの要望も踏まえて取りまとめたものが、プロダクトバックログです。

プロダクトバックログを活用するメリット

スクラム開発を進める上で、プロダクトバックログの作成は欠かせません。実際にプロダクトバックログを活用するメリットは多くあり、具体的には次のようなものが挙げられます。

• スクラムチーム全員で目標やゴールの共有ができる
• トラブルや仕様変更にも柔軟に対応できる
• リストとして整理することで、業務の優先度がひと目で確認できる
• 短期的な視点はもちろんのこと、長期的な視点でもプロジェクトの進行がしやすくなる

スクラム開発では、メンバーの一人ひとりが自分の役割を理解し、チームとして連携することが何よりも重要です。プロダクトバックログを作成することで、業務の優先順位が明確になって生産性が向上するほか、プロダクトゴールという大きな目標達成に向けてチームの連帯感やメンバーの責任感も生まれやすくなります。

まとめ

今回はプロダクトバックログについてご紹介しました。プロダクトバックログとは、アジャイル開発のフレームワークの一つであるスクラム開発において、システムに必要な機能を優先度順に並べたリストのことです。市場や顧客の価値観の変化が激しい現代における各企業には、システム開発にスクラム開発を取り入れ、プロダクトバックログを作成した上で、顧客のニーズに合ったプロダクトを作成していくことが求められています。