SRE向けスカウト文面の型｜刺さる訴求と外す訴求

SREにスカウトを送っても返信が来ない会社の文面には、共通点があります。「SREを募集しています」と肩書で始まり、業務内容が「インフラの運用・監視・改善」で、信頼性の指標も開発チームとの関係も書かれていない。SREの経験者はこれを読んで、「運用担当をSREと呼んでいる会社」と判断し、閉じます。結論を先に書くと、SREへのスカウトは、肩書ではなく経験（指標の設計、運用の改善、自動化、開発チームとの協力）で対象を絞り、一行目でその経験の一点に触れ、自社の役割の定義・指標の現状・改善の時間・開発チームとの関係を先に書き、会社の紹介は後ろに回す型にすると、返信が変わります。母集団形成の全体はSREの母集団形成に、インフラエンジニア向けの文面はインフラエンジニア向けスカウト文面の型にまとめています。

SREがスカウトを読まない理由

開発職・インフラ職と共通する理由（定型文、条件の不記載）に加えて、SREに特有の理由があります。

一つ目は、「SRE」という言葉が信用されていないことです。運用担当の呼び替えにSREを使う会社が多く、SREの経験者は「SRE募集」の文字を見ても、実態を疑います。肩書ではなく、役割の中身（信頼性の目標、改善、開発チームとの協力）が書かれていないと、読まれません。

二つ目は、開発チームとの関係を最初に確かめることです。SREの経験者は、「開発チームが運用を全部SREに押し付ける会社」を最も避けます。文面に開発チームとの関係（誰が何を持つか）が無いと、「押し付ける会社かもしれない」と読まれます。

三つ目は、改善に使える時間を見ることです。障害対応で手一杯で、改善の時間が無い会社では、SREは運用担当になります。改善の時間があるか、無いならどう作るかが書かれていないと、「運用に埋もれる」と読まれます。

この三つから、文面の型が決まります。肩書ではなく役割、開発チームとの関係、改善の時間。

先に決めるのは対象：肩書ではなく経験で絞る

SREのスカウトでは、対象の絞り方が結果を分けます。「SRE」の肩書で検索すると、運用担当の呼び替えの人も、SREの経験者も混ざり、対象が広がります。

検索の条件は、経験で絞ります。信頼性の指標を設計した経験、運用の負担を改善や自動化で減らした経験、開発チームと協力して仕組みを作った経験。この経験があれば、肩書がSREでなくても対象に入り、肩書がSREでもこの経験が無ければ外します。

対象には、SREの経験者だけでなく、転向の素養がある層を含めます。開発エンジニアで運用や信頼性の改善を自ら進めた人、インフラ運用で自動化や指標の導入を進めた人。この層は肩書では見つからず、経験の中身で見つけます。

対象を経験で絞ると、検索の手間は増えますが、一行目で触れる一点が見つかり、返信が来ます。スカウトの対象の絞り方も参考になります。

エラベルの見解

相談で多いのは、「SREの肩書の人に数十通送ったが、返信がゼロ」というご相談です。文面を見ると、一行目が「SREを募集しております」で、業務内容が運用・監視・改善、開発チームとの関係も指標も無い。SREの経験者から見ると、疑う材料しかありません。肩書で探して肩書で呼びかけると、SREの経験者ほど反応しません。

見ていて差がつくのは、「一行目で、候補者の改善や指標の経験の一点に触れ、自社の役割の定義を二行目で言えるか」です。「〇〇の指標を設計して運用の負担を減らされたご経歴を拝見しました。当社では、信頼性の目標を開発チームと決めるところから、一人目のSREとして任せたいと考えています」。この二行で、SREの経験者は「役割を分かっている会社」と判断します。エラベルでは、SREの担当者に、肩書での検索を止め、経験で絞ることを最初にお願いしています。通数は減りますが、返信は増えます。

文面の型：一行目は候補者の経験、二行目は役割の定義

型の要点は、「二で役割の定義を、三から五で信頼性の実態を、会社より前に書く」ことです。SREの経験者は、会社の事業より、役割と実態で判断します。

九の「開発チームの責任者も出る」は、SREの候補者にとって大きな判断材料です。開発チームの責任者が面談に出る会社は、開発チームがSREの採用に関わっていることの証拠になります。

刺さる訴求と、外す訴求

