先月、PMとして1年ほど働いている友人の履歴書を見てほしいと頼まれました。2カ月近く応募し続けているのに、面接に呼ばれたのは片手で数えるほどだと言います。彼の履歴書を開いてみると、職務経歴の一番上にはこう書かれていました。
ユーザー向け注文モジュールのイテレーションを担当し、購入フローを最適化してユーザー体験を向上させました。
この一行を読んだ瞬間、私はピンときました。彼が何もしていないわけではありません。プロジェクトの話になると、30分でも止まらずに語れるほどです。問題は、彼が履歴書に書いたこの文章が、注文モジュールを少しでも触ったことのあるPMなら誰でもそのままコピペできる内容だということです。
これこそが、プロダクトマネージャーの履歴書で最も致命的な落とし穴です。プロダクトマネージャーの履歴書を、ただの「機能リスト」にしてしまっているのです。
PMのアウトプットは、機能そのものではありません。あなたのアウトプットは「どんな問題を発見したのか」「それをどう分析したのか」「どんな意思決定をしたのか」「最終的にどんな成果を出したのか」です。もし最初のステップ——「どんな機能を作ったか」——だけしか書いていなければ、面接官があなたに対して抱く印象は「プロトタイプが書けて、要件定義書が書ける人」止まりです。この人物像では、今の市場で面接を得るのは難しいでしょう。
以下では、プロジェクト経験、データによる定量化、自己PR、未経験からの突破方法という4つの軸で解説します。各項目に変更前と変更後の事例を用意しています。創作ではなく、PMが日々実際に行っている「頭脳労働」を履歴書の上に再現したものです。
一、プロジェクト経験：「どんな機能を作ったか」ではなく「どんな課題を解決したか」
PMのプロジェクト経験は、陥りやすい2つの極端な書き方があります。ひとつは「機能羅列型」——やった要件をメニューのように並べていくパターン。もうひとつは「方法論の復唱型」——「ユーザーリサーチ」「要件分析」「競合調査」といった言葉が画面いっぱいに並んでいるのに、具体的な事例がひとつも見えないパターンです。
どちらの書き方でも結果は同じです。面接官は読み終わった後、あなたの強みが何なのかさっぱりわかりません。
まず「機能羅列型」の例を見てみましょう
変更前：
ECアプリの注文モジュールのイテレーションを担当。購入フロー再構築、決済手段の拡充、アフターサービスチケットシステムの構築などを実施。デザイン、開発、テストチームと連携して要件をリリースまで導き、プロジェクトは予定通りローンチしました。
この文章の何が問題なのか。面接官に伝わる情報は3つだけです。「注文モジュールを担当したことがある」「要件定義書が書ける」「プロジェクトが予定通り進んだ」。しかし面接官は読み終わった後、「この人は優秀そうだ」と結びつくような具体的なイメージを、頭の中にひとつも描けません。なぜなら、すべての動詞——「担当」「連携」「完了」——がプロセスを指すものであって、判断を指すものではないからです。
変更後：
注文確定段階での離脱問題（カートから決済確認画面へのコンバージョン率が長期間38%にとどまっていた）に対し、購入フロー再構築を主導しました。2000件以上のユーザー行動ログデータを分析した結果、「住所入力」と「クーポン選択」が2大ボトルネックであることを特定——それぞれのステップで23%と19%のユーザーが離脱していました。対策として、住所入力を独立ページからハーフスクリーンモーダルに変更し、クーポンは額面最大のものをデフォルト選択（ワンタップで切り替え可能）にしました。その結果、カートから決済確認画面へのコンバージョン率を38%から64%に引き上げ、月間注文数が約3.2万件増加しました。
このバージョンと元のバージョンの違いは何でしょう。元のバージョンは「自分がどんな機能を作ったか」を語っています。変更後のバージョンは「自分が問題を発見し、原因を分析し、解決策を提案し、効果を検証した」を語っています。この4ステップが揃って初めて、PMとしての仕事の完結したサイクルになるのです。
次に「方法論の復唱型」の例を見てみましょう
変更前：
ユーザーインタビューと競合調査を通じて、ターゲットユーザーのコアな課題を深く理解しました。RICEモデルを用いて要件の優先順位付けを行い、プロダクトロードマップを策定。デザイン・開発チームと効率的に連携し、要件を高品質にリリースしました。
この文章には、単体で見て事実情報がひとつも含まれていません。これは「特定の誰か」の仕事ではなく、「すべてのPM」がやっていることを描写しているにすぎません。面接官がこういう段落を見たときに頭に浮かぶのは「この人は専門的だ」ではなく、「実務経験が乏しいから、方法論で穴埋めしているのでは」という疑念です。
変更後：
事業者向けの商品管理バックエンドのリニューアルを担当しました。初版リリース後、カスタマーサポートのフィードバックとバックエンドの操作ログから、事業者が1商品を出品するのに平均11分かかっていることが判明。競合は3〜5分で完了できる水準でした。アクティブな事業者8名にインタビューしたところ、3つのコア課題を特定しました。スペック入力のロジックがわかりにくい、画像アップロードが一括対応できない、在庫管理の入り口が深すぎる、の3点です。これに対し、フォーム構造の再編成、一括アップロード、在庫管理へのショートカット設置という3つのモジュールをリニューアル。その結果、事業者の平均出品所要時間は11分から4分に短縮され、週間アクティブ事業者数は1カ月で120から210に増加しました。
違いがわかりましたか。同じ「ユーザーインタビュー」と「プロダクト改善」なのに、こちらのバージョンは「誰にインタビューしたのか」「何を発見したのか」「何をしたのか」「結果はどうなったのか」を書いています。方法論そのものに価値はありません。その方法論をどう使い、具体的にどんな判断と結果を出したか——それこそが価値なのです。
PMのプロジェクト経験の書き方の公式
上の2つの事例から、シンプルな構成パターンが浮かび上がります。
どんな問題を発見したか（具体的な状況を含む）→ どう原因を特定したか（分析プロセスを含む）→ どんな意思決定をしたか（選択肢と取捨選択の考え方を含む）→ どんな結果を出したか（検証可能なデータを含む）
この構成が一般的なSTARメソッドと異なる点は、PMは「なぜその分析が正しいと言えるのか」をもう一層深く書く必要がある ことです。PMの判断力は「リサーチをしました」という事実に現れるのではなく、「リサーチからどんな洞察を引き出し、その洞察に基づいてどんな取捨選択をしたか」に現れるからです。
二、データによる定量化：データがない場合、ある場合の書き方
構成の話をしたところで、より細かい問題——データについて触れましょう。PMの履歴書において、データは最も強力な武器です。しかしジュニアPMが最もよく直面するのが、「本当にデータがない」ケースと「データはあるけど書き方がわからない」ケースの2パターンです。
データはあるのに「XX%向上」と書いてしまう
典型的な例を見てみましょう。
ログイン・登録フローを最適化し、登録コンバージョン率が15%向上しました。
15%という数字は一見ポジティブに見えます。しかし面接官は必ずこう突っ込んできます。「元々は何パーセントだったのか？何パーセントになったのか？絶対値で15ポイント上がったのか、相対値で15%上がったのか？ベースとなる数値はどのくらいか？」
もしこれに答えられなければ、この一行の信頼性はゼロになります。
ですからPMのデータ定量化には鉄則があります。「XX%向上した」と書くのではなく、必ず「XからYになった」と書くことです。
ログイン・登録のコンバージョン率を52%から67%に引き上げました。
この文章は「15%向上」と同じ成果を指していますが、面接官の受け取り方はまったく違います。前者は業務報告書のように読め、後者は実際にデータに触れたことのある人間の言葉に読めるのです。
さらに一歩進んで、「どうやって実現したか」まで補足できれば、データの説得力はもう一段上がります。
ログイン・登録のコンバージョン率を52%から67%に引き上げました。主な施策：独立したパスワード設定ページを廃止し、登録完了後のポップアップでパスワード設定を案内する方式に変更。SMS認証コードは自動入力に対応させ、手動の入力ステップを削減しました。
面接官はこれを見れば、わざわざ質問しなくても、あなたの思考の筋道が手に取るようにわかります。
3段階のデータの優先順位
すべてのデータが同じ重みを持つわけではありません。弱い順から強い順に、3段階あります。
第1段階：絶対値。 最も弱いですが、ないよりはマシ。「DAUが5万から8万に増加」——変化はわかりますが、説得力は弱いです。なぜなら単に市場全体の波に乗っただけかもしれないからです。
第2段階：比較値。 絶対値だけよりは強い。たとえば「業界平均の成長率が12%という状況下で、私たちは45%の成長を達成しました」。面接官は一目で「この人は相場に乗っただけではない。この人の施策に効果があった」と理解します。
第3段階：帰属値。 最も強いデータです。なぜなら、あなたのアクションと結果を直接結びつけているからです。たとえば「リリース後、カートから決済確認画面へのコンバージョン率が38%から64%に上昇。同期間中、他のページのコンバージョン率は安定しており、季節変動の影響が除外できることを確認しました」。自ら交絡因子を排除している——この行為自体が、機能の効果をどう評価すべきかをあなたが理解している証拠になります。
本当にデータがない場合はどうするか
多くのジュニアPMが直面するリアルな状況はこうです。担当した機能がまだリリースされていない、コアKPIを負わないモジュールを担当している、会社が小さすぎてダッシュボードすら整備されていない——。
こういう状況でも慌てる必要はありません。面接官も、ジュニアPMに対して初めから高いレベルのデータを期待しているわけではありません。あなたがやるべきことは、定量的データの代わりに「定性的な成果」と「プロセスの証拠」で補う ことです。
以下の3つの書き方を参考にしてください。
1. ビジネスサイドのフィードバックを書く：
企画レビューの段階で、運用チームから「以前のバックエンドは操作ステップが多すぎて、キャンペーンを新しく出すたびに半日かかっていた」との声がありました。新案ではキャンペーン設定を7ステップから3ステップに圧縮し、運用チームが事前にレビューに参加してユーザビリティを確認。企画は一発で承認され、開発に進みました。
2. ユーザー検証の結果を書く：
プロトタイプ完成後、ターゲットユーザー6名（新規ユーザー3名、既存ユーザー3名）を集めてユーザビリティテストを実施し、4つの重要なインタラクション問題を特定して修正しました。最終バージョンでは、2回目のテストでタスク完了率が67%から100%に向上しました。
3. 比較による結論を書く：
市販の類似プロダクト5製品の登録フローを1ステップずつ分解分析した結果、業界のベストプラクティスは一般的に3〜4ステップで登録を完了させているのに対し、当社の元案は7ステップもあることが判明。この分析に基づき、案を7ステップから3ステップに圧縮し、デザインレビューを一発で通過しました。
これら3つの書き方に共通するのは、データを捏造していないが、「プロダクトに向き合う姿勢」が厳密で、方法論に基づいていることを証明できている点です。ジュニアPMにとって、このことは真偽不明の「30%向上しました」よりもはるかに価値があります。
三、自己PR：「ロジカル思考です」と書かずに、証明する
PMの自己PRは最も被害が大きいエリアです。PM10人の自己PRを見れば、8人まではこんな感じです。
ロジカル思考に優れ、コミュニケーション能力が高く、ユーザーニーズに対して鋭い洞察力を持っています。部門横断的な連携とプロジェクト推進に強みがあり、プロダクトを0から1へと効率的に導くことができます。
この文章は、書いても書かなくても同じです。なぜなら、PM職に応募する人なら誰でも一字一句同じことを書けるからです。「ロジカル思考」に資格試験は必要ありませんし、「コミュニケーション能力が高い」ことに級位認定はありません。面接官はこういう文章を見ると、自動的にスキップします。
書き換えの事例
変更前：
1年間のB向けプロダクト経験。ロジカル思考が明確で、要件分析とプロダクト企画のアウトプットを得意としています。高いプロジェクト推進力を持ち、多様なステークホルダーを調整して目標を達成できます。
変更後：
1年間のB向けSaaSプロダクト経験。事業者向けツール領域が専門です。要件調査からリリースまでの全工程を単独で担当しました。カスタマーサポートのチケット分析と事業者インタビューでコア課題を特定し、PRDを作成。レビューにおいて技術方案の合意形成をリードし、最終的にリリースした機能は、リリースから1カ月以内にアクティブ事業者の70%に採用されました。
違いは何でしょう。元のバージョンはすべての文が「自分についての説明」です。変更後のバージョンは、すべての文が「自分についての証明」になっています。
具体的に分解してみましょう。
- 「ロジカル思考が明確」→「カスタマーサポートのチケット分析と事業者インタビューでコア課題を特定」に変わっています。わかりますか。「ロジカルです」と言うのではなく、「ロジカルにこう仕事をした」という実例を見せているのです。
- 「要件分析とプロダクト企画のアウトプットを得意」→「要件調査からリリースまでの全工程を単独で担当……PRDを作成し、レビューにおいて技術方案の合意形成をリード」に変わっています。「企画書が書けます」と言うのではなく、「企画書を書き、それが実際に承認された」と言っているのです。
- 「高いプロジェクト推進力」→「最終的にリリースした機能は……アクティブ事業者の70%に採用されました」に変わっています。「推進力があります」と言うよりはるかに強力です。あなたが作った機能が実際に使われている——それこそが推進力の何よりの証明です。
自己PRのコア原則
PMの自己PRには、とてもシンプルな判断基準があります。名前を隠して他の人に読んでもらい、「この人はだいたいどんなPMなのか」を相手が言い当てられるかどうか。
読み終わった相手が「PMをやったことがある人」としか言えなければ、あなたが書いたのは汎用版です。相手が「B向けの事業者ツールを専門にしていて、自分でユーザーリサーチを実施し、リリースして実際に使われた事例をフルサイクルで持っているPMだ」と言えるレベルまで書き込んで、初めて自己PRとして合格です。
長さは3〜4文で十分です。それぞれの文を、面接官に覚えてほしいタグに対応させてください。あなたの専門領域、コアコンピテンシー、成果、差別化ポイント——この4つです。
四、プロダクト経験がない場合——キャリアチェンジと新卒の突破方法
これが最も多く寄せられる質問です。「PMに転職したいけれど、PMとして働いた経験がなくて、履歴書に書くことがない。どうすればいいですか？」
正直に言うと、この問題はあなたが思っているよりずっと解決しやすいものです。なぜなら「プロダクト経験がない」と「プロダクト能力を証明できるエピソードがない」はイコールではないからです。
今の仕事の中から、プロダクトに関係することを掘り出す
多くの職種はPMとの境界線が曖昧です。オペレーション、マーケティング、カスタマーサポート、プロジェクトマネージャー——日常業務の中で「問題を発見 → 原因を分析 → 解決策を提案 → 推進して実行」というサイクルを一度でも回したことがあるなら、あなたはすでにPMの仕事の一部を経験しています。
オペレーションからPMへの転職を想定した書き換え事例を見てみましょう。
変更前（オペレーション視点）：
コミュニティ運営を担当。20のユーザーグループを日常的に管理し、定期的にコミュニティイベントを企画して、ユーザーのアクティブ率と定着率を向上させました。
このバージョンに書かれているのは、すべてオペレーションの実行業務です。面接官が読んだ印象：この人はオペレーション担当者だ。PMではない。
変更後（プロダクト視点）：
コミュニティ運営の中で、ユーザーが「講座アーカイブ」へのアクセス方法について繰り返し問い合わせていることを発見しました。月間の関連問い合わせは300件を超えていました。ユーザーの典型的な検索経路を整理した上で、「講座アーカイブ導線の改善案」をプロダクトチームに提案しました。講座詳細ページに「過去のアーカイブ」導入口を追加し、グループ告知にアーカイブまとめリンクを固定表示する、という内容です。この提案が採用されてリリースされた結果、関連問い合わせ件数は76%減少し、コミュニティ運営の工数が週あたり約15時間削減されました。
同じ経験でも、語りの視点を「自分がどんなオペレーション業務をしたか」から「自分がどんなユーザー課題を発見し、どんな解決策を提案し、どんな成果を出したか」に切り替えただけです。後者はまさに、一人前のPMがやっていることに他なりません。
もしあなたがカスタマーサポート、営業、テクニカルサポートを担当しているなら——あなたは日々、ユーザーの生のフィードバックと現場の課題に触れているわけです。これらはPMが喉から手が出るほど欲しい一次情報です。これらを明確な問題記述と改善提案にまとめ上げること。それこそが、あなたの「プロダクト思考」の最も直接的な証明になります。
新卒の場合：自分のプロジェクトを「プロダクト」として語る
あなたが大学の公式アカウントを運営した、サークルイベントを企画した、授業のグループ課題に取り組んだ——これらはあなたにとっては「学校の中のもの」かもしれませんが、面接官から見れば、あなたが差し出せる立派な「プロダクト経験」です。ただし、書き方が正しければの話ですが。
変更前：
学内ビジネスコンテストに参加し、プロジェクトリーダーとして、チームを率いて学内中古品売買ミニアプリのプロダクトデザインを実施。学内2位を獲得しました。
変更後：
学内ビジネスコンテストプロジェクト（学内2位、参加80チーム超の中で上位5位以内）
プロジェクト背景：学内の中古品売買において、需要側と供給側に深刻な情報ミスマッチがあることを発見しました。QQグループやモーメンツに投稿された情報は埋もれやすく、検索も困難です。そこでプロジェクトの狙いを「学内中古品売買のための軽量マッチングツール」に絞り込みました。
個人の役割：要件調査とプロダクトデザインを担当
- 有効回答150件のアンケートを設計・回収し、競合分析（メルカリ、PayPayフリマおよび学内の既存チャネルとの比較）を実施。8ページの要件調査レポートを作成
- 調査結果に基づき、コア機能を3つのモジュール（出品、検索、メッセージ）に収束。当初案にあったユーザー評価機能とエスクロー取引機能を削除——その理由は「学内の顔見知りコミュニティにおいては、複雑な仕組みより軽量な信頼の方が効果的」と判断したため
- インタラクションプロトタイプを作成し、20名の学生でユーザビリティテストを実施。フィードバックに基づき商品出品フローを6ステップから3ステップに簡略化
プロジェクト成果：学内2位を獲得。審査員講評「課題定義が明確で、機能の絞り込みに明確な根拠がある」
変更前のバージョンでPM職に応募しても、面接官の印象は「コンテストに参加したことがある新卒」止まりです。変更後のバージョンなら、面接官はこう思うでしょう。「この人は課題を定義し、競合分析をし、ユーザーリサーチをし、シーンに基づいて機能の取捨選択ができる。PMが実際にやるべきことをきちんと経験している」と。
新卒の最大の強みは「何を学んだか」ではありません。ひとつのプロジェクトの中で「発見 → 分析 → 設計 → 検証」という完全なサイクルを見せられることです。中途採用のPMは、会社で大きなシステムの中の小さなモジュールしか任されていないケースが多いため、かえってこのサイクルを見せにくいのです。
キャリアチェンジと新卒に共通する2つの落とし穴
落とし穴その1：方法論で詰め込みすぎる。 「経験がないなら、方法論をたくさん書いて理解していることを証明しなければ」と考える人が多いです。その結果、履歴書はペルソナ、カスタマージャーニーマップ、AARRRモデル、KANO分析だらけ——でも具体的な事例がひとつも見当たらない。面接官がこういう履歴書を見たときの第一印象は「スクール出身者だな」です。あなたが証明すべきは「プロダクトについて勉強したこと」ではなく「プロダクトに関係することを実際にやったこと」です。
落とし穴その2：他人のプロジェクトを自分の実績として書く。 たとえばオンラインの実践講座に参加して、メンターの指導のもとで架空プロダクトの分析をしたケース。こうした経験は履歴書に書いても構いませんが、「これは学習プロジェクトである」と明記し、なおかつ「あなた個人の思考と判断」にフォーカスして書く必要があります。チームの成果を個人の実績に見せかけることよりも、面接官に「この人の頭の中はどう動くのか」を見せることの方が、はるかに大切です。
五、PMの履歴書に特有の3つの小さな工夫
ここまでは構成と大きな方向性の話でした。以下の3つは細かいですが、非常に実用的です。
1. 「Axure、Figmaが使えます」とは書かない
ツールはコアコンピテンシーではありません。どんなPMでも1週間あれば新しいツールに慣れることができます。「Axureを熟練して使えます」と書くより、「Axureで40画面以上からなる事業者向けバックエンドの高精度プロトタイプを作成し、それがそのままデザインレビューとフロントエンド開発の参照資料として使われました」と書いてください。後者は、あなたのプロトタイプが「お遊び」ではなく、実際に開発チームに渡って使われたものであることを証明しています。
2. すべての経験に「もしあなたがいなかったら、この結果は違っていた」という情報を潜ませる
面接官は履歴書を読むとき、無意識のうちにある答えを探しています。この人はその経験において、「チームにただついていった人」なのか、それとも「物事を動かした人」なのか。
もしあなたが「要件レビューに参加」「テスト検収を支援」と書いていれば、面接官が読み取る情報はこうです。「要件レビューはこの人がいなくても同じように開かれた。テスト検収は別の誰かでも同じようにできた」。これらは加点要素ではありません。これらは「私の関与度は深くありませんでした」というシグナルを面接官に送っているのです。
これらを次のように置き換えてください。「要件レビューにおいて、当初予定のY案に対してX案を提案し、その理由は……というものでした。最終的にX案が採用されました」「テスト段階で境界条件の不具合を発見し、リリース前に開発チームに修正を働きかけ、本番障害を未然に防ぎました」。これらは面接官にこう伝えています。「この人はただその場にいただけではない。この人は物事の流れを変えたのだ」と。
3. 履歴書そのものが、あなたにとって最初の「プロダクト」である
これは多くのPMが思いつかない視点ですが、トップレベルの面接官は必ずこの角度からあなたを評価します。
あなたの履歴書は、本質的にひとつの「プロダクト」です。ターゲットユーザーは面接官と人事担当者。コアニーズは「10秒でこの人と話す価値があるかどうかを判断したい」。重要指標は面接の呼ばれ率です。
あなたはこのプロダクトの情報設計をどうしますか。最も重要な情報を最も目立つ位置に置いていますか。どのエピソードも、ひとつの同じコアなポジショニングを強化するものになっていますか。それとも面接官が読み終わった後の印象は「この人はあれこれ少しずつ触ったことはあるけど、何が一番得意なのかわからない」という状態になっていませんか。
もし自分の履歴書という「プロダクト」さえうまく設計できないのなら、面接官はどうやってあなたが本物のプロダクトを設計できると信じられるでしょうか。
書き終わった後のセルフチェックリスト
- 各プロジェクト経験の冒頭は「どんな問題を発見したか」から始まっていますか？「私は……を担当しました」でいきなり始まっていませんか？
- データはありますか？もし定量的データが本当にない場合、定性的成果（ユーザーフィードバック、テスト結果、ビジネスサイドの評価）で補完されていますか？
- 自己PRの中に、削除しても経歴が近い別の人ならそのままコピペできてしまう一文はありませんか？もしあれば、書き直してください。
- 「Axure/Figma/Sketchを熟練して使えます」とは書かない——「このツールで何をデリバリーしたか」に置き換えてください。
- 履歴書全体を読み終わったとき、「これはどんな領域で、どんなコアコンピテンシーを持つPMなのか」を一文で言い表せますか？もし言い表せなければ、履歴書の情報設計を再設計する必要があります。
- 異なる領域のPM職に応募するとき、求人票に合わせて履歴書を再調整していますか？もししていなければ、それはあなたが汎用版の履歴書を書いている証拠です。
結局のところ、PMの履歴書とは「過去に何をやったかのリスト」ではありません。「自分がチームにどんな価値をもたらせるかという提案書」なのです。この提案書のロジックを明確に書き、十分な証拠を揃えれば、面接官は自然とあなたともっと話したくなるはずです。
もし書き直した後でも、自分の履歴書が面接官の目にどう映るか自信が持てないなら——正直なところ、自分の書いたものを自分で客観的に見るのは難しいものです。DeepResumeの無料診断では、成果の定量化、マッチ度、表現の明瞭さといった複数の軸から履歴書をスキャンし、各エピソードの強みと弱みの分析、改善の方向性をお伝えします。