SES転職の書類選考が通らない理由7つ｜職務経歴書と求人の直し方

理由1：止まった段階を分けず、職務経歴書だけを直している

最初に選考を四段階へ分けます。一つ目は、登録・検索しても自分へ紹介可能な求人がない段階です。二つ目は、求人を受け取ったが条件を読んで応募していない段階です。三つ目が応募後の書類選考、四つ目が面接以降です。「転職がうまくいかない」とまとめると、求人条件、職務経歴書、面接回答のどれを直すか分かりません。

紹介求人が0件なら、職務経歴書の表現より先に、年齢、実務経験、職種、勤務地、出社、入社時期、希望年収などの対象条件を確認します。条件を一つ緩めた時に候補が増えるか、現職でどの経験を積むと対象になるかを聞きます。対象外のサービスへ経歴を大きく書いて登録するのは解決になりません。

求人を受け取っているのに応募0件なら、落ちているのではありません。必須条件、仕事内容、勤務地、給与内訳、配属が希望と合わず見送ったのか、求人説明が不足して判断できないのかを分けます。判断できない項目は、担当者または採用窓口へ質問し、回答期限を置きます。

応募後に書類で不採用なら、求人ID、応募日、経路、送付した履歴書・職務経歴書の版、不採用連絡日、分かった理由を記録します。同じ企業へ直接応募と複数の紹介経路から重複応募していないかも確認します。企業名が同じでも職種や求人IDが違う場合があるため、応募単位で残してください。

面接へ進んだ後に落ちた場合、書類だけを全面改稿すると、通過していた証拠まで壊す可能性があります。面接で聞かれた案件、説明できなかった判断、技術質問、志望理由、求人理解、逆質問を記録し、書類と口頭説明の不一致だけを直します。面接通過に必要な改善は別の記事で扱います。

応募件数だけで異常を決めません。まず直近の求人を同じ列へ並べ、どの段階が多いかを数えます。母数が少ない時は結論を急がず、一求人でも必須条件との対応を確認します。数を増やす前に、応募していない求人と不採用になった求人を混ぜないことが最初の修正です。

• 紹介可能求人0件: 対象条件と不足経験を確認
• 求人受領・応募0件: 希望との差と未回答を確認
• 書類不採用: 求人ID・送付版・経路・理由を記録
• 面接不採用: 書類を壊さず口頭説明との差を確認
• 共通: 応募数ではなく止まった段階を数える

理由2：求人の必須条件と、案件経験の事実が対応していない

書類選考は「良い職務経歴書」を競うだけではなく、特定求人の必須条件へ現在の経験が合うかを確認する工程です。まず求人票を、必須、歓迎、仕事内容、入社後の責任、勤務地・働き方、労働条件へ分けます。歓迎条件が足りないことより、必須条件を満たす根拠が書類から見つからないことを先に確認します。

求人要件の横に、該当する案件、期間、担当工程、技術、自分の判断、確認できる結果を書きます。「Java3年以上」に対しては在籍3年ではなく、Javaを使った案件期間と担当範囲を出します。「基本設計経験」に対して、詳細設計書を読んだだけなら基本設計を担当したとは書かず、要件・外部仕様のどこへ関与したかを事実で区別します。

必須条件が五つある場合、すべてを自己評価の丸印で済ませません。「満たす」「近い経験がある」「経験なし」「求人へ確認」の四つに分けます。近い経験は、同じ技術名ではなく再現できる行動で説明します。たとえばクラウド未経験でも、構成変更、監視、権限、障害対応の経験がどこまで接続するかを限定して書けます。

職種名だけで応募先を決めないことも重要です。「社内SE」「自社開発」「バックエンドエンジニア」という名前が同じでも、問い合わせ、ベンダー管理、実装、レビュー、運用、当番の割合は求人ごとに違います。雇用主、配属部署、入社後90日に作成・レビュー・承認する成果物を確認し、次に持ちたい責任と合う求人を選びます。

厚生労働省の職業情報提供サイトは、プログラマーの仕事を要件定義・基本設計・詳細設計から続く開発工程の中で説明しています。職種説明をそのまま自己PRへコピーせず、現在の自分が工程のどこを担当し、誰が前後を担当したかを整理する参考にします。IPAのデジタルスキル標準も、ソフトウェアエンジニアを技術名だけでなく役割とスキルで整理しています。

