エンジニアとして転職活動を始めるとき、最初の壁になるのが職務経歴書です。
採用の現場では「もったいない書き方をしているな」と感じられる職務経歴書が多いと言われています。
経験豊富で技術力もあるはずなのに、それが全然伝わってこない。逆に、経験年数が浅くても「この人と働いてみたい」と思わせる書き方をしている人もいます。
その差はどこにあるのか？今回は、エンジニアの職務経歴書で採用担当者の目に留まるための書き方を、実践的にお伝えしていきます。
エンジニアの職務経歴書でよくある「残念な書き方」
まず最初に、多くのエンジニアがやってしまいがちな失敗パターンを見ていきましょう。
テンプレート通りに「やったこと」を羅列するだけ
転職サイトでダウンロードできるテンプレートをそのまま使って、こんな風に書いているケースが見られます。
– 基本設計
– 詳細設計
– 実装
– テスト
– リリース
これは、実は十分な情報になっていないと言われています。
なぜなら、設計・実装・テストはエンジニアなら誰でもやることだから。採用担当者が知りたいのは「何をやったか」ではなく、「どんな課題に対して、どう考え、何を成し遂げたのか」です。
実際、書き方を見直すことで書類通過率が改善されたという事例が報告されています。
技術スタックの羅列だけで終わっている
もう一つよくあるのが、使用した技術を並べるだけのパターンです。
「Java、Python、Ruby、AWS、Docker、Kubernetes…」
確かに使える技術を示すのは大事ですが、それだけでは「どのレベルで使えるのか」が全く分かりません。
同じ言語を5年使っていても、従来の手法を中心に書いている人と、Next.jsやReact等のモダンフレームワークで大規模SPA開発をリードできる人では全く違います。
プロジェクトの規模や役割が不明確
「ECサイトの開発に携わりました」と書かれていても、それが5人のスタートアップなのか、50人規模のプロジェクトなのか、自分がどんな立ち位置だったのかが分からないと、採用担当者は判断のしようがありません。
採用担当者が本当に知りたいこと
多くの採用担当者が職務経歴書で見ているポイントには、一定の傾向があると言われています。
1. 自社の課題を解決できるスキルがあるか
企業は「困りごと」があるから人を採用します。
– レガシーシステムをモダン化したい
– スケールするアーキテクチャを設計できる人が欲しい
– チームをリードできるエンジニアを探している
あなたの経験が、その企業の課題解決につながるかどうか。これが最重要ポイントです。
2. 入社後にミスマッチなく活躍できるか
技術力だけでなく、働き方のスタイルや価値観も見られています。
アジャイル開発の経験があるか、リモートワークで成果を出せるか、チームでのコミュニケーションはどうか。こうした要素も判断材料になります。
3. 成長意欲や学習能力があるか
技術は日々進化します。過去の経験だけでなく、「これから何をしたいか」「どう成長していきたいか」という姿勢も評価されるポイントです。
採用担当者に刺さる職務経歴書の書き方
では具体的に、どう書けば伝わる職務経歴書になるのか見ていきましょう。
職務要約は「あなたの価値」を端的に示す
冒頭の職務要約は、200〜400字程度であなたのキャリアのハイライトを示します。
NGな書き方：「〇〇株式会社でWebアプリケーション開発を3年、△△株式会社でインフラ構築を2年担当しました。」
良い書き方：「Web系スタートアップで5年間フルスタックエンジニアとして従事。ユーザー数10万人規模のSaaSプロダクトにおいて、React/Node.jsでの新機能開発をリードし、AWS上でのインフラ設計・構築も担当。特にパフォーマンス改善に注力し、ページ読込速度を平均2秒から0.5秒に短縮。現在はテックリードとして3名のメンバーをマネジメントしています。」
後者の方が、どんな規模感で、どんな成果を出してきたのかがイメージしやすくなっています。
プロジェクト経歴は「STAR法」で具体的に
各プロジェクトの記載にはSTAR法が効果的です。
– S（Situation）：状況・背景
– T（Task）：課題・タスク
– A（Action）：自分が取った行動
– R（Result）：結果・成果
例：
これなら、どんな課題に対してどう行動し、何を達成したのかが明確になります。
技術スキルは「レベル感」を添える
単に技術名を並べるのではなく、どの程度使えるのかを示しましょう。
良い書き方の例：
言語- Python（実務3年）：Django/FastAPIでのAPI開発、データ分析基盤の構築- TypeScript（実務2年）：React/Next.jsでのフロントエンド開発、設計から実装まで一貫して担当可能
インフラ- AWS：EC2/ECS/RDS/S3/CloudFrontを使った本番環境構築・運用経験あり- Docker/Kubernetes：コンテナ化からオーケストレーションまで実務で活用
このように、「何年使ったか」だけでなく「何ができるか」を具体的に書くのがポイントです。
自己PRは「再現性」を意識する
自己PRでは、あなたの強みが再現性のあるものとして伝わるように書きましょう。
NGな書き方：「コミュニケーション能力に自信があります。」
良い書き方：「チーム開発において、技術的な意思決定を透明化することを重視しています。前職では週次の技術共有会を立ち上げ、アーキテクチャ選定の背景や設計の意図をドキュメント化。結果、新メンバーのオンボーディング期間を2ヶ月から3週間に短縮できました。」
抽象的な表現ではなく、具体的なエピソードと成果で示すことで、説得力が増します。
フォーマットと見せ方の工夫
内容だけでなく、見やすさも重要です。
PDFで提出する場合のポイント
- 2〜3ページに収める：長すぎると読まれません
- 見出しを活用：パッと見で構造が分かるように
- 余白を取る：詰め込みすぎは読みにくい
- フォントは統一：見出しと本文でサイズを変える程度に
Markdown形式も選択肢に
一部の企業・エンジニアの間では、GitHubやNotionで職務経歴書を公開する傾向が広がっています。
特にWeb系企業への応募なら、Markdown形式の方が好印象な場合もあります。技術に対する姿勢や、情報整理能力が伝わりやすいという声が多く聞かれます。
応募企業ごとにカスタマイズする
これは手間がかかりますが、効果が期待できる方法です。
企業の求人票をよく読んで、その企業が求めているスキルや経験を強調するように調整しましょう。
例えば：- スタートアップなら→幅広い技術領域と自走力をアピール- 大企業なら→チーム開発経験やドキュメント作成能力を強調- マネジメント候補募集なら→リーダー経験や育成実績を前面に
すべて書き直す必要はありません。職務要約や自己PRの順番を入れ替えたり、強調するプロジェクトを変えたりするだけでも違いが出ます。
まとめ：職務経歴書は「あなたの価値」を伝えるツール
職務経歴書は、単なる経歴の記録ではありません。あなたがどんな価値を提供できるエンジニアなのかを伝えるツールです。
今回お伝えしたポイントをまとめると：
– 「やったこと」ではなく「成し遂げたこと」を書く
– 技術スタックには具体的なレベル感を添える
– STAR法で課題・行動・成果を明確に示す
– 応募企業の課題解決につながる経験を強調する
採用の現場で評価される職務経歴書には共通点があると言われています。それは、その人と働くイメージが湧くということ。
テンプレートをそのまま埋めるのではなく、あなた自身の言葉で、あなたのストーリーを語ってください。それが、次のキャリアを切り開く第一歩になるでしょう。
コメント