プロダクトマネージャー転職ガイド

プロダクトマネージャーの成果物は、納期どおりのリリース表ではありません。誰のどんな困りごとに対して、何を作らず、何を先に出すかを決めることです。転職先を見るときは、カンバンの運用経験より、課題の発見と優先順位の根拠が見えるかを優先してください。

Discoveryは要件ヒアリングの言い換えではありません。すでに決まった画面を聞き取る仕事と、作る前に仮説を捨てる仕事は別です。後者では、インタビューの質問、観察した事実、捨てた案、残した案の4点が残ります。前者では議事録とチケットが残ります。職務経歴では、どちらを何件担当したかではなく、どちらを自分の責任にしたかを書いてください。件数の誇張は不要です。

Discovery

仮説を立て、利用者や現場の事実で検証し、作る前に捨てる選択肢を増やします。インタビュー、ログ、問い合わせ、営業の声など、根拠の種類を明示します。

ロードマップ

時期表ではなく、いま投資する理由の列です。依存関係、学習の順番、やらないことをセットで説明します。日付だけが先行している表は計画ではなく願望です。

Deliveryとの切り分け

作ると決めたあとの分解、見積もり、リリースはDeliveryです。Discoveryの時間が取れない組織では、PdMが進捗係になりやすいです。求人を見るときは、探索の時間がカレンダー上にあるかを確認します。

指標の所有

画面の公開ではなく、追跡する指標の定義、計測方法、異常時の打ち手まで自分の仕事にするかを決めます。定義できない指標は成果にできません。

ステークホルダー調整

開発、デザイン、営業、法務、経営の利害を、プロダクトの制約として翻訳します。調整そのものが目的になると、優先順位が消えます。

同じ「PM」でも、完了責任と価値責任は別物です。ITプロジェクトマネージャーの成果は、範囲・期限・品質を合意どおりに運ぶことです。PdMの成果は、作ったものが利用者と事業の両方に意味を持つかです。エンジニア出身のPdMは、実装可能性を早く見抜ける一方、技術的興味で優先順位を歪めやすい、という癖もセットで説明できると信頼されます。

PdM求人は「事業を伸ばす」「ユーザー中心」といった抽象語が多くなります。単語を覚えるより、その単語の後ろに誰の意思決定があるかを読む方が判断しやすいです。

• 対象プロダクト（社内向け、消費者向け、B2B）が書いてある
• Discoveryの時間とDeliveryの時間の比率を面談で確認できる
• 成功指標の例が書いてある、または定義プロセスが聞ける
• エンジニア、デザイン、営業との役割分担が分かる
• 「DX推進」とだけ書かれ、プロダクトの境界がない求人は詳細を確認する

エンジニア経験は、見積もりの根拠と技術的リスクの説明に使えます。一方、実装した機能の一覧だけを成果にすると、PdM面接では「なぜそれが必要だったか」が抜けます。プロジェクト完了の話と、利用者の変化の話を分けて書いてください。

1. 01
   捨てた案を1つ書く

   作らなかった機能、縮小した範囲、後回しにした要望を具体化します。捨てた理由が、優先順位の説明になります。

2. 02
   仮説と検証を時系列にする

   何を信じ、何で疑い、何を観察したかを順に話します。検証できなかった場合は「未検証」と書き、成功談に書き換えません。

3. 03
   指標の定義を書く

   分子、分母、計測期間、除外条件を説明できる指標だけを使います。定義が社外秘なら、種類（活性化、継続、品質）だけに留めます。

4. 04
   自分で決めたことと、与えられたことを分ける

   課題選定、優先順位、実験設計、リリース判断のうち、自分が判断した範囲だけを強調します。チーム成果と個人成果を混ぜないことが信頼につながります。

IPAのデジタルトランスフォーメーション関連資料は、デジタル化を個別システムの導入ではなく、業務や価値提供の変え方として捉える公式の入口です。PdM面接では「DXを推進した」より「どの業務の何を変える仮説を持ったか」が聞かれます。確認できない全社変革の規模は語らず、自分が触れたプロダクト境界だけを話してください。

• 課題の出所

  経営方針、営業案件、問い合わせ、ログ異常のどれが起点か。起点が一つに偏っていないか。

• 検証の単位

  インタビュー、プロトタイプ、段階リリース、オフライン実験のどれを使えるか。使えない制約も明示する。

• やらないこと

  ロードマップに載っていない要望の扱い。再見積もりの頻度。例外承認の経路。

• 学習の共有

  失敗した仮説が次の優先順位に残るか。個人の記憶で終わっていないか。

