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

• スカウト採用の成否はメール文面の前段階、「誰に送るか」の候補者サーチで8割決まる

• 検索キーワードは「技術名×経験年数」だけでは不十分。業務内容・プロジェクト規模・マネジメント経験の掛け合わせで精度が上がる

• BizReach・Forkwell・Green・LAPRAS・転職ドラフトなど、媒体ごとに検索機能の強み・弱みが異なる。特性を理解して使い分けることが重要

• 候補者プロフィールの「読み方」にはコツがある。更新日・職務経歴の粒度・技術ブログのリンク有無が本気度と実力を測る手がかり

• 検索条件は週1回見直す。母集団が枯渇したら条件を緩めるのではなく、検索軸そのものを変えるのが正解

• AIツールを活用した候補者サーチの効率化も進んでいるが、最終的な「この人に送るべきか」の判断は人間が担うべき

エンジニアのスカウト採用、なぜ「サーチ」が最重要なのか

「スカウトメールを100通送ったのに返信が3通しかない」。こんな悩みを抱えるスタートアップの採用担当者は多い。

返信率が低い原因として、多くの人は文面の改善に目を向ける。たしかにスカウトメールの文面は重要だ。しかし、それ以前に**「誰に送っているか」で結果の大半は決まっている**。

たとえば、転職意欲がほぼゼロのシニアエンジニアに、いくら丁寧なスカウトを送っても返信は来ない。逆に、ちょうど次のチャレンジを考えているミドルクラスのエンジニアなら、多少素朴な文面でもカジュアル面談につながることがある。

スカウト採用の成否は候補者サーチの質にかかっている。

このページでわかること

• スカウト媒体の検索機能を最大限に活かす実践テクニック

• 職種別・経験レベル別の検索条件設計の考え方

• 候補者プロフィールから「送るべき相手」を見極める読解術

• 媒体別の検索機能の特徴と使い分け方

• AIを活用した候補者サーチの効率化手法

• サーチ品質を継続的に改善するPDCAの回し方

1. 候補者サーチの基本フレームワーク——検索条件設計の5ステップ

スカウト媒体で候補者を検索するとき、いきなりキーワードを入力し始める人が多い。しかし、それでは「なんとなく引っかかった人に送る」作業になってしまう。

成果を出すサーチには、事前の設計が欠かせない。以下の5ステップで検索条件を組み立てよう。

ステップ1：ポジションの「核となるスキル」を特定する

求人票に書いた技術要件をそのまま検索キーワードにするのは避けたい。求人票（JD）には理想を盛り込みがちだが、サーチでは**「これがないと仕事にならない」最低限のスキル**に絞る。

• バックエンドエンジニアを探すなら「Go」や「TypeScript」ではなく、まず**「サーバーサイドの設計・実装経験」**という業務レベルで考える

• そのうえで、自社の技術スタックに合う言語・フレームワークをキーワードとして追加する

こうすることで、「Goは書いていないがRustやJavaで同等の設計力を持つ人材」を取りこぼさなくなる。

ステップ2：経験レベルの幅を決める

「シニアエンジニアが欲しい」と言っても、その定義は会社によって異なる。サーチの前に、以下を明確にしておく。

• 最低経験年数: 3年以上なのか、5年以上なのか

• 期待するロール: 個人で手を動かす人か、チームリードも担える人か

• 過去のプロジェクト規模: 3人チームの経験と30人チームの経験では意味合いが違う

これを決めないままサーチすると、プロフィールを読む段階で「やっぱり違う」が頻発し、時間を浪費する。

ステップ3：「あると嬉しいスキル」を優先度付きでリスト化する

核となるスキル以外に、あると嬉しいスキルを3つ程度リストアップする。

優先度Aのスキルは検索条件に含め、B以降はプロフィールを読む際の確認項目として使う。全部を検索条件に入れると候補者数がゼロになるのでバランスが大事だ。

ステップ4：ネガティブ条件（除外条件）を設定する

見つけたくない候補者の条件もあらかじめ決めておくと、サーチ効率が上がる。

• 直近のログインが6か月以上前（転職意欲が低い可能性）

