事業価値を⽣み出すSREへ SREが担うべき意思決定の5層

事業価値を生み出すSREへ ー SREが担うべき意思決定の5層
AIがコードを書き、トイルを解消していく。ソフトウェアエンジニアとしてのSREの仕事はなくなるのか。そう感じている人は多いはずです。しかし、実際のデータはもっと厄介なことを示しています。SRE Report 2026では51%がトイル削減を実感できておらず、Faros AIの実測ではAI高採用チームのPR数が倍増する一方、業績との相関は見られません。つまり、AIのアウトプットは会社の価値に直結していないと言えます。なぜそうなるのか、どうAIを扱っていくべきなのか——それがSREのキャリアの問いでもあります。このセッションは、その問いを抱えているSREとそのリーダーに向けています。
私はSRE組織を支援する会社の経営に携わり、多くの商談で顧客の課題を聞き続けてきました。その中で気づいたことが、SREへの投資が続くケースと続かないケースの違いです。

その違いは、経営の要求を言語化し、自分たちの活動と接続できているかどうかです。AIが実行コストを下げるほど、技術的な活動量による価値証明は通じにくくなります。この変化は現場からは見えにくく、経営側と直接向き合う立場から見えてきたことでもあります。

その変化に対応するための5層の意思決定フレームワークを紹介します。経営目標を理解し、達成指標を設定し、施策を判断・決定し、AIの実行を監視・承認し、経営にコミットし続ける。技術指標は実行の証明に過ぎず、達成指標があって初めて経営言語に翻訳できます。各層について、支援現場から見えてきた実践の一端も共有します。

Transcript

