プロダクトバックログとは？
プロダクトバックログは、プロダクトを良くするために必要なものを、並び順を付けて並べた一覧です。スクラムガイド（2020年版）では、スクラムチームが行う作業の唯一の源とされています。
入るアイテムは、新しい機能だけではありません。代表的なのは次の4種類です。
- 機能： 利用者が使う新しい機能や改善。ユーザーストーリーの形で書くことが多い
- 不具合の修正： 見つかったバグの直し
- 技術的な改善： 技術的負債（後回しにした設計や作りの問題）の返済、性能の改善など
- 調査： 技術や市場の分からないことを確かめる作業。スパイクとも呼ぶ
プロダクトバックログには、「確約」としてプロダクトゴールが対応します。プロダクトゴールは、プロダクトの将来の姿を表す長期の目標です。アイテムは、そのゴールに近づくためのものです。
スプリントバックログ・WBSとはどう違う？
混同しやすい3つを並べます。
| 観点 | プロダクトバックログ | スプリントバックログ | WBS（予測型） |
|---|---|---|---|
| 範囲 | プロダクト全体のこれからの作業 | 今のスプリントのゴール・選んだアイテム・実現の計画 | プロジェクトのスコープ全体を成果物で分解したもの |
| 管理する人 | プロダクトオーナー（並び順に責任） | 開発者 | プロジェクト・マネジャーとチーム |
| 変わる頻度 | いつでも追加・削除・並べ替え | スプリント中も、学びに応じて開発者が更新 | 変更管理の承認を経て更新 |
| 詳しさ | 上ほど詳しく、下は粗い | 1日以内の作業に分けることが多い | 最下層のワーク・パッケージまで詳しく |
予測型では、要求を開発の前に文書で確定させ、変えるには変更管理の手続きが要ります。プロダクトバックログは、変化を前提に並べ直し続ける「生きた一覧」です。予測型のスコープの考え方はスコープマネジメントで整理しています。
どうやって作る？（5ステップ）
新しくプロダクトバックログを作るときの手順です。最初から全部を詳しくする必要はありません。
- 1
1. ゴールを決める
誰のどんな問題を解くかを、プロダクトゴールとして1〜2文で書く
- 2
2. 書き出す
関係者と、機能・不具合・改善・調査のアイテムを洗い出す
- 3
3. 見積もる
作業をする開発者が大きさを見積もる（ストーリーポイントなど）
- 4
4. 並べる
価値・リスク・依存関係を見て、プロダクトオーナーが一列に並べる
- 5
5. 上位を詳しくする
次の1〜2スプリント分を小さく分け、受入基準を付ける
作ったら終わりではありません。スプリントレビューで分かったことをもとに、毎回並べ直します。
並び順を決めるプロダクトオーナーの責任は、プロダクトオーナーの役割で詳しく扱います。
アイテムはどう書く？
アイテムの書き方はスクラムでは決められておらず、チームが選びます。よく使われるのはユーザーストーリーの形です。どの形でも、次の情報があると扱いやすくなります。
| 項目 | 内容 | 例 |
|---|---|---|
| 説明 | 誰の、どんな必要を満たすか | 会員として、予約を変更したい。予定が変わっても電話せずに済むように |
| 受入基準 | できたと判断する条件 | 前日18時まで変更できる／変更後に確認メールが届く |
| 大きさ | 開発者による見積もり | 5ポイント |
| 並び順 | 一覧の中の位置 | 上から3番目 |
| 価値やメモ | 並び順の根拠、関係者、依存関係 | 電話の問い合わせが月200件ある |
ユーザーストーリーの書き方と、良いアイテムの条件（INVEST）はユーザーストーリーの書き方で詳しく扱います。
優先順位はどう付ける？（価値・リスク）
並び順を決めるのはプロダクトオーナーです。基準は1つではなく、複数の観点を合わせて判断します。
- 価値： 利用者や事業にとってどれだけ役立つか。売上・コスト削減・満足度・法令順守など。
- リスク： 不確かなことを早く確かめられるか。技術的に難しい部分を先にやると、失敗が早く分かります。
- 依存関係： 他のアイテムや外部の締め切りの前提になるか。
- 大きさ： 同じ価値なら、小さいものを先にすると早く価値が届きます。
- 時期： 遅れると価値が下がるか（季節の行事、法律の施行日など）。
よく使われる手法も3つ挙げます。MoSCoW 分析は、必須・あるべき・あってもよい・今回はやらない、の4つに分けます。価値と大きさの比は、価値の点数を大きさで割り、大きい順に並べます。カノ分析は、当たり前品質・一元的品質・魅力的品質に分けて考えます。
計算例：価値と大きさの比でどう並ぶ？
価値と大きさの比を、3つのアイテムで計算してみます。
比 ＝ 価値の点数 ÷ 大きさ（ストーリーポイント）
- 1アイテムA：価値 40 ÷ 大きさ 8 ＝ 5.0
- 2アイテムB：価値 30 ÷ 大きさ 3 ＝ 10.0
- 3アイテムC：価値 20 ÷ 大きさ 5 ＝ 4.0
- 4比の大きい順：B（10.0）→ A（5.0）→ C（4.0）
価値が最大のAより、小さくて価値の高いBを先にすると、早く多くの価値が届きます。
当サイトの計算例。実際はリスクや依存関係も合わせて判断します。
価値の点数は、売上や利用者数などの根拠を添えて付けると、関係者に説明しやすくなります。大きさは開発者の見積もりを使います。
リファインメントとは？
プロダクトバックログ・リファインメントは、アイテムを小さく分け、詳しくし、並び順や大きさを見直す活動です。スクラムガイドでは、イベントではなく継続的な活動とされています。以前は「グルーミング」とも呼ばれていました。PMI の『アジャイル実務ガイド』の日本語版では「バックログの洗練」と訳されています。
目標は、上位のアイテムを、1つのスプリントで完了できる大きさと詳しさにしておくことです。そうすれば、スプリントプランニングで迷わずに選べます。
- 上位次の1〜2スプリントで扱う。小さく分けられ、受入基準と見積もりがある
- 中位数スプリント先。おおまかな内容と大きさが分かっている
- 下位いつかやるかもしれない。エピック（大きなまとまり）やアイデアのまま
全部を最初から詳しくしないことで、変化に強くなり、無駄な作業を減らせます。
- 分ける： 大きなアイテム（エピック）を、1スプリントで終わる大きさに分けます。
- 詳しくする： 受入基準を書き、分からない点をプロダクトオーナーや関係者に確かめます。
- 見積もる： 作業をする開発者が大きさを見積もります。プロダクトオーナーは内容を説明し、判断を助けます。
- 並べ直す： 分かったことをもとに、プロダクトオーナーが並び順を見直します。
かける時間はチームが決めます。2017年版のスクラムガイドには「通常は開発チームの容量の10%以下」という目安がありました。2020年版では、この目安は削除されています。『アジャイル実務ガイド』には、週1時間以内に収めることを目標にするチームが多い、と書かれています。
よくある失敗と直し方は？
| よくある失敗 | 起きること | 直し方 |
|---|---|---|
| 何百件も積み上がり、古いアイテムが残る | 大事なアイテムが埋もれ、並べ直しに時間がかかる | 長く手つかずのアイテムを統合・削除する |
| 「優先度：高」ばかりで順番がない | どれから着手すべきか、チームが判断できない | 同じ順位を作らず、一列に並べる |
| 上位が大きく、あいまいなまま | プランニングが長引き、見積もりも外れる | 定期的にリファインメントする |
| 関係者が開発者に直接頼む | バックログの外の作業が増え、ゴールが崩れる | 要望はプロダクトオーナーに集める |
| 技術的な改善が入っていない | 負債がたまり、開発が遅くなる | 改善もアイテムにして、価値と並べて扱う |
PMP試験ではどう問われる？
- 新しい要望が来た → プロダクトバックログに入れ、プロダクトオーナーが並べ直す
- プランニングでアイテムが大きすぎて選べない → リファインメントの不足。定期的に行う
- 見積もりを誰がするか → 作業をする開発者。PMやプロダクトオーナーが決めない
- 外部環境の変化（法改正など）が起きた → 影響を評価し、バックログの優先順位に反映する
- 技術的負債がたまっている → 改善のアイテムをバックログに入れ、価値と並べて扱う
新ECO（2026年版）の Business Environment のタスク8は、外部環境の変化の評価です。変化がスコープやバックログに与える影響を評価し、優先順位を付ける仕事が含まれます。バックログは、予測型でいうスコープと同じく、関係者との合意の対象でもあります。
確認問題1
法改正への対応
（当サイトの独自問題）会計ソフトをスクラムで開発しています。6か月後に施行される税制の改正で、計算方法の変更が必要になると分かりました。プロダクトバックログの上位には、営業が求める新しい画面のアイテムが並んでいます。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：4。外部環境の変化は、影響を評価してバックログの並び順に反映します。並び順を決めるのはプロダクトオーナーです。期限と作業量を考えると、早めに上位へ上げる判断になるでしょう。
1：アジャイルの場面では、新しい要求はまずプロダクトバックログで扱います。2：影響の評価を遅らせると、期限に間に合わない危険が増えます。3：並び順を決めるのは、開発者ではなくプロダクトオーナーです。
確認問題2
プランニングが毎回長引く
（当サイトの独自問題）スプリントプランニングが毎回、上限の時間を超えています。上位のアイテムの多くは「管理画面を改善する」のような、大きく漠然とした内容です。チームは、その場で分けたり質問したりしています。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：1。上位のアイテムを、1スプリントで完了できる大きさと詳しさにしておくのがリファインメントの目的です。プランニングの前に継続的に行います。
2：タイムボックスを延ばしても、準備不足という原因は残ります。3：見積もりは作業をする開発者が行います。PMが代わりに行うと、開発者の確約になりません。4：大きなアイテムにも価値があります。外すのではなく、分けて扱います。
確認問題3
価値と大きさで並べる
（当サイトの独自問題）プロダクトオーナーが、次のスプリントの候補を価値と大きさの比で並べようとしています。アイテムPは価値60・大きさ12、アイテムQは価値24・大きさ3、アイテムRは価値45・大きさ5です。リスクや依存関係に差はありません。比の大きい順に並べたものはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：2。比は P：60÷12＝5.0、Q：24÷3＝8.0、R：45÷5＝9.0 です。大きい順に R（9.0）→ Q（8.0）→ P（5.0）となります。
1：価値の点数だけで並べた順です。3：大きさの小さい順に並べただけで、価値を考えていません。4：Q と R の比の大小、P の位置の両方が誤りです。
並び順や見積もりが絡む問題は、タスク別ドリルの Process のタスクで練習できます。