人材要件定義の作り方｜「求める人物像」を採用基準に変換するフレームワーク
はじめに —— 「求める人物像」が曖昧なまま採用を進めるリスク
「コミュニケーション力があり、主体的に行動できる方」——この要件で書類選考をしたら、ほとんどの候補者が同じ評価になる。
これは極端な例ではない。実際に多くの企業の求人票や採用要件には、こうした「誰にでも当てはまる」表現が並んでいる。その結果、以下の問題が連鎖的に発生する。
| 問題 | 具体的な症状 |
|---|---|
| 書類選考がブレる | 担当者Aは通過、担当者Bは不合格。同じ候補者なのに |
| 面接で何を聞けばいいかわからない | 要件が曖昧なので、評価軸が定まらない |
| 採用したのにミスマッチ | 「思ってたのと違う」が入社3ヶ月で発覚 |
| 現場と人事の認識がずれる | 「こんな人がほしいんじゃない」と現場からクレーム |
これらの問題はすべて、人材要件定義が曖昧なまま採用プロセスが走り出していることに起因する。
本記事では、事業戦略から採用基準までを一貫して設計する「4層変換フレームワーク」を紹介する。
なぜ要件定義がスキップされるのか —— 3つの構造的原因
人材要件定義が重要だと言われながら、多くの企業でスキップされている。その原因は3つある。
原因1: 「求める人物像」が要件定義だと思っている
多くの企業が「求める人物像」を書いて、要件定義を完了したと考えている。しかし「忍耐力があり、学習意欲の高い人」といった表現は、要件ではなく感想だ。
| 感想（曖昧） | 要件（具体的） |
|---|---|
| コミュニケーション力がある | クライアントへの提案書作成・プレゼン経験が。3年以上ある |
| リーダーシップがある | 3名以上のチームを率いた経験がある |
| 忍耐力がある | 半年以上のプロジェクトを完遍させた実績がある |
| 主体的に動ける | 自分で課題を特定し、解決策を提案したエピソードがある |
原因2: 要件定義の「担当者」がいない
事業戦略は経営層が決める。JDは採用担当が書く。しかし「事業戦略を採用要件に翻訳する」役割は、誰が担っているか曖昧なことが多い。
結果、経営層が「こういう人がほしい」と言う→採用担当がそのままJDに書く→現場が「この人、うちに合わないんだけど」と言う——このたらい回しが起きる。
原因3: 「早く募集を出したい」圧力
人員不足の現場から「早く採用してほしい」と急かされると、要件定義に時間をかける余裕がなくなる。しかし要件が曖昧なまま募集を出すと、ミスマッチ採用→早期離職→再募集という悪循環に陥る。
要件定義に2週間かけることで、後工程の手戻りを1〜2ヶ月削減できる。「急がば回れ」という原則が、採用要件定義でも当てはまる。
4層変換フレームワーク —— 事業戦略→要件定義→JD→選考基準
人材要件定義は、事業戦略から選考基準までの「変換プロセス」の一部だ。全体は4つの層で構成される。
第1層: 事業戦略
「来期は東南アジア市場に展開する」
↓ 変換① 「組織課題の特定」
第2層: 人材要件定義
「東南アジアの商習慣に精通し、現地パートナーとのJV交渉ができる人材」
↓ 変換② 「具体的なスキル・経験への翻訳」
第3層: JD（職務記述書）
「Must: 海外事業開発5年以上、英語ビジネス交渉レベル、JV組成経験」
↓ 変換③ 「選考で観察可能な行動への転換」
第4層: 選考基準
「書類: 海外事業経験を定量確認。面接: 交渉シナリオで行動を観察」
ほとんどの企業が第1層から直接第3層にジャンプしている。「東南アジアに展開するから、海外経験のある人を採ろう」——これが「変換ロス」だ。第2層の「具体的にどんな能力が必要か」という翻訳が欠落している。
各層の変換で確認すべきこと
| 変換 | 確認すべき問い | 変換ロスが起きるサイン |
|---|---|---|
| ① 戦略→要件 | この戦略を実行するために、今の組織に何が足りないか？ | 「良い人がほしい」としか言えない |
| ② 要件→JD | この能力を持つ人は、どんな経歴・スキルを持っているか？ | 要件とJDの表現が一致しない |
| ③ JD→選考基準 | JDの各項目を、書類・面接でどう確認するか？ | JDに書いてあることが選考で確認されない |
人材要件定義の設計手順 —— 5つのステップ
Step 1: 事業戦略から「組織課題」を特定する
「どんな人がほしいか」ではなく、「今の組織に何が足りないか」から始める。
| 事業戦略 | 組織課題 | 必要な能力 |
|---|---|---|
| 東南アジア市場への展開 | 現地パートナーとの交渉ができる人材がいない | クロスボーダー交渉力、現地商習慣の理解 |
| プロダクトのAI化推進 | MLエンジニアが0人 | 機械学習モデルの設計・実装・運用経験 |
| エンタープライズ営業の強化 | 大企業への提案型営業ができない | ソリューション営業、複雑な意思決定プロセスのナビゲート |
Step 2: 「能力」を「観察可能な行動」に分解する
抽象的な能力を、書類や面接で確認できる具体的な行動に変換する。
| 抽象的な能力 | 観察可能な行動（書類） | 観察可能な行動（面接） |
|---|---|---|
| クロスボーダー交渉力 | 海外企業とのJV・提携実績が職務経歴にある | 「文化の違いで困った場面とその解決策」を具体的に語れる |
| MLエンジニアリング | 本番モデルの設計・デプロイ経験がある | 「過去のモデル選定でのトレードオフ判断」を説明できる |
| ソリューション営業 | 提案型営業での受注実績・単価 | 「顯客の課題を探り、提案につなげたプロセス」を説明できる |
Step 3: Must / Want / NG に分類する
分解した行動を、必須・歓迎・不可の3層に分類する。これが後工程（JD・選考基準）の土台になる。
例: 海外事業開発ポジション
| 分類 | 要件 | 確認方法 |
|---|---|---|
| Must | 海外事業開発経験5年以上 | 書類（職務経歴書） |
| Must | 英語ビジネス交渉レベル（TOEIC 800+相当） | 書類 + 面接（英語での質問） |
| Must | JVまたは提携交渉の実績 | 書類 + 面接（シナリオ質問） |
| Want | 東南アジア市場の経験 | 書類 |
| Want | 現地法規制の知識 | 面接（具体事例を確認） |
| NG | 海外経験が出張ベースのみ（駐在なし） | 書類 |
| NG | 個人プレーでの成果のみ（チーム運営経験なし） | 書類 + 面接 |
Step 4: 現場との擦り合わせを行う
要件定義は人事部門だけで完成させない。現場マネージャーとの擦り合わせが必須だ。
以下の質問を現場に投げかける。
| カテゴリ | 質問例 |
|---|---|
| 業務内容 | このポジションの人が入社1週目にやる仕事は何ですか？ |
| 成功基準 | 「この人は当たりだ」と思うのは、どんな行動を見たときですか？ |
| 失敗基準 | 過去に「この人は合わなかった」と感じた人の特徴は？ |
| チーム構成 | 今のチームに足りないスキル・経験は何ですか？ |
Step 5: 要件の重み付けを行う
Mustが多すぎると候補者が見つからない。Mustを絞り込み、Wantに重み付けをする。
| Must数 | 判定 | 対応 |
|---|---|---|
| 7以上 | 多すぎる | 「これがないと業務が回らない」ものだけにMustを絞る |
| 4〒6 | 適正 | そのまま進行 |
| 3以下 | 緒すぎるかも | 「あれば尚良」が実はMustではないか確認 |
Wantの重み付け例:
| Want | 重み | 理由 |
|---|---|---|
| 東南アジア市場の経験 | ×3 | 即戦力度に直結 |
| 現地法規制の知識 | ×2 | 入社後にキャッチアップ可能 |
| MBA保有 | ×1 | あれば良いが必須ではない |
Must/Want/NGへの落とし込み方 —— 実践ワークシート
以下のワークシートを埋めることで、要件定義から選考基準までを一貫して設計できる。
| # | 分類 | 要件 | 観察可能な行動 | 確認フェーズ | 重み |
|---|---|---|---|---|---|
| 1 | Must | 書類 / 面接 | — | ||
| 2 | Must | 書類 / 面接 | — | ||
| 3 | Must | 書類 / 面接 | — | ||
| 4 | Want | 書類 / 面接 | ×1〜3 | ||
| 5 | Want | 書類 / 面接 | ×1〜3 | ||
| 6 | NG | 書類 / 面接 | — |
職種別の記入例
エンジニア採用の場合:
| # | 分類 | 要件 | 観察可能な行動 | 確認フェーズ | 重み |
|---|---|---|---|---|---|
| 1 | Must | Pythonでの開発経験3年以上 | 職務経歴書にプロジェクト実績がある | 書類 | — |
| 2 | Must | API設計・実装経験 | 「API設計でのトレードオフ判断」を説明できる | 面接 | — |
| 3 | Must | チーム開発の経験 | PRレビュー・設計議論の実績がある | 書類 + 面接 | — |
| 4 | Want | インフラ構築経験 | Terraform/Kubernetesの実務経験 | 書類 | ×3 |
| 5 | Want | OSSコントリビュート | GitHubアカウントに実績がある | 書類 | ×1 |
| 6 | NG | 受託開発のみの経験 | 自社プロダクトの経験がない | 書類 | — |
営業採用の場合:
| # | 分類 | 要件 | 観察可能な行動 | 確認フェーズ | 重み |
|---|---|---|---|---|---|
| 1 | Must | 法人営業経験3年以上 | 職務経歴書に担当領域・実績がある | 書類 | — |
| 2 | Must | 提案型営業の経験 | 「顯客の課題を探り、提案につなげたプロセス」を具体的に語れる | 面接 | — |
| 3 | Must | 年間売上5,000万円以上の実績 | 具体的な数字で実績を語れる | 書類 + 面接 | — |
| 4 | Want | SaaS営業経験 | サブスクリプションモデルの理解 | 面接 | ×3 |
| 5 | Want | HR業界の知識 | 採用課題を自分の言葉で語れる | 面接 | ×2 |
| 6 | NG | 個人向け営業のみの経験 | 法人営業の経験がない | 書類 | — |
要件定義のよくある失敗パターン5つ
| # | 失敗パターン | 症状 | 対策 |
|---|---|---|---|
| 1 | スーパーマン要件 | Mustが10個以上。全条件を満たす人が存在しない | Mustを3〜5に絞り、残りはWantに移動 |
| 2 | コピーペースト要件 | 前任者のスキルセットをそのまま要件にした | 前任者の「成果」を分解し、必要な能力を再定義 |
| 3 | 感覚要件 | 「話が合いそうな人」「カルチャーフィット」等の曖昧表現 | 行動で定義する。「カルチャーフィット」=「チームでの意見対立時に合意形成できる」等 |
| 4 | 現場不在要件 | 人事部門だけで要件を決め、現場に確認していない | Step 4の現場擦り合わせを必ず実施 |
| 5 | 固定化要件 | 1年前の要件をそのまま使い回している | 採用結果のフィードバックで毎回更新する |
採用ミスマッチを構造的に防ぐ —— 要件定義×選考連携の設計
要件定義が終わったら、それをJDと選考基準に正しく変換する必要がある。この変換が雑だと、せっかくの要件定義が無駄になる。
要件定義→JDの変換
要件定義で決めた内容を、JDの各セクションに展開する。
| 要件定義の内容 | JDでの表現先 |
|---|---|
| 組織課題・ポジションの背景 | JDの「募集背景」セクション |
| Must要件 | JDの「必須条件」 |
| Want要件 | JDの「歓迎条件」 |
| 観察可能な行動 | JDの「業務内容」で具体的に記述 |
| NG要件 | JDには明示しないが、選考基準として共有 |
詳しいJDの書き方については、「ジョブディスクリプションの書き方」で解説している。
要件定義→選考基準の変換
Must/Want/NGの各項目を、書類選考と面接で具体的にどう確認するかを設計する。
| 要件 | 書類選考での確認方法 | 面接での確認方法 |
|---|---|---|
| 海外事業開発5年以上 | 職務経歴書の年数を定量確認 | — |
| JV交渉実績 | 「提携」「合弁」等のキーワードを確認 | 「最も難航した交渉とその解決策」を質問 |
| 英語ビジネス交渉レベル | TOEICスコアまたは相当の実績 | 面接の一部を英語で実施 |
書類選考基準の構造化については、「書類選考基準の構造化フレームワーク」で詳しく解説している。
変換ロス診断チェックリスト
自社の要件定義プロセスに「変換ロス」がどの程度あるか、以下のチェックリストで診断してみてほしい。
| # | チェック項目 | Yes / No |
|---|---|---|
| 1 | 採用の背景にある事業戦略を、1文で説明できる | □ |
| 2 | 「今の組織に何が足りないか」を具体的に列挙できる | □ |
| 3 | Must要件が5つ以内に絞られている | □ |
| 4 | 各Mustが「観察可能な行動」で定義されている | □ |
| 5 | Wantに重み付けがされている | □ |
| 6 | NG要件（絶対に採りたくない人の特徴）が明確 | □ |
| 7 | 現場マネージャーと要件の擦り合わせを行った | □ |
| 8 | JDの各項目が要件定義のどれかに対応している | □ |
| 9 | 書類選考・面接で「何を見るか」が具体的に決まっている | □ |
| 10 | 過去の採用結果を踏まえて要件を更新している | □ |
診断結果:
| Yesの数 | 判定 | 推奨アクション |
|---|---|---|
| 8〜10 | 良好 | 定期的な見直しだけでOK |
| 5〒7 | 要改善 | 「変換①」からやり直す。現場との擦り合わせを追加 |
| 0〒4 | 要再設計 | Step 1から始め直す。現行のJDも書き直し |
まとめ
採用ミスマッチの多くは、選考の問題ではなく要件定義の欠落に起因する。
- 4層変換フレームワーク（事業戦略→要件定義→JD→選考基準）で、変換ロスを防ぐ
- 「感想」を「要件」に変換する——観察可能な行動で定義する
- Mustを3〜5に絞り、Wantに重み付けをする
- 現場との擦り合わせを必ず行う
- 採用結果のフィードバックで、要件を継続的に更新する
要件定義に2週間かけることは、「時間のロス」ではなく「後工程の手戻りを1〜2ヶ月削減する投資」だ。
Tasonalは、人材要件定義をMust/Want/NGの構造で設計し、AIが書類選考スコアリングに自動反映する採用プラットフォームです。選考を重ねるほどフィードバック学習で精度が上がり、「自社専用の選考基準」に育っていきます。
