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向けに、絞る手順を番号付きで整理します。

1. 自社のSREの役割を一文で定義する。 「信頼性の目標を開発チームと決め、その達成のために運用の仕組みを作る」。この一文が無ければ、ここから。
2. 初日と一か月後に担う役割を書き出す。 指標を作るのか、監視に入るのか、改善から始めるのか、開発チームとの関係を作るのか。
3. 現場（開発チームの責任者とインフラを見ている人）の希望を全部書き出す。 ここでは絞らない。
4. 一つずつ、「初日に自社で担う役割が成り立つか」を問う。 成り立たないものだけ残す。
5. 残ったものが三つを超えたら、「社内の誰かが数か月補えるか」「入社後に自社で覚えられるか」を問う。 補えるもの、覚えられるもの（ツール、クラウドの種類、もう一方の領域）は歓迎へ。
6. SREの肩書と年数を、経験の中身に書き換える。 「SREとして〇年」ではなく「運用の負担を改善や自動化で減らした経験」「開発チームと協力して仕組みを作った経験」。
7. 歓迎に回したものを、優先順位を付けて三〜五つ書く。 面接で見る点になる。
8. 開発チームの責任者・インフラを見ている人・人事・経営で確認する。 「この三つがあれば、他は入社後に補える」と言えるか。

手順の要点は、「一で役割を定義する」ことです。役割が定義されていない状態で要件を議論すると、SREの概念に含まれる全部が並びます。

経歴で確かめられる要件と、面接でしか分からない要件

SREでは、肩書が実態を表さないので、確かめ方の区別がとくに重要です。

分け方の要点は、「面接で、開発チームの責任者が『一緒に働けるか』を確かめる」ことです。SREの適性の多くは、技術より、開発チームとの協力の仕方にあり、それは開発チームの責任者にしか判断できません。

転向層を母集団に入れる要件の書き方

SREの経験者が少ない以上、転向層（開発から、インフラから）を母集団に入れる要件の書き方が、採用の現実性を決めます。

書き方の要点は、「三つの転向元のどれからも応募できる要件にする」ことです。「SREの経験」を必須にすると、三つの転向元が全部外れます。経験の中身で書けば、三つの転向元とSREの経験者の全部が入ります。

要件が決まらないときの原因

原因の要点は、「開発チームとインフラの担当で、求めるものが違う」ことがSREに特有だという点です。この二者の要望を、役割の定義で一つにしないと、要件は両方の要望の足し算になります。

代行に出せる工程

分け方の要点は、「役割の定義は、開発チームの責任者を含めて社内で決める」ことです。代行は、その打ち合わせの進行と、決まったものの言語化を担えます。

エラベルの見解

担当する側から見ると、SREの要件で最も時間がかかるのは、開発チームの責任者とインフラの担当の要望を、一つの役割の定義にまとめることです。二者の要望は違うことが多く、足し算にすると誰もいない要件になります。役割を一文にする打ち合わせを、二者と人事と（代行がいれば代行と）で持ち、優先を決めると、必須は自然に三つに落ちます。

エラベルでは、SREの案件で要件が整理されていない場合、担当者の最初の仕事を「役割を一文にする打ち合わせの進行」にすることをお勧めしています。募集が始まるのは数週間遅れますが、役割が定義され、転向層も入る要件で募集を始めると、母集団が生まれます。飛ばして「SREの経験者」を待つと、数か月が過ぎます。

まとめ

• SREの必須要件は、先に役割を一文で定義し、「入社初日に自社で担う役割が成り立つか」で三つ以内に
• 要件が膨らむSRE特有の理由は定義が広い・開発とインフラの両方を求める・ツールを必須にする・SREの肩書を必須にする・年数で書く
• SREの肩書と年数は必須にしない。経験の中身（指標・改善・自動化・協力）で書く
• 開発とインフラの両方を必須にしない。役割が寄る側を必須に、もう一方を歓迎に
• 絞る手順は役割の定義→初日の役割→全部書き出す→初日に成り立つか→補えるか・覚えられるか→肩書と年数を中身に→歓迎に優先順位→四者で確認
• 転向層（開発から、インフラ運用から、インフラ構築から）が入る要件にする。母集団の現実性が決まる
• 決まらない原因に開発チームとインフラの担当で求めるものが違うことがSRE特有。役割の定義で一つに

よくある質問

SREの経験が無い人を採って、SREとして育つのですか

SREの経験者の多くは、開発かインフラのどちらかから転向して、SREの仕事をしながら育った人です。最初からSREだった人は少ない。開発の経験があって運用の改善に自ら取り組んだ人、インフラ運用で自動化や指標の導入を進めた人は、SREの仕事をすでに一部やっていて、役割と時間を与えれば育ちます。育てるには、改善に使える時間、開発チームとの協力の関係、外部のSREの経験者からの助言（あれば）が要ります。この体制が無いなら、転向層でもSREの経験者でも育たず、運用担当になります。

開発チームは「運用に強い人」、インフラの担当は「コードが書ける人」を求めています。どちらを必須にすべきですか

自社のSREの役割が、どちらに寄るかで決めます。開発チームのコードの信頼性を改善する役割なら開発の経験を必須に、インフラの運用を仕組みで改善する役割ならインフラの経験を必須に。両方を必須にすると、両方を深く持つ人を探すことになり、市場にいません。両方の要望を役割の定義の打ち合わせで出し、「まず何から」の優先を決めて、優先する側を必須に、もう一方を歓迎にします。一人目で片方を採り、二人目でもう一方を採る形もあります。

自社の監視ツールとクラウドの経験は、必須にしてよいですか

歓迎にとどめます。監視ツールもクラウドも、同種のものを使った経験があれば、数か月で移行できます。必須にすると、別のツールや別のクラウドで同じ仕事をしてきた人を弾き、市場がさらに狭くなります。「同種の監視ツールの経験」「いずれかのクラウドの設計・運用の経験」のように、種類で書き、自社のツールは「使用しているのは〇〇」と情報として求人票に書きます。候補者は、自分の経験で移行できるかを判断できます。