インフラエンジニアからSREになるには？活かせる経験・必要スキルと転職準備

「SREの求人が気になるけれど、今のインフラ経験で応募できるのかな」「クラウドやプログラミングを、どこまで学べばよいのだろう」。新しい職種を目指すとき、技術名が並んだ求人票だけでは、自分との距離がわかりにくいですよね。

インフラエンジニアの運用・構築経験は、SREを目指す土台になります。ただし、経験年数やクラウド資格だけで判断するのではなく、障害の切り分け、繰り返す作業の改善、コードを使った仕組みづくり、開発チームとの連携に、どのような接点があるかを整理することが大切です。

この記事では、インフラ経験者がSREへの転職を考える際に、仕事内容の違い、活かせる実務、学習の進め方、求人の確認点をまとめます。資格を順番に取るだけの準備ではなく、今の仕事から説明できる経験を見つけていきましょう。

SREとは？インフラエンジニアから目指すときの考え方

SREはSite Reliability Engineeringの略です。Googleの解説では、ソフトウェアエンジニアリングの考え方を運用に取り入れ、人が繰り返し担う仕事を仕組みで解決するアプローチが示されています。参考：Google SRE「Introduction」

転職先を考えるうえでは、「障害が起きたら対応する」に加えて、「繰り返す問題を減らし、変更しても安定して使える状態をどう作るか」に関わる仕事、と捉えると理解しやすくなります。実際の担当範囲は、応募先のチームに確認する必要があります。

インフラ運用でも、すでにその一部に取り組んでいる方はいるはずです。頻発する通知を見直した、復旧手順を改善した、定型確認を自動化した。そうした経験は、単に「運用を何年担当したか」よりも、応募先との接点を説明する材料になります。

一方、SREという肩書きだけで、仕事内容や働きやすさが決まるわけではありません。技術の学習に入る前に、自分がやりたいのは障害対応を深めることなのか、運用をコードで改善することなのか、サービス全体の信頼性を考えることなのかを整理しましょう。

インフラ・クラウドエンジニアとSREの違い

職種名の境界は、会社や組織によって重なります。インフラエンジニアも自動化や信頼性の改善を担当できますし、SREもネットワークやOSの知識を使います。次の表は仕事を比べるための視点であり、厳密な職種の線引きではありません。

クラウドは利用する基盤の種類であり、SREは仕事の進め方や役割を考える言葉です。「AWSを使っているからSRE」「オンプレミスだからSREではない」とは決められません。求人票では、サービス名に続いて、何を改善する仕事なのかを読みましょう。

たとえば「クラウド基盤の運用」と書かれている場合も、決められた変更を実施するのか、構成や監視の方針から見直すのかで経験できることが変わります。自分が進みたい方向と、入社後に任される範囲を照らし合わせてください。

まずクラウドの実務へ領域を広げたい場合は、オンプレ経験を活かすクラウド転職の準備も参考になります。SREという名前を最初の条件にするより、身につけたい経験を言葉にすると候補を比べやすくなります。

求人を読む前に知っておきたい、SREの基本用語

用語を全部暗記する必要はありません。まずは、「何を測るか」「どの水準を目指すか」「どの作業を減らすか」の三つを、現在の業務に置き換えて考えてみましょう。

SLIとSLO：測る指標と目標を分ける

SLIはサービスの状態を測る指標、SLOはその指標に対して設定する目標です。たとえば、対象リクエストの成功割合を測り、一定期間で満たしたい水準を決めます。何を対象に、どこで、どの期間測るかもセットで定義します。参考：Google SRE「Service Level Objectives」

CPU使用率を見ることが不要になるわけではありません。原因を調べるための機器の情報と、利用者がサービスを使えているかを見る情報をつなげて考えます。面接では、「どの数字を集めたか」に加えて「その情報で何を判断したか」を振り返るとよいでしょう。

エラーバジェット：目標に対して許容する未達分を考える

エラーバジェットは、SLOに対して許容する未達分です。単に障害を許すという意味ではなく、信頼性の状態を見ながら変更や改善の優先順位を話し合う材料になります。応募先では、実際にどう判断へ使っているかを確認します。

学習で考えるなら、まず一つの処理を対象に、成功と失敗の定義を決めるところからで構いません。数値だけを立派に見せるより、なぜその指標と期間を選んだのか、測れない範囲は何かを説明できるようにしましょう。

トイル：繰り返す運用作業を、仕組みで減らす

Googleはトイルを、手作業・反復的・自動化可能といった性質を持ち、サービスの成長に伴って増えやすい運用作業として説明しています。単に「面倒な仕事」の別名ではありません。参考：Google SRE「Eliminating Toil」

