COBOLのシステム開発の発注/外注/依頼/委託方法について

COBOLのシステムを発注・外注するときは、いきなりJavaなどへ全面移行するのではなく、現行資産を棚卸ししたうえで、保守継続・リホスト・リライト・段階移行を業務単位で比較することが重要です。

COBOLのシステムは、プログラムだけでなく、JCL、CICS、DB2、VSAM、IMS、帳票、ジョブネット、運用手順まで含む基幹業務の仕組みです。本記事では、発注形態の選び方、RFPと要件の整理、契約形態、費用相場、委託先の比較、移行中のリスク管理まで、外注を成功させる進め方を解説します。

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

COBOLのシステムを外注する前に決めること

発注の成否は、開発会社の知名度よりも、発注側が何を変え、何を残すかを判断できているかで決まりやすいです。COBOLのシステムでは、ソースコードだけを渡しても、業務ルールやバッチの実行順序、例外処理、手作業の補完まで再現できない場合があります。

最初に、対象を「COBOLのソース」と限定しないことが大切です。対象には、オンライン処理、夜間バッチ、JCLやジョブスケジューラ、CICSなどのトランザクション制御、DB2・IMS・VSAMなどのデータ、外部ファイル、帳票、API、運用監視、バックアップ、障害時の復旧手順が含まれます。給与、請求、決済、保険金、在庫、受発注などの業務では、画面に表示されない締め処理やデータ連携も業務継続を支えています。

仕様書が古い場合や、担当者の退職で知識が失われている場合は、設計書の復元と業務ヒアリングを発注範囲に入れます。AWS公式ドキュメントでは、COBOLだけでなく、コピー句、JCL、CICS、BMS、Db2、VSAMなどを分析対象にし、人が途中で確認する仕組みを備えています。このような資産単位の分析をRFPで求めると、単純なソース変換だけの提案を見分けやすくなります。

目的が「技術者不足の解消」なのか、「メインフレームの保守期限への対応」なのか、「クラウドとAPIで新しいサービスを接続すること」なのかで、選ぶ会社も契約も変わります。技術者不足だけが課題ならCOBOL保守と運用引き継ぎが中心になりますが、業務の再設計まで求めるなら、要件定義から伴走できる会社が必要です。

成功条件は、例えば「月末締め処理を予定時間内に完了する」「旧システムと新システムの金額・件数が一致する」「障害発生時に何時間以内に切り戻せる」「自社担当者が運用手順を理解する」といった検証可能な表現にします。納期や予算だけを成功条件にすると、テストやドキュメントが削られ、リリース後の追加費用につながりやすいです。

COBOLのシステムの発注形態はどれを選ぶべきですか？

結論として、発注形態は「保守継続」「リホスト・リプラットフォーム」「リライト・再構築」「パッケージやSaaSへの移行」「ラッピングによる段階連携」を比較して決めます。全面刷新を前提にせず、業務の重要度、停止可能時間、仕様の明確さ、データ連携の複雑さを評価し、複数の方式を同じ条件で見積もってもらうことが現実的です。

保守継続は、既存COBOLを維持しながら、障害対応、制度改定、帳票変更、周辺連携の改修を委託する形態です。処理結果が安定し、現行基盤の保守契約も有効で、移行による停止リスクが高い場合に適しています。ただし、保守担当者の属人化を放置すると、数年後に同じ問題が再発します。

保守を発注する場合でも、ソースコードの一覧、担当領域、障害の優先度、受付時間、一次切り分けの範囲、月次の改善提案、設計書の更新方法を契約に記載します。単なる人月の確保ではなく、運用手順と仕様の蓄積を成果物に含めると、将来の移行準備にもなります。

リホストは業務ロジックを大きく変えずに実行基盤を移す考え方で、リプラットフォームはCOBOL資産やデータ構造を活かしつつ、オープン系やクラウドで動かせる状態に整える考え方です。業務ルールの変更を抑えたい企業では、リライトよりも検証範囲を絞りやすい場合があります。

一方で、基盤を変えれば終わりではありません。文字コード、日付、10進数の精度、ソート順、ファイルロック、バッチの実行時間、印刷制御が変わる可能性があります。現行と移行後の入出力を同じデータで比較する同値性テストと、ピーク時の性能試験を発注条件に入れます。

COBOLからJavaなどへ書き換えるリライトや、業務要件から新たに設計する再構築は、API連携、クラウド活用、開発者の採用、画面の改善を進めやすい発注形態です。古い処理をそのまま別言語へ移すだけでなく、不要な機能や重複データを整理できる点に価値があります。

