エンジニア採用を任されたら｜Step3（スカウト立ち上げ・運用編）

こんにちは、HRdevの永井です。

エンジニア採用の全体像を6本立てで扱うシリーズの3つ目「Step3（スカウト運用編）」です。

• Step1（準備フェーズ）: 目標設定・現状把握・環境整備・要件定義・母集団形成の入り口

• Step2（企画・設計編）: 企画と経営報告、求人票、選考設計、面接形式、選考フィードバック、改善サイクル

• Step3（本記事／スカウト立ち上げ・運用編）: 媒体CSとの連携、スカウトの日次運用とカジュアル面談実施率向上

• Step4（エージェント編）: エージェントとの伴走関係と情報発信

• Step5（採用広報編）: 採用広報・技術広報・リファラル基盤の中長期の地盤づくり

• Step6（クロージング・振り返り編）: 第二の関門（候補者体験）、定量・定性の振り返り、内製/外部分担の判断軸

このStep3では、採用実務の中で採用担当が最も時間を投下するスカウト運用と、その運用を支える媒体CS（カスタマーサクセス担当）との連携を扱います。選考設計や選考フィードバックといった評価側の話はStep2（企画・設計編）に寄せているので、本記事は「候補者に到達し、カジュアル面談まで運ぶ」までに集中した構成です。

求人の要件定義（エンジニアへのヒアリング、ペルソナ、求人票の作成）はStep1（準備フェーズ）の母集団形成パートで扱っています。本記事はその要件定義が完了した前提で、媒体運用の立ち上げから日次・週次の継続運用までを時系列で整理します。

スカウト業務全体像

スカウト運用は「立ち上げ」と「継続運用」の2フェーズに分かれます。立ち上げで型を作り、継続運用で改善を回す構造です。

立ち上げを雑に進めると、継続運用でいくら改善を回しても返信率の天井が低いままです。逆に立ち上げに時間をかけても、継続運用で振り返りが回らなければ媒体特性に合わせた最適化が進まない。両方を設計してはじめて、スカウト運用は機能します。

これら業務全体を支える媒体横断のデータ管理については、記事末尾でまとめて扱います。

スカウト運用の立ち上げ

立ち上げフェーズの4つの作業（媒体ごとの求人カスタマイズ、スカウトテンプレート設計、検索条件作成、目線合わせ）を順に整理します。

媒体ごとに求人をカスタマイズする

媒体の特性に合わせて求人票の見せ方を変える作業です。

同じ原稿を全媒体にそのまま貼ると、媒体ごとの読者層と噛み合わず返信率が伸びません。媒体ごとに違うのは主に3点で表示できる文字数、項目の構成、読者層の関心軸です。媒体タイプごとに書き分けの勘所が異なるので、それぞれを分けて整理します。

尚、媒体3つに展開するなら、求人票のベース原稿1本に対してカスタマイズ版が3つできあがるイメージです。立ち上げ時の負荷は大きいですが、ここで媒体ごとの「型」が決まると、以降の更新が楽になるのでしっかり向き合いましょう。

総合型媒体（ビズリーチ、Green、Wantedly等）

総合型媒体はエンジニア特化の入力項目が用意されていないため、業務内容や募集要項といった既存項目に技術情報（開発プロセス、技術スタック、技術的チャレンジ等）を埋め込んで見せる必要があります。

注意点は、候補者の読了率が高い箇所＝求人の上部にフックとなる技術情報を集めることです。媒体によってはオプション項目のような追加領域も用意されていますが、技術情報をそちらに記載すると目立たず、結果として「薄い求人」として候補者に認知されてしまいます。読了率の高い求人上部の項目に、表示箇所を意識してバリエーションの作成することが重要です。

エンジニア特化型媒体（Findy、LAPRAS、転職ドラフト、Forkwell等）

媒体ごとに求められる情報の傾向に個性が出ます。記載項目が技術スタックや開発手法、AIの利活用状況など、総合型媒体にはそもそも項目がないものも多く、既存求人作成の段階で拾えていない場合、追加でヒアリングの必要があります。

さらにエンジニアは情報の整合性に敏感なので、媒体ごとに細かい粒度でカスタマイズした後に、他媒体やコーポレートサイト掲載求人との整合をしっかり取るようにします。求人更新は手間ですが、伝えきれていない魅力を掘り出す作業として捉えるのが重要です。

