VB.netのリバースエンジニアリングを外注しようと決断しても、「どのように発注すればよいか」「何を準備すれば失敗しないか」がわからず、最初の一歩が踏み出せないという担当者の方は少なくありません。通常のシステム開発とは異なり、リバースエンジニアリングの発注では「成果物の品質をどう定義するか」「業務ルールの意図をどう伝えるか」といった、発注側が積極的に関与しなければ品質が担保されない固有の課題があります。特にVB.netシステムでは、VB6（クラシックVB）との混在、GUIと業務ロジックの分離不明確、COM相互運用（COMインターオペラビリティ）の複雑さ、そして社内のVB.net経験者不足といった固有の難しさが発注プロセスをさらに複雑にします。

本記事では、VB.netのリバースエンジニアリングを外注・委託する際の発注準備から、発注先の選定、RFP作成・契約・プロジェクト推進・よくあるトラブルの回避策まで、実務ベースで詳しく解説します。VB.netとVB6の違いを発注側が正しく理解しているかどうかがプロジェクトの成否を大きく左右するため、チェックリストとして活用しながら読み進めてください。

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

VB.netリバースエンジニアリングを外注する前の準備

VB.netのリバースエンジニアリングを成功させるには、発注側の事前準備が決定的に重要です。ベンダー選定や発注作業に入る前に、対象システムの資産状況を正確に把握し、目的と成果物要件を明確化し、業務部門の協力体制を確保しておく必要があります。この準備を怠ると、見積もりの大幅な齟齬や成果物品質の不満につながります。

最初に対象システムのソース資産を棚卸しします。VB.netプロジェクト（.vbprojファイル）の一覧、ソリューション構成、ファイル数・行数の概算を確認してください。Visual StudioのWindowsフォームアプリケーションでは、デザイナー自動生成コードがLOCに大量に含まれるため、「業務ロジック部分のLOC」と「全LOC（デザイナーコード含む）」の両方を事前に把握しておくことが重要です。LOC従量課金で見積もりを取る場合、この区別がなければベンダーとの見積もり認識に大きなズレが生じます。

次に既存のドキュメント資産を確認します。古い設計書・画面仕様書・フローチャートが存在する場合、古くても保有しておくことでベンダーの解析精度が向上し、工数が削減されます。「ドキュメントが存在しない」というケースでも、変更履歴（Gitコミット履歴・SVNログ等）や課題管理システム（Redmine・JIRA等）のチケット履歴が業務ロジックの変遷を追う手がかりになることがあります。これらの情報を事前にまとめてベンダーに提供することで、見積もり精度と解析品質の両方が向上します。

VB.netのリバースエンジニアリング発注において、最も見落とされがちで最も深刻な問題が「VB6との混在」です。VB.netとVB6は名前こそ似ていますが、言語仕様は全く異なります。VB6はCOMベースのランタイムで動作するインタープリタ言語であり、VB.netは.NET CLRランタイム上で動作するコンパイル言語です。エラーハンドリングの仕組み、オブジェクト指向の実装方式、データ型の扱い、API呼び出しの方式がそれぞれ根本的に異なるため、両者が混在するシステムは解析難易度が格段に上がります。

特にCOM相互運用（VB6コンポーネントを.NETのコーラーから利用するCOMインターオペラビリティ）が使われているシステムは、解析に特殊な工数が必要です。GACに登録されたCOM DLL（.vbp・.cls・.bas・.frm形式）の存在有無を必ず確認し、発注前にベンダーへ伝えてください。VB6コンポーネントの存在を後から発見した場合の追加費用算定方法を契約時に決めておくことも欠かせません。また、使用している.NET Frameworkのバージョン（.NET 2.0〜4.8 / .NET 5以降）を確認しておくことで、対応するリバースツールの選定に影響します。発注側がVB.netとVB6の違いを正確に把握していることが、プロジェクトの成否を分ける第一歩となります。

「なぜリバースエンジニアリングをするのか」という目的の明確化は、成果物の粒度・品質基準・スコープのすべてを決定する起点となります。主な目的は大きく3つに分類できます。第一は「引き継ぎ問題の解決」で、担当者退職後に誰も業務ロジックを理解していない状態を解消するための仕様書復元です。この場合は業務仕様書レベル（機能一覧・業務フロー・画面仕様・入出力定義）が必要最低限の成果物となります。第二は「C#等への移行準備」で、VB.netからC#への移行を見据えて業務ロジックを文書化する目的です。

