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) に関する日本語の情報の少なさを見るに、あまり楽観視はできないと思いますが。

続々 日経コンピュータの「超高速開発」特集

ひとつの記事で、ちょっと引っ張りすぎかとも思いますが、もう少し。

この記事で違和感を感じていたことがもうひとつあります。それは、

「超高速開発」が日本を救う

という見出し。システム開発が速く効率的に進められるに越したことはないのですが、それがそのまま日本を救う…? もちろん見出し特有の誇張だとは思いますが、一方で裏を返せば、開発が速くできればそれでOKという意識が垣間見られて…ちょっと穿ち過ぎでしょうか。

***

一般的なユーザ企業で利用される(コンピュータ)システムの技術には大きく2つの方向があると私は思っています。

  • システム開発ツールや開発方法論などシステムの開発効率をあげる方向。
  • システムをどのように使って現実の問題に対処するか、システムをどのように現実の問題に応用していくか、という方向

私も学生時代を含めると30年近くこの分野に携わっていますが、私の見るに日本の企業向けシステム技術の方向が、ここのところ…というかJavaやUMLが出てきた10数年前から開発効率をあげること…開発方法論とか開発ツール、開発言語に偏重しているような気がしています。

もちろん開発効率をあげることは重要であり、未だに企業内の情報化が進んでいない企業などでは、最重要の課題であることもわかります。その上でやはり、世間一般で、「そもそもどんなシステムを作るのか」という議論が少ないように思うのです。

もっとも私自身、開発方法論こそが大事…と思っていたことがありました。そのころは企業内のコンピュータシステムは汎用機全盛の時代。システム全体での新人研修の言語はCOBOL。構造化プログラミングの話とか。学生時代に多少なりとも抽象データ型とかオブジェクト指向とかを齧ってきたものにとっては、…う~ん。という時代でした。

そんなときに最初に配属されたのが、人工知能やORを用いて生産計画(などなど)のシステムをつくるようなところ。それこそ「システムをどのように使って現実の問題に対処するか」の技術の部署でした。
最適化手法や人工知能など、技術としてそれなりにはおもしろかったのですが、個人的にはシステム開発の方法論が(生意気にも)あまりにもナイーブだなと思って、オブジェクト指向の勉強(*1)をやっていました。

それが、UMLやJava、そしてデザインパターンなどが出てきて世の中の流れが一気に方法論に傾き始めたように思います(特に日本)。もちろんこれによりさまざまな洗練された開発手法がうまれてきたことは確かですし、それ自体は喜ばしいことではあるのですが、一方でそもそもコンピュータを使って何をやるかというところについては停滞気味になってしまっていったのではないでしょうか(特に日本)。そんな中、ここ10数年インターネットが普及するにつれ、従来の企業のシステムからは考えられないようなインターネット上のサービスがうまれてきています。検索エンジンしかり、SNSしかり、動画共有サイトしかり、ECしかり…これらはいずれも「システムをどのように現実の問題に応用していくか」という問いの上に生まれてきたものです。インターネットの世界では、まず「何をつくるか」があります。

翻って従来からの企業のアプリを考えたとき「何をつくるか」というのはだいたい決まっていて、それを「どう効率的に開発するか」ということが焦点になりがちです(特に日本)。

…そろそろ企業のアプリ開発でも、「何を作るか」ということにもうちょっと重心を移していって良いのではないでしょうか(特に日本)。

私が仕事で生産計画や人工知能をやっていたのは20年以上も前。そのときはコンピュータパワーの貧弱さがひとつのネックとなっていました。しかし現在、iPad2などは、そのころの一般的なスーパーコンピュータのひとつCray2/4と同等だとか。昔を知っている人ならわかると思いますが、あのCray(*2)が街中に、電車の中に、家の中にころがっているのです。

こんな時代に20年前と同じような発想でアプリを考えていてはもったいないでしょう。昔できなかった最適化の計算などは、普通に行けたり^^。最近流行りつつある「ビッグデータ」の分析などは、これからのひとつの方向を示しているのかもしれません。

(また、このコンピュータパワーの飛躍的な増大がなければ、(ビジネスルール特化型の)BRMSは存在し得なかったでしょう。)

***

実は(ビジネスルール特化型の)BRMSの世界では、以前からの謳い文句「ビジネスの変化に合わせてITも変更」というところから一歩進んだところ、たとえばデータ分析とBRMSとを組み合わせた意思決定の最適化という方向に重点がシフトしていきつつあります。つまり、開発・保守のスピードを問題にするのではなく、そのスピードを前提にしてそれらをどう活かしていくということが焦点になってきています(*3)。

