ポストモーテムとは｜障害や失敗を責めずに振り返る進め方

システムの障害やプロジェクトのトラブルが起きた後、「誰のせいか」を探す話し合いになってしまい、本当の原因も再発防止策もはっきりしないまま終わった。そんな経験から、別の振り返り方を探している人も多いはずです。ポストモーテムとは、障害やトラブルの後に、起きたこと、影響、とった対応、原因、再発防止策を文書に残し、関係者で振り返る取り組みのことです。最大の特徴は、個人を責めず、仕組みの問題として原因を探ることにあります。この記事では、ポストモーテムの意味と、ふつうの振り返りとの違い、責めない振り返りの考え方、行う基準、進め方の手順、文書の項目と記入例、原因の探り方、よくある失敗、職場に根付かせる工夫までを順に説明します。振り返りで決めた対策を、担当と期限を付けてチームで追いかける道具として、プロジェクト管理ツールのPinatecaにも触れます。

ポストモーテムとは何か

ポストモーテム（postmortem）は、もともと英語で「死後の」「検死」を意味する言葉です。仕事の場では、障害やトラブル、プロジェクトの失敗が起きた後に、その経緯を詳しく調べ、学びを残す取り組みを指して使われます。特に、Webサービスやシステムを運用する現場で広く使われるようになりました。

Googleがシステムの信頼性を保つための考え方をまとめて公開している書籍『Site Reliability Engineering』は、ポストモーテムを「障害の記録であり、その影響、影響を抑えたり解消したりするためにとった対応、根本の原因、そして再発を防ぐための追加の対応を書いたもの」と説明しています（Google SRE）。同じ章では、ポストモーテムを書くことは罰ではなく、会社全体にとって学びの機会だとも書かれています。

ポストモーテムで残すのは、次のような内容です。

• 何が起きたのか
• 誰に、どれくらいの影響が出たのか
• いつ気づき、どう対応したのか
• なぜ起きたのか
• 同じことを繰り返さないために何をするのか

システムの障害だけでなく、プロジェクトの遅れ、商品の不具合、イベントの運営のトラブル、公開した記事の誤りなど、仕事の中で起きたさまざまな失敗に、同じ考え方を当てはめられます。

ふつうの振り返りとの違い

仕事の振り返りの方法には、ポストモーテムのほかにも、定期の振り返りの会議や、反省会があります。違いを整理しておきます。

プロジェクトの管理の道具を提供するAsanaのガイドは、ポストモーテムの会議を次のように説明しています。

一方のポストモーテム会議は、プロジェクトの終了後に行われ、実際に起こったことを振り返り、成功点や課題を共有し次回に活かす回顧的な会議。 出典: asana.com

振り返りの形	行う時期	主な目的	残すもの
ポストモーテム	障害やトラブルの後、プロジェクトの終了後	起きたことを詳しく調べ、再発を防ぐ	経緯、原因、対策を書いた文書
定期の振り返り	1〜2週間ごとなど決まった間隔	仕事の進め方を少しずつ良くする	続けること、変えることの一覧
反省会	失敗の後	反省を共有する	残さないことも多い

ポストモーテムの特徴は、特定の出来事を対象に、文書を残すことです。定期の振り返りは、日々の仕事の進め方を見直すもので、特定の障害を深く調べるものではありません。反省会は、参加者が反省の気持ちを述べ合って終わることが多く、原因の調べ方や対策の決め方に決まった手順がないことがほとんどです。

もう1つの大きな違いは、個人の責任を問わないことです。反省会では、失敗した本人が謝る場になりがちですが、ポストモーテムでは、誰が悪かったのかではなく、なぜその失敗が起きる状況だったのかを探ります。

責めない振り返りの考え方

ポストモーテムの中心にあるのが、責めない（ブレームレス）という考え方です。Googleの『Site Reliability Engineering』は、責めないポストモーテムについて、次のような考え方を示しています。

• 障害の原因を探るときに、個人やチームの行動を悪いもの、不適切なものとして非難しない
• 障害にかかわった人は全員、そのとき持っていた情報の中で、良い意図を持って正しいことをしたと考える
• 間違った行動をした人やチームを指さして恥をかかせる文化があると、人々は罰を恐れて問題を表に出さなくなる

同じ章では、この責めない文化が、ミスが命にかかわる医療や航空の分野から生まれたことにも触れています。そして、「人を直すことはできないが、仕組みと手順を直して、人が正しい判断をしやすくすることはできる」と説明しています。