PdM求人は、Web事業会社、受託の企画寄り、事業会社のDX部門、スタートアップに分散します。1社の提案だけで「PdM市場」を判断しない方が安全です。プロダクト開発に詳しい相談先と、ITプロジェクト職も扱う相談先を併用すると、役割の違いが見えます。

• IT・Web領域に詳しいサービスでプロダクト職の求人を確認する
• ハイクラス志向の求人では、意思決定権と部下の有無を確認する
• 最新の募集条件は各公式サイトと面談で確認する

PdMの肩書でも、配属先で見える景色は変わります。単一プロダクトのオーナーなのか、複数事業の横断なのか、社内システムの企画なのかを、組織図の話として聞いてください。同じ「優先順位」でも、評価される成果が「学習が速いこと」なのか「関係者を怒らせないこと」なのかが違います。

キャリアの次の一手は、必ずしも「マネージャーへ進む」ではありません。特定領域のドメイン専門、グロース、プラットフォーム、デザインとの協働など、プロダクト側で専門性を深める道もあります。面接では、今の希望だけでなく、2年後に責任を持ちたい範囲も話せるようにします。

実装ができることは強みです。ただし、技術的に面白い案を優先したり、見積もりを守るためにDiscoveryを省略したりすると、PdMとしては弱く見えます。技術の話は「制約の説明」に使い、価値の話は「利用者と指標」に戻してください。

• PMとPdMを同じ経歴に混ぜる

  進捗管理の成功と、課題発見の成功は別の話です。見出しを分けて書いてください。

• フレームワーク名だけで比較する

  スクラムもOKRも、使い方次第で仕事内容は変わります。会議体より、否決した案件を先に話します。

• 確認できない事業数字を書く

  GMVやARRなど、分母と計測期間が言えない数字は外します。

• 希望職種を広げすぎる

  PdM、ITのPM、事業企画を全部希望にすると、提案が散らばります。今回の応募軸は1つにします。

失敗は能力不足の証明ではありません。どこで認識がずれたかを言語化できる人が、プロダクト職では早く信頼されます。面談では、うまくいった案件だけでなく、出してから使われなかった機能をどう扱ったかを1つ用意してください。

1. 01
   プロダクト境界を1枚にする

   利用者、課題、今の解決、測っていること、測れていないことを四角で描きます。ツール名は後回しで構いません。

2. 02
   優先順位の失敗を1件だけ深掘りする

   何を優先し、何が起き、次に何を変えたかを各3行で書きます。数字が不明なら「不明」と書き、推測で埋めません。

3. 03
   希望する担当範囲を選ぶ

   Discovery寄り、Delivery寄り、社内業務寄り、成長事業寄りから、今の希望を1つに絞ります。

4. 04
   相談先を2系統用意する

   Webプロダクト職に強い相談と、ITプロジェクト職との切り分け相談を分けます。同じ求人を重複応募しないよう一覧を作ります。

PdM転職は、華やかな成長物語より、捨てた案と測れなかったことの話で差がつきます。何を発見し、何を後回しにし、何の指標を自分の責任にするか。この3点を自分の言葉で説明できると、求人比較も面接も具体になります。条件の最終確認は、応募先の公式情報と面談で行ってください。

指標の所有は、ダッシュボードの閲覧権限ではありません。定義、計測、異常時の次の一手、やらない判断まで含みます。活性化、継続、品質のように種類だけ言える状態と、分子分母を説明できる状態は違います。後者だけを成果に使ってください。GMVやARRの改善幅は、計測期間と自分の関与が言えないなら職務経歴から外します。

• 指標の定義を自分の言葉で話せる
• 異常が出たときの打ち手が決まっている、または未定だと認められる
• 営業数字とプロダクト指標を混ぜていない
• 確認できない他社事例を目標に置いていない

IPAのDX関連資料は、個別システムの導入をデジタル化と呼ぶことの危うさを考える入口になります。PdMとしては、全社変革のスローガンより、自分が触れるプロダクト境界での仮説検証を話してください。境界の外の成果は、想像で補わないことが信頼です。

応募書類では、ロードマップの画像より、捨てた案の理由を先に置きます。エンジニア出身なら、見積もりの根拠は強みですが、工数で優先順位を決めた話だけだとPdMとしては弱いです。利用者の変化が観測できなかった場合は、観測できなかったこと自体を書いてください。確認できないGMVは置かない、というルールを書類の段階で固定します。

PdM面接は、自分の経歴を話す時間と同じくらい、相手の意思決定を聞く時間です。直近で否決した機能、Discoveryに使っている時間、指標の定義者、エンジニアが仕様に口を出せるか。この4点が空のまま入社すると、進捗管理の仕事に寄ります。質問は批判ではなく、自分の希望する責任範囲と合うかを確認するためのものです。