アプリケーションモダナイズへの道を容易にする「ルール駆動開発」
レッドハットでルール駆動開発のエバンジェリストとして活躍している松田氏。プログラマとしてIT業界でのキャリアをスタートさせ、経験は20年に及ぶ。
「アプリケーションモダナイズへの関心が高まっている」と松田氏。モダナイズしたい理由としてはさまざまあるが、共通しているのは「柔軟かつ迅速に変更対応が可能なシステムにしたいこと」と松田氏は言う。ビジネスで優位に立つにはアジリティが重要だからだ。そのため多くの企業では、まずインフラをモダナイズすることに取り組んだ。「その上で動くアプリケーションもモダナイズしないと効果が薄いという認知が広がり、今のような関心度につながっている」と松田氏は付け加える。
だが、アプリケーションモダナイズへの道は険しい。迅速に変更可能なシステムにするには、分割するのが得策だが、「密に結合したシステムなので、簡単に分割できない」「中身がブラックボックス化して、手をつけられない」「モダンな技術を取り入れるのが難しい」「密結合した大規模システムをビッグバンアプローチするのはリスクが大きすぎる」などの壁が立ちはだかっているからだ。
松田氏は「これらの悩みの一部をルール駆動開発で解決できるかもしれない」と言い切る。
ルール駆動開発は次の3つの特徴を持つ。1つ目がレガシーアプリケーションをモダンなアプリケーションに変えていく際に、現行システム解析からではなく、現行業務分析から行うこと。2つ目に業務ルール・業務プロセスを疎結合にするアーキテクチャを採用していること。3つ目が業務分析・要件整理は業務側とIT側が協力し、要件整理→実装→テストを繰り返しながら進めるイテレーション開発を採用していることである。
この3つの中で鍵となるのが「現行業務分析からのアプローチ」と松田氏は指摘する。システム刷新の場合、現状の分析や要件整理フェーズを省略して始めるケースが多いが、それだと「アーキテクチャ技術を新しいモノに変えただけに終わってしまう」と松田氏。要件見直しから始めることが重要になってくるのだ。
では、業務分析・要件整理をどう進めていくか「業務のわかる人に聞いたり、業務のわかる資料を読んだりするなど、業務担当者と一緒に進めると良い」と松田氏はアドバイス。それらを元に、業務単位に分割して、整理を進めていくのである。「業務分割はセンシティブに捉える必要はない。ざっくりで良い」と松田氏。詳細を詰めていく中で、ドメインを修正していくことが可能だからだ。それができれば、業務単位でルールとプロセスを整理。プロセスはBPMN、業務ルールはDMN（Decision Model & Notation）やデシジョンテーブルを使って、共通認識を確認しながらモデリングし、整理していく。その際、コツは「業務側の担当者とIT開発者双方が理解できる用語を使い、双方が理解できる形式が書いていくこと」と松田氏。整理ができたところから、あとはプロセスエンジン、ルールエンジンなどのソフトウェアを使って実装していくだけである。
2つ目の特徴である業務ルール・業務プロセスを疎結合にするアーキテクチャとはどのようなものか。「業務単位で整理したプロセスやルールは、それぞれ独立したサービスとして実装し、必要に応じてインターフェースを通じて呼び出す形式にします」と松田氏は説明する。
プロセスやルールはビジネスの変化と共に変わっていく。そこを切り離してそれぞれインターフェースを持つサービスとして疎結合にすることで、システム改修時の影響分析が容易になり、改修スピードを上げることができるようになるからだ。また、プロセス・ルールをマイクロサービスとすることも可能になる。
ルールとデータアクセスを疎結合するのには意味がある。「条件判断をしながらデータアクセスを都度行って処理を実行すると、改修が入るたびに複雑さが増していくから」と松田氏は説明する。条件分岐の部分はデシジョンサービスとして分離して、それを呼び出し、データアクセスはあらかじめ必要なデータを集めてきて、デシジョンサービスを呼び出すときに集めたデータを一括で渡す形にする。こうすることで、デシジョンサービスの中のルールが参照するデータがどのテーブルにあるのか、ルール側は一切関知する必要がなくなる。また、マイグレーション時には、データベースを再設計するケースも多いが、その進捗にかかわらず業務ルール部分の開発を進めることができるようになる。
3つ目の特徴はイテレーション開発であること。イテレーション開発とは、要件整理→設計・実装→テストを繰り返す手法である。まず、必要最低限の機能を実装することから始まる。「最初のイテレーションからテストを行うこと」と松田氏。もちろん最初の段階では実装されていない機能が多いので、NGがたくさん出るが、「テストのOK率が進捗率となる。その結果を次のイテレーションにフィードバックし、品質を向上していく進め方です。このような方法を採用することで、本当に必要なモノだけを実装していくことができます」（松田氏）
しかも、現行システム解析から始めるよりも結果的に短期間でゴールにたどり着くことができる。
【レガシーモダナイズを成功させる開発手法】はじめてみよう！ルール駆動開発
レッドハットでは、レガシーモダナイゼーションのプロセスを模したマンガを提供しております。より分かりやすく、ルール駆動開発について知りたい方はこちらをぜひご確認ください。
ルール駆動開発を用いて、2カ月強でモダナイズに成功
「本当にそんなうまくいくのか」「ソースコードを見ないなんて、考えられない」「簡単なシステムだからできたのでは」と思う人もいるだろう。松田氏は「そんなことはない」と言い切り、ルール駆動開発の事例を紹介した。
松田氏が紹介したのはある金融業の顧客が基幹システムをリプレースした事例である。その顧客は数年前に金融商品の申し込み・契約・更新・請求支払いなどを行うシステムをオープン化し、既存のCOBOL資産をJavaに置き換えた。だが数年の運用で急速に複雑化・肥大化し、保守コストが激増、ビジネスアジリティも低下した。そこでテストを実施すると、「Javaコード数百万行のうち、約4割が使われていなかったコードだった」と松田氏は話す。そしてルール駆動開発でのアプリモダナイズを提案。まずは業務分析・要件整理を実施することになった。
存在していたモノは現行のシステムと、数百万行のJavaコード、最新ではないシステム設計書、To-Beの業務一覧。設計・開発側の状態は、業務内容には詳しくない人たちで構成されており、業務一覧を見ても用語がわからない上、設計書を見たところ、DBのテーブル名、カラム名が前提で、業務の内容が読み取れなかった。「業務有識者に勉強会を依頼し、1～2時間程度話してもらいました」と松田氏。それにより理解が深まり、To-Beの業務一覧が大方理解できるようになった。そして、まずは業務フロー上最初の申し込み受付業務について、ルール駆動開発で開発を開始した。
申し込み業務は各種商品に異なる業務ルールが存在している。その要件詳細をどうやって抽出するかが課題だった。忙しい現場へのヒアリングは難しかったからだ。約款があったので、それを利用することを考えたが、難解な文章のためいきなりのルール抽出が難しく、まずはDMN（Decision Model and Notation：米OMGが標準化しているビジネスの意思決定をモデル化する記法）を利用することにした。意思決定の流れと必要なデータが明確にできるからだ。「DMNはとてもシンプルな記法なので、ITユーザーでなくても習得が可能なところも採用のポイントだった」と松田氏は言う。
進めていくと、商品ごとにDMN上の違いはあまりないことがわかった。そこで代表的な1商品の申し込み受付業務についてDMNで一通りモデリングを整理。それが完了したところで、再び約款の読解作業に戻り、各意思決定の詳細化、デシジョンサービスの実装までを一気に進めた。
「最初の勉強会からここまで約2カ月。ソースコードは見ていません」と松田氏。イテレーションの1回目のテストでは、現行システムでのデータを元に、インプットデータに応じたアウトプットになっているか確認を行った。一致率は75％と、過去の経験からしても「かなり良い結果が得られた」と松田氏は話す。
だがその結果をプロジェクトオーナーに話したところ、「25％も不一致とはひどい品質だ。どう説明するのか」と問われた。そんな中、イテレーション2回目を開始。ゴールは不一致箇所を全て調査し、原因を明らかにすることにした。不一致原因調査はスムーズに進んで修正はあっという間に完了し、2週間で一致率が99％になった。残る不一致については該当ソースコードを見に行く必要があると判断し、イテレーション3回目を開始した。
「2カ月強で100％まで持って行くことができました」と松田氏は満足そうに語る。というのも、既存のやり方では1年はかかると言われていたからだ。これを元に他の商品にも横展開。顧客からは「ルールが可視化され、約款修正時にどのルールのどこを修正すれば良いかが一目瞭然になった」と満足の声をもらっている。
ルール駆動開発は、先述した要点を押さえれば決して難しいものではない。最後に松田氏は、「ブラックボックス化したレガシーアプリケーションのモダナイゼーションに悩んでいるなら、ぜひルール駆動開発にトライしてほしい。レッドハットに相談いただければ支援いたします」と語り、セッションを締めた。
【レガシーモダナイズを成功させる開発手法】はじめてみよう！ルール駆動開発
レッドハットでは、レガシーモダナイゼーションのプロセスを模したマンガを提供しております。より分かりやすく、ルール駆動開発について知りたい方はこちらをぜひご確認ください。