責めない振り返りが大切な理由は、本当の原因にたどり着けるかどうかが、関係者が正直に話せるかどうかにかかっているからです。失敗した本人が責められると思えば、自分に不利な事実を話さなくなります。ほかの人も、似た失敗をしたことを隠すようになります。その結果、表に出てくるのは一部の事実だけになり、仕組みの問題は見過ごされます。

責めないということは、何も問題にしないということではありません。起きたことの事実は正確に書きますし、誰がどの操作をしたのかも記録します。そのうえで、「なぜその人はその操作をしたのか」「なぜその操作で障害が起きる仕組みになっていたのか」と、仕組みの側に問いを向けます。

ポストモーテムを行う基準

すべての小さなミスについてポストモーテムを書いていたら、それだけで時間がなくなります。そのため、どんなときにポストモーテムを行うのかを、あらかじめ決めておきます。

Googleの『Site Reliability Engineering』は、よく使われる基準として次のようなものを挙げています。

1. 利用者から見える停止や性能の低下が、一定の基準を超えたとき
2. どんな種類であれ、データが失われたとき
3. 当番の技術者が対応に乗り出す必要があったとき（変更の取り消しなど）
4. 解決までの時間が、一定の基準を超えたとき
5. 監視の仕組みが働かなかったとき（人が手で障害を見つけた場合など）

同じ章では、障害が起きる前に基準を決めておくことが大切だと書かれています。基準が決まっていれば、誰もがポストモーテムが必要かどうかを判断でき、「この程度なら書かなくてよいだろう」という迷いがなくなります。また、決まった基準に当てはまらなくても、関係者の誰かが求めれば、ポストモーテムを行ってよいとされています。

システム以外の仕事に当てはめる場合は、自分たちの仕事に合わせて基準を作ります。たとえば、「顧客に謝罪の連絡をする必要があったとき」「予定の納期を3日以上過ぎたとき」「公開した内容に、訂正が必要な誤りがあったとき」などです。

進め方の手順

ポストモーテムは、次の7つの手順で進めます。

手順1：障害の対応を終わらせる

まず、障害やトラブルの対応を終わらせ、影響が広がらない状態にします。対応の途中でポストモーテムを始めると、原因の調べと対応が混ざり、どちらも中途半端になります。ただし、対応の間に起きたことは、後でタイムラインを作るために、その場でメモに残しておきます。

手順2：担当者を決める

ポストモーテムの文書をまとめる担当者を1人決めます。障害の対応の中心にいた人が担当することが多いのですが、その人が疲れている場合や、当事者として書きにくい場合は、別の人が担当しても構いません。

手順3：事実を集める

チャットの記録、システムの記録、監視の画面、メール、関係者の記憶などから、事実を集めます。いつ何が起き、誰が何をしたのかを、できるだけ正確に集めます。

手順4：文書の下書きを書く

集めた事実をもとに、文書の下書きを書きます。項目は次の節で説明します。下書きの段階では、原因と対策は仮のもので構いません。

手順5：関係者で振り返りの会議を開く

下書きを関係者に事前に読んでもらったうえで、振り返りの会議を開きます。会議では、事実の抜けや誤りを直し、原因を掘り下げ、対策を話し合います。

手順6：対策を決め、担当と期限を付ける

会議で話し合った対策の中から、実行するものを決め、担当と期限を付けます。対策には優先度も付けます。

手順7：文書を公開し、対策を追いかける

完成した文書を、関係者や、同じような仕事をしている人が読める場所に公開します。そして、決めた対策が期限までに実行されたかを追いかけます。

手順1から手順5までは、障害から1〜2週間以内に終えるのが目安です。時間がたつと、関係者の記憶が薄れ、記録も探しにくくなります。

文書に書く項目

ポストモーテムの文書は、項目を決めたひな形を用意しておくと、毎回同じ形で書け、読む人も必要な情報を探しやすくなります。基本の項目は次のとおりです。

