職務経歴書が書類選考で通らない理由、私が赤入れする5箇所

「〇〇社に常駐し、ECサイトの保守運用を担当」——書類選考に落ち続けている相談者の職務経歴書を開くと、経歴1年分がこの一行だけで終わっていることがよくあります。

マイナビの転職活動実態調査（2025年）によると、平均応募数13.6件に対して書類選考を通過するのは5.1件、通過率は37.3%にとどまります。これは2024年7月〜2025年6月に転職した20〜50代の正社員500人、つまり転職に成功した人の回答です。IT・Web業界で800名以上の転職支援に携わる中で、私はこの通過する側と通過しない側を分けているのは、面接の巧拙より先に職務経歴書の書き方だと感じています。今回は、私が候補者に送り返す前に実際に赤字を入れている5箇所を、Before/Afterの実例とともにお伝えします。

目次

1. 職務経歴書がエンジニアの書類選考で通らない、本当の理由
2. 職務経歴書の基本構成8項目、抜けがちな3つ
3. 私が実際に赤入れする5箇所、Before/Afterの実例
4. ① プロジェクト経歴が「担当した業務」の羅列で終わっている
5. ② 技術スキル欄が「使った言語の羅列」で終わっている
6. ③ 実績に数字が入っていない、または数字が曖昧
7. ④ 技術用語の表記が不正確、求人票のキーワードと合っていない
8. ⑤ 使い回し感のある自己PR・志望動機
9. SES企業のスキルシートと自社開発向け職務経歴書、書き分けるべき3点
10. 未経験・転職回数が多いエンジニアの職務経歴書、気をつけたい書き方
11. 職務経歴書は何枚が適切か、分量と使い回しのNG
12. よくある疑問に答えます
13. 職務経歴書はエージェントに添削してもらうべきですか、自分だけで直せますか
14. 転職サイトで配布されているテンプレートをそのまま使っていいですか
15. 職務経歴書に顔写真は必要ですか
16. ChatGPTなどの生成AIで職務経歴書を作ってもいいですか
17. GitHubやポートフォリオのURLは載せた方がいいですか
18. 前職の不満や退職理由はどこまで正直に書いていいですか
19. まとめ、赤入れの本質は「事実を盛る」ことではない

職務経歴書がエンジニアの書類選考で通らない、本当の理由

書類選考で落ちる理由は「スキル不足」だと思われがちですが、実際に赤入れをしていると、スキルより先に書き方で損をしている人の方が圧倒的に多いという実感があります。技術力自体は求人の要件を満たしているのに、職務経歴書がそれを伝えきれていないケースが半分以上を占めます。

以前、エージェントが書類選考で本当に見ている評価ポイントについて書きましたが、あちらは面接官が最終的にどんな軸で評価しているかという話でした。今回はもう一段具体的に、私が実際にどこをどう書き直させているかという「手を動かすレベル」の話をします。

実際にあった例です。5年目のバックエンドエンジニアで、負荷対策やDB設計の経験も豊富な方がいました。ところが職務経歴書には「開発・保守業務全般を担当」としか書かれておらず、3社連続で書類選考に落ちていました。一緒に経歴を洗い出すと、月間300万PVのサービスでレスポンスタイムを改善した経験や、DBのインデックス設計を主導した経験が出てきましたが、それらは本人の中では「当たり前にやったこと」として書く発想自体がなかったそうです。書けることと、書いていることは別物だというのが、赤入れの現場で毎回突きつけられる事実です。

この背景には、書類選考の担当者が1枚あたりにかけられる時間の短さもあります。人事担当者から直接聞く話では、応募が集中する求人だと1件あたり数十秒〜1分程度で一次スクリーニングをかけていることも珍しくありません。その短い時間で読まれるのは、職務要約と最初のプロジェクト経歴の数行です。ここに規模や役割が書かれていないと、後半にどれだけ優れた実績が書いてあっても、読まれる前に見送りが決まってしまいます。だからこそ、赤入れはまず職務経歴書の冒頭部分から手をつけることになります。

先ほどの5年目バックエンドエンジニアは、赤入れした職務経歴書で改めて応募し直した結果、それまで書類選考で音沙汰がなかった自社開発企業3社のうち2社から面接の案内が来ました。本人のスキルセットは赤入れの前後でまったく変わっていません。変わったのは、すでに持っている経験を選考担当者が判断できる形に書き直しただけです。

職務経歴書の基本構成8項目、抜けがちな3つ

