「今話題のBRMS、 「ビジネスルール」とは」

　少し前になりますが、日経コンピュータの3/15号で「超高速開発」が日本を救う」として、ビジネスルール管理システム(BRMS）が特集されていました。
　BRMSを使うと、ビジネスルールを実行するプログラムがルールエンジンで自動生成でき、またルール間の整合性もチェックされるため、詳細設計～テスト工数を大幅に削減することができます。ビジネスルールは、フローチャートや表などで入力・管理し、日本語などの自然言語が使えます。システム言語ではありませんので、業務部門もメンテナンスできそうです。

　ところで、システム化される前は、業務部門が全てビジネスルールを理解して業務を進めていましたが、今はどうでしょうか？システム化が進むとシステムを使って業務をすることはできても、ビジネスルールの意味を理解していない、説明できない業務担当者が増えているように思います。その結果、システム再構築などでは、既存システムの仕様は現行システム調査で確認することになります。その現行システム調査も、システムドキュメントのメンテナンスが不十分なことが多く、プログラムから解析をすることとなり、現行保守担当でないと時間がかかり、品質確保も困難です。

　しかし、ビジネスルールをアプリケーションと切り離し、一括管理して見える化すれば、業務部門が管理しやすくなります。ビジネスルールの変更であれば、業務担当者が変更することもできるようになります。
　また、ビジネスルールから実行されるプログラムが自動生成されるため、システム担当者の仕様の理解ミスによるビジネスルールとプログラムの相違は発生しません。
　ビジネスルールとアプリケーションを切り離すことで、アプリケーションがシンプルになり、そしてビジネスルールを個別に扱うことで複雑な条件分岐のロジックを組み合わせることができるようになるため、結果としてアプリケーションが柔軟に扱えるようになります。
　このように、BRMSを使うことはとても魅力的に見えます。

■ビジネスルールとは

　ところでBRMSで管理する「ビジネスルール」とは何でしょうか。
　ビジネスルールグループ（※1） によると、ビジネスルールは次の2つの観点で定義できます。

1. ビジネスの観点から
   　ビジネスルールとは「特定の活動や領域内での経営、行動、実務、手順に関する義務を記したガイダンス」です。
2. 情報システムの観点から
   　ビジネスルールとは「ビジネスの何らかの観点を定義または制約する記述」です。ビジネスルールは、ビジネス構造を確立すること、あるいはビジネスの振る舞いを制御したり影響を及ぼすことを目的としています。

　ビジネスルールグループでは、「ビジネスルール・マニフェスト（※2）」でビジネスルールを以下のように宣言しています。

　ルールとプロセス、手続きについて、さらに以下のように宣言しています。
　2.2 ルールはプロセスでもなければ手続きでもない。ルールはそのどちらにも含まれるべきではない。
　2.3 ルールは、プロセスと手続きの全体に適用される。ビジネス活動に関連するすべての領域をまたがって一貫して適用できる、まとまったルールが一組存在しなければならない。

　これはどういうことでしょうか？

ＢＲCommunityのペーパー「From Policy to Business Rules」（※3）によると、以下のようにビジネスプロセスの階層に対応して、ルールも「全社ポリシー」→「部門ポリシー」→「仕事の手順」→「ビジネスルール」と階層構造が可能だとしています。これは、プロセスや手続きに対応するルールをそれぞれに適用するということで、ルールはプロセスや手続きから分離しており、プロセスと手続きの全体（＝両方？）に適用されるというビジネスルール・マニフェストの2.2、2.3での宣言につながるのだと思います。

引用：ＢＲCommunityのペーパーの「From Policy to Business Rules」
図2. Conceptual Decomposition - Company Policy

　ところで、これは、SOA「サービス指向アーキテクチャ」と非常に考え方が似ています。SOAでは、「サービス」の集まりとしてコンポーネント化し、「サービス」として外部から標準化された手順によって呼び出すことのできるソフトウェアの集合体として扱います。ビジネスルールもプロセスからも手続きからも独立し両方に適用される、つまり呼び出されるということですから、ビジネスルールは１番粒度の小さいサービスと言えるのではないでしょうか。

■ビジネスルール・アプローチ

　さて、このビジネスルールを明確に意識した開発方法論として、ビジネスルール・アプローチという考え方があります。ビジネスルールグループのメンバーであるBarbara von Halleは、"Business Rules Applied"の中でビジネスルール・アプローチ管理手法として、次の「S-T-E-P原則」をあげています。

• Separate rules(ルールを分離する)
• Trace rules（ルールがトレースできるようにする）
• Externalize rules(ルールを外部化する)
• Position rules for change(変更を前提にルールを配置する)

　これは、

• ビジネスルールを他のシステム要件の中から分離することで、ビジネスルールを再利用したり、他のシステム要件から独立して変更できる
• ビジネスルールの基になる戦略・戦術にトレースでき、また、ビジネスルールの実装へもトレースできることにより、ビジネスルールの正当性が保証され、変更時の影響範囲もわかりやすくなる
• ビジネスルールを外部化することにより、見える化を図ることになる
• ビジネスルールを変更しやすくすることで、急速なビジネス変化へ迅速に対応できるようになる

　ということです。

　個人的には、特に「Trace rules」がポイントではないかと考えています。
　ビジネスアナリシスの知識体系であるBABOK(R)でも、要求についてトレースを重視しています。BABOK(R)では要求を「ビジネス要求」「ステークホルダー要求」「ソリューション要求」の３段階に分けています。その３つの要求について、「要求のトレーサビリティをマネジメントする」「要求を妥当性確認する」というタスクで、ビジネスゴール・ニーズである「ビジネス要求」が「ステークホルダー要求」「ソリューション要求」へトレースされていることをマネージメントし、確認するとしています。これは、戦略・戦術がルールにトレースされていることを保証するという考え方だと思います。
　また、ソリューションについては「ソリューションの妥当性確認する」で出来上がったソリューション（＝実装されたもの）が「ビジネス要求」・「ステークホルダー要求」と整合性がとれていることを確認します。これはルールが実装にトレースされていることを確認することと言えるでしょう。

　戦略・戦術がビジネスルールや実装にトレースされることが保証されるのは、
　「ビジネス要求に繋がる適切な情報システムを構築すること」
　⇒「的の外れた余分な情報システムを構築しない」
　ということで、情報システムへの投資効率の観点からも非常に魅力的だと思うのです。

　■さいごに
　日経コンピュータ3/15号3/29号でも掲載されていますように、BRMSの導入事例は、ビジネスルールの塊である保険商品を持つ保険・金融業界で多く、それ以外では通信会社の料金プラン管理やコールセンターの顧客対応ルール、物流の積載管理などでも適用されています。
　このようにビジネスルールを切り出してBRMSで管理するか、プロセスの中に記述するかは、ルールの規模と変化の頻度で判断されています。ルールが頻繁に変更される場合はビジネスルールとして切り出すのがよいでしょうし、あまり変更されなければプロセスに記述されていても問題ないでしょう。またあまり変更がなくてもルールの規模が大きいときには切り出した方が管理しやすくなるでしょう。
　某BRMS製品を提供している企業の方に話を伺うと、日経コンピュータの記事で非常にBRMSの問合せが増えたそうですが、そのほとんどがビジネスルールをどのように整理し、BRMSへ適用すればよいのか、ということだったそうです。BRMS製品は自由度が高くどのようにも登録できるため、問合せに対して適切に回答することが難しかったとのことでした。BRMS製品をうまく適用するためには、ビジネスルールの整理方法やビジネスルール記述の標準化が大切であるということでしょう。
　ビジネス要求やステークホルダー要求を実現する品質のよいシステムを高速で開発するために、今後さらにBRMSを導入する企業や組織が増えると思います。BRMSがどれくらい日本でも高速開発に寄与するのか、今後も注目していきたいと思います。

※1：ビジネスルールグループ：http://www.businessrulesgroup.org/
IBMのGUIDEの1993年に始まる Business Rules Project の中から生まれ組織で、現在はGUIDEとは独立したNPO。システムとビジネス分析の方法論の分野で経験豊富な実務家で構成されています。ビジネスグループのチャーターは、企業オペレーションとビジネスルールの関係、システムアーキテクチャとビジネスルールの関係について標準規格を作成すること。

※2：ビジネスルール・マニフェスト：
http://www.businessrulesgroup.org/brmanifesto/BRManifesto-Japanese.pdf

※3：BRCommunityのペーパー「IGOE - Guides　From Policy to Business Rules」
http://www.brcommunity.com/b661.php

*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。

• 「製造業のビジネスモデルとエンタープライズ・アーキテクチャ　その２」 前の記事へ
• 「『クラウドファンディング』に関する考察」 次の記事へ

『WEBマガジン』に関しては下記よりお気軽にお問い合わせください。

• お問い合わせ

同一テーマ　記事一覧