コンテンツにスキップ
Scrum Knowledge Graph

プロダクトバックログ (Product Backlog)

概要

Section titled “概要”

プロダクトバックログは、スクラムチームが実装すべき機能や要件を優先順位付きで集約した創発的な一覧であり、プロダクトオーナーが管理する唯一の作業源である。機能要件や品質属性要件のほか、アーキテクチャの不確実性に対処する技術タスクなども含まれる。上位アイテムほど詳細化され、リファインメントを通じて実行可能なサイズへと整えられる。市場変化や学習に応じて動的に進化し、多基準意思決定やリスク評価を適用した順序付けが行われる。CI/CD環境では独立したテストや統合を可能にする粒度設定や随時見直しも重視される。合意形成と透明性を担保する社会技術的アーティファクトであるとともに、キュー理論の観点では未処理作業の待ち行列として捉えられ、肥大化を防ぎシステムの安定性を維持する運用が求められる。

詳細

Section titled “詳細”

プロダクトバックログは、スクラムチームが実装すべき機能や要件を優先順位付きで集約したリストであり、プロダクトオーナーが管理する唯一の作業源である[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19][20][21][22][23][24][25][26][27][28][29][30][31]。バックログアイテムはユーザーストーリー、受入テスト基準、BDDシナリオテンプレートなどの形式で記述され、詳細性や見積り、完成の検証基準を持つ[6][5][4][3][2][1][13][14][18][19][9]。上位のアイテムほど明確かつ詳細に記述され、スプリントで実行可能なサイズに分解される[6][5][4][3][2]。プロダクトオーナーは、ビジネス戦略やステークホルダーのニーズに応じて優先順位を決定し、内容の管理と透明性の維持に責任を持つ[6][5][3][2][21][7][8][14][31]。開発者は、アイテムの作業規模や見積もりを評価し、スプリントプランニングで選択可能な「準備完了（Ready）」状態を維持する[1][27]。プロダクトバックログは動的に進化し、顧客ニーズや市場変化に応じて頻繁に更新・調整される[6][5][3][2][21][13][20][17][1][7][10][9][14]。リファインメントを通じてアイテムの明確化と作業の準備が進められ、スプリント実行中に変更されることもある[5][4][3][2][1][7][10][9][14][13][18]。大規模環境では、複数チームが単一バックログから作業を引き出す運用が行われる[8][27][29][10]。並びに、ワークフローの可視化やカンバンボードでの運用も行われる[11][19]。さらに、持続可能な高頻度リリース（週次リリースなど）を志向する継続的インテグレーションやデリバリー（CI/CD）の文脈においては、変化する要件やユーザーフィードバックに迅速に対応するため、スプリントの進行中であってもプロダクトオーナーが要件や優先順位を随時レビュー・更新する動的な運用がなされる[32]。あわせて、CI/CDパイプライン上で独立してテストおよび統合を行えるようにするため、バックログに含まれる要件を適切な粒度へと分割・定義することが重視される[32]。セキュリティ要件やアクセシビリティ、データ駆動の意思決定など、さまざまな手法やアプローチが適用される[16][17][12][18][19][15][31]。機能要件や品質属性要件の整理・優先順位付けにとどまらず、アーキテクチャ上の不確実性に対処するための技術計画タスクをバックログ項目として組み込み、要件精緻化の場で見積もりや詳細化を実施した上で、反復ごとの計画策定に活用する手法も存在する[33]。アジャイルソフトウェア工学における意思決定研究では、バックログの優先順位付けや順序付け（リオーダリング）が主要な問題領域として扱われており、多基準意思決定法（MCDM）、Cost-Value分析、リアルオプション評価、不確実性管理などのモデルを適用してビジネス価値やリスクを考慮したアイテムの並べ替えが行われる[34]。要件定義や計画の段階においてプロダクトオーナー、ステークホルダー、開発チーム間の整合性と透明性を担保する核となるとともに、単なるアルゴリズムによる最適化にとどまらず、チーム内の社会的ダイナミクスやステークホルダー間の交渉を反映する社会技術的アーティファクトとしても捉えられている[34]。さらに、待ち行列理論（キュー理論）の観点からは、外部からアイテムが流入しチームの処理を待つキューとしてモデル化され、システムの安定性と密接に関わる要素としても分析されている[35]。キュー理論におけるマルコフ連鎖とエルゴード性の前提に基づけば、安定したキューは最終的にサイズが一時的にゼロ（空）になる可能性を含むことが求められる[35]。実証分析によると、安定したシステムでは不安定なシステムと比較してプロダクトバックログのサイズが平均して約10倍小さく維持される傾向にあり、チームが要求を消化しきれず過負荷になると未解決アイテムが累積・肥大化してシステムの不安定性を引き起こす要因となる[35]。プロジェクトのテイラリングやアンチパターンの影響も考慮され、現場の状況に応じた柔軟な運用が求められる[23][24]。

