SREを目指すには｜他の職種からのキャリアチェンジ

SREを目指す道は一つではなく、インフラ運用、バックエンド開発、ネットワーク、QA・テスト自動化など、どこから出発しても進めます。共通して必要なのは、運用の困りごとをコードで減らした経験と、信頼性を数字で扱って関係者と判断した経験の2つです。

出発点によって、すでに持っているものと足りないものが違います。この記事では、出発点ごとの生かせる経験と足りない部分、埋める順番、面談で確かめられやすいこと、年代によるルートを整理します。フリーランスとして独立する手順はSREがフリーランスになるにはで扱っているので、ここでは「SREにたどり着くまで」に絞ります。

SREに求められることを先に押さえる

SREは、肩書きより中身で見られる職種です。案件で求められることを大きく分けると、次の4つになります。

Googleが公開しているSREの本では、運用の作業（トイル）を各SREの時間の50%未満に抑えることを目標に掲げています（2026年10月時点、公開ページによる）。運用を回すだけではSREと見なされにくく、残りの時間で運用そのものを減らす仕事をしているかが問われる、と考えておくと方向を誤りにくくなります。スキルの中身はSREに求められるスキルで詳しく扱っています。

出発点ごとの生かせる経験と足りない部分

インフラ運用・サーバーエンジニアから目指す

もっとも多い出発点です。障害対応の場数、監視の運用、サーバーやミドルウェアの知識はそのまま生きます。

足りなくなりやすいのは、コードで仕組みを変える経験と、開発チームと優先度を話す経験です。手順書どおりに運用してきた期間が長いと、自動化の経験が小さなスクリプトにとどまっていることがあります。まずは自分の担当する運用の中で、毎週繰り返している作業を一つ選び、コードにして手放すところから始めると、SREの実績として語れる材料になります。

バックエンド開発者から目指す

コードを書く力、アプリケーションの中身の理解、リリースの流れの知識が強みです。障害の原因がアプリケーション側にあるとき、ログやトレースを読んで切り分けられる点は、運用出身の人にない強みになります。

足りなくなりやすいのは、基盤とネットワークの知識と、当番として障害に向き合った経験です。担当サービスの監視の設定やアラートの見直しを自分から引き受け、障害の当番に入る機会をつくると、運用の現実が見えてきます。

ネットワークエンジニアから目指す

通信の切り分け、冗長構成の設計、変更作業の慎重さが生きます。クラウドの環境でも、通信が原因の障害は少なくありません。

足りなくなりやすいのは、アプリケーションに近い指標の扱いと、コードでの構成管理です。機器ごとの監視から、利用者の体験に近い指標へ視点を移すことが最初の一歩になります。ネットワークからの広げ方はネットワークエンジニアのキャリアチェンジもご覧ください。

QA・テスト自動化エンジニアから目指す

テストの自動化、リリース前の品質の見方、CI/CDの仕組みの知識が生きます。壊れても戻せるリリースの仕組みづくりは、テストの経験と相性がよい領域です。

足りなくなりやすいのは、本番環境の運用と障害対応の経験です。リリース後の監視や、段階的なリリースの仕組みに関わる機会を持つと、テストの経験を本番の信頼性につなげられます。

社内情報システム・ヘルプデスクから目指す

利用者の困りごとを聞き取る力、社内の関係者と調整する経験は、SLOを決めるときに役立ちます。

足りない部分は多く、クラウドの基盤、コード、本番の障害対応のいずれも一から積む必要があります。いきなりSREを名乗るより、クラウドの運用やインフラ構築の仕事を経由するほうが現実的です。

足りない部分を埋めるときの順番

出発点にかかわらず、次の順で埋めていくと、実務の中で積み上げやすくなります。

1. 今の仕事のトイルを一つ減らす：毎週・毎日繰り返している手作業を書き出し、一つをコードにして手放します。減った時間を記録しておくと、そのまま実績になります
2. 障害の振り返りに加わる：障害の後に振り返りの文書を書き、対策を追うところまで関わります。責めずに仕組みの原因を探す進め方を、場を通して身につけます
3. 指標を一つ決めてみる：担当サービスで、利用者の体験に近い指標を一つ選び、目標を決めて追ってみます。正式なSLOの運用でなくても、考え方を試した経験は話せます
4. 基盤の技術を広げる：クラウド、コンテナ、Infrastructure as Codeのうち、手薄なものを一つずつ実務か検証環境で触ります

資格は、基盤の知識を補う手段として役立つことがあります。たとえばKubernetesの知識を示す資格はCKAの記事で扱っています。ただ、SREの案件では資格より、上の1〜3の経験を話せるかが重く見られる傾向があります。

面談で確かめられやすいこと

キャリアチェンジでSREの案件に応募すると、面談では次の点がよく確かめられます。

• 自動化した経験：何を、どの言語や道具で、どれくらい減らしたか
• 障害対応での役割：指揮、切り分け、連絡のどれを担い、その後に何を変えたか
• 指標の扱い：どの指標を見ていたか、それで判断が変わった場面があるか
• 開発チームとの関わり方：改善の提案をどう伝え、どう合意したか
• 当番の経験：オンコールに入ったことがあるか、どんな体制だったか

SREの肩書きでなかった経験の書き方はSREのスキルシートの記事で記入例とあわせて解説しています。

年代によって選びやすいルート

20代・30代前半

社内での異動や担当の広げ方で、SREの経験を積みやすい年代です。SREのチームがある会社なら、正社員のうちにチームに加わり、当番と改善の両方を経験してから独立を考えるほうが、選べる案件は広がります。

30代後半・40代

元の職種での実績が厚くなっている年代です。運用やネットワーク、開発で積んだ経験に、自動化と振り返りの経験を足して、「その領域に強いSRE」として案件に入る道が現実的です。たとえば、ネットワークに強いSRE、データベースに強いSREといった形です。

50代

自分でコードを書く量より、障害対応の指揮や、信頼性の方針づくり、古い基盤からの移行計画など、判断の重い役割で関わる道が選びやすくなります。年代ごとに期待される役割はSREは40代・50代でも働けるかで整理しています。

どの年代でも、職種を変えるときの全体の考え方は職種転換の記事で扱っています。

よくある質問

インフラ運用の経験だけで、SREの案件に入れますか？

入れる案件はありますが、運用の当番が中心の案件になりやすい傾向があります。改善を任される案件に入るには、自動化や振り返りの経験を具体的に話せることが大切です。まずは今の仕事でトイルを一つ減らし、その前後を記録しておくことをおすすめします。

SREとDevOpsエンジニア、プラットフォームエンジニアの違いは何ですか？

重なる部分が大きく、現場によって呼び方が違います。SREは信頼性を数字で扱い、改善の優先度を決めることに重心があり、DevOpsやプラットフォームの仕事は開発と運用の流れを整えることに重心がある、と考えると整理しやすくなります。案件を選ぶときは、肩書きより業務の中身を確かめてください。DevOpsの進み方はDevOpsエンジニアがフリーランスになるにはをご覧ください。

プログラミングが得意でなくても、SREを目指せますか？

目指すことはできますが、運用を自動化するためのコードは書ける必要があります。最初から大きなものを作る必要はなく、繰り返しの作業を小さなスクリプトに置き換えるところから始めれば十分です。求められる程度はSREに求められるスキルで触れています。