まず基本構成を確認します。エンジニアの職務経歴書は、次の8項目で組み立てるのが標準的な形です。

このうち赤入れの対象になりやすいのは、職務要約・職務経歴・自己PRの3項目です。日付や資格の欄は事実を書くだけなので誤りが少ない一方、この3項目は「何をどこまで書くか」を自分で判断しなければならず、書き手の力量が最も出やすい箇所でもあります。

もう一つ見落とされがちなのが開発経歴一覧です。「期間・案件名・役割・使用技術・規模」を1行ずつ表にまとめたもので、職務経歴の文章を読む時間がない担当者でも、この一覧表だけでざっと経歴を把握できるようにする役割を持っています。文章での職務経歴だけを作り込んで一覧表を省略している人もいますが、書類選考の最初の数十秒で目を通されるのはむしろこちらの一覧表であることが多く、文章と一覧表の両方を用意しておく方が安全です。

特に職務要約は、先ほど触れた「数十秒で読まれる冒頭部分」そのものです。「〇年間、Webアプリケーションの開発・運用に従事」だけで終わる要約をよく見ますが、これでは職務経歴を開かずとも分かる情報しか書かれていません。私が赤字を入れるときは、経験年数に加えて「得意な工程（設計寄りか実装寄りか）」「担当してきたサービスの規模感」「今後伸ばしたい方向性」の3点を3〜5行に凝縮するよう伝えています。職務要約だけでその人の経歴の骨格が伝わるかどうかが、続きを読んでもらえるかの分かれ目になります。次のセクションでは、職務要約を含めて私が実際に赤字を入れている5箇所を具体的に見ていきます。

私が実際に赤入れする5箇所、Before/Afterの実例

ここからは、実際に私が候補者の職務経歴書へ赤字を入れる5箇所を、匿名化したBefore/Afterの実例とともに紹介します。どれも特別な文章力を求めているわけではなく、抜けている情報を足すだけの作業です。

① プロジェクト経歴が「担当した業務」の羅列で終わっている

もっとも多いのがこのパターンです。Beforeの例は「ECサイトの保守運用を担当。障害対応、機能改修を実施」という一行。これでは規模も役割も見えず、面接官は「何ができる人か」を判断する材料を持てません。

私が赤字を入れると「会員数120万人のECサイトの保守運用チームに5人体制で参画。月間30件の障害のうち原因調査から復旧対応までを単独で完結できる領域を担当し、対応件数を前年比で2倍に拡大」のようになります。規模・役割・使用技術・成果の4点セットを埋めると、同じ経験でも情報量がまったく変わります。規模・役割・使用技術・成果のどれか一つでも欠けていないか、自分の経歴を見返してみてください。

フロントエンド職種でも構図は同じです。「コーポレートサイトのコーディングを担当」という一行に対して、実際は「月間PV50万の自社メディアで、5名のデザイナーと連携しながらVue.jsでのコンポーネント設計を主導し、ページ表示速度を3秒台から1.2秒台まで改善した」という経験を持っていた候補者もいました。本人にとっては日々の業務でしかない作業も、規模・役割・使用技術・成果の型に当てはめ直すだけで、初めて選考担当者に伝わる情報に変わります。

② 技術スキル欄が「使った言語の羅列」で終わっている

「使用言語：Java、Python、JavaScript／DB：MySQL、PostgreSQL」とだけ書かれた技術スキル欄も頻繁に見ます。これでは「触ったことがある」のか「一人で設計から任せられる」のか区別がつきません。

IPAのITスキル標準（ITSS）では、レベル3を要求された作業を全て独力で遂行できる段階、レベル4を専門分野が確立し、業務上の課題の発見と解決を独力でリードできる段階とする趣旨で定義しています。この考え方を借りて、私は候補者に「Javaは要件定義から詳細設計・実装・テストまで独力で担当できる水準、Pythonは既存コードの改修対応ができる水準」のように、言語ごとにどこまで任せられるかを書き添えるよう勧めています。並べた言語の数より、何を実現できるレベルにあるかの説明の方が、面接官にとってはよほど価値のある情報です。

インフラやミドルウェアの経験も同様です。「AWS：EC2、RDS、S3を使用」という書き方だけでは、構築を任せられるのか、既存環境の運用しかできないのかが分かりません。「EC2・RDSを用いたWebアプリケーション基盤の構成をゼロから設計し、オートスケーリングの設定まで担当」のように、どの工程まで自分の判断で進めたかを添えると、同じ経験でも評価の見え方が変わります。ツールや製品名を並べる発想から、それぞれのツールでどこまでの仕事を任されていたかを説明する発想への切り替えが必要です。

