PART 03 — 分離作業の全体像とリスク把握
調査 → 抽出 → 再構成 → 検証 の4ステップ

手順を決めずに分離作業に着手して、途中でどこまで進んだか分からなくなったことがあります。調査・抽出・再構成・検証という4ステップに落とし込んだことで、ようやく全体像が見えるようになりました。

作業フローの全体像（4ステップ）

モジュール分離作業は以下の4ステップで進めます。各ステップは順番に進めることを推奨しますが、手元の情報量によってはステップを短縮できる場合もあります。

1. 1
   調査 — 何が残っているかを確認する

   ロードモジュール・オブジェクトファイル・コンパイルリスト・リンカーマップ・コピーブックのうち何が手元にあるかを棚卸しする。残存している成果物の種類によって、後続ステップで使える手法が決まる。
2. 2
   抽出 — シンボル・構造情報を取り出す

   コンパイルリストやリンカーマップからエントリポイントを特定し、依存関係グラフを作成する。ツールを使った静的解析・逆コンパイル・実行時トレースを組み合わせてモジュール境界を確認する（PART 04〜05）。
3. 3
   再構成 — ソースファイルに落とし込む

   PROGRAM-ID・ENTRY 文を単位としてファイルを分割し、命名規則・ディレクトリ構成を決めてソースツリーを組み上げる。コピーブックの整理・重複排除もここで行う（PART 06）。
4. 4
   検証 — 等価性を確認する

   再コンパイルして差異がないか確認し、入出力比較テストで元のロードモジュールと同等の動作をすることを検証する。回帰テストがない場合の代替アプローチも PART 07 で解説する。

作業前に確認すべき最低限の情報

• 対象モジュールのビルド環境（コンパイラ・バージョン・OS）
• ロードモジュールの配置場所と取得権限
• コンパイルリスト・リンカーマップが残っているか
• コピーブックが別途管理されているか
• 本番環境と検証環境の分離状況（作業は必ず非本番で）
• バックアップの取得（作業前にロードモジュールをコピー）
• テストデータ・入出力比較に使えるサンプルがあるか
• 元の担当者・設計書・仕様書へのアクセス可否

「壊してはいけないもの」を先に定義する

分離作業中に最も避けるべきは、現行の本番動作への影響です。以下を作業開始前に明確にしてください。

保護対象	具体的な行動
本番ロードモジュール	作業前に別ライブラリへコピーし、元のPDSメンバー・ファイルには一切手を触れない。
本番データ	入出力テストは必ずマスクしたテストデータで実施。本番DBへの接続はしない。
他モジュールへの依存関係	CALL 先のモジュールを誤って上書きしないよう、依存関係グラフを先に作成する。
元の成果物一式	コンパイルリスト・リンカーマップ・コピーブックは変更せずコピーして使う。

リスクマトリクス

リスク	影響度	発生しやすさ	対策
本番モジュールの誤上書き	高	中	作業ディレクトリを本番から完全に分離。変更前バックアップを必須化。
コンパイラ方言の差異による再コンパイル失敗	中	高	PART 08で詳説。コンパイラバージョンをロードモジュールから特定して揃える。
コピーブック不足によるデータ構造の欠落	高	中	コンパイルリストの展開後ソースからコピーブックを逆生成する。
最適化によるモジュール境界の消失	中	中	実行時トレースと静的解析を併用してエントリポイントを補完する。
EBCDIC / 文字コード変換ミス	中	低	ファイル転送時のコード変換設定を確認。PART 08参照。

COBOL分離作業でよくある失敗パターン

COBOL分離プロジェクトは段階的なリスク管理が不可欠です。準備不足や見積もりミスが原因でプロジェクトが失敗するケースを整理します。

誤り/失敗パターン	何が起きるか	正しい対処/防止策
依存関係を調査せずに分離を始める	共有データエリアや暗黙の連携を断ち切り、分離後に予期しない異常が多発する	作業前にリンカーマップとCALLグラフを作成し、全依存関係を可視化してから分離範囲を確定する
バックアップと元の動作記録なしに改修する	問題が発生しても元の状態に戻せず、調査が長期化してビジネス影響が拡大する	改修前にソース・ロードモジュール・テストデータを完全バックアップし、期待出力を記録してから着手する
並行稼働検証期間を設けずに本番移行する	分離前後の挙動差が本番でしか検出できず、重大インシデントに発展する	旧モジュールと新モジュールを並行稼働させ、同一入力データで出力を比較する検証フェーズを必ず設ける