先日、アマゾンに昨年春くらいに予約したまま、ほとんど忘れかけていた本が届きました。Barbara von Halle と Larry Goldberg の「The Decision Model」 という本。データにデータモデル(リレーショナルモデル)があるように、ビジネスのデシジョン(～ビジネスロジック・ビジネスルール)にもデシジョンモデルがあるべきであるとし、そのデシジョンモデルがどのようなものであるか、どうあるべきか具体的なモデルの記法なども含め説明しています。
データは、リレーショナルモデルという理論的に整備されたモデルがあることによりデータの独立性を確立したとし、そのアナロジーから、ビジネスロジックについても、その理論的な背景を明らかにした技術に依存しないモデルを確立して、ビジネスロジックの独立性を確かにしていこうという趣旨のようです。
まだきちんと読んだというわけではないのですが、このデシジョンモデルは、リレーショナルモデルと同様、正規形があったり、動機だけでなく、その構造や手続きについてもリレーショナルモデルと類似の面がある様子。もっとも、ロジックの冗長性をなくし、原子性(atomic)を求めようとすると必然、正規化のような手続きが出てくるのでしょう。
また、後ろのほうの章では、EAのZachmanや、EDMのJames Taylorなどが書いているところもあったり・・・。

これからぼちぼち読んでいくつもり。

ビジネスルールアプローチ(BRA)というと、何か特別な革命的な方法論があるのか・・・と考える方もいらっしゃるかもしれません。が、むしろ従来からの方法論の漸進的な改善と見たほうが実態を表しているように思います。ビジネスルールとは、端的に言えばビジネスのロジックや制約をルールの形で表したものであるので、システム開発の現場においてビジネスルールが対象とするべきビジネス仕様そのものは、昔から何らかの形で捉えられていたはずです。実際、ビジネスルールを抽出する一つの方法として「レガシーシステムのコードからリバースして抽出する」というのがあるくらいですから、ビジネス仕様は、ルールの形として明示的に捉えられていなかったにしろ認識はされていました。

では、ビジネスルールアプローチと従来の方法論との違いはどこにあるのか・・・というと、「ビジネスルールを明確に意識した開発」かどうかということにつきると言えます。とは言え、これだけでは何のことやらサッパリでしょうから、もう少し噛み砕いていきましょう。Barbara von Halleは、その著書“Business Rules Applied”の中でBRAの原則として次のSTEP原則というのをあげています。

• Separate rules(ルールを分離せよ)
• Trace rules（ルールがトレースできるようにせよ）
• Externalize rules(ルールを外部化せよ)
• Position rules for change(変更を前提にルールを配置せよ)

それぞれをもうちょっと解説すると

• Separate・・・ビジネスルールを他のシステム要件から明確に分離することで
  ルールを再利用したり、他のシステム要件から独立して変更したりできる。
• Trace・・・個々のビジネスルールに対して、その拠って立つビジネスの動機
  (ミッション、ゴール、目的、戦略、戦術、ポリシーなど)へとトレースできる一方、
  そのビジネスルールの実装形へも明確にトレースできる。これにより、ルールの
  正当性が保証でき、またルールを変更したときの影響度合いがわかりやすく
  なる。
• Externalize・・・ルールを誰にもわかるようなフォーマットで公開すること
  によって、ビジネスを動かしているルールが何であるのか一目瞭然となる。
  今流行りの言葉で言えば、ルールの「見える化」である。
• Position・・・ルールを容易に変更できるような環境においておくこと。これは
  昨今のビジネス環境の変化の速さを考えれば、当然ビジネスルールの変更
  要請も頻繁になることが想定され、ある意味当然のことと言える。

個人的には、このうち特に”Trace”がポイントなのかなあと思っています。システム開発というと、「そもそもこのシステム要件は何のためのもの？」ってことが存外にあったり(→こんなことがあまりに多ければプロジェクトは失敗ということになってしまいますが)、プロジェクトが進んで実装の段階になると、「プログラムのこの部分はそもそもどんな要件から来ているのか？」というトレースがしんどかったり・・・皆様も経験があるかとおもいます。

