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

by mekka

Embed

Start on current slide

Slide 1

Slide 1 text

「ちゃんとやっている」は独りよがりだった ― 不安に寄り添うインシデント対応へ SREと事業部⾨、対話から始めた物語 2026年7⽉10⽇｜ SRE NEXT 2026 Track C 株式会社ログラス｜ mekka

Slide 2

Slide 2 text

⾃⼰紹介 mekka X: @melpo_mel ∕ GitHub: chmikata 株式会社ログラス技術基盤部 SRE SIerでアプリケーションエンジニアとしてキャリアをスタート ToBのSaaS企業でSRE組織の⽴ち上げを経験、2024年10⽉よりログラスに参画。共通基盤部でSRE推進‧プラットフォーム開発に従事今⽇話すインシデント対応の改善∕事業部⾨との関係再構築を主導した当事者

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

アジェンダ 1. 前回のあらすじ ― 100⽇間で作った体制 2. 教科書通りにやったはずだった 3. 「独りよがり」の発覚と根本原因 4. 対話と関係性の再構築 ― 会話と対話は違う 5. 成果と根づいた⽂化 6. まとめ ― 対話はSREの最重要スキル本⽇お話しすること

Slide 9

Slide 9 text

今⽇これだけ覚えて帰ってくださいプロセスの前に、対話と関係性がある

Slide 10

Slide 10 text

前回のあらすじ • SRE NEXT 2025「SRE不在の開発チームが障害対応と向き合った100⽇間」（発表: 勝丸真）の続き • ⼀度つくった体制は、その後どうなったのかこのセッションは「続編」です「うまく回っている」は作った側の思い込みかもしれない仕組みを作ったその先で何が起きたのか ― 今⽇はその「続き」をお話しします前回の発表資料

Slide 11

Slide 11 text

前回のあらすじ 100⽇間でつくった体制（おさらい） • SRE不在‧週次持ち回りで品質がばらつく状態からスタート • インシデントコマンダーをロール化（開発チームの有志で組成） • 障害レベル定義を整備、対応フローを刷新 • Waroom（インシデント管理ツール）を導⼊し、 MTTR（平均復旧時間）を可視化‧改善

Slide 12

Slide 12 text

教科書通りにやったはずだった

Slide 13

Slide 13 text

教科書通り • コマンダー制度‧障害レベル定義‧対応フロー • Waroom のランブック（対応⼿順書）に沿って初動からクローズまで対応 • MTTR を計測し、早く‧確実にシステムを復旧させることに注⼒ • 対応後のポストモーテムも仕組み化し、振り返りまで回す体制にベストプラクティスを⼀通り揃えた

Slide 14

Slide 14 text

教科書通り • コマンダーがランブックに沿って対応していた • MTTRも縮み、運⽤は⼀定回っていた⼿応えはあった「これで、ちゃんとやれている」この頃は、うまく回っているように⾒えていた

Slide 15

Slide 15 text

教科書通り • 各プロダクトの組織拡⼤に伴い、コマンダーをプロダクトごとに専任化 • 経営管理プロダクトは経験者2名（mekka‧勝丸）が実務を離脱 • 現場は新メンバー3名に。経験者（⼤平）は別プロダクトが主で必要時のみサポート • 引き継ぎ後もMTTR上は「問題なし」…それが落とし⽳その後 ― 体制変更、それでも「問題なし」に⾒えた

Slide 16

Slide 16 text

「独りよがり」の発覚

Slide 17

Slide 17 text

独りよがりの発覚数ヶ⽉後、事業部⾨から声が上がった “インシデントコマンダーが、機能しているとは思えない — CSマネージャー（クリティカルインシデントの対応ログを分析して）感覚ではなかった。Slackのログを⼀件ずつ調べたうえでの、根拠ある指摘だった

Slide 18

Slide 18 text

独りよがりの発覚 • レベル判断：顧客業務への影響を、基準として捉えきれていない • 情報共有：顧客対応に必要な情報が、必要な速さ‧粒度で届かない • 顧客フォロー：影響範囲の調査も、次の顧客対応も後⼿ → 共通点は1つ ― システムは⾒ていたが、顧客を⾒ていなかった指摘はどれも「顧客⽬線の⽋如」に⾏き着いた

Slide 19

Slide 19 text

