「Postmortem Guide」を発表したとき、私は責任を問わない事後検証を行うことの価値と、継続的改善の文化を確立する方法について書きました。このシリーズの最後である事後検証の本記事では、効果的な事後検証ミーティングを開催する方法について説明します。
私が参加した最後の事後検証ミーティングでは、システムで何が起きたのか、どのように対応したのか、問題が二度と起こらないようにするためにどのような改善を加えるべきかを話し合いました。PagerDutyには責任を問わないという文化があるので、誰かを名指しで非難したり、感情を傷つけたりはしませんでした。しかし、継続的な改善をという点において、この会議時間を最も効果的に活用しているのかどうか疑問に思いました。
インシデントを最適に分析する方法については、多くの記事が書かれています。「事後分析をする」というと、とかく分析のプロセスと結果として得られるドキュメントの形式に焦点が当たる傾向があります。多くの場合、このプロセスは、分析の結果について話し合うための事後検証ミーティングで終わります。私たちは最近、なぜ事後検証が重要なのか、そしてどのように実践するべきかについての詳細な情報をコミュニティに提供するため、総合的なPostmortem Guideを始めました。しかし、このガイドのために研究を行っているとき、私は事後検証ミーティングそのものについてはほとんど書かれていないことに気づきました。
分析を実行し、事後検証のドキュメントを完成させることは、インシデントから学ぶための重要な最初のステップです。結果を議論するために会議をフォローアップすることで、チームは分析からさらに多くの価値を引き出すことができます。事後検証ミーティングの目的は、インシデントの原因に対する理解を深め、実際に行動を起こせるようにアクション項目に賛同を得ることです。
一緒に、そしてクールに
何が起こったのかについてのライブ会話をするために（物理的またはバーチャルに）部屋に集まると、分析は新しい方向に進み、すべての人にとって学習ポイントが深まります。 最も重要なのは、議論することで、同じ問題が再発するのを防ぐのに必要なアクションの優先順位にチームの賛同を得ることです。
これは、「言うは易く行うは難し」です。 事後分析をみんなで読むだけでは、この会議から最大の価値を引き出すことができません。感情が高まり会議の進行が困難になることもあります。チームが責任を問わない事後検証を実行するために最善を尽くしたとしても、彼らが犯したした失敗について議論するとき、人々はどうしても防御的になるでしょう。
私は元スクラムマスターとして、事後検証ミーティングと振り返り（retrospective）の類似点に気づきました。振り返りミーティングでは、チームは最後の反復がどのように行われたか、またどのように改善したいかを検討します。同様に、事後検証は過去のインシデントの考察とそこから学びを得るために行われます。チームが奮闘していると、ふりかえりミーティングは個人間の摩擦と感情的な反応を引き起こします。事後検証も恐れや怒りといった感情を伴うことがあります。
進行役を担う
PagerDutyでの事後検証ミーティングとふりかえりの運営方法には大きな違いが1つあります。ふりかえりはチームのアジャイルコーチによって進行されますが、事後検証ミーティングは通常Incident CommanderまたはPostmortem Ownerが主導します。
これら2つの会議の類似点を考慮すると、事後検証ミーティングも熟練した進行役の参加が重要であることに気付きました。会議における進行役の役割は、他の参加者とは異なります。彼らは彼ら自身の考えを表明するのではなく、議論を軌道に乗せ続け、メンバーに発言するよう促します。対応者が会議の進行役をやると、グループ全体の一体感を保ちながら彼らの経験やアイデアを共有することは困難であると学びました。
指名された進行役は、グループが会議の2つの主たる目標に集中するのを手助けします。
- インシデントにつながった原因についての理解を深めること
- 事後検証で明らかになったアクション項目への同意を得ること
チームが議論をしている間、進行役は全員が快適で誰か1人がミーティングを支配しないよう、グループダイナミクスに注意します。進行役がこれをどの程度きちんと実行しているか注目しましょう。
インシデントの原因を探る
進行役が直面する議論を妨げる2つの大きな課題があります。
- システム障害の責任を個人に負わせてしまう傾向がある
- 分析が深く掘り下げられていない
進行役は非難が起こりそうな時に会話の方向を変えることで、チームが責めを避けるようにすることができます。事後検証の目標は、どのような体系的要因がインシデントを引き起こしたのかを理解し、この種の失敗が再発するのを防ぐ方法を見つけることです。誰がミスを犯したのかではなく、ミスがどのように起きたかに焦点を絞るようにします。
進行役は、分析を妨げ、責任追及を暗示する「誰」や「なぜ」という質問を避け、代わりに「何」や「どのように」という言葉を使って「あなたは何が起こっていたと思いましたか」や「必要な支援をどうのように受けましたか」というような質問をしてください。
特定の対応者を抽象化した人間に置き換えることにより、ある行動についての責任追求を避けます。誰でも同じミスを犯した可能性があることをチームに思い出させてください。「何がその行動をとらせたのか」と尋ねることにより、誰か1人を責めるのではなく、グループ内の誰もがシステム障害の原因についての率直な意見を述べることができるようになります。
たとえあなたが責任追及を極力避けるという文化を持っていたとしても、インシデントにつながった多くの条件を深く理解するのは難しかったりします。進行役の役目は、グループに考えさせるために適切な質問をすることです。単純に「はい」または「いいえ」で答えることができる質問ではなく、常に自由回答形式の質問をしてください。会話の初心者は事後検証ガイドの分析用の質問を参照してください。
メンバーの賛同を得る
製品管理者や技術管理者など作業の優先度を決定するチームリーダーに、事後検証ミーティングへの参加を奨励するために、カスタマーエクスペリエンスに対する脅威と技術投資へのニーズについての見識が上がることを説明します。事後検証ミーティングは、行われるか、あるいは行われない作業に関する困難な決定と、それらの選択の予想される影響について話し合う機会です。
下手なチームダイナミクスは全員の積極的参加を妨げる可能性があります。進行役はこれらのパターンに注目してグループを導きます。1人が会議を支配している場合は、その人が言っていることを繰り返し（例：「◯◯ですね。それは分かりました」）、続けて「別の観点があれば聞きたいのですが」と他の人が話すのを促します。
誰かが人の発言を遮っていたら「初めの人の言ったことが聞こえませんでした」または「ちょっと待って。マリーさんの意見を最後まで聞かせて 」と言いましょう。
反対に、意見を話す人がいないときには「他に何か検討することがあるでしょうか？」と尋ねれば参加を促せます。
これらの会話のトリックにより、進行役は全員を参加させることができます。そして最も重要なのは、アクションプランへの合意に向かって会話を進めることです。たとえ最善の行動方針について意見の相違があったとしても、みんなが聞いたことがあると思えば、グループをアクションプランに参加させることができます。
成功のために進行役を配する
チームの議論をフォローして、あなたの事後検証分析を最大限に活用してください。ライブで会話をすることは、全員の学習を深め、新たな洞察につながる可能性があります。ただし、単にその会議をスケジュールして文書を一緒に読むだけでは不十分です。事後検証ミーティングを成功させるためには、熟練した進行役の助けを借りてください。
その他の円滑化のヒントと効果的な事後検証の実行方法については、「 Postmortem Guide」を参照してください。PagerDutyのフォーラムでは事後検証ミーティングからどのようにして最大の価値を得るかについてご意見を募集しています。
本記事は米国PagerDuty社のサイトで公開されているものをDigitalStacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
カテゴリー ：ベストプラクティス
