BRMSで実験してみました-宣言的プログラミングのすすめ (2)-

Droolsを使って、ルールベース(BRMS)の動きを見るためにちょっと実験してみました。Droolsで、Projectをつくるとサンプルのプログラムをつくってくれますが、それをすこしばかり修正しての実験です。
(ルールベースの動きの基本は、プロダクションシステムとはとか、当ブログのルールベースプログラミングのカテゴリなどを参照ください)

まずは、ルール処理の対象となるファクトを準備します。

SampleFact.java

package com.sample;

public class SampleFact {
    private int num;
    private String name;

    public SampleFact() {
        super();
    }

    public SampleFact(int num, String name) {
        super();
        this.num = num;
        this.name = name;
    }

    /**
     * @return the num
     */
    public int getNum() {
        return num;
    }

    /**
     * @param num the num to set
     */
    public void setNum(int num) {
        this.num = num;
    }

    /**
     * @return the name
     */
    public String getName() {
        return name;
    }

    /**
     * @param name the name to set
     */
    public void setName(String name) {
        this.name = name;
    }

    @Override
    public String toString() {
        return "SampleFact [num=" + num 
                   + ", name=" + name + "]";
    }

}

そして、mainプログラム

DroolsTest.java

package com.sample;

import org.kie.api.KieServices;
import org.kie.api.runtime.KieContainer;
import org.kie.api.runtime.KieSession;

/**
 * This is a sample class to launch a rule.
 */
public class DroolsTest {
  public static final void main(String[] args) {
    try {
      // load up the knowledge base
      KieServices ks
       = KieServices.Factory.get();
      KieContainer kContainer
       = ks.getKieClasspathContainer();
      KieSession kSession
       = kContainer.newKieSession("ksession-rules");

      // go !
      SampleFact sf1 = new SampleFact(1, "A");
      SampleFact sf2 = new SampleFact(2, "B");
      SampleFact sf3 = new SampleFact(3, "C");
      SampleFact sf4 = new SampleFact(4, "D");
      SampleFact sf5 = new SampleFact(5, "E");
      kSession.insert(sf1);
      kSession.insert(sf2);
      kSession.insert(sf3);
      kSession.insert(sf4);
      kSession.insert(sf5);
      kSession.fireAllRules();
    } catch (Throwable t) {
      t.printStackTrace();
    }
}

上のように5つのファクトをワーキングメモリに追加して、以下のルール

Sample.drl

package com.sample

rule "サンプルルール1"
when
    SampleFact($num: num, $name: name)
then
    System.out.println("num=" + $num
         + ", name=" + $name);
end

を実行しました。
コンソールには、どのように表示されるでしょうか。

まあ、これはワーキングメモリに5つのファクトがあるので、単純に
条件節(when部分)のSampleFactにマッチして、5回ルールのサイクルが回ります。

num=5, name=E
num=4, name=D
num=3, name=C
num=2, name=B
num=1, name=A

つまり条件部にマッチしたファクトが
SampleFact(1, “A”);
SampleFact(2, “B”);
SampleFact(3, “C”);
SampleFact(4, “D”);
SampleFact(5, “E”);
の5つだったということ。

では、上記のサンプルルール1のかわりに次のルールがあった場合は
どうなるでしょうか

Sample.drl(改)

package com.sample

rule "サンプルルール1a"
when
    SampleFact($num: num > 3, $name: name)
then
    System.out.println("num=" + $num
         + ", name=" + $name);
end

このときは条件節に num > 3 という条件が加わったので
num=5, name=E
num=4, name=D
の2つのみが表示されます。

すなわち条件部にマッチしたファクトが
SampleFact(4, “D”);
SampleFact(5, “E”);
の2つということ。

さらに次はどうでしょう。

Sample.drl(改々)

package com.sample

rule "サンプルルール2"
when
    SampleFact($num: num, $name: name)
    SampleFact($num1: num, $name1: name)
then
    System.out.println("num=" + $num
         + ", name=" + $name
         + ", num1=" + $num1
         + ", name1=" + $name1);
end

今度は、条件節のSampleFactのパターンが2つになりました。結果は、
num=1, name=A, num1=1, name1=A
num=1, name=A, num1=2, name1=B
num=1, name=A, num1=3, name1=C
  ・・・(中略)・・・
num=5, name=E, num1=4, name1=D
num=5, name=E, num1=5, name1=E

以上、25行表示されました。

これは、条件節の最初のパターン
SampleFact($num: num, $name: name)
に5つのファクトがマッチして、さらに2番目のパターンにも
SampleFact($num1: num, $name1: name)
5つのファクトがマッチして結局その組合せとして5×5=25(通り)の
組合せが表示されているということを表しています。つまり

条件部にマッチしたファクトの組を
[<最初のパターンにマッチしたファクト>,<2番目のパターンにマッチしたファクト>]
の形であらわすとすると、

[SampleFact(1, “A”), SampleFact(1, “A”)]
[SampleFact(1, “A”), SampleFact(2, “B”)]
[SampleFact(1, “A”), SampleFact(3, “C”)]
  ・・・(中略)・・・
[SampleFact(5, “E”), SampleFact(4, “D”)]
[SampleFact(5, “E”), SampleFact(5, “E”)]

の25個のファクトの組が条件部にマッチしたことになります。

では、こんなルールであったらどうでしょうか。

Sample.drl(もひとつ改)

package com.sample

rule "サンプルルール2a"
when
    SampleFact($num: num, $name: name)
    SampleFact($num1: num > $num, $name1: name)
then
    System.out.println("num=" + $num
         + ", name=" + $name
         + ", num1=" + $num1
         + ", name1=" + $name1);
end

(この項続く)

if-then文とif-thenルール -宣言的プログラミングのすすめ (1)-

この前の更新からずいぶんと間があいてしまいましたが、最近、ビジネスルールというか、「ルール」というものの認識についてどうも気になることがあったので、考え方としては前回と重なる部分も多いかと思いましたが、再び記事を書いてみました。またこれに限らず、ぼちぼちと記事を書いていきたいと思っております。

さて、ちょっと唐突ですがプログラムにおけるif-then文と、一般的なルールとしてのif-thenの違いはどこにあるでしょうか。
(なお、ここで言うルールとしてのif-thenは、実際にBRMSに実装されるif-thenルールではなく、それ以前のまずは仕様(文書)としてまとめられた(ビジネス)ルールとします)

これら if-then文 と if-then ルール、同じ if-then ではあるので、それほど変わらないように感じられるかもしれません。私自身もふだんは明確な使い分けをせずあいまいな書き方をしていたりもしますが、実は大きな違いがあります。

まず、プログラムにおけるif-then文。これは、プログラムの上から下に流れる処理の流れが前提にあって、何もしなければif-thenは1回しか通りません。もう一度通すためには繰り返しを書く必要があります。つまりプログラムのif-then文は処理の流れを意識しないと成り立たず、処理の流れはすべて記載しなければなりません。すなわちプログラムのif-then文は、いわゆる手続き的 (procedural) にしか解釈されません。

一方、ルールにおけるif-thenというものは、どうでしょう。一般にルール(規則)というものは、条件 (if部) が合うのであれば常に適用されるもので、そこに処理の流れというものは存在しません。仮にいくつかif-thenルールがあったとしましょう。原則それぞれのルールは独立してそれぞれ条件が合うかどうかのみで、適用される/されないが判断されます。そこにどの順に処理するかという処理の流れはありません。

たとえば

