システム障害への対応がひと段落したあと、「振り返りを書いてください」と頼まれて手が止まったことはありませんか。

経緯を詳しく書けば、誰かを責める文章になりそう。けれども、曖昧にまとめれば、次の障害を防ぐ材料が残りません。ポストモーテムの書き方で難しいのは、この二つを両立させることです。

ポストモーテムは、失敗した人を探すための文書ではありません。障害時に何が起き、どのような条件が重なり、次はどこを変えられるかをチームで考えるための記録です。

この記事では、初めて担当する方にも使いやすい7つの記録項目と、責任追及に見えにくい表現への直し方を紹介します。完璧な報告書を目指すより、まずは次の対応に役立つ一枚を作っていきましょう。

ポストモーテムとは、障害から学ぶための記録

IT分野におけるポストモーテムとは、インシデントの影響、対応、要因、再発防止策などを障害収束後に整理する文書です。日本語では「事後検証」や「障害振り返り」と表現されることもあります。

GoogleのSRE Bookでは、ポストモーテムを、インシデントとその影響、軽減・解決のための対応、根本原因、再発防止のためのフォローアップを記録するものとして説明しています。また、個人やチームを非難せず、障害に寄与した要因へ目を向ける考え方を重視しています。

この姿勢は英語で「blameless（ブレームレス）」と呼ばれます。直訳すると「責めない」という意味です。この記事では、なじみの薄い専門用語だけに頼らず、「人を責めない振り返り」と表現します。

ここで大切なのは、単に「原因」を一つに決めることではありません。設計、手順、監視、権限、情報共有、業務上の制約など、当時の判断に影響した条件を広く見渡すことです。

「責めない」ことが再発防止につながる理由

障害対応では、設定変更や操作が直接のきっかけになる場合があります。しかし、「担当者が間違えた」で振り返りを終えると、同じ状況に置かれた別の人が同じ結果を招く可能性は残ったままです。

たとえば、誤操作が起きた背景には、レビューなしで本番変更できる権限設計、紛らわしい画面、古い手順書、検証環境の不足、アラートの見落としやすさなどが隠れているかもしれません。

人ではなく仕組みに目を向けると、改善策も「気をつける」から「変更前に自動検証を行う」「承認経路を明確にする」といった実行可能な内容へ変わります。責めない姿勢は、やさしさだけの話ではなく、技術的な改善点を見つけるための前提なのです。

ポストモーテムの書き方｜押さえたい7つの記録項目

テンプレートは組織ごとに異なりますが、初めて作るときは次の7項目から始めると整理しやすくなります。

1．概要

最初に、どのシステムで何が起きたのかを短くまとめます。技術に詳しくない関係者にも伝わる言葉を選びましょう。

記載例：8月10日10時15分ごろから、会員向けWebサービスの一部でログインしにくい状態が発生しました。設定を切り戻し、11時05分に復旧を確認しました。

この段階では原因を断定せず、発生した事象と復旧までの大枠を示します。

2．影響範囲

利用者、機能、データ、社内業務などへの影響を、確認できた範囲で記録します。件数や時間が確定していない場合は、推定値を事実のように書かず、「調査中」「ログから確認できた範囲」と区別します。

• 利用できなかった、または遅延した機能
• 影響が続いた時間帯
• 対象となった利用者や地域
• データ損失や不整合の有無
• 問い合わせや社内業務への影響

3．タイムライン

発生、検知、初動、調査、暫定対応、復旧確認までを時系列で並べます。チャットや監視ログを参照し、時刻の基準もそろえます。

10:15　監視システムがエラー率の上昇を検知
10:18　当番担当者がアラートを確認し、調査を開始
10:32　直前の設定変更との関連を調査
10:48　変更前の設定へ切り戻し
11:05　エラー率の平常化と主要機能の復旧を確認

「すぐに」「しばらくして」といった曖昧な表現より、あとから追える記録を優先します。

4．検知と対応

何をきっかけに異常を知り、どの情報を見て、どのように対応を進めたかを書きます。対応がうまくいった点も残しておくと、次回も活用できる手順が見えてきます。

• 最初の検知手段は監視、利用者連絡、社内報告のどれだったか
• 判断に役立ったログやダッシュボードは何か
• 誰へ、どの時点で連絡したか
• 復旧をどの指標と操作で確認したか

5．障害に寄与した要因

直接のきっかけだけでなく、影響の発生や拡大につながった条件を整理します。複雑なシステムでは、原因が一つとは限りません。

「設定値が誤っていた」に加えて、「変更時の自動チェックがなかった」「影響範囲を事前に確認できる検証環境がなかった」「アラートから手順書へ移動しにくかった」など、仕組みと環境まで掘り下げます。

6．うまくいったことと改善できること

問題点だけを並べると、現場には「評価される場」という緊張が生まれます。早期検知、連絡、切り戻し、他チームの支援など、被害を抑えるうえで機能したことも記録しましょう。

一方、改善できることは、当時の担当者が知り得た情報を踏まえて考えます。結果を知った現在の視点だけで「あのとき当然こうすべきだった」と評価しないことが大切です。