③ 実績に数字が入っていない、または数字が曖昧

「パフォーマンス改善に貢献」「業務効率化を実現」という表現も赤字の定番です。何をどれだけ改善したのかが分からず、実績の大きさが伝わりません。

同じ経験でも、「レスポンスタイムを平均1.8秒から0.6秒に短縮」「手作業だった月次集計を自動化し、月間20時間の工数を削減」まで書けば、実績の輪郭がはっきりします。数字が正確に出せない場合でも、「体感で半分程度に短縮」のような概算で構いません。書類選考の段階では、数字の厳密さより、成果を定量的に説明しようとする姿勢そのものが評価されます。

私の体感では、赤入れ前の職務経歴書のうち半数以上は、数字が一つも入っていないか、入っていても工数や人数のような業務規模の数字だけで止まっています。技術的な改善成果（処理速度、エラー率、稼働率など）と、事業への貢献（工数削減、コスト削減、売上・利用者数への影響など）の両方を1つずつ入れられないか、経歴を書く前に一度棚卸ししてみることをおすすめします。両方の数字がそろっている職務経歴書は、それだけで見送りになりにくいというのが現場の実感です。

④ 技術用語の表記が不正確、求人票のキーワードと合っていない

「Reactの案件を担当」とだけ書かれていて、バージョンも状態管理ライブラリも書かれていないケースもよくあります。求人票がNext.jsや特定の状態管理ライブラリの経験を明示している場合、職務経歴書側にその単語が一つもないと、書類選考の担当者は経験の有無を確認しようがありません。

略称や社内呼称をそのまま書いているケースも見かけます。正式名称に直し、求人票に出てくるキーワードと表記を揃えるだけで、担当者が経験の有無を判断しやすくなります。求人票の言葉と職務経歴書の言葉を揃えるという、地味だけれど効果の大きい作業です。

実際にあった例では、Vue.js 3系のComposition APIでの開発経験が3年近くある候補者が、職務経歴書には「JSフレームワークを使用した開発」としか書いていませんでした。応募先の求人票には「Vue.js 3系、Composition API経験者歓迎」と明記されていたにもかかわらず、書類だけを見た採用担当からは「フレームワークの経験が不明瞭」という理由で見送りの連絡が来ています。本人にVue.jsの経験を確認すると、求人票の要件を上回る経験を持っていたことが分かり、表記を直して再応募した別の求人では書類選考を通過しました。

応募数の多い企業では、応募者管理システムで職務経歴書のテキストを検索し、求人票のキーワードとの一致数で一次的に絞り込んでいる場合もあります。人の目で丁寧に読んでもらえる前提で書類を作ると、この一次選別の段階で経験があるのに弾かれてしまうことがあるので、正式名称やバージョンを省略しない習慣は、人間の担当者だけでなくこうした仕組み対策としても効いてきます。

⑤ 使い回し感のある自己PR・志望動機

最後は自己PRと志望動機です。「貴社の事業に貢献したいです」のような、どの企業にも当てはまる文章で終わっているケースが典型で、面接官には一目で使い回しだと分かってしまいます。もっと踏み込んだ例では、前の応募先の社名や求人タイトルがそのまま本文に残っていたケースも実際にありました。

赤字を入れる際は、求人票に書かれた業務内容や技術スタックのキーワードを2〜3個拾い、それに対して自分のどの経験が対応するかを一文で書き添えるよう伝えています。全社共通のテンプレート文に、応募先ごとの一文を足すだけでも、読み手の受け取り方は大きく変わります。

Beforeの例は「貴社の掲げるビジョンに共感し、これまでの経験を活かして貢献したいと考えております」。Afterでは「貴社が推進しているマイクロサービス化の取り組みに、前職でのAPI設計・分割の経験を活かして貢献したいと考えております」のように、求人票の言葉と自分の経験を1点だけでも結び付けます。全文を書き直す必要はなく、テンプレートの中に応募先固有の一文を差し込むだけで十分です。

SES企業のスキルシートと自社開発向け職務経歴書、書き分けるべき3点

SES企業出身の方から、スキルシートと職務経歴書を同じフォーマットで使い回している相談をよく受けます。案件単位の稼働率や契約形態を並べるスキルシートの書式は、自社開発企業の選考ではむしろ読みにくくなることがあります。

