IT資産の健全性回復、外部システム連携を
レガシーマイグレーションで実現する方法

「とかくCOBOL言語はネガティブにとらえられがちですが、当社はそう考えていません。問題の本質はCOBOL言語そのものではなく、そのメンテナンスが十分行われていないことにあるのです」と東京システムハウス（以下、TSH）の比毛 寛之氏は述べる。

幾度ものシステム改修で環境が複雑化しているほか、技術者や仕様理解者が減ったことで、IT資産の健全性が大きく低下している。マイグレーションプロジェクトを進める上では、この観点を持つことが肝心だという。

TSHは自社開発の代替フレームワーク「AJTOOL」などの製品群を用いた「MMS（Mainframe Migration Service）」を提供している。「お客様ごとの課題に対応できるよう、『①AJTOOL方式(Micro Focus)』『②AJTOOL方式（OSS）』『③ホストエミュレート方式』『④二刀流方式』の4つの方式を用意しています」と比毛氏は紹介する（図1）。

図1　4種類のマイグレーション方式を提供

一口にモダナイゼーションといっても、移行元の環境や抱えている課題は企業によって様々だ。そこで東京システムハウスでは、ユーザーの状況に応じて選べる4種類のマイグレーション方式を提供している

①と②はメインフレームの機能をAJTOOLで代替する方式だ。前者はMicro Focus社のCOBOL製品、後者はGnuCOBOL／opensource COBOLを利用する。③はMicro Focus社のエンタープライズ製品を用いてメインフレームの機能をエミュレートする方式。そして④はopensource COBOL 4Jを用いてJava移行を行う方式である。「コンパイルの過程で中間Javaソースを生成するため、COBOLを使いつつJavaに移行することができます。そのため二刀流方式と呼んでいます」（比毛氏）。

また、実際にプロジェクトを進める際は「早期の移行性検証」「十分なテスト準備」「事前の資産整理」「業務理解者の参画」の4点がカギになる。すべてにおいて重要なのはユーザー企業自身が積極的に関与することだ。それ次第でプロジェクトの結果が変わってくるという。

それでは、これまで同社が支援してきた企業・組織のマイグレーションプロジェクトの例をいくつか紹介しよう。

1つ目はオープン系COBOLからのJavaマイグレーションである。この企業は約15年前から、メインフレームを段階的にオープン系COBOLやパッケージ製品へ移行してきた。しかし、それでもまだCOBOL資産の半分が残っていたという。「そこで今回、UNIXサーバーの老朽化を契機として、Linux／クラウドへ移行することを決断。また、COBOL技術者の引退も見据えてCOBOL to Javaの言語移行も行うことにしました」と比毛氏は話す。

プロジェクトは現在も進行中だが、サーバー老朽化対策に加えて、外部連携を強化できることも効果として期待されている。opensource COBOL 4J の機能を用いてAPIを自動生成することで、COBOLロジックで処理されたデータをクラウド上の外部システムやデータ基盤で活用できるようにするのである。

「また、稼働後のリスキリングや不慣れな障害対応の不安を排除するため、段階的にJavaに切り替える二刀流方式を採用したことも本事例のポイントです」と比毛氏。引き続きCOBOLで運用保守を行いつつ、運用体制の強化を図りながら徐々にJavaへ切り替えていく狙いだ（図2）。

図2　二刀流方式でCOBOLをJavaにリライト

opensource COBOL 4Jは、COBOLをコンパイルする際に中間Javaを生成する。これを利用することで、COBOLを継続しつつ段階的にJavaへ切り替えることが可能だ。REST APIの自動生成も行えるため外部システムとの連携も容易になる

なお、二刀流移行では生成される中間Javaは、いわゆる「JaBOL」になる。当然、時間をかけて解析すればよりきれいなコードを作成できるが、マイグレーションプロジェクトではそのための時間をとれないケースが多い。中間Javaは現状のCOBOL処理を再現しているため、現担当者も理解しやすく保守が可能。使用頻度の高いプログラムは次のフェーズでリファクタリングを行う予定だ。また、中間JavaはCOBOL処理を完全に再現しているため、過去に脱メインフレームを行ったノウハウを生かして移行できる点もメリットだという。

2つ目は、富士通製メインフレームで動く基幹系システムを刷新した事例である。「本件ではホスト機能の移行性検証を早期に行うと同時に、それまで2系統あったシステムを統合して資産を整理しました」（比毛氏）。これにより、IT資産の健全性を回復するとともに、テスト手順も整備してスムーズな移行を実現したという。

富士通製メインフレームのマイグレーションでは、トランザクション管理システム「AIM」の機能代替がポイントになる。本件ではAJTOOLやオープン系ミドルウエアを用いることで、画面の構成や項目などが従来と変わらないようにした。

「また、マイグレーションの品質は照合テストの現新比較に左右されるため、この工程での準備不足は致命的になります。その点今回は、システム統合時のテスト資源を再利用するなどして効率よく対応できました。また、お客様がしっかりプロジェクトに参画いただき、業務理解者とのコミュニケーションが図れたことも本件の成功要因です」と比毛氏は説明する。

そして3つ目は、NEC製メインフレームのCOBOL再活用マイグレーション事例だ。複数組織の収納、保険契約管理、会員管理などを請け負うある企業では、それらの処理を担うシステムをメインフレームで構築して運用してきた。ところが近年はランニングコスト増が課題になっており、数年前からマイグレーションを検討していたという。既にいくつかのシステムを置き換えていたものの、主要3業務がまだNECメインフレーム上に残っている状況だった。

「本件のポイントは、マイグレーションの方式／進め方の検討プロセスにあります。対象となる3システムは、それぞれ改修の頻度や規模、現行仕様の把握状況が異なっていました。そこで、システムごとに合うマイグレーション方式を個別に検討。改修頻度が高く、改修の規模も大きいシステムAはお客様自身がC#とJavaでリビルドし、システムB、Cでは業務ロジックをそのまま利用できるCOBOL再活用を選択しました」と比毛氏は話す。改修頻度が高いシステムは、顧客自身が仕様をある程度把握していたため、この方式が最良と判断したという。

COBOL再活用に当たってはTSHと顧客の役割分担も明確化した。具体的には、COBOL／Sの変換や帳票の移行は顧客が自社ツールや手作業で行い、JCL移行は、AJTOOLの開発元であるTSHが担当する形にしたという。「必要な部分だけを当社にお任せいただくことで、自社保有のツールやリソースを生かして移行コストを抑制できます」と比毛氏は続ける。

これにより、長年の懸案であった脱メインフレームを実現。COBOL技術者がLinux系技術を習得できたほか、バッチ処理を最大75％削減して大幅な性能向上も図れている。

単なる言語の置き換えではなく、IT資産の健全性向上を意識することがレガシーマイグレーションの勘所といえる。TSHの提案を参考に、自社にとってベストなプロジェクトの進め方を検討してもらいたい。