2023.10.11

プロダクトバックログとは？項目や書き方・例をわかりやすく解説

著者株式会社SHIFT　マーケティンググループ

「プロダクトバックログ」とは、開発が必要な機能や改善が必要なものに優先順位をつけたリストのことを指し、特にアジャイル開発においてToDoリストのような役割を果たしています。

昨今、ソフトウェア開発手法の主流ともいえるアジャイル開発のなかで、多くの企業が採用するフレームワークが「スクラム」です。スクラムにおいて、最も結果に差がつきやすく、開発全体に影響を与えるのが、プロダクトバックログといえます。では、具体的にどのようにプロダクトバックログを作成し、活用するのでしょうか。

本記事では、プロダクトバックログの概要とスクラムとの関係、それらに含まれる項目や作り方について解説します。

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

プロダクトバックログとは、機能や改善が必要なものについて優先順位をつけ、記述したものです。優先順位をつけることで、今回のスプリントで対応する機能、次回のスプリントで対応する必要がある機能を明確にすることができます。

また、プロダクトバックログは、ステークホルダーがプロダクトの状況を把握することにも用いられます。

プロダクトバックログとバックログの違い

「バックログ」とは、積み残しや残務といった意味をもつ言葉です。IT業界では、未処理の作業や案件など広い意味で用いられます。

一方、スクラムで用いられるプロダクトバックログは、開発しているプロダクト（成果物）を実現するために活用されるものです。必要な項目が一覧化され、開発すべき機能や修正すべきバグなどが記載されます。また、プロダクトバックログのほかにスプリントバックログも活用します。

スクラムでは、スプリントと呼ばれる設計から開発・テストまでの工程を繰り返し実施します。プロダクトバックログが直近から将来までの作業項目を管理するのに対して、スプリントバックログは1回のスプリントで作業する項目を一覧にしたものです。

プロダクトバックログと要件定義の違い

未処理分を指すという意味でよく似ているものに、「要件定義」が挙げられます。同じように見えますが、プロダクトバックログが開発途中で変化する未処理の項目であるのに対し、要件定義は開発において作成するかしないかを明記したものです。

要件定義は開発の前段で、ユーザーからの要求をまとめ、何をつくるかを明確にしたものです。内容が変わらない大枠の部分のことであり、必ず開発しなければならない項目を記しています。プロダクトバックログは未処理の作業や機能を指し、かつこれらは開発途中で形が変わっても問題ないものです。両者には明確な違いがあることを覚えておきましょう。

スクラム開発の概念とプロダクトバックログの役割・概要

これまで述べた概要だけではプロダクトバックログのイメージがつきにくいという方も多いでしょう。

スクラムでは、その名称から想像ができるラグビーのスクラムのように「チームメンバー同士でがっちりと肩を組み」、ゴールに向かい、メンバーが一丸となって動くことを非常に重要視しています。

その具体的な内容は、スクラムを行ううえでよく参照される「スクラムガイドブック」のなかに次のように明記されています。

・スクラムの理論における3本の柱（「透明性」、「検査」、「適応」）
・スクラムの価値基準（「確約」、「集中」、「公開」、「尊敬」、「勇気」）

このように、スクラムとはそもそもどのような概念であり、何を大切にしているのかといったことを理解しておくことで、これから説明するプロダクトバックログについてより深く理解することができるでしょう。

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

スクラムにおけるプロダクトバックログの役割は、プロダクトバックログを見れば、「誰でも今後のプロダクトがどのように変わるかがわかるようになる」ことです。つまり、プロダクトバックログは、スクラムチームの情報源であり、ロードマップのようなモノとして役割を果たすといえます。

プロダクトバックログ概要

「バックログ」とは、わかりやすくいえば「積み残しのリスト」のことです。つまり、「プロダクトバックログ」は、「プロダクトの積み残しリスト」と理解することができます。そして「リスト」というだけあって、このリストのなかには「アイテム」が「並んで」いるはずです。

スクラムでは、この「アイテム」のことを「プロダクトバックログアイテム」（以下、PBI）とよびます。PBIはスクラムチームメンバーであれば全員作成することが可能で、そこには、プロダクトの改善事項が適切な粒度で記載されています。また、そのPBIはただ並んでいるのではなく、実現の優先度順に並べられているのです。

