エンジニア採用のWin/Loss分析とは、内定承諾・辞退・不採用の結果を構造化データとして収集し、勝因と敗因を定量・定性の両面で振り返り、次の採用設計に反映する仕組みです。月1回・直近10〜20件のクロージング結果を分析するだけで、勝率の低い選考フェーズと競合企業が特定でき、求人票・面接設計・オファー条件のどこを直すべきかが具体的に決まります。

TL;DR（この記事の要約）

• Win/Loss分析は「個別の辞退案件への対症療法」ではなく、辞退・不採用パターンを構造化して採用設計の意思決定に活かす経営ツール

• 収集すべきデータは「結果（Win/Loss）」「ステージ（どこで負けたか）」「競合（誰に負けたか）」「理由（なぜ負けたか）」の4軸

• ヒアリング先は候補者本人だけでなく、推薦エージェント・社内面接官・採用担当の3者から多角的に取る

• 分析結果は月次の採用定例で共有し、求人票・スカウト文面・面接体験・オファー条件の改善に直接結びつける

• スプレッドシート1枚と月30分の振り返りから始められる。規模ではなく振り返りの密度が採用力を決める

1. Win/Loss分析がエンジニア採用に必要な理由

Win/Loss分析が必要なのは、個別案件をその場で振り返るだけでは構造的な問題が見えないからです。1件ごとの「年収で負けた」という感想を積み上げても、自社がどの候補者層のどのフェーズで負け続けているかは見えてきません。

データで見る：なぜ「負けの分析」が採用力を左右するのか

Win/Loss分析の価値は、採用市場の競争環境を数字で押さえると理解しやすくなります。

• 経済産業省「IT人材需給に関する調査」：2030年時点で最大約79万人のIT人材が不足すると試算

• 厚生労働省「一般職業紹介状況」（令和8年7月）：情報処理・通信技術者の有効求人倍率は1.50倍、全職業計は1.18倍

• doda「転職求人倍率レポート」（2026年8月）：全体2.86倍、前月差+0.15pt

注目すべきは、ハローワーク経由の全職業1.18倍に対して転職市場全体が2.86倍という乖離です。1人の候補者を約2.9件の求人が奪い合う市場では、候補者が複数オファーを持っている状態が標準になります。「負ける」ことが例外ではなく常態である以上、負けから学ぶ仕組みを持たない組織は同じ敗因を繰り返します。

辞退理由は3層に分解できる

私は採用コンサル営業を経て現在はエンジニアとして事業を運営しており、BizReach・Forkwell・Greenなど13サービス以上でスカウト運用を見てきました。その中で、辞退や不採用の理由は次の3層に分解できると考えています。

• 表層: 「年収」「リモート可否」「内定の早さ」といった候補者が口にする条件

• 中層: 面接体験・選考期間・面接官の質問内容といった選考プロセスの設計

• 深層: 求人ターゲットそのもののズレ、競合企業との立ち位置、自社の市場ポジション

表層だけ追っていると「年収を上げる」しか手段がなくなりますが、深層まで掘ると「そもそもこの候補者層には勝ち目がない」「求人票のメッセージが競合と被っている」といった戦略レベルの課題が見えてきます。Win/Loss分析は、この3層を行き来して採用戦略を更新する仕組みです。

私自身の失敗としては、辞退が続いた時期に求人票・スカウト文面・オファー基準を同時に変えてしまい、どの変更が効いたのか判別できなくなったことがあります。月次で変えるのは1〜2項目までに絞るのが、遠回りに見えて最短です。

Win/Loss分析と類似プロセスの違い

エンジニア採用には、いくつかの振り返りプロセスがあります。それぞれの位置づけを整理しておきます。

• 面接デブリーフ: 各候補者の合否を決める会議。個別案件の意思決定が目的（エンジニア採用の面接デブリーフ設計ガイド｜合否判定の精度を高める方法）

• エグジットインタビュー: 退職するエンジニアから採用・定着の課題を引き出す。在職中に同じ論点を先回りして聞く手法はエンジニアのステイインタビュー設計｜離職の予兆を掴む実践ガイドにまとめています

