COBOLのリバースエンジニアリングの開発期間・スケジュール・納期について

COBOLのリバースエンジニアリングは、ソースコード解析・仕様書がないレガシーシステムから仕様・設計を逆算的に復元する調査工程であり、モダナイゼーションや刷新プロジェクトの「前段調査」として位置づけられます。一般的な新規システム開発の期間見積もりとは異なり、IBM汎用機（メインフレーム）上で稼働するCOBOLプログラムを対象とする場合、JCL（Job Control Language）によるバッチジョブ制御、COPY句（コピー句）で外部定義されたデータ構造、VSAMやDB2といったホスト固有のファイル・データベース仕様が複雑に絡み合っているため、単純なソースコード行数（LOC）だけでは開発期間を正確に見積もることができません。「まず設計書を作り直したいが、どれくらいの期間がかかるのか分からない」という担当者の悩みは、このホスト固有仕様の複雑さに起因しています。

本記事では、COBOLのリバースエンジニアリングの開発期間・スケジュール・納期について、なぜ期間が読みにくいのかという構造的要因から、工程別・規模別の期間目安、長期化を招く典型パターン、納期を守るための進め方、依頼先選定と着手タイミングが期間に与える影響までを体系的に解説します。COBOLシステムの現状分析・仕様書復元の着手を検討している担当者の方はもちろん、すでにモダナイゼーション計画の一部として調査工程を進めている方にとっても、現実的なスケジュールを描くための判断軸が身に付く内容です。JCL・COPY句・VSAMというホスト固有仕様への理解が、期間見積もりの精度を左右する最大の鍵になります。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

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

COBOLリバースエンジニアリングの開発期間はなぜ読みにくいのか

JavaやPythonといったモダン言語のリバースエンジニアリングであれば、ソースコードの静的解析だけである程度の構造を把握できます。しかしCOBOLの場合、プログラム単体を解析しただけでは全体の処理フローを理解できません。COBOLプログラムはJCLというジョブ制御言語によって実行順序・入出力データセット・依存関係が外部から規定されており、JCLを解析しなければ「どのプログラムがどの順番で、どのファイルを読み書きしているか」という全体像すら見えてこないためです。この構造的な特性が、開発期間の見積もりを難しくしている最大の要因です。

COBOLプログラムのデータ構造は、多くの場合COPY句（COPY文）によって外部のコピーブックファイルから読み込まれています。COPY句は共通のレコードレイアウトを複数のプログラムで再利用するための仕組みですが、裏を返せば1つのプログラムのソースコードだけを読んでも、実際に扱っているデータ項目の全貌は分かりません。COPY句を展開し、参照先のコピーブックをすべて洗い出した上でデータ構造を復元する「COPY句展開」という工程が必須になり、この展開作業自体が想定より多くの時間を要するケースが頻発します。さらにVSAM（Virtual Storage Access Method）ファイルのキー構造やレコード形式、DB2のテーブル定義とSQL文の対応関係も、専門知識なしには正確に把握できません。これらホスト固有仕様の解析工数は、COBOLソースコード自体の解析工数の20〜40%に相当することが多く、期間見積もりの段階でこの上乗せ分を織り込んでいるかどうかが、後々のスケジュール精度を大きく左右します。

システム開発の期間見積もりでは、対象ソースコードの行数（LOC：Lines of Code）を基準にすることが一般的ですが、COBOLの場合はこの手法がそのまま通用しません。React やPythonの1行が関数呼び出しや描画ロジック1つを表すのに対し、COBOLの1行はWORKING-STORAGE SECTIONにおける複雑なデータ定義やPIC句による桁数・型指定、PERFORM文による処理呼び出し制御など、業務ロジックの核心部分を凝縮していることが多くあります。「COBOL1万行とモダン言語1万行は別物」という前提を共有しないまま、単純な行数ベースでスケジュールを組んでしまうと、着手後にアセスメント期間だけで当初想定の1.5〜2倍を要する事態になりかねません。加えて、コメントがほとんど残っておらず、変数名も「WS-CUST-CD-TRAN-FLG」のような意味の分かりにくい省略形になっているケースが多いことも、解析期間を押し上げる要因の一つです。

規模・工程別に見る開発期間の目安

