デジタルトランスフォーメーションのための超高速開発基盤！　Vol.5

デジタルトランスフォーメーションのための超高速開発基盤！ Vol.5

デジタルトランスフォーメーションを成し遂げることが命題となる中、企業のITにはダイナミックな変革を支える柔軟性とスピード感が求められています。しかし、ビジネスの中核を担う基幹システムが変革を阻む枷となってしまっているケースがあります。従来、基幹システムで最も重視されたのは自社のビジネスを止めないための堅牢性であり、そこに多額の投資が行われてきました。さらにそこには様々な機能が追加され長年使い続けられています。（全5回連載）

Vol.5　レガシーモダナイゼーションのためのビジネスルール分離 ― 変革の時代のための基幹システムの姿とは

基幹システムの全面刷新は茨の道

企業の基幹システムには、顧客データ、会計データをはじめ、様々な企業の資産としてのデータが集約されています。業務にあわせた様々な機能要件がカスタマイズして付け加えられた結果、年月を経て最終的に誰も全貌を把握できないような複雑なシステムになってしまうケースもあります。このような「“超”基幹システム」を抱えて苦労している情報システム部門は非常に多く、デジタルトランスフォーメーションの時代を迎えた今になって、いわば「独自進化」の袋小路で立ち往生しています。

基幹システムと情報系システムの中間が必要

基幹ではないフロント系システム、いわゆる「情報系システム」は、基幹システムからは切り離されています。これらはビジネス戦略の必要性から、データ分析やレポーティングという用途で独自路線を歩んでいます。問題は、業務プロセスとは不可分で、情報系システムに属さない、本来であればビジネス競争優位を出すためのシステム機能です。このような機能は、大抵が多くのビジネスルールを内包しています（※ビジネスルールについては過去の連載記事「BPMを成功させるためのビジネスルール分離」等で解説していますのでご参照ください）。そしてそれらのビジネスルールが基幹システムに組み込まれた時、前述のように変革を阻む枷となってしまいます。これをどうそぎ落とすかが、これからの基幹システム改修の課題になるでしょう。

基幹システムに持たせる機能は本来の目的であるものに絞るべきです。競争力を出すための独自機能（カスタマイズによる機能追加）は、基本的に行うべきではありません。これらはサブシステムとして、基幹周辺に構築します。これで、基幹システムが「独自進化」をとげて行き詰る可能性は大きく低減されます。その際、基幹系と情報系の間をつなぐビジネスルールとデータ連携基盤の構築が重要な鍵となります。AS/400、SAPといった基幹系の場合は、EAIツールが、メインフレームの場合はHULFTなどによるファイル連携が現実的であり実績があります。

レガシーコードからのビジネスルールの切り離し

ビジネスルールのCOBOLコードからの切り離しについては、COBOL文法ベースのパターンマッチングが提唱されたこともありますが、実用化されていません。やはり、ビジネス戦略を担うディシジョンの構造を詳らかにすることが重要です。この連載でも触れている「DMN」を利用することで、本当に切り出すべきビジネスルール＝ディシジョンが明確になるはずです。ちなみにチェックロジックも含めた全てのビジネスロジックを切り出してしまうことを米国の第一人者は「大きなルールのバケツ」と名付け、アンチパターンとしています。先の文法ベースのパターンマッチングもそもそも、システム観点でしか物事をとらえていなかったがゆえ、実用化されなかったのかもしれません。

新しい基幹システムのあり方とは

システムのマイグレーションを行う際、従来利用してきた仕様をそのまま再現しても、それは新しい言語で作られただけの旧システム。海外では「ニューレガシー」などと揶揄されているものです。また、「どうせ刷新するならさらに機能を盛り込もう」という考えももちろん失敗の元です。

今、考えなければならないことは、なるべくビジネスルールを切り離して、基幹システムを身軽にしておくことです。ビジネスルールが分離されていないシステムは、新たに構築したところで再び肥大化し、同じ袋小路への道が待っています。

情報システム部門は業務のスペシャリストではないため、必要な機能を把握しにくく、網羅性ばかりに気を取られてしまいがちです。しかし、業務部門の要望にただ応えているだけでは変革に耐えうるシステムは作れません。これまでの連載で触れた要求マネジメント、超高速開発、ビジネスルール分離などは、いずれもビジネス改革をITで牽引する情報システム部門にとって極めて有効なツールです。これを機に取り入れることを検討してはいかがでしょうか。