C#移行を想定した発注の場合は特に注意が必要です。単に業務仕様書を作成するだけでなく、詳細設計書レベルの成果物に加え、言語変換後の動作保証テスト費用を見積もりに明示させることが重要です。VB.netからC#への変換ツールによる自動変換は技術的には可能ですが、変換後コードが「若手エンジニアで保守可能な品質か」という保守性の観点での確認が必須です。逆コンパイルで得られた変数名のない断片的なコードをそのまま転記した仕様書は、C#移行の要件定義には使えません。第三の目的は「セキュリティ診断」で、自社製品の脆弱性を特定するための解析です。この場合はセキュリティレポートが成果物となり、業務仕様書とは別の観点での解析が主体となります。

発注先の選定

VB.netのリバースエンジニアリングは、通常のシステム開発会社やセキュリティ専門企業など複数の発注先候補がありますが、対象システムの特性に応じて適切な発注先を選ぶことが重要です。特にVB.net固有の対応実績とクリーンルーム運用体制の有無が、発注先選定における最重要の確認ポイントとなります。

発注先候補となるベンダーに対して、VB.net固有の対応実績を必ず確認してください。確認すべき実績の具体的な観点は以下のとおりです。まず「VB.net（VB6ではなく）のリバースエンジニアリングを過去に実施したか」を直接確認します。VB6のリバース実績はあるがVB.netは初めてというベンダーは、.NET CLRの逆コンパイル特性を正しく理解していない可能性があります。VB.netはILSpy・dnSpy・JetBrains dotPeekといった.NET専用の逆コンパイラで比較的ソースに近い形まで復元できる一方、GUIとビジネスロジックが混在したWindowsフォームコードの解読には特有のノウハウが必要です。

次に、VB6との混在システムの対応実績を確認します。COM相互運用（COMインターオペラビリティ）の解析経験があるかどうかは、発注先の技術力を測る重要な指標です。対応実績の確認では「過去の成果物サンプル（機密情報を除いたもの）の提示」を依頼することが効果的です。フローチャートのみか、業務仕様書レベルか、詳細設計書レベルかという成果物の粒度と品質を事前に確認することで、納品後の品質不満を防ぐことができます。また、C#移行を前提とした発注の場合は「C#への言語変換経験と動作検証実績」も確認してください。変換後コードの保守性（変数名復元・コメント生成・業務ロジックの背景ドキュメント化）まで対応できるかどうかが、長期的なプロジェクト成功を左右します。

発注先選定において、クリーンルーム手法を自社プロセスとして実際に運用できる体制があるかを確認することは法的リスク管理の観点から欠かせません。クリーンルーム手法とは、解析チーム（Dirty Room）と開発チーム（Clean Room）を完全に分離し、著作権侵害（依拠性）を回避する手法です。1980年代にフェニックス・テクノロジーズがIBM BIOSを合法的に逆エンジニアリングした際に確立された手法であり、解析チームが作成した仕様書のみを開発チームに引き渡し、元ソースコードは開発チームが一切閲覧しないという厳密な運用が必要です。

クリーンルーム手法を自社プロセスとして運用できる体制があるかどうかを見極めるには、「解析チームと開発チームの分離が社内規定として文書化されているか」「仕様書に著作権保護対象の表現が混入していないかを確認する法務・仲介担当者が配置されているか」「セガ対アッコレード事件（1993年）のような先例を踏まえた法的リスク管理ができているか」を具体的に確認してください。これらの体制が整っていないベンダーに発注すると、後日著作権侵害のリスクが発注側にも及ぶ可能性があります。「クリーンルーム手法を適用する」という言葉だけでなく、具体的な運用プロセスを提示できるかどうかで判断することが重要です。

RFP作成と契約

発注先候補が絞り込めたら、RFP（提案依頼書）を作成して各社に提案を求めます。VB.netのリバースエンジニアリングのRFPには、通常のシステム開発とは異なるVB.net固有の情報を必ず含める必要があります。契約段階での法的リスク管理も同様に重要です。

VB.netのリバースエンジニアリングのRFPには、以下の固有情報を必ず記載してください。対象システムの概要（業務機能・規模・稼働年数）、VB.netのバージョン・.NET Frameworkのバージョン（2.0〜4.8 / .NET 5以降を区別）、VB6コンポーネントの有無と概要（COMインターオペラビリティの有無）、ファイル数・推定LOC（業務ロジック部分と全LOCの両方）、難読化ツールの適用有無、既存ドキュメントの有無と種類、データベーススキーマの構造（SQL Server等）です。

