エンジニア採用KPIの設計｜職種別ファネルと現場工数の見方

エンジニア採用KPIを応募数だけにすると、数字は増えても開発計画に必要な人が採れているか分かりません。バックエンド、フロントエンド、SRE、EMでは対象者も選考工程も違います。全職種を一つのファネルへ混ぜれば、どこを直すべきか見えなくなります。

僕なら、採用する役割、人数、期限から職種別に逆算します。その上で、CTO・VPoE・EM・採用担当者が毎週変えられる指標と、承諾や入社の結果指標を分けます。KPIは担当者を評価する点数ではなく、技術組織が次の判断を早くする共通言語です。

エンジニア職種と入社期限からファネルを逆算する

最初に職種ごとの採用理由を決めます。「エンジニア三名」ではなく、決済APIの開発を担うバックエンド一名、Web体験を改善するフロントエンド一名、信頼性と運用を担うSRE一名と置きます。同じ三名でも、候補者層、採用経路、技術選考、現場面接官が違います。

入社希望日から、オファー、最終面接、技術面接、書類確認、応募や返信までを戻します。過去実績がある職種は自社データを使い、初採用のEMやSREは仮説として数字を置きます。外部相場を確定値にせず、一件ごとに反応と前提を記録して仮説を更新します。率を共有するときは母数と集計期間を必ず併記し、少数の結果を安定した基準として扱いません。

率と同時に日数を見ます。候補者数が十分でも、CTOの書類確認に四日、テックリードとの技術面接調整に七日かかれば、候補者の意思決定へ間に合いません。「書類通過率が低い」と「書類を見ていない」を分けるため、件数、率、滞留日数を並べます。

指標の定義も文章で残します。カジュアル面談を選考へ含めるか、技術課題の提出を技術面接の開始と数えるか、候補者辞退と会社不合格をどう分けるかを揃えます。採用媒体やATSごとに定義が違う場合は、元データを無理に合算しません。

経路別の応募率を比べる前に、求人情報の前提もそろえます。厚生労働省の求人等に関する情報の的確な表示では、虚偽または誤解を生じさせる表示を禁じています。職種名、仕事内容、就業場所、賃金などの条件が実態とずれたままでは、応募後の辞退を媒体の良し悪しだけで説明できません。エンジニア採用媒体の選び方と同じ職種・接点の単位で、求人内容とファネルを対応させます。

計画には面接可能枠も入れます。テックリード二名が週に技術面接を各一件しか持てないのに、毎週六名を通過させれば待ちが生まれます。必要な候補者数だけでなく、CTO、EM、面接官が使える時間を制約として逆算します。

結果KPIと今週動かせる先行KPIを分ける

入社、承諾、内定は重要な結果KPIですが、今週の行動だけでは変えられません。週次では、求人公開、書類確認の期限内完了、面接枠の確保、評価記録の回収など、社内が次週に変えられる先行KPIも見ます。

職種別の例を挙げます。バックエンドなら求人閲覧から応募への率と技術面接の通過理由、SREなら返信率とオンコール条件に関する質問、EMならカジュアル面談から選考への移行とCTO面接までの日数です。同じ応募数でも、職種が違えば見る前提と改善策が変わります。

技術選考には品質と速度の両方を置きます。面接設定までの日数、面接後二十四時間以内の評価記録率、面接官間で判定が割れた割合、課題採点に使った時間などです。通過率だけを目標にすると、難易度を上下させるだけで評価基準の曖昧さを見逃します。

合否理由は、応募者の印象ではなく職務遂行に必要な適性・能力と記録へ結びつけます。厚生労働省の公正な採用選考の基本も、適性・能力に基づく採用基準を基本としています。エンジニア採用スコアカードで期待成果と証拠を対応させ、エンジニア採用の面接評価基準に沿って質問の目的と評価記録をそろえると、通過率の変化を基準変更と候補者構成に分けて読めます。

先行指標を増やしすぎると入力が採用活動を圧迫します。各数字へ「悪化したら誰が何を変えるか」を書き、打ち手につながらないものは外します。たとえば評価記録の遅れならEMが期限とテンプレートを直し、技術面接の待ちならテックリードが面接官を増やすか工程を見直します。

週次会議で数字と技術選考の記録を一緒に読む

週次会議で全数字を読み上げる必要はありません。計画差が大きい職種と工程を一つ選び、先週決めた改善が実行されたかを確認します。数字だけで原因を決めず、候補者からの質問、辞退理由、面接官の評価記録を一緒に読みます。

たとえばSREの返信率が低い場合、対象者の問題と決めつけません。求人にオンコール頻度、障害対応の権限、現行の信頼性課題が書かれているかを確認します。バックエンドの技術面接後に辞退が多い場合は、課題の所要時間、面接で伝えた仕事内容、連絡速度を分けて見ます。

評価が割れた場合も「面接官の相性」で終えません。システム設計を見た人が、候補者の発言という事実と、自社水準に対する判断を分けて記録しているかを確認します。同じ記録をCTO、EM、テックリードで採点し、曖昧な評価項目を直します。

会議の最後には、次週に変える項目を一つか二つに絞ります。「EMがSRE求人のオンコール説明を金曜までに修正し、翌週の返信率と質問内容を見る」のように、担当者、期限、確認するKPIを一文で残します。複数施策を同時に変えると学びにくくなります。

月次レビューにはCTOやVPoEが参加し、職種の優先順位、採用期限、予算、開発現場の面接工数を確認します。応募を増やす前に面接枠を増やす、採用時期を変更する、バックエンドよりSREを優先するなど、採用担当者だけでは決められない事項を先送りしません。

KPIの所有者をCTO・EM・採用担当者へ分ける

採用担当者はファネルの更新と候補者体験、EMは技術要件と選考速度、CTOやVPoEは職種の優先順位と予算を持ちます。数字の所有者は、悪化の責任を負う人ではなく、数字を見て次の判断を提案する人です。

面接評価が戻らない場合、採用担当者へ催促だけを任せません。EMが評価期限を守る責任者となり、エンジニア面接官の工数、テンプレート、判定会議の時間を直します。採用課題を採用チームだけへ閉じないため、現場が制御できる指標を現場へ渡します。

数値の悪化を「候補者の質」で片づけないことも重要です。技術要件、求人内容、採用経路、選考速度のどこに差があるかを見ます。会社側が出した条件と選考体験を確認せず、候補者だけを原因にすると同じ詰まりが続きます。

目標値を変えるときは、変更者、日付、理由を記録します。EM採用の母数が仮説より少ないなら、達成しやすくするために数字を下げるのではなく、要件、期限、採用しない場合の代替案をCTOへ説明して更新します。変更前の値を残せば次の計画精度も上がります。

採用後も入社時点で表を閉じません。三か月後に、採用時に期待した責任と実際に渡せた仕事を振り返ります。技術選考で見た能力が業務へつながったか、要件が現実的だったかを確認し、次のバックエンドやSRE採用へ戻します。

まず現在のダッシュボードで職種を一つ選び、「この数字が悪化したら、CTO・EM・採用担当者の誰が何を変えるか」と書いてください。答えが出ない数字は報告用かもしれません。エンジニア採用KPIは、採用と開発現場の判断をつなぐために使います。

参考にした一次情報

• 厚生労働省「職業安定法に基づく周知｜労働者の募集広告の表示について」
• 厚生労働省「公正な採用選考の基本」