ポストモーテムと障害報告書は何が違い、両方必要なのですか？

障害報告書は経営層・顧客向けの対外説明文書で、技術的詳細や再発防止策が抽象化されがちです。再発防止の実効性を確認したい場合は、報告書の書き直しを求めるのではなく、別文書としてポストモーテムの提出を追加で依頼してください。

発注者がポストモーテムの実施をベンダーに求めるのは越権行為になりませんか？

ポストモーテムの設計思想では、ステークホルダーである発注者は実施を要求してよい立場に含まれるため、越権行為にはなりません。ただし要求できるのは実施そのものであり、誰の責任かを特定することではない点に注意が必要です。

ポストモーテムの会議には発注者として同席すべきですか？

一律の正解はありません。複数ベンダーが絡み事実の突き合わせが必要な場合や経営説明に一次情報が要る場合は同席を、契約窓口が営業のみの場合や技術内容が高度な場合は報告受領に留める判断が目安になります。

ベンダーにポストモーテムの実施を依頼するタイミングはいつがよいですか？

復旧直後（0〜24時間）は原因追及をせず記録保全のみを依頼し、目的を明記したうえで48〜72時間以内の実施を別途依頼するのが推奨されます。時間が経つほど関係者の記憶が曖昧になるためです。

再発防止策（アクションアイテム）が実行されず風化するのを防ぐには？

各項目にオーナー・期日・完了条件を明記して合意し、既存の週次・月次定例に進捗確認の常設議題を追加してください。件数を3〜5件に絞り優先度の高いものから確実に実行させる方が効果的です。

複数ベンダー・内製が混在する体制では、誰がポストモーテムの進行役を担うべきですか？

発注者・主契約ベンダー・中立の第三者のいずれも選択肢になります。ただし進行役に関わらず、責任分界点の議論より先に各社の時系列を統合して事実を固めてから原因分析に入ることが重要です。

ポストモーテムとは？障害後の振り返りに発注者が関わる5ステップ

本番環境が数時間止まりました。復旧はできました。経営会議では「原因と再発防止策を報告するように」と言われました。そしてベンダーから届いた障害報告書には、最後に「今後は確認体制を徹底いたします」と書かれている——このまま経営層に提出しても、まず間違いなく「それで本当に再発しないのか」と聞き返されます。

かといって、ベンダーを厳しく問い詰めるのも簡単な判断ではありません。強く追及した結果、担当エンジニアが萎縮して、次から軽微な障害やヒヤリハットが報告されなくなるかもしれない。そうなれば、目の前の1件は片付いても、次の大きな障害の兆候を見逃すことになります。実効性のある再発防止策がほしい気持ちと、関係を壊したくない気持ちが同時に成り立たず、身動きが取れなくなる。多くの発注担当者がこの板挟みに立たされます。

この板挟みを解く鍵が、ポストモーテムという振り返りの手法です。ポストモーテムは、そもそも「誰の責任かを問わない」ことを設計思想として組み込んだ仕組みであり、追及と関係維持を両立させるために作られています。手法を知っているかどうかではなく、発注者としてどこまで関わり、何を依頼し、どんな質問を投げるかという線引きを持てるかどうかで、得られる再発防止策の質は変わります。

本記事では、ポストモーテムとは何かという定義と、障害報告書やレトロスペクティブとの違いを整理したうえで、テンプレートの9項目を「発注者が何を読み取れるか」という視点で解説します。さらに、発注者が関わるための5つのステップ、関係を壊してしまうNG対応、次の障害に備えて保守契約に組み込む方法まで、明日ベンダーに送る依頼メールの中身が決まる粒度でお伝えします。

Contents — 目次

ポストモーテムとは？障害後の振り返りを仕組み化するSRE発の手法
ポストモーテムと障害報告書・レトロスペクティブの違い
ポストモーテムの書き方｜テンプレートに入れるべき9項目
発注者がポストモーテムに関わる5つのステップ
発注者がやりがちなNG対応｜ベンダーが萎縮する4つのサイン
保守契約・SLAにポストモーテムを組み込む方法
複数ベンダー・内製混在の体制でポストモーテムを回すには
まとめ｜ポストモーテムを次の発注判断につなげる
関連情報

—Free Download / 資料ダウンロード

業務委託エンジニアのマネジメント実践ガイド

この資料でわかること

こんな方におすすめです

