メインフレームのオープン化でETLツールを活用する

今回は、メインフレームをオープン化する際に言語への移行のみではなく、最近オープン環境で活用されているETLツール（ASTERIA（アステリア社）、DataSpider（セゾン情報システムズ社）、他）の活用について書いていきたいと思います。

メインフレームでの開発は、COBOL言語の開発が主流となっています。オープン化する上で安価で、低リスクな移行方法として、同じオープン系のCOBOL言語への移行を推進しております。

今後も移行期間や、移行後の人材活用を含め非常に有益な手段であることは間違いありません。我々はこれまで、マイグレーション（移行）では、この方法を推進してきました。そして、これからも、この方法で推進していきます。

但し、このような言語変換が伴わないマイグレーションでも動作環境の差異や文字コードの差異により、マイグレーションの経験がないとプロジェクトの失敗に陥りますので注意が必要です。

一方で、COBOL言語の経験者が高齢化し、現在はJAVA言語での開発が主流となっています。そのため、COBOL言語の要員確保が困難となってきています。

そして、単純にCOBOL言語をJAVA言語に変換して行うマイグレーションをすると、本来のJAVAではなく、COBOLのようなJAVAとなってしまいます。

さらに、単純なJAVA言語への変換では、DBアクセスなどで性能問題などが発生し、改修なども必須となります。
そして、移行後のJAVAソースについても純粋なJAVA開発要員での保守は困難を極めます。

そのため、我々は、現行資産を可視化し、純粋なJAVAで再構築するものと、冒頭でも書きましたがETLツール（ASTERIA、DataSpiderなど）を活用してマイグレーション（移行）を行う提案をしています。 ETLツールとは、データを抽出・収集（Extract）し、用途に応じて変換・加工（Transform）したうえで、その先にある格納先に有用な情報として配信・送出（Load）してくれる、ノーコードによる開発ツールとなります。

オープン化で再構築時のポイント（資産の棚卸）

メインフレームのJCLやCOBOLを再構築する前に、まずは移行対象となる資産の棚卸作業を行います。棚卸のポイントは次の通りです。

1. 現在の資産を明確にします。
2. 現在の資産の中で、重複している資産や、不足している資産を明確にします。
3. メインフレームで使用しているユーティリティを明確にします。
4. １~３をもとに対象資産を確定します。（不要な資産まで移行しない）

まず、最初に行うこととして、現在の資産を整理し、対象の資産を確定させることが大切です。

その際に、重複している資産の取捨選択や、不足資産の調査を行います。また、メインフレームでのユーティリティも調査し、オープン化する際の代替案を決定します。対象資産が確定したら、次は、資産の可視化を行います。

対象資産の可視化

対象の資産が決まったら、可視化を行います。可視化を行う内容としては、最低限、入出力インターフェース情報を明確にすることです。また、出力インターフェース情報には、抽出条件や編集内容を明確にします。

バッチ処理については、JCLからジョブフローを作成します。このように可視化した情報をもとに、JAVA言語での開発を行うのか、ETLツールを活用して開発するのかを画面単位、ジョブ単位で決定していきます。弊社では、効率を上げるため、一部、可視化ツールを使用して行っております。

JAVA言語での開発、ETLツールでの開発の決め方

開発効率を上げるため、また、保守効率を上げるためには、出来るだけETLツールでの開発を主流に開発を推進していきます。どうしてもETLツールでの開発が困難と思われるものや、ETLツールが不得意なものについては、JAVA言語で開発するといった対応が良いと思います。

ETLツールも各社色々提供していますので、導入する際には、開発する内容をもとに検討してETLツールを選択するのが良いと思います。ETLツールでは、大量データの突合せ処理など苦手としているものもありますので、ETLツールの特性を把握し、ETLツールの選択し開発を行ってください。

まとめ

メインフレームをオープン化する上で、移行先言語を変更する場合（例：COBOLをJAVAに変更）は、以下の3パターンが考えられるかと思います。

　パターン１．JAVAなどオープン環境で主流の言語で再構築する
　パターン２．変換ツールでCOBOLを、JAVAなどオープン環境で主流となっている言語へ変換する
　パターン３．ノーコードでユーザーでも保守可能なETLツール（ASTERIA、DataSpiderなど）で再構築する

パターン１は、現行資産から仕様を作成し、新たな言語での再構築が必要となります。この場合、費用や時間などをかけて長期的な対応が必要です。また、開発、保守要員も今までのスキルとは異なりますので、注意してください。

パターン２は、言語変換を行うため、COBOLチックなソースになりますので、本来の言語とは、見た目も考え方も異なるので、注意が必要です。言語変換した保守スキルと、新たな言語での開発スキルの両方が必要となりますが、費用や時間などは一番安価にオープン化を実現できます。

パターン３は、パターン１と同じく現行資産から仕様を作成し、ノーコードでユーザーでも保守可能なETLツール（ASTERIA、DataSpiderなど）で再構築することになります。

簡単な修正などはユーザーでも可能となり、開発、保守の中では一番、ハードルが低いかもしれませんが、ETLツールを使用するためベンダーロックとなってしまうことや、複雑なプログラムについては、やはり言語での再構築が必要となります。

それぞれの特長がありますので、何を重視してオープン化するかをはっきりさせて上でオープン化の方針を決めていくことが大事かと思います。

以下に弊社で評価した結果をまとめてみました。検討した結果を参考にして頂ければ幸いです。また、続編として次回は、実際にETLツールを活用した事例を掲載する予定です。