ソフトウェア開発で障害が起きたとき、私たちはつい「なぜ起きたのか」を丁寧に掘り下げたくなります。経緯を整理し、関係者の判断をたどれば、次はうまくいくはずだと考えるからです。この記事は、その考え方に静かに異議を唱えます。著者がある幹部から投げかけられた「詳細はいらない」という一言を起点に、説明を尽くすことと、再発を防ぐことは別だと訴えています。
著者は数か月前、エンジニアリングの担当者とその上司、さらにその上司でもあるSVP of engineeringの三者で呼び出しのような会議に参加しました。何か問題が起きたのですが、致命的ではないものの、SVPが直接出てくる程度には重要だったそうです。著者が経緯を説明しようとすると、そのSVPは「Michael, I don't want the details」と話を止めました。
その言葉に、著者は最初、冷たさや切り捨てを感じます。だがSVPの説明を聞いて考えを改めます。相手は、詳細を聞けば「なぜそうなったのか」は十分に理解できるし、関係者がその時点で合理的に見える判断をしたこともわかってしまう、と言うのです。誰も悪意で動いたわけではなく、状況なりに妥当な選択をしていた、となれば、周囲は納得し、同情もする。すると「では次はどう変えるか」という話が先送りになり、同じことがまた起きる。だから彼が欲しかったのは原因の物語ではなく、次に何を変えるのか、だったのです。
著者はここで、障害後に多くの組織が「なぜこれが起きたのか」と尋ねるやり方を批判します。タイムラインを作り、意思決定を並べ、依存関係を洗い出し、最後に「その時点では筋が通っていた」という文書をまとめる。すると全員がうなずき、理解した気分になって終わる。しかし、理解は修正ではありません。むしろ、説明がうまくできるほど「仕方なかった」で終わりやすくなり、変化の圧力が弱まると著者は言います。
そこで彼は、障害後に問うべき質問を変えます。「なぜ起きたのか」ではなく、「次に同じ種類の失敗が起きにくくなるよう、何を変えるのか」。原因の物語よりも、変更点を決める問いに寄せるべきだというのです。
本文では具体例も挙げています。たとえば「Aliceが休暇中で、BobがWidgetsチームの担当だと思っていたので見逃した」という説明があったら、そこで止まるのではなく、不在時でも責任の所在が曖昧にならないようにするにはどうするかを考える。あるいは「要件がリリース3日前に変わった」というなら、リリース直前の変更にどう対応するかを決める。「夜の間に価値の低いアラートを20件処理した後に、当番のエンジニアが見逃した」というなら、アラートのノイズをどう下げるかを考える。要するに、問題を起こしたのは個人よりシステムであり、変えるべきはたいてい人ではない、という立て付けです。
ただし著者は、プロセスを増やしすぎることも警戒しています。「再発防止のために新しい手順を増やせばよい」とやりすぎると、働きにくい環境になる。すべての失敗に重い仕組みが必要なわけではない。防止コストが高すぎるなら、リスクを理解したうえで受け入れる判断もあり得る。その場合に重要なのは、「もっと気をつけます」と雰囲気だけ整えることではなく、「このリスクは意識して受け入れている」と自覚することだとしています。
最後に著者は、SVPの「詳細はいらない」を、焦りではなく信頼の表明として受け取ったと書きます。相手は、関係者が無能でも悪意でもない前提から始めていた。もし調査で別の事実が出れば、その時に対処すればいい。だが、共感が組織の免罪符になってしまい、変えるべきことから目をそらすのは避けたい。人はたいてい、与えられた情報・インセンティブ・制約の中で最善を尽くしている。だからこそ、リーダーが言うべきなのは「詳しくはいい。何を変える？」なのだ、というのがこの記事の芯です。
この話でおもしろいのは、著者が「説明するな」と言っているわけではないことです。むしろ逆で、説明のうまさが組織を鈍らせる瞬間を問題にしています。障害報告書が立派になるほど、関係者は安心します。誰も怠慢ではなかった、判断は妥当だった、状況は複雑だった。ここまでは事実として正しいことが多い。だが、その正しさが「では現状維持でよい」に変わると、説明は防波堤ではなく麻酔になる。私はここにかなり現実的な怖さがあると思います。
特に大きい組織ほど、「犯人探しをしない文化」が良い方向に働く一方で、変更の決断までやわらかくしてしまいがちです。人を責めないことと、仕組みを変えることは別なのに、会議ではしばしば混ざります。誰も悪くない、だから難しい、だから次回は注意しよう、で終わる。著者が嫌っているのはこの流れでしょう。注意するだけでは、注意する人がいなくなった瞬間に崩れます。退職や異動が起きたら消える改善は、改善ではないという指摘はかなり鋭いです。
本文のもう一つの核は、「人はだいたい善意でやっている」という前提です。これは少し耳ざわりがいいだけの理想論にも見えますが、実務ではかなり重要です。なぜなら、問題の再発はたいてい、誰かが明確に悪かったからではなく、条件がそろうと自然に起きるからです。責任者が休暇中、引き継ぎが曖昧、アラートが多すぎる、要件変更が遅い。こうした条件を放置したまま「次は丁寧にやる」で済ませるのは、再発を人の記憶力に賭けるのと同じです。
ただし、ここで注意したいのは、仕組み化を万能薬にしないことです。著者も書いている通り、何でも手順化すればよいわけではありません。私はむしろ、良い問いは「仕組み化するかしないか」ではなく、「この問題は人の努力で吸収するには高すぎるか」を見極めることだと思います。低頻度で、影響も限定的で、対策コストが大きいなら、あえて受け入れる判断もありうる。その判断まで含めて設計するのが、大人の運用です。
SVPの発言は、文面だけ見るとかなり強いです。部下にとっては圧を感じるでしょうし、「説明する価値がない」と受け取られても不思議ではありません。けれど著者の解釈が面白いのは、そこに信頼を読み取った点です。私はこの読み替えに納得する一方で、同時に、発言者の振る舞いの質がかなり高かったのだろうとも思います。単に詳細を嫌がったのではなく、「事情はわかった。では次に何を変えるかを決めよう」という順序を、感情ではなく役割として押し出したわけです。
現場では、障害の説明を聞く側が「理解した気になる」ことで満足しやすいし、説明する側も「理解してもらえた」で安心しやすい。両者の気持ちが落ち着くぶん、具体的な変更が置き去りになる。だからこそ、リーダーが最初に求めるべきものは詳細ではなく、変化の設計なのだと思います。もちろん、原因究明そのものを軽視してよいわけではありません。再発防止の前提として事実確認は必要です。ただし順番が逆になると、理解が目的化する。この記事はその危うさを、かなり実務的な言葉で突いています。
この文章が刺さるのは、ポストモーテムや障害レビューが「やった感」を作る儀式になっている組織だと思います。タイムラインは整う、責任者は出る、再発防止策も並ぶ。けれど数か月後にまた似た事故が起きる。そんな現場では、原因説明の巧さがむしろ危険です。説明書が立派であるほど、未解決のまま残る構造的な欠陥が見えにくくなるからです。
一方で、この記事は「説明を捨てろ」と極端に振っていないのが良いところです。私はそこに現場感を感じました。人はまず事情を理解したいし、納得もしたい。だから本当は、説明と変更を切り分けて考える必要がある。説明は理解のため、変更は再発防止のため。この二つを同じ会議で雑に混ぜると、どちらも中途半端になります。著者はその混線をほどきたかったのだと思います。
