プロダクトマネージャーの職務経歴書｜実績の書き方を例文付きで解説

採用担当が知りたいのは、入社後にどのプロダクトのどの範囲を任せられるかです。そのために職務経歴書には、担当したプロダクトと事業フェーズ、解決したユーザー・事業課題、自分が担った意思決定と責任範囲、生まれた成果という4点を記載しましょう。ここでは、それぞれの示し方を解説します。
 

1-1. 担当したプロダクトと事業フェーズを示す

担当プロダクトは、事業モデルと利用規模、そして立ち上げ期かグロース期か成熟期かというフェーズまで書くと、経験の再現性が伝わります。同じプロダクトマネージャーでも、BtoB向けSaaSの契約更新を伸ばす仕事と、コンシューマー向けアプリの継続率を上げる仕事では、追う指標も意思決定の速度も変わるためです。

盛り込む要素は、プロダクトの領域と提供形態、想定ユーザー、月間利用者数や導入社数といった規模、開発体制の人数、担当したフェーズの5つです。例えば、「BtoB向けの勤怠管理SaaSで導入企業450社、エンジニア6名とデザイナー1名の体制、グロースフェーズを担当」と書いておくと、その後に続く実績を読むための前提が整います。
 

1-2. どのようなユーザー・事業課題を解決したかを示す

課題は、誰のどの場面での困りごとで、事業のどの指標に影響していたかまで書きます。プロダクトマネージャーの仕事は課題の設定から始まるため、課題をどう定義したかは施策内容とセットで評価される部分です。

課題を書くときは、把握した手段も添えましょう。利用ログの離脱地点、カスタマーサクセスへの問い合わせ内容、解約時アンケート、ユーザーインタビューといった情報源を示すと、事実にもとづいて課題を絞り込んだ過程が伝わります。例えば、「無料トライアル中の初期設定で操作が止まる利用者が一定数おり、有料契約への転換が8%前後で推移していた」というように、ユーザーの状態と事業指標を並べて書くのが基本形です。
 

1-3. 自分が担った意思決定と責任範囲を示す

意思決定は、どこまで自分が決め、どこから他の職種と合意して進めたかを線引きして書きます。プロダクトマネージャーの職域は会社によって幅があり、同じ肩書きでも担当する範囲が異なるためです。決裁に関わった対象を箇条書きで挙げると、責任範囲を短時間で把握してもらえます。

・プロダクトの方向性とロードマップの決定
・四半期ごとの開発優先順位の確定
・要求仕様と受け入れ条件の確定
・リリース可否とタイミングの判断
・価格や課金プランの設計

意思決定の範囲は、組織の体制によって変わります。上位の責任者と合意しながら進める体制であれば、課題の分析から改善案の提示、関係部門との合意形成まで、自分が担った工程を明記しましょう。提案が採用された経緯まで書けば、判断に関与した実績として評価されます。
 

1-4. 施策によって生まれたプロダクト・事業成果を示す

成果は、施策の前後で動いた指標と、その変化を生んだ自分の判断をセットで示します。指標の変化だけではたまたま改善した可能性もあるため、自分の判断を添えることで、成果を生んだ要因まで採用担当に伝わります。

書く順序は、課題、決めたこと、指標の変化、期間が基本です。例えば「初期設定の手順が有料契約への障壁になっていると判断し、3ステップへ再設計する案を選んだ結果、有料転換率を3カ月で8%から12%へ引き上げた」といった形で並べます。プロダクトの改善そのものも成果に含まれます。機能の統合による操作手順の削減や、問い合わせ件数の減少といった変化も、指標と一緒に記載する価値があります。

職務経歴書は、職務要約、職務経歴、スキル・使用ツール、自己PRの4項目で構成するのがおすすめです。ここでは、項目ごとに書く内容と例文を紹介します。なお、例文に登場する数値や社数は、書き方を示すためのサンプルなので、自身の経歴に置き換えてご活用ください。
 

2-1. 職務要約は担当プロダクト・経験領域・主な成果をまとめる

職務要約は、冒頭の3〜5行で経験年数と担当プロダクトの領域、主な成果を凝縮するパートです。採用担当が最初に読み、続きを詳しく読むかを判断する部分にあたります。

