[Verica - Inhumanity of Root Cause Analysis](https://www.verica.io/blog/inhumanity-of-root-cause-analysis/) > ソフトウェア業界で一般的に行われている[[Root Cause Analysis]]（RCA）は、複雑なソフトウェアシステムにおける将来のインシデントを防止する上で、何の価値ももたらさない。それどころか、責任を押し付ける階層構造を強化し、学習や創造性、心理的な安全性を阻害する。要するに、RCAは非人道的な行為である。 - RCAを奨励する一般的な誤解は、「根本原因」を理解しなければ、何が問題なのかを解決できないというものです。 - その解釈の促進がRCAである。RCAを開始する前に、インシデントが「修正」されていることに注目してください。- - 「根本原因」と「[[Least Effort to Remediate]]（LER）」を区別してみる。 - インシデントが進行中である限り、LERを追求するのは絶対に正しい。 - ある大規模停電の例。この停電は十分に大規模であったため、検知までの時間はほぼ即時であった。しかし、復旧には少し時間がかかり、約40分かかった。設定ファイルの1行を元に戻すことで、サービスを復旧させられた。 - 事件の発端は、一行設定の公表に相当する。それを元に戻すのがLERだった。この1行がインシデントの「根本的な原因」だと言いたくなる。 実際、LERは「根本的な原因」については何も言っていない。 - 設定が間違っていたのではなく、設定ファイルを解釈するコードが十分に柔軟でなかった - 問題の行を書いた人は、その構成がシステムにどのような影響を与えるかについて、チームやトレーニング、導入プロセスで十分な文脈を与えられていなかった。 - このシステムでは、構成の変更を一度にグローバルに展開することが可能だった - 運用に近い組織では、機能開発者が設定ファイルを実際にどのように使用するかを理解するために、開発者と十分な時間を共有することができなかった。 - その人のマネジメントチェーンが、変更を押し進める前に、より多くのテスト、調査、レビューを行えるように適切な優先順位を設定しなかった。 - その変更にサインオフした同僚が、外部のリソース制約のために多忙を極め、プルリクエストを適切にレビューする時間がなかった。 - 新しい設定が正しいことが確認されるまで古い設定と並行して実行するブルー/グリーンデプロイメントを実行するために、デプロイメントコストを高くすることを支援できるほど、会社は儲かっていない。 LERが事故後のレビュープロセスで誤解を招いている。これらの代替案はどれも、一本の線を元に戻すほど簡単に修正できるものではない。どれも同じ「根」から生じていることを示唆するものではありません。どれも同じ人に責任を負わせるものではない。しかし、これらの選択肢はすべて、設定ファイルの1行よりもレジリエンスにとって基本的なものである。 ### Whither the ‘Root Cause’? 「根本原因」が何であれ、それを特定し、再発防止策を講じる必要があると考えたくなるが、2つの根本的な問題があります。 - RCAのプロセスがポジティブな結果をもたらさない - 「根本原因」が実際には存在しない ...すべての複雑なソフトウェアシステムは社会技術的なシステムでもある。ハードウェア、コード、そしてそれを維持する人間で構成され、彼らの不完全なメンタルモデルについて互いに理解しがたい方法でコミュニケーションをとっている。社会技術的なシステムは直線的ではなく、予測可能でもない。決定論的でもない。そして、いくらデータを集めても、客観的ではない。 上のリストで列挙したように、この事件には他の要因がある。世の中全体を考える必要はない。もし違っていたら、システムがダウンすることはなかったという世界になるものだけに絞って考えればいいのだ。これには、設定ソフトウェア、設定を解釈するソフトウェア、それに依存または影響する他のすべてのシステム、関係する他のすべてのサービスの堅牢性とフォールバック機能、雇用と訓練の方法に関する経営者の決定、暗黙のうちに期待されている仕事の文化、組織間の関係と政治、会社全体のすべてのリソース配分、その他諸々が含まれます。そのセリフを書いた人の個人的な生活だって、その時の精神状態や認識に影響を与えたかもしれないのだから、関連性はある。十分な時間と十分な想像力があれば、無限に近い数の要因を思いつくことができるのだ。 実際、問題の設定を書いた人は、最近新しい猫を飼い始めたばかりで、その猫が前夜遅くまで起きていたのですから、本当の「根本的な原因」は猫にあるのかもしれませんね。もちろん、それは不合理なことですが、恣意的なものです。設定変更に線を引いて、それを根本原因と呼んだり、チームの力学と呼んだり、その他いくらでもあることと同じで、それ以上でも以下でもない。 あるものを「根本原因」として選択することと、別のものを選択することは、現実には存在しないことです。それは、ある特定の人間が、起こったことについて自分の物語に投影したものである。それは物語だ。 ### So What is RCA Actually Doing? ほとんどのRCAプロセスでは、上記のインシデントの「根本原因」として設定ファイルを特定し、そのファイルの作成者に責任を負わせることになるでしょう。これは、一種の「誰が最後にそれに触れたか」という責任の所在を示す慣習に従ったものである。 私がJohn Allspawから初めて聞いた例を言い換えると、あなたの会社で有名な成功を思い浮かべてください。おそらくあなたの会社は、収益目標を達成したり、大きな新機能のバージョンアップをリリースしたり、顧客成功の目標を達成したりしたことでしょう。では、ある特定の時期に起こったことで、その成功に貢献した人物は誰でしょうか？ もちろん、それは愚かな質問です。成功の責任は皆にある。組織全体が、時間をかけて、100万通りの方法で成功に貢献したのだ。それなのに、なぜ失敗を、ある特定の時期にあることをした一人の人間のせいであるかのように扱うのだろうか。成功の責任は全員にあるのなら、なぜ失敗の責任も全員にないのでしょうか？ その答えは、RCAは「根本原因」があったとしても、それを見つけるためのものではないからです。RCAは、責任の所在を明らかにするために存在する。具体的には、最下層に責任を見いだすことで、上層部の人間に対して倒錯した秩序を維持するのである。 なぜなら、RCAは、難しい質問をしたり、より意味のある解決策を開発するために資源を配分したりすることから、簡単に逃れられるからである。連鎖の下を指さし、前線のどこかに責任を負わせることで、経営陣は、システムをより堅牢にするために、より深く掘り下げることや、より困難で根本的な作業を行う必要を免れることができます。 このようなヒエラルキーの都合の悪い副作用として、個人は恥をかかされ、しばしば「二度と起こらないようにする」ために追加的な仕事を課される。この恥と罰は公式の方針で認可されているため、チームの人々の心理的安全、特に報復なしにミスをする自由が損なわれてしまうのです。 ほとんどの人がそうであるように、会社にとって最善のことをするつもりで職場に来ているのに、そのつもりにもかかわらず恥をかかされたり罰を受けたりすると、組織に属するすべての人の人間性を軽んじてしまうことになります。それは、特別視された人物を卑下し、その尊厳を打ち砕くことになるのです。だから、私たちはRCAを非人道的な行為と呼ぶのです。