COBOLの移行テストで何を確認する？新旧比較・差異調査の仕事と経験の伝え方
COBOLから別の言語や環境へ移すプロジェクトでは、テストの担当範囲を具体的に確認する必要があります。手順に沿って実行する仕事なのか、比較するデータを作るのか、結果の違いを調べて修正まで行うのかで、求められる経験が変わるからです。
LegacyForceの掲載案件と登録エンジニアの実例を手がかりに、COBOL移行テストの募集を読むポイントを整理します。
LegacyForceの掲載案件では、テストと不具合対応が同じ募集に含まれる
販売管理システムのモダナイゼーション案件では、結合・総合テストに加え、COBOLとC#双方の不具合対応、移行計画、文書作成が担当範囲です。求めるスキルにはCOBOL、JCL、C#の開発経験が記載されています。
この募集は、COBOLを読めればテストだけを担当できる、と解釈してよい内容ではありません。移行先の言語についても開発経験が求められています。自分の経験と照合する際は、歓迎スキルと必須の条件を分けて確認してください。
登録エンジニアの経験：移行先の開発より、現行COBOLを読み解く役割だった
LegacyForceの登録エンジニアから、COBOLからVB.NETへの移行について伺ったとき、本人が強調していたのは、移行先の言語でどれだけ開発したかではありませんでした。
登録エンジニアのコメント（発言要旨）
COBOLの内容が分からない方が多く、現行システムを解析して詳細設計書を作っていました。結合テスト・総合テストのケースを作り、テストも実施しました。経歴書にはVB.NETと書いてありますが、自分で手を動かして作ることより、設計書を作ることの方が多かったです。
この方は、リリース後の問い合わせ対応や、利用者への新しい要件の確認にも携わっていました。経歴にある「VB.NETへの移行」という言葉だけでは、こうした役割までは読み取れません。
キャリアを振り返る中では、別言語の案件で開発を学びたい気持ちもあったものの、設計書を作る役割を任され、その後は顧客との打ち合わせや要件定義にも関わっていった経緯を話しています。直近に書いている言語だけを見れば、長く積み上げた解析や設計の経験を見落としかねません。
LegacyForceの見方
この実例で私たちが注目するのは、現行COBOLを理解し、移行先の設計や確認作業へつなげていた点です。「移行先言語を主に実装する人」と「現行の処理を読み解き、設計・テストへ渡す人」では、同じ移行プロジェクトでも役割が違います。
案件を紹介するときも、COBOLを使った年数だけでなく、何を解析し、どんな設計書やテストケースを作ったかまで伺うことで、担当できる仕事が見えやすくなります。前述のC#案件とは別の実例であり、その案件の必須条件を満たすことを示すものではありません。
この登録者の経験は、COBOL経験者向けの記事でも紹介しています。
新旧比較は、最初に「何を一致させるか」を決める
新旧の出力を比較する前に、入力条件、処理日、マスタの状態など、比較の前提をそろえます。そのうえで、完全一致させる項目と、仕様変更によって差が出る項目を整理します。
例えば、出力に実行日時が入る場合、その差をどう扱うかを事前に決めないと、比較結果が意図した差で埋まってしまいます。逆に、合計値だけを比べていると、明細単位のずれを見落とす可能性があります。
次の表は、編集部が作成した架空の請求処理の比較例です。特定の案件のテスト仕様ではありません。
| 観点 | 準備する例 | 確認したい結果 |
|---|---|---|
| 通常の取引 | 対象期間に発生した売上 | 対象明細、件数、請求額が合うか |
| 締め日の境界 | 締め日前後の取引 | 当月・翌月の扱いが定義どおりか |
| 取消・返品 | 元の取引と、その取消・返品 | 対象や金額の反映先が合うか |
| 金額の端数 | 端数が生じる計算条件 | 合意した丸め方・計算順で一致するか |
| 対象なし | 入力がゼロ件の状態 | 不要な出力や前回値の持ち越しがないか |
| 再実行 | 中断後のやり直しを想定した条件 | 重複・欠落が生じないか |
すべての案件でこの表をそのまま使えるわけではありません。対象の業務仕様と移行方針に合わせ、必要な条件を選び直します。
差が出たときは、入力から順に追う
結果が違っていても、直ちに移行先のプログラムの不具合とは限りません。比較に用いたデータ、設定、処理順、仕様変更などを確認します。
差異の記録には、少なくとも「再現条件」「期待した結果」「実際の結果」「調べた範囲」「未確認の点」を残します。対応者へ渡す際にも、旧システムがこう動くという事実と、その動きが業務上正しいという判断を分けておくと、議論が進みやすくなります。
現行動作をそのまま維持するのか、既知の問題を移行と合わせて直すのかは、プロジェクトで決めることです。テスト担当者が独断で仕様を変更するのではなく、判断が必要な差を明確にして承認につなげます。
JCLや運用の経験を持つ方は、プログラム単体の入出力だけでなく、前後のジョブ、ファイルの受け渡し、処理日などを確認してきた経験も整理してください。ただし、担当したことがない運用設計まで経験として広げる必要はありません。
応募前に確認したい、テスト担当の五つの仕事
1.設計：テスト観点やケースを作るのか、既存の手順を使うのか。 2.準備：入力データ、マスタ、検証環境を誰が用意するのか。 3.実施・比較：実行だけでなく、結果比較や証跡整理まで含むのか。 4.調査・修正：差異の原因調査や、移行先言語の修正まで任されるのか。 5.移行：リハーサルや本番切替、移行後確認も担当するのか。
本番切替の作業が含まれる場合は、作業日時、出社先、戻し判断の担当者も確かめます。募集に「テスト」とあっても、役割や勤務条件はその一語では決まりません。
長年の保守経験を、移行テストの仕事につなげる
LegacyForce編集部は、COBOLを長く扱ってきた方に、言語経験と合わせて「結果の違いをどう説明してきたか」を振り返ることを勧めます。
仕様と実装の違いを調べた、締め処理の例外を業務担当者に確認した、障害の再現条件を整理した。そうした経験は、移行のどの役割に生かせるかを検討する材料になります。採用や参画を保証するものではありませんが、経験を相手が判断できる形にする助けになります。
