BRMSを用いた開発プロジェクトは規模が大きいと、多くの場合、
・画面等を中心としたアプリケーション開発チーム
・BRMSを用いたルール開発チーム
に別れて、ウォーターフォール的に進められますが、その場合、BRMSチームの方は従来の一般的なプロジェクトよりも、ずっと早い段階で業務的な仕様の核心に入ってしまいます。
ユーザとの打ち合わせで、BRMSチームがルールで使う項目や条件についてヒアリングしようとすると、業務ユーザに
「もう、こんなことを決めなくてはいけないの？」
と、面食らわれることがままあったり…。
従来のウォーターフォール開発ですと、要件定義、基本設計、詳細設計、プログラミング…と、順次詳細に入っていくので、詳細設計くらいの段階でようやくルールの条件や条件に使われる項目の明確な意味が必要になってきます。
仮にアジャイルな開発手法を使っても、ふつうは画面を中心に使い勝手や画面間のつながりなどプロセス的な側面を、まずチェックするので、業務のルールを実装するのは若干、後に。
さて、BRMSですが、これは業務ルールそのものを単刀直入に実装します。その前に設計を…と言っても、
・業務で使っている用語(項目)をきちんと定義します。
・上記の用語(項目)を使って、業務のルールを記述します。
というくらい。これを実装するにしても、上記にしたがって、用語(項目)、ルールを定義してあとは、
・用語(項目)に具体的なデータを設定して実行してみて、結果が想定とあっているか確認します。
これだけ。
論理的に考えれば当たり前といえば当たり前なのですが、従来ですと、仮に業務のルールにあたるプログラムができたとしても、これを動かすためには、データの入出力を担う画面が必要になったり、同じくデータの入出力を司るテスト用のドライバプログラムが必要になったりするのが普通。それに対し、BRMSは、業務のルール(ロジック)を切り出して、独立して動かしテストできます(cf.STEPの原則)。
私の思うに、これは重要なBRMSのメリットのひとつ。本来やりたいことが、業務処理の何らかの(半)自動化ということであれば、処理のしたがう業務ルールを早い段階で実装、動かすことができることは、事前に業務ロジックのバグをつぶしたりするのに大きな威力を発揮することでしょう。実際、以前のプロジェクトで、ユーザが、社内文書としてまとまっていた査定基準を、ルールの形に実装したことで、実は隠れていた査定基準の不備まで発見してしまったということも聞きました。
「もう、こんなことを決めなくてはいけないの？」
…「そうなんです。でないと、BRMSチームはやることがなくなるんです。」
…「でも、決めていただければ、すぐにでも業務のロジックを動かして、テストできますよ。」
コメント