 if 赤信号 then 止まる

というルールですが、これを手続き的に解釈して処理の手順を考え、先ほど赤信号を処理したので、次の赤信号は処理できず結果的に無視してしまうということはないでしょう。どんな状況でも、条件さえ合えば常に適用されるというのがルールです。

無理やり手続き的に書こうとすると、「if 赤信号 then 止まる」という if-then文 をループで囲って、1回赤信号を処理しても、次の赤信号も処理できるように待っているといった書き方になります。

また、個々のデータが○か×の値をとる配列があり、

 if × then エラー出力

などといったルールでも同じです。ルールそのものは上記で書けても、手続きを明示しないといけないので、if-then文 を配列全体にわたってループする・・・という追加の記述が必要になります。

まとめますと、仕様としての if-then ルールを手続き的に書こうとすると、ループなどの処理手順も明示する必要があり、それが複雑になると本来の仕様が処理手順に埋もれてしまうということになります。たとえば前回の記事などのようにデータに親子関係があり、複数の子の間での制約など if-then ルールとして記述すれば比較的わかりやすいけれども、手続き的に書こうとすると面倒というケースです。従来の手続き的なプログラミングの問題点の一つはそんなところにもあるのではないでしょうか。

    ***

さて、みなさまは「宣言的」(あるいは宣言型)プログラミングという言葉をお聞きになったことがありますか?

Wikipediaの宣言型プログラミングという項には、

「宣言型プログラミング(英: Declarative programming)は、プログラミングパラダイムの名称だが、2種類の意味がある。第一の意味は、処理方法ではなく対象の性質などを宣言することでプログラミングするパラダイムを意味する。第2の意味は、純粋関数型プログラミング、論理プログラミング、制約プログラミングの総称である。」

とあります。

上にあげた第2の意味は、現在一般的に認知されているプログラミングパラダイムの中で、第1の意味での宣言型プログラミングを具現化しているものとも解釈できるかと思います。そういった視点で第2の意味に加えるとしたら、プログラミングパラダイムとして一般的に必ずしも認知されているわけではないけれども、たとえばSQLなどはあげられるでしょう。実は、前回あげた ルールベース(プロダクションシステム)のプログラミングも宣言的なプログラミングの仲間に入れていいかと思います。

宣言型プログラミングの第1の意味では、処理方法ではなく対象の性質などを宣言することでプログラミングするパラダイムを言いますが、「対象の性質」と言っても、なかなかわかりにくいのでもう少しかみ砕いた記述を見てみましょう(宣言型プログラミングの可能性と限界より)。

「宣言型プログラミングが記述するものは、問題の定義、すなわち解くべき問題の性質や、その際に満たすべき制約の記述です。」

「対象の性質」をかみ砕くと「問題の定義、すなわち解くべき問題の性質や、その際に満たすべき制約」ということになるでしょうが、これをルールベースによる宣言的プログラミングに置き換えると、if-then ルールを使って、問題の性質や制約を記述することになりましょう。このことは何を意味しているのでしょうか。

