「詳細はいらない」と言ったSVPの一言が、組織を変える

これには共感するし、多くのチームがそうやって動いているが、根本的には同意できない。

AmazonのCoE主導のエンジニア文化がこれほどのオペレーショナル・エクセレンスを実現した理由の一部は、責任が管理チェーン全体に押し上げられたことにある。あなたのマネージャーがsev2の根本原因を掘り下げなければ、ディレクターが必ずやったし、ディレクターがやらなければ、Andy Jassyがそれを指摘した。

それは多くの無駄な作業のように聞こえるし、実際かなりの部分がそうだろう。しかしその裏返しとして、実際の根本原因が対処され、根本原因が深刻な部門横断的リソースを必要とする場合、エスカレーションによって必要なものが得られた。ロードマップから3ヶ月分の作業を外す承認が必要？VPが電話に出てその判断を下す。他のチームに問題を修正させる必要がある？彼らのディレクターより上のプリンシパルエンジニアが仕事を推進する。などなど…

この記事のSVPが表現した感情に賛成だ：「我々は合理的な選択を通じてこの点に達したとすでに信じている。同じことが再び起きないようにシステムをどう変えるかを話そう。」

彼の言葉選びは少し最適ではなかったと思う。しかし、要点は伝わった。

これには強く反対する。

良い解決策を導き出すには、問題をマスターする必要がある。それには多くの作業が必要だ。

> 問題を理解することは、それを修正することと同じではない。良い説明は事態を悪化させることがある。全員がその行動は合理的だったと同意した瞬間、何かを変える緊急性は消える。

これは非論理的だ。我々は行動が合理的だったかを評価するためにここにいるのではなく、悪い結果を避ける方法を考えるためにここにいる。もしすべての行動が合理的だったなら、問題は別のところにあり、それは適切な解決策を練る上で重要な発見だ。

著者は文字通り、なぜと問うのは間違った質問であり、代わりに「何を変えるのか？」と問うのが正しい質問だと言っている。その由来はわかるが、なぜ起きたのかを深く理解するまで、何を変えるのかを本当に答えることはできない。

> 組織に変化を促すには、「なぜこれが起きたのか？」と問うな。

> 代わりに、こう問え：

> 同じ種類の失敗が次に起きにくくなるために、我々は何を変えるのか？

なぜこれらがほぼ相互排他的であるかのように枠組みされているのか？理解できない。「どのように/なぜこれが起きたのか？」は「我々は何を変えるのか？」への答え方に情報を与える。次のセクション「合理的な人々」でさえ、「なぜこれが起きたのか？」に続いて「我々は何を変えるのか？」という形で同じように機能している。

この記事は「それはするな、これをしろ」というスタイルを達成するために、内部で矛盾しているように感じる。

非本質的と見なされたり、権威者の不興を買うことへの恐怖の風土が、優先順位の重大な不一致や信頼の崩壊を生み、それが様々な状況で組織の非効率の上流にある可能性があることに気づかずにはいられない。おそらくこの種のメタ問題への解決策は、思考リーダーたちが好んで言うように、高いレバレッジを持つのかもしれない。

ポストモーテムのプロセスはこれらすべてをカバーできる：

- 何が起きたか

- 影響

- 根本原因

- 何を変えるか（コミットメント）

根本原因を話さずに何を変えるかを話すことはできず、何が起きたかを話さずにそれを話すことはできない。また、リソースは限られており機会費用は現実であるため、実際の潜在的影響を議論せずにコミットメントのコストを検討することもできない。

経営陣が影響＋コミットメントの要約だけを受け取るのは構わない。しかし、ポストモーテムのプロセス全体が踏まれなければならず、一部の人々はすべての詳細を把握していなければならない。

「わかった、みんな働きすぎだ。このチームにもっと人を雇う必要がある。技術的負債が多すぎて、来週どれが爆発するか予測できない。変化は経営陣の態度から始めなければならない。」

おっと、これでクビだ。