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

プロダクトオーナー (Product Owner)

概要

Section titled “概要”

プロダクトオーナーは、スクラムチームにおいてプロダクトと作業の価値を最大化する説明責任を負う中核的な役割である。顧客や外部環境とのインターフェースとなり、プロダクトビジョンの提示やプロダクトバックログの管理・優先順位付けを通じて開発の方向性を導く。反復前の要件精緻化やクライアント調整、スプリント終了時の成果確認や仮説評価など、要求定義から品質・リリース判断までを統括する。原則として単一の個人が決定権を持つが、大規模環境ではPO間の協調や依存関係管理が求められる。現場では要求競合や主観的判断の偏り、権限不足等の課題に直面しやすいため、組織的な権限委譲とオープンな対話に基づく信頼関係の構築が不可欠である。

詳細

Section titled “詳細”

役割の定義と目的

Section titled “役割の定義と目的”

プロダクトオーナーは、スクラムマスター、チームとともにスプリントプランニングミーティングに参加し、次のスプリントで何を行うかを議論する[1]。原則として必ず1人の人間（個人）で構成される必要があり、委員会などの合意体やテクノロジーであってはならないとされる[2][3][4][5][6][7][8][9][10]。また、2009年版と2010年版のスクラムガイドでは、プロダクトオーナーがスクラムマスターを兼任してはならないとされていた（2011年版以降、2020年版を含むスクラムガイドにはこの規定は無い）[2][3]。開発チームが設計、テスト、デプロイといった技術的実装を担うのに対し、プロダクトオーナーは何を開発すべきかを把握し、製品機能の定義、リリーススケジュールの決定、製品の収益性の確保に責任を負う役割としても位置づけられる[11]。チームレベルのアジャイル手法において、顧客や外部環境との依存関係・インターフェースを担う中核的な役割として位置づけられるとともに、ビジネスチームがアジャイルな考え方を取り入れ、技術チームと協調して価値ストリームに参加する際に使用される標準的なスクラムの役割の一つでもある[12]。 Ericssonの大規模アジャイル開発組織の事例では、プロダクトオーナーをチームごとに置かず、チーフプロダクトオーナー1名とプロダクトオーナー10名からなるPOチームが、要求に連帯して責任を負う[13]。 大規模アジャイルシステム開発の通信会社の事例では、プロダクトオーナーの階層構造が、製品要件や顧客に見えるフィーチャーをバックログアイテムへと分解する[14]。プロダクトオーナーは、プロダクトのビジョンを策定し、プロダクトバックログアイテムの定義と優先順位付けを通じてスクラムチーム全体の作業を方向付ける役割である[15]。 プロダクトオーナーは、顧客やステークホルダー、チームと協調して課題や提供価値を明確化し、プロダクトの価値最大化に向けた協調的学習サイクルを中心となって推進する役割である[16]。

プロダクト戦略・ビジョンとプロダクトゴールの管理

Section titled “プロダクト戦略・ビジョンとプロダクトゴールの管理”

プロダクトに対する明確なビジョンを確立し、チーム全体に浸透させることが価値志向の開発を推進する上で重要とされる[17][18]。プロダクトオーナーは単なるバックログの詳細化や管理業務にとどまらず、ビジョナリーや意思決定者として戦略的に振る舞うことが求められ[8]、開発チーム等との調整を通じて実効性のある実用最小限のプロダクト（MVP）の範囲を定義する役割も果たす[19][10]。なお、プロダクトゴールの策定・伝達・確約の責任はガイドやNexus[9][7][8]で明確に位置づけられたものであり、プロダクトの長期的な目標として設定・確約することが求められる[9]。それ以前のガイド定義[3][4][5][6][20]ではプロダクトバックログの内容・優先順位の決定や最適化を中心に規定されていた。なお、プロダクトゴールの策定権限について、スクラムではプロダクトオーナーが自律的にゴールを定義するが、Scaled Agile Framework（SAFe）では外部ステークホルダーとの協議が不可欠となり自律性が制限される傾向がある[21]。また、MVPの定義においても、Large-Scale Scrum（LeSS）ではポートフォリオレベルで複数グループが関与して合意を形成する運用がとられる[21]。また、リスク管理や製品要求仕様（PRD）等の戦略的方向性に関する意思決定において、デベロッパーやマネージャー、外部ステークホルダーとの橋渡し役として機能する[22]。

プロダクトバックログの管理と要求分析・リリース管理

