連載　企業および社会における情報システムの意味を考える
第5回　ビジネスの変化に迅速に対応できる情報システムにするための課題 その4

　今回も、前回に引き続いて、「ビジネスの変化に迅速に対応できない情報システム」ということについて、その問題の本質と解決策を探っていきます。今回は、ビジネス・モデルを構成する要素の一つである“ビジネス・ルール”について触れてみたいと思います。この言葉は、この数年よく使われるようになりました。そして、ビジネスの変化が具体的な形で出現するところでもあります。しかし、必ずしもその概念は明確とはいえません。Googleで検索してみても、いろいろな説明が見つかります。

　“ビジネス・ルール”という用語は日本語に訳すと“業務規則”や“業務規定”となりますが、それには、挨拶の励行から、法律への遵守規定などを含みます。実際インターネットで検索すると、「上司とのコミュニケーションの仕方」、「新入社員の心がけ」、「身だしなみ」などもビジネス・ルールの例として書かれている記事も見つかります。それらは、“業務規則”の意味での”ビジネス・ルール”ですが、英語の“Business Rule”とは幾分違った意味になります。そのため、”業務規則”とは翻訳されずにカタカナで使用されています。それでも、この言葉は日本では馴染みがなく、当初適切な理解は困難であったように思います。数年前になりますがある日本の技術者が、「日本ではビジネス・ルールを文書化せずにシステム開発をしている」と言っていたのを思い出します。実際にはそんなことはなかったのですが。

　そういうことも踏まえて、ここでは、次の観点からまとめたいと思います。

　　　(1) ビジネス・ルールという言葉の意味
　　　(2) 現行のビジネス・ルールの可視化
　　　(3) 法律のビジネス・ルール化

１．ビジネス・ルールという言葉の意味

　ビジネス・ルール(Business Rule)という概念は、もともとは、1980年代末にITの技術者（主にデータ・モデリングの専門家）が集まって検討を開始し、1993年に“the GUIDE Business Rules Project”というプロジェクトの中で確立したものです。(*1、*2)　そこには、こう書かれています。(*3)
　「rule that is under business jurisdiction. ‘Under business jurisdiction’ is taken to mean that a business (or any other semantic community) can, as sees fit, enact, revise, and discontinue the business rules that govern and guide it. If a rule is not under business jurisdiction in that sense, then it is not a business rule.」

　つまり、ビジネス活動での判断の正当性にかかわる事柄で、ビジネス行う中で適用したり変更したり廃止などの対象となるものということです。ビジネス・ルールという概念を考え出したメンバーはデータ・モデルの専門家が多くを占めており、彼らのコンサーンはエンティティや関連を明確にした場合でも、そういった事柄が実装コードを作成する段階まで完全には文書化されずあいまいなままであるという事実にありました。当時は、米国においても、ビジネス要件の文書化はきちんとされていなかったということでしょう。

　そのチームが考えたビジネス・ルールの定義は理論的です。ビジネス・ルールは次の４つの概念に分類できるとされています。

　(1) 業務用語の定義　（Definitions of business terms）
　(2) 事実（Facts relating terms to each other）
　(3) 制約(Constraints (here called ‘action assertions’))
　(4) 導出結果(Derivations)

　また、「ビジネス・ルールはそれ以上分解できない厳密な解釈ができる文章記述」です。それに対して、“if〜then〜else”で表現されたものを、“ビジネス・ルール文(business rule statement)”と言い使い分けています。ビジネス・ルール文は、複数のビジネス・ルールを含んだり、さらに詳細にできる規則を含んでいても構いません。ビジネス・ルール文は、ビジネス・ルールをソフトウェアでの実装を意識して抽象化し共通化した表現形式と解釈できます。

　また、ビジネス・ルールには、振る舞いルール(an operative business rule)と構造ルール(a structural rule)があると書かれています(*2)。つまり、ビジネス・ルールはデータ・モデルにおけるエンティティそれ自身が持つ規則（本であれば、ISBN番号の桁数のルール）と、関連があるエンティティ間のその関連の意味（顧客は信用限度額の範囲であれば、商品を購入できるというルール）というルールが存在するということです。
　これらの定義からわかるように、日本では従来から要件定義書の業務機能仕様に「〜の場合は〜する」と記述していた内容が該当します。あるいは、次の様なことがらもすべてビジネス・ルールということになります。

　これらは、ビジネス上の判断を行う上で、判断結果の正当性を示す基準です。このように、SBVRで規定している定義によると非常に多くの事柄がビジネス・ルールに該当します。ビジネス活動を行う上で判断や意思決定に関与しているすべてがビジネス・ルールということになります。

　こういうビジネス・ルールを網羅的に識別するのは容易ではありませんし、あまり意味があるとも思えません。そのため、実際には上記の４つのカテゴリーのうち、三番目の「制約」にかかわる部分のみがビジネス・ルールとして識別されるのが通常です。それでも網羅性は重要ではなく、対象となる業務領域の中で、「重要な判断で将来変わりえるもの」をビジネス・ルールと判断するのが実際的です。

