CSに"SLO"は要らない、経営層に"99.9%"は伝わらない - SREを全社に"翻訳"する3原則

Embed

Start on current slide

Slide 1

Slide 1 text

CSに"SLO"は要らない、経営層に"99.9%"は伝わらない - SREを全社に"翻訳"する3原則株式会社サイバーセキュリティクラウド VP of Engineering Operations 川崎雄太 2026/07/10 - 11 SRE NEXT 2026

Slide 2

Slide 2 text

2 ⾃⼰紹介川崎雄太　Yuta Kawasaki @yuta_k0911 株式会社サイバーセキュリティクラウドセキュリティインテリジェンス本部本部長 VP of Engineering Operations 2026年7月入社。 EM of EMs、DevHR、DevRelを管掌。 AWS Community Builder（Security） SRE NEXT登壇：2023、2025、2026 SRE NEXTスタッフ：2024 〜

Slide 3

Slide 3 text

株式会社サイバーセキュリティクラウドについて 3 ©Cyber Security Cloud, Inc. 社名株式会社サイバーセキュリティクラウド設⽴ 2010年8⽉11⽇代表者代表取締役社⻑兼 CEO ⼩池敏弘代表取締役CTO 渡辺洋司所在地東京都品川区上⼤崎3-1-1 JR東急⽬黒ビル13階事業内容サイバーセキュリティサービスの開発‧提供グループ会社 Cyber Security Cloud Inc. （USA） Cyber Security Cloud Pte. Ltd. （Singapore）株式会社ジェネレーティブテクノロジー株式会社DataSign 売上高（百万円）クラウド型WAF提供開始 WAF⾃動運⽤サービス提供開始フルマネージドセキュリティサービス提供開始 US⼦会社設⽴ CSC Managed Rules for AWS WAF ‧ジェネレーティブテクノロジー設⽴ ‧シンガポール⼦会社設⽴ DataSign⼦会社化脆弱性診断サービス ‧新規上場 ‧ソフテック⼦会社化 2013 ‧‧‧ Mission 世界中の⼈々が安⼼安全に使えるサイバー空間を創造する 2024 2025 2023 2020 2018 2019 2017 2013 脆弱性情報管理‧収集

Slide 4

Slide 4 text

4 ©Cyber Security Cloud, Inc. 株式会社サイバーセキュリティクラウドについてプロダクトラインナップ脆弱性診断サービス Webサイト‧サーバへのサイバー攻撃を検知‧遮断するサービス 3⼤クラウドプラットフォームのフルマネージドセキュリティサービスパブリッククラウドのWAF⾃動運⽤サービス OSやアプリケーションの脆弱性情報を収集し提供するサービス世界各国の規制に対応した個⼈情報同意管理ツール Webアプリケーション等に関する脆弱性診断サービスセキュアなシステム開発環境の構築サービス WAF自動運用サービスクラウド型 WAF クラウド構築・開発フルマネージドセキュリティ脆弱性管理・診断個人情報同意管理ツール防御管理構築運用運用管理 CSC Managed Rules for AWS WAF AWS WAF専⽤のルールセット

Slide 5

Slide 5 text

5 ⚠前提のご案内 ⚠ このセッションで話す内容は前職（ココナラ）での実績となります。その前提でお聞きいただけると幸いです。

Slide 6

Slide 6 text

6 ⚠はじめに⚠ このセッションで話すこと🙆 ● Inclusive SREをEMが実践するなかで試行錯誤したことや学び（失敗もあるよ）このセッションで話さないこと🙅 ● SREのテクニカルな内容 ● PMBOKのように体系立てて実践した話

Slide 7

Slide 7 text

Contents 問題提起壁①：専⾨⽤語の壁 ── CSをIncludeする壁②：温度差の壁 ── 経営層をIncludeする壁③：完璧主義の壁 ── 全員に同じ理解を求めた失敗まとめ：Inclusive SREの3原則 01. 02. 03. 04. 05. 7

Slide 8

Slide 8 text

問題提起 01.

Slide 9

Slide 9 text

9 01. 問題提起 Q. ちょっと聞いてもいいですか？この会場で「SREの数値目標（ KPI）や成果などを経営層やビジネス部門に説明したことがある」方はいますか？そのうち「ちゃんと伝わった」と感じた方は？今日は"伝わらない "を解消する話をします。

Slide 10

Slide 10 text