ただし、ソースコードの自動変換率だけで会社を選ぶと危険です。変換後のコードがコンパイルできても、業務上の例外や締め処理の順序が正しいとは限りません。AWSは2026年6月、COBOLなどの資産分析から要求事項、コード生成までを追跡可能にするワークフローを発表しましたが、公式資料でも人の確認を前提にしています。AIを使う提案では、生成物のレビュー担当、データの持ち出し範囲、テスト証跡、承認者を確認します。

RFPと要件整理はどのように進めますか？

RFPは、委託先に「何を作ってほしいか」だけでなく、「現状の何を理解し、どのリスクをどの方法で下げてほしいか」を伝える文書です。資料が不完全でも問題ありませんが、不完全な部分を隠さず、受注側に調査・分析の提案を求めることが大切です。

RFPには、対象業務、利用部門、オンライン画面数、バッチ本数、COBOLソースの規模、コピー句、JCL、CICS、DB2・IMS・VSAM、ファイル形式、帳票、外部システム、データ量、月次や年次のピーク、停止可能時間を記載します。正確な数字が取れない場合は、現時点の推定値と調査方法を分けて示します。

同時に、業務担当者が知っている例外処理、手作業の補正、Excelや固定長ファイルによる連携、障害時にだけ行う復旧操作も集めます。ソースにない業務ルールを発見できるかどうかが、COBOL案件の見積精度を大きく左右します。機密性が高いデータは、匿名化データや項目定義だけを先に渡す方法も検討します。

機能要件には、登録、照合、集計、締め、帳票、データ連携、権限、履歴、再処理の条件を記載します。非機能要件には、処理時間、同時利用者数、バッチの終了時刻、可用性、バックアップ、災害対策、監査ログ、暗号化、アクセス制御、障害時の復旧時間と復旧時点を含めます。

例えば「月末バッチを朝7時までに完了する」「障害から4時間以内に業務を再開する」「直近24時間のデータを復旧できる」のように、測定方法と合格基準まで書きます。処理速度だけでなく、異常終了からの再実行、途中まで処理したデータの扱い、二重計上の防止も確認対象です。

複数社へRFPを配布するときは、対象範囲、前提条件、データ量、納期、停止可能時間、求める成果物、評価基準、質問期限、提案期限をそろえます。委託先ごとに前提が違うと、安い見積もりが対象範囲を含んでいないだけという事態が起きます。

提案書には、方式の選定理由、工程、体制、担当者の経験、現行分析の方法、移行波、テスト方針、並行稼働、切り戻し、教育、保守、セキュリティ、再委託の有無を求めます。見積書は、アセスメント、設計、変換・開発、データ移行、テスト、リリース、運用引き継ぎ、ライセンス、クラウド費用を分けてもらうと比較しやすいです。

COBOLのシステム開発で契約形態を選ぶポイント

COBOLのシステムでは、契約形態を案件全体で一つに固定せず、調査・要件定義・開発・運用の不確実性に応じて使い分けます。特に現行仕様が分からない段階で、成果物と範囲を確定した請負契約を急ぐと、追加変更や責任分界の争いにつながります。

準委任契約は、受託者が専門知識や作業時間を提供し、発注者と協力して業務を進める形態です。現行資産の棚卸し、設計書の復元、業務ヒアリング、移行方式の比較、PoCなど、開始時点で作業量や論点が読みにくい工程に適しています。

準委任では、完成したシステムの動作保証を契約だけで期待できるとは限りません。月次の成果物、会議体、作業報告、課題管理、レビュー方法、投入する人員、再委託、機密情報の扱い、終了時の引き継ぎを具体化します。時間単価だけでなく、何が残るかを評価します。

請負契約は、合意した成果物を完成させ、発注者が検査・受入を行う工程に向いています。詳細設計、変換プログラム、データ移行ツール、テスト仕様書、操作マニュアルなど、完成物と検査方法が定義できる範囲で採用します。

契約書や個別契約には、対象資産、除外範囲、前提条件、納期、検収基準、瑕疵や不具合への対応、変更管理、遅延時の扱い、知的財産権、ソースコードの納品、データ消去、秘密保持、損害賠償の範囲を記載します。移行後に旧システムを一定期間保守する場合は、開発契約と保守契約の責任分界も分けます。

COBOLのソース、コピー句、データ定義、業務ルール、顧客情報は、発注側の重要な資産です。成果物に含まれるソースコード、変換前後の設計書、テストデータ、生成AIへの入力情報、学習利用の可否、退職者や再委託先へのアクセス権を確認します。

IPAの「情報セキュリティ10大脅威 2025」では、組織向けの1位がランサム攻撃、2位がサプライチェーンや委託先を狙った攻撃、3位がシステムの脆弱性を突いた攻撃です（出典：IPA「情報セキュリティ10大脅威 2025」、2025年）。委託先の会社規模だけで安心せず、特権ID、接続元、ログ保存、脆弱性対応、インシデント報告、再委託管理を契約と運用の両方で確認します。

