実務経験があるのに書類選考へ通らないエンジニア向けに、求人とのずれ、職務要約、成果、技術レベル、案件経歴の見直し方と改善手順を解説します。
「実務経験があるのに、書類選考で落ち続けている」
「求人の必須条件を満たしているはずなのに面接へ進めない」
「職務経歴書のどこを直せばよいのか分からない」
経験者エンジニアの書類選考では、技術力そのものだけでなく、募集ポジションとの一致、経験の深さ、成果の再現性、読みやすさが判断されます。十分な経験があっても、採用側が短時間でそれを確認できなければ通過しません。
本記事では、書類選考に通らない原因を7つに分け、職務経歴書の修正方法、経験の伝え方、求人との合わせ方、改善効果の確認方法まで解説します。
最初に確認すること：問題は本当に書類だけか
応募結果を感覚で判断せず、次の項目を一覧にしてください。
- 応募日と企業名
- 求人の職種・期待役割
- 必須条件を満たす項目と不足する項目
- 使用した職務経歴書の版
- 応募経路
- 書類結果と連絡までの日数
- エージェントや企業からのコメント
数件落ちただけでは原因を特定できません。希望条件が高い、求人との技術領域が違う、書類が伝わりにくいなど、複数の要因を分けて考えます。
同じ書類で応募し続けるのではなく、5〜10社程度を一つの単位として、求人の選び方か書類のどちらを変えたか記録してください。変更点と結果を対応させることで、改善すべき場所が見えます。
原因1：求人が求める役割と経験がずれている
「Java経験3年」のように言語だけが一致していても、求人が求める役割と違えば通過しません。
例えば、同じJava求人でも次のような違いがあります。
- 指示された仕様をもとに実装するメンバー
- 基本設計からテストまで担当する中堅
- チームの設計方針とレビューを担うリード
- 顧客と要件を調整する上流担当
- 大規模トラフィックや性能改善に強い専門職
求人票から、技術、工程、役割、業界、チーム規模の5項目を抜き出し、自分の経験と比較しましょう。3つ以上が大きくずれている場合は、書類の表現より応募先の選定を見直す方が先です。
改善策
応募先を「挑戦」「同等」「安全」の3段階に分けます。すべてを挑戦求人にせず、現在の経験と近い求人も含めて反応を確認します。
原因2：冒頭で強みが伝わらない
採用担当者は、職務経歴書を最初から最後まで精読してから判断するとは限りません。冒頭の職務要約で、募集との一致が分かるようにします。
弱い例は、経歴を時系列で並べただけの文章です。
ITエンジニアとして複数プロジェクトを経験してきました。コミュニケーションを大切にし、幅広い業務へ柔軟に対応できます。
改善例では、経験年数、得意領域、担当工程、技術、成果を短くまとめます。
Web業務システムのバックエンド開発を5年経験。Java・Spring Bootを用いた基本設計、実装、テスト、リリース後の改善を担当した。直近は6名チームのサブリーダーとしてコードレビューと進行管理を行い、バッチ処理の見直しによって夜間処理時間を約35%短縮した。
応募先がリーダーを求めるならレビューと推進経験を前へ、実装者を求めるなら設計・実装と技術課題を前へ出します。
原因3：業務内容だけで成果が書かれていない
「設計・開発・テストを担当」という記載では、どの程度の難易度を担い、どんな価値を出したかが分かりません。
実績は次の順番で整理します。
- どのような課題があったか
- 自分はどの範囲を担当したか
- どのように考えて行動したか
- 結果がどう変わったか
- 他の環境でも再現できる学びは何か
数値がない仕事でも書けます。「問い合わせ分類を見直して一次回答できる範囲を広げた」「レビュー観点をテンプレート化し、指摘のばらつきを減らした」のように、前後の変化を具体化してください。
数値を使う場合は、根拠を説明できるものだけにします。チーム全体の成果を、自分一人の実績として書いてはいけません。
原因4：技術スタックのレベルが分からない
スキル欄に言語名を大量に並べるだけでは、実務でどこまで使えるか判断できません。
| 書き方 | 伝わる内容 |
|---|---|
| Java：3年 | 期間だけで担当範囲が不明 |
| Java：業務システムのAPI・バッチ実装、既存コード改修、単体テスト | 使用場面と実装範囲が分かる |
| AWS：EC2、RDS、S3 | サービス名だけで操作レベルが不明 |
| AWS：既存構成の運用、CloudWatch調査、Terraformの修正・レビュー | 実務での関与レベルが分かる |
「触ったことがある」「調べながら対応できる」「独力で設計・実装できる」「他者へレビューできる」を区別します。募集に関係しない古い技術まで上部へ詰め込まず、関連性の高いものから記載しましょう。
原因5：プロジェクトごとの担当範囲が曖昧
SESやSIerの経験では、会社名よりプロジェクトの中身が重視されます。各案件について次を揃えてください。
- システムの目的と利用者
- プロジェクト規模とチーム人数
- 担当期間
- 担当工程
- 使用技術・ツール
- 自分の役割
- 課題、行動、成果
「要件定義〜運用」と全工程へ印を付けるだけでは、自分が主担当だったのか補助だったのか分かりません。要件定義なら、顧客ヒアリング、要件整理、合意形成のどこまで行ったかを書きます。
守秘義務に配慮し、顧客名や機密情報を出さずに、業界、システム種別、規模、技術的課題を説明します。
原因6：応募先ごとの調整がない
すべての企業へ同じ職務経歴書を送ると、重要な経験が埋もれます。経歴を作り替える必要はありませんが、次の箇所は求人ごとに調整できます。
- 職務要約の2〜4行
- スキル欄の順番
- 代表実績として詳しく書く案件
- 自己PRのテーマ
- ポートフォリオや技術記事の掲載順
求人票に「性能改善」「チームリード」「顧客折衝」が繰り返し書かれていれば、自分に該当する経験を上部へ移します。求人の言葉をそのままコピーするのではなく、実体験で裏付けてください。
原因7：読みづらさと情報の不整合がある
内容が良くても、採用側が探せなければ評価されません。
次の状態は修正が必要です。
- 日付の表記が統一されていない
- 履歴書と職務経歴書で在籍期間が違う
- 長い段落が続き、担当業務と成果が混ざっている
- 略語や社内用語の説明がない
- 同じ自己PRが複数箇所で繰り返される
- 使用技術のバージョンや担当工程に矛盾がある
- ファイル名が「最新版」「修正版2」のようになっている
見出し、箇条書き、表を使い、採用側が「何ができる人か」「募集との接点はどこか」を短時間で追える形にします。
経験者向け職務経歴書の基本構成
おすすめの順番は次のとおりです。
- 職務要約
- 活かせる経験・技術
- 職務経歴・プロジェクト詳細
- 資格・社外活動・個人開発
- 自己PR
職務要約
3〜6行程度で、経験年数、専門領域、担当工程、代表成果、希望ポジションとの接点をまとめます。
活かせる経験・技術
「言語」「フレームワーク」「クラウド」「データベース」「開発プロセス」「マネジメント」などに分け、使用場面とレベルを書きます。
プロジェクト詳細
すべての案件を同じ分量にせず、応募先と近い直近案件を詳しくします。古い案件は、キャリア上重要なものを除き簡潔にまとめます。
自己PR
「コミュニケーション力があります」ではなく、課題、行動、結果のエピソードを1〜2件使います。技術的な強みとチームへの貢献を分けると伝わりやすくなります。
GitHub・ポートフォリオが逆効果になるケース
経験者でも、公開物が応募先に関連すれば補足材料になります。ただし、次の状態なら無理に載せない方がよい場合があります。
- 起動方法が書かれていない
- 教材のコピーで自分の工夫が分からない
- APIキーや個人情報が含まれている
- 長期間放置され、依存関係のエラーがある
- READMEと実装内容が一致していない
- 応募職種と関係のない小さな練習コードだけが大量にある
経験者は、個人開発の規模よりも、設計判断、技術記事、OSSへの貢献、業務外で検証した内容などを説明できると効果的です。公開できる実務コードがないこと自体は問題ではありません。
応募経路も見直す
書類だけでなく、応募経路によって伝えられる情報が変わります。
転職サイトからの直接応募
自分で求人を比較しやすい一方、募集背景を把握しにくいことがあります。求人票に合わせて職務要約を調整します。
転職エージェント
企業が重視する点や不採用理由を確認できる場合があります。担当者には「書類を直してください」だけでなく、どの求人でどの経験が不足して見えるかを質問しましょう。
スカウト・リファラル
プロフィールや紹介文が先に読まれるため、職務経歴書との整合が重要です。カジュアル面談へ進んでも選考基準が下がるとは限らないため、正式応募時には書類を整えます。
2週間で改善する手順
1〜2日目：応募結果を分類する
求人を職種・技術・役割別に分け、どの種類で落ちているかを確認します。
3〜5日目：経歴を事実ベースで棚卸しする
各案件の課題、担当範囲、行動、結果を洗い出します。曖昧な数値は、当時の資料などで確認できなければ使いません。
6〜8日目：基本版を作り直す
職務要約、スキル、直近案件の順に修正します。第三者に「どんな役割のエンジニアに見えるか」を確認してもらいます。
9〜14日目：2パターンで応募する
例えば「バックエンド実装者向け」と「リーダー候補向け」を作り、それぞれに近い求人へ応募します。結果を比較し、反応の良い軸へ寄せます。
書類提出前のチェックリスト
- 求人の技術・工程・役割・業界・規模を確認した
- 職務要約だけで自分の専門性が分かる
- 担当業務だけでなく成果と工夫を書いた
- 技術ごとの使用場面とレベルが分かる
- 自分とチームの成果を区別した
- 直近かつ応募先に近い案件を詳しくした
- 履歴書、プロフィール、職務経歴書の日付が一致している
- 守秘義務や個人情報に配慮している
- 応募先に合わせて上部の情報を調整した
- ファイル名に氏名と書類名を入れた
まとめ：経験を増やす前に「伝わり方」を直そう
経験者エンジニアが書類選考に通らないとき、必ずしも技術力が不足しているとは限りません。求人の役割と経験がずれている、実績が担当業務に埋もれている、技術レベルが読み取れないといった伝達上の問題も多くあります。
まず応募結果を分類し、職務要約と直近案件から直してください。そのうえで、求人ごとに重要な経験の順番を変え、一定数の結果を比較します。経験の数ではなく、「この募集で、入社後に何を任せられる人か」が伝わる書類にすることが、面接へ進むための最短ルートです。