「Reactで構築したシステムの仕様書が失われており、改修もままならない状態です。リバースエンジニアリングを外部に依頼したいのですが、どうやって発注すればいいか分からない」——このような相談は、DX推進担当者やIT部門のマネージャーから非常に多く寄せられます。Reactのリバースエンジニアリングは高度な専門技術を要するため、発注経験のない企業にとっては「何を準備すべきか」「どのような契約形態が適切か」「ベンダーとの役割分担はどうすればいいか」など、分からないことだらけというのが実情です。適切な準備なく発注を進めると、成果物の品質が期待を下回ったり、費用が当初見積もりを大幅に超過したりといったトラブルに発展するリスクがあります。

本記事では、Reactのリバースエンジニアリングを外注する際の発注準備・RFP作成・契約・プロジェクト推進・よくあるトラブルの回避まで、実務レベルの手順を体系的に解説します。React固有の発注ポイントも随所に盛り込んでいますので、初めてリバースエンジニアリングを外注する方にも役立つ内容です。

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

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

リバースエンジニアリングの外注において、発注側の準備不足はプロジェクト失敗の主な原因の一つです。ベンダーと契約する前に、発注側が社内で整理しておくべき5つの項目を解説します。

まず「解析対象のReactアプリに関して、社内で入手できる情報を全て収集・棚卸し」することから始めます。収集すべき情報は以下の通りです。①ソースコードリポジトリへのアクセス権（GitHubやGitLabのリポジトリが存在するか、アクセスできるか）②package.jsonやyarn.lock（使用ライブラリのバージョン一覧が分かる）③ビルド時に生成されたソースマップ（.mapファイル）の有無と保管場所④過去の設計書・仕様書・画面設計書（一部でも残っていれば解析工数削減に直結）⑤API仕様書（OpenAPIのYAMLやSwaggerUI等）の有無⑥旧開発ベンダーとのやり取りメール・要件定義書。これらが一部でも存在する場合、ベンダーに事前提供することで見積もりの精度が上がり、解析工数・費用の削減につながります。「何も残っていない」という場合でも、それを明確にすることがベンダーへの適切な情報共有となります。

「なぜリバースエンジニアリングを行うのか」という目的を明確にすることが、発注仕様書（RFP）作成の核心です。目的によって必要な成果物の種類・粒度が異なります。「保守担当者の引継ぎのため」なら画面遷移図＋主要機能の業務仕様書で足りる場合があります。「次期システムの開発ベンダーにRFPを出すため」なら業務仕様書レベルが必要です。「システムを完全に作り直すため」なら詳細設計書（コンポーネント設計・API仕様・DB設計含む）が必要です。「セキュリティ診断を行うため」なら脆弱性レポートの形式が成果物になります。成果物の粒度を明確にせずに発注すると、ベンダーが「フローチャート」を納品したのに発注者は「詳細設計書」を期待していたというミスマッチが頻発します。成果物のサンプルやテンプレートをベンダーに提示してもらい、期待する品質・粒度を事前に確認することを強く推奨します。

Reactのリバースエンジニアリングで最も見落とされやすいのが、業務部門の巻き込みです。ベンダーはコードを解析して「How（どう動くか）」を把握できますが、「Why（なぜその仕様になっているか）」はコードからは分からない場合が多くあります。例えば「この条件分岐がなぜここにあるのか」「このステータスの意味は何か」「このAPIは何の業務処理に対応しているか」といった業務ルールの背景を理解するためには、現場の業務担当者へのヒアリングが不可欠です。プロジェクト開始前に、以下の体制を社内で整えておきましょう。①業務部門の窓口担当者を各部門から1名指名する②週1回程度のヒアリング時間を確保する③業務知識を持つ担当者が退職予定の場合は優先的にヒアリングを実施する。業務部門の協力が得られないと、技術的な解析は完了しても業務仕様の復元が不完全なまま終わるリスクがあります。

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

準備が整ったら、実際の発注プロセスを進めます。RFP（提案依頼書）の作成から契約締結までの流れを、React固有の注意点を交えながら解説します。

