COBOLのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

COBOLのシステム開発は、現行資産を棚卸しして業務要件を整理し、残す・基盤を移す・新しく作り替える範囲を段階的に決めることが成功の近道です。

COBOLで構築された基幹システムは、金融や保険、公共、流通などの重要業務を支えています。一方で、仕様書の不足、技術者の高齢化、周辺システムとの接続、保守費用の高止まりなどが重なり、刷新を検討する企業が増えています。本記事では、COBOLのシステム開発を実務で進めるために、要件整理から定着までの6フェーズ、方式選定、費用相場、見積もりのチェックポイントを具体的に解説します。

▼全体ガイドの記事
・COBOLのシステム開発の完全ガイド

COBOLのシステム開発の全体像

COBOLのシステムとは、プログラミング言語だけではなく、業務アプリケーション、バッチ処理、オンライン取引、データベース、ジョブ制御、帳票、運用基盤までを含む業務処理の仕組みです。開発や刷新では、COBOLのソースコードだけを見て判断すると、JCL、CICS、DB2、VSAM、IMS、外部ファイル、手作業の運用を見落とすおそれがあります。

代表的な業務は、売上・請求・入出金・口座振替・保険契約・給与・在庫・受発注・生産実績の登録、照合、集計、締め処理、帳票出力です。オンライン処理では高い可用性とトランザクションの正確性が求められ、夜間バッチでは大量データの一括計算や他システムとのファイル連携が行われます。長年の制度改定や業務変更が反映されているため、処理の一つひとつに現場の例外ルールが含まれていることも珍しくありません。

この構成を把握するには、ソースコード、コピー句、JCL、ジョブネット、DB定義、ファイルレイアウト、帳票定義、外部連携、運用手順、障害履歴を一つの資産台帳にまとめます。設計書が残っていても、現行プログラムと一致しているとは限りません。資料と実装、担当者の知識を突き合わせ、どの業務ルールがどの資産に対応するのかを確認することが最初の開発作業になります。

COBOLを使い続ける理由には、長年蓄積した業務ルール、既存データとの整合性、障害時の運用ノウハウ、周辺システムとの接続実績があります。そのため、古い言語だからという理由だけで全面的にJavaなどへ置換する判断は危険です。保守を続けながらAPIで新システムと接続する方法、実行基盤だけを移す方法、特定の業務だけを再構築する方法も選択肢になります。

判断の軸は、技術の新しさではなく、業務の重要度、変更頻度、停止可能時間、技術者の確保、監査要件、データ連携、5年から10年先の運用費です。仕様書が不足している場合は、先にアセスメントと設計書の復元を行います。NTT DATAは2025年の公開情報で、COBOLソースから設計情報を復元し、COBOL有識者による精度評価を組み合わせる取り組みを紹介しています（出典: NTT DATA「レガシーシステムのモダナイゼーションを加速する、生成AIの活用法」、2025年）。生成AIは可視化を助けますが、業務担当者の承認まで自動化するものではありません。

COBOLのシステム開発の進め方

COBOLのシステム開発は、要件整理、方式選定、設計・開発、テスト、稼働、定着の6フェーズで進めると、技術課題と業務課題を分けて管理しやすくなります。各フェーズで成果物と判断基準を決め、次工程へ進む前に関係者の合意を取ることが重要です。特に現行仕様が不明な案件では、最初から全機能を作り始めず、業務単位や移行波単位で小さく検証します。

最初に「COBOLをやめる」という技術目標ではなく、経営と業務の課題を言葉にします。たとえば、保守期限への対応、技術者不足、夜間バッチの長時間化、制度変更への対応遅れ、クラウドやAPIとの接続、運用費の見直しなどです。課題ごとに、現状の数値、目標値、対応しない場合の影響、対応期限、関係部署を整理します。

実務では、資産台帳に「業務名、オンライン画面数、バッチ数、ソース本数、データ量、連携先、実行頻度、停止可能時間、担当者、障害時の復旧手順」を記録します。仕様書がない場合も、ソース、JCL、コピー句、ジョブ実績、帳票サンプル、入出力ファイル、運用者へのヒアリングを集めれば、調査の起点を作れます。要件整理の完了条件は、対象範囲と対象外範囲、重要業務、移行の制約、受け入れ基準が文書化され、業務部門と情報システム部門が承認していることです。

方式選定では、現行COBOLを保守するリテイン、実行基盤だけを移すリホスト、オープン系やクラウド上でCOBOLを動かすリプラットフォーム、内部構造を整理するリファクタリング、Javaなどへ書き換えるリライト、SaaSやERPへ業務を寄せるパッケージ移行を比較します。さらに、APIで新システムから段階利用するラッピングも候補になります。全体を一つの方式に統一せず、業務ごとに使い分ける設計が現実的です。

