このページでわかること

• エンジニアの職務経歴書・レジュメで本当に見るべきポイントと見落としがちな要素

• 非エンジニア人事でも使える書類選考の評価基準テンプレートと通過判定の考え方

• 書類選考の通過率を最適化して、優秀な候補者を逃さず採用効率を上げる方法

• GitHub・ポートフォリオ・技術ブログなど補助資料の正しい評価方法

• AI時代における書類選考の自動化・効率化の実践手法

エンジニア採用の書類選考は、非エンジニアの人事担当者にとって最もハードルが高い工程の一つです。技術用語が並ぶ職務経歴書をどう読み、何を基準に通過・不通過を判断するのか。本記事では、書類選考の設計から運用まで、すぐに使える実践的な手法を解説します。エンジニア採用の選考フロー設計や構造化面接の設計と併せて活用してください。

TL;DR（要点まとめ）

• 書類選考の通過率は30〜40%が目安。低すぎると優秀な人材を逃し、高すぎると面接工数が膨らむ

• 職務経歴書で最も重視すべきは「経験年数」ではなく**「何を作り、どんな課題を解決したか」**の具体性

• 技術スタックの一致度だけで判断しない。学習能力と適応力を示すキャリアの変遷にも注目する

• 非エンジニア人事は「Must（必須）」「Nice-to-have（歓迎）」の2段階で評価基準を設計し、現場エンジニアとすり合わせる

• 書類選考は48時間以内のレスポンスが鉄則。スピードが候補者体験と歩留まりを決める

1. エンジニア採用における書類選考の位置づけと課題

なぜ書類選考が採用成功の鍵を握るのか

エンジニア採用の選考プロセスにおいて、書類選考は「最初のフィルター」であると同時に「最初の候補者体験」でもあります。ここでの判断が、その後の採用活動全体の効率と質を左右します。

書類選考が適切に設計されていない場合、以下の問題が起きます。

• 優秀な候補者を落としてしまう: 技術スタックの完全一致を求めすぎて、ポテンシャルの高い人材をスクリーニングアウトする

• 面接の質が下がる: 通過基準が甘すぎて、面接に進むべきでない候補者が大量に流入する

• 候補者体験が悪化する: レスポンスの遅さや画一的なお祈りメールが、企業の評判を下げる

特にエンジニア採用では、技術スキルの評価という専門性の高い判断が求められるため、非エンジニアの人事担当者と現場エンジニアの連携が不可欠です。

エンジニアの書類選考でよくある3つの失敗パターン

失敗1: 技術キーワードの完全一致に固執する

「Java 5年以上」「AWS経験必須」といった要件に1つでも合致しない候補者を即不通過にしてしまうパターンです。しかし、優秀なエンジニアは新しい技術を短期間で習得できます。PythonからGoへの移行、AWSからGCPへの移行は、基礎力のあるエンジニアにとっては大きなハードルではありません。

失敗2: 経歴の「見た目」だけで判断する

有名企業の出身者を優遇し、中小企業や受託開発出身者を低く評価してしまうケースです。大企業出身でも限定的な役割しか担っていないことがあり、逆に小規模チームで幅広い経験を積んだエンジニアが即戦力になることも多くあります。

失敗3: 書類だけで合否を決めすぎる

書類選考で「完璧な候補者」を探そうとして、通過率が10%以下になるケースです。書類だけでは候補者のコミュニケーション力、問題解決の思考プロセス、カルチャーフィットは判断できません。書類選考はあくまで「面接に進めるべきかの判断」であり、最終評価は面接で行うものです。

2. エンジニアの職務経歴書・レジュメの読み方

職務経歴書の基本構成を理解する

エンジニアの職務経歴書は、一般的な職種とは異なる特徴を持っています。まず、その基本構成を押さえましょう。

技術スタックの評価方法

技術スタックの記載を評価するとき、以下の4つの視点で読み解きます。

視点1: 技術の深さ（Depth）