Section titled “プロダクトバックログの管理と要求分析・リリース管理”

概念から実行に至るまで、行うべき作業の価値と順序を整理して組織的な整合性を確保する[23]。エンドユーザーやステークホルダーからの要望やインプットを基に明確で理解しやすいプロダクトバックログを作成し、アイテムの明確化、並び替え、維持管理を行う唯一の権限と責任を持つ[2][3][7][8][9][24][10][25][4][5][20][18][26]。自チームのスプリントバックログの構成や優先順位付けに全責任を持つ[24]。品質、速度、リスク、コスト、ステークホルダーの要望など、相反する制約やトレードオフのバランスを取ることが求められる[8]。開発チームの作業とプロダクトの価値を最大化・最適化することに責任を持ち[3][5][6][20]、ゴールを達成できるようバックログアイテムを明瞭な形で表現して並び替える[3][4][5][6][20][7][9][10][25][27][18]。なお、バックログ管理作業やアイテム作成などの実務作業を開発チーム（デベロッパー）等へ委譲可能であるが、最終的な決定権や結果に対する責任は常にプロダクトオーナー自身が保持し続ける[5][7][10]。バックログの内容や優先順位に関する決定は独断またはチームとの協議で行われ、他メンバーへの作業委任も可能とされる[21]。価値あるアウトカムに焦点を当てたプロダクトバックログを作成し、適切なバックログアイテムが作業可能な「準備完了」な状態になるよう維持することが求められる[23]。顧客指向の視点からプロダクトを定義し、バックログを管理する役割として位置づけられている[28][19]。適切な権限が付与されることで、セキュリティ課題や非機能要件をアジャイル開発プロセスへ円滑に統合できるように支援する[29]。多基準意思決定（MCDM）手法やペアワイズ比較、コスト・価値分析、プロトタイプを活用した優先順位付け手法などを通じて、要件の明確化とリリース計画の策定に関与する[22]。また、リリース判断（リリース内容、リリース日、リリース方法）に関する意思決定は通常プロダクトオーナーに委ねられるが、Scrum@ScaleではPOチーム全体の合意が必要とされ、SAFeではPIプランニングを通じてチームやビジネスオーナーも関与するなど、フレームワークによって権限の所在が異なる[21]。大規模なアジャイル ERP 変革プログラム 1 件のケーススタディでは、各スクラムチームのプロダクトオーナー 1 名が、バックログの定義と優先順位付けを行い、完了した作業を受け入れていた[30]。

ステークホルダーとの連携と意思決定の権限

Section titled “ステークホルダーとの連携と意思決定の権限”

プロダクトバックログの決定権を持ち、その意思決定はチーム全体から尊重される必要がある[31]。プロダクトデータを用いて次に何を構築すべきかについて情報に基づいた意思決定を行えるよう支援を受ける協働関係の構築が挙げられている[23]。1人の個人（人間）であり、プロダクトバックログアイテムの明確化や優先順位の決定・調整について全責任を負う[2][3][4][5][6][20][7][8][9][10][31][25][28][18][17][29]。顧客に指名される役割とされる[27]。Scrum チームのメンバー 182 人への調査（自己申告の横断データ）では、プロダクトオーナーが優先順位を決定する権限を持つことは、成功しているという認識に特に影響が大きい要素の一つだった[32]。規模の異なる 10 社の専門家 13 人へのインタビューでは、各チームに 1 人しかいないプロダクトオーナーの問題を挙げた参加者の組織で、異なる職能の最大 7 名が共同で優先順位を決めるビジネス協議会の創設例が語られた[33]。 ニュージーランドの IT 中心企業の小売部門の事例（1 組織、アジャイル専門職 9 人へのインタビュー）では、以前の役職でチームに指示を出してきたバリューストリームオーナーなどのマネージャーが、チームやプロダクトオーナーから異議を唱えられたり、自分たちの決定に反対されたりすることに慣れていなかった[34]。

開発者との対話とスクラムイベントでの役割

Section titled “開発者との対話とスクラムイベントでの役割”