• Win/Loss分析: 採用結果（内定承諾・辞退・不採用）をデータとして集約し、採用設計を更新する

面接デブリーフは選考中の意思決定、エグジットインタビューは入社後の定着分析、Win/Loss分析はその間の選考結果から学ぶプロセスを担います。3つはセットで回すと採用力が体系的に強化されます。

Win/Loss分析を導入すると何が変わるか

採用支援を通じて見てきた中で、Win/Loss分析を回している組織には共通する変化が5つあります。

1. 打ち手が「年収を上げる」以外に増える：敗因が体験・スピード・訴求内容に分解され、報酬以外の改善余地が見つかる

2. スカウトの送り先が変わる：「とりあえず打つ」から、勝率の高い候補者層に絞った運用に変わる

3. 候補者体験が底上げされる：面接官の質問内容や雰囲気に具体的なフィードバックが返るため、選考体験が改善される

4. オファーの決裁が速くなる：過去の勝ち負けデータがあるため、金額の妥当性を議論する時間が短くなる

5. 経営層への説明材料が増える：採用予算や要件緩和の交渉に、感覚ではなく実績データを使えるようになる

逆に、辞退理由を「年収が他社より低かった」とだけ記録している組織は、永遠に「年収を上げてくれ」という議論しかできなくなります。

2. Win/Loss分析で集めるべきデータの4軸

Win/Loss分析の核は「データの構造化」です。バラバラのコメントを集めても、翌月に同じ切り口で比較できなければ傾向は見えません。次の4軸に固定して整理します。

軸1: 結果（Win / Loss / Draw）

シンプルですが定義が曖昧になりがちです。次の5分類で記録します。

1. Win：自社が内定を出し、候補者が承諾

2. Loss-Decline：自社が内定を出したが、候補者が辞退

3. Loss-Reject：自社が選考途中で見送り

4. Loss-Withdraw：候補者が選考途中で辞退

5. Draw：双方が次回機会を約束（タレントプール候補）

「不採用」と「辞退」をひとくくりにすると分析の意味が薄れます。自社判断で見送ったケース（Loss-Reject）は採用基準やソーシング設計の問題、候補者が離れたケース（Loss-Decline / Withdraw）は体験・オファー設計の問題と、改善対象が異なるからです。

軸2: ステージ（どのフェーズで結果が出たか）

選考プロセスのどこで結果が確定したかを記録します。

• スカウト送信→開封→返信

• カジュアル面談→一次面接→技術面接→最終面接

• オファー提示→オファー面談→承諾／辞退

承諾率をファネル全体で見ないと、「内定承諾率は上がったがそもそも内定数が減っていた」という見落としが起きます。

軸3: 競合（誰に負けたか）

辞退の場合は、競合先を可能な限り具体的に記録します。

• 競合企業名（業界・規模・フェーズも含めて）

• 競合のオファー条件（年収・リモート可否・役職・入社時期）

• 候補者が競合を選んだ決定要因（複数選択可）

競合企業を集計すると「勝ち相手・負け相手の傾向」が見え、自社が戦うべきレンジが明確になります。エンジニア採用では「同業他社」だけでなく「異業種の自社開発組織」「外資テック」「フリーランス独立」も競合です。

軸4: 理由（なぜその結果になったか）

候補者・面接官・採用担当の3者から見た理由を、複数のカテゴリで記録します。カテゴリは次の7分類に固定しておくと、月次の集計がそのまま比較可能になります。

1. 報酬・年収・株式報酬

2. 業務内容・技術スタック・プロダクト魅力度

3. 組織・カルチャー・チーム構成

4. 働き方・リモート・勤務地・労働時間

5. 選考体験・面接官の印象・選考スピード

6. ブランド・知名度・ミッション

7. タイミング・入社可能日・他社内定との関係

複数選択可にすると、表層理由と深層理由を両方拾えます。「年収が低かった」と「面接官の質問がふわっとしていた」が同時に出てきたとき、後者を放置すると年収を上げても辞退は続きます。

3. ヒアリング設計：誰に・いつ・どう聞くか

