この記事でできるようになること

「なんとなく良さそう」で書類を通してしまう状態を、構造化された基準に置き換えられる
複数の採用担当者が選考しても、評価がブレない仕組みを作れる
職種ごとに使い回せる評価基準テンプレートを手元に持てる

はじめに —— 「基準がない」と、何が起きるか

「書類選考の基準はありますか？」と聞くと、多くの採用担当者はこう答える。

「一応ありますよ。求人票に書いてある要件が基準です」

だが実際の選考では、求人票の要件と選考の判断が一致していないケースが非常に多い。

よくある現場の風景:

Aさんは「学歴・職歴の見栄え」で判断し、Bさんは「転職回数」を重視する
「技術スキル必須」と書いてあるのに、ポテンシャル枠で通過させる担当者がいる
面接官から「なんでこの人を書類で通したの？」と差し戻される

ある企業では、同じ候補者の書類を5人の担当者に見せたところ、「通過」と「不通過」が3対2に分かれた。基準が明文化されていないと、こうした「判断の分裂」が日常的に起きる。

書類選考の基準が曖昧なまま運用を続けると、3つの問題が連鎖する。

問題	具体的に起きること	影響
面接の無駄打ち	書類で落とすべき人が面接に進む	面接官の工数浪費（月10〜20時間）
優秀人材の見落とし	明確な基準がないため「迷ったら落とす」判断が増える	採用できたはずの人を逃す
選考スピードの低下	判断に迷うたびに上長に相談 → リードタイム長期化	候補者が他社に流れる

この記事では、こうした問題を解消するための「書類選考基準の作り方」を5ステップで解説する。テンプレートとチェックリストつきなので、読みながらそのまま自社の基準を作れる。

前提条件・準備するもの

基準設計を始める前に、以下を手元に用意しておくとスムーズに進められる。

準備するもの	用途	なければどうするか
求人票（JD）	基準のベースとなる要件を確認	採用担当者・現場マネージャーにヒアリング
過去の通過者・不通過者のデータ（5〜10名分）	基準の妥当性を検証	なくても作れるが、Step 4の検証ができない
面接官からのフィードバック（あれば）	「書類で見てほしかったこと」の洗い出し	Step 1のヒアリングで代替
Excel or スプレッドシート	評価基準シートの作成	Google スプレッドシートでOK

Step 1: 「何を見て判断しているか」を棚卸しする

最初にやるべきことは、いきなり基準を作ることではない。今、実際に何を見て判断しているかを洗い出すことだ。

やること

選考に関わる全員（採用担当者、面接官、現場マネージャー）に、以下の質問をする。

「書類を見たとき、最初にどこを見ますか？」
「この人は通過、と判断する決め手は何ですか？」
「逆に、この人はNGと感じるポイントは何ですか？」

棚卸しシート

評価観点	誰が重視している	判断基準（現状）	備考
例: 職務経歴の一貫性	採用担当A	転職回数3回以上はNG	感覚的な基準
例: 技術スキル	面接官B	JDに記載の言語経験があるか	年数は見ていない
例: 志望動機の具体性	現場マネージャー	「なぜうちなのか」が書かれているか	中途では記載なしも多い
...	...	...	...

ポイント: この段階では「正しい基準」を作ろうとしなくてよい。現状の判断基準を、属人的なものも含めてすべて書き出すことが目的。

よくある発見

棚卸しをすると、ほぼ確実に以下のパターンが出てくる。

同じ観点でも基準が違う: Aさんは「転職3回以上NG」、Bさんは「5回以上でなければOK」
暗黙の評価軸がある: 誰も明文化していないが「大手出身者を優先」という判断が実質的に働いている
JDに書いていない観点で判断している: 「コミュニケーション力」は求人票に書いていないが、職務経歴書の書き方で判断している

これらの「ズレ」と「暗黙知」を可視化することが、基準設計の出発点になる。

Step 2: 評価項目をMust / Want / NG に分類する

棚卸しした評価観点を、3つのカテゴリに分類する。

3分類の定義

カテゴリ	定義	判断への影響
Must（必須）	これを満たさなければ即不通過	1つでも欠ければNG
Want（加点）	あれば評価が上がるが、なくても不通過にはしない	加点方式で評価
NG（即不通過）	これに該当すれば他がどんなに良くても不通過	1つでも該当すればNG

分類テンプレート（エンジニア採用の例）

Must（必須要件）:

対象言語（Go / TypeScript）の実務経験3年以上
チーム開発経験あり（1人開発のみは不可）
日本語ビジネスレベル以上

Want（加点要件）:

マイクロサービスアーキテクチャの設計・運用経験（+20点）
CI/CDパイプラインの構築経験（+10点）
テックリードまたはメンター経験（+15点）
OSS貢献実績（+10点）

