※本記事にはプロモーション（広告）が含まれています。
「車に乗らなきゃいいんじゃない？」――。この記事では、ビジネスの現場で起きるこの現象の裏にある「OSのバグ」を、アーキテクトの視点で解剖します。
よくある場面
「車に乗らなきゃいいんじゃない？」
ある時、友人がそう言いました。近所で起きた大きな交通事故のニュースを見ての感想です。
確かに、交通事故を防ぐための根本解決を突き詰めていくと「車に乗らない（外に出ない）」という究極の選択肢に行き着きます。よくあるアメリカンジョークのような極論ですが、ビジネスの現場では、これと全く同じ「ゼロリスク信仰によるシステムのフリーズ（停止）」が毎日起きています。
新しい施策やルールを導入しようとする際、必ずこう言う人が現れます。
「でも、もし〇〇というイレギュラーが起きたらどう対応するんですか？」
「××のケースも想定しておかないと危険です」
彼らは、発生確率1%未満のレアケース（例外）を恐れるあまり、すべての可能性を網羅した完璧なマニュアルができるまで動こうとしません。結果として、99%の正常なビジネスの進行が完全にストップしてしまいます。
なぜ起きるのか ― バグの構造
なぜ、彼らはこのような過剰な防衛（エッジケースへの執着）に走るのでしょうか。
それは、「リスクを取らないことによるリスク（機会損失）」を正確に見積もるOSが実装されていないからです。
見えるリスクの裏には、必ず逆ベクトルのリスクが存在します。
「銀行に預金するよりも投資しろ」と言われても投資できない人は、投資によって「資産が減るリスク」を極端に恐れています。しかし実のところ、彼らはインフレや経済成長の中で「投資でリターンを得ない（相対的に資産が目減りする）リスク」を無自覚に取っているのです。
コロナ禍の初期もそうでした。「外出による感染リスク」をゼロにするため、人間的な活動を極限まで制限しました。当時は未知のウイルスであり、最大多数を守るための手段としてそれは正しい選択でしたが、結果として「活動を制限したことによる経済的・精神的リスク」で命を落とした方も存在します。もし「人のいない山道をバイクで走る」といった、許容可能なリスクを少しでも取れる（逆ベクトルのリスクを回避する）設計ができていれば、最悪の結果は防げたかもしれません。
車に乗らなければ、事故には遭いません。しかし同時に「遠くへ早く移動する」という絶大なリターンも永遠に手放すことになります。
目の前の「1%のエラー（目に見えるリスク）」に怯え、システムを停止させて「99%の機会損失（目に見えないリスク）」を垂れ流す。これこそが、ゼロリスクを求める大衆（QA層）の致命的なバグです。
では、この「もしも話の無限ループ」に陥った部下に対して、アーキテクト（PM）はどのようにシステムを再起動し、リスクを取らせればよいのでしょうか？
まず試せる一手：「どこまでの失敗なら許容するか」を数字で伝える
部下が例外ばかり気にするのは、上司が「失敗ゼロ」を求めていると思い込んでいるからです。システムの運用には、許容できるエラーの量を先に決めておく「エラーバジェット」という考え方があります。
「懸念はもっともです。ただ、今回は100件中5件のトラブルまでは想定内です。1%の例外のために時間をかけず、今の仕様で進めてください」
上に立つ人が許容範囲と責任を先に引き受けると、過剰な例外処理の追加が止まり、仕事が前に進みます。
ここまでが、最初の一手です。この一手を習慣にして、同じバグを繰り返さない仕組みにするための残りの手順は、noteで公開しています。
残りの解決策（How）はnoteで公開中
ここから先の具体的な解決策・コマンドは、noteの記事「アーキテクトの過去問」として公開しています。
このテーマを深めるおすすめの本
『FACTFULNESS（ファクトフルネス）』（ハンス・ロスリング ほか）
人はなぜリスクを実際より大きく見積もってしまうのか。「恐怖本能」に振り回されず、データでリスクを見る習慣をつくる一冊。
▶ 楽天で探す
▶ 耳で読むなら：新作続々追加！オーディオブック聴くなら – audiobook.jp
※本記事は、noteで公開した「「車に乗らなきゃいい」という思考停止。1%の例外処理でシステムを止めるゼロリスク信仰のバグ」の無料部分をブログ向けに再構成したものです。
コメント