メインフレーム移行（マイグレーション）の良くある問題

はじめに

企業の基幹システムには、今でも多くのメインフレーム（汎用機・ホストコンピュータ）が残っています。しかし、10数年前に、当時「ダウンサイジング」と呼ばれた、オープン系のシステムに移行していた時とは少し状況が変わりました。そこで、今回は、最近のメインフレームマイグレーションで起こりがちな問題について取り上げてみます。

他システムとの連携

現在でも、移行されることなく稼働しているメインフレームは大半が企業の基幹システムです。一方でその周辺のシステムの多くは既にオープン化されています。

このためメインフレームでは必ずと言ってよいほど、ファイル転送（FTPなど）を使用して周辺システム、関連システム、取引先システムとのデータ連携を行っています。ところが、システム担当の方がその全貌を把握されているケースは少ないのが現状です。

例えばFTPでファイル転送の際、メインフレーム自身が契機となって実行している場合は、マイグレーションのプログラムソース分析の過程でデータの送受信先等を調査することが可能です。

しかしメインフレームがFTPサーバとして機能している場合は、接続元のクライアント側にしかパラメタ等の情報が存在しないため、いくらソースを調査してもどのようなファイルをどう転送しているのかが分かりません。

　ホスト(FTPクライアント) ⇔ 他サーバ(FTPサーバ)
　※これはメインフレーム側にFTPパラメタがあるので調査可能。

　ホスト(FTPサーバ) ⇔ 他サーバ(FTPクライアント)
　※これはメインフレーム側にFTPパラメタが無いので詳細がわからない。

結局、現行システムの出力結果と移行後の新システムの出力結果を比較するテスト（以降、現新比較テスト）までひと通り終えてみないことには、ファイル転送の全貌がよくわからない、ということが起こりえます。

現新比較テストのテスト方法によっては、一部の外部連携のルートに本番直前まで気付かないこともありえます。テストデータの準備において連携された後のホスト上に残っているデータを取得してテストを進めていた場合に起こります。このテスト方法では、FTPされたかどうかはテストの実施に関係がないため、現新比較テストでは外部連携の処理に問題があるかどうか判断できませんし、そもそもFTPされているのかどうかもわかりません。

マイグレーションプロジェクトには、調査・分析を行う工程があり、そこで全てを把握することが理想ではありますが、漏れのないように現新比較テストを実施できるように、テスト方法を検討、テストシナリオを作成することも、移行精度の高いマイグレーションを行うためには重要です。

調査工程では基本的にプログラムソースを解析します。このタイミングで可能な限り外部連携の実態を明らかにするため、ソースだけではなくFTPサーバにあるログを取得して分析する、といった作業も必要となってきます。

テストは思うようには進まない

最近のマイグレーションプロジェクトで関わった情報システム部門の中には、マイグレーションを進めるための必要情報を把握・共有することが難しいとお話される方も多いです。

なぜなら、ギリギリの要員リソースで現行システムの運用をされていて、とても忙しかったり、あるいはメインフレームで稼働しているシステムの詳細（構成、仕様）を知らなかったり（知っている人は定年してしまった）などのケースがあるからです。

その様な状況下では、テストシナリオやテストデータをお客様サイドに依頼しても、なかなか連携が難しいプロジェクトも増えてきています。次善の策として、当社でテストを実施することもあります。この場合は、ある時点のデータを丸ごと取得していただき、ひと通り実行し、正常終了の確認を中心に行うという進め方を、必要に応じて取ることもあります。

この場合、テスト担当のエンジニアは現行システムの運用の詳細を把握できないまま実行するだけになってしまい、結果、エラーが多々発生するという事態にもなりかねません。この場合、大量のエラーをもとに、改めてお客様に運用に即した操作方法やデータの整合性などをご確認いただくことになり、結局それなりの手間と時間がかかってしまいます。加えてこのテスト方法では、テスト時はエラーにならずお客様に納品した後の受入テストで問題が発生する可能性も高くなります。

マイグレーションにおいては、現新比較テストのシナリオやテストデータを現行システムの運用にお詳しいお客様サイドにてしっかりご準備いただくことにより、より短期間かつ低価格で精度の高い移行を実現させることができるのです。

