VB.netのリバースエンジニアリングの開発期間・スケジュール・納期について

VB.netのリバースエンジニアリングの期間は、対象システムの規模で大きく変わります。小規模では仕様復元までで1〜2ヶ月、中規模では要件再定義を含めて3〜6ヶ月、大規模では移行完了までを含めて2〜3年以上が目安です。

期間の前提は、対象、工程、確認の3つの面で整理できます。

  • 対象:改修対象と業務条件
  • 工程:計画から実装まで
  • 確認:品質と運用条件

本テーマの全体像は、下の記事でまとめています。

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

VB.netのリバースエンジニアリングの位置づけ(分析・調査フェーズという特殊性)

VB.netのリバースエンジニアリングの開発期間を正しく見積もるには、まずこの工程が何を目的とした作業なのかを、隣接する記事群と切り分けて理解しておく必要があります。言語横断的な総論記事や、COBOL・C#・C言語・PL/Iといった他言語版の記事群と異なり、VB.netは技術的に極めて特殊です。

というのも、同じ「老朽化したVB.netシステムに向き合う」というテーマでも、刷新の判断か、切り替えそのものか、仕様を復元する分析かによって、期間を左右する変動要因は大きく異なるためです。

7波・移行波との違い(意思決定・実行の前段にある分析工程)

モダナイゼーションから改修までの7つの記事群は、今のシステムをどう変えるべきかという意思決定と設計に重心を置いています。一方、システム移行の記事群は、その意思決定が済んだあとに、変える瞬間をどう安全に遂行するかという実行フェーズを扱います。

これらの記事は、いずれも「現行システムが何をしているか、ある程度は把握できている」ことを前提にしています。しかし、VB.netシステムの中には、開発から10年以上が経ち、担当者の異動や退職で仕様書が失われ、ソースコードだけが本番稼働を続けているケースが少なくありません。

こうした状態では、7波のどのアプローチを選ぶかという意思決定そのものができません。そこで、VB.netのリバースエンジニアリングは、ソースコードを解析して実装、設計、仕様へと段階的に抽象度を上げながら、失われた仕様や設計思想を復元する分析・調査の工程です。

他言語版との違い(VB6過渡期・フォームデザイナという固有事情)

ソースコードから実装・設計・仕様へ抽象度を引き上げる基本プロセスは、COBOLやC#など、どの言語でも共通しています。一方で、解析の難所になる技術的な特徴は、言語ごとにまったく異なります。VB.netの場合、最大の固有事情は、VB6(Visual Basic 6.0)からアップグレードウィザードなどで機械的に移行された過渡期システムが、現場に数多く残っている点です。

これらは、VB6特有のGoTo文によるジャンプ処理、古いCOMコンポーネントの呼び出し、On Error Resume Nextによる強引なエラーハンドリングといった構造を、そのまま引き継いでいることが多いです。そのため、保守性の低い「スパゲティコード」になりがちです。

また、VB.netを含むVB系言語は、画面上のボタンやテキストボックスに業務ロジックが直接書き込まれる「イベント駆動型(Event-Driven)」の構造を取ります。このため、UIと業務ロジックが密結合し、他の言語にはあまり見られない解析の難所になります。こうしたVB.net特有の事情を踏まえると、開発期間の見方も、ほかの言語とは変わってきます。

ポイント

見積もりの前に、分析・調査なのか、刷新の判断なのか、切り替えそのものなのかを切り分けます。そのうえで、VB6由来の過渡期システムかどうかも確かめておくと、判断を誤りにくくなります。

開発期間・スケジュールの全体像(一般論とVB.net規模別の目安)

小規模・中規模・大規模のVB.netシステムについて、仕様復元から移行完了までの期間目安を3枚のカードで示した図。
規模が大きくなるほど、仕様復元から移行完了までの見通しも長期になります。

期間は、対象システムの規模、ドキュメントが残っているか、外部連携があるかによって、大きく変わります。まずは、一般的な期間の目安を確かめておきます。

