直接回答（Win/Loss分析とは）

エンジニア採用のWin/Loss分析とは、内定承諾・辞退・不採用の結果を構造化データとして収集し、勝因と敗因を定量・定性の両面で振り返り、次の採用設計に反映する仕組みです。1社あたり月1回・直近10〜20件のクロージング結果を分析するだけで、勝率の低い選考フェーズや競合企業を特定でき、3〜6ヶ月で内定承諾率を改善できます。

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

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

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

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

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

• 個人運営の採用支援で見てきた限り、Win/Loss分析を回している企業は半年以内に内定承諾率が10〜20pt改善するケースが多い

このページでわかること

• Win/Loss分析が他の振り返り（デブリーフ・エグジットインタビュー）とどう違うか

• 辞退理由・不採用理由を構造化するための4軸フレームワーク

• 候補者・エージェント・社内面接官への聞き取り設計

• 月次の採用定例でWin/Loss分析を回す運用フロー

• AI・スプレッドシートを使った集計と可視化のテンプレート

• 個人運営のスタートアップでも回せる最小構成

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

エンジニア採用の現場では「内定辞退された」「最終で他社に決まった」という結果が出るたびに、担当者がその場で原因を考えるケースが多いです。しかし、個別事例の振り返りだけでは構造的な問題が見えません。

筆者が採用コンサル営業の時代から見てきた中で、辞退や不採用の理由は次の3層に分解できます。

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

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

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

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

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

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

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

• エグジットインタビュー: 退職するエンジニアから採用・定着の課題を引き出す（エンジニアのエグジットインタビュー設計｜採用改善に活かす実践ガイド）

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

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

Win/Loss分析を導入する効果

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

• 内定承諾率が10〜20ポイント改善する

• 「とりあえずスカウトを打つ」ではなく、勝率の高い候補者層に絞った運用に変わる

• 面接官の質問内容や雰囲気が改善され、候補者体験が底上げされる

• オファー金額の妥当性判断が早くなり、決裁プロセスが短縮される

• 採用責任者が経営層へ説明する材料が増え、採用予算の交渉力が上がる

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

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

Win/Loss分析の核は「データの構造化」です。バラバラのコメントを集めても活用できません。次の4軸でデータを整理します。

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

シンプルですが定義が曖昧になりがちです。

• Win: 自社が内定を出し、候補者が承諾

• Loss-Decline: 自社が内定を出したが、候補者が辞退

• Loss-Reject: 自社が選考途中で見送り

• Loss-Withdraw: 候補者が選考途中で辞退

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

候補者・面接官・採用担当の3者から見た理由を、複数のカテゴリで記録します。カテゴリ例は次のとおり。

• 報酬・年収・株式報酬

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

• 組織・カルチャー・チーム構成

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

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

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

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

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

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

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

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

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

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

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

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

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

質問例:

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

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

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

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

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

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

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

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

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

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

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

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

社内側からの視点も忘れずに集めます。

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

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

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

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

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

データを集めるだけでは意味がありません。定例運用に組み込んで初めて分析が活きます。

月次運用のステップ

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軸データは、採用活動の各フェーズに反映します。

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

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

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

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

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

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

面接プロセスの再設計

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

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

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

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

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

オファー条件の調整

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

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

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

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

オファー設計の詳細は「エンジニア採用のオファーレター設計｜承諾率を高める実践ガイド」へ。

ソーシング層の見直し

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

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

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

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

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

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

Win/Loss分析は人手で回すと負担が大きいですが、AIとスプレッドシートで大幅に省力化できます。

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

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

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

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

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

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

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

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

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

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

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

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

ATSの選び方は「採用管理システム（ATS）の選び方｜エンジニア採用に強いツール比較」を参考にしてください。

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

3ヶ月続けると改善効果が見え始め、6ヶ月続くと採用組織の文化として定着します。続けるための仕組みづくりを紹介します。

心理的安全性の確保

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

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

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

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

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

KPIへの組み込み

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

• 月次レポートの提出率

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

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

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

「やったほうがいい」ではなく「やるのが当たり前」になる仕組みが、長期的な定着につながります。採用KPIの設計は「エンジニア採用のKPI設計｜成果につながる指標と運用方法」を参考に。

経営層への可視化

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

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

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

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

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

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

Win/Loss分析を始めた組織がつまずきやすいポイントをまとめます。

失敗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振り返りを習慣化しています。規模ではなく、振り返りの密度が採用力を決めます。

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

FAQ（よくある質問）

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

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

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

回答率は通常20〜40%です。エージェント経由・面接官からの個別メッセージ・短いアンケート（5問以内）の3点を工夫すると改善します。回答が取れない場合は、社内面接官と採用担当の視点だけでも構造化を続けてください。完璧を求めず、取れたデータで分析を回すのが続けるコツです。

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

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

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

エンジニア採用の内定承諾率は60〜80%が一般的な目安です。スタートアップで複数オファー競合が多い場合は50〜70%でも妥当。重要なのは絶対値より自社の改善トレンドで、Win/Loss分析を始めた時点を基準に半年で5〜10pt改善を目標にすると現実的です。

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

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

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

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

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

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

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

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

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

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

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

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

• techcellarのLP: サービスLP

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