プロダクトマネージャーの職務経歴書の書き方【2026年版・テンプレート付き】

プロダクトマネージャーへの転職・社内異動を目指すとき、多くの人が「どう書けばいいかわからない」と感じるのが職務経歴書です。PdMの職務経歴書は、一般的な職種のそれとは評価軸が根本的に異なります。この記事では、採用担当者の視点から「何が見られているか」を整理したうえで、構成・実績の書き方・よくある失敗パターンまでを体系的に解説します。

PdMの職務経歴書が一般職と根本的に異なる理由

PdMの採用担当者が職務経歴書で最も重視するのは、「何を作ったか」という成果物の列挙ではなく、「なぜ作ったか・どう意思決定したか」というプロセスと判断軸です。エンジニアやデザイナーの採用では技術力や制作物が評価の中心になりますが、PdMの場合は不確実な状況下での意思決定の質こそが問われます。

採用担当者が職務経歴書で見ているポイント

採用担当者がPdMの書類で確認したいのは、大きく3つです。第一に、プロダクト戦略やロードマップを自分で策定した経験があるか。第二に、エンジニア・デザイナー・ビジネスサイドなど複数のステークホルダーを巻き込んで意思決定を進めた実績があるか。第三に、ユーザーや市場の課題を起点に優先順位を判断できるか、です。

「新機能の開発に携わった」という記述は、エンジニアとしての職務経歴書では十分ですが、PdMとしての書類では不十分です。「なぜその機能を作ることにしたのか」「どのデータや顧客インサイトを根拠に優先順位を決めたのか」という意思決定の文脈が書かれていないと、採用担当者は「この人はPdMとして動けるのか」を判断できません。

エンジニア・デザイナー出身者が陥りがちな書き方の罠

エンジニアやデザイナーからPdMへのキャリアチェンジを目指す人が最も陥りやすいのが、技術スタックや実装の詳細を書きすぎてしまうパターンです。「React・TypeScriptを用いてフロントエンド開発を担当」という記述は、PdMとしての意思決定の経験を何も伝えていません。採用担当者は「この人はエンジニアとして優秀なのだろう」と読み取るだけで、PdMとして採用する根拠を見つけられません。

必要な視点の転換は、「開発に参加した」から「プロダクトの方向性を決めた」への移行です。たとえば「技術的負債の解消とユーザー向け新機能開発のどちらを優先するかを判断し、四半期ロードマップに反映した」という記述であれば、PdMとしての職責が明確に伝わります。自分が実際に行った意思決定・仕様策定・優先順位付けの経験を掘り起こし、それを前面に出すことが重要です。

PdM職務経歴書の基本構成とテンプレート

職務経歴書を書き始める前に、全体の構成を決めておくことで迷いがなくなります。PdMの職務経歴書に適した構成は、5つのブロックに分けて考えると整理しやすくなります。

推奨フォーマット：5ブロック構成

推奨する構成は、①職務要約（3〜5行）→ ②担当プロダクト一覧 → ③職務詳細 → ④スキルセット → ⑤自己PRの順です。この順番には理由があります。採用担当者は最初の30秒で「この人を面接に呼ぶか」を判断するため、冒頭の職務要約で全体像を掴めるようにしておく必要があります。担当プロダクト一覧を早い段階に置くことで、どのドメイン・フェーズの経験があるかを素早く把握してもらえます。

ページ数はA4換算で2〜3枚が適切です。1枚では情報が不足しており、PdMとしての経験の深さを伝えきれません。一方、4枚以上になると読まれないリスクが高まります。職務詳細が長くなりがちな場合は、直近3〜5年の経験を厚く書き、それ以前は簡潔にまとめる方針で調整しましょう。

職務要約欄：採用担当者が最初に読む30秒を制する

職務要約は、職務経歴書全体の「エグゼクティブサマリー」です。ここで採用担当者の関心を引けなければ、詳細を読んでもらえない可能性があります。書くべき内容は「どのフェーズのプロダクトを・何人規模のチームで・どんな成果を出したか」の3点を3文程度に凝縮することです。

例として、「BtoB SaaSプロダクトの0→1フェーズから1→10フェーズにかけて、エンジニア5名・デザイナー1名のチームでPdMを担当。ユーザーインタビューとデータ分析を組み合わせたロードマップ策定を主導し、リリース後12ヶ月でARR 1億円を達成。現在は新規事業の立ち上げと既存プロダクトの成長を並行して推進中」のような記述が理想的です。職種・ドメイン・フェーズ・成果が一目でわかる構成になっています。