従来の感覚ですと、このようにビジネスの動機と実装との間にはかなりのギャップがあり、それを埋めるためには結構な意志と努力が必要です。が、BRAでは、ビジネス仕様をルールで表現することによって、このギャップを軽減し比較的容易にビジネスの動機と実装との間のトレースができるようになります・・・というのが上記「Trace」の意味。これがきちんとできるということはそれだけでも結構魅力。

さて本題に戻ると、von Halleは、著書で、上記の原則に則ってシステム開発の方法論としてのBRAを展開しています。次回は、具体的なBRAの方法論をと行きたいところですが、その前にそもそもビジネスルールとは？といったところをまとめてみたいとおもいます。

「ビジネスルールアプローチ(以下BRA)」・・・最近、時々聞かれるようになった言葉ですが、結局いったい何なのかよくわからない方も多いのではないでしょうか。実際、人によって、状況によってその意味するところが若干違う(ように思える)ところもそれに拍車をかけています。実は、姉妹サイトでの「ビジネスルール２つの視点」という記事にも似たようなことを書いているのですが、BRAという言葉を使う場合、ビジネスルールを利用した開発のうち
①BRMSツールでの実装を強調した場合に使う
こともあれば、より上流の
②ルールによる仕様の記述というところを強調した方法論に対して使う
こともあります。

ところでBRAの中の「ビジネスルール」という言葉・概念。この言葉そのものは、一般の要求定義の中でも使われれるように特にツールとしてのBRMSとは関係はありません。たとえば要求定義やユースケースの解説書などでもビジネスルールに１章が割かれていたりします(たとえば「ソフトウェア要求」・・・末尾参照)。②の意味でのBRAはこの意味での「ビジネスルール」に焦点をあて、データ分析やプロセス分析と同じレベルでルール分析を取りあげていこうとする方法論であり、そのルール分析では、ルールを仕様のコア部分として認め、他の要素(データやプロセス)とは意識的に区分して厳密に扱っていこうとするものです。Ross やVon Halleの提唱しているBRAは、この範疇に入ります。

この②の意味でのBRAの歴史を紐解いてみる(A Brief History of the Business Rule Approach－BRCommunity)と、「BRA」といった言葉がなかった90年前後に、すでにその源流が始まっています。そこでは概念データモデルのモデリングで制約などをルールの形でまとめようとしていました。その後、ルールの記述範囲がモデルの制約だけでなく、推論の規則や計算規則などにも拡げられるとともに、記述方法も洗練され、述語論理を基盤とした、項(ターム)、ファクトを要素とした記述となっていきます。実は上に上げた要求定義の解説書に表れている「ビジネスルール」という言葉は、逆にこのBRAを作っていく中から生まれたといってもよいでしょう(ちなみに余談ですが、世界的に有名なデータベースの教科書『データベースシステム概論』を著したC.Dateもビジネスルールアプローチに関する本(What Not How)を書いています・・・末尾参照)。

このようにもともとのBRAは、ソフトウェアツールとしてのBRMSとは全く独立してビジネスを分析していく中から誕生しました(このことは、上に上げたBRAの歴史にも強調されています)。その一方で、ツールとしてのBRMSは、エキスパートシステムの作成などを通じてだんだんと洗練されてきています。そして今、BRMSで用いられているルールベース言語の宣言性、述語論理との親和性からBRAで書かれた実装系としてBRMSが使われるようになったということでしょうか。

(もっともRossやVon Halleなどの本で扱われているBRAは、ほとんど「ルール原理主義(?)」的な、かなりがちがちのルールアプローチです。したがってBRAの方法論としてはともかく、現実のBRA適用としては今のところもう少し緩和した上記で言う①寄りの形が主流でしょう)