レガシーシステムの
モダナイゼーションを効率的に進める

業務ルール抽出手法

Vol.009 2022年8月17日

経済産業省が発表した『DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~』では、DXの阻害要因としてレガシーシステムの存在が指摘されています。

いざ、レガシーシステムのモダナイゼーションを検討すると、膨大なプログラム資産やドキュメントに圧倒され、なかなか進まないことが多々あります。その結果、現状をそのままに実装言語だけを変更するような一時しのぎをせざる得ないケースも聞かれます。しかし、これではDXを支える柔軟なシステムを実現できません。

弊社は柔軟性の高いシステムを実現する方法として、システムから業務ルールを分離しルールエンジン上で管理する方法を推奨しています。
今回は、弊社事例を参考にレガシーシステムからルールを抽出し、ルールエンジン適用により柔軟かつコンパクトなシステムを実現する方法を紹介します。

はじめにルールエンジン適用を検討すべきレガシーシステムの特徴をまとめます。

  • 法令やサービスの要件変更に伴うシステム改修の頻度が高い
  • システムエンジニアに業務担当者と同程度の業務理解が必要
  • システム改修期間が年々長期化している

このようなシステムにルールエンジンを適応する効果には次のようなものがあります。

  • 開発工数(主にコーディング工数)の削減
  • 業務要件変更時の対応工数削減
  • エンドユーザによるシステム保守

それでは、ルールエンジン適用の進め方を説明しましょう。
レガシーシステムから業務ルールを抽出(分離)する際の観点は次の2点です。

  • IF-THEN等による条件記述が複雑化している箇所(うち業務要件に基づくもの)
  • 仕様変更が多数発生している箇所

上記の観点に基づき(1)ソースコード分析(2)基本設計書分析を行い、業務ルールを抽出するための(3)ルール性評価を行います。

1.ソースコード分析

ソースコードを読み、プログラムブロック毎に以下3つを計測する簡易プログラムを作成し、データ収集します。

(a)
条件分岐のなかに記述されたコードのステップ数
(b)
条件分岐のネストの深さ
(c)
コード修正の回数

2.基本設計書分析

基本設計書を読み、上記(1)ソースコード分析のプログラムブロックに修正回数を数えます。
ここは手作業です。

(d)設計書の修正回数

3.ルール性評価

上記(1)(2)の分析結果を一覧表にまとめて(d)から(a)の順にソート(降順)します。この一覧表の上位にあるプログラムブロックを業務ルールとして抽出する対象(=ルールエンジンで管理する対象)とします。実際の作業では上記(a)~(d)に下限値を設け、それに満たないものを対象外とすることで、抽出対象を適当な量に抑えます。

抽出したプログラムブロックは、基本設計書の対応箇所との照合や有識者からのヒアリングを行い業務要件を再整理し、最終的に判断条件を表形式で記述します。
※弊社は、この表を直接ルールエンジンに取り込めるように設計します。

抽出したプログラムブロックは、基本設計書の対応箇所との照合や有識者からのヒアリングを行い業務要件を再整理し、最終的に判断条件を表形式で記述します。
弊社は、この表を直接ルールエンジンに取り込めるように設計します。

今回は、レガシーシステムのプログラム資産と基本設計書にもとづき業務ルールを抽出する方法を説明しました。このシンプルな手法は、複雑化したシステムの分析の効率化に大変有効です。実際に実施される際には、幾つかポイントがありますので、弊社にご相談いただければと思います。