リバースエンジニアリングの開発期間は、対象システムの規模と言語、残っているドキュメントの量によって大きく変わります。目安は、小規模で2〜6週間、中規模で2〜6ヶ月、大規模で6ヶ月〜1年以上です。
- リバースエンジニアリングの定義
- 開発期間・スケジュールの全体像
- 期間を左右する要因
本テーマの全体像は、以下の全体ガイドでも確認できます。
▼全体ガイドの記事
・リバースエンジニアリングの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
リバースエンジニアリングの定義（刷新・移行前の「分析・調査」フェーズという対象範囲）
リバースエンジニアリングの開発期間を正しく見積もるには、まずこの取り組みが何を目的とした工程なのかを明確にしておく必要があります。
ソフトウェア分野のリバースエンジニアリングは、完成したプログラムから設計情報・仕様・構造を逆方向に復元するプロセスです。具体的には、ソースコードや実行バイナリを解析し、失われた設計書や業務仕様書を再構築することを指します。
本稿が扱うのは、そのうち「レガシーシステムのモダナイゼーション」を目的としたケースです。つまり、モダナイゼーションや刷新、リプレイスなど、本体プロジェクトに着手する前段で行う現状分析・調査工程が対象になります。この位置づけを見誤ると、期間見積もりの前提がずれてしまいます。
「なぜ今のシステムの動きが分からないのか」という情シス部門の悩み
長年運用されてきた基幹システムや業務システムでは、開発当初の仕様書が更新されないまま放置されたり、度重なる改修の履歴が記録されないまま散逸したりすることが珍しくありません。さらに、担当していたエンジニアが退職・異動すると、そのシステムがなぜその仕様になっているのかを知る手がかりはソースコードだけになります。
今のシステムの動きが分からない状態を放置すると、軽微な改修であっても影響範囲の特定に数週間から数ヶ月を要するようになり、IT予算の大半が保守維持に消える悪循環に陥ります。
リバースエンジニアリングは、「動きが分からない」という根本課題に、ソースコードという一次情報から仕様を逆算的に復元して応えます。
刷新・移行プロジェクトの「前段」に位置する調査工程という特殊性
通常のシステム開発プロジェクトと比べたときの大きな違いは、リバースエンジニアリングが「作る」工程ではなく「調べる」工程であることです。
本体プロジェクトでは、要件定義から設計・実装・テストへと工程を積み上げていきます。一方、リバースエンジニアリングはその手前で行う現状分析・調査であり、成果物は新しいシステムそのものではなく、業務仕様書や設計書といった「復元されたドキュメント」です。
この調査にどれだけの期間をかけるかで、後続する本体プロジェクトの要件定義の精度とスピードが大きく変わります。逆に、期間を短縮しようと焦って調査が不十分なまま本体プロジェクトに進むと、後工程で仕様の見落としが発覚し、結果として全体の期間が延びるという本末転倒な事態を招きます。
開発期間・スケジュールの全体像（4フェーズの期間配分と規模別の目安）
リバースエンジニアリングのスケジュールは、明確な工程管理のもとで4つのフェーズに分けて計画するのが一般的です。目的が曖昧なまま解析を始めると、膨大な工数をかけたのにスコープが際限なく広がり、納期が見通せなくなるおそれがあります。
準備〜成果物化までの4フェーズと期間目安
標準的なリバースエンジニアリングのWBS（作業分解構造）は、4つのフェーズで構成されます。まず、第1フェーズ「準備・スコープ確定」は約1〜2週間で、対象ソース資産を洗い出し、解析環境を整え、解析範囲を最終合意します。
次に、第2フェーズ「静的解析」は規模により約2〜8週間で、逆コンパイル・逆アセンブルによって制御フローグラフを作成し、データフローを分析します。続く第3フェーズ「動的解析・業務ヒアリング」は約2〜6週間で、デバッガを用いた実行トレースと、業務部門へのヒアリングを並行して進めます。
最後の第4フェーズ「成果物化・レビュー」は約2〜4週間で、仕様書・設計書の作成と、発注側によるレビュー・修正対応を行います。各フェーズの終わりには、成果物のレビューと進捗確認の節目を置き、スコープ変更が必要になったら工数・期間への影響をその都度合意します。この体制を保つことが、納期をコントロールするうえで欠かせません。
システム規模別に見る全体期間の違い
全体期間は、対象システムの規模によって大きく変わります。小規模プロジェクト（おおむね4,000〜10,000行程度、ECサイトの一機能やAPI連携システムなど）は2〜6週間が目安です。中規模プロジェクト（1〜10万行程度の業務システム全体）は2〜6ヶ月、大規模プロジェクト（10万行以上の基幹システムなど）は6ヶ月〜1年以上に及ぶこともあります。
難読化や暗号化が施されているコード、あるいはCOBOLやPL/Iのようなレガシー言語で書かれたシステムでは、これらの目安からさらに期間が延びる傾向があります。
プロジェクト計画を立てる際は、まず自社システムのおおよそのコード規模を把握し、この規模別の目安を出発点に全体スケジュールを描くのが現実的です。
期間を左右する要因（言語・ドキュメント有無・難読化）
同じコード行数のシステムであっても、言語やプラットフォーム、残存するドキュメントの状況によって、実際にかかる期間は大きく変わります。見積もりの精度を高めるには、これらの変動要因をあらかじめ把握しておくことが重要です。
対象言語・プラットフォームによる解析難易度の差
言語によって、解析にかかる時間は大きく変わります。COBOLやPL/Iといったレガシー言語は、独自ミドルウェアやホスト固有仕様がブラックボックス化しています。そのため、バイナリ解析が中心となり、標準的な工数の1.5〜2倍程度を要することが一般的です。
C言語のようなネイティブコンパイル言語も、変数名やコメントが実行バイナリから失われるため、1.3〜1.8倍程度の工数がかかります。一方、C#やJavaのような中間言語（IL・バイトコード）ベースの言語は、逆コンパイルによって比較的ソースに近い形まで復元できるため、標準の0.8〜1.2倍程度と短縮されやすい傾向にあります。
PHPやPythonのようなスクリプト言語は、ソース自体が読める場合が多く、難読化がなければ0.6〜1.0倍程度に収まります。ただし、難読化が施されていると、逆に1.5倍以上に延びることもあります。また、ReactやFlutterといったWeb・モバイル系は、API通信解析や特殊なバイナリ構造への対応が必要になり、1.2〜1.8倍程度が目安です。
残存ドキュメントの有無と難読化・暗号化の影響
断片的であっても、過去の仕様書・設計書・操作マニュアルが残っていれば、解析工数は大幅に減り、期間短縮につながります。反対に、ドキュメントが一切残っておらず、ソースコードだけを手がかりに解析する場合は、静的解析だけでなく動的解析や業務部門へのヒアリングにも多くの時間を割く必要があり、期間は長期化します。
また、難読化（制御フローの意図的な複雑化）や暗号化が施されたコードは、逆コンパイルしても正規のコードと囮コードの区別に多大な工数がかかります。理論上は復元できても、実用的な期間内に収まらないケースもあります。
見積もり段階で対象コードの難読化レベルを事前に確認し、スケジュールに反映させておくことが、後々の遅延を防ぐポイントです。
納期遅延のリスク要因と対策
リバースエンジニアリングのスケジュールが当初計画を超える原因は、技術的な難しさに加えて、見積もりの前提や体制構築の不備にあることも少なくありません。典型的なリスク要因とその対策を押さえておけば、納期遅延を未然に防げます。
LOC見積もりの罠によるスコープクリープ
リバースエンジニアリングの見積もりは、行数（LOC）ベースで提示されることが一般的です。ところが、着手後に「ライブラリコードも含まれていた」「コメント行・空行も行数にカウントされていた」と分かることがあります。さらに、「スコープ外と思っていた外部連携システムの解析も必要になった」という事態が重なり、当初想定の2〜3倍の期間・費用に膨れ上がるケースが頻発します。
この罠を避けるには、契約前に解析対象の範囲を文書で明確に合意しておくことが不可欠です。合意すべき範囲は、実行コード行のみか、コメント・空行を含むか、外部連携システムはどこまで含むかなどです。
発注側と開発会社が、スコープ外の追加作業の判明に備えて変更管理のプロセス（変更依頼→工数見積もり→承認→実施）を決めておけば、際限のないスコープ拡大による納期遅延を防げます。
業務部門ヒアリングの巻き込み不足という落とし穴
ソースコードから分かるのはあくまで「How（どう動くか）」です。「Why（なぜその仕様か）」は、元の業務担当者の頭の中にしか存在しないケースが多くあります。
この業務ロジックの意図を復元するには、解析と並行して現役の業務担当者にヒアリングを行うことが欠かせません。ところが、業務部門の協力体制が整っていないと、解析が途中で止まりやすく、納期超過の大きな原因になります。
対策としては、プロジェクトに業務知識を持つ担当者を専任で1〜2名参画させ、週1〜2回程度の定期ヒアリングに出席できる体制を、あらかじめWBSに組み込んでおくのが有効です。特に、業務部門のスケジュールは、プロジェクト計画の初期段階から確保しておくことが、後半での停滞を防ぐ鍵になります。
依頼先選定と体制構築が開発期間に与える影響
同じ規模・言語のシステムでも、どのパートナー企業に依頼するかで開発期間は大きく変わります。専門性が問われる領域であるだけに、依頼先の実績と契約形態の選び方が期間短縮の鍵を握ります。
実績・解析ツール活用力の確認ポイント
依頼先を選ぶ際に確認すべきポイントの1つ目は、対象言語・プラットフォームの解析実績です。COBOLやメインフレーム、あるいはReactやFlutterといった特定領域の解析経験が豊富なパートナーであれば、現状把握にかかる期間を大幅に短縮できます。
2つ目は、GhidraやIDA Pro、Binary Ninja、CAST Imagingといった静的解析・可視化ツールの活用実績です。手作業だけに頼らず、ツールを使いこなせるパートナーであれば、同じ規模のコードでも解析期間を圧縮できます。
3つ目は類似規模・類似言語のプロジェクト実績です。過去に扱ったコード量や業界が近いほど、見積もりの精度と進行のスムーズさが向上します。そこで、提案段階でこれらの実績を具体的な事例とともに共有してもらうことが、期間見積もりの妥当性を検証する近道です。
契約形態（準委任/請負）と特急対応の考え方
契約形態の選び方も、期間に影響します。スコープが不確定な初期調査フェーズには、実働時間に応じて柔軟に対応できる準委任契約（時間精算）が向いています。一方、成果物の粒度が明確になった本解析フェーズ以降は、完了責任が明確な請負契約（固定費用）が適しています。
この使い分けを誤ると、契約変更の手続きに時間を取られ、実質的な進行が滞ることがあります。また、どうしても短納期が求められる場合は、特急対応も選択肢になります。
通常の短縮（例：1ヶ月を3週間に短縮）では総額の20〜30%増、大幅な短縮や休日・深夜対応が必要な超特急案件では40〜60%増が相場です。だからこそ、特急料金を避けるためにも、システムの老朽化リスクが顕在化する前に計画的にリバースエンジニアリングへ着手することが、期間とコストの両面で最も合理的です。
まとめ
ここまで、リバースエンジニアリングの開発期間・スケジュール・納期について解説しました。工程ごとの期間配分と規模別の目安を示したうえで、期間を左右する要因、納期遅延を招く2大リスク要因と対策、依頼先選定と体制構築の影響を扱いました。
リバースエンジニアリングは、刷新・移行プロジェクトの前段にある「分析・調査」工程です。この理解が、期間見積もりの出発点になります。
目安は、小規模で2〜6週間、中規模で2〜6ヶ月、大規模で6ヶ月〜1年以上です。ただし、対象言語やドキュメントの残存状況によって、この期間は大きく変わります。
納期遅延を防ぐうえで特に大切なのは、LOC見積もりの罠によるスコープクリープを契約前の合意で防ぐことと、業務部門を早い段階からプロジェクト体制に巻き込んでおくことです。「仕様書がないから動きが分からない」という状態を放置する期間が長いほど、後続の刷新・移行プロジェクト全体のリスクも大きくなります。
対象言語の解析実績と解析ツールの活用力を持つ信頼できるパートナーに、早めに相談することをお勧めします。
▼全体ガイドの記事
・リバースエンジニアリングの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。