はじめに
この記事は、基本的には、Blameless PostMortems and a Just Culture 、Google SRE本（The SRE Book、SRE Workbookなど）、および、The infinite hows、その他インターネットに公開されているBlogやSRE Conの動画などを参考に、「Blameless Postmortem」および「Infinite hows」について自分の理解をまとめたメモです。
Blamelessとは
SREやDevOpsで重視されているBlameless
SREの実践において、インシデントの復旧後に根本原因の分析やアクションの検討のために「Blameless Postmortems」（直訳すると、非難の無いポストモーテム）を実施することが推奨されています。ITILなどでおなじみの「問題管理」と基本的には同じ領域の話ではあるのですが、「Blameless」という考え方が特に重要な考え方となっています。
ヒューマンエラーの捉え方（腐ったリンゴ理論）
以下の記事がとてもわかりやすいので一読することをおすすめします。
※以下の内容は上記の記事から抜粋しています。
システムの運用においてヒューマンエラーが発生した場合、従来、以下の対応を取りがちです。
- 根本原因はヒューマンエラーだと見なされることが多い
- 管理者たちは問題の原因を作った者を特定し、非難し、恥辱を与えるという反応をとりがち
- 管理者たちはミスを犯した人物を処罰することをほのめかす（公然と伝える場合も、そうでない場合もある）
- ミスの再発を防ぐために、プロセスや承認を増やす
しかし、こういった「ミスをした人を責める」（関係者の懲戒、再訓練、手続きの追加など）だけの対応では、昨今の複雑なシステムの運用においては、有用性に限界があるだけでなく、逆効果になる可能性があります。組織の学習を阻害し、生産性を悪化させ、かつ対策としても不十分となると考えられます。（と、「ヒューマンエラーを理解する―実務者のためのフィールドガイド」に記載されているそうです。）
ヒューマンエラーの捉え方（DevOpsやSREにおける考え方）
事故が起こった状況/個人の意思決定プロセスについて理解することは、組織が単に個人を罰した場合よりも、再発防止に効果があるという考え方に立っています。
- ヒューマンエラーは組織/システムの深くにある「脆弱性」によって引き起こされる
- 失敗について、「状況的側面」 と 「失敗に近い個人の意思決定プロセス」 に焦点を当て調査することこそが意味がある
- 「事故がどのように起こったか」についての理解の欠如は、同じ事故が繰り返されることを保証してることになり、特定の人物を懲戒したとしても、将来的に別のエンジニアが繰り返す可能性がある
「失敗に近い個人の意思決定プロセス」を、より正確に分析するためには？
ヒューマンエラーを、組織/システムの深くにある「脆弱性」を修正するための機会として活かすためには、間違い、エラー、スリップ、失効などを、「学習」の観点から見る必要があります。
そのためには、「なぜ、自分がその対応が正しいと思って実行したか」事故の一因となったエンジニアが詳細（以下のようなことを）に説明してもらう必要があります。（こうして聞き出して整理した内容のことをEstyでは「セカンドストーリー」と呼ぶそうです。）
- 発生したイベントのタイムラインについての彼らの理解
- 状況をどのように理解したか
- 行動の選択肢として考えたこと、期待/仮定した結果、選択した理由
上記を、ありのままに説明してもらうにはどうしたらよいでしょうか？
少なくとも、叱責されると思っている場合、そのような詳細をありのままに語ることは難しく、直接障害に関わったエンジニアが「安心して詳細を語れる」状況にすることがとても重要です。
そのため、「Blameless」であることが重要となってきます。（言い換えると、心理的安全性になりますね。）
EstyのJohn AllspawがSRE Confのセッションで講演した動画で「他の人のために物事をより良くすること」に価値を感じるエンジニアは多くいる」という発言をしていました。（たしか）
エンジニアが、自分が犯した間違いについて安心して詳細を説明できるようになると、他のメンバーが将来同じエラーを回避できるよう支援する傾向がある、とも言われています。（Estyの記事「Blameless PostMortems and a Just Culture」参照。）
ヒューマンエラーは出発点
Sidney Dekkerも、「ヒューマンエラーは結論ではなく、出発点」と言っているそうです。
具体的にどう調査すればいいのか？
根本原因分析の限界
ヒューマンエラーの再発防止をするためには、「根本原因分析」が必ずしも重要とは限りません。
よく使われている「5 whys」（なぜなぜ分析）ですが、SREの記事や資料では、以下の課題が指摘されています。
- 「何故」に対する回答のうち、1つを選択して「何故」を繰り返すことにより、多くの重要なことを見逃す可能性がある
- 因果関係を分析し「個人」の原因としてしまう可能性があり、分析の過程で問題に関わったエンジニアが安心して「自分のストーリー」を話せなくなる可能性がある
※5Whysを否定する意図はありません。
※5whysは「トヨタ生産方式を構成する代表的な手段の一つである。 」とWikipediaなどでも明記されていますが、（私個人ではなくトヨタさんとお付き合いの長い知り合いのエンジニアからのまた聞き情報ですが）本来のトヨタ式でのなぜなぜ分析では「5つの観点で」何故を掘り下げていくということも求められているそうです。「1つの観点で5回何故を繰り返したらおしまい」というものではないそうです。
どなたかトヨタ式本来の「5 Whys」に詳しいかたがいらっしゃいましたら、コメントください。
Infinite hows（無限のHow）
さて本題です。
5 Whysでは、“Whyをいつ始める/辞めるか“を人が選択している限り、根本原因は「人が決めている」のであり、「見つかる」というのは神話である、とされています。
そのため、「Why」ではなく「How」で質問することが推奨されています。（参考：「The infinite hows」）
「あるサブシステムが間違った方法で使用されたため、システム停止が発生しました」という状況で、WhyではなくHowで質問してみます。問題を引き起こした（間違ったサブシステムの利用を行ったサービス側の）関係者に、なぜそういう状況になったのかを聞き出す質問の例です。
- （リーダーは）プロジェクトの範囲をどのように判断したのか？
- （リーダーやメンバーは）新しい機能の設計時に既存機能への影響をどのように検討/判断したか？
- （設計者は）利用対象のサブシステム側への問合せの必要性をどのように検討/判断しか？
- （チームとして）リリースの判断基準をどのように設定していたのか？
- （開発者は）コードがデプロイされる前に「期待通りに機能する」という確信を、どのように得たのか？（テストやレビュー等）
- （チームとして、設計に関わったメンバーとして）時間的なプレッシャーは、どの程度で、どのように感じたのか？
・・・こうしてみると、プロジェクト開始時に関係チームの整理やコミュニケーション・パスの定義を見直す（関係システムについて概要を説明してもらったり、相談にのってもらえるようにするなど）、リリース時の自動テスト等の仕組み、設計レビューのプロセス、ドキュメントの整備等で、防げることもあるかもしれない、、と今後のアクションが色々見えてきます。
続けてみましょう。
「サブシステムが間違った方法で使用されたのは、実装したエンジニアが正しい利用情報を知らなかったためです」とされています。メンバーにもう少しHowで質問してみましょう。
- メンバーの調整や役割分担をどのように検討したか？
- コード実装時にどのようなアプローチをとったのか？
- 利用対象のサブシステムのAPI仕様書、ドキュメントのうち、何を参照したか？
- API仕様書の記述をどのように解釈したのか？
- 実装に迷ったのはどのタイミングか？どのように解決したのか？
- コードレビューやテストはどういった形で実施したのか？
・・・ペアでプログラミングする、レビューの仕方を工夫する、ことで防げることもあるかもしれない、、と思えてきます。更に、利用される側のサブシステムのAPI仕様書やドキュメントについても改善のポイントがあるかもしれません。
Infinite howsのポイント
質問する際には以下に注意する必要があります。
- 「ストーリーを積極的に深堀りし、偏見（および判断）を交えないようにする必要がある」ことを理解する
- 記憶を「上書き、補正」すると思われるデータを流さないように尋ねる
- 問題となった分岐点を特定するため、それぞれの時点で、その状況に関わった人々にはどのように見えたかを段階的に調査し、再構築する
合図、解釈、エラー、以前の知識/経験、目標行動を起こす、結果、コミュニケーション、ヘルプ 、といった観点での質問が有効とされています。
- 「何に気づいた/見たか？」「何に気づけなかった/見えなかったか？」
- 状況に対処するためにどのような知識を用いたか？
- 関わったメンバーに、この状況の対処に役立つ経験があったか？
- 関わったメンバーは、状況がどのように進むと予想したか？どのようなオプションがあると考えたか？
- 自分以外の（組織や運用ルール等の）影響によって、状況の解釈や行動の判断に役立ったものは何があるか？
Estyの記事はとても参考になる深い記事でしたが、ファシリテーションのガイドなどもGitHubに公開されています。自分で読み込んで、いつか記事に書きたいです。
まとめ
- インシデントの再発防止、運用の継続的な改善には、「過去のインシデントから学ぶ」ことが必要
- 「非難の無い」ポストモーテムこそ、学びには有効である
- 「根本原因を見つける(決める)」のではなく、「Howを繰り返し、潜在的な脆弱性を見つけ、改善策を考える」
以上。