以上をまとめると、プロダクトバックログとは、プロダクトの改善に必要なアイテムが優先度順に並んでいる積み残しリストのことだといえます。

プロダクトバックログに含まれる項目

プロダクトバックログでは、次の4つの作業を管理します。

・フィーチャー
・バグ修正
・技術的負債
・知識獲得

それぞれの詳細を見てみましょう。

フィーチャー

フィーチャーとは、プロジェクトによって実現するシステムに必要な機能のことです。ユーザーストーリーマップなどを通じてユーザーが求めているものや必要なものを整理し、それらを実現するために必要な機能（＝フィーチャー）に落としていきます。

バグ修正

バグの修正とは、その名の通りバグを直す作業のことを指します。特にスクラムチームでは、バグを迅速に修正しなければなりません。バグにも、一度開発をすべて止めて対応しなければならない重大なものもあれば、すぐに対処できるもの、次の工程に持ち越しても問題ないものなどがあります。

注意点としては、バグの対応に関してはチームメンバーがわかるようにしておかなければなりません。バグの共通ルールについては、プロダクトバックログの最上部に記しておくことをおすすめします。

技術的負債

技術的負債とは、対応しなければならない技術面における問題のことです。借金の金利と同じく、放置していると雪だるま式に増えていく特徴があります。技術的負債の負担を軽減するには、チーム内で作業内容を整理・共有して少しずつでも対処していくことが必要です。対処できなくなってからでは遅いため、少しずつでも解決に向けてチーム内で動いておくようにしましょう。

知識獲得

知識獲得とは、名前の通り知識を集めることです。具体的には、将来的に対処しなければならないタスクを達成するために必要な情報を集めることを指します。開発するプロダクトにもよりますが、開発において調査しなければならない要素がある場合は、プロトタイプの作成や実験結果、概念実証などの知識獲得に必要なタスクを作成しなければなりません。

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

実際のプロダクトバックログのつくり方について、前提としておさえておきたいプロダクトオーナーについて簡単に説明します。そのあとで、具体的なつくり方として4つのSTEPを解説します。内容は次の通りです。

・前提：プロダクトオーナーの役割を認識する
・STEP1：プロダクトゴールの策定
・STEP2：PBIの作成
・STEP3：ストーリーポイントの算出
・STEP4： PBIに優先順位をつける
・STEP5 : 優先順位高のPBIの詳細化

それぞれ詳しく解説します。

前提 : プロダクトオーナーの役割を認識する

プロダクトバックログを作る前提として、スクラムチームにおけるプロダクトオーナーの役割について認識しておく必要があります。その名の通り、プロダクトオーナーは実現するプロダクトに対する意思決定権と責任をもつ人です。

プロダクトオーナーの人数

原則として1つのスクラムチームにはプロダクトオーナーは1名のみです。しばしば複数のプロダクトオーナーがチームにいる場合がありますが、残念ながらそれではスクラムチームとしては成立していないといえます。

なぜならば、1つのプロダクトを素早く、ぶれずに完成させるためには、最終的な意思決定者を1人にしておく方がよいからです。

したがって、スクラムを行う際には、必ず、明確にプロダクトに対して責任をもつ人を決め、会社組織としてもプロダクトオーナーが1人でプロダクトに向き合える環境を用意することが非常に大切だといえます。

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

プロダクトオーナーの役割としては、おおむね次の4つがあげられます。

・プロダクトゴールを示す
・誰もが理解することができるPBIを作成する
・PBIの優先順位を決定する
・プロダクトバックログをメンテナンスする

このような役割を果たすプロダクトオーナーは、スクラムにおいて重要な人物といえます。決してほかの役割や業務と兼務できる役割ではないということを、プロダクトオーナー自身も周囲の関係者も理解しておくことが何よりも重要です。

スクラムチームやクライアントと綿密に連携し、プロダクトの実現に向けて尽力しなければなりません。

さて、プロダクトオーナーについてはおおむねご理解いただけたかと思いますので、次にプロダクトバックログのつくり方のSTEPについて説明していきます。

STEP1 : プロダクトゴールの策定