Win/Loss分析の品質は「データの取り方」で決まります。エンジニア採用では、3者にヒアリングするのが基本です。

候補者本人へのヒアリング

辞退・不採用のタイミングで、候補者本人に短いアンケートまたは口頭ヒアリングを実施します。設計のポイントは4つです。

1. タイミング：結果通知から3日以内（記憶が鮮明なうちに）

2. 形式：5〜10問のアンケート + 自由記述。長文インタビューは負担が大きいので避ける

3. 依頼者：採用担当ではなく、当日の面接官や採用責任者からの個別メッセージのほうが回答率が高い

4. インセンティブ：「次回機会への案内」「他社の選び方のフィードバック共有」などの非金銭的価値を提示

質問は次の4問を基本形にしてください。

1. 最終的に入社を決めた会社は、どの点が決め手でしたか（複数選択）

2. 当社の選考プロセスで「ここが良かった」「ここが残念だった」と感じた点があれば教えてください

3. もし入社を決めるとしたら、当社のどこが変われば検討余地がありましたか

4. 今後、当社から再度ご連絡してもよろしいですか

私がエンジニアとして転職活動した際に、辞退した企業から事務的な「今後のご活躍をお祈りします」メールしか来なかったとき、「ここは候補者を本気で見ていない」と感じました。逆に、面接官から個別に「お時間があれば率直にフィードバックをいただけますか」と来ると返したくなります。

推薦エージェントへのヒアリング

エージェント経由の候補者なら、エージェントが候補者から本音を聞いている可能性が高いです。

• 辞退理由を「企業に直接言いにくいこと」も含めてヒアリング

• 競合企業の提示条件（年収・タイトル・役割）を可能な範囲で確認

• エージェントから見て「当社のこの選考フローはこう改善した方がよい」という意見

エージェントは複数企業の選考プロセスを横断的に見ているので、自社では気づきにくい外部視点が得られます。月1回の定例MTGで30分でも時間を取ると、Win/Loss分析の質が一気に上がります。

社内面接官・採用担当へのヒアリング

社内側からの視点も忘れずに集めます。確認するのは次の3点です。

1. 面接官が「この候補者を取り逃したのが惜しい」と感じたか、それとも「合わなくて良かった」と感じたか

2. 採用担当が振り返って「ソーシング段階でズレがあった」と思うか

3. マネジメント側が「もしオファー条件をこう変えていたら違ったか」と感じるか

社内の認識と候補者の認識のズレを可視化することが、Win/Loss分析の最大の価値です。「自社は技術スタックで負けたと思っていたが、実は面接官の態度が決定打だった」というケースは珍しくありません。

4. 月次でWin/Loss分析を回す運用フロー

データを集めるだけでは意味がありません。振り返りを定例会議に組み込み、毎月必ず1〜2個の改善アクションを決めるところまでをセットにして、初めて分析が採用結果に接続します。

月次運用のステップ

1. データ収集（常時）: 結果が確定するたびに即時に記録。担当者の記憶が鮮明なうちが鉄則

2. 分類・集計（月末）: 4軸でデータを整理し、勝率・敗因カテゴリ別の集計を作成

3. 定例会議（月初）: 採用関係者で30〜60分の振り返り。経営層も同席が望ましい

4. 改善アクション決定: 求人票・スカウト文面・面接設計・オファー基準のどこを変えるかを決定

5. 次月のKPI設定: 「内定承諾率を5pt上げる」「ステージ別離脱率の改善」など具体的な数値目標

6. アクション実行・効果測定: 改善施策の効果を翌月のWin/Loss分析で確認

月次定例の進め方（60分版）

• 0〜10分: 前月の採用結果サマリ（Win/Loss件数・ステージ別・競合別）

• 10〜25分: 主要なLoss案件3〜5件のディープダイブ（候補者・エージェント・面接官の証言を突き合わせ）

• 25〜40分: パターン抽出（「最終面接で技術質問の深さが足りない」「年収レンジが市場+10%でも勝てない層がある」など）

• 40〜55分: 改善アクションの優先順位付け（求人票・スカウト・面接体験・オファー条件）

• 55〜60分: 次月までの宿題・担当者・期限の確認

