規模の似たCOBOLポートフォリオを持つ2つの組織が、異なる近代化の決定を下した。一方の組織はプラットフォームの再構築を行い、AWSメインフレーム近代化またはCOBOLエミュレーションレイヤーを使用してCOBOLプログラムをクラウドインフラストラクチャに移行し、物理メインフレームを排除しながらコードを維持した。18か月以内にインフラストラクチャコストを40%削減し、このプログラムは成功とみなされた。もう一方の組織は同じアプローチを試みたが、12か月後に行き詰まり、再設計に方向転換し、最も重要なプログラムをJavaマイクロサービスとして再構築した。この方向転換には当初の予算の2倍のコストがかかり、さらに3年を要した。
出発点は同じだったが、結果は全く異なった。違いはツール、ベンダー、チームの違いではなかった。2番目の組織は、新しいプラットフォームでは対応できないアーキテクチャ上の制約、CICSトランザクションの依存関係、VSAMファイル構造、そして根本的な再設計なしには再プラットフォーム化されたコードでは満たせないリアルタイム要件といった問題を抱えたシステムに対して、プラットフォームの再構築を選択したのだ。この決定は、システムを十分に理解する前に下されたもので、適切な判断を下すことができなかった。
COBOLにおける各パスの実際の意味
一般的な定義はよく知られています。重要なのは、それぞれのパスがCOBOLプログラムにとって具体的に何を意味するかということです。COBOLプログラムでは、アーキテクチャ、実行モデル、データ構造が現代のアプリケーションとは異なり、どのパスが実行可能かに直接影響するからです。
COBOLのプラットフォーム変更
リプラットフォームとは、COBOLプログラムを新しいオペレーティング環境（通常はクラウドインフラストラクチャ）に移行させるプロセスであり、コード自体はほぼ変更されません。COBOLは新しいプラットフォーム上でコンパイルおよび実行されます。その方法は、ネイティブに（Linux上のIBM COBOLコンパイラを使用して）コンパイルするか、メインフレーム固有の呼び出し（CICS、VSAM、JESなど）をインターセプトしてクラウドネイティブな呼び出しに変換するエミュレーションレイヤーを介してコンパイルするかのいずれかです。
プラットフォーム変更によって維持されるもの：
- COBOLソースコード
- プログラムのロジック、計算、およびビジネスルール
- バッチ実行モデル（PERFORMループ、シーケンシャルファイル処理）
- データ構造（レコードレイアウト、コピーブック定義）
- JCLジョブ構造（新しいスケジューラ向けに書き直されたものだが、論理的には同等）
プラットフォーム変更の内容：
- 物理インフラストラクチャ（z/OS → クラウド上のLinux）
- I/Oサブシステム（VSAM → ツールに応じてマネージドファイルストレージまたはデータベース）
- ジョブスケジューラ（JES2/JES3 → AWS Batch、Azure Logic Apps、または同等のもの）
- コストモデル（MIPSベースの課金 → 消費ベースのクラウド課金）
重要なポイント：プラットフォーム自体、z/OSの運用コスト、インフラストラクチャへの依存、MIPS課金モデルに問題がある場合は、プラットフォームの再構築は正しい選択です。しかし、コードやアーキテクチャに問題がある場合は、再構築は間違った選択です。
COBOLの再設計
アーキテクチャの再構築は、システムの根本的な設計を変更します。ビジネスロジックはCOBOLソースコードから維持または再導出されますが、新しい言語、新しい実行モデル、新しいデータ層で実装されます。結果として、COBOLが行っていたことを実行するものの、構造的にはCOBOLとは全く異なるシステムが生まれます。
再設計によって何が変わるのか：
- プログラミング言語（COBOL → Java、Python、Go、C#）
- 実行モデル（バッチ処理 → イベント駆動型、ストリーミング処理、またはAPIベース）
- データ層（VSAMファイル → リレーショナルデータベース、NoSQL、クラウドネイティブストレージ）
- トランザクションモデル（CICS擬似対話型 → RESTfulステートレスサービス）
- 統合パターン（共有データセット → API契約、メッセージキュー）
再設計において守るべきもの：
- COBOLが実装するすべてのビジネスルール（文書化されていない例外的なケースを含む）
- パック十進数演算の数値精度特性を含むすべての計算
- MOVE ステートメント内の暗黙的な型変換を含む、すべてのデータ変換
- ダウンストリームシステムが依存する可能性のある、特定のファイルステータスコードや異常終了動作を含むすべてのエラー状態
注意：最もよくある再設計の失敗例は、COBOLコードに、他のどこにも記述されていないビジネスルールが含まれていることが判明することです。新しいシステムは、実装エラーではなく、仕様が不完全だったために、特定のエッジケースで古いシステムとは異なる動作をします。再設計を開始する前に、COBOLソースコードからビジネスロジックを抽出し、文書化する必要があります。
この決定を変えるCOBOL固有の要因
一般的な近代化フレームワークでは、プラットフォームの再構築とアーキテクチャの再設計は、主にコスト、スケジュール、リスクに関する決定事項として扱われます。しかし、COBOLの場合、言語とその実行環境に特有のいくつかの技術的要因が、決定をどちらかの方向に強く押し進めます。
CICSトランザクションの依存関係
CICS（Customer Information Control System）は、多くのCOBOLプログラムが対話型ワークロードに使用するトランザクション処理ミドルウェアです。EXEC CICS呼び出しを行うCOBOLプログラムは、画面管理、端末通信、タスクディスパッチ、およびプログラム制御のために、CICSトランザクションサーバーに暗黙的に依存しています。
プラットフォーム変更の影響： Micro Focus CICSエミュレーション、OpenFrame、および一部のAWSメインフレーム近代化機能などのツールは、CICSのセマンティクスをエミュレートします。CICSの使用方法が標準的で適切に動作する場合、エミュレーションは正常に機能する可能性があります。プログラムがCICSの内部構造、コマエリア操作、同期ポイント制御、タスクレベルのストレージに依存している場合、エミュレーションの精度は低下します。
アーキテクチャ変更の意義： CICSプログラムをREST APIに変換する場合、擬似対話型トランザクションモデルをステートレスなインタラクションとして再設計する必要があります。これはコードの変換ではなく、アーキテクチャの変更です。
再設計を促すシグナル：複雑な通信領域処理、バックエンドのトランザクションチェーン、または同期ポイントロジックを伴うCICSの多用。
VSAMファイルアーキテクチャ
VSAM（Virtual Storage Access Method）は、ほとんどのCOBOL本番プログラムで使用されるインデックス付きファイルシステムです。VSAMファイルには、KSDSキー付きシーケンシャルアクセス、ESDSエントリシーケンスアクセス、RRDS相対レコードアクセスといった固有のアクセスパターンがあり、クラウドネイティブストレージには直接対応するものがありません。
プラットフォーム変更の影響：エミュレーション層は、VSAMの読み書きを基盤となるファイル操作またはデータベース操作に変換します。単純なシーケンシャルアクセスやキーベースのアクセスであれば問題ありません。しかし、複雑な代替キーアクセス、複数のプログラムで共有されるVSAMクラスタ、あるいはパフォーマンスが重要なランダムアクセスパターンでは、エミュレーションによってレイテンシと複雑さが増大します。
アーキテクチャ再設計における影響： VSAMをリレーショナルデータベースに置き換えるには、レコードレイアウトをテーブルスキーマにマッピングし、暗黙的なデータ型変換を処理し、すべてのファイルアクセスをSQLまたはORMを使用するように書き換える必要があります。
再設計を促すシグナル：複数のプログラム間で共有されるVSAMファイル、代替インデックスアクセスパターン、またはエミュレーションでは満たせないリアルタイムパフォーマンス要件。
バッチ処理とリアルタイム処理の要件
COBOLバッチプログラムは、大量のレコードをスケジュールされた時間帯に順次処理するように設計されています。多くの銀行、保険会社、政府機関のシステムでは、現在でも夜間にバッチジョブを実行して、数百万件のトランザクションを処理し、レポートを作成し、マスターファイルを更新しています。
プラットフォーム変更の影響：バッチ処理のセマンティクスは、クラウドバッチ実行（AWS Batch、Azure Batch）にうまく適合します。シーケンシャル処理モデルはプラットフォーム変更後も維持されます。要件が単に同じバッチジョブをより安価なインフラストラクチャで実行することであれば、プラットフォーム変更によって直接解決できます。
アーキテクチャ再設計の意義：ビジネス要件が、夜間バッチ処理からほぼリアルタイム処理へ、ファイルベースのデータ交換からAPI統合へ、モノリシックなバッチ実行から個別にトリガーされるマイクロサービスへなど変更された場合、プラットフォームの再構築だけでは新たな要件を満たすことはできません。アーキテクチャ自体を変更する必要があります。
再設計を促すシグナル：リアルタイム処理、APIベースの統合、イベント駆動型アーキテクチャ、またはバッチ処理では実現できない1秒未満の応答時間に対するステークホルダーの要求。
外部仕様を必要としない組み込みビジネスロジック
これは、COBOL特有の最も見過ごされがちな要素です。主なリスクとしては、数十年前のコードに組み込まれた重要なビジネスルールの喪失や、システム動作に関するドキュメントの不足などが挙げられます。COBOLプログラムには、ビジネスルールの唯一現存する仕様が含まれていることがよくあります。特定の計算を要求した規則は1983年に作成されましたが、それを理解していたビジネスアナリストは2001年に退職しています。COBOLコードは単なる実装ではなく、ドキュメントそのものなのです。
リプラットフォームの意義：コードが維持されるため、ビジネスルールはそのまま存続する。これはリプラットフォームの最も強力な利点の1つである。
再設計の際の留意点：ビジネスルールは、再実装する前にCOBOLソースから抽出する必要があります。<cite index=”28-1″>文書化されていない密結合コードは、あらゆる段階で労力を増大させます。</cite> この抽出が不完全な場合、新しいシステムは古いシステムとは異なる仕様となり、その違いが本番環境で顕在化します。
意思決定フレームワーク：8つの質問
進路を選択する前に、以下の8つの質問は、憶測ではなく自信を持って決断を下すために必要な証拠を提供する。
1. この近代化の主な原動力は何ですか？
- インフラコスト → リプラットフォームで十分
- プラットフォーム依存性（z/OS）→プラットフォーム変更で十分
- リアルタイム要件 → 再設計が必要
- 統合要件（API）→再設計が必要になる可能性が高い
- 保守性／人材の確保 → 再設計またはリファクタリング
2. CICS結合レベルはどのくらいですか？すべてのEXEC CICS呼び出しを列挙してください。20個以上の異なるCICSコマンドを含むプログラムを数えてください。CICS結合度の高いプログラムは、エミュレーションの忠実度が不確かな場合、プラットフォーム変更の対象としては不向きです。
3. VSAMへのアクセスパターンはどのようなものか？代替キー、共有クラスタ、またはパフォーマンスに影響されるランダムアクセスを使用してVSAMファイルにアクセスするプログラムを特定します。これらは、プラットフォーム変更のリスク指標となります。
4. ビジネスロジックは外部に文書化されていますか？ COBOLソースコードが唯一の公式仕様である場合、再設計にはビジネスロジックの抽出が前提条件として必要であり、並行作業として行うべきではありません。
5. バッチ処理の許容範囲はどのくらいですか？ビジネス要件として、より低コストで同じバッチ処理モデルが必要な場合は、プラットフォームを再構築します。ビジネス要件として、同じ処理をリアルタイムで実行する必要がある場合は、アーキテクチャを再設計します。
6. 依存関係の複雑さとは？サブプログラムやJCL呼び出し元など、50個の下流依存関係を持つプログラムは、スタンドアロンのユーティリティよりも再設計のリスクが高くなります。依存関係の構造によって、移行の順序とテスト範囲が決まります。
7. コードの何パーセントがデッドコードですか？変換前にデッドコードを除外することで、どちらのパスでも作業量を削減できます。再設計プログラムの場合、除外されなかったデッドコードはフルコストで変換され、その後破棄されます。
8. 複雑性の分布はどうなっていますか？プログラムあたりの循環的複雑度が50を超える場合、または含まれるコピーブックが20を超える場合は、再設計コストが高く、プラットフォーム変更のリスクが高いプログラムであることを示しています。これらのプログラムは、一括パス割り当てではなく、個別に注意を払う必要があります。
フレームワークの適用：4つのCOBOLシステムプロファイル
| プロフィール | 特性 | 推奨パス | 理由 |
|---|---|---|---|
| 安定版バッチユーティリティ | シーケンシャルファイルI/O、CICS不要、十分に文書化されたロジック、低複雑度 | リプラットフォーム | プラットフォームのコストが問題であり、コードが制約ではない。 |
| CICSを多用したオンライン取引 | EXEC CICSの多用、commareaの依存関係、擬似対話型モデル | 再設計 | CICSエミュレーションのリスクは高く、リアルタイム要件は |
| VSAMマスターファイルプロセッサ | 複雑なVSAMアクセスパターン、複数のプログラムで共有、高読み取り量 | まずエミュレーションの忠実度を評価し、エミュレーションが維持される場合はプラットフォームを変更する。 | VSAMエミュレーションは決定変数です |
| ビジネスロジック財務 | 文書化されていない規則、外部仕様なし、規制上の重要性が高い | まずロジックを抽出し、次に選択する | 事前のビジネスロジック抽出なしに再設計を行うリスクは容認できない。 |
重要なポイント： <cite index=”30-1″>実際には、大規模な資産では、安定した部分をプラットフォーム化し、保守が難しいコードをリファクタリングし、新しい機能が必要な少数のシステムを書き換え、使用されなくなったものを廃止するというアプローチを組み合わせています。</cite> 決定はポートフォリオレベルではなく、ワークロードレベルで行われ、証拠に基づいて各プログラムまたはプログラムグループに個別に適用されます。
ハイブリッドアプローチ：まずプラットフォームを再構築し、必要に応じてアーキテクチャを再設計する
実用的なルールとしては、まずは迅速に損失を食い止めるためにリホストまたはリプラットフォームを行い、その後、真の競争優位性となるシステムをリファクタリングまたは再設計することである。
COBOLを多数保有するほとんどの組織にとって、実際的な手順は次のとおりです。
フェーズ1：明確な候補となるプログラムのプラットフォーム変更を実施する。CICSを使用せず、単純なシーケンシャルI/O、文書化されたロジック、低複雑性を備えたプログラムは、予測可能な労力とリスクでプラットフォーム変更が可能である。これにより、インフラストラクチャコストを迅速に削減し、組織の信頼を高めることができる。
フェーズ2：複雑なプログラムの評価。CICSとの連携、複雑なVSAMパターン、または文書化されていないビジネスロジックを持つプログラムは、パスを選択する前に個別に分析する必要があります。この段階で、ビジネスロジックの抽出と構造分析によって、再設計が必要かどうか、またその範囲がどの程度になるかを判断します。
フェーズ3：アーキテクチャ上の障害を持つプログラムの再設計。再プラットフォーム化されたインフラストラクチャ上でビジネス要件、リアルタイム要件、API統合、イベント駆動型処理を満たせないプログラムは、ストランギュラーフィグパターンを使用して再設計されます。再プラットフォーム化されたプログラムと並行して新しいサービスを構築し、各コンポーネントが検証されるにつれてトラフィックを新しい実装に段階的にルーティングし、すべてのトラフィックが移行されたら古いプログラムを廃止します。
フェーズ4：不要コードの廃止。構造解析で不要と判断されたプログラムは、両方のパスから除外され、廃止されます。これにより、変換作業を行うことなく、継続的なメンテナンスコストを削減できます。
意思決定を行う前に分析で必ず出すべき結果
上記の意思決定フレームワークは、入力が推定値ではなく証拠である場合に、より優れた回答を生み出します。これらの入力を提供する構造分析では、ドキュメントや開発者の知識に頼るのではなく、実際のCOBOLソースコードを解析する必要があります。
各プログラムについて分析で明らかにしなければならないこと：
ドキュメントに記載されていないプログラムも含めた完全なプログラム一覧。大規模な COBOL 環境では、ドキュメント化されていないプログラム数が全体の 20% を超えることがよくあります。どのプログラムが他のどのプログラムを呼び出しているか、どのデータセットが共有されているか、どの JCL ジョブがどのプログラムを呼び出すかを示す依存関係グラフ。すべてのプログラムの CICS コマンド一覧、呼び出しの数、タイプ、および複雑さ。VSAM アクセスパターン分析、どのアクセス方法、どのファイルがプログラム間で共有されているか、どのファイルに代替インデックスがあるか。循環的複雑度分布、どのプログラムが構造的に単純で、どのプログラムが変換のリスクが高い候補か。デッド コードの識別、どのプログラムと段落にインバウンド実行パスがないか。ビジネス ロジックの抽出、各プログラムが実装するルール、どちらのパスの出力も検証するために使用できる形式。
このインベントリがなければ、パスの決定は不完全な情報に基づいて行われることになります。プログラムのリプラットフォームは、計画段階では見えなかったアーキテクチャ上の制約がエミュレーションによって明らかになった際に、誤った前提に基づいて割り当てられます。
認定条件 SMART TS XL 判決前の証拠を作成する
SMART TS XLさん レガシーの近代化 分析機能は、上述の構造的インベントリを自動化し、すべての COBOL プログラム、コピーブック、JCL ジョブ、および VSAM ファイル参照を同時に解析して、パス決定を証拠に基づいたものにする統一された依存関係モデルを構築します。
アプリケーション依存関係マッピングは、依存関係の複雑さを決定するプログラム間呼び出しグラフとデータセット共有マップを生成します。この複雑さは、プラットフォーム再構築のエミュレーションリスクと再設計の範囲および順序に最も直接的に影響を与える要因です。
静的コード解析では、ポートフォリオ内のすべてのプログラムについて、複雑度メトリクス、CICS呼び出しインベントリ、およびデッドコード識別情報が生成されます。循環的複雑度しきい値を超え、CICSとの結合度が高いプログラムは、一括してプラットフォーム変更に割り当てられるのではなく、自動的に再設計または評価の候補として表示されます。
JCL展開は、シンボリックパラメータを解決し、完全なバッチ実行依存関係チェーンを構築します。これにより、どのJCLジョブがどのプログラムを、どの順序で、どのデータセットを使用して呼び出すかが明らかになり、バッチスケジュールを満たすためにどちらのパスの出力もどのように動作する必要があるかを決定する運用コンテキストが提供されます。
影響分析機能により、プログラム開始前に各パスの範囲が明確になります。再設計対象として選択されたプログラムについては、影響分析によって、更新、再テスト、または再設計対象コンポーネントとの調整が必要な依存プログラムがすべて列挙されます。プラットフォーム再構築対象プログラムについては、同様の分析によって、一貫した処理が必要なプログラム間の依存関係を生み出す共有データセットと共有サブプログラムが特定されます。
エンタープライズ検索機能により、プログラム全体にわたってインベントリ全体をクエリできます。特定のCICSコマンドを使用するすべてのプログラム、特定のVSAMクラスタにアクセスするすべてのプログラム、特定のデータ構造を定義するすべてのコピーブックを、数百万行のCOBOLコードから数秒で検索できます。
この決定を正しく下す組織は、プロジェクト計画の仮定ではなく、構造的証拠に基づいて決定を下す組織です。構造的証拠とは、 SMART TS XL を生成します。
