はじめに
研究開発チームのマネージャーとしてチームの体制強化が私のミッションの１つなので、日々懸命に採用活動に取り組んでおり、毎日たくさんの職務経歴書に目を通します。
＞＞＞弊社「リサーチサイエンティスト」の求人票はこちら＜＜＜
ここで、心の底から残念に思うことがあります。
それは、ダメな経歴書があまりにも多い……ということです。
それぞれ熱心に経歴書を書いているはずだから本当に申し訳ないけれど、正直しっかり読む気になれない……そこをがんばって読み込んでも結局その人のことがさっぱりわからない……
そんな職務経歴書が多すぎるのです。
そこで、この記事では、
現場のマネージャーが考える「エンジニア・研究者のための職務経歴書の書き方」
を徹底解説したいと思います。
あくまで個人的な見解であることを承知で読んでください。
結論
最初に結論を述べます。
「読み手（採用側）が知りたいこと」と「自分が取り組んできたこと」とが重複する内容だけを取り出し、その「要約」を「自分のアピール」として職務経歴書に書いてください。
ここで「読み手が知りたいこと」とは、再現性の有無です。
これまで培ってきたスキルをウチの会社でもうまく発揮して、また成果を出せるか？（成果を再現できるか？）……ということを、読み手は知りたいのです。
そのため、
- どういう背景のもと、
- どういう課題があって、
- それに対してどうアプローチし、
- その結果として何を得たか（成果）
というストーリーを語って「類似の背景・課題に対して同じ成果を出せるよ！」と主張する必要があります。これを要約したものが「自分のアピール」になります。
典型的なアンチパターン
上記の結論を裏返すと、アンチパターンが浮き彫りになります。
- 「自分が取り組んできたこと」しか書かれていない
- 要約されていない
1. 「自分が取り組んできたこと」しか書かれていない
前者の具体例としてよくあるのが、業務内容（自分が取り組んできたこと）の箇条書きです。例えば、下記のような記載はよく目にします。
- 期間
- 2020年7月〜2021年3月
- 業務内容
- クライアントへの業務ヒアリング
- 分析項目の策定
- データ分析
- 分析結果をもとにした施策立案
- クライアント向けのレポート作成
- 環境
- Windows / Linux
- Python
- SQL
- AWS
- 役割
- 案件リーダー
- メンバー３人
おそらく、本人は「自分が取り組んできたこと」を端的にまとめたつもりなのでしょうが、残念ながら、これだけでは事実の列挙に過ぎず、「読み手が知りたいこと」にはなりません。
2. 要約されていない
次に後者の場合、じっくり読み込めば「知りたいこと」が書かれていることに気づけるのですが......残念ながら、現場のマネージャーはそこまで読み込む時間・労力がないことがほとんどです。
例えば、経歴書冒頭の「職務要約」の欄に 1000 字以上くらいの分量でびっしり文章が書かれていたり、経歴書全体で６ページ以上あったりすると、「要約してくれよ…」とゲンナリして読み進める気力が湧きません（申し訳ないけど、読み手も人間なので勘弁してほしい。。）
そうすると「知りたいこと」が書かれていることに、たいてい気づけません。
気づけなければ書かれていないのと同じです。
土俵に乗ってすらない
前者・後者いずれの場合も、結局「知りたいことが書かれていない」と結論づけられます。
この場合、私は何も分からないので不合格にします。
つまり、合否を判断できる材料（知りたいこと）がどこにもないので「合否を判断できない」と判断せざるを得ず、この場合は自動的に不合格になってしまうのです。これは、土俵に乗ってすらないことを意味します。
そして、この「土俵に乗ってすらない」状態で落とす（あるいは、スカウトを送らずスルーする）のは、体感で全体の８割を超えます。
それくらい、誰もが職務経歴書に「知りたいこと」をきちんと書けておらず、適切に自分をアピールできていないのです。
では具体的にどうすればよいのか？
ここから、自分のアピール（＝「読み手（採用側）が知りたいこと」と「自分が取り組んできたこと」とが重複する内容の要約）を絞り出すための方法論を説明します。
１. 「自分が取り組んできたこと」を網羅的に洗い出す
まずは自分が取り組んできたことを、全部書き出します。先の「ダメな具体例」のように、この時点では業務の箇条書きで構いません（下記再掲）
- クライアントへの業務ヒアリング
- 分析項目の策定
- データ分析
- 分析結果をもとにした施策立案
- クライアント向けのレポート作成
大事なことは、些細な業務も網羅して洗い出すことです。自分が担っている業務が意外と多岐にわたることに気づくのではないでしょうか。
２. ストーリー化する
次に、洗い出した業務をストーリー化します。ここで「ストーリー化」とは、具体的な経緯を交えてその業務と実績を文章で説明することです。
理想的には、先に説明したとおり、
- どういう背景のもと、
- どういう課題があって、
- それに対してどうアプローチし、
- その結果として何を得たか（成果）
を語ることです。
例えば、先の「ダメな具体例」の箇条書きは、次のようにストーリー化できるでしょう。
データ分析を用いた業務改善コンサルティングに携わりました。具体的には、クライアントから業務フローをヒアリングし、ボトルネックになっている業務を特定した上でその原因について複数の仮説を立て、これらを検証するためのデータ分析を行いました。また、データ分析の結果に基づいて業務改善のための施策を立案し、クライアント向けのレポートを作成しました。クライアントと協働して施策を実行に移し、業務を実際に改善することでその効率を向上させ、クライアントの業績アップに貢献しました。
架空の例なので表面的な記載になりがちですが、ストーリー化の意味は理解できると思います。
３. 要約する
ストーリー化しただけでは文章が冗長です。読み手（採用側）が知りたいこと（再現性の有無）だけを抽出し、徹底的に要約します。
例えば、先の例は次のように要約できるでしょう。
業務改善コンサルティングに携わりました。業務フローのボトルネックに対して仮説を立て、これを検証する為のデータ分析を行った上で、業務改善に向けた施策をクライアントに提案しました。本施策で業務効率が15％改善し、クライアントの業績向上に貢献しました。
先の「ダメな具体例」のような箇条書きと比較すると、こちらの方が「会ってみたい」と感じるのではないでしょうか。ウチの会社でもまた成果を出せそう（再現性がありそう）な印象を受けるからです。
より具体的な例（私自身の経歴書抜粋）
適当にでっち上げた例だけではリアリティに欠けるので、（手前味噌すぎて恐縮ですが...）私自身の経歴書を具体例として晒したいと思います。
下記は、私が民間企業の研究者・データサイエンティストとして働いていたときの経歴です。
「何に取り組んでどういう成果を上げたか」の要約が端的に記載されていると思います。
タイヤ空気圧の異常をその回転速度信号のみからリアルタイムに検出する特殊システムの研究開発に携わりました。低い検出精度（誤検出率20％）しかなかった同システムを、統計的学習を用いて実環境で頑健に動作可能なレベル（同0.5％以下）まで改良し、入社から3年でその実用化に成功しました。
下記は、私が研究開発のマネージャーとして技術広報に取り組んでいたときの経歴です。これも「何に取り組んでどういう成果を上げたか」を端的に表現することを意識して書いています。
研究開発チームの体制強化の一環として、技術広報に携わりました。例えば、学会出展、社内発表会の実施、技術コンテンツの制作など、会社が持つ技術的な資産を社内外に発信し、メンバーが研究活動に誇りを持てる取り組みに貢献しました。
繰り返しますが「読み手（採用側）が知りたいこと」は、再現性の有無です。
なので、ストーリーを端的に語って成果をドヤってください。
そうすれば「候補者が同じ文脈に立たされたとき、同じスキルを発揮して同じ成果を出すだろう」と、解釈してもらえるはずです。
おわりに
個人的には、
- 箇条書きで終わっている人 → 全体の６割
- 要約できていない人 → 全体の３割
- しっかり書けている人 → 全体の１割
くらいの感覚です。
つまり、適切に経歴書が書けている人は、本当に、本当に、少ない。これはマジです。ということは、少しの工夫と心がけだけで、他の候補者より有利に立てることは間違いありません。
この記事を読んだ皆さんには、読み手フレンドリーな職務経歴書を書いて、転職活動を有利に進めていただきたいと思います。
We are hiring!
弊社（BuySell Technologies）では、新設の研究所で刺激的な研究テーマに取り組んでいただける研究者（リサーチサイエンティスト）を大募集しています。
＞＞＞弊社「リサーチサイエンティスト」の求人票はこちら＜＜＜
画像処理、音声認識、強化学習などのキーワードにビビッときた人は、ぜひご応募ください。
もちろん、研究者だけでなくエンジニアも絶賛募集中です。
...ただし、ダメな経歴書を送ると私（や他のマネージャー）が容赦なくリジェクトしますので、そこはご了承ください。
（ヨロシクね！！）