今の仕事なら、毎回同じ情報を集め直す、同じ確認を繰り返すといった場面から改善候補を探せます。ただし、すべての確認をなくせばよいわけではありません。人の判断が必要な部分や、承認の役割も分けて整理します。

運用・構築経験から、SREにつながる実績を見つける

応募に向けては、「対応したこと」と「対応を通じて変えたこと」を分けて書き出すと、自分の経験を整理しやすくなります。大規模なサービスの経験や、特別な肩書きがなければ何も伝えられないわけではありません。

障害対応は、切り分けの根拠と改善まで振り返る

「アラートを受けて担当者に連絡した」場合も、何を確認して連絡したのかを掘り下げます。影響範囲、変更履歴、通信経路、ログなど、確認した情報と判断の順序を説明できると、問題への向き合い方が伝わります。

復旧後に、通知先や手順、記録項目を変更した経験があれば、それも分けて書きます。自分が提案した部分、チームで決めた部分、実装を担当した部分を混ぜないことが大切です。

構築経験は、変更を確かめる方法まで説明する

設定投入だけでなく、変更前の確認、試験、差分の確認、切り戻しの準備まで振り返ります。SRE求人の業務と重なるかは個別に見る必要がありますが、変更の影響を見積もり、確認しながら進めた経験は説明の材料になります。

コード化した経験がなくても、手順のどこで入力ミスが起きやすかったか、どの項目を機械的に確認できそうかを考えたことは整理できます。ただし、「自動化した」と表現するのは、実際に仕組みを作って使った範囲に限りましょう。

改善実績は、使われた範囲と残る課題を示す

たとえば「ログ収集をスクリプト化した」なら、誰が、いつ、何のために使っているかも説明します。作った後の修正や引き継ぎまで担当していれば、その範囲も書きます。試作しただけのものと、本番業務で使われたものは区別します。

時間短縮などの数字は、確認できる記録がある場合に使います。測っていない改善率を作る必要はありません。改善前の困りごと、変えた内容、利用状況、まだ残る手作業を説明するだけでも、仕事の中身が見えます。

現在の運用業務で担当範囲を広げたい方は、運用から構築へ進むための実績づくりも参考にしてください。SREへの準備でも、業務の中で相談できる小さな改善から始められます。

何を学ぶ？求人から逆算する4つの準備

学ぶ技術を増やす前に、気になる求人の必須要件と歓迎要件を分けます。ここでは学習の軸を四つに整理しますが、すべてを同じ深さで終えてから応募する、という意味ではありません。今の経験と応募先で不足している部分を見比べてください。

1. 基盤の理解：OS、ネットワーク、名前解決、権限などを、障害の切り分けと結びつけて説明する。
2. コードと変更管理：小さな処理を作り、履歴を残し、他の人が確認できる形にする。
3. 状態の観測：ログや数値から、サービスのどこに問題があるかを考える。
4. チームでの改善：課題、提案、確認方法、残るリスクを文章で共有する。

プログラミング言語は、求人の要件と作りたいものから選びます。最初はファイルを読み、情報を整理して出力する程度の小さな課題でも構いません。正常に動くことに加え、入力が欠けた場合や処理が失敗した場合にどうなるかも確認します。

Gitなどで変更履歴を残すなら、変更理由がわかる単位に分け、実行方法と注意点も記録します。コードを書いた量だけでなく、他の人が読んで確認できるか、変更後の動作を確かめられるかを意識しましょう。

クラウド、コンテナ、構成のコード化などは、応募先が何に使っているかを確認して学習対象を決めます。求人にある名称を全部並べて触るより、一つの小さな構成で、変更・確認・復旧まで説明できる方が、自分の理解を確かめやすくなります。

資格学習は知識の整理に使えますが、取得した資格だけで実務を担当できると決まるわけではありません。学んだこと、検証したこと、業務で使ったことを分けて記録してください。

小さな検証で「運用を改善する流れ」を経験する

個人学習では、大きなサービスを作る必要はありません。自分が管理できる検証環境で、簡単なWebアプリや処理を一つ動かし、状態を確認して改善する流れを試す方法があります。以下は学習例であり、採用を保証する課題ではありません。

成果物には、構成の説明、実行方法、測る対象、試した変更、確認結果をまとめます。画面の画像を貼るだけでなく、「何がわかったか」「何は未検証か」が読めるようにすると、面接でも説明しやすくなります。

クラウドで試す場合は、利用料金の確認と不要なリソースの片づけまで含めて計画します。会社の本番環境で無断の検証をしたり、顧客の設定やログを個人の成果物へ持ち出したりしないようにしてください。

