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へのスカウト文面に書いています。