    ***

仕様としての if-then ルール、これは問題の定義-問題の性質や制約を記述-を記述したものなので、実は「宣言的プログラミング」の意味での「宣言的」であるといえます。

これを実装する場合、従来のプログラミングでは if-then ルール を手続き的に直して書くだけだったので、本来の仕様以外に処理手順なども記述する必要がありました。

手続き的

これにより本質がぼやけてしまいプログラムの可読性が落ちることもありましたが、これはすなわち本来宣言的に表しているものを手続き的に表そうとすることで仕様と実装との間でのミスマッチ(注0)が起こっていたということなのです。

もし宣言的に表されている仕様を、そのまま宣言的に表せるプログラム手法があるのであれば、それに越したことはなく、プログラムの可読性を落とすことなく実装を行うことができます。

宣言的

ここであらわれたのがルールベースのプログラミング(プロダクションシステム)でした。もともとルールベースの技術は人工知能の応用としてエキスパートシステムの構築のために生まれてきたわけですが、このルールベースにおける if-then ルールの動きというものが、条件 (if部) さえ合うのであれば常に適用されるという、まさに仕様としての if-then ルールの動きと一致したわけです(注1)。

すでに前回にも書きましたが、ルールベースのプログラミングでは、if-then 文とループを使って処理手順を記述するのではなく、if-then ルールのみの仕様を記述することでプログラミングを行います。

で、if-then ルールを書けば、あとはルールのエンジンが、いい塩梅で実行してくれるというわけ。

たとえて言えば、手続き型のプログラミングは、処理の手順を一から教えなければならない新入社員のようなものである一方、ルールベースによる宣言的プログラミングは、「これこれをやっておいて(問題の性質や制約 ! )」と伝えておけば、それなりにいいようにやってくれる、常識的な処理手順はわかっている入社1~2年目の社員といったところでしょうか。

    ***

もっとも、このルールベースでのプログラミング、他の宣言的なプログラミング手法と同様、実際に実行するという視点から言えば良いことばかりではなくて、エキスパートシステム構築ツールの時代からメモリなどのコンピュータリソースを食うデメリットがありました。

ただ、昔のスーパーコンピュータの性能が ipad2と同じくらいであるといわれるようになった今日、プログラムの開発・メンテナンスのコストに対し、コンピュータリソースのコストは相対的に飛躍的に減少しているので、それほど気にすることはないでしょう。

    ***

まあ、そうは言っても実際のところ単項目のエラーチェックなどで、if-then文とif-thenルールとの違いがあまり表面化しない場合(単純なデータ構造で1回 if-then のチェックをすればよい場合など)も多々あるので、if-thenルールを記述できるBRMSを使うまでもないということもあるでしょう。

そんなときには、ちょっと手軽で安価な、手続き的に if-then文 を処理するBRMS (たとえばOpenRulesのsequential rule engine) を使ってもよいかと思います。

ただルールを手続き的な if 文で書こうとすることは、本質的にはJava(注3)やCobolなどなど従来の手続き型プログラミングをなぞっているという域を出るものではなく、本来のルールの宣言性を生かした宣言型のプログラムにはならないということは、きちんと認識しておいた方がよいかと思います。

手続き的な処理方法のBRMSで多少複雑な処理を行おうとすると、本来のBRMSのメリットである可読性が失われてしまい、メンテナンスの視点からは、結局従来のプログラムと何ら変わらないことになってしまうでしょう(注2)。要するに限界は限界として認識した上で、向き、不向きを判断して使うことが重要かと思います。