単に「React」と書かれているだけでは情報不足です。優秀なエンジニアの職務経歴書には、以下のような具体性があります。

• 使用しているバージョンやエコシステム（例: React 18 + Next.js 14 + TypeScript）

• 技術選定の理由や比較検討のプロセス

• パフォーマンス改善やアーキテクチャ設計の具体的な取り組み

視点2: 技術の幅（Breadth）

フロントエンドだけでなくバックエンドやインフラの経験があるか、異なるプログラミングパラダイム（オブジェクト指向、関数型など）に触れているかを確認します。幅広い経験は、技術的な視野の広さと学習能力の高さを示す指標です。

視点3: 技術の変遷（Evolution）

キャリアの中で技術スタックがどう変化してきたかに注目します。「5年間ずっと同じ技術を使い続けている」よりも「業務で必要になった技術を積極的に習得してきた」方が、入社後の適応力が高い可能性があります。

視点4: 自社要件との一致度

求人要件との一致度は、「完全一致」を求めるのではなく、以下の3段階で評価するのが現実的です。

• コア技術が一致: メイン言語やフレームワークが一致している（最優先）

• 隣接技術の経験あり: 同じカテゴリの別技術の経験がある（例: Vue.js経験者にReactポジション）

• 基礎力あり: 技術は異なるが、アーキテクチャ設計やシステム思考の経験が豊富（要検討）

プロジェクト経歴の評価ポイント

プロジェクト経歴こそ、候補者の実力を最も正確に読み取れるセクションです。以下の5つの観点でチェックしましょう。

1. 規模感の把握

チームの人数、プロジェクトの期間、サービスの規模（ユーザー数、トラフィック量など）が記載されているかを確認します。規模感があると、候補者がどのレベルの複雑性を扱えるかがわかります。

2. 役割の具体性

「開発に従事」ではなく、「設計から実装、レビュー、リリースまでを担当」「チームの技術選定をリード」など、具体的な役割と責任範囲が記載されているかを見ます。

3. 課題と解決策のセット

単に「〜を開発した」ではなく、「〜という課題に対して、〜というアプローチで解決した」という因果関係が書かれているかが重要です。課題を特定し、解決策を考え、実行する力はエンジニアの核心的な能力です。

4. 成果の定量化

「パフォーマンスを改善した」よりも「レスポンスタイムを800msから200msに短縮した」の方が信頼性が高いです。ただし、すべての成果を定量化できるわけではないため、定性的な成果（コードベースの可読性向上、チームの開発体験改善など）も正当に評価しましょう。

5. 技術的意思決定への関与

「なぜその技術を選んだのか」「トレードオフをどう判断したのか」が書かれている候補者は、単なる実装者ではなく技術的な意思決定に関与できるエンジニアである可能性が高いです。

非エンジニア人事が押さえるべき「技術用語の読み方」

すべての技術用語を理解する必要はありません。以下の分類を押さえておけば、技術スタックの概要は把握できます。技術リテラシーの詳細は「非エンジニア人事の技術リテラシー入門」を参照してください。

3. 書類選考基準の設計方法

Must / Nice-to-haveフレームワーク

書類選考の基準は、「Must（必須条件）」と「Nice-to-have（歓迎条件）」の2段階で設計するのが最も実践的です。この基準は、求人票を作成する段階で現場エンジニアと人事が一緒に設計します。求人票の書き方も参考にしてください。

Mustの設計ルール:

• 最大3項目に絞る（多すぎると候補者プールが枯渇する）

• 「年数」ではなく「経験内容」で定義する

• 入社後3ヶ月以内にキャッチアップ不可能なスキルのみをMustにする

例: バックエンドエンジニアの書類選考基準

評価スコアリングシートの設計

書類選考の属人化を防ぐために、スコアリングシートを作成します。以下は実用的なテンプレートです。

5段階評価（各項目1〜5点）:

通過判定の目安:

• 20点以上: 即通過（優先的にスケジュール調整）

• 15〜19点: 通過（通常フローで選考）

• 10〜14点: 要検討（現場エンジニアに確認後判断）

• 9点以下: 不通過

現場エンジニアとの連携方法

書類選考の品質を上げるために、現場エンジニアとの連携は必須です。ただし、現場エンジニアの開発業務への影響を最小限に抑える工夫が必要です。ハイヤリングマネージャーの役割も参考にしてください。

連携の3ステップ:

1. 基準設計時（月1回）: 求人要件と書類選考基準を一緒に作成・更新する

2. 判断に迷う案件の相談（随時）: Slackなどで技術スタックや経歴についてクイックに確認する

3. 選考結果の振り返り（月1回）: 書類通過者のうち面接合格した割合を確認し、基準を調整する

現場エンジニアには「全件のレジュメを見てほしい」ではなく、「判断に迷う案件だけ相談させてほしい」とお願いする方が協力を得やすくなります。

4. GitHub・ポートフォリオ・技術ブログの評価方法

エンジニアの選考では、職務経歴書だけでなくGitHub、ポートフォリオ、技術ブログなどの補助資料を確認する機会があります。これらの正しい評価方法と注意点を解説します。詳細は「GitHubとポートフォリオの正しい評価ガイド」もご覧ください。

GitHubの評価ポイント

GitHubのプロフィールを確認する際、コントリビューション数（草の緑色の濃さ）だけで判断するのは避けましょう。業務でプライベートリポジトリを使っている場合、GitHubのコントリビューショングラフには反映されません。

見るべきポイント:

• コードの品質: README、コミットメッセージの丁寧さ、テストの有無

• プロジェクトの種類: 実用的なツールやライブラリを公開しているか

• Issue・PRの対応: OSSプロジェクトへの貢献、コードレビューの質

• 最新のアクティビティ: 直近の活動状況（ただし、活動がないことがマイナスとは限らない）

注意点:

• GitHubが空でも優秀なエンジニアは多い。業務コードはGitHubには載せられない

• スター数は人気の指標であり、技術力の指標とは限らない

• GitHubの提出を必須にすると、候補者プールが狭まるリスクがある

技術ブログの評価ポイント

技術ブログ（Zenn、Qiita、個人ブログなど）は、候補者の技術的な思考プロセスを知る貴重な資料です。

高評価の指標:

• 技術的な課題の発見から解決までのプロセスを論理的に記述している

• 単なるチュートリアルの写経ではなく、独自の視点や工夫がある

• 新しい技術のキャッチアップを継続的に行っている形跡がある

• 読み手を意識した構成と文章力がある

注意点:

• ブログを書いていないエンジニアが大多数。ブログの有無で選別しない

• 記事の数より質を重視する

• 古い記事が多い場合は、直近の技術レベルの参考にならない可能性がある

ポートフォリオの評価

デザインの完成度よりも、以下の点に注目しましょう。

• 技術選定の理由が説明されているか

• 実際にデプロイされて動作しているか

• ユーザーの課題を解決する視点があるか

5. 書類選考のスピードと候補者体験

48時間ルールを守る

エンジニア採用において、書類選考のスピードは成果に直結します。エンジニアの転職市場は売り手市場であり、優秀な候補者は複数の企業に同時応募しています。書類選考のレスポンスが遅いだけで、他社に先を越されてしまうのが現実です。

推奨タイムライン:

特にダイレクトリクルーティングでスカウトを送った候補者からの応募は、最優先で対応すべきです。こちらからアプローチしたにもかかわらずレスポンスが遅いと、候補者の印象は大きく悪化します。スカウト運用のPDCA改善も参考にしてください。

不通過の場合も丁寧に対応する

書類選考で不通過になった候補者への対応も、採用ブランディングの一部です。テンプレートであっても、以下のポイントを押さえた通知を送りましょう。

• 応募へのお礼を伝える

