「とりあえずシステムで対応してきた」組織の行き着く先
例外が発生するたびにフラグを追加し、条件分岐を増やし、特別ルールを組み込む。こうして例外をすべてシステムで吸収し続けるという判断を重ねる組織があります。短期的には現場の混乱を抑えられ、顧客対応が止まらないため、「うまく対応できている」ように見えます。しかし、この選択は組織を静かに追い詰めていくのです。
経営判断レイヤー（Why）
例外吸収は「判断を先送りする装置」になる
例外をシステムで吸収するとは、例外そのものを判断対象から外すという意味でもあります。「なぜ例外が起きたのか」「原則は何だったのか」「原則を変えるべきか」といった問いを持たないまま技術的対応で事態を収める。この姿勢が続くと、原則が更新されず、判断が蓄積されない状態になります。
システムが複雑化する3つの段階
① 例外が「設定項目」になる
最初は例外は一時的な対応として扱われます。やがて、チェックボックスや管理画面のオプションとして残り始め、この時点で例外は「存在してよい前提」になります。
② 例外が「前提条件」になる
例外が増えると、通常フローより例外フローの方が多く、新人が理解できない状態になります。システムは、原則ではなく例外を前提に動くようになります。
③ 誰も全体を説明できなくなる
最終的には、「なぜこの仕様になっているのか」「どの条件で何が起きるのか」を誰も説明できない状態に陥ります。ここまで来ると、「改修が怖い」「触らない方が安全」という空気が支配します。
専門実装レイヤー（How）
システム吸収を続けた結果、何が起きるか
例外対応をシステムで吸収し続けた結果、次の問題が同時に発生します。
- 業務の原則が消える。
- 判断理由が記録されない。
- 顧客価値の基準が曖昧になる。
システムは存在していても、判断の軸が存在しない状態です。
「顧客対応を止めない」との違い
重要なのは、「顧客対応を止めないこと」と「原則を更新しないこと」は同義ではないという点です。顧客対応を止めないために一時的に例外対応をすることは合理的です。しかし、その例外をずっとシステムに残し続けることは、判断放棄に近づきます。
よくある誤解
誤解①：システムで吸収しているから安全
安全に見えるだけで、誰も判断しておらず、誰も責任を持っていない状態になっている可能性があります。
誤解②：今は問題が起きていない
問題は、起きてからでは遅い。リスクはシステム内に蓄積されています。
この判断で、最後に確認したい問い
この例外は、いつ原則に統合する想定か。
原則を更新する判断は、誰が担っているか。
例外が判断として記録されているか。
これらに答えられない場合、システムが判断の代替になっている可能性があります。
まとめ（正解は出さない）
例外をシステムで吸収すると、判断が消えます。判断が消えると、原則が更新されません。原則なきシステムは、複雑化し続けるのです。システムで例外を処理しているのか、判断を先送りしているのか。それを見極めることが、この経営判断の核心です。
