Product OwnerとProduct Managerの違いを徹底比較

Product OwnerはScrum Guideが定義する責任であり、Product Managerは規格を持たない職種名です。そのため、この名称を使うほぼすべての企業で意味が異なります。単純な「誰が何をやるか」の一覧ではなく、この非対称性こそが、「Product OwnerとProduct Managerの違い」が賢い人たちをつまずかせ続ける本当の理由です。

このテーマの記事の多くは、2つの役割が対等な立場にあり、仕事の分担が違うだけであるかのように、左右対称の比較表を作ります。実際はそうではありません。一方は、2020年以降コアな内容が変わっていない短いフレームワーク文書に由来します。もう一方は、VP of Productが前四半期に求人票へ書いた内容に由来します。この2つの事実を切り分ければ、残りの混乱、つまりロードマップを誰が持つのか、誰が顧客と話すのか、誰がどこへ報告するのか、1つの役割で足りるのか両方必要なのか、といったことは、ずっと整理しやすくなります。

Key Facts

• 2020年版Scrum Guideは、Product Ownerは「Scrumチームの仕事から生まれるプロダクトの価値を最大化することに責任を負う」と述べ、Scrumチームは「通常10人以下」と付け加えています。
• 「Product Owner」はScrum Guideという1つの文書に由来します。「Product Manager」はいかなる標準化団体にも由来せず、雇用主ごとに独自に定義されています。
• エンタープライズ規模では、Scaled Agile Frameworkが意図的に両者を分けています。Product Managementがプログラムレベルのバックログと戦略を持ち、Product Ownerがその下で1チームのバックログを持ちます。
• Product ManagementとProduct Ownerが直接足並みを揃える必要があるSAFeのPI Planningは、Agile Release Train全体を対象に、8〜12週間ごとに2日間のイベントとして開催されます。

Scrum Guideが実際に定義するProduct Ownerとは

まずここから始めます。この比較の中で、議論の余地がない唯一の部分だからです。2020年11月に最後に改訂されたScrum Guideは意図的に短く、はっきりとこう述べています。「Product Ownerは、Scrumチームの仕事から生まれるプロダクトの価値を最大化することに責任を負う」。これが仕事のすべてを1文にしたものです。この役割についてGuideが述べるそれ以外のことは、この責任が日々どう発揮されるかを説明しているにすぎません。

Guideは、Product Ownerが集団ではなく1人であることを明確にしています。「Product Ownerは1人であり、委員会ではない」。続けてこう述べます。「Product Ownerは、Product Backlogにおいて多くのステークホルダーのニーズを代表してもよい。Product Backlogの変更を望む人は、Product Ownerを説得することでそれを行える」。この1行は、見た目以上に重要です。Product Ownerは、会議で最も声の大きい人の言うことを通すだけの通過点ではない、ということです。ステークホルダーはプロダクトバックログを直接編集することはできません。責任を負う1人に主張を伝え、その人が決めるのです。

Guideによれば、Product Ownerの具体的な職務には、プロダクトゴールの策定と共有、バックログ項目の作成と共有、バックログの順序づけ、そしてバックログが透明で、チーム全員に理解されている状態を保つことが含まれます。このリストに何がないかに注目してください。採用、予算の管理、市場戦略、価格設定、Go-to-Market計画はありません。Scrum Guideは、開発チームが仕事をどう組織するかのフレームワークです。プロダクトを運営するビジネス面についてはほとんど何も語りません。それは最初からGuideの役割ではなかったからです。

だからこそ、Product Ownerは、Guideによれば「通常10人以下」で意図的に小さく保たれ、固定長のスプリントで動くScrumチームの内側に位置します。この役割は、その構造の文脈の中でしか存在しません。Scrumを取り除けば、「Product Owner」は定義されたものではなくなります。誰かがScrumから借りてきて、別の働き方に貼りつけた肩書になるのです。多くの企業で実際に起きているのが、まさにこれです。

Product Managerが実際にやること

ここが人々をつまずかせる部分です。「Product Manager」に相当する文書は存在しません。Scrum Guideが「Product Owner」を所有しているような形で、この肩書を所有する標準化団体はありません。Product Managerの実際の仕事は、会社、業界、プロダクトの成熟度、そしてその人が誰に報告するかによってまったく変わります。