必須条件が明確に足りない求人は、応募数を稼ぐために出しません。経験なしでも応募可能か採用側が明記しているか、近い経験をどう評価するかを確認します。足りない条件が現職で三か月以内に作れるなら期限を置き、別求人で現在の強みを使えるなら対象を変えます。応募しない判断も選考改善です。

• 必須条件を一行ずつ分解する
• 案件・期間・工程・技術・判断・結果を横へ置く
• 満たす／近い／経験なし／確認中で分ける
• 職種名より入社90日の成果物を確認する
• 必須不足を経歴の誇張で埋めない

理由3：案件名・工程・技術の羅列で、任せられる範囲が見えない

SESの職務経歴書でよく起きるのは、「金融システム開発」「詳細設計、製造、テスト」「Java、Spring、Oracle」と書き、本人がどこからどこまで責任を持ったかが見えない状態です。採用側は技術一覧から、仕様確認、実装方針、レビュー、リリース、障害時の行動を推測できません。

案件ごとに、目的・利用者、規模・体制、担当の入口、判断・行動、担当の出口、結果の六項目を埋めます。入口は誰から何を受け取り、どの状態から始めたか。出口は何を誰へ渡し、どの確認を受けたかです。作業の前後を書くと、指示された一部分だけか、一連の責任を持ったかを区別できます。

たとえば「既存機能の改修」なら、「障害票を受け取り、既存仕様・ログ・SQLから影響範囲を整理し、修正方針をレビューで合意、Java実装、異常系を含むテスト、本番反映後の確認まで担当」とします。実際に担当していない設計や本番作業は足さず、レビュー者と分担を明記します。

テスト中心なら実施件数だけでなく、仕様差分から追加した境界値・異常系、データの組合せ、不具合の切り分けを書きます。運用・保守なら、問い合わせ転送ではなく、ログ・SQL・監視から原因範囲を絞った順序、復旧判断へ渡した情報、再発時の手順を出します。調整中心なら、決定事項、未決事項、担当、期限、依存関係をどう管理したかを書きます。

成果は売上や大きな数値だけではありません。手戻り、確認漏れ、調査時間、障害再発、引き継ぎ、レビュー指摘、運用の再現性も結果になります。ただし測っていない削減率を作りません。「確認項目を一覧化し、後続レビューで同じ観点を使える状態にした」のように、自分の行動から説明できる変化へ限定します。

厚生労働省のマイジョブ・カードは、在職者が職務経歴、職業能力、学習歴、キャリアプランを順に整理する方法を案内しています。公式様式をそのまま提出する必要はありませんが、会社名だけでなく職歴と能力を分けて棚卸しする手順として使えます。当サイトの職務経歴書メーカーでも、入力内容を送信せず六項目を整理できます。

• 目的・利用者: 何のためのシステムか
• 規模・体制: チームと自分の立場
• 入口: 受け取った仕様・依頼・問題
• 判断・行動: 調査、選択、合意、実装、検証
• 出口: 成果物、レビュー、リリース、引き継ぎ
• 結果: 品質、手戻り、再現性の変化

理由4：技術名はあるが、使用期間・深さ・レビュー範囲が曖昧

技術欄に多くの言語・フレームワーク・クラウドを書くほど有利とは限りません。研修で触れた、既存コードを修正した、新規機能を実装した、設計した、レビューした、障害対応したでは任せられる範囲が違います。技術名の横に期間、用途、担当、支援者を置きます。

「Java 3年」だけでなく、「Java／Springを使う業務システム二案件で、既存APIの改修、単体・結合テストを計2年8か月。新規アーキテクチャ設計とコードレビュー承認は未経験」のように、できることと未経験を同時に書きます。未経験を明記すると弱く見えるのではなく、面接で説明が崩れにくくなります。

データベースなら、SQLを実行したのか、調査クエリを作ったのか、テーブル設計や実行計画を扱ったのかを分けます。クラウドなら、コンソール閲覧、設定変更、IaC、監視、権限、構成設計を分けます。テストなら、実施、項目作成、観点設計、計画、レビュー、品質判定を分けます。同じ技術名でも工程ごとに深さを示せます。

求人票の言葉をそのまま貼るキーワード合わせは行いません。求人が「要件定義」を必須とする時、顧客会議へ同席しただけなら要件定義経験と断定せず、「現行仕様の調査結果を提示し、変更対象の合意に参加」と事実を書きます。近い経験が評価対象になるかは求人企業または紹介担当へ確認します。