独りよがりの発覚 • MTTR＝機能の修正‧復旧までの時間 ― 確かに縮んでいた • でも⾒ていたのは「速く直す」という⼀軸だけ • 顧客と向き合う側 ― 判断‧情報‧フォロー ― が本質的に抜けていた • 「速く直せている」のに、顧客対応の現場は変わっていなかった「速く直せている」のに顧客⽬線が抜けていた

Slide 20

Slide 20 text

独りよがりの発覚 • ルールは作った、MTTRも⾒ている → ⼤丈夫だと思っていた • 実態は、経験者が事業部⾨と個別にやり取りし、期待値を合わせて"良い塩梅"で進めていた経験者の"強さ"はルールに書かれない「個⼈技」だった仕組みを⽀えていたのは、ルールではなく経験者の「個⼈技（慣れ‧経験）」だったその慣れ＝ノウハウは暗黙知。現場が新メンバー3名になり、担い⼿が⽇常的にいなくなった

Slide 21

Slide 21 text

独りよがりの発覚 • 横の対話：新メンバー⇄事業部⾨がない → 期待値がズレ、信頼を損ねた • 縦の対話：経験者⇄新メンバーも⾜りず →「既存ルールでやれる」と思い込んだ • 新メンバーはノウハウを知らないまま、ルールだけを信じて動いた • 事業部⾨から⾒れば「メンバーが変わって、精度が落ちただけ」に映る体制変更で露呈した「⼆重の対話不⾜」

Slide 22

Slide 22 text

独りよがりの発覚 • 個⼈技で回っていた ― これは表層。本当の問いは「なぜ個⼈技のままだったのか」 • 経験者がやっていた期待値合わせ＝対話が、関係性‧⽂化として根づいていなかった＝再現性なし根本原因 ― 個⼈技に頼り、「対話」が根づいていなかった⾜りなかったのは「対話を続ける関係性」そのものだった断絶は悪意ではなく無理解から。だから次は、対話で関係性を作り直すところから始めた

Slide 23

Slide 23 text

対話と関係性の再構築

Slide 24

Slide 24 text

対話と関係性の再構築「会話」と「対話」はまるで別物観点ただ話す（会話‧雑談‧議論）「対話」⽬的要件の伝達‧その場を埋める背景‧前提（コンテキスト）の同期スタンス⾃分の主張を通す（誰が正しいか）何が正しいかをシステム思考で探る聴き⽅次に話すことを考えながら聴くなぜその⾏動をとったか、背景を聴く焦点誰のミスか（Blame）何が起きたか（Blameless＝⾮難しない）成果表⾯的な安⼼‧⼀時的な合意⼼理的安全性と、組織の学習

Slide 25

Slide 25 text

対話と関係性の再構築 • エスカレーションを受け、まず事業部⾨マネジメントと直接調整に動く • 「正しさ」や「誰のせいか」をぶつけず、なぜ‧何に困っているかを聴く • 背景‧前提を腹を割って共有＝コンテキストの同期 • 途中からインシデントコマンダーチームも巻き込み、チームで進める対話の⼟台をつくる ― まず聴き、チームを巻き込む

Slide 26

Slide 26 text

対話と関係性の再構築 • 「正しい仕組み」と「納得できる仕組み」は別物だった • 情報共有：「確証を得てから」は開発の誠実さ、CSには「遅い」 • レベル判断：技術者はシステム⾯だけ⾒て過⼩評価しがち ― 顧客業務が⽌まっている景⾊が⾒えていない • ポストモーテム：最初はお互いに遠慮して本⾳が出なかった • 繰り返し対話を重ねるうちに、率直に話せる関係＝⼼理的安全性が育った順調ではなかった ― 四苦⼋苦したこと

Slide 27

Slide 27 text

対話と関係性の再構築 • ① 情報共有：怪しい段階で、まず出す • ② レベル判断：経験者の勘を、誰でも判定できるルールに • ③ 顧客フォロー：CS連携を、最後までやりきる • ④ 対話を続ける：運⽤しながら、CSと⼀緒に直し続ける → ここからは、実際のルールで⼀つずつ対話から⼀緒に変えた4つのこと

Slide 28

Slide 28 text

