「Else」に潜む罠：なぜビジネスルールは“意味”で語るべきなのか
システム開発の現場では、本番稼働後に予期せぬ不具合に見舞われることがあります。特に、要件が複雑に絡み合う業務アプリケーションでは、プログラムのロジックに潜む「曖昧さ」が原因でバグが発生するケースが少なくありません。その根源の一つが、プログラミングで当たり前に使われる「else」の扱いです。
この記事では、従来のプログラミングとビジネスルールアプローチの違いに焦点を当て、なぜルールを「セマンティック（意味的）」に記述することが、システムの品質と柔軟性を高めるために不可欠なのかを解説します。
プログラミングにおける「Else」の落とし穴
多くのプログラミング言語で基本となるif-then-else 構文を考えてみましょう。
if A=1 and B=2 then
action1 を実行
else
action2 を実行
end if
このコードでaction2 が実行される条件は何でしょうか。それは if の条件式（A=1 and B=2）が成立しない場合、つまり「Aが1でない、またはBが2でない」場合です。このようにelse が意味する条件は、前の if の条件を読まなければ理解できず、「暗黙的」なものとなっています。条件がさらに複雑になれば、else の内容を正確に把握することはますます困難になり、バグの温床となり得ます。
実際に、ある受発注システムの開発で、次のような仕様がありました。
ビジネスルール:
信用払いの注文で、注文金額の合計が10万円を超える場合は、与信確認をしてからでないと注文を受け付けてはならない。
この仕様に基づき、プログラマーは次のようなロジックを実装しました。
if 注文形態='信用払い' & 注文金額合計 > 10万円 then
メッセージ出力: "注文前に与信確認が必要"
else
メッセージ出力: "エラー"
end if
このシステムが本番稼働した後、「信用払いの注文が処理されない」という事故が発生しました。原因は、仕様確定時にelse の場合の要件が定義されておらず、担当プログラマーの判断で安易に「エラー処理」を組み込んでしまったことでした。これは上流工程の設計ミスとも言えますが、ビジネスの現場では初期にすべての要件を出し切ることが難しいのも事実です。
「Else」をなくすセマンティックなアプローチ
この問題に対し、ビジネスルールアプローチは明確な解決策を提示します。それは、「else」という概念をなくすことです。すべてのルールは、それ単体で意味が完結するように「明示的」に記述されます。これを「セマンティック（意味的）な記述」と呼びます。
先ほどの例も、ビジネスルールアプローチでは次のように、一つひとつが独立したルールとして定義されます。
- ルール1: 信用払いの注文で、注文金額が10万円を超える場合は、「注文前に与信確認要」とメッセージを出す。
- ルール2: 信用払いの注文で、注文金額が5万円以上10万円以下、かつ過去5年間の取引で不払いがない場合は、注文を受け付ける。
- ルール3: 信用払いの注文で、注文金額が5万円未満の場合は、すべての注文を受け付ける。
このように、すべての条件が明確に記述されるため、ロジックの曖昧さがなくなり、誰が読んでも理解しやすくなります。
セマンティック品質がビジネスコミュニケーションを変える
ロナルド・G・ロスによれば、この「意味の明確さ」は、より広い「セマンティック品質」という概念につながります。データとは単なる過去の出来事の「残留物」であり、データを作成する行為は、未来の利用者に対する「盲目的なビジネスコミュニケーション」です。
このコミュニケーションを成功させるには、データがそれ自体で意味を語る必要があります。
セマンティック品質は、以下の4つの側面から成り立ちます。(※参考文献より引用）
- 判読性 (Readability): メッセージが暗号的な名前やコードで意図せず判読不能になっていないこと。例えば PID-RAD2-TYPE のようなプログラマーにしか分からない名前は避けるべきです。
- 理解性 (Understandability): メッセージが、堅固なビジネス定義を持つ用語のみを使用していること。用語の定義が曖昧では誤解が生じます。
- 正確性 (Precision): 共有されたビジネス語彙の用語を「正しく」一貫して使用すること。
- 信頼性 (Reliability): メッセージが、関連するすべてのビジネスルールに準拠していること。
結局のところ、「データ品質」とは、それを生み出す「ビジネスルールの品質」に他なりません。ビジネスルールは単なるデータ制約ではなく、「ビジネスを正しく運営するための基準」そのものです。
ビジネスルールアプローチがもたらす価値
else のような暗黙的なロジックを排除し、セマンティックにルールを記述するアプローチは、多くのメリットをもたらします。
- バグの削減とリスク管理: ルールの意味が明確になることで、解釈の誤りによるバグが減り、システムの信頼性が向上します。
- ビジネスへの即応性: ビジネスの変化に応じて、ルールの追加や変更を安全かつ迅速に行えます。例えば、受注制限の閾値を10万円から15万円に引き上げるといった戦略的な判断も、システムに素早く反映できます。
- ビジネスとITの協業促進: ルールがビジネス用語で記述されるため、要件定義から実装までビジネスユーザーが深く関与でき、認識の齟齬を防ぎます。
一方で、このアプローチはレガシーコードをビジネスルールへ自動変換することを難しくします。コードのロジックを分析し、そこで実行されている「意味」を明確に捉え直すという、単なる構文変換以上の作業が求められるからです。
システムを単なる命令の集合体としてではなく、ビジネスの意思を伝える「コミュニケーションツール」として捉え直すこと。それこそが、セマンティックなビジネスルールアプローチの本質であり、変化の激しい時代に求められるシステム開発の姿と言えるでしょう。
参考文献：https://www.brcommunity.com/articles.php?id=c140