エンジニア向けスカウト文面の型｜刺さる訴求と外す訴求

エンジニアにスカウトを送っても返信が来ない。送る数を増やしても変わらない。この状態の会社の文面を見ると、ほとんどが同じ形をしています。会社の紹介から始まり、事業の説明が続き、最後に「ぜひ一度お話を」で終わる。候補者の経歴には触れていない。結論を先に書くと、エンジニアへのスカウトは、一行目で候補者の経歴の具体的な一点に触れ、次に技術環境と任される範囲を書き、会社の紹介は最後に回す型にすると、同じ送信数で返信が変わります。エンジニアは、一行目で「自分の経歴を読んだか」を判断し、読んでいないと分かれば以降を読みません。母集団形成の全体はエンジニアの母集団形成に、代行に出す工程の線はエンジニア採用を代行に出す判断基準にまとめています。

エンジニアがスカウトを読まない理由

送る側は「良い会社だと伝えれば興味を持ってもらえる」と考えますが、受け取る側の事情は違います。

経験のあるエンジニアには、スカウトが日常的に届きます。全部を読む時間は無く、一行目か件名で読むかどうかを決めます。そのとき見ているのは、「この会社は自分のことを見て送っているか」です。会社の紹介から始まる文面は、誰にでも送れる文面で、自分を見ていないと分かります。その時点で閉じられます。

もう一つは、エンジニアが知りたいことと、会社が書きたいことがずれていることです。会社は、事業の成長や理念を書きたい。エンジニアは、何の技術で、どんな体制で、何を任されるかを知りたい。書きたいことを先に書き、知りたいことを後ろに書くと、知りたいことに辿り着く前に閉じられます。

この二つから、文面の型が決まります。自分を見ていると一行目で分かること、知りたいことが先にあること。

先に決めるのは文面ではなく対象

文面の型に入る前に、誰に送るかを決めます。対象が広いと、一行目で経歴に触れることができず、結局は定型文になります。

対象を決める基準は、求人の要件のうち「必須」に当たるものです。技術の領域、経験した工程、関わったプロダクトの種類。この必須で検索し、必須に当たる人だけに送ります。歓迎の要件で絞ると対象が狭くなりすぎ、必須を緩めると経歴に触れる材料が無くなります。

対象が決まると、送信数は減ります。それでよいと考えてください。減った分は、経歴に触れられない人で、送っても返信は来ません。返信が来る対象に、経歴に触れた文面を送るほうが、返信の数は増えます。対象の絞り方はスカウトの対象の絞り方も参考になります。

エラベルの見解

相談で多いのは、「月に数百通送っているのに、返信がほとんど無い」というご相談です。文面を見せていただくと、一行目が「〇〇株式会社の採用担当です」で、二行目から事業の説明が続き、候補者の名前以外は全員同じです。数百通を送る労力は、定型文を送る作業に使われていて、返信が来ない構造そのものを量産しています。

見ていて差がつくのは、「一行目を、候補者ごとに書き換えているか」です。一行目だけを変える。「〇〇（技術）で〇〇（プロダクトの種類）を開発されてきたご経歴を拝見しました。当社の〇〇のチームでは、まさにその領域で〇〇（課題）に取り組んでいます」。この一行があるだけで、候補者は「読んでいる」と分かり、続きを読みます。エラベルでは、エンジニア採用の担当者に、送信数より「一行目を変えた通数」を報告してもらっています。一行目を変えた通数と、返信数は、ほぼ連動します。

文面の型：一行目は候補者、二行目は技術、会社は最後

文面の構成を、順番と中身で示します。

型の要点は、「一と二で候補者、三から五で知りたいこと、六で会社」という順番です。会社を先に書きたくなりますが、候補者は自分に関係があると分かってから会社を読みます。

長さは、読める範囲で。一から七を全部書くと長くなりますが、エンジニアは関係があると分かれば読みます。関係が分からない短い文面より、関係が分かる長めの文面のほうが読まれます。ただし、六の会社の紹介は短くします。スカウトの長さも参考になります。

刺さる訴求と、外す訴求

エンジニアに響く訴求と、響かない、または逆効果になる訴求を整理します。

訴求の要点は、「具体性の有無」です。刺さる訴求は、全部が具体的で、外す訴求は、全部が形容詞です。エンジニアは形容詞で判断せず、名詞と数で判断します。「モダン」ではなく技術の名前、「裁量」ではなく任される判断の中身、「やりがい」ではなく課題の内容。

