SREへのキャリアチェンジ【インフラ経験者の強み】

インフラエンジニアとして運用業務を続けているうちに、「同じような障害対応を何度も繰り返している」「手作業のオペレーションが一向に減らない」と感じたことはありませんか。その問題意識こそが、SRE（Site Reliability Engineering）というキャリアへの入り口です。

SREは、Googleが提唱したソフトウェアエンジニアリングのアプローチで運用課題を解決する職種です。日本でもSREの求人は増え続けていますが、「従来のインフラ運用と何が違うのか」がわかりにくいという声をよく聞きます。この記事では、インフラエンジニアからSREへのキャリアチェンジについて、具体的な道筋と覚悟すべき点を解説します。

SREとは何か：従来のインフラ運用との本質的な違い

SREの基本的な考え方

SREを一言で表すなら、「ソフトウェアエンジニアリングの手法を使ってインフラ運用の課題を解決する」職種です。従来のインフラ運用が「システムを安定させること」をゴールにしていたのに対し、SREは「信頼性を定量的に管理しながら、変更のスピードも維持する」ことをゴールにしています。

この違いは小さく見えて、実は根本的です。従来のインフラ運用では「障害を出さないこと」が最優先でしたが、SREの考え方では「どこまでの障害を許容するか」を定量的に定め、その範囲内でリリースやサービス改善を進めます。

SLI/SLO/エラーバジェットという指標

SREの実務で最も重要な概念が、SLI（Service Level Indicator）、SLO（Service Level Objective）、そしてエラーバジェットです。

概念	定義	具体例
SLI	サービスの信頼性を測る定量的な指標	リクエスト成功率、レイテンシのp99
SLO	SLIに対して設定する目標値	成功率99.9%、p99レイテンシ200ms以下
エラーバジェット	SLOの余裕分。ここまでなら障害を許容する	月間0.1%のダウンタイム（約43分）

従来の運用では「可用性100%を目指す」という非現実的な目標が暗黙的に存在しがちでした。SREはエラーバジェットという概念を導入することで、「今月はまだ余裕があるからリリースを進めよう」「エラーバジェットを使い切ったので信頼性改善に集中しよう」という判断を、データに基づいて行います。

トイル削減という思想

SREのもう一つの重要な考え方が「トイル削減」です。トイルとは、手作業で行っている運用タスクのうち、自動化可能で、繰り返し発生し、サービスの成長に比例して増加するものを指します。

従来のインフラ運用では、手順書に従って手作業でオペレーションを行うことが「堅実な運用」とされてきました。SREの世界では、そうした繰り返しの手作業はすべて「自動化すべき負債」として扱われます。SREチームでは一般的に、業務時間の50%以上をトイル削減や自動化の開発に充てることが推奨されています。

インフラエンジニアの経験がSREで強みになる理由

障害対応の実戦経験

SREの業務において、障害対応（インシデントレスポンス）は避けて通れない領域です。インフラエンジニアとして本番環境の障害を経験してきた方は、システムがどこでどう壊れるかを肌感覚で理解しています。

ログの読み方、障害の切り分け手順、関係者への報告の仕方。こうした暗黙知は、座学だけでは身につきません。開発出身のSREが苦労しがちなこの領域で、インフラ経験者は即戦力になれます。

Linux/ネットワークの基礎力

SREは高度な自動化やObservabilityの構築を行いますが、その土台にはLinuxとネットワークの基礎知識があります。プロセス管理、メモリ管理、TCP/IPの仕組み、DNS、ロードバランサーの挙動。これらを理解していないと、複雑な障害の根本原因にたどり着くことができません。

インフラエンジニアとして日常的にこれらの技術に触れてきた経験は、SREとしての問題解決能力の基盤になります。

運用の「痛み」を知っている

手作業のオペレーションがいかに非効率か、夜間の障害対応がいかに辛いか。この「痛み」を体験的に知っていることは、SREとしての原動力になります。「なぜ自動化が必要なのか」「なぜObservabilityが重要なのか」を、理屈ではなく実感として理解できるからです。

追加で身につけるべきスキル

インフラ経験はSREの強い基盤になりますが、それだけでは十分ではありません。SREとして活躍するために追加で必要なスキルを解説します。

プログラミング能力

