なぜSRE・セキュリティは評価されないのか？守りの組織を事業成長エンジンに変えた実践

Product Engineering Conference 2026の登壇資料。
https://product-engineering.jp/2026/

プロポーザル。
https://fortee.jp/pdeconf-2026/proposal/dfcd864d-0512-4de8-a800-b8489dfe2f02

Transcript

1. 2026/09/05 Product Engineering Conference 2026 なぜSRE・セキュリティは評価されないの か？守りの組織を事業成長エンジンに変 えた実践 株式会社サイバーセキュリティクラウド VP of Engineering Operations 川崎 雄太
2. ⾃⼰紹介 川崎 雄太 Yuta Kawasaki @yuta_k0911 株式会社サイバーセキュリティクラウド セキュリティインテリジェンス本部 本部長 VP of Engineering Operations EM of EMs、DevHR、DevRelを管掌。 VPoEロールとして、人事制度・評価制度の刷 新なども携わっている。 SRE NEXT 2023 / 2025 / 2026登壇 AWS Community Builder（Security） 2
3. 株式会社サイバーセキュリティクラウドについて 社 名 株式会社サイバーセキュリティクラウド 設 ⽴ 2010年8⽉11⽇ 代表者 代表取締役社⻑ 兼 CEO ⼩池 敏弘 代表取締役CTO 渡辺 洋司 所在地 東京都品川区上⼤崎3-1-1 JR東急⽬黒ビル13階 事業内容 サイバーセキュリティサービスの開発‧提供 グループ 会社 Cyber Security Cloud Inc. （USA） Cyber Security Cloud Pte. Ltd. （Singapore） 株式会社ジェネレーティブテクノロジー 株式会社DataSign Mission 世界中の⼈々が安⼼安全に使える サイバー空間を創造する 2023 2020 売上高 脆弱性診断 サービス （百万円） 2017 2025 フルマネージド セキュリティサービス 提供開始 2024 DataSign⼦会社化 ‧ジェネレーティブ テクノロジー設⽴ ‧シンガポール⼦会社設⽴ WAF⾃動運⽤サービス提供開始 脆弱性情報管理‧収集 2019 2013 2018 CSC Managed Rules for AWS WAF ‧新規上場 ‧ソフテック⼦会社化 US⼦会社設⽴ クラウド型WAF提供開始 2013 ‧‧‧ ©Cyber Security Cloud, Inc. 3
4. 株式会社サイバーセキュリティクラウドについて プロダクトラインナップ 運用 運用 フルマネージドセキュリティ WAF自動運用サービス パブリッククラウドのWAF⾃動運⽤サービス 3⼤クラウドプラットフォームのフルマネージド セキュリティサービス CSC Managed Rules for AWS WAF AWS WAF専⽤のルールセット 防御 管理 脆弱性管理・診断 クラウド型 WAF OSやアプリケーションの脆弱性情報 を収集し提供するサービス Webサイト‧サーバへのサイバー 攻撃を検知‧遮断するサービス 脆弱性診断サービス 構築 クラウド構築・開発 セキュアなシステム開発環境の構築サービス 管理 Webアプリケーション等に関する 脆弱性診断サービス 個人情報同意管理ツール 世界各国の規制に対応した 個⼈情報同意管理ツール ©Cyber Security Cloud, Inc. 4
5. ⚠前提のご案内 ⚠ このセッションで話す内容は前職（ココナラ、SRE・社 内情報システム・セキュリティのEM / グループ会社 の執行役員）の実績も含みます。 その前提でお聞きいただけると幸いです。 5
6. ⚠はじめに ⚠ このセッションで話すこと🙆 • 守りの組織（SRE・セキュリティ・情シス）を事業成長 に接続する組織設計と“翻訳”の実践（失敗もあるよ） このセッションで話さないこと🙅 • SRE・セキュリティのテクニカルな内容 • 純粋なProduct Engineeringの話 6
7. 01. 問題提起 ── なぜ守りは評価されないのか 02. 突破⼝ ── 守りの「再定義」と翻訳の型 03. 実例 ── 守りの成果を経営指標に変換する 04. 組織設計 ── SRE‧セキュリティ‧情シスを束ねる 05. まとめ ── 守りを事業成⻑のエンジンに Contents 7
8. 01. 問題提起
9. 01. 問題提起 Q. ちょっと聞いてもいいですか？ この会場で 「インシデントがなかった月の運用の成果」を 経営層に説明している方はいますか？ そのうち「守りへの投資が増えた」という方は？ 今日は“評価されない守り”を変える話をします。 9
10. 01. 問題提起 再現ドラマ風シーン 現場：来期、セキュリティ強化に1,000万円の追加投資が必要です。 経営層：今年は大きな事故もなかったよね？何に使うの？ 現場：えっ…（事故がなかったのは、対策の成果なのに…） “何も起きていない”ときの価値が伝わらず、 投資判断が進まない…😭 10
11. 01. 問題提起 守りが評価されない 3つの理由 ① 予算は使うが、売上を生まない（コストセンター視） ② 成果が“インシデントがないこと”となるため、見えにくい ③ 経営の言葉で報告されず、伝わらない → 3つは独立ではなく、連鎖して悪循環になる 11
12. 01. 問題提起 なぜ「コスト」に見えるのか 守りの価値 ＝「回避した損失」 起きなかったことは、誰にも見えない → 動いていて当たり前、守れていて当たり前 → 見えない価値は、予算の議論で最初に削られる 12
13. 01. 問題提起 守り側も、価値を語れていない 評価されない原因は、経営層だけではない 「守り＝守るだけ」という自己認識も、壁になる 「障害対応しました」「指摘に対応しました」…and more → 活動は語れても、事業への貢献を語る言葉がない 13
14. 01. 問題提起 守りが陥る「悪循環」 評価 されない 投資 されない 守りが 弱る 放置すると回り続ける 信頼が 下がる 事故が 起きる どこかで断ち切らないと、守りは弱り続ける （事故直後に付く予算は一過性で、循環は変わらない） 14
15. 01. 問題提起 今日のゴール 守りは“コスト”ではなく、 “事業継続と成長の担い手 ” そのために必要なのは、次の3つ ① 守りの指標と成果を、経営の言葉に翻訳する ② 3領域の守りの投資に、優先順位を設計する ③ 守りの役割を渡し、組織全体で守る → 守りは、事業成長のエンジンになる 15
16. 02. 突破⼝：守りの再定義
17. 02. 突破口 守りの「再定義」 ◦ After × Before コストセンター 使うだけ・成果が見えない 経営層「コストでしょ？」 再定義 リスク管理・事業継続と 成長の担い手 回避した損失を可視化する → 経営層が「投資」する 「回避した損失」を可視化すると、守りは投資対象になる 17
18. 02. 突破口 見えない価値を、可視化する 翻訳 「何も起きなかった」 「◯◯というリスクを △△万円分、回避した」 → ここから、すべての実践が始まる 18
19. 02. 突破口 同じ指標を、相手の言語に翻訳する CS 今、ユーザーに何が 起きているか 翻訳 守りの指標 PdM SLO・脆弱性・ インシデント リリース判断に使える数値 経営層 売上影響・ROI・リスク 翻訳なき指標は、ただの数字 19
20. 02. 突破口 翻訳の対訳表：同じ事実を、経営の言葉で 守りの指標 そのままの報告 経営の言葉に翻訳 SLO・ エラーバジェット 「可用性は99.9%です」 「あと◯回、 攻めるリリースができます」 脆弱性対応 「◯件パッチを適用しました」 「漏えい時の損失◯円を 回避しました」 監査・統制 「指摘に対応しました」 「大型案件の受注要件を 維持しています」 インシデント対応 「障害を復旧しました」 「機会損失を◯分×◯円に 抑えました」 20
21. 03. 実例：経営指標に変換
22. 03. 実例 実例A｜エラーバジェットが閉じている SLO・エラーバジェットは運用できていた。しかし… ❌ エンジニア内の指標に閉じている ❌ リリース可否や投資判断に接続していない → 経営層「よくわからないけど、順調なんだよね？」 22
23. 03. 実例 実例A｜「あとどれだけ攻めていいか」に翻訳 エラーバジェットを 「あとどれだけ攻めていいか」の共通ルールに翻訳 ✅ リリース判断がデータドリブンに ✅ 信頼性投資の意思決定スピードが向上 （判断リードタイム 5日→2日） → 守りが“アクセルの判断材料”になる 23
24. 03. 実例 エラーバジェット＝ “あとどれだけ攻めていいか ” 残り 70% → 攻めていい（新機能を出す） 残り 30% → 慎重に（重い変更は止める） 残り 10% → 止める（信頼性の回復に振る） ※ 割合は説明のための例。しきい値はチームで決める 同じ数字が、リリース判断の共通ルールになる 24
25. 03. 実例 実例B｜監査対応が「後追い」になる ❌ 監査指摘への対応が、毎回その場しのぎ ❌ 同じ指摘が繰り返され、都度対応で疲弊 ❌ 「開発を止める人」に見られてしまう → 守りの信頼が、社内で下がっていく 25
26. 03. 実例 実例B｜経営リスクの言葉に変換する 指摘を「経営リスク・コンプライアンスコスト」の 言葉に変換し、対応を型化・恒常化 ✅ 監査指摘が年10件→4件に減少（＝信頼の証・コスト削減） ✅ セキュリティが“売れる理由”になる → 守りが“信頼の資産”に変わる 26
27. 03. 実例 実例C｜守りの人材が育たない ❌ 成果が見えにくく、評価されにくい ❌ キャリアパスが描けない ❌ 採用も定着も、難しい → 守りの弱体化が、さらに進む 27
28. 03. 実例 実例C｜貢献を評価・育成に組み込む 守りの貢献を「回避した損失・事業継続への寄与」で 言語化し、評価・育成の設計に組み込む ✅ 守りの人材が育ち、残る組織に（その後2年、退職者ゼロ） ✅ Cloud Operator Days Tokyo 2025 最優秀オペレーター賞を受賞 → 人材面でも、悪循環を断ち切れる 28
29. 03. 実例 3つの実例に共通する「型」 課題 翻訳 接続 見えない価値 （コスト扱い） 経営の言葉へ 変換する 意思決定・投資・ 信頼へ この型は、どの守り領域でも再現できる 29
30. 03. 実例 実例A・B・C の総まとめ 実例 A｜SLO B｜監査 C｜人材 課題（Before） 翻訳 効果（After） エンジニア内に閉じる 「あとどれだけ攻めてい リリース判断が速くなる いか」 後追い・その場しのぎ 経営リスク・コンプラコス 指摘が減り、売れる理 ト 由に 評価されず、育たない 回避した損失・事業へ の寄与 育ち、残る組織になる 30
31. 03. 実例 この型が、すぐに使えなかった事例 やったこと 相手の反応 学び 守りの指標の改善 状況をそのまま数 値で報告した 守りの指標が良く なると何が嬉しい のかがわからない 事業数値と守りの 指標を結びつけて 言語化し直した 翻訳は、一度では決まらない 31
32. 03. 実例 Q. あなたの組織では、どうですか？ 先月、あなたの守りチームが回避したリスクを… 経営・PdMの言葉で、1つ言えますか？ → 言えないなら、今日の“型”を試すサインです 32
33. 04. 組織設計と優先順位
34. 04. 組織設計 束ねてわかった：全部は守れない SRE セキュリティ 情シス 専門性はまったく違う。しかし予算と人は共通で有限 “何を守らないか ”を決める、優先順位の設計が要る → 実際に後回しにしたのは「認証スコープの拡大」と「検知ルールの追加」 （前者は対象外システムを次期へ、後者は誤検知の削減に振り切った） 34
35. 04. 組織設計 3領域は、守る対象が違う SRE｜可用性・性能 セキュリティ｜脅威・脆弱性・監査 誰も 見ていない 情シス｜端末・アカウント 基盤 アプリ 認証・端末 委託先・外部 重なりは調整できる。隙間は、誰も気づかない 35
36. 04. 組織設計 EM of EMsは「翻訳のハブ」になる 各領域の専門性を深く理解するのは、現場のEM ① 3領域の成果を、経営の言葉に翻訳して束ねる ② 領域横断で、守りの投資の優先順位を設計する → 専門性の深さではなく、“接続”で価値を出す 36
37. 04. 組織設計 3領域それぞれの「経営への翻訳」例 領域 代表的な指標 経営の言葉に翻訳すると SRE SLO・エラーバジェット 売上機会の維持・攻めの余地 セキュリティ 脆弱性件数・対応リードタイム 回避した損失・受注の信頼要件 情シス 資産・アカウント統制の網羅率 監査コスト削減・全社の生産性 37
38. 04. 組織設計 守りの投資の優先順位 次点 最優先 後回し 次点 事業インパクト ↑ リスクの大きさ → ＋ 緊急度でさらに調整する 38
39. 04. 組織設計 実際に、何を後回しにしたか 最優先 次点 監査指摘の型化 誤検知の削減 事業インパクト ↑ 後回し 認証スコープの拡大 検知ルールの追加 次点 リスクの大きさ → “検知ルールを増やす ”をやめ、 “誤検知を減らす ”を選んだ 39
40. 04. 組織設計 優先順位は、経営と同じテーブルで決める 事業インパクト × リスク × 緊急度 の3つで、守りの投資を並べる ポイントは、守りチームだけで決めないこと → 経営・事業側と同じテーブルで、順位に合意する → 合意した優先順位が、守りの“評価基準”になる 40
41. 04. 組織設計 抱え込まない：役割を渡す 守りを、守りチームだけの仕事にしない 翻訳とオーナーシップを、各職種へ渡す CS PdM 経営層 それぞれの持ち場で守る → ボトルネックが解消し、組織のレジリエンスが上がる 41
42. 05. まとめ：3原則
43. 05. まとめ 守りを事業成長に変える 3原則 ▪ 原則1：翻訳する 守りの指標と成果を、経営・ビジネスの言語に変換する ▪ 原則2：優先順位を設計する 「事業インパクト × リスク × 緊急度」で守りの投資を 並べ、経営と同じテーブルで合意する ▪ 原則3：役割を渡す 守りチームがボトルネックにならないよう、 オーナーシップを各職種へ分散する 43
44. 05. まとめ 明日からのアクション ① 「インシデントがなかった月の成果」を経営の言葉で1つ書いてみる ② 回避した損失を、金額で見積もってみる ③ 守りのタスクを「事業インパクト × リスク」で並べてみる ④ 守りの指標を1つ、CSかPdMに“渡して”みる 44
45. 05. まとめ 最初の90日ロードマップ 期間 やること ゴール 明日〜 4つのアクションを試す 翻訳の「一言」を1つ作る 〜30日 経営・PdMに翻訳を届け、反応を見 る 通じる言葉のパターンを掴む 〜90日 優先順位を経営と同じテーブルで合 意する 守りの投資が「判断できる」状態に 45
46. 05. まとめ 守りは、プロダクトと事業の一部 今日お話した内容で、少しでも「これは良いな…！」と思えたもの があったら、来週試してみてください。 「100%達成」でなくて大丈夫です。“継続できる守り”を何より優先し てください。変わる組織は1人が1つ動くところから始まります。 攻めと守りの境界を越えて、一緒に事業を伸ばしましょう。 まずは、守りの成果を 1つ“翻訳”して、経営・ PdMに届けて みてください！ 46
47. fin