• 現職の在籍期間が極端に短い（入社半年未満からの転職活動）

• プロフィールの記載が極端に薄い（スカウト自体に興味がない可能性）

ただし、除外条件を厳しくしすぎると優秀な候補者を逃す。あくまで効率化のためのフィルターとして使う。

ステップ5：検索条件のバリエーションを3パターン作る

1つの検索条件だけでは、同じ候補者プールを繰り返し見ることになる。最低3パターンは用意したい。

• パターンA: メイン条件（核スキル＋優先度Aスキル）

• パターンB: 条件緩和版（核スキルのみ、経験年数を下げる）

• パターンC: 視点変更版（異なる技術スタックだが同等スキルの人材を狙う）

パターンCが特に重要だ。たとえばReactエンジニアを探しているなら、Vue.jsやAngularの経験者も含めてサーチする。フレームワークの移行は十分に可能であり、候補者プールが大きく広がる。

2. 媒体別・検索機能の特徴と使い分け

スカウト媒体はそれぞれ検索機能の設計思想が異なる。すべての媒体を同じ使い方で運用するのは非効率だ。媒体選定の全体像は別記事で詳しく解説しているが、ここでは「検索機能」に絞って各媒体の特性を押さえておこう。

BizReach：詳細条件での絞り込みに強い

BizReachはフィルター条件が豊富で、年収・業界・職種・スキルなど多軸での絞り込みが可能。ハイクラス層が多いため、マネジメント経験やCTO・VPoE候補の検索に向いている。

• 強み: 年収レンジでの絞り込み、業界経験の指定

• 注意点: エンジニア以外の職種も多いため、キーワード設定が甘いとノイズが混じりやすい

• サーチのコツ: 「職種」フィルターだけでなく、フリーワードに具体的な技術名を入れて精度を上げる

Forkwell：技術スキルベースのサーチが優秀

Forkwellはエンジニア特化の媒体で、技術スキルのタグ付けが充実している。候補者が自分でスキルセットを登録しているため、技術軸での検索精度が高い。

• 強み: プログラミング言語・フレームワーク・インフラ技術のタグ検索、GitHubリポジトリ連携

• 注意点: 登録者数はBizReachやGreenより少ないため、条件を絞りすぎると母集団が極端に小さくなる

• サーチのコツ: スキルタグの「AND検索」と「OR検索」を意識的に切り替える。まずOR検索で広く見て、候補者プロフィールの質を確認してからAND検索で絞る

Green：カジュアルな転職潜在層にリーチ

Greenは「転職活動中」というよりも「良い機会があれば」というスタンスのエンジニアが多い。プロフィールの自由度が高く、経歴や志向性からポテンシャルを読み取るスキルが問われる。

• 強み: 「気になる」機能によるライトな接触、企業ページの閲覧履歴の把握

• 注意点: プロフィールの記載粒度にバラつきが大きい

• サーチのコツ: フリーワード検索で「自己PR」や「やりたいこと」欄に書かれたキーワードを拾う。技術名だけでなく「設計」「アーキテクチャ」「チームビルディング」など業務キーワードも有効

LAPRAS：アウトプットベースの候補者発見

LAPRASはGitHub、Qiita、Zenn、ブログ、登壇資料などのアウトプットを自動で収集・スコアリングする。「実際に手を動かしているエンジニア」を見つけるのに最適だ。

• 強み: 技術アウトプットの定量評価、転職意欲スコア

• 注意点: アウトプットをしないタイプの優秀エンジニアはスコアが低く出る

• サーチのコツ: スコアだけで判断せず、実際のアウトプット内容を確認する。特にGitHubのコントリビューション内容やQiita記事のテーマは、候補者の技術的な関心領域を正確に把握できる

転職ドラフト：年収提示型のユニークなサーチ

転職ドラフトは企業側が年収を先に提示する仕組みで、候補者の「現年収」「希望年収」が比較的正確に把握できる。報酬面でのミスマッチを事前に防げるのが特徴だ。

• 強み: レジュメの質が高い（候補者が自発的に詳細を記載するインセンティブがある）、年収情報の透明性

