プロダクトマネージャー

一言でいうと

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

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

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

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

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

ミッション

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

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

主な業務範囲

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

求められる能力

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

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

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

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

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

隣接職種との違い

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

• 求人票では、決定権の範囲を具体的に書いてください。仕様をまとめる役割なのか、優先順位まで決められるのかで、応募してくる層が変わります
• 経歴書では、断った意思決定を確認してください。作った機能の一覧しか出てこないなら、直近で断った要望とその理由を挙げてもらってください
• 開発チームとの関係を伝えてください。要望を渡すだけの関係か、一緒に仕様を作る関係かで、候補者の働き方が変わります
• 同じ呼称でも、担当する範囲と決定権は企業によって違います。一領域の仕様と優先順位を担う置き方（ミドル層と呼ばれることが多い）と、プロダクト全体の方針、複数領域の順序、他のプロダクトマネージャーへの支援まで担う置き方（リード層）があります。等級名だけでなく担当範囲を求人票に書かないと、面接で期待値がずれます
• 事業の段階によって、確認する経験の重点も変わります。0→1では顧客と課題を確かめた経験、1→10では伸ばす指標を定めて既存の機能を改善した経験が重く見られます。ただし実際の業務は両方を含むため、段階名だけで判断せず、本人が担った課題と意思決定を確認してください

求人・市場の傾向

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

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