採用代行 / 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の候補者は、面接で「開発チームと一緒に働けるか」を確かめます。インフラの担当と人事だけの面接では、「開発チームとの関係が無い会社」と判断されます。
面接には、開発チームの責任者と、インフラを見ている人の両方が出ます。開発チームの責任者が「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の募集ではなく、運用の募集として整理し直すことを検討してください。