インフラエンジニアからSREへの転職を考えたとき、何から始めればいいか迷うのは自然なことです。SREは従来の運用保守とは異なり、開発やデータ分析まで踏み込む幅広い役割を担います。そのぶん求められるスキルの範囲も広く、独学だけでは方向性を見失いかねません。

本記事はSREの仕事内容から必要スキル、ロードマップまでを一本の流れにまとめた実践ガイドです。読み終えるころには、最初の一歩を自信を持って踏み出せるようになっています。

インフラエンジニアとSREの役割の違い

アプリ開発領域まで踏み込む役割の広さ

SREの業務範囲は、サーバーやネットワークの構築・運用だけではありません。デプロイの自動化やCI/CDパイプライン の整備に加え、アプリのコードリーディングまで含まれるのが大きな違いです。

特に違いがわかりやすいのが障害対応の動き方でしょう。例えば本番のPOSTエンドポイントでタイムアウトが発生したとします。その際、インフラエンジニアなら「CPU・メモリは正常」で報告が完了する場面もあるはずです。

一方SREはそこからアプリのコードまで潜り、N+1クエリを突き止めて改修し、プルリクエストを送るところまで踏み込みます。インフラの外にある不具合がサービスの信頼性を揺るがす以上、コードとの距離は避けて通れません。

SLIやSLOに基づくデータドリブンな運用

SREは稼働率100％を目指すのではなく、許容できる停止の幅をあらかじめデータで定義します。この考え方の土台になるのがサービスレベル指標（SLI）と目標（SLO）です。

例えばSLOを99.9％に設定した場合、30日間で約43分のダウンタイムが許容範囲にあたります。この余白をエラーバジェットと呼び、残量がある間はリリースを優先できるのが特徴です。エラーバジェットが枯渇した時点で開発を止め、信頼性の回復にリソースを集中させるのがSRE特有の判断軸と言えます。

インフラの現場では、障害ゼロが暗黙のゴールになりがちです。そのためSREはその基準を数値で握り直し、開発スピードとの折り合いをつけにいきます。

エンジニアリングによる定型業務の削減

SREは手順書どおりの対応を繰り返すのではなく、同じ作業が二度と発生しないようコードで仕組み化する職種です。Googleはこの手の繰り返し作業をトイルと呼び、業務時間の50％未満に抑えるよう求めています。毎朝のログ確認やバックアップの手動実行は、その典型でしょう。

インフラエンジニアならチェックリストの精度を上げる方向でトイルを削減しがちです。一方SREは、Pythonやシェルスクリプトでその作業自体を消しにいきます。率直に言えば、手順書を10回見直すよりスクリプトを1本書くほうがチームへの効果は大きいものです。

インフラエンジニアからSREへの転職に向いている人

インフラ知見を武器に自動化や開発領域に挑戦したい人

インフラの設計・構築を経験してきた人ほど、SREへの転身で武器になるものを持っています。サーバーのリソース配分やネットワーク経路を肌で知っているからこそ、Terraformのコードにも根拠が宿るわけです。

SREの業務では、EC2のインスタンスタイプを選ぶ場面があります。CPUやメモリの実測値を読んできた経験があれば、構成の初期段階で精度の高い見積もりを出せるでしょう。逆にクラウドだけを触ってきたエンジニアだと、ドキュメント頼りの試行錯誤が増えがちです。

インフラの裏側を知っていることが、自動化コードの精度をそのまま底上げしてくれます。

開発と運用の橋渡し役としてプロダクト改善を推進したい人

チーム間の壁を取り払い、サービス全体を前に進めたい人はSREとの相性が良いタイプです。SREは開発と運用の中間に立ち、障害の原因切り分けからポストモーテムの設計まで一手に引き受けることも珍しくありません。

そのため、自分の担当領域を守るだけでなく、組織全体の生産性を引き上げることにやりがいを感じられるかが分かれ目でしょう。開発側の事情も運用側の制約も把握したうえで周囲を巻き込める人ほど、SREの現場では重宝されます。

トラブル対応を迅速化しシステムの品質を上げたい人

障害の原因をコードレベルまで掘り下げ、再発しない仕組みをつくる工程を楽しめる人はSRE向きです。