とはいえ、会社を問わず、ほぼすべてのProduct Managerの求人票に現れる責任がいくつかあります。市場と顧客の理解、プロダクト戦略とロードマップの設定、限られたエンジニアリングの能力に対して何を作るかの優先順位付け、そして機能が予定どおり出荷されたかだけでなく、プロダクトが商業的に成功するかどうかへの責任です。この区別について最も広く読まれている論者の一人、Silicon Valley Product GroupのMarty Caganは、優れたプロダクトの仕事には「顧客への深い理解」と「テクノロジーを顧客の課題解決に適用する能力」が組み合わさって必要であり、この2つのスキルセットを別々の人に分けると、通常は両方が弱くなると主張しています。

実際には、Product Managerの1日は、バックログのグルーミングというより、顧客との通話、競合調査、価格に関する会話、経営陣とのロードマップレビュー、エンジニアリングリードとのスコープ交渉の間を行き来するものに近くなります。Scrum Guideによれば、Product Ownerが1チームのバックログに責任を負うのに対し、Product Managerは通常、プロダクトライン全体の成果、つまり採用、売上、リテンション、あるいはビジネスが重視する指標に責任を負います。Product Managerが作るステークホルダー分析マトリクスは、デリバリーチームの外側、つまり営業、法務、財務、そしてロードマップに資金を出す経営陣にまで及ぶ傾向があります。

標準がないため、Product Managerの職務記述書は範囲が大きく異なります。5人のスタートアップでは、「Product Manager」は市場調査、仕様書の作成、スプリントプランニングの運営、サポートチケットへの対応をすべて同時にこなすことを意味するかもしれません。従業員2,000人のエンタープライズでは、Product Managerは1つの機能領域だけを担当し、バックログには直接触れず、1週間の大半をステークホルダーとの調整会議に費やすかもしれません。2人は同じ肩書を持ちますが、仕事はほとんど重なりません。

Product Owner vs Product Manager: 並べて比較

肩書を比べる前に、責任、働く文脈、権限という観点から2つの役割を読み解いてください。

どの成果物を誰が持つか

混乱を整理する有効な方法は、肩書の比較をやめて、実際に各成果物を誰が保持しているかを比べることです。

「誰がロードマップを持つのか」と「誰がスプリントバックログを持つのか」に、2つの異なる名前で答えられない組織は、おそらく1人が1つの肩書で両方の仕事をしています。それはよくあることで、必ずしも問題ではありません。問題になるのは、誰もそれが起きていることに気づいていないときです。

実際に出会う4つの組織パターン

企業は「Product Owner」と「Product Manager」を教科書どおりの明確な役割として実装しているわけではありません。実際には、次の4つのパターンのいずれかを目にし、それぞれに予測可能な失敗パターンがあります。

パターン1: 1人が両方の帽子をかぶる

スタートアップや小規模なプロダクトチームで最も一般的な構成です。1人が「Product Manager」の肩書を持ちながら、バックログのグルーミング、スプリントプランニングへの参加、すべてのスプリントレビューへの出席など、Scrum GuideがProduct Ownerに割り当てることをすべてこなします。

これはある程度までうまく機能します。通常は、1つのプロダクト、1〜2つのScrumチーム、そしてフルタイムの戦略的な注意を必要とするほど速くは変わらない市場です。仕事の戦略面(顧客調査、ロードマップ、価格設定)と戦術面(バックログのリファインメント、ストーリーの作成、スプリントレベルのトレードオフ)が、同じ週の同じ時間を奪い合い始めると破綻します。その人は、チームをおろそかにしてバックログが古くなりバックログリファインメントのセッションが飛ばされるか、市場をおろそかにして競合が動く間にロードマップが古くなり、顧客のフィードバックが読まれないまま溜まっていくか、のどちらかになります。

パターン2: Product OwnerがProduct Managerに報告する

1つのプロダクトラインのもとで複数のScrumチームを運営する中規模企業でよく見られます。Product Managerが戦略を設定してロードマップを持ち、1人以上のProduct Ownerがそれぞれ特定のチームのバックログを運営して、ロードマップをスプリント規模の作業に落とし込みます。