実務経験がある方は、個人検証を増やすだけでなく、今のチームで改善を担当できる余地も探しましょう。既存の手順の見直しや、確認の自動化を相談する方法があります。仕事の外に学習時間を足し続けることだけが準備ではありません。

SRE求人で確認したいのは、技術名と改善できる体制

入社後の仕事を知るには、技術スタックに加えて、何を改善したいチームで、自分に何を任せる予定なのかを確認します。制度や理想像だけでなく、最近の実例を聞くと具体的になります。

「改善を進めたい」という説明があったら、最近完了した改善や、今後着手する課題を聞いてみます。改善時間の割合だけを合否の基準にせず、忙しくなったときにどう優先順位を変えるかまで確認できると、働く姿を想像しやすくなります。

SLOをまだ導入していないチームでも、今後整備する役割を募集している場合があります。そのときは、自分が一人で立ち上げる想定なのか、経験者と進められるのかを確認します。同じ「未整備」でも、任される責任は違います。

夜間対応の有無も、職種名から推測しないようにしましょう。オンコールは連絡に備える当番ですが、実際の待機条件や呼び出し、対応範囲はチームによります。当番の人数や支援体制まで聞き、自分が続けられる条件かを考えます。

職務経歴書・面接・年収は、担当する役割に合わせて考える

職務経歴書には、現在の職種を無理にSREへ言い換える必要はありません。「運用担当として何を改善したか」を正確に書き、その経験が応募先の課題にどうつながるかを説明します。具体的な書き方は、インフラエンジニアの職務経歴書の記事でも紹介しています。

この例は、自分が実際に行ったことへ置き換えてください。面接では、うまくいった点だけでなく、失敗時の扱いや残った手作業を聞かれることも想定して、説明できる範囲を整理します。

年収も、SREという肩書きだけで高くなると考えない方がよいでしょう。入社直後に任される業務、技術的な判断範囲、チームを支える役割、当番などの条件を確認します。クラウド運用からSREへ名称が変わるだけなのか、仕事の範囲が広がるのかを見比べてください。

経験と条件を整理する補助には、whoamiの年収診断も使えます。診断モデルには、従業員1,000人以上で＋13.1％、東京都で＋10.6％、クラウド実務経験ありで＋10.0％という補正設定があります。これらはモデル上の条件であり、SREへ転職すればその割合だけ昇給することを示すものではありません。

希望額を具体的に相談する段階では、インフラエンジニアの年収交渉と内定時の確認点も参考にしてください。診断額と企業の提示額を同じものとして扱わず、仕事内容と給与内訳をそろえて判断しましょう。

インフラエンジニアからSREを目指す人のよくある質問

SRE未経験でも、インフラ経験から応募できますか？

求人の必須要件と役割が合えば候補になります。職種名としてのSRE経験がなくても、障害調査、自動化、監視改善などの接点を整理しましょう。未経験の領域は、学習と実務を分けて説明します。

プログラミングが苦手でも目指せますか？

目指すことはできますが、コードで問題を解決する準備は重要です。必要な深さは求人で確認し、小さな処理の作成、変更履歴、動作確認から始めましょう。コードをほとんど扱わない仕事を希望するなら、担当内容が自分に合うかも検討します。

クラウド資格やKubernetesの知識は必須ですか？

すべてのSRE求人に共通する必須条件とはいえません。応募先の要件と利用環境を確認します。資格の有無だけでなく、どの構成や作業を説明できるか、実務で担当した範囲はどこかを整理してください。

監視・運用の経験は、SREの仕事で活かせますか？

切り分け、影響の確認、記録、引き継ぎなどは接点になります。そのうえで、繰り返す問題や作業をどう改善したかを説明できると、応募先の課題と結びつけやすくなります。

SREならリモート勤務や夜勤なしで働けますか？

職種名だけでは決まりません。出社条件と勤務時間、待機当番、緊急対応をそれぞれ確認します。開発・改善を担当する仕事でも、サービスの運用体制によって時間外の対応が含まれる場合があります。

今の経験から、一つの改善を説明できる状態にしよう

インフラエンジニアからSREを目指す準備は、知らない技術を一度に増やすことから始めなくても大丈夫です。今の仕事で何を確認し、何に困り、どう改善したか。その経験を整理するところから進められます。

まずは、繰り返している作業や障害対応を一つ選び、自分が担当した範囲と、仕組みで変えられそうな部分を書き出してみてください。そこから求人の業務を読み直すと、活かせる経験と次に学ぶことが見えやすくなります。

技術名や肩書きに合わせるだけでなく、どのサービスを、どんなチームで、どう改善したいかを考える。その視点を持ちながら、自分に合う次の仕事を探していきましょう。