まとめる要素は、経験年数と在籍社数、プロダクトの領域と提供形態、携わったフェーズ、代表的な成果1〜2件の4つです。細かい施策名は職務経歴欄に譲り、要約では応募先に近い経験を前に出します。

Webサービス企業2社で、プロダクトマネージャーとして6年間従事しました。BtoB向けSaaSの新規立ち上げから、月間利用者数30万人規模のコンシューマー向けアプリのグロースまでを担当しています。直近では有料プランの申し込み導線を再設計し、有料転換率を3カ月で8%から12%へ引き上げました。ユーザーインタビューと利用ログの分析から課題を定義し、開発チームと優先順位を合意しながら改善を進めてきました。

 

2-2. 職務経歴はプロダクトごとに役割と成果を整理する

職務経歴は、在籍企業単位ではなく担当プロダクト単位で区切ると、役割と成果が読み取りやすくなります。1社で複数のプロダクトを担当した場合でも、プロダクトごとに整理することで、担当範囲と成果の対応関係が明確になります。

1つのプロダクトにつき、概要と規模、体制と自分の役割、課題、決めたこと、成果の順で並べると、採用担当が評価しやすい構成になります。特にアピールしたい内容（貢献度の高いもの、応募先の事業に近いもの）を3〜5件に絞ると、1件あたりの記述量を確保できます。

・プロダクト：勤怠管理SaaS（導入企業450社、エンジニア6名とデザイナー1名の体制）
・役割：要求仕様の策定、四半期ごとの開発優先順位の決定、リリース可否の判断
・課題：無料トライアル中の初期設定で操作が滞り、有料転換率が8%前後で推移
・決めたこと：初期設定を3ステップへ再設計する案を選び、業種別の初期テンプレートの追加を先行して開発
・成果：有料転換率を3カ月で8%から12%へ改善。初期設定の完了率も向上

 

2-3. スキル・使用ツールは実務で使った場面とセットで示す

スキル欄は、習得したスキルや知識と、実務で使った場面をセットで書きます。ツール名に使った場面を添えると、どの深さまで扱えるかが判断の材料になるためです。

分類は、プロダクト業務、分析ツール、開発管理ツール、資格の4つに分けると整理しやすくなります。分析ツールであれば、SQLで抽出から集計まで自分で行ったのか、ダッシュボードの閲覧が中心だったのかまで書き添えましょう。資格は、PMPや応用情報技術者試験など、業務に関わるものを記載します。

・プロダクト業務：要求仕様の策定、ロードマップ策定、KPI設計、ユーザーインタビューの設計と実施（累計80件）、ABテストの設計
・分析ツール：Google アナリティクス（GA4）、Amplitude、BigQuery（SQLでの抽出と集計を担当）
・開発管理ツール：Jira、Confluence、Figma、Notion（仕様書の整備と運用ルールの策定）
・資格：PMP、応用情報技術者試験

 

2-4. 自己PRは意思決定と成果の再現性を実績で示す

自己PRは、強み、それを裏づける実績、転職先で活かせることの順で構成します。強みを抽象的に述べるだけでは不十分で、同じ成果を再び出せる根拠として実績を示すことが重要です。

強みは、プロダクトマネージャーの業務のどの工程で発揮されたかまで書きます。課題定義が強みなら「情報源の集め方と絞り込みの基準」を、合意形成が強みなら「巻き込んだ職種と進め方」を添えると、実務の場面が具体的に浮かびます。

私の強みは、ユーザーの声と利用データを突き合わせて課題を定義し、開発の優先順位を決める進め方です。勤怠管理SaaSでは、解約時アンケートとログ分析から初期設定での操作の滞りを課題として特定し、四半期の開発計画を組み替えて初期設定の再設計を最優先で進めました。その結果、有料転換率を3カ月で8%から12%へ引き上げています。

貴社でも、定性と定量の両面から課題を定義し、開発チームと合意形成をしながら改善を重ねる形で貢献できると考えています。

経歴を具体化する手がかりは、プロダクトの前提、意思決定の過程、他職種との連携、リリース後の検証の4つです。以下では、それぞれについて何を書き足すと、担った仕事が読み手に伝わるのかを解説します。
 

3-1. プロダクト概要と解決すべき課題を整理する