30名未満の組織で回す最小構成

スタートアップや個人運営の採用組織なら、運用をさらにシンプルにできます。

• スプレッドシート1枚（候補者名・結果・ステージ・競合・理由カテゴリ・自由記述）

• 月次定例は採用責任者と現場マネージャー1人で30分

• 候補者ヒアリングは「次の候補者紹介のお礼を込めたカジュアル聞き取り」程度でOK

ボリュームが小さいうちは、構造化より「結果が出るたびに即記録」の習慣化が最優先です。10件で傾向が見え始めます。

5. 4軸データを採用設計に反映する具体策

集めた4軸データは、求人票・面接プロセス・オファー条件・ソーシング層という4つの打ち手に振り分けます。どのデータがどの打ち手に対応するかを決めておかないと、「分析はしたが何も変わらない」状態に陥ります。

求人票・スカウト文面への反映

候補者が「決め手」「魅力に欠けた点」として挙げた要素を、求人票・スカウト文面に明示します。

• 勝ち事例で挙がった魅力（例: 「PMが技術出身」「コードレビュー文化」）→ 求人票の冒頭で訴求

• 負け事例で挙がった懸念（例: 「リモート可否が不明瞭」）→ 求人票の働き方セクションで明文化

• 競合企業との比較で頻出する論点（例: 「メガベンチャーと比較される」）→ 自社が選ばれる理由を逆算

求人票の改善ポイントは「エンジニア採用の求人票の書き方｜応募が集まる職務記述書の設計」も参考にしてください。

面接プロセスの再設計

ステージ別の離脱率を見ると、改善箇所が特定できます。

• 一次面接で離脱が多い → カジュアル面談の魅力訴求が弱い、または一次面接の質問が候補者の関心と合っていない

• 技術面接で離脱が多い → ライブコーディングや課題の負担感、面接官のフィードバック品質

• 最終面接後の辞退が多い → クロージング設計、オファー条件、決裁スピードの問題

エンジニアがどのフェーズで何を見ているかは「エンジニア採用の選考フロー設計｜各フェーズで見るべき観点」を参照。

オファー条件の調整

Win案件・Loss案件の年収レンジを比較し、「勝てる年収帯」「勝てない年収帯」を特定します。

• 同じ職種でも、競合がメガベンチャーなら年収+15%、外資なら+30%が必要なケースがある

• 株式報酬・サインオンボーナス・リモート手当などの金銭以外の構成要素でも差別化可能

• 「年収が低くても勝てた」事例の共通点を分析すれば、報酬以外の決め手が見える

オファー設計の詳細は「エンジニア採用のオファー面談設計｜クロージングの実践ガイド」、複数オファー競合時の立ち回りは「エンジニア採用の複数オファー競合対策」を参照してください。

ソーシング層の見直し

負けが続く候補者層には、根本的なズレがある可能性があります。

• ハイレイヤー候補者で全敗 → 自社のブランドや技術スタックで勝負にならないレンジ

• 特定の技術スタック保持者で全敗 → 自社のスタックや業務内容にミスマッチ

• 外資出身者で全敗 → 報酬体系や評価制度の根本的な違い

「勝ち目のない層にスカウトを送り続けない」決断も、Win/Loss分析から導ける重要な意思決定です。

6. AI・スプレッドシートで分析を効率化する

Win/Loss分析は人手で回すと負担が大きいですが、AIとスプレッドシートで大幅に省力化できます。特に負担が重いのは自由記述コメントの分類で、ここはLLMに任せるだけで月次作業が数十分単位で短縮されます。

スプレッドシートでの基本テンプレート

• 列構成: 候補者ID / 応募経路 / ポジション / 結果 / 結果ステージ / 競合企業 / 競合オファー年収 / 当社オファー年収 / 理由カテゴリ（複数選択） / 自由記述 / 担当者

• 集計シート: ピボットテーブルで「結果×ステージ」「結果×競合」「結果×理由カテゴリ」のクロス集計

• ダッシュボード: 月次の勝率トレンド・主要敗因・競合企業ランキング

AIによる自由記述の構造化

