レガシーアプリケーションのモダナイズを高速に実施できる「ルール駆動開発」とは【デブサミ2021】

【18-E-8】“ルール駆動開発”でレガシーアプリケーションのモダナイズを高速に実施できた話

　アプリケーションモダナイズへの関心が高まっている。その背景にあるのが、ビジネスのアジリティを高めるためには、柔軟かつ迅速に変更対応できるシステムにしたいという考えがあるからだ。だが「システムがブラックボックス化している」「設計書が残っていない」など、モノシリックなシステムをモダナイズするのは容易なことではない。そんなレガシーシステムが抱える課題も「ルール駆動開発」であれば、短期間で解決できる可能性がある。レッドハット Senior Solution Architectの松田絵里奈氏がブラックボックス化したモノシリックなシステムを、柔軟かつ迅速に変更可能なシステムに短期間で変えるルール駆動開発手法の詳細を解説した。

レッドハット株式会社 Senior Solution Architect 松田絵里奈氏

• 講演資料：“ルール駆動開発”でレガシーアプリケーションのモダナイズを高速に実施できた話

アプリケーションモダナイズへの道を容易にする「ルール駆動開発」

　レッドハットでルール駆動開発のエバンジェリストとして活躍している松田氏。プログラマとしてIT業界でのキャリアをスタートさせ、経験は20年に及ぶ。

　「アプリケーションモダナイズへの関心が高まっている」と松田氏。モダナイズしたい理由としてはさまざまあるが、共通しているのは「柔軟かつ迅速に変更対応が可能なシステムにしたいこと」と松田氏は言う。ビジネスで優位に立つにはアジリティが重要だからだ。そのため多くの企業では、まずインフラをモダナイズすることに取り組んだ。「その上で動くアプリケーションもモダナイズしないと効果が薄いという認知が広がり、今のような関心度につながっている」と松田氏は付け加える。

　だが、アプリケーションモダナイズへの道は険しい。迅速に変更可能なシステムにするには、分割するのが得策だが、「密に結合したシステムなので、簡単に分割できない」「中身がブラックボックス化して、手をつけられない」「モダンな技術を取り入れるのが難しい」「密結合した大規模システムをビッグバンアプローチするのはリスクが大きすぎる」などの壁が立ちはだかっているからだ。

　松田氏は「これらの悩みの一部をルール駆動開発で解決できるかもしれない」と言い切る。

　ルール駆動開発は次の3つの特徴を持つ。1つ目がレガシーアプリケーションをモダンなアプリケーションに変えていく際に、現行システム解析からではなく、現行業務分析から行うこと。2つ目に業務ルール・業務プロセスを疎結合にするアーキテクチャを採用していること。3つ目が業務分析・要件整理は業務側とIT側が協力し、要件整理→実装→テストを繰り返しながら進めるイテレーション開発を採用していることである。

　この3つの中で鍵となるのが「現行業務分析からのアプローチ」と松田氏は指摘する。システム刷新の場合、現状の分析や要件整理フェーズを省略して始めるケースが多いが、それだと「アーキテクチャ技術を新しいモノに変えただけに終わってしまう」と松田氏。要件見直しから始めることが重要になってくるのだ。

　では、業務分析・要件整理をどう進めていくか「業務のわかる人に聞いたり、業務のわかる資料を読んだりするなど、業務担当者と一緒に進めると良い」と松田氏はアドバイス。それらを元に、業務単位に分割して、整理を進めていくのである。「業務分割はセンシティブに捉える必要はない。ざっくりで良い」と松田氏。詳細を詰めていく中で、ドメインを修正していくことが可能だからだ。それができれば、業務単位でルールとプロセスを整理。プロセスはBPMN、業務ルールはDMN（Decision Model & Notation）やデシジョンテーブルを使って、共通認識を確認しながらモデリングし、整理していく。その際、コツは「業務側の担当者とIT開発者双方が理解できる用語を使い、双方が理解できる形式が書いていくこと」と松田氏。整理ができたところから、あとはプロセスエンジン、ルールエンジンなどのソフトウェアを使って実装していくだけである。

　2つ目の特徴である業務ルール・業務プロセスを疎結合にするアーキテクチャとはどのようなものか。「業務単位で整理したプロセスやルールは、それぞれ独立したサービスとして実装し、必要に応じてインターフェースを通じて呼び出す形式にします」と松田氏は説明する。

　プロセスやルールはビジネスの変化と共に変わっていく。そこを切り離してそれぞれインターフェースを持つサービスとして疎結合にすることで、システム改修時の影響分析が容易になり、改修スピードを上げることができるようになるからだ。また、プロセス・ルールをマイクロサービスとすることも可能になる。

　ルールとデータアクセスを疎結合するのには意味がある。「条件判断をしながらデータアクセスを都度行って処理を実行すると、改修が入るたびに複雑さが増していくから」と松田氏は説明する。条件分岐の部分はデシジョンサービスとして分離して、それを呼び出し、データアクセスはあらかじめ必要なデータを集めてきて、デシジョンサービスを呼び出すときに集めたデータを一括で渡す形にする。こうすることで、デシジョンサービスの中のルールが参照するデータがどのテーブルにあるのか、ルール側は一切関知する必要がなくなる。また、マイグレーション時には、データベースを再設計するケースも多いが、その進捗にかかわらず業務ルール部分の開発を進めることができるようになる。

　3つ目の特徴はイテレーション開発であること。イテレーション開発とは、要件整理→設計・実装→テストを繰り返す手法である。まず、必要最低限の機能を実装することから始まる。「最初のイテレーションからテストを行うこと」と松田氏。もちろん最初の段階では実装されていない機能が多いので、NGがたくさん出るが、「テストのOK率が進捗率となる。その結果を次のイテレーションにフィードバックし、品質を向上していく進め方です。このような方法を採用することで、本当に必要なモノだけを実装していくことができます」（松田氏）

　しかも、現行システム解析から始めるよりも結果的に短期間でゴールにたどり着くことができる。

「現行業務分析」からのアプローチ

業務分析・要件整理は業務担当者と一緒に進める

ルールとデータアクセスを疎結合にする意味

【レガシーモダナイズを成功させる開発手法】はじめてみよう！ルール駆動開発

　レッドハットでは、レガシーモダナイゼーションのプロセスを模したマンガを提供しております。より分かりやすく、ルール駆動開発について知りたい方はこちらをぜひご確認ください。