***

というわけで、

「超高速開発」

するのはよいのですが、それだけで

日本が救われる

とは思えません(笑)。

今の時代、開発が「超高速」かどうかはともかく、定型的な開発などはできるだけ無駄を減らし、手間をかけずに、自動生成できるところはできるだけ自動生成ですませる。そして、システムを現実の問題の解決のためにいかに適用していくかというところ、システムに「付加価値」をどうつけていくかという部分により注力していかないことには「日本は救われない」のではないでしょうか。

「超高速開発」を前提として、その一歩先の話が議論されていくようでないと「日本を救う」と言えないのではないでしょうか。

***

最後の方はかなり調子が高くなってしまいましたが、前回の記事で自動生成ツールについて使えるところではどんどん使っていけばよいと書いた真意はそこにあります。

過去20年間で、コンピュータパワーは飛躍的にアップし、またシステムを利用する要素技術も格段に進歩しました(たとえば機械学習などを含む統計的な数々の手法など)。一方でこれらを現実に適用していくことに関しては緒に就いたばかりで、これからの大きな発展が期待されています。

いままで仕事として、ユーザの業務にも、システム技術にも向き合ってきたはずのSEは、これからのシステムの応用技術を開拓し、新たなビジネスモデルを考えていくのに恰好な人材だと思っているのですがねえ。

***

*1 : ちなみに、そのころ読んだのは、バートランドメイヤーの「オブジェクト指向入門」の第1版。これはおもしろかったです。私のオブジェクト指向の知識のベースはこの本、類いまれなる名著だと思います。
今は第2版が出ていますが、2分冊になってそれぞれが辞書みたいに分厚いのでさすがに読む気になりません(^^;)・・・でも、たぶん読んだらとても勉強になると思います。その他にはOMTBooch法Coad&Yourdonの本などを濫読していました。

*2 : そのころはスーパーコンピュータといえばCray、Crayといえばスーパーコンピュータという時代でした。もちろんNECや富士通など日本勢も健闘してはいましたが、デザイン面でのCrayのインパクトにはかないませんでした。

*3 : この辺は、BRMSの記述はあまりありませんが、ちょっと古いダヴェンポートの本。さらに最近の本としては、James TaylorのDecision Management Systemsとかが参考になるかと思います。

続 日経コンピュータの「超高速開発」特集

表題の日経記事の「オール・イン・ワン型」自動生成ツール(BRMSに分類するのは私としては違和感を禁じ得ないので、あえて自動生成ツールとしておきます)について、前回も書きましたが、私自身は、使えるところであれば積極的に使っていってよいと思っています。ネットを見てみると、否定的か肯定的か極端な意見がわりに多かったですが、現実的に見れば、それほど毛嫌いする理由もないですし、一方で盲信するほど革命的という話でもないでしょう。

最近はシステムの技術も進歩して、こういった自動生成のツールに限らず、フレームワーク(商用、OSSを問わず)などでもそこそこよくできているものなら、ちょっとしたアプリのスケルトンくらい簡単にできてしまいます。

なので、今現在開発の現場にいる方にとっては、これらツールを、分野をある程度限定して、多少の開発ノウハウを加え、洗練させていけば、そこそこのアプリが自動生成できるだろうことは想像つくのではないでしょうか(もちろんそういった自動生成ツールを作るのは簡単ではないとは思います)。またそもそも自動生成するアプリが使えないようなら、ERPや業務用のパッケージはおそらくもっと使えないはず。実際にERPや業務用パッケージが製品として成り立っている以上、自動生成するアプリは少なくともそこそこは使えるでしょう。アプリ的に言えば、あとはそれをそのまま使っていくかどうかの問題だけだと思います。

自動生成ツールが使えないという話は自動生成したアプリそのものが使えないというよりもむしろ、

  • 既存の他システムとのインタフェースをとりづらい。
  • ソースコードを生成するツールの場合、生成したコードを手で微調整するだけの柔軟性はあるが、一方で、あらためてツールを使ってアプリを再構築といったときに手で修正したソースコードの扱いが非常に難しい

といったところでしょうか。逆にこの辺の弱点がうまくクリアできれば(もしくは我慢ができれば)手間をかけずに自動生成できるツールを採用しない手はないのではと思います。

そもそも今ある大部分の業務アプリというのは、事務の台帳をDB化したもの。ロジックそのものに複雑なところがあるわけではありません。そういったアプリに対しては必要以上に人手をかけて開発を行うよりも、
使えるところは自動生成ツールやパッケージを積極的に使ってうまく開発していくのが得策だと最近特に思っています。(続く…)