OfferBoxでエンジニア志望の学生を見つける検索の考え方｜作ったもので探す

OfferBoxでエンジニアを採るとき、検索条件で最初にぶつかるのは「情報系の専攻と技術名で絞ると足りない、広げると人事では読めない」という問題です。結論から言うと、エンジニアの検索は技術名で探すのではなく「自分で何かを作ったことがあるか」で探し、検索結果を人事とエンジニアの二段で読む前提で組みます。 技術名が一致する学生を探すのは、自社の技術をすでに使ったことがある学生だけを探すことになり、新卒採用では相手が足りません。この記事では、エンジニア志望の学生がプロフィールに何を書いているか、検索条件の組み方、制作物や研究の読み方、文面と面談への接続を整理します。検索項目の名称や仕様には触れず、考え方だけを書きます。現在の項目は管理画面とヘルプで確認してください。文面の書き方はOfferBoxでエンジニアを採るオファー文面の書き方で書きました。

エンジニア志望の学生がプロフィールに書いていること

エンジニアを志望する学生のプロフィールには、技術名より先に「何を作ったか」「何を調べたか」が書かれています。技術名は、その説明の中に付随して出てくることが多く、技術名だけで探すと、書き方の違いで見落とします。

技術名を見ないという意味ではありません。技術名は「あればよい条件」として読み、探す手がかりは「作ったことがあるか」「詰まったときにどうしたか」に置きます。志望職種に「エンジニア」と書いていても、作ったものの記述がない学生もいれば、志望職種に別の職種を書いていても、研究でプログラムを書いている学生もいます。志望職種の項目は、学生の「今の仮の答え」として読みます。

検索・ターゲットの考え方｜技術名ではなく「作ったことがあるか」で探す

エンジニアの検索条件は、次の手順で組みます。

1. 「どのエンジニアか」の一言を決める：自社製品か受託か、Webか組み込みか、設計から関わるか。面談に出るエンジニアと決める
2. その開発で求める行動を三つ書き出す：「作り切る」「動かないときに原因を探す」「人と分担して作る」など、学生の経験に見つかる形で
3. 条件を三段に分ける：譲れない条件、あればよい条件、見ない条件
4. 専攻と技術名は、あればよい条件に置く：譲れない条件にしない
5. 検索の名前を「どのエンジニアか」で付ける：「エンジニア」の一語で付けない

三段の分け方は、営業職と同じ考え方です。

• 譲れない条件：卒業年、勤務地の可否、入社時期など、面談まで進めても変えられないもの。ここは少なく
• あればよい条件：情報系の専攻、志望職種、使ったことがある技術。入っていれば優先するが、外れていても読む
• 見ない条件：大学名、学部の系統など、作ったものと関係のない項目

技術名を譲れない条件にすると、検索結果は少なくなり、その中にいるのは「自社と同じ技術をすでに使った学生」だけです。新卒のエンジニア採用は、入社後に自社の技術を学ぶ前提なので、探すのは「学べる学生」であって「学んだ学生」ではありません。条件の絞りすぎと広げすぎの見分け方はOfferBoxの検索条件の組み方で書きました。

エージェントベストの見解

エンジニアの検索で、発注側がよく誤解しているのは「技術名で絞れば、エンジニアに向く学生が見つかる」という考え方です。技術名は、学生が書いた場合にだけ検索に掛かります。同じことを作っていても、技術名を書く学生と、作ったものだけを書く学生がいて、後者は技術名の検索から外れます。当社は3媒体すべての販売パートナーとしてOfferBoxの契約後の運用を見ていますが、エンジニア採用で承認と面談が続いている会社は、技術名の一致ではなく「作ったものがあるか」「詰まったときに何をしたか」で読んでいます。技術名の一致で絞った会社は、送る相手がすぐに尽き、送れる学生を探して条件を緩めた結果、文面が会社紹介になり、承認が落ちる、という流れをたどります。技術名は、文面で触れる材料としては使えますが、探す条件としては細すぎます。検索は「作ったことがあるか」で広めに組み、技術名は読んだあとに文面で使う。この使い分けが、送る数と承認を両立させます。

制作物と研究をどう読むか

検索で絞ったあと、送る相手を決めるのは、制作物や研究の記述です。エンジニアの場合、自由記述で見るのは次の四つです。

• 何を作ったか、何のために作ったか：対象があるか。「勉強した」だけでなく「作った」があるか
• 詰まった箇所と、どう解いたか：うまくいかなかった記述があるか。一度で動いた話より、原因を探した話
• 一人で作ったか、人と作ったか：どちらが良いということではなく、自社の開発の形に近いのはどちらか
• 続いているか：一度作って終わりか、直し続けているか。公開後に手を入れた記述があるか

技術名の多さや、使った技術の新しさは見ません。技術の水準は、人事が自由記述から判断しようとすると、言葉の印象で決めることになります。人事が見るのは上の四つで、技術の近さの判断はエンジニアに回します。プロフィール全体の読み方はOfferBoxの学生プロフィールの読み方で書きました。

情報系だけでは足りないときの広げ方

情報系の専攻だけでは送る相手が足りないとき、条件を広げる順番があります。

