「COBOLからの移行にはいくらかかるのか」は、どの取締役会も最初に尋ねる質問です。そして正直な答えは、コードベースの規模だけでは決まらないということです。本ガイドでは、英国におけるCOBOL移行費用を実際に左右する要素、現実的な予算と期間のレンジ、そして綿密に計画されたプロジェクトを予算超過に変えてしまうリスクを分解して解説します。
TL;DR
- 英国における中規模のCOBOL移行は通常 200,000 ~ 800,000 ポンドの費用がかかり、1~2 年を要します。メインフレームの完全な廃止は数百万ポンド規模で複数年に及びます
- 費用は生の行数よりも、コードベースの複雑さ、文書化されていない業務ロジック、データアクセス層の再設計によってはるかに大きく左右されます
- ターゲット言語と移行アプローチの選択は予算を明確に変えます
- プロジェクトが予算超過する最も一般的な理由は、スコープの過小評価であり、とくに文書化されていない業務ルールとデータアクセス層です
COBOL移行費用を実際に左右するもの
行数は見出しの数字ですが、それ単独では弱い予測指標です。真のコスト要因は次のとおりです。
規模ではなく複雑さ。 100,000行のクリーンなバッチプログラムからなるシステムは、EXEC CICS、動的な CALL、複雑な REDEFINES が密集した50,000行のシステムよりも移行が安価です。トランザクション処理システムは、同じ規模のバッチシステムよりも費用がかかります。
文書化されていない業務ロジック。 COBOLシステムは、外部ドキュメントのないまま30~40年分の業務ルールがコードに埋め込まれていることがよくあります。それらのルールを再発見して検証する作業は、しばしば単一で最大かつ最も予測しにくい費用項目となります。
データアクセス層。 DB2に対する EXEC SQL やVSAMのファイル処理が自動的に変換されることはめったにありません。ターゲットプラットフォームのデータアクセス技術上に再設計する必要があり、これは業務ロジックの発見に次いで最大の作業項目となることが多いです。
データ形式の変換。 パック10進数(COMP-3)、EBCDICエンコーディング、固定長レイアウトはすべて、明示的なマッピングと実データによるテストが必要です。
ターゲット言語とアプローチ。 これらは予測可能な形で予算を動かします(以下で解説)。
テストとカットオーバー。 出力の一致を証明する回帰テストスイートの構築と、ロールバックを備えた安全なカットオーバーの実行は、経験の浅い見積もりが省いてしまう、現実的で決して些細ではない作業量です。
費用と期間の目安レンジ(英国)
これらのレンジは、分析・移行・テスト・本番稼働支援を対象とします。継続的な運用コスト、トレーニング、プロジェクト途中で浮上しがちな下流の統合作業は含みません。
| システム規模 | アプローチ | 推定費用 | 一般的な期間 |
|---|---|---|---|
| 小規模(50,000行未満) | 並行リライト | 80,000 ~ 200,000 ポンド | 3 ~ 9 か月 |
| 中規模(50,000 ~ 500,000行) | Strangler fig | 200,000 ~ 800,000 ポンド | 12 ~ 24 か月 |
| 大規模(500,000行以上) | 自動化 + 段階的リファクタリング | 500,000 ~ 2,000,000 ポンド超 | 2 ~ 4 年 |
| レガシーメインフレームの廃止 | 全体プログラム | 1,000,000 ~ 10,000,000 ポンド超 | 3 ~ 5 年超 |
これらは見積書ではなく、計画用のレンジとして扱ってください。適切な見積もりにはコード評価が必要です。各帯域内の幅は、上記の複雑さの要因によって決まります。
ターゲット言語が費用に与える影響
移行先の言語は、工数プロファイルと長期的な保有コストの両方を変えます。おおまかに言えば次のとおりです。
- Python はCOBOLの手続き型スタイルに自然に対応し、開発者人口が最大であるため、変換コストと長期的な保守コストを下げる傾向があります。
- C# は、すでに.NETおよびAzureスタックを採用している組織にとって効率的で、ネイティブの
decimal型が金融精度を正しく扱う工数を削減します。 - Java はJVMベースの企業に適しています。
BigDecimalは精度を正しく扱いますが、いくらか冗長さが増します。 - Go はビルドとデプロイが効率的ですが、ネイティブな10進数型がないため、金融フィールドのレビュー工数が増えます。
- Rust は、その所有権モデルが前段の設計工数を増やすため、どの規模帯でも上限寄りになる傾向があります。
COBOL移行の概要 では、選択の助けとなるよう、6つのターゲット言語をすべて横並びで比較しています。
移行アプローチが費用に与える影響
- 自動変換 は機械的な翻訳工数を削減しますが、完成したシステムを生み出すことは決してありません。ツールが指摘する手作業(埋め込みSQL、CICS、動的呼び出し、10進精度)のための予算を確保してください。
- 並行リライト は2つのシステムを同時に稼働させるため、移行期間中の運用コストがおおよそ倍増しますが、継続性リスクを最小化します。小規模でミッションクリティカルなシステムに適します。
- 段階的(strangler fig ) は、より長いハイブリッド期間を代償に、費用を時間的に分散させ、ビッグバンのリスクを低減します。英国の大規模エンタープライズシステムでは最も一般的なアプローチです。
現実のプロジェクトのほとんどは、自動変換と段階的なロールアウトを組み合わせます。
予算超過を引き起こすリスク
移行は予測可能な理由で予算を超過します。主要な5つは次のとおりです。
- 過小評価された業務ロジックの発見。 ルールはドキュメントではなくコードの中にあります。明示的な発見時間を予算に組み込んでください。
- データアクセスの再設計。 DB2とVSAMのアクセスは自動的に移植されません。独立した作業ストリームとして扱ってください。
- 不十分な回帰テスト。 実データでの出力一致テストなしには、移行が正しいことを証明できません。移行を始める前にテストスイートを構築してください。
- 10進精度の誤り。 浮動小数点型にマッピングされた金融フィールドは、静かに金額を破損させます。ターゲット言語の正しい10進型にマッピングしてください。
- カットオーバーの失敗。 本番への切り替えは最もリスクの高い瞬間です。ロールバックと突合を備えた詳細なカットオーバー計画は必須です。
正確な見積もりを得る方法
信頼できる数字は、行数ではなくコード評価から得られます。優れた評価は、プログラムとコピーブックを棚卸しし、EXEC SQL / EXEC CICS / 動的呼び出しのホットスポットを特定し、業務ロジックの密度を測り、データアクセスの範囲をマッピングします。Mecanik COBOL移行サービス
は、英国企業向けの評価とフルサービスの移行を提供します。IBM z/OS上のメインフレーム資産については、レガシーメインフレーム移行サービス
がコードとあわせてインフラの廃止を担います。
要点
- 英国における中規模のCOBOL移行は通常 200,000 ~ 800,000 ポンドの費用が 1~2 年にわたってかかります。メインフレームの廃止は数百万ポンド規模になります。
- 複雑さ、文書化されていない業務ロジック、データアクセスの再設計は、行数よりもはるかに費用を左右します。
- ターゲット言語と移行アプローチはいずれも、予測可能な形で予算を動かします。
- 予算超過は、発見・テスト・カットオーバーの過小評価から生じます。適切なコード評価が、見積もりの唯一の信頼できる根拠です。
よくある質問(FAQ)
英国でのCOBOL移行費用はいくらですか。 小規模システムは通常 80,000 ~ 200,000 ポンド、中規模システムは 200,000 ~ 800,000 ポンド、大規模システムは 500,000 ポンド以上です。完全なメインフレーム廃止プログラムは 1,000,000 ポンドから数千万ポンドに及びます。レンジ内のどこに位置するかは、行数ではなく複雑さで決まります。
COBOL移行にはどのくらいの期間がかかりますか。 小規模で十分に文書化されたシステムは 3~9 か月です。中規模のエンタープライズシステムは 12~24 か月かかります。大規模なメインフレームプログラムは、完全な廃止まで 3~5 年以上を要します。
COBOL移行費用がこれほど大きく変動するのはなぜですか。 複雑さが桁違いに変動するからです。文書化されていない業務ロジック、埋め込みSQLとCICS、データ形式の変換、ターゲット言語、移行アプローチのすべてが費用を動かします。同じ行数の2つのシステムでも、1桁の差が生じることがあります。
自動変換は費用を削減しますか。 機械的な翻訳工数は削減しますが、完成したシステムを生み出すツールはありません。ツールが手作業として指摘するデータアクセス層、10進精度の判断、テスト、カットオーバーの予算は依然として必要です。
COBOL移行の予算超過の最大の原因は何ですか。 スコープの過小評価、とくに文書化されていない業務ロジックとデータアクセスの再設計です。移行を始める前に出力一致のための回帰テストスイートを構築することが、そのリスクを制御する最も効果的な方法です。
コメント