選定表には、業務適合度、データ移行量、停止可能時間、性能、監査・セキュリティ、COBOL人材への依存、5年間の運用費、ベンダー変更時の移行しやすさを並べます。現行ロジックをそのまま残す必要が強い業務はリホストやリプラットフォーム、業務自体を標準化できる領域はパッケージ、新しい顧客接点やAPI連携が重要な領域は再設計という考え方です。候補方式を1つに決める前に、代表業務でPoCを行い、処理結果と運用負荷を確認します。

設計では、現行処理の移し替えと、業務の再設計を混同しないことが大切です。まず業務フロー、機能一覧、データ項目、コード値、日付・金額の扱い、丸め規則、締め処理、例外処理、権限、帳票、外部連携を基本設計に記録します。次に、現行資産と新機能の対応表を作り、残す処理、廃止する処理、統合する処理、再設計する処理を区別します。

生成AIや静的解析は、ソースコードから呼び出し関係、入出力、変数の意味、設計書のたたき台を作る用途に向いています。AWSは2025年にメインフレーム向けのAWS Transformを一般提供し、分析、文書化、リファクタリングなどを支援する機能を公開しました。2026年にはリファクタリング機能が18リージョンで利用できると案内されています（出典: AWS「AWS Blu Insights is now AWS Transform for mainframe refactor」、2026年）。ただし、AIが生成した設計やコードは、機密情報の扱いを確認したうえで、COBOL有識者と業務担当者がレビューし、承認済みの成果物として管理します。

COBOLの刷新では、画面が表示されるかだけでは合格にできません。機能テストでは、通常処理だけでなく、月末・年度末、閏年、うるう秒を含む時刻処理、負数、ゼロ、最大桁、文字コード、金額の丸め、重複データ、異常終了、再実行、ロールバックを確認します。バッチは処理件数、完了時刻、後続ジョブ、帳票件数、エラー件数を現行と比較します。

テストデータは匿名化した本番相当データと、境界値を含む人工データを組み合わせます。日次・月次・年次の代表期間を選び、入力、途中のデータ状態、出力、監査ログまで比較可能にします。判定基準は「完全一致」だけでなく、許容される差異と理由を事前に定義します。性能テストではピーク時の同時利用者数、バッチ時間、I/O、ネットワーク、障害復旧時間を測定し、数値が基準を満たさない場合は稼働判定へ進めません。

稼働前には、データ移行の手順、本番バックアップ、差分データの取り込み、利用者への通知、休日や夜間の作業体制、監視、問い合わせ窓口、障害時のエスカレーションを決めます。停止できない業務では、旧システムと新システムの並行稼働、二重更新、差分照合、段階リリースを組み合わせます。給与、決済、保険金支払、出荷など、停止が事業へ直結する業務は、切り替え時間の短さだけでなく、旧系へ戻せる時間と条件を重視します。

切り戻し計画には、誰が、どの数値を見て、何分以内に、どの手順で判断するかを書きます。たとえば、残高照合の差異、バッチ遅延、連携エラー、処理件数、応答時間、重大障害の発生を判定項目にし、Go・No-Goの責任者を決めます。本番直前に一度だけリハーサルをするのではなく、移行データの作成から照合、障害時の復旧までを複数回通して、計画と実績の差を修正します。

稼働した時点でプロジェクトを終わりにせず、運用担当者が自力で判断できる状態まで支援します。引き継ぐ資料は、機能仕様書だけでなく、ジョブネット、監視項目、バックアップと復旧、障害対応、データ修正の承認手順、リリース手順、連絡網、変更管理、ライセンス、契約の責任分界まで含めます。旧システムの担当者が退職しても運用できるかを、実際の訓練で確認します。

定着後は、問い合わせ件数、障害件数、バッチ完了時刻、復旧時間、手作業の削減時間、リリース頻度、利用者の処理時間を月次で確認します。セキュリティも継続課題です。IPAの「情報セキュリティ10大脅威 2025」では、組織向けにランサム攻撃、サプライチェーンや委託先を狙った攻撃、脆弱性を突いた攻撃、内部不正などが挙げられています（出典: IPA「情報セキュリティ10大脅威 2025」、2025年）。COBOL刷新でも、古い実行環境だけでなく、特権ID、外部接続、バッチファイル、委託先、バックアップ、監査ログを運用設計の対象にします。

COBOLのシステム開発にかかる費用相場とコストの内訳

