VB.netのリバースエンジニアリングとは、設計書や仕様書が失われた、あるいは最初から存在しないVB.net製の既存システムに対し、ソースコードを解析することで仕様・設計思想を逆算的に復元する取り組みです。これまでのモダナイゼーション・刷新・更改・リニューアル・リアーキテクチャ・リプレイス・改修という7つのアプローチ、そして「システム移行」という実行フェーズの記事群は、いずれも「何を・なぜ・いつ・どう変えるか」「変える瞬間をどう遂行するか」という意思決定・実行の論点を扱ってきました。これに対してVB.netのリバースエンジニアリングは、そうした意思決定や移行作業に着手する前段、すなわち「今のシステムが何をしているのか、そもそも正確に分かっていない」という状態を解消するための分析・調査フェーズに特化した取り組みです。ドキュメントが存在しないブラックボックス化したVB.netシステムを前に、刷新の判断すら下せない企業にとって、最初に取り組むべき工程がこのリバースエンジニアリングになります。
同じリバースエンジニアリングのクラスタに属する言語横断的な総論記事や、COBOL・C#・C言語・PL/Iといった他言語版の記事群と異なり、本記事が扱うVB.netは技術的に極めて特殊な事情を抱えています。VB6（Visual Basic 6.0）からアップグレードウィザード等を用いて機械的に移行された「過渡期システム」が現場に数多く残存しており、画面上のボタンやテキストボックスに業務ロジックが直接書き込まれる「フォームデザイナ・イベント駆動構造」から、いかにビジネスロジックを分離・抽出するかという固有の難所が存在します。本記事では、VB.netのリバースエンジニアリングにおける開発期間・スケジュール・納期について、一般的な期間感の全体像から、VB.net特有の変動要因、そして期間短縮・納期遵守のための実務ポイントまでを体系的に解説します。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・VB.netのリバースエンジニアリングの完全ガイド
VB.netのリバースエンジニアリングの位置づけ（分析・調査フェーズという特殊性）
VB.netのリバースエンジニアリングの開発期間を正しく見積もるには、まず本記事が扱う工程が「何を目的とした作業なのか」を、隣接する記事群と切り分けて理解しておく必要があります。同じ「老朽化したVB.netシステムに向き合う」というテーマでも、意思決定のための刷新論なのか、切替作業そのものなのか、それとも仕様を復元する分析作業なのかによって、期間を左右する変動要因がまったく異なるためです。
7波・移行波との違い（意思決定・実行の前段にある分析工程）
モダナイゼーション・刷新・更改・リニューアル・リアーキテクチャ・リプレイス・改修という7つの記事群は、いずれも「今のシステムをどう変えるべきか」という意思決定と設計のプロセスに重心を置き、システム移行の記事群は、その意思決定が済んだ後の「変える瞬間をどう安全に遂行するか」という実行フェーズを扱います。これらの前提には、いずれも「現行システムが何をしているか、ある程度は把握できている」という状態があります。しかしVB.netシステムの中には、開発から10年以上が経過し、担当者の異動・退職によって仕様書が失われ、ソースコードだけが本番稼働を続けているケースが少なくありません。このような状態では、7波のどのアプローチを選ぶべきかという意思決定自体が下せません。VB.netのリバースエンジニアリングは、こうした「意思決定の材料すらない」という状況を解消するために、ソースコードそのものを解析し、実装レベルから設計レベル、そして仕様レベルへと段階的に抽象度を引き上げながら、失われた仕様・設計思想を復元する分析・調査工程として位置づけられます。
他言語版との違い（VB6過渡期・フォームデザイナという固有事情）
リバースエンジニアリングの総論記事が扱う「ソースコード解析から実装・設計・仕様へと抽象度を引き上げる」という基本プロセスは、COBOLやC#、C言語、PL/Iなど、どの言語のシステムを対象にしても共通しています。しかし、対象言語ごとに解析の難所となる技術的な特徴はまったく異なります。VB.netの場合、最大の固有事情は「VB6（Visual Basic 6.0）からアップグレードウィザード等を用いて機械的に移行された過渡期システム」が現場に数多く残存している点です。これらのシステムは、VB6特有のGoTo文によるジャンプ処理や古いCOMコンポーネントの呼び出し、On Error Resume Nextによる強引なエラーハンドリングといった構造をそのまま引き継いでいることが多く、保守性の低い「スパゲティコード」になりがちです。また、VB.netを含むVB系言語は、画面上のボタンやテキストボックスに業務ロジックが直接書き込まれる「イベント駆動型（Event-Driven）」の構造を取るため、UIと業務ロジックが密結合しているという、他の言語にはあまり見られない固有の解析難所を抱えています。本記事では、こうしたVB.net特有の事情を踏まえた開発期間の見積もり方を解説します。
開発期間・スケジュールの全体像（一般論とVB.net規模別の目安）
VB.netのリバースエンジニアリングにかかる期間は、対象システムの規模、ドキュメントの残存状況、外部連携の有無によって大きく変動します。まずは一般的な期間感の目安と、その基本方針を押さえておきましょう。
一般的なアプローチ規模別の期間感（3ヶ月〜18ヶ月以上）
レガシーシステムを刷新するアプローチの規模に応じた一般的な期間の目安として、単純移行に近いリホストで3〜6ヶ月、リプラットフォームで6〜12ヶ月、リファクタリングで12〜18ヶ月、フルスクラッチに近いリライト・リビルドで18ヶ月以上という水準が知られています。リバースエンジニアリングはこれらすべてのアプローチに先行する分析工程として組み込まれるため、対象システムがどのアプローチを最終的に目指すのかによって、求められる解析の深度と期間が変わってきます。単純な移行を目的とした解析であれば実装レベルの把握で足りますが、フルスクラッチでの再構築を見据えた解析では、業務ルールというビジネス要件レベルまで踏み込んだ仕様復元が必要になり、期間は長期化します。また、機能単位でソースコードを解析し仕様書を復元する際の規模感として、ECサイトの商品登録機能クラスであれば約10ファイル・4,000行程度、外部サービスとのAPI連携部分の入出力仕様の解明、在庫予約システムクラスであれば約30ファイルの解析（セキュリティ確認を含む）といった事例が目安になります。基本料金はソースコードの行数（例:4,000行までを基本料金とし、それ以上は1行単位での従量課金）で算出されるのが一般的な考え方です。
VB.netシステムの規模別期間の目安（小規模1〜2ヶ月〜大規模2〜3年以上）
VB.netシステム、特にVB6由来の過渡期システムを対象とした仕様復元・リビルドの規模別期間の目安は次の通りです。小規模（数十画面・数万行レベル）であれば、仕様復元だけで1〜2ヶ月、再構築（リビルド）まで含めると全体で3〜6ヶ月程度が目安です。中規模（100〜300画面・10万〜30万行レベル）になると、仕様復元と要件再定義だけで3〜6ヶ月を要し、その後のリファクタリング・リビルドまで含めると全体で1年〜1年半程度が目安になります。大規模（500画面以上・50万行以上）の場合は、解析ツールの導入や専用の移行スクリプトを開発する準備期間が別途必要となり、仕様の完全な紐解きから移行完了までを含めると2年〜3年以上の長期プロジェクトになるのが一般的です。この期間感は、あくまで画面数と行数から算出した目安であり、実際にはこの後解説するフォームデザイナ・イベント駆動構造の解析難易度によって、同じ画面数でも大きくブレる点に注意が必要です。
開発期間を左右する変数（フォームデザイナ・イベント駆動構造の解析工数）
規模別の期間目安を押さえたら、次に理解すべきなのが、その期間を大きく前後させるVB.net固有の変動要因です。同じ画面数・行数のシステムでも、これから解説する要因の有無によって、必要な期間は数週間から数ヶ月単位でブレます。
画面数・イベント数が最大の変数（画面解析だけで全体の30〜50%）
VB.netをはじめとするVB系言語は、UI画面上のボタンやテキストボックスに直接業務ロジック（イベントハンドラ）が書き込まれるイベント駆動型の構造を取ります。そのため、「画面数（フォーム数）」と「画面内に配置されたコントロール（イベント）の数」が期間を左右する最大の変数となります。UIとデータベース処理、ビジネスロジックが密結合している、いわゆるスパゲティコード化しているケースが多く、ロジックを画面から分離して仕様を復元する作業は、通常のWebシステム解析に比べて画面解析だけで全体の30〜50%以上の工数を占めるケースが珍しくありません。見積もりの段階でこの画面解析工数を過小評価してしまうと、プロジェクトが進むにつれて次々と想定外のイベントハンドラが見つかり、当初のスケジュールが大きく崩れるという事態に陥りがちです。見積もり依頼の前段階で、対象システムの画面数とおおよそのコントロール数を棚卸ししておくことが、精度の高いスケジュールを得るための第一歩になります。さらに、フォーム間でコントロールの制御ロジックを共有する「共通モジュール」や「クラスモジュール」が使われているかどうかも重要な確認事項です。共通化が進んでいるシステムであれば、一度解析した共通ロジックを複数画面で再利用でき、期間短縮につながりますが、逆に画面ごとに似たような処理がコピー&ペーストで散在している場合は、見た目以上に解析対象が膨らみ、当初の想定より長い期間を要することになります。
COMコンポーネント・OCXのブラックボックス問題（数週間〜数ヶ月の遅延要因）
VB6時代のレガシーなActiveXコントロールや、古いサードパーティ製の帳票・UIコンポーネント（OCXファイル）が、VB.net上でラッパーを介して動いている過渡期システムは決して珍しくありません。これらの中身はバイナリのブラックボックスであることが多く、新システムへの仕様マッピングにおいて多大な調査時間、具体的には数週間から数ヶ月単位の遅延要因になり得ます。また、外部サービスとのAPI連携が存在する場合、その入出力（I/O）仕様の解明は独立した見積もり要因として扱う必要があります。設計書がない状態では、コードの構文という実装レベルから、コンポーネント間の相互作用という設計レベル、そして本来のビジネスルールという仕様レベルへと段階的に抽象化して意図を復元する必要があり、この抽象化の難易度こそが工数に直結します。見積もり段階でCOMコンポーネントやOCXの有無を洗い出し、それらがブラックボックスとして残るのか、代替可能な標準コンポーネントに置き換え可能なのかを事前に判断しておくことが、期間の精度を高めるうえで欠かせません。加えて、VB6由来のシステムでは、Windows APIを直接呼び出す宣言（Declare文）や、レジストリ・INIファイルへの直接アクセスといった、環境依存の強い実装が随所に見られることもあります。これらは単体では小さな処理であっても、動作環境の再現が難しく、解析担当者が実機での挙動確認に時間を取られる要因になるため、事前のヒアリングで「独自のAPI呼び出しやレジストリ操作に心当たりがあるか」を現行システムの保守担当者に確認しておくだけでも、後工程での調査時間を大きく圧縮できます。
期間短縮・納期遵守のための実務ポイント
変動要因を理解した上で、実際のプロジェクトで納期を守るためには、進め方そのものを工夫する必要があります。ここでは、VB.netのリバースエンジニアリングにおいて期間超過を防ぐための実務的な考え方を解説します。
3段階の抽象化プロセスを計画的に区切る
VB.netのリバースエンジニアリングは、実装抽象化（ソースコード・データ構造の解析）、設計抽象化（コンポーネント間の相互作用・制御フローのモデル化）、仕様抽象化（アプリケーションの要件・ビジネスルールへの変換）という3段階を経て進みます。この3段階を明確なマイルストーンとしてスケジュールに落とし込み、各段階の完了時点で成果物（解析レポート・構造図・仕様書ドラフト）をレビューする体制を組んでおくことが、納期遅延を早期に察知する鍵になります。特に、実装抽象化の段階でつまずいたまま設計抽象化に進んでしまうと、後工程で前提が崩れて手戻りが発生しやすいため、各段階の完了基準をあらかじめ発注者・開発会社の双方で合意しておくことが重要です。VB.netの中間言語（IL）へのコンパイル特性上、実装レベルの復元自体はC言語などに比べて比較的容易ですが、それを設計・仕様レベルまで引き上げる作業にこそ時間がかかるという点を、スケジュール設計の前提として共有しておく必要があります。
パイロットモジュール選定による段階的解析
いきなりシステム全体の解析に着手すると、想定外の難所に当たった際にスケジュール全体が破綻するリスクを抱えます。困難な設計課題に直面した場合、その部分に絞って運用可能なプロトタイプを作成し、素早く再検証・再分析を行うというアジャイル型の考え方に基づき、まずは業務影響が中程度で、かつイベントハンドラの複雑さが標準的なモジュールをパイロットとして先行解析することをお勧めします。パイロットモジュールで3段階の抽象化プロセスを一通り経験しておくことで、以降のモジュール解析にかかる工数の精度が高まり、全体スケジュールの見直しが必要かどうかを早い段階で判断できるようになります。また、パイロットモジュールで確立した解析手順やツールの使い方をドキュメント化しておけば、複数モジュールを並行して解析する体制に移行する際にも、解析担当者間での品質のばらつきを抑えられます。COMコンポーネントやOCXへの依存が疑われるモジュールは、パイロットの対象から外し、事前調査に十分な時間を確保したうえで後回しにする判断も、全体の納期を守るうえで有効です。加えて、パイロットモジュールの解析結果は、発注者側の業務部門にもレビューしてもらう機会を設けることを推奨します。解析担当者だけで「実装レベル」から「設計レベル」への抽象化を完結させてしまうと、業務の実態と乖離した仕様書ができあがるリスクがあるため、現場の業務知識を持つ担当者が「仕様レベル」への引き上げ段階で内容を確認するプロセスを組み込むことで、手戻りの少ない、精度の高い仕様復元が可能になります。この業務側レビューの工数もあらかじめスケジュールに織り込んでおくことが、納期遵守の観点で見落とされがちな重要なポイントです。
まとめ
本記事では、VB.netのリバースエンジニアリングにおける開発期間・スケジュール・納期について、分析・調査フェーズという位置づけの確認から、規模別の期間の目安、フォームデザイナ・イベント駆動構造という固有の変動要因、そして納期遵守のための実務ポイントまでを体系的に解説しました。VB.netシステムの規模別期間は、小規模で1〜2ヶ月（リビルドまで含め3〜6ヶ月）、中規模で3〜6ヶ月（同1年〜1年半）、大規模で2〜3年以上が目安であり、この幅を最も大きく左右するのが画面数・イベント数に起因する解析工数（全体の30〜50%）と、COMコンポーネント・OCXのブラックボックス問題です。3段階の抽象化プロセスを明確なマイルストーンとして区切り、パイロットモジュールで手順を確立してから全体展開するという進め方が、期間見積もりの精度と納期遵守の両立につながります。
VB.netのリバースエンジニアリングは、その後に控える刷新・移行プロジェクト全体の土台となる工程であり、ここでの見積もり精度が甘いと、後続のプロジェクト全体のスケジュールにまで影響が波及します。特にVB6からの過渡期システムを抱える企業は、画面数・イベント数の棚卸しとCOMコンポーネントの依存調査を早期に行い、VB.net特有の解析難所に精通したパートナーへ早めに相談することをお勧めします。
▼全体ガイドの記事
・VB.netのリバースエンジニアリングの完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。