1. 表題：何についての文書かが分かる名前
2. 日付と作成者：障害が起きた日、文書を作った日、作成者
3. 状況：下書き、確認中、完成のどれか
4. 概要：何が起きたのかを2〜3文で
5. 影響：誰に、どれくらいの範囲と時間、影響が出たのか
6. 気づいたきっかけ：監視の通知か、利用者からの連絡か、社員が気づいたのか
7. 対応：とった対応と、その結果
8. タイムライン：時刻ごとの出来事
9. 原因：直接のきっかけと、背景にある原因
10. うまくいったこと：対応の中で、うまく働いた仕組みや判断
11. うまくいかなかったこと：対応の中で、遅れや混乱を生んだこと
12. 運がよかったこと：たまたま被害が小さく済んだ点
13. 対策：再発を防ぐための行動と、担当、期限、優先度
14. 学んだこと：ほかのチームにも役立つ教訓

10の「うまくいったこと」と12の「運がよかったこと」を書く欄があるのが、ポストモーテムの特徴の1つです。うまくいったことを書けば、その仕組みを守り、ほかにも広げられます。運がよかったことを書けば、次は運に頼らずに済む仕組みを考えるきっかけになります。

タイムラインの作り方

タイムラインは、ポストモーテムの文書の中で、最も手間がかかり、最も役に立つ部分です。時刻と出来事を並べるだけですが、正確に作ると、原因と対策が自然に見えてきます。

タイムラインには、次のような出来事を入れます。

• 障害のきっかけになった変更や出来事
• 障害が始まった時刻（後から分かった場合も含む）
• 監視の通知が出た時刻、または誰かが気づいた時刻
• 対応の担当者が対応を始めた時刻
• 原因の見当がついた時刻
• 影響を抑える対応をした時刻
• 障害が解消した時刻
• 利用者や関係者に連絡した時刻

時刻は、記録から分かる範囲で分単位で書きます。チャットの記録やシステムの記録には時刻が残っているので、それを手がかりにします。記憶に頼った時刻は、「頃」と添えて、記録で確かめた時刻と区別します。

タイムラインができたら、出来事と出来事の間の時間に注目します。障害が始まってから気づくまでに時間がかかっていれば、監視の仕組みに課題があります。気づいてから対応を始めるまでに時間がかかっていれば、連絡の経路や当番の決め方に課題があります。原因の見当がついてから解消するまでに時間がかかっていれば、対応の手順書や道具に課題があります。

原因の探り方

原因を探るときに大切なのは、最初に見つかった原因で止まらないことです。障害の直接のきっかけは、たいてい誰かの操作や、ある変更です。しかし、そこで止まると、「その人が気をつけるべきだった」という結論になり、仕組みの改善につながりません。

原因を掘り下げるには、「なぜそうなったのか」を何度か重ねて問いかけます。たとえば、設定の変更でサービスが止まった場合です。

• なぜサービスが止まったのか：設定の値を誤って変更したから
• なぜ誤った値が本番の環境に入ったのか：変更の前の確認の手順がなかったから
• なぜ確認の手順がなかったのか：設定の変更は小さな作業と考えられ、手順の対象から外れていたから
• なぜ誤った値に気づかなかったのか：変更の後に動作を確かめる仕組みがなかったから

ここまで掘り下げると、「設定の変更も確認の手順の対象に加える」「変更の後に自動で動作を確かめる」といった、仕組みで防ぐ対策が見えてきます。

また、原因は1つとは限りません。多くの障害は、いくつかの小さな問題が重なって起きます。設定の誤り、確認の手順の不足、監視の不足が同時にあったから、大きな障害になった、ということがよくあります。原因を1つに絞り込もうとせず、障害に寄与したことをすべて書き出すと、対策の幅が広がります。

対策の決め方

原因が分かったら、再発を防ぐための対策を決めます。対策を決めるときは、次の点に気をつけます。

1つ目は、人の注意に頼らない対策を優先することです。「今後は注意する」「確認を徹底する」は、対策として最も弱いものです。人は疲れたり急いだりすると、必ずどこかで注意が抜けます。仕組みで止める、自動で確かめる、誤った操作ができないようにする、といった対策を優先します。

2つ目は、対策の数を絞ることです。振り返りの会議では、たくさんの対策の案が出ます。すべてを実行しようとすると、どれも中途半端になります。効果の大きさと、実行の手間で優先度を付け、本当に実行するものを選びます。

3つ目は、担当と期限を必ず付けることです。担当と期限のない対策は、日々の仕事に押されて後回しになります。対策ごとに1人の担当者を決め、いつまでに終えるかを決めます。

4つ目は、対策の効果を確かめる方法を決めることです。「監視の通知を追加する」なら、「追加した後に、試しに障害の状態を作って、通知が出るかを確かめる」まで決めておきます。

振り返りの会議の進め方

