エンジニア転職で書類選考が通らない原因と職務経歴書の直し方

PR本ページはアフィリエイト広告を利用しています。掲載順位や評価は、筆者の経験と独自の基準にもとづいています。広告掲載ポリシー

エンジニアの転職で書類選考が通らない原因は、スキル不足だけではありません。多いのは「職務経歴書の書き方」と「応募先の選び方」のズレです。

この記事では、エンジニア・PMとして働き、採用にも携わってきた立場から、書類で落ちる理由と直し方を整理します。

結論：書類選考が通らない原因は3つに絞れる

書類選考で落ちる理由は、大きく次の3つに分けられます。

1. 職務経歴書から「何ができる人か」が読み取れない
2. 応募先が求める人物像とずれている
3. 希望条件や応募の仕方で損をしている

どれも、書き直しと応募先の見直しで改善できます。まずは自分がどれに当てはまるかを確認してください。

採用側は書類のどこを見ているか

採用担当や現場のエンジニアは、多くの書類に目を通します。1通にかけられる時間は長くありません。そのため、最初の数行で「会う価値があるか」を判断されることが多いです。

採用側が見ているのは、主に次の4点です。

• 求人の必須要件を満たしているか
• 直近の経験が募集ポジションに近いか
• 役割と成果が具体的に書かれているか
• 入社後に活躍するイメージが湧くか

逆に言えば、この4点が短時間で伝わる書類は通りやすくなります。

書類選考で落ちる主な原因

業務内容が「作業の羅列」になっている

「詳細設計、実装、テストを担当」とだけ書いても、どんな工夫をしたのかは伝わりません。同じ工程を経験した人はたくさんいます。差がつくのは、そこで何を考え、何を変えたかです。

技術スタックを並べただけになっている

言語やフレームワークの名前を並べるだけでは、習熟度がわかりません。「何年使ったか」「どんな規模で使ったか」「設計から関わったか」まで書くと、評価しやすくなります。

自分の役割と成果が書かれていない

チームの成果を書いても、本人の貢献が見えないと評価できません。「チームで◯◯を開発」ではなく、「自分は◯◯を担当し、△△を実現した」と書きます。

応募先ごとに内容を変えていない

すべての企業に同じ職務経歴書を出していると、どの求人にも少しずつ合わない書類になります。応募先が重視する経験を、上に持ってくるだけでも印象は変わります。

必須要件を満たしていない求人に応募している

必須要件を大きく外れた求人は、書類の出来に関係なく見送られやすいです。「歓迎要件」は満たしていなくても応募の余地がありますが、「必須要件」は別物と考えてください。

希望年収やポジションが経験とずれている

希望年収が経験に対して高すぎる、またはマネジメント経験がないのにマネージャー職に応募している、といったケースです。希望条件そのものが悪いわけではありません。根拠が書類から読み取れないことが問題です。

転職回数・ブランク・短期離職の説明がない

経歴に気になる点があるとき、説明がないと採用側は悪い方向に想像しがちです。理由を一行添えるだけで、印象はかなり変わります。

読みにくさ・基本的なミス

誤字、日付の矛盾、リンク切れのGitHubやポートフォリオは、それだけで丁寧さを疑われます。エンジニアの書類では、細かいミスが仕事ぶりと結びつけて見られやすいです。

職務経歴書の直し方

冒頭に職務要約を3〜5行で書く

最初に読まれるのは職務要約です。ここで「何ができる人か」を伝えます。

• 経験してきた領域（Web系、業務系、インフラなど）
• 得意な技術と役割（バックエンド、テックリード、PMなど）
• 次にやりたいこと（応募先とつながる内容）

この3点を入れると、読み手が全体像をつかみやすくなります。

プロジェクトは「背景・役割・行動・結果」で書く

プロジェクトごとに、次の順で書くと伝わりやすくなります。

• 背景：どんな課題があったか
• 役割：自分の立場とチーム体制
• 行動：自分が何をしたか
• 結果：何が変わったか

書き換えの例を示します（例示用の架空の内容です）。

Before

ECサイトの機能開発を担当。PHP、Laravel、MySQLを使用。設計・実装・テストを担当。

After

ECサイトの注文処理の改修を担当（チーム5名、バックエンド担当）。注文確定時の処理が遅く、問い合わせが増えていたため、クエリの見直しと非同期処理への切り替えを提案・実装。レスポンスの改善により、関連する問い合わせが減少した。

