BLOG
Postmortem(事後検証) パート2:学習する文化を取り入れる方法

投稿:2019年4月11日   |    更新:2022年3月11日

事後検証(ポストモーテム)シリーズのパート2では、リーダーシップを発揮することから文化面での変化を起こすことまで、継続的な学習の文化を確立する方法を掘り下げます。

文化は私たちが物事を一つにする方法です。それは一貫した形で目標を満たす幸せで健康的なチームを作るための秘密のソースです。組織の中で定義し、育て、変革するのは最も難しいことです。真の文化的変化には、ポリシーを作って伝えること以上のことが必要です。コラボレーション、永続性、そして実験が必要です。

PagerDutyの私たちはアジャイルの方法論とDevOpsプラクティスの大ファンです。私たちは、ソフトウェア開発から文化の変化まで、継続的な改善の原則を適用しました。反復的な評価とコラボレーションを通じて、文化を正しい方向にシフトさせることができます。

これは別のコアなDevOpsプラクティスである事後検証に思い至らせます。事後検証の成功は単なるプロセスにかかっているのではなく、誠実さ、学び、説明責任の文化に基づいています。企業文化の変革には経営陣の参加が必要ですが、自分の役割に関係なく文化の変革を先導することができます。

身近なところから始めよう

あなたの会社のプロセスの全面的な見直しに着手する前に、どこから始めるのかを把握することは重要です。インシデント後の報告には事後検証プロセスを使用していますか? あなたが従うステップは何ですか? 誰が関与していますか? 失敗についての会話は通常どのように行われますか? あなたのチームがこれらの議論をすれば、関係者の責任を問わない事後検証を実施する文化への移行を始められると思います。

多くの企業は、重大インシデントの後に、何が起こったのかを検討する会議を開くでしょう。これらの議論の過程で少数の個人がインシデントに対する責任を負わされるのを見ることになるかもしれません。一般的に、全員がもう少し詳しく知る前に、将来問題を避けるための計画を立ててしまいます。さらに重要なことに、少数の人々があなたが避けたいと思う、かなり不愉快な気分で立ち去ります。

あなたのチームに迅速な監査ができるように事後検証の実施のためのステップバイステップガイドを見てください。現在していることや、現在何をしているけれど微調整する必要があるかもしれないこと、そしてしていないことは何でしょう?

責任を問わないことをリーダーに求める

事後検証を組織にまったく新しいやり方として紹介するにせよ、既存のプロセスを改善するために動いているにせよ、文化の変革は難しいものです。伝統的には変革より管理が優先されると思います、しかしボトムアップでの変革は通常もっと成功をもたらすものです。 あなたの役割が何であれ、新しいプロセスを導入するための最初のステップは、経営陣からの承認を得ることです。

変革について思慮深い推論を用いリーダーに近づくことが、その変革が持つはずの重要性と影響を強化するのを助けます。 そのための対話で重要な点は次のとおりです。

  • 責任追及がどれほど有害であるかを明確にし、定量化し、そして責任追及のビジネス上の価値を説明する。

  • 問題を「引き起こした」ことを理由に個人を罰する慣習は、問題が発生したときに人々が責任追及されることを恐れて発言しなくなるように仕向けます。結果としてインシデントを認識して解決するまでの平均時間が長くなり、最終的にはインシデントの影響が大きくなり、深刻な影響を受ける可能性があります。問題が発生したらできるだけ早く解決できるように、リーダーは人々に発言を求めてください。

  • 組織は責任追及される恐れを排除し、共同学習および反復的な設計の改善を促すことによって、システムの回復力を急速に向上させ、イノベーションのスピードを上げることができます。

さらに、バカみたいに聞こえるかもしれませんが、新しい事後検証プロセスを売りこむときに、管理側のせいにしないことを忘れないでください。リーダーがチームに加わっていることを確認してください。インシデント後に誤って責任追及を示唆した場合には、彼らがそのフィードバックを受け取るのを納得するというリーダーシップの確約を得ることが重要です。

ゴールは、継続的改善の文化を作るためにリーダーに確実に参加してもらうことです。

Pro tip:責任追及をしないという概念を会社の価値にマップできるかどうかを確認してください。例えばPagerDutyの文化的価値観の1つは、特に中断と継続的な改善を受け入れ、常に学習に集中することです。このような責任を問わない事後検証の概念は、これらの価値を支えることに直接対応できます。

