COBOLのリバースエンジニアリングの発注/外注/依頼/委託方法について

「COBOLのリバースエンジニアリングをベンダーに依頼したい。でも何をどう準備すればいいか分からない」——そのようなお悩みを持つIT部門のご担当者は少なくありません。COBOLプロジェクトの発注は、通常のシステム開発案件と比べて特殊な準備事項が多く、準備不足のまま発注するとベンダーとの認識齟齬・費用超過・成果物の品質不足という問題が頻発します。特にJCL・DB2・VSAMといったホスト固有仕様が絡む場合は、発注者側も相応の専門知識を持ってベンダーと対話する必要があります。

本記事では、COBOLのリバースエンジニアリングを外注（委託）する際の発注手順を、準備段階からRFP作成・契約・プロジェクト推進まで一連の流れで解説します。発注側が事前に整備すべき5項目、RFPに含めるべきCOBOL固有の記載事項、プロジェクト推進時の役割分担、よくあるトラブルと回避策まで、発注担当者が知っておくべき情報を網羅的にお伝えします。

▼全体ガイドの記事
・COBOLのリバースエンジニアリングの完全ガイド

外注前に発注側が準備すべき5項目

COBOLのリバースエンジニアリング発注を成功させるための第一歩は、ベンダーに問い合わせる前の社内準備です。準備が不十分なまま発注すると、見積もりが正確に比較できない・契約後に追加費用が発生する・成果物が使い物にならないというリスクが高まります。以下の5項目を発注前に整備することで、プロジェクト全体の成功確率を大幅に向上させることができます。

最初に行うべきは、解析対象のCOBOLシステムに関する基本情報の棚卸です。具体的には、ソースファイル一覧（ファイル名・LOC・作成日・最終更新日）、プログラム間の呼び出し関係（CALLチェーン）、JCL一覧（バッチジョブ定義）、使用しているDB2テーブル・VSAMファイルの一覧、稼働プラットフォーム（IBM z/OS・富士通FUJITSU・日立HITAC・オープン系COBOLなど）を整理します。この情報がなければベンダーは正確な見積もりを出すことができず、概算での見積もりには大きな誤差が生じます。

棚卸の過程で「ソースが見つからないプログラムがある」「バージョン管理されていないため最新版が不明」という問題が発覚するケースも多くあります。このような状況を把握した上でベンダーに情報提供することで、見積もりの精度が高まります。資産棚卸ツールとして、現行システムのJCL・ソース間の依存関係を自動解析するIBM ADDIなどの専門ツールを活用することも選択肢の一つです。

リバースエンジニアリングの目的（モダナイゼーション向け仕様書復元・継承・脆弱性診断）と、成果物として期待する粒度（フローチャート・業務機能仕様書・詳細設計書）を社内で合意しておく必要があります。「とりあえず設計書を作ってほしい」という依頼では、ベンダーによって粒度の解釈がバラバラになり、後から「これでは使えない」というトラブルの原因になります。成果物の粒度を、「この文書を基に新システムの設計ができる状態か」という観点で定義することが重要です。

また、成果物に含めるべき必須項目として「変数名・データ項目の業務的意味の説明」「業務ロジックのWhy（なぜその仕様か）の文書化」「例外処理の業務的意味の説明」を明示的に要件として定義することを強く推奨します。これらが成果物要件に含まれていないと、技術的な処理フローは分かっても業務の意図が不明なまま移行作業が進み、移行後バグの原因になります。COBOLにおけるHowの把握はコードを読めばできますが、Whyの把握は業務部門の協力なしには不可能であり、発注者側もこの部分への投資を明確に予算化する必要があります。

COBOLのリバースエンジニアリングはIT部門だけで完結するプロジェクトではありません。業務ロジックの「Why（なぜその仕様か）」を解明するためには、業務部門の担当者がヒアリングに協力する体制が必須です。発注前に、業務部門のキーパーソン（受発注担当・在庫管理担当・経理担当など、解析対象の業務に精通する人物）をプロジェクトに巻き込み、ヒアリングへの対応工数を確保してもらう合意を得ておく必要があります。

情報セキュリティ体制の整備も発注前の重要な準備事項です。COBOLのソースコードは機密性の高い業務ロジックや顧客データ処理の実装を含むため、ベンダーへの開示範囲とセキュリティ要件（NDA締結・情報取扱規程・アクセス制御）を事前に整備してください。また、著作権法第30条の4の「非享受目的」立証のために、解析専用環境の準備と解析過程の記録体制をベンダーと協議の上で合意しておくことも重要です。