• 注意点: 月に1回のドラフト形式のため、タイミングによっては候補者が限られる

• サーチのコツ: レジュメの「プロジェクト詳細」を丁寧に読む。ここに書かれている情報量と具体性が、候補者の言語化能力とスカウトへの本気度を示している

YOUTRUST：信頼関係ベースのネットワーク検索

YOUTRUSTは「友人の友人」というソーシャルグラフを活用した媒体だ。既存社員のネットワーク経由で候補者を発見できるのが最大の強み。

• 強み: リファラルに近い信頼性、転職意向の可視化（「話を聞きたい」ステータス）

• 注意点: 自社社員がYOUTRUSTを使っていないと、リーチできる候補者が限られる

• サーチのコツ: まず社員にYOUTRUSTの登録とネットワーク構築を促す。つながりの深さ（1次 / 2次）で候補者の優先順位を決めると、返信率が高くなる

Wantedly：カルチャーフィットを重視するサーチ

Wantedlyは「共感」を軸にした採用プラットフォーム。年収情報の掲載がないため、ミッション・ビジョン・働き方への共感で候補者を引きつける設計になっている。

• 強み: ストーリー記事による企業文化の発信、「話を聞きに行きたい」ボタンによるライトな接点

• 注意点: 技術スキルでの詳細な絞り込みは弱い

• サーチのコツ: 検索だけでなく、自社のストーリー記事を充実させて「自然流入」を増やす。スカウトを送る際も、相手のプロフィールに書かれた「やりたいこと」と自社のミッションを接続するメッセージが有効

3. ブーリアン検索とフリーワード検索の実践テクニック

多くのスカウト媒体では、フリーワード検索やブーリアン検索（AND / OR / NOT）を使って候補者を絞り込める。この検索テクニックを使いこなすかどうかで、サーチの精度と効率に大きな差が生まれる。

AND検索：条件を掛け合わせて精度を上げる

AND検索は、複数の条件をすべて満たす候補者に絞り込む。「Go AND Kubernetes AND AWS」と検索すれば、3つのスキルをすべて持つ候補者だけがヒットする。

使いどころ:

• ポジションの核となるスキルが明確な場合

• 候補者数が多すぎて絞り込みが必要な場合

注意点:

• AND条件を増やしすぎると候補者がゼロになる。核スキル2〜3個のAND検索が適切なバランス

OR検索：候補者プールを広げる

OR検索は、いずれかの条件を満たす候補者を含める。「React OR Vue.js OR Angular」で検索すれば、いずれかのフレームワーク経験者がすべてヒットする。

使いどころ:

• 類似スキルを幅広く探したい場合

• 母集団が少なく、候補者プールを広げたい場合

注意点:

• OR条件を広げすぎると、スキルレベルのバラつきが大きくなる。プロフィールの精読が前提

NOT検索：ノイズを除外する

NOT検索は、特定のキーワードを含む候補者を除外する。「エンジニア NOT 営業 NOT コンサルタント」のように使う。

使いどころ:

• フリーワード検索でノイズが多い場合

• 特定業界や職種を除外したい場合

注意点:

• 過度な除外は思わぬ取りこぼしにつながる。まず除外なしで検索し、ノイズが目立つ場合にのみ使う

フリーワード検索で差がつくキーワード選び

媒体の検索窓に入力するキーワードは、技術名だけではもったいない。以下のような業務レベルのキーワードを使うと、検索結果の質が変わる。

設計力を示すキーワード:

• 「設計」「アーキテクチャ」「リファクタリング」「技術選定」「技術負債」

リーダーシップを示すキーワード:

• 「テックリード」「チームリード」「マネジメント」「メンター」「コードレビュー」

事業理解を示すキーワード:

• 「KPI」「グロース」「プロダクト」「事業開発」「ユーザーインタビュー」

成長意欲を示すキーワード:

• 「登壇」「OSS」「技術ブログ」「カンファレンス」「勉強会」

これらのキーワードを技術名と組み合わせることで、「ただ言語が書ける人」ではなく「事業に貢献できるエンジニア」を発見しやすくなる。

媒体ごとの検索構文の違いに注意

