こんにちは！とも（@tomo_ITBizBlog）です！
本記事はこんな悩みを解決！
- 求人で見る「PM」が、プロダクトマネージャーなのかプロジェクトマネージャーなのか分からない
- PdM（プロダクトマネージャー）が具体的に何をする仕事なのかイメージできない
- エンジニアからPdMを目指す場合に、どんな順番で進めばいいか知りたい
この記事で分かること
- PdMの仕事内容と、PM（プロジェクトマネージャー）との決定的な違い
- 日本の求人で「PM」表記が両義的になる理由と、見分け方
- PdMのメリット・デメリットと、1年目に詰まりやすい構造
- エンジニアの実装経験からPdMへ寄せていく、現実的な順番
まず筆者の立ち位置を、正直に書いておきます。
筆者は、プロダクト企画の専任（PdM）として働いた経験はありません。運用監視からキャリアを始め、インフラ、クラウド（AWS）、生成AIと、ずっと「作る側＝実装側」の仕事をしてきました。
その実装側の現場で、受託開発やフリーランス案件を通じて「何を作るかを決める側」の人たちと一緒に仕事をしてきた立場から、この職種を整理します。
体験談ではなく、公開情報と実装側から見た実像をもとにした「職種の地図」として読んでください。
【プロダクトマネージャー（PdM）とは？「何を作るか」を決める仕事】
プロダクトマネージャー（PdM）は、Webサービスやアプリなどの「プロダクト」について、何を作り、何を作らないかを決める仕事です。
出発点はユーザーの課題です。「ユーザーはどこで困っているのか」を調べ、その課題を解く機能の優先順位を決め、作った結果を事業の指標（継続率や売上など）で検証する。この一連の責任を持つのがPdMです。
「プロダクトのミニCEO」と呼ばれることもあります。ただし、後で触れるように、実際の決裁権の範囲は会社によって大きく違います。
需要の背景には、経済産業省「IT人材需給に関する調査」（2019年公表）の試算で、2030年にIT人材が中位シナリオで約45万人、最も厳しい前提では最大約79万人不足するとされていることがあります。
ただし、この不足の中心は経験者と先端領域です。PdMはその中でも「実務経験を持った人が企画側へ移る」タイプの職種で、未経験からいきなり就く入口職種ではありません。
全職種を「入りやすさ×沼リスク」で整理したカオスマップの記事では、PdMはリーダー・マネジメント寄りのゾーンに置いています。入口は高い代わりに、技術とビジネスの橋渡しができる人材は市場で説明しやすい、という位置づけです。
図で見たい方は、エンジニアキャリアマップもあわせてどうぞ。
【PdMの仕事内容と1日の流れ｜PM（プロジェクトマネージャー）との違い】
PdMの仕事は、大きく次のような流れで進みます。
まず、ユーザー理解です。ユーザーインタビューや問い合わせ内容の分析、利用データの確認を通じて、「いま解くべき課題は何か」を言葉にします。
次に、優先順位付けと仕様策定です。やりたいことは常に山ほどあるため、「今期はこれを作り、これは作らない」を決め、機能の仕様書（要件定義書）やロードマップ（開発計画の見取り図）に落とします。
そして、開発チームとのすり合わせと、リリース後の効果検証です。指標がどう動いたかを見て、次の課題設定に戻ります。
成果物は、コードではなく、ロードマップ、仕様書、課題と指標の設計そのものです。現場の形態は、自社でサービスを持つ会社（自社開発）が中心で、受託の現場では「企画支援」という形で関わるケースもあります。
ここで、この記事の核心であるPMとの違いを整理します。日本の求人では、この2つが同じ「PM」と書かれることが少なくありません。
- PdM（プロダクトマネージャー）：問いは「何を作るか、なぜ作るか」。責任は、課題設定と優先順位、そして事業指標の結果にあります
- PM（プロジェクトマネージャー）：問いは「どう届けるか、いつまでに届けるか」。責任は、スコープ・スケジュール・進捗・リスクの管理にあります。資格のPMPは、こちらの文脈のものです
- PMO：複数のプロジェクトの進捗管理や標準化を支援する立場で、PM側の周辺領域です
見分け方のコツは、求人の仕事内容を見ることです。「ユーザー調査」「KPI設計」「課題定義」が並んでいればPdM寄り、「進捗管理」「顧客折衝」「納期調整」が中心ならプロジェクトマネージャー寄りです。
プロジェクトマネージャー側の仕事と目指し方は、別の記事で整理しています。
【PdMのメリット・デメリット】
良い面と厳しい面を、対にして整理します。ここでは「条件・性質」の話に絞り、1年目の具体的な苦悩は次の見出しで扱います。
メリットは次のとおりです。
- プロダクトの方向性そのものに関われる。「言われたものを作る」側から、「作るものを決める」側に立てます
- 技術・ビジネス・ユーザー理解の3視点が身につくため、キャリアの横展開が効きます
- 成果を事業指標（継続率・課金率など）で示せるため、「何を変えて、どう数字が動いたか」という実績が残ります
- 特定の技術の陳腐化に直接は左右されにくく、経験年数とともに守備範囲が広がります
デメリットは次のとおりです。
- 権限の設計が会社ごとに曖昧で、「責任はあるが決裁権はない」という状態になりやすい職種です
- 会議と調整が仕事の大半を占め、自分で手を動かして作る時間は大きく減ります
- 施策の成果が出るまで時間がかかるため、評価のされ方が会社の仕組み次第になりやすい面があります
- 入口が狭く、「未経験OK」の求人はほぼありません。社内異動か、企画経験を持つ人の転職が中心です
特に1つ目のデメリットは、この職種の本質的な難しさです。「決める仕事」と言いながら、どこまで決められるかは会社次第。この点が、次の苦悩パートの核になります。
【1年目の苦悩と沼ポイント｜「決める仕事」なのに決められない構造】
1つ目は、「決められない」問題です。
PdMは決める仕事ですが、最終的な決裁権は事業責任者や経営層にあることが珍しくありません。要望を集めて、上に確認して、戻って調整する。「要望の集約係」のような動きが続くと、課題設定や優先順位付けという本来のスキルが積み上がりません。
2つ目は、ステークホルダー調整の重さです。
営業は「この機能がないと売れない」と言い、開発は「その工数は出せない」と言い、経営層は「今期の数字に効くものを」と言います。全員を満足させる優先順位は存在しません。誰かの要望を断る判断が日常業務になります。
ここで判断の軸になるのが事業指標です。「どの指標を、どれだけ動かす施策か」で説明できないと、声の大きい人の要望順に並べるだけの優先順位になってしまう、と言われます。
3つ目は、実装の感覚がないと信頼を築けないことです。
開発コストの感覚がないまま仕様を渡すと、「この見積もりは本当に妥当か」「そもそも作れるのか」の会話が噛み合いません。逆に言えば、エンジニア出身者にとっては、実装が分かること自体がPdMとしての分かりやすい強みになります。実装側から見ていても、工数の感覚を持って話せる企画側の人は、現場の信頼を得やすい印象があります。
4つ目は、成果の遅効性です。
施策の効果検証には、どうしても時間がかかります。短期の結果だけを求める空気の中では、小さな改善の連続に追われ、「そもそも解くべき課題は何か」を考える時間が痩せていきます。
大事なのは、これらが個人の努力不足の話ではない、という点です。権限の設計と評価の軸が曖昧なまま「PdM」という肩書きだけが置かれると、誰がやっても同じところで詰まります。だからこそ、応募や異動の前に「どこまで決められる職種なのか」を確認することが、この職種では特に重要になります。
【PdMに向いている人・向いていない人】
向いている人は、次のようなタイプです。
- ユーザーの困りごとを聞き取り、課題を言葉にするのが好き
- 数字（指標）を見て「どれを優先するか」を判断するのが苦にならない
- 意見の違う人同士の間に立ち、調整役を引き受けられる
- 実装の現場感覚があり、開発コストとのバランスで考えられる
向いていない人は、次のようなタイプです。
- コードを書いて何かを作ること自体が、仕事の中心でないと物足りない
- 曖昧な状況や、白黒のつかない判断が続くことが強いストレスになる
- 自分の担当範囲だけに集中して、他部署との調整は避けたい
向いていない側に当てはまったからダメ、という話ではありません。
「作るもの」より「届け方」の設計に面白さを感じるなら、プロジェクトマネージャー（PM）という道もあります。PM側の仕事内容と目指し方は、別の記事にまとめています。
逆に、実装経験のあるエンジニアで「ユーザーの課題にもっと近づきたい」と感じている人は、PdMは相性がいい進路の1つです。次の手順の章で、その寄せ方を具体的に示します。
【エンジニアからPdMになるための手順】
手順をレベル順に示します。結論を先に言うと、PdMは「いきなりなる職種」ではなく、「実装の土台の上に、課題理解と企画の実績を積んで寄せていく職種」です。
Lv1：実装経験を土台にする
PdMの求人では、開発の実務理解が前提になるものが目立ちます。目安として、エンジニアとしての実務経験を数年積み、「作るのに何が要るか」を肌感覚で分かる状態を作ることが先です。
いきなりPdMを目指すのではなく、まずエンジニアとして現場に入ることが、遠回りに見えて最短ルートになります。
Lv2：ユーザーの課題に触れる工程へ寄る
要件定義、顧客との打ち合わせ、導入支援、サポート対応など、「作る前の工程」に近い仕事を担います。
ここで「ユーザーは何に困っていて、何を頼んでいるのか」の一次情報に触れる経験が、PdMの基礎体力になります。筆者のような受託・フリーランスの働き方でも、顧客の業務を聞き取る工程はこの層にあたります。
Lv3：小さく企画を担い、指標で回す
社内ツールの改善、自分の担当案件での仕様策定など、小さな範囲で「課題を決める→作る→指標で見る」を一巡させます。
大事なのは、感想ではなく指標で結果を見ることです。「何を変えて、数字がどう動いたか」を1件でも語れる実績があると、次の段階の材料になります。
Lv4：成果物で示す
- 企画書・仕様書：課題、対象ユーザー、優先順位の根拠まで書かれたもの
- プロトタイプ：画面の叩き台など、議論の土台になるもの
- 改善の記録：施策と指標の変化をセットにした実績
学習面では、プロダクトマネジメントの基本的な型（課題発見→仮説→検証の進め方）を書籍などで押さえておくと、実務の言葉が揃います。なお、PdM専用の標準資格は確立していないとされ、資格よりも「担った範囲と実績」で評価される職種です。一方で、土台であるエンジニアとしての資格は別です。どの資格から取るかの順番は、IT資格まとめで確認できます。
参入口の現実
現実的な入口は、大きく2つです。
1つは、自社開発の会社でエンジニアとして入り、社内異動でPdMへ移るルート。もう1つは、要件定義や企画寄りの実績を作ってから、経験者採用のPdM求人に応募するルートです。
応募の際は、H2-2で触れた「PM表記の見分け方」を必ず使ってください。「PM募集」でも中身がプロジェクト管理だけの求人は多く、仕事内容に課題定義やユーザー調査が含まれているかを確認することが、ミスマッチを防ぐ一番のポイントです。
なお、これからエンジニアを目指す段階の方は、先にエンジニアとしての入口を固めることが先決です。未経験からエンジニアになる全体の流れは、別記事で段階ごとに整理しています。
【転職・フリーランス・副業で変わるPdMの現実】
まず転職（正社員）です。
PdM求人の中心は、自社でサービスを持つ会社です。求められるのは、開発実務の理解に加えて、要件定義や企画に関わった経験です。未経験枠はほぼない前提で考えてください。
現実線は、「エンジニアとして入社し、企画側へ異動する」か、「要件定義・企画寄りの実績を作ってから応募する」のどちらかです。いずれも、H2-6の順番を踏んだ先にあります。
次にフリーランスです。
「PdM支援」「プロダクト顧問」のような形の案件は存在しますが、対象はプロダクトの責任者を務めた経験のある人が中心です。一般的なエンジニア案件のような受け口の広さはなく、単価も経験と担当範囲で大きく変わるため、この記事では断定しません。
最後に副業です。
週の一部だけPdM業務を支援するような形が一部にはありますが、数は少なく、本業でのPdM実績が前提になります。副業からPdMを始める、という入口は現実的ではありません。
3形態に共通するのは、「PdMは実務経験の上に乗る職種」という一点です。形態の違い以前に、土台と実績をどう積むかが先に来ます。
なお、「何を作るか」ではなく「どう届けるか」を担うプロジェクトマネージャー（PM）は、求人の数も入口の形もPdMとは異なります。両方を見比べてから進路を決めたい方は、PM側の記事もあわせてどうぞ。
＼ 「どう届けるか」を担うPMの仕事と目指し方は ／
【PdMの次のステップ｜上流・組織側・技術側への分岐】
PdMを経験した先の進路は、主に3つの方向に分かれます。
1つ目は、プロダクトの上流へ進む方向です。
シニアPdMやプロダクトリードとして、複数プロダクトの優先順位や、プロダクト戦略そのものを担う立場です。目安は、1つのプロダクトで「課題設定から指標の改善まで」を複数回まわした実績です。
2つ目は、組織側・事業側へ寄せる方向です。
事業企画やPMOのような、複数のプロダクト・プロジェクトを横断して見る立場です。個別のプロダクトから、組織全体の進め方の設計へ関心が移った人の進路になります。PM側のキャリアとの接続は、PMの記事でも触れています。
3つ目は、技術側に戻る・技術と複合させる方向です。
テックリードやエンジニアリングマネージャーのように、技術側のリーダーシップへ進む道です。「決める側」を経験したうえで技術に戻ると、仕様の背景を理解したリーダーとして振る舞える点が強みになります。
そして近年は、AIプロダクトのPdMという複合も出てきています。
生成AIを使ったプロダクトでは、「何が技術的に可能で、何がまだ無理か」の見極めが企画の成否を分けます。生成AIの実装経験を持つ人がPdM側へ寄せる動きは、その実例の1つです。生成AIエンジニア側の実像は、別の記事で整理しています。
どの方向にも共通する条件は、「自分が決めたことと、その結果」を言語化できることです。PdMのキャリアは、肩書きの積み重ねではなく、判断の記録の積み重ねでできています。
【まとめ｜PdMは「何を作るか」を担う役割】
要点を3つにまとめます。
- PdM（プロダクトマネージャー）は「何を作るか」を決める仕事。PM（プロジェクトマネージャー）の「どう届けるか」とは責任の置き場所が違う
- 日本の求人では「PM」表記が両義的。仕事内容に課題定義やユーザー調査があるかどうかで見分ける
- 目指し方の順番は、実装経験→課題に触れる工程→小さく企画を担う→成果物で示す。入口は社内異動か経験者採用が現実線
これから目指す方は、まず今の現場で「作る前の工程」に一歩寄ることから始めてください。
職種全体の地図に戻りたい方は、カオスマップの記事で、PdMと他の職種の位置関係を確認してみてください。
