「超高速開発」だけが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

などをご参考に。

システム内製とクリストファー・アレグザンダー

先週、ルールエンジンとシステム内製のブログをアップしましたが、「システム内製」 という言葉で私が思い浮かべたのが、建築家のクリストファー・アレグザンダーでした。

 クリストファー・アレグザンダーと言えば、ご存知の方も多いかと思いますが、GoFデザインパターンの発想の源であるパターンランゲージを着想し創りあげた建築家。そのアレグザンダーとシステム内製がどのようにつながるのか訝る方もおられるかと思いますが、実はアレグザンダーは有名な「時を超えた建設の道」「パターン・ランゲージ」以後にも(私が思うに)重要な著作を発表しているのですね。それらの著作「オレゴン大学の実験」「まちづくりの新しい理論」は、実はシステム開発の上でも非常に示唆的な考え方を含んでいるのではないかと思っているわけです。

 特に「オレゴン大学の実験」は、比較的入りやすいかなあと思いますが、残念ながら今のところ手に入りづらいようなので、そのまま本の目次にもなっている6つの原理を序文から引用しておきましょう。
 アレグザンダーらは、コミュニティでの建設と計画の方法を、以下の次の6つの原理にしたがって遂行することで人々が満足する環境を築けるとしています。

 (以下引用)
 一、有機的秩序の原理 The principle of organic order
 二、参加の原理 The principle of participation
 三、漸進的成長の原理 The principle of piecemeal growth
 四、パターンの原理 The principle of patterns
 五、診断の原理 The principle of diagnosis
 六、調整の原理 The principle of coodination
(「オレゴン大学の実験」鹿島出版会 p14 から引用)

これだけですと、少々わかりにくいので、一、二、だけでも、さらに説明付で引用すると、

 (以下引用)

 一、有機的秩序の原理
  計画や施工は、全体を個別的な行為から徐々に生み出してゆくようなプロセスによって導かれること。

 二、参加の原理
  建設内容や建設方法に関するすべての決定は利用者の手に委ねること。

(「オレゴン大学の実験」鹿島出版会 p15 から引用)

となっています。(ちなみにパターンの原理のパターンは、パターンランゲージのパターンです)

 さて、この6つの原理を眺めてみると、なんとなく私が「システム開発の上で示唆的」であると言っていることがわかるような気がしません? 今回、「システム内製」と関連して思い浮かべたのが、二、の「参加の原理」。「システム内製」すなわち「ユーザー主体開発」そのものという気がしませんか? また、一、の有機的秩序の原理などは、EA(エンタープライズアーキテクチャ)を、前もってきちんと定めて個々の開発をその枠内で進めていく…という行き方と真逆のことを言っているようでちょっと面白かったりします。

 もちろん、都市計画や建築の手法がそのままシステム開発に応用できるとは、万事楽観的な私といえども思ってはいませんが、新たな視点を得るという意味ではなかなか示唆に富むものではないでしょうか。

 システム業界では、クリストファー・アレグザンダーと言えばデザインパターンですが、実はデザインパターン以外にも汲み取るべき考え方はまだまだあるのではないかと思っています。

 アレグザンダー恐るべし!