キャリアメディア / 未経験転職

未経験からSREになるには｜必要スキルと現実的なルート

職種：SRE ｜更新日 2026/7/4

SREへのキャリアチェンジは、情報システム・インフラ・バックエンドエンジニアリングの三領域が交差する職種だけに、「未経験」の定義が曖昧になりやすい。本記事では「SRE専任ポジション未経験」を起点に据え、どのようなバックグラウンドが活かせるか、何をどの順序で習得すべきか、そして現実的な転職ルートはどこにあるかを体系的に整理する。

SREとは何か——職種の本質を正確に理解する

SRE（Site Reliability Engineering）は、Googleが提唱したエンジニアリング原則を起源とする職種であり、「ソフトウェアエンジニアリングの手法でシステムの信頼性を設計・維持する」ことを本質とする。運用保守の延長線ではなく、SLO（サービスレベル目標）の設計、エラーバジェット管理、トイル削減のための自動化が中心業務となる。

インフラエンジニアやサーバーサイドエンジニアと混同されやすいが、SREが他職種と異なる点は「信頼性を定量的に扱う責任を持つ」ことにある。SLI（サービスレベル指標）を設定し、障害の影響をコードで測定・改善するサイクルを回す。コードを書く能力と運用知識の両方が求められる点が、採用難易度を高める主因でもある。

「未経験」の実態——スタートラインは一様ではない

SRE未経験転職と一口に言っても、応募者のバックグラウンドは多様であり、現場での受け入れられやすさは出発点によって大きく異なる。以下の分類を参照してほしい。

「IT経験はあるがSRE専任でない」層が現実的なターゲットであり、完全な非エンジニアからSREへの一段転換は、市場の現状では想定しにくい。

習得すべきスキルの全体像

コアスキル領域

SREに求められるスキルは大きく四つに整理できる。

1. 信頼性エンジニアリングの思想と設計 SLI/SLO/エラーバジェットの設計、障害対応フロー（インシデントマネジメント）、ポストモーテムの作成と改善サイクルの実行。概念の理解に留まらず、実際のサービスに当てはめて数値を設計できるレベルが目標となる。

2. インフラ・クラウドの実装知識 主要クラウドプロバイダー（AWS・GCP・Azureのいずれか）での実践的な構築経験、Kubernetes・コンテナ技術の基礎、Terraform等のIaC（Infrastructure as Code）による再現可能なインフラ設計が求められる。クラウドの「設定画面を触れる」レベルではなく、コードとして管理できる状態が最低ラインとなりやすい。

3. 可観測性（Observability）の実装 メトリクス・ログ・トレースの三本柱を適切に設計・収集・可視化する能力。Prometheus・Grafana・Datadogなどのツールの操作に加え、「何を計測すべきか」を自分で設計する思考力が問われる。

4. 自動化・プログラミング能力 Pythonまたはシェルスクリプトでのトイル削減スクリプトの実装、CI/CDパイプラインの設計・改善。バックエンドエンジニアほどのコーディング深度は必須ではないが、コードレビューを受けられる水準のコードを書けることが重要となる。

現実的な転職ルート——三つのパターン

パターン1：社内異動によるSRE転換

最もリスクが低い経路。自社サービスのインフラやバックエンドチームからSREチームへの異動を打診する方法で、業務とスキルアップを並行させながらロールを獲得できる。特にスタートアップや中規模SaaS企業では、SREチームを新設するタイミングで社内公募が行われるケースがある。

現職でインフラ改善・障害対応・監視強化などの業務に自発的に関わり、「SREとしての実績」を積み上げることが社内異動の交渉力となる。

パターン2：SREに近い職種を経由した転換（ステップ移行）

完全未経験に近い状態であれば、「DevOpsエンジニア」「クラウドインフラエンジニア」「プラットフォームエンジニア」の求人を経由するルートが現実的となる。これらの職種はSREとスキルセットが重なる部分が大きく、1〜2年の実務経験を経てSRE専任への転換を図る戦略となる。

パターン3：SRE採用に積極的な企業への直接応募

一部のスタートアップやSaaS企業では、ポテンシャルと学習姿勢を重視し、インフラ経験が薄い候補者でもSRE見習い的な形で採用するケースがある。ただしこのパターンは求人数が限られ、採用側が「教育コストを許容する体制を持っているか」に大きく依存する。