資格や個人開発は実務と分けます。資格は知識の確認、個人開発は自分で設計・実装した証拠になりますが、企業の本番環境で運用した経験へ置き換えません。リポジトリを提出する場合も、勤務先・客先のコード、データ、画面、内部構成を持ち出さず、自分が公開権限を持つ成果物だけにします。

応募職種ごとに、詳しく書く技術を変えて構いません。ただし事実は同じに保ちます。バックエンド求人ではAPI・DB・テストを前へ、社内SE求人では業務理解・問い合わせ・ベンダー協働・受入を前へ置きます。版番号と更新日を付け、どの求人へどの版を送ったか記録してください。

• 期間: 実務で使った年月
• 用途: 何を作成・調査・運用したか
• 深さ: 実施／作成／設計／レビュー／承認
• 支援: 単独、ペア、指示・レビューあり
• 未経験: 担当していない範囲を明示
• 版管理: 求人ごとの並べ替えと送付版を記録

理由5：日付・役割・成果の不整合や、客先情報の出し過ぎがある

履歴書と職務経歴書で入社月、案件期間、役職、資格取得日が違うと、内容以前に確認が必要になります。西暦・和暦を統一し、所属会社の在籍期間と案件期間を分けます。複数案件を並行した場合は合計年数を二重計上せず、兼務の割合や期間を説明できる形にします。

「リーダー」と書く場合も、会社上の役職、案件内の呼称、実際の責任を分けます。進捗を集めた、技術方針を決めた、レビューを承認した、顧客窓口だった、評価を行ったでは責任が違います。役職名より、対象人数、決めたこと、エスカレーション先を具体化します。

数字は根拠を残します。「工数30%削減」「障害0件」「売上に貢献」と書くなら、対象期間、比較方法、本人の寄与を説明できる必要があります。測定していない数字は削除し、件数を使わなくても確認漏れを防いだ手順、再現できる資料、合意した判断を書きます。採用側の深掘りへ耐える事実を優先します。

顧客名、製品名、内部URL、IPアドレス、アカウント、未公開構成、ソースコード、障害の詳細、個人情報は職務経歴書へ入れません。企業名を出せない時は、業界、利用者、システム用途、規模、工程へ一般化します。「金融業向け口座管理システム」のように、仕事内容を理解でき、対象企業を特定しにくい粒度を所属会社のルールと合わせます。

応募書類を転職支援へ渡す場合は、登録時の利用目的、求人企業へ提供する情報、停止・削除の窓口を確認します。厚生労働省の個人情報取扱い指針は、業務目的に必要な範囲を明らかにし、本人の自由な意思に基づく明確な同意を扱う考え方を示しています。登録への同意と、特定企業への応募同意は分けて確認します。

最終確認では、日付、会社名、案件期間、技術期間、役割、数字、資格、連絡先、ファイル名を読みます。PDF化後の改ページ、文字切れ、リンク、選択できない文字も確認してください。装飾より、採用側が求人要件と案件事実を短時間で照合できる順序を優先します。

• 履歴書と職務経歴書の日付をそろえる
• 在籍期間と案件期間を分ける
• 役職名より実際に決めた範囲を書く
• 数字の対象期間・測定方法・寄与を説明する
• 顧客・個人・内部情報を一般化する
• 登録同意と企業別の応募同意を分ける

理由6：応募経路から得られる情報を使わず、同じ書類を送り続けている

企業から不採用理由が必ず開示されるわけではありません。その場合も、応募前に求人を選んだ理由、必須条件と自分の対応、推薦時に強調する経験、送付書類、選考結果を紹介担当へ確認できます。「総合的判断でした」で終わる時は、次の求人で変える仮説を一つ決めます。

転職支援を利用中なら、最初の三求人について「なぜ私へ選んだか」「必須条件のどこを満たすか」「不足条件は何か」「推薦文へ何を書くか」「不採用時に何を確認できるか」を聞きます。求人件数や担当者の話しやすさだけでなく、案件事実と求人要件を接続できるかを評価します。

同じ書類を何社へ送ったかより、どの仮説を検証したかを残します。たとえば「基本設計求人へ、仕様合意の経験が見えない」が仮説なら、担当の入口・判断・出口を追加し、必須条件が近い別求人で反応を見ます。業界、年収、職種まで同時に変えると、改善理由を判別できません。

