エンジニアを探すときの検索条件とターゲティング

エンジニアにスカウトを送る前の検索で、「経験年数〇年以上、言語は〇〇」だけで条件を組むと、二つのどちらかが起きます。条件が広すぎて数百人が出て、一人ひとりの経歴を読めず、一行目が定型になって返信が来ない。あるいは、歓迎の要件まで条件に入れて数人しか出ず、送る相手がいない。エンジニアの検索で最初にやるべきは、条件を増やすことでも減らすことでもなく、「要件のうち必須だけで組み、技術は『何を作ったか』で見て、工程と役割で絞る」ことです。それができると、一行目を書ける相手だけが出てきます。結論を先に書くと、検索条件は要件の「必須」だけで組み、技術は「使った」ではなく「何を作ったか」で見て、工程（設計・実装・運用）と役割（一人か、リードか、チームの一員か）で絞り、プロフィールの更新時期と記述の量で送る順を決めます。文面の型はエンジニアへのスカウト文面に、要件の作り方はエンジニアの採用要件の作り方に書いていますので、ここでは「検索条件とターゲティング」に絞ります。媒体ごとの検索の仕様には触れません。仕様は各媒体の公式情報でご確認ください。

条件は「必須」だけで組む

採用要件には、必須と歓迎があります。検索条件に入れるのは必須だけです。歓迎まで入れると対象が狭くなりすぎ、必須を外すと広くなりすぎます。

止まりやすいのは、要件に必須と歓迎の区別が無いときです。先に要件を分けます。分け方はエンジニアの採用要件の作り方に書いています。

技術は「使った」ではなく「何を作ったか」で見る

言語や基盤の名前で検索すると、「触ったことがある」人も「その技術で主要なプロダクトを作った」人も同じに出ます。検索は言語で入れても、プロフィールを読むときは「何を作ったか」で見ます。

止まりやすいのは、言語の一致だけで送るときです。「〇〇を使用」の人に「〇〇の設計を任せたい」と送っても、経歴と合わず返信は来ません。

工程と役割で絞る

技術の次に見るのは、どの工程（要件・設計・実装・運用・改善）を経験したかと、どの役割（一人で、チームの一員として、リードとして）だったかです。自社の任される範囲と合う人に絞ります。

止まりやすいのは、任される範囲が決まっていないときです。「何でもやってほしい」では絞れません。先に任される範囲を決めます。

エラベルの見解

相談で最も多い思い込みは、「検索条件を厳しくすれば、良い人だけが出てくる」というものです。実際には、歓迎の要件まで条件に入れると、要件に合う人がプロフィールに書いていないだけで検索から漏れ、数人しか出ず、送る相手がいなくなります。ある会社では、言語と基盤とツールと年数と役職を全部条件に入れて、出てくるのが十人以下で、その十人に送っても返信が無い状態でした。担当者が入って、条件を必須の「〇〇でのプロダクト開発」と「設計の経験」の二つに減らし、出てきた人のプロフィールを「何を作ったか」「工程」「役割」で読んで絞ったところ、送る相手は増え、一行目に書ける経歴の一点も見つかり、返信が来るようになりました。検索は「機械で絞る」より「必須で出して、人が読んで絞る」のほうが、エンジニアには合います。

プロフィールの読みどころ

検索で出てきた人のプロフィールを読むとき、見るところを決めておくと速くなります。

一つ目は、直近の経験です。数年前の技術より、いま何を作っているかを見ます。

二つ目は、自分で書いた文章の量です。技術の一覧だけの人より、「なぜこの技術を選んだか」「何が難しかったか」を書いている人は、一行目に触れる一点が見つかりやすい。

三つ目は、転職の意向や関心の記述です。「〇〇に関心がある」「〇〇に挑戦したい」と書いてあれば、自社の任される範囲と合うかを見ます。

四つ目は、更新の時期です。最近更新している人は動いている可能性があります。

五つ目は、経歴の一点です。一行目に書ける具体の一点（プロダクト、技術、工程、役割のどれか）が見つかるかどうか。見つからない人には送りません。

送る順の付け方

出てきた人を、全員に同じ日に送るのではなく、順を付けます。

