こんにちは。Topotal セールスの my-zt です。
前回の記事では、Waroom のオンコール機能を使ってインシデントに「気づく」体制の作り方をご紹介しました。第 1 回では属人化の解消、第 2 回では対応フローの標準化についても解説しています。
ツールの機能や流れは理解できた。でも、実際にチームに定着させるのが難しい──こうした声は、現場でもよく聞こえてきます。
今回は、インシデント対応フローを仕組みとして組織に根付かせるまでの過程で起きやすい壁と、その越え方について解説していきたいと思います。
ツールを入れただけでは、フローは動かない
インシデント管理ツールを導入した直後、最初にぶつかりやすいのがツールはあるのに使われないという状況です。
インシデントが発生しても、これまでの習慣でいつもの Slack チャンネルにメッセージを投げてしまう。新しいツールへの起票を忘れ、対応が終わってから遡って登録する。こういったことは珍しくないかと思います。
これはツールの問題というより、行動のパターンを変えることの難しさです。インシデント対応のような緊張した場面では特に、慣れ親しんだやり方に戻りやすくなります。
この課題に対して効果的なことは、リードエンジニアや SRE が率先してツールを使い続けるというシンプルなアプローチです。担当者が毎回起票し続けることで、チームに少しずつインシデントが起きたらまずツールに起票するという流れが浸透していきます。
心理的ハードルを下げる：Runbookが果たす役割
フロー定着の障壁としてもうひとつよく挙がるのが、心理的ハードルです。
インシデントを起票するという行為には、大げさかもしれない、自分が起票していいのかという迷いが伴うことがあります。特にエンジニア以外のメンバーにとっては、インシデント対応そのものへの参加ハードルが高く感じられることがあります。
この課題を緩和するために有効なのが、対応手順の明示です。インシデントが起票されたタイミングで、次に何をすべきかが自動的に示される仕組みがあると、初めて対応に参加するメンバーでもとりあえずこの手順に沿って動けばいいという安心感が生まれやすくなります。
Waroom では Runbook がこの役割を担います。インシデントが起票されると、サービスや重大度に応じた対応手順がチャンネルに自動展開されます。導入後に自分以外のメンバーも起票するようになった、以前より気軽にインシデントを報告できるようになったという変化が生まれやすくなります。
Topotal の Waroom を導入中のお客様からも以下のような変化を実感されております。
「次に何をすべきかが Runbook で明確になったことで、私以外のメンバーも能動的に起票するようになって、『懸念があれば、まず速やかに起票して共有しよう』という流れが定着してきました。心理的なハードルは確実に下がっています。」
詳しくは Hubble 様の導入事例をご覧ください。
誰がコマンダーかを明確にすることの効果
フローが動き始めても、対応が混乱しやすい場面があります。それが誰が判断するのかわからないという状況です。
複数のメンバーが同時に動いているとき、判断の軸となる人が不明確だと、対応の重複や抜け漏れが生じやすくなります。コマンダーを明確にすることは、単なる役割分担以上の意味を持ちます。
Waroom では /waroom role assign commander @slack_username でコマンダーをアサインできます。チャンネルの全員にコマンダーが伝わることで、各メンバーが判断を仰ぐ先がわかり、対応がスムーズに進みやすくなります。
コマンダーの役割を最初から全員に広げる必要はありません。まず特定のメンバーがコマンダーを担い、対応に慣れてきたタイミングで徐々に担える人を増やしていくというステップが、現場での定着に向いています。
以前、Waroom のバックエンドエンジニア 高谷@nerdyboy_coolが投稿した、ブログも合わせてご確認ください。
情報を一箇所に：対応の質を高める集約のすすめ
フローが定着してくると、次に見えてくるのが情報の散在という課題です。
対応の途中でさまざまな情報がやり取りされますが、それが複数のチャンネルやスレッドに分散してしまうと、後から合流したメンバーが状況を把握しにくくなります。また、対応が終わった後にあのとき何を確認したかを振り返ろうとしても、情報を探し直すのに時間がかかります。
対応専用のチャンネルに情報を集約することで、この問題を緩和できます。さらに、チャンネル内でのやり取りをトピックごとにスレッドで整理する運用と組み合わせると、原因調査・顧客影響確認・CS 対応など、それぞれの流れが見やすくなります。
Waroom ではチャンネル内のやり取りを AI がリアルタイムで取り込み、インシデントの状況を自動で整理・集約するため、誰かが記録係を担わなくても情報が蓄積されていきます。
フローを "使い続けるもの" にするために
フローが一度定着しても、それで終わりではありません。実際に運用していく中で、手順の抜けや改善点が見えてきます。
重要なのは、気づいた改善点をその都度対応手順に反映していくサイクルを作ることです。インシデントが起きるたびに手順を見直し、次の対応に活かせる状態を保つことで、フロー全体がブラッシュアップされていきます。
Waroom のポストモーテム機能では、対応後の振り返りを構造化して記録し、次のインシデント対応に活かせる仕組みを提供しています。詳細な活用方法は次回の記事で解説します。
まとめ
インシデント対応フローを仕組みとして定着させるためには、ツールの導入だけでなく、行動のパターンを変えていくプロセスが必要です。これはインシデント管理ツール全般に共通する話であり、Waroom においても同様です。
- まず率先してツールを使い、チームに流れを作る
- 対応手順を明示し、心理的ハードルを下げる
- コマンダーを明確にし、判断の軸を作る
- 情報を専用チャンネルに集約し、対応の質を高める
- 気づいた改善点を手順に反映し、サイクルを回す
これらが積み重なることで、特定のエンジニアに依存しない対応基盤が少しずつ形になっていきます。
インシデント対応のお悩みや、デモンストレーションをご希望の方は、こちらからお申し込みください👇
アナウンス
Waroom オンコール機能リリースキャンペーン実施中🎉
connpass での友達登録でイベント開催情報をゲット🗓️
オンライン/オフラインイベントを予定してますので、ぜひご登録をお願いします〜 topotal.connpass.com