大規模アジャイル開発では、正式な優先順位付け手法の欠如や、ステークホルダーの関心・知識・関与の欠如が、優先順位付けされていないプロダクトバックログにつながりうる[36]。大規模なアジャイル ERP 変革プログラム 1 件のケーススタディでは、優先順位付けと見積りが行われた要求を含む、作成されたプロダクトバックログが、実現フェーズの基礎となった[37]。

在宅勤務でスクラムを行った 12 人へのインタビューでは、プロダクトバックログとスプリントバックログを区別した対象者はおらず、大半の対象者は両者の用語を互換的に使っていた[38]。

ノルウェーの超大規模開発プログラムの事例研究では、ソリューション記述の主な目的は、プロダクトバックログにフィーチャーチームの 1〜3 イテレーション分を満たすのに十分な優先度の高い作業が含まれていることを保証することだった[39]。

プロダクトバックログは、プロダクトオーナーのビジョンを踏まえ、プロダクトに必要なアイテムを優先順位順で並べたリストである[40]。

STEM-EFにおいて、プロダクトバックログのリファインメントや優先順位付けの交渉は、メンバーのモチベーション維持や感情的摩擦の低減を図るための感情的配慮を適用する対象として位置づけられている[41]。

分類・所属

Section titled “分類・所属”
  • 所属タグ: Product Backlog Scrum Artifact Scrum Core Artifacts Product Management
  • カテゴリー: Scrum Core

オントロジー上の位置

Section titled “オントロジー上の位置”
  • 上位クラス（直接の親から順に）: Composite_Artifact → Artifact → Measurable_Software-Related_Entity → Measurable_Entity
  • 兄弟クラス: Software_Product、SprintBacklog
  • 他の概念との関係:
  • 関連する検証ルール: 未定義
  • 関連CQ: 未対応
  • 原文: 未定義
  • オントロジー階層: オントロジー階層で見る

脚注