ポストモーテムの会議は、進め方を誤ると、責任の追及の場になってしまいます。会議を進める人は、次の点に気をつけます。

会議の始めに、責めない振り返りであることを全員で確かめます。「この会議は誰が悪かったかを決める場ではなく、仕組みを良くするための場です」と、進行役がはっきり伝えます。

Asanaのガイドも、ポストモーテムの会議では、メンバーが自由に意見を出し合える雰囲気づくりが大切だと書いています。

ポストモーテム会議では、メンバーが自由に意見を出し合える雰囲気づくりが大切です。それぞれの経験や役割に基づいた振り返りを共有することで、メンバー間の相互理解が深まり、次のプロジェクトでの協力体制がより強固になります。 出典: asana.com

会議では、まずタイムラインを全員で確かめ、事実の抜けや誤りを直します。次に、原因を掘り下げ、最後に対策を話し合います。事実の確認と、原因の議論を混ぜないことが大切です。

発言が個人を責める方向に向かったら、進行役が問いの向きを変えます。「なぜその人はそうしたのか」ではなく、「その人がそうしやすい状況だったのはなぜか」と問い直します。

会議の時間は、1時間ほどが目安です。それ以上かかる場合は、対策の議論を別の会議に分けます。会議の最後には、決まった対策と担当と期限を読み上げ、文書の担当者がいつまでに完成版を公開するかを確かめて終えます。

記入例：Webサービスの障害

ここでは、小さなWebサービスで起きた障害を例に、ポストモーテムの文書の一部を書いてみます（内容は説明のための例です）。

表題：10月14日 ログインできない障害

概要：10月14日の10時5分から11時30分までの85分間、利用者がログインできない状態が続いた。原因は、認証の仕組みの設定の変更で、誤った値が本番の環境に入ったこと。設定を元に戻して解消した。

影響：この時間にログインしようとした利用者が、ログインできなかった。問い合わせは12件。データが失われることはなかった。

タイムライン：

• 10時00分　担当者が認証の設定を変更し、本番の環境に反映
• 10時05分　ログインの失敗が増え始める（後から記録で確認）
• 10時40分　利用者からの問い合わせで、障害に気づく
• 10時50分　担当者が対応を始め、直前の設定の変更を疑う
• 11時25分　設定を変更の前の値に戻す
• 11時30分　ログインが正常に戻ったことを確認
• 11時45分　利用者にお詫びと解消のお知らせを掲載

原因：直接のきっかけは、設定の値の誤り。背景には、設定の変更が確認の手順の対象外だったこと、ログインの失敗の増加を知らせる監視がなかったことがある。

うまくいったこと：問い合わせの窓口から、すぐに技術の担当者に連絡が届いた。

うまくいかなかったこと：障害が始まってから気づくまでに35分かかった。設定を元に戻す手順が文書になっておらず、戻すのに35分かかった。

運がよかったこと：利用者の少ない平日の午前に起きた。

対策：

• 設定の変更も、変更の前の確認の手順の対象に加える（担当：A、期限：10月21日、優先度：高）
• ログインの失敗が増えたら通知する監視を追加する（担当：B、期限：10月28日、優先度：高）
• 設定を元に戻す手順を文書にする（担当：A、期限：10月31日、優先度：中）

この例では、タイムラインの「気づくまでに35分」「戻すまでに35分」という2つの時間から、監視の追加と、戻す手順の文書化という対策が導かれています。担当者が設定を誤ったこと自体は事実として書いていますが、その人を責める言葉は入れていません。

システム以外の仕事で使う

ポストモーテムの考え方は、システムの障害に限らず、さまざまな仕事のトラブルに使えます。

たとえば、Webメディアで、事実の誤りを含む記事を公開してしまった場合です。ポストモーテムで振り返ると、「書き手が確かめなかった」で終わらせず、「事実を確かめる手順が、どの段階で、誰の役割として決まっていたか」「一次資料に当たる決まりがあったか」「公開の前の確認で、何が見落とされたのか」を探ることになります。対策は、「数字と固有名詞は公開の前に一次資料と照らし合わせる」といった手順の追加になります。

イベントの運営で、受付が混雑して開始が遅れた場合も同じです。「受付の担当が手際が悪かった」ではなく、「参加者の人数に対して、受付の窓口の数は足りていたか」「事前に名簿を確かめる仕組みはあったか」を探ります。