COBOLのシステム外注費用相場と内訳

COBOLのシステム外注費用は、ソースコードの行数だけでは決まりません。オンライン画面、バッチ、データベース、外部連携、帳票、業界規制、移行後の並行稼働、テストデータの準備、24時間運用の有無によって大きく変わります。以下は公開されたCOBOL案件の平均価格ではなく、一般的な業務システムの相場と、COBOL特有の作業を組み合わせた初期検討用の推定レンジです。

現行資産の棚卸し、影響分析、設計書の復元は、300万円から1,000万円程度が一つの目安です。期間は1か月から4か月程度ですが、資料がなく、複数の基盤や業務領域をまたぐほど上振れしやすいです。ここを省くと、本開発の見積もりが安く見えても、後から追加要件が増えます。

小規模なリホストやリホスト準備は1,000万円から5,000万円程度、中規模サブシステムのリプラットフォームは5,000万円から2億円程度、COBOLからJavaなどへのリライトや再構築は3,000万円から数億円程度が初期検討のレンジです。大規模メインフレーム全体の刷新では2億円から10億円超、期間は2年から5年程度になる場合があります。いずれも方式、規模、テスト、並行稼働を仮定した推定であり、個別見積もりが必要です。

見積書は、アセスメント、要件定義、基本設計、詳細設計、変換・開発、データ移行、テスト、教育、リリース、切り戻し準備、運用引き継ぎに分けます。さらに、商用COBOLランタイム、メインフレーム利用料、クラウド従量課金、監視、バックアップ、セキュリティ製品、24時間対応を別項目にします。

保守費は初期開発費の年10％から20％程度を目安にする考え方があります。例えば初期費用5,000万円の場合、年間保守費は750万円から1,000万円程度という見方もできますが、これは15％から20％を仮定した試算です。人員の待機、ライセンス、クラウド利用料、障害対応の時間外費用を含むかで変わるため、固定額と従量額を分けて確認します。

費用を抑える方法は、最初からテストや調査を削ることではありません。重要度が低い帳票や参照機能を後続波に分け、停止できる業務から先に移行し、現行資産を共通部品として再利用できるかを検討します。業務単位の小さなPoCで、変換率ではなく処理結果、性能、障害復旧の実現性を確かめます。

AIによるコード解析や設計書生成は、棚卸しや依存関係の把握を速める可能性があります。AWSは2025年5月にAWS Transform for mainframeの一般提供を開始し、2026年6月には分析から要求事項、コード生成までを追跡する機能を発表しました（出典：AWS公式発表、2025年・2026年）。ただし、機密情報の入力可否、生成物の品質確認、業務担当者の承認、同値性テストにかかる費用は残るため、AI利用を理由に総額を機械的に下げないことが重要です。

委託先の選定と見積比較で確認するポイント

委託先は、会社名や価格だけでなく、現行基盤、業界知識、移行方式、テスト、運用引き継ぎ、セキュリティ、体制の七つの観点で比較します。COBOLを長く扱ってきた会社でも、保守が得意なのか、クラウド移行が得意なのか、金融・保険・公共などの業務知識があるのかは異なります。

実績を聞くときは「COBOL案件があります」という説明だけで終わらせず、IBM z/OS、富士通系、日立系などの基盤、CICSやJCL、DB2・VSAMなどの周辺技術、対応した業務領域、規模、停止可能時間、移行後の保守体制を確認します。実績を紹介できない場合は、守秘義務に配慮した匿名事例や、提案段階での技術検証を求めます。

最近は、既存資産の可視化と人材確保を組み合わせた支援も増えています。NTT DATAは2025年7月の公式記事で、COBOLソースから設計書を復元し、生成AIとCOBOL有識者で精度を評価する取り組みを紹介しています。また、SCSKとFPTジャパンは2025年12月に「COBOL PARK」の事業開始を発表し、継続運用とモダナイゼーションを支援する体制を示しています（出典：NTT DATA公式記事、2025年、SCSK公式発表、2025年）。提案を比較するときは、こうしたAI活用や人材供給の有無だけでなく、最終的なレビューと国内の責任体制まで確認します。

提案時の責任者が、実際の設計・移行・テストにも参加するかを確認します。営業担当だけが説明し、契約後に別会社や経験の浅い担当者へ作業が移ると、認識のずれが生じやすいです。COBOL有識者、業務アナリスト、データ移行担当、テスト責任者、インフラ担当、運用引き継ぎ担当の役割を、氏名またはスキル条件で明記してもらいます。

