プロダクトマネージャーの職務経歴書の書き方——経験の見せ方と書類通過のコツ

PdMの職務経歴書は、「何を作ったか」の機能リストを書いても書類選考を通過しにくいです。採用担当者はプロダクトの機能より「その人がどんな判断をして、どんな成果を出したか」を見ています。

「機能一覧」を並べるだけでは通らない理由

PdMの職務経歴書でよくある失敗は、「担当機能」の列挙です。「○○機能のPM担当」「○○サービスの機能企画・開発管理」だけでは、担当範囲はわかっても自分の貢献度が見えません。

採用担当者は「この人のいる/いないで何が変わったか」を職務経歴書から読み取ろうとしています。そのためには機能の種類より、その機能を「なぜ作るべきと判断したか」「どう優先順位をつけたか」「リリース後に何が起きたか」を書く必要があります。

機能を「なぜ作ったか（課題の定義）→ どう動いたか（役割と判断）→ 結果はどうだったか（成果の定量化）」の流れで書くと、書類の説得力が格段に上がります。

成果の書き方：数値がない場合の対処

PdMの成果は「機能リリース後にKPIが○○%改善」という形で書ければ理想ですが、数値が出しにくいケースもあります。

数値が出しにくい場合の代替表現：

• スピード系：「リリースサイクルを○週→○週に短縮」「機能の企画〜リリースまでのリードタイムを○%削減」
• 合意形成系：「5部門にまたがるステークホルダーとの要件合意を○ヶ月で完了」
• 規模系：「月間アクティブユーザー○万人が使う機能のPMを担当」「開発チーム○名・デザイナー○名と協業」
• 意思決定系：「○件の機能候補から○件に絞り込む優先度設計を主導」

成果の数値より「判断のプロセスと根拠」を詳述することで、数値がなくても「この人が考えて動いた」ことが伝わります。

エンジニアからPdM転換を目指す場合の書き方

エンジニアとしての経験からPdM転換を目指す場合は、エンジニア経験をPdMの言語に翻訳することが重要です。

エンジニア経験からPdMらしく書き換える視点：

• 「仕様の曖昧な部分を自分で確認・定義した」→ 「要件が不明確なフェーズで課題を定義し、チームと合意形成した」
• 「バグ修正の優先度を開発チームと議論した」→ 「ユーザー影響度と工数を考慮した修正優先順位の設計に関与した」
• 「ユーザーからのフィードバックを開発に反映した」→ 「ユーザー声のデータ整理と機能改善の提案を行い、PdMの判断材料を作った」

「自分はエンジニアだったが、こういうPdM的な動きをしていた」という証拠を積み上げることで、未経験でも書類の説得力を作れます。

まとめ：PdMの職務経歴書は「課題定義と判断根拠の言語化」に集約される

PdMとして書類選考を通過するための要点は2点です。

1. 機能の列挙ではなく「課題→判断→成果」の流れで書く：採用担当者が見たいのは「この人がいたことで何が変わったか」
2. 数値がなくても「プロセスの質と規模感」で評価を作れる：スピード・合意形成・規模などの指標を活用する

PdM転職の書類準備に迷ったときは、PM職に詳しいエージェントへの相談が有効です。

NEXTPM・PdM向け転職エージェントを比較する