2025.03.31
昨今、チームが一丸となって開発を進めていく「スクラム開発」が広く採用されており、その中でも基本要素ともいえる「プロダクトバックログ」の作成が欠かせません。
プロダクトバックログとは、プロダクトの改善に必要な作業を一覧にまとめたものです。
今回はプロダクトバックログの役割や、基本の項目をわかりやすく解説します。
記事の後半では、プロダクトバックログの作り方や書き方のポイントも紹介するため、ぜひ参考にしてみてください。
1．プロダクトバックログとは
プロダクトバックログとは、スクラム開発においてプロダクトに対して必要な作業を管理するリストのことを指します。
スクラム開発では短期間の「スプリント」で開発を区切り、各スプリントでさまざまな開発項目に対応していきます。こうした開発項目に優先順位を付け、全体の対応状況を管理するものがプロダクトバックログです。スクラム開発においては基本要素といえます。
なお、そもそもスクラム開発とは何か、概要を確認しておきたい方は、次の記事をご覧ください。
1-1 プロダクトバックログの目的
プロダクトバックログは、開発チームの道しるべとなる重要なものです。プロダクトバックログを作成する目的・メリットをご紹介します。
方針決定の効率化
プロダクトバックログの各アイテムには、優先順位やステータス（対応状況）を記載することが一般的です。これにより、「何を優先すべきか」「何が終わっていないか」が可視化されるため、次のスプリントに向けた方針決定の効率化が期待できます。
残件の対応漏れ防止
各スプリントの残件をバラバラに管理すると、何を対応すべきかわからなくなりがちです。その点、プロダクトバックログには全スプリントを通しての残件を記載します。プロダクトバックログにスプリントの残件を集約することで、対応漏れの防止につながるでしょう。
ステークホルダーとの対話円滑化
プロダクトバックログはスクラムチームのみならず、顧客や運用チーム、経営陣といったステークホルダーとの対話にも活用可能です。それまでのスプリントにおける残件が集約・可視化されているため、対外的な開発状況の説明にも役立つでしょう。
1-2 スプリントバックログとの違い
| 項目 | プロダクトバックログ | スプリントバックログ |
|---|---|---|
| 目的 | 製品全体のやるべきことを管理する | 1回のスプリント（短期間の開発）でやるべきことを管理する |
| 誰が管理する？ | プロダクトオーナー | 開発チーム |
| 内容 | すべての機能や要件のリスト（優先度付き） | スプリント期間内にやるタスクの詳細（より具体的） |
| 変更のしやすさ | 追加・変更が頻繁に行われる | スプリント中は基本的に変更しない |
プロダクトバックログと関連する要素に「スプリントバックログ」があります。スプリントバックログとは、1サイクル分のスプリントにおける作業をまとめたリストのことです。
プロダクトバックログは、全スプリントを通して管理するのに対して、スプリントバックログは、1スプリントの作業だけを管理するのが違いです。
一般的に、スプリントの進行中はスプリントバックログで管理し、スプリント終了時などにプロダクトバックログへ反映します。
スクラム開発では、2つのリストを適切に併用しながら、効率的に残件を管理することが大切です。
2．プロダクトバックログに記載する主な4つの項目
プロダクトバックログで管理する「残件」とは、具体的にどのような項目なのでしょうか。プロダクトバックログに記載する主な項目は、次の4つです。
2-1 追加機能（フィーチャー）
「追加機能」はユーザーに価値を提供するために、文字どおり新しく追加する機能の項目です。
アジャイル開発では「フィーチャー」と呼ばれることもあります。ユーザーが必要とし、その価値を認識できる追加機能は全てフィーチャーとして記載しましょう。たとえば、「ファイル出力機能の追加」のように小規模な開発内容であっても記載対象となります。
なお、追加機能を整理する際には「ユーザーストーリー」と呼ばれる手法で言語化することがポピュラーです。ユーザーストーリーについて詳しくは、次の記事をご覧ください。
2-2 バグ修正
「バグ修正」は、それまでのスプリントを通して判明している、修正すべきバグの項目です。スプリント内で解決できなかった、あるいは次のスプリント以降に持ち越したいバグを記載します。
顧客からフィードバックを受けた問題も含めて、原因がソフトウェアのバグであれば記載しましょう。ただし、問題の指摘時点ではバグなのか判断できない場合も考えられます。この場合、チームによっては後述する「技術的負債」として扱うケースもあります。
2-3 技術的負債
「技術的負債」とは明確なバグではないものの、技術的に改善の余地がある項目です。たとえば、古いライブラリの更新、暫定対応した箇所の恒久対応などが挙げられます。
顧客やエンドユーザーの目に付く問題は生じないことが多いため、追加機能やバグ修正と比べて優先順位は低くなりがちです。しかし、技術的負債が積み重なると後から「返済」が困難になりやすいため、できる限り早期に対応しましょう。
2-4 知識獲得
「知識獲得」は文字どおり、将来（次のスプリント以降）を見据えて知識の獲得が必要となる項目です。たとえば、新機能を実現するための事前調査、新しいライブラリに対応するための事前学習などが挙げられます。
技術的負債と同様、追加機能やバグ修正と比べて優先順位は低くなりやすいでしょう。しかし、いざ必要となったタイミングで必要な知識がないと対応が困難となるため、漏れなく記載しておくことが大切です。
3．プロダクトバックログの作成手順
スクラム開発を正しく進めるために、プロダクトバックログの作成手順を把握しておきましょう。プロダクトバックログの作り方は、大まかに次の6ステップです。
ステップ1 プロダクトゴールの明確化
まずは「プロダクトゴール」を明確化します。プロダクトゴールとは、全スプリントを通して目指す最終的なプロダクトの姿や、提供すべき価値のことです。プロダクトゴールを明確化したうえで、その達成に向けて開発を進めていきます。
プロダクトオーナーが中心となり、プロダクトゴールを明確化します。このとき、ステークホルダーの要求をヒアリングし、正しく反映させることが大切です。対外的なニーズに応えられないプロダクトゴールでは、最終的な成功にはつながりません。
ステップ2 プロダクトバックログアイテムのリストアップ
明確となったプロダクトゴールを踏まえて、「プロダクトバックログアイテム（PBI）」をリストアップします。PBIとは、プロダクトバックログに記載する各項目（追加機能・バグ修正・技術的負債・知識獲得）のことです。プロダクトゴールの達成に必要となるPBIを漏れなくリストアップしましょう。
プロダクトオーナーのみならず、スクラムチームの各メンバーを含めて協議しながらPBIを決めていきます。この段階では漏れなくリストアップすることが重要であり、優先順位はまだケアしなくて構いません。
ステップ3 各アイテムの優先順位付け
ひと通りPBIのリストアップが完了したうえで、各アイテムに優先順位を付けます。顧客の要求度の高さや想定される工数、後回しにすることのリスクなどを考慮し、総合的に優先順位を判断しましょう。ここでもスクラムチーム全体での協議が欠かせません。
なお、各アイテムの工数を見積もる際には「ストーリーポイント」と呼ばれる手法が広く用いられます。ストーリーポイントとは、1つのアイテムを基準として各アイテムの難易度を考え、相対的に評価するものです。たとえば、あるタスクを「1ストーリーポイント」と評価した場合、他のタスクはそのタスクと比べてどれくらい難易度が高いのか、低いのかをストーリーポイントで表します。評価の基準はスクラムチームによります。
ステップ4 スプリントバックログへの落とし込み
各アイテムに優先順位を付けた後は、スプリントバックログへの落とし込みが必要です。プロダクトバックログの中から、次のスプリントで対応すべきPBIをピックアップし、スプリントバックログに記載します。優先順位や工数を考慮しながら実施しましょう。
ただし、プロダクトバックログのアイテム単位だと抽象的で、各メンバーが対応しづらい場合があります。その場合は、PBIを詳細に分割してからスプリントバックログに記載しましょう。完成したスプリントバックログに沿って、開発を進めていきます。
ステップ5 完了確認・プロダクトバックログへの反映
現在のスプリントが終了するタイミングで、スプリントバックログに記載された各アイテムの完了確認を行います。修正が完了していないバグや、追加できなかった機能などがあれば、それらの情報をプロダクトバックログへ反映しましょう。
また、そのスプリント内で完了したPBIがあれば、プロダクトバックログ内の該当項目をクローズします。以降のスプリントでも、「プロダクトバックログからスプリントバックログに落とし込み、プロダクトバックログへ反映する」といった流れで進めていきます。
ステップ6 プロダクトバックログリファインメントの定期実施
「プロダクトバックログリファインメント」を定期的に実施しましょう。プロダクトバックログリファインメントとは、各PBIの優先順位や過不足などを見直すことです。
スプリントを進めていくなかでPBIの優先順位が変わったり、増減したりすることも考えられます。定期的に見直しを行い、全体の整合性を保ちましょう。
4．プロダクトバックログにおける書き方のポイント【例文付き】
プロダクトバックログを有効活用するために、書き方のポイントも押さえておきましょう。ここでは、例文も交えてプロダクトバックログにおける書き方のポイントを3つ紹介します。
4-1 社内外を問わず伝わるように書く
プロダクトバックログは、社内外を問わず伝わるように書きましょう。内部の事情を知らない顧客や経営陣などにも見せる場合があるため、チーム内にしか伝わらない表現はNGです。
たとえば勤怠管理サービスを開発する場合、「従業員は残業を申請できる」「管理職は従業員の残業申請を承認できる」といった書き方が考えられます。このように、開発に携わっていないステークホルダーでも理解できるレベルの書き方がよいでしょう。
4-2 各アイテムが詳細すぎるのはNG
プロダクトバックログの各アイテムが詳細すぎるのはNGです。あまりに具体的な内容を入れると対外的に伝わらないばかりか、アイテムが増えて管理が煩雑になってしまいます。
たとえば、「シフトテーブルに備考カラムを追加」「申請用の関数を共通化」のように、設計やプログラムレベルの書き方は適切ではありません。このように詳細なアイテムは、基本的にスプリントバックログで管理すべきです。プロダクトバックログに記載するのであれば、「労務担当者はシフトに備考を追加できる」のように抽象化しましょう。
4-3 明確な完了条件を盛り込む
プロダクトバックログには、明確な完了条件を盛り込みましょう。完了条件が明確になっていないと、スプリントの終了時に完了確認を正しく行えません。完了条件についても、ステークホルダーに説明しやすいよう、伝わる表現を心がけるべきです。
たとえば、追加機能の場合は「機能テストでNG判定がないこと」「コードレビューが完了していること」といった書き方が考えられます。ある程度は共通化できますが、項目の種類（追加機能やバグ修正など）によって変える必要があるでしょう。
まとめ
スクラム開発におけるプロダクトバックログとは、プロダクトに対して適用されるべき残件を管理するリストのことです。適切にプロダクトバックログを運用することで、残件の対応漏れ防止や方針決定の効率化、ステークホルダーとの対話円滑化につながります。
プロダクトバックログの作り方や書き方のポイントを把握し、より高品質なスクラム開発を実現しましょう。
なお、プロダクトバックログに限らず、IT関連のノウハウに関する理解を深めたい場合は、当サイト「Qbook」をご活用ください。
Qbookの無料会員登録を行えば、イベント情報や業界人のインタビューなど、最新のお役立ち情報をメールマガジンで受信できます。
