「SREとして採用されたはずなのに、気づいたら夜中のアラート対応要員になっていました」——転職から半年たった29歳のインフラエンジニアから、そんな相談を受けたことがあります。

私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、求人票に「SRE」と書かれた案件の中身を一件ずつ確認していくと、実態はインフラ運用の延長に留まっているケースが少なくありません。今回は、名ばかりSRE求人を求人票と面談の段階で見抜く方法と、年収が伸びる求人と伸びない求人の分かれ目を、実際にあったやり取りを交えてお伝えします。

今回は、次の内容に沿ってご紹介します。

  • SREとインフラエンジニアの求人が、業務範囲・方法論・目標設定でどう違うのか
  • 「トイル削減にどれだけ時間を割けているか」が年収の伸びを左右する理由
  • 求人票だけでは分からない実態を、面談・面接で見抜く質問の言い回し
目次
  1. SRE求人の「名ばかり」問題、インフラエンジニアの仕事と何が違うのか
  2. SREとインフラエンジニアを分ける3つの軸
  3. SREの年収は本当に上がるのか、公式統計がない中での相場感
  4. 年収が伸びる分かれ目は「トイル削減にどれだけ時間を割けているか」
  5. 求人票だけでは分からない実態を見抜く、面談・面接での質問例
  6. 「SREはやめとけ」と言われる背景、オンコールの実態を数字で見る
  7. 面談前の裏取り、口コミサイトという情報源の使い方
  8. 未経験・インフラエンジニアからSREを目指すときの現実的なルート
  9. まとめ、SREという肩書きより「トイル削減への踏み込み」で選ぶ

SRE求人の「名ばかり」問題、インフラエンジニアの仕事と何が違うのか

ここ数年、求人票の職種名から「インフラエンジニア」が消え、代わりに「SRE」「Site Reliability Engineer」という肩書きが増えました。求人媒体で募集を出す企業側からすると、SREという肩書きの方が応募が集まりやすいという事情があります。実際、私が担当している法人側の求人でも、業務内容をほとんど変えずに職種名だけをSREに変更したいという相談を受けたことが何度もあります。

問題は、肩書きが変わっても業務の中身が変わらないケースが多いことです。求人票には「SLI/SLO」「エラーバジェット」といった単語が並んでいても、実際の仕事は監視ツールのアラート対応、深夜のオンコール、定型化されたパッチ適用といった、従来型のインフラ運用とほぼ同じという求人が実務上は珍しくありません。

SREという肩書き自体は、業務の実態を保証してはくれません。求人票の文言よりも、その会社が「信頼性を高めるための改善業務」にどれだけ時間と予算を割いているかを見ないと、転職後に「聞いていた話と違う」となりかねないのが、この職種特有の落とし穴です。

法人担当の同僚から聞いた話では、求人票の職種名変更を依頼してくる企業の中には「他社もSREという名前で募集しているので、うちも合わせないと母集団が集まらない」という理由だけで肩書きを変えるケースもあるそうです。業務内容も評価制度も変えずに名前だけ揃えるので、入社後のギャップは求人票を作った側の意図とは関係なく生まれてしまいます。応募する側からすると、肩書きの背景にどんな事情があるかまでは分からないので、結局は自分で見抜くしかありません。

SREとインフラエンジニアを分ける3つの軸

Googleが提唱したSREという考え方は、単なる運用担当の呼び方の変更ではなく、業務範囲・方法論・目標設定という3つの軸で従来のインフラ運用と一線を画しています。この3つを押さえておくと、求人票の文言がどちらに寄っているかを判断しやすくなります。

業務範囲でいえば、従来型のインフラ運用は「決められた手順に沿ってシステムを維持すること」が中心です。一方、本来のSREは運用に加えて、信頼性を高めるための設計変更やコードによる自動化まで踏み込みます。方法論の面では、SLI(サービスレベル指標)やSLO(サービスレベル目標)、エラーバジェットといった数値目標を置き、それを基準に開発と運用のバランスを取ります。目標設定の面では、日々の定型作業(トイル)をどこまで減らすかという指標が明確に置かれているかどうかが分かれ目です。

比較軸従来型のインフラ運用名ばかりSRE求人本来のSRE
業務範囲手順書に沿った運用・保守が中心運用中心、肩書きのみSRE運用+設計改善+自動化
方法論明文化された指標は少ないSLO等の単語はあるが形骸化SLI/SLO/エラーバジェットで運用
トイルの扱い削減目標が特に設定されない「効率化も意識」と抽象的な記載削減目標が数値で管理されている

