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

「逆コンパイルしても変数名がa、b、cばかりで意味が読み取れない」「Struts1で作られた基幹システムなのに、当時の設計者はすでに退職している」――JavaEEやStrutsといった古いエンタープライズ向けフレームワークで構築された基幹システムを抱える情シス部門にとって、これは決して珍しい相談ではありません。Javaのリバースエンジニアリングとは、コンパイル済みのクラスファイル（バイトコード）やJAR・WAR・EAR形式のアーカイブを解析し、失われた設計情報・業務仕様を逆方向に復元する技術であり、刷新・移行プロジェクトに着手する前段の「分析・調査」工程として位置づけられます。Javaのバイトコードは中間言語であるためソースコードに近い形まで逆コンパイルしやすいという利点がある一方、JavaEEやStrutsの構成、そしてProGuardなどによる難読化が絡むと、期間見積もりは一気に読みにくくなります。

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

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

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

Javaリバースエンジニアリングの開発期間はなぜ読みにくいのか（JavaEE/Strutsという構成の特殊性）

C#と同じくJavaはJVM上で動くバイトコードという中間言語にコンパイルされる言語です。COBOLやC言語のようなネイティブコンパイル言語と違い、クラス構造・メソッドシグネチャ・型情報の多くがバイトコードに保持されているため、逆コンパイルによってソースコードに近い形まで比較的短期間で復元できます。この特性だけを見れば期間見積もりは容易に思えますが、実際の現場で相談が多いのはJavaEEやStruts（Struts1・Struts2）で構築された基幹システムです。この場合、Javaコード単体の解析だけでは全体像がつかめず、XML設定ファイル群・複数WAR/EARの依存関係・アプリケーションサーバ固有の設定という周辺要素の解析が必要になり、期間見積もりの前提が大きく変わります。

JVMバイトコードは、難読化されていなければクラス名・メソッド名・フィールド名がそのまま保持されているため、JD-GUIやCFR、Procyon、IntelliJ IDEA内蔵のFernflowerといった逆コンパイラを使えば、ある程度可読性のあるJavaソースコードへ復元できます。この点はCOBOLやC言語のバイナリ解析に比べて明らかに有利です。しかし、Java言語特有の要素が逆コンパイル結果を歪めることも少なくありません。とりわけJava8以降で導入されたラムダ式はinvokedynamicという特殊なバイトコード命令に変換されるため、多くの逆コンパイラがラムダ式の由来コードを正確に復元できず、不自然な匿名クラス表現として出力してしまいます。ジェネリクスも型消去（Type Erasure）によってコンパイル時に型情報の多くが失われるため、逆コンパイル結果だけからは本来の型制約を完全には読み取れません。「バイトコードだから早く終わる」という単純な思い込みは、見積もりの精度を損なう典型的な落とし穴です。

JavaEEやStruts（Struts1・Struts2）で構築された基幹システムは、単一のJARファイルではなく、複数のWARファイルとそれらを束ねるEARファイル、さらにWebLogicやWebSphere、JBoss/WildFly、Interstageといったアプリケーションサーバ固有の設定情報が絡み合った構成になっています。web.xml、struts-config.xml（Struts1）やstruts.xml（Struts2）、ejb-jar.xmlといったXML形式のデプロイメント記述子が、画面遷移・アクションマッピング・EJBの呼び出し関係を規定しており、これらXML群を解析しなければJavaコード単体を読んでもシステム全体の業務フローはつかめません。加えてMaven（pom.xml）やAnt（build.xml）のビルド定義から依存ライブラリのバージョンを特定する作業も欠かせず、こうした周辺解析の工数はコード本体の解析工数に対して20〜30%程度の上乗せになることが多く、見積もり段階でこの上乗せ分を織り込んでいるかどうかが後々のスケジュール精度を左右します。

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

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

対象パッケージ・クラスの棚卸しと目的の明確化を行う対象選定フェーズは、標準的な規模（クラスファイル数百〜1,000程度）であれば1〜3週間が目安です。続く逆コンパイル・静的解析フェーズでは、JD-GUIやCFR、Procyon、Fernflowerといった逆コンパイラを用いてクラスファイルをJavaソースに近い形へ復元し、パッケージ構成・クラス継承関係・呼び出し関係を可視化します。この工程は同規模で難読化がなければ3〜6週間程度ですが、ProGuard等による難読化が施されている場合は難読化解除作業が加わり、6週間〜3ヶ月程度に延びることも珍しくありません。静的解析の段階でパッケージ依存関係図を作成しておくと、次の動的解析との対照がスムーズになり、後工程の手戻りを防げます。

動的解析フェーズでは、テスト環境でデバッガをアタッチし、Strutsのアクションマッピングに沿った画面遷移や、JDBC・Hibernate（JPA）・MyBatis経由のデータベースアクセスの実行トレースを業務シナリオごとに追跡します。月次バッチ処理や特定の権限を持つユーザーのみが通る例外処理の再現には業務部門へのヒアリングと並行した1〜2ヶ月程度の期間を見込むのが標準的です。その後の仕様書化（抽象化）工程は、実装レベルの制御フローを業務機能単位の設計ドキュメントへ、さらに仕様レベルの業務仕様書へと引き上げていく工程で、成果物の粒度によって1〜2ヶ月程度の幅があります。これらを合算すると、標準的な規模のJavaリバースエンジニアリングは全体で3〜6ヶ月程度、難読化や複数WAR/EARにまたがる大規模な基幹システムでは6ヶ月〜1年に及ぶこともあります。

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

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

