2025年11月06日·2 分
インシデント追跡とポストモーテムのためのウェブアプリを構築する方法
ワークフロー設計からデータモデル、UXまでを含む、インシデント追跡とポストモーテム用ウェブアプリを設計・構築・リリースするための実践的なブループリント。
ワークフロー設計からデータモデル、UXまでを含む、インシデント追跡とポストモーテム用ウェブアプリを設計・構築・リリースするための実践的なブループリント。
画面設計やデータベース選定の前に、チームが「インシデント追跡ウェブアプリ」と「ポストモーテム管理」で何を達成したいかを揃えてください。同じ言葉でもチームごとに意味が違うことが多いです：あるチームではインシデントは顧客報告の問題全般を指し、別のチームではオンコールのエスカレーションを伴うSev-1の障害のみを指すかもしれません。
短い定義で次に答えられるようにします：
この定義がインシデント対応ワークフローを決め、アプリが厳しすぎて誰も使わない／緩すぎてデータが不整合になるのを防ぎます。
組織でポストモーテムが何を意味するかを決めます：すべてのインシデントに対する簡易サマリか、高重大度のみの詳細なRCAか。目的を明確にしてください（学習、コンプライアンス、再発防止、または複数）。
有用なルール：ポストモーテムから変化を期待するなら、ドキュメント保存だけでなくアクションアイテム追跡をサポートする必要があります。
多くのチームは次のような繰り返す痛点を解決するためにこの種のアプリを作ります：
このリストを絞り、追加する機能は少なくとも一つの問題に紐づくようにします。
アプリのデータモデルから自動計測できる指標をいくつか選びます：
これらが運用指標となり、最初のリリースの“完了定義”になります。
同じアプリがオンコール運用の異なる役割に使われます：
v1では全員を同時に満足させようとするとUIが散らかります。まずは主なユーザーを1つ選び、他のユーザー向けには後でビューやダッシュボード、権限で対応できるようにします。
明確なワークフローは2つの一般的な失敗を防ぎます：次に何をすべきか誰も分からずインシデントが停滞する、あるいは表面的に「完了」になっても学びが生まれない、という状態です。まずライフサイクルを端から端までマッピングし、各ステップに役割と権限を紐づけます。
多くのチームはシンプルな流れに従います：検知 → トリアージ → 緩和 → 解決 → 学習。アプリは無限のオプションメニューではなく、予測可能な少数のステップでこれを反映すべきです。
各段階で何をもって「完了」とするか定義してください。例えば、緩和は根本原因が不明でも顧客影響が止まったことを意味するかもしれません。
人が会議を待たずに行動できるように、役割を明確にします：
UIは「現在のオーナー」を目立たせ、委譲（再割当て、対応者追加、コマンダーのローテーション）をサポートすべきです。
Investigating → Mitigated → Resolved のような必須ステートと許可される遷移を選びます。ガードレールを追加します：
内部向け更新（速く戦術的で雑になってよい）とステークホルダー向け更新（明確で時刻付き、選別されたもの）を分離します。テンプレート、可視性、承認ルールを分けた2つの更新ストリームを作り、しばしばコマンダーだけがステークホルダー向けを公開できるようにします。
良いインシデントツールはUIが「単純」に感じられますが、その下のデータモデルが一貫しているからです。画面を作る前に、どのオブジェクトが存在し、どう関係し、どの情報が履歴として正確に残るべきかを決めてください。
最初は少数のファーストクラスオブジェクトから始めます：
多くの関係は一対多です：
インシデントやイベントには安定した識別子（UUID）を使い、人が見る用に INC-2025-0042 のようなフレンドリーキーを生成すると良いでしょう。
フィルタや検索、レポートに必要になる項目は早めにモデル化します：
インシデントデータは機密で後からレビューされることが多いです。編集は単なる上書きではなくデータとして扱います：
この構造があれば、後で検索、指標、権限の機能を追加しても大幅な作り直しを避けられます。
何かが壊れたとき、アプリの役割は入力負担を減らし、明瞭さを高めることです。ここでは「書くパス」：インシデントの作成、更新の継続、後から起きたことを再構築する方法を扱います。
トラブルシューティング中に終えられる短いフォームにします。良い初期必須セットの例：
その他は作成時にはオプションにします（影響、顧客チケットリンク、疑いのある原因など）。スマートデフォルトを使いましょう：start time を「今」に設定し、ユーザーのオンコールチームを事前選択、そして「Create & open incident room」のようなワンタップ操作を提供します。
更新UIは小さな反復更新に最適化します。コンパクトな更新パネルを提供してください：
更新は上書きではなく追記方式にします：各更新がタイムスタンプ付きのエントリとして残るように。
次を混ぜたタイムラインを作ります：
これにより、人にすべてをログさせるのではなく信頼できる記録的ナラティブが得られます。
障害時には多くの更新が電話から行われます。大きなタップターゲット、単一のスクロールページ、オフライン対応の下書き、一タップの「Post update」「Copy incident link」などを優先してください。
重大度はインシデント対応の「スピードダイヤル」です：どれだけ急ぐか、どれだけ広く知らせるか、どのようなトレードオフを許容するかを決めます。
「高/中/低」だけの曖昧なラベルは避け、各レベルが明確な運用期待（応答時間やコミュニケーション頻度）に結びつくようにします。例：
重大度選択箇所でこれらルールを表示し、対応中に外部ドキュメントを探さなくてよいようにします。
チェックリストはストレス下での認知負荷を減らします。短く実行可能な項目にし、役割ごとに結びつけます。
有用なパターンの例：
チェックリスト項目はタイムスタンプと担当者が分かるようにして、インシデント記録の一部にします。
インシデントは1つのツールに収まらないことが多いです。ダッシュボード、ログクエリ、チケット、チャットスレッド、ランブックなどへのリンクを添付できるようにします。
リンクは型付き（例：Runbook、Ticket）にすると後でフィルタしやすくなります。
信頼性目標を追う組織なら、軽量なフィールド（SLO影響（yes/no）、推定エラーバジェット消費、顧客SLAリスク）を用意します。任意項目にしておき、インシデント中または直後に簡単に埋められるようにしてください。
良いポストモーテムは始めやすく、忘れられにくく、チームで一貫性があります。デフォルトテンプレート（最小の必須項目）を提供し、インシデントレコードから自動入力することで、再入力に時間を使わせず思考に時間を使わせます。
組み込みテンプレートは構造と柔軟性のバランスを取ります：
早期公開を優先する場合は「Root cause」を最初は任意にしても良いですが、最終承認前には必須にしてください。
ポストモーテムは別ドキュメントとして浮遊すべきでありません。作成時に自動で添付するもの：
これらを使ってポストモーテムのセクションを事前入力します。例えば「Impact」はインシデントの開始／終了時刻や現在の重大度で始められ、「What we did」はタイムラインから引っ張れます。
ポストモーテムが停滞しない軽量なワークフローを追加します：
各段階で意思決定ノート：何が変わったか、なぜ、誰が承認したかを記録します。これにより「無言の編集」を避け、将来の監査や学習レビューを容易にします。
シンプルにしたい場合はレビューをコメントと承認の明確な結果（Approve / Request changes）として扱い、最終承認を不変の記録として保存すると良いです。
公開フローをステータス更新ワークフローに紐づけることもできます（例：/blog/integrations-status-updates）。内容を手でコピーする必要はありません。
ポストモーテムが将来のインシデントを減らすには、フォローアップ作業が実行されることが必要です。アクションアイテムをドキュメント末尾の段落ではなくアプリ内のファーストクラスオブジェクトとして扱ってください。
各アクションアイテムは一貫したフィールドを持つべきです：
タグ（"monitoring"、"docs"）、コンポーネント／サービス、そして「created from」（インシデントID・ポストモーテムID）などのメタデータも有用です。
アクションを単一のポストモーテムページに閉じ込めないでください：
これによりフォローアップが散在するメモではなく運用キューになります。
四半期のゲームデイやランブックレビューのような繰り返し作業は、定期テンプレートで新しいアイテムをスケジュール生成し、各発生を個別に追跡できるようにすると便利です。
もしチームが既に別のトラッカーを使っているなら、アクションアイテムに外部参照リンクと外部IDを含め、インシデントの紐付けと検証のソースはあなたのアプリに残すと良いでしょう。
軽量な通知を組み込みます：期日が近づいたら所有者に通知、期限切れはチームリードにフラグ、慢性的な期限切れ傾向はレポートで可視化。ルールはチームごとの運用に合わせて設定可能にします。
インシデントやポストモーテムには機密情報（顧客ID、内部IP、セキュリティ所見、ベンダー情報）が含まれることが多いです。明確なアクセスルールで共同作業を保ちつつ情報漏洩を防ぎます。
まずは小さく分かりやすい役割セットで始めます：
複数チームがいる場合はグローバルアクセスを付与する代わりに サービス／チーム単位で権限をスコープ（例：「Payments Editors」）することを検討してください。
人々が習慣を作る前に分類しておきます：
エクスポートやステータスページではセクションをInternalまたはShareableでマークして強制する実務パターンが有効です。セキュリティインシデントはデフォルトでより厳しい設定にすることを検討してください。
すべてのインシデント／ポストモーテムの変更について、誰がいつ何を変えたかを記録します。重大度、タイムスタンプ、影響、最終承認の変更も含めます。監査ログは検索可能で編集不可にします。
メール＋MFAやマジックリンクを標準でサポートし、ユーザーが期待する場合は SSO（SAML/OIDC） を追加します。短命セッション、セキュアクッキー、CSRF対策、ロール変更時の自動セッション無効化などを実装してください。ロール変更やテストの展開については /blog/testing-rollout-continuous-improvement を参照すると良いでしょう。
インシデントがアクティブなとき、人は細部を読むのではなくスキャンします。今の状態が数秒で分かり、詳細は迷わず掘り下げられるUXを設計してください。
まずは3つの画面でほとんどのワークフローをカバーします：
ルール：インシデント詳細ページは「今何が起きているか？」を上部で、「ここまでどう来たか？」を下部で答えるようにします。
インシデントはすぐ積み上がるので発見を速く寛容にします：
「自分の未完了インシデント」や「今週のSev-1」といった保存済みビューを用意し、シフトごとにフィルタを作り直さないようにします。
アプリ全体で一貫した色かつ色覚に配慮したバッジを使い、微妙な色の差に依存しないでください。リスト、詳細ヘッダー、タイムラインイベントで同じステータス語彙を使います。
一目で分かるように：
可読性を優先します：
睡眠不足で電話を見ている最悪の状況でも、UIが正しい行動へ導くように設計します。
統合が入るとインシデントトラッカーは「メモを書く場所」からチームが実際に運用するシステムになります。接続必須のシステム（監視／可観測性、チャット、メール、チケットシステム、ステータスページ）をまずリストアップしてください。
多くのチームは混在になります：
アラートはノイズが多く、リトライされ順序が前後します。プロバイダーイベントごとに安定した冪等キー（例：provider + alert_id + occurrence_id）を定義して保存し、一意制約を付けます。デデュープルール（例：同じサービス＋同一シグネチャが15分以内なら既存インシデントに追記）を決めます。
アプリが何を担当し、どこはソースツールの責任か明示します：
統合が壊れた場合は段階的に劣化させます：再試行をキューに入れ、インシデント上に警告（"Slack投稿が遅延中"）を表示し、必ず手動で続行できるようにします。
ステータス更新をファーストクラス出力にします：UIの構造化された「Update」アクションがチャットに公開し、タイムラインへ追記し、オプションでステータスページへ同期できるようにして、同じメッセージを3回書かせないでください。
インシデントツールは“障害時に使われる”システムなので、新しさよりも単純性と信頼性を優先します。チームが2時にでもデバッグ・運用できるスタックを選んでください。
まずはチームが既に本番で使っている技術を使います。主流のWebフレームワーク（Rails、Django、Laravel、Spring、Express/Nest、ASP.NET）は、新しい理解者が一人しかいないフレームワークより安全です。
データストレージは関係を明確に扱えるリレーショナルDB（PostgreSQL/MySQL）が適しています：インシデント、更新、参加者、アクションアイテム、ポストモーテムはトランザクションと明確なリレーションで恩恵を受けます。Redisはキャッシュ、キュー、ロックが本当に必要な場合のみ追加してください。
ホスティングは管理されたプラットフォーム（Render/Fly/Heroku系）や既存クラウド（AWS/GCP/Azure）で十分です。可能ならマネージドDBとバックアップを選びます。
アクティブなインシデントはリアルタイムが快適ですが、最初から必須ではありません。
実務的なアプローチはAPI／イベント設計をポーリングで始められるようにし、後でWebSocketへ切り替えられるようにすることです。
このアプリが障害時に落ちると本体の一部になります。次を追加してください：
このシステムを本番として扱います：
ワークフローと画面を検証したい場合、vibe-coding的なアプローチでプロトタイプを作るのが速いです：詳細なチャット仕様から実働プロトタイプを生成するツール（例：Koder.ai）を使い、レスポンダーと一緒に反復します。Koder.aiは実際のReactフロントエンドとGo + PostgreSQLのバックエンドを生成でき、ソースコードのエクスポートもサポートするため、早期バージョンを“捨てるプロトタイプ”にするか、学習を取り込んで本格化する出発点にするか選べます。
リハーサルなしにインシデントトラッカーを出すのは賭けです。優れたチームはこのツールを他の運用システムと同様に扱い、クリティカルパスをテストし、実践演習を行い、段階的に展開し、実運用に基づいて改善します。
高ストレス時に頼るフローを優先してテストします：
回帰テストでは壊してはいけない箇所（タイムスタンプ、タイムゾーン、イベント順序）を検証します。インシデントはナラティブなので、タイムラインが正しくないと信頼が失われます。
権限バグは運用・セキュリティ上のリスクです。次を証明するテストを書きます：
ユーザーが途中でアクセスを失う、チーム再編でグループメンバーシップが変わるといった“ニアミス”もテストします。
本格展開前に、実際のレスポンダーを使ってテーブルトップシミュレーションを行い、アプリを唯一の情報源として使ってみます。部分的障害、データ遅延、サードパーティ障害など組織が認識するシナリオを選び、摩擦（混乱するフィールド、文脈不足、多すぎるクリック、明確でない所有権）を観察します。
フィードバックを即座にキャプチャして、小さな改善をすばやく回します。
1つのパイロットチームといくつかのテンプレート（インシデントタイプ、チェックリスト、ポストモーテム形式）から始めます。短時間のトレーニングとアプリからリンクする1ページの「我々のインシデント運用」ガイド（例：/docs/incident-process）を提供します。
導入指標を追い、摩擦点を改善します：作成時間、更新が付いたインシデントの割合、ポストモーテム完了率、アクションアイテム完了時間。これらをプロダクト指標として扱い、リリースごとに改善を続けてください。
まず組織で合意できる具体的な定義を書きます。
その定義をワークフローの状態や必須フィールドに直接結びつければ、負担にならず一貫したデータが得られます。
ポストモーテムは単なるドキュメントではなくワークフローとして扱います。
もし実際の変化を期待するなら、アクションアイテムの追跡とリマインダーが必須で、単なる保存では足りません。
実用的なv1の機能セットは：
ストレス下でこれらが確実に動くまで、高度な自動化は後回しにしましょう。
チームの実際の作業に沿った、少数で予測可能なステージを使います。
各ステージでの「完了」の定義を決め、次のようなガードレールを追加します：
これにより停滞するインシデントや学びの欠如を防げます。
いくつかの明確な役割をモデル化し、それを権限に結びつけます。
UIでは現在の担当者／コマンダーを明確に示し、委譲（再割当て、コマンダーのローテーション）を可能にしてください。
データモデルは小さく保ちながら構造化します。
安定した識別子（UUID）と人間向けキー（例: INC-2025-0042）を併用し、created_at/created_by や変更の監査ログで編集履歴を残します。
更新ストリームを分け、ルールを適用します：
両方をインシデントレコードに保存して、後で意思決定の経緯を再構築できるようにしつつ、機密情報が漏れないようにしましょう。
重大度は行動／コミュニケーション期待値と結びつけます。例：
重大度を選ぶ画面では期待値（応答速度や更新間隔）を明示してください。
アクションアイテムを構造化されたレコードとして扱います。
さらに「期限切れ」「今週期限」などのグローバルビューやリマインダー／エスカレーションを用意し、レビュー後に作業が消えないようにします。
プロバイダー固有の冪等キーとデデュープルールを使います：
provider + alert_id + occurrence_id のような一意キーを保存するAPIや統合が壊れたら手動リンクをフォールバックとして許可してください。