ITチーム向けインシデント管理アプリ：ワークフローからポストモーテムまで

内部向けインシデントアプリが実際に解決する問題

障害が発生すると、多くのチームは開いているものに手当たり次第頼ります：チャットスレッド、メールのやり取り、あるいは誰かが空いた時間に更新するスプレッドシート。プレッシャーがかかると、その仕組みは毎回同じように崩れます：所有権が曖昧になり、タイムスタンプが失われ、意思決定がスクロールの彼方に消えます。

シンプルなインシデント管理アプリは基本を解決します。インシデントが1カ所にまとまり、明確なオーナー、全員が合意する重大度、いつ何が起きたかのタイムラインが残ります。その単一の記録が重要なのは、どのインシデントでも同じ質問が出るからです：誰がリードしているのか？いつ始まったのか？現在の状況は？既に試したことは何か？

共有レコードがなければ、引き継ぎで時間が無駄になります。サポートは顧客にあることを伝え、エンジニアリングは別の対応をしている。マネージャーは更新を求めて対応者の手を止めてしまう。あとで誰も自信を持ってタイムラインを再現できず、ポストモーテムは推測に頼るものになります。

目的は監視やチャット、チケットを置き換えることではありません。アラートは他の場所から始まっても構いません。重要なのは意思決定の軌跡を記録し、人間の連携を保つことです。

IT運用やオンコールエンジニアは対応の調整に使います。サポートは正確な更新を素早く出すために使います。マネージャーは対応者を邪魔せずに進捗を確認できます。

例：P1障害のアラートからクローズまで

9:12 AMに監視がカスタマーポータルの500エラーの急増を検出します。サポート担当からも「多くのユーザーでログイン失敗」と報告が入ります。オンコールのITリードがインシデントアプリでP1インシデントを作成し、最初のアラートとサポートのスクリーンショットを添付します。

P1だと振る舞いが速く変わります。インシデントオーナーはバックエンドの担当、データベース担当、サポートのリエゾンを招集します。非必須作業は停止し、計画済みのデプロイも止めます。チームは更新の頻度（例：15分ごと）に合意します。共通の通話が始まっても、インシデントの記録が唯一の真実の場です。

9:18 AMに「何が変わった？」という質問が出ます。タイムラインには8:57 AMのデプロイが記録されていますが、何がデプロイされたかは書かれていません。バックエンド担当はとりあえずロールバックします。エラーは減少し、再び戻ります。チームはデータベースを疑い始めます。

遅延の多くは予測できる場所に現れます：曖昧な引き継ぎ（「それを見ていると思ってた」）、文脈の欠如（最近の変更、既知のリスク、現在の担当者）、チャットやチケット、メールに散らばった更新。

9:41 AMにデータベース担当がスケジュールされたジョブによる暴走クエリを発見します。ジョブを無効化し、影響を受けたサービスを再起動して復旧を確認。重大度は監視のためP2に下げられます。

良いクローズとは「直った」だけではありません。きれいな記録です：分単位のタイムライン、最終的な根本原因、誰がどの決定をしたか、何が一時停止されたか、オーナーと期日付きのフォローアップ作業。こうしてストレスフルなP1が繰り返しの痛みではなく学びになります。

データモデル：それで足りる最小限の構造

良いインシデントツールは主に良いデータモデルです。レコードがあいまいだと、インシデントが何か、いつ始まったか、何が未解決かで議論になります。

コアのエンティティはITチームが既に話している形に近づけてください：

• Incident（インシデント）： 起きた事象のコンテナ
• Service（サービス）： ビジネスが稼働させているもの（API、データベース、VPN、課金）
• User（ユーザー）： 対応者やステークホルダー
• Update（更新）： 時系列の短いステータスノート
• Task（タスク）： インシデント中（および後）の具体的作業
• Postmortem（ポストモーテム）： インシデントに紐づく1つの報告書とアクション項目

後で混乱を避けるために、インシデントには常に埋められる構造化フィールドをいくつか用意してください。フリーテキストは役立ちますが、それだけに頼ってはいけません。実用的な最小項目は、明確なタイトル、影響（ユーザーが何を体験しているか）、影響を受けるサービス、開始時刻、現在のステータス、重大度です。

関係性は余計なフィールドより重要です。1つのインシデントは多数の更新と多数のタスクを持ち、サービスとは多対多でリンクします（障害は複数システムに影響することが多いため）。ポストモーテムはインシデントと1対1にして、最終的なストーリーを1つにします。

例："Checkout errors" のインシデントはサービス「Payments API」と「PostgreSQL」にリンクし、15分ごとの更新があり、「ロールバック」「リトライガード追加」などのタスクがあります。後でポストモーテムに根本原因がまとめられ、長期タスクが作られます。

重大度レベルと対応目標

人がストレスを受けているときには、全員が同じ意味で理解できる単純なラベルが必要です。P1〜P4を平易な言葉で定義し、重大度フィールドのすぐ横に定義を表示してください。