プロダクトバックログを作成するにあたり、まずは、プロダクトバックログの基になるプロダクトゴールを策定することが必要です。プロダクトのゴールとは、プロダクトを通して実現したい「ビジョン」や「ミッション」のことです。

これらについては、プロダクトにかかわるステークホルダーやプロダクトオーナーがなんとなく頭のなかで考えているというケースもないとはいえません。ステークホルダーやプロダクトオーナーが頭の中で考えていることがある場合は、実現したいことを分解し、明確に表現する必要があります。

ゴールの明確化のために、今日では次のようなフレームワークがありますので、それらを用いることもオススメです。

＜フレームワークの例＞
リーンキャンバス
9つの要素から事業に関わる要素を整理するためのフレームワーク。1枚の紙で表現し、全体を俯瞰しながら見ることができることが最大のメリット。
PRD（Product Requirements Document）
プロダクト要求仕様書。プロダクトに関わるさまざまな事柄を定義しておき、意思決定の際や方向性の再確認を行う際に利用するドキュメント。
インセプションデッキ
用意されている10の質問に答えることで、プロダクトのビジョンやミッションを整理するプラクティス。
OnePager
まるでパンフレットのような形で、製品・サービス・ビジネスの概要をあらわすことができる1ページのドキュメント。
ゴールデンサークル
物事を「Why」「How」「What」という構成要素に分解し、本質を説明するためのフレームワーク。

もちろん、チームの構成やプロダクトの解像度などに応じてプロジェクトが置かれている状況は異なると思います。まずはいずれかのフレームを利用してみて、明確化ができるかどうかを試してみるとよいでしょう。

もし、試したフレームの使いづらさを感じたら、すぐに別のフレームワークに切り替えたり、フレームワークから要素のみ抽出し独自の手法に昇華させましょう。変化を恐れずにプロジェクトを前に進めていくことが大切です。

STEP2 : PBIの作成

STEP1でプロダクトのゴールを策定したら、次にそれを実現するためのPBIを作成し、プロダクトバックログに追加していきます。追加作業は、プロダクトオーナーだけではなく、スクラムチームに参加しているすべての人が行います。

このSTEPは、PBIを追加することを念頭に置くところからスタートです。優先順位づけは次のSTEPにおいて行うため、優劣をつけるような詳細はここでは書かず、PBIの意味を明確にしていきます。

そのため、XP（Extreme Programming）のプラクティスとして提案されアジャイル開発で広く活用されるようになったユーザーストーリーを、一例として次のようなテンプレートに則って作成します。

ユーザーストーリーのテンプレート
[Who（ユーザー・顧客）] として、[What（達成したいゴール）] をしたい。なぜなら[Why（理由）] だから。

ここで気をつけるべきポイントは、How（方法）を書かないことです。というのも、Howについては、ユーザーストーリーを実現するためのタスクをスクラムチームが検討・整理する際に議論すべきことだからです。

また、そのほかにも、誰でも理解できる言葉を用いて記載する（＝専門用語を利用しない）ことを意識することもここでは重要なポイントだといえます。

STEP3 : ストーリーポイントの算出

PBIを作成したら、各業務にどのくらい工数がかかるのかのストーリーポイントの算出を行います。

ストーリーポイントとは、アジャイル開発において各業務の難易度を見積もるために使用される測定単位のことです。ストーリーポイントの基準は、各業務の完了までの時間や必要リソース量を考慮し、チームごとの基準で定義されます。この基準を業務ごとに算出し記載していきます。

ストーリーポイントはSTEP4の優先順位づけの参考にしたり、プロダクトバックログを整理したりするために使用します。

STEP4 : PBIに優先順位をつける

STEP4では、STEP2で作成したPBIに対して優先順位をつけていきます。

優先順位がつけられないという場合は、作成したPBIのサイズが大きすぎることが理由として考えられるため、PBIを分割します。もし分割しても優先順位をつけることがむずかしい場合は、STEP4に記載している詳細化を先に進めるのも有効です。

優先順位をつけるにあたり、その基準を整理する考え方や手法はさまざまですが、以下にその例をご紹介しておきます。

