相談する

Reactのリバースエンジニアリングの発注/外注/依頼/委託方法について

仕様書が失われ、改修が難しいReactのシステムを外注するときは、発注前の準備、RFP（提案依頼書）の作成と契約、プロジェクト中の役割分担の順に進めます。DX推進担当者やIT部門のマネージャーから、発注方法が分からないという相談が多く寄せられます。

準備が不十分なまま発注すると、成果物の品質が期待を下回ったり、費用が当初見積もりを大幅に超えたりするおそれがあります。Reactのリバースエンジニアリングは高度な専門技術を要します。そのため、発注経験のない企業にとっては、何を準備すべきか、どのような契約形態が適切か、ベンダーとの役割分担はどうすればいいかなど、分からないことだらけというのが実情です。

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

AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。

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

契約前に整理する対象資産、成果物要件、業務部門の体制を3枚のカードで示す図。
資料・目的・社内体制をそろえると、発注時の認識を合わせやすくなります。

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

対象システム・ソース資産の棚卸し

解析対象のReactアプリについて、社内で入手できる情報を一覧にします。

一覧に入れる情報は、次の6つの種類に分けて確認します。

  1. ソースコードリポジトリ：GitHubやGitLabなどへのアクセス権
  2. 使用ライブラリ：package.jsonやyarn.lockに記載されたバージョン
  3. ソースマップ：ビルド時に生成された.mapファイルの有無と保管場所
  4. 過去の設計資料：設計書・仕様書・画面設計書
  5. API仕様書：OpenAPIのYAMLやSwaggerUIなどの資料
  6. 旧開発ベンダーとのやり取り：メールや要件定義書

これらが一部でも存在する場合、ベンダーに事前に提供することで見積もりの精度が上がり、解析工数と費用の削減につながります。ただし、何も残っていない場合でも、その旨を明確に伝えることが、ベンダーへの適切な情報共有になります。

目的と成果物要件の明確化

「なぜリバースエンジニアリングを行うのか」という目的を明確にすることが、発注仕様書（RFP）作成の核心です。目的によって、必要な成果物の種類と粒度が変わります。

粒度を決めないまま発注すると、ベンダーが「フローチャート」を納品し、発注者は「詳細設計書」を期待していたといったミスマッチが頻発します。

代表的な目的ごとに、RFPで求める成果物の組み合わせを示すと、次の4つになります。

  • 保守担当者の引継ぎ：画面遷移図と主要機能の業務仕様書で足りる場合があります。
  • 次期システムの開発ベンダーにRFPを出す：業務仕様書レベルの成果物
  • システムを完全に作り直す：コンポーネント設計・API仕様・DB設計を含む詳細設計書
  • セキュリティ診断を行う：脆弱性レポートの形式

発注側は、ベンダーにサンプルやテンプレートを提示してもらい、期待する品質と粒度を事前に確認することを強く推奨します。

業務部門の巻き込み体制の構築

Reactのリバースエンジニアリングで最も見落とされやすいのが、業務部門の巻き込みです。

ベンダーはコードを解析して「How（どう動くか）」を把握できますが、「Why（なぜその仕様になっているか）」は、コードだけでは分からないことが多くあります。

業務ルールの背景を理解するには、現場の業務担当者へのヒアリングが欠かせません。たとえば、次の3点を現場に確かめます。

  • 条件分岐：なぜその場所に分岐があるのか
  • ステータス：そのステータスが何を表すか
  • API：どの業務処理に対応しているか

そこで、プロジェクト開始前に社内の体制を整え、各部門から窓口担当者を1名指名して、週1回程度のヒアリング時間を確保しておきます。業務知識を持つ担当者が退職予定の場合は、優先的にヒアリングを実施します。業務部門の協力が得られないと、技術的な解析が完了しても業務仕様の復元が不完全なまま終わるリスクがあります。

ポイント

資料の有無にかかわらず、目的に合う成果物の粒度を決め、業務部門の窓口を置けているかが、発注前の準備が足りているかを見分ける目安です。

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

解析対象のシステムを中央に置き、アクセス権限、保管、廃棄、クリーンルーム手法を周囲に配置した図。
情報へのアクセスからプロジェクト終了後の廃棄まで、管理範囲がつながります。

準備が整ったら、RFP（提案依頼書）の作成から契約締結まで、実際の発注を進めます。その際は、React固有の注意点も押さえておく必要があります。

RFPに含めるべきReact固有の項目

