【技術の一覧では通らない】エンジニアの職務経歴書に何を書くか｜未経験から年収800万までの実感

転職しようと思って職務経歴書のテンプレートをダウンロードしてみたものの、スキルの欄に言語とフレームワークを並べたところで手が止まる。エンジニアの転職では、たぶんこれが一番あるあるだと思います。

僕は大手自動車メーカーの品質保証から未経験でエンジニアになり、そこから2回転職して、いまは年収800万円でフルリモートのPMをしています。その過程で職務経歴書は3回書きました。未経験でエンジニア転職したときはポートフォリオも作っていないので、企業に見せられるものは職務経歴書1枚だけでした。

そして正直に言うと、1回目の転職活動は、うまくいかずに一度あきらめています。そのときの書類は、いま見返せばおそらく技術の一覧表になっていました。この記事では、その反省と、2年後にうまくいったときに何が違ったのかを書きます。

エンジニアの職務経歴書は、なぜスキルの羅列になるのか

先に結論を書くと、職務経歴書に書くべきなのは「何を使ったか」ではなく「何を解決したか」です。当たり前のことなのですが、テンプレートを埋める作業をしていると、これがきれいに抜け落ちます。

理由ははっきりしていて、世の中に出回っている職務経歴書のフォーマットが「スキル」という欄を持っているからです。あの欄があると、人は素直に言語とフレームワークを書きます。書き終わると埋まった感じがするので、そこで満足してしまう。

でも採用する側から見ると、言語の一覧だけでは、その人が来て何が良くなるのかが一切分かりません。PHPが書ける人もMySQLが触れる人も世の中にたくさんいます。差がつくのはそこではないんですよね。

ちゅけ

僕も1回目は、スキルの表をきれいに作ることに一番時間を使っていました。今思うと完全に順番が逆でした。

SESのスキルシートをそのまま出すのが一番危ない

特に、常駐の現場でスキルシートを書き慣れている人ほど注意が必要です。スキルシートは「この人をこの現場に入れて大丈夫か」を確認するための書類なので、工程と技術さえ揃っていれば成立します。目的が違う書類を流用すると、経験が多い人ほど損をします。

職務経歴書のほうは「この人を採ったら、うちの事業がどう良くなるか」を読む書類です。同じ経歴でも、書く順番と粒度が変わります。

未経験のとき、僕が職務経歴書に書けたこと

未経験からエンジニアを目指す人の一番の悩みは、たぶん「書くことがない」です。実務経験がないのだから当然だと思います。

僕の場合、当時のカードは自動車メーカーでの品質保証3年と、コロナで工場が止まっていた時期に業務改善のためにPythonで作ったアプリケーションだけでした。車両のデータを計算してCSVに吐き出すだけの、GUI付きのシンプルなツールです。それでも社内の誰かが喜んでくれて、自分の作業も速くなったという事実がありました。

職務経歴書に書けたのは、この「誰の何が良くなったか」の部分です。技術としてはPythonとSeleniumしか書けることがなかったので、書きようがなかったとも言えます。結果として、ポートフォリオを作らずに社内SEのポジションで内定をもらえました。

前職の経験は「IT側の言葉」に翻訳できる

未経験の人がやりがちなのは、前職の経験をまるごと切り捨ててしまうことです。品質保証の仕事は、要するに「試作品を動かして出てきた不具合が本当に不具合なのかを切り分け、開発部門に対策を要求する」仕事でした。これは言葉を変えると、再現条件の確認と、優先度の判断と、他部署への説明です。

この3つは、そのままエンジニアの仕事に必要な能力です。未経験だからといって空欄にする必要はまったくありません。

ちゅけ

前職の仕事を「IT側の言葉に言い換える」だけで、書ける分量はけっこう増えます。

2回目に効いたのは、技術ではなく業界の文脈だった

エンジニアになって1年ほど経った頃、就業条件の悪さに耐えかねて1回目の転職活動をしました。結果は、納得できる年収の提示がほとんど得られず、活動をいったん止めています。

そこから1年、同じ会社で同じプロダクトに関わり続けて、2年経った頃にもう一度動きました。今度は同じ業界の競合他社から、当時の年収より300万円ほど高い水準で内定が出ました。実際の着地は年収800万円で、240万円のアップです。

この2回で、エンジニアとしての技術力がそこまで劇的に伸びたかというと、正直そんなことはありません。差がついたのは「その業界のプロダクトを2年見てきた」という文脈のほうでした。

