« 「大規模集積回路モデル」と「板チョコモデル」 | トップページ | ボトルネックは「業務系スキル」 »

2014.07.30

データとして登録されるビジネスルール

 ビジネスルール(*1)と呼ばれるものの多くは「データベース構造」としてシステムに反映されるが、一部は「データ(インスタンス)」としてデータベースに登録される。その位置づけはシステム構成を考える際に興味深い論点で、効果的なシステムを設計するためのヒントになるだろう。

 なお、ビジネスルールは業務システムの「業務構成」か「データ構成」か「機能構成」のいずれかの様態として組み込まれる。これらの3要素はそれぞれ、「役割分担や業務手順」、「データベース構造」、「プログラム仕様」くらいに理解してもらえばよい。これらのうちの「機能構成」に組み込まれがちなビジネスルールをいかに「データ構成」側に持ち込むか。それが、保守性の高い業務システムを手に入れるための課題である。

 さて、ある種のビジネスルールは「データ構造」としてではなく「データ」としてシステムに組み込まれる。ただしこれは比較的特殊なケースだ。たとえば「受注テーブルのデータ構造」は、受注業務に関するビジネスルールが反映された結果である。いっぽう「受注テーブルのデータ」は個々の受注が反映されたもので、ビジネスルールそのものではない。では「データとして組み込まれるビジネスルール」とはいったいどんなシロモノなのだろう。

 「ルール」とは言い難いところもあるのだが、「システム変数」はそのわかりやすい例だ。システム変数とは、プログラムが動作する際に参照されるグローバル変数のことで、「年度初月」、「月末締日」、「標準賃率」、「標準為替レート」といった多彩な情報が含まれる。項目によっては値が変わることがほとんどなかったりするが、それでもプログラムのコード中に固定値として書き込むのではなく、可変なシステム変数として一元化しておいたほうがいい。結果的にこれらの要素はある種の「データとして組み込まれるビジネスルール」として、システムの振舞いに影響を与える。

 もっと本格的で興味深い例が、先日のIT勉強宴会で紹介した「受注生産システム」の事例に含まれている。この業態では、注文品の仕様管理が効果的になされる必要がある。そのために、製造品のタイプ毎に「仕様構成」のマスターを用意することを考える。注文を受け取ったときに製造品のタイプを指定することで、規定の仕様構成にもとづいて注文品の仕様を登録・管理するためだ。たとえば、ある製造品タイプ向けの仕様構成マスターが次のようだったとしよう。

<仕様構成マスター>
No. 仕様要素名 データ型
-------------------------
1. 素材      文字(10)
2. 内径(mm)   数字(5.1)
3. 外径(mm)   数字(5.1)
4. 長さ(mm)   数字(5.1)
5. 表面仕上げ 文字(10)

 注文毎に、この構成にもとづいて各仕様要素の実際値を設定することになる。実際の注文において、たとえば以下のような値をとる。

<実際の受注生産品の仕様明細>
No. 仕様要素名 実際値
------------------------
1. 素材     超合金Z
2. 内径(mm)  10.8
3. 外径(mm)  14.5
4. 長さ(mm)  350.2
5. 表面仕上げ 輪島塗

 これらはユーザによって明示的に値が指定される項目だが、そういうものばかりとは限らない。たとえば次の「5.重量(g)」はどうだろう。

<実際の受注生産品の仕様明細>
No. 仕様要素名 実際値
------------------------
1. 素材     超合金Z
2. 内径(mm)  10.8
3. 外径(mm)  14.5
4. 長さ(mm)  350.2
5. 重量(g)    760.1
6. 表面仕上げ 輪島塗

 この項目は他と違って、いくつかの項目の組み合わせ(たとえば素材と内径と外径と長さ)から導出可能である。ただしその導出手順は項目毎に固有で、あらかじめ「導出区分」のような形に類型化できそうにない。とはいえユーザにいちいち手計算させるわけにはいかないので、さきほどの仕様構成マスターに「導出式」を組み込むことを考える。

<仕様構成マスター>
No. 仕様要素名 仕様ID データ型 導出式
--------------------------------------------------
1. 素材     sozai  文字(10)   null
2. 内径(mm)  naikei 数字(5.1)  null
3. 外径(mm)  gaikei 数字(5.1)  null
4. 長さ(mm)  nagasa 数字(5.1)  null
5. 重量(g)    jyuryo 数字(9.1)  (具体的なコード)
6. 表面仕上げ siage  文字(10)  null

 「導出式」には、各仕様要素の「仕様ID」にもとづく条件文や演算を含んだコードセグメントが埋め込まれる。導出式の他に、指定値の妥当性を検査するための「評価式」も要りそうだ。定型的な内容については可読性を高めるために、あらかじめわかりやすい名前の関数を用意しておいても効果的だろう。これはまさに、「データとして組み込まれるビジネスルール」の例なのである。

 こういった処理要件をJavaのようなコンパイル言語だけで実装することは難しいが、eval(その場でコードを与えて実行するための命令)を搭載したスクリプト言語を併用すれば比較的容易だ。データベースに「計算項目の値」ばかりでなく「計算手順」までを登録して、必要に応じて読み出して実行できる。やり過ぎると見通しが悪くなったりテストしにくくなったりもするが、適度に使えば大きな効果がある。金融商品や複雑な単価テーブルの制御など、さまざまに応用できる。

 ちなみに拙作の開発基盤XEAD Driverでは、evalは「テーブル・スクリプト」の中で記述される。テーブル毎に決まる処理過程をスクリプトとしてテーブル定義に組み込めるだけでなく、テーブルにデータとして登録されたロジックさえその中で実行できるのである。セッションが立ち上がると、アプリケーションドライバが「プログラム仕様書」を読み込み、さらにその中で処理対象として指定されている「テーブル仕様書(テーブルスクリプトを含む)」を読み込んで統合し、その場で自分自身を変形させて立ち上がる(コードの自動生成とかは起こらない)。現在の実装技術を使えば、仕様要素を機能構成からデータ構成に寄せるためのこんな工夫さえ可能だ。

 これまで多くのビジネスルールが、画面や帳票といった「機能構成」に無批判に組み込まれてきた。もしそれらが「テーブルに従属するルール」なのであれば「データ構成」として組み込まれるべきだ。それらのルールが「テーブルに関する諸問題」であるからにはそのほうがインテンショナルだし、結果的に各機能の仕様が「ありきたりで薄っぺら」になって全体の保守性が高まるからだ。それだけでなく、業務システムそのものの可能性も広がるような予感がある。


*1.業務ロジックなどともいう。ここでは「業務上の要請によって決まる機能的システム要件」くらいに理解しておいてもらえばいい。

|

« 「大規模集積回路モデル」と「板チョコモデル」 | トップページ | ボトルネックは「業務系スキル」 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: データとして登録されるビジネスルール:

« 「大規模集積回路モデル」と「板チョコモデル」 | トップページ | ボトルネックは「業務系スキル」 »