ビジネスルールアプローチ(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の方法論をと行きたいところですが、その前にそもそもビジネスルールとは？といったところをまとめてみたいとおもいます。