職務経歴書の方向性が固まったら、Granty のPdM特化転職エージェントに添削を依頼することで、応募先企業の採用基準に合わせた具体的なフィードバックを受けることができます。

担当プロダクト・実績の書き方：数値化と文脈化のコツ

職務経歴書の中で最も差がつくのが、実績の書き方です。「何をしたか」の羅列ではなく、「どんな課題に対して・どう判断して・どんな成果を出したか」を数値と文脈で示すことが、PdMとしての能力を伝える核心です。

KPI・ビジネス指標を使った実績の数値化

実績を書く際は、プロダクト固有のKPIをBefore/Afterの形式で示すことが最も説得力を持ちます。DAU（デイリーアクティブユーザー数）・継続率・NPS（ネットプロモータースコア）・売上貢献額・チャーンレートなど、担当プロダクトの事業モデルに合った指標を選びましょう。「機能Xをリリースした結果、3ヶ月後のDAUが15万から18万に増加（+20%）」のように、施策と結果を紐づけて記述します。

数値が出せない場合でも、意思決定の質を示す代替指標があります。「四半期ロードマップから廃棄した機能数（優先順位判断の厳格さ）」「開発リードタイムの短縮幅」「ユーザーインタビューの実施件数と得られたインサイトの数」などは、数値化しにくい意思決定プロセスを可視化する有効な手段です。NDAや機密保持の関係で具体的な数値を出せない場合は、「前年比XX%改善」「業界平均と比較してYY%高い水準」のような相対値での表現も有効です。

プロダクトのフェーズ・規模感を明示する

採用担当者がミスマッチを防ぐために必要な情報として、プロダクトのフェーズと規模感があります。0→1（新規立ち上げ）・1→10（初期グロース）・10→100（スケール）のどのフェーズを経験しているかを明記することで、応募先企業が求める経験と自分の経験が合致するかを双方が判断しやすくなります。

規模感を示す情報としては、ユーザー数・ARR（年間経常収益）・チーム規模・予算規模などが有効です。「MAU 50万のコンシューマーアプリ」「ARR 3億円のBtoB SaaS」「エンジニア8名・デザイナー2名のスクラムチーム」のような文脈情報を添えることで、採用担当者は自社のプロダクト規模と比較しながら読むことができます。

意思決定プロセスの記述：STAR法のPdM版

実績を記述する際の構造として、STAR法（Situation・Task・Action・Result）のPdM版が有効です。Situation（どんな課題・市場環境があったか）→ Task（自分の役割・責任範囲）→ Action（どう判断し・どんな施策を打ったか）→ Result（定量・定性の成果）の順で記述します。

PdMとしての差別化ポイントは、Actionの部分に「なぜその優先順位にしたか」の根拠を1文添えることです。「競合3社の機能比較と既存ユーザー20件へのインタビューから、検索精度の改善が最優先課題と判断した」のような記述は、データと顧客インサイトを組み合わせた意思決定ができるPdMであることを示します。この1文があるかないかで、書類の印象は大きく変わります。

スキルセット欄の書き方：PdMに求められる能力を正しく伝える

スキルセット欄は、ツール名や手法名を羅列するだけでは採用担当者に何も伝わりません。PdMに求められる能力を3つのカテゴリに整理し、それぞれに具体的な活用場面を添えることで、実践的なスキルとして伝わります。

PdMスキルの3分類で整理する

PdMのスキルは大きく3つに分類できます。①プロダクト発見（ユーザーリサーチ・仮説検証・ジョブ理論の活用）、②プロダクト提供（ロードマップ策定・スプリント管理・仕様書作成・リリース判断）、③ビジネス（P&L管理・ステークホルダー調整・KPI設計・事業戦略との整合）です。この3分類に沿って自分のスキルを整理することで、採用担当者が求める能力との対応関係が明確になります。

自分の強みがどの分類に集中しているかを把握することも重要です。たとえばエンジニア出身であれば②プロダクト提供の経験は豊富でも、①の定性リサーチや③のP&L管理の経験が薄い場合があります。弱い領域を隠すのではなく、「現在補強中」として学習中の取り組みを添えることで、成長意欲を示すことができます。

ツール・手法の書き方：ただの列挙を避ける

「Figma・Jira・Notion・Miro使用可」のような列挙は、スキルセット欄として最も避けるべき書き方です。ツールはあくまで手段であり、それを使って何を達成したかが重要です。「Figmaでプロトタイプを作成し、ユーザーインタビュー20件を実施して仕様を3回改訂した」のように、ツールの使用を具体的な成果と紐づけて記述しましょう。

