取り組み方
最近よくモダナイゼーションという言葉を耳にしたり、目にしたりする機会が増えていますが、モダナイゼーションとは一体どんな内容なのでしょうか？
IT用語として解釈すると、古い資産をITの技術を使って改革するという意味合いなのですが、一言でモダナイゼーションといっても、色々なとらえ方、考え方、やり方があります。
それではBA製品を使ったレガシーモダナイゼーションとは、どのような取り組みなのかを具体的に説明します。
モダナイゼーションを分類すると図１のように、一番下から、既存のプラットフォームを差替える「リホスト」、真ん中の、ソースコードを差替える「リライト」、一番上が、アプリケーションのアーキテクチャから見直す「リビルド」になります。
そのいずれもモダナイゼーションという言葉が使われています。リホストやリライトは、リビルドと比べると、リスクは低いのですが、既存のシステム構造に依存してしまうため、必ずしもメンテナンス性が向上するとは言えません。
ただ、この図にあるように、上に行けば行くほど、リスクや対応時間が増えるのも事実です。
BA製品を使ったモダナイゼーションは、どこにあたるかというと、アプリケーションのアーキテクチャから見直す「リビルド」に該当します。
当然「リビルト」を選択すれば、高リスク、長時間というマイナス面もありますが、その反面、実施後の効果は絶大で、大きな改革による大きな利益を得られることになります。
それでは、なぜ多くの企業様はその「リビルド」に取組まなかった、あるいは取組めなかったのでしょうか？
その要因は各企業様で、それぞれ事情は異なりますが、その多くはリスクが大きいと考えてしまうことが原因と考えられます。
レガシーシステムに大手術を行う訳ですから、確かにそのリスクは計り知れません。
当然、ご検討されているお客様の立場にたてば、モダナイゼーションの実施で、本当に現行機能は保障できるのか？ お客様によっては、大きな投資と、長い時間をかけてモダナイゼーションを行う必要があるのか、全くモダナイゼーション後の世界が想像できない。そのよな意見もあると思います。
結局のとろこ行きつく先は、本当にモダナイゼーションはできるのか？ という疑問を払拭できないまま、何年も経過しているお客様は多いのではないでしょうか。
そのような状況で、ずるずる先送りを選択せざるを得なかったのは仕方のないことですが、ここにきていよいよその重い腰を上げるタイミングが迫ってきたと思います。
あるメインフレームメーカーでは2030年にはメインフレームの製造・販売から完全撤退するという発表がありました。このニュースはまさにモダナイゼーションへの意識を加速させているはずです。
そういった背景のなか、BA製品をつかったレガシーモダナイゼーションとはどのようなものなのかをご紹介いたします。
ODMを使ったレガシーモダナイゼーション
BA製品の中のODMという製品は、モダナイゼーションという言葉が使われ始める随分前から、アプリケーションからのビジネスルールを分離しましょうというコンセプトのもと、それを実現するためのルール化の進め方のメソドロジーとして、アジャイル開発をベースとした、段階的にかつサイクリックに進めていく方式を採用してきました。
ビッグバン的な方式ではなく、少しずつ確実にルール化を進めていき、それを拡張していく方式です。
モダナイゼーションの波が加速している今、ODMを使った取り組みというのが、実はモダナイゼーションを成功させる１つのカギとなるのです。
ODMのアプローチ方法を、レガシーモダナイゼーションにも当てはめることで、安全かつ結果的に当初の見積もりの開発期間よりも短い期間で終わらせるとこができると考えています。
さらに、モダナイゼーションすることだけがゴールではなく、モダナイゼーション後の世界では、実行されてルールの分析やＭＬやAIとの連携など、これまでの閉ざされたレガシーシステムでは取組むこと困難とされてきたことにも積極的に取組める環境に代わるということです。
一般的なODMを使ったプロジェクトの開発手法（アジャイル開発）についてご紹介します。（図２）
ルールの抽出、ルールの実装、ルールのテストを１つのサイクルのなかで全て行います。それによって開発の初期段階から実装したルールのメンテナンス性やリスクを見極めることができるため、これまでのウォーターフォール型の開発で頻繁に発生していたプロジェクト後半での手戻りによる前工程からのやり直しのリスクがなくなります。
また、開発の初期段階からビジネスユーザがプロジェクトのメンバーとして参加することで、ITユーザとビジネスユーザが同じルールを見ながら会話を行い、双方の意見の合意をとって進めていくことができます。
メインフームのモダナイゼーション
ODMにはオープン系で使用するエディションと z/OS上で使用するエディションがあります。
Operational Decision Manager for z/OSでは、 オープン系プラットフォームでルール・プロジェクトを作成し、以下のいずれかの環境でこれらのルールを実行することができます。
・zRule Execution Server for z/OS
・CICS JVM サーバー上の zRule Execution Server for z/OS
このルール実行環境では、ルール実行を z/OS アプリケーション (COBOL または PL/I アプリケーション) から zRule Execution Server for z/OSにオフロードします。ここで、ルールは JVM を実行するサーバー上で実行されます。
zRule Execution Server for z/OS は、バッチ・クライアントとトランザクション・クライアントの両方をサポートします。
ホスト内のローン申込審査モジュールを例として、どのように適用できるのかを説明します。
COBOLモジュール内に審査に関するビジネスルールがコーディングされています。この部分をビジネスルールとして抽出します。
（図３）
抽出したビジネスルールを実装し、COBOLモジュールからはCALL文を使ってそのルールを呼出します。
（図４）
ホスト上のローン申込審査アプリケーションは、ルール化の前後で動きは変わりませんが、ルール部分を抽出して外だししたことで、COBOLモジュールを変更することなくビジネスルールの変更が行えるようになります。（図５）
まとめ
ODMでレガシーモダナイゼーションを行って得られるメリットを以下まとめます。
１．これまで膨大な時間やコストを必要とされてきたレガシーシステムのメンテナンス性が向上します。
２．ルールが外部化したことにより、ルールに特化したテストができることでテスト工数の大幅な削減と品質が向上します。
３．これまで作成・修正してきたプログラム仕様書が必要なくなり、仕様書類にかかる時間が削減できます。
４．将来的にAIやMLなどとの連携にも容易に取り組める環境になります。
#OperationalDecisionManager(ODM)#modernization