また、外部URL（Speakerdeckの登壇資料、外部メディアの登壇記事、テックブログ等）の活用に寛容な媒体も多いので、それらの素材も余すことなく記載します。注意点として、古い情報を載せっぱなしにしていると「この会社は採用チームが機能していないのか？」という疑念を招きます。メンテナンスの仕組みも並行して準備することが望ましいです。

SNS型媒体（LinkedIn、YOUTRUST等）

求人やスカウト本文の作り込みに加えて、アカウント情報の充実と地道なネットワーキングが効果を発揮します。

特に「誰から連絡が来るか」が重要な要素のひとつ。スカウト送信者が魅力ある人物として受け手に感じてもらえるように、情報拡充（プロフィール、登壇歴、技術発信等）をしっかり整えておく必要があります。

距離感も通常の転職媒体と異なるため、会社対人ではなく人対人のコミュニケーションを意識したコミュニケーション設計をするのがポイントになります。

全媒体共通の観点

媒体タイプを問わず押さえる観点は次の4つです。

• 媒体の読者層が一番気にする情報を冒頭に置く

• スマホ閲覧前提で、最初の数行で要点が伝わるか確認する

• 採用広報・技術ブログ・登壇資料のリンクを、媒体の文化に合わせて出し方を変える

• 募集背景は会社の事情ではなく、候補者にとっての挑戦として書き直す

スカウトテンプレートとCTAを設計する

求人票が整ったら、スカウト文面のテンプレートを作ります。1to1（候補者一人一人のレジュメを読んで個別に書く）が基本ですが、毎回ゼロから書くと、候補者に本来訴求すべきポイントがずれてしまうことがあります。ベースとなる伝えるべきエピソードや訴求ポイントは、テンプレートとして管理しておくことが重要です。

テンプレート運用の2パターン

テンプレートの運用には、大きく分けて2パターンあります。

• パターン1：ベーステンプレートに対してカスタマイズメッセージを載せる

  • 訴求点を固定し、冒頭の指名理由と末尾のCTA前後だけを候補者ごとに差し替える形

  • 訴求点が固定されるので、ABテストがしやすい

• パターン2：ペルソナに合わせてベーステンプレートの内容も取捨選択し、1to1のメッセージを載せる

  • 候補者のペルソナごとにベース部分も書き替えていく形

  • ペルソナごとに訴求点の柔軟なアトラクトができるが、ABテストの難易度が上がる

HRdevが支援に入る場合は、パターン1（訴求点を固定する方向）で進めることが多いです。ABテストがしやすいことに加えて、訴求点を固定したベーステンプレートに1to1のメッセージを載せる構造が、運用の基本形として馴染みやすいため、おすすめしています。

テンプレートの基本構成

エンジニアスカウトのテンプレートは、おおむね次の8ブロックで組み立てます。

1. 件名（候補者の関心を1行で示す）

2. 冒頭挨拶＋指名理由（候補者ごとにカスタム）

3. 会社・プロダクトの一言紹介

4. ポジションの背景と期待する役割

5. 技術スタックと開発プロセス

6. 候補者にとっての挑戦・成長機会

7. 条件面の概要（年収レンジ・働き方）

8. CTA（次のアクションの提案）

このうち2と8がカスタム部分、それ以外はテンプレートとして固定。経験領域に応じて差し替える「分岐ブロック」を持っておくと運用効率が上がります。フロントエンド向け／バックエンド向け／フルスタック向けで2〜3パターン用意しておくイメージ。

レイヤー別の構成調整

募集の狙いや候補者のレイヤーによって、スカウト文章の構成や順番を調整していきます。

同じ会社・同じプロダクトでも、ターゲットのレイヤーで響くポイントが違います。テンプレートを1つだけ作って全層に送るのではなく、レイヤーごとに重心を変えたバージョンを用意しておくと運用がぶれにくくなります。

• ジュニア〜ミドルクラス：

  • 成長機会やチャレンジの機会を主眼に置きます。

  • 「どんな技術領域に関わって何を経験できるか」「どのレベルの裁量でどこまで任せてもらえるか」をフックにします。

• シニアクラス：

  • 社会的なインパクト、事業への貢献、どのような価値を発揮していけるかといった、自己効力感にフォーカスした組み立てに調整します。

  • 「自分が関わることで何が動くのか」が伝わるように設計することが重要です。

