キャリアメディア / 職務経歴書

プロダクトマネージャーの職務経歴書の書き方｜書類通過率を上げる実例テンプレート

職種：プロダクトマネージャー（PdM） ｜更新日 2026/7/4

プロダクトマネージャー（PdM）の職務経歴書は、一般的なビジネス職のそれと根本的に構造が異なる。採用担当者やHiringマネージャーが読むのは「何を担当したか」ではなく、「どのようにプロダクトの意思決定を行い、結果として何が変わったか」という思考と行動の連鎖である。書類通過率を左右するのは、この視点の有無にほぼ集約される。

本記事では、PdM採用の選考実態を踏まえながら、職務経歴書の構成・記述の優先順位・具体的な表現の型を体系的に解説する。

PdM職務経歴書が他職種と根本的に異なる理由

営業職であれば「売上〇〇円達成」、エンジニアであれば「〇〇技術を用いた機能開発」という軸で実績を整理できる。PdMの場合、成果は「自分が直接生み出したもの」ではなく「チームや組織が動いた結果として生まれたもの」であるため、どこまでが当人の寄与なのかが外から見えにくい構造になっている。

採用サイドが職務経歴書で見極めようとしているのは、以下の3点である。

1. 課題発見の質：データや定性情報をもとにどのような問いを立てたか
2. 意思決定のプロセス：トレードオフをどう整理し、なぜその施策を選んだか
3. 結果への責任範囲：KPIの設計者なのか、モニタリングのみなのか

この3点が職務経歴書から読み取れない場合、面接に進む前に「具体性が薄い」と判断される傾向がある。

構成の全体設計

PdMの職務経歴書に適した構成は以下の通りである。一般的な「職歴の羅列」からは大きく外れる。

A4用紙換算で2〜3枚が一般的な目安であるが、マネジメント経験が複数社・複数プロダクトにわたる場合は3枚を超えることも許容される。ただし情報密度が下がる場合は圧縮を優先する。

各セクションの書き方

プロフィールサマリー

書類を読む順序として、採用担当者はまずサマリーを読み、詳細を見るかどうかを判断する傾向がある。ここでは以下の情報を凝縮させる。

• どのドメイン・フェーズのプロダクトに携わってきたか（BtoB SaaS、toC成長期、0→1など）
• チームや組織に対してどのような役割を担ってきたか
• 自身の強みとして認識しているアプローチ（データドリブン、ユーザーリサーチ重視など）

記述例（実例の型）

BtoB SaaSスタートアップにて計5年、SMB向けCRMプロダクトのPdMとして開発ロードマップの策定からリリース後のKPI改善まで一貫して担当。特にユーザーインタビュー・行動ログ分析を組み合わせた課題発見プロセスを強みとし、チャーン率の低減に向けた機能改善を主導。直近では3名のアソシエイトPdMのメンタリングを兼任。

このサマリーから「SMB向けBtoB・成長フェーズ・リテンション改善・ピープルマネジメント経験あり」という情報が30秒以内に伝わる。

スキル・ドメイン領域

ここは箇条書きで整理するが、「エクセルが使える」のような粒度は避ける。PdMとして評価されるスキルは以下の区分で整理すると読みやすい。

• プロダクトスキル：ロードマップ策定、要件定義、PRD作成、ユーザーストーリーマッピング
• 分析・調査：SQL（SELECT〜JOIN程度）、GAやMixpanel等のプロダクト分析、ユーザーインタビュー設計
• ステークホルダー管理：経営・事業部・エンジニア・デザイナーとの合意形成、OKR設計
• ドメイン：HR Tech、フィンテック、ECなど業界固有の知識

使用ツール（Figma、Jiraなど）も列挙できるが、ツール名の羅列より上記カテゴリ軸の方が評価者には伝わりやすい。

職務詳細の記述（最重要）

各プロダクト・各企業の記述において、以下の構造を守ることが通過率に直結しやすい。

①プロダクトの概要と自分の役割の明示

会社名・在籍期間・事業規模（ARR、DAUなど規模感が伝わる指標）・チーム構成を簡潔に記す。「〇〇機能の担当PdM」ではなく「〇〇プロダクト全体のロードマップを所管し、エンジニア5名・デザイナー2名と協働」のように、スコープと責任範囲を明示する。

②課題設定〜施策選定のプロセス

ここが最も差別化できる部分である。「〇〇機能を開発した」という記述では、課題発見から開発に至った思考が一切見えない。下記のような流れで記述することを推奨する。

