リバースエンジニアリングを外注したいが「どのように依頼すればよいか分からない」「RFPに何を書けばよいか」「契約でどんな条件を取り決めるべきか」と悩んでいるご担当者は少なくありません。一般的なソフトウェア開発の外注と異なり、リバースエンジニアリングは対象システムの詳細が事前に不明確なケースが多く、スコープ定義・費用見積もり・法的条件の設定が特に難しい領域です。本記事では、発注前の準備からRFP作成・契約・プロジェクト推進・WBS引きまでの実務プロセスを一から解説します。

「業務部門を巻き込まずにIT部門だけで進めたら業務ロジックが復元できなかった」「LOC見積もりの定義が曖昧で発注後に大幅な費用追加が発生した」といった典型的なトラブルを避けるための具体的なポイントもご紹介します。リバースエンジニアリングの外注をスムーズに進めるための実務ガイドとしてご活用ください。

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

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

リバースエンジニアリングを外注する際に最も重要なのは、発注前の「自社側の準備」です。ベンダーに丸投げすると、技術的には正確でも業務目的に合わない成果物が納品されるリスクがあります。発注側がしっかり準備することで、見積もり精度・成果物品質・プロジェクト期間の全てが改善されます。

まず「対象システムの資産棚卸し」を実施します。対象となるソースコードのファイル数・概算行数・言語・プラットフォームを一覧化し、残存しているドキュメント（仕様書・設計書・操作マニュアル・画面定義書）を可能な限り収集します。断片的であっても構いません。残存ドキュメントをベンダーに提供することで、解析工数が削減され、費用を抑えられます。また、システムの稼働年数・変更履歴・連携外部システムのリストも整理してください。特に外部システムとのI/F（インターフェース）仕様は、解析範囲を定義する上で重要な情報です。最後に、解析対象に含まれるべき機能とそうでない機能を優先度別に仕分けることで、スコープを適切にコントロールできます。

「何のためにリバースエンジニアリングをするのか」という目的を明文化し、それに対応した成果物の要件を定義します。目的がモダナイゼーション計画策定であれば「新システムのRFP作成に使える業務仕様書」が成果物、セキュリティ診断であれば「脆弱性レポートと修正優先度一覧」が成果物、引き継ぎ対応であれば「保守担当者が理解できるフローチャートと機能説明書」が成果物となります。成果物の粒度（フローチャート・業務仕様書・詳細設計書）はプロジェクト費用に直接影響するため、過不足ない要件定義が重要です。また「変数名の復元」「コメントの自動生成」「業務ロジック背景（Why）のドキュメント化」を成果物要件に明示的に含めることを推奨します。これらを成果物要件として契約に盛り込まないと、技術的に正確でも保守できないコードや仕様書が納品されるリスクがあります。

リバースエンジニアリングにおいて業務部門の協力は不可欠です。ソースコードを解析してHow（処理の流れ）は分かっても、Why（なぜその仕様か）は業務部門の知識なしには復元できません。特にCOBOLやPL/Iで書かれた古いシステムでは、業務ルールが暗黙知として担当者の頭の中にのみ存在することが多く、業務部門へのヒアリングなしでは解析結果の正確性を担保できません。具体的な巻き込み体制として、プロジェクトに業務知識を持つ業務部門担当者を専任で1〜2名参画させること、ベンダーとの定期的なヒアリングセッション（週1〜2回）に出席できる体制を整えること、そして「業務担当者がいつ協力できるか」のスケジュールをWBSに反映させることが重要です。業務部門の協力体制が整っていないプロジェクトは、解析が止まりやすく、納期超過と追加費用の原因になります。

発注の進め方：RFP作成から契約まで

発注のプロセスはRFP（提案依頼書）の作成から始まり、提案評価・ベンダー選定・NDA締結・正式契約へと進みます。各ステップで押さえるべきポイントを解説します。

リバースエンジニアリングのRFPには、通常のシステム開発RFPに比べて追加で記載すべき項目があります。基本事項として「プロジェクトの背景・目的」「対象システムの概要（言語・規模・稼働状況）」「求める成果物の定義と粒度」「スケジュール・納期」「予算規模の目安」を含めます。リバースエンジニアリング固有の項目として「言語ごとの見積もり方法（LOC課金の計算方法と言語補正の考え方）」「成果物のフォーマット・サンプル提示の要求」「クリーンルーム体制の運用方法の説明要求」「業務部門との連携方法の提案要求」「変数名復元・コメント生成・業務ロジック背景ドキュメント化への対応方針」も明記します。また、過去の類似プロジェクトの実績（言語・規模・成果物サンプル）の提示を求めることで、ベンダーの実力を事前に評価できます。RFPは3〜5社程度に配布し、提案内容と費用を横比較することが適正価格での発注につながります。