これは、後述するSAFeがスケールで正式化していることの、本質的には非公式版です。戦略と実行の間の引き継ぎが本当に双方向である場合にうまく機能します。Product Ownerがスプリントの実行から学んだことをProduct Managerに伝え返し、Product Managerがロードマップを壁越しに放り投げるだけにならない場合です。そのフィードバックループが一方向にしか流れず、Product Ownerが純粋な指示待ちになると破綻します。

パターン3: Product Ownerが市場への権限を持たない、デリバリー側の代理人

これは、Caganの批判が直接的に向けられているパターンです。多くの場合「Product Manager」の肩書を持つ1人が、顧客と市場とのすべての接点を持ちます。別の人である「Product Owner」はバックログを管理して開発チームと話しますが、顧客と話すことはなく、戦略への発言権もありません。そのProduct Ownerは、チームに整ったバックログ項目を供給し続けるためだけに存在します。

ここでの失敗パターンは特有です。プロダクトを実際に形づくる、その場その場の優先順位付けの判断を下す人が、それを適切に下すための顧客のコンテキストを持っていません。Caganは、この種の分割は、統合されているべき仕事を分けてしまうものだと主張します。良いバックログの判断は、良い戦略の判断と同じ顧客理解に依存するからです。このパターンを運用しているチームは、バックログは形式的には健全に保たれているのに、プロダクト自体は顧客が実際に必要とするものから離れていくことによく気づきます。

パターン4: Product Managerはいるが、Product Ownerはまったくいない

Scrumを運用していない企業でよく見られます。Kanban、継続的フローモデル、あるいは場当たり的なやり方のいずれを使っていても同じです。Product Managerはいます。その責任が結びつくScrumチームがないため、「Product Owner」はいません。

これは直すべき欠落ではありません。Scrum Guideの正しい読み方です。Product Ownerの役割はScrumの中にしか存在しません。チームがScrumを運用していないなら、Product Ownerを発明する必要はありません。優先順位付けをしている人、多くの場合はProduct Manager自身、ときにはデリバリーリードが、呼び名にかかわらず自分の権限について明確である必要があります。

SAFeはProduct ManagementとProduct Ownerをどう分けるか

組織が数チームを超えてScrumチームを増やすと、上記の非公式なパターンはうまく機能しなくなる傾向があります。そこでScaled Agile Frameworkが関わってきます。両方の役割を明示的に名づけ、その間に明確な線を引く数少ないフレームワークの1つだからです。

SAFeはProduct Ownerを、「チームバックログが顧客とステークホルダーのニーズに沿っていることを確実にすることで、チームが届ける価値を最大化することに主たる責任を負う、Agileチームのメンバー」と定義しています。この役割はチームレベルにあり、Agile Teamごとに1人で、Scrum Guideの記述に近い仕事をします。

SAFeにおけるProduct Managementは、別個のプログラムレベルの機能です。「顧客のニーズを満たす、望ましく、実現可能で、持続可能なソリューションを定義することに責任を負う機能」とされます。Product Managementはプログラムバックログ(チームレベルのストーリーではなくフィーチャー)を持ち、Agile Release Train全体にわたって優先順位を設定し、Business OwnerやSystem Architectと直接協働します。SAFe自身のドキュメントは、Product Ownerが「より大きなProduct Management機能の一部として」機能すると明言しています。これは、上のパターン2が非公式に行っていることの正式な言い方です。戦略は実行の上にあり、両者には単なる近さではなく、定められたつながりが必要です。

そのつながりが最も目に見える形で現れるのが、PI Planningです。Agile Release Trainのすべてのチームが、Product Managementとともに、2日間かけて次の8〜12週間の仕事の足並みを揃えるイベントです。Product Managementが持つプログラムレベルの戦略と、Product Ownerが管理するチームレベルのバックログが、同じ部屋で調整されなければならない、定期的に訪れる唯一の機会です。また、Product Managementは通常、エピック、フィーチャー、ストーリーの違いで述べた分担も担います。エピックとフィーチャーはプログラムレベルにあり、Product Ownerがスプリントの中で管理する単位であるストーリーはチームレベルにあります。

