kubell Creator's Note

株式会社kubellのエンジニアのブログです。

ビジネスチャット「Chatwork」のエンジニアのブログです。

読者になる

損失コストを減らす!インシデント対応の「4つのタイムスパン」可視化戦略

この記事は、kubell Advent Calendar 2025(シリーズ 2)の12日目の記事です。

こんにちは。QAエンジニアの稲垣です。

突然ですが、質問です。

  • インシデントが発生した場合の損失コストがどれくらいかご存知ですか?

  • あなたのチームではインシデントが発生した場合、どうように対応をしていますか?

私が入社当初から関わっているインシデント障害対応改善委員会では、インシデント対応の継続的な改善活動を行っています。 本記事では、その取り組みの一部をご紹介します。

ビジネスチャット「Chatwork」においてインシデント対応が重要な理由

私が携わっているビジネスチャットの「Chatwork」は、業種や職種問わず、全従業員が業務時間中を通して使い続けるという特性を持っているため、24時間365日止めることができません。

また、最もBPaaSしやすいビジネスチャットへと進化すべく、機能の追加や強化が進められており、単なるコミュニケーションツールにとどまらず、今後ますます、ビジネスを支える”インフラ”と言っても過言ではないサービスになっていくと考えています。

出典: kubell会社説明資料

このようなサービスにおいて、システム停止など重大なインシデントが発生した場合、お客様には多大なご迷惑をおかけすることになりますし、そこにかかるコストも計り知れないものがあります。

深刻なシステム停止が発生した場合の損失コストをご存知ですか?

深刻なシステム停止が発生した場合、1時間あたりの損失コストの中央値は200万ドルに上り、システムが復旧するまで1分ごとに約3万3,333ドルが失われています。調査対象企業において、深刻なITシステム停止により失われる年間コストの中央値は7,600万ドルに達しました。

出典: New Relic「2025年オブザーバビリティ予測レポート」

日本円に換算した場合 (1ドル=155円換算、2025年12月時点)

時間単位 損失コスト
1分 約517万円
1時間 約3億1千万円
1日 約74億円

この数字は、インシデント対応の迅速性がいかに事業に直結するかを物語っています。

私たちの取り組みのご紹介

委員会のMissionは「お客様に安心してご利用いただき、インシデントによる事業への機会損失を減らすこと」と掲げています。

今回は、私たちが取り組んでいる、インシデントが発生した場合のインシデント対応フローの改善についてご紹介します。

DORAが提唱する「Four Keys」(デプロイ頻度、変更リードタイム、変更失敗率、サービス復元時間)を計測しているチームは多いと思いますが、私たちは少し違った視点からアプローチをしています。

具体的には以下のデータを記録しています。

  • 発生日時
  • 検知日時
  • 社内初期広報実施日時
  • ユーザー告知実施日時
  • 障害復旧日時

また、定量的にモニタリングできるように、以下の「タイムスパン」を計測・改善のKPIとしています。

  • 発生日時 → 検知日時
    • 「いかに早く問題に気づくか」の指標
    • モニタリング体制やアラートの精度を評価
  • 検知日時 → 社内初期広報実施日時
    • 「いかに早く関係者に情報が連携できるか」の指標
    • 情報連携プロセスの迅速性を評価
  • 社内初期広報実施日時 → ユーザー告知実施日時
    • 「いかに早くお客様に状況を正確に伝えられるか」の指標
    • 広報判断の迅速性を評価
  • ユーザー告知実施日時 → 障害復旧日時
    • 「いかに早くサービスを正常に戻せるか」の指標
    • 復旧体制とエンジニアリング力を評価

これにより、以下ができるようになりました。

  1. どのフェーズがボトルネックなのか特定できる
  2. 改善施策の効果を定量的に測定できる
  3. 技術的な復旧だけでなく、情報伝達や広報のスピードも可視化できる

上記の指標を注視し、課題のありそうなインシデント対応フロー箇所を発見し、改善を繰り返していくことで、タイムスパンが短縮すれば、委員会のMissionである「お客様に安心してご利用いただき、インシデントによる事業への機会損失を減らすこと」ができている状態と言えると考えています。

クロスファンクショナルなメンバー構成の理由

委員会のメンバーは、SRE、Dev、PdM、QAなど様々な職能から集められています。 必要に応じて、ビジネスサイド、サポート、広報に協力いただくこともあります。 これは、技術的な復旧だけでない視点を取り入れるためです。

インシデント対応は開発者だけで完結するのではなく、広報やサポート部門なども含めた全社的な活動として捉えることが極めて重要だと考えています。

なぜなら、技術的な復旧作業と並行して

  • お客様への初期広報を迅速かつ正確に実行すること
  • お客様からの問い合わせに一貫性のある情報で対応すること

これらが適切に連携されることで、お客様の不安を最小限に抑え、信頼の低下を防ぐことにつながるからです。

最後に

インシデントは「発生しないようにする」ことも勿論重要ですが 「発生した時にいかに迅速に対応するか」も同じくらい重要です。

あなたのチームでは、インシデント対応のどのフェーズに時間がかかっているか 把握できていますか?

まずは現状を可視化することから始めてみてはいかがでしょうか?

本記事が、あなたのチームの信頼性向上への取り組みを考える一助となれば幸いです。