コトラ（広報チーム） 
PdMは、プロダクトマネージャーの略称です。顧客の課題を捉え、事業として成立する形に整理し、開発チームとともにプロダクトを成長させる役割を担います。
市場価値が高く、事業に大きな影響を与えられる職種である一方、仕事内容は幅広く、組織によっては責任だけが重くなることもあります。そのため、未経験から目指す人や、転職を検討している人に対して「PdMはやめとけ」と言われることがあります。
ただし、PdMそのものが避けるべき職種というわけではありません。自分の適性、任される権限、組織体制を見極めれば、顧客と事業の両方に価値を生み出せる仕事です。本記事では、PdMが厳しいと言われる背景と、向いている人・向いていない人の特徴、求人選びの確認ポイントを解説します。
PdMはやめとけと言われる背景
PdMの役割とPM・プロダクトオーナーとの違い
PdMは、プロダクトの成功に向けて「なぜ作るのか」「何を作るのか」を考える役割です。顧客や市場の課題を調べ、プロダクトの方向性を定め、開発後の成果まで確認します。
一方、PMと呼ばれるプロジェクトマネージャーは、決められたプロジェクトを予定や予算、品質の条件に沿って進める役割です。PdMがプロダクト全体の価値や成長に責任を持つのに対し、PMは特定の開発計画を円滑に完了させることに重点を置きます。
プロダクトオーナーは、主にスクラム開発の中で定義される役割です。開発チームに近い場所で、何を優先して作るかを決め、開発項目の管理を行います。会社によってはPdMとプロダクトオーナーを同じ人が兼ねることもありますが、役割を分ける組織もあります。
肩書きだけでは実際の仕事内容を判断できません。PdMという名称であっても、戦略づくりが中心の会社もあれば、仕様作成や進行管理が中心の会社もあります。
PdMが担う企画・優先順位付け・関係者調整
PdMの仕事は、機能の仕様を決めることだけではありません。代表的な業務には、顧客や市場の調査、課題の整理、プロダクトの方向性づくり、開発する内容の優先順位付け、リリース後の効果確認などがあります。
特に重要なのが、限られた開発時間や人員をどこに使うかを決めることです。営業からは顧客要望への対応を求められ、経営陣からは売上への貢献を求められ、開発チームからは技術的な制約や品質面の課題が提示されます。PdMはこうした意見を受け止めながら、顧客価値と事業への影響を基準に判断します。
顧客の要望をそのまま機能にすることが、顧客志向とは限りません。たとえば「このボタンを大きくしてほしい」という要望の背景には、操作の分かりにくさや業務の手間といった本質的な課題が隠れている場合があります。PdMには、表面的な要望を課題として捉え直す力が求められます。
会社によって仕事内容と権限が大きく異なる理由
PdMの役割は、会社の規模、プロダクトの成長段階、組織の体制によって大きく変わります。立ち上げ直後の小規模な会社では、PdMが顧客ヒアリング、企画、要件整理、営業支援、リリース後の分析まで幅広く担うことがあります。
一方、組織が大きくなると、ユーザー調査、デザイン、データ分析、マーケティング、開発進行などの役割が分かれる場合があります。この環境では、PdMは全体の方向性や優先順位の判断に集中しやすくなります。
また、同じPdMでも、ロードマップを自ら決められる会社と、経営陣や事業部の決定を開発チームに伝えるだけの会社では、働き方が異なります。肩書きではなく、意思決定の範囲と、誰が最終判断を行うのかを確認することが重要です。
雑用係と見なされるPdMに共通する組織の課題
PdMが「何でも屋」や「雑用係」のようになってしまう会社には、共通する課題があります。代表的なのは、役割分担と意思決定の仕組みが曖昧なことです。
営業要望の整理、会議の調整、仕様書の作成、問い合わせ対応、開発の進行確認などがすべてPdMに集まると、本来行うべき顧客理解や戦略づくりに時間を使えません。結果として、目の前の依頼を処理するだけの働き方になりやすくなります。
また、PdMに決定権がないにもかかわらず、成果だけを求める組織も注意が必要です。責任と権限が釣り合わない状態では、PdMが関係者の板挟みになり、疲弊しやすくなります。
PdMはやめとけと言われる5つの理由
業務範囲が広く、求められる知識が多いため
PdMには、顧客理解、事業計画、データ分析、開発の基礎知識、デザインへの理解、関係者との対話力など、幅広い知識が求められます。すべてを専門家レベルで身につける必要はありませんが、それぞれの領域について会話し、判断できる程度の理解が必要です。
あるスキル整理では、PdMに必要な能力を事業戦略、調査、進行管理、要件定義、詳細設計、リリース、コミュニケーション、支援業務といった複数の領域に分けています。幅広さがPdMの価値である一方、学ぶことが多く、経験が浅いうちは負担に感じやすい理由でもあります。
不足している知識を一人で埋めようとすると、学習と実務の両方で余裕を失います。周囲の専門家と協力し、自分が担うべき判断を明確にすることが重要です。
成果への責任が重い一方で決定権が不足しやすいため
PdMは、プロダクトの利用状況、顧客満足、売上、継続利用などの成果に関わります。しかし、実際には予算、人員、開発の優先順位、価格、販売方針を自分だけで決められないことが多くあります。
特に、経営陣や営業部門の意向が強く、PdMが顧客価値や技術的な事情を踏まえた判断をできない環境では、責任だけを背負う状態になりがちです。成果を求められても、必要な人員や開発時間を確保できなければ、改善を進めることは困難です。
この問題は個人の能力だけで解決できません。転職前であれば、PdMにどの範囲の決定権があるのか、意見が対立した際に誰がどの基準で決めるのかを確認する必要があります。
開発・営業・経営陣など関係者との調整が多いため
PdMは、エンジニア、デザイナー、営業、カスタマーサポート、マーケティング、経営陣など、多様な立場の人と関わります。それぞれが重視するものは異なります。
開発チームは品質や実現可能性を重視し、営業は顧客要望や受注機会を重視し、経営陣は事業成長や収益性を重視します。PdMには、それぞれの事情を理解したうえで、共通の目的に向けて議論を進める役割があります。
単に全員の意見を受け入れるだけでは、プロダクトの方向性がぶれます。対立を避けるのではなく、顧客課題、事業への影響、必要な開発コストを整理し、判断理由を説明しなければなりません。人との調整が連続するため、一人で作業に集中したい人には負担が大きくなります。
正解のない優先順位付けと意思決定を続ける必要があるため
プロダクト開発では、やりたいことが常に開発できるとは限りません。時間、人員、予算には制約があるため、PdMは「何をやるか」だけでなく「何をやらないか」も決める必要があります。
優先順位を考える際は、顧客への影響、事業への影響、実現の難しさ、緊急性などを確認します。たとえば、利用者が多く影響も大きいが開発に時間がかかる施策と、影響は中程度でも短期間で実施できる施策では、どちらを先に進めるべきかを検討しなければなりません。
判断の透明性を高めるために、影響の大きさ、対象となる利用者数、確信度、必要な工数を整理する考え方が使われることもあります。ただし、数字だけで正解が出るわけではありません。プロダクトの方向性や顧客体験との整合性も含めて判断する必要があります。
未経験からの転職難易度が高く、会社選びも難しいため
PdMは、幅広い経験が求められるため、完全未経験者向けの求人は多くありません。未経験可と記載されていても、顧客理解、企画、データ分析、開発進行、営業支援など、何らかの関連経験を求めるケースが一般的です。
また、PdMという職種名でも、実際にはWebディレクターに近い業務、事業企画に近い業務、プロジェクト管理に近い業務を任される場合があります。転職後に「戦略を考えたいのに、進行管理だけだった」「顧客理解を深めたいのに、社内要望の処理が中心だった」と感じるミスマッチも起こり得ます。
未経験から目指す場合は、肩書きだけにこだわらず、プロダクトに近い仕事で実績を積める環境を選ぶことが現実的です。
PdMで疲弊しやすい会社と求人の見分け方
PdMの責任範囲と意思決定権が明文化されていない
求人票に「プロダクトの成長に責任を持つ」「幅広い業務を担う」と書かれていても、具体的な責任範囲や権限が分からなければ注意が必要です。
確認したいのは、プロダクト戦略、ロードマップ、開発優先順位、仕様、価格や販売方針について、誰が最終決定するのかという点です。PdMが提案するだけなのか、最終判断を担うのかによって、業務の性質は大きく変わります。
役割が曖昧な組織では、問題が起きた際にPdMへ仕事が集中しやすくなります。入社後の期待値をそろえるためにも、責任範囲を言葉にできる会社かどうかを確認しましょう。
開発・デザイン・分析の体制が不足している
PdM一人に、顧客調査、デザイン、仕様作成、分析、開発進行、営業支援まで求める会社では、業務過多になりやすい傾向があります。少人数の組織では兼務が必要な場合もありますが、どの業務を誰が支えるのかが明確かどうかが重要です。
たとえば、デザイナーが企画段階から参加できる体制であれば、PdMが一人で体験設計を抱え込まずに済みます。データ分析担当者がいれば、施策の効果をより正確に確認できます。開発チームが不足している場合は、どれほど良い企画でも実現までに時間がかかります。
人員が少ないこと自体が悪いわけではありません。ただし、少ない体制で何を優先し、どこまでを実現するかについて、組織として合意できているかが重要です。
経営陣や営業部門からの要望が優先され続ける
経営陣や営業部門の意見は、プロダクト開発にとって重要です。しかし、顧客課題やプロダクト戦略を確認せず、声の大きい要望だけが優先される状態が続くと、プロダクトは一貫性を失います。
特定顧客向けの機能追加を繰り返すと、全体として使いにくくなったり、保守の負担が増えたりすることがあります。また、開発チームが目的を理解できず、単なる依頼処理になりやすくなります。
健全な組織では、要望を受け取った際に、背景、対象顧客、解決したい課題、期待する効果、必要な工数を整理します。そのうえで、他の施策との優先順位を比較します。こうした仕組みがあるかを確認しましょう。
プロダクトの顧客や課題が曖昧になっている
「誰の、どのような困りごとを解決するプロダクトか」が曖昧な会社では、PdMの判断も難しくなります。顧客像が定まらなければ、どの要望に応えるべきか、どの指標を改善すべきかを判断できません。
面接では、主な顧客、顧客が抱える課題、競合との違い、現在重視している指標について質問するとよいでしょう。これらに対する回答が具体的であれば、プロダクトの方向性がある程度整理されている可能性があります。
反対に、「幅広い人が対象」「とにかく機能を増やしたい」といった説明に終始する場合は、PdMが課題設定から担う必要があるかもしれません。その状況を成長機会と感じるか、負担と感じるかは、自身の経験や志向によって変わります。
求人票と面接で確認したい質問項目
求人票だけでは、実際の働き方を十分に判断できません。面接では、以下の項目を確認すると、入社後のミスマッチを減らしやすくなります。
- PdMが担う業務と、担わない業務の範囲
- プロダクトの優先順位を最終的に決める人
- 現在の開発、デザイン、分析、顧客対応の体制
- PdM一人あたりが担当するプロダクトや開発チームの数
- 直近で優先している事業課題とプロダクト課題
- 顧客の声を集める方法と、開発へ反映する仕組み
- 開発チームとの連携方法、会議の頻度、意思決定の流れ
- 入社後3か月から半年で期待される成果
- PdMの評価基準と、過去に評価された取り組み
- 要望が対立した場合の判断基準と、実際の事例
質問への回答内容だけでなく、面接官ごとに説明が一致しているかも確認しましょう。認識が大きく異なる場合は、組織内で役割が整理されていない可能性があります。
PdMに向いていない人の特徴
一つの専門分野を深く極める働き方を望む人
PdMは、特定の分野だけを深く担当するよりも、複数の領域を横断して判断する仕事です。技術、デザイン、顧客理解、事業計画のすべてに関わるため、専門性を一つに絞りたい人は負担を感じることがあります。
もちろん、技術に強いPdM、顧客調査に強いPdM、マーケティングに強いPdMのように得意分野を持つことは可能です。ただし、自分の専門外であっても、関係者と対話し、全体を見ながら意思決定する姿勢は欠かせません。
深い専門性を磨くことに強い喜びを感じる場合は、エンジニア、デザイナー、データ分析、リサーチ、マーケティングなどの専門職のほうが合う可能性があります。
利害が異なる相手との調整に強い負担を感じる人
PdMは、立場の異なる人と日常的に話し合います。全員の希望をかなえることは難しく、時には要望を断ったり、優先順位を下げたりする必要があります。
人との調整が苦手であったり、意見の対立を強く避けたいと感じたりする場合、PdMの仕事は精神的な負担になりやすいでしょう。合意形成は、全員を満足させることではありません。目的と判断基準を共有し、納得できる形で前に進めることです。
相手の立場を理解しつつ、必要なことを伝える姿勢に苦痛を感じる場合は、PdM以外の働き方も検討する価値があります。
不確実な状況で判断することが苦手な人
プロダクト開発では、すべての情報がそろうことはほとんどありません。市場の反応、顧客の行動、開発の難しさは、実際に試してみなければ分からない部分があります。
PdMには、限られた情報から仮説を立て、必要に応じて修正する力が求められます。完璧な正解が出るまで動けない人や、計画変更に強いストレスを感じる人は苦労しやすいでしょう。
不確実性を減らすために調査や検証は重要ですが、最終的には一定の不確実さを受け入れて決める必要があります。
数字や顧客の声を基に仮説を見直すことが苦手な人
PdMの仕事では、リリース後に成果を確認し、仮説を見直します。自分が考えた機能が使われなかった場合や、想定した効果が出なかった場合も、原因を調べて次の改善につなげる必要があります。
数字を見ることを避けたり、顧客の声より自分の考えを優先し続けたりすると、プロダクトの改善が止まります。高度な分析技術が必須というわけではありませんが、利用者数、継続率、利用頻度、問い合わせ内容などを確認し、判断材料にする姿勢は必要です。
作って終わりではなく、成果が出たかを確かめることに関心を持てるかどうかが、PdMの適性を分けます。
担当するプロダクトや顧客課題に関心を持てない人
PdMは、長期的にプロダクトと顧客課題に向き合う仕事です。困難な調整や失敗があっても、顧客の課題を解決したいという関心があれば、改善を続ける原動力になります。
一方で、担当する領域に関心が持てず、顧客の業務や悩みを理解することにも意欲がわかない場合、仕事が単なる調整業務になりやすくなります。プロダクトへの愛着だけでなく、顧客が置かれている状況への興味も重要です。
PdMに向いている人の特徴
顧客の困りごとを理解し、解決策を考えることが好きな人
PdMに向いているのは、顧客が何に困っているのかを知り、その解決策を考えることに面白さを感じる人です。顧客の要望をそのまま実現するのではなく、「なぜその要望が出たのか」「本当の課題は何か」を掘り下げられる人は強みを発揮しやすいでしょう。
営業、カスタマーサポート、マーケティング、業務改善などで顧客の声に触れてきた経験は、PdMにも生かせます。顧客の言葉を事業や開発の判断につなげる力が重要です。
全体像を捉え、優先順位を付けられる人
PdMは、個別の要望だけを見るのではなく、プロダクト全体、事業目標、開発体制、顧客体験のつながりを考えます。目の前の依頼をすべて受けるのではなく、限られた資源をどこに使うべきかを判断します。
優先順位付けでは、顧客への価値、事業への影響、実現の難しさ、緊急性を整理します。判断理由を言葉にし、関係者と共有できる人は、チームの信頼を得やすくなります。
正解を当て続けることよりも、判断基準を明確にし、結果から学び続けられることが重要です。
異なる立場の人と対話し、合意をつくれる人
PdMには、多様な人の考えを聞き、目的に沿って議論を前に進める力が求められます。話すことが得意であるだけではなく、相手が何を重視しているのかを理解し、伝え方を変えることが重要です。
エンジニアには背景や目的を共有し、経営陣には事業への影響を示し、営業には顧客への価値と優先順位の理由を説明する必要があります。異なる専門性や利害をつなぐことにやりがいを感じる人は、PdMに向いています。
結果を検証し、失敗から改善を重ねられる人
PdMの仕事では、最初から完璧な答えを出すことはできません。機能を出した後に利用状況を確認し、顧客の声を聞き、想定との違いを見つけて改善します。
失敗を避けることだけに集中するのではなく、小さく試し、学び、次の判断に生かせる人は成長しやすいでしょう。リリースを成果物の完成ではなく、仮説を確かめる機会として捉えられることが大切です。
プロダクトの成長に長期的に関わりたい人
PdMは、短期間で目に見える成果が出るとは限りません。顧客理解を深め、開発し、リリースし、改善するという流れを繰り返しながら、プロダクトを育てていきます。
長期的な視点で、顧客の課題が解決される過程や、プロダクトが成長する過程に関わりたい人にとっては、大きなやりがいを得られる仕事です。機能を作ること自体よりも、利用者や事業にどのような変化が起きたかに関心を持てる人が向いています。
PdMを目指すか迷ったときの選択肢
未経験者がPdMに必要な経験を積む方法
未経験からPdMを目指す場合、いきなりPdMの肩書きを得ることだけを目標にしないほうが現実的です。まずは現在の仕事や近い職種で、顧客理解、課題整理、関係者調整、企画、データ確認といった経験を積みましょう。
たとえば、営業やカスタマーサポートの経験者は、顧客課題の把握を強みにできます。エンジニアは技術的な実現可能性の理解を、デザイナーは利用体験への理解を、マーケティング担当は市場や顧客分析の経験を生かせます。
経験を積む際は、単に担当業務をこなすだけではなく、以下のような行動を意識するとよいでしょう。
- 顧客へのヒアリングや問い合わせ分析に参加する
- 施策の目的と成果指標を考える
- 小さな改善案を提案し、実施後の結果を確認する
- 開発やデザインの会議に参加し、意思決定の流れを理解する
- 自分が関わった施策を、背景、判断、結果、学びの形で記録する
学習と実践を繰り返すことが重要です。知識を得るだけではなく、自社や身近なサービスに当てはめて考え、実際の行動に移すことで理解が深まります。
現役PdMが負担を減らすために見直すべきこと
現役PdMが疲弊している場合、個人の努力だけで解決しようとする前に、仕事の仕組みを見直す必要があります。まず、業務を棚卸しし、自分しかできない判断と、他の人に任せられる作業を分けましょう。
会議の調整、情報収集、定型的な問い合わせ対応などに時間が取られている場合は、仕組み化や役割分担で負担を減らせる可能性があります。また、優先順位の判断基準を共有し、要望を受け付ける窓口や評価方法を整えることも有効です。
開発チームには、仕様だけでなく背景や目的を伝えることが重要です。なぜ作るのかが共有されれば、技術的によりよい案や、効率的な実現方法が提案される可能性があります。PdMがすべての答えを出すのではなく、チームで考える状態をつくることが負担軽減につながります。
担当プロダクトに興味を持てない場合の判断基準
担当プロダクトに興味を持てない状態が続く場合は、原因を整理しましょう。プロダクトの領域自体に関心がないのか、顧客との接点が少ないのか、意思決定できない環境に不満があるのかによって、取るべき行動は異なります。
顧客理解が不足しているだけであれば、利用者の話を聞いたり、利用場面を観察したりすることで、仕事の意味を見いだせることがあります。一方で、組織の方針や価値観、プロダクトの方向性に根本的に共感できない場合は、担当変更や転職を検討することも選択肢です。
判断する際は、「仕事内容が嫌なのか」「環境が合わないのか」「扱う顧客課題に関心が持てないのか」を分けて考えることが大切です。
PdM以外に検討できる近い職種
PdMに興味があっても、すべての業務が自分に合うとは限りません。自分の強みや希望する働き方に応じて、近い職種を検討することも有効です。
- プロジェクトマネージャー
- Webディレクター
- プロダクトオーナー
- プロダクトマーケティング担当
- 事業企画
- カスタマーサクセス
- UXリサーチャー
- プロダクトデザイナー
- データアナリスト
- BizDev
たとえば、開発の進行や計画管理に強みがある人はプロジェクトマネージャー、顧客の声を深く掘り下げたい人はリサーチやカスタマーサクセス、プロダクトの市場投入や訴求に関心がある人はプロダクトマーケティングが向く可能性があります。
PdMを目指す過程で得た顧客理解、事業理解、調整力は、これらの職種でも十分に生かせます。
自分に合う環境と働き方を基準にキャリアを選ぶ
PdMが向いているかどうかは、性格だけで決まるものではありません。組織の体制、権限の範囲、プロダクトの成長段階、チームの専門性、顧客課題への関心によって、働きやすさは大きく変わります。
幅広い役割を担いながら事業の立ち上げに関わりたい人もいれば、役割分担が整った環境で、顧客理解や優先順位付けに集中したい人もいます。新規プロダクトの不確実さを楽しめる人もいれば、既存プロダクトを分析し、着実に改善する仕事に強みを発揮する人もいます。
「PdMはやめとけ」という言葉をそのまま受け取る必要はありません。大切なのは、PdMの仕事の厳しさを理解したうえで、自分の強み、価値観、働き方に合う環境を選ぶことです。肩書きではなく、どのような顧客課題に向き合い、どの範囲で意思決定し、誰と協力して価値を作りたいのかを基準に、キャリアを考えましょう。