• P1（重大）： コアサービスがダウン、またはデータ損失の可能性。多くのユーザーが利用不能。
• P2（高）： 主要機能が壊れているが回避策があるか、影響範囲が限定的。
• P3（中）： 緊急性低め、小グループが影響を受け、ビジネス影響は小さい。
• P4（低）： 見た目や軽微なバグ、後回しでよい。

対応目標はコミットメントのように読めるようにします。単純な基準（実情に合わせて調整）：

エスカレーションルールは機械的にしておくとよいです。P2が更新頻度を逃したり影響が拡大したら、システムが重大度の再評価を促すべきです。混乱を避けるために、重大度を変更できるのは限定された人（多くはインシデントオーナーやインシデントコマンダー）にしつつ、誰でもコメントでレビューを依頼できるようにします。

インパクトマトリクスを用意すると重大度を素早く決められます。必要項目として：影響ユーザー数、収益リスク、安全性、コンプライアンス／セキュリティ、回避策の有無を捕捉します。

ストレス時に人を導くワークフロー状態

インシデント中に人々が必要なのはオプションの多さではなく、次に何をすべきかが明確になる少数の状態です。

普段うまくいっているときの手順から始め、リストは短く保ってください。状態が6〜7個以上になると、チームは文言の議論を始めてしまい、本来の問題解決が進みません。

実用的なセット：

• New（新規）： アラート受信、まだ確認されていない
• Acknowledged（受領）： 誰かが所有をセットし、最初の応答を開始
• Investigating（調査中）： 影響の確認、有力原因の絞り込み
• Mitigating（緩和中）： 影響を減らすためのアクション実施中
• Monitoring（監視中）： サービスが安定しており再発を監視
• Resolved（解決）： サービスが復旧し、レビュー準備完了

各ステータスには明確な入出条件を設けます。例えば：

• オーナーが設定され、次のアクションが一文で書かれていないとAcknowledgedに移せない。
• 少なくとも1つの具体的な緩和タスク（ロールバック、機能フラグオフ、キャパシティ追加）がないとMitigatingに移せない。

遷移で人が忘れがちなフィールドを強制してください。一般的なルール：短い根本原因要約と最低1件のフォローアップがないとインシデントを閉じられない、という具合です。“RCA: TBD”を許すと、そのまま残りがちです。

インシデントページは一目で次の3つに答えられるべきです：誰が担当か、次のアクションは何か、最後の更新はいつか。

割り当てとエスカレーションルール

インシデントが騒がしいときに時間を失う最速の方法は曖昧な所有権です。アプリは1人を明確に責任者にしつつ、他の人が手を貸しやすくすべきです。

単純で有効なパターン：

• Primary owner（主要オーナー）： 対応を主導し、更新を投稿し、次の手を決める
• Helpers（支援者）： タスクを引き受け（診断、ロールバック、広報など）、報告する
• Approver（承認者）： リスクのある操作を承認できるリード

割り当ては明示かつ監査可能にします。誰がオーナーを設定したか、誰が承認したか、以降の変更履歴を追跡してください。“Accepted（受諾）”は重要です。誰かを割り当ててもその人が寝ていたりオフラインだと実際の所有権になりません。

オンコール割り当てとチームベース割り当ては重大度で使い分けるとよいです。P1/P2ではオンコールのローテーションをデフォルトにして必ず名前がつくようにします。低い重大度ではチームベースで問題ありませんが、短時間で1人の主要オーナーを必須にしてください。

休暇や障害を人のプロセスだけでなく仕組みでも扱う計画を立ててください。割り当てられた人が不在設定なら、セカンダリのオンコールやチームリードに自動ルーティングします。自動化しつつも修正が見えるようにしてください。

エスカレーションは重大度と沈黙の両方で発火させます。出発点として有用な例：

• P1： 5分以内にオーナー受諾がなければエスカレーション
• P1/P2： 15〜30分で更新がなければエスカレーション
• 任意の重大度： 状態が目標応答時間を超えて"Investigating"のままならエスカレーション

タイムライン、更新、通知

良いタイムラインは共有の記憶です。インシデント中は文脈がすぐ失われます。適切な瞬間を1カ所に記録すれば、引き継ぎが容易になり、ポストモーテムは誰かがドキュメントを開く前にほぼ書かれた状態になります。

タイムラインが捕らえるべきもの

タイムラインは意見を持たせてください。チャットログにしてはいけません。多くのチームは検知、受領、主要な緩和ステップ、復旧、クローズのような少数のエントリを頼りにします。

各エントリにはタイムスタンプ、作成者、短い平易な説明が必要です。遅れて参加した人が5件読めば状況を理解できるべきです。

明確さを保つ更新タイプ

異なる更新は異なる対象に向いています。エントリにタイプを持たせると便利です（内部メモ（生の詳細）、顧客向け更新（表現を安全にしたもの）、決定（なぜ選んだか）、引き継ぎ（次の人が知るべきこと）など）。