Androidアプリだけでなく、パッケージ製品として配布されるJavaアプリケーションでも、ソースコード保護のためProGuardやyGuard、Allatori、Zelix KlassMasterといった難読化ツールが使われているケースがあります。これらのツールはクラス名・メソッド名・変数名をa、b、cといった意味のない短い識別子に置き換えるリネーム難読化に加え、制御フローの複雑化、文字列リテラルの暗号化まで行うことがあります。難読化されたコードは逆コンパイル自体は可能でも、a.b(c, d)のような無意味な呼び出しの羅列になり、業務ロジックの意図を読み取るには膨大な手作業での識別子復元が必要になります。難読化の有無を事前に確認せずに見積もりを行うと、着手後に想定の1.5〜2倍の工数が判明するケースが典型的な長期化要因です。

Struts1は2013年に公式サポートが終了しており、Struts2も度重なる脆弱性（CVE-2017-5638等）が指摘されながら十分な対応がされないまま稼働し続けているシステムが少なくありません。こうしたEOL（サポート終了）フレームワークで構築されたシステムは、当時使われていたライブラリのバージョンが現在では入手困難になっていたり、ビルド環境自体の再構築が困難になっていたりすることが多くあります。逆コンパイルしたソースをビルドし直して動作検証しようとしても、依存ライブラリのJARファイルが散逸し、Mavenリポジトリからも取得できない古いバージョンが使われていることが判明し、解析が停滞するケースが典型的な長期化要因になります。

納期を守るための進め方

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

JD-GUIは軽量で素早くクラスファイルの中身を確認できるため、初期の全体像把握に向いています。CFRは複雑な制御フローやジェネリクスの復元精度に優れ、ラムダ式を含むJava8以降のコードにも比較的強い逆コンパイラです。Procyonはアノテーションの復元に定評があり、Fernflower（IntelliJ IDEA内蔵）はIDE上でシームレスに逆コンパイル結果を確認しながら解析を進められる利点があります。1つのツールに頼らず、対象コードの特性に応じて複数の逆コンパイラの結果を突き合わせることで、単独のツールでは復元しきれない部分を補完し合い、解析精度と速度の両方を高められます。

Javaのリバースエンジニアリングが他の言語と比べて有利な点の一つは、web.xml、struts-config.xml、ejb-jar.xml、Spring利用時のapplicationContext.xmlといったXML形式のデプロイメント記述子が、ソースコードの解析より先に、あるいは解析と独立して読み解ける点です。これらのXMLファイルにはURL・アクションクラス・EJBの対応関係が明示的に記述されており、逆コンパイル済みのJavaコードを読み込む前に、まずXML群からシステム全体の機能一覧・画面遷移マップを作成しておくことで、以降のコード解析の優先順位付けが格段にしやすくなります。この「XML先行解析」は、ソースコードしか手がかりのないC言語やCOBOLのリバースエンジニアリングにはない、Java・JavaEE特有の期間短縮手法です。

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

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

依頼先を選定する際は、単に「Java対応可能」というだけでなく、JavaEEやStruts、EJBといった古いエンタープライズ仕様への対応実績、そしてJD-GUI・CFR・Procyonといった逆コンパイラやProGuard難読化解除の実務経験を具体的に確認することが重要です。WebLogicやWebSphere、JBoss/WildFlyといった商用アプリケーションサーバ特有の設定解析経験があるかどうかも、着手後の停滞を防ぐ上で見逃せない確認ポイントです。この部分の実績が乏しいベンダーに依頼すると、静的解析の途中でJavaEE固有仕様の壁にぶつかり、体制を立て直すことになり、結果として期間全体が想定以上に伸びてしまうリスクが高まります。

Struts1やEJB2.xといった古いJavaEE仕様の経験者は、Java技術者全体で見ればなお現役の技術者が多いものの、当時の設計思想やアプリケーションサーバ特有の癖を熟知したベテランは徐々に減少しつつあります。加えて、担当者の退職・異動によって「なぜこの画面遷移がこう設計されているのか」という業務ロジックのWhyを語れる人材が失われると、解析後半のヒアリング工程が滞り、結果的に期間が延びます。「システム担当者が退職予定で急いで知識を保存したい」というトリガーで動き出すプロジェクトも多いですが、退職の2〜3ヶ月前では十分な期間を確保できないまま計画を進めざるを得ません。有識者が在籍しているうちに早めに対象選定・現状棚卸しだけでも着手しておくことが、期間を現実的にコントロールする最も有効な備えです。

まとめ

本記事では、Javaのリバースエンジニアリングの開発期間・スケジュール・納期について、バイトコード解析特有の二面性、JavaEE/Struts構成が期間見積もりを難しくする構造、工程別・規模別の期間目安、長期化を招く主な要因（難読化とEOLフレームワーク）、納期を守るための進め方、依頼先選定・着手タイミングが期間に与える影響を体系的に解説しました。Javaのバイトコードは中間言語であるため、逆コンパイルによる復元自体はCOBOLやC言語のネイティブバイナリより短期間で進みやすいものの、JavaEEやStrutsという構成、そしてProGuard等による難読化が絡むと、標準的な規模で3〜6ヶ月、難読化や複数WAR/EARにまたがる大規模な基幹システムでは6ヶ月〜1年以上を見込む必要があります。

納期遅延を防ぐ最大のポイントは、逆コンパイラを使い分けて解析精度を高めることと、XML設定ファイル群を先行解析してシステム全体の構造を早期に把握することです。JavaEE/Struts解析実績を持つ信頼できるパートナーに、有識者が在籍しているうちに早めに相談することをお勧めします。

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

株式会社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を創業。