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

インフラエンジニアにスカウトを送っても返信が来ない会社の文面を見ると、二つの共通点があります。運用の人にも構築の人にも同じ文面を送っていることと、夜間対応やオンコールの条件が書かれていないことです。前者は「自分向けではない」と読まれ、後者は「聞くまでもなく条件が合わないだろう」と読まれます。結論を先に書くと、インフラエンジニアへのスカウトは、運用か構築かで対象と文面を分け、一行目で候補者の環境の規模や移行・構築の経験に触れ、自社の構成・これからやること・働き方の条件を先に書き、会社の紹介は後ろに回す型にすると、返信が変わります。母集団形成の全体はインフラエンジニアの母集団形成に、開発エンジニア向けの文面の型はエンジニア向けスカウト文面の型にまとめています。

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

開発エンジニアと共通する理由（会社の紹介から始まる定型文は読まれない）に加えて、インフラ職に特有の理由があります。

一つ目は、運用の人と構築の人で、求めているものが違うことです。運用の人は、安定した環境と、夜間対応の少なさ、資格や技術を伸ばせる環境を見ます。構築の人は、設計から任されるか、新しい技術を選定できるか、移行や自動化の課題があるかを見ます。同じ文面で両方に送ると、どちらにも刺さりません。

二つ目は、働き方の条件が最初の関心事だということです。夜間対応、オンコール、休日メンテナンス、常駐か自社か。インフラ職の候補者は、条件を確認してから中身を読みます。条件が書かれていないスカウトは、「書けない事情がある」と読まれます。

三つ目は、経歴に規模が出ることです。インフラ職の経歴には、担当した環境の規模（台数、拠点、利用者）が出ます。候補者は、自分の規模と自社の規模が合うかを見ます。自社の規模が書かれていないスカウトは、判断ができず、閉じられます。

この三つから、文面の型が決まります。層で分ける、条件を先に書く、規模を書く。

先に決めるのは対象：運用か構築か

文面の前に、誰に送るかを決めます。インフラ職では、「運用か構築か」の決定が対象の絞り込みそのものです。

構築の人を探すなら、検索の条件を「設計」「構築」「移行」「自動化」「コードで管理」の経験に絞り、「運用」「監視」「保守」だけの経歴は外します。運用の人を探すなら逆に、「運用」「監視」「障害対応」の経験で絞ります。両方を一つの検索で拾おうとすると、対象が広がり、一行目で触れる一点が選べず、定型文になります。

対象の中でも、規模で絞ります。自社の環境と近い規模を担当した人。規模が大きすぎる人は「小さい環境では物足りない」と見送り、小さすぎる人は「大きい環境は不安」と見送ります。近い規模の人に、「同じくらいの規模で」と一行目で触れると、返信が来ます。

対象を決めると送信数は減りますが、減った分は返信が来ない人です。スカウトの対象の絞り方も参考になります。

エラベルの見解

相談で多いのは、「インフラエンジニアに月に百通以上送っているが、返信が数件」というご相談です。文面を見ると、一行目が「〇〇株式会社の採用担当です」、二行目が事業の説明、条件は「詳細は面談で」。運用の人にも構築の人にも同じ文面です。候補者から見ると、自分の層に向けたものか分からず、条件も分からず、会社の説明から始まる。三つの理由が全部そろっています。

見ていて差がつくのは、「条件を、スカウトの中に書けているか」です。「夜間対応は当番制で月に数回、翌日は勤務の調整あり。リモートは週の半分」と書く。条件が合わない人は返信せず、合う人は「条件が明確な会社」として返信します。エラベルでは、インフラ職の担当者に、スカウトの文面に働き方の条件を入れることを最初にお願いしています。条件を書くと返信の総数は減りますが、返信した人と面談したときの辞退が減り、面接に進む数は増えます。

文面の型：一行目は候補者の環境、次に自社の構成と条件

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

型の要点は、「五の条件を、会社の紹介より前に書く」ことです。インフラ職の候補者は、条件を確認してから中身を読みます。条件が後ろにあると、辿り着く前に閉じられます。

刺さる訴求と、外す訴求

インフラ職に響く訴求と、響かない訴求を、運用の人と構築の人で分けて整理します。

訴求の要点は、「運用の人と構築の人で、刺さるものが逆になることがある」点です。「設計から任せる」は構築の人には刺さり、運用の人には負担に見えます。「環境が安定している」は運用の人には刺さり、構築の人には課題が無いように見えます。層で分けて書きます。