インフラエンジニアの障害対応がサーバーやネットワークの復旧で完了しがちなのに対し、SREはそこからさらに踏み込みます。ログとメトリクスを照合してボトルネックを特定し、修正パッチやアラート設計まで仕上げるのが基本の動き方でしょう。

正直なところ、同じ障害を二度と起こさない執念がある人ほどこの仕事は手応えを感じやすいと思います。

インフラエンジニアからSREへの転職に向いていない人

プログラミングや新しい技術の習得に抵抗がある人

SREの業務では、PythonやGoでスクリプトを書く場面が日常的に発生します。物理サーバーの構築やネットワーク設定だけに集中したい人にとって、この比重は想像以上に大きいでしょう。SREの業務において、Terraformでインフラをコード化し、CI/CDパイプラインを自分で組む作業は欠かせません。

そのため、コードを書くこと自体に苦痛を感じるなら、従来型のインフラエンジニアとしてキャリアを深めたほうがよいでしょう。

サービス全体よりも特定の技術領域のみを深掘りしたい人

一つの技術を深く極めたい志向が強い人は、SREの守備範囲の広さに息苦しさを感じやすいタイプです。

この職種はアプリケーションのコードからインフラ構成、セキュリティ設計まで横断的に手を出すことになります。障害の原因がネットワークにあるのかアプリのロジックにあるのか、切り分けの段階から複数領域の知識が求められるためです。

個人的には、特定のデータベースやOSを突き詰めたいならインフラスペシャリストのほうが満足度は高いと感じます。

インフラエンジニアからSREになるために必要な4つのスキル

IaCによるインフラ自動化スキル

SREを目指すうえで、インフラコードで定義・管理するIaCの習得は最優先事項です。管理画面を手作業で操作するClickOpsは、設定ミスや属人化の温床になりやすく、環境の再現性も担保できません。

一方Terraformのようなツールを導入すれば、構成をコードに落とし込み、同じ環境を何度でも正確に再現可能です。変更履歴もGitで追えるため、誰がいつ何を変えたかがチーム内で共有しやすくなります。

手順書とコンソール操作に頼る運用から抜け出すためにも、早い段階で身につけておきたいスキルです。

コンテナ技術とオーケストレーションの運用知見

SREの現場では、Dockerによるコンテナ技術の理解が前提として求められます。アプリをコンテナに閉じ込めれば環境差異がなくなり、どこでも同じ挙動を再現可能です。ただし本番ではコンテナの数が膨らむため、手動管理は現実的ではありません。

ここで頼りになるのが、Kubernetesのようなオーケストレーションツールです。このツールは障害時の自動復旧やスケーリングなど、商用環境を支える制御を一手に担ってくれます。この領域に明るいかどうかで、任せてもらえる仕事の幅は大きく変わるでしょう。

モダンな監視ツールを用いたオブザーバビリティ構築

SREに求められる監視は、サーバーの死活問題にとどまりません。メトリクス・ログ・トレースを横断的に分析し、システム内部の状態を可視化するオブザーバビリティの視点が必要です。

例えばDatadogやGrafanaを活用すれば、メトリクスの異常やリクエストの遅延を一元的に把握できます。こうした仕組みがなければ、複雑化するシステムの異変を先回りして捉えることはできません。

だからこそ、オブザーバビリティの構築経験は障害を未然に防ぐうえで代えがたい武器になります。

自動化やツール作成のためのプログラミング基礎

SREに求められるプログラミング力は、Webアプリをゼロから作り上げるほどの水準ではありません。まず目指すべきは、PythonやGoを使って運用作業を自動化するスクリプトが書けるレベルです。例えばデプロイ手順の自動化や、障害時の初動対応を簡易ツールに落とし込むといった場面で使います。

あわせて、チームが書いた既存コードを読み解くリーディング力も日常的に求められるスキルです。しかし、最初から完璧を求める必要はありません。実務で書ける処理の範囲を少しずつ増やしていく姿勢があれば大丈夫です。

インフラエンジニアからSREに転職するための実践ロードマップ

【STEP1】上位クラウド資格で客観的な知識を証明する

実務経験が浅い段階からSREポジションを狙うなら、上位のクラウド資格を取得するのが最も確実な突破口です。経験上、AWS SAPのような高難易度資格を持っているだけで、書類選考の通過率は大きく変わります。というのも、設計や構築フェーズへの参画を前提とした求人では、資格が実務経験の不足を補う証明書として機能するためです。