この3列を並べると分かる通り、名ばかりSRE求人が厄介なのは、単語だけは本来のSREに寄せてある点です。求人票の文言をそのまま信じると、実態は左端の従来型運用のまま採用されてしまいます。

求人票の書きぶりでもう一段見分けるなら、「安定稼働を守る」「障害対応」「24時間365日の運用」といった守りの表現ばかりが並ぶ求人と、「トイル削減」「自動化による工数削減」「開発チームへの提案」といった攻めの表現が具体的な数値や取り組み例つきで書かれている求人とでは、実態にかなり差があるというのが私の実感です。ただし、この違いは求人票の言葉選びだけでは断定できません。書いている担当者の言語感覚の差でもあるので、最終的には面談で確認する必要があります。

SREの年収は本当に上がるのか、公式統計がない中での相場感

SREという職種単体の公的な賃金統計は、実は存在しません。厚生労働省の賃金構造基本統計調査や経済産業省のIT関連産業給与実態調査にも、SREという区分は出てきません(出典:レバテックフリーランス「SREの年収や仕事内容」)。ネット上で見かける「SREの平均年収◯◯万円」という数字の多くは、エンジニア全般の統計に転職サイトの独自集計を足したもので、職種単体の公式な裏付けがあるわけではないという前提で読む必要があります。

その上で、私が現場で見てきた相場感を言うと、経験5年前後のインフラ出身のSREで550万〜650万円、コンテナ基盤やIaCの設計まで一人で回せる経験8年以上の層で700万〜900万円あたりに集まる印象があります。マネジメントを兼ねる、あるいは複数サービスの信頼性設計を横断で見る立場になると、900万円を超える提示も出てきますが、これは職種というより裁量の大きさに対する評価です。ただしこれはあくまで目安で、事業会社かSIerか、扱っているサービスの規模によって大きく振れます。

雇用形態によっても伸び方は変わります。SIer・受託系の運用保守契約の中でSREを名乗るポジションは、契約単価の枠に給与が縛られやすく、経験を積んでも年収レンジの中位から上に抜けにくい傾向があります。一方、自社サービスを持つ事業会社のSREは、サービスの信頼性が事業の売上に直結するため、成果が見えやすく評価にも反映されやすい構造になっています。同じ経験年数でも、どちらの構造にいるかで昇給のスピードがまったく違うというのが、求人を見比べていて感じる実感です。

大事なのは、この年収レンジに届くかどうかが「SRE歴◯年」という単純な経験年数では決まらないことです。次の章で触れますが、名ばかりSRE求人にいる限り、経験年数を重ねても年収レンジの下の方に留まり続けるケースを何度も見てきました。

年収が伸びる分かれ目は「トイル削減にどれだけ時間を割けているか」

Googleが定義するトイルとは、手作業で繰り返し発生し、自動化できるはずなのに人手で対応し続けている運用作業のことです。Google Cloudの公式ブログでは、Googleの原則として「SREはトイルに割く時間を勤務時間の50%未満に抑える」という基準が示されています(出典:Google Cloud「SREの原則に沿ったトイルの洗い出しとトラッキング」)。

ポイント: トイルに割く時間が50%を超えている職場では、いくら「SRE」という肩書きがついていても、実質的にはインフラ運用担当と変わりません。求人票でこの比率がどう扱われているかが、年収の伸びしろを左右します。

29歳・経験6年のEさんは、SES常駐でデータセンターの運用を担当していたインフラエンジニアです。あるとき、BtoB SaaSを展開する事業会社の「SREチーム」求人に応募し、年収480万円から495万円という条件で転職しました。求人票には「SLOに基づいた信頼性向上」「トイル削減による開発生産性の向上」と書かれており、面接でも「改善業務にしっかり時間を割いてもらう」と説明を受けていたそうです。

ところが入社後の実態は、監視ダッシュボードのアラートに応じて夜間対応をする当番シフトと、月次のパッチ適用作業がほとんどで、自動化に充てられる時間はほぼゼロでした。改善のためのチケットを起票しても、目の前の障害対応や棚卸し作業が優先され、後回しになる。1年たっても評価面談で「まだ運用が安定していないので改善業務は来期以降」と言われ続け、年収も据え置きのまま私のところに相談に来ました。