テストデータの準備にも関わってくるのですが、データ移行はお客様にもかなりのご負担をいただく工程になります。データ移行と一口に言っても、実際には移行対象になるデータの判別、移行対象となったデータのレイアウト、データを現行システムから抽出するタイミング、テスト時のデータコンバージョン（現行システムからのデータ抽出と文字コード変換など）、本番切り替え前のデータ移行などがあります。

どうしてもお客様主体で進めて頂かなくてはならない作業ですので、マイグレーションを行う際にはそのようにご認識いただきますとよろしいかと思います。（基本的に文字コード変換を含めたデータ移行の仕組みの準備はマイグレーションベンダーで行います）

現新比較テストで発生する、防げるはずの問題

現新比較テストで、現行システムの出力データと移行後のプログラムを実行して出力したデータを比較した時の不一致の原因のひとつとして、ソースのバージョン差異があります。これは変換するためにホストから取得したソースと、テストのためにホストで実行した時のソースに差異があり、出力データに影響してしまったことにによる比較検証の不一致となります。

マイグレーションプロジェクトは長期にわたることもあり、変換のためにプログラムソースを提供していただいた後、法対応や業務の変更による改修など、どうしても現行システムでプログラムソースに改修が入ります。そこで、ソース提供後の変更管理をどのプロジェクトにおいても、お願いしているのですが、様々な業種・業界のお客様の中には、そのような細かな資産変更の記録に慣れているという方は決して多くはなく、記録漏れが発生しがちです。

比較検証テスト不一致の原因調査では、基本的にソースを見てどの処理で該当データを出力しているのかを確認することから始めますが、コーディングされている通りにデータは出力されているため、なぜ不一致になるのかをすぐに把握することは難しく、調査に時間がかかってしまいます。そのためできる限りこういった不一致は減らしていきたいところです。

お客様と相談し、テスト前にもう一度プログラム資産をご提供いただきプログラムソースレベルでのコンペアを行ったり、ホストのオブジェクトの更新日の情報を取得していただいてチェックしたりするなど、マイグレーションベンダーとして尽力するのはもちろんですが、こういったテストでのエラーの早期解決のためには、お客様にも可能な限りソースの変更内容の把握にご協力をお願いしながら、プロジェクトを進めています。

時には新システムの方が遅くなってしまう事も

今まさに進行形で、新しいインフラはどんどん性能が良くなっています。それでもマイグレーション後のプログラムの方が、処理に時間が掛かってしまうということがあります。

例えば、ホストの階層型DBをオープン系のRDBに移行する時に、とあるコード以降のデータを読み込むような処理を単純にSQLへ移行すると、「>=」のような条件になりますが、これだと必要ないデータまで抽出してしまい、処理に時間がかかります。

他にも、マイグレーションにおいてはホストと同じ動作をさせるために共通処理を用意するのですが、その初期処理でホストと同じような環境（一時領域等）を準備する処理が実行されるため、どうしてもジョブの初動に、ほんの数秒とはいえ時間がかかってしまいます。

性能問題の原因は上記だけとは限らないので、できるだけ早く性能に問題ないことを確認しておくことは重要です。マイグレーションプロジェクトでは、本格的にソース変換を始める前に、一部だけ変換して実行し、課題を洗い出すパイロットテストという工程がありますが、このタイミングで実行時間についても確認しておきたいところです。その為には、性能を確認出来るような処理をパイロットテスト対象に選定する事や、パイロットテストに間に合うよう、新しいインフラを手配、テスト環境を準備することが必要です。

変換すれば終わり、ではない

今まであげた問題は、マイグレーションで必ず起こるわけではありませんし、これ以外にも様々な問題が発生します。それは技術的な問題だけではなく、どちらかというと泥臭い、人間系の問題であったり、プロジェクトのマネジメントの問題であったりします。

それらを未然に防いでいくために重要なのは、お客様、コンサルファーム、他社ベンダー、現行運用ベンダーなどの会社間、担当者間のコミュニケーションだと考えます。当社では、お客様がどのような状況か、担当の方がどの程度移行作業に携われるのか等、確認させていただいたうえで、役割分担をご提案します。お客様と一丸となってプロジェクトを推進できるよう、密なコミュニケーションをとっていきたいと考えています。