見積比較では、総額の安い順に並べるのではなく、同じ対象範囲を含んでいるかを確認します。特に、データクレンジング、移行リハーサル、現行と新システムの並行稼働、利用者教育、帳票の印刷確認、障害時の切り戻し、ドキュメント作成、ソースコード納品が除外されていないかを見ます。

各社の見積もりに、作業項目、工数、単価、前提、除外、リスク、追加費用が発生する条件を記載してもらいます。最安値の提案にだけ「仕様調査は発注者が実施」「テストデータは提供済み」「並行稼働は別途」といった条件がないかを確認します。見積もりの差が大きい場合は、金額の再提示ではなく、前提を同じにした再見積もりを依頼します。

候補を二社から四社程度に絞ったら、提案書だけでなく、現行ソースの一部や匿名化したデータを使った技術対話を行います。会社側が不明点を質問し、リスクを正直に示し、代替案と調査計画を提案できるかを確認します。何でもできますと答える会社より、できない条件と検証方法を説明できる会社のほうが、長期の発注先として信頼しやすいです。

小規模なアセスメントやPoCを有償で依頼する方法もあります。成果物として、資産一覧、依存関係、方式比較、課題一覧、概算費用、移行波案、テスト方針を受け取り、本開発へ進む判断材料にします。PoCの成果物を本契約で再利用できるか、別会社へ切り替える場合に持ち出せるかも契約前に確認します。

よくある質問

ここでは、COBOLのシステムを発注・外注するときに多い疑問へ回答します。個別案件では、現行資産の規模、業務の停止条件、データの機密性、社内の判断体制によって最適な進め方が変わります。

小規模な資産分析は300万円から1,000万円程度、リホストは1,000万円から5,000万円程度、中規模のリプラットフォームは5,000万円から2億円程度が初期検討の推定レンジです。リライトや再構築は3,000万円から数億円、大規模刷新は2億円から10億円超になる場合があります。公開平均価格ではないため、対象資産とテスト範囲をそろえたRFPで個別見積もりを取ります。

外注できますが、最初から本開発を依頼せず、現行資産の棚卸しと設計書の復元をアセスメント工程として発注する方法が安全です。COBOLソース、コピー句、JCL、ジョブネット、データ定義、帳票、運用手順、障害履歴、業務担当者へのヒアリングを組み合わせ、分からない部分を課題として残します。

AIによるコード解析、設計書生成、依存関係の抽出、変換支援で、調査や開発の一部を効率化できる可能性があります。ただし、生成コードの業務妥当性、金額計算や日付処理の同値性、セキュリティ、機密情報の扱い、テスト証跡を人が確認する必要があります。短縮効果は資産の構造とレビュー体制に左右されるため、PoCで実測してから本見積もりに反映します。

候補を二社から四社程度に絞り、同じRFPと資料で比較する方法が現実的です。候補数を増やしすぎると、質問対応や提案評価が浅くなります。基盤、業界知識、移行方式、運用体制が異なる会社を含め、提案の前提条件、費目別金額、体制、リスク、成果物を同じ評価表で確認します。

まとめ

COBOLのシステムを発注・外注するときは、COBOLを残すか捨てるかを先に決めるのではなく、業務単位で保守継続、リホスト、リプラットフォーム、リライト、パッケージ移行を比較します。現行資産の棚卸し、業務ルールの確認、停止条件、非機能要件、テスト基準を整理してからRFPを作成します。

発注前には、対象資産、目的、方式、RFP、契約、費用、体制、非機能要件、同値性テスト、並行稼働、切り戻し、機密情報、成果物の所有権を確認します。決められない項目は無理に確定せず、アセスメントで調査する範囲と、調査後に再見積もりする条件を明記します。

最初から数年規模の刷新を約束するのではなく、現行資産の可視化と小さな技術検証を発注し、方式と費用を具体化します。経営層、業務部門、IT部門、委託先が同じ事実を見ながら次の移行波を決めることで、業務を止めずに段階的な刷新へ進みやすくなります。

契約では、調査や要件定義に準委任、成果物と受入条件が明確な工程に請負を使い分け、データ移行、並行稼働、切り戻し、ソースコード、運用引き継ぎ、機密情報、再委託の扱いを明記します。見積比較では総額の安さではなく、前提と除外をそろえ、基盤・業務知識・テスト・体制・移行後保守まで確認することが重要です。

まずは小さなアセスメントで、資産一覧、依存関係、方式比較、概算費用、移行波、テスト計画を作成します。その結果を社内の経営・業務・ITで共有し、止められない業務を守りながら、無理のない発注計画へ落とし込むことが、COBOLのシステムを安全に外注する近道です。

▼全体ガイドの記事
・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を創業。