   ***

今回は、概念的な宣言的プログラミングの説明で終わってしまいましたが、どこかで宣言的プログラミングの例をもう少し書いてみたいと思います。たとえばビジネスの例ではありませんが、ポーカーの役の判定などは、手続き的に書くとするとループを回したりする必要がありますが、ルールベースで書くと役の定義に素直に、比較的直感的に書けるので、良い例になりそうだと思っています。

(注0) ミスマッチという言葉を使ったのは、ここを書いていて、一昔前によく言われていたオブジェクト指向言語からRDBを呼び出す際に、それぞれの拠って立つモデルが違うことから実装が複雑になる「インピーダンス・ミスマッチ」という言葉が頭に浮かんできたので・・・。

(注1) ちなみに、これが、現在の一般的なBRMSの多くが、エキスパートシステム構築ツールをルーツに持っているという所以です。たとえば、IBMのOperational Decision Manager、FICOのBlaze Advisor、RedHatのJBoss Rules、Oracle Business Rulesは、いずれもReteアルゴリズムベースのエキスパートシステム構築ツールをルーツに持ちます。またSAPのルールエンジンはReteベースのようですし、ProgressのCorticonは、DeTIという独自のアルゴリズムですが、動き的にはReteと同等です。

(注2) なお、OpenRulesにはそのために制約プログラミングをベースとした Rule Solver というもうひとつのルールエンジンがあり、上記にあげたルールベース的な動きではありませんが、宣言的なプログラミングができるようになっています。

(注3) 余談ですが、最近では Java も流行の関数型のパラダイム (上にも書きましたが宣言型のパラダイムの一つ) を取り入れるようになってきています。ルールベース的な宣言とは、ちょっと違うのですが、個人的には、関数型は関数型で結構好きだったりもします。

「超高速開発」だけがBRMSのメリットか?

昨年あたりから、「超高速開発」のツールとしてBRMSが取り上げられることが多いのですが、BRMSは本当に「超高速開発」のツールなのでしょうか。

確かに、開発のスピードを速めることになるのは確かなのですが、どうも「超高速開発」ばかりが強調されていて、BRMSを用いた開発の他のさまざまな側面が忘れ去られているように思えるのは私だけでしょうか。

BRMSによる開発、もう少し広く BRA (Business Rule Approach) による開発の視点から考えると、少なくとも次のような特徴をあげることができます。

1.ビジネスルールを「見える化」できる。

従来の手法ですと、企業におけるさまざまな業務が拠って立つビジネスルールは、一旦、仕様書/設計書に落とされ、さらにシステムに実装されたときにはCOBOL、Java、C#など、プログラムのソースコードに埋め込まれてしまいます。実際にシステムを利用する業務担当者は、実装されているビジネスルールを仕様書を通してしか見ることができません。一方、システムを実装する担当者は、仕様書に書かれているビジネスルールをプログラムのソースコードに変換してシステムとして実装することになります。業務担当者とシステム実装者との間には、仕様書/設計書を通しての何段かの伝言ゲームが存在し、有名な下の図 ( University of London Computer Center Newsletter, No.53, March 1973 から*注 ) のような要求の食い違いが表れやすくもなってくることでしょう。

仕様伝達の食い違い
もし、業務担当者がプログラミングの素養があり、プログラムのソースコードを参照できるようであれば多少なりとも事態は改善するかもしれません。が、一般的なプログラミング言語で実装したソースコードは、通常、ビジネスルールの実装部分が明確に分離されていることは少なく、肝心なビジネスルールがどこに記述されているかを特定することそのものが困難であるというのは、実務でプログラムを書いたことがある人であれば誰しも同意するのではないでしょうか。

これに対し、BRMSによる開発は、ビジネスルールの実装を、システム上のロジックや、UIに関するロジックなどから明確に分離し、表(デシジョンテーブル)の形、あるいはDSLを用いて自然言語に近い形などで表現することで、業務担当者からシステムの担当者まで皆がビジネスルールの実装そのものを見てコミュニケーションができるようになることを目指すものであり、業務上のビジネスルールをより直截に実装しようとするものです。
もうちょっと言うと、そもそも、BRAという方法論は、STEPの原則にもみられるように、上記のような問題に対して正面から対峙するものであって、「超高速開発」というのは、むしろ、ビジネスルールが直截的に実装できることになったことによる副次的なものと言ってもいいかもしれません。

さらに、「見える化」という特徴については、おもしろい使い方もあって BRMS(ルールベース技術) を技術継承の道具として使う使い方などもあったりします(たとえばこんなサービスもあります)。製造業などではプラントの操作など、いたるところに職人的な専門家がいることが多いですが、その場合そのノウハウは、たいてい、明示的に文書化されておらず、専門家の頭の中に暗黙知として埋蔵されています。ルールベースによる技術継承では、この暗黙知を「ルール」として記述していくことになるのですが、単純に記述するだけでは文書としてルールを記述するのと何が違うの?という話になるでしょう。さて、その違いは・・・というと、それは記述したルールがそのまま実行できるというところにあります。
記述したルールがそのまま実行できると、次のようなことが可能になります。