一般的なシステム開発のRFPに加えて、Reactのリバースエンジニアリング特有の項目も必ず盛り込みます。

技術情報としては、次の項目を示します。

  • 技術スタック：Reactのバージョンと状態管理ライブラリ（Redux・Zustand・Recoil・Context APIなど）
  • ビルド環境：バンドラー・ビルドツール（Webpack・Vite・Create React Appなど）
  • API：種類（RESTまたはGraphQL）とエンドポイントの概要
  • ソースマップ：有無
  • ソースコードリポジトリ：アクセスの可否

技術情報のうち分からない項目は、調査が必要な情報として明示します。解析範囲には、解析対象の機能・画面一覧（既知の範囲で）、優先度の高い機能・低い機能の区分、解析対象外とする機能（例：管理画面は対象外など）を入れます。

成果物要件では、納品物の種類（フローチャート・業務仕様書・詳細設計書）と文書形式（ExcelかWord・MarkdownかNotionかPlantUMLかなど）を決めます。さらに、中間成果物の提出タイミングを含む、レビューとフィードバックのサイクルを定めます。

NDA・クリーンルーム手法の契約条項

Reactのリバースエンジニアリングを外注する契約では、守秘義務（NDA）は必須です。解析対象のシステムはビジネス上の重要資産であるため、ベンダー側の情報管理体制（誰がアクセスできるか、保管場所はどこか、プロジェクト終了後の情報の廃棄方法）を契約に明記します。

情報管理体制には、次の3点を含めます。

  • アクセス権限：アクセスできる人の範囲
  • 保管：情報を置く場所
  • 廃棄：プロジェクト終了後の情報をどう廃棄するか

他社が権利を持つシステムのリバースエンジニアリングを行う場合は、「クリーンルーム手法」に関する条項も必要です。そのうえで、解析チームと開発チームの分離、法務仲介担当者の配置、解析成果物が純粋な「機能」「アルゴリズム」「データ構造」の記述のみであることを、著作権帰属の条件として契約書に明確に定めます。

また、成果物の著作権を発注者に帰属させ、ベンダーが同様の解析成果物を他社に流用しないことを約束する条項も盛り込みます。特にAPIの認証情報や機密データを解析環境で扱う場合は、情報セキュリティの詳細な規定を契約条項に加えることを推奨します。その規定には、アクセスログの記録、専用端末の使用義務、リモートアクセスの制限が含まれます。

ポイント

RFPにReact固有の技術情報と解析範囲を書き込み、NDAとクリーンルームの条項を契約に入れられているかが、契約前の判断の目安になります。

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

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

3者の役割と責任範囲

3者が担う範囲は、次のように分けて確認しておきます。

  • 業務部門：業務ルールの知識の提供、ヒアリングへの対応、解読したコードの動作と業務の意図の照合
  • IT部門（発注側）：技術情報（ソースコード・ソースマップ・APIアクセス権限）の提供、週次の進捗確認会議の運営、成果物の技術的な妥当性の確認
  • ベンダー：技術解析と成果物作成、API通信や状態管理の流れの把握、業務部門への質問リストの作成と定期的なヒアリングの依頼

業務部門は、コードだけでは分からない背景知識も伝えます。たとえば、「この条件がなぜあるのか」「このステータス遷移のルールはなぜこうなっているのか」といった点です。

WBS・コミュニケーション計画の雛形

ReactのリバースエンジニアリングのプロジェクトWBSは、次の5つのフェーズで構成するのが標準的です。

  • フェーズ1（準備：1〜2週間）：情報収集、環境構築、解析計画の作成
  • フェーズ2（静的解析：2〜4週間）：Webpackバンドル解析、コンポーネント構造の把握、状態管理ライブラリの特定
  • フェーズ3（動的解析：2〜4週間）：API通信の記録、REST/GraphQLのエンドポイント一覧化、状態管理（Redux/Zustand）のアクション一覧作成
  • フェーズ4（抽象化・成果物作成：2〜6週間）：解析した情報を目的に応じた粒度の仕様書・設計書にまとめる作業
  • フェーズ5（レビュー・修正：1〜2週間）：業務部門とIT部門によるレビューと、フィードバックへの対応

コミュニケーション計画では、次の3つの会議・確認を設けることを推奨します。

  • 週次進捗会議：ベンダー×IT部門
  • 隔週の業務ヒアリング：ベンダー×業務部門×IT部門
  • 月次マイルストーン確認：全関係者

ポイント

