DXを推進するため「脱メインフレーム」を実現したい。このように考えている企業は多いはずだ。実際にこれを支援するソリューションも、すでに欧米ベンダーを中心に数多く存在する。

　「しかしこれらを使った国内の成功事例はあまり聞いたことがありません。その理由は大きく3つあります」と説明するのは、日本ティーマックスソフトの羅 鍾弼（ラ ジョンピル）氏だ。同氏は日本／海外でのメインフレームマイグレーション・モダナイゼーションに20年以上従事し、50件近くの脱メインフレームプロジェクトにＰＭや責任者としてかかわってきた。

　1点目は「アジア圏特有の文字コードの存在」である。欧米のメインフレームにはダブルバイトの文字コードがないため、この対応がそもそも難しい。

　2点目は、日本特有の「マルチベンダー文化」だ。日本ではメインフレームを導入する際に、IBMと富士通、IBMと日立といったように、複数ベンダーの製品を採用するケースが多かった。このため複数のベンダーのメインフレームを理解する必要がでてくるわけだ。

　そして3つ目が「作り込み文化」である。日本企業では自社固有の機能をアセンブラなどで作り込むケースが多い。このようなソフトウエア資産の存在も、脱メインフレームのハードルを上げているのである。

　これらの壁を乗り越えていくには、アジア特有の文字文化を理解しマルチベンダーにも対応できるソリューションと、作り込みにも対応できる開発力のあるパートナーが不可欠だ。こうしたニーズに対応できるのが、日本ティーマックスソフトだと羅氏は述べる。

　「当社は1997年に韓国で設立され、オンラインのトランザクション処理を行うTPモニター『Tmax』の提供から事業をスタートしました。その後、WASなどのミドルウエアやデータベース、フレームワークソフトウエアを中心に製品ラインアップを拡充、韓国ミドルウエア市場の4割超のシェアを獲得し、韓国の5大メガバンクを含む4,500社を超える顧客に導入されています。韓国では2005年頃から脱メインフレームへの取り組みが始まっており、すでに弊社のソリューションで20年近く安定稼働しているシステムも存在します」（羅氏）

　このような実績や能力が評価され、米国の調査会社であるISGは4年連続で、同社をモダナイゼーションソリューションベンダーのリーダーとして位置づけている。

　それでは具体的に、同社ではどのようなモダナイゼーション方法を提供しているのか。それは大きく2種類ある。

アプリケーション資産をそのまま移行する「リホスト/リプラットフォーム」と、モダンな言語で書き換える「リライト／リファクター」の2種類を用意している。言語の変換ツールだけではなく、それらを動かすインフラ系ソリューションを提供していることも、大きな特徴だといえる

　1つは「リホスト/リプラットフォーム」だ。これはメインフレームやオープン系COBOL上の資産を、そのままオンプレミスやクラウドのLinuxへと移行するもの。これを可能にするのが同社の「OpenFrame7」である。

　「まずインフラは、メインフレームからパブリッククラウドやオンプレミスで稼働するLinuxへと移行し、その上で動くミドルウエアはメインフレームのミドルウエアと同等機能を提供するOpenFrame Online／Batchを利用することで、メインフレームと同等の安全性を実現します。データベースは、OpenFrameにインタフェースをもち、メインフレームでのデータアクセスロジックを担保します。ただし、ファイルや階層型データベース、ネットワーク型データベースをRDB化するため、他システムとのシームレスな連携を可能にします。

　COBOLやPL/I、アセンブラなどで記述されたアプリケーション資産は、文字コード変換のみでそのまま継承。そしてUIはOpenFrame Webエミュレータによって、メインフレームのMAP定義をブラウザ画面に展開できます」（羅氏）。

　もう１つは「リライト／リファクター」だ。これはCOBOLコードなどをオープン系のJavaなどへ書き換える方法であり、同社の「OpenFrame21」で実現する。

　「OpenFrame21は、Spring BootやSpring Batchといったオープンソースをベースにした、MVCアーキテクチャを採用しています。OpenFrame Refactorというツールを使用することで、MAPはJavaScript、COBOLはJava、JCLはXMLへとモダナイズし、これらをSpring Boot／Spring Batchベースの環境で運用できるようにするわけです」と羅氏は説明する。

　メインフレームのモダナイズというと、後者の「リライト／リファクターリアーキテクチャ」を思い浮かべる読者も多いかもしれないが、これをいきなり行うのはリスクが高いと羅氏は指摘する。

　そのためまずは「リホスト・リプラットフォーム」を行い、リホスト後の環境で発生した問題を全て解決した上で、リライト／リファクターへと進んでいくことを推奨しているという。これによって、リライト／リファクターの段階で問題が発生しても、その原因究明の範囲を限定でき、解決が容易になるのである。

　リホスト・リプラットフォームのプロジェクトワークフローは図２の示すとおりだ。

事前に約3カ月のPoCを行い、正式提案からは12～14カ月でプロジェクトが完了するケースが一般的だという

　まず顧客やパートナーとNDA（秘密保持契約）を結び、ヒアリングシートでシステムの現状を調査。その上でティーマックスソフトからPoCの提案を行う。提案が採用された場合には有料PoCによって、顧客の資産取得・分析・移行性検証・動作検証を行い、正式提案へ。これが承認されれば、約2カ月で要件定義・設計、約2カ月で開発・移行、約6カ月で現新比較テスト、2～4カ月で結合／総合／受け入れテストを行い、システム切り替えを実施する。正式提案からの期間は12～14カ月が一般的だという。

　実際に、OpenFrame7でリホストを行う日本企業の事例も増えている。

　自動車部品メーカーはその一例だ。短期間で安心・安全・低コストでの移行する実現するためにリホストを選択し、次世代システムの将来像につながるシステムにすることを目指しOpenFrame7を採用。約17カ月で移行を完了し、約50％のコスト削減、拡張性や柔軟性の向上、次世代システムに向けた準備などが実現できた。

　金融機関の事例も多い。FWD生命保険では富士通メインフレームからのリホストにOpenFrame7を採用。極めて大規模なシステムだったがリホストされ、70％のコスト削減、スケーラビリティと柔軟性の向上、さらなるDXの実現などの効果がもたらされているという。

　2025年問題はすでに現実のものとなっており、今後もメインフレーム技術者の引退が続くことが予想される。そのため、早急に対応を開始する必要がある。対応のポイントとして、第3に最適なソリューションを選定すること、そして第4に開発力を備えた信頼できるパートナーと協業することも挙げられる。

　脱メインフレームに課題を抱えているなら、まずは気軽に相談して見てはいかがだろうか。