相談事例 /
legacy-analysis
VB6 で組まれた20年物の受発注システムを継承可能な形に再生した事例
課題
Visual Basic 6 で構築された受発注システムが、開発者退職により誰も保守できなくなっていた。
解決策
静的解析・動的解析・リバースエンジニアリング・テスト整備により、誰でも保守可能な状態へ。
成果
システム稼働は維持したまま、ドキュメント・テスト整備完了。新規メンバーへの教育期間が 3ヶ月 → 2週間に短縮。
## ご相談時の状況
年商80億円の卸売業のお客様。中核となる受発注システムが Visual Basic 6（VB6）で構築されており、20年間使い続けていました。安定して動いていたものの、3年前に主担当エンジニアが退職した後、誰も触れない状態が続いていました。
「機能追加もバグ修正もできない」「いつ動かなくなるか分からない」「VB6 の実行環境（Windows 7 サーバ）がいつまで保つか不安」。経営層も IT 担当者も、深刻なリスクを認識しつつ、どこから手を付けてよいか分からない状態でした。
いきなり全面リプレイスする案もありましたが、見積もり額が1.5億円。すぐには動けない金額です。「もっと現実的な選択肢はないか」というご相談でした。
## 私たちの提案
全面リプレイスは確かに時期尚早と判断しました。動いているシステムを止めるリスク、業務側の移行コスト、新システムが完全に同じ機能を持つまでの並行運用、すべてを考えると、いきなり置き換えるのは賢明ではありません。
代わりに提案したのは「3段階の救済プラン」です。
Step 1（4ヶ月）: 現システムを「読める」「触れる」状態に整備。Step 2（任意・将来）: クリティカルな機能を新しい技術で書き換え、並行稼働。Step 3（任意・将来）: 全面リプレイスへの最終移行。
まずは Step 1 だけ確定で進めましょう、というご提案にしました。
## Step 1 の作業内容（4ヶ月）
第1ヶ月は静的解析。ソースコード一式（VB6 のプロジェクトファイル、フォーム、モジュール）を取得。ファイル数は約 320、総行数は約12万行。ファイル依存関係を mermaid 形式で図示。データベース（SQL Server 2008）のスキーマもリバースエンジニアリングして ER 図を作成。
第2ヶ月は動的解析。実際にシステムを動作させながら、主要な業務フロー（受注登録、出荷指示、請求処理、月次締めなど）をログ追跡しました。どのフォームからどの処理が呼ばれ、どのテーブルが更新されるか、すべてマッピング。
業務担当者へのインタビューも行い、システムでカバーされている業務、システム外でやっている業務、エクセルで補完している処理を可視化しました。
第3ヶ月はドキュメント化。機能一覧（200項目）、データフロー図、ER図、運用手順書、よくあるトラブルと対処、を全て日本語で整備しました。技術者でない業務担当者でも読める内容にすることを意識しました。
第4ヶ月はテスト整備。VB6 のソースコードに対する単体テストは難しいため、現状の入出力を「ブラックボックステスト」として固定する方針を取りました。具体的には、テスト用の DB を用意し、特定の入力を行ったときの DB 更新内容・画面表示・出力ファイルを、すべてスクリーンショットと SQL ダンプで記録。これを「Golden Master」として保存し、今後の修正時には必ず Golden Master と一致することを確認する運用にしました。
## 結果と効果
Step 1 終了時点で、お客様は以下の状態になりました。
- 全 200 機能について、誰が読んでも分かるドキュメントが整備された
- 任意のエンジニア（VB6 の経験がなくても）が、ドキュメントを読めば短期間で全体像を把握できる
- 修正時に「ここを触ると別が壊れるかも」という不安を解消する Golden Master テストが整備された
- 新人エンジニアの教育期間が、それまでの 3ヶ月 → 2週間 に短縮された
- 「いつ動かなくなるか分からない」という漠然とした不安が「ここまでは対応できる」という具体的な把握に変わった
お客様は Step 2（部分的な書き換え）を 6ヶ月後に開始することを決定。Step 1 で整備した資産があるため、見積もりも当初の 6千万円規模から 3千万円規模に圧縮できました。
## 学び
「全面リプレイス vs 維持」の二択ではなく、「読める状態に整備する」という第3の選択肢があります。これにより、リスクを大きく下げながら、段階的な意思決定が可能になります。
レガシーシステムは、まだ動いている間に手を付けるべきです。動かなくなってからでは、復旧コストは数倍に跳ね上がります。「いま動いているうちに、せめて読める状態にしておく」だけでも、企業の継続性は大きく改善します。
年商80億円の卸売業のお客様。中核となる受発注システムが Visual Basic 6（VB6）で構築されており、20年間使い続けていました。安定して動いていたものの、3年前に主担当エンジニアが退職した後、誰も触れない状態が続いていました。
「機能追加もバグ修正もできない」「いつ動かなくなるか分からない」「VB6 の実行環境（Windows 7 サーバ）がいつまで保つか不安」。経営層も IT 担当者も、深刻なリスクを認識しつつ、どこから手を付けてよいか分からない状態でした。
いきなり全面リプレイスする案もありましたが、見積もり額が1.5億円。すぐには動けない金額です。「もっと現実的な選択肢はないか」というご相談でした。
## 私たちの提案
全面リプレイスは確かに時期尚早と判断しました。動いているシステムを止めるリスク、業務側の移行コスト、新システムが完全に同じ機能を持つまでの並行運用、すべてを考えると、いきなり置き換えるのは賢明ではありません。
代わりに提案したのは「3段階の救済プラン」です。
Step 1（4ヶ月）: 現システムを「読める」「触れる」状態に整備。Step 2（任意・将来）: クリティカルな機能を新しい技術で書き換え、並行稼働。Step 3（任意・将来）: 全面リプレイスへの最終移行。
まずは Step 1 だけ確定で進めましょう、というご提案にしました。
## Step 1 の作業内容（4ヶ月）
第1ヶ月は静的解析。ソースコード一式（VB6 のプロジェクトファイル、フォーム、モジュール）を取得。ファイル数は約 320、総行数は約12万行。ファイル依存関係を mermaid 形式で図示。データベース（SQL Server 2008）のスキーマもリバースエンジニアリングして ER 図を作成。
第2ヶ月は動的解析。実際にシステムを動作させながら、主要な業務フロー（受注登録、出荷指示、請求処理、月次締めなど）をログ追跡しました。どのフォームからどの処理が呼ばれ、どのテーブルが更新されるか、すべてマッピング。
業務担当者へのインタビューも行い、システムでカバーされている業務、システム外でやっている業務、エクセルで補完している処理を可視化しました。
第3ヶ月はドキュメント化。機能一覧（200項目）、データフロー図、ER図、運用手順書、よくあるトラブルと対処、を全て日本語で整備しました。技術者でない業務担当者でも読める内容にすることを意識しました。
第4ヶ月はテスト整備。VB6 のソースコードに対する単体テストは難しいため、現状の入出力を「ブラックボックステスト」として固定する方針を取りました。具体的には、テスト用の DB を用意し、特定の入力を行ったときの DB 更新内容・画面表示・出力ファイルを、すべてスクリーンショットと SQL ダンプで記録。これを「Golden Master」として保存し、今後の修正時には必ず Golden Master と一致することを確認する運用にしました。
## 結果と効果
Step 1 終了時点で、お客様は以下の状態になりました。
- 全 200 機能について、誰が読んでも分かるドキュメントが整備された
- 任意のエンジニア（VB6 の経験がなくても）が、ドキュメントを読めば短期間で全体像を把握できる
- 修正時に「ここを触ると別が壊れるかも」という不安を解消する Golden Master テストが整備された
- 新人エンジニアの教育期間が、それまでの 3ヶ月 → 2週間 に短縮された
- 「いつ動かなくなるか分からない」という漠然とした不安が「ここまでは対応できる」という具体的な把握に変わった
お客様は Step 2（部分的な書き換え）を 6ヶ月後に開始することを決定。Step 1 で整備した資産があるため、見積もりも当初の 6千万円規模から 3千万円規模に圧縮できました。
## 学び
「全面リプレイス vs 維持」の二択ではなく、「読める状態に整備する」という第3の選択肢があります。これにより、リスクを大きく下げながら、段階的な意思決定が可能になります。
レガシーシステムは、まだ動いている間に手を付けるべきです。動かなくなってからでは、復旧コストは数倍に跳ね上がります。「いま動いているうちに、せめて読める状態にしておく」だけでも、企業の継続性は大きく改善します。