SQLやデータ分析スキルは、技術系PdMポジションへの応募で特に有効です。「BigQueryを用いてユーザーの行動ログを分析し、離脱ポイントを特定してオンボーディングフローを改善した」のような記述は、データドリブンな意思決定ができるPdMであることを示します。ツール名だけでなく、「何のためにどう使ったか」を必ず添えることを習慣にしましょう。

未経験・異職種からの転職：経験をPdM文脈に翻訳する方法

PdMへのキャリアチェンジを目指す場合、「PdMとしての職歴がない」ことを理由に職務経歴書を書くことを躊躇する人が多くいます。しかし、エンジニア・営業・コンサルタント・カスタマーサクセスなど、多くの職種にはPdMの職責と重なる経験が含まれています。重要なのは、その経験をPdMの文脈に翻訳して記述することです。

職種別：PdM経験への翻訳パターン

エンジニア出身の場合、技術的負債の解消と新機能開発のどちらを優先するかを判断した経験や、仕様の曖昧な部分をPdMや事業責任者と議論して決めた経験は、PdMとしての意思決定能力の証拠になります。「技術的負債の解消を優先するよう提案し、四半期の開発計画に反映させた」のような記述は、エンジニアとしての経験をPdM視点で翻訳した好例です。

営業・カスタマーサクセス出身の場合は、顧客課題の構造化とプロダクト改善への接続が強みになります。「顧客からのフィードバック50件を分類・優先順位付けし、開発チームへの機能改善提案として取りまとめた」「解約理由の分析からプロダクトの根本課題を特定し、改善提案を経営層にプレゼンした」のような経験は、PdMに求められるユーザーインサイトの活用能力を示します。コンサルタント出身であれば、課題の構造化・仮説検証・ステークホルダーへの提言プロセスがそのままPdMの職責と重なります。

サイドプロジェクト・社内新規事業の書き方

個人開発・ハッカソン参加・社内の0→1プロジェクトへの関与は、PdMとしての実践経験として有効に活用できます。特に「プロダクト発見（課題設定・ユーザーリサーチ）からリリース・改善サイクルまでの全工程を経験した」ことを示せる場合は、職務経歴書の中で独立したプロジェクトとして記述する価値があります。

書き方のポイントは、規模の小ささを謝罪するのではなく、意思決定の質を前面に出すことです。「個人開発のWebアプリで、ユーザーインタビュー10件を実施して機能仕様を決定し、リリース後のフィードバックを基に3回の改善を行った」という記述は、PdMとしての思考プロセスを示す証拠として十分機能します。

企業規模・業種別：職務経歴書のカスタマイズ戦略

同じ経験を持つ人でも、応募先の企業規模や業種によって職務経歴書で強調すべきポイントは変わります。一つの「汎用版」を使い回すのではなく、応募先に合わせてカスタマイズすることが通過率を上げる重要な戦略です。

スタートアップ vs 大企業：強調ポイントの違い

スタートアップへの応募では、スピード感・不確実性への耐性・リソース制約下での意思決定経験が評価されます。「情報が不完全な状態でも意思決定を進めた経験」「少人数チームで複数の役割を兼務した経験」「仮説検証サイクルを短期間で回した経験」を前面に出しましょう。0→1フェーズの経験がある場合は、それを職務要約の冒頭に持ってくることが効果的です。

大企業への応募では、ステークホルダー調整力・組織横断プロジェクトの推進経験・コンプライアンスへの配慮・大規模ユーザーベースでのスケール経験が重視されます。「法務・セキュリティ・経営企画など複数部門との調整を主導した」「数百万ユーザーへの影響を考慮したリリース判断を行った」のような記述が刺さります。

BtoB SaaS・BtoC・社内プロダクトで変わる記述の重点

BtoB SaaSへの応募では、顧客ヒアリングの質・契約更新率（ネットリテンション）への貢献・エンタープライズ顧客の複雑な要件を整理して優先順位を判断した経験が評価されます。「大手顧客5社へのヒアリングを通じてエンタープライズ向け機能の仕様を策定し、契約更新率を85%から92%に改善した」のような記述が理想的です。

BtoCプロダクトへの応募では、グロース指標（DAU・MAU・リテンション率）・A/Bテストの設計と解釈・データドリブンな意思決定の実績が重視されます。「A/Bテストを月平均5件実施し、オンボーディングフローの改善で7日間リテンション率を12ポイント向上させた」のような記述が効果的です。社内プロダクト（情報システム・業務効率化ツール）の場合は、業務課題の構造化・現場ユーザーとの合意形成・導入後の定着率改善などを強調しましょう。