一般的なアプローチ規模別の期間感(3ヶ月〜18ヶ月以上)

レガシーシステムを刷新する場合、アプローチの規模に応じた一般的な期間の目安が知られています。単純移行に近いリホストは3〜6ヶ月、リプラットフォームは6〜12ヶ月が目安です。さらに、リファクタリングは12〜18ヶ月、フルスクラッチに近いリライト・リビルドは18ヶ月以上とされています。

リバースエンジニアリングは、これらすべてのアプローチに先行する分析工程で、どのアプローチを最終的に目指すかによって、求められる解析の深さと期間が変わります。単純な移行が目的なら、実装レベルの把握で足ります。一方、フルスクラッチでの再構築を見据えるなら、業務ルールというビジネス要件のレベルまで踏み込んだ仕様の復元が必要になり、期間も長くなります。

機能単位の規模感の目安は、ECサイトの商品登録機能クラスで約10ファイル・4,000行程度、在庫予約システムクラスで約30ファイル(セキュリティ確認を含む)です。外部サービスとのAPI連携部分は、入出力仕様の解明が別に必要です。基本料金は、ソースコードの行数(例として、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年以上の長期プロジェクトになるのが一般的です。これらの期間は、画面数と行数から算出した目安にすぎません。実際には、後で扱うフォームデザイナ・イベント駆動構造の解析難易度によって、同じ画面数でも大きくぶれる点に注意が必要です。

ポイント

期間は、規模とドキュメントの残り具合で大きく変わります。最終的に目指すアプローチを先に決めておくと、求める解析の深さと期間を見積もりやすくなります。

開発期間を左右する変数(フォームデザイナ・イベント駆動構造の解析工数)

画面数・イベント数を中心に、共通モジュール、COMコンポーネントやOCX、API連携を解析期間の変動要因として示した図。
画面解析に加え、再利用できる共通処理や仕様が見えにくい部品も見積もりを左右します。

規模別の目安を押さえたら、次は期間を大きく動かすVB.net固有の変動要因です。同じ画面数・行数でも、要因の有無によって、必要な期間は数週間から数ヶ月単位でぶれます。

画面数・イベント数が最大の変数(画面解析だけで全体の30〜50%)

VB.netをはじめとするVB系言語は、イベント駆動型の構造を取り、画面上のボタンなどに業務ロジック(イベントハンドラ)が直接書き込まれています。そのため、画面数(フォーム数)と、画面内のコントロール(イベント)の数が、期間を左右する最大の変数になります。UI、データベース処理、業務ロジックが密結合し、いわゆるスパゲティコード化しているケースが多くあります。

このため、ロジックを画面から切り離す作業は、通常のWebシステム解析に比べ、画面解析だけで全体の30〜50%以上の工数を占めるケースが珍しくありません。見積もりの段階でこの工数を過小評価すると、想定外のイベントハンドラが次々と見つかり、スケジュールが大きく崩れがちです。見積もり依頼の前に、画面数とおおよそのコントロール数を洗い出しておくことが、精度の高いスケジュールを得る第一歩です。

さらに、フォーム間で制御ロジックを共有する「共通モジュール」や「クラスモジュール」が使われているかも、確認しておきたい点です。共通化が進んでいれば、共通ロジックを複数の画面で再利用でき、期間短縮につながります。一方で、画面ごとに似た処理がコピー&ペーストで散在していると、見た目以上に解析対象が膨らみ、当初より長い期間が必要になります。

COMコンポーネント・OCXのブラックボックス問題(数週間〜数ヶ月の遅延要因)

VB6時代のActiveXや、古いサードパーティ製の帳票・UI部品(OCX)が、VB.net上でラッパーを介して動く過渡期システムは珍しくありません。その中身はバイナリのブラックボックスであることが多く、仕様の対応づけで数週間から数ヶ月単位の遅延要因になり得ます。API連携がある場合は、その入出力(I/O)仕様の解明を、独立した見積もり要因として扱う必要があります。

設計書がない場合は、コードの構文、コンポーネント間の相互作用、ビジネスルールへと段階的に抽象化して意図を復元する必要があり、この難しさが工数に直結します。見積もり段階でCOMコンポーネントやOCXの有無を洗い出し、ブラックボックスとして残すか、標準コンポーネントに置き換えるかを事前に判断しておくことが、期間の精度を高めるうえで欠かせません。

VB6由来のシステムには、Windows APIを直接呼ぶDeclare文や、レジストリ・INIファイルへの直接アクセスといった、環境依存の強い実装も見られます。これらは単体では小さくても、動作環境の再現が難しく、挙動確認に時間を取られます。そのため、「独自のAPI呼び出しやレジストリ操作の心当たり」を事前のヒアリングで保守担当者に確かめると、調査時間を減らせます。

ポイント

期間を読むときは、画面数とイベント数、COMコンポーネントやOCXの有無を先に確かめます。ブラックボックスとして残るものがあると、解析の遅れに直結しやすくなります。

期間短縮・納期遵守のための実務ポイント

ソースコードやデータ構造の解析から、設計のモデル化、要件やビジネスルールへの変換へ進む3層図。
下層の解析結果を上位の設計や仕様へ引き上げていく構成です。

変動要因を理解したうえで納期を守るには、進め方そのものを工夫する必要があります。期間超過を防ぐには、作業の区切り方と、着手する順番を見直すことが中心になります。

3段階の抽象化プロセスの区切り方

VB.netのリバースエンジニアリングは、次の3段階で進みます。

  1. 実装抽象化:ソースコード・データ構造の解析
  2. 設計抽象化:コンポーネント間の相互作用・制御フローのモデル化
  3. 仕様抽象化:アプリケーションの要件・ビジネスルールへの変換

この3段階をマイルストーンとしてスケジュールに組み込み、各段階が終わるごとに、解析レポートや構造図、仕様書ドラフトを確認する体制を組むことが、納期遅延を早く察知する鍵になります。

特に、実装抽象化でつまずいたまま設計抽象化に進むと、後工程で前提が崩れ、手戻りが起きやすくなります。そのため、各段階の完了基準を、発注者と開発会社の双方で事前に合意しておくことが重要です。

VB.netは中間言語(IL)へコンパイルされる特性があるため、実装レベルの復元は、C言語などに比べて比較的容易です。一方で、それを設計・仕様のレベルまで引き上げる作業には、時間がかかります。この点を、スケジュール設計の前提として共有しておく必要があります。

パイロットモジュール選定による段階的解析

いきなりシステム全体の解析に着手すると、想定外の難所に当たった際にスケジュール全体が破綻するリスクがあります。困難な設計課題には、その部分に絞って運用可能なプロトタイプを作り、素早く再検証するアジャイル型の考え方が有効です。そこで、まずは業務影響が中程度で、イベントハンドラの複雑さが標準的なモジュールを、パイロットとして先行解析することをお勧めします。

パイロットで3段階を一通り経験すると、以降の工数の精度が高まり、全体スケジュールの見直しも早く判断できます。確立した解析手順とツールの使い方を文書に残せば、並行して解析する段階でも、担当者間の品質のばらつきを抑えられます。COMコンポーネントやOCXへの依存が疑われるモジュールは、パイロットから外して事前調査に時間を充て、後回しにすることも納期の確保に有効です。

解析担当者だけで実装レベルから設計レベルへの抽象化を完結させると、業務の実態と合わない仕様書になるおそれがあります。このため、パイロットの解析結果は、発注者側の業務部門など現場の業務知識を持つ担当者に、仕様レベルの段階で確認してもらうことを推奨します。この業務側レビューの工数も、あらかじめスケジュールに織り込んでおくことが、納期遵守の観点で大切です。

ポイント

納期を守るには、3段階の区切りごとに確認する流れを決め、パイロットモジュールで手順を先に試すことが目安です。業務側のレビュー工数も、最初からスケジュールに入れておきます。

まとめ

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・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

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

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