検索条件を作成する

媒体上で実際に候補者を検索する条件を作ります。要件定義で作ったペルソナを、媒体の検索仕様に翻訳する作業です。

媒体ごとに検索のクセがあります。フリーワード検索の精度、職種カテゴリの粒度、必須項目の入力傾向、転職意向度の階層分け、スカウト返信率の表示有無。媒体のヘルプドキュメントとCSの説明を読み込んで、自社のペルソナがどの検索パターンで一番ヒットするかを試行錯誤します。

候補者プロフィール側の表記バラつきを把握する

要件定義で出てきた人物像をそのまま検索ワードにしても、候補者は集まりません。同じ役割でも、候補者プロフィール側の表記は人によって大きくばらつきます。

このギャップを把握しないまま「テックリード」だけで検索すると、本来ターゲットに入る候補者を取りこぼします。要件定義で出てきた役割名ごとに、候補者側の表記揺れを書き出すところから始めます。

バラつきを吸収する2パターン

表記バラつきを吸収するアプローチは、大きく2パターンあります。

• パターン1：最も広い条件でカテゴリを切ったうえで、共通キーワードで絞る

  • たとえば職種カテゴリを「Webエンジニア」のように広く取っておき、フリーワード検索で「Next」「Go」など必須スキルキーワードでANDをかけて絞る形

  • ターゲットの最大化を実現

  • 検索条件が少なく、複数媒体管理している場合認知負荷が大きくなりますが、それを最小化

