COBOLのリバースエンジニアリングを外注する流れは、発注前の社内準備、RFP（提案依頼書）の作成から契約までの進め方、契約後のプロジェクト推進の順です。
特にJCL・DB2・VSAMといったホスト固有の仕様が絡む場合は、発注者側も相応の専門知識を持ってベンダーと対話する必要があります。
▼全体ガイドの記事
・COBOLのリバースエンジニアリングの完全ガイド
AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。
外注前に発注側が準備すべき5項目
COBOLのリバースエンジニアリング発注を成功させるための第一歩は、ベンダーに問い合わせる前の社内準備です。社内準備が不十分なまま発注すると、見積もりを正確に比べられず、契約後に追加費用が発生したり、成果物が使い物にならなかったりします。発注側が事前に揃えておくべき5つの項目を、下に挙げます。
- 対象システムとソース資産の棚卸
- 目的と成果物要件の明確化
- 業務部門を巻き込む体制の整備
- 情報セキュリティ体制の整備
- 発注条件と確認事項の社内共有
これら5項目を発注前に整えておくと、プロジェクト全体の成功確率を大幅に高められます。
準備1：対象システム・ソース資産の棚卸
最初に行うのは、解析対象のCOBOLシステムに関する基本情報の棚卸です。この情報がなければ、ベンダーは正確な見積もりを出せず、概算では大きな誤差が生じます。棚卸では、ソースファイル一覧（ファイル名・LOC・作成日・最終更新日）、プログラム間の呼び出し関係（CALLチェーン）、JCL一覧（バッチジョブ定義）を整理します。
加えて、使用しているDB2テーブル・VSAMファイルの一覧や、稼働プラットフォーム（IBM z/OS・富士通FUJITSU・日立HITAC・オープン系COBOLなど）も洗い出します。資産棚卸ツールとして、現行システムのJCL・ソース間の依存関係を自動解析するIBM ADDIなどの専門ツールを活用することも、選択肢の一つです。
棚卸の過程で「ソースが見つからないプログラムがある」「バージョン管理されていないため最新版が不明」という問題が発覚するケースも多くあります。そのため、こうした状況を把握したうえでベンダーに情報を提供すると、見積もりの精度が高まります。
準備2・3：目的の明確化と成果物要件の定義
発注側は、解析の目的（モダナイゼーション向け仕様書復元・継承・脆弱性診断）と、成果物に期待する粒度（フローチャート・業務機能仕様書・詳細設計書）を社内で合意しておく必要があります。「とりあえず設計書を作ってほしい」といった依頼では、ベンダーごとに粒度の解釈が分かれ、後から「これでは使えない」というトラブルの原因になります。
そのため、成果物の粒度は「この文書を基に新システムの設計ができる状態か」という観点で定義することが大切です。また、成果物に含める必須項目として、「変数名・データ項目の業務的意味の説明」「業務ロジックのWhy（なぜその仕様か）の文書化」「例外処理の業務的意味の説明」の3つを、要件として明示することを強く推奨します。
成果物要件にこれらが含まれないと、技術的な処理フローは分かっても業務の意図が不明なまま移行作業が進み、移行後のバグの原因になります。COBOLのHow（どう動くか）はコードを読めば把握できますが、Why（なぜその仕様か）の把握は業務部門の協力なしには不可能です。そのため、発注側もこの部分への投資を明確に予算化する必要があります。
準備4・5：業務部門の巻き込み体制と情報セキュリティ体制の整備
COBOLのリバースエンジニアリングは、IT部門だけで完結するプロジェクトではありません。業務ロジックのWhyを解明するには、業務部門の担当者がヒアリングに協力する体制が欠かせません。
そのため、発注前に業務部門のキーパーソン（受発注担当・在庫管理担当・経理担当など、解析対象の業務に精通する人物）をプロジェクトに巻き込み、ヒアリングへの対応工数を確保してもらう合意を得ておく必要があります。また、情報セキュリティ体制の整備も、発注前の重要な準備事項です。
COBOLのソースコードは機密性の高い業務ロジックや顧客データ処理の実装を含むため、ベンダーへの開示範囲とセキュリティ要件（NDA締結・情報取扱規程・アクセス制御）を事前に決めておきます。さらに、著作権法第30条の4の「非享受目的」を立証するため、解析専用環境を用意し、解析過程の記録体制もベンダーと協議のうえで合意しておきます。
発注の進め方（RFP作成〜契約）
準備が整ったら、RFP（Request for Proposal：提案依頼書）を作成してベンダーに発信し、評価・選定を経て契約に進みます。なお、COBOLのリバースエンジニアリングのRFPには、通常のシステム開発RFPには含まれないCOBOL固有の記載事項があります。
RFPに含めるべきCOBOL固有の項目
COBOL固有の記載項目としては、まず稼働環境の詳細を明示します。IBMメインフレーム（z/OS）の場合は、OSバージョン、COBOLコンパイラのバージョン、JCLの管理ツール（Tivoli Workload Schedulerなど）を記載します。オープン系COBOLの場合は、使用するコンパイラ（MicroFocus COBOL・GnuCOBOLなど）を明示します。
次に、対象ソースの規模情報として、総ファイル数・総LOC・JCLファイル数・DB2テーブル数・VSAMファイル数を記載します。解析対象の範囲と除外対象も重要な記載項目で、全プログラムを対象にするのか、特定の業務領域（例：受発注管理モジュール）に絞るのかを明確にします。除外するプログラム（例：廃止予定の旧バッチ処理）も示します。
「成果物の詳細要件」には、前述の粒度（フローチャート・業務仕様書・詳細設計書）に加えて、変数名の業務的意味説明、業務ロジックのWhy記述の有無、業務部門ヒアリングの実施可否を明記します。最後に「見積もり方法」では、LOC課金の単価（COBOL固有の複雑さ補正の有無）、ホスト固有仕様解析の追加費用、業務部門ヒアリング工数の含み方を開示するよう求めます。
NDA・クリーンルーム手法の契約条項
COBOLのリバースエンジニアリング契約では、通常のNDAに加えて「クリーンルーム手法の遵守」に関する条項を盛り込むことを検討します。特に、サードパーティが開発したソフトウェアを解析する場合（例：パッケージソフトのCOBOL部分を解析して互換実装を行う場合）は重要です。
契約条項に含めるべき内容は、解析チームと実装チームの分離義務と、解析チームが作成した仕様書が著作権保護対象の「表現」を含まないことの確認義務です。このほか、解析過程の記録保持義務（著作権法第30条の4の非享受目的立証のため）も挙げられます。成果物に関する知的財産権の帰属も、契約で明確化すべき重要事項です。
ベンダーが解析過程で作成したツール・スクリプト・テンプレートの知的財産権や、成果物（仕様書）の著作権が発注者に帰属するかどうか、第三者への開示・使用の条件を明記してください。さらに、COBOLシステムのソースコードや業務ロジックは機密情報として扱い、プロジェクト終了後のデータ廃棄に関する条項も含めることが推奨されます。
プロジェクト推進時の役割分担
COBOLのリバースエンジニアリングは、ベンダー（解析チーム）、発注者IT部門、業務部門の三者が緊密に連携することで、成果が最大になります。そのため、三者それぞれの役割と責任範囲を明確にしておくと、プロジェクトが円滑に進み、情報の断絶によるトラブルも防げます。
IT部門の役割：情報提供・品質確認・プロジェクト管理
発注者IT部門の主な役割は、ソースコード・JCL・DB2スキーマ・VSAMファイル情報のベンダーへの提供と、解析環境（隔離されたテスト環境）の整備です。加えて、成果物のレビューと品質確認、プロジェクト全体のスケジュール管理と進捗報告も担います。
IT部門はCOBOL解析の専門家でなくても、「どのプログラムが何の業務を担っているか」という概要レベルの知識は持ち合わせているはずです。この概要知識をベンダーに提供すると、解析チームは優先度の高い業務領域から効率的に解析を進められます。
成果物レビューでIT部門が確認すべき点は、記述内容の業務的正確性（業務部門と連携して確認）、成果物の粒度が契約要件を満たすか、後続フェーズ（モダナイゼーション実装）で使える品質か、の3点です。技術的な解析精度の確認はベンダーに委ねるとしても、成果物が「使えるものか」という観点のレビューは、発注者IT部門が責任を持って行う必要があります。
業務部門の役割：業務ロジックのWhy提供・仕様書レビュー
業務部門は、COBOLのリバースエンジニアリングにおいて最も重要かつ希少なリソースです。コードを読めば「どう動くか（How）」は分かりますが、「なぜそうなっているか（Why）」は業務部門にしか分かりません。たとえば、「特定の顧客コードの場合に処理を分岐させている」コードがあった場合、その顧客が過去に特別契約を結んでいた経緯は業務担当者でなければ知り得ません。
業務部門の主な役割は、ベンダーからのヒアリングへの対応（質問票への回答・インタビューへの参加）と、業務処理シナリオ（月次バッチ・特定取引条件での動作など）の提供・説明です。加えて、完成した仕様書の業務的正確性をレビューします。
業務部門のヒアリング工数は、プロジェクト規模によって数十時間から数百時間に及ぶことがあります。「業務部門は本来業務があるため時間が取れない」という状況はよくありますが、この工数を削減しようとすると、成果物の品質が著しく低下します。計画段階で業務部門のヒアリング工数を確保し、繁忙期を避けて日程を組むことが、プロジェクト成功の重要な要件です。
よくあるトラブルと回避策
COBOLのリバースエンジニアリングの発注では、同じような失敗が繰り返されています。そのため、よくあるトラブルとその回避策を把握しておくと、発注後の問題を未然に防げます。
トラブル1：LOC見積もりの齟齬による費用超過
最も多いトラブルは、「LOC課金で安く見積もられたが、作業開始後に追加費用が次々に発生した」ケースです。COBOLの1行は他言語と複雑さが異なるにもかかわらず、COBOL経験の浅いベンダーが一般的なLOC単価で見積もることがあります。
その結果、作業着手後に「JCL解析が想定より複雑だった」「業務ロジックのWhyの確認工数が膨大だった」といった理由で、追加費用を請求されるパターンです。回避策としては、見積もり時にCOBOL固有の複雑さ補正を単価に含めているかを確認します。
加えて、JCL・DB2・VSAM解析を含む追加費用の試算を事前に出してもらい、業務部門ヒアリング工数の扱い（見積もりに含むかどうか）も明確にします。
トラブル2：成果物の品質不足と業務ルール欠損
「仕様書が納品されたが、モダナイゼーション実装に使えない」というトラブルも頻繁に起こります。たとえば、フローチャートは作成されていても、変数名の業務的な意味や業務ロジックのWhy（判断根拠）が書かれていない、例外処理の業務的な意味が不明のままといったケースです。
このような成果物で実装を進めると、移行後に業務ルールの解釈ミスによるバグが多発します。そのため、回避策は、RFP段階で成果物の品質基準を詳細に定めることと、プロジェクト開始前にサンプル成果物（数ファイル分）をベンダーに作ってもらい、レビューすることです。
サンプルレビューによって期待する品質水準のギャップを事前に確認し、必要に応じてスコープや費用を調整することができます。
トラブル3：機械変換後のコード品質問題
COBOLからJavaやPythonへの機械変換（自動変換ツールによる変換）を選択した場合、「変換後のコードが若手エンジニアでは保守できない品質だった」というトラブルが発生します。機械変換で生成されたコードは、COBOLの文法やデータ構造をJavaの文法に直訳したものであることが多いです。
そのコードには、変数名が意味不明なままの箇所や、COBOLの業務ロジックをそのまま翻訳した非効率な処理が大量に含まれます。このようなコードは、技術的には動作するものの、保守のたびに大きな工数がかかり、最終的にスクラッチ開発より高コストになるケースが少なくありません。
回避策として、機械変換後のコードを人手でレビュー・改善するリファクタリング工数を計画に含めることと、「変換後のコードが若手エンジニアでも保守可能な品質か」を契約要件に明示することを推奨します。
まとめ
COBOLのリバースエンジニアリングを外注で成功させるには、発注前に十分な準備を整えることが欠かせません。準備には、ソース資産棚卸（解析対象のCOBOLシステムの基本情報を洗い出すこと）、目的と成果物要件の明確化、業務部門の巻き込み体制構築（ヒアリングに協力してもらう体制を発注前に作ること）が含まれます。
RFP作成では、COBOL固有の項目（稼働環境詳細・LOC課金の単価補正・ホスト固有仕様の追加費用・業務部門ヒアリング工数の扱い）を明示します。契約段階では、クリーンルーム手法の遵守、成果物の知的財産権の帰属、データ廃棄条項を含めることが重要です。
プロジェクト推進中は、ベンダー・IT部門・業務部門の三者が緊密に連携し、技術解析（How）と業務理解（Why）を同時に進めることが成功の鍵です。
LOC見積もりの齟齬、成果物の品質不足、機械変換後のコード品質問題という3つの典型的なトラブルを事前に把握しておきます。そのうえで、それぞれの回避策（COBOL複雑さ補正の確認・サンプル成果物レビュー・リファクタリング工数の計画）を発注段階で盛り込むことで、プロジェクトの成功確率を大幅に高められます。
▼開発を相談する前に読みたい無料ホワイトペーパーはこちらをご覧ください。
・【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。