Slackとkickflowを使ったインシデント管理の仕組み

はじめに

これは株式会社TimeTree Advent Calendar 2025 の13日目の記事です。

こんにちは。株式会社TimeTreeで COSO (Chief Organizational System Officer) という、組織OSを作る仕事をやっている @lazy です。

組織OSとは、会社を組織的にパフォーマンスさせるための仕組みのことで、目標管理の仕組みや会議体、意思決定フロー、企業文化などが含まれます。

会社が成長すると、会社で発生するインシデントをどのように把握し、適切に対処し、再発防止の動きを取っていくか といったインシデント管理プロセスを備えていく必要が出てきます。

今回は、TimeTreeで運用しているSlackとkickflowを使ったインシデント管理の仕組みについて紹介します。

背景と課題

会社が成長するにつれて、インシデントの発生頻度や種類も増加していきます。そのような状況において、インシデント管理では以下のようなことが求められるようになります。

• インシデントの把握: 会社全体でどのようなインシデントが発生しているのか、それぞれがどのようなステータスにあるのかを把握できること
• 適切な対応の促進: 対応中のインシデントに対して、適切な対応が取れるように働きかける仕組みがあること
• 記録の管理: インシデント対応の時系列や振り返りを適切に記録し、証跡として残せること

特に、監査対応を意識した証跡管理が重要になってきます。対応記録は証跡として残しやすいシステムで実施することが求められます。

TimeTreeでは以前からインシデント対応ガイドラインをもって運営してきましたが、全社的なステータス管理については属人的な部分が残っていました。そこで、今後組織拡大しても問題なく運用できるよう、仕組みのアップデートを行いました。

解決方針

上記の背景を踏まえ、TimeTreeでは以下のような解決方針を取っています。

• インシデントの一覧管理と可視化

  TimeTreeでは以前から、発生しているインシデントに対してそれぞれSlackの個別チャンネル（#incident-* のようにprefixを付与）を作成する運用を行っています。
  インシデントを1つの管理簿で可視化する際にはGoogleスプレッドシートを利用しますが、この個別チャンネルをキーにしてインシデントを区別し、ステータス管理しています。

• 対応状況の監視と促進

  インシデントのステータスに応じて、Slack BOTから定期的に次に取るべきアクションについて働きかけを行うことで、インシデント対応の放置を防ぎます。
  インシデント対応中でもスムーズにステータスが変更できるようにするため、Slack BOT経由でステータス変更が可能です。（クローズの際は後述のワークフローを利用）

• 記録の管理と証跡化

  インシデント対応の時系列や振り返りは、対応中に情報集約のため記録しつつ、報告書として利用できるようフォーマット化しています。その報告書をベースに、インシデントをクローズする際には適切な責任者に確認を依頼し、クローズを行います。確認プロセスの記録は、監査対応を想定してワークフローシステムを利用して行います。

システム構成

解決方針を実現するために、Slack、kickflow、GAS、Googleスプレッドシートを組み合わせてインシデント管理の仕組みを構築しました。

Googleスプレッドシート

インシデントの一覧管理と可視化は、Googleスプレッドシートで実現しています。

スプレッドシートには以下のような情報を管理しています。

• インシデントID
• 起票日時
• ステータス（対応中、一次対応完了、対応不要、再発抑止完了など）
• 概要
• 完了日時
• 報告ワークフローリンク
• 詳細ドキュメントリンク

このスプレッドシートが、インシデント管理の 単一の情報源（Single Source of Truth） として機能しています。

Slack BOT

個別Slackチャンネルのコミュニケーションを活かしながらインシデント管理を実現するため、「インシデント対応ガイドくん」BOTを実装し、活用しています。

■チャンネル作成と自動同期
Slackのチャンネルが作成され、BOTが追加されると、管理簿（スプレッドシート）に自動同期されます。パブリックチャンネルでインシデントチャンネルを作成した場合、BOTも自動的に追加されるため、手動での操作は不要です。

■BOTの機能
このBOTを招待することで、インシデント管理に関する以下の機能が有効になります。

• 一次対応完了時のスプレッドシートへのステータス反映
• 定期リマインド
• インシデントクローズ報告ワークフロー完了時のSlack通知
  これらの処理はすべて、後述のGASで実装されています。

kickflow

記録の管理と証跡化の一環として、発生済みのインシデントをクローズする際にkickflowを利用します。

インシデントのクローズ申請には、適切な責任者による承認フローも含まれます。クローズするまでの確認プロセスの記録は、監査対応において必要となるため、稟議等のワークフローシステムとして採用しているkickflow上で実現しています。

Google Apps Script (GAS)

対応状況の監視と促進、およびkickflowとの連携を実現するため、GASを活用して以下の処理を自動化しています。

■定期リマインド
インシデント対応が放置されないよう、クローズしていないインシデントチャンネルには定期リマインドを実施します。

• 対応中のとき: 定期的に進捗確認を促すリマインド
  

• 一次対応完了のとき: 再発防止策の実施状況を確認するリマインド
  

■kickflowクローズ申請完了時の処理
kickflowのクローズ申請が完了した際に、kickflowからのwebhook通知をトリガーにGASで処理を実行しています。

• スプレッドシートのステータスを書き換え
• Slackでクローズを通知
  

今後改善したいこと

この取り組みにより、Slackやkickflowでのアクションをトリガーにして、インシデントのステータス管理を行う仕組みが実現できるようになりました。そのためインシデント「管理」という意味では課題がクリアになっています。
しかし、インシデント「対応」全体をスムーズに実行していくためには、改善できるポイントは多いと考えています。

例えば、以下のようなポイントが挙げられます。

• インシデントを挙げる基準
• 対応レベルの判断
• いつ何をすべきかの対応指針
• 最新の状況をすぐ取得しやすくする仕組み

これらはガイドラインとしてドキュメント整備していますが、それでも有事の際にスムーズに対応を行うには十分ではありません。一般的には定期的なインシデント訓練などが用いられますが、上記のSlack BOTとAIを利用して、担当者を随時ガイドラインに沿ってナビゲートするなども今後実践していきたいと考えています。

まとめ

今回は、TimeTreeで運用しているSlack、kickflow、GAS、Googleスプレッドシートを組み合わせたインシデント管理の仕組みについて紹介しました。

この仕組みにより、属人化することなく組織的にインシデント管理ができるようになりました。特に、監査対応を意識した証跡管理と自動化による運用負荷の軽減が大きなポイントとなっています。
同様の課題を抱えている組織の参考になれば幸いです。