業務委託エンジニアのオンボーディングを効率化したい
正社員と業務委託が混在するチームのマネジメントを改善したい
業務委託エンジニアとの長期的な関係を構築したい

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

入力いただいたメールアドレスにPDFをお送りします。

ポストモーテムとは？障害後の振り返りを仕組み化するSRE発の手法

ポストモーテムとは、システム障害やインシデントが発生した後に、何が起きたのか・なぜ起きたのか・次にどう防ぐのかを文書化し、組織全体で共有・学習するためのプロセスです。単なる報告書作成ではなく、「同じ障害を二度と起こさないための知見を組織の資産に変える」ことを目的とした運用プラクティスを指します。

発注者としてまず押さえておきたい結論は、ポストモーテムは再発防止の実効性を担保するための仕組みであって、責任追及の場ではないということです。この前提を共有できているかどうかが、ベンダーから引き出せる情報の質を決定的に左右します。

ポストモーテムの意味と語源｜「検死」から運用改善の手法へ

ポストモーテム（postmortem）は、もともとラテン語の post（後）と mortem（死）に由来する医学用語で、「検死」「死後解剖」を意味します。人が亡くなった原因を解剖によって突き止め、同じ死を防ぐための知見を医学界に残す——この考え方が、システム運用の世界に転用されたものがITにおけるポストモーテムです。

検死という語感から「犯人捜し」を連想されるかもしれませんが、本来の目的は正反対です。検死の目的は執刀医を裁くことではなく、死因のメカニズムを解明して次の患者を救うことにあります。IT の文脈でも同じで、障害を起こした担当者を特定することではなく、その障害を許してしまったシステム・プロセス・監視体制の構造的な弱点を明らかにすることが狙いです。

なぜ「非難しない（ブレームレス）」が前提条件なのか

ポストモーテムを語るうえで欠かせないのが「ブレームレス（blameless、非難しない）」という原則です。Google の Site Reliability Engineering（SRE）ブックでは、ブレームレスなポストモーテムとは「個人やチームの不適切な行動を糾弾することなく、インシデントに寄与した要因を特定することに集中するもの」と定義されています。そのうえで、「インシデントに関わった全員が善意を持ち、その時点で持っていた情報のもとで正しいことをしたと仮定する」という姿勢を求めています（Google SRE Book: Postmortem Culture）。

これは道徳的な理想論ではなく、情報の質を確保するための実務上の要請です。ミスを認めると罰せられると考えているエンジニアは、詳細を隠し、影響範囲を小さく見積もり、体裁は整っているのに中身が薄い報告書を作ります。逆に、非難されないと分かっていれば、「実はこの設定変更は手順書になくて口頭で引き継いでいた」「アラートは鳴っていたが誤検知が多くて無視する運用になっていた」といった、本当に価値のある事実が出てきます。

発注者と受注者という関係が加わると、この力学はさらに強く働きます。金銭を支払う側からの追及は、社内での上司からの追及よりも心理的な圧力が大きいためです。したがって、ブレームレスの原則を最も強く意識しなければならないのは、実はベンダー側ではなく発注者側です。

SREでポストモーテムが定着した理由と、発注者側にとっての意味

ポストモーテムが運用の標準プラクティスとして広まった背景には、SRE という考え方の普及があります。SRE では「障害はゼロにできない」という前提に立ちます。システムが複雑化し変更頻度が上がるほど、障害の発生確率をゼロにするコストは無限に膨らむからです。そこで発想を転換し、障害を「必ず起きるもの」と受け入れたうえで、起きた障害から最大限の学びを引き出す仕組みとしてポストモーテムを位置づけました。

Google SRE ブックでは、ポストモーテムを開始する典型的なトリガーとして、ユーザーに見える形でのダウンタイムや性能劣化が一定のしきい値を超えた場合、あらゆる種類のデータ損失、オンコール担当者の手動介入（リリースのロールバックやトラフィックの切り替え等）が発生した場合、復旧時間が一定のしきい値を超えた場合、監視の失敗（＝人間が手動で障害に気づいた場合）を挙げています。加えて、ステークホルダーであれば誰でも重要なイベントについてポストモーテムを要求できるとされています。

最後の一文は、発注者にとって重要な意味を持ちます。ポストモーテムの設計思想において、発注者は「実施を要求してよい立場」に含まれているということです。「振り返りをお願いするのは越権ではないか」と迷う必要はありません。ただし、要求してよいのは実施そのものであって、誰の責任かを特定することではない、という線引きが同時にセットになっています。

