TOP>製品/サービス>カテゴリから探す>ビジネスルール管理(BRMS)>Progress Corticon>BRMSコンサルタントが語る ~超高速開発だけがメリットではない~ Vol.1

Progress Corticon

BRMSコンサルタントが語る ~超高速開発だけがメリットではない~ Vol.1

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

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

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

BRMSによる開発は、もう少し広く BRA (ビジネスルールアプローチ) による開発といった視点、さらに対象とするビジネスそのものといった視点に立って考えると、少なくとも次のような特徴をあげることができるようになります。

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

従来の手法ですと、企業におけるさまざまな業務が拠って立つビジネスルールは、一旦、仕様書/設計書に落とされ、さらにシステムに実装されたときにはCOBOL、Java、C#など、プログラムのソースコードに埋め込まれてしまいます。実際にシステムを利用する業務担当者は、実装されているビジネスルールを仕様書を通してしか見ることができません。

一方、システムを実装する担当者は、仕様書に書かれているビジネスルールをプログラムのソースコードに変換してシステムとして実装することになります。業務担当者とシステム実装者との間には、仕様書/設計書を通しての何段かの伝言ゲームが存在し、有名な下の図のような要求の食い違いが表れやすくもなってくることでしょう。

University of London Computer Center Newsletter, No.53, March 1973

University of London Computer Center Newsletter, No.53, March 1973
詳細は「豆蔵ソフト工学ラボ」を参照

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

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

さらに付け加えると、このBRMS(ルールベース技術) の「見える化」という特徴を一歩進め、BRMSを技術継承の道具として使う使い方などもあります。一時期の「2007年問題」はまさにこの技術継承の問題。さすがに「2007年問題」は最近では言われることはなくなりましたが、技術継承の問題は企業を継続して運営していく上ではどこにおいても避けることのできない問題です。たとえば製造業などではプラントの操作など、いたるところに職人的な専門家がいることが多いですが、その場合そのノウハウは、たいてい、明示的に文書化されておらず、専門家の頭の中に暗黙知として埋蔵されています。これらのノウハウは、昔ですと徒弟制度的にOJTで伝えていったり、文書化できるところだけでもマニュアル化して伝承したり、最近では作業の動画を録ってみたりと、これまでにもさまざまな伝達手段がありました。ルールベースによる技術継承もこのうちのひとつで、暗黙知を「ルール」として記述していくことになります。ただ、単純にルールとして「記述する」だけでは文書としてルールを記述するのと何ら違いがありません。「ルールとして記述する」ということが「文書として記述する」のに比べて何がおもしろいか・・・というと、それは記述したルールがそのまま実行できるところなのです。さて記述したルールがそのまま実行できると、次のようなことが可能になります。

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

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

2. 変化に対応しやすい

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

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

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

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

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

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

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

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

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

著者プロフィール

BRMSコンサルタント 津島 靖彦 氏

BRMSコンサルタント。
様々な経営方針に基づくシステム化の企画に携わり、過去には損害保険、生命保険会社で、BRMSを利用した申請書類や査定事務処理チェックシステムの構築、保険料試算、査定支援システムの構築など数々の実績を残す。

関連記事

お求めの情報は見つかりましたでしょうか。

資料請求/お問い合わせはこちら(専門の担当者が確認し、ご対応します。)

お客様の状況に合わせて詳しい情報をお届けできます。お気軽にご相談ください。

ページの先頭へ戻る