事業価値を⽣み出すSREへ SREが担うべき意思決定の5層 2026/07/10 SRE NEXT 2026 @kenta_hi 

Kenta Hishida @kenta_hi Topotal, Inc. COO/CFO - Topotalではエンジニアリング以外をしてます - SRE NEXTでコミュニティ活動をしています - 「もう⼀度読むSRE」で話す && 編集‧配信し てます 2 

3 ⼀つの企業にフォーカスし、現場で⽣じる開発‧運 ⽤の課題をダイレクトに改善するSREのプラクティ スを軸としたエンジニアリングサービス SRE のワークフローを SaaS として実装し、より多 くの企業の課題を改善する - インシデントマネジメ ントSaaS 

AIが作業を担うようになってきた。 仕事は、なくなるのだろうか。 4 

"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 奪われるのは作業 事業価値の出し⽅は残る その「事業価値」を、 経営層は何で判断してるのか？ 

Topotalでの失敗例 運⽤⽀援は理解された。しかし、監視の提案は 通らなかった。 - ある⽀援先で、経営の要請（デプロイフロー整備‧コスト削減）は 進められた - だが、コストのかかる運⽤改善に必要な監視基盤の提案は、経営層 の理解を得られなかった - なぜ、経営層から理解が得られなかったのだろうか？ 7 

⼀⽅で、経営層に事業価値が 届いているケースもある SREの活動を経営層に 「事業価値として届ける」には 何をしたらよいのか？ 8 

そもそも 経営層は何を価値として 判断しているのか？ 9 

経営は「競争優位をつくること」を考えている 10 経営は、「競争優位をつくること」を考えている。事業成⻑もコスト削減も守り も、突き詰めれば市場で勝ち続けるため。 事業成⻑ コスト削減 採⽤‧組織作り リスク対策 etc… 競争優位 になるか 競争優位を獲得し 企業価値が⾼まる 

⾃社の状況と動かせる範囲で競争優位の仮説を作る 11 ⾃社の状況（事業のフェーズ‧システム障害の損失の⼤きさ）を分析し、動かせる 範囲（開発速度‧信頼性）に⽐重を置いて仮説を作る。  事業のフェーズ  システム障害の  損失の⼤きさ ⾃社の 状況 開発速度 信頼性 ⾃分たちの 動かせる範囲 事業価値 => 競争優位 

⾃社の状況を分析する 12 同じ事業でも、プロダクトのフェーズで、いま必要なことが変わる。では、SREは このフェーズに何を合わせるのか。 出典：Theodore Levitt「Exploit the Product Life Cycle」Harvard Business Review, 1965 

システム障害の損失も考慮する 13 同じフェーズでも、落ちたときに事業がどれだけ傷つくかで、信頼性の必 要性が変わる。 - システム障害の損失が⼤きい（決済‧⾦融‧医療など） → 導⼊期から、開発速度と信頼性のバランスが要る - 損失が⼩さい（コンテンツなど） → まず開発速度で、後から信頼性へ 出典：Nolan & McFarlan "Information Technology and the Board of Directors" HBR 2005 

⽐重は、事業フェーズと損失で診断できる 横軸に事業のフェーズ、縦軸に落ちた時の損失。速度と信頼性のどちらに ⽐重を置くかが、仮説の出発点。 14 参考：横軸＝プロダクトライフサイクル（Levitt, HBR 1965）∕縦軸＝信頼性要求度（Nolan & McFarlan, HBR 2005）。2軸の診断は本発表の整理。 ↑ シ ス テ ム 障 害 の 損 失 速度と信頼性のバランス 先に速度を重視し、 徐々に信頼性へ 信頼性を維持し コスト最適化へ 