これがインフラエンジニアからSREへの転向で最大のハードルになることが多いです。SREはシェルスクリプトだけでなく、Python、Go、あるいは自社で使われている開発言語でツールやプラットフォームを開発する力が求められます。

「スクリプトが書ける」レベルと「ソフトウェアを設計・開発できる」レベルには大きな差があります。テスト可能なコードの書き方、APIの設計、バージョン管理を含む開発プロセス。これらは、インフラ運用の延長線上にはないスキルです。

ただし、最初から完璧なプログラミング力は不要です。まずは自動化スクリプトの品質を上げることから始め、徐々にアプリケーション開発の手法を取り入れていくのが現実的なアプローチです。

CI/CDの理解と構築

SREは開発チームのデプロイパイプラインに深く関わります。GitHub Actions、GitLab CI、Jenkins、ArgoCD、Spinnaker。これらのツールの使い方だけでなく、CI/CDパイプラインの設計思想を理解している必要があります。

テスト自動化、カナリアリリース、ブルーグリーンデプロイメント、ロールバック戦略。開発チームがコードを安全かつ高速にデプロイできる仕組みを整えることは、SREの主要な責務の一つです。

Observability（可観測性）

SREにとって、Observabilityは最も重要な技術領域の一つです。メトリクス、ログ、トレースという3つの柱を組み合わせて、システムの内部状態を把握できる仕組みを構築します。

柱	主なツール	目的
メトリクス	Prometheus, Datadog, CloudWatch	数値的な傾向の可視化、アラート
ログ	Elasticsearch, Loki, CloudWatch Logs	詳細なイベントの記録と検索
トレース	Jaeger, X-Ray, OpenTelemetry	リクエストのサービス間の流れの追跡

従来のインフラ監視が「異常を検知する」ことに主眼を置いていたのに対し、Observabilityは「なぜ異常が起きたかを探索できる」ことを目指します。ダッシュボードを作って終わりではなく、「未知の問題を調査できる」レベルの仕組みを構築する力が求められます。

IaCとプラットフォームエンジニアリング

Terraform、Pulumi、CDKといったIaC（Infrastructure as Code）ツールの活用は、SREの基本スキルです。インフラエンジニアとしてTerraformを触ったことがある方も多いと思いますが、SREの文脈ではさらに一歩進んで、開発チームがセルフサービスでインフラをプロビジョニングできるプラットフォームを提供する視点が求められます。

求人の実態と年収レンジ

SRE求人の現状

日本におけるSRE求人は増加傾向にありますが、企業によって「SRE」の定義が大きく異なるのが現実です。Googleの定義に忠実なSREポジションもあれば、実態は従来のインフラ運用に「SRE」というラベルを貼っただけのポジションもあります。

求人票を見る際は、以下の点をチェックすることをおすすめします。

• SLI/SLOの運用について言及があるか
• 自動化やツール開発が業務に含まれているか
• オンコール体制が整備されているか
• 開発チームとの協業が明記されているか

これらの要素が含まれていなければ、実質的には「名前だけSRE」の可能性があります。

年収レンジ

キャリア段階	年収の目安	求められるスキル
ジュニアSRE（1〜2年）	500〜650万円	Linux基礎、監視ツール運用、スクリプティング
ミドルSRE（3〜5年）	650〜850万円	SLO設計、自動化開発、CI/CD構築
シニアSRE（5年以上）	850〜1,100万円	プラットフォーム設計、組織へのSRE文化導入
SREマネージャー / リード	1,000〜1,300万円	チームビルディング、全社的な信頼性戦略

インフラエンジニアからの転向の場合、プログラミング力が十分であればミドルSREのレンジからスタートできることもあります。ただし、「インフラ経験5年＝SRE経験5年」とは評価されない点は理解しておく必要があります。

フリーランスのSRE案件は月額70〜110万円が相場で、特にKubernetesやObservabilityの構築経験があると高単価が見込めます。フリーランスのクラウドエンジニア単価と比較しても遜色ないレンジです。ただし、SREはチームに長期的に関わることで成果を出す職種なので、短期案件は少ない傾向にあります。

SREの大変さ：覚悟すべきこと

SREのキャリアには魅力的な面が多いですが、厳しい側面も正直にお伝えします。

オンコール対応の負荷

多くのSREチームでは、オンコールのローテーションがあります。担当週は深夜でも休日でも、アラートが来れば対応しなければなりません。

