diff --git a/docs/culture/accountability.md b/docs/culture/accountability.md index e953564..5bbfed3 100644 --- a/docs/culture/accountability.md +++ b/docs/culture/accountability.md @@ -4,18 +4,18 @@ description: 成功するポストモーテムプロセスは、誠実さ、学 --- ![Accountability](../assets/img/headers/Postmortems-Accountability.png) -情報共有と透明性はまた、説明責任を育む環境をサポートします。ポストモーテムの効果を妨げる一般的な課題は、インシデントを分析し再発を防ぐためのアクションアイテムを作成した後、透明性を高めるための情報共有が行われないことです。 +情報共有と透明性は、説明責任（accountability）を育む環境をサポートします。ポストモーテムの効果を低減させるよくある課題として、インシデントを分析し再発を防ぐためのアクションアイテムを作成した後、透明性を高めるための情報共有が行われないことがあります。 -まず、ポストモーテムのアクションアイテムがいつ完了すべきかのポリシーを設定します。PagerDutyでは、Sev-1インシデントの再発を防ぐために必要な高優先度のアクションアイテムは、インシデント後15日以内に完了する必要があります。Sev-2インシデントからのアクションアイテムは30日以内に対処する必要があります。この期待をエンジニアリング全体に伝え、将来の参照のために文書化してください。 +まず、ポストモーテムのアクションアイテムがいつ完了すべきかのポリシーを設定します。PagerDutyでは、Sev-1インシデントの再発を防ぐのに必要な高優先度のアクションアイテムは、インシデント後15日以内に完了する必要があります。Sev-2インシデントからのアクションアイテムは30日以内に対処する必要があります。この期待値をエンジニアリング組織全体に伝え、将来的にも参照できるよう文書化してください。 -アクションアイテムが実行されるためには、明確なオーナーが必要です。私たちはアジャイルとDevOpsの組織であるため、影響を受けたサービスを担当するクロスファンクショナルチームも、障害の可能性を減らすと期待される改善の実装を担当します。エンジニアリングリーダーシップは、システムのどの部分を各チームが所有しているかを明確にし、新しい開発と運用改善を所有するチームに対する期待を設定します。所有権の指定は組織全体に伝えられ、すべてのチームが誰が何を所有しているかを理解し、所有権のギャップを特定できるようにします。**いつものように、この情報を将来の参照と新入社員のために文書化してください。**インシデントのアクションアイテムの所有権に関する不確実性は、アクションアイテムを所有する可能性のあるすべてのチームの代表者とのポストモーテム会議で議論されます。 +アクションアイテムが実行されるためには、明確なオーナーが必要です。私たちはアジャイルとDevOpsの組織であるため、影響を受けたサービスを担当する職能横断チームも、障害の可能性を減らすと見込まれる改善の実装を担当します。エンジニアリングのリーダー陣は、各チームがシステムのどの部分を所有しているかを明確にし、新規開発と運用改善を担当するチームに対する期待値を設定します。オーナーシップの指定は組織全体に伝えられ、誰が何を所有しているのかをすべてのチームが理解し、オーナーシップの認識にギャップがあれば特定できるようにします。**例によって、新たにチームに加わるメンバーのために、将来的にも参照できるようこの情報を文書化してください。**インシデントのアクションアイテムのオーナーシップに不確実なところがあれば、ポストモーテムミーティングにおいて、アクションアイテムを所有する可能性のあるすべてのチームの代表者との間で議論します。 -また、チームの作業の優先順位付けを担当するリーダー（プロダクトマネージャーとエンジニアリングマネージャー）をポストモーテム会議に参加させることで、アクションアイテムの完了に対する説明責任が向上しました。プロダクトマネージャーは良い顧客体験を定義する責任があります。インシデントは顧客体験を悪化させます。ポストモーテムの議論にプロダクトマネージャーを参加させることで、顧客体験への脅威とその体験を改善する方法についてより広い視点を提供することを説明します。これにより、エンジニアリングはこれらのアクションアイテムの重要性を説明し、プロダクトマネージャーがそれに応じて作業の優先順位を付けることができます。同様に、エンジニアリングリーダーシップをポストモーテムの議論により多く参加させることで、技術リソースをどのように、どこに投資すべきかを知らせるシステムの弱点についてより良い理解を得ることができます。この文脈を作業の優先順位を付けるリーダーと共有することで、高優先度のアクションアイテムをインシデント分析から迅速に完了するチームの努力をサポートすることができます。 +また、チームの作業の優先順位付けを担当するリーダー（プロダクトマネージャーとエンジニアリングマネージャー）をポストモーテムミーティングに参加させることで、アクションアイテムの完了に対する説明責任が向上します。プロダクトマネージャーには、よい顧客体験を定義する責任があります。インシデントは顧客体験を悪化させます。ポストモーテムの議論にプロダクトマネージャーに参加してもらい、顧客体験に対する脅威とその体験を改善する方法についてより広い視点を提供してもらいます。これによって、エンジニアリングはこれらのアクションアイテムの重要性を説明し、プロダクトマネージャーがそれに応じて作業の優先順位を付けることができます。同様に、より多くのエンジニアリングのリーダー陣をポストモーテムの議論に参加させることで、技術リソースをどこへどのように投資すべきかの判断につながるような、システムの弱点に関する理解を深めることができます。この文脈を作業の優先順位付けを行うリーダーと共有することで、インシデント分析から発生した高優先度のアクションアイテムを迅速に完了できるよう、チームの取り組みを支援できます。 -最後に、ポストモーテムのアクションアイテムが発見可能で定期的に確認されるようにします。ポストモーテムのアクションアイテムを他のタスクと同様に文書化します。インシデント分析からのアクションアイテムのリストは、ポストモーテム文書にのみ存在するべきではありません。タスク管理ツールでチケットを開き、アクションアイテムを所有するチームのプロジェクト内に配置して、他のすべての計画された作業と一緒に表示できるようにします。すべてのチケットに重大度レベル（Sev-1、Sev-2など）と日付タグ（YYYYMMDD）を付けて、特定のインシデントからのチケットを簡単に照会し、重大なインシデントからのオープンチケットの数のレポートを作成できるようにします。 +最後に、ポストモーテムのアクションアイテムを見つけやすく、定期的に確認できるようにしておきます。ポストモーテムのアクションアイテムを他のタスクと同様に文書化しましょう。インシデント分析から発生したアクションアイテムのリストは、ポストモーテムの文書にのみ記載しておくだけでは足りません。タスク管理ツールでチケットをオープンし、アクションアイテムを所有するチームのプロジェクト内に配置して、他にも計画されたすべての作業と一緒に表示できるようにします。すべてのチケットに重大度レベル（Sev-1、Sev-2など）と日付タグ（YYYYMMDD）を付けて、特定のインシデントからのチケットを簡単に照会し、重大なインシデント起点でオープンしているチケットの数のレポートを作成できるようにします。 !!! info "重要なポイント" - - ポストモーテムのアクションアイテムのポリシーを設定する：例えば、Sev-1アクションアイテムは15日以内、Sev-2アクションアイテムは30日以内。 - - ポストモーテムのアクションアイテムの所有権を明確にする。 - - 作業の優先順位付けを行うリーダーを参加させる。 - - ポストモーテムのアクションアイテムのチケットを作業管理チケットシステムで開く。 + - ポストモーテムのアクションアイテムのポリシーを設定すること：例えば、Sev-1アクションアイテムは15日以内、Sev-2アクションアイテムは30日以内。 + - ポストモーテムのアクションアイテムのオーナーシップを明確にすること。 + - 作業の優先順位付けを行うリーダーを参加させること。 + - ポストモーテムのアクションアイテムのチケットを、タスク管理システムでオープンすること。 diff --git a/docs/culture/blameless.md b/docs/culture/blameless.md index 3b9d976..12f14e8 100644 --- a/docs/culture/blameless.md +++ b/docs/culture/blameless.md @@ -4,52 +4,51 @@ description: 成功するポストモーテムプロセスは、誠実さ、学 --- ![Blameless](../assets/img/headers/Postmortems-Blameless.png) -IT専門家として、私たちは複雑なシステムでは障害が避けられないことを理解しています。**障害が発生した時にどう対応するかが重要です。** _[The Field Guide to Understanding Human Error](https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/0754648265)_ の中で、Sidney Dekkerは人的エラーに関する2つの見方を説明しています：1）古い見方では、人々のミスが障害の原因であるとし、2）新しい見方では、人的エラーをシステム的問題の症状として扱います。古い見方は「腐ったリンゴ理論」に従い、悪い行為者を取り除けば障害を防げると信じています。この見方は個人の性格を彼らの行動に結びつけ、過失や悪意がエラーにつながると想定しています。 +情報技術のプロフェッショナルとして、私たちは複雑なシステムでは障害が避けられないことを理解しています。**重要なのは、障害が発生した時にどう対応するかです。** _[The Field Guide to Understanding Human Error](https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/0754648265)_ の中で、Sidney Dekkerはヒューマンエラーに関する2つの見方を説明しています：1）古い見方では、人々のミスが障害の原因であるとし、2）新しい見方では、ヒューマンエラーをシステム的な問題の症状として扱います。古い見方では「腐ったリンゴ理論」のように、望ましくない行いをする人を取り除けば障害を防げると信じられています。この見方は個人の性格を彼らの行動に結びつけ、過失や悪意がエラーにつながると想定しているのです。 -この人的エラーに関する古い見方に従う組織は、インシデントに対応する際に、インシデントを引き起こした不注意な個人を見つけて叱責することがあります。**非難し罰することへのこの衝動は、将来の障害を防ぐために必要な知識共有を妨げるという意図しない効果をもたらします。** エンジニアは非難されることを恐れて、インシデントが発生した際に発言することをためらうでしょう。この沈黙はインシデントの平均確認時間、平均解決時間を増加させ、インシデントの影響を悪化させます。 - -ポストモーテムプロセスが学習とシステム改善につながるためには、人的エラーに関する新しい見方に従う必要があります。ソフトウェア開発の複雑なシステムでは、様々な条件が相互作用して障害につながります。**ポストモーテムの目的は、インシデントにつながったシステム的要因を理解し、この種の障害が再発するのを防ぐためのアクションを特定することです。** ブレームレス（非難のない）なポストモーテムは、ミスを「誰が」犯したかではなく、ミスが「どのように」発生したかに焦点を当てます。これは、多くの先進的な組織（例えば[ブレームレスなポストモーテム](https://codeascraft.com/2012/05/22/blameless-postmortems/)のパイオニアであるEtsy）が活用している重要なマインドセットであり、罰の恐怖を排除することで、エンジニアが実際に何が起こったかについて真に客観的な説明をできるようにし、ポストモーテムが適切なトーンを持つことを保証します。 +ヒューマンエラーに関する古い見方に従う組織では、不注意によってインシデントを引き起こした個人が叱責されることがあります。**このように非難を行い罰することへの衝動は、将来の障害を防ぐ上で必要な知識共有を妨げるという予期せぬ影響をもたらします。** エンジニアは非難されることを恐れて、インシデントが発生した際に発言することをためらうでしょう。この沈黙はインシデントの平均確認時間（MTTA）、平均解決時間（MTTR）を増加させ、インシデントの影響を悪化させます。 +ポストモーテムプロセスを学習とシステム改善につなげるためには、ヒューマンエラーに関する新しい見方に従う必要があります。ソフトウェア開発の複雑なシステムでは、様々な条件が相互作用して障害を引き起こします。**ポストモーテムの目的は、インシデントの発生につながったシステム的要因を理解し、この種の障害が再発するのを防ぐためのアクションを特定することです。** ブレームレス（非難のない）なポストモーテムは、「誰が」ミスを犯したかではなく、「どのように」ミスが発生したかに焦点を当てます。これは、多くの先進的な組織（例えば[ブレームレスなポストモーテム](https://codeascraft.com/2012/05/22/blameless-postmortems/)のパイオニアであるEtsy）が活用している重要なマインドセットであり、罰に対する恐怖を排除することにより、実際に何が起こったかをエンジニアが真の意味で客観的な説明をできるようにし、ポストモーテムが適切なトーンで行われることを保証します。 ## なぜブレーム（非難）を意識することが難しいのか -継続的改善の文化を望むことは簡単ですが、学習に必要なブレームレスさを実践することは難しいです。障害の予期せぬ性質は、人間が自然とそれを理解する妨げとなる方法で反応することにつながります。情報を処理する際、人間の心は無意識のうちにショートカットを取ります。一般的な経験則を適用することで、心は正確さよりもタイムリーさを最適化します。これが誤った結論を生み出す場合、それは認知バイアスです。 +継続的改善の文化を望むことは簡単ですが、学習に求められる非難のない状態の実践は難しいです。障害の予期せぬ性質は、自ずと人間が理解する妨げとなるような反応をすることにつながります。情報を処理する際に、人間の心は無意識のうちにショートカットを取ります。一般的な経験則を適用することで、心は正確さよりもタイムリーさを最適化します。これが誤った結論を生み出す場合、それは認知バイアスと呼ばれます。 -[J. Paul Reed](https://techbeacon.com/blameless-postmortems-dont-work-heres-what-does)は、非難する傾向が何百万年もの進化的神経生物学によって配線されているため、ブレームレスなポストモーテムは神話だと主張しています。この傾向を無視したり、完全に排除しようとしたりすることは不可能です。「ブレーム・アウェア（非難を意識する）」であることの方が生産的です。**私たちのバイアスを意識することで、それらが発生した時に識別し、それを乗り越えるために取り組むことができるでしょう。** 以下ではいくつかのバイアスについて触れますが、詳細については、ポストモーテムを実施する際に意識すべき認知バイアスについての[Lindsay Holmwood](http://fractio.nl/2015/10/30/blame-language-sharing/)の記事をお読みください。 +[J. Paul Reed](https://techbeacon.com/blameless-postmortems-dont-work-heres-what-does)は、非難する傾向が何百万年もの進化的神経生物学によって配線されているため、ブレームレスなポストモーテムは神話だと主張しています。この傾向を無視したり、完全に排除しようとしたりすることは不可能です。「ブレームアウェア（非難を意識する）」であることの方が生産的です。**私たちのバイアスを意識することで、それらが発生した時に識別し、乗り越える取り組みを行えるでしょう。** 以下ではいくつかのバイアスについて触れますが、詳細については、ポストモーテムを実施する際に意識すべき認知バイアスについての[Lindsay Holmwood](http://fractio.nl/2015/10/30/blame-language-sharing/)の記事をお読みください。 -**[基本的帰属エラー](https://en.wikipedia.org/wiki/Fundamental_attribution_error)**は、人々が行うことが彼らの状況ではなく性格を反映していると信じる傾向です。これは人的エラーの古い見方を表し、障害の責任を不注意で無能な悪い行為者に帰します。皮肉なことに、私たちは自分自身の行動を説明する際には、自分の性格ではなく状況によって説明する傾向があります。この非難する傾向と戦うには、分析を個人が取った具体的な行動ではなく、状況的な原因に意図的に焦点を当てることです。 +**[基本的帰属エラー（fundamental attribution error）](https://en.wikipedia.org/wiki/Fundamental_attribution_error)**は、人々の行動が、彼らの状況ではなく性格を反映したものであると信じる傾向です。これはヒューマンエラーの古い見方を表し、障害を不注意で無能な悪い人物のせいにします。皮肉なことに、私たちは自分自身の行動を説明する際には、自分の性格ではなく状況によって説明する傾向があります。この非難する傾向と戦うには、個人が取った具体的な行動ではなく、状況的な原因へ意図的に分析の焦点を当てることです。 -もう一つの広く見られる認知バイアスは**確証バイアス**で、これは既存の信念を強化する情報を好む傾向です。曖昧な情報に直面すると、私たちはそれを既存の仮定を支持する方法で解釈する傾向があります。人的エラーの古い見方と組み合わさると、このバイアスはポストモーテムにとって危険です。なぜなら、それは腐ったリンゴを非難しようとするからです。個人に責任があるという仮定でアプローチすると、反対の証拠があるにもかかわらず、その信念を支持する方法を見つけるでしょう。 +もう一つの広く見られる認知バイアスは**確証バイアス（confirmation bias）**で、これは既存の信念を強化する情報を好む傾向です。曖昧な情報に直面すると、私たちはそれを既存の仮定を支持する方法で解釈する傾向があります。ヒューマンエラーの古い見方と組み合わさると、このバイアスはポストモーテムにとって危険です。なぜなら、それは腐ったリンゴを非難しようとする流れにつながるからです。個人に責任があるという仮定でアプローチすると、反対の証拠があるにもかかわらず、その信念を支持する方法を探してしまうでしょう。 -確証バイアスと戦うために、Holmwoodは調査中に反対の視点を取る悪魔の代弁者を任命することを提案しています。悪魔の代弁者によって否定性や対立性を導入することには注意してください。また、他のチームから誰かを招いて、彼らの心に浮かぶあらゆる質問をしてもらうことで、確証バイアスに対抗することもできます。これにより、チームが当然と考えるようになった調査の方向性が明らかになります。 +確証バイアスと戦うために、調査の過程で逆の立場をとる代弁者を任命することをHolmwoodは提案しています。ただし、逆の立場をとる代弁者によって否定性や対立性をが持たされることには注意してください。また、他のチームから誰かを招いて、彼らの心に浮かぶあらゆる質問をしてもらうことで、確証バイアスに対抗することもできます。これにより、チームが当然と考えるようになった調査の方向性が明らかになります。 -**後知恵バイアス**は、判断を形成するために事象を思い出す際の記憶の歪みの一種です。結果を知っていると、それを予測する客観的な根拠がほとんどまたは全くなかったにもかかわらず、その事象が予測可能だったと簡単に見なすことができます。しばしば、私たちは自分自身をより良く見せるために事象を思い出します。例えば、インシデントの原因を分析している人が、それがそのように起こることを知っていたと信じる場合です。このバイアスを実行すると、チーム内の防御と分裂につながる可能性があります。Holmwoodは、後知恵バイアスを避けるために、事象を予見の観点から説明することを提案しています。タイムライン分析をインシデントの前の時点から始め、解決から逆算するのではなく、前に進むようにしましょう。 +**後知恵バイアス（hindsight bias）**は、判断を形作るために事象を思い出す際の記憶の歪みの一種です。結果を知っていると、当時はそれを予測する客観的な根拠がほとんどまたは全くなかったにもかかわらず、その事象が容易に予測可能だったと見なしてしまいがちです。しばしば、私たちは自分自身をよりよく見せるようなやりかたで出来事を思い出します。例えば、インシデントの原因を分析している人が、それが起こるとを予期していたと信じる場合が挙げられます。このバイアスを体現すると、チーム内の防御と分裂を招きかねません。Holmwoodは、後知恵バイアスを避けるために、事象を予見の観点から説明することを提案しています。すなわちタイムライン分析をインシデント発生前の時点から始め、解決から逆算するのではなく、前に進むようにするのです。 -注意すべきもう一つの一般的なバイアスは**[否定性バイアス](https://en.wikipedia.org/wiki/Negativity_bias)**です。これは、より否定的な性質のものが、中立的または肯定的な性質のものよりも、人の精神状態に大きな影響を与えるという概念です。社会的判断に関する研究では、否定的な情報が他者に対する人の印象に不釣り合いな影響を与えることが示されています。これは「腐ったリンゴ理論」、つまり組織内に障害の責任を負うべき否定的な行為者がいるという信念に関連しています。研究はまた、人々が否定的な結果を他の人の意図に帰する可能性が、中立的および肯定的な結果よりも高いことを示しています。これもまた、重大なインシデントを説明するために個人の性格を非難する傾向を説明しています。 +注意すべきもう一つの一般的なバイアスは**[否定性バイアス（negativity bias）](https://en.wikipedia.org/wiki/Negativity_bias)**です。これは、否定的な性質のもののほうが、中立的または肯定的な性質のものよりも、人の精神状態に大きな影響を与えるという概念です。社会的判断に関する研究では、他者に対する印象に、否定的な情報がとてつもなく大きな影響を与えることが示されています。これは「腐ったリンゴ理論」、つまり組織内に障害の責任を負うべき好ましくない人物がいるという信念に関連しています。研究はまた、人々が否定的な結果を他の人の意図によるものだとする可能性が、中立的および肯定的な結果よりも高いことを示しています。これもまた、重大なインシデントを説明するために個人の性格を非難する傾向を説明しています。 -実際には、物事がうまくいくことの方が、うまくいかないことよりも多いのですが、私たちは否定的な出来事に焦点を当て、その重要性を拡大する傾向があります。インシデントを否定的な出来事として焦点を当て、誇張し、内面化することは、士気を低下させ、燃え尽き症候群につながる可能性があります。インシデントを学習の機会として再構築し、対応でうまく処理されたことを説明することを忘れないようにすることで、視点のバランスを取るのに役立ちます。 +実際には、物事がうまくいくことの方が、うまくいかないことよりも多いのですが、私たちは否定的な出来事に焦点を当て、その重要性を協調する傾向があります。インシデントを否定的な出来事として焦点を当て、誇張し、内面化することは、士気を低下させ、燃え尽き症候群を招く可能性があります。インシデントを学習の機会として再構築し、対応でうまく処理されたことを説明することを忘れないようにすることで、視点のバランスを取っていきましょう。 ### 認知バイアス | バイアス | 定義 | 対策 | |---|---|---| -| 基本的帰属エラー | 人々が行うことが彼らの状況ではなく性格を反映している。 | |分析を個人が取った具体的な行動ではなく、状況的な原因に意図的に焦点を当てる。 | -| 確証バイアス | 既存の立場を強化する情報を好む。 | 調査中に反対の視点を取る悪魔の代弁者を任命する。 | -| 後知恵バイアス | 結果を知っているため、それを予測する客観的な根拠がほとんどまたは全くなかったにもかかわらず、インシデントが避けられなかったと見なす。 | 事象を予見の観点から説明する。タイムライン分析をインシデントの前の時点から始め、解決から逆算するのではなく、前に進む。 | +| 基本的帰属エラー | 人々の行動には彼らの状況ではなく性格が反映されているものとみなす。 | |分析を個人が取った具体的な行動ではなく、状況的な原因に意図的に焦点を当てる。 | +| 確証バイアス | 既存の立場を強化する情報を好む。 | 調査の過程で逆の立場の代弁者を任命する。 | +| 後知恵バイアス | 結果を知っているため、それを予測する客観的な根拠がほとんどまたは全くなかったにもかかわらず、インシデントが避けられなかったとみなす。 | 事象を予見の観点から説明する。タイムライン分析をインシデントの前の時点から始め、解決から逆算するのではなく、前に進む。 | | 否定性バイアス | より否定的な性質のものが、中立的または肯定的なものよりも、人の精神状態に大きな影響を与える。 | インシデントを学習の機会として再構築し、インシデント対応でうまく処理されたことを説明することを忘れないようにする。 | -私たち全員が、チェックされなければ事象の歪んだ見方につながり、チームの関係を損なう可能性のあるこれらの認知バイアスを持っています。これらの傾向を意識することで、バイアスが発生した時に認識することが重要です。ポストモーテムを共同プロセスにすることで、チームはグループとして非難を特定し、分析をより深く掘り下げることができます。 +私たち全員がこれらの認知バイアスを持っていて、見過ごされると事象の歪んだ見方につながったり、チームの関係を損なったりする可能性があります。これらの傾向を意識することで、バイアスが発生した時に認識することが重要です。ポストモーテムを共同プロセスにすることで、チームはグループとして非難を特定し、分析をより深く掘り下げることができます。 ## ブレームレス（または非難を意識した）文化をどのように育むか -非難を認識し、それを乗り越えることは言うは易く行うは難しです。ブレームレスな文化に向けてどのような行動を採用できるでしょうか？Holmwoodは、非難を最小限に抑え、学習を最大化するために使用する言葉の重要性について雄弁に書いています。彼は「何」という質問（例えば、「何が起きていると思いましたか？」「次に何をしましたか？」）をするよう促しています。「何」という質問をすることで、インシデントに寄与した大きな要因に分析の基礎を置きます。 +非難を認識し、それを乗り越えることは、言うは易く行うは難しです。ブレームレスな文化に向けてどのような行動をとればよいでしょうか？Holmwoodは、非難を最小限に抑え、学習を最大化するために使用する言葉の重要性について雄弁に書いています。彼は「何」という質問（例えば、「何が起きていると思いましたか？」「次に何をしましたか？」）をするよう促しています。「何」という質問をすることで、インシデントに寄与した大きな要因に分析の基礎を置きます。 彼の記事「[The Infinite Hows](https://www.oreilly.com/ideas/the-infinite-hows)」の中で、John Allspawは「どのように」という質問をするよう勧めています。なぜなら、それらは人々に出来事が起こることを可能にした条件（少なくともいくつか）を説明させるからです。Holmwoodもまた、「どのように」という質問が技術的な詳細を明確にし、人々を彼らが取った行動から距離を置かせるのに役立つと指摘しています。「なぜ」という質問は避けてください。なぜなら、それは人々に自分の行動を正当化させ、非難を帰することになるからです。 -[Crucial Accountability](https://www.vitalsmarts.com/crucial-accountability-training/)は、感情が高まった時にポストモーテムに適用できる、満たされない期待についての難しい会話にアプローチするための役立つフレームワークを提供しています。障害を分析する際、私たちは感情を駆り立て、最悪の行動を正当化しようとする被害者、悪役、無力な物語に陥る可能性があります。物語の残りの部分を語ることで、非難を超えることができます。問題におけるあなた自身と他者の役割を考慮してください。合理的で理性的で良識のある人が、インシデントの原因となったように見える行動を取った理由を自問してください。この思考は、インシデントにつながった複数のシステム的要因に注意を向けるのに役立ちます。 +[Crucial Accountability](https://www.vitalsmarts.com/crucial-accountability-training/)では、期待と現実の不一致に関する難しい会話にアプローチするのに役立つフレームワークが提供されており、感情が高まるようなポストモーテムにも適用できます。障害を分析する際、私たちは感情を駆り立て、最悪の行動を正当化しようとする被害者、悪役、無力な物語に陥る可能性があります。物語の残りの部分を語ることで、非難を乗り越えることができます。問題における、あなた自身と他者の役割を考慮してください。合理的で理性的で良識のある人が、インシデントの原因となったように見える行動を取った理由を自問してください。この思考は、インシデントにつながった複数のシステム的要因に注意を向けるのに役立ちます。 -最善の努力をしてブレームレスであろうとしても、ポストモーテムミーティング中に誰かが非難されていると感じて防御的になる可能性があります。これが起こった場合、生産的な議論を続けるために相互の目的と相互の尊重を回復するよう努めてください。ポストモーテムの目的はインシデントにつながったシステム的要因を理解し、将来の障害を減らすためのアクションを共同で特定することであることを再確認することで、相互の目的を回復します。しばしば、人々は自分の性格が攻撃されていると感じると防御的に行動します。対比することで相互の尊重を回復します。あなたが意図しなかったこと（「あなたが仕事が下手だと言うつもりはありませんでした」）と、あなたが意図したこと（「任意の対応者がその行動を取るような状況的要因を尋ねるつもりでした」）を対比させてください。非難を暗示する個人の動機から調査の焦点を外してください。特定されていない対応者に抽象化することで、他の対応者がシステム障害に寄与した可能性のあることについてより多くの提案をするよう促します。 +最善の努力をしてブレームレスであろうとしても、ポストモーテムミーティング中に誰かが非難されていると感じて防御的になる可能性があります。これが起こった場合、生産的な議論を続けるために互いの目的意識と尊重を回復するよう努めてください。ポストモーテムの目的はインシデントにつながったシステム的要因を理解し、将来の障害を減らすためのアクションを共同で特定することだと再確認することで、相互の目的意識を回復します。しばしば、人々は自分の性格が攻撃されていると感じると防御的に行動します。対比することで相互の尊重を回復します。あなたが意図しなかったこと（「あなたが仕事が下手だと言うつもりはありませんでした」）と、あなたが意図したこと（「任意の対応者がその行動を取るような状況的要因を尋ねるつもりでした」）を対比させてください。非難を暗示する個人の動機から調査の焦点を外してください。特定されていない対応者に抽象化することで、システム障害に寄与した可能性のあることについて、他の対応者がより多くの提案を行いやすくなります。 !!! info "重要なポイント" - - 「誰が」や「なぜ」ではなく、「何を」と「どのように」という質問をする。 + - 「誰が」「なぜ」ではなく、「何を」「どのように」という質問をする。 - 複数の多様な視点を考慮する。 - 合理的で理性的で良識のある人が特定の行動を取った理由を自問する。 - 人間の行動について尋ねる際、特定されていない対応者に抽象化する。誰でも同じミスを犯す可能性がある。 diff --git a/docs/culture/introduce.md b/docs/culture/introduce.md index 2b1f406..7f23d6b 100644 --- a/docs/culture/introduce.md +++ b/docs/culture/introduce.md @@ -6,26 +6,26 @@ description: 成功するポストモーテムプロセスは、誠実さ、学 ポストモーテムを組織に全く新しい実践として導入する場合でも、既存のプロセスを改善する場合でも、文化の変革は難しいものです。あなたの役割に関わらず、新しいプロセスを導入する最初のステップは、リーダーシップと個々の貢献者から賛同を得ることです。なぜなら、多くの場合、ボトムアップの変化は経営陣からのトップダウンの指示よりも成功する可能性が高いからです。 -非難のないポストモーテムを実践し、継続的改善の文化を促進するためには、インシデント後に個人が何らかの形で叱責されることはないというリーダーシップからのコミットメントが必要です。 +非難のない（ブレームレスな）ポストモーテムを実践し、継続的改善の文化を促進するためには、インシデント後に個人が何らかの形で叱責されることはないというリーダーシップからのコミットメントが必要です。 -非難のない分析へのシフトを経営陣に納得させるためには、非難がビジネスにどのように有害であるかを明確にし、非難のなさのビジネス価値を説明してください。例えば、インシデントを「引き起こした」個人を罰することは、非難されることを恐れて問題が発生したときに発言することを躊躇させます。この沈黙はインシデントの平均確認時間、平均解決時間を増加させ、最終的にはインシデントの影響を悪化させます。組織は、非難の恐怖を排除し、協力的な学習を奨励することで、システムの回復力を迅速に向上させ、イノベーションのスピードを上げることができます。 +経営陣の納得を得ながら非難のない分析への転換を進めるためには、非難がビジネスにどのように有害であるかを明確にし、非難がない状態のビジネス価値を説明しましょう。例えば、インシデントを「引き起こした」個人を罰すると、人は非難されることを恐れて問題が発生したときに発言を躊躇します。この沈黙はインシデントの平均確認時間（MTTA）、平均解決時間（MTTR）を増加させ、最終的にはインシデントの影響を悪化させます。組織は、非難に対する恐怖を排除し、協力的な学習を奨励することで、システムの回復力を迅速に向上させ、イノベーションのスピードを上げることができます。 -奇妙に聞こえるかもしれませんが、経営陣に非難のないポストモーテムプロセスを売り込む際には、他者を非難したことで経営陣を非難することは避けてください。非難のなさを実践することは誰にとっても難しいことを認識してください。チームは、インシデント後に非難が観察された場合、お互いに責任を持ち、指摘することができます。リーダーシップがインシデント後に誤って非難を示唆した場合、そのフィードバックを受け入れる意思があるかどうかを尋ねてください。 +奇妙に聞こえるかもしれませんが、経営陣に非難のないポストモーテムプロセスを売り込む際には、過去に他者を非難したことで経営陣を非難することは避けてください。ブレームレスを実践することは誰にとっても難しいことを認識しましょう。チームは、インシデント後に非難が観察された場合、お互いに責任を持ち、指摘することができます。リーダー陣がインシデント後に誤って非難めいた発言をした場合、そのフィードバックを受け入れる意思があるかどうかを尋ねてください。 -インシデントを引き起こしたことで人々を罰しないという経営陣からの口頭でのコミットメントは、非難のないポストモーテムを導入する重要な第一歩ですが、それだけでは非難の恐怖を排除するには不十分です。リーダーシップの支持を得たら、ポストモーテム分析を実行する個々の貢献者からも賛同を得る必要があります。インシデント後に誰も罰せられないという経営陣からのコミットメントを共有してください。非難が信頼と協力に有害である理由をチームに説明してください。非難をより意識し、非難が観察されたときにお互いに優しく指摘することに協力することに同意してください。 +インシデントを引き起こしたことで人々を罰しないという経営陣からの口頭でのコミットメントは、非難のないポストモーテムを導入する重要な第一歩ですが、それだけでは非難の恐怖を排除するには不十分です。リーダーシップの支持を得たら、ポストモーテム分析を実行する個々の貢献者からも賛同を得る必要があります。インシデント後に誰も罰せられないという経営陣からのコミットメントを共有してください。そして、非難が信頼と協力に有害である理由をチームに説明しましょう。非難をより意識し、非難が観察されたときにお互いに優しく指摘することに協力することに同意してください。 -Googleがチームを研究して、グループを成功させる行動を学んだとき、心理的安全性がチームがうまく協力するための最も重要な要素であることがわかりました。ハーバード・ビジネス・スクールの教授エイミー・エドモンドソンは、心理的安全性を「チームが発言することで誰かを恥じさせたり、拒絶したり、罰したりしないという自信」と定義しています。安全の感覚は、インシデントに関する情報を共有するのに十分な快適さを人々に与え、それによってより深い分析が可能になり、システムの回復力を向上させる学びにつながります。 +Googleが、チームに対する研究を行いグループを成功させる行動を学んだとき、チームがうまく協力するための最も重要な要素は心理的安全性であることがわかりました。ハーバード・ビジネス・スクールの教授エイミー・エドモンドソンは、心理的安全性を「チームが発言することで誰かを恥じさせたり、拒絶したり、罰したりしないという自信」と定義しています。安全の感覚は、インシデントに関する情報を共有するのに十分な快適さを人々に与え、それによってより深い分析が可能になり、システムの回復力を向上させる学びにつながります。 -Googleは、心理的安全性の高い高パフォーマンスチームが2つの重要な行動を共有していることを発見しました。まず、これらのチームは会話のターンテイキングを示します。チームメンバーはほぼ同じ割合で話します。全員が自分の視点を共有できるとき、グループの集合知が増加します。第二に、良いチームは高い社会的感受性または共感を持っています。成功したチームは、非言語的な手がかりに基づいて誰かが動揺したり取り残されたりしていることを感じることができます。 +Googleは、心理的安全性の高いハイパフォーマンスチームに共通する2つの重要な行動があることを発見しました。まず、これらのチームでは参加者みんなに会話の順序が回ってきます。チームメンバーはほぼ同じ割合で話します。全員が自分の視点を共有できるとき、グループの集合知が増加します。第二に、よいチームは高い社会的感受性または共感を持っています。成功したチームは、非言語的な手がかりに基づいて誰かが動揺したり取り残されたりしていることを感じとることができます。 -これらの行動と結果としての心理的安全性の感覚は、脆弱性をモデル化することで奨励することができます。Googleのマネージャーは、全員が自分自身について何か個人的なことを共有するアイスブレーカー活動をした後、チームがより良く協力する方法を見つけることができたことに気づきました。マネージャーはがんとの闘いについてチームに話すことから始め、それが他の全員がより快適に共有することを助けました。チーム内で感情的な絆を作ることは、より大きな心理的安全性と高いパフォーマンスにつながります。 +これらの行動と結果としての心理的安全性の感覚は、弱みをモデル化することで奨励することができます。Googleのマネージャーは、全員が自分自身について何か個人的なことを共有するアイスブレーカー活動をした後、チームがより良く協力する方法を見つけることができたことに気づきました。マネージャーはがんとの闘いについてチームに話すことから始め、それが他の全員がより快適に共有することを助けました。チーム内で感情的な絆を作ることは、より大きな心理的安全性と高いパフォーマンスにつながります。 -文化の変革は一夜にして起こるものではありません。新しい実践を組織に反復的に導入するには、小さく始め、新しい実践で実験することの成功した結果を共有し、それらの実践をチーム間で徐々に拡大していきます。単一のチーム内で非難のないポストモーテムの実験を始めることができます。始めるには、私たちの[「ポストモーテムの書き方」](../how_to_write/writing.md)ガイドを使用してヒントを共有してください。 +カルチャーの変化は一夜にして起こるものではありません。新しい実践を組織に反復的に導入するには、小さく始め、新しい実践を実験した成功結果を共有し、それらの実践をチーム間で徐々に拡大していきます。まずは、単一のチーム内で非難のないポストモーテムの実験を始めるとよいでしょう。始めるには、私たちの[「ポストモーテムの書き方」](../how_to_write/writing.md)ガイドを使用してヒントを共有してください。 -また、より小さなインシデントのポストモーテムを実践することから始めるのも簡単です。より小さなインシデントのポストモーテムを行うことで、チームはインシデントへの人々の貢献を超えた、より深いシステム分析のスキルを開発することができます。これはまた、全員が非難のない文化を実践している間、個人を保護するのにも役立ちます。人々は非難に戻るかもしれませんが、同じミスがより重大なインシデントで起こった場合よりも、個人への影響は少なくなります。 +また、より小さなインシデントのポストモーテムを実践することから始めるのもよいでしょう。小さなインシデントのポストモーテムを行うことで、チームはインシデントへの個々人の貢献に留まらず、より深いシステム分析のスキルを高めることができます。これはまた、全員が非難のない文化を実践している間、個々人を保護するのにも役立ちます。人々は非難に戻ってしまうこともあるかもしれませんが、同じ失敗がより重大なインシデントで起こった場合よりも、個人への影響は少なくなります。 !!! info "重要なポイント" - - 非難のなさのビジネス価値を売り込む：より迅速なインシデント解決、より回復力のあるシステム、イノベーションのための時間の増加 - - 非難が観察されたときにお互いに優しく指摘することを約束する - - 単一のチームから始める - - より小さなインシデントから始める + - 非難のない状態（ブレームレス）のビジネス価値を売り込むこと：より迅速なインシデント解決、より回復力のあるシステム、イノベーションのための時間の増加 + - 非難が観察されたときにお互いに優しく指摘することを約束すること + - 単一のチームから始めること + - より小さなインシデントから始めること diff --git a/docs/culture/sharing.md b/docs/culture/sharing.md index c145ac2..88434ab 100644 --- a/docs/culture/sharing.md +++ b/docs/culture/sharing.md @@ -4,24 +4,24 @@ description: 成功するポストモーテムプロセスは、誠実さ、学 --- ![Information Sharing](../assets/img/headers/Postmortems-InfoSharing.png) -共有を通じて文化を拡大することができます。1人々は自分の成功を共有したいと思い、何かがうまくいっているのを見ると、その成功を再現したいと思います。インシデントレポートを共有することは、失敗の話を共有しているように見えるため、直感に反するかもしれません。真実は、非難のないポストモーテムを実践することは成功につながるということです。なぜなら、それによってチームは失敗から学び、失敗の発生を減らすためにシステムを改善することができるからです。インシデントを個人的な失敗ではなく、具体的な改善をもたらす学習の機会として位置づけることで、モラルも向上し、それが従業員の定着率と生産性を高めます。 +私たちは、共有を通じて文化を広げることができます。1人々は自分の成功を共有したいと思い、何かがうまくいっているのを見ると、その成功を再現したいと思います。インシデントレポートを共有することは、失敗の話を共有しているように見えるため、直感に反するかもしれません。けれども実際は、非難のない（ブレームレスな）ポストモーテムの実践こそが成功につながります。なぜなら、チームは失敗から学び、失敗の発生を減らすためにシステムを改善することができるからです。インシデントを個人的な失敗ではなく、具体的な改善をもたらす学習の機会として位置づけることで、モラルも向上し、従業員の定着率と生産性を高めます。 **ポストモーテムの結果を共有することには2つの主な利点があります：** 1. 組織全体のシステム知識を増やします。 -1. 非難のない文化を強化します。 +1. 非難のない（ブレームレスな）文化を強化します。 -インシデント分析からの学びを共有することで、修復を担当する影響を受けたチームだけでなく、組織全体が学ぶのを助けます。PagerDutyは完了したポストモーテムを「インシデントレポート」配布リストを通じてエンジニアリング、プロダクト、サポートのすべて、およびすべてのインシデントコマンダー（これらの部門のいずれにも属していない可能性があります）にメールで送信します。これにより、インシデント対応に関わるすべての人のシステム知識が広がります。 +インシデント分析からの学びを共有することで、影響を受けた修復を担当するチームだけでなく、組織全体が学べるようにします。PagerDutyは完了したポストモーテムを「インシデントレポート」配布リストを通じてエンジニアリング、プロダクト、サポートのすべて、およびすべてのインシデントコマンダー（前述の部門のいずれにも属していない可能性があります）にメールで送信します。これにより、インシデント対応に関わるすべての人のシステム知識が広がります。 -私たちは、ポストモーテムが広く共有される前にレビューするために利用できる経験豊富なポストモーテム作成者のコミュニティをホストすることで、チームがポストモーテムのベストプラクティスを互いに学ぶことを奨励しています。これにより、ポストモーテムが書かれている間にフィードバックとコーチングを通じて非難のない分析が確保されます。 +私たちは、ポストモーテムが広く共有される前にレビューが行われるよう、経験豊富なポストモーテム作成者のコミュニティを主催することで、ポストモーテムのベストプラクティスをチームが互いに学べるようにすることを奨励しています。これにより、ポストモーテムが書かれている間にフィードバックとコーチングを通じて非難のない分析ができるようになります。 -また、すべてのポストモーテム会議を共有カレンダーにスケジュールしています。このカレンダーは会社全体に公開されており、誰でも参加することができます。これにより、エンジニアリングチームは非難のなさを実践し、インシデントの原因を深く分析する方法について互いに学ぶ機会が得られます。また、インシデントは隠しておくべき恥ずかしい失敗ではないことを明確にします。 +また、すべてのポストモーテムミーティングを共有カレンダーにスケジュールしています。このカレンダーは会社全体に公開されており、誰でも参加することができます。これにより、エンジニアリングチームはブレームレスを実践し、インシデントの原因を深く分析する方法について互いに学ぶ機会が得られます。また、インシデントは隠しておくべき恥ずかしい失敗ではないことを明らかにします。 -システムの障害について透明性を持つことは、非難のない文化を強化します。ポストモーテムが共有されると、チームはインシデントに対して個人が非難されたり罰せられたりしないことを目にします。これにより、問題が発生したときに発言することへの恐怖が軽減されます。情報を自信を持って共有できる文化を作ることは、チームが協力して改善を設計できる継続的学習の文化につながります。 +システムの障害について透明性を持つことは、非難のない文化を強化します。ポストモーテムが共有されると、チームはインシデントに対して個人が非難されたり罰せられたりしないことを知ります。これにより、問題が発生したときに発言することへの恐怖が軽減されます。自信を持って情報を共有できる文化を作ることは、チームが協力して改善を設計できる継続的学習の文化につながります。 !!! info "重要なポイント" * 経験豊富なポストモーテム作成者のコミュニティを作り、ポストモーテムのドラフトをレビューし、ベストプラクティスを広めます。 - * ポストモーテム会議を共有カレンダーにスケジュールし、関心のある人なら誰でも聞いて学ぶことができるようにします。 - * 完了したポストモーテムをインシデント対応に関わるすべてのチームにメールで送り、学びを共有し非難のなさを強化します。 + * ポストモーテムミーティングを共有カレンダーにスケジュールし、関心のある人なら誰でも聞いて学ぶことができるようにします。 + * 完了したポストモーテムをインシデント対応に関わるすべてのチームにメールで送り、学びを共有し非難のない状態を強化します。 --- 1. Puppetの[2018年DevOpsレポート](https://puppet.com/resources/whitepaper/state-of-devops-report)によると、運用的に成熟した組織は共有を促進する実践を採用しています。 diff --git a/docs/how_to_write/effective_postmortems.md b/docs/how_to_write/effective_postmortems.md index 6f725ad..d9cd1a5 100644 --- a/docs/how_to_write/effective_postmortems.md +++ b/docs/how_to_write/effective_postmortems.md @@ -4,18 +4,18 @@ description: 効果的なポストモーテム文書を作成するための具 --- ![Effective Postmortems](../assets/img/headers/Postmortems-Tips.png) -詳細で正確なポストモーテムを作成することで、ミスから迅速に学び、システムとプロセスを全員のために改善することができます。このガイドでは、効果的なポストモーテムを作成するために私たちが行っていることをいくつか紹介します。 +詳細で正確なポストモーテムを作成することで、ミスから迅速に学び、全員のためにシステムとプロセスを改善することができます。このガイドでは、効果的なポストモーテムを作成するために私たちが行っていることをいくつか紹介します。 ## すべきこと -- タイムラインに出来事が正確に表現されていることを確認する。 -- 新しく参加した人が理解できない可能性のある専門用語や略語を定義する。 -- [何が起きたかと、それをどう修正するかを分けて考える](https://www.youtube.com/watch?v=TqaFT-0cY7U)。 -- フォローアップタスクは、実行可能で具体的かつ範囲が限定されたものにする。 -- [インシデントが影響を受けたサービスの健全性と回復力に関する理解にどのように適合するかを議論する](https://www.pagerduty.com/blog/postmortem-understand-service-reliability/)。 +- タイムラインに出来事が正確に表現されていることを確認すること。 +- 新しく参加した人が理解できない可能性のある専門用語や略語を定義すること。 +- [何が起きたかと、それをどう修正するかを分けて考えること](https://www.youtube.com/watch?v=TqaFT-0cY7U)。 +- フォローアップタスクは、実行可能で具体的かつ範囲が限定されたものにすること。 +- [インシデントと、影響を受けたサービスの健全性と回復力に関する自分たちの理解を照らし合わせ、どのように合致するかを議論すること](https://www.pagerduty.com/blog/postmortem-understand-service-reliability/)。 ## すべきでないこと -- 本当に停止していない限り、「停止（outage）」という言葉を使わないようにし、インシデントの影響を正確に反映させる。「停止」は通常、使用するには広すぎる用語です。顧客に製品が完全に利用できなくなったと思わせる可能性がありますが、実際にはそうではないことがほとんどです。 -- 「より良く見せる」ために詳細や出来事を変更しない。ポストモーテムでは正直であること。そうでなければ、その効果が失われます。 -- 特定の人を名指しで非難しない。ポストモーテムは非難のないものにする。誰かが問題を引き起こす変更をデプロイした場合、それはその人の責任ではありません。破壊的な変更をデプロイできるシステムを構築したことに対して、全員が共同で責任を負っています。 -- 「ヒューマンエラー」を非難しない。ミスが人間の行動に「根ざしている」ことはほとんどありません。多くの場合、いくつかの要因（人間が実行したスクリプトにレートリミットの対応がなかった、ドキュメントが古かった、など）が関係しています。このような事柄には対処することができ、また対処すべきです。 -- 何が間違っていたかだけを指摘しない。問題の根本的な原因を掘り下げる。 +- 本当に停止していない限り、「停止（outage）」という言葉を使わないようにし、インシデントの影響を正確に反映させること。「停止」は通常、使用するには広すぎる用語です。顧客に製品が完全に利用できなくなったと思わせる可能性がありますが、実際にはそうではないことがほとんどです。 +- 「より良く見せる」ために詳細や出来事を変更しないこと。ポストモーテムでは正直であることが重要で、さもないとその効果が失われます。 +- 特定の人を名指しで非難しないこと。ポストモーテムは非難のないものにしましょう。誰かが問題を引き起こす変更をデプロイした場合、それはその人の責任ではありません。破壊的な変更をデプロイできるシステムを構築したことに対して、全員が共同で責任を負っています。 +- 「ヒューマンエラー」を非難しないこと。ミスが人間の行動に「根ざしている」ことはほとんどありません。多くの場合、いくつかの要因（人間が実行したスクリプトにレートリミットの対応がなかった、ドキュメントが古かった、など）が関係しています。このような事柄には対処することができ、また対処すべきです。 +- 何が間違っていたかだけを指摘しないこと。問題の根本的な原因を掘り下げましょう。 diff --git a/docs/how_to_write/writing.md b/docs/how_to_write/writing.md index 48392d7..7c32bdb 100644 --- a/docs/how_to_write/writing.md +++ b/docs/how_to_write/writing.md @@ -7,7 +7,7 @@ description: ポストモーテム文書を作成するための具体的なス 以下は、概要レベルでのポストモーテム実施のステップです。各ステップの実施方法の詳細を以下に示します。 1. インシデントの新しいポストモーテムを作成する。 -1. 「インシデントポストモーテム会議」共有カレンダーに、必須および任意の参加者のために、必要な時間枠内でポストモーテム会議をスケジュールする。 +1. 「インシデントポストモーテムミーティング」共有カレンダーに、必須および任意の参加者のために、必要な時間枠内でポストモーテムミーティングをスケジュールする。 1. ステータス/影響の重要な変化と、対応者が取った主要なアクションをインシデントタイムラインに記入する。 - タイムラインの各項目について、データの出所となるメトリクスまたはサードパーティのページを含める。 1. インシデントを分析する。 @@ -16,7 +16,7 @@ description: ポストモーテム文書を作成するための具体的なス 1. フォローアップアクションのチケットを作成する。 1. 外部向けメッセージを作成する。 1. レビューを依頼する。 -1. ポストモーテム会議に参加する。 +1. ポストモーテムミーティングに参加する。 1. ポストモーテムを共有する。 ## オーナーの責任 @@ -24,11 +24,11 @@ description: ポストモーテム文書を作成するための具体的なス ポストモーテムのオーナーは以下の責任を負います： -- 共有カレンダーにポストモーテム会議をスケジュールし、関連する人々を招待する（Sev-1の場合は3日以内、Sev-2の場合は5営業日以内にスケジュールする必要があります）。 +- 共有カレンダーにポストモーテムミーティングをスケジュールし、関連する人々を招待する（Sev-1の場合は3日以内、Sev-2の場合は5営業日以内にスケジュールする必要があります）。 - インシデントを調査し、調査に必要な他のチームのメンバーを招集する。 - ページに必要なすべてのコンテンツが更新されていることを確認する。含めるべき内容については[テンプレート](../resources/post_mortem_template.md)を参照してください。 - フォローアップチケットを作成する（オーナーはチケットの作成のみ責任を負い、解決までのフォローアップは責任外です）。 -- 会議前に適切な関係者とポストモーテムの内容をレビューし、ポストモーテム会議でトピックを進行する（インシデントコマンダーが会議を「運営」し、議論を軌道に乗せますが、あなたが最も多く話すことになるでしょう）。 +- 会議前に適切な関係者とポストモーテムの内容をレビューし、ポストモーテムミーティングでトピックを進行する（インシデントコマンダーが会議を「運営」し、議論を軌道に乗せますが、あなたが最も多く話すことになるでしょう）。 - ポストモーテムの結果を社内に伝える。 ポストモーテムのオーナーはポストモーテム文書を作成し、関連するすべての情報を更新します。 @@ -43,9 +43,9 @@ description: ポストモーテム文書を作成するための具体的なス まだインシデントコマンダーが実施していない場合、ポストモーテムオーナーの最初のステップは、インシデントのための新しい空のポストモーテムを作成することです。Slackの履歴を確認して対応者を特定し、彼らにポストモーテムの作成を手伝ってもらえるようにページに追加します。インシデントコマンダー書記官も足しましょう。インシデント対応のレコーディングへのリンクを追加します。 -次に、インシデントの複雑さに応じて30分から1時間のポストモーテム会議をスケジュールします。プロセスの最初に会議をスケジュールすることで、SLA内にポストモーテムが完了することを確保します。**会議はSev-1の場合は3暦日以内、Sev-2の場合は5営業日以内にスケジュールする必要があります。**すべての参加者にとって最適な時間を見つけることを心配する必要はありません。優先事項はこの時間枠内にスケジュールすることであり、参加者はそれに応じてスケジュールを調整する必要があります。PagerDutyでは、すべてのポストモーテム会議を「インシデントポストモーテム会議」共有カレンダーにスケジュールし、組織全体で関心のある人々が簡単に見つけられるようにしています。 +次に、インシデントの複雑さに応じて30分から1時間のポストモーテムミーティングをスケジュールします。プロセスの最初に会議をスケジュールすることで、SLA内にポストモーテムが完了することを確保します。**会議はSev-1の場合は3暦日以内、Sev-2の場合は5営業日以内にスケジュールする必要があります。**すべての参加者にとって最適な時間を見つけることを心配する必要はありません。優先事項はこの時間枠内にスケジュールすることであり、参加者はそれに応じてスケジュールを調整する必要があります。PagerDutyでは、すべてのポストモーテムミーティングを「インシデントポストモーテムミーティング」共有カレンダーにスケジュールし、組織全体で関心のある人々が簡単に見つけられるようにしています。 -ポストモーテム会議には以下の人々を招待します： +ポストモーテムミーティングには以下の人々を招待します： - 必須 - [インシデントコマンダー](https://response.pagerduty.com/training/incident_commander/)。 @@ -62,7 +62,7 @@ PagerDutyのポストモーテムには、ポストモーテムが現在プロ | ステータス | 説明 | |-|-| | **ドラフト** | ポストモーテムの内容がまだ作業中であることを示します。 | -| **レビュー中** | ポストモーテムの内容が完成し、ポストモーテム会議でのレビューの準備ができていることを示します。 | +| **レビュー中** | ポストモーテムの内容が完成し、ポストモーテムミーティングでのレビューの準備ができていることを示します。 | | **レビュー済み** | 会議が終了し、内容がレビューされ合意されたことを示します。
「対外メッセージ」がある場合、カスタマーサポートチームがメッセージを取り、適切にステータスページを更新します。 | | **クローズ** | ポストモーテムに関するさらなるアクションは必要ない状態です（未解決の問題はJIRAで追跡されます）。
「対外メッセージ」がない場合、会議終了後にこのステータスに直接移行できます。
「対外メッセージ」がある場合、サポートチームがメッセージを投稿した後にこのステータスに更新します。 | @@ -210,29 +210,29 @@ Slackのインシデントログを確認して、対応中に行われた重要 ![Followup](../assets/img/thumbnails/5FollowUpActions.png) インシデントの原因を特定した後、これが再び起こらないようにするために何をする必要があるかを考えます。分析に基づいて、この特定のインシデントではなく、この種の問題の発生を減らすための提案もあるかもしれません。 -同じインシデントや類似のインシデントが再び発生する可能性を完全に排除することは不可能（または努力に値しない）かもしれないので、将来のインシデントの検出と軽減をどのように改善できるかも考慮してください。この種の問題に対してはより良いモニタリングとアラートが必要で、将来より迅速にチームが対応できるようにする必要がありますか？この種のインシデントが再び発生した場合、チームはどのように重大度や対応時間を抑えることができますか？インシデント対応プロセスを改善するためのアクションも特定することを忘れないでください。Slackのインシデント履歴を確認して、インシデント中に提起されたすべてのToDoアイテムを見つけ、これらもチケットとして文書化されていることを確認してください。（この段階では、チケットを作成するだけです。ポストモーテム会議の前にタスクを完了させる必要はありません。） +同じインシデントや類似のインシデントが再び発生する可能性を完全に排除することは不可能（または努力に値しない）かもしれないので、将来のインシデントの検出と軽減をどのように改善できるかも考慮してください。この種の問題に対してはより良いモニタリングとアラートが必要で、将来より迅速にチームが対応できるようにする必要がありますか？この種のインシデントが再び発生した場合、チームはどのように重大度や対応時間を抑えることができますか？インシデント対応プロセスを改善するためのアクションも特定することを忘れないでください。Slackのインシデント履歴を確認して、インシデント中に提起されたすべてのToDoアイテムを見つけ、これらもチケットとして文書化されていることを確認してください。（この段階では、チケットを作成するだけです。ポストモーテムミーティングの前にタスクを完了させる必要はありません。） -提案されたすべてのフォローアップアクションのチケットをタスク管理ツールで作成します。すべてのチケットに重大度レベルと日付タグを付けて、チケットシステムで簡単に見つけて報告できるようにします。チームのプロダクトオーナーが他の作業と比較してタスクの優先順位を付けるのに十分な情報があり、最終的な担当者がタスクを完了するのに十分な情報を得られるように、チケットにできるだけ多くのコンテキストと提案された方向性を提供してください。 +提案されたすべてのフォローアップアクションのチケットをタスク管理ツールで作成します。すべてのチケットに重大度レベルと日付タグを付けて、チケットシステムで簡単に見つけて報告できるようにします。チームのプロダクトオーナーが他の作業と比較してタスクの優先順位を付けるのに十分な情報があり、最終的な担当者がタスクを完了するのに十分な情報を得られるよう、チケットにできるだけ多くのコンテキストと提案された方向性を提供してください。 -_;login:_ マガジンの記事「[Postmortem Action Items: Plan the Work and Work the Plan](https://www.usenix.org/system/files/login/articles/login_spring17_09_lunney.pdf)」で、ジョン・ラニー、スー・ルーダー、ベッツィ・ベイヤーはGoogleがポストモーテムのアクションアイテムを迅速かつ簡単に完了させるためにどのように書くかについて説明しています。彼らはすべてのアクションアイテムを実行可能、具体的、かつ範囲が限定されたものとして書くことを勧めています。 +_;login:_ マガジンの記事「[Postmortem Action Items: Plan the Work and Work the Plan](https://www.usenix.org/system/files/login/articles/login_spring17_09_lunney.pdf)」で、John Lunney・Sue Lueder・Betsy Beyerは、Googleがポストモーテムのアクションアイテムを迅速かつ簡単に完了させるためにどのように書いているかを説明しています。彼らはすべてのアクションアイテムを実行可能、具体的、かつ範囲が限定されたものとして書くことを勧めています。 - **実行可能：** 各アクションアイテムを動詞で始まる文として表現します。アクションは有用な結果をもたらすようにします。 - **具体的：** 各アクションアイテムの範囲をできるだけ狭く定義し、範囲内と範囲外を明確にします。 -- **範囲が限定された：** 各アクションアイテムを、オープンエンドまたは継続的なタスクではなく、いつ終了したかを示すように表現します。 +- **範囲が限定的：** 各アクションアイテムを、オープンエンドまたは継続的なタスクではなく、いつ終了したかを示すように表現します。 | 不適切な表現 | より良い表現 | |-|-| | このシナリオのモニタリングを調査する。 | **実行可能：** このサービスが>1%のエラーを返すすべてのケースのアラートを追加する。 | | 停止を引き起こした問題を修正する。 | **具体的：** ユーザーアドレスフォーム入力の無効な郵便番号を安全に処理する。 | -| エンジニアが更新前にデータベーススキーマが解析できることを確認するようにする。 | **範囲が限定された：** スキーマ変更の自動事前送信チェックを追加する。 | +| エンジニアが更新前にデータベーススキーマが解析できることを確認するようにする。 | **範囲が限定的：** スキーマ変更の自動事前送信チェックを追加する。 | 出典: _;login:_ Spring 2017 Vol. 42, No. 1. -チケットを作成する前に議論が必要なフォローアップアクションの提案がある場合は、これらの項目をポストモーテム会議の議題に追加するメモを作成してください。これらはチームの検証や明確化が必要な提案かもしれません。会議でこれらの項目を議論することで、どのように進めるのが最善かを決定するのに役立ちます。 +チケットを作成する前に議論が必要なフォローアップアクションの提案がある場合は、これらの項目をポストモーテムミーティングの議題に追加するメモを作成しましょう。場合によってはチームの検証や明確化が必要な提案かもしれません。会議でこれらの項目を議論すると、どのように進めるのが最善かを決定するのに役立つでしょう。 -あまりにも多くのチケットを作成しないように注意してください。P0/P1のタスク、つまり絶対に対処すべきタスクのみを作成してください。ここにはいくつかのトレードオフがあり、それは問題ありません。時には、インシデントの再発を減らす可能性のあるアクションを実行するために必要な労力に対してROIが価値がない場合があります。その場合、その決定をポストモーテムに文書化する価値があります。チームがアクションを実行しないことを選択する理由を理解することは、学習性無力感を避けるのに役立ちます。 +あまりにも多くのチケットを作成しないように注意してください。P0/P1のタスク、つまり絶対に対処すべきタスクのみを作成しましょう。ここにはいくらかトレードオフが発生することがありますが、それは問題ありません。ときには、インシデントの再発を減らす可能性のあるアクションを実行するために必要な労力に対して、ROIが見合わないケースもあります。その場合も、その決定をポストモーテムに文書化しておく価値があります。チームがアクションを実行しないことを選択した理由を理解するのは、やったことが役に立たなかったのではないかという無力感を避けるのにも役立つでしょう。 -チケットを作成する人がそれを完了する責任を負うわけではないことに注意してください。チケットは影響を受けたサービスを所有するチームのプロジェクトの下で開かれます。フォローアップアクションの責任を負うすべてのチームの代表者が少なくとも1人、ポストモーテム会議に招待されます。 +チケットを作成する人自身がそれを完了する責任を負うわけではないことに注意しましょう。チケットは影響を受けたサービスを所有するチームのプロジェクトでオープンされます。フォローアップアクションの責任を負うすべてのチームの代表者を少なくとも1人、ポストモーテムミーティングに招待します。 !!! info "重要なポイント" @@ -241,9 +241,9 @@ _;login:_ マガジンの記事「[Postmortem Action Items: Plan the Work and Wo * この種のインシデントの重大度や対応期間をどのように抑えることができますか？ * 実行可能、具体的、かつ範囲が限定されたタスクを書くこと。 -## 外部メッセージの作成 +## 対外メッセージの作成 ![External](../assets/img/thumbnails/6WriteExternalMessaging.png) -外部メッセージの目標は、技術や組織に関する独自情報を明かすことなく、何が起こったのか、それに対して何をしているのかについて顧客に十分な情報を提供することで信頼を構築することです。内部分析の一部は主に内部の聴衆に利益をもたらし、外部のポストモーテムに含める必要はありません。 +対外メッセージの目的は、技術や組織に関する独自情報を明かすことなく、何が起こったのか、それに対して何をしているのかについて顧客に十分な情報を提供することで信頼を築くことです。内部分析の一部は主に内部の読者に利益をもたらすもので、外部のポストモーテムに含める必要はありません。 外部ポストモーテムは、内部ポストモーテムに使用される情報を要約し、整理したものです。外部ポストモーテムには以下の3つのセクションが含まれます： @@ -256,19 +256,19 @@ _;login:_ マガジンの記事「[Postmortem Action Items: Plan the Work and Wo >ヒント：本当に完全な停止でない限り、「停止（outage）」という言葉を使用することは避けてください。代わりに「インシデント」または「サービス低下」という言葉を使用してください。顧客は一般的に「停止」を見て最悪の事態を想定します。 -この時点で、外部ポストモーテムはまだ送信または公開すべきではない草案の言語であることに注意してください。ポストモーテム会議で送信前にレビューする必要があります。 +この時点で、外部ポストモーテムはまだ送信または公開すべきではないドラフトであることに注意してください。送信前にポストモーテムミーティングでレビューする必要があります。 ## ポストモーテムレビュー ![Review](../assets/img/thumbnails/7PostmortemReview.png) -PagerDutyでは、スタイルと内容についてポストモーテムをレビューするために利用できる経験豊富なポストモーテム作成者のコミュニティがあります。これにより、会議中の無駄な時間を避けることができます。会議がスケジュールされる少なくとも24時間前に、Slackにポストモーテムへのリンクを投稿してフィードバックを受け取ります。 +PagerDutyでは、スタイルと内容に関するポストモーテムのレビューに活用できる経験豊富なポストモーテム作成者のコミュニティがあります。これにより、会議中の無駄な時間を減らせます。会議がスケジュールされる少なくとも24時間前に、Slackへポストモーテムへのリンクを投稿してフィードバックを受け取ります。 -以下は、私たちが探すいくつかのことです： +以下は、私たちが主に確認する事柄です： - 十分な詳細を提供していますか？ - 何が間違っていたかを指摘するだけでなく、問題の根本的な原因を掘り下げていますか？ - 「何が起きたか？」と「どう修正するか」を分けていますか？ - 提案されたアクションアイテムは意味がありますか？十分に範囲が限定されていますか？ - ポストモーテムは適切に書かれ、理解可能ですか？ -- 外部メッセージは顧客に共感しますか、それとも怒りを引き起こす可能性がありますか？ +- 対外メッセージは顧客の共感を得られそうな内容ですか、それとも反感を引き起こす可能性がありますか？ -ポストモーテムのレビューは誤字脱字を細かく指摘することではありません（ただし、外部メッセージにスペルや文法エラーがないことを確認してください）。それは、ポストモーテムから最大の利益を得るために、ポストモーテムに価値ある変更を加えるための建設的なフィードバックを提供することです。 +ポストモーテムのレビューは誤字脱字を細かく指摘することではありません（ただし、対外メッセージにスペルや文法エラーがないことを確認してください）。重要なのは、ポストモーテムから最大の利益を得るために、ポストモーテムに価値ある変更を加えるための建設的なフィードバックを提供することです。 diff --git a/docs/index.md b/docs/index.md index ad6d45a..510498b 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,8 +1,8 @@ ![PagerDuty](assets/img/headers/Postmortems-Title.png) -インシデント発生後にポストモーテムを実施すると、何がうまくいったのか、どこを改善できるのか、そして最も重要なことに、同じ誤りを繰り返さないための方法を学ぶことができます。適切に設計されたポストモーテムにより、チームはインフラストラクチャとインシデント対応プロセスを段階的に改善できます。 +インシデント発生後にポストモーテムを実施すると、何がうまくいったのか、どこを改善できるのか、そして最も重要なこととして、同じ誤りを繰り返さないための方法を学ぶことができます。適切に設計されたポストモーテムによって、チームはインフラストラクチャとインシデント対応プロセスを段階的に改善できます。 -ポストモーテムの概念はテクノロジー業界ではよく知られていますが、効果的なポストモーテムに必要な文化的ニュアンスを個人、チーム、組織が新たに取り入れるのは難しい場合もあります。このガイドでは、継続的な学習の文化を構築する方法、分析に含めるべき最も重要な要素、そして効果的なポストモーテムミーティングを実施する方法について説明します。 +ポストモーテムの概念はテクノロジー業界ではよく知られていますが、効果的なポストモーテムに必要な文化的ニュアンスを個人、チーム、組織が新たに取り入れるのは難しいこともよくあります。このガイドでは、継続的な学習の文化を構築する方法、分析に含めるべき最も重要な要素、そして効果的なポストモーテムミーティングを実施する方法について説明します。 ## 対象者 このリソースは、チームに影響を与えるインシデントから段階的に学びたいオンコール担当者や、組織内に学習の文化を育みたいマネージャーを対象としています。 @@ -12,28 +12,28 @@ [ポストモーテム](what_is.md)を誰が、何を、いつ、なぜ行うのか。 ### ブレームレスな文化 -成功するポストモーテムプロセスは、誠実さ、学習、そして説明責任の文化に基づいています。文化の変革には経営陣の賛同が必要ですが、あなたの役割に関わらず文化の変革をリードすることができます。このセクションでは、ポストモーテムを通じて継続的な学習の文化を構築する際の一般的な課題と、それらを克服するための戦略について説明します。 +成功するポストモーテムプロセスは、誠実さ、学習、そして説明責任の文化に基づいています。カルチャーの変革には経営陣の賛同が必要ですが、あなたの役割によらず推進していくことは可能です。このセクションでは、ポストモーテムを通じて継続的な学習の文化を構築する際の一般的な課題と、それらを克服するための戦略について説明します。 -- [非難のない（Blamelessな）ポストモーテム](culture/blameless.md) +- [非難のない（ブレームレスな）ポストモーテム](culture/blameless.md) - [ポストモーテムの導入方法](culture/introduce.md) -- [情報共有](culture/sharing.md) -- [説明責任](culture/accountability.md) +- [情報共有のありかた](culture/sharing.md) +- [説明責任の考えかた](culture/accountability.md) ### ポストモーテムの書き方 ポストモーテムに含めるべき情報、その情報の収集と提示方法、そしてシステムの改善につながる効果的な分析の実施方法について学びます。 -- [ステップバイステップ](how_to_write/writing.md) +- [段階を追ったポストモーテムの書きかた](how_to_write/writing.md) - [効果的なポストモーテムのためのヒント](how_to_write/effective_postmortems.md) ### ポストモーテムミーティング -生産的な[ポストモーテムミーティング](meeting.md)の実施方法。 +生産的な[ポストモーテムミーティング](meeting.md)の実施方法を解説します。 ### 追加リソース - [テンプレート](resources/post_mortem_template.md) - [チェックリスト](resources/checklist.md) -- [分析の質問](resources/analysis.md) -- [例](resources/examples.md) +- [分析にあたっての質問](resources/analysis.md) +- [実践例](resources/examples.md) - [参考文献](resources/reading.md) ### ライセンス diff --git a/docs/meeting.md b/docs/meeting.md index 3e41d75..8fb8adf 100644 --- a/docs/meeting.md +++ b/docs/meeting.md @@ -5,23 +5,23 @@ description: 文書化されたポストモーテムを完了した後、イン ![The Postmortem Meeting](assets/img/headers/Postmortems-Meeting.png) ## 目的 -文書化されたポストモーテムを完了した後、インシデントについて議論するためのミーティングを行います。**このミーティングの目的は、直接的なコミュニケーションを通じてポストモーテム分析を深め、アクションアイテムへの賛同を得ることです。** 文書化されたポストモーテムの非同期的な作成はチームがインシデントから学び始めるのに役立ちますが、会話を持つことでより深い学びにつながります。さらに、文書化されたポストモーテムについて議論するためのミーティングをスケジュールすることで、ポストモーテムをタイムリーに完了するための[説明責任（Accountability）](culture/accountability.md)が生まれます。このミーティングでアクションアイテムについて議論することで、それらのタスクが確実に完了するよう支援します。 +文書化されたポストモーテムを完了した後、インシデントについて議論するためのミーティングを行います。**このミーティングの目的は、直接的なコミュニケーションを通じてポストモーテム分析を深め、アクションアイテムへの賛同を得ることです。** 文書化されたポストモーテムの非同期的な作成はチームがインシデントから学び始めるのに役立ちますが、会話を持つことでより深い学びにつながります。さらに、文書化されたポストモーテムについて議論するためのミーティングをスケジュールすることで、ポストモーテムをタイムリーに完了するための[説明責任（accountability）](culture/accountability.md)が生まれます。このミーティングでアクションアイテムについて議論することで、それらのタスクが確実に完了するよう支援します。 -ポストモーテムミーティングのアンチパターンは、文書化されたポストモーテムに記載された直接的な懸念事項に過度に焦点を当てることです。ドキュメントの各セクションを単に読み上げることでミーティング時間を埋めることは避けてください。この時間を最も有効に使うには、詳細な分析から一歩引いて、インシデントにつながったシステム的要因をより良く理解することです。 +ポストモーテムミーティングのアンチパターンは、文書化されたポストモーテムに記載された直接的な懸念事項に過度に焦点を当てることです。ドキュメントの各セクションを単に読み上げることにミーティング時間を使うのは避けてください。この時間を最も有効に使う方法は、詳細な分析から一歩引いて、インシデントにつながったシステム的要因をより良く理解することです。 -一部のチームは、ミーティングの基調を設定し、目標を定期的に思い出させるために[レトロスペクティブ・プライム・ディレクティブ](http://retrospectivewiki.org/index.php?title=The_Prime_Directive)を活用しています。これは、レトロスペクティブ、ポストモーテム、またはポストインシデントレビューを始めるための白紙の状態を提供し、議論の基盤となる役立つツールとなります。 +一部のチームは、ミーティングの基調を設定し、目的を定期的に思い起こすために[レトロスペクティブ・プライム・ディレクティブ](http://retrospectivewiki.org/index.php?title=The_Prime_Directive)を活用しています。これは、レトロスペクティブ、ポストモーテム、またはポストインシデントレビューを始めるための白紙の状態を提供し、議論の基盤となる役立つツールとなります。 > - 「私たちが何を発見しようとも、その時点で知っていたこと、スキルと能力、利用可能なリソース、そして直面していた状況を考慮すると、誰もが最善を尽くしたと理解し、真に信じています。」 + 「私たちが何を発見しようとも、その時点で知っていたこと、スキルと能力、利用可能なリソース、そして直面していた状況を考慮すれば、誰もが最善を尽くしたと理解して信じています。」 --Norm Kerth著「Project Retrospectives: A Handbook for Team Review」 -**ポストモーテムミーティングの最も重要な成果は、アクションプランへの賛同です。** これは提案された[アクションアイテム](how_to_write/writing.md)について議論し、他の選択肢についてブレインストーミングし、チームリーダーシップ間でコンセンサスを得る機会です。時には、提案されたアクションアイテムの投資対効果が作業を正当化するほど大きくない場合や、ポストモーテムのアクションアイテムが他の優先事項のために遅延しなければならない場合があります。ポストモーテムミーティングは、これらの難しい決断について議論し、どの作業が行われ、どの作業が行われないか、そしてそれらの選択の予想される影響について明確にする時間です。 +**ポストモーテムミーティングの最も重要な成果は、アクションプランへの賛同です。** これは提案された[アクションアイテム](how_to_write/writing.md)について議論し、他の選択肢についてブレインストーミングし、チームリーダーシップ間でコンセンサスを得る機会です。ときには、提案されたアクションアイテムの投資対効果が作業を正当化するほど大きくない場合や、他の優先事項をポストモーテムのアクションアイテムに比べて遅らせなければならない場合もあります。ポストモーテムミーティングは、これらの難しい決断について議論し、どの作業を行い、どの作業を行わないのか、そしてそれらの選択によって予想される影響を明確にする時間です。 文書化されたポストモーテムは組織内で広く共有されることを意図していますが、ポストモーテムミーティングの主な対象者はインシデントに直接関わったチームです。このミーティングは、チームが何が起こったのか、それについて何をすべきか、そしてインシデントについて内部および外部のステークホルダーにどのように伝えるかについて認識を合わせる機会を提供します。 !!! tip - ミーティングの24時間前にポストモーテムドキュメントのリンクを参加者に送信してください。ポストモーテムは参加者に送信される時点で完成している必要はありませんが、ポストモーテムミーティングの前に完成させましょう。参加者が文書を読み始められるように、不完全なポストモーテムでも事前に共有しておく価値があります。 + ミーティングの24時間前にポストモーテムドキュメントのリンクを参加者に送信してください。ポストモーテムは参加者に送信される時点で完成している必要はありませんが、ポストモーテムミーティングの開催までに完成させましょう。参加者が文書を読み始められるように、不完全なポストモーテムでも事前に共有しておく価値があります。 これにより、ミーティングで単に文書を読み上げるために時間を無駄にすることを避けられます。ミーティングの目的は、インシデントの原因と将来それを防ぐ方法について深い会話をすることであり、文書をレビューすることではないことを覚えておいてください。ポストモーテムミーティングは、何が起こったのか、そしてそれが再び起こるのを防ぐためにチームで何をするかに関する疑問点を明らかにする機会でもあります。全員が同じ認識を持てるよう、参加者にあらゆる質問を促し、分析を進める上でチームが新しい視点から考えられるようにしましょう。 @@ -52,7 +52,7 @@ description: 文書化されたポストモーテムを完了した後、イン - 影響を受けたシステムのエンジニアリングマネージャー。 - インシデントに対応したチームを担当するマネージャーは、スタッフ配置と技術投資の決定に情報を提供するためにポストモーテムミーティングに参加します。 - 影響を受けたシステムのプロダクトマネージャー。 - - プロダクトマネージャーは、インシデントが顧客体験に与える影響を理解するためにポストモーテムミーティングに参加します。ポストモーテムのアクションアイテムが優先され完了するためには、提案されたフォローアップタスクの重要性と範囲についてのこの議論にプロダクトマネージャーを関与させることが重要です。 + - プロダクトマネージャーは、インシデントが顧客体験に与える影響を理解するためにポストモーテムミーティングに参加します。ポストモーテムのアクションアイテムを優先し完了するためには、提案されたフォローアップタスクの重要性と範囲についてのこの議論にプロダクトマネージャーを関与させることが重要です。 - 任意参加（Sev-1インシデントのみ） - [カスタマーリエゾン](https://response.pagetduty.co.jp/training/customer_liaison/)。 - カスタマーリエゾンはインシデントに対する顧客の反応について話すことができます。彼らは外部メッセージを最終化して送信できるように、アクションアイテムに関するチームの決定を理解する必要があります。 @@ -63,17 +63,17 @@ description: 文書化されたポストモーテムを完了した後、イン ファシリテーターが行うこと： -- 人々が発言するよう促し、全員の声が聞かれるようにします。 -- 洞察を明確にし、質問でチームに挑戦します。 -- チームが異なる視点と異なる選択肢に目を向けるのを助けます。 +- 人々が発言するよう促し、全員の声に耳が傾けられるようにします。 +- 洞察を明確にし、チームに質問を投げかけます。 +- チームが異なる視点と異なる選択肢に目を向けられるよう促します。 - 全員が時間通りに議論を進め、軌道に乗るようにします。話の脱線を防ぎ、特定の人々がミーティング全体を支配するのを止めます。 - できるだけ少なく話します。議論を導くことを念頭におきながら、ミーティングを乗っ取らないように注意してください。 ファシリテーターが行わないこと： -- 決定を下す。 -- 誰かの肩を持つ。ファシリテーターが特定の側につくと、チームメンバーは攻撃されていると感じ、ミーティングへの貢献をやめるかもしれません。 - - 人々が言うことにコメントするのは、たとえそれが肯定的なフィードバックを与える意図だったとしても避けましょう。話者自身は肯定感と感じるかもしれませんが、他の人からすると自分がこれから言おうとすることについて悪く感じたり、貢献することを思いとどまったりすることにつながるかもしれません。 +- 決定を下すこと。 +- 誰かの肩を持つこと。ファシリテーターが特定の側につくと、チームメンバーは攻撃されていると感じ、ミーティングへの貢献をやめるかもしれません。 + - 人々が言うことにコメントするのは、たとえそれが肯定的なフィードバックを与える意図だったとしても避けましょう。話者自身は肯定感を感じるかもしれませんが、他の人からすると自分がこれから言おうとすることについて悪く感じたり、貢献することを思いとどまったりすることにつながるかもしれません。 ### 誰がファシリテートすべきか 優れたファシリテーターは通常、高度な感情的知性を持ち、人々がどのように感じているかを理解するために非言語的な手がかりを容易に読み取ることができます。彼らはこの感覚を使って、誰もが話しやすい環境を育みます。アジャイルコーチやプロジェクトマネージャーはしばしば熟練したファシリテーターです。PagerDutyでは、ファシリテーションの学習に興味のある個人をコーチする自信のあるファシリテーターのギルドがあります。組織内でポストモーテムミーティングのファシリテートを手伝う個人を探す際には、これらのコアコンピテンシーを持つ人を探してください： @@ -88,7 +88,7 @@ description: 文書化されたポストモーテムを完了した後、イン ポストモーテムミーティングのファシリテーターは、影響を受けたシステムの専門家である必要はありません。ファシリテーターは議論の内容に精通している必要はありません。ファシリテーターは議論に自分の意見を貢献するのではなく、他の人が話すよう促すことを忘れないでください。インシデント対応に関わったミーティング参加者がインシデントの専門家であり、ファシリテーターはそれらの専門家がグループと情報を共有するよう促す質問をします。 -しかし、ファシリテーターはポストモーテムプロセスとポストモーテムミーティングの目標に精通しているべきで、それによりグループ議論をそれらの目標達成に導くことができます。ポストモーテムミーティングのファシリテーターは、[非難のないこと（Blameless）](culture/blameless.md)についてしっかりした理解を持っている必要があり、グループがミーティングで非難の言葉を避けられるようにします。 +しかし、ファシリテーターはポストモーテムプロセスとポストモーテムミーティングの目標に精通しているべきで、それによりグループ議論をそれらの目標達成に導くことができます。ポストモーテムミーティングのファシリテーターは、[非難のないこと（ブレームレス）](culture/blameless.md)についてしっかりした理解を持っている必要があり、グループがミーティングで非難の言葉を避けられるようにします。 ## ファシリテーションのヒント ポストモーテムミーティングのファシリテーターは、チームが分析をより深く掘り下げ、[非難を避け](culture/blameless.md)ながら、アクションアイテムへの賛同を得られるようにします。ポストモーテムミーティングの一般的な課題は、文書化されたポストモーテムに過度に焦点を当てることと、システム障害の責任を個人に帰する傾向に屈することです。以下は、効果的なポストモーテムミーティングを実施する方法と、発生した場合の厄介な状況の対処方法に関するヒントです。 @@ -117,9 +117,9 @@ description: 文書化されたポストモーテムを完了した後、イン **会話がトピックから外れている場合の対処法：** -- ファシリテーターの仕事はチームを軌道に乗せておくことであり、トピックを続けることが価値があるか、またはオフラインで取り上げることができるかを尋ねることで、ミーティングの目標をチームに思い出してもらうために中断する必要があります。 +- ファシリテーターの仕事はチームを軌道に乗せておくことであり、トピックを続けることが価値があるか、またはオフラインで取り上げることができるかを尋ねることで、ミーティングの目標をチームに思い出してもらい、不適切なトピックを中断する必要があります。 - 「申し訳ありませんが、このトピックはこのミーティングの目標と関係ないようです。元のトピックに戻りますか、それともこの議論を続けますか？」 -- アジェンダ項目の時間を制限します。時間が終わったら、さらに数分間話し続けるかどうかを投票できます。 +- アジェンダ項目の時間を制限します。時間が終わったら、さらに数分間話し続けるかどうかの投票を行います。 **一人がミーティングを支配している場合の対処法：** diff --git a/docs/next_steps.md b/docs/next_steps.md index 136e171..f913265 100644 --- a/docs/next_steps.md +++ b/docs/next_steps.md @@ -57,7 +57,7 @@ Slackやその他のデータソースと統合している場合、その情報 変更は今後のポストモーテムレポートにのみ適用されます。既に作成されたレポートには適用されません。 質問や説明情報をどのように設定するかのガイダンスについては、このガイドの[分析の質問](https://postmortems.pagerduty.com/resources/analysis/)セクションを参照してください。 -いつでもデフォルトのテンプレートから再開したい場合は、テンプレートをリセットできます。元のデフォルトセクションに戻すには、レポートテンプレートの上部にある「Reset Template」ボタンをクリックします。ポップアップメニューでテンプレートをリセットするか、キャンセルするかを選択するよう促されます。 +いつでもデフォルトのテンプレートから再開したい場合は、テンプレートをリセットできます。元のデフォルトセクションに戻すには、レポートテンプレートの上部にある「Reset Template」ボタンをクリックします。ポップアップメニューでテンプレートをリセットするか、キャンセルするかの選択が促されます。 ### レポートと関連インシデント間のナビゲーション 現在、レポートに関連付けられたインシデントを確認する唯一の方法は、レポートを開いて追加されたインシデントを確認することです。現在、インシデントに移動して関連するレポートを表示することはできません。 diff --git a/docs/resources/analysis.md b/docs/resources/analysis.md index cd5b0c9..8e1ecd7 100644 --- a/docs/resources/analysis.md +++ b/docs/resources/analysis.md @@ -4,7 +4,7 @@ description: ポストモーテム分析を深めるための質問事項。 --- ![Analysis](../assets/img/headers/Postmortems-Questions.png) -シドニー・デッカーの著書『The Field Guide To Understanding Human Error』に掲載されているゲイリー・クラインのデブリーフィング質問にインスパイアされ、以下に深い分析を促進するための質問リスト（網羅的ではありません）を紹介します。「誰が」や「なぜ」ではなく、「どのように」「何が」という質問を使うことで、非難を避け、学習を促進します。 +Sidney Dekkerの著書『The Field Guide To Understanding Human Error』に掲載されているGary Kleinのデブリーフィング質問を参考に作成された、深い分析を促すための質問リスト（網羅的ではありません）を紹介します。「誰が」や「なぜ」ではなく、「どのように」「何が」という質問を使うことで、非難を避け、学習を促進します。 [PDFとしてダウンロード](../assets/pdf/PostmortemAnalysisQuestions.pdf)。 @@ -23,8 +23,8 @@ description: ポストモーテム分析を深めるための質問事項。 過去の知識/経験 @@ -34,8 +34,8 @@ description: ポストモーテム分析を深めるための質問事項。 @@ -45,7 +45,7 @@ description: ポストモーテム分析を深めるための質問事項。 @@ -53,8 +53,8 @@ description: ポストモーテム分析を深めるための質問事項。 行動 @@ -64,8 +64,8 @@ description: ポストモーテム分析を深めるための質問事項。 diff --git a/docs/what_is.md b/docs/what_is.md index c40c891..f6c0fc1 100644 --- a/docs/what_is.md +++ b/docs/what_is.md @@ -20,7 +20,7 @@ description: ポストモーテムの基本。ポストモーテムが重要な ## なぜポストモーテムを行うのか インシデント対応中、チームは100％サービスの復旧に集中しています。最適な方法を考えたり、インシデントの原因を深く掘り下げたりするために時間と精神的エネルギーを無駄にすることはできません（そうすべきでもありません）。そのためポストモーテムは不可欠で、ユーザーに影響する問題が解消された後に振り返りの機会を提供します。**ポストモーテムプロセスは焦点を絞り、学習の文化を醸成し、そうでなければ失われてしまう改善の機会を特定します。** -ポストモーテムを行わなければ、何がうまくいっているのか、どこを改善できるのか、そして最も重要なことに、将来同じ間違いを避ける方法を認識できません。効果的なポストモーテムを実施することで、ミスから迅速に学び、システムとプロセスを改善することができます。適切に設計された、ブレームレス（非難のない）なポストモーテムにより、チームは継続的に学習し、インフラストラクチャとインシデント対応プロセスを段階的に改善する方法として機能します。ポストモーテムから最大限の利益を得るためには、詳細で正確なポストモーテムを作成するようにしましょう。 +ポストモーテムを行わなければ、何がうまくいっているのか、どこを改善できるのか、そして最も重要なことに、将来同じ誤りを避ける方法を認識できません。効果的なポストモーテムを実施すれば、ミスから迅速に学び、システムとプロセスを改善することができます。適切に設計されたブレームレス（非難のない）なポストモーテムは、チームが継続的に学習し、インフラストラクチャとインシデント対応プロセスを段階的に改善する方法として機能します。ポストモーテムから最大限の利益を得るためには、詳細で正確なポストモーテムを作成するようにしましょう。 ## いつポストモーテムを行うべきか **すべての重大なインシデント（Sev-2/1）に対してポストモーテムを実施してください**。これには**インシデント対応が発動されたすべての場合**が含まれます。後に重大度が実際には低かったことが判明した場合や、誤報だった場合、または介入なしで迅速に回復した場合であっても実施します。これらのケースでもポストモーテムを怠るべきではありません。なぜなら、インシデント対応プロセスで何がうまくいき、何がうまくいかなかったかを確認する機会だからです。インシデントがインシデント対応を発動すべきでなかった場合、なぜ発動されたのかを理解し、将来、不必要にインシデント対応を発動しないようにモニタリングを調整することが価値があります。この分析とフォローアップアクションを行うことで、今後のアラート疲れを防ぐのに役立ちます。