項目	SES向けスキルシート	自社開発向け職務経歴書
単位	案件ごとの稼働期間・規模・契約形態	プロダクト単位の成果・意思決定の関与度
技術の見せ方	対応できる技術の幅広さ	自分が選定・判断した技術とその理由
自己PR	複数現場への適応力、折衝力	事業への当事者意識、裁量を持った提案力

自社開発企業の面接官が知りたいのは「どの現場に何ヶ月いたか」という稼働履歴ではなく、その人がプロダクトの意思決定にどこまで関わったかです。SESでの経験を自社開発向けに書き直す場合は、案件を並べる書き方から、担当した機能やその機能がプロダクトにもたらした成果を中心に据える書き方へ組み替える必要があります。逆に、SES企業への応募でプロダクト成果ばかりを強調すると、複数現場への適応力や折衝力が見えづらくなり、評価されにくくなることもあります。応募先がどちらのタイプの企業かで、経歴の「見せ方」を変える判断が要ります。

SESから自社開発への転職を考えていたHさん（20代後半・SES企業所属）の例です。スキルシートには、この3年間で経験した5つの現場が案件名と稼働期間だけで並んでいました。自社開発企業の書類選考を受けても反応が薄かったため、直近の現場を掘り下げて聞くと、要件定義から入り、既存の決済フローの改修案を自分で提案して実装まで担当していたことが分かりました。

案件の羅列を、この決済フロー改修の1本に絞って規模・役割・技術・成果の型で書き直したところ、次に応募した2社で立て続けに書類選考を通過しています。5つの現場を均等に紹介するより、自社開発企業に響く経験を1本選んで深く書く方が、結果につながりやすいというのが実感です。

未経験・転職回数が多いエンジニアの職務経歴書、気をつけたい書き方

未経験からIT業界を目指す場合、職務経歴書に書ける開発経験がほとんどないのが実情です。前職の経験を「翻訳」して書く発想が必要で、たとえば営業職なら顧客折衝で培った要件のヒアリング力、事務職なら業務フローを整理してマニュアル化した経験などが、開発の上流工程に近い経験として読み替えられます。求人票の言葉自体の読み方は「未経験可」求人票の実態で詳しく書いているので、そちらもあわせて参考にしてください。

たとえば経理事務を5年経験していた方は、月次決算の締め作業をExcelマクロで半自動化した経験を持っていました。本人は「ただの効率化」としか捉えていませんでしたが、これは業務課題を発見し、自分で仕組みを作って解決した経験そのものです。職務経歴書には「月次決算業務における手作業の集計フローを分析し、VBAによる自動化を提案・実装。作業時間を月10時間から2時間に削減」と書き直しました。開発経験がなくても、課題発見から解決までの一連のプロセスを踏んだ経験があれば、それは立派な自己PR材料になります。

転職回数が多いエンジニアの場合、職務経歴書で問われるのは回数そのものより、それぞれの転職に一貫した理由があるかどうかです。在籍期間が短い会社が続いていると、面接官はまず「何か問題を抱えている人ではないか」と身構えます。各社の経歴に、転職した理由を一言添えるだけで、印象はかなり変わります。「受託開発中心の環境から、自社サービスの成長に関わりたいという軸で一貫して動いてきた」のように、点在する転職を一本の線として説明できるかどうかが分かれ目です。

6年で4社を経験していたIさんは、当初「在籍期間が短いことは触れない方がいい」と考えて、各社の経歴に転職理由を一切書いていませんでした。しかし面接では毎回、在籍期間の短さについて厳しく突っ込まれていたそうです。職務経歴書の各社の末尾に「〇〇の技術に強い環境を求めて転職」のように一言ずつ理由を添えたところ、面接で同じ質問をされても「書類に書いた通りです」と落ち着いて答えられるようになり、その後の選考通過率も上がりました。書かずに隠すより、先回りして書いておく方が、結果的に選考を有利に進められます。

職務経歴書は何枚が適切か、分量と使い回しのNG

分量の目安は2〜4枚です。経験年数が浅いのに1枚に収まりきらないほど書き込む必要はありませんが、5年目以降で複数のプロジェクトを経験しているにもかかわらず1枚しかないと、経歴の掘り下げが足りないという印象を持たれます。逆に6枚を超えるような分量になると、読み手が要点を拾いきれず、かえって評価が下がることもあります。