同じ時期、34歳・経験10年のFさんは、自社開発のBtoCメディア企業でインフラ担当を務めながら、複数のSRE求人を比較検討していました。私がFさんの面談に同席し、応募先の採用担当者に「直近1年で自動化した運用作業の具体例を教えてください」と尋ねたところ、ある企業の担当者は言葉に詰まり、「今後整備していく予定です」という抽象的な説明に終始しました。別の企業の担当者は、日次デプロイのカナリアリリースを自動化した経緯や、オンコール当番の対応履歴をPagerDutyで集計してトイルを月次で可視化している仕組みまで、具体的に答えられました。

Fさんは後者を選び、前職比80万円アップの年収で入社しました。入社半年後にはSLOの策定プロジェクトに正式にアサインされ、トイル削減の実績がそのまま評価と年収に反映される環境で働いています。1年後の評価面談では、削減できたオンコール件数を根拠に、次期の昇給交渉にも臨めたそうです。EさんとFさんの違いは経験年数ではなく、転職の時点でトイルの比率と改善業務への予算配分を確認できたかどうかにありました。

求人票だけでは分からない実態を見抜く、面談・面接での質問例

求人票の文言だけで名ばかりSRE求人を完全に見抜くのは難しいのが実情です。私が面談や一次面接の場で候補者に使ってもらっている質問は、次のようなものです。

初回面談・面接で実態を確認する質問例

  • 「直近1年でコード化・自動化した運用作業の具体例を教えてください」
  • 「オンコール対応のうち、同じ原因の障害が再発した割合はどのくらいですか」
  • 「チームとしてトイルに使っている時間の目安と、それを減らす目標はありますか」
  • 「SLI/SLOを設定しているサービスはどれで、直近で見直したのはいつですか」
  • 「エラーバジェットを使い切った、または余らせて機能開発を優先した事例はありますか」

これらの質問に共通しているのは、抽象的な「改善に取り組んでいます」ではなく、具体的な件数・比率・時期を答えられるかどうかを見ている点です。名ばかりSRE求人の担当者は、この手の質問に対して「これから整備していく予定です」という将来形の答えに逃げがちですが、それ自体が今トイル削減に踏み込めていないという実態を示すサインです。

質問ごとにもう少し補足すると、「自動化の具体例」を聞くのは、改善業務に実際に工数が割かれているかを見るためです。「再発対応の割合」を聞くのは、その職場が同じ火消しを繰り返す構造になっていないかを確認するためで、この比率が高いほどオンコールの負荷は下がりにくくなります。「トイルの時間と削減目標」を聞くのは、Googleが示す50%という基準を自社の指標として持っているかどうかを見るためで、目標自体がない職場は改善の優先順位が上がりにくい傾向があります。

同じ質問は、応募者側の職務経歴書やカジュアル面談の受け答えを整える際にも使えます。自分がインフラ運用の延長でしかない業務をしてきたのか、それとも自動化まで踏み込んできたのかを、面接前に自分自身に問い直す材料にもなります。面接で「SREとしてどんな成果を出しましたか」と聞かれたときも、「障害対応に尽力しました」で終わらせず、「月あたりのオンコール件数を◯件から◯件に減らした」「手作業だった構築手順をコード化し、対応時間を◯時間短縮した」のように、数字と自動化の中身をセットで語れると評価が変わります。

「SREはやめとけ」と言われる背景、オンコールの実態を数字で見る

「SREはやめとけ」「きつい」という声をネットで見かけることがありますが、私の見立てでは、この評判の多くは名ばかりSRE求人での経験に由来しています。トイル削減が進まないまま人員だけ増やさずに運用を回している職場では、オンコール当番の頻度が週1回を超えることも珍しくなく、しかも呼び出される原因の多くが既知の障害の再発だったりします。

一方で、本来のSREとして自動化・改善が進んでいる職場では、オンコールの発生自体が減っていきます。私が支援した中でも、月次のオンコール発生件数を可視化してチームで共有し、同じ原因の再発が続く箇所から優先的に自動化を進めている企業では、オンコール当番であっても実際に呼び出されるのは月に1〜2回程度という声を聞きます。同じ「SREのオンコール」という言葉でも、職場によって実態がまったく違うということです。

