採用基準の決め方｜「いい人が来たら採る」から脱却する5ステップ設計法
はじめに —— 「いい人が来たら採る」が失敗する構造
「採用基準はありますか？」と聞くと、多くの企業が「あります」と答えます。しかしその中身を見ると、
- 「経験3年以上」
- 「コミュニケーション能力が高い」
- 「当社のカルチャーに合う」
といった抽象的な要件が並んでいることがほとんどです。
これは「採用基準がある」のではなく、「採用基準のようなもの」がある状態です。担当者によって「コミュニケーション能力が高い」の意味が違い、「カルチャーに合う」の判断が個人の好みになる。結果、同じ候補者に対して面接官Aは「通過」、Bは「不通過」と判断する。
もっと根本的な問題は、「いい人が来たら採る」というスタンスです。基準を先に決めず、候補者を見てから判断する。これでは採用の質は永遠に安定しません。
この記事では、抽象的な「求める人物像」を、書類選考・面接で実際に使える採用基準に変換する5ステップを解説します。
採用基準が曖昧だと何が起きるか
| 問題 | 発生メカニズム | 影響 |
|---|---|---|
| 評価がブレる | 担当者ごとに「良い人」の定義が違う | 同じ候補者に真逆の評価 |
| 優秀人材を見逃す | MustとWantが区別されず、「全部満たす人」を探す | 候補者プールが枯渇 |
| 面接が非効率 | 「何を見るか」が決まっておらず、全方位で聞く | 時間がかかるのに深く見極められない |
| 現場と乖離 | 採用担当と現場で基準が違う | 「なぜこの人を通したの？」が発生 |
| PDCAが回らない | 基準が曖昧なので振り返れない | 次の採用も同じ失敗を繰り返す |
これらはすべて、**基準が「存在しない」のではなく「構造化されていない」**ことが原因です。
採用基準を構造化する5ステップ
Step 1: 「なぜこの採用が必要か」を言語化する
↓
Step 2: 「入社後6ヶ月の成果」を具体化する
↓
Step 3: Must / Want / NGに分類する
↓
Step 4: 抽象要件を観察可能な行動に分解する
↓
Step 5: 書類と面接の役割分担を決める
Step 1: 「なぜこの採用が必要か」を言語化する
最初のステップは、採用の背景を明確にすることです。これが曖昧だと、後のすべてがブレます。
言語化すべき3つの問い：
| 問い | 悪い回答例 | 良い回答例 |
|---|---|---|
| なぜ今この人が必要か？ | 「人が足りないから」 | 「新規事業の立ち上げに当たり、プロダクトのアーキテクチャ設計をリードできる人材が必要」 |
| この人がいないと何が困るか？ | 「忙しい」 | 「プロダクトのリリーススケジュールが3ヶ月遅れ、競合に先を越される」 |
| 育成では補えないか？ | 「無理」 | 「既存メンバーにアーキテクチャ経験がなく、1年以上の育成期間が必要。事業スピードを考えると即戦力採用が必要」 |
この段階で現場のマネージャーと合意しておくことが重要です。採用担当者だけで決めると、現場から「こんな人を探してくれとは頼んでいない」と言われるリスクがあります。
Step 2: 「入社後6ヶ月の成果」を具体化する
採用基準を決める最も効果的な方法は、「入社後6ヶ月で何をしていてほしいか」を先に決めることです。
これが具体的であれば、「そのために何が必要か」は自然に導出されます。
| 悪い例 | 良い例 |
|---|---|
| 「プロダクト開発に携わってほしい」 | 「新規プロダクトのAPIアーキテクチャを設計し、チームのレビューを経て実装・リリースまで立ててほしい」 |
| 「営業を強化したい」 | 「月間8件の新規商談をこなし、2件以上の受注を獲得してほしい」 |
| 「チームをリードしてほしい」 | 「5人の開発チームの1on1・スプリント運営・技術方針を主導し、リリースサイクルを改善してほしい」 |
具体的な「6ヶ月後の姿」が描ければ、「そのために何が必要か」は自明です。 APIアーキテクチャを設計できる人には、バックエンドの設計経験が必要だと分かる。しかし「プロダクト開発に携わる」だけでは、何が必要か分からない。
Step 3: Must / Want / NGに分類する
すべての要件を、3層に分類します。
| 層 | 定義 | 判断ルール |
|---|---|---|
| Must | これがないと不採用 | 1つでも欠けていれば不通過 |
| Want | あれば加点 | 充足度に応じてスコア加算 |
| NG | これに該当したら不採用 | 自動的に不通過 |
MustとWantの境界線を引く問い
これが最も重要なステップです。境界線が曖昧だと、「全部Must」（候補者が見つからない）か「全部Want」（基準がないのと同じ）になります。
| 問い | Mustの場合 | Wantの場合 |
|---|---|---|
| この要件がない人が入社したら、業務が回るか？ | 回らない | 他でカバーできる |
| 過去にこの要件なしで採用した人はいるか？ | いない or 失敗 | 成功例がある |
| 入社後の育成で補えるか？ | 補えない | 補える |
| この要件で候補者の何%がフィルタされるか？ | 20%以下が適正 | 50%以上が消えるなら厳しすぎ |
具体例: バックエンドエンジニア
| 層 | 要件 | 判断基準 |
|---|---|---|
| Must | 静的型付け言語でのサーバーサイド開発3年以上 | Go/TypeScript/Java/Rust等。言語は問わない |
| Must | チームでの開発経験 | コードレビュー・Git運用の実務経験 |
| Must | 日本語での業務コミュニケーション | 読み書き・口頭ともに業務レベル |
| Want | クラウドインフラ（AWS/GCP）の構築・運用経験 | 重み: 20% |
| Want | マイクロサービス設計・運用経験 | 重み: 15% |
| Want | テックリード or チームリード経験 | 重み: 15% |
| NG | 競業避止契約が有効 | 即不通過 |
| NG | リモート専用希望（自社はハイブリッド） | 勤務条件不一致 |
注目すべきは、Mustの「静的型付け言語」という設計です。「Go経験3年」ではなく「静的型付け言語」と抽象度を上げることで、TypeScriptやJava出身の優秀なエンジニアも候補者プールに含められます。スキル（Go経験）はWant、コンピテンシー（課題解決力）はMust。この切り分けが重要です。
Step 4: 抽象要件を観察可能な行動に分解する
「コミュニケーション力」「リーダーシップ」といった抽象的な要件は、そのままでは評価できません。「書類や面接で確認できる具体的な行動」に分解します。
| 抽象要件 | 観察可能な行動に分解 | 書類での確認 | 面接での確認 |
|---|---|---|---|
| コミュニケーション力 | ① 複雑な内容を非専門家に分かりやすく説明できる ② 意見対立時に双方の立場を踏まえた解決策を提示できる | 職務経歴書の論理構成、実績の説明方法 | 面接での応答品質、深掘りへの対応 |
| リーダーシップ | ① メンバーの強み・弱みを把握しタスクを適切に配分した経験 ② 困難な状況で意思決定しチームを導いた経験 | 役職・チーム規模の記載 | STAR法でのエピソード確認 |
| 主体性 | ① 誰にも指示されずに自ら始めた取り組み ② 業務プロセスを自発的に改善した経験 | 「自ら提案」「主導」等の記載 | 「なぜそれに気づいたのか」を深掘り |
| カルチャーフィット | ① 不確実な環境で柔軟に対応できる ② スピード感を持って仕事を進められる | スタートアップ経験、新規事業経験 | 価値観に関する質問で探る |
ポイント: 抽象要件を「観察可能な行動」に分解するだけで、「コミュニケーション力が高い」の意味が担当者間で統一されます。
Step 5: 書類と面接の役割分担を決める
最後のステップは、各要件を「書類で確認」「面接で確認」のどちらで見るかを決めることです。
| 確認方法 | 向いている要件 | 例 |
|---|---|---|
| 書類で確認 | 経験年数、資格、定量的な実績など事実確認が可能なもの | 「サーバーサイド開発3年以上」 |
| 面接で確認 | 思考プロセス、コミュニケーションスタイル、価値観など対話でしか分からないもの | 「課題解決力」「カルチャーフィット」 |
| 書類で推定→面接で確定 | 書類から一定の推定はできるが、深さは面接で確認が必要 | 「チームリード経験」「設計判断力」 |
役割分担表の例
| 要件 | 書類 | 面接 | 引き継ぎ事項 |
|---|---|---|---|
| サーバーサイド開発3年以上 | ◎ | ○補完 | 「書類で確認済み。深さのみ面接で確認」 |
| チーム開発経験 | ◎ | — | 「確認済み。面接での再確認不要」 |
| 技術的課題解決力 | △推定 | ◎ | 「書類では推定レベル4。面接で深掘りして確定してください」 |
| 協働推進力 | ×不可 | ◎ | 「書類からは判断できない。面接で重点確認」 |
| カルチャーフィット | △推定 | ◎ | 「スタートアップ経験あり。不確実性耐性を確認」 |
この「引き継ぎ事項」が、書類選考→面接の質を劇的に上げます。 面接官は「何を重点的に確認すべきか」が事前に分かる状態で面接に臨めるので、「ご経歴を教えてください」から始める必要がなくなります。
採用基準が変える3つの場面
場面1: 「全員Must」の罠から抜け出せる
「Go経験3年」「AWS経験必須」「マイクロサービス経験必須」——すべてをMustにすると、候補者プールは極端に絞られます。
Must/Wantを分類すれば、「サーバーサイド開発の基本力はMustだが、Go経験はWant（入社後習得可能）」と設計できる。スキルは育成できるが、行動特性（コンピテンシー）は容易に変わらない——この原則で切り分けると、「スペック外だが本質的に優秀な人材」を見逃さなくなります。
場面2: 現場との「温度差」がなくなる
採用担当者が「この人は面接で会えば可能性が見える」と思っても、現場から「経験が足りない」と却下される。逆に、現場が「この人は優秀だ」と言っても、採用担当から見ると「当社のカルチャーと合わないのでは」。
この温度差は、「何をMustとし、何をWantとするか」が採用担当と現場の間で合意されていないことが原因です。Step 3でMust/Wantを明確に分類し、現場マネージャーと合意しておけば、この問題は解消されます。
場面3: 採用基準のPDCAが回り始める
構造化された基準があれば、「この基準が正しかったか」を検証できます。
- 「Must要件を満たして入社したが、半年で離職」→ 見落としていたコンピテンシーがあるのでは？
- 「Wantだった要件を持つ人の方が、活躍している」→ そのWantは実はMustでは？
- 「NGとしていた要件に該当する人が、実は活躍している」→ NG要件を見直すべきでは？
このフィードバックループがあるからこそ、基準が「固定のチェックリスト」ではなく「育つフレームワーク」になるのです。
導入の進め方 —— 1ポジションから始める
Week 1: 基準の設計（2時間）
| やること | 所要時間 | アウトプット |
|---|---|---|
| 対象ポジションを1つ選ぶ | 5分 | ポジション名 |
| Step 1-2を現場マネージャーと実施 | 45分 | 背景・6ヶ月後の成果 |
| Step 3でMust/Want/NGを分類 | 30分 | 要件分類表 |
| Step 4で抽象要件を分解 | 30分 | 観察可能行動リスト |
| Step 5で役割分担を決める | 10分 | 役割分担表 |
Week 2-3: 実務で試す
- 次の応募者から、構造化した基準で書類選考を実施
- 「面接で確認すべきこと」を面接官に引き継ぐ
- 面接官から「基準が実務で使えたか」のフィードバックを集める
Week 4: 振り返りと改善
- Must/Wantの線引きが適切だったか検証
- 「この観察行動では判断しづらかった」要件を改善
- 他ポジションへの展開を検討
採用基準設計チェックリスト
背景・要件
- 「なぜこの採用が必要か」が事業目標と接続されている
- 入社後6ヶ月の具体的な成果が定義されている
- 現場マネージャーと合意が取れている
構造化
- 全要件がMust/Want/NGに分類されている
- Mustは3個以内に絞られている
- 抽象的な要件が観察可能な行動に分解されている
- 各要件に「判断基準」が明記されている
役割分担
- 「書類で確認」「面接で確認」の分担が決まっている
- 書類選考の引き継ぎに「面接で確認すべきこと」が含まれている
- 面接官が「何を重点的に確認するか」を事前に把握できる
運用
- 四半期ごとにMust/Wantの見直しが予定されている
- 入社後のパフォーマンスと採用基準の照合が計画されている
まとめ —— 「いい人が来たら採る」から「基準を先に決める」へ
採用基準は「チェックリスト」ではありません。「いい人が来たら採る」をやめ、「どんな人を採るかを先に決める」ためのフレームワークです。
| ステップ | やること | 得られる効果 |
|---|---|---|
| Step 1 | 「なぜこの採用が必要か」を言語化 | 採用の目的が明確になる |
| Step 2 | 入社6ヶ月後の成果を具体化 | 「どんな人か」が自然に導出される |
| Step 3 | Must/Want/NGに分類 | 判断の優先順位が統一される |
| Step 4 | 抽象要件を観察可能な行動に分解 | 担当者間で基準の意味が揃う |
| Step 5 | 書類と面接の役割分担を決める | 書類→面接が分断されず、情報が積み上がる |
まずは1つのポジションで、この5ステップを試してみてください。 2時間あればできます。それだけで、「いい人が来たら採る」から「基準を先に決める」への転換が始まります。
Tasonal AI書類選考は、この5ステップで設計した採用基準を、AIがそのまま選考に適用します。Must/Want/NGを構造化し、全候補者を同じ基準でスコアリング。「面接で確認すべきこと」まで自動生成し、基準→書類選考→面接の一貫性を仕組みで実現します。
