転職活動で損しないために——エンジニアの職務経歴書、本当に使える書き方

エンジニアの転職市場、今どうなっているのか

「転職しようかな」と思い始めた瞬間、多くのエンジニアが最初に感じるのは「自分のスキルは市場で通用するのか」という不安ではないでしょうか。実際のところ、ITエンジニアの転職市場は今も売り手市場が続いています。ただし、それは「どんなスキルでも通用する」という意味ではありません。求められるスキルセットは年々明確になっており、何となくの経験をただ積み上げてきただけでは、思うような評価を得られないことも増えています。

この記事では、転職を考え始めたエンジニアが「職務経歴書」をどう書くべきか、という点に絞って深掘りします。面接対策や転職エージェントの選び方など気になることはたくさんあるかもしれませんが、まずは職務経歴書なしに選考は始まりません。そして、多くの若手エンジニアが「なんとなく書いた」と後悔する書類でもあります。

なぜエンジニアの職務経歴書は難しいのか

一般的なビジネス職の職務経歴書と、エンジニアのそれは根本的に異なります。営業職であれば「売上○○円達成」という数字が自然に出てきますが、エンジニアの仕事は数字に落としづらいことが多いのです。

「Webアプリケーションの開発をしていました」という一文では、採用担当者にはほとんど何も伝わりません。どんな規模のシステムか、どんな役割を担ったか、何を技術的に工夫したか、チームはどんな構成だったか——こうした情報がなければ、スキルの判断が困難なのです。

さらにやっかいなのが「書きすぎ問題」です。技術的な詳細を全部書こうとすると、10ページを超える職務経歴書ができあがります。採用担当者がそれを読む時間は、多くて5分程度。情報が多すぎると、伝えたいことが埋もれてしまいます。

採用担当者が職務経歴書で見ているポイント

採用担当者（とくに技術面接の前段階を担う人事担当者）が確認したいのは、大きく3つです。

ここで重要なのは、「使ったことがある」と「実務で活用できる」の差です。たとえば「Dockerを使っていました」という記述は、ローカル環境でコンテナを起動しただけでも書けてしまいます。採用担当者はそこをよく見ています。どういう場面で、どういう判断のもとで使ったか、という文脈が伴って初めて「実力がある」と判断されるのです。

若手エンジニアにありがちな失敗パターン

経験3〜5年程度のエンジニアが職務経歴書を書くとき、よく陥るパターンがあります。

技術スタックをただ羅列する

「使用技術：Java、Spring Boot、MySQL、AWS、Docker、Jenkins...」という一覧は確かに情報ですが、それだけでは評価につながりません。大事なのは「どんなシステムで、どんな規模で、どんな問題を解くために使ったか」という文脈です。たとえば同じJavaでも、月間100万リクエストのAPIを設計した経験と、社内の小規模バッチ処理を書いた経験では、求められる力量がまったく違います。

担当業務を「作業」ベースで書いてしまう

「ユーザー管理画面の開発」「APIの実装」「バグ修正対応」——こういった記述は、仕事の内容として間違いではありません。しかし採用担当者に刺さるのは、その業務の中で「あなたが何を考え、何を判断し、どう貢献したか」という部分です。

たとえばこんな書き方ができます。「ユーザー管理画面の開発において、既存の検索処理がN+1問題を引き起こしていたことに気づき、クエリを最適化することで画面表示速度を約60%改善した」——具体的な問題認識と行動と成果がセットになっていると、読んだ人の印象が大きく変わります。

職責範囲を曖昧にする

「設計から実装まで担当しました」という記述をよく見かけますが、設計といっても詳細設計なのか基本設計なのか、それとも要件定義レベルまで関与したのかで、求められる経験レベルが大きく変わります。「チームでの役割」を明確にすること、とくにメンバーだったのかリードポジションだったのかは必ず書くようにしましょう。

採用担当者に刺さる職務経歴書の書き方

プロジェクト単位で整理する

職歴を「○○株式会社　20XX年〜20XX年」という時系列で書くだけでなく、携わったプロジェクトの単位で整理することをおすすめします。在籍中に複数のプロジェクトを経験している場合は、それぞれを分けて書くことで、経験の幅が伝わりやすくなります。

各プロジェクトには、次の要素を盛り込みましょう。

• プロジェクトの概要（何のためのシステムか、規模感）
• 自分の役割（メンバー/リード/PM補佐など）
• 使用技術（なぜその技術を選んだかも添えると◎）
• 取り組んだ課題と成果

「改善した話」は最強の武器になる

新機能の実装より、既存の問題を発見して改善した話のほうが、技術力・問題解決力の両面をアピールできます。なぜなら改善には「現状を正しく認識する力」「優先度を判断する力」「解決策を設計する力」「実装して効果を検証する力」が全て含まれているからです。

「レスポンスタイムを○ms改善した」「デプロイ頻度を週1回から日次に改善した」「テストカバレッジを○%から○%に向上させた」——このような成果は、数字が具体的であればあるほど説得力が増します。

転職理由と志望動機はセットで考える

職務経歴書の最後に「転職理由」「志望動機」を添える場合、ネガティブな理由（残業が多い、人間関係、給与不満）ではなく、ポジティブな方向性（より大規模なシステムに挑戦したい、特定の技術分野を深めたい、プロダクト開発に関わりたい）に変換することが基本です。ただし、それが空虚な建前になってしまうと、面接での深掘りに耐えられなくなります。

自分が本当に「次のステップで何をしたいのか」をしっかり言語化し、その企業・ポジションとどう結びつくのかをロジカルに説明できるようにしておきましょう。

完成したら必ずやるべき3つのこと

第三者に読んでもらう

書いた本人は内容を知っているので、どうしても「伝わっている気」になってしまいます。エンジニアではない友人や家族に読んでもらい「何をした人かわかった?」と聞いてみてください。もしうまく伝わっていなければ、それは技術外の採用担当者にも同様に伝わっていないということです。

応募先に合わせて微調整する

職務経歴書は一種類を使い回すものではありません。応募する企業が求めるスキルや文化に合わせて、強調するポイントを変えることが大切です。スタートアップに応募するなら「少人数で幅広くこなした経験」、大手企業なら「大規模システムでの堅確な設計経験」を前面に出すなど、軸足を変えましょう。

誤字脱字・技術用語の表記揺れをチェックする

「JavaScript」「Javascript」「javascript」——こうした表記揺れは、細部への注意力を問われるエンジニアにとって印象が悪くなる可能性があります。技術用語の正式表記を改めて確認し、統一しておきましょう。

まとめ

職務経歴書は「自分の仕事の記録」ではなく「次のキャリアのための提案書」です。何ができるかではなく、どんな問題をどう解いてきたか、そして次の環境で何をしたいか——そこに焦点を当てて書くことで、書類選考の通過率は大きく変わります。

転職活動は長期戦になることも多いですが、職務経歴書の質を上げることが、その後の面接・条件交渉・内定獲得まで、すべての土台になります。まずは今の自分の職歴を棚卸しするところから始めてみてください。思っていたより、伝えられることはたくさんあるはずです。