弊社は創業から順調に事業が成長し、プロダクト開発に関わる開発メンバーだけでなく、アカウントマネージャーやカスタマーサクセスなど、関係者が急激に増えていきました。

一方で、インシデント対応は全員が利用する対応マニュアルこそあるものの、創業当時からシステムを熟知しているエンジニアに頼ってしまう状況が続いていました。熟練者に依存することで、他のメンバーがインシデントの影響を把握しにくかったり、インシデント対応の習熟度にばらつきが出たりといった課題がありました。

はい。これらの課題を解決するために、インシデント対応のプロセスを整備し、誰でも対処できる環境を作っていく必要があると考えました。実際、インシデント対応のマニュアル自体はすでにありましたが、十分に活用されている状態ではありませんでした。

マニュアルがあるだけではなく、インシデント対応の中で自然に使われる状態を作る必要がある。そう考えて、インシデントマネジメントサービスを探し始めた中で、Waroomと出会いました。

当初、監視システムとして導入していたサービスのインシデント管理機能を検討しました。情報集約の観点では魅力的でしたが、最終的にWaroomを選びました。

Waroomを選定した理由は、大きく2つあります。1つは、インシデント対応プロセスの標準化を定着させられること。もう1つは、組織全体で活用できることです。

まず、1つ目の標準化についてです。誰もが同じインシデント対応を進められる状態にするために、インシデント対応の全体の流れを定義し、アラートがきたら何をするのか、重大度に応じて誰を招集するのか、招集後にどのように調査を進めるのか、といった具体的な手順を明確にしました。加えて重要なのは、定義した手順が資料として存在するだけでなく、実際の対応の中で継続的に実行されることです。

この継続的に実行される状態を作るうえで、WaroomのRunbookが有効でした。WaroomのRunbookを利用すれば、インシデント対応で切羽詰まった状況でも「今やるべきこと」が提示され、実行すると次のアクションが自動的に示されます。これによって、インシデント対応者が今やることを理解できる状態になり、再現性を持ってインシデント対応を進められるようになりました。

もう1つは、組織全体で活用できることです。弊社は経営に関わるデータを扱っており、インシデントがお客様に与える影響は重大になることもあります。そのため、インシデント対応ではエンジニアだけでなく、CSや営業、場合によっては経営層も巻き込む必要があります。全社で使う前提だからこそ、ユーザー数や部門ごとの利用状況を気にしながら運用するのは現実的ではありません。Waroomは組織単位でのシンプルな課金体系だったため、ユーザー数を気にせず、必要な関係者を自然に巻き込める点がフィットしました。

標準化を定着させられること、そして全社で活用できること。この2点を理由に、Waroomの導入を決定しました。

実際に運用してみて一番大きいのは、インシデント対応のいまの状態が見えるようになったことで、周囲が困らなくなったことです。

これまでは、インシデントコマンダーやレスポンダーが誰で、いま何が起きていて、どこまで進んでいるのかが周囲から見えにくく、状況確認が必要になる場面が多くありました。結果として、「いまどうなっていますか？」という問い合わせが発生しやすく、対応側も説明に追われたり、関係者側も判断に迷ったりしがちでした。

Waroom導入後は、対応に関する情報が集約され、現状のステータスが把握しやすくなりました。誰が担当していて、いまどの段階にあるのかが見えることで、状況確認のためのコミュニケーションが減り、対応者が作業に集中できる環境になりました。

加えて、対応が「収束させて終わり」になりがちだったところから、Waroomを前提にインシデント対応の型を作れたことで、対応プロセスを見直し、改善していくための土壌も整ってきています。

まずは、今回構築したガードレールの上で、改善のサイクルを回し続けることです。

そして、今後立ち上がる新規プロダクトに対しても、組織全体で構築し、既存事業で確立したインシデント対応の型を、新しい事業部にも横展開していきたいと考えています。

また、Waroomには影響調査と原因調査を並行して進められるようなワークフローの分岐機能など、より高度なインシデント管理への対応も期待しています。今後もパートナーとして、弊社の成長を支えていただけることを楽しみにしています。