媒体によって、ブーリアン検索の構文や対応状況は異なる。媒体によっては全文検索に対応していないケースもある。事前に各媒体のヘルプページで検索仕様を確認しておくことをすすめる。

特に注意すべきは検索対象のフィールドだ。フリーワード検索が「スキル欄」だけを対象にしているのか、「自己PR」「経歴」も含むのかで、同じキーワードでもヒットする候補者が変わる。

4. 職種別・検索条件設計のベストプラクティス

「エンジニア」と一括りにしても、職種によって検索のアプローチは大きく異なる。代表的な職種ごとに、効果的な検索条件の組み方を解説する。

バックエンドエンジニア

核となる検索キーワード:

• 言語: Go、Java、Python、Ruby、PHP、TypeScript（Node.js）

• フレームワーク: Spring Boot、Django、Rails、Express、NestJS

• インフラ: AWS、GCP、Docker、Kubernetes

サーチのポイント:

• 言語の指定を1つに絞らない。Go経験者が欲しくても「Go OR Rust OR Java」で幅を持たせる

• 「API設計」「マイクロサービス」「DB設計」など、業務レベルのキーワードを追加すると設計力のある人材が見つかりやすい

• 「〇〇人月」「チームリード」「テックリード」でマネジメント経験もフィルタリングできる

フロントエンドエンジニア

核となる検索キーワード:

• フレームワーク: React、Vue.js、Next.js、Nuxt、Angular

• 言語: TypeScript、JavaScript

• 関連技術: GraphQL、REST API、Storybook、Figma連携

サーチのポイント:

• フロントエンドはフレームワークの移行が比較的容易。React経験者だけに絞らず、Vue.js経験者も候補に入れる

• 「アクセシビリティ」「パフォーマンス最適化」「Core Web Vitals」といったキーワードで、品質意識の高い人材を発見できる

• デザインシステム構築経験がある人材は希少価値が高い。「デザインシステム」「コンポーネント設計」で検索する

SRE・インフラエンジニア

核となる検索キーワード:

• クラウド: AWS、GCP、Azure

• コンテナ: Docker、Kubernetes、ECS、EKS

• IaC: Terraform、Ansible、CloudFormation

• 監視: Datadog、New Relic、Grafana、Prometheus

サーチのポイント:

• SREは他職種と比べて母集団が小さい。条件を絞りすぎず、「インフラエンジニアからSREへのキャリアチェンジ希望者」も視野に入れる

• 「SLA」「SLO」「可用性」「障害対応」「ポストモーテム」など、SRE特有の業務キーワードで実務経験を持つ人材を見分けられる

• オンコール対応経験の有無は、SRE候補者を見極める重要な指標

データエンジニア・MLエンジニア

核となる検索キーワード:

• データ基盤: BigQuery、Redshift、Snowflake、dbt、Airflow

• ML: Python、TensorFlow、PyTorch、MLflow、Kubeflow

• データ分析: SQL、Spark、Pandas

サーチのポイント:

• データエンジニアとMLエンジニアは求められるスキルが異なるので、混同しないよう注意

• 「データパイプライン」「ETL」「データマート」はデータエンジニア向けキーワード

• 「モデル学習」「推論基盤」「特徴量エンジニアリング」はMLエンジニア向けキーワード

• Kaggleでの実績やデータ分析コンペの参加歴は、候補者の探究心と技術力の指標になる

モバイルエンジニア（iOS / Android）

核となる検索キーワード:

• iOS: Swift、SwiftUI、UIKit、Objective-C

• Android: Kotlin、Jetpack Compose、Java

• クロスプラットフォーム: Flutter、React Native、Kotlin Multiplatform

サーチのポイント:

• App StoreやGoogle Playでリリース済みのアプリがあるかをプロフィールで確認する

• 「CI/CD」「自動テスト」「アプリ内課金」「プッシュ通知」など、実務経験を示すキーワードが有効

• クロスプラットフォーム開発の経験者は、ネイティブ開発の知識も持っていることが多い。逆方向の検索も試す価値がある

5. 候補者プロフィールの「読み方」——送る前に判断する7つのチェックポイント