エージェントや候補者からの自由記述コメントを、AIに分類させると効率が上がります。

• ChatGPT・Claudeなどに「次のコメントを、報酬／業務内容／カルチャー／選考体験／タイミングの5カテゴリに分類して」と依頼

• 月20件程度のコメントなら数分で構造化可能

• カテゴリ別の頻出キーワードを抽出すれば、傾向把握が一気に進む

私がスカウト運用代行の現場で実践している方法でもあります。AIを使えば個人運営でも大企業並みの分析品質が出せます。AI活用の詳細は「エンジニア採用のAIエージェント活用ガイド｜スカウトから選考までの実装術」を参照。

ATS・採用管理ツールとの連携

Greenhouse・Workable・HERPなどのATSを使っていれば、ステージ別データはすでに蓄積されています。Win/Loss分析専用のカスタムフィールド（競合企業・敗因カテゴリ）を追加するだけで、運用がスムーズになります。

ステージ別の転換率をどう読むかは「エンジニア採用の選考ファネル転換率改善ガイド」が参考になります。

7. Win/Loss分析を続けるための仕組み化

Win/Loss分析が失敗する最大の理由は、分析の質ではなく継続できないことです。3ヶ月続けると改善の手応えが見え始め、6ヶ月続くと採用組織の文化として定着します。続けるための仕組みを3つ紹介します。

心理的安全性の確保

Loss案件を共有するとき、「面接官の◯◯さんが悪かった」という個人攻撃にならない設計が重要です。

• 振り返りは「個人の責任」ではなく「プロセスの問題」として議論

• 失敗事例を出した担当者を称賛する文化（「課題を可視化してくれてありがとう」）

• 経営層が率先して「自分のオファー判断がズレていた」と認める姿勢

心理的安全性が低い組織では、辞退理由が「報酬」に集約されがちです。本音が出ない環境では、表層理由しか上がってきません。

KPIへの組み込み

採用責任者の評価指標に、Win/Loss分析の運用そのものを組み込みます。

• 月次レポートの提出率

• Loss案件の根本原因分析の実施率

• 改善アクションの実装率

• 内定承諾率の改善トレンド

「やったほうがいい」ではなく「やるのが当たり前」になる仕組みが、長期的な定着につながります。指標そのものの設計は「エンジニア採用の選考ファネル転換率改善ガイド」も参考にしてください。

経営層への可視化

経営層に毎月Win/Loss分析の結果を共有することで、採用予算・組織方針の意思決定が早くなります。

• 主要敗因と改善施策をワンページにまとめる

• 競合企業との戦況を地図化する

• 「今のオファー条件では勝てない層」を明示し、判断を仰ぐ

採用は経営課題です。Win/Loss分析を経営の会話に乗せることで、採用責任者の地位も上がります。

8. よくある失敗パターンと対策

Win/Loss分析を始めた組織がつまずくポイントは、ほぼ5パターンに収束します。いずれも設計段階で対策を決めておけば回避できるものです。

失敗1: 表層理由しか集まらない

「他社の年収が高かった」しか出てこない場合、ヒアリング設計に問題があります。

• 対策: アンケート質問を「決め手は何か」だけでなく「もし◯◯が違ったら検討余地はあったか」など仮定法で聞く

• 対策: エージェントや面接官からの視点を必ず追加する

失敗2: データが溜まらない

結果通知後すぐに記録しない・記録ルールが曖昧で、データが集まらないケース。

• 対策: ATSにカスタムフィールドを追加し、結果入力時に必須項目化

• 対策: 担当者の評価指標に「Win/Lossデータ入力率」を含める

失敗3: 分析しただけで何も変わらない

レポートは作るが、アクションに繋がらないパターン。

• 対策: 月次定例の最後に必ず「次月までに何を変えるか」を1〜3項目決める

• 対策: 改善アクションのオーナーと期限を明示する

失敗4: 短期で諦める

1〜2ヶ月でデータがバラついて諦めるケース。

• 対策: 最低3ヶ月、できれば6ヶ月は継続する前提でスタート

• 対策: 初期は「定着」だけを目標にし、改善効果は半年後に測る