一般的なシステム開発のRFPに加えて、Reactのリバースエンジニアリング特有の項目を必ず盛り込みます。技術情報として記載すべき内容は以下の通りです。①Reactのバージョン（既知の場合）②状態管理ライブラリ（Redux・Zustand・Recoil・Context APIなど、既知の場合）③バンドラー・ビルドツール（Webpack・Vite・Create React Appなど）④APIの種類（REST/GraphQL）とエンドポイントの概要⑤ソースマップの有無⑥ソースコードリポジトリへのアクセス可否。解析範囲として記載すべき内容は、「解析対象の機能・画面一覧（既知の範囲で）」「優先度の高い機能・低い機能の区分」「解析対象外とする機能（例：管理画面は対象外など）」です。成果物要件として記載すべき内容は「納品物の種類（フローチャート・業務仕様書・詳細設計書）」「文書形式（ExcelかWord・MarkdownかNotionかPlantUMLかなど）」「レビューとフィードバックのサイクル（中間成果物の提出タイミング）」です。

Reactのリバースエンジニアリングを外注する際の契約では、守秘義務（NDA）は必須です。解析対象のシステムはビジネス上の重要資産であるため、ベンダー側の情報管理体制（誰がアクセスできるか・保管場所はどこか・プロジェクト終了後の情報廃棄方法）を契約に明記します。他社が権利を持つシステムのリバースエンジニアリングを行う場合は、「クリーンルーム手法」に関する条項も必要です。解析チームと開発チームの分離・法務仲介担当者の配置・解析成果物の著作権帰属（純粋な「機能」「アルゴリズム」「データ構造」の記述のみであること）を契約書に明確に定義します。また、成果物の著作権が発注者に帰属することを明記し、ベンダーが同様の解析成果物を他社に流用しないことを約束する条項も含めましょう。特にAPIの認証情報・機密データを解析環境で扱う場合は、情報セキュリティに関する詳細な規定（アクセスログの記録・専用端末の使用義務・リモートアクセスの制限）も契約条項に加えることを推奨します。

プロジェクト推進時の役割分担（業務部門×IT部門×ベンダー）

Reactのリバースエンジニアリングプロジェクトを成功させるには、発注側の業務部門・IT部門・外注ベンダーの3者が明確な役割を持って連携することが不可欠です。

業務部門の役割は「業務ルールの知識提供とヒアリング対応」です。ベンダーがAPIレスポンスや状態管理から解読した「コードの動作」が「業務の意図」と合致しているかを確認し、コードだけでは分からない背景知識（「この条件がなぜあるのか」「このステータス遷移のルールはなぜこうなっているのか」）を提供します。IT部門（発注側）の役割は「システム情報の提供・進捗管理・品質確認」です。技術的な情報（ソースコード・ソースマップ・APIアクセス権限）のベンダーへの提供、週次での進捗確認会議の運営、成果物の技術的な妥当性確認を担います。ベンダーの役割は「技術解析・成果物作成」です。Reactのコード解析・API通信の記録・状態管理のトレース・成果物（仕様書・設計書）の作成を担当します。解析途中で生じた疑問点を業務部門への質問リストとしてまとめ、定期的にヒアリングを依頼します。

ReactのリバースエンジニアリングのプロジェクトWBSは以下の構成が標準的です。フェーズ1（準備：1〜2週間）として、情報収集・環境構築・解析計画作成を実施します。フェーズ2（静的解析：2〜4週間）として、Webpackバンドル解析・コンポーネント構造の把握・状態管理ライブラリの特定を行います。フェーズ3（動的解析：2〜4週間）として、API通信の記録・REST/GraphQLのエンドポイント一覧化・状態管理（Redux/Zustand）のアクション一覧作成を行います。フェーズ4（抽象化・成果物作成：2〜6週間）として、解析情報を目的に応じた粒度の仕様書・設計書にまとめます。フェーズ5（レビュー・修正：1〜2週間）として、業務部門・IT部門によるレビューとフィードバック対応を行います。コミュニケーション計画としては、週次進捗会議（ベンダー×IT部門）・隔週業務ヒアリング（ベンダー×業務部門×IT部門）・月次マイルストーン確認（全関係者）を設定することを推奨します。

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

Reactのリバースエンジニアリングの外注で実際に発生しているトラブルのパターンと、その回避策を解説します。事前に把握することでリスクを大幅に低減できます。

最も多いトラブルが「LOCベースの見積もりと実際の作業量の大きな乖離」です。ベンダーがminify後のバンドルファイルの行数（数百〜数千行程度）で見積もりを出したために費用が安く見えたが、実際の解析工数はバンドル前のソースコード（数万行相当）を解析する難度に相当し、途中で追加費用を請求されたというケースです。回避策は、見積もり時に「バンドル前のソースコードの推定行数または解析工数（人日）をベースに見積もりを提示すること」をRFPに明記することです。また「見積もり提示時の前提条件（どのような情報を基に見積もったか）」を書面で確認し、前提が変わった場合の変更対応プロセスを契約に定めておくことも有効です。