つまり、職務経歴書に書くべきだったのは「PHPが書けます」ではなく「この業界の、この種類の業務システムの、こういう課題を触ってきました」だったということです。技術の一覧は、それ単体では市場価値になりません。

応募先ごとに書き分ける価値がある

文脈で評価されるということは、裏を返すと全社に同じ職務経歴書を送っても刺さらないということです。同じ経歴でも、同業種に出すなら業務知識を前に、異業種に出すなら汎用的な設計や改善の話を前に持ってくる。この並べ替えだけで印象は変わります。

全部書き直す必要はありません。職務要約の5行と、自己PRの並び順を変えるだけで十分です。

書き始める前にやると一番ラクな準備

テンプレートを開く前に、まずメモ帳で「関わった案件」と「その案件で何が良くなったか」だけを箇条書きにしてください。技術名は一切書かないのがコツです。

• どんな事業・業務のためのシステムだったか
• そのシステムの、誰のどんな困りごとを扱っていたか
• 自分は何を担当し、担当前後で何が変わったか
• 変わったことを数字で言えるか（時間・件数・金額・人数）
• その中で自分が判断したこと、提案したことは何か

ここが埋まってから、初めて言語やフレームワークを「手段として」添えます。順番を逆にするだけで、書類の読みやすさは明らかに変わります。

数字が出せないときは「範囲」で書く

守秘義務があったり、そもそも測っていなかったりで数字が出ないことはよくあります。その場合は無理に作らないでください。盛った数字は面接で必ず崩れます。「月次で行っていた集計作業を自動化」「担当領域は5画面程度」のように、範囲や規模感で書けば十分伝わります。

2回目に転職した時の私の職務経歴書一部

以下に2回目に転職をした時の私の経歴書の内容を記載します。
粒度的にはこんな感じで各会社における経験を時期ごとに記載しています。

研修申込みシステム開発

自社開発の顧客が利用する研修申込みシステムの開発にTLとして参画している。

TLという役割のもと自身で開発を行うとともに
SWEの進捗管理、コードレビューなどを行っている。

【担当開発工程】

要件定義～保守運用

【業務詳細】

研修申込み利用をしている他部門の要望をヒアリングし業務効率改善、売上向上のための改修を行っている。

要望内容を鵜呑みにして開発するのではなく

本質的な課題は何かを依頼部門と話し合い、的確な解決策を見つけた上で要件定義を行った。

開発フローにはアジャイル開発を用いておりリリース後社内からのフィードバックを受けて

柔軟に要件定義を変更することによりユーザー目線で一番使いやすいシステムを指針として開発をしている。

コードレビューを頻繁に実施している。

【取り組んだ課題】

複数開発者が各機能について開発している案件であったため結合テスト以前から結合部でのバグが多発しており、リリースの延期が見込まれていた。

【工夫した点】

各自が見つけたコードの共通部分や発見したバグに関しては逐一情報共有し、担当者を定め修正をすることで品質を向上させる仕組みを構築した

【工夫した理由】

TLとして納期の厳守が要求される立場であると自覚していた。

1開発者として実装で貢献することも考えられたがチーム全体の生産性を考えたときにリソース頼りで力任せに解決するのではなく

仕組化したほうが場合の以下の理由からメリットが大きいと考えたため仕組化と運用を実行した。

①多くの人員に対し影響するため効果が大きい

②一度仕組みを構築してしまえば将来的にも通用する

【取り組みの成果】

品質が向上することでバグ修正に伴う手戻りが減り開発効率が向上した。結果として新たなリソースを追加することなくリリースの日時延期を防ぐことができた。

ちゅけ

僕が1回目にやっていたのは、右側のリストのほうでした。反省しています。

まとめ：職務経歴書は技術の証明書ではない

エンジニアの職務経歴書というと、どうしても自分の技術力を証明する書類だと思ってしまいます。でも実際に読まれているのは、「この人がうちに来たら、どの仕事を任せられるか」が想像できるかどうかだけです。

技術の一覧は、その想像を助ける材料のひとつでしかありません。まずは関わった事業と、そこで何が良くなったかを書く。言語はそのあとに添える。この順番を変えるだけで、書ける量も通りやすさも変わります。

僕自身、1回目の転職では条件面で妥協して痛い目を見ています。そのあたりの失敗は転職失敗して地獄だった2年半の記事に、未経験から2年でどう動いたかはエンジニア未経験から二年、年収800万、フルリモ環境を勝ち取るまでに詳しく書いています。あわせて読んでもらえると、この記事の背景が分かりやすいと思います。