NG（即不通過）:

直近2年以内に同業他社で守秘義務違反の経歴
応募書類に明らかな虚偽記載
求人で明示している勤務地・勤務形態の条件不一致

分類テンプレート（営業職の例）

Must（必須要件）:

法人営業経験2年以上
新規開拓（テレアポ・飛び込み以外の手法含む）の実績あり
目標達成率の記載あり（数字で語れるか）

Want（加点要件）:

SaaS / IT商材の営業経験（+20点）
年間売上1億円以上の実績（+15点）
マネジメント経験（+10点）
英語での商談経験（+10点）

NG（即不通過）:

個人向け営業のみで法人営業経験ゼロ
職務経歴書に実績数字の記載が一切ない

分類のコツ

Mustは3〜5個に絞る。 多すぎると候補者プールが狭くなりすぎて、そもそも書類が通らない。「あったら嬉しい」レベルのものはWantに回す。

NGは「絶対に譲れないもの」だけ。 「転職回数が多い」をNGにするかWantの減点にするかは、採用方針で決める。迷ったらWant（減点）側に入れておき、運用しながら調整する。

Step 3: 評価項目にウェイト（配点）をつける

Must/Want/NGの分類ができたら、Want項目に点数をつけて合計100点満点のスコアリングシートにする。

ウェイト設計の手順

① 大項目を決める（3〜5個）

大項目	配点	含まれる小項目
技術スキル	40点	言語経験、アーキテクチャ、インフラ
業務経験	30点	業界経験、プロジェクト規模、役割
カルチャーフィット	20点	志向性、働き方、成長意欲
ポテンシャル	10点	学習速度、キャリアの一貫性

② 小項目に配点を振る

技術スキル（40点）の内訳例:

小項目	配点	評価基準
Go / TypeScript経験	20点	3年以上: 20点 / 1-3年: 12点 / 1年未満: 5点
マイクロサービス設計	10点	設計主導: 10点 / 参加経験: 6点 / なし: 0点
CI/CD構築	5点	あり: 5点 / なし: 0点
インフラ（AWS/GCP）	5点	運用経験: 5点 / 基礎知識: 2点 / なし: 0点

③ 通過ラインを設定する

判定	スコア	アクション
A（即面接）	80点以上	24時間以内に面接日程調整
B（面接推奨）	60〜79点	48時間以内に面接日程調整
C（保留）	40〜59点	他候補者の状況を見て判断
D（不通過）	39点以下	お見送り連絡

ウェイト設計でよくある失敗

失敗パターン	なぜ起きるか	対策
全項目が均等配点	「どれも大事」と考えて差をつけられない	「1つだけ残すならどれか」を面接官に聞く
技術スキルに偏りすぎ	エンジニア面接官が設計すると技術100%になりがち	ビジネスサイドの観点を必ず入れる
配点が細かすぎ	1点刻みで50項目 → 運用できない	大項目3〜5個、小項目は各3〜5個まで

Step 4: 過去データで基準を検証する

作った基準が「実際に使えるか」を、過去の選考データで検証する。

検証方法

過去の通過者・不通過者を5〜10名ピックアップし、新しい基準でスコアリングし直す。

候補者	実際の結果	新基準スコア	新基準判定	一致
候補者A	通過→内定	82点	A（即面接）	✅
候補者B	通過→面接NG	55点	C（保留）	⚠️ 書類で止められた
候補者C	不通過	71点	B（面接推奨）	❌ 見落としていた
候補者D	通過→内定辞退	78点	B（面接推奨）	✅
候補者E	不通過	35点	D（不通過）	✅

チェックポイント

通過→面接NGが多い → Mustの基準が甘い。面接官が重視する項目をMustに追加
不通過だが高スコア → 基準が厳しすぎるか、NGの条件が広すぎる。見直しが必要
通過→内定者のスコアが低い → ウェイト配分が実態と合っていない。内定者が高く出るように調整

検証データがない場合: Step 5に進み、2〜4週間の運用データを溜めてから検証する。最初から完璧な基準は作れないので、「まず使ってみる → 調整する」のサイクルが重要。

Step 5: 評価シートにまとめて運用を開始する

Steps 1〜4の成果物を、実際に選考で使える1枚のシートにまとめる。

評価シートの構成

■ 求人名: [ポジション名]
■ 作成日: [日付]  ■ 最終更新日: [日付]
■ 作成者: [名前]  ■ 承認者: [名前]

━━━━━━━━━━━━━━━━━━━━━━━
【STEP 1】NG チェック（1つでも該当 → 即不通過）
━━━━━━━━━━━━━━━━━━━━━━━
□ [NG項目1]
□ [NG項目2]
□ [NG項目3]