チームを指導する

これでリーダーシップが完成しました。組織で大きな文化の変革を遂げることができました。次のステップはあなたのチームの個々のコントリビューターの参加を確保することです。彼らがまだ、インシデントの責任を追及されることを恐れているかもしれないことに留意してください。その恐れは、ポリシーだけでは消えないでしょう。インシデント対応後にどんな方法でも誰も罰せられることはない、という経営陣からのコミットメントを得ていることを必ず共有してください。責任をもっと意識して、責任が認められたらお互いに声をかけて協力することで、同僚との信頼関係を築きましょう。

グループ内での心理的安全性の重要性について読んでください。)

変革を繰り返す

文化の変革は一晩では起こりません。実験を成功させた結果を新しいプラクティスと共有し、次にそれらのプラクティスをチーム間でゆっくりと拡張するなど、小規模から始めて新しいプラクティスを組織に繰り返し導入します。

始め方:

  • チームを1人選び、完璧な事後検証の実験を始めましょう。 始めるには、「事後検証記録の書き方」ガイドを使用してヒントを共有してください。スキルを磨き、他の人に教えます。

  • 小さなインシデントから始めましょう。 小さなインシデントのビジネスへの影響は小さいため、インシデントの原因として個人をスケープゴートにする圧力は少なくなります。

  • 責任追及する人を批判しないでください。上記で推奨されているように、個人に責任を負わせがちな人を探してください。必ず声をかけて、チームがこのインシデントに対して新しい、責任追及のないアプローチを使用することを決定したことを伝えてください。

覚えておいてください:責任追及のない事後検証へのグループの信頼を築くために最初は単純なものから始めてください。チームにとって最適なものを試し、次のラウンドで繰り返します。

共有することはケアすること

組織のためでも、単一のチームのためであっても、文化的シフトを促すには大きなエネルギーを必要とします。試みられ、テストされ、そして最終的に採用される前に、それが「難しい」という単なる認識のために、変革は時に強く非難されることがあります。

インシデントレポートを共有することは、最初は直感に反するように思われるかもしれません。成功というより失敗のストーリーを共有するように思えますからね。でもそれとは全く反対に、チームは失敗から学んでシステムを改善し、失敗の発生率を減らせます。

インシデントを個人的な失敗としてではなく、具体的な改善をもたらす学習機会として再考することです。それは士気を高め、ひいては従業員の定着率と生産性を高めます。

批判しないことがアカウンタビリティを育てる

自由に情報を共有し、透明性を促すことで、説明責任を養う環境を支えられます。事後検証のあとに起きることは、システムの健全性にとって重要です。事後検証の行動項目が網羅されたと思われた時点でSLAを設定することは、チームがタスクを迅速に割り当て、優先順位を付けるのに役立ちます。また、許可を待たずにチームが行動に移れるようにします。

Pro-tip:このSLAをすべてのエンジニアリング部門に伝達し、将来の参考にするために必ず文書化してください。

PagerDutyでは、Sev-1インシデントの再発防止に必要な優先順位の高いアクションアイテム(行動項目)は、インシデントから15日以内に完了することを期待しています。Sev-2インシデントから得たアクションアイテムは30日以内に対処されるべきです。

カルチャーのチャンピオンになる

あなたの会社の文化を良い方向に変えることは、実現が最も難しい仕事のひとつです。信じられないほど微妙で、高レベルの共感を必要とし、そして感情的に疲れることです。継続的に学習する、責任を問わない文化を促進することは、より幸せなチームとより良いソフトウェアにつながるので、組織にとって最も重要でやりがいのある作業でもあります。

評価、コラボレーション、コミュニケーション、そして実証という具体的なステップを適用すれば組織を正しい方向に変えることができます。

  • 現在の事後検証プロセスの状況を知ることから始めましょう

  • リーダーとチームの了承を得て、責任を問わない事後検証を試しましょう

  • 1チームまたは小規模なインシデントで試してみてください

  • 実証結果を共有して、変化を広めてください

責任を問わない事後検証を採用する方法の詳細については、包括的な「Postmortem Guide」をご覧ください。あなたがどのようにして文化の変化にアプローチし、誠実さを広めているかをお聞きしたいです。当社のフォーラムにアクセスしてコミュニティと情報共有してください

本記事は米国PagerDuty社のサイトで公開されているものをDigitalStacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

book-markカテゴリー :ベストプラクティス