リマインダーは個人の好みではなく重大度に従わせます。タイマーが鳴ったらまず現在のオーナーに通知し、それでも繰り返し無視されればエスカレーションします。

通知は対象を絞り、予測可能にします。作成時、重大度変更時、復旧時、更新の期限超過時に通知する小さなルールセットで十分です。全社に毎回通知するのは避けてください。

実際にフォローが進むポストモーテム

ポストモーテムには2つの仕事があります：平易な言葉で何が起きたかを説明すること、そして同じ故障が再発しにくくすること。

書き出しは短くし、アウトプットをアクションに強制してください。実用的な構成は：要約、顧客影響、根本原因、実施した修正、フォローアップです。

フォローアップが要点です。段落で終わらせないでください。各フォローアップを担当者と期日付きの追跡タスクに変えてください。たとえ期日が「次のスプリント」でも構いません。それが「監視を改善すべき」から「Alexが金曜日までにDB接続飽和のアラートを追加する」への違いです。

タグは後でポストモーテムを有用にします。各インシデントに1〜3個のテーマを追加してください（監視の穴、リリース、キャパシティ、プロセスなど）。1か月後には多くのP1がリリース由来かアラート不足由来かといった基本的な問いに答えられます。

証拠は添付しやすく、必須にしないでください。スクリーンショット、ログスニペット、外部システムへの参照（チケットID、チャットスレッド、ベンダーのケース番号）を任意で添付できるようにして、軽量に保ち、人が実際に記入するようにします。

ステップバイステップ：1つの内部アプリとしてミニシステムを構築する

これはスプレッドシートに列を増やしただけのものではなく、小さなプロダクトとして扱ってください。良いインシデントアプリは実際に3つのビューで構成されます：今何が起きているか、次に何をするか、そして後で何を学ぶか。

プレッシャー下で人が開く画面をスケッチすることから始めます：

• Queue（キュー）： フィルタ付きのオープンインシデント（Open、Needs update、Waiting on vendor、Closed）
• Incident page（インシデントページ）： 重大度、オーナー、現在のステータス、タイムライン、タスク、最新の更新
• Postmortem page（ポストモーテムページ）： 影響、根本原因、アクションアイテム、担当者

データモデルと権限設定を同時に作ってください。誰でも全部を編集できると履歴が乱れます。一般的なアプローチは：ITには広い閲覧権限、ステートや重大度の変更は制御、対応者は更新を追加でき、ポストモーテム承認には明確なオーナーがいること。

次に半端なインシデントを防ぐワークフロールールを追加します。必須フィールドは状態に依存させます。"New"ならタイトルと報告者だけでよいが、"Mitigating"には影響の要約を必須にし、"Resolved"には根本原因の要約と最低1件のフォローアップを必須にする、といった具合です。

最後に過去のインシデント2〜3件を再現してテストします。1人がインシデントコマンダー役、1人がレスポンダー役を演じます。どのステータスが不明瞭か、どのフィールドを飛ばすか、どこにデフォルトが必要かがすぐ見えてきます。

よくある失敗と回避法

多くのインシデントシステムが失敗する理由は単純です：ストレス下でルールを覚えられない、アプリが後で必要な事実を捕らえない。

失敗1：重大度やステータスが多すぎる

6つの重大度や10の状態があると人は推測します。重大度は3〜4に抑え、状態は次に何をすべきかに集中させてください。

失敗2：単一オーナーがいない

誰もが“見ている”だけだと誰もそれを進めません。インシデントが前に進む前に必ず1人の名前付きオーナーを要求し、引き継ぎは明示的にしてください。

失敗3：信頼できないタイムライン

"いつ何が起きたか"がチャット履歴頼みだとポストモーテムが議論になります。開いた、受領、緩和、解決のタイムスタンプを自動取得し、タイムラインエントリは短く保ってください。

また曖昧な根本原因メモ（"ネットワークの問題"）で閉じるのは避けてください。明確な根本原因の一文と少なくとも1件の具体的な次ステップを要求します。

ローンチチェックリストと次のステップ

全IT組織に展開する前に基本をストレステストしてください。最初の2分で適切なボタンが見つからなければ、人はチャットやスプレッドシートに戻ります。

短めのローンチチェックに注力します：役割と権限、明確な重大度定義、所有権の強制、リマインダールール、応答目標未達時のエスカレーション経路。

まずは1チームと頻繁にアラートが出る数サービスでパイロットを行い、2週間運用して実際のインシデントに基づき調整してください。

もしスプレッドシートや別アプリをつなぎ合わせずに単一の内部ツールとして構築したければ、AppMaster (appmaster.io) は一つの選択肢です。データモデル、ワークフロールール、Web/モバイルのインターフェースを一箇所で作れるので、インシデントキュー、インシデントページ、ポストモーテム追跡にうまく合います。