＜PBIの優先順位づけを行う考え方や手法の例＞
狩野モデル
顧客満足度に影響を与える品質要素を分類して、それぞれの特徴を記述したモデル。
MoSCoW法
要件をMust、Should、Could、Won’tに分類する。特にMustを決めることが非常に重要。
アイゼンハワー・マトリクス
縦軸を重要度・横軸を緊急性とし、それぞれ高と低に分け、全部で4つに分類する方法。重要度高×緊急性高に振り分けられたものが一番重要。
CD3（Cost of Delay Divided by Duration）
その名の通り、遅延のコストを期間で割ったものをスコアとして用いるもの。経済性で優先度を決める手法。

もちろん、これらの方法を無理に使う必要はありません。状況によってビジネスの価値の最大化を最優先にするためにトップダウンに従い優先度を決めることもありえます。

しかし、どのように順位づけをするにせよ、一番やってはいけないことは「優先順位を決めた基準をプロダクトオーナーが説明できない」状態になることです。

仮にプロダクトオーナーがなんとなく優先順位を決めた場合でも、そこには必ず基準はあります。それが明示化できていないと、優先順位を再び見直す際のコストの増大や、スクラムチームでの意思統一を図ることが非常に困難になるかもしれません。また、プロジェクトにズレが発生しやすい状況になるでしょう。

したがって、優先順位の基準を明確にしてプロダクトバックログを理解し、スクラムチームが利用できる状態を実現することが、このSTEPでもっとも欠かせないことだといえます。

STEP5 : 優先順位高のPBIの詳細化

最後に、STEP4でつけられた優先順位が高いPBIに対して詳細化を行い、スプリントバックログに渡せるような状態にします。スプリントバックログに渡せるような状態とは、開発者が開発することができる状態のことです。

詳細化については次の3つを実行する必要があります。

・ストーリーをINVESTで満たすようにする
・プロダクトオーナーによる受け入れ基準を作成する
・完了条件を定義し、スクラムチーム全員が意味を理解する

ここでは、それぞれについて少しだけ説明します。

ストーリーをINVESTで満たすようにする

STEP2で作成したストーリーをBill Wake氏によって作成されたINVESTを満たすように修正・確認をします。

＜INVEST＞
Independent　独立している
ほかのプロダクトバックログアイテムと依存関係がなく、どのような順序でも実行できるように独立している必要がある。
Negotiable　交渉可能
詳細は会話して決めていくため、Howが書かれていないこと。
Valuable　価値がある
タスク内容が書かれているのではなく、価値について書かれている必要がある。
Estimable　見積可能
見積が可能な状態になっている必要がある。
Small　小さい
Estimableとも関連。大きすぎると見積もりが困難かつストーリーを把握することがむずかしいため、適切な大きさである必要がある。
Testable　テスト可能
ストーリーを達成しているか否かを確認するテストが実施できる。

出典：INVEST in Good Stories, and SMART Tasks

プロダクトオーナーによる受け入れ基準を作成する

受け入れ基準とは、プロダクトオーナーが個々のPBIに対して設けている、何をもってPBIが完成したかを確認するための基準です。

1つのPBIに対して複数の基準があり、個々が「前提条件を満たしたうえでのアクションに対する結果」を具体的にあらわした形になっているため、これを受入テストの基準として開発者が利用することが可能です。

つまり、確実に受入OKかNGかが判断できる形、かつ誰でも確実にわかる形で表現されています。

完了条件を定義し、スクラムチーム全員が意味を理解する

完了条件とは、すべてのPBIに対して共通で設けられており、PBIを完了状態にするための条件のことです。また、完了状態とはいつでもリリースしてもよい状態であることを意味しています。

代表的な完了条件の定義としては、次の非機能的要件があります。

・受け入れ条件を満たしている
・コードレビューが実施されている
・結合テストを完了している
・自動テストのカバレッジが〇〇%を超えている

完了条件はすべてのPBIに対して共通で設けられていることから、スクラムチーム全員が完了条件を理解、認識している必要があり、全員で議論してチューニングする必要があります。

プロダクトバックログのメンテナンス方法

ここまで紹介した4つのSTEPを経て、プロダクトバックログは完成します。しかし、プロダクトバックログは一度完成して終わりではありません。

