リホストで失敗しないために注意すべきポイント

「リホストは既存資産をそのまま再利用することで、移行にかかるコストやリスクの大幅な軽減を可能にしている」とよく説明されます。だからといって、何も考えずに簡単に移行が実現するわけではありません。私が実際に経験したリホストプロジェクトを通じて、リホスト実施時に注意および考慮すべき点についてお伝えしたいと思います。

リホストとは

まず最初に「リホスト」について確認です。リホストとは、基幹系業務システムのマイグレーション手法のうち、業務アプリケーションには変更を加えず、プラットフォームとなるハードウェアのみ移行する方法です。

リホストプロジェクトの移行概要

私が経験したリホストプロジェクトでは、IBMメインフレーム上のCOBOL、JCL、CICS、IMSの各資産について、開発・テストだけではなく、その実行・運用も含めたオープンシステム環境への移行を行いました。

新システムへの移行概要はこちらの図・表の通りです。

リホスト作業の期間は、リホスト範囲の決定～資産の変換まで6ヵ月、新旧比較テストに12ヵ月、合計18ヵ月でした。

また、リホストするにあたってマイクロフォーカス社の製品を採用し、開発環境には「Micro Focus Enterprise Developer」、実行環境には「Micro Focus Enterprise Server」で、メインフレームからオープンシステムへ移行しました。（マイクロフォーカスのエンタープライズ製品サイト）

リホストの流れ

リホストの流れの中で一番大事な工程は「資産の洗い出し」です。リホストするシステム、リホストしないシステムを整理することで、リホストの規模感が決定され、実際の作業へと進められます。内容によっては、リビルド・リライト・リホスト、どの変換方法を選択するか協議すると思いますが、コスト面や時間を考えてリホストになるケースが多いのではないでしょうか。

また一番時間がかかるのは「新旧比較テスト」です。ここでの新旧の相異点は、DBの違い、SAMファイルかテキストデータかの違いであり、ビジネスロジックには変更は加えていない状態です。よって、テスト仕様書には全条件をテストケースに記入する必要はなく、同じインプットデータを読ませて処理後の結果が新旧一致すれば、テスト完了とする作業内容です。単純に思えますが、実は大変な苦労がありました。これを踏まえて、新旧比較テストでの注意点を具体的にお伝えします。

リホストの新旧比較テストにおける注意点

文字コード

今回のプロジェクトの文字コードは、旧環境のメインフレームがIBMのz/OSであったためEBCDIC、新環境のオープン系はWindowsのためSJISでした。最終的に新旧を比較する時はお互いをSJISにしてコンペアしました。その時に一番悩まされたことは、文字コードの違いによって発生した新旧の差異でした。

文字コードの違いによって発生した課題

1. 漢字のシフトアウト／シフトイン
   • EBCDICの漢字はシフトアウト(0E)とシフトイン(0F)に挟まれています。SJISに変換する時はスペースにするかカットするしかなく、新旧に差異が発生する要因です。
   • SJISに変換する時はスペースにしないとCOBOLで定義しているデータ分が全て修正対象になります。
2. シフトコード置き換えによるプログラムへの影響
   • シフトコードをスペースに置き換えたことにより、スペースを条件にしているプログラムが正しく判定できなくなり、出力結果に差異が生じました。
3. シフトコードに挟まれたスペースの処理
   • メインフレームではシフトコードに挟まれたスペースは全角スペースですが、オープン系ではシフトコードの考えが無いため半角スペースです。（文字コード40と20の違い）
4. COBOLの漢字データ定義
   • COBOLのデータ定義で漢字の項目をG(025)ではなく、X(050)で定義しているものがあり、漢字項目としての2バイト変換をせずに文字化けしました。
5. 帳票出力対応
   • 出力結果が帳票の場合、シフトコードをスペースに置き換えたことにより帳票に印字する時は、そのスペースを削除しました。
   • プルーフリストのように横幅があまり気にならないものはいいのですが、オーバーレイ（枠だけ印字されているもの）の帳票に出力する時はスペースを削除する必要がありました。

DBの比較

出力結果がDBの場合も苦労しました。メインフレームはDB2、オープン系はOracleを使用しましたが、メインフレームでは現行システムが稼働していたため、DB2のデータは常に変化し、インプットデータ／アウトプットデータを確保することが難しく、新旧比較で完全一致するものは一割にも満たない状態でした。

検証する時はテーブルのKEY部分が一致しているデータを対象に残りの項目が一致しているか確認しました。中には残りの項目が更新されている場合もありましたが、その時は更新されるべき内容なのかを調べて問題ないことを確認しました。

処理のタイミング

新旧比較テストの実施率は、こちらのようになりました。

このように、JOBの特性よりテストをするタイミングが日次、月次、年次、臨時、依頼と様々なため、比較するためのインプットデータ入手が非常に困難で、テストが進まないということになりました。現行の処理結果とリホスト後の処理結果を比較するには長い期間のスケジュールが必要です。本プロジェクトでは、日次・週次・月次の新旧比較テストは6ヵ月で終わりましたが、それ以外のテストに、件数が少ないものの、さらに6ヵ月を要しました。

現行が処理されないと比較できないので、その時は何をもって「OK」とするかをお客様と決定しなければなりません。簡単に結果をコンペアすればいいテストでも進捗が芳しくないと、比較元になるメインフレーム環境がテスト完了前に撤去される事態になることもあります。この場合、オープンシステムで実行された処理結果の正しいことを実証しなくてはなりません。

リホストの考慮すべき点

新旧比較テストを中心にリホストの注意点を挙げましたが、他にも考慮すべき点があります。

テスト

通常の開発と同様に、テストは網羅的に実施することが重要です。しかし前述のように全量テストではありません。また、本番環境に移行するためのテスト運用期間も考慮が必要です。本番運用で表面化される不具合もあるので、本番フォロー、運用サポート体制も考えておかなければなりません。

セキュリティー

オープンシステムの場合、セキュリティー対策は最優先事項のひとつです。リホスト後のシステムに必要なセキュリティー機能の実装について検討が必要です。メインフレーム時代にはなかった概念なので、抜け漏れがないように気を付けましょう。

終わりに

リホストで失敗しないためには、まず事前に戦略をしっかり立てることが重要です。どの部分が必要で、どのような改善が必要なのか、そしてどの部分が要らないのか。課題を明確化し、その上でリホストの範囲を決定します。また、一時的なリホストでなければ、今後もそのシステムは長期的に使い続けることになります。リホストのきっかけはリース契約終了やハードウェア維持コストの削減かもしれません。しかし、そのような場合でも、リホスト後のアップグレードなど改善を重ねていく姿勢が重要と感じています。

なお、tdiでは、リホストサービスを提供しております。リホストに関するご相談は、お気軽にこちらのWebフォームからお問い合わせください。

マイグレーション | 情報技術開発株式会社

https://www.tdi.co.jp/category/migration

「脱ホストに踏み切れない」とお悩みのお客様に向け、大規模基幹系システムのリホストマイグレーションを手がけた豊富な経験と、専任チームにより、短期間で、お客様のホスト環境をオープン化します。

www.tdi.co.jp