送った後の運用

文面が整っても、送った後の運用で返信が消えることがあります。

一つ目は、返信への対応の速さです。エンジニアが返信してきたら、その日か翌日には返す。数日空くと、候補者は「送るだけ送って、対応は遅い会社」と判断し、他社に進みます。返信の一次対応は、日中に依頼側の担当が定型で返し、詳しい返信は担当か代行が行う、という分担を決めておきます。

二つ目は、返信の次の一歩の軽さです。返信が来た候補者に、いきなり応募書類を求めると止まります。まず短い面談（技術の話ができる人が出る）を提案し、そこで互いに合うかを見る。面談の相手が技術の分からない人事だけだと、候補者は「技術の話ができない会社」と判断します。

三つ目は、送った記録です。誰に、いつ、どの文面を送り、返信があったか無かったかを、依頼側の環境で記録します。同じ候補者に二度送る、返信があった候補者を放置する、という事故を防ぎます。スカウトの重複防止も参考になります。

代行に出せる範囲

スカウトの工程で、代行に出せる部分と、社内で持つ部分を整理します。

分け方の要点は、「文面の中身（技術環境、範囲、課題）は現場から出て、それを候補者ごとの文面にする作業は代行に出せる」ことです。中身が無いまま代行に「文面を書いてください」と頼むと、代行は形容詞で埋めるしかなく、外す訴求になります。

エラベルの見解

担当する側から見ると、エンジニアへのスカウトは、文面を書く技術より、候補者の経歴を読む時間で決まります。一行目を候補者ごとに書くには、経歴を読んで、自社の募集と重なる一点を見つける必要があります。一通あたりの時間は、定型文の数倍かかります。送信数は減りますが、返信は増えます。依頼側から「送信数が少ない」と言われることがあるので、報告では送信数と返信数を並べて、一行目を変えた通数の返信率を示すようにしています。

エラベルでは、エンジニア採用のスカウトを担当者にお願いするとき、最初の一か月は「対象を絞り、一行目を変える」ことに集中し、送信数の目標を置かないようお伝えしています。送信数の目標を置くと、担当者は定型文に戻ります。返信率が出てから、その率を保ったまま対象を広げる順番が、結果的に返信の総数を増やします。

まとめ

• エンジニアは一行目で「自分の経歴を読んだか」を判断し、読んでいないと分かれば閉じる
• 先に決めるのは対象。必須の要件で絞る。送信数は減ってよい
• 文面の型は一行目に候補者の経歴の一点→重なる理由→技術環境→任される範囲→技術的な課題→会社の紹介（短く）→負担の小さい次の一歩
• 刺さる訴求は具体的な名詞と数（技術名、範囲、課題、体制）。外す訴求は形容詞（モダン、裁量、やりがい、アットホーム）
• 送った後は返信にその日か翌日・軽い面談を先に・技術の話ができる人が出る・記録を残す
• 代行に出せるのは検索・一行目の個別化・送信・一次対応・面談の設定・記録。文面の中身は現場が出す

よくある質問

会社の紹介を後ろに回すと、どんな会社か分からないまま読まれなくなりませんか

エンジニアは、自分に関係があると分かってから会社を調べます。一行目で関係が分かれば、会社の紹介が後ろにあっても読み、会社名で検索もします。会社の紹介が先にあっても、関係が分からなければ、会社を調べる前に閉じられます。会社の紹介は、消すのではなく、候補者に関係があると伝えたあとに、短く置きます。事業の詳しい説明は、面談で話せば足ります。

一行目を候補者ごとに変えると、一通に時間がかかりすぎます

かかります。ただ、定型文を数百通送って返信がゼロに近い状態と、一行目を変えた文面を数十通送って返信が来る状態を比べると、後者のほうが面接に進む数は多くなります。時間は、送信数ではなく返信数に対して使うものです。時間が足りないなら、対象をさらに絞って、通数を減らします。一行目を変えられない候補者は、対象から外れているということです。

スカウトの文面作成だけを外に出せますか

出せますが、条件があります。文面の中身（技術環境、任される範囲、技術的な課題）は、現場のエンジニアから出す必要があり、外部はそれを候補者に伝わる言葉に直し、候補者ごとに一行目を書く役になります。中身が無い状態で「文面を書いてください」と頼むと、外部は形容詞で埋めるしかありません。現場が中身を出す一時間の打ち合わせを先に確保し、そのうえで文面の作成と個別化を外に出す形なら、機能します。