10 01. 問題提起 SRE：いまxxx機能で障害が発生しています。影響は〜（説明中） CS：（影響わからないけど）急いでユーザーに障害報告します。 SRE：あっ…（最後まで話を聞いて正しくユーザーに伝えないと…）報告速度は大事だが、影響範囲 / 回避策の有無が正しく伝わらず、ユーザーが混乱する…😭 再現ドラマ風シーン①

Slide 11

Slide 11 text

11 01. 問題提起 SRE：今月は運用改善により、SLO目標（99.9%）を達成しました。経営層：ほぼ100%だからシステムは全く問題ないよね？ SRE：…えっ（完璧なシステムなんて存在しないけども…） SLO目標を達成するための改善活動が経営層に正しく伝わらず、評価されない…😭 再現ドラマ風シーン②

Slide 12

Slide 12 text

12 01. 問題提起

Slide 13

Slide 13 text

13 01. 問題提起 SRE NEXT 2025の登壇内容サマリと問い ✅ SLO・エラーバジェット運用が定着 ✅ 経営層との共通言語化を実践 ✅「経営層への翻訳」で手応えを得た業務の中で次の問いが浮かんだ ● エンジニア以外のロールに SREは届けられるか？ ● 「SREを届けること」に価値はあるのか？

Slide 14

Slide 14 text

14 01. 問題提起しかし、エンジニア以外には届かない ❌ CSは「SLO」の意味を知らないままユーザー対応 ❌ 経営層は「SLO 99.9%」を「ほぼ100%」と解釈 ❌「SREはエンジニアだけのもの」が暗黙の前提 → この前提が組織の壁を作っている

Slide 15

Slide 15 text

15 01. 問題提起今日乗り越える 3つの壁壁① 専門用語の壁 CSに「SLO」と言っても通じない壁② 温度差の壁「99.9%」が「問題なし」と解釈される壁③ 完璧主義の壁全員に同じ理解を求めた失敗

Slide 16

Slide 16 text

壁①：専⾨⽤語の壁 ── CSをIncludeする 02.

Slide 17

Slide 17 text

17 02. 壁① 専門用語の壁よくあるパターン「SLO 99.9%を下回った場合、エラーバジェットが消費されます」 → CS：「何を言っているのかわからない」 CSが知りたいのは1つだけ「今、ユーザーに何が起きているか」

Slide 18

Slide 18 text

18 02. 壁① 専門用語の壁なぜ言葉が通じないのかエンジニアとCSでは「知りたいこと」が違う ● エンジニア：「SLO・エラーバジェット・MTTR…」 ● CS ：「今使える？影響は？いつ直る？」相手の仕事に必要な情報に変換できていなかった

Slide 19

Slide 19 text

19 02. 壁① 専門用語の壁

Slide 20

Slide 20 text

20 02. 壁① 専門用語の壁翻訳レイヤーの設計 3ステップ ① CS専用ステータス報告（3段階のみ）　 ✅ 正常 / ⚠ 一部遅延 / ❌ 障害中 ② インシデント通知テンプレート（3点のみ）　「何が起きているか」「影響」「復旧見込み」 ③ CS → エンジニアへのフィードバックルート整備　ユーザーの声をSLO改善に活用

Slide 21

Slide 21 text

21 02. 壁① 専門用語の壁 ① CS専用ステータス報告機能状態 ───────────────────────────────── 決済 ✅ 正常マイページ ⚠ 一部遅延（遅延幅は最大5秒）メッセージ ❌ 障害中（復旧見込み30分） SLOの数値は一切見せないユーザー影響だけを記載する

Slide 22

Slide 22 text

22 02. 壁① 専門用語の壁

Slide 23

Slide 23 text

23 02. 壁① 専門用語の壁 ② インシデント通知テンプレート 📋 何が起きているか決済機能が断続的に失敗している 📊 ユーザーへの影響一部ユーザーで決済が完了できない、ユーザー数はxxx名 🔧 復旧見込み 30分以内に復旧予定 ※全体的に技術的な原因は書かない

Slide 24

Slide 24 text

24 02. 壁① 専門用語の壁 ③ CSフィードバックルートの整備 CSが気づく「体験劣化」はSLOに現れる前に発生する「こういう問い合わせが増えています」 → SLO対象の見直しに直結実績：CSのフィードバックでSLO対象を1つ追加（それまで検知できていなかった劣化を発見）

