コトラ（広報チーム） 
PdMとPMは、いずれもプロダクト開発に関わる重要な役割です。しかし、両者は似た略称で呼ばれることがあり、企業ごとに担当範囲も異なるため、混同されやすい職種でもあります。
基本的には、PdMは「どのような価値を提供するプロダクトをつくるか」に責任を持ち、PMは「決められた目標を、期限や予算の条件内でどう実現するか」に責任を持ちます。本記事では、役割、責任範囲、成果指標、キャリアの考え方まで整理します。
PdMとPMの違いをひとことで整理する
PdMはプロダクトの価値と成長に責任を持つ役割
PdMは、プロダクトマネージャーを指します。顧客や市場の課題を把握し、プロダクトが提供すべき価値を考え、成長の方向性を決める役割です。
担当範囲は、企画、戦略、開発の優先順位付け、リリース後の改善まで幅広くなります。プロダクトをリリースすること自体ではなく、利用者に選ばれ続け、事業に成果をもたらす状態をつくることが主な目的です。
PMはプロジェクトの完了と進行に責任を持つ役割
PMは、一般的にプロジェクトマネージャーを指します。決められた目標、範囲、期限、予算の条件を踏まえ、プロジェクトを計画どおりに進める役割です。
PMは、進捗、品質、コスト、人員、リスクなどを管理します。開発が遅れそうな場合は原因を把握し、優先順位の変更、人員配置、スケジュールの見直しなどを行います。チームが継続して成果を出せる状態を整えることが重要です。
プロダクトとプロジェクトの違い
プロダクトは、顧客に提供する製品やサービスそのものです。Webサービス、業務システム、スマートフォンアプリ、SaaSなどが該当します。プロダクトはリリース後も改善を続け、長期的に利用者や事業の成果を高めていきます。
一方、プロジェクトは、特定の目的を達成するために期間を区切って進める活動です。たとえば、新機能の開発、システム移行、アプリのリニューアルなどが該当します。プロジェクトには開始と終了があります。
PdMはプロダクト全体を長期的に見ます。PMは、プロダクト開発に含まれる個別プロジェクトを含め、定められた範囲の活動を成功させることに重点を置きます。
呼び方だけでは役割を判断できない理由
PdMとPMの役割は、企業規模、事業形態、開発手法、組織体制によって変わります。PMという名称でも、プロダクト戦略や機能の優先順位付けまで担う場合があります。反対に、PdMという名称でも、開発計画や進行管理の比重が大きい場合があります。
そのため、職種名だけで判断するのではなく、次の点を確認することが重要です。
- 何の成果に責任を持つのか
- どの指標で評価されるのか
- 何を決定できる権限があるのか
- 顧客、市場、開発チームとどの程度関わるのか
- 企画からリリース後の改善まで、どこまで担当するのか
PdMとPMの役割・責任範囲を比較する
目的と責任範囲の違い
PdMの目的は、顧客にとって価値のあるプロダクトをつくり、事業として成長させることです。市場や利用者の変化を捉えながら、何をつくるべきか、どの課題を優先すべきかを決めます。
PMの目的は、プロジェクトを計画どおりに完了させることです。求められる品質を満たしながら、予算と納期を管理し、関係者が合意した目標を実現します。
PdMが主に問うのは「なぜつくるのか」「何をつくるのか」です。PMが主に問うのは「どのように進めるのか」「いつまでに実現するのか」です。
主な業務と日々の判断の違い
PdMは、顧客へのヒアリング、利用データの分析、市場調査、競合の確認などを通じて課題を見つけます。その上で、プロダクトの方針、機能の優先順位、ロードマップ、成果指標を設計します。
日々の判断では、「この機能は利用者の課題解決につながるか」「今つくるべきか」「ほかの施策より効果が高いか」といった観点が中心になります。
PMは、作業の洗い出し、担当者の配置、スケジュール作成、進捗確認、課題管理、リスク対応などを行います。日々の判断では、「遅延を防ぐには何が必要か」「品質を確保するにはどのような確認が必要か」「予算超過を避けるにはどう調整するか」といった観点が中心です。
意思決定権と最終責任の違い
PdMには、プロダクトの方針や機能の優先順位に関する意思決定が求められます。ただし、最終的な決定権を経営者や事業責任者が持つ企業もあります。その場合でも、PdMには判断材料を整理し、意思決定を主導する役割が期待されます。
PMには、プロジェクトの進め方、計画、体制、リスク対応に関する意思決定が求められます。ただし、予算や納期、要件の大きな変更は、顧客や事業責任者との合意が必要になることが一般的です。
重要なのは、PdMとPMのどちらが決めるかではなく、判断の対象を明確にすることです。プロダクトの価値に関する判断と、実現方法に関する判断を混同すると、責任の所在が曖昧になります。
開発チームとの関わり方の違い
PdMは、開発チームに対して、解決したい顧客課題や目指す成果を伝えます。開発の背景や目的を共有し、何を優先するかを明確にする役割です。仕様を一方的に渡すのではなく、デザイナーやエンジニアと協力しながら解決策を考えます。
PMは、開発チームが継続して作業を進められる環境を整えます。作業の依存関係、担当者、日程、会議、課題、外部との調整などを管理し、チームの障害を取り除きます。
小規模な組織では、PdMが開発の進行管理も担当することがあります。大規模な組織では、PdMが価値や方向性を担い、PMが計画や実行を担う分業が行われやすくなります。
成果を測る指標の違い
PdMは、利用者価値と事業成果に関する指標で評価されます。代表的な指標には、継続利用率、解約率、機能の利用率、顧客満足度、売上、収益、顧客単価などがあります。
PMは、プロジェクトの実行成果に関する指標で評価されます。代表的な指標には、納期の達成率、予算の達成率、品質、不具合件数、手戻りの少なさ、進捗の安定性などがあります。
開発速度や作業量だけをPdMの成果指標にすると、利用者に価値があるかどうかを見失いやすくなります。一方で、PMが事業成果だけを追うと、現場で管理すべき品質や進捗の課題が見えにくくなります。
PdMが担う仕事と成果指標
顧客や市場の課題を見つける
PdMは、まず顧客がどのような不便や不満を抱えているかを理解します。ユーザーインタビュー、問い合わせ内容、営業やカスタマーサポートからの情報、利用データ、市場調査などを活用します。
利用データは「どこで問題が起きているか」を把握するために役立ちます。顧客へのヒアリングは「なぜ問題が起きているか」を理解するために役立ちます。定量データと定性情報を組み合わせることで、表面的な要望ではなく本質的な課題を捉えやすくなります。
プロダクトの方針と優先順位を決める
顧客要望や改善案は無制限に増えますが、開発できる時間や人員には限りがあります。そのためPdMは、すべての要望に応えるのではなく、目的に照らして優先順位を決めます。
優先順位を決める際は、目的、判断基準、対象項目の順に整理するとよいでしょう。まず、何を達成したいのかを明確にします。次に、顧客への影響、事業への影響、実現に必要な工数、緊急性などの基準を定めます。その上で、複数の施策を比較します。
声の大きい関係者や直近の要望だけで優先順位を決めると、プロダクトの一貫性が失われます。プロダクトの戦略や目標を基準にして判断することが重要です。
開発計画を作り関係者と合意する
PdMは、プロダクトの方針をロードマップや開発計画に落とし込みます。ロードマップは、いつ何をつくるかを示すだけでなく、プロダクトがどのような状態を目指すのかを共有するためのものです。
営業、マーケティング、カスタマーサポート、開発、経営層など、関係者ごとに重視する点は異なります。PdMは、目標、優先順位、変更の背景を説明し、認識をそろえます。
計画は一度決めたら固定するものではありません。市場環境、顧客ニーズ、利用状況、技術的な制約などが変われば、見直しが必要です。
リリース後の利用状況と成果を検証する
PdMの仕事は、リリースで終わりません。新機能や改善施策が実際に使われているか、期待した成果につながっているかを検証します。
たとえば、新規利用者が価値を実感するまでの行動、特定機能の利用率、継続利用率、解約率、問い合わせの変化などを確認します。数値が悪化している場合は、導線が分かりにくいのか、機能の価値が伝わっていないのか、そもそも課題設定が誤っていたのかを切り分けます。
利用率が低い機能についても、すぐに廃止するとは限りません。価値が低いのか、存在を知られていないのか、使い方が分かりにくいのかを確認する必要があります。
利用者価値と事業成果で評価する
PdMの成果指標は、プロダクトの成長段階に応じて変わります。初期段階では、利用者が最初の価値を感じられているか、継続して利用されているかが重要になります。成長段階では、利用拡大、継続率、収益性などの重要度が高まります。
代表的な指標には、次のようなものがあります。
- 新規利用者数
- 継続利用率
- 解約率
- 機能の利用率
- アクティベーション率
- 顧客満足度
- 推奨意向
- 売上や継続収益
- 顧客単価
- 顧客獲得にかかる費用
指標は多ければよいわけではありません。事業目標から逆算し、日々の意思決定につながる指標に絞ることが重要です。特に、改善行動によって早期に変化を確認できる先行指標を持つと、優先順位付けに活用しやすくなります。
PMが担う仕事と成果指標
プロジェクトの目標と進め方を明確にする
PMは、プロジェクトの目的、成果物、範囲、期限、予算、体制を明確にします。開始時点で認識がそろっていないと、途中で要望が増えたり、担当範囲が曖昧になったりして、遅延や品質低下につながります。
プロジェクトの目標は、できるだけ具体的に定義することが重要です。何をいつまでに、どの品質で、どの予算内に実現するのかを関係者と確認します。
人員・予算・予定を管理する
PMは、必要な作業を分解し、担当者、工数、依存関係、期限を整理します。進行中は、作業が予定どおりに進んでいるか、人員が不足していないか、予算が超過していないかを確認します。
プロジェクト管理では、品質、コスト、納期のバランスが重要です。品質を高めるために追加の作業が必要になれば、コストや納期に影響します。納期を早める場合は、人員追加や範囲の調整が必要になることがあります。
すべてを同時に最大化することは難しいため、PMはプロジェクトの目的に応じて、何を優先すべきかを関係者と合意します。
課題とリスクを早期に管理する
PMは、発生した問題に対応するだけでなく、起こりうる問題を早期に見つけて備えます。たとえば、仕様変更、外部ベンダーの遅延、技術的な不確実性、担当者の不足、品質問題などがリスクになります。
課題とリスクは、発生確率、影響の大きさ、対応期限、担当者を明確にして管理します。重大な問題ほど、早い段階で共有し、対策を検討することが重要です。
問題を報告しにくい雰囲気があると、発見が遅れ、後半で大きな手戻りが発生します。PMには、悪い情報ほど早く共有される状態をつくる役割があります。
関係者との調整と情報共有を進める
プロジェクトには、開発者、デザイナー、営業、顧客、経営層、外部パートナーなど、さまざまな関係者が関わります。PMは、それぞれに必要な情報を適切なタイミングで共有し、認識のずれを防ぎます。
特に変更が発生した場合は、変更内容だけではなく、理由、影響範囲、対応方針、今後の予定を明確に伝える必要があります。納期や予算への影響を隠すのではなく、複数の選択肢とともに早めに相談することが、信頼関係の維持につながります。
納期・品質・予算の達成で評価する
PMは、プロジェクトの計画達成度で評価されます。代表的な指標には次のようなものがあります。
- 納期の達成率
- 予算の達成率
- 品質基準の達成状況
- 不具合の件数や修正にかかる時間
- 進捗の遅延状況
- 手戻りの発生状況
- リスク対応の実施状況
- 関係者の合意形成の状況
ただし、納期を守るためだけに品質を下げたり、過度な残業で乗り切ったりする方法は持続的ではありません。PMには、プロジェクトを完了させることに加え、継続して安定した進行ができる仕組みをつくることも求められます。
会社や組織によって変わるPdMとPMの役割分担
PdMとPMを一人が兼務するケース
小規模な組織や新規事業では、PdMとPMを一人が兼務することがあります。担当者は、顧客課題の発見、機能の優先順位付け、開発計画、進捗管理、リリース後の分析まで担います。
意思決定が速い点はメリットですが、業務量が多くなりやすい点には注意が必要です。市場や顧客を見る時間が不足すると、進行管理に偏ります。反対に、企画に集中しすぎると、プロジェクト管理が不十分になる可能性があります。
兼務する場合は、プロダクトの判断とプロジェクトの判断を意識的に分け、定期的に時間を確保することが重要です。
PdMとPMを分業するケース
一定規模以上の組織では、PdMとPMを分業することがあります。PdMはプロダクト戦略、顧客理解、優先順位、成果指標を主に担い、PMは計画、進捗、品質、コスト、リスク管理を主に担います。
分業の利点は、それぞれが専門性を発揮しやすいことです。一方で、役割の境界が曖昧だと、判断が遅れたり、責任の押し付け合いが起きたりします。
分業する場合は、プロダクト方針の変更がプロジェクトにどう影響するか、プロジェクト上の制約がプロダクトの優先順位にどう影響するかを、日常的に共有する必要があります。
小規模組織と大規模組織で異なる役割
小規模組織では、役割の境界が柔軟です。PdMが営業や顧客対応を担うこともあれば、PMがプロダクトの企画に深く関わることもあります。幅広い経験を得やすい一方で、担当範囲が広くなります。
大規模組織では、PdM、PM、デザイナー、エンジニアリングマネージャー、マーケティング担当などに役割が分かれていることがあります。専門性を深めやすい一方で、部門間の調整や合意形成がより重要になります。
どちらが優れているかではなく、自分がどのような経験を積みたいか、どの領域に強みを持ちたいかで選ぶことが大切です。
開発手法によって変わる責任範囲
計画を先に固めて進める開発では、PMの計画・進捗・品質管理の比重が高くなりやすい傾向があります。要件や範囲を明確にし、変更を適切に管理することが重要です。
短いサイクルで開発と検証を繰り返す開発では、PdMやプロダクトオーナーが、優先順位付けや開発チームとの連携をより頻繁に行うことがあります。利用者の反応をもとに、次に取り組む内容を見直す必要があるためです。
ただし、どの開発手法でも、計画、品質、リスク、顧客価値の管理は必要です。役割の名称よりも、誰が何に責任を持つかを確認することが重要です。
役割の重複や抜け漏れを防ぐ整理方法
役割分担を整理する際は、業務を列挙した上で、決定者、実行者、相談先、共有先を明確にするとよいでしょう。
たとえば、次のような業務について担当を定めます。
- プロダクト戦略の策定
- 顧客調査と市場調査
- 目標と成果指標の設定
- 機能の優先順位付け
- 要件の整理
- 開発計画の作成
- スケジュールと予算の管理
- 品質確認
- リスク管理
- リリース判断
- リリース後の効果検証
定期的に見直し、実際の運用と役割分担がずれていないかを確認することも必要です。
求人票と自社の体制から役割を見分ける方法
求人票で確認するべき責任範囲と権限
求人票を見る際は、職種名よりも責任範囲を確認します。PdM寄りの求人では、プロダクト戦略、顧客理解、ロードマップ、優先順位付け、成果指標の改善などが記載されやすい傾向があります。
PM寄りの求人では、進捗管理、予算管理、品質管理、リスク管理、要員管理、顧客との調整などが記載されやすい傾向があります。
あわせて、どの程度の意思決定権があるかも確認します。機能の優先順位を決められるのか、予算や人員の調整に関われるのか、経営層への提案機会があるのかによって、実際の役割は大きく変わります。
求められる成果指標から職種を判断する
求人票に評価指標が書かれている場合は、特に重要な情報です。以下のような記載があれば、PdM寄りと考えられます。
- 利用者数や継続利用率の向上
- 解約率の改善
- 機能利用率の向上
- 顧客満足度の向上
- 売上や収益の成長
- プロダクトの成長戦略の実行
以下のような記載があれば、PM寄りと考えられます。
- プロジェクトの納期遵守
- 予算内での完了
- 品質基準の達成
- リスク管理の徹底
- 複数チームや外部パートナーの進行管理
- プロジェクト計画の策定と実行
業務内容からPdM寄りかPM寄りかを見極める
業務内容に「顧客課題の発見」「市場分析」「プロダクトの方向性」「機能優先順位」「リリース後の利用分析」が多い場合は、PdM寄りです。
「要件定義」「工程管理」「予算」「品質」「進捗」「リスク」「ベンダー管理」が多い場合は、PM寄りです。
ただし、要件定義や開発チームとの連携は、PdMにもPMにも必要です。そのため、業務項目を一つだけ見て判断せず、全体の比重を見ることが重要です。
自社の役割分担を確認する質問項目
自社や応募先の役割を把握するためには、次のような質問が役立ちます。
- プロダクトの方針や優先順位は誰が決めますか
- 顧客調査や利用データの分析は誰が担当しますか
- 開発計画と日々の進捗管理は誰が担いますか
- プロダクトの成果はどの指標で評価されますか
- 納期や予算の変更が必要な場合、誰が判断しますか
- リリース後の改善責任は誰が持ちますか
- 営業、マーケティング、カスタマーサポートとの連携は誰が主導しますか
- PdM、PM、プロダクトオーナーの役割はどう分かれていますか
質問への回答が曖昧な場合は、役割が未整理である可能性があります。入社後に期待される業務を具体的に確認することが大切です。
PdMとPMのどちらに必要な経験かを判断する
PdMを目指す場合は、顧客理解、課題発見、企画、データ分析、優先順位付け、事業成果の改善といった経験が強みになります。
PMを目指す場合は、計画作成、工程管理、品質管理、予算管理、リスク対応、関係者調整といった経験が強みになります。
どちらの経験も無駄にはなりません。PM経験は、実現可能な計画を立てる力やチームを動かす力としてPdM業務に生かせます。PdM経験は、プロジェクトの目的を明確にし、優先順位を判断する力としてPM業務に生かせます。
PdMとPMに求められるスキルとキャリアの考え方
PdMに求められる顧客理解と事業を考える力
PdMには、顧客が抱える課題を深く理解する力が求められます。顧客の言葉をそのまま受け取るのではなく、利用状況、業務の流れ、代替手段、背景にある目的まで確認することが重要です。
また、顧客価値だけでなく、事業として継続できるかを考える必要があります。市場規模、競合、収益性、提供コスト、成長可能性などを踏まえて、プロダクトの方針を決めます。
PMに求められる計画力と進行管理力
PMには、複雑な業務を整理し、実行可能な計画に落とし込む力が求められます。作業を細分化し、依存関係、担当者、必要な工数、期限を把握することが基本です。
また、計画どおりに進まないことを前提に、遅延や変更に対応する力も必要です。進捗を確認するだけではなく、問題の予兆を早期に捉え、関係者と調整しながら対策を実行します。
両者に共通する調整力と伝達力
PdMとPMのどちらにも、調整力と伝達力が必要です。多様な立場の関係者と仕事を進めるため、相手の関心や前提を理解し、必要な情報を分かりやすく伝える必要があります。
開発チームには、背景、目的、優先順位を伝えます。経営層には、事業への影響、選択肢、判断が必要な点を伝えます。顧客には、期待値や変更点を正確に伝えます。
意見が対立した場合も、単に多数決を取るのではなく、目標、データ、制約条件に立ち返って合意をつくることが重要です。
PMからPdMへ転向する際に補うべき経験
PMからPdMを目指す場合は、進行管理の経験に加えて、顧客や市場に近い経験を増やすことが重要です。
たとえば、次のような経験が役立ちます。
- 顧客へのヒアリングや利用者調査
- 営業やカスタマーサポートとの連携
- 利用データの分析
- プロダクトの成果指標の設定
- 機能の優先順位付け
- リリース後の効果検証
- 市場や競合の調査
- 事業計画や収益構造の理解
PMとして培った計画力、リスク管理力、関係者調整力は、PdMにとっても大きな強みです。そこに顧客理解と事業視点を加えることで、キャリアの選択肢が広がります。
PdMとPMの経験を次のキャリアに生かす方法
PdM経験を積むと、プロダクト責任者、事業開発、プロダクトマーケティング、経営に近い役割などを目指しやすくなります。顧客、市場、事業、開発を横断して考える経験が、次の役割に生かせるためです。
PM経験を積むと、より大規模なプロジェクトの責任者、複数プロジェクトを統括する役割、プログラム管理、業務改革、ITコンサルティングなどの道があります。複雑な関係者をまとめ、計画を実現する力が評価されます。
PdMとPMのどちらを選ぶかは、優劣ではなく、関心の置きどころで判断するとよいでしょう。顧客課題やプロダクトの価値を考え続けたい場合はPdM寄り、計画を実現しチームで成果を出す過程に強い関心がある場合はPM寄りです。
ただし、実務では両方の視点が必要です。PdMは実現可能性や開発の進め方を理解することで、よりよい優先順位を決められます。PMはプロダクトの目的や顧客価値を理解することで、単なる進捗管理にとどまらない判断ができます。
自分が担う役割の名称ではなく、どの成果に責任を持ち、どの経験を積みたいのかを明確にすることが、PdMとPMの違いを正しく理解し、キャリアにつなげる第一歩です。