現在の担当者が求人理由を説明できない、送付版・推薦文を確認できない、希望外の一括応募を勧める、未回答を回収しない場合は、担当変更または別の支援先を比較できます。逆に回答が具体的なら、サービス数を増やす必要はありません。対象条件に合う二社までへ同じ経歴と質問を渡し、七日で一社へ絞ります。

会社員向けの比較ページでは、広告の有無にかかわらず8社を同じ条件で確認できます。年齢、実務経験、勤務地、希望職種を先に照合し、同じ職務経歴書と質問を対象に合う2社までへ渡してください。

全員に全社を勧めません。年齢、実務経験、勤務地、希望職種、面談できる時期・転職意思などの利用条件に合う候補だけを選びます。申込前に最新条件を公式画面で読み、面談では自分へ現在紹介可能な求人と選定理由を確認します。条件を満たすためだけの登録、経歴の誇張、連絡へ応じる意思がない申込は行わないでください。

• 求人を選んだ経験上の理由
• 必須条件を満たす案件事実
• 不足条件と選考上のリスク
• 企業へ送る書類と推薦文
• 不採用時に確認できる項目
• 担当変更・別支援を判断する期限
• 対象に合う二社までを同じ入力で比較

理由7：一度に全部直し、次の14日で何が効いたか分からない

書類選考が続けて不採用になると、文章、デザイン、希望職種、年収、応募数、担当者を一度に変えたくなります。しかし同時に変えると、次に通過しても理由を特定できません。最初の一日で選考段階と求人要件対応表を作り、最も大きい不一致を一つ選びます。

一〜三日目は、直近の求人三件を並べます。求人ID、必須条件、仕事内容、勤務地、給与、応募経路、送付版、結果を書き、必須条件に対応する案件事実へ線を引きます。事実があるのに書類へない項目、事実自体がない項目、求人へ確認が必要な項目を色ではなく文字で区別します。

四〜七日目は、一つの修正を行います。案件の入口・判断・出口を加える、技術の使用範囲を具体化する、応募職種に近い案件を前へ出す、日付を統一するなどです。全面的に経験を作り替えず、元の版と修正版を保存し、変更箇所と理由をメモします。顧客情報や実績の数字を新たに作りません。

八〜十四日目は、必須条件が近く、仕事内容と勤務地を確認できた求人だけを検討します。同じ企業へ別経路から再応募せず、過去応募の扱いを確認します。応募する場合は求人ごとに本人が同意し、送付版を記録します。結果が出るまでの期間は企業ごとに違うため、十四日で合否が揃わない場合は途中経過として残します。

反応を「通過／不採用」だけで評価しません。紹介可能求人が増えた、求人選定理由が具体的になった、担当者が必須条件と経験を接続できた、書類質問が特定案件へ変わった、面接で担当範囲を聞かれた、という変化も記録します。通過しても求人条件が希望と違うなら応募先の質は改善していません。

十四日後に、書類修正を続ける、対象求人を変える、現職で不足経験を作る、担当者を変える、別の支援先を一社だけ比較する、直接応募へ切り替える、活動を止める、のいずれかを決めます。内定を急ぐことより、求人要件と自分の事実が対応する状態を作ることが、次の面接と入社後のミスマッチ防止につながります。

• 1日目: 選考段階と最大の不一致を決める
• 1〜3日目: 直近求人の必須条件と案件事実を対応させる
• 4〜7日目: 一つだけ修正し版と理由を残す
• 8〜14日目: 条件が近い求人で検証する
• 14日後: 書類・求人・経験・経路の次の一手を決める

職務経歴書の変換例

案件名・工程・技術の羅列を、目的・体制・入口・判断・出口・結果へ変えます。担当していない工程も明記し、求人要件との対応を採用側が確認できる形にします。

行動前チェックリスト

• 紹介0・応募0・書類不採用・面接不採用を分けた
• 求人ID・応募経路・送付版・結果を記録した
• 必須条件を満たす案件事実を一行ずつ対応させた
• 案件の目的・体制・入口・判断・出口・結果を書いた
• 技術の期間・用途・深さ・支援・未経験を分けた
• 履歴書と職務経歴書の日付・役割・資格をそろえた
• 顧客名・内部情報・測っていない数字を削除した
• 登録同意と求人企業ごとの応募同意を分けた
• 担当者へ求人理由・不足条件・推薦文を確認した
• 対象条件に合う支援だけを二社まで比較した
• 一度に一項目だけ修正し、14日後の判断日を置いた