解約ユーザーへのインタビューと行動ログ分析の結果、初期設定の完了率が低いことがチャーンの主因であると仮説を立て、オンボーディングフローを再設計。A/Bテストを経て本番展開し、初期設定完了率が60%から82%に向上。

③定量的な成果の記載

PdMの成果指標として記載しやすいものは以下の通り。すべてを持っている必要はなく、自分が責任を持って追っていた指標を選ぶ。

数値を記載する際は「〇〇施策を主導した結果、〜が改善した」という因果の形にする。施策と成果が乖離した記述（「在籍中に売上が2倍になった」など）は評価者に懐疑的に読まれる傾向がある。

代表プロジェクト詳述（STAR形式の活用）

1〜2プロジェクトを選び、STAR形式（Situation・Task・Action・Result）で600〜800字程度で詳述する。これは「読ませる」というより「面接前の事前情報」として機能し、面接官の質問を誘導する狙いもある。

記述の型

• S（状況）：プロダクトが置かれた市場・競合・組織の状況
• T（課題）：自分が担うべき問いや責任の定義
• A（行動）：リサーチ・施策立案・チーム調整・実装判断の具体的な手順
• R（結果）：定量・定性の変化。未達の場合は「学びと次のアクション」まで書くとPDCAの意識が伝わる

表記・フォーマットの注意点

• 箇条書きは1行20〜30字程度に抑える
• 動詞は「担当した」より「主導した」「策定した」「合意形成した」など能動的な語を選ぶ
• 時制は「〜しました」ではなく「〜した」で統一（体言止めも可）
• ファイル形式はPDF推奨。フォント・レイアウト崩れを防ぐため

よくある質問

Q1. 0→1フェーズのプロダクトに携わった経験が少ない場合、どう記述すればよいですか？

グロース・改善フェーズの経験であっても、「既存の何を変えるべきかを定義し、優先順位をつけた」という意思決定の文脈が書ければ十分に評価対象になります。「0→1しか評価されない」という前提は実態と異なり、スケールや改善局面での判断経験を求める企業も多くあります。自身の経験フェーズを正直かつ具体的に記述することが最善の対応です。

Q2. 開発経験がないPdMは技術スキルの欄をどう書くべきですか？

エンジニアと同等の技術スキルを持つことは多くのポジションで必須ではありません。「エンジニアとの技術的な会話の範囲」として、API設計の概念理解、データベース構造の基礎、フロントエンド・バックエンドの役割分担程度を把握していれば、その旨を簡潔に記述することで実務上のコミュニケーション能力の裏付けになります。SQLの実務活用経験があれば具体的に示すと効果的です。

Q3. 在籍が短い企業がある場合、どう扱うべきですか？

短期在籍の事実を隠すことは推奨できません。ただし職務経歴書は「短期在籍の理由を説明する書類」ではないため、在籍中に何をしたかを端的に記述し、詳細は面接で誠実に説明する準備をするのが現実的な対応です。なお、プロダクトのPivotや会社都合のリストラなど、外部要因に起因する場合は一行でその旨を添えると誤解を防げます。

Q4. マネージャー経験がない場合、応募できる求人の幅は狭まりますか？

IC（Individual Contributor）としての採用を前提とするPdMポジションは一定数存在します。職務経歴書においては、チーム横断での合意形成やステークホルダーマネジメントの経験を丁寧に記述することで、ピープルマネジメントの有無を補完する文脈を作ることができます。採用要件の「マネジメント経験」が必須か歓迎かを確認したうえで応募判断することを推奨します。

まとめ

PdMの職務経歴書で評価されるのは、肩書や担当機能の一覧ではなく、課題をどう定義し、何を根拠に意思決定し、チームを動かして結果を出したかという思考と行動の可視化である。プロフィールサマリーで全体像を提示し、職務詳細でプロセスと成果を構造的に記述し、代表プロジェクトで深度を示すという三層構造が、選考通過率を高める基本設計となる。数値は「因果の形」で記載し、自身が責任を持って追っていた指標に絞ることが信頼性の担保につながる。現在の職務経歴書が採用担当者にこれらの情報を正確に伝えられているかを点検することが、次のステップへの第一手となる。自身の経験の見せ方や求人との適合度について客観的な視点が必要と感じる場合は、専門のキャリアアドバイザーへの相談が有効な選択肢になりえる。