「ちゃんとやっている」は独りよがりだった ― 不安に寄り添うインシデント対応へ / Towards incident response that addresses anxieties

Transcript

1. 「ちゃんとやっている」は独りよがりだった ― 不安に寄り添うインシデント対応へ SREと事業部⾨、対話から始めた物語 2026年7⽉10⽇ ｜ SRE NEXT 2026 Track C 株式会社ログラス ｜ mekka
2. ⾃⼰紹介 mekka X: @melpo_mel ∕ GitHub: chmikata 株式会社ログラス 技術基盤部 SRE SIerでアプリケーションエンジニアとしてキャリアをスタート ToBのSaaS企業でSRE組織の⽴ち上げを経験、2024年10⽉よりログラスに参画。共通基 盤部でSRE推進‧プラットフォーム開発に従事 今⽇話すインシデント対応の改善∕事業部⾨との関係再構築を主導した当事者
8. アジェンダ 1. 前回のあらすじ ― 100⽇間で作った体制 2. 教科書通りにやったはずだった 3. 「独りよがり」の発覚と根本原因 4. 対話と関係性の再構築 ― 会話と対話は違う 5. 成果と根づいた⽂化 6. まとめ ― 対話はSREの最重要スキル 本⽇お話しすること
9. 今⽇これだけ覚えて帰ってください プロセスの前に、対話と関係性がある
10. 前回のあらすじ • SRE NEXT 2025「SRE不在の開発チームが障害対応と向き合った100⽇間」（発表: 勝丸 真）の続き • ⼀度つくった体制は、その後どうなったのか このセッションは「続編」です 「うまく回っている」は作った側の思い込みかもしれない 仕組みを作ったその先で何が起きたのか ― 今⽇はその「続き」をお話しします 前回の発表資料
11. 前回のあらすじ 100⽇間でつくった体制（おさらい） • SRE不在‧週次持ち回りで品質がばらつく状態か らスタート • インシデントコマンダーをロール化（開発チー ムの有志で組成） • 障害レベル定義を整備、対応フローを刷新 • Waroom（インシデント管理ツール）を導⼊し、 MTTR（平均復旧時間）を可視化‧改善
12. 教科書通りにやったはずだった
13. 教科書通り • コマンダー制度‧障害レベル定義‧対応フロー • Waroom のランブック（対応⼿順書）に沿って初動からクローズまで対応 • MTTR を計測し、早く‧確実にシステムを復旧させることに注⼒ • 対応後のポストモーテムも仕組み化し、振り返りまで回す体制に ベストプラクティスを⼀通り揃えた
14. 教科書通り • コマンダーがランブックに沿って対応していた • MTTRも縮み、運⽤は⼀定回っていた ⼿応えはあった 「これで、ちゃんとやれている」 この頃は、うまく回っているように⾒えていた
15. 教科書通り • 各プロダクトの組織拡⼤に伴い、コマンダーをプロダクトごとに専任化 • 経営管理プロダクトは経験者2名（mekka‧勝丸）が実務を離脱 • 現場は新メンバー3名に。経験者（⼤平）は別プロダクトが主で必要時のみサポート • 引き継ぎ後もMTTR上は「問題なし」…それが落とし⽳ その後 ― 体制変更、それでも「問題なし」に⾒えた
16. 「独りよがり」の発覚
17. 独りよがりの発覚 数ヶ⽉後、事業部⾨から声が上がった “インシデントコマンダーが、機能しているとは思えない — CSマネージャー（クリティカルインシデントの対応ログを分析して） 感覚ではなかった。Slackのログを⼀件ずつ調べたうえでの、根拠ある指摘だった
18. 独りよがりの発覚 • レベル判断：顧客業務への影響を、基準として捉えきれていない • 情報共有：顧客対応に必要な情報が、必要な速さ‧粒度で届かない • 顧客フォロー：影響範囲の調査も、次の顧客対応も後⼿ → 共通点は1つ ― システムは⾒ていたが、顧客を⾒ていなかった 指摘はどれも「顧客⽬線の⽋如」に⾏き着いた
19. 独りよがりの発覚 • MTTR＝機能の修正‧復旧までの時間 ― 確かに縮んでいた • でも⾒ていたのは「速く直す」という⼀軸だけ • 顧客と向き合う側 ― 判断‧情報‧フォロー ― が本質的に抜けていた • 「速く直せている」のに、顧客対応の現場は変わっていなかった 「速く直せている」のに顧客⽬線が抜けていた
20. 独りよがりの発覚 • ルールは作った、MTTRも⾒ている → ⼤丈夫だと思っていた • 実態は、経験者が事業部⾨と個別にやり取りし、期待値を合わせて"良い塩梅"で進めていた 経験者の"強さ"はルールに書かれない「個⼈技」だった 仕組みを⽀えていたのは、ルールではなく経験者の「個⼈技（慣れ‧経験）」だった その慣れ＝ノウハウは暗黙知。現場が新メンバー3名になり、担い⼿が⽇常的にいなくなった
21. 独りよがりの発覚 • 横の対話：新メンバー⇄事業部⾨ がない → 期待値がズレ、信頼を損ねた • 縦の対話：経験者⇄新メンバー も⾜りず →「既存ルールでやれる」と思い込んだ • 新メンバーはノウハウを知らないまま、ルールだけを信じて動いた • 事業部⾨から⾒れば「メンバーが変わって、精度が落ちただけ」に映る 体制変更で露呈した「⼆重の対話不⾜」
22. 独りよがりの発覚 • 個⼈技で回っていた ― これは表層。本当の問いは「なぜ個⼈技のままだったのか」 • 経験者がやっていた期待値合わせ＝対話が、関係性‧⽂化として根づいていなかった＝再現性なし 根本原因 ― 個⼈技に頼り、「対話」が根づいていなかった ⾜りなかったのは「対話を続ける関係性」そのものだった 断絶は悪意ではなく無理解から。だから次は、対話で関係性を作り直すところから始めた
23. 対話と関係性の再構築
24. 対話と関係性の再構築 「会話」と「対話」はまるで別物 観点 ただ話す（会話‧雑談‧議論） 「対話」 ⽬的 要件の伝達‧その場を埋める 背景‧前提（コンテキスト）の同期 スタンス ⾃分の主張を通す（誰が正しいか） 何が正しいかをシステム思考で探る 聴き⽅ 次に話すことを考えながら聴く なぜその⾏動をとったか、背景を聴く 焦点 誰のミスか（Blame） 何が起きたか（Blameless＝⾮難しない） 成果 表⾯的な安⼼‧⼀時的な合意 ⼼理的安全性と、組織の学習
25. 対話と関係性の再構築 • エスカレーションを受け、まず事業部⾨マネジメントと直接調整に動く • 「正しさ」や「誰のせいか」をぶつけず、なぜ‧何に困っているかを聴く • 背景‧前提を腹を割って共有＝コンテキストの同期 • 途中からインシデントコマンダーチームも巻き込み、チームで進める 対話の⼟台をつくる ― まず聴き、チームを巻き込む
26. 対話と関係性の再構築 • 「正しい仕組み」と「納得できる仕組み」は別物だった • 情報共有：「確証を得てから」は開発の誠実さ、CSには「遅い」 • レベル判断：技術者はシステム⾯だけ⾒て過⼩評価しがち ― 顧客業務が⽌まっている景⾊が⾒えていない • ポストモーテム：最初はお互いに遠慮して本⾳が出なかった • 繰り返し対話を重ねるうちに、率直に話せる関係＝⼼理的安全性が育った 順調ではなかった ― 四苦⼋苦したこと
27. 対話と関係性の再構築 • ① 情報共有：怪しい段階で、まず出す • ② レベル判断：経験者の勘を、誰でも判定できるルールに • ③ 顧客フォロー：CS連携を、最後までやりきる • ④ 対話を続ける：運⽤しながら、CSと⼀緒に直し続ける → ここからは、実際のルールで⼀つずつ 対話から⼀緒に変えた4つのこと
28. 対話と関係性の再構築 ① 情報共有 ― 怪しい段階で、まず出す（対話で覆った思い込み） 認識のズレが、いちばんはっきり出たのが「情報を出すスピード」 怪しい動きや問い合わせを、"完全に問題"と確定してから起票していた コマンダーチームの思い込み • 不正確な情報は外に出したくない • 確証を得てから伝えるべき • 曖昧なまま出すとCSに迷惑では 対話で知ったCSの本⾳ • 早く動きたい ― スピードが要る • 今わかっていることを早く • 「問題なければ、それでいい」 → だから ― 怪しい段階でも、社内‧CSへはまず共有して動き出す ※顧客への通知は別 ― "調査中"だけは出さず、意味のある情報をサポート体制とセットで
29. 対話と関係性の再構築 ② レベル判断 ― 経験者の勘を、再現性あるルールへ 影響度 × 緊急度のマトリクスで判定 ― CSと実事例を元に基準と具体例を再定義 緊急度 ⾼ 緊急度 中 緊急度 低 影響度 ⾼ Critical High Low 影響度 中 High Low Info 影響度 低 Low Info Info •影響度 ⾼：多数の顧客のレポート実績がズレる可能性 / 中：特定条件下の顧客のみ •緊急度 ⾼：機能停⽌＋代替案なし（⾮現実的な代替は不可）/ 中：代替案で対応可能 •判定後に関係者でクロスチェック ― レベルはいつでも⾒直してよい、変わればすぐ共有 → 基準は対話の出発点 ― 決めつけず対話の中で⾒直し続ける"⽣きたルール"
30. 対話と関係性の再構築 • インシデント対応は「システム修正」と「顧客対応」の2本⽴て • 以前は修正のフローにばかり⽬がいき、顧客対応が抜けていた • CSの個別フォローに必要な情報を共有（必要なら追加調査も） • 全対応が完了するまで⾒届けて、はじめてクローズ ③ 顧客対応のフローを、最後までやり切る
31. 対話と関係性の再構築 • ポストモーテム：CSも参加し、顧客対応の視点で改善点を上げてもらう • フロー：やり⾟ければいつでも声を上げて⾒直す ― 気になったらすぐ共有が前提 • CS業務の改善：サポートサイト周知やメール配信など、CS側の作業をヒアリングし技術者が⾃動化を提案 • 四半期ごとにCSへヒアリングし、運⽤の困り事を拾う → お互いの業務を理解し、対話を通じて協業しながら継続的に改善する関係へ ④ 対話を「続ける」― 継続的な改善のために
32. 成果と根づいた⽂化
33. 成果と⽂化 • 起票から数時間⾳沙汰なし → 検知から30分以内に共有‧レベル判定‧全体周知 • ⽔準‧⽬線を揃え直した ― 「凡事徹底」ができていなかったと気づけた • 組織の学習が回り出した ― 振り返って仕組みを直す • 事業部⾨（CS）の満⾜度向上も、関係者ヒアリングで確認 数値だけでなく⽂化が変わりはじめた 根っこは同じ ― みんな「顧客に良いサービスを」。⼩さなかけ違いを、対話で埋めていった 率直にFBし合える関係に近づいてきた ― 信頼回復は道半ば、これからも続けていく
34. まとめ • 『SREをはじめよう』は、多くの⼈を巻き込み協⼒を得る重要スキルとして「ストーリーテリング」を挙げている • 対話で背景を揃え、物語として伝えることで、相⼿が"協⼒したくなる"状態をつくる 対話はSREの最重要スキル スピードやルールの前にまず"対話"がある ― SREのコアスキル 背景を同期し"何が起きたか"を⼀緒に探る → ⼼理的安全性と組織の学習へ繋げる
35. まとめ • 対話とは、背景を同期し、"何が起きたか"を⼀緒に探ること • 「会話」と「対話」は違う ― ⼀⽅的に伝える∕議論で勝つのは対話ではない • その積み重ねが、⼼理的安全性と組織の学習を⽣む • 仕組みは、それを動かす⼈と⼈の対話が伴って初めて機能する • 信頼性は、組織全体で対話を通じて担うもの まとめ
36. まとめ • 「ちゃんとやっている」はずなのに、なぜか相⼿と⼿応えがズレる • そんなときの答えは、たぶんプロセスの外側 ― 対話の中にあります 最後に 「ちゃんとやっている」を、独りよがりにしないために まず、向き合うべき⼈と対話を始めましょう