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の質問（指標、開発との関係、リリースの決め方）に答えられません。

送る前の確認

返信が来ないときの直す順番

一箇所ずつ変えます。変え方はスカウト文面のABテストのやり方に書いています。

エラベルの見解

担当する側から見ると、SRE向けの文面で会社ごとに差がつくのは、「開発チームの責任者が、文面の内容を確認し、面談に出ることに合意しているか」です。件名と一行目は担当者が書けますが、指標の現状と開発との関係は、開発の責任者にしか語れず、人事や担当者が想像で書くと実態とずれます。開発の責任者に「指標は何を見ていて、いまどの水準か」「SREに何を決めてほしいか」「リリースにどう関わってもらうか」を聞いて書き、その責任者が面談に出る文面は、SREに「開発が本気で迎えている」と伝わります。エラベルでスカウト文面を担当する人には、文面を書く前に、開発の責任者に実態を聞き、面談に出る合意を取ってもらっています。刺さる訴求と外す訴求はSRE向けスカウト文面の型に書いています。

代行に出す場合の範囲

担当者が持つのは、候補者の経験（指標・改善・自動化・開発との協力）を読んで件名と一行目を相手ごとに書くこと、開発の責任者に聞いた定義と指標の現状と開発との関係を本文にすること、送る前の確認、返信の記録と直す順番の提案、です。会社が持つのは、自社でのSREの定義、指標の現状と改善の時間の事実、開発チームとの関係の決定、開発の責任者が文面を確認して面談に出ること、条件の幅、です。開発の責任者が担当者に話す時間と面談に出る時間を取れないと、SREへのスカウトは成立しません。出す前に確保します。

まとめ

• 先に自社でのSREの定義を決める。実態が運用なら運用と書いたほうが合う人が来る
• 件名は「相手の経験の一点（指標・改善・自動化）＋自社の実態が分かる役割」。肩書だけの件名は開かれない
• 本文は一行目に相手の経験の一点→役割の定義→指標の現状→改善の時間の割合→開発との関係→構成と体制→条件の幅→開発の責任者も出る面談への締め
• 指標の現状と改善の時間を正直に書く。悪くても正直なほうが返信は来る
• 開発チームとの関係を書き、開発の責任者が面談に出る。人事だけの面談ではSREの質問に答えられない
• 返信が来ないときは件名→定義と指標の正直さ→面談に開発が出たか→実態の一致の順に直す

よくある質問

指標をまだ置けていません。書いても来ないのでは

「まだ置けていない。一人目として定義から任せたい」と正直に書きます。定義から作りたいSREは一定数いて、その人たちには「白紙から作れる」が材料になります。指標があるように見せて面談で無いと分かると、その場で辞退されます。無いものは無いと書き、そのうえで何を任せるかを書きます。

開発の責任者が面談に出る時間を取れません

その状態でSREにスカウトを送ることはお勧めしません。SREは開発チームとの関係を最初に確かめる職種で、開発の責任者が出ない面談では判断できず、辞退につながります。三十分でよいので、開発の責任者の枠を確保してから送ります。確保できないなら、いまはSREではなく、運用の改善を任せる役割として書くほうが、合う人が来ます。

「SRE」と名乗ってよいか迷っています

自社でのSREの定義を書けるなら名乗ってよく、書けないなら名乗らないほうがよい、が目安です。定義が「運用と障害対応」だけなら、運用エンジニアやインフラエンジニアとして書き、「改善の時間を確保して信頼性を上げていきたい」と将来の方向を添えます。肩書を先に付けて実態が追いつかないと、SREの経験者からの信頼を失います。役割の定義の作り方はSREの採用要件の作り方に書いています。