実務上の要点はこうです。スケールした環境では、「Product Owner vs Product Manager」は、どちらの肩書が上かという議論ではなくなり、バックログ階層のどのレベルに責任を負うのかという問いになります。SAFeは、この記事の他の場所にある曖昧さを解消するわけではありません。1つの調整されたトレインのもとで複数のScrumチームを運用する組織に対して、特にそれを解消します。それはまさに、パターン1(1人が両方の帽子)が持続できなくなる状況です。

スキルとキャリアパス

2つの役割は、同じ人がキャリアの初期に両方の仕事をこなす場合でも、異なる強みが報われます。

2つの間のキャリアパスは、求人サイトが示すほど直線的ではありません。戦略を担えるだけのドメイン知識と顧客の知識を築いたところで、Product OwnerからProduct Managerへ移る人は大勢います。SAFeの構造が暗示する自然な流れです。同じくらい多くの人が、意図的に逆方向へ移ります。ステークホルダーマネジメントから離れてチームにもっと近づきたい経験豊富なProduct Managerが、特に「Product Manager」がプロダクト戦略よりもプロジェクトの調整に寄ってしまった企業で、あえてProduct Ownerの役割を選ぶことがあります。

これら2つの肩書の報酬データは、引用するには本当に信頼できません。公開されている給与の集計サイトは、同じ市場の同じ肩書について数万ドルも互いに食い違っています。これは本物のシグナルではなく、自己申告で管理されていないサンプルから予想される結果です。オンラインで見かける単一の数字は十分に疑ってかかり、代わりに自社の社内グレード制度を見てください。

チームが実際にどちらの役割を必要としているかの決め方

次の質問に順番に答えてください。

よくある間違い

職務記述書が実際にはProduct Managerの仕事なのに、「Product Owner」を採用する。 これは頻繁に起こります。企業が「Product Owner」の求人を出していても、実際の責任には市場調査、価格設定へのインプット、ロードマップの所有が含まれており、そのどれもScrum Guideはこの役割に割り当てていません。候補者はバックログ中心の仕事を期待して来ますが、採用された目的でも、グレードの対象でもない戦略的な仕事をすることになります。

肩書が会社をまたいで互換だと思い込む。 ある会社のProduct Ownerは、ロードマップの完全な権限を持っているかもしれません。別の会社のProduct Managerは、権限がまったくなく、1日中チケットを書いているかもしれません。名刺から相手の実際の仕事の範囲を知っているつもりにならないでください。何を担当しているのかを尋ねましょう。

Product Ownerを純粋な指示待ちにしてしまう。 Scrum Guideは、Product Ownerは事務的ではなく責任を負う存在だと明言しています。Product Ownerの仕事が、Product Managerの決定を、その決定がどうあるべきかへの意見なしに、整ったバックログ項目へ中継することに縮小されるなら、それはパターン3の失敗パターンを、意図的に組織図に組み込んだものです。

役割の分離が遅すぎる。 チームは、両方の仕事を担う人が目に見えて燃え尽きるまで、戦略と実行を分けるのを待つことがよくあります。より良いシグナルは燃え尽きではなくバンド幅です。バックログリファインメントとロードマップ計画の両方が急いで片づけられているなら、それが仕事を分けるタイミングです。士気がすでに崩れてから6か月後ではありません。

SAFeの調整の仕組みなしにSAFeの構造だけをコピーする。 一部の組織は、2つのレベルが対話し続けるためのPI Planningのようなものを導入せずに、「上にProduct Management、下にProduct Owner」という分担だけを採用します。構造だけでは足並みは揃いません。それを強制する仕組みが揃えるのです。

この比較から1つだけ持ち帰るなら、その非対称性そのものにしてください。「Product Owner」と「Product Manager」の間にきれいな行ごとの対応を探しに行かないでください。対応の片側は文書に根ざしていて、もう片側はそうではないからです。チームが実際にカバーすべき責任が何なのかを見極めてください。スプリントレベルのバックログの健全性なのか、プロダクトレベルの戦略なのか、その両方なのか。そのうえで、1人でそれだけを正直に担えるのか、それとも分ける時期なのかを判断するのです。