COBOLのリバースエンジニアリングは、対象選定・ツール準備・静的解析・動的解析・抽象化・成果物化という一連の工程で進めるのが一般的です。全体スケジュールを描く際は、この工程ごとにどれだけの期間を要するかを個別に把握しておく必要があります。

対象モジュールの棚卸しと目的の明確化を行う対象選定フェーズは、標準的な規模（ソースファイル数十本・総行数4,000〜1万行程度）であれば2〜4週間が目安です。続く静的解析フェーズでは、DIVISION構造（IDENTIFICATION・ENVIRONMENT・DATA・PROCEDURE）の整理、COPY句展開によるデータ構造の復元、JCLとのインターフェース解析による依存関係マップの作成を行います。この工程は、同規模で標準的なケースなら1〜2ヶ月程度ですが、COPY句の参照先コピーブックが他システムと共有されている、あるいはJCLのステップ数が数百に及ぶといった複雑な環境では2〜4ヶ月に伸びることも珍しくありません。静的解析の段階で制御フローグラフ（CFG）を作成しておくと、次の動的解析との対照がスムーズになり、後工程の手戻りを防げます。

動的解析フェーズでは、テスト環境でデバッガをアタッチし、月末バッチ・受注処理・在庫更新といった業務シナリオごとに実際の処理の流れを追跡します。本番環境でしか発動しない月次・年次の締め処理や特定の取引コードに紐づく例外処理は再現が難しく、業務部門への聞き取りと並行しながら進めるため、1〜2ヶ月を見込むのが標準的です。その後の抽象化（Design Recovery）〜成果物化の工程は、実装レベルの制御フローを業務機能単位の設計ドキュメントへ、さらに新システム開発に使える仕様レベルの業務仕様書へと引き上げていく工程で、成果物の粒度（フローチャートのみか、詳細設計書まで求めるか）によって1〜3ヶ月程度の幅があります。これらを合算すると、標準的な規模のCOBOLリバースエンジニアリングは全体で4〜8ヶ月程度、ホスト固有仕様が複雑な大規模システムでは1年以上を要するケースもあります。

開発期間が長期化する主な要因

工程別の期間目安を押さえた上で、実際のプロジェクトで納期が計画通りに進まなくなる典型的な要因を理解しておくことが、現実的なスケジュールを組む上で欠かせません。

事前のアセスメントでどれだけ丁寧に対象を棚卸ししても、実際に静的解析へ着手して初めて「このJCLステップは想定外の別プログラムを呼び出していた」「COPY句の参照先コピーブックが複数バージョン存在し、どれが最新か判別できない」といった事実が判明することがあります。特に長年運用されてきたシステムでは、JCLのメンテナンス履歴自体が失われており、現在稼働しているジョブネットの全体像を誰も把握していないという状態も珍しくありません。こうした「隠れたホスト仕様の複雑さ」が実装フェーズならぬ解析フェーズの途中で次々と表面化することが、COBOLリバースエンジニアリング特有の長期化要因です。契約前の提案段階で、見積もりに「想定外のJCL依存関係が発見された場合のバッファ」を明示的に含めてもらうことが、後工程での納期崩壊を防ぐ最初の防波堤になります。

COBOLのコードを読み解けば「何をしているか（How）」は分かっても、「なぜその仕様になっているのか（Why）」はコードだけでは判断できません。30年以上前に意思決定された業務ルールがそのままロジックとして埋め込まれているケースが多く、これを解明するには業務担当者へのヒアリングが不可欠です。ところが業務部門の繁忙期や担当者の年次有給休暇によってヒアリングの日程調整が難航し、解析チームの作業自体は完了しているのにヒアリング待ちで工程全体が停滞するという事態が頻繁に発生します。解析チームが「How」を読み解きながら業務担当者が「Why」を補完するという協働体制を、静的解析の段階から並行して立ち上げておくことが、ヒアリング待ちによる遅延を防ぐ最も効果的な対策です。

納期を守るための進め方

長期化要因を理解した上で、実際に納期を守るために有効な進め方を2つの観点から整理します。