  1. 専門家にヒアリングする、もしくは専門家自身がざっとルールを書き出す。
  2. それらのルールをルールベースに実装する。
  3. 専門家の選んだいくつかの事例に対して、上記で実装したルールベースを実行して結果を得る。
  4. 専門家に結果を検証してもらい、足りないと思われるルールを引き出す。
  5. 2.に戻って上記手順を繰り返し、ルールを精緻化していく。

ここでのミソは、ルールを実行してシミュレーションすることによって、すでに実装されているルールから論理的に帰結できることは新たにルールとして現れず、本質的に足りないルールが浮き彫りになるというところにあります。誰しも仕事をやるときに、自分がどんなルールを使ってやっているかなど、あまり意識はしていないでしょう。専門家も例外ではありません。思いつくルールをいくつか書き出すという程度なら書けるとは思いますが、これで十分かと問われるとおそらく自信を持って答えられないと思います。このときルールベース技術を用いれば、思いついたルールを「実行できる」形で表現でき、ルールを引き出す上で、「シミュレーション」という道具を手に入れることができます。これによって過不足なくルールを引き出すということができるわけですね。
これなどは BRMS をシステム開発のツールとして使うというよりも、むしろナレッジマネジメントの道具として使うというおもしろい例になるでしょう。

2.変化に対応しやすい

「超高速開発」ということで開発のときの速さがクローズアップされがちなBRMSですが、BRMSはシステムの稼働後にルールを状況に合わせて変更していくということも容易です。1.であげたようにビジネスルールが「見える化」されることで、どこを変更すればよいかが一目瞭然となるだけでなく、実際の変更も、BRMSの場合、仕様≒実装なだけに簡単にできます。オフィス風景

これは、業務担当者(ユーザ)自身がビジネスルールを実装する体制になっている場合に特に如実にあらわれます。従来ですと、ルールの仕様が変更されると自社のシステム部門を通し、さらに外注にルールの実装の変更をお願いしたりするなど、何重ものフィルタを通して仕様の変更を伝えるのが普通です。さらなるおまけとして費用もかかるとなるとなかなか簡単にはいかないのが従来のやり方。また、単純にロジック的なルールの変更が発生するというだけでなく、それにまつわる社内、社外的な手続きなども発生するので、結構な労力になり、心理的な障壁も高くなってしまうのは、たいてい誰しもが経験するところ。

それが、業務担当者が直接手を下すことができるとなると、ルール仕様の伝達に際しての中抜きができるだけでなく(というよりも伝達の必要もない)、仕様変更に伴う有形無形の間接的な作業も減るので、ルール仕様の変更に対しての障壁が目に見えて低くなります。

さて、このように仕様の変更に対する物理的、心理的な障壁が低くなってくることで何が起きるでしょう。状況や時流に合わせてルールが頻繁に変更されるようになり、次第に、むしろ積極的に、まわりに合わせてルールを変更するようになってくるのではないでしょうか。

実際、近年、米国で盛んに言われている概念 「デシジョンマネジメントシステム(Decision Management System)」は、BRMSのこの変更の容易さがひとつの前提になっています。日常の業務の中ではさまざまな判断(デシジョン)があらわれます。簡単なところでは書類のチェックとか、もう少し複雑なところでは何らかの(たとえば保険に入れるかどうかの)査定とか…。

デシジョンマネジメントシステムは、こういった日常頻繁に起こる判断業務の自動化(オートメーション)を目指します。

こういった書類のチェックとか、査定などの判断業務は基準も比較的明確でルール化しやすいものです。しかし、とは言っても現在のルールの条件から漏れてしまうケースがないとは限りません。デシジョンマネジメントシステムでは、こういったいままでルールから漏れてきたケースなどにも対処できるように、データ分析や機械学習、シミュレーション等々周辺の技術も動員してルールによる実行結果を吟味し、その内容を元にルールを変更したり、新たなルールを追加したりすることで、判断業務の自動化水準を高めてより多様なケースに自動で対応できるようにしていきます。

…若干話が脱線しましたが、このように先進的な取り組みの中では、BRMSのルールの変更のしやすさは、すでに前提となっていて、それをもとに状況に合わせて積極的にルールを変更するという方向で考えられるようになっています。

今の時代、どこの会社にもいる事務担当者ですが、近い将来の事務担当者の業務は、個々のケースをひとつひとつ手で処理するのではなく、典型的なケースはシステムで自動処理し、典型的でないケースを手で処理すると同時に、それらのケースも自動で処理できるようにルールを調整する…というようなことになるかもしれませんね。

注:有名な絵なのでご存知の方も多いかと思いますが、その簡単な解説は、たとえば

http://labo.mamezou.com/opinion/op_000/op_000_003.html

などをご参考に。

もう、こんなことを決めなくてはいけないの? -BRMSのプロジェクトにて-

BRMSを用いた開発プロジェクトは規模が大きいと、多くの場合、

・画面等を中心としたアプリケーション開発チーム
・BRMSを用いたルール開発チーム

に別れて、ウォーターフォール的に進められますが、その場合、BRMSチームの方は従来の一般的なプロジェクトよりも、ずっと早い段階で業務的な仕様の核心に入ってしまいます。
ユーザとの打ち合わせで、BRMSチームがルールで使う項目や条件についてヒアリングしようとすると、業務ユーザに
「もう、こんなことを決めなくてはいけないの?」
と、面食らわれることがままあったり…。

従来のウォーターフォール開発ですと、要件定義、基本設計、詳細設計、プログラミング…と、順次詳細に入っていくので、詳細設計くらいの段階でようやくルールの条件や条件に使われる項目の明確な意味が必要になってきます。

仮にアジャイルな開発手法を使っても、ふつうは画面を中心に使い勝手や画面間のつながりなどプロセス的な側面を、まずチェックするので、業務のルールを実装するのは若干、後に。

さて、BRMSですが、これは業務ルールそのものを単刀直入に実装します。その前に設計を…と言っても、

・業務で使っている用語(項目)をきちんと定義します。
・上記の用語(項目)を使って、業務のルールを記述します。

というくらい。これを実装するにしても、上記にしたがって、用語(項目)、ルールを定義してあとは、

・用語(項目)に具体的なデータを設定して実行してみて、結果が想定とあっているか確認します。

これだけ。
論理的に考えれば当たり前といえば当たり前なのですが、従来ですと、仮に業務のルールにあたるプログラムができたとしても、これを動かすためには、データの入出力を担う画面が必要になったり、同じくデータの入出力を司るテスト用のドライバプログラムが必要になったりするのが普通。それに対し、BRMSは、業務のルール(ロジック)を切り出して、独立して動かしテストできます(cf.STEPの原則)。

私の思うに、これは重要なBRMSのメリットのひとつ。本来やりたいことが、業務処理の何らかの(半)自動化ということであれば、処理のしたがう業務ルールを早い段階で実装、動かすことができることは、事前に業務ロジックのバグをつぶしたりするのに大きな威力を発揮することでしょう。実際、以前のプロジェクトで、ユーザが、社内文書としてまとまっていた査定基準を、ルールの形に実装したことで、実は隠れていた査定基準の不備まで発見してしまったということも聞きました。

「もう、こんなことを決めなくてはいけないの?」

…「そうなんです。でないと、BRMSチームはやることがなくなるんです。」
…「でも、決めていただければ、すぐにでも業務のロジックを動かして、テストできますよ。」

経営、IT、ビッグデータ

データイメージ世の中ビッグデータ…ということで、時流にのせられているようでちょっと抵抗もあるのですが、も一つビッグデータの話を。先日、日経朝刊に

ビッグデータ活用の条件 ITと経営の融合が鍵に

という記事が載りました。

趣旨は、Web上に存在する膨大なデータに車の運行状況や携帯電話の位置情報などのデータが加わって、新たなビジネスチャンスが生まれつつある。Webのデータのみで言えば、GoogleやFacebookなどデータのもとを押さえている企業などの独り勝ちの傾向がある。しかし、それにセンサーデータなどの個々人のより深い行動データが得られる場合、さまざまな収益モデルを得られる可能性があり、モバイルや電子マネーの先進国である日本は、この分野でまだまだリードする余地がある…ということ。

一方、従来から現在にかけて、企業におけるIT利用は、日本では基幹系(販売、会計、生産等々)などの業務効率化中心のものであり、米国ではより経営に近い攻めの部分で使われている状況。これがビッグデータの登場で日本でも経営の攻めの部分にITが使われるように変わってくるのでは。

ただ、そのためには経営の視点でのITの利用を推進していかなくてはならず、

・個人情報の扱いを柔軟に適用
・ITと経営の視点をもった人材の育成

といったことが今後重要になってくるだろうとのこと。

そりゃまあそうだよね・・・という気もしなくもないですが、確かに、今ある企業システムを見てみると、まだまだコンピュータの潜在能力を活かしきれていないように思います。前にもこのブログに書きましたが、今現在の企業システムは大部分が「電子大福帳」以上のものではなく、「電脳」には至っていないのではないかと。

もっとも今までの通常のシステム開発 - システムのユーザから要件をヒアリングし、それに基づいて設計をし、実装・テストをし、稼働 - の手法によれば、なかなか現行の作業の効率化という視点以上の要件は出づらく「電子大福帳」システムが蔓延するというのも当然と言えば当然かもしれません。

おそらく今後は、より経営に近い戦略に立ち戻って要求を開発していく「要求開発」などといった方法論が重要になっていくのではないでしょうか。

(ちなみに少々我田引水的ではありますがビジネスルールによるシステム開発方法論「ビジネスルールアプローチ」は、戦略からビジネスルールによる実装までトレースが明確にできるというところがひとつの肝でありまして、こういった「要求開発」などとは親和性が高いと思っています。)

ところで、上の日経の記事は日本はセンサーデータに強いという論調ではありましたが、

ビッグデータを支える「センサー」に落とし穴、今こそ知恵絞る時

とか IoT(Internet of Things) に関する日本語の情報の少なさを見るに、あまり楽観視はできないと思いますが。

ビジネスルールを避ける口実 トップ10

デシジョン管理システム界の大御所 James Taylor のブログにちょっと面白い連載記事が出ていました。読んで楽しむにも、周囲を説得するご参考にも・・・。

Top 10 excuses to avoid business rules (ビジネスルールを避ける口実 トップ10)

#1 You want business users to do what?! (現場のユーザにいったい何をやってほしいの?)
#2 business users don’t want it (現場のユーザはそんなこと望んでないし)
#3 takes too long (結果が出るまでが長すぎるのでは?)
#4 It will never work (そんなもの決して稼働までこぎつけられないよ)
#5 I can’t afford it (そんな余裕ないし)
#6 my operational system does that (そんなことは、すでにうちの現場のシステムでできる)
#7 why do I need more technology? (何で、これ以上新しい技術が必要?)
#8 we’re doing fine (すでに今うまくやってるし)
#9 management doesn’t get it (上が採用しようとしないんでね)
#10 we tried before (前にやったことがある(けど効果がなかった))

よろしかったらどうぞ。

ビジネスルール管理システムとエキスパートシステム(3)

(前項の続き)
1番目は対象分野の違いと書きましたが、その違いによって開発ツールの力点の違いがでてきます。

2.開発ツールの力点の違い

・BRMSは、比較的単純で明確なルールを容易に書け、ビジネスユーザ自身でもルールを記述できることを目指している。
・一方で、エキスパートシステムは、専門家の知識をきちんと表現できるように、複雑なルールも書きやすくしているかわりに、ルールの記述はツールの使い方を習得した専門の担当者でないと難しいようになっている。

(もっとも今のBRMSでも昔のエキスパートシステムシェルでも使っているルールエンジンのコアアルゴリズムはそれほど変わっていないのでルールの記述力としては同じです)

実際、昔のエキスパートシステム開発ツール(シェル)のいくつかは、生のLispやPrologが垣間見えるところがあったりして、さすがにこれを使ってユーザが直接ルールを直すというのはちょっと…という感がありました。しかし、最近のBRMSでは簡単なルールを簡単にわかりやすく記述するというところが徹底されて(もしくは徹底しようとして)いて、さらに、それを前提としたルールのリポジトリや容易なデプロイのしくみなど、まあ言ってみれば至れり尽くせりの方向に進んでいます。

この方向性というのは、結局のところBRMSの概念のもうひとつのルーツである、ビジネスルールアプローチの影響かと思います。

実は、ビジネスルールアプローチについても前に書きかけていたり(^^;)したのですが

ビジネスルールアプローチ(1)

これは、そもそもIBMのGUIDEの1993年に始まる Business Rules Project の中から生まれてきたものです。それまで企業をモデリングするというと、データの側面からや機能の側面からのモデリングは試みられてきたものの、企業が日常のオペレーションを行っていく上での制約といった側面は看過されておりモデリングされてきていませんでした。以上の反省から、このプロジェクトでは、企業のオペレーションのコントロール、構造といった部分をビジネスルールを用いてモデリングすることを目指しました。ちなみにこの辺は、Business Rules Groupのサイトにある

Defining Business Rules ~ What Are They Really?

を見ていただくとわかるかと。ちなみにこのプロジェクトのメンバーを見てみると、E.F. Codd とか John Zachman などといった錚々たる顔ぶれが並んでいてちょっとびっくりします。また、のちにビジネスルールアプローチを推進していく中心的な人物 Barbara von Halle や Ronald Ross の名前も見えます。

(ちょっと脱線しますが、このようにビジネスルールの考え方は、関係データベースやEAの祖を含めた人々が集まって作られてきました。データベースの教科書で有名な C.J.Dateもルールに関する本を書いています。)

さて、メンバーであった Barbara von Halle は、その後2001年にビジネスルールアプローチの具体的な開発方法論を次の本にまとめています。

Business Rules Applied: Building Better Systems Using the Business Rules Approach

この中で、Barbara Von Halle は、BRAの原則としてSTEPということを言っています。詳しくはすでに上記にあげた記事の中で書いているのでそちらを参照するとして、原則だけ列挙しておきましょう。

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

最近のBRMSはまさに上の原則を満たすような形につくられています。
最初にエキスパートシステムの中で実装レベルであらわれた「ルール」の考え方は、ここにいたってビジネスルールアプローチであらわれてきた概念レベルの「ビジネスルール」とドッキングして、BRMSというツールが生まれたわけです。
(この項続く)

(補足)
私が日経コンピュータの例の記事の「ビジネスルール特化型」のBRMSと「オールインワン型」のツールとをしつこく区別しようとしているのは、記事ではBRMSの背景にあるこういった考えをまったく無視しており、自動生成のツールを十把一絡げに「BRMS」という言葉でくくってしまっているからです。たとえば、RDBMSとNoSQLのDBMSを同じDBだからと言って「RDBMS」という言葉でくくってしまっているようなもので、さすがに乱暴すぎるだろうということ…芸人ではないのだから、あまりに ワイルド にすぎるかと。

ルールエンジンとシステム内製

