日本のSREはなぜ“インフラ寄り”になりやすいのか

SRE（Site Reliability Engineering）という役割で3年ほど働いています。
現場で感じた「SREの理想と現実のギャップ」について整理しました。
愚痴半分ですが、これからSREを目指す人の参考になればと思います。

---

SREの本来の定義（Google流）

SREはGoogleが提唱した「ソフトウェアエンジニアが運用をソフトウェア的に解決する」チームです。
公式のSRE本では以下の考え方が強調されています。

• 運用の自動化（Toil削減）
• 信頼性指標（SLI/SLO/SLA）とエラーバジェット
• モニタリングとインシデント対応
• 開発速度と信頼性のバランス調整

要するに 「OpsをDevのやり方でやる」 のがSREです。

---

日本企業でのSREの現実

一方で、日本企業のSRE求人や実務を見るとこうなりがちです。

• クラウドインフラ（AWS/GCP/Azure）の設計・運用
• CI/CDの構築・改善
• モニタリング基盤の整備
• IaCによる自動化（Terraform/Pulumi/CloudFormation）
• 障害対応やセキュリティ対応

……正直、インフラエンジニアの延長線です。

---

なぜ“インフラ寄り”になるのか

1. クラウド化の影響

   • インフラがコード（IaC/Kubernetes）で管理できるようになったため、
     「インフラ＋少しのプログラミング」でSREを名乗れるようになった。

2. 採用市場の要請

   • 企業は「既存の運用を効率化してくれる即戦力」を求めており、
     要件が“インフラ＋自動化”に寄りがち。

3. 文化の違い

   • GoogleやNetflixのようにDevとOpsが一体化した組織は稀。
   • 日本ではインフラチームがそのまま「SRE部隊」と呼ばれることが多い。

---

本来のSREとのギャップ

本来のSREは SLOを軸にDevとOpsが協調する仕組み ですが、
日本では「インフラ担当が便利屋化」してしまうケースが多いです。

• SLOが低下 → 原因はアプリの新規リリース
• 本来はアプリ改善が必要なのに、SREが丸投げされる
• 結果として「SRE＝なんでも屋」と誤解されやすい

---

日本でSREをやるなら必要なスキルセット

愚痴だけで終わらせないために、現場で特に役立つスキルを整理します。

• クラウド基盤運用（AWS/GCP/Azure）
• コンテナ運用（EKS/ECS/Kubernetes）
• IaC（Terraform/Pulumi/CloudFormation）
• 監視/Observability（Prometheus, Datadog, Grafana, ELK）
• 自動化スクリプト（Python/Go）
• インシデント対応とSLO設計

これらができると、日本市場では「即戦力SRE」としてかなり重宝されます。

---

まとめ

• SREは本来「ソフトウェアエンジニアリングでOpsを進化させる」役割
• 日本では「インフラ＋自動化要員」として扱われやすい
• 問題は 開発との分断。SREだけでは信頼性を担保できない
• これからSREを目指す人は「インフラ＋自動化」をまず武器にし、
  余裕があれば「アプリ理解」も広げると強みになる

---

💡 まとめると
日本でSREをやるなら、愚痴りつつも現実を受け入れて
「インフラ寄りのスキルを伸ばしつつ、アプリ側との協調を意識する」
これが一番現実的なキャリア戦略だと思います。