ベロシティの高いチームのためのインシデント管理
誰も責めることのない事後分析を行う方法
インシデントの事後分析は成長に焦点を当てる — 誰も責めることのないゲーム
ほとんどの企業は、少なくとも年に数回は重大なインシデントを経験しています。
インシデントの防止、影響の軽減、タイムラインの短縮に取り組めます。しかし、おそらくインシデントはすぐに完全には消えません。
良いニュースは、インシデントは学習の機会であるということです。システム内の脆弱性を発見して将来の再発を防ぎ、インシデントの影響を軽減するためのプロセスを磨いて将来的により優れたソフトウェアを構築するチャンスです。
インシデントから学ぶための最良の方法は、インシデントの事後分析を行うことです。Atlassian の事後分析では、誰も責めたりしません。
誰も責めることのない事後分析とは何か?
インシデントの事後分析では、チームを集めてインシデントをより深く見て、何が起こったのか、それが起こった理由、チームの対応方法、インシデントの再発の防止と将来の対応の改善のために何ができるかを把握します。
誰も責めることのない事後分析では、誰も責めることなくこれをすべて行います。
誰も責めることのない事後分析では、すべてのチームと従業員が当時持っていた情報に基づいて、最善の意図を持って行動したと仮定されます。失敗した人を特定して罰するのではなく、誰も責めることのない事後分析は今後のパフォーマンスの向上に焦点を当てます。
Atlassian のインシデント管理ハンドブック:
うまくいかなかったときに、誰かのせいにしたいと思うのは人間にとって自然なことです。それを回避するのが、Atlassian の最大の関心事です。事後分析を実行する際は、これを意識的に克服する必要があります。私たちはスタッフの善意を前提として、スタッフの失敗を決して非難しません。事後分析は、正直かつ客観的に障害を引き起こした状況を調べる必要があります。それによって、正しい根本原因を見つけて緩和できます。
Google、Etsy などの支持者は、このアプローチは学習の文化を促進して時間とともにパフォーマンスを改善できると述べています。彼らは、プログラムの魔女狩り的要素を取り除くと、心理的な変化が生じることを指摘しています。解雇や降格を恐れて責任を押し付けあうことなく、チームは根本的な課題修正に集中できます。
批判者は、誰も責めることのない事後分析が本当に可能かどうかに疑問を抱き (人間は非難しないでいられるのか?)、このアプローチでは説明責任を確保できないのではないかと懸念しています。
誰も責めることのない事後分析は可能ですか?
誰も責めることのない事後分析の主な批判の 1 つは、単に不可能であるということです。結局のところ、責めることと判定することは自然なことです。説明責任は、チームの成功には不可欠な要素です。そして、批判者は、誰も責めることのない事後分析は、本音を隠して作り笑いしながら家族とぎこちなく食卓を囲むようなものだと想像しています。
これらの批判は、誰も責めることのない事後分析のポイントは、インシデントの責任者の気分を害さないこと、つまり、おそらく実際の会話と説明責任を阻害する目標であると想定しています。
しかし、誰も責めることのない事後分析の実際のポイントは、より良い将来の結果につながる、正直で客観的かつ事実中心のコミュニケーションを奨励するという究極の目標を持って、愚かに見える、叱責される、または仕事を失う恐怖を取り除くことです。
たとえば、従業員 A が誤って従業員 B がすでに修正を行ったものと仮定したために、インシデントが発生したとします。誰も責めることのない事後分析では、従業員 A と従業員 B のどちらを責めるべきか考えるのではなく、各従業員が自分の作業プロセスや思考プロセスを検討して、課題の中心に到達しようとします。
プロセスを検討することによって、改善点を特定できます。トレーニング プロセスの問題かもしれません。ドキュメントが混乱を招いたかもしれません。当社の技術システムにチェックやバランスを作成する方法があるため、従業員が誰に連絡すべきかを覚える必要がないのかもしれません。
ポイントは、誰も責めることのない事後分析では、誰が間違いを犯したかを決して特定しないことです。つまり、誰も責めないことによってコミュニケーションの機会が開かれて、IT インシデントは複雑であり、将来的に改善する方法は複数ある可能性があることを確認できます。従業員 A を非難したり解雇したりしません。
効果的な誰も責めることのない事後分析の価値
多くの人にとって、誰も責めることのない事後分析は、文化の転換を必要とするかもしれません。しかし、私たちの経験では、メリットはその労力を上回ります。誰も責めることのない事後分析:
· チーム間で健康的な文化を創り出す
非難する他のチームを探すことがなくなれば、より効果的に協力し、恐れることなく明確にコミュニケーションを取り、周りのチームに共感を持てるようになります。
· 非難を恐れてインシデントを無視する可能性を減らす
インシデントが人前で非難されることや解雇につながらない場合、従業員はそのインシデントについて伝えてチームの注意を喚起し、将来の修正のためのアイデアを共有する可能性が高くなります。仕事を失う可能性がある場合、間違いやミスを隠す動機が生まれます。
· オープンで常に改善する学習文化を創る
誰も責めることのない事後分析は、チームが失敗したことを段階的に話して、改善のためのアイデアをブレーンストーミングするように促します。また、インシデントは複雑で私たち全員が人間であることを認めて、従業員が結果を恐れて選択を守るのではなく学習を受け入れて変化できるようにします。
· サポートとコミュニケーションを増やす
従業員 A と B が停止を巡ってお互いを責める必要がない場合、彼らの関係は強くなる可能性があります。恐怖を取り除くことは、プレッシャーを取り除いて人々にお互いをサポートする機会を与えます。
· チームが最高の仕事をできるようにする
チームメイトがミスのために責められる、非難される、あるいは解雇されるのを見て、他の従業員は自信をなくして、自分の仕事についてより恐怖を抱くようになります。これによって業務の速度が低下して、将来の進捗の障害となる可能性があります。
誰も責めることのない事後分析のベスト プラクティス
誰も責めることのない事後分析の実施は、誰も責めることのない文化の基盤を築くことから始まります。最初に行うべきことは次のとおりです。
オープンで、失敗に寛容なアプローチを前もって伝える
会議が始まる前に、これは魔女狩りではないことをチームに周知します。これは会社が学んで改善する機会です。人々は叱責を恐れることなく、仮定、誤った想定、間違いについて正直に発言できます。
誠実さと失敗を認めることを促す
誰も責めることのない事後分析の批判者は、説明責任の欠如を指摘していますが、ここに誤りがあります。事後分析では、誠実さと説明責任を促すべきです。結果に関する恐怖を取り除くことで、人々は自分の間違いや誤解について正直に言えるようになります。それが、それらを修正する唯一の方法です。
情報を共有して、タイムラインを構築する
インシデントの分析に取りかかる前に、実際に何が起こったかについて全員で情報を共有してください。核となる課題を誤解すると、インシデントの事後分析がすぐに本題から逸れる可能性があります。そのため、インシデントのタイムラインを構築することが重要なのです。
一貫して誰も責めない
一度誰も責めない事後分析を行っても他の事後分析で誰かを責めていたら、恐怖の除去とよりオープンな文化の醸成はうまくいきません。
経営幹部の支持を得る
誰も責めることのない事後分析は、ほとんどの組織にとって文化の変化になるでしょう。始める前に、企業の幹部に誰も責めることのない事後分析と企業文化の利点を理解してもらいましょう。文化の転換は、トップレベルの幹部の支持があって初めて可能になります。
コラボレーション
インシデントに直接関与していないチームでも、事後分析で何かを学んだり貢献したりする可能性があります。
事後分析に別のチームを招くことで、チーム間のコラボレーションが促進されてより多くの視点が得られ、最終的にインシデント管理が向上します。セキュリティおよびプライバシー チーム、法務、リスクとコンプライアンスのメンバーを招待することで、以前はわからなかった要因や、既存のプロセスにおけるその他の潜在的な落とし穴、他のチームが技術システムやプロセスのサポートを改善できる方法を特定できます。
決定を下すが、承認を得る
誰も責めることのない事後分析を適切に行うと、将来のインシデントを防ぐのに役立ついくつかの提案が得られます。推奨されたアクションを承認して内容を審査する責任者を特定してください。
Atlassian では、それはエンジニアリング部門のリーダーが行います。彼らは結論を見直して、事後分析後に合意されたアクションと緩和策に優先順位を付ける責任を担います。
誰も責めることのない事後分析の成功事例
では、誰も責めることのない事後分析によって本当に成果が向上するのでしょうか? Atlassian では、実際にそうなっています。
数年前、あるエンジニアが重要な機器の構成ファイルの構文について大きな間違いを犯して、会社全体の業務が 45 分間停止しました。数値化すれば、何十万ドルもの損失です。
しかしそのエンジニアを責めず、誰も責めることのない事後分析を行いました。私たちの目標は、間違いのために誰かを罰することではなく、将来同じ間違いを防ぐ方法があるかどうかを確認することでした。人間は間違うものです。それ自体は回避できません。問題は、人的ミスを減らす方法です。その方法を知るためには、何が起こったのか、なぜ起こったのかを知る必要がありました。
結局、シンプルで永続的な修正は、ロード前に構成ファイルに対して自動で「開始するかどうか」を確認するメッセージを表示して、最終的にシステムの構成に対する人間による介入を完全に排除することでした。現在、停止の原因となった課題は、迅速な技術的な修正によって防止されています。失敗したエンジニアは今でも Atlassian で働き、私たちのチームに大きく貢献してくれています。
アトラシアンは、シンプルで再現可能なプロセスを重視しており、誰も責めることのない事後分析も例外ではありません。私たちにとってうまくいくプロセスを考え出しましたので、こちらでその詳細を確認できます。また、Incident Handbook にも詳述されています。
PDF ハンドブックを入手する
インシデント管理ハンドブックの印刷版は、数量限定で無料配布しています。または、PDF 版をダウンロードしてください。
Statuspage でインシデント コミュニケーションを学ぶ
このチュートリアルでは、システム停止時にインシデント テンプレートを使用して効果的にコミュニケーションを取る方法について説明します。さまざまなサービス中断に適応可能です。
このチュートリアルを読むインシデントの事後分析プロセスの重要性
インシデント後レビューとも呼ばれるインシデントの事後分析レビューは、インシデント中に何が起こったかを調査して教訓を取り込むのに最適な方法です。
この記事を読む