本文へ移動
採用内製化支援 by cotomu

エンジニア採用のスカウト返信率を改善する|職種別に実験する

株式会社adding / 採用内製化支援チーム

エンジニア採用 / スカウト

ガイド内の位置づけ
エンジニア採用
公開ガイド
36
この記事の更新
2026年8月17日

「エンジニア向けスカウトの返信率が五パーセントでした」と聞いても、良し悪しは判断できません。送信件数と到達人数のどちらを分母にしたのか、辞退を返信へ含めたのか、どの職種へ何日間送ったのかで数字の意味が変わるからです。

僕なら、相場を探す前に自社の計測条件を一枚へ書きます。エンジニア採用のスカウト返信率を改善するには、バックエンドとSREを分け、同じ経過日数で読み、対象者を固定した実験が必要です。返信を得た後に面談や技術選考へ進んだかも、元の送信条件へつなげます。

本記事は運用担当者の分担ではなく、返信率の分母、職種別コホート、実験、返信後指標に絞って解説します。

エンジニア採用のスカウト返信率は分母と分子を先に定義します

最初に分母を決めます。媒体から取得できる数字が送信件数なら送信件数、到達件数まで取得できるなら到達件数を使えます。ただし月ごとに分母を変えてはいけません。自動再送や同じ候補者への複数送信がある場合は、メッセージ件数と候補者人数を分けて残します。

分子も一種類ではありません。辞退や質問を含む全返信、興味を示した前向きな返信、面談へ進む意思を確認できた返信を分けます。全返信率だけが上がった場合は、文面が反応を得たのか、条件の不一致を早く伝えられただけなのかを判別できません。

観測期間は送信日から同じ日数へ揃えます。今週送った候補者と三週間前に送った候補者を同じ表で比較すると、返信を待てた期間が違います。送信週を固定し、七日後、十四日後など、媒体と自社の検討期間に合わせた同じ時点で記録します。

率には必ず実数を添えます。二件中一件の五十パーセントと、二百件中百件の五十パーセントは、次の実験へ使える情報量が違います。母数が少ないコホートでは結論を急がず、候補者ごとの対象理由や反応も読みます。

計測対象から除く条件も事前に決めます。送信エラー、重複送信、媒体上で連絡不能だった候補者を後から都合よく外すと、期間ごとの比較が崩れます。除外理由と件数を集計表へ残します。

診断軸固定する定義・条件数字が動いたときの確認先
分母送信件数か到達件数か再送、送信エラー、同一候補者の重複
分子全返信、前向き返信、面談意思のどれか辞退や質問を含めたことで率だけ上がっていないか
観測期間送信から7日後、14日後など同じ経過日数新しい送信群だけ返信待ち期間が短くないか
コホート職種、シニアリティ、媒体、送信週対象者の構成変化を文面の効果と混同していないか
変更する変数件名、訴求、送信者など一度に一つ他の条件を同時に変えていないか
後続成果面談実施、技術選考移行、次工程返信だけ増えて選考が進んでいるか

職種とシニアリティでコホートを固定します

全エンジニアの返信率を一つにまとめると、採用したい職種の変化なのか、送信構成の変化なのか分かりません。職種、シニアリティ、媒体、送信週を組み合わせ、同じ条件の集団をコホートとして追います。

バックエンドエンジニアのミドル層と、信頼性の責任を持つシニアSREでは、候補者母数も任せる仕事も違います。EMと個人で技術判断を担うテックリードも分けます。職種名が同じでも、入社後に任せる成果が変わった場合は同じコホートへ混ぜません。

一方で、条件を細かく分けすぎると各コホートが数件になり、率の上下へ振り回されます。最初に検証したい軸を一つ選び、他の条件を固定します。職種差を見たい期間なら媒体と送信週を揃え、媒体差を見たい期間なら職種と訴求を揃えます。

コホート名には判断できる情報を入れます。「七月一週目」だけではなく、「七月一週目・バックエンド・シニア・決済基盤」のように記録します。後から同じ職種名を見ても、対象にした責任と技術課題を再現できます。

相場の返信率を参照する場合も、職種、シニアリティ、媒体、集計時期、分子の定義が自社と同じか確認します。条件が公開されていない数字は目標値にせず、自社コホートの基準期間を比較の出発点にします。

