コトラ（広報チーム） 
PdMは、顧客が抱える課題を見つけ、解決する価値を定め、開発チームと協力してプロダクトを育てる役割です。WebサービスやSaaSでは、リリース後も利用状況を確認しながら改善を続けるため、企画だけで仕事が終わるわけではありません。
本記事では、PdMの基本的な役割から、日々の実務、開発チームとの連携、必要なスキル、目指すための経験の積み方までを解説します。
PdM（プロダクトマネージャー）とは
PdMは、プロダクトマネージャーの略称です。プロダクトとは、企業が顧客に提供する製品やサービスを指します。Webサービス、スマートフォンアプリ、業務用SaaSなどでは、プロダクトの企画、開発、販売、改善を横断して考える担当者として置かれることが一般的です。
PdMの役割は企業や組織の規模によって異なります。小規模な組織では、企画、要件整理、プロジェクトの進行、販売部門との連携まで幅広く担う場合があります。一方で、組織が大きい企業では、開発、デザイン、マーケティング、プロジェクト管理などの担当者と分担しながら、プロダクトの方向性と優先順位を担います。
PdMが担うプロダクト全体への責任
PdMは、単に機能の仕様を決める仕事ではありません。「誰の、どのような課題を解決するのか」「その課題に対して、なぜ今この機能が必要なのか」を考え、プロダクト全体の成功につなげる役割です。
たとえば、顧客から機能追加の要望があった場合でも、そのまま開発するとは限りません。要望の背景にある業務上の困りごとを確認し、より多くの顧客に共通する課題か、事業方針と合うか、開発に必要な時間に見合う効果があるかを検討します。
PdMは、顧客価値、事業性、技術的な実現可能性のバランスをとりながら判断します。そのため、プロダクトの成果には関わりますが、すべてを一人で決めたり、一人で実行したりする職種ではありません。各専門職が力を発揮できるように、目的と判断基準を整えることが重要です。
PdMが必要とされる背景
ITプロダクトは、リリース後も継続的な改善が必要です。顧客の業務や市場環境、競合の状況、利用する技術は変化します。一度作った機能を提供し続けるだけでは、顧客に選ばれ続けることが難しくなります。
また、開発部門だけで機能を考えると、技術的には優れていても顧客の課題に合わない可能性があります。反対に、営業や顧客対応の要望だけを優先すると、個別対応が増え、プロダクト全体が複雑になるおそれがあります。
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でも、課題の背景や優先する条件を丁寧に共有し、「顧客にとって使いやすいか」「目的に対して過剰な開発になっていないか」といった問いを投げかけることで、開発チームに貢献できます。
開発中の判断と優先順位の調整を行う
開発が始まると、当初は見えていなかった課題や追加の要望が出ることがあります。PdMは、すべてを受け入れるのではなく、リリースの目的、顧客への影響、開発の進み具合を踏まえて判断します。
たとえば、予定していた機能の一部を後回しにしても、顧客が価値を得られる場合があります。反対に、品質や安全性に関わる問題は、予定よりも優先すべきことがあります。
判断を行う際は、変更内容だけでなく、なぜ優先順位を変えるのかを説明します。意思決定の基準を共有することで、チームの納得感を高められます。
営業やカスタマーサポートと情報を共有する
営業やカスタマーサポートは、顧客に近い立場で要望、不満、導入時の課題を把握しています。PdMは、これらの情報を企画や改善に活かします。
一方で、リリースする機能の背景、対象顧客、利用条件、提供開始時期も共有する必要があります。顧客に誤った期待を持たせないためです。
機能をリリースした後は、営業やカスタマーサポートから顧客の反応を集めます。利用が進まない理由や、説明時に伝わりにくい点を確認し、機能改善や案内方法の見直しにつなげます。
PdMが見る指標と改善の進め方
PdMは、プロダクトが顧客価値と事業成果につながっているかを確認するために、指標を見ます。ただし、数字を追うこと自体が目的ではありません。数字から課題を見つけ、改善の仮説を立てるために活用します。
プロダクトの目的に合った指標を設定する
指標は、プロダクトが目指す目的から考えます。たとえば、売上や利益は重要な結果ですが、変化が現れるまでに時間がかかることがあります。そのため、日々の改善では、成果につながる途中の行動も確認します。
SaaSであれば、登録後に必要な設定を完了した割合、主要機能の利用率、継続利用率、解約率などが指標になります。どの指標が重要かは、プロダクトの目的や成長段階によって異なります。
指標は多すぎると、何を優先すべきか分からなくなります。まずは、顧客価値と事業目標に強く関係するものを絞り、指標同士のつながりを整理することが大切です。
利用状況や継続率から成果を確認する
利用状況を見ることで、機能が実際に使われているかを確認できます。ただし、単純な利用回数だけでは十分ではありません。顧客が目的を達成できたか、継続して価値を感じているかも確認が必要です。
継続率は、ある時点で利用を始めた人や企業のうち、その後も利用を続けている割合です。継続率が下がっている場合は、初回利用の体験、導入支援、日常的な使いやすさ、競合サービスへの乗り換えなど、複数の可能性を考えます。
利用者の属性や利用開始時期ごとに分けて確認すると、どの層で課題が起きているかを把握しやすくなります。
数字だけでは分からない利用者の声を集める
数値は状況を把握するために有効ですが、なぜその数字になったのかまでは分からない場合があります。そこで、顧客ヒアリング、問い合わせ、営業記録、利用者の観察などを通じて、利用者の声を集めます。
たとえば、ある機能の利用率が低い場合、画面が分かりにくいのか、そもそも必要とされていないのか、別の方法で目的を達成しているのかは、顧客に聞かなければ判断できません。
定量情報と定性情報を組み合わせることで、改善するべき点をより正確に見極められます。
改善施策の効果を検証する
改善施策を実施する前に、何を変えたいのか、どの指標で効果を確認するのかを決めます。たとえば、初回設定の完了率を高めたい場合は、設定画面の改善後に完了率がどう変化したかを確認します。
施策の効果を判断する際は、実施前後の数字だけでなく、季節要因、顧客構成の変化、同時期に行った他の施策なども考慮します。
一度の結果だけで結論を急がず、利用者の声も確認しながら、施策の有効性を判断します。期待した効果が出ない場合は、仮説、対象顧客、実施方法のどこに問題があったかを振り返ります。
次の開発計画に改善結果を反映する
改善結果は、次の優先順位やロードマップに反映します。効果が高かった施策は広げ、十分な成果が得られなかった施策は見直します。
ロードマップは、一度決めたら変えない計画ではありません。市場、顧客、競合、事業方針、開発体制が変われば、優先順位も変わります。
PdMは、改善の学びを蓄積し、関係者に共有します。判断の根拠が共有されることで、次の企画や開発に対する理解を得やすくなります。
PdMに求められるスキルと向いている人の特徴
PdMには幅広いスキルが求められますが、すべてを最初から高い水準で備えている必要はありません。自分の強みを活かしつつ、不足する領域を学び、専門職と協力することが重要です。
課題を見つけて整理する力
PdMには、表面的な要望の奥にある課題を見つけ、整理する力が必要です。情報が多いなかで、何が本質的な課題なのか、誰にとって重要なのかを考えます。
この力は、顧客ヒアリング、利用データの確認、問い合わせ分析、業務フローの観察などを通じて磨けます。特に、事実と解釈を分けて考える習慣が重要です。
顧客の発言や数値をそのまま結論にせず、「なぜこの状況が起きているのか」と問い直す姿勢が求められます。
利用者と事業の両方を考える力
利用者にとって便利な機能でも、事業として継続できなければプロダクトを提供し続けられません。反対に、売上だけを重視して利用者の負担を増やすと、長期的な信頼を失う可能性があります。
PdMは、利用者が得る価値と、事業として得たい成果の両方を考えます。顧客がプロダクトを使い続ける理由と、企業が投資する理由をつなげる力が必要です。
そのため、顧客の業務理解だけでなく、収益の仕組み、販売方法、競合状況、事業目標への理解も役立ちます。
関係者を巻き込んで合意をつくる力
PdMは、権限だけでチームを動かす立場ではないことも多くあります。そのため、関係者が納得して動けるように、背景と目的を共有し、対話を進める力が求められます。
意見が対立した場合は、誰かの主張を通すことではなく、顧客価値、事業目標、開発上の制約といった共通の判断基準へ戻ることが重要です。
相手の専門性を尊重し、必要な情報を分かりやすく伝え、意思決定の理由を残すことが、信頼関係につながります。
データを読み取り判断する力
PdMには、利用データや事業データを読み、判断に活かす力が必要です。高度な分析手法を最初から使いこなす必要はありませんが、指標の意味を理解し、変化の理由を考える力が求められます。
たとえば、利用者数が増えていても、継続率が下がっている場合があります。その場合は、どの顧客層が増えたのか、利用開始後のどの段階で離脱しているのかを確認します。
数字を根拠にしつつ、数字だけで判断しないことも大切です。顧客の声や現場の状況と組み合わせて考えます。
開発やデザインの基礎知識
PdMが自分でプログラムを書くことや、デザインを作ることが必須とは限りません。しかし、開発の進め方、技術的な制約、画面設計の基本を知っていると、エンジニアやデザイナーとの会話が円滑になります。
たとえば、機能追加には開発だけでなく、設計、テスト、運用準備が必要であることを理解していれば、現実的な計画を立てやすくなります。
基礎知識を身につける方法としては、開発会議への参加、デザインレビューの見学、小さな改善プロジェクトの経験、書籍や研修での学習などがあります。
PdMを目指すための経験の積み方
PdMになるための決まった経路はありません。エンジニア、プロジェクトマネージャー、営業、マーケティング、デザイナー、カスタマーサポート、事業企画など、さまざまな職種から目指せます。
大切なのは、今の職種で得られる強みを活かしながら、顧客理解、事業理解、開発連携、改善の経験を広げることです。
エンジニアからPdMを目指す場合
エンジニアは、技術的な実現可能性、開発の難しさ、保守性を理解している点が強みです。開発チームとの信頼関係を築きやすく、現実的な企画や優先順位付けに貢献できます。
一方で、PdMを目指す場合は、顧客や事業に触れる機会を増やすことが重要です。顧客ヒアリングへの同席、営業やカスタマーサポートとの情報交換、利用データの確認、企画書の作成などに取り組むとよいでしょう。
技術的に優れた解決策だけでなく、どの課題を優先するべきかを考える経験を積むことが必要です。
プロジェクトマネージャーからPdMを目指す場合
プロジェクトマネージャーは、進行管理、リスク管理、関係者との調整、チーム運営の経験をPdMの仕事に活かせます。開発を計画どおり進める力は、プロダクト開発でも重要です。
PdMを目指す場合は、実行管理に加えて、企画の上流に関わる経験を増やします。顧客課題の調査、プロダクトの方針づくり、指標設計、機能の優先順位付けなどに取り組みます。
「決まったものをどう実現するか」から、「何を実現するべきか」へ視点を広げることが転向のポイントです。
営業やマーケティングからPdMを目指す場合
営業やマーケティングの経験者は、顧客の課題、市場の動き、競合との差別化、価値の伝え方を理解している点が強みです。顧客に近い情報を企画に活かせます。
PdMを目指す際は、開発やデザインの基礎知識を身につけ、実現可能性を考慮した企画を作れるようにすることが重要です。開発チームとの定例参加、要件整理の支援、簡単な画面案の作成、利用データの分析などから始める方法があります。
顧客要望をそのまま持ち込むのではなく、共通する課題を整理し、プロダクトとして解決する視点を持つことが求められます。
小さな改善企画から実績をつくる方法
未経験からPdMを目指す場合は、大規模な新規事業や新機能の企画を最初から担当する必要はありません。まずは、小さな改善を一貫して担当する経験を作ることが有効です。
取り組む流れは、次のように整理できます。
- 利用者や社内メンバーから課題を集める
- 課題の背景と対象者を整理する
- 改善案と期待する成果を考える
- デザイナーやエンジニアと実現方法を検討する
- リリース後に利用状況や反応を確認する
- 結果と学びを次の改善につなげる
重要なのは、機能を作った実績だけではなく、なぜその課題を選び、どのような根拠で判断し、結果から何を学んだかを説明できることです。
PdMの求人で確認したい仕事内容と組織体制
PdMの求人は、企業によって仕事内容が大きく異なります。応募前には、職種名だけでなく、具体的な担当範囲を確認することが重要です。
確認したい主な項目は以下のとおりです。
- 担当するプロダクトの種類と成長段階
- 新規企画と既存プロダクト改善のどちらが中心か
- 顧客ヒアリングや利用データ分析を行う機会があるか
- 要件整理、優先順位付け、開発進行のどこまでを担うか
- エンジニア、デザイナー、営業、カスタマーサポートとの連携体制
- PdMの意思決定権限と、最終決定者
- プロダクトの目標や評価指標が明確か
- 一人で複数の役割を兼任する体制か、専門職と分担する体制か
PdMは、プロダクトの企画から改善まで幅広く関わる仕事です。だからこそ、どのような顧客課題に向き合い、どのようなチームで価値を届けるのかを確認し、自分の経験や目指すキャリアに合う環境を選ぶことが重要です。