実績を書き始める前に、プロダクトの前提と解くべき課題を1〜2行で置きます。前提が共有されていれば、続く判断が妥当だったかどうかを、採用担当が自分で評価できます。

前提に含めるのは、提供形態、想定ユーザー、収益モデル、当時追っていた主要KPIの4点です。例えば、「無料トライアルから有料契約へ転換する収益モデルで、主要KPIは有料転換率と継続率だった」と書いておけば、初期設定の改善を優先した判断の理由が読み手に伝わります。プロダクトの規模や体制も同じ場所にまとめると、経歴全体が読みやすくなります。
 

3-2. 仮説・優先順位づけ・意思決定の過程を示す

施策を選んだ理由と、同時に検討した案の扱いまで書くと、判断の質が伝わります。選定の過程を示すことで、自分で優先順位を決めた経験として評価されます。

過程を書くときは、仮説の根拠、優先順位づけの基準、決定の場（会議体・関係者）の3点を押さえます。基準は、見込み効果、開発工数、検証のしやすさ、事業戦略との整合などから、当時実際に使ったものを挙げましょう。例えば、「検討した3案のうち、開発工数2週間で効果を検証しやすい初期設定の簡素化を先に進め、機能追加は翌四半期へ回した」と書けば、判断の順序まで具体的に示せます。
 

3-3. エンジニア・デザイナー・ビジネス部門との連携内容を示す

連携は、相手の職種ごとに自分が担った役割を分けて書きます。プロダクトの成果はチームで生まれるため、その中でどの位置に立って動いたかが評価の対象です。

職種別に整理すると、担当範囲が伝わります。エンジニアとは要求仕様と受け入れ条件をすり合わせ、デザイナーとは画面設計とプロトタイプによる検証、営業やカスタマーサクセスとは顧客要望の整理とリリース後の案内を、経営層とは投資判断の説明を担当したという具合です。関わった人数や頻度も、「週1回の定例に開発と営業の10名が参加」といった形で書き添えると、調整の規模が具体的になります。
 

3-4. リリース後の検証と改善まで示す

リリース後の検証と次の打ち手まで書くと、運用まで任せられるプロジェクトマネージャーとして評価されます。出した後の動きまで示すことで、改善を継続して担った経験が伝わります。

検証について書く内容は、計測設計、判断の基準、結果に応じた次の行動の3点です。例えば、「リリースから4週間、有料転換率と初期設定の完了率を計測し、完了率が伸びた導線を全ユーザーへ展開した」という流れで書くと、改善サイクルを回した経験が明確いなります。期待した水準に届かなかった施策も、原因の分析と次の仮説まで書けば、検証を重ねた経験として評価されます。

成果は、プロダクトの目的に合った指標を選び、施策前後の変化と自分の貢献をセットで示すことで伝わります。ここでは、指標の選び方、変化の書き方、数値以外での示し方という3つの観点から、成果の伝え方を解説します。
 

4-1. MAU・CVR・継続率・売り上げなど成果に応じた指標で示す

指標は、担当していた当時のプロダクトの目的から選びます。利用者を増やす、申し込みにつなげる、使い続けてもらう、収益を伸ばすといった目的のどれを担っていたかによって、採用担当が知りたい数字が変わるためです。

目的別に示しやすい指標は、次の通りです。
 

プロダクトの目的	職務経歴書で示しやすい指標
利用者を増やす	MAU、新規登録数、招待経由の登録比率
申し込みにつなげる	CVR、有料転換率、申し込み完了率
使い続けてもらう	継続率、機能の利用頻度、初期設定の完了率
収益を伸ばす	売り上げ、ARPU、契約単価、更新率

指標名だけでなく、計測期間と対象範囲もあわせて書きましょう。全ユーザーを対象とした数値なのか、新規登録者だけが対象なのかによって数値の意味が変わるため、条件を明記することで実績を正確に受け取ってもらえます。
 

4-2. 数値だけでなく施策前後の変化と自分の貢献を示す

数値は、施策前の水準、施策後の水準、計測期間の3点をそろえて書きます。3点がそろうと、どれだけ数値を動かしたのかを採用担当が正確に読み取れるためです。

