VB.netのリバースエンジニアリングのPoC・プロトタイプ・モックアップ開発について

VB.netのリバースエンジニアリングとは、設計書や仕様書が失われた、あるいは最初から存在しないVB.net製の既存システムについて、ソースコードを解析して仕様と設計思想を逆算的に復元する取り組みです。

本格解析の前に、PoCやモックアップ開発で実現可能性を見極める進め方を、順に見ていきます。

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

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

VB.netのリバースエンジニアリングにおけるPoCの位置づけ

7波の記事群が扱うPoCとVB.netのリバースエンジニアリングのPoCで、検証対象が左右に対比されています。
対象の違いを押さえると、PoCで確かめることを整理できます。

PoCの目的を正しく理解するには、この工程が「何を検証するためのものか」を、隣接する記事群と切り分けておく必要があります。

同じ「小規模に試してから本格着手する」という発想でも、対象が刷新の技術的な実現性なのか、仕様復元の実現可能性なのかによって、PoCの設計はまったく異なります。

7波・移行波のPoCとの違い(分析可能性の検証という目的)

7波の記事群(モダナイゼーション、刷新、更改など)や移行の記事群が扱うPoCは、これから作る・移す対象の実現可能性を検証します。具体的には、新システムの技術選定が妥当か、新アーキテクチャで想定通りの性能が出るか、移行方式が現実的に機能するかを確かめます。7波の記事群の残りは、次の4つです。

  • リニューアル:7波の記事群の一つ
  • リアーキテクチャ:7波の記事群の一つ
  • リプレイス:7波の記事群の一つ
  • 改修:7波の記事群の一つ

これに対し、VB.netのリバースエンジニアリングのPoCは、まだ何も作らない段階で、ブラックボックス化した既存システムから意味のある仕様を抽出できるかを検証します。

分析作業そのものの実現可能性を見る点で、根本的に異なります。この検証を経ずに全体解析の契約を結ぶと、着手後に「想定より解析が困難で、当初の見積もりでは終わらない」ことが発覚するリスクがあります。

PoCは、こうした本格着手後のリスクを事前に把握できる「保険」の役割を果たします。とりわけ、複数年にわたる大規模な基幹システムを検討する企業では、数百万円から数千万円規模になり得る本格プロジェクトの前に、比較的小さな投資でリスクの所在を見られます。その意味で、PoCは投資判断の精度を左右する工程です。

他言語版との違い(フォームデザイナという固有の検証対象)

COBOLやC#、C言語、PL/Iなど他言語のリバースエンジニアリングのPoCも、実装抽象化・設計抽象化・仕様抽象化の3段階が実際に機能するかを検証する点は共通しています。

しかしVB.netでは、この共通プロセスに加えて、フォームデザイナで自動生成されるレイアウト情報と、イベントハンドラに埋め込まれた業務ロジックをどう紐づけて解析するかという、VB系言語に固有の検証対象があります。

画面ベースのGUIアプリケーションであるVB.netシステムでは、UIと裏側のロジックが密接に結びついています。そのため、この紐づけ解析の手法を確立できるかどうかが、PoCで最も重視すべき論点になります。本格解析の前に代表的な画面を1つ選んで紐づけ解析を試しておくと、全体解析の見積もり精度を大きく高められます。

ポイント

PoCは、既存システムから意味のある仕様を抽出できるかを、全体解析の契約前に確かめる工程です。刷新や移行のPoCとは目的が違うため、何を検証するPoCかを取り違えないよう注意します。

PoC(概念実証)の進め方

実装抽象化、設計抽象化、仕様抽象化の3層を積み上げた図です。
下の実装情報を土台に、上位の仕様へ整理していきます。

VB.netのリバースエンジニアリングのPoCは、限られた期間と少人数で「解析が実際に成立するか」を確かめる、小規模な取り組みとして設計します。その進め方は、3段階の抽象化の検証と、対象モジュールの選定が中心になります。

PoCで行う3段階の抽象化プロセスの検証

ソフトウェアのリバースエンジニアリングは、「設計の復元(Design Recovery)」と呼ばれるプロセスで、抽象度を段階的に引き上げていきます。実装抽象化はソースコードやデータ構造の解析、設計抽象化はコンポーネント間の相互作用や制御フローのモデル化、仕様抽象化はアプリケーションの要件やビジネスルールへの変換です。

PoCでは、特定の帳票出力機能や計算ロジックなどのモジュールを対象に、この3段階が実際に行えるか、既存のコードから意味のある仕様を抽出できるかを検証します。困難な設計課題に直面した場合は、その部分に絞って運用可能なプロトタイプを作り、素早く再検証・再分析するアジャイル型の考え方に基づきます。