基準期間には率だけでなく、対象条件、使用した訴求、除外件数、観測日も保存します。前月の数字だけを残すと、採用要件が変わった後も同じ返信率を追い続けることになります。

送信判断、返信担当、技術確認を週次運用へ落とす方法は、エンジニア採用のダイレクトリクルーティング運用で役割別に整理しています。本記事の率と実験表を、担当者と期限のある運用表へ接続してください。

実験では一度に一つの変数だけを変えます

返信率が低いときに、検索条件、件名、本文、送信者、送信時間を同時に変えると、数字が動いても理由を説明できません。実験前に仮説、変更する変数、固定する条件、観測期間、判定日を書きます。

たとえばバックエンド候補への技術訴求を試すなら、対象条件と送信者を固定し、「利用言語」を伝える文面と「決済処理の部分失敗を減らす責任」を伝える文面を比べます。SREならクラウド製品の一覧と、オンコール負担を減らすために渡す権限を比べられます。実際に任せられない責任を実験用に書いてはいけません。

候補者ごとの一文を変える場合も、募集職務と関係する公開情報だけを使います。経歴を大げさに褒める文章、根拠のない適性判断、私生活への言及は実験対象にしません。媒体規約と個人情報の取扱いを確認した範囲で記録します。

文面の前提となる職務や必須条件が曖昧なら、先にエンジニア採用の要件定義で期待成果と必要能力を一職種ずつ確定します。条件が変わった実験群は、同じコホートとして比較しません。

厚生労働省の公正な採用選考の基本も確認し、本人に責任のない事項や思想・信条に関わる事項を、対象条件や個別文面の材料へ使いません。

送信対象は比較する文面へ偏りなく割り当てます。経験豊富な候補者だけを新しい文面へ寄せると、文面と対象者の差を分けられません。割り当て方法を実験メモへ残し、途中で結果を見て対象条件を変えないようにします。

実験を止める条件も先に決めます。採用要件が変わった、求人条件に誤りが見つかった、候補者から誤解を招くとの指摘を受けた場合は、件数を満たすまで続けません。返信率の改善より求人情報の正確さを優先します。

一回の結果を普遍的な勝ちパターンにしません。別の送信週や同じ職種で再現するかを確かめます。技術市場や候補者の関心は変わるため、採用を再開する際は以前の結果を仮説として扱います。

返信後の指標まで元のコホートへつなげます

返信率だけを最適化すると、返事をもらいやすい広い表現へ文面が寄ります。「裁量が大きい」と書いて返信が増えても、面談で実際の決裁範囲を説明できず辞退が増えれば、採用は前へ進みません。

各コホートで、前向きな返信、面談設定、面談実施、双方が技術選考へ進む判断、技術選考実施、次工程への移行をつなぎます。途中の割合と実数を並べると、スカウト文面で生じた期待が選考まで保たれたかを確認できます。

返信から最初の連絡まで、面談設定までの日数も残します。訴求が合っていても社内の連絡が遅ければ、文面実験の結果と候補者対応の遅れが混ざります。計測上は別の列へ置き、返信率の変化へ原因を押しつけません。

辞退理由は回答を強制せず、候補者が任意で伝えた内容だけを分類します。技術的な責任、事業段階、報酬条件、選考負荷、時期などへ分け、元のコホートと訴求へ戻します。個人を特定できる詳細を改善資料へ残す必要はありません。

外部支援へ計測設計を依頼する場合も、候補者接点との境界を確認します。現在提供している採用内製化支援は、職種と技術要件、共通文面、検証条件、集計方法の設計です。候補者の選定、送信判断、スカウト送信、返信対応は企業に行っていただきます。

候補者接点を外部へ委託するときは、厚生労働省の募集情報等提供と職業紹介の区分を確認し、必要に応じて管轄の都道府県労働局や専門家へ相談してください。サービス名ではなく、選別、勧誘、送信、意思疎通など実際の行為で確認します。

直近一か月の送信データから一つの職種とシニアリティを選び、分母、前向きな返信、面談実施、技術選考移行を同じ行へ置いてください。次に変える変数と判定日を一つだけ書けば、返信率の報告表が次の判断を検証できる実験表へ変わります。

※制度に関する記載は2026年8月17日時点です。個別のサービス区分や候補者接点の委託については、管轄の都道府県労働局または専門家へ確認してください。