こんにちは、atama plusでSREをしている加藤です。
この記事はatama plus Advent Calendar 2024 12月9日の記事です！
はじめに
atama plusではインシデント発生後には（ときにはヒヤリハットの場合でも）必ずポストモーテムを実施しています。
この場の最大の目的は、学びを得て次に活かすことです。そのためのアドバイスやベストプラクティスは世の中に数多く紹介されています。
しかし人とのコミュニケーションにおいて、それらのアドバイスを全て意識しつつ話題そのものにも集中するのは難しいですよね。私の一番苦手なことでもあります。それでも、「たったひとつの原則」だけを念頭に置くことならできそうな気がしませんか？
この記事では、その「たったひとつの原則」―― 「反省会にならないようにする」 を中心に据えて、ポストモーテムをより良い場にするためのアイデアをお届けします。
「反省会」とは何か
「反省会」と聞いて、どんな場面を思い浮かべますか？「反省会」という字面から否定的なイメージを思い浮かべる方は多いと思いますが、ここではインシデント後の振り返りの内、「自分たちのためになっていない」会を広く「反省会」と呼ぶことにします。
具体的には次のような特徴を持つ場を「反省会」と定義します。
- 犯人探しをする
- 責任を押し付け合う
- 自分たちのためではなく、外への説明のために行っている
- 原因究明と再発防止策の決定だけが目的になっている
それでは次のセクションからなぜ「反省会」が好ましくないのか、どうすれば良いポストモーテムに持っていけるのかを説明していきます。
誰も悪くない、誰がやっても失敗した
犯人探しや責任の押し付け合いが悪いという点について、多くの人はすぐに同意できるでしょう。しかし、これがポストモーテムの場で具体的にどのように悪影響を及ぼすのか、さらに深掘りしてみましょう。
ポストモーテムで誰かを「犯人」にしてしまうと、その人は次から本番環境での変更を恐れるようになります。慎重さが増すだけなら良いかもしれませんが、最悪の場合、チャレンジする勇気を失ってしまいます。そうなると、その人の仕事へのモチベーションは下がり、最終的には組織全体の成長にも悪影響を及ぼします。
さらに、犯人を特定しなくても、犯人探しの雰囲気が漂うだけで、当事者は自分が悪いのだと思い始めます。その結果、萎縮し、ポストモーテムの場での発言が減る可能性があります。当事者が発言しないポストモーテムに、一体どれだけの価値があるでしょうか？
こうした状況を防ぐためには、単に「誰かを責めない」だけでは不十分です。大切なのは、「あなたは悪くない」というフォローを積極的に入れることです。
たとえば、とあるバグによってインシデントが引き起こされた場合、そのバグは事前に細かいテストを行えば見つけられたかもしれません。しかし、リリース時の状況を振り返ると、リソースや時間の制約の中で、バグが発生する可能性が低い当該箇所に対してテストを行う決断が果たして合理的だったでしょうか？あるいは、特定の問題が本番環境でしか発生しないものであれば、誰が担当しても結果は同じだったかもしれません。
ポストモーテムの場で、「〇〇さんは悪くないよ」「自分が担当しても同じことが起きていたと思う」といった一言を添えるだけで、場の雰囲気は大きく変わります。このようなフォローは、心理的安全性を高め、当事者が自分の視点や経験を率直に共有できる環境を作ります。
そういう状況なら間違えるのも納得だ
ポストモーテムは学習とカイゼンのために行いたいものです。しかし、実際にはインシデント発生後、外部への説明を意識しすぎるあまり、原因となった事象の究明と（しばしば取ってつけたような）再発防止策の立案に終始してしまうことがよくあります。これではポストモーテムの場を活かしきれていません。
インシデントの直接的な原因が特定された時点で、それ以上深掘りせずに「フタ」をするような再発防止策を立てていないでしょうか？
たとえば、リリース前のチェックリストを延々と長くするだけの対応策。チェックリストが増え続けると、やがて形骸化し、真に有効な対策にはなり得ません。
原因究明や再発防止策の立案自体は悪いことではありません。外部に説明するためには必要ですし、場合によっては「それっぽい内容」で十分なケースもあるでしょう。しかし、せっかくポストモーテムに時間を割くのであれば、自分たちのためになる学びやカイゼンを引き出したいものです。
ではどうやったら効果的に深堀りできるのでしょうか？手法については様々ありますが、おすすめなのは操作ミスやバグの混入などを引き起こした人のメンタルモデルを検討してみることです。
ほとんどの場合、人は意図的にミスをしたり、バグだと分かってコードをコミットするわけではありません。「なぜミス、バグだと思わなかったのか？」、「どのような前提知識があれば自分で気づくことができたのか？」と、その行動の背景にある考え方を知ればきっと組織やプロセスの問題が浮き彫りになるはずです。
それがわかってしまえば、あとはメンタルモデルが矯正されるような仕組みを導入するだけです！
メンタルモデルなんて考えるまでもないような「うっかり」でやらかしてしまった？うっかりでインシデントが起こってしまう仕組みを見直しましょう！
インシデントは起きてしまった、しかし対応はよかった
ポストモーテムが建設的に進み、誰も悪者にされることなく、再発防止策が適切に立てられたなら、そのポストモーテムはすでに100点に近いでしょう。しかし、そこで終わりではありません。まだ学べることがあります。
ベテランメンバーは気づかないかもしれませんが、インシデントに慣れていないメンバーや初めて障害対応を経験した新人はきっと右往左往したことでしょう。力になれず、どう動いたら良いかもわからずただただ焦るばかりという経験を持っている人は多いと思います。
ポストモーテムの中でインシデント対応のオペレーション自体を振り返ることで、経験に頼らないインシデント対応の技術と知識を蓄積していく機会にしましょう。
極端な話、インシデントの原因調査や再発防止策はログやメトリクスがあれば後からでも検討可能です。しかし、インシデント対応のオペレーションを振り返る機会は、発生直後の熱量があるうちにしか作れません。オペレーションをログから再現することはできないし、対外説明が必要な再発防止策と異なり必ずしも振り返りを行う必要がないからです。
熱々のうちにうまくいったこと・幸運だったこと・カイゼンできることを話したり、素晴らしい動きをした人・インシデント対応を乗り切ったチームを褒めてあげましょう！
まとめ
冒頭で書いた通り、この記事で紹介したやり方をすべて意識することは難しいと思います。
皆さんそれぞれの持つ「反省会」定義を取り入れてアレンジしながら、ぜひ「反省会にならないように」という意識一つだけ持ってポストモーテムに臨んでみてください！
Discussion