1. 事業価値を⽣み出すSREへ SREが担うべき意思決定の5層 2026/07/10 SRE NEXT 2026 @kenta_hi
2. Kenta Hishida @kenta_hi Topotal, Inc. COO/CFO - Topotalではエンジニアリング以外をしてます - SRE NEXTでコミュニティ活動をしています - 「もう⼀度読むSRE」で話す && 編集‧配信し てます 2
3. 3 ⼀つの企業にフォーカスし、現場で⽣じる開発‧運 ⽤の課題をダイレクトに改善するSREのプラクティ スを軸としたエンジニアリングサービス SRE のワークフローを SaaS として実装し、より多 くの企業の課題を改善する - インシデントマネジメ ントSaaS
4. AIが作業を担うようになってきた。 仕事は、なくなるのだろうか。 4
5. "Any correlation between AI adoption and key performance metrics evaporates at the company level." AI活⽤と業績指標の相関は、全社で⾒ると消える 5 出典：Faros AI「The AI Productivity Paradox（AI Engineering Report 2025）」
6. 6 奪われるのは作業 事業価値の出し⽅は残る その「事業価値」を、 経営層は何で判断してるのか？
7. Topotalでの失敗例 運⽤⽀援は理解された。しかし、監視の提案は 通らなかった。 - ある⽀援先で、経営の要請（デプロイフロー整備‧コスト削減）は 進められた - だが、コストのかかる運⽤改善に必要な監視基盤の提案は、経営層 の理解を得られなかった - なぜ、経営層から理解が得られなかったのだろうか？ 7
8. ⼀⽅で、経営層に事業価値が 届いているケースもある SREの活動を経営層に 「事業価値として届ける」には 何をしたらよいのか？ 8
9. そもそも 経営層は何を価値として 判断しているのか？ 9
10. 経営は「競争優位をつくること」を考えている 10 経営は、「競争優位をつくること」を考えている。事業成⻑もコスト削減も守り も、突き詰めれば市場で勝ち続けるため。 事業成⻑ コスト削減 採⽤‧組織作り リスク対策 etc… 競争優位 になるか 競争優位を獲得し 企業価値が⾼まる
11. ⾃社の状況と動かせる範囲で競争優位の仮説を作る 11 ⾃社の状況（事業のフェーズ‧システム障害の損失の⼤きさ）を分析し、動かせる 範囲（開発速度‧信頼性）に⽐重を置いて仮説を作る。  事業のフェーズ  システム障害の  損失の⼤きさ ⾃社の 状況 開発速度 信頼性 ⾃分たちの 動かせる範囲 事業価値 => 競争優位
12. ⾃社の状況を分析する 12 同じ事業でも、プロダクトのフェーズで、いま必要なことが変わる。では、SREは このフェーズに何を合わせるのか。 出典：Theodore Levitt「Exploit the Product Life Cycle」Harvard Business Review, 1965
13. システム障害の損失も考慮する 13 同じフェーズでも、落ちたときに事業がどれだけ傷つくかで、信頼性の必 要性が変わる。 - システム障害の損失が⼤きい（決済‧⾦融‧医療など） → 導⼊期から、開発速度と信頼性のバランスが要る - 損失が⼩さい（コンテンツなど） → まず開発速度で、後から信頼性へ 出典：Nolan & McFarlan "Information Technology and the Board of Directors" HBR 2005
14. ⽐重は、事業フェーズと損失で診断できる 横軸に事業のフェーズ、縦軸に落ちた時の損失。速度と信頼性のどちらに ⽐重を置くかが、仮説の出発点。 14 参考：横軸＝プロダクトライフサイクル（Levitt, HBR 1965）∕縦軸＝信頼性要求度（Nolan & McFarlan, HBR 2005）。2軸の診断は本発表の整理。 ↑ シ ス テ ム 障 害 の 損 失 速度と信頼性のバランス 先に速度を重視し、 徐々に信頼性へ 信頼性を維持し コスト最適化へ
15. 特定の会社の話ではなく、よくある場⾯として。段階と損失で、⽐重の置きどころ は変わる。 開発速度に寄せる場⾯ 機能をすぐ出したいのに、リリースは ⼿動で⽉に1回。開発〜リリースの リードタイムが⻑く、競合に先を越さ れて成⻑機会を逃す。 → リードタイムを縮めて、リリース 頻度をあげて、機能を速く届け続ける たとえば、こんな場⾯に覚えはないですか 15 信頼性に寄せる場⾯ 簡易な基盤で⽴ち上げた。急成⻑ で、ログはすぐ消え、1台落ちると 全部⽌まる。 → 速度を保ったまま、成⻑に耐え る基盤を構築する
16. 経営視点では、ソフトウェアで何ができるか⾒えにくく、 事業の競争優位になるかも分からない。 ⾒えていないものは、必要と判断されない。 だから活動しても、事業価値として届かない。 経営層に知ってもらうために、対話が要る。 では、その内容をどうつくり、⾏動に移すのか？ 経営がSREを分かっていないと、必要と判断されない 16
17. 経営と対話するために 活動できる粒度(5層)に分解する 17
18. 活動できる粒度をWhy,What,How,Result,Whenの5つで整理する。 活動できるまでの5層に分解する 18 参考：⽬標管理（Drucker）‧⽬標設定理論（Locke 1968） Why What How When 競争優位 目指す状態 速度と信頼性の比重 状態の到達期日 Result 状態を表す結果 ⽬指す状態を経営と の共通⾔語に。 状態を表す結果は⾃ 分たちが動かせるも のにする。
19. 「速度と信頼性の⽐重」はSREの⾔葉。そのままでは経営に伝わらな い。事業の⾔葉＝⽬指す状態に翻訳し、経営と合意する。 経営の⾔葉に翻訳し、⽬指す状態を合意する 19 速度と信頼性の比重 開発速度 > 信頼性 目指す状態 機能を市場に早く届け 事業成長を加速させる 例：機能をすぐ出したいのに、リリースは⼿動で⽉に1回。開発〜リリースのリードタイムが ⻑く、競合に先を越されて成⻑機会を逃す。 → ⽬指す状態を「機能を市場に早く届け事業成⻑を加速させる」に翻訳し経営と合意する。
20. 合意した状態を経営の⾔葉だけではなく、⾃分の⼿で動かせるものに表現しなお す。さらに計測可能な数値に繋げる。 Resultは、⾃分が主体になるものに変換する 20 合意した状態 機能を市場に早く届け 事業成長を加速させる 経営の言葉： 機能を届け る速度をあげる 技術の言葉：リリース頻 度をあげる デプロイ頻度を 計測期間あたり n回に増やす
21. ⾃分の貢献を⽰すには、直接価値も間接価値も、⾃分が制御できる業務 の範囲で表す。担当分を指標で⽰せば、価値は伝わる。 直接価値(⾃分の業務範囲で完結する) - 成果：インフラのコストを下げる - ⽰し⽅：指標をそのまま数値で⾔ い切る - 例：インフラ費をn%削減 ⾃分が動かせる指標で貢献を⽰す 21 出典：Balanced Scorecard（Kaplan & Norton, HBR 1992）∕Porter バリューチェーン（1985） 間接価値(複数の機能を経由する) - 成果：リリース頻度を上げ、機能を 市場に届ける - ⽰し⽅：⾃分が動かせる指標で⽰す - 例：デプロイの所要時間を短く する
22. ここまでやっても 思い通りの成果が出ないこともある 22
23. 仮説は外れるので、何度も仮説検証を繰り返す - 事業の変化が早く、仮説が外れる - 成果が、数値に表れるまで時間がかかる 仮説が外れることは失敗ではない。 外した仮説を前提に、進化した仮説検証を積み重ねる。 その積み重ねが、価値を届ける。 23
24. すぐに成果に繋がらなくても 仮説検証を繰り返し 価値を届けようとする⼈を 経営する⽴場からすると 頼りたい 24
25. 作業はAIに渡しても 価値を届ようとする姿勢は 奪われない。 それが、会社にとって 必要不可⽋な存在です 25
26. 26 参考資料 経営‧戦略 - Theodore Levitt "Exploit the Product Life Cycle" HBR 1965 - Nolan & McFarlan "Information Technology and the Board of Directors" HBR 2005 - Kaplan & Norton "The Balanced Scorecard" HBR 1992 - Michael Porter『Competitive Advantage』1985 技術‧SRE - Google『SRE Book』"Embracing Risk" - DORA "State of DevOps Report 2025" - Faros AI "The AI Productivity Paradox"