プロジェクト経歴の書き分け方としては、直近2〜3年に携わった案件は規模・役割・使用技術・成果の4点セットで厚めに、それより前の案件は案件名と技術要素だけの一覧に圧縮するのが目安です。10年選手のエンジニアがすべての案件を同じ密度で書こうとすると、それだけで4枚を超えてしまいます。読み手が今の実力を判断しやすいのは直近の経験なので、古い案件から厚みを削っていくと自然な分量に収まります。

分量以上に見落とされがちなのが、複数社へ使い回す際の事故です。フォーマットを使い回すこと自体は問題ありませんが、前の応募先の社名や求人タイトルが本文中に残ったまま提出されるケースを、私はこれまで何度も見てきました。誤字脱字と違って、この種のミスは「この人はこちらを第一志望と思っていない」という印象を与えかねません。

ポイント： 提出前に、ファイル内を検索して以前応募した会社名や求人タイトルが残っていないか確認してみてください。作成日の古いテンプレートを使い回している場合ほど、この種の消し忘れが起きやすくなります。

よくある疑問に答えます

職務経歴書はエージェントに添削してもらうべきですか、自分だけで直せますか

自分だけで直すことも可能ですが、今回挙げた5箇所は「自分では当たり前だと思っていて書いていない」情報がほとんどです。第三者に読んでもらい、「ここは何をしたのか」と聞かれて初めて言語化できることが多いので、エージェントや同僚など、一度他人の目を通すことをおすすめします。

転職サイトで配布されているテンプレートをそのまま使っていいですか

フォーマット自体は使って構いません。問題になるのは、フォーマットの見出しに合わせて内容を埋めた気になり、規模や成果の記述が薄いまま提出してしまうことです。テンプレートは箱でしかなく、箱を埋める中身の解像度は自分で上げる必要があります。

職務経歴書に顔写真は必要ですか

IT・Web業界では、職務経歴書に顔写真を求められることはほとんどありません。履歴書側に貼っていれば十分で、職務経歴書のスペースはプロジェクト経歴や技術スキルの説明に使う方が選考上は有利です。

ChatGPTなどの生成AIで職務経歴書を作ってもいいですか

使うこと自体は問題ありません。私が勧めるのは、経験の棚卸しの壁打ち、下書きのたたき台、求人票に合わせた添削の3つです。一方で、丸投げして仕上げた文章を持ち込む候補者は、面接で書類の内容を自分の言葉で語れず、そこで崩れてしまうことが少なくありません。書類が整っているほど、深掘りされたときの落差が目立ちます。

もう一つ、AIに数字や実績を足させないでください。書いていない成果が文面に混ざると、面接で説明できないだけでなく、事実と違う記載として信用を落とします。事実は自分で用意し、AIには整理と言い回しを任せる使い分けが安全です。

GitHubやポートフォリオのURLは載せた方がいいですか

公開できる成果物がある場合は、職務経歴書の目立つ位置に載せることをおすすめします。特に未経験や実務経験が浅い候補者にとっては、職務経歴書の文章だけでは伝わらない実装力を補う材料になります。ただし業務で開発したコードは公開できないことが多いので、個人開発や学習用のリポジトリであることを一言添えておくと誤解を防げます。

前職の不満や退職理由はどこまで正直に書いていいですか

「人間関係が悪かった」「残業が多すぎた」のような不満そのものを書く必要はありません。ただし、不満を隠して当たり障りのない理由だけにすると、面接で深掘りされたときに答えに詰まります。「案件によって使う技術がその都度変わり、専門性を積み上げにくい環境だった」のように、不満の背景にある構造を客観的な言葉に置き換えて書くと、ネガティブさを出さずに転職理由の説得力を保てます。

まとめ、赤入れの本質は「事実を盛る」ことではない

職務経歴書は、経歴の記録ではなく、企業へのプレゼン資料です。今回紹介した5箇所は、どれも新しい実績を作り出す作業ではなく、すでにある経験から規模・役割・技術・成果を拾い出して言葉にする編集作業にすぎません。書けることを書いていないだけで書類選考に落ちている人が、実感としてはかなりの割合を占めています。

次に職務経歴書を見直すときは、まず今回の5箇所——プロジェクト経歴の4点セット、技術スキルのレベル感、数字の有無、用語の正確さ、自己PRの使い回し——に沿って自分の書類を読み返してみてください。書き足す情報のほとんどは、すでにあなたの経歴の中にあるはずです。

書類選考に落ち続けている段階で、いきなり資格取得やスキルの学び直しに走る人もいますが、多くの場合、まずやるべきことはもっと手前にあります。今の経歴をどう書けば伝わるかを見直すだけで結果が変わる人を、私はこれまで何人も見てきました。