 先週紹介した日経コンピュータの記事には、クラウドとルールエンジンの組み合わせを使った開発でのメリットとして8つあげられていました。このうちの8番目「内製しやすい」というのが今日のテーマ。
 確かにビジネスロジックをルールエンジンを用いて実装すると、ロジックのシステム的な制御部分を隠蔽し、本質的な部分を浮き彫りにさせる効果があります。今回あがっている保険商品の整合性チェックとか保険料の試算などは、ロジック自身はそれほど複雑でないので、ビジネスロジックをたとえば表形式(デシジョンテーブル)でまとめれば、それがほぼそのまま実際に動きます。DroolsではDSL(ドメイン記述言語)もあるので、DSLをうまく設計すれば「日本語で仕様を書けばそれがそのまま動く」といった世界を実現することも夢ではないかもしれません。たとえば

 保険料は、基本料率 * ○○割増 * 保険金額である。
  ただし
 …の場合は○○割増は1.03
 …の場合は○○割増は1.05

とかいったような。こんな感じで書いた仕様がそのまま動くとなると、業務に携わる人が直接プログラムを保守するということも現実解として十分考えられるようになってきそうです。

 今のところ日本ではBRMS(ビジネスルール管理システム)を使って、現場で業務に携わる人が直接ルールを直すという事例はまだ聞いたことはありません。ただ、ごく一般的な日本の事務現場のExcelシート、マクロの開発力(!!)などを考えると、BRMSでの現場での修正開発も案外いけるのかもしれないなあと思っている今日この頃。
 というわけで、最近「システム内製を極める」という本を読みました。基本的に日経コンピュータの記事を集めた内容なので比較的さらっと読めるのですが、最後「おわりに」には、システム開発にたずさわるものとしては考えさせられることが書いてあります。それはまた次の機会に。



エンタープライズマッシュアップ

