「インシデントデブリーフを攻略」~世界のインシデント対応~incident.io-Part15

はじめに

英国のスタートアップ企業であるPineapple Technology Ltd様が運営するincident.ioに関連したブログ　The Practical Guide to Incident Management　のポイントと解説

ポイント!!

インシデント障害後のインシデントデブリーフでは対話的な分析が重視され、デブリーフミーティングでは、インシデントの対応者やステークホルダーが参加し、インシデントの時系列や今後の対応を含む文書が作成されます。
デブリーフミーティングの開催には慎重なバランスが求められ、全てのあらゆるインシデントに対して盲目的に実施することは非効率的であり、インシデントを対応するメンバーにとってストレスの少ない環境で、今後の対応を明確にすることに焦点を当てる必要性があります。
インシデント後の反省には時間をかけることが必要であり、即座にデブリーフを行うことは避けるべきです。また、重要なのは文書の形で公表することではなくデブリーフのプロセスそのものであることを念頭に置くべきです。

解説

振り返り（post-mortem）は、システム障害対応の中でも「効果的に実行すること」が一番難しいものかもしれません。なぜならばシステム障害対応そのものは緊急性が高いことからすぐに対応が行われますが、振り返りは重要性が高いはずなのに緊急性が極めて低いためです。

　それも過去やった振り返りが「意味がなかった」と感じるものだったからと認識しています。そのため元記事でも、全てをやることは非効率で、学びがありそうなものを選定せよ、と認識しました。

　incident.ioでは、「全てをやらないで効率的に」「即座にやらず時間を持つ」以外に、「避難と説明責任を分ける」、「ファシリの重要性」「予防以外の成果」「浸透をさせる」「報告プロセスを重視」と書いていますが、私としてはもうちょっと現場目線の軽い振り返りが重要だと認識しています。

　私の意見で振り返りに必要なものは「次もやってもいいかな」と参加者に思ってもらうことで、そのためには３点「前向きな雰囲気」「参加者が価値を実感」「打ち手ができそう」が必要だと思っています。

　「前向きな雰囲気」について、チームよりますが障害に関することなので反省会や誰かを責めるようなことになることがあります。万が一このような振り返りをやってしまうと、みんなが振り返りをやりたがらなくなってしまいます。前向きな雰囲気を出してポジティブな記憶を残すことが重要です。

　「参加者が価値を実感」について、振り返りがとりあえず全員を集めて非効率だったり、ミーティングで何を目指しているかがよくわからないとなることがよくあります。大抵の場合、一定規模以上の障害対応の振り返りをすることが多く、そこに関わった５～１０名ほど振り返りに召集されますが、誰か一人がしゃべり続けていたり、事実の確認を淡々とされ続けたりと、事実の整理に１時間使って結局、教訓を得たり施策を考えるのに時間が使えない場合が多く「この振り返りはなんだったんだろう」となりがちです。振り返りこそしっかり事前に事実は個別に聞き取っておく、論点を整理しておくとして、せっかく多くの人を集めるのであれば考える時間に使えるようにすべきです。

　「打ち手ができそう」について、出てきた打ち手が崇高すぎていつになるのかわからないことだったり、全員がやりたくないであることは避けましょう。以前聞いたことがあるのは「サービスを一から設計し直す」という打ち手が意見としてでました。気持ちはわからなくはないですが現実的にできることは極めて稀です。他にも参加者が諦め気味で「ダブルチェックをトリプルチェックにする」という打ち手がでると参加者としてはやりたくない！という気持ちが出てきて、組織として打ち手にできる間隔が湧きません。効果は小さくとも、すぐに実行できそうで参加者が少し楽になるような打ち手を導きだすことが重要です。

他の方が考える振り返りポイントは「経営目線」で素晴らしいものが多いですが、私は「現場目線」で少しでも前に進むようなポイントとなっています。このような目線も１つとして是非利用いただければと思います。