スクラムチームの作業の優先順位を変更・指示できる唯一の存在（権限者）であり[2][3][4][5][6]，他者が直接チームに割り込んだり作業を依頼することは許されない[3][5][6][35]。異なる要求や不統一な作業を開発チームに強制することは誰にも許されない[20]。ビジネスオーナーとして反復の開始時にチームと対話し、その反復で実現する内容やゴールについて合意を形成する[35][18]。スプリントプランニングにおいて完成させるべき機能を提示し[28]、デベロッパーやドメインエキスパートと連携してユビキタス言語やオントロジーを活用して要件の明確化や曖昧さの排除を図る[27]。各スプリント終了時には開発成果物（プロダクトインクリメント）を検査し、受け入れの可否を判断する[27][35]。この際、受け入れ基準の決定に関して、SAFeではプロダクトオーナーが決定権限を持つとされる一方、LeSSなど他のフレームワークではプロダクトオーナーによる一方的な受け入れ基準の決定は推奨されない、または批判される場合がある[21]。スプリントプランニングやバックログリファインメントを通じて開発内容を明確化し方向性を示す責任を持つ[26][22]。加えて、スクラムチームの一員として、ワークフローの定義やその運用の検査・適応に参加する役割も担う[36][11]。英国の大学 IT 部門の 1 チームを調べた単一ケース研究では、プロダクトデモで、プロダクトに関するフィードバックがプロダクトオーナーからチームに与えられた[37]。 STEM-EFにおいて、プロダクトオーナーには要件変更時における開発者への共感や感情的サポート、対立解消の促進といった感情的側面に配慮した行動が求められる[38]。

要件の精緻化・クライアントとの調整・仮説評価

Section titled “要件の精緻化・クライアントとの調整・仮説評価”

スクラムマスターがファシリテートする要件精緻化会議に、アーキテクトや開発者とともに参加し、機能要件と品質要件からなるバックログの精緻化・優先順位付け・見積もりに関わる事例も報告されている[39]。また、仮説の技術計画に関わる作業のうちクライアントとのやり取りが要るものを担い、スプリント終了時の品質管理会議に出席して、タスクの結果の確認や仮説評価の見直しに関与する実践も報告されている[39]。

継続的インテグレーション・デリバリー（CI/CD）環境での実践

Section titled “継続的インテグレーション・デリバリー（CI/CD）環境での実践”

また、リリース初期サイクルのプロトタイピングにおいて品質属性に焦点を当てる際、迅速なフィードバックへ対応するため、プロダクトオーナーとアーキテクトが緊密に連携する実践が有効とされる[40]。さらに、週次リリース等を目指す拡張モデル（Continuous SCRUM等）において、プロダクトオーナーはトリアージ会議の議長を務め、スプリント中にも製品要件やプロダクトバックログの優先順位付けを継続的に実施する役割を担う[40]。

チームの自己組織化の支援と権限の境界

Section titled “チームの自己組織化の支援と権限の境界”

プロダクトオーナーが命令統制型のアプローチを採用し、業務や課題の共有を制限すると、チームの自律性と相互信頼が損なわれるため、そうした阻害要因を回避することが不可欠である[41]。チームメンバーが自発的にリーダーシップを発揮できるようにするためには、過度な介入を控え、自由な活動スペースと権限委譲を提供する姿勢が求められる[41]。また、チームが自律的に決定すべき事項とプロダクトオーナーが決定すべき事項の境界を明確にし、頻繁な再優先順位付けや過剰な作業要求からチームを保護・支援するスクラムマスターとの協調関係を維持することが重要である[41]。

フロー指標の活用とトラッキング・予測

Section titled “フロー指標の活用とトラッキング・予測”

スプリントレビューをはじめとする機会においてスループットなどのフロー指標をレビューし、現実的なデリバリー日程の検討や予測、プロダクトゴールの進捗モニタリングに活かす[36]。プロダクト開発のトラッキングに責任を持つことが明記され[27]、スプリントレビュー等のフィードバックの追跡・管理責任が言及されている[28]。

スケール環境での役割（Nexus・Scrum@Scale・SAFe・LeSS）

Section titled “スケール環境での役割（Nexus・Scrum@Scale・SAFe・LeSS）”

