COBOLシステムの移行方法と費用の考え方
COBOLで作られた基幹システムを今も使っている企業では、「COBOLがわかる担当者が定年を迎える」「保守を頼んでいるベンダーから体制縮小の話が出た」「メインフレームの更新費用が重い」といった悩みが表面化しています。一方で、長年安定して動いてきたシステムを移行することには、費用面でもリスク面でも慎重になるのが当然です。
この記事では、COBOLシステムの移行が求められる理由、代表的な移行方法とそれぞれの特徴、費用を左右する要因と見積もりの考え方、移行を成功させるための進め方を解説します。
- COBOL移行の主な方法は、COBOLのまま基盤を移す、他言語へ変換する、作り直す、パッケージへ置き換えるの4つです。
- 費用はプログラムの量（本数・行数）だけでなく、仕様の可視化状況とテストの範囲で大きく変わります。
- 見積もりの前に、現行資産の棚卸しと不要プログラムの洗い出しを行うと、費用とリスクを抑えられます。
- 全体を一度に移すより、機能ごとに方法を選び段階的に移行する方が失敗しにくくなります。
目次
COBOLシステムの移行とは
COBOLシステムの移行とは、COBOL（1959年に登場した事務処理向けのプログラム言語）で作られたシステムを、現在の技術で保守・運用できる環境や言語へ移し替えることです。COBOLは大量のデータを正確に処理するのが得意で、金融・保険・製造・流通などの基幹システムで長く使われてきました。
COBOLそのものが悪い言語というわけではありません。問題は、COBOLを扱える技術者の減少と、長年の改修で仕様がわからなくなった「ブラックボックス化」が重なり、システムを変えたくても変えられない状態になっていることです。
COBOL移行が求められる主な理由
加えて、クラウドサービスやWebシステムとの連携が難しい、帳票やデータを柔軟に出力できない、といった業務上の制約も移行を検討するきっかけになります。
COBOLシステムの4つの移行方法
| 移行方法 | 内容 | メリット | 注意点 |
|---|---|---|---|
| COBOLのまま基盤を移す（リホスト） | メインフレームからLinuxなどのオープン系サーバーやクラウドへ移し、COBOLのまま動かす | プログラムの変更が少なく、短期間・低リスク | COBOL技術者が必要な状況は変わらない |
| 他言語へ変換する（リライト） | 変換ツールと人手でJavaなどに書き換える | 技術者を確保しやすくなる | 変換後のコードが読みにくく、設計の問題も引き継ぐ |
| 作り直す（リビルド） | 業務を整理し直し、新しい設計・技術で開発する | 業務改善と拡張性の向上を同時に実現 | 費用・期間が最も大きく、現行仕様の解明が必要 |
| パッケージへ置き換える | ERPや業種向けパッケージ、SaaSへ移行する | 保守や制度対応をベンダーに任せられる | 業務を製品に合わせる必要がある |
各手法の一般的な考え方は、レガシーマイグレーションの記事でも解説しています。COBOL移行の場合、メインフレーム固有の仕組み（ジョブ制御言語やデータファイル形式、画面制御など）の移し替えも必要になる点が特徴です。
関連記事レガシーマイグレーションの手法（リホスト・リライト・リビルド）
移行対象はプログラムだけではない
- COBOLプログラム：オンライン処理とバッチ処理（夜間の一括処理）の両方
- JCL（ジョブ制御言語）：バッチ処理の実行順序や条件を記述したもの
- データ：独自のファイル形式や文字コード（EBCDICなど）の変換が必要
- 画面・帳票：端末画面や専用プリンター向け帳票の再設計
- 外部連携：他システムや取引先とのファイル授受の方式
COBOL移行の費用の考え方
COBOL移行の費用は、一律の相場で示すのが難しい分野です。同じプログラム量でも、仕様書の有無や品質、テストに必要な範囲によって費用が数倍変わることがあります。見積もりを比べる際は、次の要因を押さえておきましょう。
上の図は、リライト型の移行で費用がかかりやすい工程の相対的なイメージです。とくに見落とされやすいのがテストです。移行では「現行と同じ結果が出ること」を証明する必要があり、現行システムと新システムに同じデータを流して出力を比較する「現新比較テスト」に大きな工数がかかります。
費用を左右する主な要因
| 要因 | 費用が上がる条件 | 費用を抑える工夫 |
|---|---|---|
| プログラム量 | 本数・行数が多い、似たプログラムが重複している | 使われていないプログラムを特定して移行対象から外す |
| 仕様の可視化 | 設計書がなく、処理内容を解析から明らかにする必要がある | 解析ツールで資産を可視化し、調査範囲を絞る |
| テスト範囲 | 全機能を網羅的に比較する必要がある | 業務上重要な処理に重点を置き、テストデータを早期に準備 |
| 移行方式 | 一括で全システムを切り替える | 機能単位で段階的に移行し、リスクと費用を分散 |
見積もりでは、人月単価（PM 100万〜160万円、SE 80万〜120万円、PG 60万〜100万円が目安）に工数を掛けて算出されるのが一般的です。複数社の見積もりを比べる際は、金額だけでなく、調査・テスト・データ移行がどこまで含まれているかをそろえて確認しましょう。
見積もりを比較するときの注意点
COBOL移行の見積もりは、会社によって前提条件が大きく異なるため、金額だけを並べても比較になりません。たとえば、ある会社は変換作業だけを見積もり、別の会社は調査からテスト、データ移行、稼働後の保守まで含めている、ということがよくあります。見積もりを依頼する際は、対象範囲（プログラム・JCL・データ・帳票）、テストの方法と範囲、現行ベンダーとの調整を誰が担うか、稼働後の不具合対応期間を明記してもらい、条件をそろえて比べましょう。
COBOL移行を成功させる進め方
- 現行資産の棚卸しプログラム・JCL・データ・帳票・連携の一覧を作り、利用状況を調べる
- 不要資産の削減使われていないプログラムや帳票を特定し、移行対象から外す
- 方式の決定機能ごとにリホスト・リライト・リビルド・パッケージ化を振り分ける
- パイロット移行一部の機能で試験的に移行し、方式・費用・品質の見通しを確かめる
- 本格移行と現新比較段階的に移行し、出力比較で同一性を確認してから切り替える
よくある質問
- COBOLのまま使い続けることはできますか？
- 可能です。オープン系サーバーやクラウド上でCOBOLを動かす環境もあり、基盤だけを移して使い続ける選択肢もあります。ただし、COBOL技術者の確保という課題は残るため、中長期の保守体制を合わせて検討しましょう。
- COBOLからJavaへの自動変換だけで移行できますか？
- 変換ツールで多くの部分を自動変換できますが、変換できない部分の手修正や、現行と同じ結果になるかのテストは必ず必要です。変換後の保守性も確認し、必要に応じて整理を行います。
- COBOL移行の見積もりを取る前に準備すべきことは？
- プログラムやJCLの本数、データ量、利用している帳票、外部連携の一覧をできる範囲で用意しておくと、見積もりの精度が上がります。使われていない機能がわかっていれば、それも伝えましょう。
まとめ
COBOLシステムの移行は、技術者不足とブラックボックス化に対応するための重要な取り組みです。移行方法にはリホスト、リライト、リビルド、パッケージ化があり、費用はプログラム量だけでなく、仕様の可視化状況とテスト範囲で大きく変わります。まずは現行資産の棚卸しと不要資産の削減から始め、パイロット移行で見通しを立てて段階的に進めましょう。
この記事に関連するサービス
システムリプレイス
老朽化したシステムやサポートが終わるシステムを新しく置き換えます。仕様書がないシステムも、画面・データ・プログラムの解析から対応し、段階的な移行で業務を止めずに切り替えます。 サービスの詳細を見る
