エンジニア採用のダイレクトリクルーティング運用｜現場で止めない分担

エンジニア採用のダイレクトリクルーティングは、始めるより続ける方が難しい仕事です。採用担当者が候補者を探し、技術経歴を読み、文面を書き、開発責任者へ確認を頼む。リリースや障害対応が重なると確認が止まり、未送信の候補者だけが増えていきます。

僕なら、送信件数の目標を置く前に、誰が何を決め、何分使い、担当者が休んだ日に誰が引き継ぐかを決めます。エンジニア採用のダイレクトリクルーティングを改善するには、個人の熱意ではなく、開発現場が無理なく参加できる運用が必要です。

本記事では返信率の計算や文面実験ではなく、採用担当者、EM、CTOが毎週続けるための責任分担と確認工数に絞ります。チャネル全体の配分を先に決める場合は、エンジニア採用チャネルの選び方へ進みます。

採用要件から選考までの全体像は、エンジニア採用の進め方でも整理しています。

採用担当・EM・CTOの決定権を工程ごとに分けます

最初に、ダイレクトリクルーティングの工程を一行ずつ書き出します。優先するエンジニア職種を決める、採用要件を更新する、検索条件を作る、候補者の公開経歴を確認する、送信を判断する、返信する、技術面談を行う、次の選考へ進める、といった工程です。

各行には実行者と決定者を一人ずつ置きます。採用担当者は候補者管理と連絡を進められますが、SREに任せるオンコール改善の責任を単独では決められません。EMは公開経歴と役割の接点を確認できますが、採用予算や入社時期の優先順位は決められない場合があります。CTOは技術組織の方針を決めますが、一件ごとの文面確認を抱えると送信が止まります。

優先職種、採用期限、報酬条件、候補者へ約束できる裁量は、月次でCTOが確定します。採用担当者は確定した条件から検索と候補者管理を進めます。EMは技術経歴の読み取りで迷う例外と、返信後の技術説明を担います。役職名ではなく、各社で実際に決裁できる人を置いてください。

候補者の選定と送信判断は、採用する企業が持ちます。判断基準を文書へ残し、担当者が候補者を対象に含めた理由を説明できる状態にします。外部支援や別部署へ一覧を渡し、誰が最終判断したか分からない状態を作りません。

主担当だけでなく代替担当も決めます。採用担当者が休む日は返信担当、EMが不在の週は技術質問の相談先、CTOの決裁が必要な条件変更は次に確認できる日時まで記録します。人が空いたときに探すのではなく、工程表へ最初から書きます。

開発現場の確認工数を上限付きで予定へ入れます

全候補者をCTOが読む運用は品質が高く見えますが、技術判断が一人の予定に依存します。開始時は採用担当者とEMが同じエンジニア候補者の記録を読み、対象に含める理由を合わせます。判断が揃った条件は採用担当者へ移し、職種をまたぐ経歴、シニア職、公開情報だけでは責任範囲を判断できない例だけをEMへ戻します。

確認時間は空いた時間へ入れず、予定表へ固定します。たとえば週二回の確認枠を置くなら、枠内で見る件数の上限と、次の枠まで待てない例外を決めます。件数が上限を超えた週は担当者の残業で埋めず、検索条件を狭めるか、採用期限と開発工数の優先順位を決め直します。

文面も毎回ゼロから作りません。会社共通の採用背景、エンジニア職種ごとの技術課題、候補者ごとに公開経歴から確認する接点を分けます。候補者固有の記述は募集職務に必要な範囲に限定します。公開プロフィールに載っていても、採用目的と関係のない情報を収集して社内へ共有しません。

返信後の技術面談枠は、送信後に探すのではなく先に確保します。候補者からアーキテクチャや開発体制の質問を受けた際の回答者、回答期限、面談担当者も決めます。送信だけ進めて技術説明が数日止まれば、候補者との信頼を失います。

工数は送信作業だけで測りません。採用担当者の候補者管理、EMの経歴確認と面談、CTOの条件決裁を分けて記録します。開発現場の時間が想定を超えた場合は、個人の作業速度ではなく、例外条件と承認経路を見直します。

運用が回っても返信が増えない場合は、スカウト返信率を職種別に診断・実験する方法で、分母、観測期間、職種別コホート、後続の選考指標を同じ条件にそろえます。

外部支援と候補者接点の境界を手順へ書きます

外部支援を使う場合は、「エンジニア採用のダイレクトリクルーティングを支援する」という契約名だけで担当を決めません。採用要件、検索条件、共通文面、社内レビュー手順を設計する仕事と、候補者を選び、応募を勧め、送信し、返信する仕事を分けます。

支援範囲を比較する際は、エンジニア採用コンサルとは何かも参考にしてください。

現段階の僕たちの支援は、採用要件、検索条件、共通文面、社内運用、集計方法の設計と定着です。候補者の紹介、応募勧誘、候補者の選別、スカウト送信、返信対応は提供しません。クライアント企業の担当者が対象者を判断し、候補者との連絡を行います。

職業安定法上の区分は「コンサル」「RPO」という名称だけでは決まりません。厚生労働省の募集情報等提供と職業紹介の区分では、事業者の判断による候補者や求人の選別、相手に応じた情報の加工、意思疎通への介入など、実際の行為から必要な許可等を判断すると説明しています。

候補者接点を外部へ委託する契約では、開始前に管轄の都道府県労働局や専門家へ確認してください。画面上でクライアント企業のアカウントを使うだけでは、業務の実態まで自動的に直接募集へ変わるとは限りません。

手順書には、利用するアカウント、候補者情報へアクセスできる人、選定と送信を承認する人、返信する人、記録の保管場所を書きます。契約終了時のデータ返却と権限削除も決めます。法的な境界と日常の引き継ぎを同じ工程表で確認できる形にします。

週次運用は件数より滞留を一つずつ解消します

週次の管理画面では、候補者を「確認前」「技術確認待ち」「送信判断済み」「返信対応中」「面談予定」「社内判断待ち」のように状態で分けます。各候補者に次の行動、担当者、期限を置きます。合計件数だけでは、誰の判断で止まっているか分かりません。

週次会議では、期限を過ぎた項目と最も長く止まっている項目から確認します。技術経歴の確認で止まったならEMが判断基準を追記し、報酬条件で止まったならCTOが決裁します。採用担当者へ一律に処理を急がせず、判断できる人へ滞留を戻します。

会議の最後には、翌週までに変える運用を一つだけ決めます。例外の相談先を追加する、技術面談枠を増やす、返信担当の代替者を置くなど、担当者と期限を記録します。変更を手順書へ反映しなければ、同じ滞留が担当者の記憶へ戻ります。

CTOは週次の候補者確認へ毎回参加せず、月次で優先職種、採用期限、開発現場が使った時間、条件変更の必要性を判断します。週次の実行と月次の経営判断を分けると、現場は決められた範囲で動けます。

担当者が休む想定で、月に一度は代替担当だけで工程を進めます。返信期限や技術確認先が分からず止まった場所を、引き継ぎ資料へ追加します。実際に不在になってから手順の不足を見つけるより、候補者へ影響する前に確かめる方が安全です。

次週の予定表を開き、候補者確認の固定枠と技術面談枠を置いてください。各枠へ主担当、代替担当、判断できる範囲まで書ければ、ダイレクトリクルーティングは誰かの善意ではなく、開発組織が続けられる仕事になります。

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