Nexusにおけるプロダクトオーナーは、複数チームで構成される規模においても単一の個人として1人のみ存在する[9]。Nexus全体で共有される単一のプロダクトバックログの内容、順序、利用可能性に全責任を負い、プロダクトゴールを設定し確約する[9][17]。また、Nexus統合チームの一員として活動し、複数チームが統合して生み出す成果物全体の価値の最大化を支援する責任を担う[9]。一方でScrum@Scale[24]では、自チームのスプリントバックログの構成や優先順位付けに責任を持ち、共通バックログからのアイテムの引き出しや独立したバックログアイテムの生成を担う。さらに、大規模環境においては個々のプロダクトオーナーが連携してプロダクトオーナーチームを形成し、全体のビジョンや優先順位を整合させるとともに、チーフプロダクトオーナー（CPO）やエグゼクティブメタスクラム（EMS）と連携して共通バックログに基づき優先順位を調整する[24][11]。また、Scaled Agile Framework（SAFe）導入に関する実証調査においては、プロダクトオーナーは要件エンジニアと共に「プロダクトレベルの役割」として整理されており、同調査におけるプロダクトレベルの役割を担当する回答者は全体の8%となっている[42]。SAFeなどの大規模アジャイルフレームワークでは、顧客があらゆるレベルにおいてプロダクトオーナーなどの役割を通じて関与する体制がとられる[12]。大規模アジャイル変革の事例（Ericsson）では、当初プロダクトオーナーがバックログの優先順位付けに関与できず、プロダクトマネジメントとチームの間のメッセンジャーのような存在になっていた[43]。POチームの設立とプロダクトマネジメントとの責任範囲の明確化によってこの状況は改善し、明確に定義され理解された役割を持つことの重要性が示された[43]。この際、全体の責任を共有する形態や、特定の製品機能を個別に担当する形態が存在する[11]。関係性協調理論（Relational Coordination Theory）の視座からは、PO間やチーム間において「共有された知識」「共通の目標」「相互尊重」、および頻繁かつタイムリーで問題解決志向の「高品質なコミュニケーション」を通じた連携が成果を上げる鍵となる[11]。こうした協調を実践するメカニズムとして、週次PO会議、大判のタスクボードを用いた進捗確認会議、四半期ごとの合宿型ワークショップといった計画的な手法に加え、チャットツールや自席での臨機応変な立ち話などの非計画的な調整手段が有機的に組み合わされる[11]。 さらに、大規模アジャイル開発の事例研究では、プロダクトオーナーが現場組織の従業員や技術アーキテクトとともにビジネスプロジェクトに所属し、業務ニーズの分析を通じてエピックやユーザーストーリーの定義・優先順位付けを主導する体制が示されている[44]。この環境下では、機能チームが実施する「ミニデモ」や直接の対話を通じてデベロッパーと仕様の綿密な認識合わせを行い、閉ループコミュニケーションに基づく迅速なフィードバックループを成立させることが効果的なチーム間協調メカニズムとして機能する[44]。 また、大規模アジャイル開発の組織統制とチーム自律性に関する実証研究では、プロダクトオーナーが単一チーム専従ではなく複数チームを担当し、バックログ管理やタスク割り当てを統括する運用が一般的であることが示されている[45][21]。大規模環境の実態として、エリアプロダクトオーナーや運用プロダクトオーナーといった階層的・専門的な役割分担が見られる[45]。プロダクトオーナーは市場要求や生産性の観点に基づき各チームが取り組むべき機能領域の優先順位を決定し、日次スタンドアップミーティングへの参加やボード確認を通じて進捗を追跡し成果物の受け入れに関与する[45]。さらに、指示統制型のスタイルを排して開発者コミュニティとオープンに対話することで、技術的実現性と真の顧客価値を反映した要件定義を実現する振る舞いも観察されている[45]。 大規模アジャイル変革の文献レビュー（一次文献の大半は体験報告）では、多くの事例でプロダクトオーナーが十分に機能しなかった場合の問題が報告され、その役割に専任の担当者を置くことが不可欠と見なされた[46]。

大規模分散環境での依存関係の管理と調整

Section titled “大規模分散環境での依存関係の管理と調整”

大規模分散アジャイル開発において、プロダクトオーナーは専門知識、要件、タスク割り当て、ビジネスプロセス、エンティティの5つの領域にわたる依存関係を管理する中核的なコーディネーターとして機能する[47]。ステークホルダーの利害を開発チームに伝達し、全体の進捗ステータスを確認した上でチームが進むべき明確な方向性を提示する橋渡し役を務める[47]。また、チームリーダーやテクニカルリードと緊密に連携し、四半期を通じて優先すべき主要な成果（OKRなど）を議論・決定することで、チームが着手すべきタスクの依存関係を整理する[47]。さらに、関連する他チームとの調整を主導してチーム間の連携を維持し、誤解や作業の停滞（ボトルネック）を防ぎながら、開発チームがプロダクト開発に集中し自律性を発揮できる環境を整える[47]。このように、プロダクトオーナーはゲートキーパー、チームの動機づけ、コミュニケーション、優先順位付けといった多面的な責任を担い、開発プロセス全体の円滑化を図る[47]。

