フリーランス市場におけるSREの月額平均単価は 93.5万円/月 で、職種別でも高い水準です。ただし、この数字を「SREと名乗れば高単価になる」と読むのは誤りです。
単価が高くなる理由は、ツールの知識ではなく、サービス停止や性能劣化といった損失の大きい問題を予防し、復旧する責任にあります。
SRE・インフラ・DevOpsの違い
求人では用語が混在します。一般的な違いは次のように整理できますが、会社ごとの実務を確認する必要があります。
| 呼称 | 主な焦点 | 求人で確認すること |
|---|---|---|
| インフラエンジニア | サーバー、ネットワーク、クラウド基盤の設計・構築・運用 | 構築と運用の比率、自動化の範囲 |
| SRE | 信頼性をソフトウェアで改善し、開発速度との境界を決める | 信頼性目標、コード変更権限、オンコール |
| DevOps | 開発と運用の分断を減らす考え方・実践 | 専任職なのか、チーム全体の文化なのか |
SREという肩書でも、実態が監視アラートの一次対応と手作業の定常運用だけなら、専門性は伸びにくくなります。反対に、インフラエンジニアという名称でも、アプリケーションを変更し、信頼性目標や自動化を担うならSREに近い経験を積めます。
職種名を比較するのではなく、障害を減らすためにどこまで変更できるか、どの指標へ責任を持つかを確認します。
責任範囲1：障害を切り分けて復旧する
監視アラートを受け取るだけでなく、どこまで正常かを確認し、変更履歴、メトリクス、ログから原因を絞ります。評価されるのは障害の件数ではなく、次の力です。
- 影響範囲を短時間で判断する
- 復旧と原因調査を分けて進める
- 再発防止を監視や設計へ反映する
オンコールがある求人では、頻度、手当、一次対応者、翌日の勤務調整まで確認します。高い提示額に負荷が織り込まれている場合があるためです。
年収を分けるのは製品知識より問題の難しさ
クラウドサービスや監視ツールの名前は求人の入口になりますが、給与を押し上げるのは次のような経験です。
変更を安全にする
Infrastructure as Code、段階的なリリース、ロールバック、権限管理などを使い、作業者の注意力に依存しない変更を作ります。
観測できる状態を作る
メトリクス、ログ、トレースを集めるだけではなく、利用者への影響から原因へたどれる観測設計を行います。アラートは多いほどよいのではなく、行動につながるものに絞ります。
開発チームへ改善を戻す
障害を運用チームだけで処理せず、アプリケーションの設計、テスト、リリース方法へ改善を戻します。組織の境界を越えられることがSREの価値です。
コストと信頼性を両立する
余裕を増やせば信頼性は上がりますが、費用も増えます。利用状況を測り、守るべき機能と許容できるリスクを分けます。
責任範囲2：定常作業を自動化する
手順書どおりの作業を正確に行うだけでは、経験が増えても価値は頭打ちになります。繰り返し作業をコード化し、安全に誰でも実行できる状態へ変えると、組織全体の時間と事故を減らせます。
自動化の実績は「スクリプトを書いた」で終わらせず、対象作業、失敗時の戻し方、削減できた工数、事故の変化まで説明します。
責任範囲3：性能と容量を予測する
今動いているかだけでなく、利用が増えたときにどこが先に限界へ達するかを考えます。負荷試験、ボトルネック分析、容量計画を行い、コストと信頼性のバランスを取ります。
これはアプリケーションコードを読む力とも直結します。インフラだけを見ていても、遅いクエリや直列処理が原因なら解決できません。年収につながるスキルで扱う読解力が、SREでも土台になります。
必要なスキルを6領域で整理する
- OS・ネットワーク — 名前解決、接続、プロセス、ファイル、権限の問題を切り分ける
- クラウドとIaC — 再現可能な構成と変更レビューを作る
- アプリケーション開発 — コードを読み、運用上の問題を実装で直す
- データと性能 — クエリ、キャッシュ、キュー、容量の限界を予測する
- 観測と障害対応 — 影響把握、復旧、原因分析、再発防止を行う
- 合意形成 — 信頼性、コスト、開発速度のトレードオフを説明する
すべてを同じ深さで持つ必要はありません。自分の強い領域を一つ持ち、障害を端から端まで追える程度に隣接領域を広げます。
資格は転職の入口、実績は採用の根拠
クラウドやネットワークの資格は、学習範囲を作り、基礎知識を示すのに役立ちます。ただし、資格だけでは本番の責任を担った証明にはなりません。
資格学習と並行し、現在の環境で次のような小さな実績を作ります。
- 手作業のデプロイを一部自動化する
- 重要な処理へメトリクスを追加し、正常値を定義する
- よくある障害の切り分け手順を作り、訓練する
- 負荷試験を行い、最初に限界へ達する場所を特定する
- 変更失敗時のロールバックを自動化する
面接では、使った製品名より「何が失敗し得たか」「どう安全にしたか」を説明します。
責任範囲4：信頼性を事業判断に変える
可用性を上げるほどコストと開発速度に影響します。すべてを最高水準にするのではなく、どの機能をどこまで守るかを事業側と合意する役割が必要です。
求人票で職種名より見る項目
同じSREでも、実態は大きく異なります。
- 信頼性の目標を誰が決めるか
- アプリケーションコードを変更する権限があるか
- 定常運用と改善に使う時間の比率
- 障害対応後の振り返りが評価されるか
- オンコールの頻度と補償
加えて、改善へ使える時間を聞きます。障害と定常作業だけで勤務時間が埋まるチームでは、根本原因へ手を入れられません。「直近3か月で自動化した運用作業は何ですか」「障害後の改善は誰が優先順位を決めますか」という質問で実態が見えます。
正社員としての相場は、職種名だけでなく経験年数、企業タイプ、勤務地、スキルを合わせて見ます。
| 企業タイプ | 推定レンジ | レンジの図 |
|---|---|---|
| メガベンチャー・外資 | 780〜915万円 | |
| 上場・大手 | 686〜805万円 | |
| 中小の受託・SIer | 593〜696万円 | |
| スタートアップ | 624〜732万円 | |
| SES | 530〜622万円 |
アプリケーションエンジニアからSREへ移る6ステップ
- 現在のサービスで、デプロイから監視までの流れを図にする
- 直近の障害を一つ選び、検知と復旧の遅れを分析する
- 手作業を一つコード化し、失敗時の戻し方も作る
- OS、ネットワーク、クラウドの不足を障害事例から学ぶ
- オンコールや運用改善へ部分的に参加する
- 問題、判断、結果を職務経歴書へまとめる
インフラエンジニアから移る場合は、アプリケーションコードとテストを追加で強化します。どちらの出身でも、自分の領域だけで問題を閉じないことが移行の要点です。
SRE求人の危険信号
- オンコール頻度や補償を説明できない
- アプリケーションを変更する権限がない
- 信頼性の指標がなく、障害件数だけを追っている
- 自動化より手順遵守が主な評価項目になっている
- 開発チームとの振り返りがない
- 欠員を高い提示額だけで埋めようとしている
一つ当てはまるだけで悪い求人とは限りません。ただし、どの時期にどう改善する計画なのか、入社者にその権限があるのかを確認します。
面接で聞かれやすいテーマと答え方
最近の障害をどう改善したか
障害の大きさを誇るのではなく、影響把握、復旧、原因、再発防止の順で説明します。自分が担当した範囲と、チームで判断した範囲を分けます。
信頼性と開発速度が衝突したらどうするか
「信頼性を優先する」だけでは答えになりません。利用者影響、変更頻度、復旧可能性を測り、どのリスクを受け入れるか関係者と合意する過程を話します。
自動化の対象をどう選ぶか
頻度、失敗時の影響、作業時間、変更の多さを比較します。一度しか行わない複雑な作業を無理に自動化せず、手順と検証を整える判断もあります。
知らない障害へどう対応するか
知識量ではなく切り分け方を示します。利用者影響を確認し、正常な範囲を見つけ、変更履歴と観測情報から境界を狭めます。復旧と原因調査を分ける判断も重要です。
SREから先のキャリア
- スタッフ・プリンシパルSRE：複数チームの信頼性と技術方針を扱う
- プラットフォームエンジニア：開発者が安全に利用できる共通基盤を作る
- セキュリティ・性能専門職：特定の失敗コストへ深く責任を持つ
- エンジニアリングマネージャー：SRE組織の採用、配置、成果を担う
- アプリケーション側のテックリード：運用経験を設計と開発へ戻す
キャリアは一方向ではありません。運用で得た障害と性能の知識は、アプリケーション設計にも使えます。次の役割で何に責任を持ちたいかから、深める領域を決めます。
入社前の最終チェック
- 信頼性の指標と優先順位を説明できるチームか
- アプリケーションを含む根本原因へ変更できるか
- 定常作業を減らす時間と権限があるか
- オンコールの頻度、補償、翌日の扱いが明確か
- 障害後の振り返りが個人批判ではなく改善につながるか
- 入社後半年に期待される改善テーマが具体的か
まず現職で小さな運用課題を一つ選び、検知、復旧、自動化、効果測定まで担当すると、SREへの転職で使える一連の実績になります。