→ 該当あり → 不通過  |  該当なし → STEP 2へ

━━━━━━━━━━━━━━━━━━━━━━━
【STEP 2】Must チェック（すべて満たす → STEP 3へ）
━━━━━━━━━━━━━━━━━━━━━━━
□ [Must項目1]
□ [Must項目2]
□ [Must項目3]

→ 1つでも未達 → 不通過  |  全達成 → STEP 3へ

━━━━━━━━━━━━━━━━━━━━━━━
【STEP 3】Want スコアリング（100点満点）
━━━━━━━━━━━━━━━━━━━━━━━
[大項目1]（__点 / 40点）
  - [小項目1]: __点 / 20点
  - [小項目2]: __点 / 10点
  - [小項目3]: __点 / 10点

[大項目2]（__点 / 30点）
  ...

合計: __点 / 100点

━━━━━━━━━━━━━━━━━━━━━━━
【判定】
━━━━━━━━━━━━━━━━━━━━━━━
□ A（80点以上）→ 即面接
□ B（60〜79点）→ 面接推奨
□ C（40〜59点）→ 保留
□ D（39点以下）→ 不通過

担当者コメント:

運用のルール

ルール	理由
評価シートは求人ごとに作る	営業職とエンジニア職で同じ基準は使えない
月1回、基準を見直す	市場の変化、面接官のフィードバックを反映
判断に迷ったら「保留」にして2人目の意見を取る	1人の判断で落とさない仕組み
通過率を記録する	通過率が高すぎ（80%超）→ 基準が甘い、低すぎ（20%未満）→ 基準が厳しすぎる

通過率の目安

通過率	状態	アクション
20〜40%	適正	現状維持
40〜60%	やや甘い	Must要件の見直し、またはWantの通過ラインを引き上げ
60%超	基準が機能していない	Step 1からやり直し
20%未満	厳しすぎ	母集団の質か基準のどちらかに問題。Must要件を減らす

よくあるトラブルと対処法

Q1: 「現場が基準を守ってくれない」

原因: 基準設計に現場（面接官・現場マネージャー）が関わっていない。
対処: Step 1の棚卸しから現場を巻き込む。自分たちが作った基準なら守るモチベーションが生まれる。

Q2: 「基準を作ったが、候補者が全員不通過になる」

原因: Mustを欲張りすぎている。
対処: Mustは「絶対に譲れない3つ」に絞る。それ以外はWantに移動させ、加点方式で評価する。

Q3: 「職種ごとに基準を作るのが大変」

原因: ゼロから作ろうとしている。
対処: 共通のMust（勤務地、日本語レベルなど）をテンプレート化し、技術スキル・業務経験のWant部分だけ職種ごとにカスタマイズする。共通部分7割 + 職種固有部分3割が効率的。

Q4: 「スコアリングに時間がかかりすぎる」

原因: 小項目が多すぎる（20項目以上）。
対処: 大項目3〜5個 × 小項目3〜5個 = 最大25項目に抑える。1名あたり5〜10分で完了するのが目安。それ以上かかるなら項目を減らす。

Q5: 「評価基準を作り込む時間と人的リソースがない」

原因: 採用担当者が少人数で、日常業務に追われている。
対処: まず最低限のMust 3項目 + NG 2項目だけで運用を始める。Wantのスコアリングは後から追加すればよい。完璧な基準を作ってから始めるのではなく、最小限で始めて育てるのが現実的。

AIツールを活用すれば、求人要件をもとに評価項目の叩き台を自動生成し、担当者はレビューと微調整だけで済む。評価基準の「作り込みハードル」を大幅に下げられる。

まとめ —— 基準は「作って終わり」ではなく「育てる」もの

書類選考基準の作り方を5ステップで解説した。

Step	やること	成果物
1	判断基準の棚卸し	評価観点リスト
2	Must/Want/NG分類	3分類テンプレート
3	ウェイト設計	100点満点スコアリングシート
4	過去データ検証	基準の妥当性確認
5	評価シート化＆運用開始	運用ルール付き評価シート

最も重要なのは、基準は一度作ったら終わりではないということだ。

採用市場は変わる。求めるスキルセットも変わる。面接で「この観点を書類で見てほしかった」というフィードバックも出てくる。月1回の見直しサイクルを回すことで、基準は「属人的な感覚」から「組織の知見」に育っていく。

Tasonal AI書類選考は、求人要件をもとにAIが評価項目を構造化し、候補者を0〜100点でスコアリングする。Must/Want/NGの設計、職種ごとのウェイト配分も求人単位でカスタマイズ可能。「基準の作り込みが大変」という課題を、AIの叩き台生成で解消する。

→ 無料で試してみる

書類選考の評価基準の作り方｜「なんとなく通過」を卒業する5ステップ設計法