一覧に戻る
    なぜSREへの投資は軽視されがちなのか――警察・消防との比喩から考える、デジタルインフラの価値
    SRE
    PRこの記事には広告が含まれています

    なぜSREへの投資は軽視されがちなのか――警察・消防との比喩から考える、デジタルインフラの価値

    13 分で読める

    「ものづくり」をしたいのに、トラブルシューティングばかり

    ある日、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の役割が変わってきている。

    SREPlatform 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について体系的に学びたい方には、以下の書籍がおすすめです。


    次の問い

    この記事を読んで、あなたはどう思いますか?

    • あなたの組織では、SREやPlatform Engineeringにどれくらい投資していますか?
    • 経営層は、デジタルインフラの価値を理解していますか?
    • 「見えない損失」を可視化するために、何ができますか?

    もしこの記事が、あなたの組織での対話のきっかけになったら嬉しい。


    付録: SRE・Platform Engineering 入門ガイド(経営層向け)

    記事内で言及した経営層向けガイドは、マークダウンファイルとしてダウンロードできます。非エンジニアの方でも読めるよう、できるだけ平易な言葉で書きました。社内共有や経営会議の資料としてご活用ください。

    この記事は役に立ちましたか?

    Coffee cup

    この記事が、何かの整理につながったら

    コーヒー1杯分の応援をもらえると嬉しいです。

    ※ これは応援とは別の話ですが、

    同じようなテーマを自分の文脈で整理したい場合は、 (文章だけだと詰まりやすい人向けに) 思考整理の壁打ちという形で対話の時間も取っています。

    対話の時間について