検索でヒットした候補者に片っ端からスカウトを送るのは非効率だ。プロフィールを読んで**「この人に送るべきか」を判断する目利き力**が、スカウト運用の生産性を左右する。

チェック1：最終ログイン日・プロフィール更新日

最も基本的な指標。直近2週間以内にログインしている候補者は、転職意欲が高い可能性がある。逆に3か月以上ログインがなければ、スカウトが読まれる確率は低い。

ただし、LAPRASのようにアウトプットを自動収集する媒体では、ログイン頻度と転職意欲が必ずしも連動しないため注意が必要だ。

チェック2：職務経歴の記載粒度

職務経歴が「〇〇株式会社 バックエンドエンジニア 20XX年〜現在」だけの候補者と、使用技術・担当機能・チーム規模・成果まで書いている候補者では、後者のほうがスカウトへの反応率が高い。

プロフィールを丁寧に書いているということは、転職活動に一定の本気度がある証拠だ。

チェック3：技術ブログ・GitHub・登壇資料へのリンク

外部リンクを貼っている候補者は、自分の技術力を見せる意欲がある。これはスカウトにおいて大きなアドバンテージだ。

• GitHub: コミット頻度、使用言語、OSS貢献の有無を確認。詳しい評価方法はGitHubポートフォリオ評価の実践ガイドを参考にしてほしい

• 技術ブログ: 記事のテーマ・深さ・更新頻度から、技術的な関心領域と表現力がわかる

• 登壇資料: 技術カンファレンスでの発表経験は、コミュニケーション力の指標

これらのリンクはスカウトメールをパーソナライズする際の素材にもなる。

チェック4：希望条件の記載内容

「フルリモート必須」「年収800万円以上」「マネジメントはしたくない」など、候補者が明示している希望条件は必ず確認する。

自社の条件と明らかに合わない場合、スカウトを送っても時間の無駄になる。一方で、「フルリモート希望」の候補者に「週1出社のハイブリッド」を提案して成功するケースもある。完全な不一致でなければ、カジュアル面談で擦り合わせる余地はある。

チェック5：転職理由・志向性のキーワード

「技術的な挑戦がしたい」「プロダクト開発に携わりたい」「裁量のある環境で働きたい」——これらの記述は、候補者が何を求めているかを直接教えてくれる。

自社の環境がその志向性にマッチするなら、スカウト文面でそのポイントを具体的に語ることで返信率が上がる。

チェック6：現職の在籍期間と転職回数

在籍期間が極端に短い（1年未満）転職が連続している場合は注意が必要だが、エンジニアの場合はキャリアアップのための転職は一般的だ。

重要なのは「なぜ転職したか」のストーリーに一貫性があるか。技術的な成長やプロダクトへの関心が見て取れるなら、転職回数自体は大きな問題にならない。

チェック7：スキルの「組み合わせ」で希少性を見る

個々のスキルではなく、スキルの掛け合わせで希少性を判断するのが上級テクニックだ。

• 「Go × インフラ × チームリード」→ SREチームのリードができる人材

• 「React × デザインシステム × アクセシビリティ」→ フロントエンド基盤を任せられる人材

• 「Python × データパイプライン × ドメイン知識（金融・ヘルスケアなど）」→ 特定領域のデータエンジニア

こうした掛け合わせで候補者を評価すると、「スペック上は条件を満たさないが、実はぴったりの人材」を発見できることがある。

6. 候補者サーチでよくある失敗パターンと対策

候補者サーチで成果が出ないチームには、共通する失敗パターンがある。自分のチームが当てはまっていないか、チェックしてみてほしい。

失敗1：検索条件が理想形すぎる

求人票に書いた要件をそのまま検索条件にすると、候補者がほとんど見つからない。求人票は「こんな人が理想」を書く場所だが、サーチは「この条件なら十分活躍できる」最低ラインで探す場所だ。

対策: 求人要件を「Must（必須）」「Want（歓迎）」「Nice-to-have（あれば嬉しい）」の3段階に分け、検索にはMustだけを入れる。

失敗2：1つの媒体だけに依存している