IBMのApplication Discovery and Delivery Intelligence（ADDI）やMicroFocus（OpenText）の解析ツール群は、JCL・VSAM・DB2との依存関係を自動的にマッピングする機能を備えており、手作業による棚卸しに比べて静的解析フェーズの期間を大幅に短縮できます。汎用のバイナリ解析ツールではCOBOL特有のCOPY句展開やホスト固有仕様までは追い切れないため、COBOL・JCL・VSAM・DB2の解析実績があるツール群を初期段階から導入することが、期間短縮の直接的な効果につながります。ただし、ツールが自動生成する依存関係マップはあくまで機械的な検出結果であり、業務的な意味づけまでは行えません。ツールによる自動化と、専門技術者による解析・業務部門とのヒアリングを組み合わせることで、初めて実効性のある期間短縮が実現します。

「全システムを一括で解析する」という進め方は、想定外のホスト仕様が発覚した際に全体スケジュールへの影響が大きく、納期リスクを高めます。これに対し、業務影響が比較的小さく独立性の高いモジュール（周辺業務のバッチ処理など）をパイロット領域として先行着手し、そこでJCL解析やCOPY句展開の実際の工数を実測してから、残りの範囲のスケジュールを精緻化する段階的アプローチが有効です。パイロット領域での実測値を踏まえることで、「1万行あたり何人月かかるか」という自社システム固有の解析生産性を把握でき、以降のフェーズの見積もり精度が大きく向上します。

依頼先選定・着手タイミングが期間に与える影響

同じ規模・技術構成のCOBOLシステムでも、どのパートナー企業に依頼するか、そしていつ着手するかによって開発期間は大きく変わります。

COBOLのリバースエンジニアリングを依頼する際は、単に「COBOL対応可能」というだけでなく、JCLのジョブネット解析、VSAMファイルのキー構造解析、DB2のテーブル定義とSQL文の対応関係解析について、具体的な実績・事例を確認することが重要です。この部分の実績が乏しいベンダーに依頼すると、静的解析の途中でホスト固有仕様の壁にぶつかり、そこから体制を立て直すことになり、結果として期間全体が想定以上に伸びてしまうリスクが高まります。また、クリーンルーム体制（解析チームと実装チームを分離する体制）の整備状況や、成果物の粒度と品質基準がどれだけ明確に定義されているかも、着手後の手戻りを防ぐ観点から必ず確認すべきポイントです。

経済産業省の「IT人材需給に関する調査」によれば2030年には最大約79万人のIT人材不足に陥ると予測されており、COBOLやメインフレームに対応できる技術者はその中でも特に希少で、対応可能な人材の高齢化・退職が進んでいます。着手を先送りにするほど、JCLやCOPY句の意図を説明できる有識者がすでに退職しているという事態に直面しやすくなり、いざ着手した際のヒアリング協力者が確保できず、期間がむしろ長期化するという逆説的な構造が生まれます。「システム担当者が退職予定で急いで知識を保存したい」というトリガーで動き出すプロジェクトも多いですが、退職の2〜3ヶ月前では十分な期間を確保できないまま計画を進めざるを得ません。余裕のあるうちに対象選定・現状棚卸しだけでも早期に着手し、有識者が在籍しているうちにヒアリングを進めておくことが、期間を現実的にコントロールする最も有効な備えです。

まとめ

本記事では、COBOLのリバースエンジニアリングの開発期間・スケジュール・納期について、期間が読みにくくなる構造的要因、工程別・規模別の期間の目安、長期化を招く主な要因、納期を守るための進め方、依頼先選定と着手タイミングが期間に与える影響を体系的に解説しました。COBOLリバースエンジニアリングの期間見積もりを正しく行う鍵は、これを単なるソースコード解析としてではなく、JCLによるジョブ制御・COPY句によるデータ構造・VSAMやDB2といったホスト固有仕様の解析を含む複合的な調査プロセスと捉えることにあります。標準的な規模であれば全体で4〜8ヶ月、ホスト固有仕様が複雑な大規模システムでは1年以上を見込む必要があり、想定外のJCL依存関係の発覚や業務部門ヒアリングの遅延が、計画を崩す典型的な要因になります。自動解析ツールの活用とパイロット領域からの段階的着手、そしてJCL・VSAM・DB2の解析実績が豊富なパートナー選びが、現実的な納期を実現する近道です。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を創業。