障害報告プレゼンの作り方：時系列・影響・改善案を正確に伝える

障害報告のプレゼンでは、利用者に何が起きたのか、どう復旧したのか、原因について何が分かっているのか、次にどの改善に取り組むのかを説明します。障害対応チャネルの投稿を順番に読み上げる場ではありません。きれいにまとまったスライドによって、調査中の原因が確定したように見えてしまうのも避けたいところです。

まず、内容を確認した障害記録を用意します。そのうえで、影響を受けた処理と利用者、復旧と未処理分の解消、観測された事実とその説明を分けて示します。以下の架空事例で、その区別を資料にどう反映するかを見ていきましょう。

この振り返りで何を決めるのか

スライドを作る前に、会議で答えを出したい問いを一つ書きます。サービス運用チームなら、「このリリースを再開できるだけの理解が得られたか。先に対応すべき課題は何か」といった問いです。一方、顧客向けの説明では、影響範囲と次回の連絡予定が中心になることもあります。相手に共有してよい内容が確認された版を使ってください。

Google の SRE ガイドでは、ポストモーテムを影響、緩和策、原因、事後対応などを残す記録として扱い、個人を責めるのではなく、その判断に至った状況に目を向けています。資料作りでも、先に記録を整え、それから説明するという順序が役立ちます。スライドは障害調査の代わりにはなりません。

特定の障害ではなく日常業務の進捗を伝える場合は、週次・月次報告の構成を使うほうが適しています。通常の状況報告をすべて混ぜ込むと、障害についてまだ答えの出ていない問いが埋もれてしまいます。

架空事例：レポート生成が失敗し、残りの処理が完了するまで

ダウンロード用レポートを生成するサービスを例にします。以下は説明のために作成した架空の事例です。時刻はすべて同じ発生日の UTC で表しています。

補足記録には、障害中にワーカーが未知のステータスをエラーとして記録したことが残っています。ただし、そのステータスをどのコンポーネントが発生させたのか、なぜリリース前の確認で見つからなかったのかは、まだ分かっていません。180 件は重複しないジョブ ID の数です。顧客の実人数も、事業上の損失額も確認されていません。

空欄を推測で埋めなくても、この記録から有用な振り返りはできます。ログの参照先はたどれるようにしつつ、機密を含むペイロード、アクセストークン、顧客情報を投影するスライドに貼り付けないようにします。

新規処理の復旧と、影響を受けたジョブの処理完了を分ける

「27 分間のサービス停止で 180 人の顧客に影響」とまとめたくなるかもしれません。しかし、この表現は二つの点で正確ではありません。確認できるのはレポート生成ジョブの失敗であり、サービス全体の停止ではありません。また、数えているのは人ではなくジョブです。一人が複数のジョブを実行していた可能性があります。

例えば、「レポート生成ジョブの失敗を 27 分間観測。影響を受けたと特定した 180 件は、10:00 までに照合して完了を確認」と説明します。その下に、二つの区間を示します。

• 09:00–09:27：記録上最初の失敗から、新規ジョブが正常に完了するようになるまで。
• 09:27–10:00：影響を受けたジョブすべての完了を照合するまでの、残り 33 分間。

新規処理が正常に戻っても、レポートを待っている利用者にとっては後半の 33 分間も重要です。ただし、すべてのジョブが 1 時間遅れたとは言えません。個々の投入時刻と完了時刻がなければ、遅延時間は計算できないからです。同様に、ジョブの完了だけでは、全レポートの内容が正しいことやデータ損失がないことまでは証明できません。

スライドには横向きのタイムラインを置き、新規処理の復旧と残りの処理完了に別々の印を付けます。軸のそばにはタイムゾーンも記載します。実際の障害で最初の失敗時刻が推定にとどまる場合は、その不確かさを示してください。記入しやすいという理由で、リリース時刻を代用してはいけません。

記録をもとに、7 枚のスライドを組み立てる

この事例なら、次の 7 枚から構成を考えられます。事実が少なければ枚数を減らし、判断が分かれる点の確認に必要なら補足資料を追加します。

