PdM（プロダクトマネージャー）のスキルシートの書き方｜面談で評価される実績の見せ方

PdM（プロダクトマネージャー）のスキルシートは、リリースした機能を並べるよりも、「どんな根拠で、何を作り、何を作らないと決めたか」を書くと伝わります。PdMの価値は成果物そのものより判断にあり、読み手はその判断を任せられるかを見ているからです。

この記事では、PdMならではの書き方のポイントを、架空の記入例とあわせて紹介します。全体の構成はスキルシートの書き方の基本、PdMに求められるスキルはPdMのスキルの記事をご覧ください。

PdMのシートが伝わりにくくなる理由

PdMの経歴は、文字にすると似たような言葉が並びやすい職種です。「要件定義」「ロードマップ策定」「ユーザーインタビュー」「KPI管理」と書いても、どの会社のPdMも同じことを書けてしまいます。

また、PdMの仕事は社外に見せられないものがほとんどです。仕様書やロードマップ、調査の結果をそのまま添付することはできません。そのため、スキルシートでは判断の流れを文章で再現することが中心になります。

読み手が知りたいのは、主に次のようなことです。

• どんなプロダクトの、どの段階を担ったか
• 何を自分で決める権限があったか
• 判断の根拠に何を使ったか（調査、データ、事業側の要請など）
• 決めたことが、その後どうなったか

プロダクトの概要は「段階」と「誰が使うか」を先に書く

PdMの案件は、プロダクトの段階によって求められる動きが大きく変わります。立ち上げ期は仮説を早く確かめる力が、成長期は優先順位を決めて開発の速度を保つ力が、成熟期は既存の利用者を崩さずに改善を重ねる力が求められます。

プロダクトの欄には、名称の代わりに次の項目を書きます。

権限の行は見落とされやすい項目です。同じ「PdM」でも、優先順位を自分で決めていたのか、決まった方針を仕様に落としていたのかで、任せられる範囲の見立てが変わります。

判断は「きっかけ・根拠・選択肢・結論」で書く

PdMのプロジェクト欄の中心は、判断の記録です。1件の判断を、次の4つに分けて書くと、面談で深掘りされても説明しやすくなります。

1. きっかけ：何が問題になっていたか
2. 根拠：何を調べ、何が分かったか
3. 選択肢：どんな案があり、何と比べたか
4. 結論：何を作る・作らないと決め、その後どうなったか

記入例（架空）：機能の一覧から判断の記録へ

書き直す前：請求書の一括発行機能、テンプレートの編集機能、外部会計ソフトとの連携機能を企画・リリース

書き直した後
きっかけ：問い合わせの中で、請求書の作成に時間がかかるという声が多かった
根拠：利用者への聞き取りと操作のログを見たところ、時間がかかっていたのは作成よりも、会計ソフトへの二重入力だと分かった
選択肢：要望の多かったテンプレートの編集機能を先に作る案と、会計ソフトとの連携を先に作る案を比較
結論：連携を先に開発し、テンプレートの編集は次の四半期に回した。リリース後、二重入力の手間に関する問い合わせが目に見えて減った

これは書き方を示すための架空の例です。プロダクトの種類や判断の内容は、ご自身の経験に置き換えてください。

書き直した後の例では、「要望の多い機能をそのまま作らなかった」という判断が読み取れます。PdMの面談では、このように調べた結果で方針を変えた経験がよく聞かれます。すべてのプロジェクトをこの形にする必要はありませんが、直近の1〜2件は判断の形で書いておくことをおすすめします。

指標の数字を伏せるときの書き方

PdMは指標で語る職種ですが、利用者数や売上、解約率などの実数は、多くの場合社外に出せません。数字を伏せる場合でも、次のように書けば判断の質は伝わります。

• 指標の名前は書く：「有料プランへの移行率」「初回利用から一定期間内の継続率」など、何を見ていたかは書いてかまわないことが多い
• 値は方向と大きさの目安にする：「改善した」「目標の水準に届いた」「伸び悩んでいた指標が上向いた」など
• 指標を選んだ理由を書く：なぜその指標を目標にしたのかは、数字以上に評価されやすい

どこまで書いてよいかの考え方はスキルシートに書いてよいこと・いけないことで解説しています。

数字の因果を言い過ぎない

指標の改善を書くときに気をつけたいのは、その変化を自分の施策だけの成果として書いてしまうことです。プロダクトの数字は、季節の要因、営業やマーケティングの施策、価格の変更など、多くの要因で動きます。

面談で「その改善は、ほかの要因とどう切り分けましたか」と聞かれることは珍しくありません。比較の方法（期間の比較、対象を分けた検証など）を説明できない数字は、書かないか、「同時期に〜の施策もあった」と添えるほうが誠実です。

関係者との関わりは「誰と、何を合意したか」で書く

PdMは、開発・デザイン・営業・カスタマーサポート・経営と、多くの関係者の間に立ちます。スキルシートでは「関係者調整」と一言で書かず、誰と何を合意したかを短く書きます。

営業からの個別要望を断った経験や、経営の方針と現場の声が食い違ったときの調整は、PdMの面談でよく話題になります。シートには一行で触れ、詳しくは面談で話す形が向いています。

作ったドキュメントの書き方

仕様書やロードマップは添付できませんが、どんな種類のドキュメントを自分で書いていたかは、スキルとして伝わります。

• プロダクトの要求をまとめた文書（目的・対象の利用者・受け入れ条件など）
• 四半期または半期のロードマップ
• 利用者への聞き取りの設計と結果のまとめ
• 指標の定義書やダッシュボードの設計

「どの粒度で書いていたか」「誰が読む前提だったか」を添えると、外部から参画したときにどんな形で成果を残せるかが読み手に伝わります。

エンジニア・デザイナー出身の方の書き方

開発やデザインの経験からPdMになった方は、前の職種の経験を別のプロジェクトとして並べるより、PdMとしての判断に生きた場面として書くほうが伝わります。たとえば「技術的な制約を踏まえて段階的にリリースする計画を立てた」「画面の試作を自分で作り、聞き取りに使った」などです。

前の職種の技術スキルは、スキル一覧の欄に年数とあわせて書いておけば十分です。PMとの違いを意識した書き分けはPMのスキルシートの記事も参考になります。

よくある質問

担当したプロダクトが失敗して終了した場合も書いてよいですか？

書いてかまいません。立ち上げ期のプロダクトは、続けるか止めるかを判断すること自体が仕事の一部です。何を確かめ、どの時点で何を根拠に止める判断をしたか、またはその判断にどう関わったかを書くと、経験として伝わります。

社内向けのシステムのPdM経験は評価されますか？

社内の利用者向けのプロダクトでも、利用者の課題を調べて優先順位を決めた経験は、PdMの経験として書けます。利用者が社内の部門であること、利用部門の数、自分の権限の範囲を書き添えると、読み手が案件と照らし合わせやすくなります。

稼働日数が少ない案件に応募するときは、何を強調すればよいですか？

限られた時間で関わる案件では、短期間でプロダクトの状況をつかむ力と、判断の内容を記録して社内のメンバーに引き継ぐ力が見られやすくなります。要約の欄で、得意な段階と担える分野を絞って書くと伝わりやすくなります。稼働の形については週3日の業務委託案件の記事もご覧ください。