止まりやすいのは、「せっかく出てきたから全員に」と送るときです。一行目を書けない相手に送ると、定型になり、返信が来ないうえに、その媒体でのアカウントの評価に影響することもあります。媒体の仕様は公式情報でご確認ください。

条件の保存と見直し

組んだ検索条件は、役割ごとに名前を付けて保存し、送った結果（開封、返信、面談、決定）と一緒に記録します。月に一度、「この条件で出た人のうち、返信が来たのはどんな人か」を見て、条件を直します。返信が来る人の共通点が「設計の経験がある人」なら、条件の工程を設計に寄せる。「〇〇（プロダクトの種類）を作った人」なら、検索の言葉にプロダクトの種類を足す。担当者が替わっても同じ検索ができるように、条件を担当者の頭の中に置きません。保存の仕方は検索条件の保存と使い回しに書いています。

エラベルの見解

担当する側から見ると、エンジニアの検索で会社ごとに差がつくのは、「任される範囲が決まっているか」です。条件の組み方と読み方は担当者が持てますが、任される範囲が「何でもやってほしい」だと、工程も役割も絞れず、一行目も書けません。任される範囲が「一人目として設計から」「既存チームで実装と改善」と決まっている会社では、検索は必須の二つで足り、あとはプロフィールを読めば送る相手が決まります。エラベルでスカウトの検索を担当する人には、条件を組む前に、現場のエンジニアに「この人が入ったら何を任せて、何を決めてよいか」を聞いてもらっています。それが分かると、検索も文面も一本につながります。文面の型はエンジニアへのスカウト文面に書いています。

代行に出す場合の範囲

エンジニアの検索を代行に出すなら、担当者が持つのは、要件から必須を取り出して条件を組むこと、出てきた人を「何を作ったか」「工程」「役割」で読んで絞ること、送る順を付けること、条件と結果を記録して月に一度見直すこと、です。会社が持つのは、要件の必須と歓迎の区別、任される範囲の決定、現場のエンジニアが担当者に話す時間、です。担当者がエンジニアの経歴を読める経験があるかは、担当者を選ぶときに確かめます。読めない担当者は、言語の一致だけで送ります。担当者の経歴の見方は担当者の経歴の見方に書いています。

まとめ

• 検索条件は要件の「必須」だけで組む。歓迎まで入れると狭すぎ、必須を外すと広すぎる
• 技術は「使った」ではなく「何を作ったか」で読む。言語の一致だけで送らない
• 工程（設計・実装・運用）と役割（一人・チームの一員・リード）で、任される範囲と合う人に絞る
• プロフィールは直近の経験・自分で書いた文章の量・関心・更新時期・一行目に書ける一点を見る
• 一行目に書ける一点が無い人には送らない。全員に送ると定型になる
• 条件は役割ごとに名前を付けて保存し、返信が来た人の共通点で月に一度直す

よくある質問

出てくる人が少なすぎます

条件に歓迎の要件が入っていないか、年数の下限が高すぎないか、言語や基盤を複数「かつ」で組んでいないかを見ます。必須だけにして、「または」で組み直すと増えます。それでも少ないなら、要件の必須が市場に対して多すぎる可能性があります。要件を見直すか、隣の技術からの転向を対象に入れます。要件が高すぎるときの見直し方は採用要件が高すぎるときに書いています。

出てくる人が多すぎて読めません

条件が広い（言語だけ、年数だけ）か、工程と役割で絞っていないかのどちらかです。任される範囲から工程と役割を決めて絞ります。それでも多いなら、直近の更新時期で順を付け、上から読める人数だけ読みます。全員を読む必要はなく、一行目を書ける人が月の送信数だけ見つかれば足ります。

自社の技術と少し違う技術の人にも送ってよいですか

任される範囲が「設計から」なら、言語が違っても設計の経験があれば対象になることがあります。その場合は、文面の一行目で「〇〇での設計のご経歴を拝見し、当社は〇〇ですが、設計の考え方が活きると思い」と、違いに先に触れます。触れずに送ると「読んでいない」と受け取られます。実装だけの範囲なら、言語の一致を優先します。