プロダクトオーナーとプロダクトマネージャーの違いとは？スクラムが「PM」を定義しない理由とPMこそPOになれる理由
「スクラムを導入することになって、PMとしての自分の立ち位置がわからなくなった」
そう感じているとしたら、その感覚は正しいです。スクラムには「プロダクトマネージャー」という役割が存在しません。PMが担ってきた責務は、スクラムではチーム全体に分散されているからです。
ただ、これはPMが不要になるという意味ではありません。むしろ逆です。
PMが積み上げてきた判断力・市場を読む力・組織を動かす力は、スクラムのプロダクトオーナーとして求められる能力と本質的に通じています。「スクラムに乗り換えるなら、PMこそPOとしてチームを導いてほしい」これがこの記事の出発点です。
- スクラムがPMを定義しない設計思想の理由
- 日本の現場で起きている「なんちゃってPO」問題
- PMのスキルがPOに活きる理由
スクラムはソフトウェア開発から生まれたフレームワークですが、今やマーケティング・人事・製造など業種を問わず活用されています。
スクラム導入を検討している経営者の方にも、「自分の立ち位置」を模索しているPMの方にも、参考になる視点をお届けします。
あわせて読みたい
スクラム（Scrum）とは？簡単にわかるスクラム開発のスプリント・役割など5分で解説
スクラムは「人が人を管理する」構造を意図的に排除している
POとPMの違いが分かりにくい理由は、単純です。そもそも比較できるものではないからです。組織の構造そのものが、根本から異なります。
スクラムがなぜPMを定義しないのか、以下の2点で説明します。
- 階層型組織とスクラムの設計思想の違い
- PMの責務はスクラムのどの役割に分散されるか
それぞれの観点を押さえれば、POとPMの関係が整理しやすくなります。
階層型組織とスクラムの設計思想の違い
一般的な開発組織では、PMというマネージャーが存在し、情報は上から下、または下から上へへ伝達され、承認を通して意思決定が進みます。この構造では、判断が遅くなります。
スクラムは、この遅さを構造ごと変えようとして設計されました。「人が人を管理する（マネジメント）」という概念を意図的に排除し、早い意思決定と自律性を最優先にしています。
その結果として、従来PMが1人で抱えていた権限と役割が、スクラムチーム全体（PO・スクラムマスター・開発者）に分散されています。
PMという役割をスクラムから消したのではなく、PMが持っていた機能をチーム全体の役割に組み込んだのです。
スクラムにはマネージャーの役割はありません。マネージャーはトップダウンで管理しますが、アジャイルチームは自己管理します。SMはスクラムというゲームで自己管理の方法を教え、開発者は進捗傾向を自ら報告します。POはチーム内で働き、予算やスコープ、優先順位の決定に責任を持ちます。
アジャイル開発の基本思想やウォーターフォールとの違いについては、以下の記事で詳しく解説しています。
あわせて読みたい
アジャイル開発とは？メリットとデメリットなどアジャイルをわかりやすく解説
PMの責務はスクラムのどの役割に分散されるか
スクラムガイド（2020年版）が定義する役割は以下の3つだけです。PMはその中にいません。
- プロダクトオーナー
- スクラムマスター
- 開発者
PMの責務がどの役割に振り分けられているかを表にまとめました。
| 一般的なPMの責務 | スクラムでの担い手 |
|---|---|
| プロダクトビジョン・戦略の策定 | プロダクトオーナー |
| バックログの管理・優先順位決定 | プロダクトオーナー |
| スクラムの実践支援 | スクラムマスター |
| 技術的な設計・実装 | 開発者 |
一極集中だった判断構造が解消され、チーム内で即座に意思決定が完結します。この構造が、スクラムの速さの源泉です。
POの責務にはビジョンや戦略も含まれます。「戦略は別の誰かが決め、POは実行だけ」という切り分けは、スクラムの思想とは異なります。
あわせて読みたい
プロダクトオーナーとは？役割、やること、必要なスキル
日本の現場に多い「なんちゃってPO」問題
スクラムを導入したはずなのに、意思決定が遅いままの組織があります。たいていの場合、「なんちゃってPO」が生まれています。
よくある2つのパターンを見ていきます。
- 教科書的なPOと日本の現場のギャップ
- 意思決定が止まる組織の共通パターン
自社の状況に当てはまらないか、確認してみてください。
教科書的なPOと日本の現場のギャップ
教科書どおりのPOは、プロダクト全体の責任と権限を持ちます。ビジョンから優先順位の決定まで、一気通貫で判断できる立場です。
日本の縦割り組織では、この権限が分割されやすい構造になっています。よく見られるのは、開発現場に近いリーダー層が「PO」を名乗っているのに、最終的なビジネス要件の決定権はビジネス側が握っているパターンです。
POがビジネスサイドを巻き込めず、機能やモジュール単位の調整役にとどまってしまいます。
スクラム開発の現場で実際に起きている悩みとその取り組みについては、以下の記事も参考にしてください。
あわせて読みたい
【寄稿】スクラム開発の現場でよくある悩みに対する3つの取り組み
意思決定が止まる組織の共通パターン
このPOは、チームに優先順位を伝えられません。「ビジネス側に確認してから」という言葉がスプリント（1〜4週間の固定された開発サイクル）のたびに飛び交い、意思決定が止まります。
スクラムを入れたのに、開発スピードがむしろ落ちてしまいます。
最も効率的なのは、プロダクトオーナーやスクラムマスターの役割を開発者全体で共有し、全員が開発者として動くことです。目的は迅速な意思決定であり、チームが待たされない状態を作ることが理想です。
「うちにPOが必要か？」と迷ったら、「誰がプロダクトの価値と優先順位の決定に責任を持つか」を先に確認してください。その答えが出れば、POを担うべき人物像も見えてきます。
答えがすぐに出ない場合は、スクラムの導入を急ぐのではなく、まずこの責任の所在をチームや経営層と話し合うところから始めてみてください。
POをプロダクト全体の判断者として配置するには、役割と責務を正しく理解しておく必要があります。
PMのスキルはPOに活きる
「スクラムを導入することになったが、PMとしての自分はどこへ行けばいい？」
答えを先に言います。PMが持つスキルは、スクラムのプロダクトオーナーとして直接活かせます。
その理由を2つの視点から説明します。
- POとPMに求められるコアスキルは重なる
- 開発チームの近くで判断できるかが成否を分ける
PMの経験をPOとしてどう活かせるか、具体的に見ていきましょう。
POとPMに求められるコアスキルは重なる
POとPMに求められるコアスキルは、大部分が重なります。市場を読む力、ステークホルダーと調整する力、数字と事業の両面で優先順位を判断する力。PMが日常的に発揮してきた能力が、POの責務に直結します。
「PMの方がより高度なスキルが必要」という見方は正確ではありません。違いは能力の高低ではなく、「どの枠組みの中で、誰に向けて何に責任を持つか」という文脈の差です。
POにはスクラムの枠組みやプロダクトバックログ管理の実務が新たに加わりますが、判断の土台となるスキルは共通しています。
プロダクトの改善に必要な作業を優先順位順に並べたリスト。チームが「次に何をすべきか」を迷わず判断するための情報源として機能する。
あわせて読みたい
プロダクトバックログの優先順位の付け方
PMとして事業全体を見てきた経験は、POの判断精度を高めます。ビジネスと開発の言葉を両方持っていること自体が、スクラムのチームにとって大きな強みです。
PMが日々の業務で鍛えてきた「事業数値と開発コストのバランスで判断する」感覚は、POとしてバックログを並べ替える場面で直接活きるでしょう。
開発チームの近くで判断できるかが成否を分ける
PMがPOとして機能するうえで、スキル以上に問われるのが「チームとの距離感」です。スクラムのPOは、開発チームと時間の半分を過ごすのが理想です。
「この仕様はどうする？」という問いにその場で答えられる距離にいるか。判断を持ち帰らずに即断できるか。この物理的・心理的な近さが、スプリントの停滞を防ぐ最大の要因になります。
プロダクトバックログ管理で最も大切なのは、チームが「次に何をすべきか」を迷わない状態を作ることです。私が見てきた優秀なプロダクトオーナーは、アイテムの「なぜ」を明確に書き、チームが自律的に判断できる情報を常に提供していました。
PMが持つ事業判断の速さと精度は、チームの近くで使ってこそ活きます。市場側との調整を得意とするPMがPOに転換する際、「判断の場所をチームの近くに移す」という意識の切り替えが、最初の実践的な変化になります。
あわせて読みたい
プロダクトバックログの優先順位の付け方
プロダクトオーナーとプロダクトマネージャーが共存するときの役割設計
すでにPMが配置されている組織にスクラムを導入すると、POとPMの責任範囲が重複するケースが出てきます。
共存させるときに押さえておきたい点は以下のとおりです。
- 軸足の違いで責任の所在を整理する
- POとSMの兼任は避けたほうがよい
役割の境界線をどう引くか、確認していきましょう。
軸足の違いで責任の所在を整理する
大切なのは「どちらが最終判断を下すか」を事前に決めておくことです。方針の承認やリリース判断など、責任の所在を曖昧にしたまま進めると、前述の「なんちゃってPO」問題が起きやすくなります。
POの軸足は開発チームと顧客の間に立つことです。組織にPMがいる場合、事業・市場側の調整を担うケースが多いですが、PMの肩書きはスクラムの役割定義には含まれません。
たとえば「プロダクトの優先順位はPOが最終判断する」と明確にしておくだけでも、日常の判断はスムーズになります。
POとSMの兼任は避けたほうがよい
POとスクラムマスター（SM）の兼任は、避けることをおすすめします。POは「何を作るか」を決める立場で、SMは「チームを守る」立場です。リリース日を優先したいPOと、チームの負荷を下げたいSMでは判断が対立しやすくなります。
POとPMの兼任は状況によって機能しますが、POとSMは別の人が担うのが安全です。小規模チームでリソースに限りがある場合でも、POとSMだけは分けて配置してください。
POとSMの兼任を避けるべき理由は明確です。POは「これを作ってほしい」と優先順位を決める立場であり、SMは「チームが持続可能なペースで働けているか」を守る立場。この2つは時に利害が対立します。POが「今週中に絶対リリースしたい」と言っても、SMは「チームが疲弊している」と止める必要があるのです。
ただし、チームが十分に成熟した先の理想像は「全員が開発者であり、POであり、SMでもある状態」です。意思決定の待ち時間がなくなり、全員がプロダクトづくりに参加するため、コスト効率も高い状態です。
これは「いますぐ目指すべきゴール」ではなく、チームの自律性が育った先に見えてくる姿です。導入初期の段階では、POとSMを別の人が担い、役割の境界線を明確にしておくのが現実的でしょう。
あわせて読みたい
スクラムマスターとは？役割、やること、PMとの違い
プロダクトオーナーとプロダクトマネージャーに関するよくある質問
最後に、プロダクトオーナーとプロダクトマネージャーに関するよくある質問に回答します。
プロジェクトマネージャー（PjM）との違いは何ですか？
プロジェクトマネージャー（PjM）は、プロジェクトを計画どおりに完遂することに責任を持つ役割です。POが「プロダクト」の成功を目指すのに対し、PjMは期日・予算・品質の範囲内でプロジェクトを終わらせることに集中します。
時間軸にも違いがあり、PjMの責任はプロジェクト期間に限定されますが、PMやPOはプロダクトのライフサイクル全体に関わり続けます。スクラムにPjMというロールは存在せず、従来PjMが担っていた進捗管理やリスク管理はチーム全体に分散されています。
スクラムマスター（SM）との違いは何ですか？
POが「なぜ・何を作るか（Why・What）」に責任を持つのに対し、SM（スクラムマスター）は開発プロセスの最適化やチームの環境づくりを担当します。
スクラムの実践を支援し、進行の妨げになる障害を取り除くコーチとして動くのが特徴です。POとSM、そしてPMが同じ組織にいる場合は、それぞれの担当領域を事前に整理しておくと意思決定の混乱を防げます。
SMの必要性については以下の記事で説明しているので、参考にしてください。
あわせて読みたい
スクラムマスターはいらない・不要？失敗するケースとは？
まとめ
スクラムにPMが存在しないのは、PMを排除したからではありません。PMが持っていた機能をチーム全体の役割に組み込み、意思決定を速くするための設計です。
だからこそ、PMのスキルはスクラムのPO業務に直接つながります。ビジネスと開発の両方の言葉を持ち、プロダクト全体の判断者としてチームの近くで動けるPOの存在が、スクラム導入の安定に大きく影響します。
日本の組織では「なんちゃってPO」が生まれやすい構造があります。スクラムを導入する前に、誰がプロダクト全体の判断者になるかを決めておくことが、最初の一手です。
プロダクトオーナーの実践力を身につけたい方は、CSPO認定プロダクトオーナー研修がお勧めです。世界のアジャイル現場を知るジョー・ジャスティスから直接学べます。
