PMの職務経歴書：求人要件を経験の根拠で伝える書き方

PMの職務経歴書は、求人の要件・キーワードを抜き出し、実際の経験と照合して、自分の判断・役割・結果が伝わるように書き直すことから始めます。課題設定、優先順位、データ分析、関係者との連携について、用語を並べるのではなく、何を根拠にどのような判断をしたのかを示しましょう。

refresh.cvでも、求人の要件と応募書類の表現・経験の根拠を比較する流れで修正を進めます。求人にある言葉は、実際に行ったことに合う範囲で使ってください。ここでは、履歴書の基本情報ではなく、プロダクトマネージャー（PM）の職務経歴書に書く経験の選び方と伝え方に焦点を当てます。

PMの求人では、どのような能力を読み取るべきですか？

まずは要件を、課題設定、プロダクト戦略・優先順位、データ分析・成果検証、関係者との連携に分けてみましょう。この記事では、求人を読み解き、経験を整理するための確認項目として使います。

トスのTechnical Product Owner求人には、顧客の要望と事業へのインパクトに基づく課題設定、目標・戦略の策定、主要指標とデータに基づく実験、解決策と役割を関係者に伝える業務が挙げられています。技術プロダクトへの理解とリード経験も求められているため、一般的なPMの応募要件と同一視しないでください。

멋쟁이사자처럼のProduct Manager求人（Wanted掲載）には、プロダクトのビジョン・ロードマップに沿ったバックログの優先順位付け、開発・デザインとの合意形成、指標と仮説に基づく実験が挙げられています。こちらは募集終了済みです。現在の募集情報ではなく、要件の読み解き方の例として参照してください。

能力の名前を次のような問いに置き換えると、対応する経験を探しやすくなります。

• **課題設定：**誰のどのような困りごとを見つけましたか。判断に使った資料は何ですか。
• **戦略・優先順位：**どの目標と制約を基準に選び、何を見送りましたか。
• **データ分析：**何を明らかにするために指標を確認し、その後、何を変えましたか。
• **関係者との連携：**誰とどの論点を調整し、合意をどのように実行へつなげましたか。

求人を「要件と経験の根拠」の表にする

求人の業務内容、必須要件、歓迎要件を分けて書き出してください。似た表現はまとめても、業界・事業領域、技術、経験年数などの条件は別に残します。データに基づく意思決定の経験があるからといって、SQLの使用経験まで満たしているとは書けません。

以下は、先ほどの要件の種類をもとに作った架空の整理表です。実際に使う際は、左の列を応募先の求人に書かれた表現に置き換えてください。

職務経歴書と照合したら、次のように状態を分けます。

• **キーワードも根拠もある：**自分の役割と結果が明確になるように整えます。
• **関連する経験はあるが、キーワードがない：**実際の行動に合う求人の用語を反映します。
• **キーワードも根拠も記載されていない：**別のプロジェクトや記録に関連経験がないか確認します。実際にはない経験を追加してはいけません。

職務経歴書に書かれていないだけで、経験自体もないとは判断しないでください。記録を確認する作業と、表現を直す作業は分けて進めます。

プロジェクトは「自分の判断を説明できるか」で選ぶ

掲載するプロジェクトは、応募要件とのつながり、自分が決定・提案した範囲、確認できる結果を基準に選びましょう。サービスの知名度や規模よりも、その要件に答えられる根拠を優先します。

プロジェクトごとに、課題を見つけた資料、選んだ案と理由、調整した論点、結果を確認した記録を整理してください。チーム全体の成果と、自分の貢献は分けて書きます。分析を担当したのであれば、分析内容と提案までを記載し、最終決定権がなかったのにプロダクト戦略を統括したと広げないようにします。

売上やコンバージョン率の数値がない場合は、確認できる成果物や検証結果を記載してください。方針の確定や要件の合意についても、何が決まったのかを具体化できます。ただし、リリースした事実を顧客への成果と同一視したり、リリース前後の変化だけで自分の施策の効果と断定したりしてはいけません。数値を使う際は、指標の定義、測定期間、比較条件、自分の貢献を併せて確認します。

