エンジニアの職務経歴書、採用側は最初の30秒でここを見ている

「職務経歴書に書けるようなことをやっていない気がする」「技術は使ってきたけど、どう書けば評価されるのかわからない」と感じたことはありませんか？

その感覚は、あなたの経験が薄いからではありません。社内で当たり前にやってきた仕事を、社外に通じる言葉へ翻訳する方法を教わったことがないだけです。私は採用側として職務経歴書を数多く読んできましたが、「実力はありそうなのに、書類でそれが伝わらない人」が本当に多い。もったいないの一言です。

この記事では、採用側が職務経歴書のどこを、どんな順番で見ているのかを開示しながら、評価される書き方に変換する方法を整理します。

採用側は最初の30秒で3つしか見ていない

書類選考の現場は、じっくり読む場ではありません。応募が多い求人では、1通あたり最初の判断は30秒〜1分。その短時間で見ているのは、実はこの3つです。

1. 直近のプロジェクトで「何の役割」を担ったか：実装だけか、設計からか、リードか
2. 規模感：チーム人数、ユーザー数、トラフィック、データ量など、経験の文脈がわかる数字
3. 技術選定や改善に「自分の意思」が入っているか：言われたものを作ったのか、判断をしたのか

逆に言うと、この3つが冒頭で読み取れない職務経歴書は、どれだけ技術用語が並んでいても「よくわからない」の箱に入ります。時系列で業務を羅列する前に、直近の役割・規模・判断が最初のページで見えるか。まずここを確認してください。

技術スタックの羅列が響かない理由

「Java / Spring Boot / AWS / Docker / MySQL…」と使用技術を並べるセクション、ほぼ全員が書きます。もちろん必要な情報ですが、羅列そのものは評価をほとんど動かしません。

採用側から見ると、技術名の羅列からは「触ったことがある」以上のことがわからないからです。同じ「AWS」でも、コンソールを操作したことがあるのと、コスト構造を踏まえてアーキテクチャを設計したのでは市場価値がまったく違います。でも羅列では、その差が消えてしまう。

差が出るのは、技術名に深さの文脈を添えたときです。

• × AWS
• ○ AWS（ECS/Fargate中心の構成設計、月額コストを32%削減）

「何を使ったか」ではなく「それで何を判断し、何が変わったか」。これが、社内評価と市場評価のズレを埋める翻訳作業の核心です。

「普通の業務」を実績に変換するテンプレート

削減とか改善とか、数字になるような派手な実績がないんです。保守運用が中心だったので…。

保守運用こそ、書き方で差がつく領域ですよ。「障害対応をしていました」ではなく「どんな障害を、どう再発防止したか」。地味に見える仕事の中の判断を言語化できる人は、採用側からすると逆に信頼できます。

変換の型はシンプルで、**「状況 → 自分の判断・行動 → 結果」**の3点セットです。

ポイントは、**数字は「成果の大きさ」の証明ではなく「文脈の提供」**だということです。月10件が2件でも、5人チームでも構いません。規模が伝われば、採用側は自社に引きつけて評価できます。「すごい数字」を盛る必要はないんです。

なお、レビューや障害対応のような「見えにくい仕事」が社内で評価されにくい構造については、レビュー業務が評価されない理由や障害対応とキャリアの記事でも掘り下げています。

書く前にやる「経験の棚卸し」が9割

職務経歴書がうまく書けない人の多くは、書き方ではなく棚卸しの材料不足でつまずいています。書く前に、プロジェクトごとに次の質問に答えてみてください。

1. そのプロジェクトで、自分がいなかったら何が起きていたか？
2. 自分が「決めた」ことは何か？（技術選定、設計方針、優先順位、やらないと決めたこと）
3. 前任者・他メンバーと比べて、自分のやり方の違いは何だったか？
4. 数字で語れるものはあるか？（件数、時間、人数、頻度、金額）
5. その経験を後輩に教えるとしたら、何をコツとして伝えるか？

特に1と2は、「担当業務」を「実績」に変える源泉です。ここで出てきた答えをテンプレートに流し込めば、職務経歴書の骨格は8割完成します。

