メインフレームの移行が失敗する理由は予測可能です。ターゲットとなるクラウドアーキテクチャが間違っているからではありません。COBOLからJavaへの変換ツールが不十分だからでもありません。チームの意図や予算が不足しているからでもありません。失敗する理由は、チームが移行対象が何であるかを把握する前に、つまり、各プログラムが何をするのか、どのプログラムが他のどのプログラムに依存しているのか、データがどのようにシステム内を流れるのか、何かが変更されたときに何が壊れるのかを推測ではなく証拠に基づいて説明できる前に、移行を開始してしまうからです。失敗のパターンはほぼ常に同じです。移行の途中で発見された、誰も存在を知らなかった依存関係、400ものプログラムに組み込まれているコピーブックに埋もれたビジネスルール、誰も文書化しようと思わなかったファイルを通して12のダウンストリームシステムにデータを供給するバッチジョブなどです。
メインフレームの移行プロセスでは、リスクを最小限に抑え、事業継続性を確保するために、綿密な計画と実行が不可欠です。この説明は正しいものの、完全ではありません。重要な綿密な計画とは、ロードマップやベンダー選定、段階的なタイムラインのことではありません。重要なのは、これらの決定を行う前に実施される構造分析です。この分析によって、システムが実際に何を含み、どのように動作するのかが明らかになります。これは、ドキュメントに記載されている内容や、当初の設計意図とは異なります。大規模なメインフレーム環境では、この2つの記述は大きく乖離し、その差が移行の成否を左右することがよくあります。
メインフレーム移行が失敗する理由：分析のギャップ
メインフレームの移行が失敗する理由は、コードが古いからではなく、手遅れになるまで誰もコードの動作をきちんと理解していないからです。隠れたロジック、文書化されていないエッジケース、忘れられた処理フロー。これらは理論上のリスクではなく、プロジェクトを停滞させ、本番環境で問題を引き起こし、移行計画への信頼を静かに損なう、現実的な障害なのです。
分析ギャップには特有の構造がある。20年、30年とメインフレームシステムを運用してきた組織では、ドキュメントに反映されなかった変更、明示的なインターフェースではなく共有ファイルを介してプログラムが結合されたことで自然発生的に形成された依存関係、そして既に退職した開発者の頭の中にしか存在しないビジネスロジックが蓄積されている。メインフレームデータを標準ファイルのように扱っているチームは、移行中に「データ」に条件文や88レベルの条件名の中に散在する数十年分のビジネスロジックが含まれていることに気づき、痛ましい驚きを経験することになる。
移行を阻害する具体的な知識ギャップは4つあります。それぞれに、ギャップを埋めるための分析手法が存在します。これらのギャップは、ドキュメントのレビューや開発者へのインタビューだけでは解消できません。
ギャップ1：不明なプログラムインベントリ。組織は、実際のプログラム数が文書化されたプログラム数よりはるかに多いことに気づくことがよくあります。特定の業務ニーズのために作成されたプログラム、テストプログラムが本番プログラムになったもの、誰も作成したことを覚えていないユーティリティプログラムなど、すべてがロードライブラリに存在し、本番スケジュールに表示されるJCLジョブによって呼び出される可能性があります。
ギャップ2：文書化されていない依存関係。メインフレームは、WebSphere、CICS Transaction Gateway、Enterprise Service Busといったミドルウェアに加え、共有ユーティリティ、スケジューラ、ビジネスプロセスといった複雑なネットワークを通じて、数十ものシステムにデータを供給しています。問題は、これらの接続、特に下流のデータフィードや消費パターンをマッピングするのに時間がかかりすぎることです。
ギャップ3：組み込みのビジネスロジック。COBOLプログラムは数十年にわたりビジネスルールを蓄積していきます。1985年には単純だった計算式が、その後12人の開発者によって変更され、それぞれがどこにも文書化されていないビジネスルールの変更を反映した条件付きロジックを追加してきました。ロジックを理解せずにプログラムを移行すると、元のシステムとは異なる結果を計算する移行システムが生まれます。コードの観点からは正しいのですが、ビジネスの観点からは誤った結果となります。
ギャップ4：データ形式とスキーマの結合。APIではなくファイルを介してデータを共有するプログラムは、FD文とCOPY文以外には存在しないデータ形式契約によって結合されています。共有ファイルのレコードレイアウトが変更されると、そのファイルを読み取るすべてのプログラムが動作しなくなり、移行対象のプログラムだけでなく、メインフレーム上に残るプログラムも含まれる可能性があり、気づかないうちに統合が失敗します。
移住前に必ず行うべき8つの分析
以下の分析は、移行に関する最終決定を下す前、およびコードに手を加える前に完了しておく必要があります。これらは急いで行うべき予備的な手順ではなく、その後のすべての決定の基盤となるものです。
1. プログラム一覧を完成させる
最初の分析は、環境内に実際に存在するプログラム、ジョブストリーム、コピーブック、プロシージャ、データ定義を把握するための調査です。これはドキュメントのレビューではなく、実際のロードライブラリ、ソースライブラリ、プロシージャライブラリを解析して、信頼性の高いインベントリを作成する作業です。
インベントリには、以下の項目を網羅する必要があります。言語と概算サイズを含むすべてのソースプログラム。すべてのコピーブックと、それをインクルードするプログラム。すべてのカタログ化されたプロシージャーと、それを呼び出すジョブ。DD ステートメントに現れるすべてのデータセットと、それを生成または消費するプログラム。埋め込み SQL で参照されるすべての DB2 テーブル、ビュー、およびストアドプロシージャー。
ほとんどの大規模メインフレーム環境では、このインベントリによって、移行計画チームが認識していなかったプログラムが明らかになり、その差は全体の20～30%にも及ぶことがあります。不完全なインベントリに基づいて移行計画を策定すると、プロジェクトの途中で不足しているプログラムが発見された場合に、コスト超過が発生します。
2. 全言語にわたる依存関係マッピング
インベントリが作成されると、依存関係マッピングによって、各コンポーネントが他のすべてのコンポーネントとどのように接続されているかが追跡されます。依存関係マップは、その後のすべての変更の範囲を定義するため、移行前の分析の中で最も重要なものです。
完全な依存関係マップには以下が含まれます。
- プログラム間呼び出し: CALL、PERFORM、LINK、ATTACH、および実行時に解決される動的CALL
- JCLからプログラムへの呼び出し: シンボルパラメータ置換が解決された PROC 呼び出しを含む、すべての JCL ジョブ ストリーム内のすべての EXEC PGM= ステートメント
- 模範解答の包含連鎖どのプログラムがどのコピーブックを含んでいるか（他のコピーブックによってインクルードされたネストされたコピーブックを含む）
- データセットの生産者と消費者の関係どのプログラムがどのデータセットに書き込み、どのプログラムがそれらのデータセットから読み取り、それによって生じるシーケンシャルなジョブチェーンの依存関係。
- DB2スキーマ参照どのプログラムがどのテーブルから読み書きするか、どのテーブルが他のどのテーブルとスキーマを共有するか
出力は有向グラフです。このグラフ内の任意のノードに対する変更案は、エッジをたどって依存する他のすべてのノードを列挙することで、その影響を分析できます。このグラフがなければ、影響分析は推測に頼るしかありません。
コードに手を加える前に、徹底的な可視性を確保することが何よりも重要です。古いドキュメントに頼ることは致命的な欠陥です。自動化ツールは、JCL、COBOL、PL/Iを自動的にスキャンして現在の状態をマッピングし、すべてのアプリケーション、データフロー、依存関係、および隠れたジョブをマッピングする必要があります。
3. ビジネスロジックの抽出と文書化
COBOLプログラムには、組織内の他のどこにも存在しないビジネスロジックが含まれています。これは移行計画において最も見落とされがちな分析であり、移行後の失敗において最もコストのかかる原因となります。
ビジネスロジックの抽出では、IF/THEN/ELSEおよびEVALUATE構造にエンコードされた決定ルール、COMPUTEステートメントの計算式、PROCEDURE DIVISION段落のデータ検証ルール、エラー処理パスとそのビジネス上の意味、および演算の順序が出力の正確性に影響する順序依存ロジックに関するドキュメントが生成されます。
この分析では、すべてのプログラムのすべての行を手動で読み込む必要はありません。COBOLを理解する静的解析ツールを使用すれば、決定構造を特定し、条件ロジックを抽出し、それらがエンコードするルールの構造化されたドキュメントを作成できます。この出力は2つの目的を果たします。1つは、移行チームが移行後のシステムが正しい結果を生成することを検証するために必要な仕様を提供すること、もう1つは、何十年もの間コードの中にしか存在しなかった可能性のあるビジネスルールを、初めて体系的に文書化することです。
4. デッドコードの識別
メインフレーム内のすべてを移行する必要はありません。どのジョブストリームからも呼び出されないプログラム、どの呼び出しパスからも実行されないパラグラフ、どのコピーブックメンバーからも参照されないものなど、これらはすべてビジネス価値を生み出さない移行作業です。
デッドコード識別機能は、依存関係グラフを解析して、本番ジョブストリームからの参照がないコンポーネントを特定します。これらのコンポーネントは移行範囲から除外できるため、機能を損なうことなくコストを削減できます。大規模なレガシー環境では、デッドコードは通常、インベントリ全体の10～25%を占めます。偶発的に発見するのではなく、体系的に識別することで、移行範囲を大幅に縮小できます。
分析では、真にデッドコード（本番環境の実行パスから決してアクセスできないコード）と、まれにしか実行されないコード（アクセスは可能だが、ほとんど実行されないコード）を区別する必要があります。年末処理ルーチン、規制報告プログラム、災害復旧手順など、まれにしか実行されないコードは、実行頻度は低くても重要な場合があります。これらのコードを移行対象から除外すると、99%の時間は正常に動作するものの、最も必要とされる時にまさに障害が発生するシステムとなってしまいます。
5．複雑性とリスク分類
プログラム一覧と依存関係マップが作成されると、各プログラムを複雑度と移行リスクに基づいて分類できます。この分類に基づいて移行順序が決定されます。複雑度と依存度の低いプログラムは最初に移行され、複雑度と依存度の高いプログラムは最後に、最も徹底的なテストを実施して移行されます。
COBOL移行リスクの複雑性指標：
| 複雑さの要因 | 測定するもの | 高リスク閾値 |
|---|---|---|
| 循環的複雑性 | プログラムごとの意思決定分岐数 | 各プログラムにつき50名以上 |
| コピーブックの依存関係数 | 付属のノート冊数 | 20冊以上のノート |
| 呼び出し回数 | このプログラムを呼び出すプログラムの数 | 15人以上の発信者 |
| データセットの参照 | 読み書きされたデータセットの数 | 30以上のデータセット |
| 組み込みSQL | SQLステートメントの数 | 100件以上の声明 |
| EXEC CICS呼び出し | トランザクションサーバーとの連携 | CICSへの依存関係 |
| 動的CALL | 実行時に解決された呼び出し | 動的な呼び出し |
| アセンブラ呼び出し | COBOL以外のロジックが組み込まれています。 | 任意のアセンブラ呼び出し |
複数の要素で高い評価を得たプログラムは、移行におけるリスクが最も高いコンポーネントであることを示しています。そのため、最も徹底的な分析、最も経験豊富な移行エンジニア、そして最も包括的なテスト範囲が必要となります。
6. バッチウィンドウとスケジューリングの依存関係分析
メインフレームのバッチジョブは、複雑な依存関係を持つスケジュールされた時間帯に実行されます。ジョブBはジョブAが正常に完了するまで開始できず、ジョブCは月末の最終営業日にのみ実行され、ジョブDにはジョブEの開始時間に影響を与える最大実行時間制約があります。これらのスケジューリング上の依存関係はシステムの運用動作の一部であり、ターゲット環境でも再現する必要があります。
バッチウィンドウ分析ドキュメントには、各本番バッチ実行の完全な実行チェーン、各ステップの時間制約、条件付き実行ロジック（ステップが失敗した場合、またはゼロ以外の戻りコードを生成した場合に何が起こるか）、ステップ間で流れるデータセット、およびバッチシステムが生成する外部トリガーと通知が含まれます。
クラウドネイティブ環境においては、これは以下のことを意味します。同等のCI/CDパイプラインまたはワークフローオーケストレーション構成、エラー処理およびアラート設定、監視およびSLA構成、そしてバッチ出力を受け取る下流システムとの統合。
7. データ品質とフォーマットの評価
レガシーシステムには、COBOL、PL/I、またはアセンブラで記述された数千行ものコードが含まれていることが多く、その多くはドキュメントが不十分であったり、密結合していたりする可能性があります。静的解析ツールを使用して、技術的負債、冗長なコード、モジュール化または廃止可能なモジュールを検出してください。
データ品質評価では、本番データセット内の実際のデータを、COBOL FDおよびコピーブック定義のフォーマット定義と照合します。不一致はよく見られます。例えば、特定のレコードタイプに対して無効なビットパターンを含むパック10進数フィールド、一部のレコードで長さインジケータが範囲外になっている可変長フィールド、特定の位置に表示不可能な値を含むEBCDIC文字フィールドなどです。
これらの不一致は、移行テスト中に発見されるのではなく、移行前に特定して解決する必要があります。500億件のレコードを移行した後に、そのうち0.1%に無効なフォーマットが含まれていることが判明した場合、それはソースデータに存在し、検証ステップまで知られていなかった、本番環境に影響を与える欠陥となります。
8. 統合と外部システムマッピング
データリネージには、レポートツールからパートナーとの連携まで、メインフレームデータを利用するすべてのシステムを網羅する必要があります。なぜなら、開発の後半になって、これらのデータフィードの維持が不可欠だったにもかかわらず計画されていなかったことにチームが気付いた場合、近代化プロジェクトは稼働開始できないからです。
統合マッピングでは、メインフレームからデータを受信したり、メインフレームにデータを送信したりする、メインフレーム外部のすべてのシステムを識別します。これには、ファイル転送を介してバッチ出力を利用するダウンストリームアプリケーション、MQ、CICS、またはAPI呼び出しを介したリアルタイムインターフェース、特定のファイル形式と送信スケジュールに依存するパートナー統合、DB2テーブルを直接照会するレポートシステム、および変換されたメインフレームデータを取り込むデータウェアハウスフィードが含まれます。
各統合ポイントは潜在的な切り替えリスクとなります。移行されたシステムが下流システムが想定していない形式でデータを生成する場合、下流の利用者が異常を報告するまで検出されないまま、静かな障害が発生する可能性があります。統合マッピングは、切り替え計画を楽観的なものにするのではなく、包括的なものにするための分析です。
分析結果に基づいた移行戦略の選択
移行前の分析は、移行のリスクを軽減するだけでなく、各コンポーネントに適した移行戦略を決定します。チームは、管理可能な変更の規模に応じて、さまざまな方法でメインフレームのワークロードを移行します。分析結果は、その決定に直接役立ちます。
| 分析結果 | 推奨される戦略 | 理由 |
|---|---|---|
| 複雑性が低く、依存関係が少なく、動的な呼び出しがない | リホスティング（リフトアンドシフト） | リスクが最も低く、行動上の同等性を迅速に達成可能 |
| 中程度の複雑さ、十分に文書化されたビジネスロジック | プラットフォームの再構築 | 多少の変更は許容範囲内。論理は理解できる。 |
| 複雑度が高く、依存関係グラフが密集している。 | 位相絞め殺しイチジク | 段階的に抽出する。メインフレームをコアとして残しつつ、その周辺を近代化する。 |
| 重要な共有プログラム、100人以上の参加者 | APIラッパー | サービスとして公開し、プログラムに手を加えることなく消費者を移行する |
| 無効なデータまたはフォーマットの問題を含むプログラム | データ修復を第一に | データがクリーンになるまで、移行は成功しない。 |
| 分析によりデッドコードが確認された | 引退 | 移行は不要です。スコープから削除してください。 |
| 文書化されていないビジネスロジック、専門家もいない | 詳細な分析が必要 | ロジックが抽出され文書化されるまで、安全な移行はできません。 |
依存関係グラフから移行シーケンスを構築する
依存関係グラフが完成すると、移行順序が直接定義されます。他のメインフレームコンポーネントに依存しないコンポーネントは、独立して早期に移行できます。多くのコンポーネントが依存しているコンポーネントは、すべての依存コンポーネントの準備が整った後、最後に移行する必要があります。
実践的な順序付けアプローチ：
フェーズ1：ユーティリティプログラムとスタンドアロンのバッチジョブ。呼び出し元がなく、共有データセットもないプログラム。これらは個別に移行でき、調整は不要です。
フェーズ2：依存関係ツリーの末端プログラム。他のプログラムを呼び出すが、呼び出されるプログラムが少ないプログラム。これらのプログラムを移行することで、残りのプログラムの依存関係の範囲から除外されます。
フェーズ3：データ結合プログラム。データセットを共有するプログラム群は、1つの単位としてまとめて移行することができ、移行後のグループ内でデータ形式の互換性が解消されます。
フェーズ4：共有サービスプログラム。呼び出し元が多いプログラム、つまり依存関係グラフにおける高ファンインノードは、すべての呼び出し元が移行後の実装に対して検証された後にのみ移行されます。
フェーズ5：コアトランザクションプログラム。最もリスクの高いコンポーネントは、最も包括的なテスト範囲と最も厳密に管理された移行プロセスを経て、最後に移行されます。
この手順は一般的なヒューリスティックではなく、移行対象となる特定のシステムの依存関係グラフに基づいて導き出されたものです。プログラム数が同じメインフレーム環境であっても、依存関係構造が異なるため、最適な移行手順は全く異なります。
認定条件 SMART TS XL 移行前分析を生成します
SMART TS XL 本稿で説明する8つの分析すべてを、環境内のすべてのコンポーネントの実際のソースコードを解析することで自動的に実行します。ドキュメント、開発者へのインタビュー、既存の図表などに依存することなく、コード自体から構造モデルを導き出すため、ドキュメント化されていないプログラムや、意図せずして発生した依存関係についても、正確なモデルが得られます。
レガシーシステムの近代化分析は、完全なインベントリ生成から始まります。すべてのCOBOLプログラム、JCLジョブストリーム、コピーブック、PROC、およびSQLスキーマは、ソースの場所、サイズ、言語バージョン、および予備的な複雑度スコアとともにカタログ化されます。アプリケーション依存関係マッピングは、完全な依存関係グラフを構築し、 JCL展開機能を使用してJCLシンボルパラメータを解決し、未解決のテンプレート参照ではなく、実際に呼び出されるプログラムを表示します。
影響分析機能により、依存関係グラフをクエリ可能にできます。コンポーネントを移行する前に、チームはメインフレームから削除した場合に何に影響が出るかを問い合わせ、検証または調整が必要なすべての依存コンポーネントを列挙した構造化リストを受け取ることができます。エンタープライズ検索機能により、すべての言語にわたるインベントリ全体を同時に検索でき、特定のデータセットを読み取るすべてのプログラム、特定のフィールドを定義するすべてのコピーブック、特定の列を参照するすべてのSQLステートメントを、数百万行のコードベース全体で数秒で見つけることができます。
移行前分析の成果物はプロジェクト計画書ではありません。それは構造的な証拠、つまり依存関係グラフ、複雑性分類、デッドコード一覧、ビジネスロジック文書、統合マップであり、これらを総合すると移行チームは作業対象を正確に把握できます。この証拠こそが、本番環境で予期せぬ問題を発見する移行と、分析段階で発見し解決する移行との違いを生み出すのです。後者の場合、問題の発見と解決にかかるコストは数週間で済み、数ヶ月で済むことになります。
分析はオーバーヘッドではなく、移行です
包括的な移行前分析に対する最も一般的な反対意見は、スケジュールに関するものです。組織は移行開始日を決定しており、経営陣からのプレッシャーも大きいため、コードに手を加える前に6～8週間も分析に費やすのは遅延のように感じられるのです。しかし、この考え方はリスク評価を逆転させています。ルールが明確になり、フローがマッピングされれば、プロジェクトは憶測からエンジニアリングへと移行します。自動化ツールは目に見えないものを可視化し、それこそが重要な部分なのです。
完全な分析を行わずに開始する移行は、開始が速くなるわけではなく、未知の範囲から始まることになります。未知の範囲は、未発見の依存関係が明らかになったときに、スケジュールの予期せぬ変更、予算超過、および本番環境でのインシデントを引き起こします。分析フェーズは移行を遅らせるものではなく、それ自体が移行です。切り替え時ではなく分析時に発見されたすべての依存関係は、発生しなかった本番環境でのインシデントです。移行前にデッドコードとして特定されたすべてのプログラムは、無駄になった労力です。変換前に文書化されたすべてのビジネスルールは、推測ではなくテスト可能な検証基準です。
成功する組織とは、複雑性に積極的に取り組み、依存関係を早期に把握し、知識を民主化し、ビジネス価値に焦点を当て、初日から明確な目標に基づいて連携する組織です。これらは単なるベストプラクティスではなく、測定可能な投資対効果（ROI）をもたらす変革プロジェクトと、教訓となる失敗事例との違いを生み出すものです。