なお、障害が発生している最中に発注者が何をすべきかについては、本番障害の対応フローで時系列に沿って整理しています。本記事は障害が収束した「その後」の話です。

ポストモーテムと障害報告書・レトロスペクティブの違い

「ベンダーから報告書は来たけれど、中身が薄い」と感じるとき、その原因はベンダーの怠慢とは限りません。そもそも受け取った文書が、あなたが期待していたものとは別の目的で書かれた別の成果物である可能性があります。発注者が障害後に受け取りうる文書には複数の種類があり、目的も読者も粒度も異なります。

目的・読者・タイミングの比較表

混同されやすい3つの文書・活動を、4つの軸で整理します。

軸	障害報告書	ポストモーテム	レトロスペクティブ
主な目的	対外的な説明責任を果たし、信頼を回復する	根本原因を解明し、再発を防ぐ知見を組織に残す	開発プロセス・チームの働き方を継続的に改善する
想定読者	顧客・経営層・監督官庁など組織の外側	開発・運用に関わるエンジニアと関係者	開発チームのメンバー自身
実施タイミング	障害収束後、対外説明が必要になった時点	障害収束後、記憶が新しいうち	スプリント終了時など定期的
対象範囲	その1件のインシデント	その1件のインシデント	一定期間に起きた出来事全般
粒度の特徴	事実と対応方針を簡潔に。技術的詳細は抑制的	技術的詳細・時系列・判断根拠まで踏み込む	プロセスや協働の観点が中心

SCROLL→

この表から分かるのは、障害報告書とポストモーテムは対立するものではなく、役割が違うということです。障害報告書は「外向きの説明」であるがゆえに、意図的に技術的詳細を削ぎ落として作られます。これは手抜きではなく、対外文書としては正しい書き方です。問題は、発注者が再発防止の根拠を知りたいときに、外向きの文書だけを受け取っている点にあります。

障害報告書の書き方だけでは再発防止に届かない理由

障害報告書の書き方を解説する記事は数多くありますが、その多くは「発生日時・影響範囲・原因・対応・再発防止策」という定型のフォーマットを紹介しています。このフォーマット自体は妥当です。しかし、対外文書という性質上、次の3つの制約が構造的に働きます。

第一に、原因の記述が抽象化されます。「設定値の誤りにより」と書かれていても、なぜその誤った設定値がレビューを通過してしまったのかという層には踏み込みません。対外文書で自社の内部プロセスの弱点を詳細に開示するインセンティブは、ベンダー側にありません。

第二に、再発防止策が「意思表明」になりがちです。「確認体制を徹底します」「ダブルチェックを実施します」という表現は、対外文書としては誠意を示す定型句ですが、検証可能な変更ではありません。誰がいつまでに何をどう変えるのかという情報が欠けているため、実行されたかどうかを後から確認できません。

第三に、時系列が要約されます。障害の検知から復旧までのどの工程に時間がかかったのかは、対外文書では「〇時〇分に復旧」としか書かれません。しかし発注者が本当に知りたいのは、検知に30分かかったのか、原因特定に3時間かかったのか、復旧作業自体は5分だったのか、という内訳です。ここが分からなければ、次に投資すべきは監視なのか、手順書なのか、体制なのかを判断できません。

つまり、障害報告書に不満を感じたときの正しい打ち手は、報告書の書き直しを求めることではなく、「ポストモーテムという別の成果物を追加で依頼する」ことです。これは追及ではなく、依頼するドキュメントの種類を変えるという建設的な調整です。

レトロスペクティブとの使い分け｜インシデント単位か、期間単位か

もう一つ混同されやすいのがレトロスペクティブ（振り返り、ふりかえり）です。アジャイル開発でスプリントの終わりに実施される定期的な振り返りを指し、「うまくいったこと・改善すべきこと・次に試すこと」を話し合う場です。

両者の決定的な違いは、トリガーが時間か事象かという点です。レトロスペクティブは期間で区切って定期実行されるのに対し、ポストモーテムはインシデントという事象をトリガーに単発で実行されます。また、レトロスペクティブが扱うのはチームの働き方やプロセス全般であるのに対し、ポストモーテムは特定の障害の技術的・組織的な原因に集中します。

発注者としては、「定例の振り返りで一緒に話しました」という回答が来た場合に注意が必要です。スプリントレトロスペクティブの議題の一つとして障害が触れられただけでは、根本原因の追跡やアクションアイテムの期日管理までは通常行われません。インシデント単位での独立した振り返りを依頼しているのだ、という意図を明示する必要があります。