リバースエンジニアリングの契約では、通常の秘密保持契約（NDA）に加えて、著作権法上のコンプライアンスを担保するための特別条項が必要です。NDA条項では、解析対象のソースコードを解析目的以外に使用しないこと、プロジェクト終了後にソースコードを返却または確実に削除することを明記します。クリーンルーム手法の運用については、解析チームと開発チームを完全に分離することの合意、解析チームの作成した成果物（仕様書）に著作権保護対象の「表現」が混入していないかを確認するレビュープロセスの設置、法務・仲介担当者の配置と役割を契約書に明記することを推奨します。また「非享受目的」の立証可能性を高めるため、解析過程をレポート・作業ログとして記録し、発注側に開示できる体制を契約条件に含めることも重要です。著作権法上の問題が後から発生した際に、適切な記録が残っていることがリスク管理の基本です。

プロジェクト推進時の役割分担と体制設計

リバースエンジニアリングプロジェクトを成功させるには、業務部門・IT部門・ベンダーの3者が明確な役割分担のもとで連携することが不可欠です。役割が曖昧なままプロジェクトを進めると、解析が止まったり成果物の方向性がズレたりする原因になります。

業務部門の役割は「業務ロジックの意図（Why）の提供者」です。ベンダーから提示された解析結果（処理フロー・業務ルールの仮説）に対してレビューを行い、「この条件分岐は〇〇の場合に適用される」「この計算式は〇〇を目的としたもの」という業務背景を補足します。業務部門は週1〜2回のヒアリングセッションに参加し、解析精度を高める役割を担います。IT部門（発注側）の役割は「プロジェクト全体のガバナンス」です。ベンダーの進捗管理・品質レビュー・スコープ変更の判断、業務部門とベンダーの橋渡し、そして法的コンプライアンスの監督を担当します。また、解析に使用するソースコードへのアクセス権限の管理と、情報セキュリティ上のリスク管理も IT部門の責任範囲です。ベンダーの役割は「技術的な解析と成果物の作成」です。静的解析・動的解析・Design Recoveryを担当し、業務部門へのヒアリングセッションを企画・ファシリテートし、合意した成果物を規定の品質・粒度・納期で提供します。

リバースエンジニアリングプロジェクトのWBS（作業分解構造）は、フェーズ分けと成果物のマイルストーン設定が鍵です。標準的なフェーズ構成は以下の通りです。第1フェーズ「準備・スコープ確定（1〜2週間）」では、ソース資産の棚卸し確認・解析環境の整備・解析スコープの最終合意を行います。第2フェーズ「静的解析（規模により2〜8週間）」では、逆コンパイル・制御フローグラフ作成・データフロー分析を実施します。第3フェーズ「動的解析・業務ヒアリング（2〜6週間）」では、デバッガを使った実行トレースと業務部門へのヒアリングセッションを並行して進めます。第4フェーズ「成果物化・レビュー（2〜4週間）」では、仕様書・設計書の作成と発注側レビュー・修正対応を行います。各フェーズの終わりに成果物のレビューと次フェーズへの進捗確認を設け、スコープの変更が必要な場合は工数・費用・期間への影響を合意した上で変更指示を出す体制を維持することが重要です。

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

リバースエンジニアリングプロジェクトで頻発するトラブルには共通のパターンがあります。事前に対策を講じることで、大半のトラブルは防止できます。

最も多いトラブルの一つが「LOC見積もりの齟齬」です。「4,000行で30万円」という見積もりを受けたのに、実際に解析を進めると「ライブラリコードも含まれていた」「コメント行・空行も行数にカウントされていた」「スコープ外と思っていた外部連携システムの解析も必要になった」といった事態が発生し、当初見積もりの2〜3倍の費用になるケースがあります。この回避策として、見積もり段階で「LOCの計測方法（実行コード行のみか、コメント・空行を含むか）」「スコープに含まれる外部システムの範囲」「難読化・暗号化への対応コストの扱い」を契約書に明記することが重要です。また、スコープ外の追加作業が発生した場合の変更管理プロセス（変更依頼→工数見積もり→承認→実施）を事前に合意しておくことで、勝手に作業を進められて後から費用を請求されるトラブルを防げます。

