本エントリーはイノルールズ株式会社　白石浩一様が寄稿したエントリー（https://business.facebook.com/innorules.co.jp/）を転載したものとなります。

システムが本番稼動したあとでプログラムのミスが原因で不具合が発生する場合、elseに起因するバグが多く含まれます。業務アプリよりはOSに近いプログラムにその傾向があるようですが、例として受発注プログラムの事故について記します。

例）注文処理のプログラム開発でバグを作りこむケース

　ビジネスルール：信用払いの注文の注文金額の合計が10万円を超える場合は、与信確認をしてからでないと、注文を受け入れてはならない

　この仕様をそのままプログラミングして、

　if 注文形態＝信用払い &　注文金額合計＞10万円 then

メッセージ出力："注文前に与信確認が必要"

else

メッセージ出力："エラー"

　end if

（Business Rule Conceptsより引用一部加筆）

このロジックがシステムとしてカットオーバーされると、運用後に信用払いの注文が処理されないという事故が起こる場合があります。

仕様を確定したタイミングまたはプログラム開発時にelseの内容を保証していないことに起因します。そこでプログラミング時に担当者の判断でエラー処理とするロジックをつくりこんでしまいます。。

システム開発プロジェクト的には、要件を出し切っていない上流工程の設計ミスに当てはまりますが、ビジネス的には初期にすべての要件を出し切るのは難しい面もあります。

BRMSを導入すれば、要件整理からビジネスルールの実装までビジネスユーザが密に関わることができます。その過程で次のようなルールの追加が容易に想起されます。

ルール：信用払いの注文で、注文金額が５万円以上10万円以下の場合は、過去５年間の取引実績で不払いがなければ、注文を受け付ける

ルール：信用払いの注文で、注文金額が５万円未満の場合は、すべての注文を受け付ける。 etc.

　　　　　　　　　：　　　　　　　：

ここにはElseという概念がなく、すべてのルールはそれぞれ明示的に表現されており、ルール単体で意味が完結します。

このようなルールの追加はビジネスポリシーにそって、運用後からでも追加することができる為、カットオーバーしたが、業務アプリは半年前の仕様で時代遅れになっていたということも無くなります。

また、リスクを取る代わりに、注文金額の閾値を10万から15万へ上げることで受注制限を緩和して売り上げ増を図るといった"業務指針を実現するオペレーショナルなディシジョン"を安全に実行することができます。

参考資料）BRS(http://www.brsolutions.com/)　JT on EDM(http://jtonedm.com/)　Business Rule Concepts (BRCommunity.com)