プロダクトが関わるさまざまな環境変化の流れは早く、しかもビジネスの不確実性が高いのが今日の状況です。状況に合わせてプロダクトバックログを常にメンテナンスしなければ、意味のないプロダクトバックログになってしまいます。

メンテナンスの重要性が理解できたところで、メンテナンス方法についても解説する必要があるでしょう。メンテナンスについては、大きく次の2つの部分に着目して行うと非常に効果的です。

1．優先順位のメンテナンス
2．PBIのメンテナンス

1. 優先順位のメンテナンス

まず意外におろそかになりがちなのが、優先順位の見直しです。これはプロダクトオーナーが責任をもって実施する必要があり、基本的には常に行う必要があります。

しかし、プロダクトオーナーは時間に追われていることが多いのが実情です。

効率的に優先順位のメンテナンスを行うための実践的な方法としては、明示化されている優先順位の基準のメンテナンスを実施し、その変更の影響範囲内で優先順位を修正することです。これにより、効率的に優先順位をメンテナンスすることができます。

2．PBIのメンテナンス

PBIのメンテナンスは非常にわかりやすく、シンプルに、PBI自体の追加・更新・削除を行うことで実現できます。具体的にはそれぞれ次のように行います。

追加

PBIを追加するタイミングは常にあります。プロダクトに対してユーザーが新しい価値を求めた時、会社が新しいビジネス価値を求めた時、スクラムチームが新しい価値を求めた時です。PBIを追加した際にはどこかの場でスクラムチーム全体に共有することが大切です。

更新

PBIの更新は優先順位の高い順番で行います。プロダクトバックログは優先順位が高ければ内容が詳細にされ、逆に優先順位が低ければ内容があいまいになるという傾向があります。優先順位が高い方の更新は考えるべきことが多く、非常に大変です。

また更新時は、更新する背景・内容をスクラムチーム全体に伝えたうえで、優先順位をプロダクトオーナーに判断してもらう必要があります。

削除

削除は一見簡単に見えますが、一番勇気のいる行為であり重要な行動です。プロダクトバックログはアイテム数が膨大になりがちです。膨大であることはスクラムの概念的にはあまり問題ありませんが、実践的にはアイテム数が膨大になるにつれて、必要コストも増え、対応可能な時間も少なくなっていきます。

したがって、ユーザーやビジネスの状況の変化や開発チーム体制の変更が行われた際は、合わせてPBIの削除も検討してください。

アジャイル開発の実態調査

開発やテストの相談はSHIFTへおまかせ

プロダクトバックログの運用を成功に導くために一番大事なことは、スクラムチーム全体が同じゴールを目指して、自分たちで作業を管理・推進していくといった責任に対してしっかりと向き合えているかということです。いかに優れたプロダクトバックログを作っても、プロダクトオーナーがその役割を全うしても、チーム全体が同じ方向を向かなければプロジェクトはうまく進まない可能性があります。

チーム全体がプロジェクトに向き合うためには、プロダクトバックログを用いたコミュニケーションの促進ということも重要になってくるのかもしれません。いずれにしても、いまいちどスクラムの概念を思い出し、何が大切なのかを理解しましょう。

自社では対応できない開発やテストがあり困っている場合は、SHIFTまでご相談ください。上流工程から納品までの対応が可能なほか、必要な部分だけのご依頼も可能です。過去多くのシステム開発・システムテストの実績をもっているため、さまざまな分野でお役に立てるでしょう。

システム開発について悩みがある、テストだけでもお願いしたいという場合は、ぜひSHIFTにお問い合わせください。

>SHIFTのお問い合わせページへ

監修

株式会社SHIFT
「ヒンシツ大学」クオリティエヴァンジェリスト　永井敏隆

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座

・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数

――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――

この記事を書いた人

著者株式会社SHIFT　マーケティンググループ

SHIFTは「売れるサービスづくり」を得意とし、お客様の事業成長を全力で支援します。無駄のないスマートな社会の実現に向けて、ITの総合ソリューションを提供する会社です。

サービスサイト：https://service.shiftinc.jp/
コーポレートサイト：https://www.shiftinc.jp/
X（旧Twitter）：https://twitter.com/SHIFT_cp

ご支援業種

製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント

など多数

前のページへ

次のページへ

コラム一覧に戻る