失敗5: 競合分析と混同する

Win/Loss分析と競合分析（エンジニア採用の競合分析と差別化戦略）は別物です。

• 競合分析は事前に競合の動向を調べるプロセス

• Win/Loss分析は事後に自社の結果を振り返るプロセス

• 両者をセットで運用するのが理想

9. 個人運営・ひとり人事でもWin/Loss分析を回す方法

採用専任が1人、または社長兼採用担当という小さな組織でも、Win/Loss分析は十分に回せます。むしろ意思決定の経路が短いぶん、データから改善までのサイクルは大きな組織より速く回ります。

最小構成の運用フロー

• 採用候補者を1件追うたびに、結果・ステージ・競合・理由をスプレッドシートに即記入（所要時間1〜2分）

• 月末に過去1ヶ月分を見返し、敗因パターンを3つ書き出す（所要時間15〜30分）

• 翌月のアクションを1〜2個決める（求人票の書き換え、スカウト文の修正など）

• 半年経過したら、6ヶ月分のデータで傾向を再分析

特別なツールは不要です。継続することそのものが最大の差別化要因になります。

ひとり人事の強み

Win/Loss分析は、組織が大きいほど合議制で時間がかかります。ひとり人事の場合、

• 即決即実行が可能

• データ収集者と分析者と意思決定者が同一人物なので、情報の劣化がない

• 候補者ヒアリングも担当者個人として親密に行えるため、本音が引き出しやすい

私自身、個人事業として採用支援を運営する中で、毎週のWin/Loss振り返りを習慣化しています。規模ではなく、振り返りの密度が採用力を決めます。

ひとり人事の運用ノウハウは「ひとり人事のエンジニア採用ガイド｜限られたリソースで成果を出す方法」も参考にしてください。

10. Win/Loss分析を立ち上げる90日ロードマップ

「まず全件記録する」と決めずに始めると、ほぼ2ヶ月目で止まります。記録項目を最小限に絞り、90日で1周させる設計にしてください。

立ち上げ期にやってはいけない3つのこと

1. 記録項目を増やしすぎる：初期は「結果・ステージ・競合・理由カテゴリ・自由記述」の5列で十分です。項目を増やすほど記入率が落ち、分析できなくなります

2. 初月から改善効果を求める：最初の1〜2ヶ月はデータがばらつきます。効果判定は最低3ヶ月分が揃ってからにしてください

3. 複数の改善を同時に打つ：求人票・スカウト文面・オファー基準を同時に変えると、どれが効いたのか分かりません。月次で変えるのは1〜2項目に絞ります

記録が止まったときの復旧手順

止まった記録を再開するとき、過去分を遡って埋めようとするとまた止まります。遡るのは諦めて「今日以降の分から再開する」と決めてください。そのうえで、原因が「記録する場所が分からない」のか「結果確定の通知が担当者に届かない」のかを切り分けます。前者ならスプレッドシートのリンクを採用定例のアジェンダに固定で貼り、後者なら結果通知メールのCCに記録担当を入れるだけで再発を防げます。

FAQ（よくある質問）

Q1: Win/Loss分析を始めるのに必要な工数はどれくらいですか？

データ収集は1件あたり1〜2分、月次分析は30〜60分が目安です。スプレッドシートで始めれば、初期投資はほぼゼロ。継続的な負担も採用担当の通常業務の5〜10%程度に収まります。

Q2: 候補者からヒアリングの回答が得られないときはどうすればよいですか？

全員から回答が得られることはまずありません。エージェント経由での確認、面接官からの個別メッセージ、5問以内の短いアンケートという3点を工夫すると回答率は上がります。それでも取れない場合は、社内面接官と採用担当の視点だけでも構造化を続けてください。完璧を求めず、取れたデータで分析を回すのが続けるコツです。

Q3: 競合企業の名前を候補者は教えてくれますか？

直接的に「どこに決めましたか」と聞くと答えにくい場合があります。「最終的に選ばれた会社の特徴（業界・規模・フェーズなど）を教えてください」と聞くと回答率が上がります。エージェント経由なら、エージェントから直接ヒアリングしやすいです。

