ルール駆動開発を用いて、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年はかかると言われていたからだ。これを元に他の商品にも横展開。顧客からは「ルールが可視化され、約款修正時にどのルールのどこを修正すれば良いかが一目瞭然になった」と満足の声をもらっている。
ルール駆動開発は、先述した要点を押さえれば決して難しいものではない。最後に松田氏は、「ブラックボックス化したレガシーアプリケーションのモダナイゼーションに悩んでいるなら、ぜひルール駆動開発にトライしてほしい。レッドハットに相談いただければ支援いたします」と語り、セッションを締めた。
【レガシーモダナイズを成功させる開発手法】はじめてみよう！ルール駆動開発
レッドハットでは、レガシーモダナイゼーションのプロセスを模したマンガを提供しております。より分かりやすく、ルール駆動開発について知りたい方はこちらをぜひご確認ください。