 Web2.0やマッシュアップという言葉が流行っていたころ、一部で「エンタープライズマッシュアップ」という言葉が使われた時期がありました。まあ、読んで字のごとく、「企業におけるマッシュアップ」ということで、その心は社内外のWeb-APIを組み合わせて企業内のポータルなどを構築する方法論というようなイメージでしょうか。最近はあまり聞かれなくなりましたが、ことさら「マッシュアップ」という言葉を使わなくても、Web上での開発のひとつの方法論としてある程度定着したからなのでしょうか。

 さて、この言葉を思い出したのは、最近ある雑誌の記事を読んだからです。日経コンピュータの最新9月29日号の「システムを「作らず」に作った」という記事。今回作ったシステムは、ユーザインタフェース部分でひとつのクラウド、帳票生成サービス用のクラウド、ルールエンジン用のクラウド、3つのクラウドの間で通信しながら処理を行うというまさに 「クラウド間でSOAを実現しちゃいました」 的なちょっとおもしろいシステムです。そこそこのパフォーマンスも出ているようで一昔前なら夢物語だったような世界が手の届くところまで来たということですね。

 もちろんこのブログの趣旨からして強調したいのは、ルールエンジンでして・・・^^;。最近のルールエンジンのひとつの典型的な使い方として、今回の例のように、保険料の計算や整合性チェックなどのビジネスロジックの処理部分を、ルールエンジンを用いて独立したWebサービスとして提供するというのがあります。そして将来的には、このサービスをさまざまなアプリケーションで使いまわすということ…もっとも、日本国内で「さまざまなアプリケーションで使いまわす」というところまで行っているところはさすがにまだ聞いたことがないのですが…。