Q4: 内定承諾率の目標値はどのくらいに設定すべきですか？

業界平均値を追いかけるより、自社の改善トレンドを基準にするのが現実的です。複数オファー競合が常態化している市場では、承諾率の絶対値は候補者レンジや競合の顔ぶれによって大きく変わるためです。Win/Loss分析を始めた月の承諾率を基準値として記録し、半年後にそこから何ポイント動いたかで評価してください。

Q5: AIで自動化できる範囲はどこまでですか？

自由記述コメントの分類、傾向の要約、月次レポートの初稿生成までは現時点で十分に自動化可能です。一方、ヒアリングの実施・本音の引き出し・改善アクションの決定は、現時点では人間の判断が必要な領域です。AIは「分析の補助」、人間は「意思決定の主体」という役割分担が現実的です。

Q6: エグジットインタビューとWin/Loss分析、どちらから始めるべきですか？

採用フェーズの課題が大きいならWin/Loss分析、定着フェーズの課題が大きいならエグジットインタビューから始めてください。両者は補完関係にあるので、最終的には両方を運用するのが理想です。新規採用が多い組織ほどWin/Loss分析の効果が早く現れます。

Q7: Win/Loss分析の結果を経営層にどう伝えれば理解されますか？

「敗因の上位3つ」「競合企業との戦況」「改善アクションと必要なリソース」の3点をワンページに要約するのがおすすめです。経営層は「個別案件の話」ではなく「採用全体の戦況」を求めています。改善アクションには必ず「いくらかかるか・誰が責任を持つか」を併記すると意思決定が早くなります。

Q8: 採用件数が年間数件しかない組織でも意味がありますか？

あります。むしろ母数が少ない組織ほど、1件の敗因を掘り下げる価値が高くなります。ただし「勝率◯%」という率での分析は成立しないので、個別事例の質的な積み上げで見てください。年間3件でも、3件すべてで「最終面接後に他社のスピードに負けた」と分かれば、行動を変えるに足る発見です。率が意味を持つのは累計10件を超えたあたりからです。

Q9: Loss-Reject（自社が見送ったケース）も分析する必要がありますか？

必要です。ここを飛ばす組織が多く、機会損失の発見が遅れます。Loss-Rejectが特定の流入経路やスキルセットに偏っている場合、問題は候補者ではなくソーシング要件やスカウト文面の側にあります。見送り理由を「経験不足」で片付けず、「求人要件のどの項目に対して不足だったのか」まで記録してください。同じ項目での見送りが続くなら、その要件が本当に必須かを見直す材料になります。要件定義の詰め方は「エンジニア採用ペルソナ設計ガイド」も参考になります。

Q10: AI面接やAIスカウトを使っている場合、分析の軸は変わりますか？

4軸の枠組みは変わりませんが、「ステージ」の定義を見直す必要があります。AIスカウトでは送信・開封・返信の分布が人力運用時と変わるため、従来の基準値がそのまま使えません。またAI生成の文面を使っているなら、Loss-Withdraw（選考途中の辞退）が増えていないかを重点的に見てください。文面と実際の選考体験にギャップがあると、この段階での離脱が増えます。詳細は「エンジニア採用のAIエージェント活用ガイド」にまとめています。

まとめ：負けを資産に変える

エンジニア採用は、勝つことよりも負けから何を学ぶかで長期的な成果が決まります。

辞退・不採用は短期的には残念な結果ですが、構造化して分析すれば、求人票・スカウト・面接体験・オファー設計のすべてを磨く素材になります。スプレッドシート1枚と月30分の振り返りから始められます。

techcellarでは、スカウト運用代行を通じてクライアントのWin/Loss分析の仕組み化を支援しています。13サービス以上の運用経験と、エンジニアとして採用された側の視点の両方を活かし、データドリブンな採用設計をお手伝いします。

• スカウト運用代行・AIスカウト運用の詳細: サービス紹介

• 採用課題のご相談はこちら: お問い合わせ

• techcellarのLP: サービスLP

採用結果を振り返り、次の打ち手につなげる仕組みを一緒に作りましょう。