　興味深いことに、IT業界でビジネス・ルールという言葉に関心が広まったのは、実際にはビジネスそのものからの要請ではなく、むしろシステムの設計やアーキテクチャ、あるいはルール・エンジンやBRMS(Business Rule Management System)といった製品が使われるようになったのが理由と言えるでしょう。その意味では、“ビジネス・ルール”とビジネスとうたってはいるものの、それを識別する意義は、特定のアプリケーケーション・アーキテクチャを前提とした上での、ソフトウェアの設計対象を識別することだといえます。ですから、ビジネス・パーソンにとって、ビジネス・ルールを特別視することの意義を理解するのは困難であり、それを識別し抽出することが業務にとってどのような意味があるのかがわかりにくいものになっています。

　たとえば、業務機能単位に業務の仕様を詳細に記述すれば、設計からコードの生成までを自動的に実行してくれるツールがあったとします。その場合、業務仕様の中からビジネス・ルールを特別に切り出して管理する意義はあるでしょうか?　考えてみる価値のある問題だと考えています。

　また、ビジネス・プロセスや作業の順序の規定はビジネス・ルールには含まれないと考えられています。しかしながら、作業の順序（ワークフローの処理順序）も、ビジネス活動を行う上でのルールであり、ある時期が来れば変わりえる要素です。システム設計の立場では、そういった変更可能性は十分考慮すべきですが、そういったことはビジネス・ルールの概念には含まれていないことも知っておいて損はないでしょう。

2．現行のビジネス・ルールの可視化

　現在、こういったビジネス・ルールは、多くがプログラムの中に埋め込まれています。システム化されていないもののみが、どこかの文書に記載されているということです。問題はプログラムに実装されているビジネス・ルールは、a)表現形式がビジネス・ユーザーにはわかりにくいこと、b)場合によっては、複数のビジネス上の判断がひとつのコードで実装されていること（上記の“ビジネス・ルール文”として実装されているということです）、そして、c)プログラムで実装されている処理内容と設計書の内容が違うことです（適切に保守されていないということ）。

　ビジネス・ルール（だけではありませんが）は、文書化しただけでは十分ではありません。それを、知識データベース（リポジトリ）に保管し、また、常にプログラムとの整合性を担保できる仕組みを構築することが将来的に必要です。ビジネス活動や情報システムの仕組みをリポジトリに登録して維持管理するようにしないことには、“経営の変化に迅速に対応できる情報システム”には決してならないでしょう。この問題を放置したままシステムを運用し続けることに対して、もっと多くの企業が問題意識を持つべきと考えます。

　新たに情報システムを開発するとき、“ビジネス・ルール”の識別はビジネス・モデリングの中で、ある意味一番時間のかかる作業です。最初、ビジネス・プロセスを展開したタスクに割り当てられる業務機能ごとにビジネス・ルールを識別し文書化します。複数のタスクで同じビジネス・ルールを利用することもあるので、共通のビジネス・ルールを別に切り出して管理することもあります。その場合、タスクの記述に埋め込むのではなく、別に記述することが推奨されています。ただし、ルール・エンジンやBRMSツールを使わないのであれば、タスクの仕様の中に埋め込んで記述したほうが文書の可読性は高まります。また、複数のタスクで、同じビジネス・ルールを利用することがあるということは、“ビジネス・プロセス”対“ビジネス・ルール”も多対多の関係にあるということです。そのことは認識しておくべきでしょう。ビジネス・ルールは量も多いということもありますし、アプリケーションの設計仕様の中心的な役割を担うことからも、文書化と同時に、ビジネス・モデルの各要素との関連をしっかり管理していくことが求められます。

３．法律のビジネス・ルール化

　ビジネス・ルールを識別することで実際的な意義があるのは、“法律のビジネス・ルール化”ではないかと考えています。企業は業務を実施するときに法律に基づく規定が多くありそれらを情報システムに実装しています。もし、そういった法律を政府が“if 〜then〜else”形式のルール集を提供するようになれば、企業の情報システムは法律の改定に対して容易な対応ができるようになるでしょう。業種によっても違いがありますが、法律や行政指導が業務に直接的に影響することを考えると、それらをビジネス・ルール集として企業に提供することは、業務の大幅な効率化に資することになるでしょう。行政組織が今後検討すべきテーマではないでしょうか。

　昨年１０月からの連載で、ビジネス・モデルの主要要素の構造について書いてきました。ビジネス・モデルとは何かということについて、最後に、OMGが発行しているBMM(Business Motivation Model)(*4)にある図を改めて示しておきます（図1）。また、今まで述べてきたビジネス・モデルの主要要素間の全体の関係を概念的に図示したものを図2に示します。ビジネス・モデルのメタモデルともいうべきものですが、こういった関連を管理されてはいかがでしょう。

　以上