「機能企画と連携」を、判断が伝わる文章に変える

トスは、先ほど紹介したTechnical Product Owner求人で、プロジェクトごとに課題設定、仮説または解決策、実行・検証や連携、結果の流れを示すよう案内しています。業務の列挙にとどめず、成果と学びも説明するという考え方です。

次は、説明用に作成した架空のオンボーディング改善例です。問い合わせ記録と登録ステップごとのログを確認し、案内文を修正して公開したものの、登録完了率の改善はまだ測定していない状況を想定しています。実在の利用者やrefresh.cvの顧客の成果ではありません。

修正前

オンボーディング機能の企画と、開発・デザインとの連携を担当しました。

修正後の職務経歴

• 問い合わせ記録と登録ステップごとのログを照合し、認証の案内が分かりにくい点を改善課題として整理しました。
• 開発範囲を考慮し、全面改修よりも案内文の修正を優先する案を提案しました。開発・デザインと適用範囲を合意し、公開しました。
• 公開後の登録完了率を確認するための測定計画をまとめました。

修正後は、判断に使った資料、優先順位の理由、自分の提案、連携の結果が分かります。まだ測定していない登録完了率の上昇は書いていません。

文章の具体性と、求人への適合度は別に確認する

この例で資料と行動を具体化したのは、職務経歴書の品質を高める修正です。一方、その経験が応募先の要件に答えているかは、別に確認する必要があります。

たとえば求人がSQLを使った直接の分析経験を求めている場合、「ログを照合した」と具体的に書いても、SQLを使った根拠までは示せません。実際にSQLを使ったのであれば、その作業を明記します。経験がなければ、キーワードだけを追加しないでください。

同じプロジェクトでも、求人によって先に示す根拠は変わります。優先順位の判断を重視する求人なら、全面改修ではなく案内文の修正を選んだ基準を示します。データ分析を重視する求人なら、どのログを問い合わせ記録と照合し、何を判断したのかを具体化してください。アナリストが提供した分析結果を検討したのであれば、自分が直接分析したとは書かず、検討と提案の範囲を記載します。

PMへ転職する場合、これまでの経験をどう生かしますか？

これまでの職種名をPMに置き換えるのではなく、顧客の課題発見、選択と調整、結果の検証に当たる行動を探しましょう。

• **運用の経験：**繰り返し届く問い合わせを分類し、プロダクト改善を提案した過程と、実際に反映された範囲を整理します。
• **マーケティングの経験：**顧客の反応やファネルのデータを読み取り、提案を変えた判断を説明します。広告の成果とプロダクトの成果は分けてください。
• **開発の経験：**技術上の制約とユーザーの要望を比較し、リリース範囲を調整した例を探します。実装への参加を、プロダクト全体の責任に置き換えてはいけません。

これは経験を整理し直す方法であり、応募資格を満たしているかの判定ではありません。必須の業界・事業領域の経験や、プロダクトをリードした経験が不足している場合は、表現の修正とは別に検討する必要があります。

refresh.cvで修正の優先順位を決める

refresh.cvでは、求人の入力、要件・ATSキーワードの抽出、応募書類の表現と経験の根拠の比較、不足する表現・要件の確認、事実に沿った修正という流れで見直せます。大切なのはキーワードを増やすことではなく、根拠のある経験を、求人で使われている言葉で伝えることです。

具体性・成果・表現・文法などを見る書類の品質スコアと、求人ごとのキーワード適合度は分けて読み取ってください。どちらも採用確率や、応募先企業のATSによる実際の判定、面接の成功を意味しません。

修正を反映する前に、次の点を確認しましょう。

• 求人の必須要件と歓迎要件を分け、経験の根拠と照合しましたか。
• チームの成果と、自分の判断・提案・担当範囲を分けましたか。
• 未測定の成果や、使っていない技術を追加していませんか。
• 提案された文章の役割と結果が、自分の記録と一致していますか。

応募する求人と現在の職務経歴書を用意して、refresh.cvで比較してみてください。関連する経験はあるのに表現が抜けている項目から、修正を始めましょう。