ポストモーテムの書き方｜テンプレートに入れるべき9項目

ここからは、ポストモーテムの書き方を具体的に見ていきます。ただし、書くのはベンダー側のエンジニアです。発注者にとって重要なのは項目を暗記することではなく、各項目から何を読み取り、どんな判断ができるかを知っておくことです。以下では、実務で広く使われている9項目を「発注者の読み方ガイド」として整理します。

ポストモーテムのテンプレート9項目と、発注者が読み取れること

Google SRE ブックが示すポストモーテムの標準的な構成要素（サマリ、タイムライン、根本原因分析、影響評価、オーナーと期日付きの是正措置）をベースに、実務で使われる形に展開すると次の9項目になります。

#	項目	記載される内容	発注者がここから読み取れること
1	インシデント概要	何が起きたかの1〜2段落の要約	この1件を組織がどう認識しているか。重大度の認識が自社とずれていないか
2	影響範囲	影響を受けたユーザー数・機能・期間・金銭的影響	経営報告に使える定量情報。ここが空欄なら影響を測定する仕組み自体がない
3	タイムライン	発生・検知・エスカレーション・原因特定・復旧の各時刻	どの工程がボトルネックか。次に投資すべき領域（監視か手順か体制か）
4	根本原因	なぜ障害が起きたのかの構造的な説明	「人的ミス」で終わっていないか。仕組みの層まで掘れているか
5	トリガー	障害を引き起こした直接のきっかけ（リリース・設定変更・負荷増等）	同じトリガーが今後も繰り返されるか。リリースプロセスの見直しが必要か
6	検知方法	どうやって障害に気づいたか（監視アラート・ユーザー報告等）	監視の穴。ユーザー報告で気づいた場合、監視設計の見直しが最優先課題
7	対応の経緯	復旧までに試したこと・判断の根拠・うまくいかなかった対応	属人性の度合い。特定の1人しか対応できていないなら体制リスクがある
8	教訓	うまくいったこと・うまくいかなかったこと・幸運だったこと	組織の学習能力。「幸運だったこと」が書けているチームは成熟度が高い
9	アクションアイテム	再発防止策の一覧（担当者・期日・完了条件つき）	実効性の核心。担当者と期日がない項目は実行されないと考えてよい

SCROLL→

この表の右列こそが、発注者にとってのポストモーテムの使い道です。たとえば項目6の検知方法に「お客様からのお問い合わせにより認知」と書かれていたら、それは監視設計に穴があるという事実の告白であり、次の投資先が明確になります。項目9に期日が入っていなければ、その再発防止策は高い確率で風化します。

なお、項目8の「幸運だったこと」は見落とされやすい項目ですが、価値が高い情報です。「たまたま深夜帯で利用者が少なかった」「たまたま担当者がログを見ていて早期に気づいた」といった記述は、次に同じ幸運がなければもっと深刻な事態になることを示しています。ここが書けているかどうかは、ベンダーの振り返り品質を測る一つの目安になります。

根本原因分析の進め方｜「なぜ」を5回繰り返すときの落とし穴

根本原因の欄が「担当者の確認漏れ」で終わっている報告書を受け取ったことはないでしょうか。これは、根本原因分析（なぜなぜ分析）が途中で止まっているサインです。

なぜなぜ分析はトヨタ生産方式に由来する手法で、「なぜ」を繰り返すことで表層的な原因から構造的な原因へ掘り下げていきます。ただし、この手法には広く知られた落とし穴があります。最初の「なぜ」の主語に人を置いてしまうと、以降の答えが必然的にその人の注意力・経験・責任感といった属性に向かってしまい、分析が責任追及に変質するという問題です（SHIFT ASIA: なぜなぜ分析とは）。

たとえば「なぜ担当者は確認しなかったのか」と問えば、答えは「急いでいたから」「疲れていたから」といった個人の心理状態に行き着きます。ここから導かれる対策は「注意喚起」「意識向上」しかなく、再発防止としては機能しません。

主語を仕組みに置き換えると、掘り下げの方向が変わります。「なぜ確認漏れが本番に到達したのか」と問えば、「レビュープロセスに該当項目のチェックが含まれていなかったから」「デプロイ前の自動検証で検出できない種類の設定だったから」といった、変更可能な対象に到達します。