貢献を書くときは、自分が何を決め、誰を巻き込んだのかを、能動的な表現で示しましょう。「初期設定を3ステップへ再設計する案を選び、開発チームと2週間で検証したうえで、有料転換率を3カ月で8%から12%へ引き上げた」と書けば、結果に加えて担当した工程まで伝わります。共同で進めた施策であれば、担当した範囲を明記することで、チームの成果と自分の貢献を両立できます。
 

4-3. 数値化しにくい成果は意思決定や開発プロセスの改善で示す

成果に関して、社外に公開できない数値を扱っていたり、複数チームで進めた施策で個別の寄与を切り出しにくかったりする場合もあります。その場合は、意思決定や開発プロセスに残した変化で示すと、貢献を伝えられます。

置き換えの手がかりは、仕組み、基準、範囲の3つです。例えば、「要求仕様のテンプレートを整備して、開発チームとの仕様確認の工程を1回に集約した」「優先順位づけの基準を明文化して、他プロダクトのチームでも使われるようになった」「社内に散在していた顧客要望の集約先を1カ所にまとめた」といった事実が該当します。第三者が引き継いで再現できる形で残した仕組みは、数値がなくても貢献として評価されます。

同じ経験でも、担当したプロダクトのフェーズによって、採用担当が読みたい内容は変わります。以下では、新規、グロース、成熟の3つのフェーズごとに、前に出す経験と書き方を解説します。
 

5-1. 新規プロダクトでは顧客探索・仮説検証・立ち上げ経験を示す

新規プロダクトの経験は、顧客探索から仮説検証、初期リリースまでの進め方を示します。立ち上げの段階では既存の数値が少なく、判断の材料を自分でつくった過程そのものが評価されるためです。

書く内容は、対象顧客の絞り込み方、検証した仮説、検証の手段、最小構成の決め方の4点です。例えば「想定ユーザー20名へのインタビューで課題を絞り込み、ランディングページで需要を確かめたうえで、機能を3つに限定した初期版を2カ月でリリースした」という流れで示します。リリース後に何を基準に次の開発範囲を決めたかまで書ければ、立ち上げから改善までを一貫して担った経験として伝わります。
 

5-2. グロースフェーズではKPI改善と施策の優先順位づけを伝える

グロースフェーズでは、KPIの分解の仕方と、限られた開発リソースの配分の考え方を書きます。伸ばす対象が明確な段階では、どこに絞って手を打ったかが判断力の証明になります。

まず、指標をどう分解したかを示しましょう。例えば、「有料転換率を、登録、初期設定の完了、利用開始の3段階に分け、最も改善余地の大きい段階から着手した」という書き方です。あわせて、ABテストの運用方法や、四半期ごとに優先順位を見直した進め方なども書き加えると、継続的に数値を伸ばした経験として評価されます。
 

5-3. 成熟プロダクトでは継続改善と複数部門を巻き込んだ意思決定の経験を見せる

成熟プロダクトでは、既存ユーザーへの影響を見ながら改善を重ねた過程と、部門をまたいだ合意形成を示します。利用者と関係部門が増えた段階では、調整を含めて前に進めた実績が評価の対象です。

例えば、「大きな仕様変更が生じた際の移行設計と既存顧客への案内」「営業やカスタマーサクセスから届く要望の優先順位づけ」「保守性を高める改修への投資を経営層に説明して予算を確保した経験」などが挙げられます。「利用の少ない機能を統合してサポート範囲を整理した」といった判断も、プロダクト全体を見て決めた実績です。関わった部門の数や調整にかけた期間を添えると、意思決定の規模が具体的に伝わります。

プロダクトマネージャーの職務経歴書は、担当プロダクトの前提、解決した課題、自分が下した意思決定、動いた指標の4点をそろえることで、入社後に任せられる範囲が明確に伝わります。職務要約から自己PRまでの4項目はプロダクト単位で整理し、担当したフェーズに合わせて前に出す経験を選んでみてください。

マスメディアンは、宣伝会議グループの人材サービスとして、マーケティング・クリエイティブ領域の転職を支援しています。プロダクトマネージャー経験者の経歴の棚卸しや職務経歴書のブラッシュアップ、応募書類の作成などに伴走いたします。ぜひお気軽にご相談ください。