はじめに ― SRE採用はスキルシート勝負ではない
なぜSRE採用だけ“読み解く力”が重視されるのか
SRE（Site Reliability Engineering）は、インフラや運用の延長線上にある職種と思われがちですが、採用現場ではまったく違う評価軸が用いられます。理由はシンプルで、SREは「技術だけで成果が出せる職種ではない」からです。
可用性、レイテンシ、デプロイ頻度、エラーバジェット──扱う領域はどれも技術的に見えますが、その裏には必ず「誰が判断し、誰と合意し、誰がアクセルやブレーキを踏むのか」という関係性の力学が存在します。
採用で問われるのは“技術では説明できない部分”
SRE採用で特に重視されるのは、次の3つです。
- 観測 → 分析 → 改善のループを回した経験があるか
- 関係者との摩擦をどう扱ってきたか
- 信頼性を「技術 × ビジネス × 組織」の観点で語れるか
つまり、単なる技術スタックではなく、判断の軸・物語・関係性の作り方を問われる職種だと言えます。
採用の第一次選考は“スキルシート”ではなく“観測ログ”
ツール名の羅列だけでは、何も伝わらない
SREの選考でよくあるのが、「Kubernetes / Terraform / Prometheus / Grafana…」といったツール名やクラウドサービスの羅列です。もちろん触ったことがあるに越したことはありませんが、それだけでは「その人が現場で何をしてきたか」がほとんど見えません。採用側が知りたいのは、ツールそのものではなく、ツールを通じてどんな問題を観測し、どう扱ってきたのかです。
例えば「Prometheus での監視構築」と書くのであれば、「どんなメトリクスを切り出し」「どのような閾値やアラートポリシーを設計し」「そこからどんな学びや改善につなげたのか」までがセットで初めて、SREとしての経験になります。スキルシートは、経験の“表札”でしかなく、その奥にあるストーリーが見えなければ、評価のしようがありません。
評価されるのは“現場をどう観測していたか”という視点
優れたSRE候補者の経歴書には、共通する特徴があります。それは、単に「障害対応を行った」「自動化を進めた」と書くのではなく、「何を問題だと観測したのか」から書き始めていることです。
例えば、「バッチ処理が毎晩ギリギリまで伸びており、翌朝の業務開始時間に間に合わないことが増えていた」「リリース後のインシデントが特定のチームに集中していた」「アラートの9割がノイズで、本当に見るべきサインが埋もれていた」といった“現場の痛み”が具体的に書かれている経歴は、採用側から見ると非常に強く印象に残ります。
理由はシンプルで、そのような記述からは「この人はシステムだけでなく、チームやビジネスの状態を観測しようとしている」ことが伝わるからです。SREは、メトリクスのグラフを読むだけではなく、その背後にある関係性や構造を読み解く仕事でもあります。その視点が文章に滲み出ているかどうかが、第一次選考で最初に見られているポイントです。
書類で刺さるSREは何を書いているのか
評価されるのは「成果」よりも「文脈の読み取り方」
SRE採用では、「自動化しました」「MTTRを短縮しました」といった成果そのものよりも、そこに至るまでの文脈が重視されます。同じ MTTR 改善でも、何がボトルネックで、どんな観測を行い、どれだけの関係者と連携し、どう合意形成したかによって評価は大きく変わります。
採用側が知りたいのは、改善そのものよりも、「なぜその改善が必要だったのか」「どのようにして現場の不協和を読み取り、調整したのか」という“読み解く力”です。SREにおいては、技術より先に「問題を意味づける力」が問われるからです。
具体例：書類で高評価を取るSRE経験の書き方
実際に採用担当者が評価しやすい書き方は、次のような構造を持っています。
- ①観測：どんな“痛み”を見つけたか（例：夜間アラートの9割がノイズだった）
- ②分析：その痛みをどう読み解いたか（例：閾値設定とアラートポリシーがチームによってバラバラだった）
- ③改善：どんな打ち手を実行したか（例：SLOに基づきアラート設計を統合し、ノイズを70%削減）
- ④関係性：どんな合意形成を経たか（例：開発と運用でワークショップを実施し、閾値の意味を共有）
この4つが揃っていると、短い文章でも現場で積み重ねた“判断の質”が伝わります。単なる成果よりも、「どう考え、どう動いたか」のほうがSRE採用において核心になります。
面接で必ず聞かれる“3つの問い”
問い1：「一番印象に残っている障害と、その学びは？」
ほぼすべてのSRE面接で聞かれると言ってもいいのが、この質問です。ここで見られているのは、「どれだけ派手な障害を経験したか」ではありません。評価されるのは、障害をどれだけ多面的に観測し、どれだけ構造的に学びへ変換しているかです。
たとえば、「EC2が落ちました」だけでは情報が足りません。採用側が知りたいのは、「なぜその構成になっていたのか」「どこまでが想定内で、どこからが想定外だったのか」「どのタイミングで、どんな合図を見て動き始めたのか」「ポストモーテムでどこまで掘り下げ、何を次の改善に繋げたのか」といったストーリー全体です。ここで“人を責めず、構造を観る”視点があるかどうかは、かなりシビアに見られています。
問い2：「SLOやエラーバジェットをどう使っていましたか？」
もうひとつ定番なのが、SLOやエラーバジェットに関する問いです。ここで問われているのは、数値の正しさではなく、「その数値をどう意味づけていたか」です。例えば、「99.9%にしました」だけでは弱く、「どのユーザー行動を守るためのSLOだったか」「どのステークホルダーとどう合意したか」「エラーバジェットを使い切ったとき、どんな会話が起きたか」まで話せると、SREとしての解像度が一気に伝わります。
信頼性の指標を「数字」として扱っていたのか、「対話のきっかけ」として使っていたのか。この差は、面接官から見ると非常に大きな違いになります。後者を語れる人は、現場でSREとして文化を動かしてきた可能性が高いと判断されます。
問い3：「摩擦が生じたとき、どう振る舞いましたか？」
SREの仕事は、きれいな世界だけでは終わりません。リリースを止めるかどうか、技術的負債にいつ向き合うか、運用負荷をどこまで許容するか──現場では、開発・プロダクト・ビジネスの“正義”がぶつかる瞬間が必ずあります。面接では、この摩擦をどう扱ってきたかが必ずと言っていいほど問われます。
このとき、「相手が間違っていた」「こう主張して押し切った」という語り方だけだと、評価は伸びません。採用側が見ているのは、「どこまで相手の事情を理解しようとしたのか」「どこまで譲り、どこは譲らないと決めたのか」「その結果、関係性はどう変わったのか」といった対話のプロセスです。信頼性は関係性の上にしか立たない──この前提を自分なりに体験しているかどうかが、面接でじわっと滲み出てきます。
SRE採用の現場が警戒するパターン
警戒ポイント1：ツール依存で“判断のプロセス”が書かれていない
最も多いのが、「〇〇の経験があります」というツール依存の記述だけで終わってしまうケースです。Kubernetes、Terraform、BigQuery、Datadog──どれも強力な技術ですが、それらを使った理由や背景が書かれていないと、「ただ触っただけなのか」「現場の課題に応じて選択したのか」が判断できません。
SREは“仕組みを作る”だけでなく、仕組みを作るべきかどうかを判断する役割でもあります。技術選定の意図や、改善における優先順位の付け方が書かれていないと、採用側に「観測ではなく手段ありきで動く人かも」という不安を与えます。
警戒ポイント2：障害対応が「作業ログ」になっている
“障害対応経験あり”という記述は多いですが、その多くが「〇〇の障害が発生し、復旧作業を行いました」という作業ログの域を出ません。SRE採用で評価されるのは、復旧までの手順よりも「どのサインを最初の手がかりにしたか」「最も影響が大きいポイントはどこだと判断したか」「再発防止のために、何を観測し直したか」といった判断・学習のプロセスです。
障害対応を“作業”として書く人は、面接でも同じように“手順の話”に終始しがちです。逆に、障害を構造で語れる人は、「信頼性を設計する側」に回れる人だと判断されます。
警戒ポイント3：“衝突”の経験が書かれていない
SREは、開発・運用・プロダクト・ビジネスの“間”に立つ仕事です。つまり、必ず摩擦が発生します。リリース判断の基準、技術的負債の棚卸し、エラーバジェットの扱い──どのチームの優先度とも綺麗には噛み合わない瞬間があります。
もし経歴書に「チームとの衝突」や「合意形成のプロセス」が一切書かれていない場合、採用側は「まだ衝突を経験していない」「SREのコア領域で戦っていないのかも」と判断します。むしろ、摩擦をどう観測し、どう越えてきたかこそが、SREの成熟を測る重要な材料になります。
SRE採用は「信頼性をどう捉えているか」の試験
「信頼性＝落ちないこと」だけではすぐ限界が来る
面接で「あなたにとって、信頼性とは何ですか？」と聞かれたとき、「システムを落とさないことです」「稼働率を守ることです」と答えるのは、決して間違いではありません。ただ、それだけだとSREとして見ている世界がまだ平面的だと判断されます。なぜなら、現場で本当に問われるのは「誰にとって、何を守るための信頼性なのか」という問いだからです。
同じ“99.9%の可用性”でも、BtoB SaaS の業務システムと、夜間利用が少ないtoCサービスでは意味が変わります。ビジネスのフェーズ、ユーザーの期待、既存の運用体制──これらを踏まえたうえで「このプロダクトにとっての信頼性とは何か」を語れるかどうか。SRE採用では、この解像度が静かにチェックされています。
関係性としての信頼性を語れるかどうか
より踏み込んだ面接になると、「開発チームから見たとき、あなたはどんな存在でしたか？」「ビジネスサイドとは、どのように信頼を築いてきましたか？」といった質問が飛んできます。ここで試されているのは、信頼性を関係性の中の概念として捉えられているかどうかです。
例えば、「開発チームからは『リリース前に必ず相談する相手』として認識されていた」「ビジネス側とは、エラーバジェットレポートをもとに毎月『攻めと守り』のバランスを話す場を作っていた」といった具体的なエピソードは、「この人は信頼性を数字だけでなく、対話と関係性の中で扱っている」と伝えてくれます。技術的な正しさと、人との信頼。この両方をどう編み上げてきたかが、採用の現場ではじっくりと見られています。
まとめ ― 採用の現場は、あなたの物語を見ている
SRE採用は、派手な技術スタックや資格の有無だけで決まるものではありません。むしろ見られているのは、「どんな現場で、どんな痛みを観測し、どのように解釈し、誰と一緒に解決してきたか」という、あなた自身の物語です。
書類では、ツールや技術名の列挙ではなく、観測 → 分析 → 改善 → 関係性 という流れをどれだけ具体的に描けるかがポイントになります。面接では、印象に残っている障害やSLOの運用、開発との摩擦といった問いを通じて、「信頼性をどの視点で捉えているか」「人との関係性をどう扱ってきたか」が、じわじわとチェックされます。
もし今、「自分の経歴をどうSREとして語ればいいのか分からない」と感じているなら、まずはこれまでの経験を“観測ログ”として書き出してみるのがおすすめです。どんな違和感があったのか、どんな決断をしたのか、どこでうまくいかず、どこで少し手応えを感じたのか。そこには必ず、SREとしての視点の種が眠っています。
SRE採用の現場は、完璧な正解を持つ人を探しているのではありません。変化の激しいプロダクトや組織の中で、観測し、考え、対話しながら信頼性を育てていける人を探しています。あなたが歩んできた道のりを、そのままの順番で語る必要はありません。SREというレンズを通して、自分の経験をもう一度編み直してみてください。
その過程そのものが、次のチームで信頼性に向き合うための準備運動になるはずです。この記事が、あなた自身のキャリアを見つめ直すきっかけになればうれしいです。