ケーススタディ：バックエンドエンジニアからSREへの転換の型

前提：Webサービス開発会社でバックエンドエンジニアとして3年勤務。PythonとRailsの業務経験あり。AWSの基礎的な操作は経験済みだがインフラ設計は未経験。監視ツールはCloudWatchを触った程度。

フェーズ1（0〜3か月）：基盤知識の整理

• Google SRE本（“Site Reliability Engineering”）の通読によるSLO/エラーバジェットの概念習得
• AWSの主要サービス（EC2・ECS・RDS・ALB・VPC）をTerraformでコードとして扱えるレベルに引き上げる
• PrometheusとGrafanaをローカル環境または個人AWSアカウントで構築・試行

フェーズ2（3〜6か月）：実務への接続

• 現職で監視設定の見直しや障害対応プロセスの改善提案を担当し、実績として記録する
• KubernetesのCKA（Certified Kubernetes Administrator）取得を目指す（必須ではないが転職の説得材料になりやすい）
• 個人ブログや社内LTで取り組み内容を言語化し、アウトプットの形を作る

フェーズ3（6か月〜）：転職活動の開始

• SREまたはインフラエンジニア求人への応募を開始。ポートフォリオとして「SLOを設計した経験の記述」と「Terraformコードの公開リポジトリ」を準備
• 職務経歴書には「信頼性向上の取り組み」を定量的に記載する（例：障害対応時間の短縮、監視カバレッジの改善）

年収レンジの目安

職種・経験年数・企業規模によって大きく幅が出るが、以下は市場感を把握するための参考値として捉えてほしい。

上記はSaaS・IT企業の正社員・東京圏を想定した目安であり、事業会社かSIか、企業の規模感、個人の実績によって大きく変動する。

よくある質問

Q. 資格はどれを取るべきですか？

資格取得そのものが採用の決定打になることは少ないが、学習の道標として有効なものはある。AWS認定（SAA・SAPなど）はクラウド基礎の証明として機能しやすく、CKA（Certified Kubernetes Administrator）はKubernetes理解の担保として評価されやすい傾向にある。ただし資格取得よりも、実際に構築・設計した経験をGitHubや職務経歴書で示せることの方が、採用現場では重視されやすい。

Q. プログラミングはどの言語をどのレベルまで習得すればよいですか？

PythonまたはGoが業務での使用頻度が高い傾向にある。レベル感としては「インシデント対応やトイル削減のための自動化スクリプトを自力で書き、コードレビューを受けられる水準」が現実的な目標となる。フロントエンドやアプリケーション開発エンジニアほどのコーディング量は求められないが、コードを「読める・直せる」だけでは不十分と考えたほうがよい。

Q. 未経験でSREに応募する際、職務経歴書で何を強調すべきですか？

SREの業務と重なる経験を「信頼性・自動化・可観測性」の観点で再解釈して記述することが有効となる。例えば「障害対応の手順を整備した」「デプロイフローを改善した」「監視ルールを追加した」といった経験は、SREの言語でリフレーミングできる。また、現職でSLOに相当する指標を定義・追跡しようとした試みがあれば、その思考プロセスごと記述すると説得力が増しやすい。

Q. 転職エージェントを使う場合、SRE転職に詳しいエージェントをどう見分ければよいですか？

担当者がSLO・エラーバジェット・IaCなどの概念を文脈に沿って会話できるか、求人票の中身を技術的に解説できるかが判断の手がかりになる。SRE・インフラ・DevOps領域の求人を継続的に扱っている実績があるかどうかも、初回面談で確認するとよい。

まとめ

SRE未経験転職において重要なのは、「どこから転換するか」によって必要な補完スキルと現実的なルートが異なることを正確に把握することにある。インフラまたはバックエンドの実務経験を持つ層であれば、信頼性設計の思想・IaC・可観測性の実装という三点を集中的に強化することで、SRE専任ポジションへの転換可能性は十分に開かれている。一方、手運用中心の経験しかない段階では、まず隣接職種を経由するステップ移行が現実的な戦略となる。資格よりも実績の言語化、ツールの操作よりも設計の思想が問われる職種であることを念頭に置いて準備を進めてほしい。現状のスキルセットがSRE市場においてどのように評価されうるかを客観的に確認したい場合は、領域特化のキャリア相談を活用することも一つの手段となる。