発注者としては、根本原因の欄を読むときに次の点を確認してください。記述の主語が人になっていないか。「注意」「意識」「徹底」という語で終わっていないか。もしそうなっていた場合、指摘の仕方は「担当者を責めるつもりはありません。同じ状況になれば誰でも起こしうるという前提で、この確認漏れを検出できなかった仕組みの側を、もう一段掘り下げていただけますか」といった形が有効です。人ではなく仕組みに視線を向け直す依頼であることを明示します。

なお、「なぜ」を5回という回数はあくまで目安です。回数にこだわって無理に掘り下げると、こじつけの結論に至ります。物理的・管理的にこれ以上さかのぼれない原因に到達したと判断できれば、3回でも7回でも構いません。

再発防止策を「できない約束」にしないための書き方

再発防止策の欄が「確認体制を徹底します」で終わっている場合、その約束は守られたかどうかを誰も検証できません。実効性のある再発防止策には、次の4つの要素が揃っています。

第一に、具体的な変更内容です。「徹底する」ではなく「デプロイ前チェックリストに設定値の差分確認を追加する」「該当設定の変更を自動検証パイプラインの対象に含める」といった、何がどう変わるのかが分かる記述です。

第二に、オーナーです。誰が実行の責任を持つのかを個人名または役割名で特定します。チーム名だけでは実質的に誰の責任でもなくなります。

第三に、期日です。いつまでに完了するのかを日付で明示します。「次のスプリントで」という表現は、スプリントの優先順位次第で無期限に後ろ倒しされます。

第四に、完了条件です。何をもって完了とみなすのかを定義します。「チェックリストを更新した」なのか「更新したチェックリストで1回運用を回した」なのかで、実効性は変わります。

もう一つ、発注者側が心得ておくべきことがあります。アクションアイテムは多ければよいわけではないという点です。1件の障害から10個の対策が出てきた場合、そのうち実行されるのは上位数件で、残りは風化します。優先度をつけて3〜5件に絞り、確実に実行するほうが、再発防止としては効果があります。「他に対策はありませんか」と数を求めるのではなく、「この中で最も効果が大きいのはどれですか」と優先度を問うほうが、実効性の高い議論になります。

発注者がポストモーテムに関わる5つのステップ

ここまでの内容を踏まえて、発注者としてどう動くかを時系列で整理します。ポイントは、タイミングごとに自分の役割を切り替えることです。復旧直後に踏み込みすぎると情報が閉じ、逆に何も言わないまま数週間が過ぎると振り返りの機会そのものが失われます。

ステップ1〜2｜インシデント振り返りを依頼するタイミングと伝え方

ステップ1：復旧直後（0〜24時間）は原因追及をせず、事実の記録依頼に徹する

復旧直後の現場は、疲弊しています。徹夜対応の直後に「なぜこうなったのか」と問われれば、防御的な反応が返ってくるのが自然です。この段階で発注者がすべきことは、原因を問うことではなく、記録が失われないようにすることです。

伝える内容は次の3点に絞ります。まず復旧対応への労いを伝えること。次に、後日の振り返りのためにログ・チャットの履歴・作業記録を保全しておいてほしいと依頼すること。そして、原因の詳細は後日あらためて整理してもらう予定であると予告することです。

この予告が重要です。「後で聞かれる」と分かっていれば、担当者は自分のメモを残します。逆に予告がないと、数日後に時系列を聞いても「もう覚えていない」という回答になりかねません。

ステップ2：48〜72時間以内の実施を、目的を明記して依頼する

障害やインシデントが発生した場合、できるだけ早く、理想は48時間以内にポストモーテムを実施することが推奨されています。時間が経つほど関係者の記憶は曖昧になり、対応の経緯や判断理由を正確に再現できなくなるためです（NTTドコモビジネス: ポストモーテムとは）。チャットの履歴やログの保持期間の観点からも、早期の実施には合理性があります。

依頼メールに含めるべき要素は次のとおりです。

目的の明示：責任の所在を問うためではなく、再発防止と組織的な学習のために依頼していること
成果物の指定：障害報告書とは別に、時系列・根本原因・アクションアイテムを含むポストモーテム文書を求めていること
期限：文書の提出期限（実施は48〜72時間以内、文書提出は1週間以内などが現実的です）
フォーマットの提示：前掲の9項目を添付し、この粒度で記載してほしいと伝える
同席の意向：会議に同席を希望するか、報告書の受領のみでよいかを事前に伝える