Slide 25

Slide 25 text

25 02. 壁① 専門用語の壁

Slide 26

Slide 26 text

26 02. 壁① 専門用語の壁壁①を越えた成果（実績値） ⬇ 30% CS初期回答時間の短縮障害時の平均30分から ⬆ 10% ユーザー満足度向上 🆕 +1 SLO対象を追加 CSフィードバックによる発見

Slide 27

Slide 27 text

27 02. 壁① 専門用語の壁 Q. 今のCSチームに聞いてみてくださいあなたのチームのCSは... 「今、サービスに障害が起きているか」 SREに聞かなくても自分で判断できますか？ → 「SREに確認しないとわからない」なら　まだ壁①が残っています

Slide 28

Slide 28 text

壁②：温度差の壁 ── 経営層をIncludeする 03.

Slide 29

Slide 29 text

29 03. 壁② 温度差の壁よくあるパターン月次経営会議での報告「今月のSLO達成率は99.95% エラーバジェット残は60%です」 → 経営層:「99.95%？ほぼ100%じゃないか。　　　　問題ないよね」

Slide 30

Slide 30 text

30 03. 壁② 温度差の壁なぜ温度差が生まれるのかエンジニア：「99.9%と99.99%は全然違う！」経営層：「どちらもほぼ100%でしょ？」「危機感」と「安心感」のギャップ → 投資判断の遅れに直結する数値ではなく、「影響」で伝える必要がある

Slide 31

Slide 31 text

31 03. 壁② 温度差の壁ビジネスインパクトへの変換 SLO → 月間ダウンタイム → 売上損失「99.9%達成」ではなく「この月は43分サービス停止があった」と言うエラーバジェット残60% →あと○件の障害まで猶予あり数値の羅列から「経営判断の材料」へ

Slide 32

Slide 32 text

32 03. 壁② 温度差の壁

Slide 33

Slide 33 text

33 03. 壁② 温度差の壁

Slide 34

Slide 34 text

34 03. 壁② 温度差の壁四半期「信頼性レポート」の設計 📊 障害による売上影響の累計 📈 信頼性投資のROI 投資額 vs 障害による損失削減額 ⚡ エラーバジェット残高「あと何件の障害が許容できるか」 → 経営層が「自分ごと」で判断できる形に

Slide 35

Slide 35 text

35 03. 壁② 温度差の壁経営層の反応が変わった Before ：「報告を受け取るだけ」 After ：「信頼性は大丈夫？」が月2-3回 → 信頼性が経営課題として認識された投資判断のスピードが変わった

Slide 36

Slide 36 text

36 03. 壁② 温度差の壁壁②を越えた成果（実績値） ⬇ 60%信頼性投資の承認速度改善平均2ヶ月から 📈 月2-3回経営層からの能動的な確認月0回から ✅ 技術的負債解消の予算確保に成功

Slide 37

Slide 37 text

37 03. 壁② 温度差の壁 Q. 経営会議で ... 「SLO」や「信頼性」という言葉が経営層の口から自然に出てきますか？経営層がSREを「自分ごと」として話し始めたら → その組織は「壁②」を越えています

Slide 38

Slide 38 text

壁③：完璧主義の壁 ── 全員に同じ理解を求めた失敗 04.

Slide 39

Slide 39 text

39 04. 壁③ 完璧主義の壁全員に同じ理解を求めた失敗ステークホルダー向けSREスキルトランスファーを実施 ✅ 参加率は高かった ⚠ 理解度はなかなか上がらない ❌ 一定期間後「結局SRE固有の話でしょ？」

Slide 40

Slide 40 text

40 04. 壁③ 完璧主義の壁なぜ失敗したのか CSに「5 Whys」は必要ない経営層に「MTTRの計算式」は必要ない役割に合わない理解を押し付けていた「Inclusive = 全員が同じことを知る」ではなかった

Slide 41

Slide 41 text

41 04. 壁③ 完璧主義の壁 Inclusiveを再定義する Before ：「全員が同じことを知る」 After ：「全員が自分の役割で SREを実践する」 100%の理解 = オーバーエンジニアリング役割に応じた理解 = ちょうどいい関わり方

Slide 42

Slide 42 text