体制の厚みも大きく影響します。3人程度でオンコールを回している職場と、10人以上でローテーションを組んでいる職場とでは、当番が回ってくる頻度自体が3倍以上違います。求人票やカジュアル面談で「オンコール当番は何人体制で回していますか」と聞くのは、トイルの質を確認する質問とセットで使うと、入社後の生活への影響までイメージしやすくなります。

面談の段階で「オンコール対応時間のうち、同じ原因の再発対応は何%くらいですか」と聞いておくと、その職場がトイル削減に本気で取り組んでいるかどうかの手がかりになります。この比率が高いまま何年も変わっていない職場は、肩書きがSREでも、働き方の実態は従来型の運用担当に近いと考えた方が現実的です。

面談前の裏取り、口コミサイトという情報源の使い方

ここまで、求人票の文言を鵜呑みにせず、面談や面接の場で具体的な数字を引き出すことの大切さをお伝えしてきました。ただ、面談で聞ける情報にはどうしても限りがあります。応募前の裏取り手段の一例として、企業の社員・退職者による口コミを集めた「転職会議」のようなサイトに目を通しておくという方法もあります。

面談前の裏取りに

社員・退職者の口コミで企業の実態を確認できる転職口コミサイト

企業の口コミ・評判を見る【転職会議】

会員登録後、口コミの続きを閲覧できます(無料)

転職会議は企業ページごとに口コミが「ワークライフバランス」「退職理由、退職検討理由」といったカテゴリに分かれており、オンコール当番の負荷や、SRE・インフラ職から離れた人がどんな理由を挙げているかが書かれていることがあります。2026年現在、全国23万社・約550万件の転職口コミ情報を掲載しているとのことです。

ただし、口コミを読めば実態が正確に分かるという話ではありません。口コミはあくまで在籍者・退職者個人の主観であり、特に退職理由のカテゴリは、不満を抱えて辞めた人の声に偏りやすいというのが私の見方です。この記事で挙げた質問を面談でぶつける前に、どこを重点的に確認すべきかの当たりをつける材料として使うのが現実的だと思います。なお、ここで挙げた掲載数やカテゴリはあくまで公式サイト・公式発表に記載されている内容であり、私自身が担当した相談実績として書いているわけではない点は明確にしておきます。

未経験・インフラエンジニアからSREを目指すときの現実的なルート

インフラエンジニアからSREへのキャリアチェンジを考える場合、いきなり大規模なSRE専任求人に応募するより、今の職場で自動化に踏み込む実績を作ってから動く方が、結果的に年収の伸びる求人に届きやすくなります。

転職前に押さえておきたい準備

  • ShellスクリプトだけでなくPythonやGoなど、運用作業をコード化できる言語を1つ選んで実務に持ち込む
  • TerraformなどのIaCツールで、手作業の構築・変更手順を1つでもコード化した経験を作る
  • 監視・アラートの誤検知や再発障害を洗い出し、削減した件数を数字で語れるようにしておく
  • 応募先の求人票やIR資料に、改善業務への投資姿勢が具体的に書かれているかを確認する

未経験からSREを目指す場合も同様で、いきなり「SRE」の肩書きに飛びつくより、インフラ運用の中でどれだけ自動化・効率化に手を伸ばせたかという実績を積んでから応募する方が、面接での説得力が違います。私が支援したケースでも、運用担当のまま構築手順をIaC化した経験を職務経歴書に書いた候補者の方が、SRE専任求人での通過率が明らかに高い傾向がありました。

目安として、運用の中で自動化に手を挙げてから半年〜1年ほど実績を作り、その後にSRE専任求人へ応募するというペースで動いた候補者が多いです。焦って肩書きだけを追いかけると、結局は名ばかりSRE求人に流れ着いてしまい、実務経験が積み上がらないまま年数だけが経つという遠回りになりかねません。

まとめ、SREという肩書きより「トイル削減への踏み込み」で選ぶ

求人票に「SRE」と書かれているかどうかは、実は年収が伸びるかどうかとほとんど関係がありません。EさんとFさんの違いが示す通り、分かれ目はトイル削減への時間と予算の配分であって、肩書きでも経験年数でもありませんでした。

求人票の文言を鵜呑みにせず、面談や面接の場で「直近1年で何を自動化したか」「同じ障害の再発対応にどれだけ時間を使っているか」を具体的な数字で聞く。この一手間があるかどうかが、転職後に「名ばかりSRE」で足踏みするか、トイル削減の実績を積んで年収を伸ばしていけるかを分けるというのが、この記事で一番伝えたかったことです。