プロジェクトが予定より大幅に遅れた場合は、プロジェクトの終了後にポストモーテムを行い、見積もりの立て方、途中の進み具合の確かめ方、問題が分かったときの報告の経路を振り返ります。

どの場合も、文書を残すことが大切です。口頭の反省会だけでは、半年後には何を学んだのかを誰も覚えていません。

小さなチームや1人で行うとき

ポストモーテムは、大きな会社の技術の部署だけのものではありません。数人のチームや、1人で仕事を受けているフリーランスでも、形を小さくすれば十分に取り入れられます。

数人のチームなら、文書の項目を減らして使います。概要、影響、タイムライン、原因、対策の5つだけでも、振り返りの質は大きく変わります。会議も、30分ほどの短い時間で、チームの全員がそろうときに行えば足ります。

1人で仕事をしている場合は、自分あての記録として書きます。納期に遅れた、納品物に誤りがあった、といったことが起きたら、その日のうちに、何が起きたか、なぜ起きたか、次から何を変えるかを、短く書き残します。誰にも見せない記録でも、責めない考え方は役に立ちます。「自分の不注意だった」で終わらせず、「なぜ見落としやすい状況だったのか」と問うと、確認の手順を一覧にする、作業の時間帯を変える、といった具体的な改善が見えてきます。

書いた記録は、1つの場所に日付順に保存しておきます。半年ほどたってから読み返すと、自分が繰り返しやすい失敗の型が見えてきます。

発注した相手に報告する必要がある場合は、自分あての記録をもとに、経緯と原因と対策を整理して伝えます。相手に伝える文書でも、言い訳や過度な謝罪ではなく、事実と対策を中心にすると、受け取る側は状況を判断しやすくなります。

よくある失敗

ポストモーテムは、形だけ取り入れても、効果が出ないことがあります。よくある失敗を5つ挙げます。

1つ目は、責めない振り返りのつもりが、実際には責める場になっていることです。言葉では「責めない」と言いながら、会議で失敗した本人が延々と説明を求められたり、評価に影響したりすると、次からは誰も正直に話さなくなります。

2つ目は、対策が実行されないことです。文書を書き、会議で対策を決めても、担当と期限がなかったり、追いかける人がいなかったりすると、同じ障害が繰り返されます。

3つ目は、時間がたってから行うことです。障害から1か月もたってから振り返ると、記憶が薄れ、記録も探しにくくなり、事実が不正確になります。

4つ目は、文書が読まれないことです。完成した文書を、関係者以外が見られない場所に保存すると、ほかのチームが同じ失敗をするのを防げません。

5つ目は、大きな障害のときだけ行うことです。大きな障害は、小さな問題が積み重なった結果であることが多く、小さなトラブルの段階で振り返っていれば防げたかもしれません。基準を決めて、小さなトラブルでも振り返る習慣を作ります。

職場に根付かせる工夫

ポストモーテムを一度行うことは難しくありませんが、職場の文化として根付かせるには時間がかかります。Googleの『Site Reliability Engineering』は、ポストモーテムの文化を育てるには継続的な取り組みが必要で、経営層が振り返りと協力の過程に積極的に参加することで文化を強めていると書いています。

職場に根付かせるために、次の工夫が役立ちます。

1つ目は、上の立場の人が自分の失敗のポストモーテムを書くことです。管理職や経営者が自ら失敗を文書にして共有すれば、「失敗を書いても大丈夫だ」という安心感が広がります。

2つ目は、ポストモーテムを書いた人をたたえることです。失敗を正直に書き、学びを共有した人を、会議などで評価します。罰ではなく学びの機会だということを、行動で示します。

3つ目は、文書を読み合う場を作ることです。月に1回など、過去のポストモーテムの文書をみんなで読み、学びを共有する時間を設けます。ほかのチームの失敗から学べれば、同じ失敗を未然に防げます。

4つ目は、ひな形と手順を整えることです。書き方が決まっていれば、書く人の負担が減り、続けやすくなります。

対策をチームで追いかける道具

ポストモーテムの文書そのものは、共有の文書の道具で十分に作れます。難しくなるのは、文書で決めた対策を、期限までに確実に実行するところです。対策が複数のチームにまたがったり、複数の障害の対策が同時に進んだりすると、誰がどの対策を受け持ち、今どこまで進んでいるのかを把握するのが難しくなります。

