リライトマイグレーションにおけるデータ変換の重要性
皆様、こんにちは。
TIS株式会社で、モダナイゼーションサービスのテクニカル担当の津田と申します。
本日は、リライトマイグレーションにおける業務データの変換の重要性についてご紹介したいと思います。
マイグレーション手法のひとつである「リライト」では、弊社サービス「Xenlon~神龍Migrator」などのマイグレーションツールを活用することで、レガシーなプログラム資産(COBOL、PL/Iなど)をJavaプログラムへ自動変換し、安全かつ迅速なレガシーマイグレーションを実現できます。しかし、メインフレーム上で稼働するプログラム資産だけをオープン系システムへ移行するだけでは、レガシーマイグレーションは完了しません。メインフレームに格納されているファイルやDBデータなどのレガシーな業務データも変換し、オープン系システムへ移行しなければ、システム全体が正しく稼働しないためです。
レガシーな業務データの変換は、プログラム資産の変換と同じくらい、リライトマイグレーションにおいて重要なプロセスです。しかし、マイグレーションの検討・計画フェーズでは、プログラム資産の自動変換率や保守性には注目が集まる一方で、業務データの変換については十分に重視されていないように感じられます。
そこで今回は、リライトマイグレーションにおけるデータ変換の重要性と、その難しさについてご紹介します。
データ変換の重要性について
レガシーな業務データの変換は、レガシーマイグレーションの本番切り替え時に実施するデータ移行だけでなく、テストフェーズにおいても非常に重要な役割を果たします。これは、レガシーマイグレーションにおけるテストで、現行システムと新システムの処理結果を比較する「現新比較」という手法が採用されるためです。
現新比較テストでは、テストの入力値や期待値として使用するデータを、現行システム(メインフレーム)から取得し、新システム(オープン系システム)向けに適切にデータ変換する必要があります。もしこのデータ変換の品質が不十分であれば、新システムのアプリケーションが正しく動作しないだけでなく、現行システムとの処理結果の比較も正確に行うことができません。すなわち、現新比較テスト自体が成立しなくなってしまいます。
このように、データ変換の品質は、そのままアプリケーションの品質向上に直結すると言えます。
しかし、レガシーな業務データの変換は難易度が高いため、テストフェーズまでに十分な品質を確保できない場合もあります。その結果、アプリケーションの品質向上の取り組みにも影響を及ぼしてしまう可能性があります。
レガシーな業務データの変換の難しさについて
ではなぜ、レガシーな業務データの変換は難しいのでしょうか。それは、メインフレームが扱うデータの考え方や仕様が、オープン系システムとは大きく異なるためです。
メインフレーム上の業務データには、その特有のデータ仕様や設計思想が存在します。データ変換を行う際には、変換対象となるデータ定義を正確に理解し、その仕様に合わせて変換を進める必要があります。しかし、これらのデータ仕様はオープン系システムのエンジニアにとって馴染みが薄いため、変換作業の難易度が高まる要因となっています。
それでは、メインフレーム特有のデータ仕様について、具体的な例を3点ご紹介します。
1.メインフレーム特有の文字コード
メインフレームでは、EBCDIC(Extended Binary Coded Decimal Interchange Code)という文字コードが利用されていることが多いです。EBCDICは、オープン系システムで一般的に使われているASCIIやUTF-8とは異なるため、通常のエディタで開いても文字化けしてしまい、内容を正しく読むことができません。また、EBCDICを利用したメインフレーム上のプログラムでは、LOW-VALUE(0x00)、HIGH-VALUE(0xFF)、シフトアウト(Shift-Out: 0x0E)やシフトイン(Shift-In: 0x0F)など、オープン系システムではあまり馴染みのない制御文字や特有の値が使用されることがあります。
このようなメインフレーム特有の文字コードや表現は、オープン系システムのエンジニアにとっては不慣れである場合が多く、理解や対応に時間を要することがあります。
2.メインフレーム特有のデータ型
メインフレームでは、オープン系システムには馴染みが少ないデータ型が存在します。代表的な例として「パック形式」(パック10進数、Packed Decimal、またはCOMP-3と呼ばれることもあります)という、ビット単位で数字を表現する数値型があります。例えば、0x12 0x13は「123」を示します。
また、パック形式では符号(プラス・マイナス)を数値の最終バイトの下位4ビット(ニブル)で表現します。たとえば、0xF1 0xC2は「+12」、0xF1 0xD2は「-12」を表します(ここで、CやDは符号を表す値です)。
このようなビットやニブル単位で数値や符号を表現する考え方は、EBCDICと同様に、オープン系システムのエンジニアにとっては不慣れな場合が多いです。
3.メインフレーム特有のデータ構造
メインフレームでは、「集団項目」(COBOLでは「グループ項目」とも呼ばれます)というデータ構造があります。これは、複数の単独項目(要素)をまとめてグルーピングした構造であり、プログラム上では個々の単独項目だけでなく、集団項目全体をまとめて操作することも可能です。
また、「マルチレイアウト」と呼ばれるデータ構造もあります。これは、同一のデータ領域に対して複数のレイアウト(異なるデータ構造)を定義し、状況に応じて使い分けるというものです。たとえば、ファイルの種類やレコードの種別によって、同じ領域を異なる構造として解釈することができます。
このようなデータ構造が存在する背景には、COBOLなどのレガシーなプログラム言語がデータ領域を物理的なメモリ空間に直接確保し、その領域を柔軟に操作できるという特徴があります。そのため、データ領域全体(集団項目)を一括して処理したり、プログラムで定義した個々の項目を個別に操作したりすることが可能です。
このような考え方やデータ構造は、オープン系システムで一般的に使われるJavaなどのプログラミング言語にはほとんど見られない特徴です。
レガシーな業務データの変換を成功させるために
これらの技術的な難易度の高さに加え、レガシーマイグレーションにおいては、現行システムであるメインフレームがブラックボックス化しているため、移行対象となるデータの特定自体が困難になるケースがあります。また、現行システムが基幹系かつ大規模なシステムである場合、移行対象となるデータの種類や数が多く、データ容量も膨大になることがしばしばあります。こうした要因が技術的な課題と重なり合うことで、レガシーマイグレーションにおけるデータ変換の難易度はさらに高まります。
では、こうした問題を解決するには何が必要なのでしょうか。
「Xenlon~神龍 モダナイゼーションサービス」では、これまでの豊富なデータ変換のノウハウや経験をもとに、こうした課題を乗り越えてきました。
本日は、レガシーな業務データの変換を成功させるために重要なポイントを3つ、ご紹介します。
1.レガシーなデータの仕様を網羅した変換
先ほどご紹介したメインフレーム特有の文字コード、データ型、データ構造など、あらゆるレガシーデータの仕様に対応したデータ変換ができることが重要です。また、可能な限り少ない製品やソリューションで、すべてのデータの変換を完結できることも大切です。なぜなら、複数の製品やソリューションを組み合わせると、データ変換の作業プロセスが非常に煩雑になってしまうためです。
リライトマイグレーションでは、現新比較を用いたテストのために、データ変換を繰り返し実施する必要があります。そのため、データ変換の作業プロセスは、できる限りシンプルに保つことが不可欠です。
2.変換の処理性能
レガシーマイグレーションの対象となるシステムは、基幹系システムであることが多く、システム移行時の停止時間をできるだけ短縮することが求められます。また、基幹システムであるため、移行対象となるデータのサイズも非常に大きくなる場合が多いです。そのため、データ変換の処理性能は非常に重要な要素となります。
さらに、繰り返しになりますが、リライトマイグレーションではテストフェーズにおいてデータ変換作業を頻繁に実施する必要があります。したがって、データ変換の処理性能はテスト作業の生産性にも大きく影響します。
このように、データ変換の処理性能を追求することは、レガシーマイグレーションを成功させる上で不可欠です。
3.変換ツールの自動生成
データ変換を行う際には、変換対象データの定義を正確に把握し、その仕様に応じたデータ変換が求められます。そのため、各業務データのデータ定義ごとに、データ変換用スクリプトを用意する必要があります。しかし、レガシーマイグレーションの対象は大規模システムであることが多く、移行対象となる業務データの数も多くなりがちです。
もしデータ変換用スクリプトの作成が自動化できなければ、人手による作業となり、膨大な工数が発生します。したがって、データ変換用スクリプトの自動生成を実現し、開発生産性を高めることが不可欠です。
「Xenlon~神龍 モダナイゼーションサービス」製品ラインナップ
「Xenlon~神龍 モダナイゼーションサービス」シリーズはTIS独自のリライト手法によるマイグレーションを中心としたモダナイゼーションサービスで企業のDX推進をご支援します。
アセスメントサービス | リライトによるモダナイゼーションを検討中の企業様に対して「Xenlon~神龍 モダナイゼーションサービス」を活用したプロジェクト推進の『実現性』と『実効性』を検討します。 さらに、ご希望のお客様に対しては情報システム化戦略やエンハンス革新戦略・DX戦略の評価・診断をご支援します。 |
---|---|
マイグレーションサービス | TIS独自のリライト技術「Xenlon~神龍 Migrator」を活用して、レガシーな言語(COBOL、PL/Ⅰなど)からJavaへのリライトを実現し、オープン環境へ移行します。業務ロジックの100%を自動変換するとともに、メインフレームと同等以上の処理性能を実現します。 |
エンハンス革新・DX推進サービス | マイグレーション後の早期エンハンス革新やDXの実現に向け、各種戦略やマイグレーションプロジェクトからの情報をインプットにしてエンハンス革新計画・DX計画を立案。 PoCを実現しながら実現性を検証するとともに、必要に応じて、マイグレーションプロジェクトにフィードバックすることで早期にエンハンス革新・DX実現に向け推進します。 |
エンハンス革新・DX実践サービス | システムの正常稼働を保つためのメンテナンスをはじめ、オープンシステムの手法を有効活用した安全なリファクタリングやエンハンスメント革新の実践によるシステム効率を支援します。またマイグレーション後のシステムをベースとして、データ利活用や先端技術活用などDX実践を支援します。 |