対話と関係性の再構築 ① 情報共有 ― 怪しい段階で、まず出す（対話で覆った思い込み）認識のズレが、いちばんはっきり出たのが「情報を出すスピード」怪しい動きや問い合わせを、"完全に問題"と確定してから起票していたコマンダーチームの思い込み • 不正確な情報は外に出したくない • 確証を得てから伝えるべき • 曖昧なまま出すとCSに迷惑では対話で知ったCSの本⾳ • 早く動きたい ― スピードが要る • 今わかっていることを早く • 「問題なければ、それでいい」 → だから ― 怪しい段階でも、社内‧CSへはまず共有して動き出す ※顧客への通知は別 ― "調査中"だけは出さず、意味のある情報をサポート体制とセットで

Slide 29

Slide 29 text

対話と関係性の再構築 ② レベル判断 ― 経験者の勘を、再現性あるルールへ影響度 × 緊急度のマトリクスで判定 ― CSと実事例を元に基準と具体例を再定義緊急度⾼緊急度中緊急度低影響度⾼ Critical High Low 影響度中 High Low Info 影響度低 Low Info Info •影響度⾼：多数の顧客のレポート実績がズレる可能性 / 中：特定条件下の顧客のみ •緊急度⾼：機能停⽌＋代替案なし（⾮現実的な代替は不可）/ 中：代替案で対応可能 •判定後に関係者でクロスチェック ― レベルはいつでも⾒直してよい、変わればすぐ共有 → 基準は対話の出発点 ― 決めつけず対話の中で⾒直し続ける"⽣きたルール"

Slide 30

Slide 30 text

対話と関係性の再構築 • インシデント対応は「システム修正」と「顧客対応」の2本⽴て • 以前は修正のフローにばかり⽬がいき、顧客対応が抜けていた • CSの個別フォローに必要な情報を共有（必要なら追加調査も） • 全対応が完了するまで⾒届けて、はじめてクローズ ③ 顧客対応のフローを、最後までやり切る

Slide 31

Slide 31 text

対話と関係性の再構築 • ポストモーテム：CSも参加し、顧客対応の視点で改善点を上げてもらう • フロー：やり⾟ければいつでも声を上げて⾒直す ― 気になったらすぐ共有が前提 • CS業務の改善：サポートサイト周知やメール配信など、CS側の作業をヒアリングし技術者が⾃動化を提案 • 四半期ごとにCSへヒアリングし、運⽤の困り事を拾う → お互いの業務を理解し、対話を通じて協業しながら継続的に改善する関係へ ④ 対話を「続ける」― 継続的な改善のために

Slide 32

Slide 32 text

成果と根づいた⽂化

Slide 33

Slide 33 text

成果と⽂化 • 起票から数時間⾳沙汰なし → 検知から30分以内に共有‧レベル判定‧全体周知 • ⽔準‧⽬線を揃え直した ― 「凡事徹底」ができていなかったと気づけた • 組織の学習が回り出した ― 振り返って仕組みを直す • 事業部⾨（CS）の満⾜度向上も、関係者ヒアリングで確認数値だけでなく⽂化が変わりはじめた根っこは同じ ― みんな「顧客に良いサービスを」。⼩さなかけ違いを、対話で埋めていった率直にFBし合える関係に近づいてきた ― 信頼回復は道半ば、これからも続けていく

Slide 34

Slide 34 text

まとめ • 『SREをはじめよう』は、多くの⼈を巻き込み協⼒を得る重要スキルとして「ストーリーテリング」を挙げている • 対話で背景を揃え、物語として伝えることで、相⼿が"協⼒したくなる"状態をつくる対話はSREの最重要スキルスピードやルールの前にまず"対話"がある ― SREのコアスキル背景を同期し"何が起きたか"を⼀緒に探る → ⼼理的安全性と組織の学習へ繋げる

Slide 35

Slide 35 text

まとめ • 対話とは、背景を同期し、"何が起きたか"を⼀緒に探ること • 「会話」と「対話」は違う ― ⼀⽅的に伝える∕議論で勝つのは対話ではない • その積み重ねが、⼼理的安全性と組織の学習を⽣む • 仕組みは、それを動かす⼈と⼈の対話が伴って初めて機能する • 信頼性は、組織全体で対話を通じて担うものまとめ

Slide 36

Slide 36 text

まとめ • 「ちゃんとやっている」はずなのに、なぜか相⼿と⼿応えがズレる • そんなときの答えは、たぶんプロセスの外側 ― 対話の中にあります最後に「ちゃんとやっている」を、独りよがりにしないためにまず、向き合うべき⼈と対話を始めましょう

Slide 37

Slide 37 text

No content