 今回、ルールエンジンがクラウドにのったということになると、上記のようなことがやりやすくなるだけでなく、(もちろんセキュリティの面など解決しなければならないことは多いですが)ルールエンジンを用いてビジネスロジックの処理をサービスとして提供するような可能性、幅がより拡がってくことになるでしょう。冒頭に述べた「マッシュアップ」は、ウィジェットを組み合わせてユーザインタフェース部分をひとつにまとめる感が強いですが、今回のケースは、もう少しビジネスのロジックに踏み込み、クラウドに散在するWebサービス間で物事を処理していく、いわばインターネットSOA、クラウドtoクラウドSOAが始まりつつあるということではないでしょうか。

 最初はルールエンジンの話を書こうと思っていたのですが、結局最後はSOAの話になってしまいましたね。長くなるのでルールの話はぜひ記事を…。

(2012年1月12日追記) この日経コンピュータの記事は、日経の電子版の12月28日つけ記事「システムを「作らず」に作った…得られた八つの利点」として読めるようになりました。

Agile Business Rule Development (ABRD)

 ずいぶん久しぶりの投稿になってしまいました。というのも最近、ルール関連の案件が増えてきたおかげで、うれしい悲鳴というのでしょうか。多忙な日々をすごしておりました。

 ブログを書かない間、Droolsは5.2が出ているし・・・、「アイログ」と入れてググってみると、アイドルグループ育成ゲームが出てきたりするようになっていたり・・・。それはともかく、本日は本の話。前に Amazon で予約していた本なのですが超多忙な時期に出版・送付されてきたもので本棚に積み上げ状態になっておりました。その本は

Agile Business Rule Development: process, Architecture, and JRules Examples
  Jerome Boyer、 Hafedh Mili

 IBM(アイログ) の JRules を例にとってはいますが、方法論としてはツールに依存したものではなく、JRules以外でも使えます。その名のとおり一般的な Agile な開発方法論をベースにしており、ドキュメントよりも動くソフトウェアを重視する、利用者との密なコミュニケーションなどといったAgile方法論の原則に則った反復型の開発方法論。
 まだ読み始めたばかりのこの本ですが、久しぶりに出版されたビジネスルールによる実践的なシステム開発の本と言えましょう。ボリュームはありますが、その割りには読みやすいように思えます。JRulesを使わない方も目を通す価値があるのではないでしょうか。