• 選考結果を明確に伝える（曖昧にしない）

• 可能であれば、不通過の主な理由を簡潔に伝える

• タレントプールへの登録を案内する（将来のポジションにマッチする可能性がある場合）

詳しい不採用通知の設計については「不採用通知とフィードバック設計ガイド」を参照してください。

書類選考の通過率を最適化する

書類選考の通過率は、採用チャネルや求人のポジションによって異なりますが、一般的な目安は以下の通りです。

全体の通過率が20%を下回っている場合は、求人要件が厳しすぎる、または求人票の内容と応募者の期待にギャップがある可能性があります。逆に60%を超えている場合は、基準が甘すぎて面接官の負担が増えている可能性があります。

通過率を定期的にモニタリングし、採用KPIとして管理することをおすすめします。

6. AI時代の書類選考の効率化

AIを活用した書類スクリーニング

2026年現在、書類選考にAIを活用する企業が増えています。ただし、AIに丸投げするのではなく、人間の判断を補助するツールとして活用するのが現実的なアプローチです。

AIが得意な領域:

• 技術スタックのキーワードマッチング

• 職務経歴書のフォーマット正規化（異なるフォーマットの統一化）

• 基本的な要件チェック（年数、資格の有無など）

• 候補者情報の要約作成

AIに任せるべきでない領域:

• 最終的な通過・不通過の判断

• プロジェクト経歴の質的な評価

• カルチャーフィットやポテンシャルの判断

AI活用における公平性やバイアスの問題については「エンジニア採用AI活用のリスクと法的対応ガイド」で詳しく解説しています。

AI時代に職務経歴書をどう読むか

生成AIの普及により、職務経歴書やカバーレターをAIで作成・ブラッシュアップする候補者が増えています。これ自体は問題ではありませんが、以下の点に注意して評価する必要があります。

AI作成レジュメの特徴:

• 文章が過度に洗練されており、定型的な表現が多い

• 具体的な数値やプロジェクト名が曖昧

• 技術用語の使い方が表面的（深い理解を伴わない羅列）

対策:

• 職務経歴書の内容を面接で深掘りし、本人の実体験かどうかを確認する

• プロジェクトの具体的なエピソード（失敗経験、トレードオフの判断など）を聞く

• 技術的な補助資料（GitHub、技術ブログ等）との整合性を確認する

重要なのは、「AIで作成されたからダメ」ではなく、**「書かれている内容が本人の実力を正しく反映しているか」**を確認することです。

書類選考のワークフロー自動化

書類選考の工数を削減するために、ワークフローの自動化も検討しましょう。ATS（採用管理システム）を活用すると、以下の自動化が可能です。

• 応募受領時の自動返信メール

• 技術スタックのキーワードによる自動タグ付け

• 評価シートの自動生成

• 不通過通知の一括送信

• 面接官への自動アサイン

ただし、自動化しすぎると「人間味のない対応」になり、候補者体験を損なうリスクがあります。特に通過通知や不通過通知は、テンプレートを使いつつもパーソナライズの要素を残すことが重要です。採用AXの実践手法もあわせて参考にしてください。

7. 書類選考でよくある判断に迷うケース

ケース1: 技術スタックが一致しないが経歴が魅力的

Go言語の求人に対して、PythonやJavaの経験しかないが、大規模システムの設計・運用経験が豊富な候補者が応募してきた場合。

判断基準: 言語の違いよりも、アーキテクチャ設計の経験やシステム思考の深さを重視する。静的型付け言語の経験があれば、Goへの移行は比較的スムーズ。通過させて面接で技術力を確認するのが得策。

ケース2: 短期間での転職が多い（ジョブホッパー）

直近5年で3社以上を経験している候補者の場合。