「うちはBizReachだけ使っている」というチームは多い。しかし、特定の媒体に登録していないエンジニアは大勢いる。特にForkwellやLAPRASには、BizReachには登録していない技術志向の強いエンジニアが多く、逆もまた然りだ。

対策: 最低2媒体を並行運用する。予算が限られるなら、メイン媒体の年間契約＋サブ媒体のスポット利用という組み合わせが現実的。

失敗3：プロフィールを読まずに一斉送信している

「検索で引っかかった人全員に送る」というやり方は、短期的には送信数を稼げるが、返信率は低い。しかも、質の低いスカウトを大量に送ると、媒体内での自社の評判が下がるリスクもある。候補者同士は意外とつながっているものだ。

対策: 検索結果の全員に送るのではなく、プロフィールを読んで「なぜこの人に送るか」を言語化できる候補者にだけ送る。

失敗4：同じ検索条件を何か月も使い続けている

一度設定した検索条件を変えずに使い続けると、同じ候補者プールを何度も見ることになる。新規登録者が出てきても、既存の候補者に埋もれて見逃す。

対策: 検索条件は週1回見直す。「新規登録順」「プロフィール更新日」でソートを変えるだけでも、見え方は変わる。

失敗5：検索結果の数だけを見て判断している

「検索結果が500人出たから大丈夫」と安心するのは早い。その500人のうち、実際にスカウトを送る対象になるのは一部だ。結果の「量」ではなく「質」——ターゲット率——で判断するべきだ。

対策: 検索結果の最初の20人のプロフィールを読み、何人がスカウト対象になるか（ターゲット率）を確認する。30%未満なら条件を見直す。

7. 検索条件の継続改善——「枯渇」を防ぐPDCAサイクル

スカウト運用を続けていると、必ず「もう送る人がいない」という壁にぶつかる。これは候補者が本当にいないのではなく、検索条件が固定化して同じ候補者プールを繰り返し見ているだけのケースが大半だ。

週次で検索条件を見直す

以下のサイクルを週1回で回すことを推奨する。

Plan（計画）:

• 今週のスカウト送信目標数を設定（例: 30通）

• 検索パターンA / B / Cの配分を決める

Do（実行）:

• 各パターンでサーチし、候補者リストを作成

• プロフィールを読んで送付対象を選定

• スカウトを送信

Check（検証）:

• パターン別の返信率を計測

• 「送ったが返信がなかった人」のプロフィールを振り返り、共通点を探す

• 検索結果の新規候補者数（前週と重複しない人数）を確認

Act（改善）:

• 返信率が高いパターンの配分を増やす

• 新規候補者が少ないパターンは条件を変更

• 返信がなかった候補者の共通点から、除外条件を更新

母集団が枯渇したときの対処法

「もう候補者がいない」と感じたら、以下の打ち手を試す。

検索軸そのものを変える:

• 言語・フレームワークの指定を外し、「設計」「アーキテクチャ」などの業務キーワードだけで検索する

• 職種の枠を超えて「バックエンドエンジニア」から「フルスタックエンジニア」「SRE」に広げる

• 業界フィルターを変える。自動車業界のエンジニアがWeb系スタートアップに転職するケースは増えている

使っていない媒体を追加する:

• メイン媒体だけでは候補者の母集団に限界がある。2〜3媒体を並行運用することで、各媒体にしかいないユニークな候補者にリーチできる

タイミングを変える:

• 年度末（3〜4月）、ボーナス支給後（7月、12月）は転職活動が活発になる時期。この時期に合わせてサーチを強化すると、新規候補者が増える

過去の候補者を再サーチする:

• 3〜6か月前にスカウトを送って返信がなかった候補者が、状況の変化で転職意欲を持っている可能性がある。期間を空けて再アプローチすることは有効な手段だ

8. AIを活用した候補者サーチの効率化

生成AIやAIスカウトツールの進化により、候補者サーチの効率は大幅に向上している。ただし、AIに任せるべき部分と人間が判断すべき部分を明確に分けることが重要だ。

AIが得意なこと：条件マッチングとリスト化

• 求人要件と候補者プロフィールの自動マッチング

• 大量のプロフィールから条件に合う候補者のリスト化