同じ経験でも、After のほうが「課題を見つけて解決できる人」だと伝わります。

数字で書けない成果の書き方

成果を数字で示せないことも多いです。その場合は、次のような書き方ができます。

• 変化を書く：手作業だった作業を自動化した、属人化していた手順を文書化した
• 規模を書く：チームの人数、関わった部署の数、システムの利用者層
• 評価を書く：社内で横展開された、他チームから相談を受けるようになった

無理に数字を作るより、事実を具体的に書くほうが信頼されます。

技術スキルは経験年数と深さをセットで書く

スキル欄は、次のように深さがわかる形にします。

• 言語・フレームワーク名
• 実務での使用期間
• 関わり方（設計から担当、既存コードの保守中心、など）

触った程度の技術を並べすぎると、かえって得意分野がぼやけます。

PM・リーダー経験は「判断」を書く

PMやリーダーの経験がある人は、担当したタスクより「何を判断したか」を書いてください。スコープの調整、優先順位の決定、メンバーの役割分担、ステークホルダーとの交渉などです。採用側は、その人が入ったら何を任せられるかを知りたいと考えています。

応募先ごとに要約と並び順を変える

職務経歴書を毎回ゼロから書く必要はありません。変えるのは次の2か所で十分です。

• 職務要約の「次にやりたいこと」
• プロジェクトの並び順（応募先に近い経験を上に）

応募戦略を見直す

必須要件と歓迎要件を読み分ける

求人票は、必須要件を満たしているかをまず確認します。歓迎要件は「あれば嬉しい」程度のことが多いです。歓迎要件を満たしていないことを理由に応募をあきらめる必要はありません。

応募先の幅を見直す

通らない応募先に共通点がないか振り返ってください。たとえば次のような偏りです。

• 有名企業や人気サービスばかりに応募している
• 今の経験から一段上のポジションばかり狙っている
• 未経験の技術領域ばかりに応募している

企業のフェーズ（スタートアップ、成長期、大企業）や、同じ技術を使う別業界まで広げると、経験を評価してくれる企業が見つかりやすくなります。

希望条件に優先順位をつける

年収、リモート可否、技術スタック、業界など、すべてを満たす求人は多くありません。「絶対に譲れない条件」と「妥協できる条件」を分けておくと、応募先を選びやすくなります。

転職エージェントやスカウトを活用する

自分だけで書類を直すのに限界を感じたら、第三者の目を入れるのも有効です。

エージェント経由で応募するメリット

• 職務経歴書の添削を受けられる
• 企業が重視しているポイントを事前に聞ける
• 担当者からの推薦コメントを添えて応募できる
• 書類で落ちた理由を聞ける場合がある

一方で、担当者によって技術への理解度や提案の質には差があります。合わないと感じたら、担当の変更や別サービスの併用を検討してください。

スカウト型サービスで市場の反応を確かめる

スカウト型サービスに職務経歴書を登録すると、どんな企業から声がかかるかで、自分の経歴がどう見られているかを知る手がかりになります。反応が少ない場合は、書き方を見直すサインと考えられます。

経験者エンジニア向けの主なサービス

サービスごとの特徴や選び方は、転職エージェント比較ページで詳しくまとめています。1社に絞らず、エージェントとスカウト型を組み合わせて使う人も多いです。

それでも通らないときのチェックリスト

応募前に、次の項目を確認してください。

• 職務要約を読むだけで「何ができる人か」が伝わるか
• 各プロジェクトに自分の役割と結果が書かれているか
• 応募先に近い経験が上のほうにあるか
• 求人の必須要件を満たしているか
• 希望年収やポジションの根拠が書類から読み取れるか
• 転職回数やブランクに一言説明を添えたか
• 誤字、日付の矛盾、リンク切れがないか
• 第三者（エージェントや知人のエンジニア）に一度読んでもらったか

まとめ

エンジニアの転職で書類選考が通らないときは、次の順で見直すのが近道です。

1. 職務経歴書：役割と成果が伝わる書き方に直す
2. 応募先：必須要件と経験が合う求人に絞る
3. 進め方：エージェントやスカウトで第三者の視点を入れる

書類で落ちるのは、あなたの実力が足りないからとは限りません。伝え方と届け先を変えるだけで、結果が変わることは十分にあります。まずは職務要約の数行から書き直してみてください。