本記事は『プロダクトマネージャーになりたい人のための本 エンジニアからプロジェクトマネージャー・事業企画・経営コンサルタント・デザイナー・現役PMまで』（松永拓也、山本航、武田直人、監修：及川卓也）の「第3章 プロダクトマネージャーの転職活動の進め方」から抜粋したものです。掲載にあたって一部を編集しています。
転職活動の7つのステップ
ステップ1 転職の目的を明確にする
ステップ1は転職の目的を明確にすることです。転職とはあくまでもキャリアをよりよくするための手段でしかなく、転職自体が目的になってしまってはいけません。「何を得るために転職をするのか？」をしっかりもつことで、キャリアに迷った際の考えのより所となります。「内定をもらってから考えよう」という姿勢も時に必要ですが、内定をもらったからといっても迷いがなくなるということはありません。事前にしっかり考えておくことが肝心です。
ステップ2 応募したい企業を探す・絞る
ステップ2では応募したい企業を探して絞りこんでいきます。プロダクトマネージャーの転職においては企業選びだけでなくプロダクト選びも大切です。自分が求めているキャリアや環境がその企業にあるのか、自分が愛せるプロダクトなのかどうかなどを吟味する必要があります。この企業選び・プロダクト選びは転職目的に依存することを忘れてはいけません。
ステップ3 相手が会いたいと思う職務履歴書をつくる
ステップ3では相手が会いたいと思う職務経歴書をつくります。転職活動には履歴書・職務経歴書の2つの書類が必要です。履歴書は住所や学歴、社名などを書くだけなのでさほど時間も手間もかかりません。一方で職務経歴書は書く人の個性や言語化能力が如実に表れます。自分の実績やスキルを過不足なく伝えることは、簡単ではありません。
多くの求職者を見ていて共通して思うのは「せっかく面白いエピソードをもっているのに、それが職務経歴書に書いていないのではもったいない」ということです。応募先企業にどのようなエピソードや言葉が響き、あるいは響かないのかは自分ではわかりづらいものです。だからこそ知っておくべき観点があります。
ステップ4 カジュアル面談を使いこなす
転職目的が定まり、応募する企業も決め、履歴書と職務経歴書が整ったら面接を進めていきます。ただ最近では面接前にステップ4で説明するカジュアル面談をはさむ場合もあります。カジュアル面談とは、その名の通り面接よりもカジュアルな形式で企業の方と会話をする場です。企業の文化やプロダクトの特徴、組織体制などを事前に細かく確認することができる点がメリットです。ただし、必ずしもカジュアル面談を設定しなければいけないわけではなく、あくまでも「事前に細かく知っておきたい」のであれば、企業へ依頼してみるのがよいでしょう。
ステップ5 面接に備える
ステップ5は面接に備えて準備をします。はやく面接に臨みたい気持ちもわかりますが、職務経歴書で自分の実力を示すことができない場合があるのと同様に、面接でも本来の力を十分に発揮できない事例を数多く見てきました。これは未経験からの転職者やジュニアプロダクトマネージャーに限った話ではなく、シニアプロダクトマネージャーであっても同様です。応募する企業に応じた対策を入念に行ってから面接に臨むことをおすすめします。
ステップ6 選考を進める
ステップ6ではいよいよ選考を進めて面接に臨みます。面接を進めている中で気持ちや志向が変わったりすることもあるでしょう。その場合、追加で応募企業を増やしたり、途中での辞退も視野に入れましょう。状況にあわせて選考の進捗を調整することも欠かせません。
ステップ7 決断をする
ステップ7は転職先を決断します。応募企業から無事内定を獲得することができたら転職活動は終了ではありません。どの企業を選ぶべきか、はたまた本当にいま所属している会社から出るべきなのか。非常に悩ましい決断のときとなります。転職目的に立ち返り、目的をもっとも達成できる選択肢を選んでいきます。
以上が転職活動の7ステップの大まかな流れです。この記事では特に「ステップ3 相手が会いたいと思う職務履歴書をつくる」を詳しく紹介します。
キャリアの棚卸しをする
転職活動を始めようと思ったら、履歴書や職務経歴書を作成しなければなりません。履歴書は簡単に作成できますが、職務経歴書の作成は時間がかかり、正解がないがゆえに完成させるにはひときわ苦労します。きっと職務経歴書を書こうとするだけで、億劫になってしまう人もいるのではないでしょうか。
私たちは普段から「職務経歴書は転職活動時に書くのではなく、日常的にキャリアを棚卸ししながら書くようにしましょう」と伝えています。普段からこまめに自身のキャリアを振り返って、それを文字に起こしておくことが肝心なのです。
キャリアの棚卸しとは、これまで携わってきた仕事や実績、培ったスキルなどを書き出してキャリアを振り返ることを指します。では、キャリアの棚卸しはなぜ必要なのでしょうか。大きく3つのメリットがあります。
1つ目のメリットは、転職活動に向けて、自分が過去から現在までにどんな「経験・実績」「能力・スキル」をもっているかを明確にできることです。何が「得意・強み・できるのか」、何が「不得意・弱み・できないのか」を改めて自己認識し、自分なりに言語化します。
2つ目は、今後のキャリアの方向性（進むべき道）と、そこに向けた課題と成長の伸びしろが明確になることです。自分が目指すキャリア、やるべきことが明確になれば、日々の仕事に対する向き合い方やモチベーションにもよい影響を及ぼすことでしょう。
そして3つ目のメリットは、これらの自己分析だけに限らず、転職活動に大いに役立てることができる点です。自分がどんな経験・スキルをもっているのかが明確になれば、それだけ「自分の経験・スキルを活かせる求人」が見つけやすくなります。また、企業に提出する職務経歴書にて自身がアピールすべきことを具体的かつ、読み手にわかりやすく整理して伝えることもできるでしょう。
日常的にキャリアを棚卸ししていれば、職務経歴書の作成はさほど難しいものではありません。キャリアを振り返る癖をつけてみてください。
基本的な書き方の作法を知る
ここからは職務経歴書を書く際の基本的な作法やポイントを紹介します。実際の職務経歴書の作成例は次項「職務経歴書の成功の法則と実際の記入例」にて記載していますので、適宜参照しながら読み進めてください。
職務経歴書とは何か
職務経歴書とは、これまで経験してきた業務内容やスキルを記載した書類のことです。社会人になってから現在に至るまでの間に携わった仕事や業務、有している経験、実績、スキル、そしてそれらをどのように活かせるのかを企業へアピールすることを目的としています。一般的にはA4サイズの用紙を用い、2～3枚にまとめます（多くても4枚程度にまとめるのが好ましい）。
その理由は、シンプルに少ない枚数の方が読みやすいからです。せっかく長い時間と労力をかけて5枚も6枚もある大作をつくり上げても、書類選考の担当者も日々の忙しい中で大量の書類を見ているため、全ページを隅々まで見てくれないかもしれません。限られた時間内で書類選考をしている読み手に対して、端的かつわかりやすく伝わる職務経歴書に仕上げることがポイントです。
前提として、職務経歴書に決まったフォームや型はありません。形式があるわけではなく自由記載で問題ありません。とはいえ、一般的によく目にする形式や構成に沿って記載するのが無難でしょう。職務経歴書の基本的な書式および主に記載する項目は下記になります。
- （1）職務要約
- （2）活かせる経験・知識・スキル
-
（3）職務内容
a. 会社概要
b. 職務経歴（実績・役職・役割など） - （4）自己PR
- （5）資格
それぞれの項目の記載の仕方を（1）から順に説明していきます。
（1）職務要約
職務要約とは、これまでの職務経歴のサマリーです。社会人1年目から現在に至るまでどういう経歴で何をしてきたのか、どんな実績を出してきたのかを経歴ダイジェストのイメージで記載します。書類選考の際、採用担当者は、ここでどういう経験をもっている求職者なのかを大まかにとらえ、その下に記載している職務経歴（（3）のb.）に目を通します。期待感をもって職務経歴を見てもらえるか否かの「つかみ」は、この職務要約にかかっています。文字量にして5～7行程度がよいでしょう（文字サイズや余白の大小によって異なる）。箇条書きよりも、文章で書く形式をよく見かけます。
（2）活かせる経験・知識・スキル
募集要項にある「求める経験・スキル（必須条件／歓迎条件）」を満たしている経験だけではなく、希望する業務に関連する資格・スキルをもっている場合は、それらを含めて「活かせる経験」として数行で記載しましょう。ただし、より注力してアピールするのは職務経歴の欄とし、ここではあまり分量を割かずに記載することをおすすめします。
エンジニアの場合の記載例
- Webサービスのアーキテクチャ設計
- バックエンド開発、フロントエンド開発両方の経験
- 開発工数の見積もり
- スクラム経験
- 認定スクラムマスター（CSM）
- 認定プロダクトオーナー（CSPO）
- SQLなどを用いたデータ抽出、分析
- 経験言語：Ruby on Rails、JavaScript、React、Python
（3）職務内容
これまで所属した企業を1つのモジュール（まとまり）として、在籍企業ごと（もしくはプロジェクトごと）に詳細な職務経歴を記載していきます。通常「編年体形式（古い経歴から新しい経歴へと順に記載）」もしくは「逆編年体形式（最新の経歴から過去を遡る順に記載）」のいずれかで記載します。私たちは後者の逆編年体形式をおすすめします。通常、もっとも企業が重視するのは直近の経歴であり、過去であればあるほど参考にする可能性が低くなるためです。伝えたいことは上（最初）から書いていくほうがよいでしょう。
モジュール内は大きく分けて、会社概要と職務経歴に分かれます。
a. 会社概要
法人格（例：株式会社、合同会社）、事業内容、設立年月日、資本金、従業員数、売上などを記載します。重要度は低いため1～2行で構いません。
b. 職務経歴
ここが職務経歴書で最重要のパートです。ここで合否のほぼすべてが決まります。職務経歴では主に以下の事柄について記載します。
- 期間
- 担った役職・役割
- 実施業務
- 目標達成・ミッション遂行のための工夫
- 具体的な数値の記載を伴った実績と成果
上記がひとつのモジュールになります。複数企業に在籍した経験がある場合は、そのモジュールを逆編年体形式で記載していきます。一方、所属企業が1社だけの場合は、各部署での経験やプロジェクトをひとつのモジュールとして分けて記載しても問題ありません。
書き方としては、箇条書きと文章による補足説明を適宜織り交ぜながら記載すると、見やすくて具体的な内容になります。具体例は次項にて詳述します。
個人での実績や成果はもちろん、マネジメントとしての職務を担っている場合は、チームや組織としての実績なども記載しましょう。
重要なのは、企業が見たいと思うエピソードや内容を記載することです。現役のプロダクトマネージャーであれば、企業側はプロダクトマネジメントの実績が一番見たいはずです。しかしマーケティングの経験ばかり書いてしまうと、「プロダクトマネージャーのポジションにはあまり関係ないな……」と思ってしまうでしょう。コツとしては、その企業の求人票に記載されている「業務内容」に近い経歴や実績を記載することです。そうすれば「おっ、この人は即戦力になるかもしれない」と判断されやすくなります。
未経験者であっても、プロダクトマネジメント業務に近いエピソードや、プロダクトマネージャーと関わった業務を記載するのがよいでしょう。どのエピソードをどこまで具体的かつ抽象的に記載するかは非常にセンスが問われる部分です。だからこそキャリアアドバイザーなどに相談することをおすすめします。
関わった業務をすべて記載する必要はありません。すべて書いてしまった結果、7～10ページにふくれあがった大作を何度も目にしました。先述の通り、こういった職務経歴書はすべてを読んでもらえない可能性も高く、「端的にまとめられない人」という印象を与えてしまうリスクがあります。「企業が欲しそうなエピソード」に絞りましょう。ただし、プロダクトマネージャーとしての経験年数が浅い場合は、多くなりすぎない程度にすべてを記載しても構いません。
（4）自己PR
自己PRは、一般的に文章か箇条書きで記載します。能力や強み、人柄など、自分のよいところをアピールする文章になりますが、「いったもの勝ち」にならないよう気を付けて記載しましょう。
自己PRをしっかりと書く人は比較的多いのですが、採用担当者は職務経歴詳細の欄ほど自己PR欄を見ていないことがほとんどです。なぜなら、自己PRはあくまで自己評価であり、自己をアピールすることを目的に記載された文章なので、実態と異なることが多いからです。
たとえば、「コミュニケーション能力には自信があります」と記載していても、コミュニケーション能力が高いか低いかは、求職者自身ではなく採用側が判断する、というのが企業のスタンスです。コミュニケーション能力をアピールしたければ、それを証明するエピソードを職務経歴の欄に記載するのがよいでしょう。また、エピソードを面接で聞かれた際に、しっかりと語ることができて相手が十分納得できるような内容のものでなければ、むしろ記載しないほうがよいでしょう。
また、志望理由も応募企業からのリクエストがない限りは記載する必要はありません。中途採用における書類選考は、あくまでも職務経歴を評価するためのものです。それを通過してはじめて、面接で志望動機が聞かれる流れとなります。書類選考を通過するために、まずは職務経歴の構成に全力を注ぎましょう。
そのうえで自己PRを書く意味は、自身の経歴を反芻し、企業に伝えたいことを整理する、というプロセスを踏むことにあります。自らが思う自身の強みを伝え、それにまつわるエピソードなどを記載することは、面接の準備にもきっと役に立つでしょう。
（5）資格
資格の「基本的な書き方」の例は以下の通りです。記載するような資格がない場合は、「資格」の項目自体設ける必要はありません。
＜資格＞
- TOEIC公開テスト スコア850（2022年〇月〇日）
- 基本情報技術者試験 合格（2012年〇月〇日）
- ITストラテジスト試験 合格（2020年〇月〇日）
職務経歴書の成功法則と実際の記入例
職務経歴書の成功法則とは
書類選考では、職務経歴の内容次第で合否のほぼすべてが決まります。職務経歴を書こうと思えば、これまでの経験を振り返り、やってきたことをただ単に箇条書きにして手っ取り早く仕上げることもできるでしょう。しかし、いくらすばらしい経歴や実績を有していても、企業側が「会ってみたい」と思える内容になっていないと書類選考を通過できません。プロダクトマネージャーの職務経歴書には、書き方の「成功法則」があります。具体的には次の3つの要素を盛り込むことを指しています。
- 「課題」「打ち手」「成果」の3つをワンセットにして書く
-
プロダクトマネージャー組織での立ち位置について書く
（組織体制・人数、担当プロダクト／1名で担当しているのか、複数名で機能ごとにプロダクトを担当しているのかなど） - 他の職種（エンジニアやデザイナーなど）の人達とどのような仕事をしてるのかを書く
成功法則の中でももっとも重要な「『課題』『打ち手』『成果』の3つをワンセットにして書く」について、もう少し丁寧に説明します。
プロダクトの「課題」
「課題」はプロダクトの課題を指します。どのような課題なのかはもちろん、それがなぜ解決すべき課題となっている（いた）のか、といった理由や背景も記載します。「なぜ」解決すべき課題である（あった）のか、を丁寧に書くことで、プロダクトの置かれている背景を読み手がイメージしやすくなります。とくに、なぜ複数ある課題の中から、その課題に目をつけて着手したのか、の意図も記載するようにしましょう。
課題に対して実際に行った「打ち手」
「打ち手」は、課題に対して実際に行った具体的なアクションを指します。たとえば、「数値分析／グロース施策の立案を行った」「○○を○○のメンバーと共に○か月の短い期間で改善した」「ユーザーヒアリングを○○人に○○回行った」「経営会議にて○○の提案を行った」などです。自分が実施した行動と業務内容をより具体的に記載するために、期間や人数などの数・量に関する記載はしておきましょう。この打ち手は比較的書きやすい部分だと思います。
「成果」
そして最後に「成果」です。ここがもっとも重要であり、記載するのが難しい部分だと思われます。ここでは、その打ち手によってプロダクトにどのような価値をもたらしたのか、までを記載してください。打ち手はアウトプットであり、ここで求められているのは、実績や成果であるアウトカムにあたります。
プロダクトマネージャーが達成すべきことは、「プロダクトロードマップを作成した」「開発マネジメントを行った」というアウトプットではなく、そのプロダクトにどう成長をもたらしたかです。どんなによいロードマップが描けたとしても、プロダクトが成長しなければ何の意味もありません。PVやCVRの変化、ユーザー数の変化、チャーンレート（解約率）の変化、売上の変化などのように定量的であればあるほど望ましいです。
実はこの「成果」の記載に苦戦する方が非常に多いです。打ち手はすらすら書ける一方で、「成果・実績は何ですか？」と問われると筆が止まってしまいます。日頃から「自分のやったことはどんな成果・実績につながっているのか」を意識しておくことが肝心です。
成果は第三者が客観的に判断できるように、できる限り具体的な数字を記載してください。定量的なものが一切なく定性的な表現ばかりになってしまっては、やってきたことは伝わるにしても、どれだけ力量があるのかは判断ができません。よほど魅力的な経歴の持ち主でない限り、定性的な記載ばかりではなかなか面接の機会を得ることはできないでしょう。採用担当者は「何をしてきたか」の確認もしていますが、「何をどれくらいやってきたのか」という定量的な確認も当然しています。ここでいう「どれくらい」は、期間のことだけではなく、規模や人数、成長／削減率なども含みます。たとえば、以下のようにできる限り数字で表現します。
- 主な体制について人数まで記載する（例：プロダクトマネージャー1名、UXディレクター1名、エンジニア2名、その他事業部関係者2名）
- 取り組みと実績について期間や達成率まで記載する（例：サービスMAUグロースのための新機能開発：機能リリースから3か月でサービス内最多利用者数の機能に成長。MAUは+35％で上昇しており、広告収益源として大きく貢献）
長期間にわたって実績を重ねてきた業務については、年度ごとの売上の推移や自分が担当する前後での比較を数値化して記載するなど、変化がわかるように工夫してみてください。
以上のように、成功法則に則って職務経歴書を作成するのは、多少時間と労力が必要となりますが、ここが十分に記載できればきっとどの企業からも「会いたい！」と思われるような結果をもたらしてくれるはずです。
ここからはエンジニアの職務経歴書の具体的な書き方を例を示しながら紹介していきます。なお、各職務経歴書は読者特典としてダウンロードできますので、原寸レイアウトで確認されたい場合はそちらもご活用ください。
エンジニアの職務経歴書の書き方
下記にエンジニアからプロダクトマネージャーをめざす場合の職務経歴書の成功法則記述か所の例を示しますので、参考にしながら記載してください。なお、本書では実際に書き込んだ職務経歴書の例も掲載しています。
エンジニアの職務経歴書の成功法則記述か所の例
■背景・課題
これまでマイクロサービスを推進してきた中で、各プロダクトチームの枠を超えた課題が取り組みづらい体制になっていた。結果、組織横断的な技術課題への取り組みがされずに蓄積されてしまっていた。
緊急度の高い課題にばかりリソースを向けて、緊急ではないが重要な課題への投資がなされていなかった。
［※注意点としては、開発を担当したシステムの名称だけを記載するのではなく、なぜ、その開発にアサインされたのかなど背景から記載しましょう］
■担当
組織横断技術課題解決チームのリーダー
エンジニア6名＋CTO
■打ち手
近視眼的でない課題に取り組むことをミッションとし、組織横断の技術課題解決チームを立ち上げた。横断分野のステークホルダーを招いたミーティングを定期的に実施し、長期的なビジネスニーズの洗い出しを行った。横断組織であるからこそ見える視点で、マイクロサービス化された各組織内の課題をさまざまな視点から探索した。
健全な形で“緊急ではないが重要な課題”に取り組めるよう、予算策定の段階で各部門長への働きかけを行い、対応リソースをプランニング段階で組み込むように修正を実施。
［※注意点としては、「・組織横断のミーティングを実施」「・組織ごとの予算策定から関与」など、箇条書きで済ませないようにしましょう。ここも背景や目的に触れながら書いていきます］
■成果
セキュリティインシデントの可能性のあるポイントに気付き、セキュリティアーキテクチャの更改に着手。将来的にユーザーに起きうる被害を未然に防ぐことができた。
副次的な効果として、セキュリティに関するハードルが高いエンタープライズ企業への訴求ポイントが増え、新規に2件の受注が発生した。
［※注意点としては、エンジニアの職務経歴書で欠けることが多い視点なので、ユーザーにとってのメリット、収益の貢献などの視点を入れて書きましょう］
