コンピテンシー評価を採用で使いこなす方法｜書類選考→面接を一気通貫で設計する
はじめに —— 「コンピテンシー評価」は人事評価の話ではない
「コンピテンシー評価」と聞くと、多くの人事担当者は人事評価制度を思い浮かべます。MBOと並ぶ評価手法として、既存社員のパフォーマンス評価で使われるもの、と。
しかし、コンピテンシー評価が本当に威力を発揮するのは採用選考の場面です。
なぜか。採用選考には、人事評価にはない特有の難しさがあるからです。
| 人事評価 | 採用選考 | |
|---|---|---|
| 評価対象 | 日常業務のパフォーマンスを観察できる | 職務経歴書と数回の面接でしか判断できない |
| 評価期間 | 半年〜1年の蓄積がある | 書類は数分、面接は数十分で判断する |
| 情報の質 | 実際の行動を直接見ている | 候補者の自己申告がベース |
| やり直し | 評価期間ごとに修正できる | 採用は一回の判断で決まる |
限られた時間と情報で判断しなければならない。だからこそ、「何を見るか」の設計が採用の質を左右します。
そして多くの企業で起きているのは、この設計が欠落した状態での選考です。
「経験3年以上」「コミュニケーション力」「リーダーシップ」——こうした抽象的な要件を並べ、担当者ごとに異なる解釈で判断している。結果として、同じ候補者に対してAさんは「通過」、Bさんは「不通過」の判断を出す。
コンピテンシー評価は、この「解釈のブレ」を構造的に解消するフレームワークです。
この記事では、コンピテンシー評価を採用選考に導入する方法に特化して解説します。書類選考でのスクリーニングから面接での深掘りまで、一気通貫で使える設計を紹介します。
コンピテンシーとは何か——採用における定義
まず、採用選考の文脈でのコンピテンシーを定義します。
一般的な定義と、採用での再定義
一般的にコンピテンシーは「高い成果を生み出す行動特性」と定義されます。しかし採用選考では、もう少し実用的に捉えた方が使いやすい。
採用におけるコンピテンシー = 「このポジションで成果を出すために必要な、観察可能な行動パターン」
ポイントは3つです。
| ポイント | 説明 | なぜ重要か |
|---|---|---|
| ポジション固有 | 全社共通ではなく、ポジションごとに異なる | エンジニアと営業では「問題解決力」の意味が違う |
| 成果に紐づく | 「良い人」ではなく「成果を出す人」の行動パターン | 採用の目的は成果を出す人を見つけること |
| 観察可能 | 「ポテンシャル」ではなく「過去の行動」で測る | 書類と面接で確認できるものに限定する |
スキルとコンピテンシーの違い
混同されがちですが、スキルとコンピテンシーは別物です。
| スキル | コンピテンシー | |
|---|---|---|
| 定義 | 特定の技術・知識 | 成果につながる行動パターン |
| 例 | Go言語、AWS、SQL | 曖昧な要件を構造化して推進する、チーム内の対立を解消する |
| 測り方 | 経験年数、資格、テスト | 過去の行動エピソード（STAR法） |
| 書類での確認 | 比較的容易 | 難しい（面接が主な確認手段） |
| 育成可能性 | 比較的短期で習得可能 | 長期間かかる（行動習慣の変容） |
採用選考でコンピテンシーが重要な理由：スキルは入社後に育成できるが、コンピテンシー（行動パターン）は容易に変わらない。つまり、採用時にコンピテンシーを見極められるかどうかが、入社後の成果を最も左右するのです。
採用でコンピテンシーを使う4ステップ
では、具体的にどう採用選考に組み込むか。以下の4ステップで設計します。
Step 1: ポジションのコンピテンシーを定義する
↓
Step 2: 書類選考での確認方法を設計する
↓
Step 3: 面接での深掘り質問を設計する
↓
Step 4: 書類→面接の一貫評価を設計する
Step 1: ポジションのコンピテンシーを定義する
コンピテンシーの定義は、以下の手順で行います。
1-1. 「このポジションで成果を出す人」の行動を洗い出す
過去に同じポジションで成果を出した人（ハイパフォーマー）の行動パターンを分析します。いなければ、「理想の人材がいたらどう行動するか」を現場マネージャーと議論します。
洗い出しの問い：
- このポジションで「できる人」と「普通の人」の違いはどこに出るか？
- 入社後6ヶ月で「この人を採ってよかった」と感じるのはどんな場面か？
- 逆に「この人は合わなかった」と感じた過去のケースは何が原因だったか？
1-2. コンピテンシーを5〜7個に絞る
洗い出した行動パターンをグルーピングし、5〜7個のコンピテンシーに集約します。多すぎると評価が散漫になり、少なすぎると見極めが不十分になります。
1-3. 各コンピテンシーをレベル定義する
各コンピテンシーに、5段階のレベル定義をつけます。これが後のスコアリング基準になります。
コンピテンシー定義テンプレート（例：バックエンドエンジニア）
| # | コンピテンシー | 定義 | Must/Want | 重み |
|---|---|---|---|---|
| 1 | 技術的課題解決力 | 曖昧な要件や未知の技術課題に対し、問題を構造化して解決策を導き出す力 | Must | 25% |
| 2 | 設計判断力 | トレードオフを理解した上で、チームが納得する設計判断を下せる力 | Must | 20% |
| 3 | 協働推進力 | コードレビュー・ペアプロ・議論を通じて、チーム全体のアウトプット品質を高める力 | Must | 20% |
| 4 | 自律的学習力 | 新技術や未経験領域に対して、自ら学び業務に適用できる力 | Want | 15% |
| 5 | プロダクト志向 | 技術をプロダクト価値に結びつけて考え、ユーザー影響を意識した判断ができる力 | Want | 10% |
| 6 | 不確実性耐性 | 要件や優先順位が変わる環境で、柔軟に対応しながら前進できる力 | Want | 10% |
レベル定義の例（「技術的課題解決力」）：
| レベル | 定義 | 書類での判断ヒント | 面接での判断ヒント |
|---|---|---|---|
| 5 卓越 | 組織横断の技術課題を特定し、複数の解決策を比較検討した上で最適解を実装。後続の設計指針にもなる | 「社内技術基盤の刷新をリード」等の記載 | 構造化された問題分析と複数案の比較を自発的に語る |
| 4 優秀 | チームレベルの技術課題に対し、根本原因を特定して適切な解決策を実行する | 「パフォーマンス問題を調査・解決」等の定量成果記載 | 原因分析のプロセスを論理的に説明できる |
| 3 標準 | 定義された課題に対し、適切な技術的アプローチで解決する | 一般的な開発経験の記載 | 質問に対して具体的なエピソードを答えられる |
| 2 発展途上 | 技術課題は認識できるが、解決策の立案にサポートが必要 | 経験の記載が曖昧、具体性に欠ける | エピソードが表面的、深掘りに耐えられない |
| 1 不十分 | 技術課題の認識自体が不十分 | 関連経験の記載がない | 具体的なエピソードが出ない |
Step 2: 書類選考での確認方法を設計する
コンピテンシーの多くは面接で確認するものですが、書類の段階でも一定の推定は可能です。
ポイントは、コンピテンシーごとに「書類で何が分かるか」「面接で何を確認すべきか」を明確に分けることです。
| コンピテンシー | 書類で推定できること | 書類だけでは分からないこと |
|---|---|---|
| 技術的課題解決力 | 取り組んだ課題の規模・複雑さ、定量的な成果 | 問題分析のプロセス、思考の深さ |
| 設計判断力 | アーキテクチャ経験の有無、技術選定の記載 | トレードオフの判断プロセス |
| 協働推進力 | チーム規模、コードレビュー言及の有無 | 実際のコミュニケーションスタイル |
| 自律的学習力 | 新技術の採用経験、OSS活動、副業での技術探索 | 学習の動機と深さ |
| プロダクト志向 | ユーザー影響に言及した成果記述 | プロダクト思考のプロセス |
| 不確実性耐性 | スタートアップ経験、新規事業立ち上げ経験 | 実際のストレス対処法 |
書類選考スコアリングシート
書類選考の段階では、各コンピテンシーを「推定レベル」としてスコアリングします。
候補者名: ________
ポジション: ________
評価日: ________
| # | コンピテンシー | 推定レベル (1-5) | 根拠（書類のどこから判断したか） | 面接で確認すべきこと |
|---|-------------|:--------------:|---------------------------|------------------|
| 1 | 技術的課題解決力 | | | |
| 2 | 設計判断力 | | | |
| 3 | 協働推進力 | | | |
| 4 | 自律的学習力 | | | |
| 5 | プロダクト志向 | | | |
| 6 | 不確実性耐性 | | | |
Must項目（#1-3）の推定レベルがすべて3以上 → 面接に進める
Must項目に2以下がある → 不通過（理由を明記）
Want項目は加点として記録
総合所見:
面接官への引き継ぎ事項:
重要なのは「面接で確認すべきこと」の欄です。これが書類選考→面接の引き継ぎの核になります。「書類では推定レベル3だが、実際の深さは面接で確認が必要」「OSSコントリビュートの記載があるが、動機と学習プロセスを深掘りしたい」——こうした引き継ぎが面接の質を大きく変えます。
Step 3: 面接での深掘り質問を設計する
面接では、書類で推定したコンピテンシーレベルを実際の行動エピソードで検証します。
コンピテンシー別の質問設計
各コンピテンシーに対して、メイン質問（STAR法）と深掘り質問を用意します。
「技術的課題解決力」の質問設計：
| 質問タイプ | 質問例 | この質問で何を見るか |
|---|---|---|
| メイン | これまでに直面した、最も難しい技術的課題を教えてください。どのように解決しましたか？ | 課題の複雑さの認識、分析アプローチ、解決策の質 |
| 深掘り① | その問題をどう分析しましたか？最初に何を調べましたか？ | 問題の構造化能力 |
| 深掘り② | 他にどんな解決策を検討しましたか？なぜその方法を選びましたか？ | 複数案の比較・トレードオフ判断 |
| 深掘り③ | その解決策で想定外のことは起きましたか？どう対処しましたか？ | 不確実性への対応力 |
| 深掘り④ | その経験から、次に似た課題に直面したら何を変えますか？ | 振り返りと学習の深さ |
「協働推進力」の質問設計：
| 質問タイプ | 質問例 | この質問で何を見るか |
|---|---|---|
| メイン | チームで技術的な意見が割れた経験はありますか？どう進めましたか？ | 意見対立の解消スタイル |
| 深掘り① | 相手の主張のどこに理があると思いましたか？ | 他者の視点を理解する力 |
| 深掘り② | 最終的にどう合意しましたか？全員が納得しましたか？ | 合意形成のプロセス |
| 深掘り③ | コードレビューで、自分のコードに厳しいフィードバックをもらった経験は？ | フィードバック受容力 |
「プロダクト志向」の質問設計：
| 質問タイプ | 質問例 | この質問で何を見るか |
|---|---|---|
| メイン | 技術的な判断をする際に、ユーザーへの影響をどう考慮していますか？具体的なエピソードを教えてください | 技術とプロダクト価値の接続 |
| 深掘り① | その判断をするために、どんな情報を集めましたか？ | 情報収集の主体性 |
| 深掘り② | エンジニアとして「これは技術的に正しいが、ユーザーにとっては良くない」と感じた経験は？ | 技術とユーザー体験のトレードオフ判断 |
質問設計のルール
| ルール | 理由 |
|---|---|
| 過去の行動を聞く（「〜した経験は？」） | 仮定質問（「〜ならどうしますか？」）は理想論を引き出しやすい |
| 具体的なエピソードを求める | 「一般的にはこう考えます」ではなく「実際にこうしました」を聞く |
| 書類で確認済みの事項は聞かない | 候補者は「書類に書いたことをまた聞かれる」と不信感を持つ |
| 1つのコンピテンシーに集中する時間を確保 | 浅く広く聞くより、深く掘った方がレベル判定の精度が上がる |
Step 4: 書類→面接の一貫評価を設計する
ここが最も重要なステップです。書類選考と面接を同じコンピテンシー軸で一貫して評価する設計です。
一貫評価マトリクス
| コンピテンシー | 書類（推定レベル） | 面接（確定レベル） | 総合判断 |
|---|---|---|---|
| 技術的課題解決力 | 4（定量成果の記載あり） | 面接で深掘り | 書類の推定が正しいか検証 |
| 設計判断力 | 3（経験はあるが具体性不明） | 面接で重点確認 | 書類で分からなかった部分を埋める |
| 協働推進力 | 2（チーム開発の記載が薄い） | 面接で重点確認 | 推定が低い→面接で覆るか確認 |
| 自律的学習力 | 5（OSS活動が顕著） | 面接で動機を確認 | 高い推定の裏付けを取る |
この設計のポイント：
- 書類で推定レベルが低いコンピテンシー → 面接で重点的に確認（覆る可能性がある）
- 書類で推定レベルが高いコンピテンシー → 面接で裏付けを取る（過大評価でないか）
- 書類で判断できないコンピテンシー → 面接が唯一の確認機会
つまり、書類選考の評価結果が面接の設計を自動的に決める構造です。書類→面接が分断されず、一貫した評価軸の中で情報が積み上がっていく。
コンピテンシー評価で採用が変わる3つの場面
場面1: 「スペック外」の優秀人材を見逃さなくなる
従来の選考では、「Go経験3年」というスキル要件に満たない候補者は書類で落とされていました。しかしコンピテンシー軸で見ると、別の言語で高い「技術的課題解決力」を発揮している人材は、Go経験がなくてもポジションで活躍する可能性が高い。
スキル = 教えられる。コンピテンシー = 容易に変わらない。
「Go経験」はWant（入社後に習得可能）、「技術的課題解決力レベル4以上」はMust——こう設計すれば、スペック外だが本質的に優秀な人材を見逃さなくなります。
場面2: 面接官の「なんとなく合わない」がなくなる
面接官が「なんとなく合わない気がする」と感じたとき、コンピテンシー評価があれば「具体的にどのコンピテンシーが基準未達なのか」を明確にできます。
- 「なんとなく合わない」→ 判断として却下
- 「協働推進力がレベル2。チーム内の意見対立時に自分の意見を押し通すスタイルで、当社のコードレビュー文化と合わない」→ 根拠ある判断
場面3: 採用基準のPDCAが回り始める
入社後のパフォーマンスデータと採用時のコンピテンシー評価を照合すると、**「実際に活躍する人材のコンピテンシーパターン」**が見えてきます。
- 「技術的課題解決力がレベル5の人は活躍しているが、プロダクト志向がレベル2だと半年以内に離職する傾向」
- 「不確実性耐性がレベル4以上の人は、早期にチームにフィットしている」
こうしたデータが蓄積されると、コンピテンシーの定義と重み付け自体を改善できます。基準が「固定のチェックリスト」ではなく「育つフレームワーク」になるのです。
よくある失敗パターンと対策
コンピテンシー評価の導入でよくある失敗と、その回避策です。
| 失敗パターン | 何が起きるか | 対策 |
|---|---|---|
| コンピテンシーが多すぎる | 評価が散漫になり、結局「なんとなく」に戻る | 5〜7個に絞る。Must 3個 + Want 2〜4個が目安 |
| レベル定義が曖昧 | 「レベル3と4の違いが分からない」と面接官が困る | 各レベルに「具体的な行動の例」を書く |
| 全ポジション同じコンピテンシー | ポジションの特性が反映されない | ポジションごとにカスタマイズ。共通は2〜3個まで |
| 書類選考で無理にコンピテンシーを判定しようとする | 書類からは推定しかできないのに確定しようとして混乱 | 書類は「推定」、面接で「確定」と明確に分ける |
| 導入が大がかりすぎる | 全ポジション一斉に導入しようとして頓挫 | 1ポジションで試し、効果を確認してから展開 |
導入の進め方——1ポジションから始める
Week 1: コンピテンシーの定義（2時間）
- 対象ポジションを1つ選ぶ（最も採用ボリュームが多い or 評価がブレている）
- 現場マネージャーと採用担当者で「成果を出す人の行動パターン」を洗い出す
- 5〜7個のコンピテンシーに集約し、Must/Wantを決める
- 各コンピテンシーの5段階レベル定義を作成する
Week 2-3: 書類選考で試す（実務の中で）
- 書類選考スコアリングシートを使って、次の応募者から試す
- 特に「面接で確認すべきこと」の欄を意識して記入する
- 面接官に引き継ぎ資料として渡す
Week 4: 面接での効果を検証
- 面接官に「引き継ぎ情報は役に立ったか」をヒアリング
- 書類の推定レベルと面接での確定レベルの乖離を分析
- 乖離が大きいコンピテンシーの「書類での判断ヒント」を改善
Month 2〜: 他ポジションに展開
- テンプレートを使い、ポジション別にカスタマイズ
- 四半期ごとにコンピテンシーの定義と重み付けをレビュー
まとめ —— 「何を見るか」を設計することが、採用の質を決める
コンピテンシー評価は、人事評価制度のための仕組みではありません。採用選考で「何を見るか」を構造化し、書類から面接まで一貫した基準で判断するためのフレームワークです。
| やるべきこと | 得られる効果 |
|---|---|
| ポジションごとにコンピテンシーを5〜7個定義する | 「何を見るか」が明確になり、評価ブレが減る |
| Must/Wantと重み付けを設定する | 判断の優先順位が統一される |
| 書類で推定し、面接で確定する設計にする | 書類→面接が分断されず、情報が積み上がる |
| 書類選考の引き継ぎに「面接で確認すべきこと」を含める | 面接の質が向上し、候補者体験も改善される |
| 入社後データと照合してコンピテンシーを改善する | 基準が「育つフレームワーク」になる |
まずは1つのポジションで、コンピテンシーを5〜7個定義するところから始めてみてください。 それだけで、書類選考の判断に「根拠」が生まれ、面接官との共通言語ができます。
Tasonal AI書類選考は、コンピテンシーを含む評価項目を構造化し、AIが全候補者を同じ基準でスコアリングします。各候補者の強み・懸念点・面接で確認すべきポイントを自動抽出し、面接官への引き継ぎまでシームレスに。判断は人がする。AIはその判断材料を揃えます。
