スカウト代行 / Findy
Findyの検索条件の組み方|母集団を狭めすぎない設計
Findyの企業側の検索画面は公開されておらず、法人向けページも検索項目の一覧や候補者数の内訳は出していません。一方で、候補者が求人を探すときの画面は誰でも見られます。同じデータベースを両側から見ている以上、候補者側の軸は、企業側で条件を組むときの手がかりになります。この記事では、条件を一度に決めきるのではなく、引いてみて足りなければどこを外すかという分岐の順番で組み立てます。以下は2026年9月24日時点で公式サイトに記載されている内容に基づいており、運営はファインディ株式会社です。
分岐に入る前に、候補者のカードに並ぶ四つを確かめる
候補者向けサイトの求人一覧を見ると、1枚のカードに並んでいる情報は四つです。候補者はこの四つで求人を比べているので、企業側が条件を組むときの軸もこれに対応している可能性が高いと読めます。確定はできませんが、商談で何を確かめるかを絞る材料にはなります。次の表は、カードの情報を、自社の検索条件でどう扱うかに置き換えたものです。
| カードの情報 | 掲載されている例 | 条件を組むときの扱い |
|---|---|---|
| 職種 | バックエンドエンジニア、QAエンジニア、機械学習エンジニア など | 境目が動いているので、最初から一つに絞らない |
| 年収レンジ | 600万円〜1,200万円、920万円〜1,400万円 など | 条件より前に、対象層と重なるかを確かめる |
| 技術スタックのタグ | Go、Python、GraphQL、gRPC、BigQuery など | 必須は一つ、残りは優先順位として持つ |
| アクション | 「いいかも」 | 候補者側の興味の表明として受け取る |
技術スタックのタグは、カードに5つ程度が表示され、残りは「+4」のように件数で畳まれていました。上位に何を置くかで候補者からの見え方が変わるので、求人票に書く技術の順番も条件設計の一部と考えます。候補者の側で比べられている軸と、自社が条件で絞る軸がずれていると、引いた相手に文面が刺さりません。
最初の関門は、年収レンジが想定年収と重なるか
分岐の一段目は、検索条件ではなく年収レンジです。候補者向けサイトには想定年収の機能があり、「経験やスキルをもとに、自分の市場価値の目安を確認できます」と説明されています。実際の求人には600万円〜1,200万円、920万円〜1,400万円、1,200万円〜2,500万円といった幅で掲載されているものがあり、企業一覧のページでも企業ごとに年収の幅が示されています。候補者は自分の相場観を持った状態で、企業のレンジを見ています。
ここで重ならないと分かったら、条件をどう工夫しても反応は出にくいので、先に進まずに手を打ちます。レンジを上げられるならそれが最短です。上げられないなら、任せる役割の大きさか、学べる環境で差をつけることになります。この判断を条件設計のあとに回すと、送った通数だけが減って理由が分からないまま1か月が過ぎます。
言語を一つだけ必須にして引き、出た数で次を決める
二段目で、技術スタックで引きます。候補者向けサイトのトップには、Ruby、Python、Java、PHPといった言語での絞り込み導線があり、リモート、自社サービスを開発、フロントエンド、業務委託といった切り口も並んでいます。企業ページでは利用技術が、言語、フレームワーク、インフラ・ミドルウェア、開発ツールの四分類で掲載されていました。
分類が四つに分かれているということは、言語とインフラの組み合わせで経験の意味が決まる設計だと読めます。同じ言語でも、Webアプリケーションを作っている人とデータ基盤を作っている人では経験が違います。それでも最初の検索では、必須にするのは言語一つにとどめ、フレームワークやインフラは並べ替えの優先順位として持つのが無難です。
出た人数が面談枠に対して多ければ、条件を足さずに送る順番の設計に移ります。少なければ、言語を増やすのではなく三段目に進みます。言語を二つ三つと重ねて調整を始めると、どの条件が効いたのかが後から読めなくなるからです。
足りなければ、職種の境目をまたいでスキル偏差値の足切りを外す
三段目は職種です。求人カードの職種名は、バックエンド、QA、機械学習、Android、iOS、SRE、フロントエンド、データ、セキュリティ、フルスタックの各エンジニアに、エンジニアリングマネージャーやプロダクトマネージャーまで細かく分かれています。候補者向けサイトのトップには、PdM、エンジニア、プロマネ、SIer/SE、FDE、CTO、VPoE、EMという対象の並びもあります。運営のセミナー案内には「AIの台頭でエンジニアの『職種の壁』が消えつつある今、採用基準はどう変わるべきか」という問いと、「越境人材」という言葉が掲げられていました。職種名で機械的に絞ると、隣の職種にいる適任者が落ちます。
四段目がスキル偏差値です。候補者向けサイトは「GitHub連携で、開発言語ごとのスキルを客観的に把握できます」と説明し、タイトルにも「GitHubからスキル偏差値を算出」と掲げています。公開されたコードが入力なので、業務のコードを外に出せない環境にいる人ほど数字が出にくくなります。企業側でこの数値を必須条件に使うのか、並べ替えに使うのかは公開されていないため、契約前に確かめる項目です。
エラベルの見解
スキル偏差値という名前は、条件設計を誤らせやすいと考えています。偏差値という語は「高いほど良い」と連想させますが、測っているのは公開されたアウトプットの量と質です。母集団が165,000名(2026年9月時点)という規模でも、指標で上位に絞れば一気に細り、上位層ほど他社からのスカウトも集中します。担当する側から見ると、偏差値で足切りした一覧より、偏差値を外して職歴と一緒に読んだ一覧のほうが、競合の少ない候補者に根拠のある文面を書けます。同じ料金で代行を頼んでも、この読み方をする担当者かどうかで、送る相手の質が変わります。
尽きたら、企業ページと求人票で待つ側に回る
一段ずつ外しても未接触の相手がいなくなる時期は来ます。そのときの打ち手は、条件をさらに緩めることではなく、候補者の側から見つけてもらう準備です。企業ページはミッション、ビジョン、プロダクト、インタビュー、技術ブログ、メンバー、会社概要、利用技術、関連リンクで構成されていました。技術ブログは記事のタイトルと技術タグ、公開日が一覧で並ぶので、自社の技術発信がそのまま企業ページの中身になります。
コーポレートサイトはサービスを「独自に開発したAIでエンジニアのスキルと企業の求人票を解析し、最適なマッチングを実現」と説明しています。求人票が解析の入力になっている以上、書き直せば届く相手そのものが変わります。条件を絞る作業と求人票を書き直す作業は、この媒体では同じ方向を向いています。文面と求人票の組み立てはFindyのスカウトテンプレートの作り方にまとめています。
分岐全体を一枚にすると、次のようになります。各段で「何を見て」「どちらに進むか」を先に決めておけば、担当者が替わっても同じ順番で回せます。四段目まで進んだら、それ以上は条件ではなく待つ側の準備で補う、という線もここで引いておきます。
| 分岐 | 判定に使うもの | 足りているとき | 足りないとき |
|---|---|---|---|
| 一段目 年収レンジ | 対象層の想定年収との重なり | 二段目へ | レンジか役割を見直す |
| 二段目 言語 | 言語一つで引いた人数と面談枠 | 送る順番を決める | 三段目へ |
| 三段目 職種 | 隣接職種まで広げた人数 | 職歴で並べ替える | 四段目へ |
| 四段目 偏差値 | 足切りを外した人数 | 職歴と一緒に読む | 待つ側の準備へ |
分岐の途中で止まらないよう、非公開の部分を商談で埋める
企業側の検索項目が公開されていない以上、分岐のどこかで「その条件は使えるのか」が分からずに止まることがあります。止まる場所を契約前に減らすには、ほかの媒体で公開されている情報と並べて、Findyで何を聞くかを決めておきます。次の表は、エンジニア向けの他媒体で公開されている情報と、Findyで確かめる項目の対応です。
| 比較の観点 | 他媒体で公開されている例 | Findyで確かめること |
|---|---|---|
| スコアの分布 | LAPRASは平均値と上位何%かを公開 | 偏差値帯ごとの人数 |
| 検索項目の一覧 | LAPRASはヘルプで全項目を公開 | 使える条件の一覧 |
| 母集団の職種内訳 | OpenWorkは経験職種別の概数を公開 | 自社職種での人数 |
| 条件の保存と再利用 | LAPRASは保存機能を公開 | 週次の運用が回るか |
聞いた数字は、そのまま分岐の判定に使えます。言語別・偏差値帯別の人数が出れば、二段目と四段目でどれだけ増えるかを契約前に見積もれます。自社の面接枠から逆算した月の送信数でその人数を割れば、母集団が何か月持つかも出ます。エンジニア向けの他の媒体の組み方は、LAPRASの検索条件の組み方やForkwellの検索条件の組み方もあわせてご覧ください。
エラベルの見解
企業側の仕様が非公開の媒体を、それだけで候補から外す必要はないと考えています。個社ごとに条件を組む営業方針なら、公開しないのは自然な判断です。ただし発注側は、非公開であることのコストを見込んでおく必要があります。他媒体なら契約前に母集団を試算できるところを、この媒体では商談で出してもらうしかなく、職種別の人数が出てこないまま年間契約を結べば、分岐の設計を契約後に賭けることになります。商談の場で人数が出てくるかどうかは、媒体の良し悪しではなく、自社がこの媒体を比較の土俵に乗せられるかどうかの判定だと捉えてください。
まとめ
- Findyの企業側の検索項目は非公開なので、候補者のカードに並ぶ四つ(職種・年収レンジ・技術タグ・アクション)から条件の軸を借りる
- 最初の関門は年収レンジ。候補者は想定年収を知っているので、重ならなければ条件より先にレンジか役割を見直す
- 技術は言語一つだけを必須にして引き、足りなければ職種の境目をまたぐ
- スキル偏差値は足切りに使わず、職歴と一緒に読む。上位ほど他社のスカウトも集中する
- 尽きたら企業ページと求人票を整えて待つ側に回り、非公開の部分は契約前に商談で埋める
よくある質問
Q. Findyの企業側の検索項目は、どこで確認できますか
2026年9月24日時点では、企業側の検索項目の一覧は公開されていません。候補者向けの求人カードや企業ページから軸を推し量ることはできますが、確定には商談での確認が要ります。使える条件の一覧と、偏差値帯ごとの人数を出してもらうよう依頼すると、分岐の見積もりに使えます。
Q. スキル偏差値は高めに設定したほうが効率的ですか
足切りに使うと、母集団が一気に細るうえ、上位層ほど他社のスカウトが集中します。GitHubに公開されたコードが入力なので、業務のコードを外に出せない実力者は数字に現れにくい点にも注意が要ります。まずは外した状態で引き、職歴と一緒に読んで並べ替える使い方をお勧めします。
Q. 条件を緩めても候補者が見つからないときはどうすればよいですか
条件をさらに緩めるより、候補者の側から見つけてもらう準備に切り替えます。企業ページの技術ブログやメンバー紹介を整え、AIの解析対象でもある求人票を書き直すと、届く相手そのものが変わります。あわせて、月あたりの新規登録の状況を運営に確認しておくと、待つ期間の見当が付きます。
※料金・通数・機能の条件は変わります。掲載した内容は2026年9月24日時点で公式サイトに記載されているものであり、企業側の検索仕様については契約前に運営にご確認ください。