あなたのチームが製品を発売する。競合他社が先に市場に出て、あなたの「アップグレード」が小さな改良に見えてしまうような機能を備えている。あなたの最初の本能は責任を取ることではなく、物語を構築することだ。チームの準備が整っていなかった。リソースが限られていた。タイミングが不可能だった。
これらはすべて真実かもしれない。しかし、同様に真実なのは：あなたは当然必要だったはずの競合情報なしに発売を承認したということだ。これは予見不可能な盲点ではない。これはあなたが責任を持っていた決断だったが、失敗した途端に誰も責任を持たなくなった。
自己奉仕バイアスは単にあなたの自尊心を守るだけでなく、あなたのシステムも守る。もしこの失敗が本当にあなたの責任なら、それを生み出したプロセスを検証する必要がある。チーム構造に疑問を投げかける必要がある。意思決定プロトコルの全面的な見直しが必要だ。それはコストがかかる。それは不快だ。だからこそ、代わりに物語を作る機械が動き出す。あなたは何が壊れたのかを探しているのではなく、その破綻が合理的に見える説明を探しているのだ。
説明と検証の違い
同じ製品発売の失敗を2つの方法で処理した例を見てみよう：
説明の道筋：
あなたは事後検証会議を招集する。会議は「何が起きたのか理解しよう」という言葉で始まる。しかし実際にあなたが意味しているのは「これが筋の通った話に見えるような出来事のバージョンを構築しよう」ということだ。
マーケティングは3ヶ月前にリソース制約を指摘していたと言う。エンジニアリングはテクニカルデットを考えるとタイムラインは常に厳しかったと言う。プロダクトは競合環境が誰の予測よりも速く変化したと言う。全員が証拠を持っている。全員の話に一貫性がある。
あなたはこれを次のようにまとめる：「私たちは急速に変化する市場で不完全な情報のもとで運営していました。結果は望んだものではありませんでしたが、制約を考えると全員がうまく実行しました」
会議は終わる。何も変わらない。あなたは知っていたことを前提に失敗が避けられなかった理由を説明したにすぎない—つまり、それを生み出したすべてのプロセスと前提を検証したことになる。この失敗を生み出したシステムは、全員が自分の役割を正しく果たしたという理由で、検証から守られることになる。
あなたは循環を閉じた。原因を割り当てた。誰も責められていると感じないよう心理的安全性を維持した。事後検証で有能なリーダーがすべきことをすべて行った。
そして、3ヶ月後に別の製品について同じ会話をすることを保証したのだ。
検証の道筋
あなたは同じ会議を招集する。しかし次のように始める：「私は適切な競合情報なしにこの発売を承認しました。それは私の責任です。今、なぜ私がその判断をすることに安心していたのか理解する必要があります」
部屋の雰囲気が変わる。あなたは個々のパフォーマンスを守るのではなく、実際のシステムを検証することを安全にしたのだ。
マーケティングは制約を指摘したと言うが、それを発売を阻止するものとして枠付けしなかったことを認める。彼らは誰か他の人が競合のタイミングを追跡していると思い込んでいた。エンジニアリングはタイムラインが厳しかったと言うが、以前のプロジェクトでの反発が緊急性への抵抗と解釈されたため、強く反対しなかったことを明かす。プロダクトは環境が変化したと言うが、機能は追跡していたものの、発売能力は追跡していなかったことを認める。
今、あなたは全く異なるものを見ている。
あなたの組織では、制約の指摘が意思決定の見直しを引き起こさない。技術的懸念はあなたに届く前に文化的解釈でフィルタリングされる。競合情報は競合他社が持っているものに焦点を当てており、彼らが何をしようとしているかには焦点を当てていない。「誰か他の人がそれを処理している」という部門間の思い込みが、失敗が露呈するまで誰も気づかないギャップを生み出している。
問題は誰がボールを落としたかではない。なぜあなたのシステムが意思決定ポイントで適切な情報を表面化させないのか、なぜ欠陥のある判断に反対することが文化的にリスクを感じるのか、そしてなぜ全員が自分の役割を正しく実行しているのに集合的な出力が失敗するのかということだ。
これを修正するには、情報の流れ方、懸念事項のエスカレーション方法、意思決定の検証方法、部門間の引き継ぎ方法を変える必要がある。あなたが信頼してきたプロセスや強化してきた文化的規範が単に不完全なだけでなく、あなたが予測不可能な状況として説明してきた予測可能な失敗を生み出していることを認めることを意味する。
検証の道筋は全員が気分よく感じる総括で終わらない。それはシステムの機能不全のリストと、その修復がいつ完了するかの明確なタイムラインがないまま終わる。それは未解決で、不快で、組織的にコストがかかる。
だからこそ、ほとんどのリーダーは説明の道筋を選び、それを学習と呼ぶのだ。
あなたが実際に構築しているもの
失敗を検証するのではなく説明するたびに、あなたは組織に特定のスキルを訓練している：防御可能な物語を構築することだ。あなたのチームは制約を考慮すると失敗が合理的だったことを示すのが上手くなる。彼らは誰も責任を問わず、構造的な変化も必要としない、物事が間違った理由についての洗練された説明を開発する。
時間の経過とともにこれがどのように見えるかを観察しよう：
製品発売が失敗する。あなたはそれを競合環境の変化として説明する。6ヶ月後、市場拡大が失敗する。あなたはそれを誰も予想していなかった規制の複雑さとして説明する。1年後、重要なクライアント関係が悪化する。あなたはそれをあなたのコントロールを超えたクライアント側のリーダーシップの変化として説明する。
各説明は防御可能だ。各説明は因果関係の必要性を満たす。各説明は大きな混乱なく全員が仕事に戻ることを可能にする。
しかしあなたが見逃しているのは：あなたは同じ不十分な情報収集を使用して3つの競合ウィンドウを逃した。あなたは標準的な慣行であるべき規制レビューなしに3つの新しいイニシアチブに参入した。あなたは、チームが警告として解釈しなかった同じ初期警告サインを示した3つのクライアント関係を失った。
失敗はランダムではない。それらはパターン化されている。しかし説明は、各説明が失敗をシステム的に予測可能なものではなく状況的に独自のものとして扱うため、あなたがそのパターンを見ることを妨げる。
あなたの組織は失敗から学んでいない。それは失敗が防げなかった理由の尤もらしい理由を生成することが上手くなっている。そしてそれらの説明が洗練されればされるほど、あなたの機能不全のシステムは検証から守られる。
これが機能していることを示す兆候
リーダーは責任を回避していると思っていない。彼らは厳格に責任を追及していると思っている。
ギャラップの調査によると、リーダーの46%が例外的または優れたパフォーマンスに対して全員に責任を持たせることにおいて自分を例外的または優れていると評価している。しかし、マネージャーの30%しか直属のリーダーを同様に評価していない。これはコミュニケーションスタイルについての認識のギャップではない。これは2つのグループが異なる現実を正確に描写している診断的証拠だ。
リーダーは徹底的な事後検証を行い、明確な原因を特定し、学んだ教訓を抽出し、結果に対して人々に責任を持たせているため、責任を追及していると感じている。すべての責任メカニズムが機能している。彼らは仕事をしている。
従業員は、同じシステムの失敗が繰り返される一方で、それぞれが誰も責任を問わず何も変えなかった独自の状況として説明されるのを見ているため、責任を感じていない。事後検証は行われた。教訓は文書化された。失敗のパターンは続いた。責任はどこにあるのか？
両グループは正しい。リーダーは人々に責任を持たせている—既存のシステム内で彼らの役割を実行することに対して。リーダーがしていないのは、予測可能な失敗を生み出すことに対してシステム自体に責任を持たせることだ。説明によって、あなたはシステム設計の責任を回避しながら、実行に対する責任を維持できる。
46%と30%の間のギャップは認識についてではない。それはあなたが何に責任を持たせるかについてだ：欠陥のあるシステム内での個人のパフォーマンスか、システム自体か。
検証が実際に必要とするもの
システムに責任を持たせること—実際に説明ではなく検証すること—は、ほとんどのリーダーが準備していないものを必要とする。
検証は責任のように感じないのは、それがあなたがどれだけ解決できていないかを露呈するからだ。
製品発売の失敗を検証するとき、あなたは学んだ教訓と明確なアクションアイテムで事後検証を終えるのではない。まだ答えのないシステム設計に関する質問で終える：
なぜ私たちの文化は技術的な反対意見を抵抗ではなく専門知識として解釈しないのか？意思決定の速度を停止させることなく、それをどのように変えるのか？
どのような構造が、失敗になる前に部門間のギャップを表面化させるだろうか？
なぜ私は標準であるべき競合情報なしに発売を承認することに安心していたのか？どのような意思決定プロトコルが私を止めただろうか？
これらの質問には明確な答えがない。あなたは意思決定インフラが不完全であることを認めなければならない。人々が「私たちの働き方」として内面化しているプロセスを変える必要がある。現在、不完全ながらも組織を支えているシステムを再構築している間、長期的な不快感に耐える必要がある。
説明は即座の解決を提供する。検証は、実際に壊れたものを修正できるかどうかについての長期的な不確実性を提供する。
しかし検証は説明ができないものを明らかにする：実際に何を変える必要があるかについての診断的可視性だ。
製品発売の失敗を検証すると、競合情報収集は18ヶ月間既知のギャップであり、3つの異なるチームがそれを回避してきたことがわかる。厳しいタイムラインは緊急性を生み出しているのではなく、あなたの決定に挑戦すべき専門知識を抑制している。そして会議ではシームレスに見える部門間のコラボレーションは、検証されていない引き継ぎポイントで崩壊する。
これらはどれも快適ではない。すべて修正可能だ—しかし、あなたがそれを見る意志があるときだけ。
説明はあなたのシステムを無傷に保ちながら、失敗から価値を抽出しているように見せる。検証はあなたのシステムが設計通りに機能していないことを見ることを強制する—それらは、あなたが予見不可能な状況と呼んできた予測可能な失敗を生み出している。
検証を選ぶリーダーは、失敗からの学習においてより回復力があるわけでも優れているわけでもない。彼らは組織インフラが実際に健全かどうかについての長期的な不快感を持って運営する意志がある。彼らは失敗を説明を必要とする例外的な状況としてではなく、システム設計に関する診断データとして見る意志がある。
それはコストがかかり、不快で、ほとんどのリーダーはそのコストを支払わない—彼らが悪いリーダーだからではなく、説明が組織的混乱なしに検証が約束するすべて（責任、学習、改善）を提供するからだ。
だから彼らは事後検証が厳格で、学んだ教訓が文書化され、同じ失敗が予定通りに繰り返し起こる組織を構築する。全員が説明が責任であり、検証はオプションであり、次の失敗は同様に満足のいく、防げなかった理由の物語とともにやってくることを学んでいる。