成果物の要件についても具体的に記載します。フローチャート・業務仕様書・詳細設計書のどのレベルが必要かを明記し、「新システム開発の要件定義に直接使用できるレベル」という品質基準を言語化してください。C#への移行を想定した発注の場合は「テストケース仕様書の作成有無」「言語変換後の動作保証テスト費用の明示」「変換後コードの保守性基準（変数名復元・コメント生成の有無）」を追加します。ベンダーに対しては「VB6混在システムの対応実績」「クリーンルーム手法の運用体制の詳細」「業務部門へのヒアリング実施方法と頻度」「VB6コンポーネント発見時の追加費用算定方法」を提案書に明記するよう求めることで、各社の対応力を比較しやすくなります。

VB.netのリバースエンジニアリングの発注では、契約段階での法的リスク管理が非常に重要です。まずNDA（秘密保持契約）は必ず最初に締結してください。リバースエンジニアリングの過程でソースコード・業務データ・ビジネスロジックへのアクセスが発生するため、情報漏洩リスクへの対処が不可欠です。NDAには秘密情報の定義・利用目的の制限（解析業務のみに限定）・漏洩時のペナルティ・契約終了後の情報返却・廃棄義務を明記します。

次に、クリーンルーム手法の適用を契約条項として明記することをお勧めします。「解析チームが作成した仕様書のみを開発チームに引き渡す」「法務・仲介担当者が仕様書に著作権保護対象の表現が混入していないかを確認する」「仕様書には純粋な機能・アルゴリズムの記述のみを含め、元ソースコードの表現は含めない」というプロセスを契約条項に含めることで、後日の法的トラブルを防ぎます。さらに、「非享受目的」（著作権法第30条の4）での解析であることを証明するため、解析過程の記録・レポートの作成・保存を義務付ける条項も有効です。解析専用のパソコンを用意して実行し、解析過程をレポートに記録することで、事後的に「機能享受目的ではない」ことを立証できる体制を整えてください。

プロジェクト推進の役割分担

VB.netのリバースエンジニアリングプロジェクトを円滑に推進するには、業務部門・IT部門・ベンダーの三者の役割を明確に分担し、それぞれの責任範囲を事前に確定しておくことが重要です。この三者連携が機能しないプロジェクトでは、成果物の品質低下や工期の長期化が避けられません。

プロジェクト開始前に、業務部門・IT部門・ベンダーの三者でWBS（Work Breakdown Structure）を共同で作成することを推奨します。WBSに含めるべき主要タスクと担当者の割り当ては以下のとおりです。ベンダーの担当タスクは、対象ソースコードの受領・環境構築、静的解析（逆コンパイル・制御フロー解析・データフロー解析）、VB6コンポーネントのCOMインターオペラビリティ解析、動的解析（デバッガによる実行トレース）、業務部門へのヒアリング実施（週次）、仕様書ドラフト作成・修正、クリーンルーム手法の記録保持です。

IT部門の担当タスクは、ソースコード・実行ファイル・関連ライブラリの安全な受け渡し（暗号化転送）、解析に必要な開発環境の提供（Windowsバージョン・.NET Frameworkバージョン・SQL Serverバージョン等）、データベーススキーマ・テーブル定義の提供、プロジェクト全体のスケジュール管理・進捗確認、ベンダーと業務部門の橋渡し役です。業務部門の担当タスクは、ベンダーのヒアリングへの対応（週1〜2回）、業務ロジックの意図・背景の説明、仕様書ドラフトの内容確認・承認、現行機能の要否判断（不要機能の特定）です。このWBSを契約書の附属資料として添付しておくことで、責任範囲の認識齟齬を防ぐことができます。

VB.netのリバースエンジニアリングでは、コードの技術的解析だけでは業務ロジックの「意図（Why）」を復元できません。ある計算式がなぜその係数を使っているのか、ある分岐条件がどのビジネスルールに基づいているのかは、コードから読み取れない情報であり、業務部門のキーパーソンへのヒアリングによってのみ補完できます。コードから「どう動くか（How）」はベンダーが解析できますが、「なぜそうなのか（Why）」は業務部門の協力なしには復元できません。

業務部門の協力を効果的に引き出すためには、発注前に業務部門の協力体制を確保し、ヒアリング対応が可能な担当者を確定させておくことが必須です。具体的には、対象システムの業務を最もよく知っている社員（元担当者・長期利用者・業務責任者）をリストアップし、プロジェクト期間中に週数時間のヒアリング対応ができる体制を事前に確保してください。「コードを読んで疑問に思った箇所のリスト」をベンダーが週次で発注側に提示し、業務部門が翌週までに回答するというサイクルを設定することが効果的です。業務部門の担当者が解析工程で積極的に関与するかどうかが、最終的な成果物の品質を最も左右する要因です。業務部門の協力が得られない場合、リバースエンジニアリングの成果物は「どう動くかはわかるが、なぜそうなのかがわからない仕様書」となり、後の新システム開発で業務ロジックの誤解によるバグが多発するリスクが高まります。

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