特に1点目の目的の明示は、形式的な前置きではありません。この一文があるかないかで、返ってくる文書の率直さが変わります。「担当者の評価や契約に影響させる意図はありません」と明記することも、状況によっては有効です。

ステップ3｜同席すべきか、報告受領に留めるかの判断基準

発注者がポストモーテムの会議そのものに同席すべきかどうかは、一律の正解がありません。同席すれば情報の解像度は上がりますが、発注者がその場にいることで現場が率直に話せなくなるリスクもあります。次の観点で判断してください。

同席したほうがよいケース

複数のベンダーや内製チームが関わっており、責任分界点を跨いだ事実の突き合わせが必要な場合
障害の影響が事業に直結し、経営層への説明で自分が一次情報を把握しておく必要がある場合
発注者側の運用や意思決定（緊急リリースの承認、監視予算の見送り等）が障害の背景にある場合
これまでの関係が良好で、率直な議論ができる素地がある場合

報告受領に留めたほうがよいケース

契約上の窓口が営業担当のみで、開発現場との直接のやり取りが日常的でない場合
障害の技術的内容が自分の理解を大きく超えており、会議の場では判断できない場合
ベンダー側に「発注者の前で原因を話す」ことへの明らかな緊張がある場合
単一ベンダーの閉じた領域で発生した障害で、責任分界点の議論が不要な場合

判断に迷う場合は、二段構えという選択肢もあります。まずベンダー内部で率直な振り返りを実施してもらい、その結果を発注者向けに共有する場を別途設けるという進め方です。この場合、内部向けの議事メモまで開示を求めず、9項目のポストモーテム文書と、そこから生じた質疑に答えてもらう形にします。

同席する場合に一つだけ決めておくべきことがあります。それは、自分の役割を「質問する人」に限定し、「評価する人」にならないと事前に宣言しておくことです。会議の冒頭で「今日は責任の話をする場ではなく、仕組みを直す材料を集める場だと理解しています」と一言添えるだけで、場の緊張は大きく下がります。

ステップ4〜5｜質問の向け先と、アクションアイテムの追跡方法

ステップ4：質問は「誰が」ではなく「どの仕組みが検知できなかったか」に向ける

会議やレビューの場での質問の作り方が、得られる情報の質を決めます。同じことを聞くにも、主語を人から仕組みに移すだけで、返ってくる答えが変わります。

避けたい質問（主語が人）	置き換えた質問（主語が仕組み）
なぜ担当の方は気づかなかったのですか	この変更が本番に反映される前に、異常を検出できたポイントはどこにありましたか
誰がこの設定を変更したのですか	この設定変更は、どのような承認・確認のプロセスを通っていましたか
なぜもっと早く連絡をくれなかったのですか	エスカレーションの判断基準は、現在どのように定められていますか
再発防止策はどうなっていますか	この中で最も効果が大きいと考えている対策はどれで、その理由は何ですか

SCROLL→

右列の質問には、共通する特徴があります。答えが個人の属性ではなく、変更可能な対象（プロセス・監視設定・基準・優先順位）に着地することです。結果として、そのまま次のアクションにつながります。

ステップ5：アクションアイテムに期日・オーナー・完了条件を付けて合意し、定例で追跡する

ポストモーテムで最も価値が失われやすいのが、この最終工程です。文書が完成した時点で満足してしまい、アクションアイテムが次のスプリントの優先順位争いに埋もれて風化するというパターンは頻繁に起こります。

これを防ぐには、ポストモーテムの締めくくりとして次の3点を合意し、記録に残します。第一に、各アクションアイテムのオーナーと期日と完了条件です。第二に、進捗を確認する場です。既存の週次・月次の定例会議の議題に「前回インシデントのアクションアイテム進捗」という常設項目を追加するのが現実的です。第三に、完了報告の方法です。完了時にどのような形（チケットのクローズ、定例での口頭報告等）で知らせてもらうかを決めておきます。

発注者側にも役割があります。アクションアイテムの中には、ベンダーだけでは実行できないものが含まれるためです。監視ツールの追加導入には予算が必要ですし、リリース承認プロセスの変更には発注者側の合意が要ります。「対策の実行に必要な発注者側の判断があれば挙げてください」と問いかけ、自社側の宿題も一覧に含めることで、振り返りは一方的な要求ではなく共同作業になります。

—Free Download / 資料ダウンロード