• 候補者のスキルセットの構造化・タグ付け

• 類似候補者の推薦（「この候補者に似た人」の提案）

一部のスカウト媒体では、AIによるレコメンド機能がすでに実装されている。これを活用すると、手動検索では見つけられなかった候補者を発見できることがある。

AIが苦手なこと：文脈の読み取りと優先判断

• 候補者のキャリアストーリーの一貫性を読み取ること

• 「この候補者は自社のカルチャーに合うか」の判断

• 技術ブログやGitHubの内容を深く評価すること

• 競合他社からの転職候補者の扱いに関する戦略的判断

AIはサーチの「量」を効率化し、人間はサーチの「質」を担保する。この役割分担を意識すると、限られたリソースで最大の成果を出せる。

生成AIを活用したサーチ効率化の実践例

検索キーワードの拡張:

• 求人要件を生成AIに入力し、「この要件にマッチする候補者が使いそうな技術キーワードの類義語・関連語」を出力させる

• 自分では思いつかなかった検索キーワードが見つかることが多い

プロフィール要約:

• 候補者のプロフィール情報を生成AIに読み込ませ、「この候補者の強み・懸念点・スカウト時のアピールポイント」を要約させる

• 大量のプロフィールを効率的にスクリーニングできる

ブーリアン検索の自動生成:

• 求人要件を自然言語で入力し、媒体の検索機能に最適化されたブーリアン検索式を生成させる

• 特にLinkedIn Recruiterなど高度な検索構文を持つ媒体で有効

9. スカウト運用チームの体制と役割分担

候補者サーチは属人化しやすい業務だ。特定の担当者だけがサーチのノウハウを持っている状態は、その人が異動や退職したときにリスクになる。

少人数チームでの運用モデル

スタートアップでは、採用担当が1〜2名というケースが多い。その場合の推奨体制は以下のとおりだ。

採用担当者の役割:

• 検索条件の設計とパターン作成

• 候補者プロフィールの最終判断（送る/送らないの決定）

• スカウト文面の作成・送信

• 返信対応とカジュアル面談のセッティング

現場エンジニアの役割:

• 検索キーワードのレビュー（技術的な妥当性の確認）

• 候補者の技術力評価（GitHub・ブログの確認）

• カジュアル面談への同席

経営者・CTOの役割:

• サーチ対象の優先順位決定（どのポジションを先に埋めるか）

• ハイクラス候補者へのスカウト送信（CTO自らのメッセージは返信率が高い）

• 採用媒体の予算配分の意思決定

サーチノウハウの蓄積と共有

属人化を防ぐために、以下の情報を記録・共有する仕組みを作っておきたい。

• 検索条件テンプレート: ポジション別の検索パターンをドキュメント化

• 候補者評価メモ: プロフィールを見て「送る/送らない」を判断した理由を簡潔に記録

• 媒体別の返信率データ: どの媒体のどの検索パターンで高い返信率が出たかを蓄積

• 成功パターンの言語化: 内定承諾に至った候補者のサーチ〜スカウトのプロセスを振り返る

10. サーチ品質を測るKPIと目標設定

候補者サーチの品質を定量的に測るKPIを設定し、継続的に改善していくことが重要だ。

基本KPI

KPIの読み方

ターゲット率が低い場合（30%未満）:

• 検索条件が広すぎる。キーワードの追加やフィルターの強化が必要

開封率が低い場合（40%未満）:

• 件名が魅力的でないか、送信タイミングが悪い可能性。ただし、これはサーチの問題ではなく文面の問題

返信率が低い場合（10%未満）:

• 候補者選定の精度が低い（転職意欲のない人に送っている）か、文面が候補者に刺さっていない。プロフィールの読み込み精度を上げる

カジュアル面談設定率が低い場合（50%未満）:

• 返信後のフォローが遅い、または候補者の期待と提案内容にギャップがある

FAQ（よくある質問）

Q. スカウト媒体は何個くらい並行運用すべきですか？