7．アクションアイテム

最後に、再発の可能性や影響を下げる対応を決めます。「注意する」「周知する」だけでは完了を確かめにくいため、担当、期限、完了条件まで明らかにします。

改善前：本番変更では十分に注意する。
改善後：本番設定の変更前に差分を自動表示するチェックを追加する。担当は運用チーム、期限は9月15日、テスト環境で誤設定を検知できた時点を完了とする。

すぐに直せない項目は、優先度や暫定策も併記します。実行状況を追える場所へ登録して、書いただけで終わらせないことが重要です。

人を責めない文章へ直す3つの視点

責めない文章は、責任を曖昧にする文章ではありません。行動と結果は具体的にしながら、人格評価や結果論を混ぜないようにします。

ただし、「人を責めない」とは、規程違反や故意の行為を見過ごすことではありません。法令、就業規則、情報セキュリティ規程などに関わる事案は、通常の技術的な振り返りと切り分け、社内の定めに沿って責任者や担当部門へ相談してください。

また、顧客名、個人情報、認証情報、未公開の脆弱性などを文書に含める場合は、閲覧範囲と保管場所を先に確認します。学びを共有することと、機密情報を広く公開することは別です。

事実と意見を分けるチェック方法

ポストモーテムの信頼性は、情報量よりも「どこまで確認できているか」が伝わるかどうかで決まります。提出前に、各文を次の三つへ分けてみましょう。

• 確認済みの事実：ログ、監視データ、チケット、チャットなどで確かめられる内容
• 推定：根拠はあるものの、現時点では断定できない内容
• 今後の判断：改善案、優先度、採用する対策など、チームで決める内容

たとえば、「負荷が急増したため停止した」と断定する前に、どの指標がいつ上がったのかを確かめます。因果関係が未確認なら、「同時刻に負荷上昇を観測した。停止との因果関係は調査中」と書けば、事実と推定を混同せずに済みます。

あわせて、主語が大きすぎないかも確認します。「利用者全員」「必ず再発する」といった表現は、根拠の範囲を超えやすい言葉です。ログで確認できた対象や期間へ絞ると、文章の精度が上がります。

30分で行う振り返りミーティングの進行例

振り返りは長時間でなくても始められます。事前にタイムラインを共有できている場合は、次のように30分を配分すると、原因探しだけで終わりにくくなります。

1. 0〜3分：目的を共有する。「個人を評価する場ではなく、次回の対応をよくするための場」と確認します。
2. 3〜10分：タイムラインと影響範囲を確認する。認識が異なる箇所は、その場で断定せず調査事項にします。
3. 10〜18分：障害に寄与した条件を出す。設計、監視、手順、連絡、権限など観点を分けます。
4. 18〜25分：うまくいったことと改善できることを整理する。継続したい行動も残します。
5. 25〜30分：アクションアイテムの担当、期限、完了条件を決める。決めきれない項目は、判断する担当と期限を置きます。

進行役は、発言の正しさをすぐに判定するより、「それはどの記録から分かりますか」「その判断時点では何が見えていましたか」と問いかけます。事実と当時の状況を丁寧に拾うことで、改善につながる会話になりやすくなります。

開発が止まる背景を、個人の忙しさではなく仕事の流れから考えたい方は、キャリテの「なぜ開発は止まるのか？『待ち』をなくすフロー効率の科学」も参考にしてください。

障害対応の経験は、キャリアでも言語化できる

ポストモーテムの作成経験は、単なる報告書作成ではありません。状況を整理する力、関係者と認識をそろえる力、再発防止策を具体化する力が表れる仕事です。

職務経歴書や面談で伝えるときは、障害の詳細や顧客情報を開示せず、担当した範囲と工夫へ置き換えます。

言語化の例：運用保守チームで障害後の振り返りを担当。監視ログと対応記録からタイムラインを整理し、関係チームと再発防止策の担当・期限・完了条件を合意しました。

「大きな障害を解決した」と背伸びして表現する必要はありません。記録を整えた、確認事項を洗い出した、手順の更新を提案したなど、自分が実際に担った行動を具体的にするほうが経験は伝わります。

応募書類全体の整え方は、キャリテの「派遣登録担当が教える職務経歴書の整え方」や「ITエンジニアの職務経歴書｜AI時代の書き方と技術転換のコツ」も役立ちます。

まとめ｜まずはタイムラインと一つの改善策から

初めてのポストモーテムで、すべての要因を一度に解明する必要はありません。まずは確認できた事実を時系列に並べ、次回の検知や復旧を少しよくするアクションを一つ決める。それだけでも、障害対応の経験はチームの資産へ変わります。

書き進める途中で誰かを責める表現になったと感じたら、「同じ状況で別の人が担当しても防げる仕組みは何か」と問い直してみてください。視点を人から環境へ移すと、次に直す場所が見えやすくなります。

障害対応や運用保守の経験を活かせる仕事を探す際は、エーティーエスが運営するIT・Web業界向け求人サイト「テクパス」の求人検索もご覧いただけます。今の経験を棚卸ししながら、次の現場で活かせる強みを探してみてください。