２．従来の業務システム（プロセスベース）の問題点とその影響
従来の業務システムの開発方法の問題は何でしょうか。それがもたらす悪影響はどんなものが予想されるでしょうか。逆に問題が解決できると、どのようなメリット（恩恵）が得られるのでしょうか。順番に考えてみます。
２．１従来の業務システム（プロセスベース）開発の問題点
従来の業務システムの開発では、業務プロセス（業務ロジック）の中で、制約条件や判定基準などのビジネスルールを組み込んでアプリケーションコードを作成していました。
データベースをアプリケーションから切り離すこと（いわゆるDOA：データーオリエンテッドアプローチ）に主眼が置かれていて、データベース管理として長く定着してきた歴史があります。しかし、その反面ビジネスルールへの関心はあまり高くなく、アプリケーション（プロセス）の一部分という認識しかなかったのです。
Red Hat社資料より
業務アプリケーション＝ プロセス + ルール + データ
のはすが、実際のアプリケーションでは
業務アプリケーション＝ プロセス[ルール含む] + データ
だったのです。
それでも多くの業務アプリケーションでは問題ありませんでした。それは比較的単純な業務でデータだけしっかり管理していれば効果が高く得られていたからです。
Red Hat社資料より
ルールを変更しようとすると、システムのアプリケーションコードを書き換えなくてはいけず、多大な工数を必要とします。最近このことのデメリットが目立ってきました。
２．２ ルールがプロセスに混在することの悪影響
運用時においてビジネスルールは変更する可能性が多いものです。例えば、ビジネス環境が変化し、競合他社の戦略が変更されたりすると、ビジネスルールも変更せざるを得なくなるケースがしばし見受けられます。携帯電話の料金プランはその典型例と言えます。ABCプラン、XYZプラン、DEF割引など、毎月のように新たなルールが登場します。
このような状況で、ルールがプロセスに混在したままアプリケーションコードを作成してしまうと、ビジネスの環境変化に対応することが大変困難です。ルールだけ変更するためにも、システム開発するのに匹敵するだけの工数を必要とすることになりかねません（すべてのプロセスを見直す必要が生じた場合）。競合状況も悪化します。ルールを環境に合わせるのに数か月かかってしまうと、競合状況も一変してしまいます。競合に差をつけられるだけでなく、顧客満足度にも影響が出るかもしれません。スポンサーの期待からもほど遠いものになるでしょう。社員のリストラや工場売却などが現実味を帯びてきます。かつての日本を代表する超一流メーカーの凋落ぶりは大変歯がゆいものがあります。韓国のサムソンに大きく差をつけられている要因かもしれません。
Red Hat社資料より
２．３ ルールとプロセスの混在を解消した場合のメリット
逆に、ルールをプロセスから分離できたとしたら、どんなメリットがあるのか考えてみましょう。システムを運用中であったとしても、アプリケーションコードをいじる必要なくルールだけを変えることができるようになるでしょう。ひょっとしたら情報システムのエンジニアでなくてもルールを変更できるかもしれません。そうなると、ルールをその日のうちに変更することができ、その日のうちに新ルールで実行が可能になります。ビジネス環境の変化に素早く対応することができ、逆にビジネス環境の変化をリードすることすら可能になります。
また、競合に遅れていたものが逆に競合をリードできる立場になり、先手で対策を打つことが可能になります。顧客が期待していたルールが早期に実現できるので顧客満足度も向上します。その結果スポンサーの満足度も向上することになるでしょう。
ルールがプロセスからうまく分離できれば、プロセスはよりシンプルになり、アプリケーションコードはより安定（長持ち）することになります。運用時の要求変化をルールの形でうまく吸収することも可能になります。
どうやらルールをプロセスから分離するべきことのようですね。
次回は最近のBRMS（ビジネスルール管理システム）の動向を見てみましょう。