自分の市場価値がどう決まるかの全体像はエンジニアの市場価値はどう決まるかで整理しているので、棚卸しの前に読むと視点が定まりやすいです。

そのまま使える構成テンプレート

棚卸しができたら、次は器です。採用側の読む順番に合わせた、実戦的な構成を載せておきます。

1. 職務要約（3〜4行）
   - 経験年数・主戦場の領域・直近の役割・強みを凝縮
   - 例：「Web系開発7年。直近3年はECサイトのバックエンドリードとして
     設計〜運用を担当。パフォーマンス改善と若手育成が強み」

2. 活かせるスキル（表形式・5〜8行）
   - 技術名＋習熟の文脈（年数ではなく「何をしたか」）

3. 職務経歴（新しい順・直近を厚く）
   - プロジェクトごとに：概要／規模（人数・ユーザー数）／
     自分の役割／工夫・判断／成果

4. 自己PR（行動エピソード2つまで）

ポイントは冒頭の職務要約です。ここで「役割・規模・判断」の3点が伝われば、続きを読んでもらえます。逆に要約がないと、忙しい面接官は職歴の羅列から自力で人物像を組み立てることになり、その手間の分だけ評価は保守的になります。

もうひとつ地味に効くのが、プロジェクト欄の「工夫・判断」行を独立させることです。業務内容と成果の間に「なぜそうしたか」を1〜2行挟むだけで、読み手はあなたの思考の解像度を判断できます。技術選定の理由、やらないと決めたことの理由——ここが書ける人は、面接でも同じ質問に淀みなく答えられるので、書類と面接の一貫性も生まれます。

分量の目安は、経験5年で2ページ、10年で3ページまで。それを超えると要約力を疑われ始めます。「全部書く」のではなく「選んで書く」。職務経歴書は履歴の記録ではなく、プレゼン資料だと考えてください。

職務経歴書でやりがちなNG3つ

1. 全プロジェクトを同じ濃度で書く

10年分を均等に書くと、直近の重要な経験が薄まります。直近2〜3年を厚く、古いものは要約が原則です。採用側が一番知りたいのは「今のあなた」です。

2. 社内用語をそのまま使う

「基幹システムのフェーズ2対応」「〇〇連携案件」——社内では通じても、初見の読み手には何も伝わりません。固有名詞は「何をするシステムか」に置き換えてください。

3. 自己PRで人柄だけを語る

「コミュニケーションを大切にしています」だけでは判断材料になりません。人柄はエピソードで示すもの。「仕様の齟齬を防ぐため、実装前に画面モックで合意を取る進め方をしていた」のように、行動で書くと信頼されます。

書き上げたら：市場に出して「読まれ方」を確かめる

職務経歴書は、書いて終わりではなく市場の反応で磨くものです。転職サイトに登録して職務経歴を公開すると、どんな企業からどんなスカウトが来るかで、自分の経歴がどう読まれているかがわかります。

想定と違う職種のスカウトばかり来るなら、書き方が狙いとズレているサイン。狙い通りの企業から声がかかるなら、その経歴書は機能しています。転職する気が固まっていなくても、この「読まれ方テスト」だけで登録する価値はあります。具体的な使い方は転職する気がなくても転職サイトに登録すべき理由にまとめています。

まとめ

エンジニアの職務経歴書について、要点をおさらいします。

• 採用側が最初に見るのは役割・規模・自分の判断の3つ。冒頭で見えるように書く
• 技術スタックの羅列ではなく、技術名＋判断＋変化で深さを示す
• 実績がない気がするのは棚卸し不足。**「自分がいなかったら何が起きたか」**から掘る
• 数字は盛るためではなく文脈のため。小さい数字でも書く
• 完成したら市場に出して、スカウトの質で「読まれ方」を検証する

社内で当たり前にやってきたことを、外の言葉に翻訳する。それだけで、書類の通過率も、あなた自身の自己認識も変わります。まずは直近プロジェクトの棚卸し5問から始めてみてください。

関連記事

• エンジニアの市場価値はどう決まるのか｜社内評価との違い
• 転職する気がなくても転職サイトに登録すべき理由
• レビュー業務が評価されない会社で起きていること
• 社内評価が低いのに市場価値が高いエンジニアの特徴