42 04. 壁③ 完璧主義の壁役割ごとの Include設計役割必要な理解 SREの実践例 ────────────────────────────────────── SRE SLO/エラーバジェット設計・運用 PM リリース判断用の数値データ意思決定 CS ユーザー影響状態対応・フィードバック経営層売上影響とROI 投資判断法務通知基準法的通知判断

Slide 43

Slide 43 text

43 04. 壁③ 完璧主義の壁

Slide 44

Slide 44 text

44 04. 壁③ 完璧主義の壁実例①：CSのフィードバックが SLO改善に直結 CSからのフィードバック：「検索画面の表示が遅いという問い合わせが増えています」 → 従来SLOにはなかった指標を発見 →「検索画面の表示速度」をSLO化 CSが「SREの一員」として機能した瞬間

Slide 45

Slide 45 text

45 04. 壁③ 完璧主義の壁実例②：経営層の投資が信頼性向上に信頼性レポートを見た経営層: 「この3ヶ月で数百万円規模の損失が出ている技術的負債を解消しよう」 → 予算承認 → インフラ改善 → 障害減少経営層が「SREのスポンサー」になった

Slide 46

Slide 46 text

46 04. 壁③ 完璧主義の壁壁③を越えた成果（実績値） ⭐ 大幅改善 SREに関わっている実感 ⬇ 75%改善インシデント初動から全部門連携まで以前は20分から5分に短縮 🔄 共通認識「信頼性を高めるための活動はエンジニアだけの仕事じゃない」

Slide 47

Slide 47 text

47 04. 壁③ 完璧主義の壁 Q. あなたのチームには ... ビジネス職で「信頼性を自分ごと」として話している人がいますか？ CSが「あの問い合わせ、信頼性に関係しそう」と言い経営層が「信頼性の予算、足りてる？」と聞く → それが「壁③」を越えた証拠です

Slide 48

Slide 48 text

まとめ：Inclusive SREの3原則 05.

Slide 49

Slide 49 text

49 05. まとめ Inclusive SRE 3原則 ■ 原則1：翻訳する　SLO・エラーバジェットを経営・ビジネス言語に変換する ■ 原則2：役割を渡す　SREがボトルネックにならないよう、オーナーシップを　分散する ■ 原則3：完璧を求めない　「100%達成」より「今週は改善した」を重視する　理解度は役割に応じたレベルにチューニングする

Slide 50

Slide 50 text

50 05. まとめ

Slide 51

Slide 51 text

51 05. まとめ原則1：翻訳する SREの言葉を、相手の言語に翻訳する ● 「エラーバジェット残30%」→「残り○時間の障害余力」 ● 「SLO 99.9%」→「月間43分の許容ダウンタイム」 ● 「P50レイテンシ200ms」→「2人に1人が0.2秒待っている」翻訳なき指標は、ただの数字。相手の意思決定に繋がる言葉を選ぶことがSREの仕事。

Slide 52

Slide 52 text

52 05. まとめ原則2：役割を渡す SREがすべてを抱え込まない組織設計 ● SLO定義はプロダクトオーナーと共同で ● 障害対応のRunbookは開発チームが書く ● ダッシュボードの読み方は全員が知っている SREの役割は「やる人」から「教える人・設計する人」へ。オーナーシップを渡すことで、組織全体のレジリエンスが高まる。

Slide 53

Slide 53 text

53 05. まとめ原則3：完璧を求めない「今週より来週が良ければ良い」という文化「全員が同じ深さで理解する必要はない」 ● 役割に合った理解が「ちょうどいい関わり方」 ● CSは「ユーザー影響」を、経営層は「ROI」を知れば十分 ● SREがすべてを教え込もうとすることが完璧主義完璧なInclusiveより、継続できるInclusiveを。

Slide 54

Slide 54 text

54 05. まとめ Include Everyone, in Their Own Way. SREは、特定のチームのものではない。 ● エンジニアには技術的な深さで ● PMには数字と影響で ● 経営層にはリスクと機会で同じ信頼性の話を、相手に合わせた「言語」で届ける。それが「全社SRE」の姿。

Slide 55

Slide 55 text

55 05. まとめ Include Everyone, in Their Own Way. お話した内容で、少しでも「これは良いな …！」と思えたものがあったら、来週試してみてください。変わる組織は1人が1つ動くところから始まります。あなたの組織で、次に壁を一緒に越えたい相手は誰ですか？まずは1人のエンジニア以外の職種の方にぜひ声をかけてみてください！

Slide 56

Slide 56 text

ﬁn