職種・体制

プロダクトマネージャー

（ぷろだくとまねーじゃー／Product Manager）

登場（海外）: 2008年
国内で見られるように: 2016年ごろ
更新: 2026-08-24

一言でいうと

何を作るかを決めて、その成果に責任を持つ職種です。自分では実装せず、利用者にとっての価値・使いやすさ・技術的な実現性・事業としての成立を同時に満たす案を選びます。

この職種の出自と登場時期

米国のソフトウェア企業には以前から置かれていた職務ですが、実務の型として整理されたのは2008年です。この年に Marty Cagan が『INSPIRED』の初版を出し、プロダクトマネージャーを「価値・使いやすさ・実現性・事業の成立を担保する責任者」として定義しました。同書は改訂を重ね、現在も国内外で共通の参照点になっています。

国内では2016年にプロダクトマネージャーカンファレンスが始まり、職種としての議論が加速しました。それまで「企画」「ディレクター」と呼ばれていた職務が、プロダクトマネージャーの名称へ移っていきます。

呼称の衝突に注意が必要です。国内では PM がプロダクトマネージャーとプロジェクトマネージャーの両方を指すため、PdM と PjM で書き分ける慣行があります。求人票でどちらを指しているかは、業務内容で判断してください。

ミッション

問われるのは、作ったものが使われて事業の数字が動いたかどうかです。仕様を決めて出すことではなく、その判断が正しかったかで評価されます。

そのため、作らない判断が仕事の中心に入ります。要望をすべて実装すると開発が滞り、プロダクトの筋も通らなくなります。優先順位を決めて、通さなかった理由を説明する役割です。

主な業務範囲

課題の発見。利用者への調査、データ分析、問い合わせから解くべき課題を特定する
優先順位の決定。ロードマップとバックログを組み立て、順序を決めて説明する
仕様の定義。デザイナーと開発チームと一緒に、実現方法を含めて仕様を固める
効果の測定。リリース後の指標を追い、続けるか作り直すかを判断する
関係者の調整。営業・カスタマーサクセス・経営との間で期待値を揃える

求められる能力

実装はしないものの、開発チームの議論を理解して実現コストを見積もれる水準は求められます。技術的な制約を理解しないまま優先順位を決めると、計画が現実と乖離します。

技術以外では、判断と説明が中心になります。データを読む力、利用者の言葉から本当の課題を取り出す力、そして決めたことを関係者に納得してもらう力が問われます。権限がない状態で人を動かす場面が大半です。

この職種に就く人のキャリア経路

入口は幅があります。エンジニアからの移行、デザイナーからの移行、営業やカスタマーサクセスからの移行、コンサルティングからの移行がいずれも見られます。国内では事業側の企画職からの転換も多くを占めます。

プロダクト組織の責任者や CPO へ進む例が代表的です。事業責任者に回る人、起業する人もいます。

隣接職種との違い

職種	責任の中心	プロダクトマネージャーとの違い
プロジェクトマネージャー	期日・予算・進行の管理	決まったものを届ける。プロダクトマネージャーは何を作るかを決める
プロダクトエンジニア	事業成果まで含めた実装	自分で作る。プロダクトマネージャーは実装しない
Technical Product Manager	技術寄りの領域のプロダクト判断	対象が基盤やAPIなど。プロダクトマネージャーは利用者向け機能が中心
PMM	市場への出し方と訴求	売り方が対象。プロダクトマネージャーは作るものが対象

採用担当の見極めポイント

求人票では、決定権の範囲を具体的に書いてください。仕様をまとめる役割なのか、優先順位まで決められるのかで、応募してくる層が変わります
経歴書では、断った意思決定を確認してください。作った機能の一覧しか出てこないなら、直近で断った要望とその理由を挙げてもらってください
開発チームとの関係を伝えてください。要望を渡すだけの関係か、一緒に仕様を作る関係かで、候補者の働き方が変わります

求人・市場の傾向

需要に対して経験者が不足しており、他職種からの転換で採る前提の募集が増えています。実際の件数は媒体ごとの職種カテゴリの定義で変わるので、自社が使う媒体の検索結果で確認してください。

担当するプロダクトのいまの指標を、伸びている数字も止まっている数字も含めて書いてください。打ち手が想像できる求人にだけ、この層は反応します。