Section titled “脚注”

  1. Scrum Guide 2020（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  2. Scrum Guide 2017（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  3. Scrum Guide 2013（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. Scrum Guide 2011 October（ライセンス: All Rights Reserved） ↩ ↩2 ↩3 ↩4

  5. Scrum Guide 2010（ライセンス: ライセンス不明） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  6. Scrum Guide 2009（ライセンス: ライセンス不明） ↩ ↩2 ↩3 ↩4 ↩5

  7. Scrum Guide Expansion Pack — 「プロダクトバックログは透明性を高めるためのツールである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  8. Nexus Guide — 「スクラムで規 定されているように、プロダクトバックログには内容について最終的な決定権を持つ 1 人のプロダクトオーナーが割り当てられる。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3

  9. Scrum Guide (LeSS Version)（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  10. Scrum@Scale Guide — 「プロダクトのフィードバックは、プロダクトオーナー組織によって解釈され、プロダクトバックログを更新することでプロダクトの継続的改善を促す。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  11. Kanban Guide for Scrum Teams 2021 — 「- 作業項目の定義 スクラムチームのシステムを(通常はプロダクトバックログアイテ ムとして)流れる価値の単位(ステークホルダーの価値、知識の価値、プロセス改 善の価値)。」（ライセンス: CC BY-SA 4.0） ↩ ↩2

  12. An Ontology-based Approach to Enable Data-driven Decision-making in Agile Software Organizations（ライセンス: CC BY 4.0） ↩ ↩2

  13. ScrumOntoBDD: Agile software development based on scrum, ontologies and behaviour-driven development（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  14. Agile Software Development and Reuse Approach with Scrum and Software Product Line Engineering（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  15. ChainAgile: A framework for the improvement of Scrum Agile distributed software development based on blockchain（ライセンス: CC BY 4.0） ↩ ↩2

  16. Identifying Key Activities, Artifacts and Roles in Agile Engineering of Secure Software with Hierarchical Clustering（ライセンス: CC BY 4.0） ↩ ↩2

  17. Agile Software Development with Secure and Scrum-Centric Approach（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3

  18. Integrating Design-Based Research and Agile Scrum for Inclusive Educational Technology Design — 「私たちのプロダクトバックログには、機能ストーリーと研究ストーリーの両方が組み込まれ、データ収集および分析タスクに体系的な注意が払われるようにしました。」（原文: “Our product backlog incorporated both feature stories and research stories, ensuring systematic attention to data collection and analysis tasks.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  19. Integrating DAST in Kanban and CI/CD: A Real-World Security Case Study（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  20. A Theory of Scrum Team Effectiveness（ライセンス: CC BY 4.0） ↩ ↩2

  21. Scrum: An Agile Software Development Process and Metrics — 「プロダクトバックログ、すなわちビジネス要件の順序でプロダクトオーナーによって優先順位付けされた機能リストです。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  22. Agile Coaching Growth Wheel — 「- ● 効果的なプロダクトバックログ： 価値あるアウトカムを通じてプロダクトを改善するために必要なものに焦点を当てたプロダクトバックログを作成すること。」（原文: “● Product Backlog Effectiveness: creating a Product Backlog that focuses on what is needed to improve the product through valuable outcomes.”）（訳）（ライセンス: CC BY-SA 4.0） ↩

  23. Tailoring Choices Made in Scrum Projects: A Systematic Literature Review（ライセンス: CC BY 4.0） ↩ ↩2

  24. Exploring the Prevalence of Anti-patterns in the Application of Scrum in Software Development Organizations（ライセンス: CC BY 4.0） ↩ ↩2

  25. Systematic Literature Review Report on the Challenges of Agile Scrum（ライセンス: CC BY 4.0） ↩

  26. Improving Risk Management in a Scaled Agile Environment — 「Daily Standup Meeting（デイリースタンドアップミーティング）、Kanban Board（カンバンボード）、Product Backlog（プロダクトバックログ）などのアジャイルプラクティスは、個々のチームのリスクの透明な取り扱いを支援する。」（原文: “Agile practices such as Daily Standup Meeting, Kanban Board or Product Backlog support the transparent handling of risks for an individual team.”）（訳）（ライセンス: CC BY 4.0） ↩

  27. Decision-Making and Team Autonomy in Large-Scale Agile Software Development: An Analysis of Scaling Frameworks — 「プロダクトバックログはプロダクトオーナー（PO）の責任であり、バックログの内容と優先順位付けに関する意思決定スタイルは、POが完全な自律性を持っているためPOに委ねられています（SP3）。」（原文: “The product backlog is the responsibility of the Product Owner (PO), and the decision-making style for backlog content and prioritization is up to them (SP3), as they have complete autonomy.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  28. Finding the sweet spot for organizational control and team autonomy in large-scale agile software development（ライセンス: CC BY 4.0） ↩

  29. Do Agile Scaling Approaches Make a Difference? An Empirical Comparison of Team Effectiveness Across Popular Scaling Approaches — 「作業は共有のプロダクトバックログからプルされ、単一のプロダクトオーナーによって管理される。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  30. Inter-team Coordination in Large-Scale Agile Development: A Case Study of Three Enabling Mechanisms（ライセンス: CC BY 4.0） ↩

  31. Applicability of the Scrum Methodology in Remote Work Environments and the Challenges Encountered — 「スクラムは、プロダクトバックログやスプリントバックログといった主要な作成物（アーティファクト）と、デイリースクラム、スプリント計画（Sprint Planning）、スプリントレビュー（Sprint Review）、スプリントレトロスペクティブ（Sprint Retrospective）などの定期的なイベントで構成されています。」（原文: “Scrum consists of key artifacts such as the Product Backlog and Sprint Backlog, as well as regular ceremonies including the Daily Scrum, Sprint Planning, Sprint Review, and Sprint Retrospective.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  32. Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices — 「プロダクト要求の変更を可能にし承認するために、スプリントにプロダクトオーナーレビューが導入されたほか、プロダクトオーナーがプロダクト要求のバックログに優先順位を付けられるようになった。」（訳）（ライセンス: All Rights Reserved） ↩ ↩2

  33. ArchHypo: Managing Software Architecture Uncertainty Using Hypotheses Engineering — 「機能要件および品質要件で構成されるバックログがリファインおよび優先順位付けされ、その項目が見積もられた。」（訳）（ライセンス: CC BY 4.0） ↩

  34. Decision-Making in Agile Software Engineering: A Systematic Literature Review of Models, Methods, Actors and Lifecycle Contexts — 「さらに意思決定は、バックログの優先順位付け、リリース計画、アーキテクチャのトレードオフ、リスク評価、イテレーションのふりかえり（レトロスペクティブ）といったプラクティスに組み込まれた、アジャイルソフトウェア開発において固有かつ反復的な活動である。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  35. A Novel Technique to Assess Agile Systems for Stability — 「この分析の結果から、これらのJiraプロジェクトのうち72.89%が不安定であり、平均すると、安定したシステムのプロダクトバックログサイズは約10倍短いことがわかりました。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  36. Challenges in Large-Scale Agile Software Development Projects — 「プロダクトマネージャー、顧客、および主要なステークホルダーが作業の優先順位を設定します。彼らの関心の欠如、知識の不足、または関与の欠如は、優先順位付けされていないバックログにつながる可能性があります。ストーリーポイントなどの正式な優先順位付け手法に従っていないチームも、優先順位付けされていないプロダクトバックログを生み出します。」（原文: “The product manager, customers, and key stakeholders set work priorities. Their lack of interest, lack of knowledge, or lack of involvement can lead to un-prioritised backlogs. Teams not following any formal prioritisation techniques, such as story points etc., also generate un-prioritised product backlogs.”）（訳）（ライセンス: CC BY 4.0） ↩

  37. Investigating Effort Estimation in a Large-Scale Agile ERP Transformation Program — 「優先順位付けと見積りが行われた要求を含む、作成されたプロダクトバックログが、実現フェーズの基礎となる。」（訳）（ライセンス: CC BY 4.0） ↩

  38. The impact of working from home on the success of Scrum projects: A multi-method study — 「プロダクトバックログとスプリントバックログはスクラムにおける2つの異なる作成物（アーティファクト）であるにもかかわらず、私たちの議論の中でその2つを区別した参加者はいませんでした。大半の参加者にとって、それらの用語は互換的に使われており、バックログがJiraやTrelloでデジタル形式になっていたため、どちらのバックログを扱うかも同様に互換的でした。」（訳）（ライセンス: CC BY 4.0） ↩

  39. Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation — 「Performにおけるソリューション記述の主な目的は、プロダクトバックログにフィーチャーチームの1〜3イテレーション分を満たすのに十分な優先度の高い作業が含まれていることを保証することであった。」（原文: “The main purpose of solution description in Perform was to ensure that the product backlog contained enough high priority work to fill one to three iterations for the feature teams.”）（訳）（ライセンス: CC BY 4.0） ↩

  40. Scrum: A Systematic Literature Review — 「これに基づいて、優先順位ごとにリソースアイテムを並べたリストが作成され、これはプロダクトバックログと呼ばれる。」（原文: “From this, a list of resource items by priority level is created, called the Product Backlog.”）（訳）（ライセンス: CC BY 4.0） ↩

  41. STEM-EF: A Scrum Teamwork Effectiveness Model Based on Emotional Factors — 「IS1「プロダクトバックログにおける交渉」およびIS2「チームや組織の目標に向けた影響力」は、主体的な対話とスプリントの目標への整合を反映している[22]。」（原文: “IS1 – Negotiation in the Product Backlog and IS2 – Influence toward team or organizational goals reflect proactive dialogue and alignment with sprint objectives [22].”）（訳）（ライセンス: CC BY 4.0） ↩