リホストとは

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

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

私が経験したリホストプロジェクトでは、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フォームからお問い合わせください。

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

/category/migration

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

今回は、業務システムのマイグレーションをどんなところに注意して行うべきかを、実体験からお話しさせていただきます。

マイグレーションとは

一般的にずっと同じシステムを使い続けるというのは困難です。

• ハードウエアの保守切れ/老朽化
• ＯＳサポート終了
• 保守費用の見直し
• データ量増加による圧迫
• パッケージシステムの導入

などにより、サーバーやアプリケーションを乗せ換えるというのは、どの企業でも発生します。

こうした乗せ換え／移行というものを、IT分野では「マイグレーション」と呼びます。

類似用語で「リプレイス」もありますが、こちらは機械故障で同等のものに乗せ換えるなど、同じ基盤・仕組みへの移行を指すため、今回のお話しするスコープには含めていません。

マイグレーションの難易度

マイグレーションは、システムに詳しくない方からすると「現行踏襲だから設計もさほど変わらないし簡単」と思われがちなのですが、移行先によっては難易度が高くなります。

（ちなみに本記事では、「事前に全体像を把握するのが難しい」ことを、「難易度が高い」としています。工数が大規模でも、事前調査の想定通りでギャップがなければ、難易度は低いと考えています。）

ＯＳバージョンアップであれば、使用しているアプリケーションの影響調査がメインです。該当アプリケーションが次世代ＯＳに対応しているならば、難易度は低いといえます。

自社設置サーバーを別の場所のサーバーに乗せ換えたり、クラウドに乗せ換えたりするリホストであれば、通信速度想定やバックアップ手法、リカバリプラン見直し、周辺サーバー・機器とのドライバ確認など、一般的に想定できる項目でスケジュールと工数は算出できると思います。組み合わせにより時間はかかるかもしれませんが、難易度は高くないでしょう。

しかし、業務システムのマイグレーションは、仕組みがお客様独自のものであるため、簡単には全体像を把握できません。現状調査で、プログラム本数・ソースのステップ数などの規模から算出するのはとても危険です。

業務システムマイグレーションの難易度が高い４つの理由と対策

なぜ業務システムのマイグレーションが難しいのでしょうか。その理由と対策を整理していきましょう。

１．移行元と移行先のギャップを押さえなければならない

例えば、プログラミング言語が変わる場合、値の持ち方（型・桁）の影響調査が必要です。また手続き型言語からオブジェクト指向言語に変わるのであれば、設計自体の大幅な見直しを余儀なくされます。またプログラムの組み方や命名規約で一定のルールがないと、移行が煩雑になります。

始めに一通りのプログラムを解析しなければならないため、サンプルでトライアルをして、調査にかかる実際の時間を想定することが重要です。

２．業務を理解しなければならない

プログラム解析で「この経路でこう処理されて出力されている」というロジックはおおよそわかります。ただ、業務を知らない開発メンバーだと「何のためのプログラムか」「受け取る・渡すデータはどうあるべきか」がわかりません。そうすると、テスト実施時に結果が期待値と乖離していても気が付かないことになりかねません。

設計書には業務機能の記載はあれど、業務自体の説明が無い場合が多いです。該当業務はお客様独自の場合があるため、憶測せずに内容を確認しなければなりません。画面の打鍵の順序やインプットする書類の流れ、締め処理、手作りのファイルがないかなど、お客様に協力いただき整理することで「業務的な正解」が見えてきます。

なるべく早い段階で該当業務を理解できると、データやロジックの調査・分析にも役立ちます。

３．業務上ありえないテストを行う可能性がある

画面が多くあるシステムでは、すべての入力値の組み合わせをテストをすると、テストケースが何万通り、何十万通りになってしまいます。ただ、入力値の組み合わせによっては、「業務上発生しえないもの」であり、テストケースとして不適合の場合があります。このような無駄な組み合わせのテストケースをなくせば、工数の削減につながります。

このために行うのが「実データの分析」です。セキュアな業務になればなるほど、実データをお目にかかれるのは後ろの工程となってしまいがちです。それでも、メンバー限定などで権限を付与してもらい、調査フェーズでデータを解析することで、入念に行うべきテスト・無駄なテストを整理できます。

実データがわかれば、設計時点でデッドロジックに気が付くかもしれません。またお客様の業務整理を行う過程で、実装しなくてよい機能が出るかもしれません。

４．リソース規模により難易度が変わる

ハードウエアマイグレーションであれば、どれだけプログラム・データ量が多くても、移行時間が取れるか否かという運用時間調整の問題は発生すれど、難易度が大きく変わることはありません。

一方、大規模なシステムマイグレーションでは、システムのプログラムが、過去の改修の積み重ねにより、つぎはぎになってることが多々あり、全体把握が困難です。ある項目を当初の想定とは異なる用途で使用したり、退職した元担当者の応急処置ロジックが含まれていたりすることもあるでしょう。お客様側も過去の経緯がわからないため、削除を判断できない可能性もあります。こうした問題は、解析に時間がかかる要因です。

ただ、時間がかかるからといって、解析せずにそのまま実装するというのは逆効果です。正解のわからないテストを行ってしまうでしょうし、マイグレーション後の保守フェーズでも、問題は変わらず付きまといます。

お客様の協力のもと、業務の観点・実データ解析より、きれいなロジックに設計しなおし、判断がつかないものは後から削除する可能性を見据えて目印をつけ、削除の仕方を整理しましょう。これにより、第三者（担当外の人・後任など）も理解しやすくなります。

まとめ

いかがだったでしょうか。

前工程で業務習得や調査にできるだけ時間をかけることで、後工程の製造からテストの精度やスコープの品質が上がり、後戻りやペンディングによる時間のロスが減ります。急がば回れを心がけていきましょう。

tdiでは、マイグレーションソリューションを提供しております。マイグレーションに関するご相談は、お気軽にこちらのWebフォームからお問い合わせください。

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

/category/migration

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