COBOLの刷新費用は、ソース本数だけでは決まりません。オンライン画面、バッチ、データベースやファイル形式、帳票、外部連携、データ量、並行稼働、業界規制、停止可能時間、設計書の有無で大きく変わります。以下の金額は、リサーチノートに記載された業務システムの一般的な相場と、COBOL案件で追加されやすい資産分析・データ移行・同値性テスト・並行稼働を踏まえた記事作成用の推定レンジです（出典: リサーチノート「COBOLのシステム」、2026年）。公開見積もりの平均値ではないため、予算計画の起点として使い、アセスメント後に個別見積もりで確定します。

現行資産の棚卸し、影響分析、設計書の復元、業務ヒアリングを行うアセスメントは、300万〜1,000万円程度が一つの目安です。期間は1〜4か月程度ですが、ソース、JCL、DB定義、ジョブ実績、帳票、外部連携をどこまで対象にするかで変動します。資料が不足している、担当者が限られている、複数の基盤や拠点に分散している場合は、調査範囲が増えるため上振れしやすくなります。

この費用を削りすぎると、後工程で未把握の連携や例外処理が見つかり、追加開発や納期延長が起きやすくなります。見積もりを依頼するときは、調査対象の資産一覧、分析レポート、復元する設計書の粒度、業務部門のレビュー回数、次工程で再利用できる成果物を分けて確認します。アセスメントを単なる報告書作成で終わらせず、方式選定とRFPの根拠にすることが重要です。

小規模なCOBOL業務のリホストや準備は1,000万〜5,000万円程度、期間は4〜10か月程度が目安です。中規模の基幹サブシステムをリプラットフォームする場合は5,000万〜2億円程度、期間は8〜18か月程度となります。データ変換、API連携、帳票、性能検証、並行稼働を含めるほど、同じソース本数でも費用は上がります。

COBOLからJavaなどへのリライトやリビルドは、3,000万〜数億円程度、12〜30か月程度が目安です。大規模メインフレーム全体の刷新では、複数業務、災害対策、データ移行、教育、段階リリースを含み、2億〜10億円超、2〜5年程度の計画になる場合があります。これらは案件固有の推定レンジであり、特定の会社や方式の価格を保証するものではありません。自社の対象範囲と制約を明記して、同じ前提で複数社から見積もりを取ります。

初期費用だけでなく、保守契約、商用COBOLランタイム、メインフレームやクラウドの利用料、監視、バックアップ、セキュリティ対策、24時間運用、障害対応、教育を分けて見積もります。リサーチノートでは、業務システムの保守費を初期費用の年10〜20％程度とする一般的な目安が示されています。たとえば初期開発費が5,000万円の場合、保守だけで年間500万〜1,000万円程度が一つの目安になりますが、基盤費や運用体制は別途必要です。

クラウド移行では、従量課金、通信、ログ保管、バックアップ、災害対策、ライセンス、サポートプランを5年分で試算します。逆に、現行COBOLを継続する場合も、技術者確保、保守契約、ハードウェア更新、脆弱性対応、属人化解消の費用が発生します。初期費用が安い方式ではなく、移行費用と運用費用、業務停止や失敗のリスクを合わせた総保有コストで比較します。

COBOLのシステム開発で見積もりを取る際のポイント

見積もりの差は、会社の単価だけでなく、前提条件と対象範囲の差から生まれます。現行資産が見えないまま「COBOLをJavaへ変換する」とだけ依頼すると、後からデータ移行、帳票、ジョブ、例外処理、並行稼働、教育が追加されます。RFPでは、作業範囲と成果物、受け入れ基準、責任分界をできるだけ具体化します。

発注前に、対象業務、対象外業務、画面一覧、バッチ一覧、ソース本数、プログラム間の依存、DB・ファイル定義、データ量、外部連携、帳票、利用者数、ピーク時間、停止可能時間、法令・監査要件を整理します。資料がない項目は「不明」と明記し、調査費用を見積もりに含めるよう依頼します。担当者の記憶だけでなく、ジョブ実績や本番ログ、障害票、帳票サンプルを使うと、見積もりの前提が具体的になります。

成果物も、要件定義書、方式比較表、復元設計書、データ移行設計書、変換後ソース、テスト仕様書、結果証跡、運用手順書、教育資料、ソースコードの権利と保管方法まで指定します。特にAIを使う場合は、入力データを学習に利用しない条件、生成物のレビュー責任、プロンプトや変換ルールの管理、再現可能なテスト記録を契約前に確認します。

複数社へ依頼する場合は、同じ資産台帳、同じ対象業務、同じ移行波、同じテスト範囲を渡し、価格だけでなく提案の前提をそろえます。比較する項目は、COBOL・メインフレーム・JCL・DBの経験、対象業界の業務知識、リホストとリライトの実績、同値性テスト、データ移行、並行稼働、障害対応、移行後の保守体制です。営業説明だけでなく、実際に設計やテストを担当する責任者に質問します。

