「詳細は省こう」というエンジニアリング責任者の依頼は、切り捨てのように聞こえることがある。しかし、Michael Heapの記述では、その経営者の主張はもっと限定的だった。関係者は有能であると前提されていたため、妥当な判断のひとつひとつを追跡することが主な課題ではなかったのだ。優先すべきは、失敗の後に組織が何を変えるかを決めることだった。
書き出しでは、Heapが、経営者が組織の変更に焦点を当てながら詳細を省くよう求めた出来事を紹介している。
Heapは、ポストモーテムではしばしば「なぜこれが起きたのか」という問いに対し、首尾一貫した時系列で答えが出されると論じる。しかしその後、当時利用できた情報、インセンティブ、制約の下では、あらゆる行動に納得できる理由があったと分かることが多い。この理解は重要だが、それだけで再発を減らせるわけではない。物語は、なぜアラートが見逃されたのか、所有権が曖昧だったのか、遅れて入った要件が公開期間に紛れ込んだのかを説明できても、それらの問題を生んだ条件をそのまま残してしまうことがある。
有用な次の問いは、「有能な人々がこの結果を招いたのだとすれば、何を変える必要があるのか」というものだ。この問いは、具体例を設計要件に変える。対応範囲が一人の人物に依存しているなら、所有権には明確な代替担当者を設ける必要がある。公開に伴う変更が予測可能な混乱を生むなら、そのプロセスには、公開期間中に行われる判断を定める規則が必要だ。対応担当者が繰り返し発生する誤警報の後にアラートを無視するなら、見直すべきなのは個人の忍耐力ではなく、アラートシステムそのものなのだ。
だからといって、リーダーが技術的・運用的な詳細を避けるべきだという意味ではない。Heapの立場は、説明が無用だとか、経営者が文脈なしにあらゆる対策を評価できるとかいうものではない。重要なのは、説明責任を理解するために使われる詳細と、介入方法を選ぶために使われる詳細とを区別することだ。リーダーにはなお、提案された変更が該当する失敗の種類に対処しているか、より大きなリスクを生んでいないか、そして予防費用に見合っているかを検証できるだけの証拠が必要である。
またHeapは、記憶だけに依存する是正措置を避けるよう警告している。「よりよく意思疎通する」「もっと注意する」「早期にサポートを巻き込む」といった表現は、善意を示していても、翌日実際に起きることを変えるとは限らない。より強力な対策は、当初の関係者がいなくても効果を発揮し続ける制約、経路、ゲート、または判断地点を作る。実用的な検証方法は反事実的に考えることだ。同じ状況が再び起きた場合、何が異なる結果をもたらすのだろうか。
その逆の誤りは、インシデントのたびにプロセスを追加することだ。Heapは、すべての失敗に別の規則が必要なわけではないとはっきり述べている。場合によっては、予防にかかる費用の方が、時折の再発よりも高くなる。重要なのは、偶然的に欠点を見逃す状態から、明示的なリスク受容へ移ることだ。組織が弱点をそのまま残す判断を下すことは合理的であり得る。ただし、その場合でも、予想される費用を把握し、その判断に対する責任者を割り当て、状況が変わったときに判断を見直さなければならない。
ここで提供された資料は、この手法がインシデント発生率を下げると、独立して立証するものではない。主要な記事は、Heap自身による会話の記述と、彼の運用に関する考え方を裏付けている。一方、参考用のGitHubページは、Heapを開発者、著述家、プロダクトリーダーとして紹介しているが、その経営手法の妥当性を検証するものではない。したがってこの記事は、「何を変えるかを問う」ことを、実証済みの普遍的な法則ではなく、意思決定のための枠組みとして扱っている。その価値は実践にある。この問いは、レビューを将来の行動につなげながら、その行動を判断するために必要な詳細も保持する。