「ものづくり」をしたいのに、トラブルシューティングばかり
ある日、SREチームのメンバーと話していて、こんな声を聞いた。
「SREの仕事って、有事の際に問題を沈下することが主な仕事になりがちで、ものづくりをしたいエンジニアにとってはモチベーションが上がらないこともある」
確かに。既存のオペレーションを自動化したり、トラブルシューティングしたりするけど、新しい何かが生まれているわけじゃない。普段サービスが安定して動いている状態だと感謝されないし、でも問題があったら呼び出される。
これ、すごく本質的な問題だと思った。
警察・消防との類似性
ふと思ったんだけど、SREの仕事って、日常に近い仕事で言ったら 警察・消防・自衛隊 と似た構図なんじゃないか。
彼らも税金を使って社会を守る活動をしているわけだけど、問題が起きないときは訓練をしている。でも「何もしてない」と見られがちで、予算を削られたりする。
「予防の価値」は見えにくい。
- 新機能リリース → 「売上に貢献した!」と可視化しやすい
- システムが24時間安定稼働 → 「当たり前」と思われる
- 大規模障害を未然に防いだ → そもそも起きてないから認識されない
警察・消防も同じで、「犯罪率が低い」「火事が起きない」って、実は彼らの活動の成果なのに、「何もしてない」と見えてしまう。
SREは「守る人」だけじゃない
でも、警察・消防も実は「ものづくり」をしているんだよね。
- 消防は防災インフラの設計や訓練プログラムの開発
- 警察は防犯システムの構築や地域コミュニティづくり
- 自衛隊は有事シミュレーションや装備の研究開発
SREも同じで:
- 信頼性を「設計」する: 新機能のアーキテクチャレビュー、SLO/SLIの策定
- カオスエンジニアリング: 意図的に障害を起こして耐性を鍛える(これ、めちゃくちゃクリエイティブ)
- 観測可能性の構築: 複雑なシステムを可視化する監視基盤づくり
- 自動化ツールの開発: toil(定型作業)を削減する仕組みづくり
つまり、SREって本当は「守り」と「攻め」の両面がある仕事なんだと思う。
ビジネスの中で軽視されがちな構造
ただ、ビジネスの中にいると、SREのポジションって結構軽視されがちというか、事業価値を産んでいないと見られてしまう ことがある。
これも警察とかと同じで、「自分たちの税金で飯食いやがって」と感じる人達がいるのと同じ構図だと思う。
特にスタートアップや成長期の企業だと:
- 短期的ROIが重視される → 「今すぐ売上に繋がるか?」
- 機会損失は計算されない → 「障害で失った信頼」は財務諸表に載らない
- 予算削減の標的になりやすい → 「今動いてるんだからSRE減らしても大丈夫では?」
そして、怖いのが 負のスパイラル だ。
予算削減
↓
人員不足・ツール不足
↓
インシデント増加
↓
「SRE無能だ」
↓
さらに予算削減
予算削減 → 人員不足 → インシデント増加 → 「SRE無能だ」 → さらに予算削減。
これ、警察でも消防でも起きてる。「犯罪増えてるのに何やってんだ」と言われて予算削られて、パトロール減って、犯罪が増える…みたいな。
鶏卵問題:問題が起きないと予算がつかない
さらに厄介なのが、鶏卵問題 だ。
パターン1: 問題が起きないと予算がつかない
- 大規模障害 → 緊急で予算承認 → 対策実施 → 安定稼働 → 「もう大丈夫だよね?」 → 予算削減
パターン2: 予防投資が評価されない
- 「このままだと半年後にDBが限界を迎えます」
- 「でも今動いてるよね? 本当に必要?」
- (半年後、障害発生)
- 「なんで予測できなかったんだ!」
これって消防の「耐震補強予算」と全く同じ構図だよね。地震が起きる前は「無駄」、起きた後は「なぜやらなかった」。
Platform Engineeringの台頭
ここ2-3年、Platform Engineering という考え方が注目されている。
これは、開発者が自分でインフラを操作できる「セルフサービス基盤」を作る活動 のことだ。
具体的には:
- 開発者が自分でデプロイできるCI/CDパイプライン
- ボタン一つで環境が立ち上がるIaC(Infrastructure as Code)
- 標準化されたObservability(監視・ログ・トレース)
- 開発者ポータル(Backstage、Portなど)
背景には、DevOpsの理想と現実のギャップ がある。
DevOpsの理想(2010年代)
- 「開発者がインフラも運用も全部やる!」
- "You build it, you run it"
現実
- 開発者に運用の負担が集中しすぎた
- Kubernetes、Terraform、監視ツール…学習コストが高すぎ
- 各チームが独自にツールを選んで、カオス化
- 結局「運用できる一部の人」に負荷が集中
→ 「開発者全員がインフラエキスパートになるのは無理だった」 という反省がある。
SREの役割が再定義されている
Platform Engineeringの登場で、SREの役割が変わってきている。
| SRE | Platform Engineering | |
|---|---|---|
| 主な目的 | サービスの信頼性を守る | 開発者の生産性を上げる |
| 誰のため? | エンドユーザー(顧客) | 内部の開発者 |
| 活動内容 | インシデント対応、SLO管理、 キャパシティプランニング |
セルフサービス基盤構築、 ツール標準化、DX改善 |
警察の比喩で言うと:
従来のSRE = パトカーで街を巡回、犯罪が起きたら駆けつける
Platform Engineering = 街灯を増やす、防犯カメラを設置する、住民が自分で防犯できる仕組みを作る
つまり、SREは「守る人」から「エンパワーする人」へ という変化が起きている。
それでも残る予算問題
でも、ここで気づいた。
アプローチを変えても「どこまで投資すれば十分か」問題からは逃れられない。
Platform Engineeringでも同じ壁にぶつかる。
防犯カメラの例で言うと:
- カメラ10台 → 「効果あるの?」
- カメラ100台 → 「そんなに必要?」
- カメラ1000台 → 「やりすぎでは?」
Platform Engineeringでも:
- CI/CDパイプライン構築 → 「工数かけすぎでは?」
- 開発者ポータル導入 → 「Backstageのライセンス費用いくら?」
- 全サービスに監視基盤 → 「小さいサービスにも必要?」
しかも、SREの障害対応は 「起きてしまった損失」が可視化される けど、Platform Engineeringは 「起きなかった機会損失」 を証明しないといけない。
- 「デプロイ時間が30分→5分になりました」 → 「で、売上は?」
- 「開発者の待ち時間が減りました」 → 「その分何作ったの?」
- 「開発者満足度が上がりました」 → 「それビジネス価値あるの?」
「生産性向上」は「障害による損失」より説明しづらい。
CTOやCEOが非エンジニアだと、さらに厳しい
CTOやCEOにエンジニア的なバックグラウンドがある場合は良い。話が通じる。
でもそうじゃないパターンはかなり厳しいと思うんだよね。
しかも全部を説明しようにも、その時間を割いてくれないと思うし、説明できたとしても理解が追いつかないかもしれない。
だからこそ、エンジニアのバックグラウンドがない人でも理解できるレベルでSREとかPlatform Engineeringの必要性を言語化しておきたい。
「まずはこれ読んでください」と言って、素養が出来上がるレベルのもの。
経営層向けガイドを書いた理由
そう思って、経営層向けのガイドを書いた。(記事の後半に全文掲載)
ポイントは:
- 非エンジニアでも理解できる言葉
- 警察・消防との比喩を活用
- 「見えない損失」を可視化する計算式
- 具体的な投資目安(エンジニア比率、売上比率)
- 10分で読める分量
正直、書きながら「これで伝わるのか?」と何度も迷った。
でも、少なくとも 「なぜSREやPlatform Engineeringに予算が必要なのか」という問いに対して、一つの答えを提示できた と思う。
振り返り: デジタルインフラは「コスト」ではなく「投資」
この対話を通じて、改めて思ったことがある。
SREやPlatform Engineeringへの投資は、火災保険と同じだ。
企業は火災保険に年間数百万円払う。「火事が起きないから無駄」とは言わない。
同じように:
- 期待損失: 年間3,000万円(障害リスク)
- 投資額: 年間500万円(SRE)
- 投資額 < 期待損失 なら、合理的
でも、多くの企業は 大規模障害を経験してから SREに投資する。
警察・消防は、大事件・大火災が起きる前から予算がある。それは 「社会インフラ」として認識されてるから。
SREも「デジタル社会インフラ」として認識されるべき。
そのためには:
- 経営層の啓蒙(CTO/CEOレベル)
- 業界全体での標準化(「SREに●%投資するのが常識」という空気)
- 規制や第三者認証(金融系のシステム監査みたいな)
正直、完璧な解はないと思う。
結局、「どこまで投資すれば十分か」に絶対解はなく、組織の価値観や優先順位の問題になる。
でも、少なくとも「考えるための材料」は提供できたんじゃないかと思う。
SREやPlatform Engineeringについて体系的に学びたい方には、以下の書籍がおすすめです。
[📦 商品リンク: moshimo-book-sre-google]
[📦 商品リンク: moshimo-book-monitoring-intro]
次の問い
この記事を読んで、あなたはどう思いますか?
- あなたの組織では、SREやPlatform Engineeringにどれくらい投資していますか?
- 経営層は、デジタルインフラの価値を理解していますか?
- 「見えない損失」を可視化するために、何ができますか?
もしこの記事が、あなたの組織での対話のきっかけになったら嬉しい。
付録: SRE・Platform Engineering 入門ガイド(経営層向け)
記事内で言及した経営層向けガイドは、マークダウンファイルとしてダウンロードできます。非エンジニアの方でも読めるよう、できるだけ平易な言葉で書きました。社内共有や経営会議の資料としてご活用ください。