第9章プロダクトオーナー

本章では、スクラムの3つの役割のひとつである「プロダクトオーナー」の目的と、チームやステークホルダーとの関わり方について説明します。

9.1 概要

プロダクトオーナーは、組織のステークホルダー、顧客、ユーザーが持つニーズや優先順位について、彼らの代理として行動する責任があります。

プロダクトオーナーは、開発チームに何を構築するのかを伝え、受け入れ条件を明確にします。
プロダクトマネージャーとしてのビジョンを持つことと、ビジネスアナリストやテスターのような詳細なレベルの実務を同時にこなすことが求められます。

9.2 主な責任

プロダクトオーナーの主な責任は多岐にわたります。

経済性の管理

プロダクト開発中に生じる経済的（スコープ、納期、予算、品質などのトレードオフ）な意思決定を継続的になさる責任があります。
リリースレベルやスプリントレベルで、投資収益率（ROI）が高まるように立ち回ります。

プランニングへの参加

ポートフォリオプランニング、プロダクトプランニング（エンビジョニング）、リリースプランニング、スプリントプランニングという、各種プランニングの重要な参加者です。

プロダクトバックログのグルーミング

プロダクトバックログアイテムの作成、洗練、見積もり、並べ替え（優先順位付け）を行う責任があります。プロダクトオーナーだけで作業を行うわけではなく、チームと協力して実施します。

受け入れ条件の定義と検証

プロダクトバックログアイテムの受け入れ条件を定義し、スプリントプランニングの際などにチームに協力して条件を明確にします。
スプリントレビューまでに、実装された機能が受け入れ条件を満たしているかを検証する責任があります。

開発チームとの協力

開発チームと密接に協力し、日々コミュニケーションを取ります。チームからの質問に答え、フィードバックを与え、方向性を指示します。

ステークホルダーとの協力

内外のステークホルダー（経営陣、営業、顧客、ユーザーなど）の声を代表し、彼らの要望をまとめて交渉し、合意形成を図ります。

9.3 特性とスキル

プロダクトオーナーに求められる重要な特性は以下の通りです。

ドメインスキル: プロダクトのビジョンをまとめ、チームをリードするビジョナリーであること。ビジネスとドメインの深い知識が求められます。
対人スキル: 「顧客の声」になり、優れたコミュニケーターとしてステークホルダーやチームと対話できること。
意思決定力: 情報が不十分な状況でも、ビジネスニーズと技術的な実現性のバランスを取りながら、適切なタイミングで難しい意思決定を下せること。
説明責任力: プロダクトの投資収益率（ビジネス結果）に対して説明責任を持ちます。また、なぜその優先順位や意思決定になったのかをチームやステークホルダーに説明できなければなりません。

9.4 一日の様子

プロダクトオーナーの責任範囲を把握すれば、それが片手間の仕事（パートタイム）でできるものではないことが分かります。

各種プランニング、バックログのグルーミング、開発チームとの協力、ステークホルダーへの対応など、絶え間ない活動が求められます。
1人の人間が複数のスクラムチームのプロダクトオーナーを兼任するのは困難であり、専任であることが望ましいとされています。

9.5 誰がプロダクトオーナーになるべきか？

スクラムを導入していない組織には「プロダクトオーナー」という役職は存在しません。そのため、既存の役割の中から適切な人物を割り当てる必要がありますが、プロダクトの種類によって適任者は異なります。

社内開発: 自社内で使用するシステムの場合、IT部門のマネージャーではなく、そのシステムによって直接恩恵を受ける「ビジネス部門の代表者（または社内ユーザーの代表）」がPOを務めるべきです。
商用開発: 社外の顧客に販売するソフトウェアの場合、「プロダクトマネージャー」や「プロダクトマーケティングの担当者」など、市場のニーズとビジネスの採算に責任を持つ人物がPOに適しています。
外部委託開発（受託開発）: 開発を外部に委託する場合、要件の優先順位を最も理解している「依頼主（顧客）側の代表者」がPOを務めるのが理想的です。
コンポーネント開発: アーキテクチャや再利用可能なコンポーネントのみを作るチームの場合、技術的な優先順位を判断できる「シニアアーキテクト」や「技術リーダー」がPOになることがあります。

9.6 その他の役割との組み合わせ

1人の人間が複数のスクラムチームのPOを兼任することは、キャパシティの許す範囲であれば可能です。

しかし、以下の兼任は避けるべきです。

POとスクラムマスターの兼任
POと開発チームメンバーの兼任

これらの役割は目的が異なるため、1人が兼任すると「利害関係の衝突（利益相反）」を引き起こし、機能不全に陥るリスクが非常に高くなります。

9.7 プロダクトオーナーチーム

スクラムの原則では「POは常に1人」ですが、大規模なプロジェクトでは1人のキャパシティを超えてしまうため、チーム体制をとることがあります。

プロダクトオーナープロキシ（代理人）の危険性: 権限のない「プロキシ（代理人）」を立てても、結局は真のPOの決裁を待つことになり、承認プロセスが長引いてボトルネックになるだけなので推奨されません。
チーフプロダクトオーナー: 複数のチームが関わる大規模開発では、全体の方向性を定める「チーフプロダクトオーナー」を頂点に配置し、その下で各チームのPOが動く階層構造を作ります。重要なのは、合議制（委員会）にするのではなく、各レベルの最終決定権は常に「1人のチーフ」が持つという原則を守ることです。

9.8 終わりに

本章では、プロダクトオーナーという役割が、単なる要件定義の担当者ではなく、ビジネス上の意思決定を行い、ROIを最大化するための「ミニCEO」のような存在であることを学びました。

次章（第10章）では、このPOや開発チームが能力を最大限に発揮できるように支援し、障害を取り除く「スクラムマスター」の役割について詳しく見ていきます。

QAエンジニアとPOの連携: 受け入れ条件の定義や検証（9.2）は、品質保証の観点と極めて密接に関わります。POが書いた要件に対してQA目線で「このエッジケースの挙動はどうしますか？」とプランニング段階で問いを投げかけることで、手戻りを未然に防ぎチーム全体のベロシティ向上に大きく貢献できます。
役割の兼任を避ける・帽子を被り直す: 個人開発において、「要件の決定（PO的役割）」と「実装（開発者）」を一人で担う場合、「実装が面倒だからこの要件は削ろう」という技術的妥協がビジネス価値を損なう利益相反が生まれやすくなります。自分が今「POの帽子」を被っているのか、「開発者の帽子」を被っているのかを、意識的に切り替えることが重要です。

第9章 プロダクトオーナー