コトラ（広報チーム） 
PdMの基本知識
PdMの意味と定義
PdMは、プロダクトマネージャーを指す言葉です。プロダクトとは、利用者に価値を提供する製品やサービスのことをいいます。Webサービスやアプリ、業務システム、ソフトウェアなどが代表例です。
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がプロダクトの方向性や開発の優先順位に落とし込む形になることがあります。
組織規模が小さい場合は、事業責任者が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として経験を積むと、より大きなプロダクトや複数のプロダクトを担当する役割へ進むことがあります。担当領域を広げ、プロダクト全体の方針やチームの進め方に関わる機会も増えます。
また、プロダクトづくりの経験を生かして、事業責任者、企画部門の責任者、プロダクト組織のマネジメントなどを目指す道もあります。利用者の課題と事業の成果を結び付ける視点は、幅広い仕事で役立ちます。
一方で、管理職を目指すだけがキャリアの選択肢ではありません。特定の領域に深く関わり、複雑な課題を持つプロダクトを担当するなど、専門性を高める働き方もあります。自分が利用者課題の発見、事業づくり、組織づくりのどこに強い関心があるかを考えながら、キャリアを選ぶことが大切です。
