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

SRE NEXT 2026の登壇資料。
https://sre-next.dev/2026/schedule/#slot111

Transcript

1. CSに"SLO"は要らない、経営層 に"99.9%"は伝わらない - SREを全社に"翻訳"する3原則 株式会社サイバーセキュリティクラウド VP of Engineering Operations 川崎 雄太 2026/07/10 - 11 SRE NEXT 2026
2. 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 〜
3. 株式会社サイバーセキュリティクラウドについて 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 脆弱性情報管理‧収集
4. 4 ©Cyber Security Cloud, Inc. 株式会社サイバーセキュリティクラウドについて プロダクトラインナップ 脆弱性診断サービス Webサイト‧サーバへのサイバー 攻撃を検知‧遮断するサービス 3⼤クラウドプラットフォームのフルマネージド セキュリティサービス パブリッククラウドのWAF⾃動運⽤サービス OSやアプリケーションの脆弱性情報 を収集し提供するサービス 世界各国の規制に対応した 個⼈情報同意管理ツール Webアプリケーション等に関する 脆弱性診断サービス セキュアなシステム開発環境の構築サービス WAF自動運用サービス クラウド型 WAF クラウド構築・開発 フルマネージドセキュリティ 脆弱性管理・診断 個人情報同意管理ツール 防御 管理 構築 運用 運用 管理 CSC Managed Rules for AWS WAF AWS WAF専⽤のルールセット
5. 5 ⚠前提のご案内 ⚠ このセッションで話す内容は前職（ココナラ）での実 績となります。 その前提でお聞きいただけると幸いです。
6. 6 ⚠はじめに⚠ このセッションで話すこと🙆 • Inclusive SREをEMが実践するなかで 試行錯誤したことや学び（失敗もあるよ） このセッションで話さないこと🙅 • SREのテクニカルな内容 • PMBOKのように体系立てて実践した話
7. Contents 問題提起 壁①：専⾨⽤語の壁 ── CSをIncludeする 壁②：温度差の壁 ── 経営層をIncludeする 壁③：完璧主義の壁 ── 全員に同じ理解を求めた失敗 まとめ：Inclusive SREの3原則 01. 02. 03. 04. 05. 7
8. 問題提起 01.
9. 9 01. 問題提起 Q. ちょっと聞いてもいいですか？ この会場で 「SREの数値目標（ KPI）や成果などを経営層やビジネス 部門に説明したことがある」 方はいますか？ そのうち「ちゃんと伝わった」 と感じた方は？ 今日は"伝わらない "を解消する話をします。
10. 10 01. 問題提起 SRE：いまxxx機能で障害が発生しています。影響は〜（説明中） CS：（影響わからないけど）急いでユーザーに障害報告します。 SRE：あっ…（最後まで話を聞いて正しくユーザーに伝えないと…） 報告速度は大事だが、影響範囲 / 回避策の有無 が正しく伝わらず、ユーザーが混乱する…😭 再現ドラマ風シーン①
11. 11 01. 問題提起 SRE：今月は運用改善により、SLO目標（99.9%）を達成しました。 経営層：ほぼ100%だからシステムは全く問題ないよね？ SRE：…えっ（完璧なシステムなんて存在しないけども…） SLO目標を達成するための改善活動が 経営層に正しく伝わらず、評価されない…😭 再現ドラマ風シーン②
12. 12 01. 問題提起
13. 13 01. 問題提起 SRE NEXT 2025の登壇内容サマリと問い ✅ SLO・エラーバジェット運用が定着 ✅ 経営層との共通言語化を実践 ✅「経営層への翻訳」で手応えを得た 業務の中で次の問いが浮かんだ • エンジニア以外のロールに SREは届けられるか？ • 「SREを届けること」に価値はあるのか？
14. 14 01. 問題提起 しかし、エンジニア以外には届かない ❌ CSは「SLO」の意味を知らないままユーザー対応 ❌ 経営層は「SLO 99.9%」を「ほぼ100%」と解釈 ❌「SREはエンジニアだけのもの」が暗黙の前提 → この前提が組織の壁を作っている
15. 15 01. 問題提起 今日乗り越える 3つの壁 壁① 専門用語の壁 CSに「SLO」と言っても通じない 壁② 温度差の壁 「99.9%」が「問題なし」と解釈される 壁③ 完璧主義の壁 全員に同じ理解を求めた失敗
16. 壁①：専⾨⽤語の壁 ── CSをIncludeする 02.
17. 17 02. 壁① 専門用語の壁 よくあるパターン 「SLO 99.9%を下回った場合、 エラーバジェットが消費されます」 → CS：「何を言っているのかわからない」 CSが知りたいのは1つだけ 「今、ユーザーに何が起きているか」
18. 18 02. 壁① 専門用語の壁 なぜ言葉が通じないのか エンジニアとCSでは「知りたいこと」が違う • エンジニア ：「SLO・エラーバジェット・MTTR…」 • CS ：「今使える？影響は？いつ直る？」 相手の仕事に必要な情報に変換できていなかった
19. 19 02. 壁① 専門用語の壁
20. 20 02. 壁① 専門用語の壁 翻訳レイヤーの設計 3ステップ ① CS専用ステータス報告（3段階のみ） 　 ✅ 正常 / ⚠ 一部遅延 / ❌ 障害中 ② インシデント通知テンプレート（3点のみ） 　「何が起きているか」「影響」「復旧見込み」 ③ CS → エンジニアへのフィードバックルート整備 　 ユーザーの声をSLO改善に活用
21. 21 02. 壁① 専門用語の壁 ① CS専用ステータス報告 機能 状態 ───────────────────────────────── 決済 ✅ 正常 マイページ ⚠ 一部遅延（遅延幅は最大5秒） メッセージ ❌ 障害中（復旧見込み30分） SLOの数値は一切見せない ユーザー影響だけを記載する
22. 22 02. 壁① 専門用語の壁
23. 23 02. 壁① 専門用語の壁 ② インシデント通知テンプレート 📋 何が起きているか 決済機能が断続的に失敗している 📊 ユーザーへの影響 一部ユーザーで決済が完了できない、ユーザー数はxxx名 🔧 復旧見込み 30分以内に復旧予定 ※全体的に技術的な原因は書かない
24. 24 02. 壁① 専門用語の壁 ③ CSフィードバックルートの整備 CSが気づく「体験劣化」はSLOに現れる前に発生する 「こういう問い合わせが増えています」 → SLO対象の見直しに直結 実績：CSのフィードバックでSLO対象を1つ追加 （それまで検知できていなかった劣化を発見）
25. 25 02. 壁① 専門用語の壁
26. 26 02. 壁① 専門用語の壁 壁①を越えた成果（実績値） ⬇ 30% CS初期回答時間の短縮 障害時の平均30分から ⬆ 10% ユーザー満足度向上 🆕 +1 SLO対象を追加 CSフィードバックによる発見
27. 27 02. 壁① 専門用語の壁 Q. 今のCSチームに聞いてみてください あなたのチームのCSは... 「今、サービスに障害が起きているか」 SREに聞かなくても自分で判断できますか？ → 「SREに確認しないとわからない」なら 　 まだ壁①が残っています
28. 壁②：温度差の壁 ── 経営層をIncludeする 03.
29. 29 03. 壁② 温度差の壁 よくあるパターン 月次経営会議での報告 「今月のSLO達成率は99.95% エラーバジェット残は60%です」 → 経営層:「99.95%？ほぼ100%じゃないか。 　　　　問題ないよね」
30. 30 03. 壁② 温度差の壁 なぜ温度差が生まれるのか エンジニア ：「99.9%と99.99%は全然違う！」 経営層 ：「どちらもほぼ100%でしょ？」 「危機感」と「安心感」のギャップ → 投資判断の遅れに直結する 数値ではなく、「影響」で伝える必要がある
31. 31 03. 壁② 温度差の壁 ビジネスインパクトへの変換 SLO → 月間ダウンタイム → 売上損失 「99.9%達成」ではなく 「この月は43分サービス停止があった」と言う エラーバジェット残60% →あと◦件の障害まで猶予あり 数値の羅列から「経営判断の材料」へ
32. 32 03. 壁② 温度差の壁
33. 33 03. 壁② 温度差の壁
34. 34 03. 壁② 温度差の壁 四半期「信頼性レポート」の設計 📊 障害による売上影響の累計 📈 信頼性投資のROI 投資額 vs 障害による損失削減額 ⚡ エラーバジェット残高 「あと何件の障害が許容できるか」 → 経営層が「自分ごと」で判断できる形に
35. 35 03. 壁② 温度差の壁 経営層の反応が変わった Before ：「報告を受け取るだけ」 After ：「信頼性は大丈夫？」が月2-3回 → 信頼性が経営課題として認識された 投資判断のスピードが変わった
36. 36 03. 壁② 温度差の壁 壁②を越えた成果（実績値） ⬇ 60%信頼性投資の承認速度改善 平均2ヶ月から 📈 月2-3回 経営層からの能動的な確認 月0回から ✅ 技術的負債解消の予算確保に成功
37. 37 03. 壁② 温度差の壁 Q. 経営会議で ... 「SLO」や「信頼性」という言葉が 経営層の口から自然に出てきますか？ 経営層がSREを「自分ごと」として話し始めたら → その組織は「壁②」を越えています
38. 壁③：完璧主義の壁 ── 全員に同じ理解を 求めた失敗 04.
39. 39 04. 壁③ 完璧主義の壁 全員に同じ理解を求めた失敗 ステークホルダー向けSREスキルトランスファーを実施 ✅ 参加率は高かった ⚠ 理解度はなかなか上がらない ❌ 一定期間後「結局SRE固有の話でしょ？」
40. 40 04. 壁③ 完璧主義の壁 なぜ失敗したのか CSに「5 Whys」は必要ない 経営層に「MTTRの計算式」は必要ない 役割に合わない理解を押し付けていた 「Inclusive = 全員が同じことを知る」ではなかった
41. 41 04. 壁③ 完璧主義の壁 Inclusiveを再定義する Before ：「全員が同じことを知る」 After ：「全員が自分の役割で SREを実践する」 100%の理解 = オーバーエンジニアリング 役割に応じた理解 = ちょうどいい関わり方
42. 42 04. 壁③ 完璧主義の壁 役割ごとの Include設計 役割 必要な理解 SREの実践例 ────────────────────────────────────── SRE SLO/エラーバジェット 設計・運用 PM リリース判断用の数値 データ意思決定 CS ユーザー影響状態 対応・フィードバック 経営層 売上影響とROI 投資判断 法務 通知基準 法的通知判断
43. 43 04. 壁③ 完璧主義の壁
44. 44 04. 壁③ 完璧主義の壁 実例①：CSのフィードバックが SLO改善に直結 CSからのフィードバック： 「検索画面の表示が遅いという 問い合わせが増えています」 → 従来SLOにはなかった指標を発見 →「検索画面の表示速度」をSLO化 CSが「SREの一員」として機能した瞬間
45. 45 04. 壁③ 完璧主義の壁 実例②：経営層の投資が信頼性向上に 信頼性レポートを見た経営層: 「この3ヶ月で数百万円規模の損失が出ている 技術的負債を解消しよう」 → 予算承認 → インフラ改善 → 障害減少 経営層が「SREのスポンサー」になった
46. 46 04. 壁③ 完璧主義の壁 壁③を越えた成果（実績値） ⭐ 大幅改善 SREに関わっている実感 ⬇ 75%改善 インシデント初動から全部門連携まで 以前は20分から5分に短縮 🔄 共通認識 「信頼性を高めるための活動は エンジニアだけの仕事じゃない」
47. 47 04. 壁③ 完璧主義の壁 Q. あなたのチームには ... ビジネス職で「信頼性を自分ごと」として 話している人がいますか？ CSが「あの問い合わせ、信頼性に関係しそう」と言い 経営層が「信頼性の予算、足りてる？」と聞く → それが「壁③」を越えた証拠です
48. まとめ：Inclusive SREの3原則 05.
49. 49 05. まとめ Inclusive SRE 3原則 ▪ 原則1：翻訳する 　SLO・エラーバジェットを経営・ビジネス言語に変換する ▪ 原則2：役割を渡す 　SREがボトルネックにならないよう、オーナーシップを 　分散する ▪ 原則3：完璧を求めない 　「100%達成」より「今週は改善した」を重視する 　理解度は役割に応じたレベルにチューニングする
50. 50 05. まとめ
51. 51 05. まとめ 原則1：翻訳する SREの言葉を、相手の言語に翻訳する • 「エラーバジェット残30%」→「残り◦時間の障害余力」 • 「SLO 99.9%」→「月間43分の許容ダウンタイム」 • 「P50レイテンシ200ms」→「2人に1人が0.2秒待っている」 翻訳なき指標は、ただの数字。 相手の意思決定に繋がる言葉を選ぶことがSREの仕事。
52. 52 05. まとめ 原則2：役割を渡す SREがすべてを抱え込まない組織設計 • SLO定義はプロダクトオーナーと共同で • 障害対応のRunbookは開発チームが書く • ダッシュボードの読み方は全員が知っている SREの役割は「やる人」から「教える人・設計する人」へ。 オーナーシップを渡すことで、組織全体のレジリエンスが高まる。
53. 53 05. まとめ 原則3：完璧を求めない 「今週より来週が良ければ良い」という文化 「全員が同じ深さで理解する必要はない」 • 役割に合った理解が「ちょうどいい関わり方」 • CSは「ユーザー影響」を、経営層は「ROI」を知れば十分 • SREがすべてを教え込もうとすることが完璧主義 完璧なInclusiveより、継続できるInclusiveを。
54. 54 05. まとめ Include Everyone, in Their Own Way. SREは、特定のチームのものではない。 • エンジニアには技術的な深さで • PMには数字と影響で • 経営層にはリスクと機会で 同じ信頼性の話を、相手に合わせた「言語」で届ける。 それが「全社SRE」の姿。
55. 55 05. まとめ Include Everyone, in Their Own Way. お話した内容で、少しでも「これは良いな …！」と思えたものが あったら、来週試してみてください。 変わる組織は1人が1つ動くところから始まります。 あなたの組織で、次に壁を一緒に越えたい相手は誰ですか？ まずは1人のエンジニア以外の職種の方にぜひ声をかけてみてく ださい！
56. fin