発注の進め方（RFP作成〜契約）

準備が整ったら、RFP（Request for Proposal：提案依頼書）の作成とベンダーへの発信、評価・選定・契約という一連のプロセスを進めます。COBOLリバースエンジニアリングのRFPには、通常のシステム開発RFPには含まれないCOBOL固有の記載事項があります。

COBOL固有のRFP記載項目として、まず「稼働環境の詳細」を明示します。IBMメインフレーム（z/OS）の場合はOSバージョン・COBOLコンパイラバージョン・JCLの管理ツール（Tivoli Workload Schedulerなど）を記載し、オープン系COBOLの場合は使用コンパイラ（MicroFocus COBOL・GnuCOBOLなど）を明示します。次に「対象ソースの規模情報」として、総ファイル数・総LOC・JCLファイル数・DB2テーブル数・VSAMファイル数を記載します。

「解析対象の範囲と除外対象」も重要な記載項目です。全プログラムを対象にするのか、特定の業務領域（例：受発注管理モジュール）に絞るのかを明確にし、除外するプログラム（例：廃止予定の旧バッチ処理）も明示します。「成果物の詳細要件」には、前述の粒度（フローチャート・業務仕様書・詳細設計書）に加えて、変数名の業務的意味説明・業務ロジックのWhy記述の有無・業務部門ヒアリングの実施可否と工数見積もりの含み方を明記します。最後に「見積もり方法」として、LOC課金の単価（COBOL固有の複雑さ補正の有無）・ホスト固有仕様解析の追加費用の有無・業務部門ヒアリング工数の含み方を開示するよう求める項目を設けてください。

COBOLのリバースエンジニアリング契約では、通常のNDAに加えて「クリーンルーム手法の遵守」に関する条項を盛り込むことを検討してください。サードパーティが開発したソフトウェアを解析する場合（例：パッケージソフトのCOBOL部分を解析して互換実装を行う場合）は特に重要です。契約条項に含めるべき内容としては、解析チームと実装チームの分離義務、解析チームが作成した仕様書が著作権保護対象の「表現」を含まないことの確認義務、解析過程の記録保持義務（著作権法第30条の4の非享受目的立証のため）が挙げられます。

また、成果物に関する知的財産権の帰属も契約で明確化すべき重要事項です。ベンダーが解析過程で作成したツール・スクリプト・テンプレートの知的財産権、成果物（仕様書）の著作権が発注者に帰属するかどうか、成果物を第三者に開示・使用する条件などを明記してください。さらに、COBOLシステムのソースコードや業務ロジックは機密情報として、プロジェクト終了後のデータ廃棄に関する条項も含めることが推奨されます。

プロジェクト推進時の役割分担

COBOLリバースエンジニアリングプロジェクトは、ベンダー（解析チーム）・発注者IT部門・発注者業務部門の三者が緊密に連携することで成果が最大化されます。三者それぞれの役割と責任範囲を明確にしておくことで、プロジェクトの推進が円滑になり、情報の断絶によるトラブルを防ぐことができます。

発注者IT部門の主な役割は、ソースコード・JCL・DB2スキーマ・VSAMファイル情報のベンダーへの提供、解析環境（隔離されたテスト環境）の整備と提供、成果物のレビューと品質確認、プロジェクト全体のスケジュール管理と進捗報告です。IT部門はCOBOL解析の専門家でなくても、「どのプログラムが何の業務を担っているか」という概要レベルの知識は持ち合わせているはずです。この概要知識をベンダーに提供することで、解析チームが優先度の高い業務領域から効率的に解析を進められます。

成果物レビューにおいてIT部門が確認すべき点は、記述内容の業務的正確性（業務部門と連携して確認）、成果物粒度が契約要件を満たしているか、後続フェーズ（モダナイゼーション実装）で使用できる品質か、の3点です。技術的な解析精度の確認はベンダーに委ねるとしても、成果物が「使えるものか」という観点のレビューは発注者IT部門が責任を持って行う必要があります。