担当と期限と進み具合を複数人で共有したい場面では、プロジェクト管理ツールを使う方法があります。その選択肢の1つが、国産のプロジェクト管理ツールのPinateca（ピナテカ）です。公式サイトによると、カンバン、ガントチャート、カレンダー、リストなど8種類のボードとチャットが無料プランから使えます。対策を1枚ずつカードにして担当と期限を付け、カードの項目に「優先度」や「どの障害の対策か」を追加しておけば、対策の進み具合をチーム全員が同じ画面で確かめられます。カードのコメントの履歴は操作の記録にも残ると案内されているので、対策を実行した後の確認の結果も、作業と一緒に残せます。公式の料金ページでは、5人までのチームなら期限なしで無料、ボードは10個まで、クレジットカードの登録は不要とされています。6人目、または11個目のボードからはスタンダードプランになり、料金は1人あたり月額500円（税抜）です。Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

なお、Pinatecaはポストモーテムの文書のひな形を備えた道具ではありません。文書は共有の文書の道具で作り、そこで決めた対策を追いかける段階で使う、という分担で考えると無理がありません。

振り返りの力が活きる仕事

ポストモーテムの考え方は、システムの開発と運用の仕事では欠かせないものになっています。障害の対応だけでなく、障害の経緯と原因と対策を文書にまとめる力が、開発の仕事でも求められます。開発の仕事の内容はアプリケーション開発のお仕事で紹介しています。

企業の業務の進め方を見直す支援をする仕事でも、トラブルを仕組みの問題として捉え、再発防止策を提案する力が役立ちます。こうした仕事はAIコンサル・業務活用支援のお仕事で紹介しています。システムの安全を守る仕事に関心がある場合は、AI・マーケティング・セキュリティのお仕事も参考になります。

編集や制作の仕事でも、公開の後に誤りが見つかったときに、責めずに手順を見直す考え方は役立ちます。制作にかかわる職種の報酬の目安はデザイナーの年収・単価相場で確かめられます。

運営者として見てきた、失敗の後に信頼される人

在宅ワークとフリーランスの仲介を2004年から続けてきた運営者として見てきた限りでは、長く仕事を頼まれ続ける人は、失敗をしない人ではなく、失敗の後の振り返りが上手な人です。納品物に誤りがあったとき、経緯と原因を短く整理し、「次からはこの手順を加えます」と具体的な対策を添えて伝える。自分を責める言葉を並べるのではなく、仕組みを直す提案ができる人は、発注する側から「次も任せられる」と受け止められています。ポストモーテムの考え方は、1人で働く人にとっても、信頼を守るための技術です。

発注する側と受ける側が直接やり取りする形では、こうした振り返りの報告が、そのまま相手に届きます。間に人が入らない分だけ、受ける側の手取りも厚くなります。手数料0%で直接取引できる在宅ワークの仕事は、@SOHO 求人一覧から探せます。

よくある質問

Q. ポストモーテムと反省会は何が違いますか？

大きな違いは、個人を責めないことと、文書を残すことです。反省会は、失敗した本人が反省を述べる場になりがちで、記録が残らないことも多くあります。ポストモーテムは、起きたこと、影響、対応、原因、再発防止策を文書にまとめ、誰が悪かったかではなく、なぜその失敗が起きる仕組みだったのかを探ります。

Q. ポストモーテムはどんなときに行えばいいですか？

あらかじめ基準を決めておき、その基準に当てはまったときに行います。システムの運用なら、利用者から見える停止が一定の時間を超えたとき、データが失われたとき、監視が働かずに人が障害を見つけたときなどです。システム以外の仕事なら、顧客に謝罪が必要になったとき、納期を大幅に過ぎたときなど、自分たちの仕事に合わせて決めます。

Q. ポストモーテムの文書は誰が書くべきですか？

障害の対応の中心にいた人が書くことが多いですが、決まりはありません。当事者が疲れている場合や、書きにくい場合は、対応にかかわった別の人が担当しても構いません。大切なのは、1人の担当者を決めてまとめ役にすることと、関係者全員が下書きを読んで、事実の抜けや誤りを直せるようにすることです。

Q. 責めない振り返りでは、ミスをした人の責任はどうなりますか？

ポストモーテムでは、誰がどの操作をしたのかという事実は記録しますが、個人を非難したり、評価の材料にしたりはしません。その人がその操作をしやすい状況だった仕組みの側に問題があると考え、仕組みを直します。責めないことで関係者が正直に話せるようになり、本当の原因にたどり着きやすくなります。