対象は「代表的だが複雑すぎない」モジュールが成功の鍵で、複雑すぎると期間内に結論が出ず、判断を先送りしかねません。レポートには、各段階で何が得られたか、各段階の工数、本格解析で想定される課題をまとめておくことが望まれます。このレポートは、社内の予算承認で解析を続ける価値を判断する材料になり、本格解析の見積もりの前提資料にもなります。

対象モジュールの選定基準

PoCの対象モジュールは、業務上の重要度、コードの複雑さ、COMコンポーネント・OCXへの依存度の3つの観点で候補を評価します。重要度が高すぎるモジュールは、PoCの失敗が経営判断に不必要な不安を与えかねないため避けます。逆に、重要度が低すぎると、検証結果が全体解析の見積もりに反映しにくくなります。

コードの複雑さは、平均的なイベントハンドラの数やネストの深さといった指標で測り、対象システム全体の「中央値」に近いモジュールを選ぶと、結果を全体へ外挿しやすくなります。COMコンポーネント・OCXへの依存度については、依存度が高いモジュールと低いモジュールを1つずつ選び、解析難易度を比べる方法も有効です。

この比較で、ブラックボックス依存の有無による工数の差という定量的な知見が得られ、見積もり精度の向上に活かせます。加えて、PoCの実施期間はおおむね2週間〜1ヶ月程度、体制はエンジニア1〜2名の少人数が一般的な目安です。この制約を最初に示しておくと、目的が「完璧な仕様書」ではなく「実現可能性の見極め」だと、発注者と開発会社の双方で共有できます。

ポイント

PoCの対象は、代表的だが複雑すぎないモジュールを選び、2週間〜1ヶ月程度、エンジニア1〜2名で進めるのが目安です。成果はレポートにまとめ、予算判断と本格解析の見積もりに使います。

解析ツールのプロトタイピング

モジュール単位のPoCと並行して、解析作業そのものを効率化するツールの試作にも取り組む価値があります。

リバースエンジニアリングを手動で行うと膨大な時間と労力がかかるため、自動化ツールの活用は欠かせません。ここでは、VB.netの解析に特化したツールのプロトタイピングの考え方を見ていきます。

自動化スクリプトの試作(API活用による効率化検証)

対象のVB.netシステムの解析を効率化するため、コードの特定パターンを抽出したり、データの流れを図にしたりする独自の小規模ツール(スクリプトなど)を試作することが有効です。既存のリバースエンジニアリングツールが提供するAPIを活用して、解析を自動化するスクリプトをプロトタイプとして開発します。

たとえば「特定の関数呼び出しを自動でリストアップするツール」や「コードの依存関係をマッピングするツール」を試作し、実際のVB.netコードベースで正しく動くかを試しながら、解析業務全体の効率化に備えます。

このプロトタイプは、PoCの範囲では完成度よりも、「本格解析でこの自動化アプローチが有効かどうか」を確かめることに主眼を置きます。ただし、完成度を追求しすぎると、ツール開発自体に想定以上の時間がかかり、PoC本来の目的である実現可能性の検証が後回しになってしまいます。

VB.net特有のツール選定(逆コンパイラの比較検証)

VB.netは.NET Frameworkで中間言語(IL)にコンパイルされるため、CやC++などのネイティブ言語に比べて、逆コンパイルで復元しやすい特徴があります。この特性を活かし、PoCで.NET Reflector、dotPeek、ILSpyなどの逆コンパイラを対象コードに適用して、次の2つの観点を比べておくことをお勧めします。

  • 可読性:復元されたコードの構造を追いやすいか
  • コメント・変数名:どこまで正しく推測できるか

ツールによって復元結果の質に差が出ることがあり、特にVB6由来の過渡期コードでは、独自の命名規則や省略記法が使われている場合もあります。そのため、どのツールが自社のコードと相性がよいかを早期に見極めることが、本格解析の作業効率を左右します。

あわせて、汎用のGhidraやIDA Proも、COMコンポーネントやOCXのバイナリ解析にどこまで有効かを試しておくと、ブラックボックス部分の調査方針を立てる判断材料になります。

ツール選定では、動くかどうかに加えて、復元結果を実際にレビューする社内担当者や外部パートナーのエンジニアが読みやすいと感じるかという主観的な評価も記録しておくことをお勧めします。最終的に仕上げるのは人間なので、解析チームの生産性への寄与も判断材料に加えます。

ポイント