業務部門はCOBOLリバースエンジニアリングプロジェクトにおいて、最も重要かつ希少なリソースです。コードを読めば「どう動くか（How）」は分かりますが、「なぜそうなっているか（Why）」は業務部門にしか分かりません。例えば「特定の顧客コードの場合に処理を分岐させている」コードがあった場合、その顧客が過去に特別契約を結んでいたという経緯は業務担当者でなければ知り得ません。業務部門の主な役割は、ベンダーからのヒアリングへの対応（質問票への回答・インタビューへの参加）、業務処理シナリオ（月次バッチ・特定取引条件での動作など）の提供・説明、完成した仕様書の業務的正確性のレビューです。

業務部門のヒアリング工数は、プロジェクト規模によって数十時間から数百時間に及ぶことがあります。「業務部門は本来業務があるため時間が取れない」という状況はよくありますが、この工数を削減しようとすると成果物品質が著しく低下します。プロジェクト計画段階で業務部門のヒアリング工数を確保し、繁忙期を避けたスケジュール調整を行うことが、プロジェクト成功の重要な要件です。

よくあるトラブルと回避策

COBOLのリバースエンジニアリング発注では、同じような失敗が繰り返されています。よくあるトラブルとその回避策を把握しておくことで、発注後の問題を未然に防ぐことができます。

最も多いトラブルが「LOC課金で安く見積もられたが、実際に作業を開始したら追加費用が次々に発生した」というケースです。COBOLの1行は他言語と複雑さが異なるにもかかわらず、COBOL経験が浅いベンダーが一般的なLOC単価で見積もり、作業着手後に「JCL解析が想定より複雑だった」「業務ロジックのWhyの確認工数が膨大だった」という理由で追加費用を請求してくるパターンです。回避策としては、見積もり時にCOBOL固有の複雑さ補正を単価に含めているか確認すること、JCL・DB2・VSAM解析を含む追加費用の試算を事前に出してもらうこと、業務部門ヒアリング工数の扱い（見積もりに含むかどうか）を明確化することの3点が有効です。

「仕様書が納品されたが、モダナイゼーション実装に使えない」というトラブルも頻繁に起こります。フローチャートは作成されているものの変数名の業務的意味が記載されていない、業務ロジックのWhy（判断根拠）が書かれていない、例外処理の業務的な意味が不明のままというケースです。このような成果物で実装を進めると、移行後に業務ルールの解釈ミスによるバグが多発します。回避策は、RFP段階で成果物の品質基準を詳細に定義することと、プロジェクト開始前にサンプル成果物（数ファイル分）をベンダーに作成してもらいレビューすることです。サンプルレビューによって期待する品質水準のギャップを事前に確認し、必要に応じてスコープや費用を調整することができます。

COBOLからJavaやPythonへの機械変換（自動変換ツールによる変換）を選択した場合に発生するトラブルが「変換後のコードが若手エンジニアでは保守できない品質だった」という問題です。機械変換で生成されたコードは、COBOLの文法・データ構造をJavaの文法に直訳したものであることが多く、変数名が意味不明なままで、COBOLの業務ロジックをそのまま翻訳した非効率な処理が大量に含まれます。このようなコードは技術的には動作しますが、保守のたびに大きな工数がかかり、最終的にスクラッチ開発よりも高コストになるケースが少なくありません。回避策として、機械変換後のコードを人手でレビュー・改善するリファクタリング工数を計画に含めること、「変換後のコードが若手エンジニアでも保守可能な品質か」を契約要件に明示することを推奨します。

まとめ

COBOLのリバースエンジニアリングを外注で成功させるためには、発注前の十分な準備（ソース資産棚卸・目的と成果物要件の明確化・業務部門の巻き込み体制構築）が不可欠です。RFP作成においてはCOBOL固有の項目（稼働環境詳細・LOC課金の単価補正・ホスト固有仕様の追加費用・業務部門ヒアリング工数の扱い）を明示し、契約段階ではクリーンルーム手法の遵守・成果物の知的財産権帰属・データ廃棄条項を含めることが重要です。

プロジェクト推進中は、ベンダー・IT部門・業務部門の三者が緊密に連携し、技術解析（How）と業務理解（Why）を同時に進めることが成功の鍵です。LOC見積もりの齟齬・成果物品質不足・機械変換後のコード品質問題という3つの典型的なトラブルを事前に把握し、それぞれの回避策（COBOL複雑さ補正の確認・サンプル成果物レビュー・リファクタリング工数の計画）を発注段階で盛り込むことで、プロジェクトの成功確率を大幅に高めることができます。

▼全体ガイドの記事
・COBOLのリバースエンジニアリングの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。