A. 予算とリソースにもよるが、2〜3媒体の並行運用が現実的だ。1媒体だけでは候補者プールが限られ、4媒体以上は運用が回らなくなることが多い。メイン1媒体＋サブ1〜2媒体の構成が効率的だ。どの媒体をメインにするかは、採用したいポジションの特性と予算で決める。

Q. 検索しても候補者が10人以下しか出てこない場合、どうすればいいですか？

A. まず検索条件を見直す。言語やフレームワークの指定を緩めるか、OR条件に変更する。それでも少ない場合は、媒体自体にその職種の登録者が少ない可能性があるため、別の媒体を試すのが早い。また、経験年数の下限を下げるのも有効な打ち手だ。「5年以上」を「3年以上」にするだけで候補者数が倍以上になることがある。

Q. 同じ候補者に再度スカウトを送るのはマナー違反ですか？

A. 一度送って返信がなかった候補者への再アプローチは3〜6か月の間隔を空ければ問題ない。ただし、前回と同じ内容のスカウトを送るのではなく、新しいポジションの案内や会社の変化（資金調達、新プロダクトリリースなど）を理由にするのが自然だ。

Q. 技術がわからない人事担当者でも候補者サーチはできますか？

A. できる。ただし、現場エンジニアとの連携が前提だ。最初に現場エンジニアと一緒に検索キーワードの妥当性を確認し、プロフィールの技術的な読み方をレクチャーしてもらう。その後は自律的にサーチし、判断に迷ったら都度エンジニアに確認する運用がよい。techcellarのような採用支援サービスを活用すれば、技術面の目利きを外部に委託することもできる。

Q. 候補者のGitHubアカウントを見て何を確認すればいいですか？

A. 主に以下の3点を確認する。1つ目はコミット頻度。年間を通じてコンスタントにコミットしているか。2つ目はリポジトリの内容。個人プロジェクトのテーマや使用言語から技術的な関心領域がわかる。3つ目はOSS貢献の有無。有名なOSSプロジェクトへのPull Request実績があれば、コードレビューの経験やチーム開発への適応力の裏付けになる。ただし、GitHubのアクティビティだけで技術力を判断するのは避けるべきだ。業務コードは公開できないため、GitHubが活発でなくても優秀なエンジニアは多い。

Q. AIスカウトツールの導入を検討しています。効果は出ますか？

A. AIスカウトツールは候補者のリストアップとスクリーニングの工数を削減する効果がある。一般的に、手動でのサーチと比較して候補者リスト作成の工数を半減させたという報告もある。ただし、AIが推薦する候補者をそのまま送信対象にするのではなく、人間が最終確認する運用がベストだ。AIの推薦精度は媒体やツールによって差があるため、導入後も返信率をモニタリングして効果を検証しよう。

Q. スカウトのサーチと送信、それぞれどのくらい時間をかけるべきですか？

A. 目安として、サーチ6割・文面作成4割の時間配分を推奨する。1時間のスカウト作業なら、36分をサーチと候補者選定に、24分を文面作成と送信に充てるイメージだ。多くのチームは文面に時間をかけすぎてサーチがおろそかになっているが、「誰に送るか」の精度を上げるほうが、ROIは高い。

まとめ——スカウトの成功は「探す力」で決まる

スカウトメールの文面改善に多くの時間を費やしている採用チームは少なくない。もちろん文面は重要だが、「誰に送るか」の候補者サーチが、スカウト採用の成否を最も大きく左右する。

この記事で紹介した内容を実践に移すなら、まずは以下の3つから始めてほしい。

1. 検索条件を3パターン作る: メイン条件、条件緩和版、視点変更版の3つを設計する

2. プロフィールの読み方を磨く: 最終ログイン日、記載粒度、外部リンクの有無を必ず確認する

3. 週1回のPDCAを回す: 返信率をパターン別に計測し、検索条件を継続改善する

候補者サーチは地道な作業だ。しかし、ここに時間と知恵を投資するチームは、限られた採用予算でも確実に成果を出している。

スカウト運用の体制構築や候補者サーチの代行については、techcellarの採用支援サービスにお気軽にご相談ください。エンジニア×AIの知見を活かし、スカウト媒体の選定から候補者サーチ、メール作成まで一貫してサポートします。