送った後の運用

返信が来たあとの運用で、インフラ職に特有の注意を整理します。

一つ目は、面談の相手です。インフラ職の候補者は、面談で自社の構成を見たがります。技術の分からない人事だけが出る面談では、「構成の話ができない会社」と判断されます。面談には、インフラを見ている人（社内の担当か、委託先の担当か、外部の技術の分かる人）が出ます。

二つ目は、条件の再確認です。スカウトに書いた条件を、面談で改めて伝えます。書いてあっても、候補者は読み飛ばしていることがあります。面談で確認して、その時点で合わなければ、互いの時間を使わずに済みます。

三つ目は、返信の速さと記録です。開発職と同じく、返信にはその日か翌日、送った記録は依頼側の環境に。スカウトの重複防止も参考になります。

代行に出せる範囲

分け方の要点は、「条件と構成は現場から出る」ことです。夜間対応の頻度、オンコールの体制、自社の構成は、外部が知りようがなく、現場が出した中身を代行が文面にします。中身が無いまま代行に頼むと、「詳細は面談で」になり、外す訴求になります。

エラベルの見解

担当する側から見ると、インフラ職のスカウトで最も効くのは、条件を書くことです。書けば返信の総数は減りますが、返信した人は条件を受け入れていて、面談後の辞退が減ります。依頼側から「条件を書くと不利では」と言われることがあるので、報告では返信数だけでなく、面談後の辞退率と面接に進んだ数を並べて示しています。

エラベルでは、インフラ職の案件で担当者を紹介するとき、依頼側に「運用か構築か」「働き方の条件」「自社の構成」の三つを先に決めていただくようお伝えしています。この三つが担当者に渡れば、担当者は最初の週から層で分けた文面を書けます。渡らなければ、担当者の最初の仕事は、この三つを引き出す打ち合わせになります。

まとめ

• インフラ職がスカウトを読まない理由は運用と構築で求めるものが違う・条件が最初の関心事・規模で判断する。開発職と共通の理由（定型文）に加えて
• 先に決めるのは運用か構築か。層と規模で対象を絞る
• 文面の型は一行目に候補者の環境の一点→重なる理由→自社の構成→これからやること→働き方の条件→体制→会社の紹介（短く）→短い面談
• 条件を会社の紹介より前に書く。隠すと面談後に辞退される
• 刺さる訴求は構築の人には設計・課題・技術選定、運用の人には安定・当番の少なさ・制度。両方に外すのは形容詞と条件の不記載
• 面談には構成の話ができる人が出る。代行に出せるのは検索・個別化・送信・一次対応・面談の設定・記録

よくある質問

夜間対応の条件をスカウトに書くと、返信が減りませんか

減ります。減るのは、その条件で働けない人で、その人は面談や内定の段階で辞退するので、最初から返信しないほうが互いの時間を使いません。書き方は、有無だけでなく、頻度、体制、手当、翌日の扱い、改善の方針まで書くと、「それなら」と返信する人がいます。「詳細は面談で」と書くと、最悪を想定して返信しない人が増え、返信した人も面談で条件を聞いて辞退します。書いて減る返信より、書かずに面談後に消える候補者のほうが、損が大きい。

運用と構築の両方に送りたいのですが、文面を二つ作る必要がありますか

あります。一つの文面で両方に刺さる書き方は無く、両方に書くとどちらにも刺さりません。運用の人向けと構築の人向けで、一行目・これからやること・訴求を変えた二つの型を作り、検索も層で分けて、それぞれに送ります。手間は倍になりますが、返信は一つの文面で両方に送るより増えます。どちらか一方しか作れないなら、優先する層（採りたい層）の文面だけを作り、その層にだけ送ります。

自社の構成を書くと、セキュリティ上の懸念がありませんか

書くのは、候補者が判断に使う粒度（オンプレかクラウドか、おおよその規模、主要な技術の名前）で、構成図や設定の詳細ではありません。この粒度は、求人票や採用サイトに書かれている範囲と同じで、懸念は通常ありません。詳細は、面談で、必要な範囲で、必要なら秘密保持の合意のもとで示します。構成をまったく書かないスカウトは、候補者が判断できず、返信が来ません。書く粒度を社内で決めて、その範囲で書きます。