候補者DBが大きいほど有利ではある。ただし、それだけではない

サーチファームを比較すると、候補者DB数や業界別人材プールの規模がよく示される。

これは意味のある資産だ。長く採用を支援してきた会社には過去の接触履歴や業界ネットワークが蓄積され、すでに関係のある候補者へ早くアクセスできる。

ただ、難易度の高いポジションでは別の問いが必要になる。『DBに何人いるか』と『今回の役割で実際に検討できる人が何人いるか』は同じ数字なのか。

大きなDBでも、実際に採用できる候補者プールはずっと小さくなる

たとえば製造企業が、ある装置領域の制御エンジニアを探すとする。一定の経験年数、量産設備、勤務地、報酬条件まで付く。

同じ『制御』でも実務は異なる。PLC中心、Motion Control、Embedded Control、Mechatronics、装置Softwareなど、肩書が近くても担当Taskは違う。

さらに転職意向、勤務地、報酬、今回の役割に必要な問題を実際に解いた経験まで確認すると、候補者プールは再び小さくなる。

そのため全DB規模と、今回の採用で現実に検討できるEffective Candidate Poolには差がある。

検索技術が良くなるほど、検索前の定義が重要になる

企業や採用チームが広い外部人材プールを直接検索できる技術は進歩している。候補者を探すスピードと範囲は今後も改善するだろう。

しかし検索可能人数が増えることと、採用問題が自動的に簡単になることは同じではない。

検索は入力条件の中で人を見つける。問題は、その入力条件自体が正しいかどうかだ。

必要なCapabilityを誤って定義したり、肩書・業界・年数を必要以上に固定すれば、大きなDBでも誤って描いた市場の中だけで精密になる。

検索技術が進むほど、Searchとその前段のMarket Definitionを分けて考える必要がある。

DBは『持っている人』、Talent Marketは『探すべき人』まで含む

既存DBから近い人を素早く探すことは効率的な出発点だ。

しかし十分な候補がいなければ、『同じCapabilityを持つ人は別の職種や業界のどこにいるか』を考える必要がある。

Equipment Control、Motion Control、Factory Automation、Mechatronics、Machine Vision、Embedded Software、Servo・PLC、System Integrationなどの経験は、役割によって隣接候補になり得る。

重要なのは無制限に広げることではない。どこまでが移転可能な経験で、どこから責任が違うのか、その境界を描くことだ。

JDは採用依頼書であって、完成した人材市場地図ではない

採用の出発点は通常JDだ。しかしJDに書かれた条件をそのまま検索語に変えることが常に最適とは限らない。

『特定業界10年以上』という条件でも、本当に必要なのが10年間その業界にいた事実なのか、その期間で得たと期待されるCapabilityなのかで市場は変わる。

入社前に必須の条件と、入社後に学べる条件も分ける必要がある。

難しい採用ではMust-haveとTrainableを分け、肩書よりTaskとEvidenceを見直すことが先になる場合がある。

Business CompetitorとTalent Competitorは同じとは限らない

人材を探す時、まず同業の競合企業を思い浮かべることは自然だ。

しかし同じ顧客市場で競争していなくても、同じCapabilityを採用していれば人材市場では競争相手になる。

逆に同じ業界でも採用するRoleやSkillが違えば、人材獲得では直接競合しないこともある。

BanseogはこれをBusiness Competitor ≠ Talent Competitorと捉える。難しい採用では、事業競合リストより『同じCapabilityを買っている場所』を見ることが重要になる。

だからといってDBが重要でないわけではない

大きなDBと長いネットワークは依然として強い資産だ。初期候補を早く見つけ、過去の接触を確認し、既存関係から再度アプローチできる。

Market Mappingが正しくても、候補者へ接触し、関心を作り、条件を調整できなければ採用は完了しない。

良いSearchはDBとMarket Mappingの二者択一ではない。

既存ネットワークを使いながら、必要なら検索結果の外へ出てTalent Marketを描き直せるかが重要だ。

サーチファームを比較する時、DB数と一緒に聞けること

このポジションをどのTalent Marketとして見ているか。Must-haveとTrainableをどう分けたか。どの市場をTalent Competitorと見ているか。

既存DBに候補が十分いない時、次にどこを探すのか。なぜこの候補者を推薦したのか。TaskとEvidenceで説明できるか。

そして候補者が実際に動ける状態か。転職意思、時期、勤務地、報酬条件まで確認されているか。

難しい採用では、DBの総数よりこうした問いへの答えの方がSearchの設計をよく表す場合がある。

BANSEOG VIEW | 検索性能より先に『何を検索するか』を定義する

採用しやすいポジションでは、大きなDBと高速検索が大きな効率を生む。

一方、希少専門職、経営人材、新技術領域では、正解候補が最初から既存DB内にいるとは限らない。

その時の問いは『何人持っているか』だけではない。『実際に競争しているTalent Marketはどこか』を先に定義する必要がある。

良いヘッドハンティングは既存履歴書の検索から始められる。しかし難しい採用では、その検索結果の外側を正確に描き直すところから差が生まれる。

Banseog View — Database Searchの前にTalent Marketを定義する

候補者DBはスピード、接触履歴、既存関係で重要な強みだが、全DB規模と特定ポジションの実際の採用可能プールは同じ数字ではない。

検索技術が進むほど『人を探す機能』と『誰を探すべきかを定義する判断』は分離する。誤って定義した市場を高速検索しても採用問題は解決しない。

難しい採用ではJDをCapability、Must-have、Trainable、Talent Competitorの観点から読み直し、Talent Marketの境界を先に描くことが重要だ。

参照した主な資料

本文のRole・Industry例は特定顧客や実際の案件を再現したものではなく、説明用の仮想例である。この記事はBanseogの公開Search原則のみを説明し、具体的な内部運用方法や顧客情報は含まない。