• パターン2：条件ごとに被らないような設計をして、複数の検索条件を用意してドメインを作る

  • 「テックリード系(35歳以上）」「ミドルエンジニア系（35歳未満）」のように1ポジションに対してペルソナを立て、対象が重複しない形で検索条件を分けて運用する形

  • ペルソナごとに訴求軸を分けてアトラクトを変えたい場合、後工程がスムーズに進められる

どちらのアプローチでも、検索条件の再設計だけで対象候補者数が週10件から週30件に増えるケースはあります。

加えて、ヒアリングシートで聞いた「合わない人物像」（カルチャーフィットしない傾向、スキルセットが噛み合わない経験等）を検索条件のNGに設定します。NG条件を入れずに広くスカウトすると、面談・面接のプロセスでエンジニアの工数が浪費されてしまうことが有るため、事前に確認することが必要です。

また、検索条件は一度作って終わりではありません。立ち上げ時の条件をベースに、候補者の検索結果の表示状況を見ながら週次〜月次くらいのサイクルで見直すのがおすすめです。

目線合わせ（リストアップ、文章作成）

ここまでで作った媒体ごとの求人・スカウトテンプレート・検索条件を持ち寄って、運用を開始する前にエンジニアと採用担当で目線を合わせる工程を必ず入れます。要件定義は完了しているとはいえ、ペルソナの言語化と「実際にこの人を採るか」の感覚は別物です。

リストアップの目線合わせ

作成した検索条件で実際に媒体上から5〜10名ほど候補者をピックアップし、エンジニアに「この人を採りたいか／会いたいか」を一人ずつ確認します。

要件定義の文書だけでは判断できなかった微妙な経験値の過不足・チームカルチャーとのフィット感・ポテンシャル図り方や観点を揃えることができます。エンジニアからのOK理由・NG理由を引き出して、その判断軸を採用担当が言語化することで、検索条件・NG条件のチューニングに反映できます。

文章作成の目線合わせ

用意したスカウトテンプレートと指名理由のサンプル文（実在の候補者2〜3名分）をエンジニアに見せて、技術的な訴求の正確さ・候補者目線で読んだときの違和感を確認してもらいます。技術的に的外れな訴求や、エンジニア目線で「この会社わかってないな」と感じる表現は、ここで潰し切ります。

また、この工程をすることで、「こういった経験がある候補者だったら、今の技術イシューであるこれやってもらえそう」という鮮度・解像度の高いアトラクトエピソードがでてくることが有るのでおすすめです。

この目線合わせの工程を省略すると、運用が始まってから「採用担当が良いと思った候補者をエンジニアが落とす」「文面の技術訴求が浅いまま送り続ける」といった問題が後から見つかり、軌道修正のコストが大きくなることがあります。

媒体CSと緊密に連携する

利用中の媒体には、それぞれカスタマーサクセス担当者（以下CS）がついています。検索条件の助言、返信率のベンチマーク提供、新機能の案内、事例共有、イベント招待。CSが持っている情報は多岐にわたるのに、採用担当側でその情報を十分に受け取れていないケースをよく見ます。

最前線の生情報を持つCSと向き合って対話する

CSは採用マーケットの最前線にいて、自社・他社問わず生の情報を横断的に持っている存在です。媒体内の他社事例、業界全体のベンチマーク、自社側では見えない運用のコツ、候補者動向の変化。CSが持っている情報の厚みは、採用担当が一人で集めようとしても到底代替できません。正面から向き合って対話する時間を定例で確保することは、採用担当にとって非常に価値があります。

定例で扱うと効果が出やすいテーマは次のあたりです。

• 直近1ヶ月の運用データ（送信数・返信率・面談実施率）の共有とCSからの所感

• 検索条件の見直し（スカウト対象が増えないときの相談）

• スカウト文面のレビュー（反応が落ちたときの打診）

• 新機能・仕様変更のキャッチアップ

• 同業種・同規模の他社ベンチマーク（開示可能な範囲で）

自社側の開示情報が連携の精度を決める

こちら側から情報をオープンに出すほど、CSから返ってくる情報の精度は上がります。CS側は複数の支援先を並行して見ているので、こちらの情報が断片的だと助言も一般論に寄りがちです。開示範囲は会社の方針に依存しますが、次のような情報を共有できると、CSも具体的で実務的な助言を返しやすくなります。

• 自社のパイプライン状況（選考中候補者の数、各ステータスの進捗、直近のクロージング状況）

• 他媒体での候補者反応（他媒体の返信率との差、同じ文面での効き方の違い）

• 選考プロセス中に立てている仮説（「この層に刺さっているのは技術的負債の開示が効いているのではないか」「最近の辞退はオファー面談のタイミングが原因ではないか」といった仮説段階の気づき）

• ターゲット候補者像の変化（四半期ごとの要件変更、優先ポジションの入れ替え）

情報を出さない状態だと、CSも「なぜスカウトが伸びないのか」の仮説を立てられません。採用チームの内部情報に近い粒度でオープンに共有できるほど、CSとの連携の質は深まります。

定点観測で自社の訴求・ターゲットとの乖離感を掴む

定例頻度は運用の立ち上がり度合いで変えます。立ち上げから最初の3ヶ月は月2回（隔週）で細かく検索条件や文面を磨き、返信率が3ヶ月連続で自社基準値の±3%程度の変動幅に収まってきたら、「安定」と判断して月1回に切り替えるイメージです。

頻度を決めるときも、四半期の棚卸しで媒体の継続・切替を判断するときも、以下の指標を継続的に見ておくと議論の土台が作れます。

四半期の頭では「このまま使い続けるか、別媒体に切り替えるか」の棚卸しを入れます。CS側も他支援先の引き合いで候補者動向の変化を見ているので、「この媒体は自社のターゲットと合わなくなってきた」という相性変化のシグナルに気づくのが早い。媒体の切り替え・追加の判断材料としても、定例のなかの対話が一番の素材になります。

定例と指標の定点観測を続ける一番の価値は、自社の訴求内容やターゲット像が、マーケットの実態とどれくらいズレてきているかを継続的に掴めるようになることにあります。数字を1回だけ見ても気づけませんが、同じ指標を毎月・毎四半期で並べて眺め、CSの所感と突き合わせていくと、「自社が狙っている像と、実際に反応が出ている層がずれ始めている」「打ち出しているフックがマーケット側で陳腐化している」といった乖離感が早い段階で見えてきます。この乖離感を掴み続けられること自体が、CS連携の最大のリターンです。

スカウトを日次で回し、週次で改善する

実行フェーズの中心業務であり、人事が最も時間を投下する領域でもあります。

ここでは送信サイクル（日次）と改善サイクル（週次）の分け方、ターゲティング、カジュアル面談実施率を上げるための工夫までを扱います。

送信は日次、改善レビューは週次で分ける

スカウトの送信サイクルと、施策の改善サイクルは別物として設計します。送信のベストは日次です。毎日リストアップして毎日送信するのが、返信率・面談実施率ともに最も安定します。

候補者が媒体にログインした直後、プロフィールを更新した直後、ステータスを「活動中」に変えた直後といった、候補者側のアクションを起点としたタイミングで届けられるかどうかが勝負を分けます。タイミングが命の領域なので、週1回まとめて送る運用だと、直近に動いた候補者を他社に先に拾われます。

日次送信の基本リズム:

曜日や時間帯の効き方は、後述の「候補者のホットな瞬間を捕まえる」で扱います。ここではまず「毎営業日送信を回す」というリズムの部分を固めてください。

改善レビューは週次で回すことが多いです（運用全体の改善サイクルの詳細はStep2 企画・設計編「改善サイクル」を参照）。日次送信で蓄積したデータを週次で振り返り、お客様の新規アップデート情報（組織変更、プロダクトの進捗、要件の調整など）の差分を定例で取り込みながら、スカウト文面・検索条件・アプローチの改善を進めます。

お客様との合意が前提にはなりますが、振り返りのために送信を止めることは基本的にはしません。送信の手は止めずに、翌週以降のスカウトに改善内容が反映されていく運用です。ただし、要件や訴求軸のアップデートのインパクトが大きく、文面・検索条件の大幅な書き直しが必要な場合は、そのアップデートの反映が完了するまで運用を一時的に止めるケースもあります。

返信率を動かす要素の優先順位

改善打ち手を探すときは、次の順で見直します。

最初に見直すべきは候補者選定です。対象条件が甘いまま件名や文面を磨いても、返信率は一定のラインで頭打ちになります。候補者選定は、リストの質を通じて開封率にも、マッチ精度を通じて返信率にも効く打ち手です。

その先の整理として、件名・求人名・冒頭一行目は開封率に効く要素、スカウトテンプレートと1to1の度合い・企業側の情報整備は返信率に効く要素、と分けて捉えます。開封されているのに返信が来ないなら下流（テンプレート〜情報整備）を、そもそも開封されていないなら上流（リストと件名）を疑う、という切り分けがしやすくなります。

スカウトテンプレートを優先的に見直す場面は、「候補者には届いているのに反応が薄い」と感じたときです。テンプレートが想定している候補者像と、実際にリストアップしている候補者像にずれがあると、文面の訴求が刺さりません。テンプレートが古びてきた、あるいは初期に立てた候補者仮説が外れている可能性を疑ってみてください。

送信タイミングについては、ターゲットとするペルソナに対する返信傾向は最初の段階では分かりません。一定のデータが蓄積されたタイミングで見直すのが現実的だと考えています。一般的な傾向値（媒体タイプ別の曜日・時間帯）はありますが、立ち上げ期はまずはデータの蓄積を優先する判断もありえます。

自分が関わったプロジェクトでは、検索条件やターゲット要件を見直すことで、送信可能な対象が既存運用の3倍程度に広がったケースがありました。母集団の広がりに加えて、自社に合う候補者層へ正しくリーチできるようになった結果、返信数や返信率が2倍程度まで上がった事例もあります。

候補者選定は、打ち出し求人やスカウトテンプレートの設計とも連動する領域です。どれか一つだけ磨いても効きにくく、求人の切り出し・ターゲット定義・文面のすべてを一緒に動かして初めて成果が伸びます。そういう意味でも、候補者選定は実行フェーズの中でも一番大きなレバーだと捉えています。

候補者の「ホットな瞬間」を捕まえる

「誰に送るか」と同じくらい効くのが「どのタイミングで届けるか」です。同じ候補者でも、状態によって返信率は数倍動きます。特に反応が出やすいホットな瞬間は次のあたりです。

これらのサインは媒体の機能（最新アクティビティ表示、新着順ソート、ステータスフィルタ）で把握できます。毎日リストアップする運用（前述の日次送信）と相性がよく、日次で回しているからこそホットな瞬間を逃さずに拾えます。週1回のまとめ送信では、登録から数日経って温度が下がった状態で届くことになります。

曜日・時間帯の効き方も、候補者の状態や属性と合わせて考えます。時期・施策・競合動向によって揺れますが、自分の支援現場で観測してきた大まかな傾向は次のとおりです。

加えて、候補者ペルソナによっても最適な時間帯は変わります。

• 子育て中のエンジニア層 → 夜の対応が難しいため、朝のほうが読まれやすい

• 副業・業務委託で多忙な層 → 平日日中の反応が鈍く、夜間や休日のほうが反応が出る

• 海外拠点・時差で働く層 → 日本の感覚の朝夕とはずれる

「どの曜日・時間帯が効くか」は媒体 × ペルソナ × 時期の組み合わせで決まるので、自社のデータを3〜4週間取って、媒体別・曜日別・時間帯別の返信率で判断できることがベストです。

「誰に送るか」と「いつ届けるか」をセットで設計するのが、最初に手を入れる返信率改善です。冒頭文言や件名の調整より、はるかに効く場面が多いです。

ABテストは一度に1要素

改善したいなら、変える要素は一度に1つに絞ります。件名だけ変える週、冒頭だけ変える週、と分けてログを残します。

複数要素を同時に変えてしまうと、何が改善に貢献したのかを判別できなくなるのが一番の問題です。結果として、次にどの変数を調整すべきかが不明確になり、アップデートのサイクルそのものが機能しなくなります。1回1変数に絞ることで、施策と結果の因果が残り、次の打ち手の精度が上がっていきます。

「返信のハードルを下げる（CTA設計）

スカウトのゴールは応募ではなくカジュアル面談への接続なので、CTA（Call to Action、候補者に取ってほしい次の行動）も「まずは話す」の方向で組み立てます。

返信後のオペレーションは、こちらが提示する選択肢の数や日程調整の流れによって候補者の負担が変わるため、設計の選択肢を整理しておきます。

スカウト文面に「まずはご返信ください」と書く際は、候補者に期待するアクションを具体的に明示する必要があります。何を求められているのかが読み取れないと、返信のハードルが上がってしまうからです。

• 転職の意向が定まっていなくても良いと伝える

• 「まずは技術や組織についてディスカッションしましょう」と提案する

• 「あなたが聞きたいことを話しましょう」「今困っているこれについて話しませんか」など、内容を軽くする

• 所要時間を明示する（30分・45分・1時間など）

時間の長さによっても候補者側のリアクションは変わります。我々として何がしたいのか、それに対して候補者に何をしてほしいのか、このセットを「リード」としてしっかり設計しておくことが重要です。

返信後の候補者負担を最小化するオペレーション

候補者負担を最小化するオペレーションには、大きく分けて3パターンあります。候補者のアクションに対する負荷が軽い順に並べました。

人間が介在して調整を行うと、どうしても手戻りや再調整が発生しがちです。社内の面接担当者のスケジュール調整に問題がないという前提であれば、URLを活用した調整は非常に有効かつ有益な手段になります。

返信から面談設定までをどれだけ早く設定できるかで、面談実施率は大きく変わります。私たちが行う場合は、可能なら即レス、24時間以内の一次返信を基本にしています。

カジュアル面談での握り

カジュアル面談のあとに選考へ進んでいただく場合、握っておきたいのは次の観点です。

• 候補者のキャリア希望と、自社のポジションのどこが接点になったか

• 不安になっている点（技術的負債・働き方・評価制度等）

• 他社選考の進捗と、比較軸

• 選考プロセスの概略と、次のステップに進むかどうかの確認

この握りを面談者が文章で残しておくと、技術面接・最終面接の担当者が準備する時の情報ソースになります。カジュアル面談が単発のコミュニケーションで終わらず、選考のスタート地点として機能するようになります。

パイプライン進行中の候補者から逆算してスカウトを改善する

弊社が採用支援に入るとき、スカウト運用が業務の中心になることは多々あります。

もちろんスカウトという母集団形成レイヤーの改善に力を入れますが、運用が立ち上がってきた段階では、ファネル全体の観点でスカウトを改善していくのが大事だと考えています。

具体的には、スカウトを送った・返信が来たといった各論の指標だけを見るのではなく、パイプラインに入った候補者が選考のどこまで進んでいるか（一次面接、最終選考、内定など）を重視します。

1. 候補者の属性（経験年数、技術スタック、関心領域、現職の状況など）

2. 面接官がどのようにコメントしたか

3. 1,2の情報をもとに分析し、スカウトのターゲット要件を再定義する／要件変更の仮説を立てる

このようにパイプライン進行中の候補者から逆算して、スカウト運用を改善していくイメージです。スカウトの返信率だけ上がっても、そこから先の選考通過・内定承諾まで続いていなければ、本来届けたい層にリーチできていない可能性があります。逆に、返信率が横ばいでも進行している層の属性が変わってきたら、ターゲット要件の再定義に向けた前向きなシグナルとして捉えます。

この逆算を回すためには、選考パイプラインの情報に採用担当（あるいは支援側）がアクセスできる状態を作っておくことが欠かせません。

お客様からのヒアリング、あるいはATS情報へのアクセスをさせていただくなどで、選考ステータスや「今ポジティブな評価を受けている候補者は誰か」といった生の情報をキャッチアップしながら運用を見直していく。そういうサイクルを作れるようにしていくことが重要です。

媒体横断のデータ管理

ここまで扱った業務すべてを媒体横断で支えるインフラが必要です。

特に、送信実績・検索条件メモ・テンプレートのバージョン・候補者情報を、どう保管しどう参照するか。立ち上げ初日から決めておかないと、半年後には運用が立ち行かなくなります。

現状はスプレッドシートが現実解

媒体側のダッシュボードはあくまでその媒体内の指標しか見られません。

媒体A・B・Cを横断して「同じ候補者への重複送信を防ぐ」「媒体別の返信率を週次で比較する」「ABテストの結果を集計する」といった横断管理は、各媒体の管理画面ではできません。

ATS（応募者追跡システム）でカバーできる範囲も限定的です。スカウト送信履歴まで連携できるATSはまだないと認識しています。結果として、媒体横断の運用データはスプレッドシート（GoogleスプレッドシートやExcel）で管理するのが現状の現実解になります。

重複送信を防ぐための最低限の準備

最低限の防止策としては、まず同じ媒体内での重複送信を防ぐために、候補者の固有URL（媒体上の候補者ページURL）で重複チェックできる仕組みを整えます。

加えて、媒体間の重複送信にも備えます。同じタイミングで転職活動をしている候補者は複数媒体に登録しているケースがあるため、媒体A・B・Cを横断して同じ氏名が出てきたときに気づける状態にしておく必要があります。

スプレッドシートで媒体別シートを統一フォーマットにし、氏名で送信前にVLOOKUP／COUNTIFで照合する運用が現実的です。リファラル候補者・エージェント紹介中の候補者も除外リストに入れておきます。これらを含め、候補者体験を損なわない準備をしていくことが非常に重要です。

担当者個人名でスカウトを送る場合の除外設計

面接担当者・面談担当者の名前でスカウトを送るケースもあります。CTOやEMといった現場の名前で送ると返信率が上がる場面が多い一方、除外設計を雑に進めると個人と候補者の関係を損ねるリスクがあります。整理しておきたい観点は2つ。

1. 個人レベルのNG設定：「この会社の所属者には、自分の名前で送らないでほしい」といった個人ルールを送信担当者ごとに確認し、除外リストに反映する

2. 会社レベルのNG設定：「この企業の方にはスカウトを送らない（取引先・出戻りNG・関係先など）」というルールを会社として共有する

これらの条件を踏まえて適切に除外できる仕組みを整えることが、運用の安全性の基盤になります。

1万件を超えると一気につらくなる

スプレッドシート管理は、立ち上げ期はかなり快適です。送信実績、開封・返信ステータス、検索条件メモ、テンプレートのバージョン、すべてシート1枚で見渡せる。

問題は件数が増えてからです。送信ログが累計1万件を超えてくると、いくつもの限界に当たります。

• ピボットテーブルや関数の再計算が遅くなり、開くだけで数十秒待たされる

• 複数人で同時編集すると競合が頻発する

• 候補者の重複チェック（媒体間、過去送信履歴）が関数ベースだと精度が落ちる

• フィルタ条件を変えるたびに動作が重くなり、振り返りの速度が落ちる

• 履歴管理が弱く、過去の検索条件・テンプレートのバージョンを追えなくなる

1〜2年運用するとほぼ確実に1万件は超えます。当面はスプレッドシート＋部分的な自動化（GAS、社内スクリプト）でしのぐのが現実的です。1万件を超えてから動き出すケースが多いですが、そのときが運用の棚卸しと部分的なツール化を考えるタイミングです。

次へ — エージェント対応と採用広報

スカウト運用は母集団形成の主要チャネルですが、もう一つの主要チャネルであるエージェント対応はStep4、中長期で採用を楽にする採用広報・技術広報・リファラル基盤はStep5で扱います。

シリーズ一覧

• エンジニア採用を任されたら｜Step1（準備フェーズ）

• エンジニア採用を任されたら｜Step2（企画・設計編）