教育への適用（eduScrum）

Section titled “教育への適用（eduScrum）”

教育版スクラム（eduScrum）において、プロダクトオーナーは教授、教師、または教育者が担当する[48]。学習対象の管理や教育プロセス全体を監督し、クラスにおける学習目標や解決すべき課題の枠組みを設定して学生をチーム登録へと導く責務を担う[48]。従来の講義型教育のように一方的な作業指示や具体的な解法を細かく指示するのではなく、学生が主体的に取り組むべき主要な概念やゴールを提示し、学習活動を導く役割を果たす[48]。

プロダクト視点での長期的な管理と価値の促進

Section titled “プロダクト視点での長期的な管理と価値の促進”

一時的なプロジェクトではなくプロダクトの視点に立ち、長期間にわたる継続的な管理と改善を担当する[8]。また、顧客の生涯価値（LTV）や総所有コスト（TCO）などを考慮しながらプロダクトの成長を促進する[8]。さらに、反復的かつ漸進的な投資モデルや実験的な手法を通じて、持続可能なビジネス利益と継続的な価値デリバリーを追求することが求められる[23]。

スプリントの中止権限

Section titled “スプリントの中止権限”

プロダクトオーナーは、スプリントを中止する権限を持つ唯一の人物である[3][21]。

現場でのテイラリングと課題

Section titled “現場でのテイラリングと課題”

スクラムガイドでは、プロダクトオーナーは委員会ではなく1人の人間であることが原則とされ[2][7]、2009年版と2010年版ではスクラムマスターとの兼任も禁じられていた（2011年版以降のスクラムガイドにはこの規定は無い）[2][3]。しかし、プロダクトオーナーの役割が実際の現場でどのように実践されるかは組織的要因や開発環境に大きく依存する[18][28]。実際のプロジェクトにおいては、スクラムの各役割の中で最も頻繁にテイラリングされる傾向があり、規範的なガイドラインと実態の間で以下のような様々な形態や課題、反パターンが存在する[49][28][31]。

  • 役割の兼任・追加責務：ビジネスアナリスト、プロジェクトマネージャー、顧客代表、スクラムマスターなどの他職種や他役割をプロダクトオーナーが兼務する事例は多く報告されている[49]。また、教育・研究プロジェクトにおいてリード研究者がPOを務め、ユーザーニーズの代弁とともに研究アジェンダやアクセシビリティ要件の優先順位付けを兼ねるなど、専門性を発揮した兼任形態もある[19]。さらに、教育版スクラム（eduScrum）において教員がこの役割を担い、学習の対象や目標の管理・監督する実践もみられる[48]。
  • 専任POの不在と代理（プロキシ）の配置：専任のプロダクトオーナーを配置せず、代理としてプロキシプロダクトオーナー（代理PO）を設置して運用する形態や、実際のPOが日常的に利用できない場合に備えて代理者を置く形態が見られる[49]。
  • 複数POの配置・存在形態の変容：本来は単一の個人とされる定義に反し、1つのスクラムチーム内に複数のプロダクトオーナーが存在する構成も報告されている[49]。
  • リモート環境におけるコミュニケーション課題：リモートワーク環境下においては、プロダクトオーナーとデベロッパーとの間にコミュニケーションギャップが生じたり、役割の定義に曖昧さが発生したりするといった運用上の不確実性や課題が観察されている[28]。
  • 仕様の不一致と技術知識の不足：粗粒度の要件を作成するものの、高レベルな要件に潜むシステム間の依存関係を見抜く技術的知識が不足している場合、開発チームとの間に仕様の乖離が生じる課題が指摘されている[50]。
  • バックログ優先順位の不一致：大規模環境において複数のプロダクトオーナーが相互の調整無しでバックログアイテムの優先順位を決定すると、フロントエンドとバックエンドの間で開発の足並みが乱れる要因となる[50]。
  • 組織構造と役割の配置に伴う効率性低下：伝統的なIT組織では、プロダクトオーナーの役割がIT部門ではなくビジネスステークホルダーに割り当てられる傾向があり、チーム外部の人間となることで緊急性や開発効率を損なう事例がある[50]。
  • 利害関係者の要求競合と意思決定の遅れ：要件が複数のステークホルダーから提示され優先順位付けで競合することによる「利害関係者の意思決定の遅れ」は、PO関連で唯一の一般的な問題とされる[31]。32.5%の回答者が「頻繁に」「常に」発生すると答えた[31]。表IXの重み付けスコアは41.07%（満点168に対する割合で、組織の割合ではない）である[31]。
  • 権限と役割理解に関する反パターン：「権限のないプロダクトオーナー」と「顧客から委任されたPOが役割を理解していない」は稀である[31]。63%以上の回答者が「ほとんどまたは全く発生しない」と答えた[31]。表IXの重み付けスコアは24.40%と17.86%（満点168に対する割合で、組織の割合ではない）である[31]。また、PO関連の設問は「わからない」という回答が最も多かった[31]。著者らは、回答者がPOの役割を十分に理解していないことの表れでありうると述べている[31]。
  • 意思決定における課題と主観的判断の偏り：コミュニケーションギャップや相反するステークホルダーの優先事項、主観的判断の偏りといった意思決定上の課題に直面しやすい主体としても報告されている[22]。体系的文献レビューと実務家のフォーカスグループによる研究では、プロダクトオーナーの役割は組織レベルの影響を受ける一方で、その役割のパフォーマンスは個人レベルの属性に強く影響されるという内在的な緊張関係が見いだされた[51]。
  • ハイブリッド型の運用での役割の機能：チェコの大企業 4 社の 8 人へのインタビューでは、顧客がプロダクトオーナーを務めるが、その役割は必ずしも正しく機能していなかった[52]。