1. 専攻の絞りを外す：理系全般、さらに専攻を問わない範囲へ。研究でプログラムを書いた学生、独学で作った学生が見つかる
2. 志望職種の絞りを外す：エンジニア以外を選んでいる学生の中にも、作ったものを書いている学生がいる
3. 「作ったもの」の絞りを緩める：作ったものがなくても、学び始めた動機が書いてある学生まで広げる

広げる順番は、開発との関係が薄い条件から外します。三つ目まで広げると、文面の書き出しが変わります。作ったものがある学生には自社の開発との近さを、学び始めた学生には動機への言及を書きます。検索を広げるときは、「この検索の相手には、書き出しに何を置くか」を一緒に決めます。理系学生全般の考え方はOfferBoxで理系学生を採る、多くのオファーを受ける理系学生に届く文面は理系学生の取り合いに負けるときのOfferBox運用で書きました。

選考への接続

検索で見つけた学生は、文面と面談でも「同じ制作物」で見ます。

• 検索で読んだ制作物・研究を、文面の書き出しに使う：読んだ事実と、自社の開発のどこに近いかを書く。評価はしない
• 面談で、同じ制作物を学生に聞く：何を作り、どこで詰まり、どう解いたか。聞くのは面談に出るエンジニア
• コードや制作物を見せてもらうなら、文面か面談前に伝える：当日に求めない
• 面談の担当は、「どのエンジニアか」を決めたエンジニア：検索の一言を決めた人が、面談でその開発を話す

検索、文面、面談で見るものが揃っていると、「どの条件で見つけた学生が、面談まで来て、選考に進んだか」が読めます。面談の組み方はOfferBoxの面談設計で書きました。

エージェントベストの見解

エンジニアの検索条件を組む前に、当社が先に決めてもらうのは「検索結果を誰が読むか」です。営業職の検索は、求める行動が決まれば人事だけで読めます。エンジニアの検索は、「作ったものがあるか」までは人事で読めますが、「自社の開発に近いか」は人事では判断できません。ここをエンジニアに回す時間を決めずに検索を組むと、人事が技術名の印象で送る相手を決めるか、エンジニアに全件を回して止まるか、のどちらかになります。当社が運用を見ている会社で回っているのは、人事が一次で「作ったものがある学生」に絞り、週に一度、エンジニアが二次で「近い・遠い」を付ける、という二段の読み方です。エンジニアの時間は週に一度のまとまった枠だけで済み、人事は技術の判断をしなくてよくなります。検索条件は、この二段の読み方が回る量に合わせて広さを決めます。条件を先に組んで、読む人をあとで探す順番だと、検索は組めても運用が止まります。現場社員に頼むことを絞る考え方はOfferBoxの運用に現場社員を巻き込む方法で書きました。

社内の分担

エンジニアに頼むのは、一言と、週に一度の二次の判断と、面談の三つです。一次の絞り込みと送る作業は人事が持ちます。二次の判断を「近い・遠い」の二択にしておくと、エンジニアの負担が読め、続けてもらえます。

やりがちな失敗

まとめ

• エンジニア志望の学生は、技術名より「何を作ったか」で自分を書く。技術名ではなく「作ったことがあるか」で探す
• 「どのエンジニアか」の一言を面談に出るエンジニアと決め、求める行動を三つ書き出す
• 条件は譲れない・あればよい・見ないの三段。専攻と技術名はあればよい条件
• 自由記述は、何を作ったか・詰まった箇所・一人かチームか・続いているか、の四つで読む。技術の水準は人事が判断しない
• 一次を人事、二次をエンジニアが週に一度。検索の広さは、この二段が回る量に合わせる

よくある質問

使っている技術が特殊で、経験者を探したいのですが

新卒採用では、その技術をすでに使った学生はごく少なく、技術名で絞ると相手が尽きます。探すのは「近い分野で作ったことがある学生」「動かないときに原因を探した学生」です。技術の特殊さは、文面で「入社後にどう学ぶか、誰が見るか」として書き、面談でエンジニアが話します。経験者に限る採用は、媒体で探すより、紹介で探すほうが合う場合があります。

エンジニアが忙しく、検索結果を見てもらえません

全件を見てもらう必要はありません。人事が一次で「作ったものがある学生」に絞り、週に一度、まとまった枠で「近い・遠い」を付けてもらうだけにします。二択にしておけば、一人あたりの判断は短く済みます。それも難しい場合は、「どのエンジニアか」の一言と、求める行動の三つだけを決めてもらい、人事が四つの読み方で送る相手を決めます。文面で技術の言葉を書かない構成にしておけば、人事だけでも送れます。

エンジニアの検索設計は、運用代行に頼めますか

頼めますが、「どのエンジニアか」の一言と、求める行動の三つ、二次の判断をするエンジニアは社内で決めておきます。代行に任せられるのは、決まった行動で検索を組み、一次で「作ったものがある学生」に絞り、エンジニアの二次に回す作業です。二次の判断まで代行に任せると、技術の近さを社外の人が決めることになり、面談でずれが出ます。範囲の決め方は運用代行に任せる範囲で書きました。