訴求の要点は、「SREの経験者は、会社の実態を疑いながら読む」ことです。刺さる訴求は、実態を正直に、具体的に書いたもので、外す訴求は、肩書と形容詞で実態を隠したものです。整っていない実態を正直に書くほうが、「作る人」を探すスカウトとして響きます。

送った後の運用

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

一つ目は、面談に開発チームの責任者が出ることです。SREの候補者は、面談で開発チームの責任者と話し、「この人たちと一緒に信頼性を作れるか」を確かめます。インフラの担当と人事だけの面談では、確かめられず、見送ります。

二つ目は、面談で実態を隠さないことです。指標が無い、改善の時間が無い、開発チームが運用を持ちたがらない。この実態を面談で正直に話し、「だから、作るところから任せたい」と伝えます。隠して入社してもらっても、すぐに分かり、離れます。

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

代行に出せる範囲

分け方の要点は、「役割の定義と開発チームとの関係は、社内でしか出せない」ことです。代行に「SRE向けの文面を書いてください」と頼んでも、この二つが社内から出ていなければ、代行は肩書と形容詞で埋めるしかなく、外す訴求になります。

エラベルの見解

担当する側から見ると、SREのスカウトで最も時間がかかるのは、依頼側から役割の定義と開発チームとの関係を引き出すことです。依頼側は「SREを採りたい」と言いますが、SREに何を任せ、開発チームが何を持つかは、決まっていないことが多い。ここを決めずに文面を書くと、SREの経験者に疑われる文面になります。

エラベルでは、SREの案件で担当者を紹介するとき、依頼側に役割の一文と、開発チームとの関係を先に決めていただき、それが担当者に渡ってから文面に入るようお伝えしています。決まっていない場合、担当者の最初の仕事は、この二つを引き出す打ち合わせの進行です。スカウトの送信数は、その後です。

まとめ

• SREがスカウトを読まない理由は「SRE」の言葉が信用されていない・開発チームとの関係を最初に確かめる・改善の時間を見る。共通の理由（定型文、条件の不記載）に加えて
• 先に決めるのは対象。肩書ではなく経験（指標・改善・自動化・協力）で絞る。転向の素養がある層を含める
• 文面の型は一行目に候補者の経験の一点→役割の定義→指標の現状→改善の時間→開発チームとの関係→構成→体制→会社の紹介（短く）→開発チームの責任者も出る面談
• 刺さる訴求は実態を正直に、具体的に。外す訴求は肩書と形容詞で実態を隠す
• 面談には開発チームの責任者が出て、実態を隠さない
• 代行に出せるのは経験で絞った検索・個別化・送信・一次対応・面談の設定・記録。役割の定義と開発チームとの関係は社内から

よくある質問

「SRE」の肩書で検索しないと、対象が見つからない気がします

肩書で検索すると、運用担当の呼び替えの人が多く混ざり、SREの経験者は少数です。経験（指標の設計、改善、自動化、開発チームとの協力）で検索すると、肩書がSREでない人も含めて、SREの素養がある人が見つかります。開発エンジニアで運用の改善を進めた人、インフラ運用で自動化を進めた人は、肩書では出てきません。経験で検索する手間はかかりますが、一行目で触れる一点が見つかり、返信が来る対象になります。肩書は、検索の一つの条件にとどめ、経験を主にします。

指標も改善の時間も開発チームとの関係も、まだ無い状態です。正直に書くと返信が来ませんか

正直に書くと、整った体制を求める人からは返信が来ません。その人は入社後に「聞いていた話と違う」となる人なので、最初から来ないほうが互いのためです。「指標を作るところから、改善の時間を確保する体制を作るところから、開発チームとの関係を設計するところから、一人目として任せたい」と書くと、仕組みを作ることに魅力を感じる人から返信が来ます。一人目のSREにとって、全部を設計できることは裁量の大きさです。整っていないことを隠すより、「作る人」を探すスカウトとして書くほうが、合う人に届きます。

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

出せますが、役割の定義・指標の現状・改善の時間・開発チームとの関係の四つは、社内から出す必要があります。この四つが無い状態で「SRE向けの文面を」と頼むと、外部は肩書と形容詞で埋めるしかなく、SREの経験者に疑われる文面になります。社内で四つを決める打ち合わせ（開発チームの責任者を含めて一時間）を先に持ち、そのうえで文面の作成と個別化を外に出す形なら、機能します。四つを決める打ち合わせの進行を外部に手伝ってもらうこともできます。