チームの作業バックログとビジネスオーナーとの関係

Section titled “チームの作業バックログとビジネスオーナーとの関係”

プロダクトオーナーは単に成果物の価値を最大化するだけでなく、開発チームが行うすべての作業（成果物作業および非成果物作業）の価値最適化に責任を持つチームメンバーとして位置づけられる[53]。プロダクトバックログは実質的にチームの「作業バックログ」であり、組織の目標やミッションを所有する「ビジネスオーナー」に対して説明責任を負う構造が指摘されている[53]。また、市場や顧客に向けた戦略的プロダクトマネジメントと、開発チームの日々の作業成果にフォーカスする戦術的なチームプロダクトオーナーの二面性が分析されている[53]。

分類・所属

Section titled “分類・所属”
  • 所属タグ: Product Owner Scrum Role Scrum Core Roles Product Management
  • カテゴリー: Scrum Core

オントロジー上の位置

Section titled “オントロジー上の位置”

Process Constraints (プロセス制約)

Section titled “Process Constraints (プロセス制約)”

SRO (Scrum Reference Ontology) に基づく、この概念に関係する制約です。各制約の括弧内は、その制約が対象とするクラスです。

  • S9 (ProductOwner): プロダクトオーナーはプロダクトバックログを管理しなければなりません。プロダクトバックログを持たない、または優先順位を付けないテーラリングが報告されています。プロダクトバックログのテーラリングの結果として、チームが顧客にとって価値の無い誤った機能に取り組むことになった事例が挙げられています（Özkan & Özcan-Top, 2022）。

脚注