特定の会社の話ではなく、よくある場⾯として。段階と損失で、⽐重の置きどころ は変わる。 開発速度に寄せる場⾯ 機能をすぐ出したいのに、リリースは ⼿動で⽉に1回。開発〜リリースの リードタイムが⻑く、競合に先を越さ れて成⻑機会を逃す。 → リードタイムを縮めて、リリース 頻度をあげて、機能を速く届け続ける たとえば、こんな場⾯に覚えはないですか 15 信頼性に寄せる場⾯ 簡易な基盤で⽴ち上げた。急成⻑ で、ログはすぐ消え、1台落ちると 全部⽌まる。 → 速度を保ったまま、成⻑に耐え る基盤を構築する 

経営視点では、ソフトウェアで何ができるか⾒えにくく、 事業の競争優位になるかも分からない。 ⾒えていないものは、必要と判断されない。 だから活動しても、事業価値として届かない。 経営層に知ってもらうために、対話が要る。 では、その内容をどうつくり、⾏動に移すのか？ 経営がSREを分かっていないと、必要と判断されない 16 

経営と対話するために 活動できる粒度(5層)に分解する 17 

活動できる粒度をWhy,What,How,Result,Whenの5つで整理する。 活動できるまでの5層に分解する 18 参考：⽬標管理（Drucker）‧⽬標設定理論（Locke 1968） Why What How When 競争優位 目指す状態 速度と信頼性の比重 状態の到達期日 Result 状態を表す結果 ⽬指す状態を経営と の共通⾔語に。 状態を表す結果は⾃ 分たちが動かせるも のにする。 

「速度と信頼性の⽐重」はSREの⾔葉。そのままでは経営に伝わらな い。事業の⾔葉＝⽬指す状態に翻訳し、経営と合意する。 経営の⾔葉に翻訳し、⽬指す状態を合意する 19 速度と信頼性の比重 開発速度 > 信頼性 目指す状態 機能を市場に早く届け 事業成長を加速させる 例：機能をすぐ出したいのに、リリースは⼿動で⽉に1回。開発〜リリースのリードタイムが ⻑く、競合に先を越されて成⻑機会を逃す。 → ⽬指す状態を「機能を市場に早く届け事業成⻑を加速させる」に翻訳し経営と合意する。 

合意した状態を経営の⾔葉だけではなく、⾃分の⼿で動かせるものに表現しなお す。さらに計測可能な数値に繋げる。 Resultは、⾃分が主体になるものに変換する 20 合意した状態 機能を市場に早く届け 事業成長を加速させる 経営の言葉： 機能を届け る速度をあげる 技術の言葉：リリース頻 度をあげる デプロイ頻度を 計測期間あたり n回に増やす 

⾃分の貢献を⽰すには、直接価値も間接価値も、⾃分が制御できる業務 の範囲で表す。担当分を指標で⽰せば、価値は伝わる。 直接価値(⾃分の業務範囲で完結する) - 成果：インフラのコストを下げる - ⽰し⽅：指標をそのまま数値で⾔ い切る - 例：インフラ費をn%削減 ⾃分が動かせる指標で貢献を⽰す 21 出典：Balanced Scorecard（Kaplan & Norton, HBR 1992）∕Porter バリューチェーン（1985） 間接価値(複数の機能を経由する) - 成果：リリース頻度を上げ、機能を 市場に届ける - ⽰し⽅：⾃分が動かせる指標で⽰す - 例：デプロイの所要時間を短く する 

ここまでやっても 思い通りの成果が出ないこともある 22 

仮説は外れるので、何度も仮説検証を繰り返す - 事業の変化が早く、仮説が外れる - 成果が、数値に表れるまで時間がかかる 仮説が外れることは失敗ではない。 外した仮説を前提に、進化した仮説検証を積み重ねる。 その積み重ねが、価値を届ける。 23 

すぐに成果に繋がらなくても 仮説検証を繰り返し 価値を届けようとする⼈を 経営する⽴場からすると 頼りたい 24 

作業はAIに渡しても 価値を届ようとする姿勢は 奪われない。 それが、会社にとって 必要不可⽋な存在です 25 

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"