海外拠点やオフショアを含む体制では、機密データの持ち出し、国内の責任者、品質レビュー、言語や時差、成果物の引き継ぎ、障害時の連絡時間を確認します。2025年12月にはSCSKとFPTジャパンが、COBOL人材の確保やレガシーシステムの継続運用・モダナイズを支援するCOBOL PARKの事業開始を公表しました（出典: SCSK・FPTジャパン「COBOL PARKを設立、事業を開始」、2025年）。こうした新しい支援体制も候補になりますが、自社の基盤と業務で誰が何を担当するのかを提案書で確認することが大切です。

契約前には、アセスメント、要件定義、設計・開発、変換、データ移行、テストデータ作成、性能試験、並行稼働、教育、運用引き継ぎ、ライセンス、クラウド利用料、保守を費目別に分けます。各費目について、固定価格か準委任か、前提が変わった場合の変更手順、追加単価、納期、検収条件、瑕疵対応、ソースコードや設計書の帰属を確認します。金額の安さだけでなく、不確実性をどちらが管理する契約なのかを見ることがポイントです。

移行のリスクは、契約書に書く前に試験で減らします。代表業務のPoCで、入力結果の同値性、バッチ時間、データ変換、障害復旧、切り戻しを実測し、次の移行波へ進む条件を決めます。Go・No-Goの基準、重大障害の定義、切り戻し判断者、追加調査の費用負担、納品後の問い合わせ期間を明文化しておくと、本番直前の責任の押し付け合いを避けやすくなります。

よくある質問（FAQ）

COBOLのシステム開発では、現行資料の不足、移行方式、費用、停止リスクについて質問が多く寄せられます。ここでは、発注や社内検討の前に確認したい疑問へ、実務での判断基準を先に回答します。

使い続けること自体が問題なのではなく、技術者、保守契約、脆弱性対応、性能、災害対策、周辺連携を将来も維持できるかが判断基準です。重要業務を安定して処理でき、後継者と運用費を確保できるなら、保守継続や基盤移行を選べます。人材不足や保守期限が明確なら、まず資産を棚卸しして段階的な移行計画を作ります。

刷新できますが、最初から全機能を一括変換するのではなく、ソース、JCL、DB定義、ジョブ実績、帳票、障害履歴、担当者の知識を集めてアセスメントを行います。静的解析や生成AIで設計書のたたき台を作る方法もありますが、業務担当者とCOBOL有識者が処理結果と業務ルールを確認し、承認した設計情報だけを後工程で使います。資料不足を前提にした調査費と期間を見積もることが大切です。

AIや自動化で分析、文書化、変換、テストの一部を効率化できる可能性はありますが、費用が必ず下がるとは限りません。COBOLとJavaではデータ型、エラー処理、ジョブ制御、トランザクション、設計思想が異なるため、変換後のコードレビュー、再設計、同値性テスト、運用教育が必要です。機密データの入力可否、生成物のレビュー責任、テスト証跡を確認し、代表業務のPoCで効果を検証してから全体へ広げます。

アセスメントは300万〜1,000万円程度、小規模なリホストは1,000万〜5,000万円程度、中規模のリプラットフォームは5,000万〜2億円程度、リライトやリビルドは3,000万〜数億円程度が推定レンジです。大規模刷新では2億〜10億円超になる場合もありますが、いずれもソース本数、業務範囲、データ量、並行稼働、テスト、停止制約で変動します。公開平均ではないため、対象資産を整理したRFPで複数社へ個別見積もりを依頼します。

まとめ

COBOLのシステム開発では、言語を残すか捨てるかを先に決めるのではなく、業務の重要度と将来の運用条件から方式を選びます。要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズを分け、各工程の成果物とGo・No-Go基準を設定すると、技術者の経験や曖昧な記憶だけに頼らず計画を進められます。

まず、ソースコード、JCL、DB、ジョブ、帳票、外部連携、運用手順、障害履歴を棚卸しし、仕様書がない部分を明らかにします。そのうえで、代表業務のPoCと移行リハーサルを実施し、データ同値性、性能、復旧、セキュリティを確認します。費用はアセスメント、開発、移行、テスト、並行稼働、保守に分け、根拠のあるレンジで比較することが大切です。

成功のポイントは、全面刷新を急がず、業務単位で方式を使い分け、現行と新システムの比較可能なテスト証跡を残すことです。AIは設計書復元やコード分析を助ける道具として活用し、最終判断は業務担当者と技術者が行います。稼働後も運用資料、教育、監視、脆弱性対応、後継者育成を続けて、システムを組織の中に定着させます。

▼全体ガイドの記事
・COBOLのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。