Section titled “脚注”

  1. Development and Validation of a Theoretical Model for Addressing Problems in Agile Meetings: A Systematic Literature Review and a Qualitative Study — 「スプリントプランニングミーティングは、プロダクトオーナー、スクラムマスター、チームが参加する月次のミーティングであり、次のスプリントで何を行うかを議論します。」（訳）（ライセンス: CC BY 4.0） ↩

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

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

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

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

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

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

  8. Scrum Guide Expansion Pack — 「1 人のプロダクトオーナーと 1 つのスクラムチームという構成では、プロダクトオーナー はプロダクトマネージャー、マーケティングディレクター、技術部門責任者などを担うこ ともある。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  9. Nexus Guide — 「プロダクトオーナーはプロダクトバ ックログの結果に責任を持つ。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

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

  11. The Product Owner in Large-Scale Agile: An Empirical Study Through the Lens of Relational Coordination Theory（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  12. Dependencies of Agile Teams – An Analysis of the Scaled Agile Framework — 「顧客は、プロダクトオーナーなどの役割を通じて、あらゆるレベルで関与します。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  13. Managing the requirements flow from strategy to release in large-scale agile development: a case study at Ericsson — 「人的リスクを軽減するため、POチーム全体が連帯して要求に対して責任を負い、開発チームの作業の管理および同期を行う。」（原文: “In order to mitigate personnel risks, the whole PO team is jointly responsible for the requirements and for managing and synchronizing the work of the development teams.”）（訳）（ライセンス: CC BY 4.0） ↩

  14. Requirements engineering challenges and practices in large-scale agile system development — 「スクラムのスプリントはバックログに基づいており、プロダクトオーナーの階層構造によって、製品要件や顧客に見えるフィーチャーがバックログアイテムへと分解される。」（原文: “Scrum sprints are based on a backlog and a hierarchy of product owners breaks down product requirements and customer visible features to backlog items.”）（訳）（ライセンス: CC BY 4.0） ↩

  15. Scrum: A Systematic Literature Review — 「プロダクトオーナーは、顧客の目標と要件に焦点を当てたプロダクト開発に責任を持ち、プロダクトバックログアイテムの定義に加えて、チーム全体の作業を方向付ける。」（原文: “The product owner is responsible for product development focused on customer goals and requirements, and directs the work of the entire team, in addition to defining the product backlog items.”）（訳）（ライセンス: CC BY 4.0） ↩

  16. Collaboration and Uncertainty Management in Agile Software Development: A Systematic Integrative Review and Literature-Based Positioning of CDM — 「顧客またはその代理人、プロダクトオーナー、チームが、課題、価値、アクター、制約、受け入れ条件を確立します。」（訳）（ライセンス: CC BY 4.0） ↩

  17. Do Agile Scaling Approaches Make a Difference? An Empirical Comparison of Team Effectiveness Across Popular Scaling Approaches — 「ステークホルダーとの協調、共有されたゴール、スプリントレビューの質、価値への注力という4つの下位尺度」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  18. A Theory of Scrum Team Effectiveness — 「プロダクトオーナーは、コレクティブ・プロダクト・オーナーシップ（集合的なプロダクト所有権）を促進し、価値に関する共通理解を深めるために、さまざまな戦略を用いることができます。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  19. Integrating Design-Based Research and Agile Scrum for Inclusive Educational Technology Design — 「プロダクトオーナーはステークホルダーを代表してこれらの機能の優先順位を設定し、開発の労力が最も重要な部分に集中するようにします。」（原文: “The Product Owner represents stakeholders to prioritize these features, ensuring that development effort is focused on the most critical ones.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

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

  21. Decision-Making and Team Autonomy in Large-Scale Agile Software Development: An Analysis of Scaling Frameworks（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  22. Decision-Making in Agile Software Engineering: A Systematic Literature Review of Models, Methods, Actors and Lifecycle Contexts（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  23. Agile Coaching Growth Wheel（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  24. Scrum@Scale Guide — 「プロダクトオーナー組織(プロダクトオーナー、チーフプロダクトオーナー、エグゼクティブメタスクラム)は、プロダクトオーナーサイクルの以下の固有コンポーネントの要求を満たすために全体として機能する。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  25. Scrum: An Agile Software Development Process and Metrics — 「プロダクトオーナーはプロダクトバックログを維持・管理する唯一の人物です。」（原文: “The Product Owner is the only person who maintains the Product Backlog.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  26. Agile Software Development and Reuse Approach with Scrum and Software Product Line Engineering — 「プロダクトオーナーは、プロダクトバックログから最も優先順位の高いアイテムを提示する。」（原文: “The Product Owner presents the highest-priority items from the Product Backlog.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2

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

  28. Applicability of the Scrum Methodology in Remote Work Environments and the Challenges Encountered（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

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

  30. Investigating Effort Estimation in a Large-Scale Agile ERP Transformation Program — 「バックログの定義と優先順位付けを行い、完了した作業を受け入れるプロダクトオーナー（PO）1名、ソリューションアーキテクト1名、技術設計および実装を担当するチームメンバー2〜5名、そしてドキュメント作成、機能仕様策定、テストを担当するチームメンバー2〜5名である。」（訳）（ライセンス: CC BY 4.0） ↩

  31. Exploring the Prevalence of Anti-patterns in the Application of Scrum in Software Development Organizations（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11

  32. Mastering scrum with a focus on team maturity and key components of scrum — 「特に影響が大きいのは、計画を適応させる開発者の能力、優先順位を決定するプロダクトオーナーの権限、そしてすべてのイベントが確実に開催されるようにするスクラムマスターの能力である。」（訳）（ライセンス: CC BY 4.0） ↩

  33. What makes effective leadership in agile software development teams? — 「彼らは代わりにプロダクトオーナーシップの機能と目的に焦点を当て、異なる組織の職能からなる最大7名が共同で優先順位を設定するビジネス協議会を創設した。」（訳）（ライセンス: CC BY 4.0） ↩

  34. An exploratory study of sustaining organisational agility — 「これらのマネージャーは、チームやプロダクトオーナーから異議を唱えられたり、自分たちの決定に反対されたりすることに慣れていなかった。」（原文: “These managers were not used to the teams or product owners challenging or disagreeing with their decisions.”）（訳）（ライセンス: CC BY 4.0） ↩

  35. Relationships between Agile Work Practices and Occupational Well-Being: The Role of Job Demands and Job Resources（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  36. Kanban Guide for Scrum Teams 2021（ライセンス: CC BY-SA 4.0） ↩ ↩2

  37. Onboarding: How Newcomers Integrate into an Agile Project Team — 「プロダクトに関するフィードバックは、プロダクトオーナーからチームに与えられた。」（訳）（ライセンス: CC BY 4.0） ↩

  38. STEM-EF: A Scrum Teamwork Effectiveness Model Based on Emotional Factors — 「CR1『スクラムマスターの役割』とCR2『プロダクトオーナーの役割』は、対立が生じた際にリーダーシップがオープンな対話と感情面のレディネスをどのように促進するかを規定している。」（原文: “CR1 – Scrum Master’s role and CR2 – Product Owner’s role specify how leadership facilitates open dialogue and emotional readiness during conflict.”）（訳）（ライセンス: CC BY 4.0） ↩

  39. ArchHypo: Managing Software Architecture Uncertainty Using Hypotheses Engineering — 「このミーティングの中で、POは優先度の高いバックログ項目を詳細に説明し、アーキテクトは特定されたアーキテクチャ上の仮説を提示して、それらの不確実性レベルと影響度を評価した。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  40. Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices — 「そこではプロダクトオーナーがミーティングを進行し、トリアージ委員会を決定する。」（訳）（ライセンス: All Rights Reserved） ↩ ↩2

  41. Leadership Gap in Agile Teams: How Teams and Scrum Masters Mature（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  42. Benefits and Challenges of Adopting SAFe - An Empirical Survey（ライセンス: CC BY 4.0） ↩

  43. Large-scale agile transformation at Ericsson: a case study — 「この問題は調査期間中に対処され、明確に定義され理解された役割を持つことの重要性を示している。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  44. Inter-team Coordination in Large-Scale Agile Development: A Case Study of Three Enabling Mechanisms — 「このプロジェクトには、プロダクトオーナー、部門の現場組織の従業員、開発チームからの技術アーキテクトなどが含まれていました。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  45. Finding the sweet spot for organizational control and team autonomy in large-scale agile software development — 「PO プロダクトオーナー、OPO オペレーティブプロダクトオーナー、APO エリアプロダクトオーナー、L リーダーシップグループ、LM ラインマネジメント、SO システムオーナー、RM リリースマネージャー、PM プロダクトマネジメント、ART アジャイルリリーストレイン」（原文: “PO product owner, OPO operative product owner, APO area product owner, L leadership group, LM line management, SO system owner, RM release manager, PM product management, ART agile release train”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  46. Challenges and success factors for large-scale agile transformations: A systematic literature review — 「多くの事例で、プロダクトオーナーが十分に機能しなかった場合の問題が報告されており、その役割に専任の担当者を置くことが不可欠と見なされた [P12, P14, P30, P39]。」（原文: “Many cases reported problems if the Product Owner did not perform adequately, and it was seen as critical to have a dedicated person in that role [P12, P14, P30, P39].”）（訳）（ライセンス: CC BY 4.0） ↩

  47. Managing Dependencies in Large-Scale Agile（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  48. An Implementation and Evaluation Report of the Active Learning Method EduScrum in Flipped Class（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

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

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

  51. Investigating the role of Product Owner in Scrum teams: Differentiation between organisational and individual impacts and opportunities — 「また、プロダクトオーナーの役割は組織レベルの影響を受けるものの、その役割のパフォーマンスは個人レベルの属性に強く影響されるという事実に起因する、内在的な緊張関係も見出した。」（訳）（ライセンス: CC BY 4.0） ↩

  52. Real-Life Water-Scrum-Fall: Insights from Large Companies in Czech Republic — 「顧客がプロダクトオーナーを務めますが、この役割は必ずしも正しく機能しているとは限りません。」（訳）（ライセンス: CC BY 4.0） ↩

  53. Scrum Guidebook: Analysis of the 2017 Scrum Guide（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3