判断基準: 単に「転職回数が多い」だけで不通過にしない。エンジニア業界では、スタートアップの事業撤退やプロジェクト完了による退職は珍しくない。各社での経験内容と、キャリア全体での成長ストーリーに一貫性があるかを確認する。ただし、すべての在籍が1年未満の場合は、面接で転職理由を丁寧にヒアリングする前提で通過判断を行う。

ケース3: ブランク期間がある

1年以上のブランク期間がある候補者の場合。

判断基準: ブランクの理由はさまざま（育児、介護、留学、個人プロジェクト、体調回復など）であり、ブランクがあること自体をマイナス評価にしない。ブランク中に技術学習やOSS活動を行っている場合はプラス評価。面接でブランクの理由と現在の技術レベルを確認する前提で、スキルが要件に合っていれば通過させる。

ケース4: SES・受託開発出身のエンジニア

自社プロダクト開発の求人に、SESや受託開発出身の候補者が応募してきた場合。

判断基準: SES・受託開発の経験を一律に低く評価するのは避ける。多様な業界・技術スタックに触れた経験は強みになりうる。注目すべきは、「指示された作業をこなしていただけか」「自ら設計や技術選定に関与していたか」の違い。詳しくは「SES出身エンジニアの採用と見極め方」を参照。

ケース5: 新卒・未経験からのキャリアチェンジ

プログラミングスクール卒や独学で学んだ未経験エンジニアの場合。

判断基準: ポジションが「即戦力」を求めているのか「ポテンシャル採用」を許容しているのかで判断が変わる。ポテンシャル採用の場合は、ポートフォリオの完成度、技術的な好奇心、学習の継続性を重視する。ポテンシャル採用の実践ガイドやプログラミングスクール卒エンジニアの採用ガイドも参考にしてほしい。

8. 書類選考の品質を継続的に改善する方法

データで振り返る

書類選考の品質を高めるには、定期的なデータ分析と振り返りが欠かせません。以下の指標を月次でトラッキングしましょう。

書類→面接合格率が低い場合: 書類選考の基準が甘い可能性。Must条件の見直しや、スコアリングの閾値を上げることを検討する。

書類→面接合格率が高すぎる場合: 書類選考が厳しすぎて、面接に進むべき候補者を落としている可能性。Nice-to-have条件の緩和を検討する。

面接官からのフィードバックを活かす

面接後に「書類の印象と面接の印象が大きく違った」というフィードバックがあれば、書類選考の基準を見直すサインです。

• 「書類は良かったが面接では期待外れだった」→ 書類で見るべきポイントが不足している

• 「書類は微妙だったが面接では非常に良かった」→ 書類選考の基準が的外れな可能性がある

このフィードバックサイクルを回すことで、書類選考の精度は着実に向上します。面接デブリーフの仕組み化と連動させると効果的です。

チェックリスト: 書類選考の運用品質

定期的に以下のチェックリストで運用状況を確認しましょう。

• 書類選考基準は直近3ヶ月以内に更新されているか

• 現場エンジニアと基準のすり合わせを行っているか

• 書類選考のリードタイムが48時間以内に収まっているか

• 通過率は適切な範囲（30〜40%）に入っているか

• 不通過の通知は丁寧に行われているか

• 書類通過者の面接合格率は30%以上あるか

• 書類選考者間の評価のブレが生じていないか

FAQ（よくある質問）

Q1. エンジニアの職務経歴書で「経験年数」はどの程度重視すべきですか？

経験年数は参考指標の一つですが、過度に重視すべきではありません。「3年間同じ作業を繰り返していた」エンジニアよりも、「1年間で多様なプロジェクトに挑戦し成長した」エンジニアの方が即戦力になるケースは多くあります。年数よりも「何を経験し、何を学んだか」の具体性で評価することが重要です。求人票にも「〜年以上」ではなく「〜の経験」と記載する方が、適切な候補者を集めやすくなります。

Q2. 書類選考は人事だけで行うべきですか？現場エンジニアも参加すべきですか？