1. 何が起き、何を判断するのか。確認できた影響範囲、現在のサービス状態、まだ決まっていないリリース判断を示します。
2. 何に、誰に影響したのか。重複のない 180 件のジョブ、影響した業務の流れ、未確認の顧客数を示します。不明な数を、もっともらしい推計で置き換えません。
3. どのような順序で起きたのか。記録された五つの時刻を並べ、通知、ロールバック、復旧、残りの処理完了を区別します。
4. 現時点の根拠から何が言えるのか。未知のステータスを観測した事実と、調査中の問いを並べます。ロールバック後の経過は重要ですが、それだけで障害の仕組みすべてが説明できるわけではありません。
5. 対応を助けたもの、遅らせたものは何か。記録で裏付けられる情報、ツール、連携上の具体的な点を扱います。スライドの見栄えを整えるためだけに「教訓」を作らないようにします。
6. どの改善を提案するのか。予防策と対応手順の改善を分け、担当者と完了を確認する根拠を示します。
7. この場で何を決めるのか。優先順位、未確認の根拠、リリースを再検討するための条件を確認します。

詳細なログ、テスト条件、ジョブ照合の定義は補足資料に残します。幅広い関係者に説明する際は、冒頭に要約を置くと全体をつかみやすくなります。報告内容を PREP 法で整理する方法も構成の参考になりますが、要約しても「処理の復旧」と「利用者に残っている影響」の区別は省かないでください。

調査中の原因を、確定したように説明しない

「誰かが悪い変更をデプロイした」という説明では、次の担当者が同じ問題を見つけたり防いだりする助けになりません。この事例で必要なのは、ジョブを送る側とワーカーのバージョンは何だったのか、それぞれがどのステータスを扱えたのか、リリース前の確認では何を実行したのか、という問いです。

スライドを観測した事実、考えられる説明、追加で必要な根拠の三つに分けます。ここでの事実は、未知のステータスというエラーです。互換性の不一致は、該当バージョンと再現結果に裏付けられるまでは仮説にとどまります。次の調査ではバージョンの組み合わせを比較し、適切なテスト環境で失敗したケースを再現します。

二つの情報源で時刻が食い違うなら、差異を調べる間も両方の記録を残します。原因の説明に異論が出たら、見出しを確認済みの事実の範囲に戻しましょう。「調査を続ける」という判断を支える資料にも価値があります。会議を成立させるために、原因の説明を無理に完成させる必要はありません。

「今後は注意する」で終わらない改善案にする

この架空事例では、次の二つが検討候補になります。完了した修正でも、承認済みの約束でもありません。

担当者、優先順位、期限は、責任を持つチームと合意します。最初に対応した人だからという理由だけで、そのエンジニアの名前を計画に書き込んではいけません。「二度と発生しない」とも約束しないでください。テストや手順を一つ追加しただけでは、そこまで言えません。各対策が、どの失敗や遅れに対処するものなのかを具体的に説明します。

確認済みの記録を Presenti で資料の下書きにする

機密情報を除いた資料作成メモを用意し、影響の定義、時系列、参照元、確認済みの事実、未解決の問い、改善案をまとめます。Presenti のテキストから資料を作成する機能に渡して、7 枚の構成を下書きにします。09:27 と 10:00 を別の節目として残し、顧客数は不明のまま扱うよう指示してください。

デザインを選ぶ前に構成を確認します。「互換性の不一致の可能性」が「根本原因を特定」に変わっていたら、見た目を整える前にその記述を直します。編集できる下書きでは、時系列のラベルを読める大きさで配置し、各改善案のそばに完了を確認する根拠を置きましょう。Presenti は説明の整理を支援しますが、障害ログの正しさやリリースの安全性を判断するものではありません。

障害報告用メモと 7 枚構成のひな型をダウンロードするか、次の作成指示を使ってください。

提供した記録から障害の振り返り資料を下書きしてください。影響、検知、ロールバック、新規ジョブの復旧、影響を受けたジョブの照合を分けてください。観測した事実と仮説を区別し、不明点、参照元、タイムゾーンを残してください。影響を受けた顧客数、損失額、原因、担当者の承諾、対策の完了を作り足さないでください。

会議の最後には、実際に合意したことと、まだ必要な根拠を記録し、次回の確認につなげます。目指すのは、障害の状況をより正確に共有し、次の変更を根拠に基づいて選べることです。再発が不可能になったと宣言するスライドではありません。