ただし、取得には順序があります。まずはAWS SAAで基礎を固め、そのうえでSAPやCKAといった上位資格へ進むのが王道のルートです。

こうした資格は面接でも話題になりやすく、技術的な対話の土台にもなってくれます。未経験の壁を超える第一歩として、これほど費用対効果の高い投資はそうありません。

【STEP2】現職の定型業務を自動化して実績を作る

転職活動を始める前に、現職でSRE的な実績をひとつ仕込んでおくと、選考の流れが変わります。例えば、毎日のバックアップ確認やログチェックなど繰り返し発生する定型業務が狙い目です。こうした作業はPythonやシェルスクリプトで置き換えられることが多く、高度な開発力は求められません。

あわせて意識したいのが、自動化の前後で削減した工数を数値として記録に残しておくことです。実際に月10時間の作業を2時間まで短縮したと数字で示せれば、職務経歴書での説得力が一気に増します。

SREの現場ではトイル削減が当たり前に求められるため、この一歩は選考における大きな分かれ目です。

【STEP3】クラウド上でのWebアーキテクチャをIaCで構築する

ポートフォリオとして特に評価されやすいのは、クラウド上にWeb三層構造をIaCで構築した実績です。

具体的には、AWS上にVPC・EC2・RDSを配置し、Terraformでコード管理するまでをひとまとめに仕上げます。手動でコンソールから構築しただけでは、再現性を重視するSREの選考で評価にはつながりません。

さらにGitHub ActionsでCI/CDパイプラインを組めば、デプロイの自動化まで一貫して見せられます。この構成をGitHubに公開しておくだけで、面接の場で技術力を裏づける有力な根拠になってくれるはずです。

【STEP4】GitHubでのコード公開と技術ブログで発信する

構築したコードをGitHubで公開し、その過程をQiitaやZennで発信することが選考突破への近道になります。採用側が注目するのは完成物だけでなく、なぜその技術を選んだのか、どこで詰まったのかという思考の流れです。こうした情報は職務経歴書の文面だけではなかなか伝わりません。

発信実績がある候補者は思考プロセスを事前に示せるため、面接の場でも話がスムーズに進みやすくなります。だからこそ、スキルを外から見える形で残しておくことが選考を前に進める最大のカギです。

インフラエンジニアからSREへの道を伴走するキッカケエージェント

組織形態や役割の明確さなど内部情報を調査

キッカケエージェントなら、求人票だけでは見えないSREチームの組織形態や役割の線引きを選考前に調査できます。リクルーティングアドバイザーが企業の人事へ直接ヒアリングを行い、一次情報を引き出すためです。

こうしたチームの成熟度や技術スタックの情報は自力で集めようとしても限界があり、転職サイトを眺めるだけでは手に入りません。そのため、ビジネスサイドとの距離感や裁量の幅まで事前に把握できるのは、大きなアドバンテージです。

だからこそ、キッカケエージェントは入社後のミスマッチを防ぐうえで心強い味方になります。

強みを言語化する職務経歴書添削と年収交渉

インフラ経験をSREの実績としてどう言語化するかが、書類選考を左右する最大のポイントです。キッカケエージェントでは元エンジニアのアドバイザーが書類を添削し、採用側に刺さる表現へ仕上げます。実際のところ、自分の経験をどう整理すればSRE向けにアピールできるのか、一人では意外と気づけません。

さらに年収面では、前職の給与ではなく市場価値をベースにした金額を企業へ直接交渉してくれます。書類の完成度と交渉力の両面からサポートを受けられる点は、転職の成功率を引き上げる大きな後押しです。

まとめ：インフラエンジニアからSREへ第一歩を踏み出そう

SREは、インフラエンジニアが積み上げてきた経験をそのまま活かせる数少ないキャリアパスです。資格取得や自動化実績づくり、ポートフォリオの公開といったステップは今日からでも始められます。

だからといって、完璧な準備が整うのを待つ必要はありません。一歩を踏み出した人から順にチャンスは広がっていくものです。まずは気になる資格の学習から始め、プロの力を借りたくなったらキッカケエージェントへの相談をおすすめします。

キッカケエージェントTOPに戻る