業務ルールの知識、技術情報の提供、進捗と品質の確認が3者のどこに割り当てられているか、また週次・隔週・月次の会議がそろっているかを見れば、体制の抜けに気づけます。

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

見積もり、成果物品質、業務ルールに対応する発注条件を3つのパネルで示す図。
見積もりの前提、納品物の基準、業務知識の確認が予防の柱になります。

Reactのリバースエンジニアリングの外注で実際に起きているトラブルと、その回避策を、パターンごとに見ていきます。事前に把握しておけば、リスクを大幅に減らせます。

LOC見積もりの齟齬・費用超過

最も多いトラブルは、LOCベースの見積もりと実際の作業量の大きな乖離です。たとえば、ベンダーがminify後のバンドルファイルの行数（数百〜数千行程度）で見積もりを出したため、費用が安く見えたケースがあります。ところが、実際の解析工数はバンドル前のソースコード（数万行相当）を解析する難度に当たり、途中で追加費用の請求を受けました。

回避策は、見積もり時に「バンドル前のソースコードの推定行数または解析工数（人日）をベースに見積もりを提示すること」をRFPに明記することです。また、見積もり提示時の前提条件（どのような情報を基に見積もったか）を書面で確認し、前提が変わった場合の変更対応を契約に定めておくことも有効です。

成果物の保守性・品質不足

仕様書は受け取ったものの、内容が不完全でそのまま使えないというトラブルも頻発します。たとえば、ReactのAPIレスポンスのデータ構造は記載されていても、そのデータがどの業務ルールに基づくかが書かれていないケースがあります。また、コンポーネントの一覧はあっても、各コンポーネントの業務上の役割が説明されていない場合もあります。

回避策は、RFPに成果物要件を「機能レベル」だけでなく、「業務ルールの記述水準」まで具体的に定義することです。たとえば、「バリデーションルールをすべて記載すること」「エラーコードとその業務的な意味を記載すること」といった基準を、要件に明記します。さらに、状態管理のアクション一覧にビジネスコンテキストを注釈として付与する基準も、要件に含めます。

発注側は、中間成果物のレビューを設けて、品質を早い段階で確かめます。

業務ルールの欠損・復元失敗

「コードは全て解析できたが、なぜその仕様になっているかが分からず、新システムに正確に移行できなかった」という業務ルール欠損のトラブルも深刻です。ReactのSPAでは、フロントエンドのコンポーネントロジック・API通信・状態管理をすべて解析しても、バックエンドで適用されているビジネスルールの「Why（なぜ）」は、コードから復元できないことがあります。

回避策は、業務部門へのヒアリングをプロジェクト計画に組み込むことと、不明点を明示したまま成果物を完成させ、業務確認後に補完するプロセスを設けることです。また、現役の業務担当者だけでなく、そのシステムの企画・要件定義に関わったOB・OG社員へのヒアリングも検討したいところです。

業務ルールの「Why」を復元するには、技術的な解析に加えて、人的な知識の収集が不可欠です。

トラブルを防ぐには、見積もり条件、成果物品質、業務ルールの各項目を発注条件に組み込みます。

  • 見積もり条件：バンドル前ソースコードの行数または解析工数
  • 成果物品質：業務ルールの記述水準（RFPに明記）
  • 業務ルール：業務部門へのヒアリング（計画への組み込み）

ポイント

見積もりの条件、成果物の品質、業務ルールの3点を発注条件に入れておけば、よくあるトラブルの多くは防げます。判断に迷ったときは、この3点に照らして確かめてください。

まとめ

Reactのリバースエンジニアリングを成功させるには、①対象システム情報の棚卸し、②目的と成果物要件の明確化、③業務部門の巻き込み体制の構築の順に進めます。続いて、④React固有項目を含むRFPの作成、⑤NDA・クリーンルーム手法の契約条項の整備、⑥3者（業務部門・IT部門・ベンダー）の役割分担の確立へと進むことが重要です。

よくあるトラブル（LOC見積もりの齟齬・成果物品質不足・業務ルール欠損）はいずれも、発注側の準備と仕様の明確化によって大部分を回避できます。

Reactのリバースエンジニアリングは、フロントエンド特有の難しさを持つ専門領域です。しかし、適切な準備と体制構築により、システムの仕様復元、モダナイゼーション、セキュリティ強化など、組織にとって大きな価値をもたらすプロジェクトになります。

本記事を参考に、発注計画を一歩ずつ着実に進めてください。

開発を相談する前に、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」もご覧ください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。