よく整備されたチームでは、オンコールの頻度は4〜6週に1回程度で、アラートの品質も高く保たれています。しかし、SRE文化が成熟していない組織では、頻繁な誤報アラートに悩まされ、オンコール期間が実質的な「夜勤」になるケースもあります。スタートアップのインフラ担当のように少人数体制の環境では、この負荷がさらに大きくなる傾向があります。

オンコールのストレスは人によって感じ方が大きく異なります。「夜中に起こされるかもしれない」というプレッシャーだけで強いストレスを感じる方には、この点は慎重に検討すべきです。

開発チームとの調整の難しさ

SREは開発チームと運用チームの「橋渡し役」ですが、この立場は時に板挟みになります。開発チームは新機能のリリースを急ぎたい。SREは信頼性を担保したい。エラーバジェットの概念があっても、実際の現場では「でも今回だけは急ぎでリリースしたい」という圧力がかかることがあります。

技術的な正しさだけでは人は動きません。開発チームの事情を理解した上で、信頼性とスピードのバランスを取る交渉力が求められます。こうした技術以外のスキルの重要性はテックリードにも共通する課題です。この対人スキルの部分で苦労するSREは少なくありません。

自動化への高い要求

SREには「同じ手作業を2回以上やるなら自動化せよ」という強い文化があります。これは理想としては素晴らしいですが、実際には自動化のための開発工数が確保できなかったり、自動化自体のメンテナンスコストが発生したりと、現実との折り合いに苦労する場面があります。

また、自動化を推進するために高いプログラミング力が必要です。インフラエンジニアとして手作業に慣れていた方が、すべてをコードで解決する文化に適応するまでには相応の時間がかかります。

常に学び続ける必要がある

Kubernetes、サービスメッシュ、OpenTelemetry、eBPF。SREが扱うべき技術は広範で、新しい技術やツールが次々と登場します。インフラエンジニア時代よりも学習すべき領域が広がるため、継続的な学習への投資が求められます。

インフラからSREへの現実的な転向ステップ

ステップ1：現在の業務にSRE的な視点を持ち込む（0〜3ヶ月）

まずは今の環境で始められることがあります。運用しているサービスのSLIを定義してみる。手作業のオペレーションをリストアップし、自動化の優先順位をつける。障害の振り返り（ポストモーテム）を文書化する。これらはSREの基本的なプラクティスであり、現在のポジションのまま始められます。

ステップ2：プログラミング力を強化する（3〜6ヶ月）

PythonまたはGoで、運用ツールの開発に取り組んでください。最初は既存のシェルスクリプトをPythonに書き直すところから始め、徐々にテストの書き方、モジュール設計、APIの設計といった開発の基礎を身につけます。

ステップ3：ObservabilityとCI/CDの実践経験を積む（6〜12ヶ月）

PrometheusやGrafanaの構築、CI/CDパイプラインの設計と運用を経験します。個人プロジェクトでも、業務内でも構いません。重要なのは、「監視ツールを導入した」ではなく「SLOに基づいたアラート設計を行い、ノイズを削減した」というレベルの経験を積むことです。

ステップ4：SREポジションへの移行（12〜18ヶ月）

社内にSREチームがあればそこへの異動を打診する、なければSRE求人への転職活動を始めるタイミングです。面接では、インフラの経験に加えて、SRE的な取り組みの実績（SLO定義、自動化、ポストモーテム）をアピールできると強いです。

まとめ

インフラエンジニアからSREへのキャリアチェンジは、障害対応経験やLinux/ネットワークの基礎力という強みを活かしながら、キャリアの幅と年収レンジを広げられる選択肢です。年収600万〜1,100万円のレンジで、成長を続けている領域です。

ただし、プログラミング力の強化は避けて通れませんし、オンコール対応や開発チームとの調整など、インフラ運用とは異なる種類の大変さがあります。「運用が嫌だからSREに逃げる」という動機では、SREの大変さに直面して後悔する可能性があります。

SREの本質は「エンジニアリングで運用課題を解決する」ことです。繰り返しの手作業に対して「これを自動化したい」と強く感じる方、信頼性を定量的に管理する考え方に共感できる方にとっては、やりがいの大きいキャリアになるでしょう。まずはあなたのスキルセットがどのキャリアパスに合っているか、シミュレーターで確認してみてください。