採用代行 / 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の採用は開発チームの採用でもある
よくある質問
インフラ運用の担当を「SRE」という名前で募集すると、応募が増えませんか
「SRE」の文字に惹かれて応募する人は増えるかもしれませんが、SREの経験者は求人票を読んで「実態は運用」と判断して見送り、運用の人は入社後に「SREと言われたのに」となります。名前で応募を増やしても、合わない人が増えるだけです。運用の募集なら「インフラエンジニア(運用)」と正直に書き、運用の改善や自動化を任せる部分があれば、それを訴求として書きます。名前を変えるより、役割を正直に書くほうが、合う人が来ます。
信頼性の指標がまだありません。SREを採る前提になりますか
指標が無いこと自体は、SREを採らない理由にはなりません。「指標を作るところから任せる」と正直に書けば、それを魅力に感じるSREの経験者はいます。一人目のSREにとって、指標を自分で設計できることは、裁量の大きさです。隠して「指標を管理してほしい」と書くと、入社後に「無いじゃないか」となります。無いなら無いと書き、「作るところから、開発チームと一緒に」と、これからやることとして示します。
開発チームが「運用はSREに任せたい」と言っています
その考え方のままSREを採ると、SREは運用担当になり、SREの経験者は入社後に離れます。SREは、開発チームと一緒に信頼性を作る役割で、開発チームが運用の一部を持ち、SREが仕組みで支える、という関係が前提です。採用の前に、開発チームの責任者と「誰が何を持つか」を決め、その関係を求人票に書きます。開発チームの考え方が変わらないなら、SREではなく運用の募集として整理するほうが、双方にとって正直です。開発チームとの関係の設計は、採用の工程の外ですが、採用の成否を決めます。