例外対応をシステムで吸収し続けた末路

例外が起きるたびにフラグを足し、条件分岐を増やし、特別ルールを組み込む。例外をすべてシステムで吸収し続ける、という判断を重ねていく組織があります。

短期的には、現場の混乱は抑えられ、顧客対応も止まりません。だから「うまく対応できている」ように見えます。しかしこの選択は、組織を静かに追い詰めていきます。

例外の吸収は「判断を先送りする装置」になる

例外をシステムで吸収するということは、例外そのものを判断の対象から外すということでもあります。

「なぜ例外が起きたのか」「原則は何だったのか」「原則を変えるべきか」。そうした問いを持たないまま、技術的な対応で事態を収めてしまう。この姿勢が続くと、原則は更新されず、判断も積み上がっていきません。

システムが複雑になっていく3つの段階

① 例外が「設定項目」になる

最初、例外は一時的な対応として扱われます。やがてチェックボックスや管理画面のオプションとして残り始めます。この時点で、例外は「あってよい前提」になります。

② 例外が「前提条件」になる

例外が増えると、通常のフローより例外のフローのほうが多くなり、新人には理解できなくなります。システムは、原則ではなく例外を前提に動き始めます。

③ 誰も全体を説明できなくなる

最後には、「なぜこの仕様なのか」「どの条件で何が起きるのか」を誰も説明できなくなります。ここまで来ると、「改修が怖い」「触らないほうが安全」という空気が組織を支配します。

吸収し続けた先で、同時に起きること

例外をシステムで吸収し続けた結果、次の問題が同時に起きます。

• 業務の原則が消える。
• 判断理由が記録されない。
• 顧客価値の基準が曖昧になる。

システムはあっても、判断の軸がない。そういう状態です。

「顧客対応を止めない」と「原則を更新しない」は違う

見落としてはならないのは、「顧客対応を止めないこと」と「原則を更新しないこと」は同じではない、という点です。

顧客対応を止めないために、一時的に例外で対応するのは合理的です。けれども、その例外をいつまでもシステムに残し続けることは、判断の放棄に近づいていきます。

例外吸収をめぐる、二つの誤解

誤解①：システムで吸収しているから安全

安全に見えるだけかもしれません。実際には誰も判断しておらず、誰も責任を持っていない状態になっている可能性があります。

誤解②：いまは問題が起きていない

問題は、起きてからでは遅いのです。リスクはすでに、システムの中に積み上がっています。

自社の例外を点検する三つの問い

• この例外は、いつ原則に統合する想定か。
• 原則を更新する判断は、誰が担っているか。
• 例外が判断として記録されているか。

答えられないなら、システムが判断の代わりになってしまっているのかもしれません。

まとめ：原則なきシステムは、複雑になり続ける

例外をシステムで吸収すると、判断が消えます。判断が消えると、原則は更新されません。そして原則のないシステムは、複雑になり続けます。

システムで例外を処理しているのか、それとも判断を先送りしているだけなのか。それを見極めることが、この経営判断の核心です。