コンテンツへスキップ

ビジネスルールの上流設計で失敗しないための羅針盤

業務知識とIT要素の分離戦略
2025年11月25日 by
ビジネスルールの上流設計で失敗しないための羅針盤
innorules, イノルールズ株式会社

業務知識とIT要素の分離戦略


システム開発において、品質と柔軟性を大きく左右するのが、ビジネスルールの上流設計です。特に、要件の中でどこをルール化するかを決めるプロセス(ビジネスルールの抽出、または Business rule mining)は極めて重要です。

本記事では、どのようにして本質的なビジネスルールを抽出し、上流フェーズでの失敗を避けるか、そして業務知識とIT要素を分離することの重要性について解説します。


1. ビジネスルールの抽出とは何か?


ビジネスルールとは、一言で言えば「業務知識」にほかなりません。ビジネスルール専門家コミュニティ(BRCommunity)によれば、組織のシステムやデータの中に「埋もれて見えなくなっている意思決定のルール」を、「掘り起こし」、誰もが理解・確認できるように明確に定義することです。

たとえば、通信業で「他社に負けない割引オプションを適用する」という目標(GOAL)がある場合、それを達成するためには、「学生割引は最初の3か月は60%に設定する(50%では解約率が高い為今回は10%UPする)」といった具体的な業務知識を経験やレガシーコードから抽出する必要があります。


ここで、ビジネスルールの構造を見てみましょう。言葉で説明すると業務ロジックに近い内容ですが、ここではモデルとして定義してみます。

ビジネスルールは、構造的に以下の要素から構成されています。

  • 意思決定(ディシジョン)
  • 項目(業務用語)
  • ガイドライン(拠り所)
  • 制約:例)被保険者の年齢は、20歳以上60歳未満でなくてはならない。
  • 推論:例)顧客の月間購入額が10万円以上で支払の延滞履歴が全くなければ、優先顧客とする。
  • 計算:例)顧客がゴールド会員であれば、注文総額は、注文した商品総額から5%割り引いた後、消費税と送料を加えたものとする。

BRMS製品ではルールでルールを書ける、いわゆるメタルールの構造がとれる製品があります。InnoRulesもその一つです。上図で単位ルールはそのことを表現しています。


2. BRMS(ビジネスルール管理システム)の位置づけ


BRMSとは、この「業務知識」をルールとして登録・管理するための専門ツールです。

スクラッチベースのシステム開発では、業務ロジックがアプリケーションやデータアクセス層のコード内に埋め込まれがちです。しかし、ルールベースのシステムでは、業務ロジックをアプリケーションからシンプルに外出しし、BRMSで一元的に管理できるようになります。

スクラッチとルールベースの違い


3. 上流フェーズで失敗する「最悪のケース」:IT要素の混入


上流工程でのビジネスルール抽出が失敗するケースは多々ありますが、特に危険なのは、ルール担当が必要以上にIT要素を取り込んでしまうケースです。

メインフレーム上のアプリケーションではしばしば見られますが、本来、ビジネスルールはデータやプロセスから分離されているべきものです。


最悪のルール抽出例

以下のようなルール記述は、ITロジックと業務ロジックが混ざり合ってしまっている「最悪のケース」とされています。


“リスクスコア >75 かつ 取引 DB の注文テーブルから該当顧客の注文総額を計算しその値が 100 万円未満で かつ 取引 DB の今回注文番号をキーにして取得した区分が”A”の場合は”適格”と判定し、そうでない場合は不適格と判定する”


この記述には、純粋な業務知識ではない以下のIT要素が混入しています。

  1. データの場所が含まれる(取引 DB の注文テーブル)。
  2. データの取得方法(手順)が含まれる(注文総額を計算し、今回注文番号をキーにして取得)。
  3. ELSE構文が含まれる(そうでない場合は不適格と判定する)。

このような記述は、BRMSで管理すべき純粋な業務知識とは言えません。

レガシーコードには、このように処理と知識が一体化されて記述していることがあるので、そのまま抽出してしまうケースです。


4. 効果的なルール抽出の考え方と役割分担の明確化


そこで、正しいビジネスルール抽出と、IT部門と業務部門の妥当な役割分担を実現することが重要です。

効果的なルール抽出は、業務ロジックとITロジックを明確に分離することで、誰が何をすべきかを明確にします。

したがって、ビジネスルールの上流設計は業務(ビジネス)サイドだけで完遂できるものではなく、IT・技術サイドの協業が不可欠になります。


担当者

役割

担当する要素

ルール担当(業務側)

ルールの内容を洗い出す

ガイドラインや分析モデルなどの知識ソースを基に、何を判断し、その判断基準は何かを明確にする。

IT担当/分析・調査担当

技術的な側面を調査する

データ(注文情報、顧客プロフィール、取引履歴など)の情報の場所、アクセス権限、取得方法などを調査する。

業務とITの要素を分離することで、適切な担当者に作業を割り振ることが可能となり、現実的で精緻なスケジューリングを実現できます。

 

5. BRMSを活用したルールの「見える化」と「高品質化」


抽出されたビジネスルールは、デシジョンテーブルなどの形式でBRMSに登録され、視覚的に確認できるようになります。上流工程でBRMSを活用することには、非常に大きな利点があります。

例)リスクスコアリングルール

ルールの見える化

以下のメリットがあります;

  1. そのまま動作する仕様書そのものとなる:抽出したルールは、絵に描いた餅で終わらず、BRMSに登録されることで、実際のシステム動作の根拠となります。
  2. 早期シミュレーションと高品質化:開発の早い段階でシミュレーションが可能になり、ルールの妥当性を検証し、高品質なルールを開発できます。
  3. 継続的なコミュニケーションプラットフォーム:業務側とIT側が、共通理解に基づいた継続性のあるコミュニケーションを行うための共通基盤を提供します。

6. まとめ


ビジネスルールの抽出と上流設計は、複雑な業務知識を整理し、それをITシステムとして実現するための基盤そのものです。この過程で重要なのは、業務知識(ルール)をIT実装(データ取得や手順)から分離することです。

これは、まるで建物を建てる(システム)前に、設計図を引く作業に似ています。設計図に基づいて、どの部屋(意思決定)に、どんな家具(ルール)を、どこから調達した資材(データ/知識ソース)で配置するかを詳細に決めることで、実際に工事(開発)に入る前に、計画の妥当性や担当者の役割を明確にするとができます。