VB.netのリバースエンジニアリング発注では、特定のトラブルパターンが繰り返し発生しています。事前に知っておくことで、これらのトラブルを回避または最小化できます。特にVB.netに固有のトラブルとして、VB6との混在による見積もり齟齬と、変換後コードの保守性問題の2つは必ず押さえておく必要があります。

最も多いトラブルが「見積もりと実際の費用の齟齬」であり、VB6/VB.net混在システムではこのリスクが特に高まります。第一の齟齬原因はデザイナーコードによるLOC膨張です。VB.netのWindowsフォームアプリケーションでは、Visual Studioが自動生成するデザイナーコードがLOCに大量に含まれており、「実際の業務ロジックは5,000行だが、デザイナーコードを含めると30,000行になる」というケースがあります。LOC従量課金で見積もりを取る際は、「業務ロジック部分のLOC」と「全LOC（デザイナーコード含む）」を分けた見積もりを提示するよう発注前に確認してください。

第二の齟齬原因はVB6コンポーネントの後発見です。プロジェクト開始後にVB6で開発されたCOM DLLの存在が判明した場合、追加工数が大幅に発生します。VB.netとVB6は解析手法が根本的に異なり、VB6のCOMインターオペラビリティ部分の解析には.NETの逆コンパイラとは別のアプローチが必要となるため、追加費用は単純なLOC比例では算定できません。VB6コンポーネントの存在を後から発見した場合の追加費用算定方法を契約時に合意しておくことが重要です。また、LOC従量課金の「罠」として、VB.netの1万行とCOBOLの1万行では複雑さも1行の意味も全く異なります。言語・コンポーネント種別ごとの適正単価を確認し、行数だけで見積もるベンダーには注意が必要です。

VB.netのリバースエンジニアリングで「仕様書は完成したが、これをもとに新システムを開発できる品質ではなかった」という保守性の齟齬は深刻なトラブルです。逆コンパイルで得られたコードをそのまま仕様書に転記しただけの成果物には、変数名がIL（中間言語）レベルの抽象的な名称のまま（「var_1」「field_2」等）残っていたり、業務ロジックの意図説明がないフローチャートのみであったりするケースがあります。これらは技術的には「解析完了」であっても、実用に耐えない品質です。

この問題を防ぐためには、発注前に「成果物のサンプル」を提示してもらい、品質水準を事前に確認することが有効です。特にC#移行を想定した発注の場合、変換後コードの保守性基準として「変数名の意味的復元」「業務ロジック背景（Why）のコメント記述」「スパゲティコード化の解消」の3点を成果物要件に明記することを推奨します。機械変換だけに頼ったC#変換では、変換後コードが若手エンジニアで保守可能な品質にならない可能性が高く、変換後の動作保証テスト費用を見積もりに明示させることも重要です。成果物の品質基準（「新システム開発の要件定義に直接使用できるレベル」など）を契約書に明記しておくことで、完成物の品質判断基準が明確になり、納品後のトラブルを未然に防ぐことができます。

まとめ

VB.netのリバースエンジニアリングを外注で成功させるための発注前チェックリストをまとめます。準備フェーズでは、対象システムのソース資産棚卸（ファイル数・LOC概算・業務ロジックLOCと全LOCの区別）、VB6コンポーネントの有無確認（GACに登録されたCOM DLL・COMインターオペラビリティの有無）、.NET Frameworkバージョンの確認、目的と成果物要件の明確化（フローチャート/業務仕様書/詳細設計書のどのレベルが必要か）、業務部門の協力体制の確保（ヒアリング対応者の確定）の5点を確認してください。

発注先選定では、VB.net（VB6ではなく）のリバースエンジニアリング実績、VB6混在システムの対応実績、クリーンルーム手法の具体的な運用プロセスの提示可否、成果物サンプルの品質確認を必ず実施してください。RFP作成では、VB.net固有情報（.NETバージョン・VB6混在有無・難読化有無・LOC概算）の記載と、C#移行を想定する場合の動作保証テスト費用の明示を求めることが重要です。契約ではNDAの締結とクリーンルーム手法の条項化、成果物品質基準の明記、VB6コンポーネント後発見時の追加費用算定方法の合意が必須です。プロジェクト推進では、業務部門（Why提供）・IT部門（技術情報・進捗管理）・ベンダー（技術解析・成果物作成）の三者WBSを共同作成し、週次ヒアリングサイクルを設定することで、確実にプロジェクトを成功に導くことができます。

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

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