ポストモーテムは〇〇ではない - 『SREをはじめよう』を読んで

2025年02月06日

はじめに

平素は大変お世話になっております。
クイックガードのパー子です。

オライリーの SREシリーズ最新作『SREをはじめよう - 個人と組織による信頼性獲得への第一歩』を読みました。
特に第10章 “失敗から学習する” で扱われているポストモーテムに関する内容が非常に興味深く、改めて気づかされる/学ぶ点が多かったのでご紹介します。

本章では「ポストモーテムとは何であるのか/何ではないのか」、そして「どのような罠に気をつけたいか」が詳しく語られています。
今回、その中から特に印象に残った部分をピックアップし、自分なりの解釈を添えて記事としてまとめました。

ポストモーテムは学習のプロセスである。〇〇ではない

本書では、ポストモーテムは 失敗から学ぶ学習のためのプロセス であると繰り返し語られています。

そのうえで「何ではないのか」という具体例として、次の 4点を挙げています。

アクション/修理項目のリストでもなければ、アクション/修理項目作成プロセスでもない
文書や報告書ではない
因果関係を証明しようとするものではない
責任をなすりつけようとしているのではない

さすがに今どき 4番を (明示/暗黙を問わず) 目的に据えて、インシデントのたびに犯人探しをしているような組織はかなり危ういでしょう。
そのような安全性の著しく低い場では、当然、生き残ることが最優先で学習どころではなくなります。

2番については、意識しておくと「ポストモーテムが形だけの儀式化している」という気づきのきっかけになるかもしれません。
外部や経営層への報告書が必要なケースもあるでしょうが、それは学習プロセスであるポストモーテムとは切り分けて、別の作業として実施するべきです。

1番や 3番はいずれも、ポストモーテムのプロセスに自然と含まれるステップなので勘違いしやすいところかと思います。

もちろんインシデント発生の機序を明らかにし、アクションアイテムを見極め実行することはシステムの運用において不可欠な取り組みです。
しかし、アクションアイテムの作成を急ぎ、それを目的としてしまうと、重大な事実を見落とすことになってしまうかもしれません。

本書で指摘されているように、学習し、洞察を得るためには、まず事実を正確に把握することが欠かせないのです。
ポストモーテムの本質は、学習のために丁寧に事実を整理し、考察し、組織にとっての示唆を得ることにあるのです。

「なぜ」を慎重に問う

本書では「なぜ」を問う際のリスクについても触れています。

トヨタ生産方式で有名な “なぜなぜ分析” に関して、著者は以下のような懸念を示しています。

現代の複雑なシステムは、複雑な方法で壊れる。真理となるただ一つの因果関係/根本原因に集約できるとは限らない。
なぜなぜ分析によって 1つの因果の連鎖に束縛されると、全体像や学びのタネとなる他の要因を見逃してしまう。
したがって、単一の根本原因に固執することはアンチパターンであり、このような態度は失敗から学ぶうえで不利になる。

そのうえで本書は、「なぜを問うより先に 何 (が起こったのか) を漏れなく明らかにするべきである」と説いています。
つまり、「なぜ」に飛びつく前に、まずは事実関係を正確に把握することが学習を最大化する鍵だというわけです。

一見すると因果関係を深掘りしていくことは悪くないように思えるので、この点は自分も常に意識しておきたいなと思いました。

補足

前セクション “3. 因果関係を証明しようとするものではない” は、実は以下の一文で締め括られています。

加えて、他のすべてを排除して一元的な根本原因を追求するプロセスには、驚くほどの学びがあります。

この章での一貫した主張であるはずの「単一の根本原因に固執してはならない」に反して、根本原因の追求を肯定的に述べています。

これ以外に肯定的な文は他には存在せず、あまりに唐突に感じたため、原文『Becoming SRE』を確認してみました。
すると、原文は以下のようになっていました。

Plus, the process of seeking a unary root cause to the exclusion of all else sheds surprising amounts of potential learning.

念のため O’Reilly Media, Inc. に問い合わせたところ、テクニカルサポート担当の方から「章の主張どおり『学びの機会を失うので、単一の根本原因に固執すべきでない』と解釈してよさそうだ」との回答をいただきました。
原著者の David N. Blank-Edelman氏ではなく O’Reilly社の見解であるため、あくまで参考程度にしかなりませんが、個人的にはやはりこの章では単一の根本原因への固執を一貫して戒めていると考えたいところです。

実施プロセス

ポストモーテムの実施プロセスとして、本書では次の手順が紹介されています。

時系列を洗って、補足情報を盛り込みつつ、事実をドキュメントにまとめる
関係者で集まって、当該ドキュメントをもとにインシデントをレビューする
対策を 翌日に 話し合う

手順2 までは多くの現場で共通すると思いますが、手順3 の “対策を翌日に持ち越す” という点が特徴的だと感じます。

これは先のセクションで述べたアンチパターンである「アクションアイテムの作成を急ぐと、学習の機会を損ねてしまう」ことを避けるための工夫だとされています。

事実を確認するフェーズと対策を検討するフェーズが強制的に分離されるので、落ち着いて事実の整理/共有に専念できる点がよいと感じました。

よくある罠

また、ポストモーテムにおいてよく陥りがちな罠として以下のような点が挙げられています。

結果だけを見て、後知恵で批判しない。当時その場にいた人が持っていた知識やコンテキストを尊重する。
(つまり、当時の状況下ではその判断が合理的であったと信じる)
「〜すべきだった」という仮定の話よりも、現実に起きたことに集中する。そのとき、どのような知識/コンテキストが欠けており、どのようなサポートが不足していたのかを考える。
「機械は完璧であり、インシデントの原因は常に人間である」と決めつけない。システムにも欠陥があるし、人間の柔軟な対応によって被害を最小化できることがある。

他にも印象に残ったのは、「うまくいった点を無視しがちである」という罠です。

インシデントに直面するとどうしても失敗点にばかり目が行きますが、実際には被害の拡大を食い止めたファインプレーも少なからず存在しているはずです。
このようなうまくいった点からの学びを見落とすことの防止策として、本書では「このインシデントがそれ以上に悪化するのを防いだのは何か？」といった質問が有効であると述べられています。
このような問いを立てることで、ポジティブな要因を正しく評価し、学びの幅を広げることができるのです。