「仕様書は納品されたが、業務ロジックのWhy（意図）が全く記載されておらず、新システム開発で結局同じ調査をやり直すことになった」というトラブルも多発します。また「変換後のコードが意味不明な変数名だらけで、若手エンジニアが保守できない」という品質問題も頻繁に起きます。これを防ぐには、発注時に成果物のサンプルを提示してもらい、具体的な品質基準（変数名の命名規則・業務ロジックの説明粒度・レビュー回数と対応範囲）を契約に明記することが有効です。また、プロジェクト中間時点での成果物レビューを設け、品質が要件を満たしていない場合は早期に修正を求める体制を整えることが重要です。「納品されたものを受け入れるしかない」という状況にならないよう、受入基準（アクセプタンスクライテリア）を事前に合意しておくことを強く推奨します。

費用相場とコストを抑えるポイント

発注前に費用の全体感を把握しておくことで、予算計画と交渉をスムーズに進めることができます。発注方法の工夫でコストを最適化することも可能です。

仕様書復元（LOC課金）の基本相場は、基本料金30万円（4,000行まで）・超過分1行50円です。小規模プロジェクト（ECサイト機能・API連携など）は30〜80万円が一般的な範囲です。中規模プロジェクト（1〜10万行程度の業務システム）では300〜800万円程度、大規模プロジェクト（10万行以上）では1,000万円を超えるケースも多くあります。モダナイゼーション全体では、リホストで数千万円〜1億円台（3〜6ヶ月）、リプラットフォームで1〜3億円（6〜12ヶ月）、リファクタリングで2〜5億円（12〜18ヶ月）、リビルドで5億円以上（18ヶ月以上）が目安となります。特急対応は通常の20〜60%増となるため、計画的な発注で特急料金を回避することが重要です。

発注方法の工夫によって外注費用を適正化できる方法が4つあります。一つ目は「段階的発注（フェーズ分け）」です。全機能を一括で発注するのではなく、重要度の高い機能から優先的に発注し、成果物の品質を確認してから次フェーズを発注することで、初期リスクを抑えられます。二つ目は「準委任契約と請負契約の使い分け」です。スコープが不確定な初期調査フェーズは準委任契約（時間精算）、成果物が明確な本解析フェーズは請負契約（固定費用）が適しています。三つ目は「内製と外注のハイブリッド」です。ベンダーにしかできない高度な解析作業は外注し、成果物の整理・ドキュメント化の一部は社内担当者が行うことで、外注費用を削減できます。四つ目は「残存ドキュメントの事前整備」です。過去の設計書・仕様書を社内で収集・整理してベンダーに提供することで、調査工数が削減され見積もり金額を下げられます。

まとめ

リバースエンジニアリングの外注を成功させるためには、発注前の「自社側の準備」が最も重要です。ソース資産の棚卸し・目的と成果物要件の明確化・業務部門の巻き込み体制構築という3つの準備を整えることで、RFPの精度が上がり、見積もり・成果物品質・プロジェクト期間の全てが改善されます。

RFPにはリバースエンジニアリング固有の項目（LOC計測方法・クリーンルーム体制・成果物粒度・業務ロジック背景のドキュメント化方針）を明記し、NDA・クリーンルーム手法の契約条項で法的リスクを担保することが不可欠です。プロジェクト推進は業務部門・IT部門・ベンダーの3者が明確な役割分担のもとで進め、WBSにヒアリングセッションと成果物レビューのマイルストーンを設けることで、典型的なトラブルを防止できます。「LOC見積もりの齟齬」「成果物品質の齟齬」「業務ロジック欠損」という3大トラブルへの対策を発注段階で講じておくことが、プロジェクトを成功させるための最も確実なアプローチです。

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

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

また「Boxシリーズ」による、受発注管理・在庫管理・配送管理・業務システム・生成AI・SaaS・マッチングサイト・EC・アプリ・LINEミニアプリなどの標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」を活用することで、低コスト・短期間でのスクラッチ開発を実現いたします。

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

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

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

執筆者プロフィール

張田谷凌央

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