スカウト代行 / Geekly
Geeklyの検索条件の組み方|母集団を狭めすぎない設計
Geekly(ギークリー)のスカウトは、IT・Web・ゲーム業界に特化した転職エージェントの人材紹介契約に付帯する無料の機能として案内されており、一次面接確約が条件とされています。送った相手が応じれば面接になるので、検索条件は「広いほど良い」とも「狭いほど精度が高い」とも言えません。この記事では、最初の条件の置き方から、候補が多すぎるとき、少なすぎるとき、それでも出ないときへと、母集団が尽きるまでの分岐の順に条件の直し方を整理します。以下は2026年9月23日時点で公式サイトに記載されている内容に基づきます。
最初の条件は、週の面接枠から広さを逆算して置く
公式の企業様向けページは、料金体系の項目に「求職者スカウト無料」を置き、データサービスから直接求職者を探せること、レジュメを確認できること、無料で直接アプローチできることを挙げ、「※一次面接確約が条件です」と注記しています。条件が広すぎれば面接枠を超えて送れない候補が溜まり、狭すぎれば枠が空いたまま週が終わります。そのため、最初の条件は「誰を探したいか」より先に「週に何人を読めば枠が埋まるか」から広さを決めます。目安は、読んで選ぶ余地を残すために、面接枠の三倍前後の候補が出る広さです。
| 週の面接枠 | 条件で出したい候補数の目安 |
|---|---|
| 2枠 | 6〜8人 |
| 3枠 | 9〜12人 |
| 5枠 | 15〜20人 |
この目安は、返信の割合によって上下させる前提の出発点です。二週間ほど回して、出た候補のうち送りたいと思える人がどれくらいいるかを数えると、自社の倍率が見えてきます。三人に一人も送りたい人がいなければ広げ、ほとんど全員を送りたいなら条件がまだ狭すぎるか、読み方が甘いかのどちらかです。
条件そのものは、二段に分けて組みます。一段目は職種の区分を二つか三つと勤務地で、面接できる仕事がある層を作ります。二段目は技術名、経験年数、開発体制で、同じ母集団の中で誰から読むかの順番を決めます。二段目を一段目に混ぜてしまうと、該当者が数人まで減り、翌週には候補がいなくなります。ここから先の分岐は、この二段の構えを前提にしています。
| 状態 | 最初に触る場所 | 触らないほうがよい場所 |
|---|---|---|
| 候補が多すぎる | 二段目(読む順番) | 一段目の職種区分を削ること |
| 候補が少なすぎる | 一段目(隣の職種区分を足す) | 面接枠を増やして帳尻を合わせること |
| 広げても出ない | 紹介に任せる領域かどうか | 未経験層まで条件を広げること |
候補が多すぎるときは、条件ではなく読む順番で分ける
週の枠に対して候補が多すぎるとき、多くの会社は条件を足して絞ろうとします。けれども条件を厳しくすると、翌週に候補がゼロになり、また条件を緩めるという往復が始まります。広さは保ったまま、二段目で読む順番を決めるほうが安定します。たとえば、募集ポジションで使う技術を実務で扱っている人から読み、次に隣接する技術の人、最後に経験年数だけが合う人、という並べ方です。
読む順番を決めるときは、送らない条件も先に決めておきます。一次面接確約が条件である以上、当たらない相手に送ると面接枠をそのまま失うからです。次のような相手は、読んだうえで見送る候補になります。
- 勤務地の希望が自社の拠点とまったく合わない
- 希望年収が募集のレンジを大きく超えている
- 募集職種と経験がまったく重ならない
- レジュメの更新が長期間止まっている
- 紹介経由ですでに接触している
最後の項目は、この媒体に固有の確認です。スカウトを送った候補は担当アドバイザーに共有する運用にしておくと、紹介と二重に接触することを避けられます。更新日やログイン状況で絞れるかは公開されていませんが、絞れるなら二段目の最初に置くと、転職の検討が進んでいる層から読めます。
エラベルの見解
相談で最も多い思い込みは、「条件を細かく指定するほど良い候補に当たる」というものです。実際には、言語、フレームワーク、経験年数、業界、規模と足していくと、該当は数人になり、その数人は他社も同じ条件で見ています。IT職種の検索で効くのは、条件を足すことより、二つまでに抑えた条件で出た候補を、技術の分かる人が読んで順番を付けることです。三つ目の条件を足したくなったら、それは別の条件セットとして分け、週ごとに交互に回してください。担当者によって結果が分かれるのも、条件の数ではなく、この読む工程の質です。条件表だけで提案してくる相手より、読む順番の付け方を説明できる相手を選んでください。
候補が少ないときは、隣の職種区分に広げる
候補が少なすぎるときは、一段目の職種区分を見直します。求職者向けサイトの求人検索では、技術職(SE・インフラエンジニア・Webエンジニア)のなかに、ITコンサルタント・システムコンサルタント、業務系SE・PG(SI・受託/自社製品)、インフラエンジニア、データベースエンジニア、ネットワークエンジニア、サーバーエンジニア、社内SE(社内情報システム/IT戦略・企画/開発/ネットワーク)、スマホアプリ系エンジニア、制御系・組込み・ファームウェア開発、セキュリティエンジニア、機械学習・AIエンジニア、データサイエンティスト、データエンジニアといった区分が並んでいます。区分がこれだけ細かいと、一つの区分だけで探せば母集団はすぐに尽きます。
広げる先は、仕事の中身が重なる隣の区分です。サーバーサイドの開発者を探しているなら、社内SE(開発)や、インフラから開発へ移ろうとしている層も候補になり得ます。データ基盤の担当を探しているなら、データベースエンジニアとデータエンジニアを一段目に並べて入れる、といった形です。区分をまたいで一段目に入れておけば、二段目の技術名で読む順番を付けられるので、精度はそれほど落ちません。
二段目の技術名は、人事が思いつく言葉ではなく、現場が使う言葉で組みます。現場に「この仕事で使う言葉を三十個」挙げてもらうところから始めると、区分を広げても読む順番がぶれません。ただし、検索できる項目は公開されていないので、次の点は契約前に運営へ確かめてください。
| 確認すること | 分かると何ができるか | 分からないときの代わり |
|---|---|---|
| 検索できる項目(職種、技術、経験年数、勤務地、年収) | 条件を設定値で書ける | 職種区分で広く出し、読む段で分ける |
| レジュメの本文を横断して探せるか | 技術名で直接探せる | 現場の言葉の一覧を見ながら目で読む |
| 条件の保存と再利用 | 週ごとの手間が減る | 条件を社内の文書に残して毎回入れる |
| 送信済みの相手を除外できるか | 重複送信を防げる | 送信記録と照合してから送る |
それでも出ないときは、紹介に任せる領域かを見直す
区分を広げても候補が出ないなら、その要件はスカウトで探すより紹介に任せたほうがよい領域かもしれません。同ページは、サービスご利用の流れとして、基本契約の締結後に希望の職種や要件を確認して求人票を作成し、条件に合った求職者を紹介するとしています。そのうえで、月間12,000名超えの登録者の中から1社あたり平均40名を紹介するとしています(登録者数・紹介人数は2026年6月時点の実績)。登録者数は約56万名以上(2026年7月時点)とされており、自社の検索で出ない候補が、アドバイザー経由なら出てくる可能性はあります。
逆に、スカウトで自分で探す意味がはっきりしている場面もあります。どちらに寄せるかは、要件を言葉にして渡せるかどうかでおおむね決まります。次の表は、スカウトに残す場面と、紹介に寄せる判断を対にしたものです。
| 場面 | スカウトに残す理由 | 紹介に寄せる判断 |
|---|---|---|
| 要件が特殊で、言葉で伝えにくい | 自分で読んだほうが早い | 要件を言語化できたら紹介にも渡す |
| 紹介の推薦が要件とずれている | どこがずれているか自分で確かめられる | ずれの理由をアドバイザーに返す |
| 特定の技術やドメインの経験者を狙う | 二段目の条件で直接探せる | 三か月出なければ要件を見直す |
| 未経験者や育成前提の層を探す | 残す理由は薄い | この媒体以外の経路を検討する |
最後の行には理由があります。同ページは、登録者の95.9%が即戦力人材であるとしています(即戦力人材とは登録している求職者のうちIT職種経験者を指すとされ、2024年7〜9月の実績と注記されています)。未経験者やポテンシャル層を条件に入れても母集団はほとんど増えないので、経験者の中でどの経験を見るかという設計にとどめます。
条件は見送りの記録で月に一度直す
分岐をたどったあとは、条件を固定せずに月に一度見直します。同ページは月間12,000名超の登録があるとしているので、先月出なかった候補が今月は出ることもあります。見直しの材料になるのは、どの条件で何人出て、何人を見送り、見送った理由が何だったかの記録です。見送りの理由が年収に偏っているなら条件より募集の設計の問題で、職種の不一致に偏っているなら一段目の区分の選び方の問題だと切り分けられます。
もう一つの材料は、面接に来た人の顔ぶれです。条件どおりの人が来ているのに面接で噛み合わないなら、ずれているのは条件ではなく要件の定義です。この場合は条件をいじっても直らないので、面接官と一緒に要件を書き直します。運用全体の時間の流れはGeeklyのスカウト運用設計に、条件で選んだ相手に送る文面はGeeklyのスカウトテンプレートの作り方にまとめています。
エラベルの見解
担当する側から見ると、この媒体の条件設計が難しいのは、検索の操作ではなく、どこで広げるのをやめるかの判断です。候補が少ないときに一段目を広げるのは正しい手ですが、広げ続けると、読む量が増えて一通の重さが落ちます。一次面接確約の媒体でそれをすると、面接枠が噛み合わない候補で埋まります。目安は、二段目の技術名で順番を付けたときに、上位の候補を読み切れる範囲までです。それを超えたら、条件を広げるのではなく、紹介に任せるか要件を見直す段階に来ています。この線を引ける担当者かどうかは、提案の段階で「どこで止めますか」と聞けば分かります。
まとめ
- 最初の条件は、週の面接枠の三倍前後の候補が出る広さから始め、職種区分と技術名の二段に分けて組む
- 候補が多すぎるときは条件を足さず、技術名で読む順番を決め、送らない条件を先に決めておく
- 候補が少ないときは、仕事の中身が重なる隣の職種区分を一段目に足す
- 広げても出ないときは、紹介に任せる領域かを見直す。即戦力層が中心なので未経験層には広げない
- 条件は見送りの理由と面接の顔ぶれで、月に一度直す
よくある質問
Q. Geeklyではどんな項目で候補者を検索できますか
検索できる項目の詳細は、公式サイトでは公開されていません。職種、技術、経験年数、勤務地、年収で絞れるか、レジュメの本文を横断して探せるかは、契約前に運営へ確認してください。分からない場合は、職種区分で広く出して読む段で分ける形で始められます。
Q. 候補が多すぎるとき、条件を足して絞ってはいけませんか
絞ること自体は構いませんが、条件を足すと翌週に候補がゼロになりやすくなります。広さを保ったまま、技術名などで読む順番を決めるほうが週ごとの数が安定します。三つ目の条件を足したくなったら、別の条件セットとして分けるのが一つの方法です。
Q. 未経験者も検索条件に入れたほうがよいですか
公式サイトでは、登録者の95.9%がIT職種経験者である即戦力人材とされています(2024年7〜9月の実績)。未経験者を条件に入れても母集団はほとんど増えないと考えられます。育成前提の採用は、別の経路を検討するほうが合っています。
※仕様や提供範囲は変わります。掲載した内容は2026年9月23日時点で公式サイトに記載されているものです。検索項目、通数、一次面接確約の適用範囲は公開されていないため、契約前に運営の案内でご確認ください。