理想は「人事が一次スクリーニング、判断に迷うケースを現場エンジニアに相談」という分担です。全件を現場エンジニアに回すと開発業務に支障が出ます。人事がMust条件のチェックとスコアリングを行い、スコアがボーダーライン付近の候補者について現場エンジニアの意見を求めるのが現実的です。

Q3. 英語の職務経歴書（レジュメ）はどう評価すればよいですか？

英語レジュメは日本語の職務経歴書とフォーマットが異なります。一般的にサマリー → 職歴 → スキル → 学歴の順で構成されます。職歴は箇条書きでAction Verb（動詞）から始まる表現が多く、「Led」「Designed」「Implemented」「Optimized」などの動詞が、候補者の役割レベルを把握する手がかりになります。英語レジュメの場合も、評価の本質は同じで「何を作り、どんな課題を解決したか」の具体性を重視します。

Q4. 書類選考にAIスクリーニングツールを導入する際の注意点は？

AI選考ツールには採用バイアスのリスクがあります。学歴や性別、年齢といった属性で無意識にフィルタリングされる可能性があるため、導入前にバイアスチェックを行いましょう。また、AIによる判定結果は最終判断にせず、人間がレビューするプロセスを必ず設けてください。法的にも、AI選考の透明性や説明責任が求められる傾向が強まっています。

Q5. ダイレクトスカウトで送った候補者からの応募も、書類選考は必要ですか？

スカウト時点で候補者のプロフィールを確認しているため、通常の書類選考とは異なる扱いにするのが合理的です。ただし、「書類選考免除で即面接」にすると面接官の負担が増えるリスクがあります。スカウト候補者には簡易版の書類確認（職務経歴書の更新依頼＋簡単なフォーマットでの情報整理）を行い、面接の準備に活用するのがベストプラクティスです。

Q6. 書類選考で落とした候補者が、別のポジションに応募してきた場合は？

以前の選考結果に引きずられず、新しいポジションの要件に照らして改めて評価すべきです。前回の不通過理由が「技術スタックの不一致」であれば、新しいポジションでは問題ないケースもあります。ATS上で過去の選考履歴を確認しつつ、フラットに判断しましょう。タレントプールに登録されている候補者であれば、再応募を歓迎する姿勢で対応します。

Q7. 職務経歴書が極端に短い（1ページ以下）場合、どう判断すべきですか？

エンジニアの中には、簡潔さを重視して短いレジュメを作成する人もいます。特に海外経験のあるエンジニアは「1ページレジュメ」が一般的です。内容が充実していれば短くても問題ありません。逆に、長いだけで具体性のない職務経歴書よりも、要点が絞られた短いレジュメの方が、情報の整理能力が高い可能性もあります。判断に迷う場合は、GitHubやポートフォリオなどの補助資料を確認するか、カジュアル面談に案内するのも一つの手です。

まとめ：書類選考を「落とすための関門」から「見つけるための仕組み」へ

エンジニア採用の書類選考は、候補者をふるい落とすためのプロセスではなく、自社にとって価値ある人材を見つけ出すための仕組みとして設計すべきです。

本記事のポイントを振り返ります。

1. Must条件は最大3つに絞り、技術の完全一致を求めない。学習能力と適応力も重要な評価軸

2. スコアリングシートで属人化を防ぎ、評価のブレをなくす。現場エンジニアとの基準すり合わせも定期的に

3. 書類選考のスピードは候補者体験に直結する。48時間以内のレスポンスを徹底

4. GitHub・技術ブログなどの補助資料は参考情報として活用。提出がないことをマイナス評価にしない

5. データで通過率をモニタリングし、基準を継続的に改善する。面接官からのフィードバックも活用

書類選考の精度を上げることで、面接の質が向上し、結果として採用全体の効率と成果が高まります。

エンジニア採用の書類選考や選考プロセス全体の設計でお困りなら、techcellarにご相談ください。採用媒体でのスカウト運用から選考設計まで、エンジニア×AIの視点で採用成功をサポートします。