インシデントのポストモーテムを録画する：障害をチームの知見に変える

障害が起きれば、どのチームもポストモーテム文書を書きます。しかし、それを最後まで読むチームはずっと少ないのが実情です。ダッシュボードのリンクとログの断片で埋まったタイムラインは、読み手に頭の中でインシデントを再構築するよう求めます。多くの人はざっと目を通し、うなずいて、そのまま忘れてしまいます。

短い画面録画はこの状況を変えます。午前2時14分のエラー率グラフがどうだったかを文章で説明する代わりに、実際に見せればいい。根本原因を突き止めたクエリを説明する代わりに、その場で実行すればいい。このガイドでは、チームが実際に視聴するポストモーテム動画の作り方と、数か月後も価値が残る形で残す方法を紹介します。

なぜ録画するのか

• 説明より証拠：グラフ、トレース、ログはそもそも視覚的なものです。スクリーンショットでは、スパイクを一目瞭然にする前後の動きが失われます
• 制作が速い：すでに開いている画面をナレーション付きで録画するほうが、推敲した文章を書くより時間がかかりません
• 新メンバーに効く：6分のインシデント解説動画は、Wikiページよりはるかに速くシステムの壊れ方を理解させてくれます
• 判断の過程が残る：文書は何が起きたかを記録しますが、録画は対応者が各段階でなぜそう考えたかを残します
• 非同期に適する：分散したチームがタイムゾーンを合わせて会議を設定しなくてもレビューを消化できます

何を録画し、何を省くか

ポストモーテムの録画はインシデント全体の再生ではありません。読むより見るほうが優れている部分だけに絞りましょう。

録画するもの：

• 検知の瞬間 — アラート、ダッシュボード、最初のユーザー報告
• 障害期間の影響範囲を示す主要なグラフ
• 原因を絞り込んでいった調査の手順（行き止まりも含めて）
• 障害を引き起こした具体的なコード、設定、クエリ
• 修正の適用とメトリクスの回復

省くもの：

• デプロイやデータ読み込みの長い待ち時間
• 診断に関係のない内部の雑談
• ナレーション一文で言えてしまうこと全般

録画前の準備

インシデント対応ツールには、共有動画に映してはいけないものが数多くあります。5分だけ準備に使いましょう。

1. タブを事前に開く：適切な時間範囲のダッシュボード、該当するログクエリ、プルリクエスト、アラート
2. 時間範囲を固定する：ダッシュボードを障害期間に固定し、視聴者が同じ画面を見られるようにします
3. 機密画面を閉じる：顧客レコード、個人情報を含む社内チケット、個人DM、認証情報マネージャー
4. 通知をオフにする：真剣なポストモーテムの最中にランチのリマインダーが出るほど台無しなことはありません
5. 3行の骨子を書く：影響、根本原因、再発防止。残りはすべてこの3点にぶら下がります

ダッシュボードが1つのブラウザウィンドウに収まっているなら、全画面ではなくウィンドウキャプチャを使ってください。余計なものが映り込まない最も簡単な方法です。

うまくいく構成

動画は5〜10分に収めます。信頼できる構成は次のとおりです。

1. 影響を最初に（30秒）：誰が、どれだけの時間、どの程度の影響を受けたか。多くの視聴者が知りたいのはここです
2. タイムラインの説明（2〜3分）：検知、エスカレーション、緩和、解決を実際のダッシュボード上で示します
3. 根本原因（2〜3分）：実際のコードパス、設定変更、クエリを見せます。該当行はズームで拡大します
4. 何が難しかったか（1分）：不足していたアラート、分かりにくいログ、不明確な責任範囲 — 文書では平板になりがちな部分です
5. アクションアイテム（1分）：各項目を担当者とともに口頭で述べ、説明欄にリンクを添えます

エディタで読みやすくする

生のインシデント映像は情報密度が高すぎます。Recordedのエディタで追いやすく整えましょう。

• ズーム効果：ダッシュボードやログの文字は小さいものです。スパイク、エラーメッセージ、問題の差分を拡大しましょう。視聴者に目を細めさせてはいけません
• 速度リージョン：デプロイパイプラインやクエリ実行は早送りし、根本原因が現れる瞬間は等速に戻します
• テキストオーバーレイ：タイムライン解説にタイムスタンプ（02:14 UTC — 最初のアラート）を重ね、動画と文書を対応づけます
• トリミング：ダッシュボードの時間範囲を間違えてやり直した冒頭は削除します
• カーソル効果：再現手順を示すときはクリックを強調します

ウェブカメラは冒頭と締めくくりだけに使いましょう。影響やアクションアイテムを語る場面では顔がトーンを伝えますが、ログ解析中はターミナルを隠すだけです。

非難のないトーンを保つ

動画は文書と違い、話し方がそのまま伝わります。同じ一文でも、言い方次第で分析にも非難にも聞こえます。

• 誰がデプロイしたかを挙げるのではなく「このデプロイで混入しました」と表現します
• 当時得られていた情報を前提に説明します：「この時点ではキュー深度のメトリクスがまだありませんでした」
• 行き止まりも言い訳せずに見せましょう。診断が難しかった証拠であり、それ自体が改善課題です
• 冒頭の声にいら立ちが残っているなら録り直してください。2分で済み、視聴者全員の受け取り方が変わります

文書との併用

動画はポストモーテム文書を補うものであり、置き換えるものではありません。文書は検索でき、リンクでき、流し読みできますが、動画はそうではありません。

良い組み合わせはこうです。

• タイムライン、アクションアイテム、担当者の正式な記録は文書が担います
• 動画は文書の冒頭に埋め込み、何を扱っているか一行で添えます
• 説明欄のチャプタータイムスタンプで根本原因の章に直接飛べるようにします
• アクションアイテムは動画の中だけでなく、必ずトラッカーに登録します

インシデントのライブラリを作る

個々の録画も有用ですが、蓄積するとさらに価値が高まります。

• 命名を統一する：2026-09-28-checkout-latency-postmortem のような形式は並べ替えも検索も快適です
• システム別にタグ付けする：関係するサービスごとにまとめれば、新しいオンコール担当に特定コンポーネントの資料を一式渡せます
• 四半期ごとに見返す：直近四半期の録画をまとめて見ると、繰り返す失敗パターンがすぐに浮かび上がります
• オンボーディングで使う：過去のインシデント3〜4件を厳選しておくと、システムの実際の壊れ方を最速で教えられます

よくある失敗

• 対応中に録画する：まず復旧に集中しましょう。落ち着いて語れるようになってから振り返りを録画します
• 未編集のまま共有する：編集していない40分の画面共有はポストモーテムではありません。誰も見ません
• 顧客データの流出：共有前に必ず一度通して視聴し、ログやダッシュボードに個人情報がないか確認します
• 影響のまとめを省く：最初の1分だけ見て離脱する視聴者も、最も重要な事実は持ち帰れるようにします
• 文書の代わりにする：半年後に似た障害が始まったとき、動画は検索できません

まとめ

ポストモーテムは、理解されるためではなく保管されるために書かれたとき失敗します。影響を先頭に置き、実際の証拠を画面に映し、非難のないナレーションで語り、明確なアクションアイテムで締める短い画面録画は、一つひとつの障害をチーム全員が10分で学べる資産に変えてくれます。

次のポストモーテムは書くだけでなく録画してみてください。関心を持つ人がどれだけ増えるか、きっと驚くはずです。