解析ツールは、本格解析で自動化が効くかを確かめる程度に試作するのが目安です。逆コンパイラは、復元コードの読みやすさを実際のコードで比べて選びます。

フォームデザイナ解析によるモックアップ開発

フォームの定義ファイルの解析から画面遷移図、画面のモックアップ、運用担当者のフィードバックへ進む図です。
解析で得た画面構造が、操作確認と業務部門の認識合わせにつながります。

PoCと解析ツールの検証が済んだら、次に取り組むべきは、フォームデザイナ解析の実証実験としてのモックアップ開発です。

VB.netなどGUIベースのシステムでは、フォームデザイナで自動生成されるレイアウト情報とイベントハンドラが密接に結びついています。そのため、この解析結果を新システムのモックアップへ展開する試みが有効です。

画面遷移・UI構造の設計抽象化

低レベルの実装抽象化、つまりフォームの定義ファイルや自動生成コードの解析から、画面遷移図やUIコンポーネントの構造という設計抽象化へ情報を引き上げます。具体的には、対象画面のコントロールの配置情報と各コントロールのイベントハンドラの処理内容を突き合わせ、「このボタンを押すとこの画面に遷移し、このデータが更新される」という画面遷移ロジックを図式化します。

この段階では、UIの見た目を精緻に再現するより、画面同士の関係と各画面の業務上の役割を正確に把握することに重点を置きます。VB6由来の過渡期システムでは、1つの画面に複数の業務機能が詰め込まれていることも多いです。このため、旧画面の構成を踏襲するか機能単位で分け直すかの判断も、この工程で同時に検討しておくと後工程がスムーズです。

また、複数の画面から共通で呼び出されている業務ロジック(共通関数・クラスモジュール)を特定できた場合は、モックアップの段階から独立した部品として切り出しておきます。この部品は後続の本格開発で再設計する際の土台としてそのまま使えるため、二度手間を防げます。

新プラットフォーム上でのモックアップ作成と検証

設計抽象化が完了したら、この解析結果を使って、Webベースの最新フレームワークなど新しいプラットフォーム上で動く画面のモックアップを作成します。このモックアップが旧システムと同じ仕様(ユーザー要件)を満たすかを検証し、UI部分の移行難易度や必要な工数を見積もる判断材料にします。

実際の運用担当者にモックアップを操作してもらい、「旧システムで行っていた業務がこの画面構成でも問題なく行えるか」というユーザビリティの観点でフィードバックを得ることも欠かせません。そのフィードバックは、後続の本格的なリバースエンジニアリングやリビルドのプロジェクトで、業務部門との認識合わせを効率化する貴重な材料になります。

形のあるモックアップがあると、経営層や業務部門も投資対効果を具体的に思い描けるため、予算承認を進めやすくなります。特に、長年VB.netを使い続けてきた現場の担当者は、抽象的な仕様書より実際に操作できるモックアップのほうが、移行への心理的な抵抗を和らげ、後続プロジェクトの合意形成にも役立ちます。

ポイント

フォームデザイナの解析結果は、画面遷移とUI構造を図にしてモックアップで検証するのが目安です。現場の運用担当者に操作してもらい、業務が問題なく行えるかが判断の材料になります。

まとめ

ここまで、PoC・プロトタイプ・モックアップ開発を、分析可能性の検証という位置づけから見てきました。進め方、解析ツールの試作、フォームデザイナ解析によるモックアップ開発まで、順に取り上げています。

PoCでは、対象モジュールを業務上の重要度、コードの複雑さ、COMコンポーネントへの依存度の3つの観点で選び、3段階の抽象化プロセスが小規模な範囲で機能するかを確かめます。あわせて、複数の逆コンパイラを比較検証し、解析結果をモックアップの形で示すと、本格解析の見積もり精度と社内合意形成の両方を高められます。

PoCを省略していきなり本格解析に着手すると、フォームデザイナ・イベント駆動構造という技術的難所を過小評価したまま契約を結び、後工程で工数超過に直面するリスクが高まります。特にVB6由来の過渡期システムを抱える企業ほど、まず小規模なPoCで解析の可能性とツールの相性を見極め、VB.net特有の解析ノウハウを持つパートナーに早めに相談することをお勧めします。

数週間から1ヶ月程度の限られた投資で得られるPoCの知見は、その後に控える数ヶ月から数年規模の本格プロジェクトの成否を左右するだけの価値があります。PoCの結果を踏まえて進む際は、確立した抽象化プロセスの手順やツールの選定結果を引き継ぎ、体制を大きくしすぎずに段階的に広げていくことが、着実な前進につながります。

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

会社紹介

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

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

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

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

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

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