よくあるNGパターンと添削例

職務経歴書の書き方を理解していても、実際に書いてみると陥りやすいパターンがあります。採用担当者が「読む気を失う」典型的な3つのパターンと、その改善方法を具体例で確認しましょう。

採用担当者が「読む気を失う」3つのパターン

第一のパターンは、業務の羅列です。「ユーザーリサーチを実施した」「ロードマップを作成した」「エンジニアと仕様を調整した」のように、何をしたかだけが並んでいて、なぜその判断をしたか・どんな成果が出たかが一切書かれていない状態です。採用担当者は「この人がPdMとして機能するか」を判断できません。

第二のパターンは、主語が「チームで」ばかりで自分の貢献が不明確なケースです。「チームで新機能を開発し、リリースした」という記述では、自分がどの部分に責任を持ち、どんな判断をしたかが全く伝わりません。「私が主導して〜」「私の提案により〜」のように、自分の貢献を明確に示すことが必要です。ただし、チームの成果を一人で成し遂げたかのように誇張することは避け、「チームをリードして〜を達成した」のような表現でバランスを取りましょう。

第三のパターンは、社内略語や専門用語が多く、文脈なしでは意味が取れない記述です。「XXXプロジェクトのPMOとしてYYYシステムのZZZ対応を推進」のような記述は、社内の人間にしか意味が伝わりません。社内固有の略語・プロジェクト名・システム名は必ず一般的な言葉で補足説明を加えましょう。

添削例：ビフォーアフターで見る改善ポイント

具体的な添削例を見てみましょう。

NG例：「新機能の開発を担当し、リリースした。」

OK例：「競合3社の機能比較と既存ユーザー15件へのインタビューを基に機能仕様を策定。エンジニア4名・デザイナー1名のチームをリードし、スプリント6回でリリースを実現。リリース後3ヶ月でDAUが20%向上し、ユーザーからの機能要望数が月間50件から12件に減少した。」

改善のポイントは3つです。①意思決定の根拠（競合調査とユーザーインタビュー）を明示した、②自分の役割（チームリード・仕様策定）を明確にした、③定量的な成果（DAU+20%・要望数減少）を示した。この3点を意識するだけで、採用担当者が「この人はPdMとして機能する」と判断できる記述に変わります。

職務経歴書を書いたら：提出前チェックリストと次のステップ

職務経歴書を書き終えたら、提出前に必ずセルフチェックを行いましょう。また、PdM特化のエージェントに添削を依頼することで、自分では気づきにくい改善点を発見できます。

提出前セルフチェック10項目

以下の10項目を確認してから提出しましょう。

1. 各プロジェクトに「意思決定の根拠」が記述されているか
2. 各プロジェクトに「定量的な成果」または「意思決定の質を示す代替指標」があるか
3. 担当プロダクトの「フェーズ（0→1 / 1→10 / 10→100）」が明記されているか
4. 主語が「チームで」ばかりになっておらず、自分の貢献が明確か
5. 社内略語・固有名詞に補足説明が付いているか
6. 職務要約欄で「ドメイン・フェーズ・成果」の3点が3〜5文に凝縮されているか
7. スキルセット欄がツール名の列挙ではなく、活用場面と紐づいているか
8. A4換算で2〜3枚に収まっているか
9. 誤字脱字・表記揺れ（「プロダクト」と「プロダクト」の混在等）がないか
10. ファイル形式がPDF（レイアウト崩れ防止）になっているか

PdM特化エージェントに添削を依頼するメリット

一般的な転職エージェントでは、PdMの職務経歴書における「プロダクト戦略の見せ方」や「意思決定プロセスの記述の質」を適切に評価できないケースが多くあります。PdM特化のエージェントであれば、採用担当者がどの記述を重視するかを熟知しており、「この実績はもっと具体的に書けます」「このプロジェクトの意思決定プロセスを追加してください」のような的確なフィードバックが得られます。

また、応募先企業の採用基準に合わせたカスタマイズ提案も受けられます。スタートアップと大企業では強調すべき経験が異なり、BtoB SaaSとBtoCでは評価されるKPIも変わります。自分一人で書いた職務経歴書を、応募先の文脈に最適化する作業は、専門家のサポートがあると大幅に効率化できます。

職務経歴書の添削から応募先の選定まで、Granty のPdM特化転職エージェントでは無料でご相談いただけます。PdMとしてのキャリアを次のステップに進めたい方は、ぜひお気軽にご利用ください。