一番の課題は、インシデント対応の手順書（Runbook）の存在がチームに十分に認知されていなかったことです。Runbook自体はNotionにまとめてあったのですが、知られている範囲が限られていたため、初動に対応できるのが状況をよく知る一部のメンバーに限られていました。

当時は誰が・どこで・何をしているのかが見えづらく、対応が属人化しやすい傾向にありました。情報も複数のチャネルに分散していて、その話は別のスレッドで進んでいたと後から気づくようなすれ違いも起きがちでした。Runbookというドキュメントがあることと、チーム全員が迷わず動けることの間には、まだ距離があったんです。

実は、かなり初期からWaroomのファンの一人でした。普段使っている別ツールのインシデント管理機能も見てはいましたが、私のなかではほぼ一択でしたね。

惹かれていたのは、インシデント対応を全社で取り組んでいこうとする思想や、SREのプラクティスに沿った対応の型が、プロダクトに反映されている点です。なかでも人数によらない課金体系は、エンジニアだけでなくCSやビジネスサイドまで巻き込む広範な体制構築を見据えると、非常に理にかなっていました。実際、CSのメンバーからも「アカウント数を気にせず連携できるのはすごくいい」と声が上がっていました。

非常にスムーズでした。トライアルで触ってもらった際もネガティブな反応はなく、「良い取り組みやツールは積極的に検証し、スピード感を持って取り入れよう」という弊社のカルチャーも後押ししました。

自社で一から同様の仕組みを構築・メンテナンスする膨大な工数や開発運用のコストを考慮すれば、最初からベストプラクティスに基づいた型が用意されているWaroomへの投資対効果は明確でした。私たちが選んだのは、固定化された完成品というよりも、自分たちの組織に合わせて柔軟に育てていける優れた土台だったと思います。

インシデントを検知、またはその兆候があった段階でWaroomで起票して専用チャンネルを作り、まずスレッドを立てます。役割分担が確定する前でも、即座に作業に入れるようにするためです。あとは、Slack上にRunbookが手順として順番に表示されるので、それに沿って進めるだけです。原因調査・顧客影響・CS向けといったトピックごとにスレッドを分け、最後の事後対応のステップではポストモーテムの開催までガイドされます。起票から振り返りまで、Runbookをたどれば一通りの適切な対応が完了する形になっています。

SlackのRunbookが、対応フローを一つずつ指示してくれる機能ですね。ここを磨けば対応フローの質自体がそのまま良くなっていくので、一番手をかけている部分です。

弊社ではこのRunbookをGitHubで管理し、AIエージェントのDevinと繋いでいます。調査そのものを任せたり、対応を効率化するプルリクエストを出してもらったりといった運用の自動化を試みています。そのためのマクロを用意して、Runbookのなかにこのコマンドを実行してくださいという形で組み込んでいます。そうすると、手順を見るだけでこのマクロを実行すればDevinが自動で調査してくれると誰でも分かります。特定の人に依存せず、チームの誰もが迅速に調査の入り口に立てるようになったのは大きな収穫ですね。

Runbook自体はWaroom標準のものをベースに、基本フローを一つに集約して自社向けに育てています。正直に言うと、この中身を自社の最適な形に作り込むのが一番苦労したところで、他社がどう作っているのかは今でもすごく知りたいくらいです。

AIとうまく組み合わせれば、フロー自体を回しながら現場で育てていける。これは当初まったく想定していませんでした。Runbookを作ったあとの持続的な運用は手探りでしたが、結果的にいいサイクルを回せていて、そこが一番よかった点です。

数値での詳細な分析はこれからですが、体感では初動から解消までのスピードが劇的に速くなりました。突発的なトラブルが発生した場合でも、多くのケースでその日のうち、半日ほどで迅速に解消できる体制が整っています。

特に大きいのは、対応が収束して終わりではなく、組織的な改善のサイクルが確実に回るようになったことです。Runbookでフローを整え、ポストモーテムで対応プロセス自体も振り返って「ここはこうすればもっと良くなる」をRunbookに落とし込んでいく。こうしてRunbookがどんどんブラッシュアップされていきます。

半分は新しく作り直した感覚です。Waroom導入と同時に、そもそもポストモーテムとは何か、定義や目的から見直しました。それまではシステム的な根本原因にしかフォーカスしていませんでしたが、障害が起きたときに「いかに迅速に対応し、影響を最小化できたか」という運用の観点もテンプレートに加えました。

開催ルールもRunbookに組み込んでいます。事後対応のステップでこの基準で開催しましょうとコマンダーに提示されるので、クローズと同時にスケジュールが設定され、1週間以内には必ず実施される状態になりました。

大きく変わりました。以前は情報が分散して作業メンバーの認知負荷が高まることがありましたが、それが解消され、一人ひとりが対応に集中できるようになっています。次に何をすべきかがRunbookで明確になったことで、私以外のメンバーも能動的に起票するようになって、「懸念があれば、まず速やかに起票して共有しよう」という流れが定着してきました。心理的なハードルは確実に下がっています。

引き続きAI活用を進めたいです。Waroom MCPと接続して自動化できる部分を増やし、人間の判断が必要な部分を減らしていければと思っています。

もう一つは、インシデントコマンダーを増やすこと。いまは横断的に見てくれているEM3名にお願いしていますが、まずそのメンバーが対応できるようになり、そこから各チームのリーダーへ広げていきたいです。CSとの連携など、まだ巻き込みきれていない部分も育てている途中です。

これから作っていく企業なら、もう導入しない手はないと思っています。ひとつだけお伝えしたいのは、導入はゴールではなくスタートだということ。対応フローをブラッシュアップするフィードバックループをどう作るか、そこを意識してもらえればと思います。