レガシーVBシステムの移行・モダナイゼーション - 金融情報システム開発なら20年以上の実績があるテンファイブ株式会社

本章では、VB6や古いVB.NETで構築された既存資産を、安全に保守・改善・移行するための考え方を学習します。

多くの業務システムでは、長年運用されてきたVB6、VB.NET、Windows Forms、COMコンポーネント、.NET Frameworkベースのアプリケーションが今も現役で稼働しています。これらのシステムは、企業の重要な業務を支えている一方で、保守担当者の不足、古い実行環境、セキュリティリスク、仕様書不足、属人化などの課題を抱えていることが少なくありません。

レガシーシステムの移行では、単純に古いコードを新しい言語やフレームワークへ書き換えればよいわけではありません。現行業務の理解、既存仕様の解析、影響範囲の調査、移行リスクの評価、段階的な置き換え、十分なリグレッションテストが必要です。

本章のゴールは、既存VB資産をただ新しくすることではありません。現行業務を止めずに、安全に保守し、改善し、必要に応じて現代的な.NET、WPF、Webアプリケーションへ移行できる判断力と設計力を身につけることです。

1. レガシーVBシステムとは

レガシーVBシステムとは、古い技術や設計で作られ、長期間運用されているVB系の業務システムを指します。代表的なものには、VB6、古いVB.NET、.NET Framework、Windows Forms、COMコンポーネント、ActiveX、Access連携、Excelマクロ連携などがあります。

代表的なレガシーVB資産

VB6で作られた業務アプリケーション
.NET Framework上の古いVB.NETアプリケーション
Windows Formsで構築された社内システム
COMコンポーネントやActiveXを利用したアプリケーション
AccessやExcelと密結合した業務ツール
古い帳票ライブラリに依存した出力処理
仕様書が不足している長期運用システム
退職者や特定担当者しか仕様を知らないシステム

レガシー化によって発生する課題

開発環境を構築しづらい
保守できる技術者が少ない
OSやミドルウェアの更新に弱い
セキュリティ対応が難しい
コードが複雑で影響範囲を把握しづらい
テストが手作業に依存している
仕様書と実装が一致していない
改修のたびに既存機能が壊れるリスクがある

レガシーシステムは、古いから悪いというわけではありません。長年業務を支えてきた重要な資産でもあります。そのため、移行や刷新を考える際には、単に技術的に新しくするのではなく、業務継続性とリスクを重視する必要があります。

2. VB6とVB.NETの違い

VB6とVB.NETは、名前は似ていますが、内部構造や実行基盤は大きく異なります。 VB6はCOMベースの言語であり、VB.NETは.NET CLR上で動作するマネージド言語です。

VB6とVB.NETの主な違い

項目	VB6	VB.NET
実行基盤	COM / ネイティブ寄り	.NET CLR
型システム	Variantなど柔軟だが曖昧	.NET型システムに基づく
メモリ管理	参照カウント中心	ガベージコレクション
例外処理	On Error GoTo中心	Try / Catch / Finally
オブジェクト指向	限定的	継承、Interface、Genericsなどに対応
配列	下限指定などVB6独自仕様あり	0始まりの.NET配列
文字列	VBランタイム依存	System.String
UI	VB6フォーム	Windows Forms / WPFなど

例外処理の違い

VB6では、On Error GoToによるエラー処理が一般的でした。

On Error GoTo ErrorHandler

' 処理

Exit Sub

ErrorHandler:
    MsgBox Err.Description

VB.NETでは、Try / Catch / Finallyを使用します。

Try
    ' 処理

Catch ex As Exception
    MessageBox.Show(ex.Message)

Finally
    ' 後処理

End Try

VB6からVB.NETへ移行する場合、単純な構文変換だけでなく、例外処理の考え方そのものを見直す必要があります。

VB6からVB.NET移行時の注意点

Variantに依存した曖昧な型を明確化する
On Error GoToをTry / Catchへ置き換える
配列の下限や添字の扱いを確認する
既存COMコンポーネントの依存関係を整理する
フォームイベントやコントロール仕様の違いを確認する
ファイルI/Oや文字コードの差異を確認する
暗黙変換に依存している箇所を洗い出す

VB6からVB.NETへの移行は、機械的な変換だけでは品質を担保しにくいです。特に、型、例外、外部コンポーネント、画面イベント、DBアクセスの差異を重点的に確認する必要があります。

3. COMコンポーネント連携

古いVBシステムでは、COMコンポーネントやActiveXを利用していることがあります。帳票出力、バーコード生成、スキャナ連携、Excel制御、外部機器制御などで使われているケースがあります。

VB.NETからCOMコンポーネントを利用する場合、COM参照や相互運用機能を通じて呼び出します。ただし、COMは.NETのマネージド環境とは異なる仕組みで動作するため、解放処理や32bit / 64bitの違いに注意が必要です。

COM連携で確認すべきこと

対象COMコンポーネントが現在も利用可能か
32bit版か64bit版か
インストールや登録手順が明確か
ライセンス上の制約がないか
移行先OSで動作するか
.NETから呼び出せるか
代替ライブラリが存在するか

COMオブジェクト利用例

Dim excelApp As Object = CreateObject("Excel.Application")

Try
    excelApp.Visible = False

    ' Excel操作

Finally
    If excelApp IsNot Nothing Then
        excelApp.Quit()
        Runtime.InteropServices.Marshal.ReleaseComObject(excelApp)
    End If

End Try

COMオブジェクトは、.NETのガベージコレクションに任せるだけでは解放タイミングが遅れる場合があります。特にExcelなどのOffice連携では、プロセスが残る問題が発生しやすいため注意が必要です。

COM依存を残すリスク

移行先OSで動作しない可能性がある
64bit環境で動作しない可能性がある
インストール作業が属人化しやすい
ライブラリの提供元が保守終了している可能性がある
自動テストが難しくなる
サーバー環境での実行に向かない場合がある

COMコンポーネントは、短期的には残す判断もあります。しかし、長期的なモダナイゼーションを考える場合は、代替ライブラリや.NETネイティブの実装へ置き換える計画を立てることが重要です。

4. 既存資産の解析手法

レガシーシステムを移行する前に、まず既存資産を正確に把握する必要があります。仕様書が古い、ドキュメントが存在しない、実装と仕様が違う、といったケースも多いため、実際のコードと動作をもとに解析します。

解析対象

ソースコード
画面一覧
DBテーブル
SQL文
ストアドプロシージャ
帳票
バッチ処理
外部連携ファイル
COMコンポーネント
設定ファイル
ジョブスケジュール
運用手順書

解析で確認すること

どの機能が使われているか
どの機能が使われていないか
どの画面からどの処理が呼ばれるか
どのテーブルを参照・更新しているか
どの外部ファイルを読み書きしているか
どの外部システムと連携しているか
どの処理が業務上重要か
どの処理が障害を起こしやすいか
どの処理が特定担当者に依存しているか

機能棚卸し表の例

機能ID	機能名	利用状況	重要度	移行難易度	備考
F001	ユーザー登録	利用中	高	中	複数画面から呼び出し
F002	売上CSV取込	利用中	高	高	外部システム連携あり
F003	旧帳票出力	利用不明	低	中	利用者確認が必要

コード解析の観点

巨大クラスや巨大メソッドがないか
SQLが画面に直接書かれていないか
重複コードが多くないか
外部依存がどこにあるか
例外処理が適切か
ログが出力されているか
Option Strict Offに依存していないか
未使用機能や未使用テーブルがないか

既存資産解析では、すべてを一度に完璧に把握しようとすると時間がかかりすぎます。まずは重要業務、利用頻度の高い機能、障害リスクの高い箇所から優先的に整理することが現実的です。

5. 移行計画の立て方

レガシーVBシステムの移行では、技術的な置き換えだけでなく、業務影響、スケジュール、テスト、リリース方式、運用体制まで含めて計画する必要があります。

移行計画で決めること

移行対象範囲
移行しない機能
優先順位
移行方式
移行後の技術構成
データ移行方針
テスト方針
並行稼働期間
切り戻し手順
利用者教育
運用手順の変更

移行方式の種類

方式	内容	メリット	注意点
一括移行	全機能をまとめて新システムへ移行する	旧システムを早く廃止できる	リスクが大きい
段階移行	機能単位で順番に移行する	リスクを分散できる	旧新システムの並行運用が必要
ラッピング	既存機能を外部APIやラッパーで包む	短期的に連携しやすい	根本的な技術負債は残る
リホスト	実行環境を変えるがアプリ構造は大きく変えない	比較的短期間で対応しやすい	設計上の問題は残りやすい
リライト	新技術で再設計・再実装する	構造を大きく改善できる	工数とリスクが大きい

移行優先度の決め方

業務重要度が高いか
利用頻度が高いか
障害発生頻度が高いか
保守担当者が不足しているか
OSやミドルウェアの制約が強いか
セキュリティリスクが高いか
他システムへの影響が大きいか

移行計画では、「作り直したい機能」ではなく、「移行する必要性が高い機能」から優先順位を決めることが重要です。

6. .NET Frameworkから.NETへの移行

古いVB.NETシステムの多くは、.NET Framework上で動作しています。現在の.NETは、.NET Coreを経て統合されたクロスプラットフォームな実行基盤ですが、 Windows FormsやWPFの移行ではWindows依存の要素も残ります。

.NET Frameworkと.NETの違い

項目	.NET Framework	.NET
対象環境	Windows中心	クロスプラットフォーム対応。ただしWinForms/WPFはWindows向け
開発の方向性	既存資産中心	現代的な.NET開発の主流
Windows Forms	対応	対応
WPF	対応	対応
ライブラリ互換性	古いライブラリと相性が良い	一部非互換に注意
構成管理	app.config中心	appsettings.jsonやDIなど現代的構成と相性が良い

移行前に確認すること

現在の.NET Frameworkバージョン
利用しているNuGetパッケージ
参照しているDLL
COMコンポーネントの有無
Windows Forms / WPFの利用状況
帳票ライブラリの対応状況
外部APIやDBドライバの対応状況
設定ファイルの構造
ビルド・配布方式

移行時に起きやすい問題

古いライブラリが.NETに対応していない
COM依存が残っている
設定ファイルの読み込み方式が変わる
文字コード処理で追加対応が必要になる
一部APIが非推奨または非対応になっている
ビルド設定や配置方式が変わる

移行アプローチ

1. 現在のプロジェクト構成を整理する
2. 参照ライブラリと外部依存を一覧化する
3. .NET対応状況を確認する
4. 小さな検証プロジェクトで移行可否を確認する
5. 影響の小さい機能から移行する
6. 自動テストや手動回帰テストを整備する
7. 段階的に本体へ反映する

.NET Frameworkから.NETへの移行では、いきなり本番システム全体を変換するのではなく、まず技術検証を行い、非互換箇所を把握することが重要です。

7. Windows FormsからWPF / Web化への判断

古いVB.NETシステムを現代化する際、Windows Formsのまま改善するか、WPFへ移行するか、Webアプリケーション化するかを判断する必要があります。

この判断は、技術的な好みだけで決めるべきではありません。利用者数、利用場所、業務フロー、端末環境、保守体制、将来拡張性を考慮する必要があります。

Windows Formsを継続する判断

利用者が社内の限られた端末に限定されている
既存資産が大きく、画面移行コストが高い
ローカル機器や専用端末との連携が多い
短期的には安定稼働を優先したい
画面要件が比較的シンプル

WPFへ移行する判断

Windowsデスクトップアプリを継続したい
UIとロジックを分離したい
データバインディングやMVVMを活用したい
複雑な画面表現が必要
将来的に保守性を高めたい

Web化する判断

複数拠点から利用したい
端末ごとのインストールを減らしたい
ブラウザで利用できるようにしたい
スマートフォンやタブレット対応を検討したい
権限管理やログ管理を一元化したい
将来的なクラウド化を視野に入れたい

判断比較表

選択肢	向いているケース	注意点
Windows Forms継続	既存資産を活かして短期改善したい	設計改善をしないと技術負債が残る
WPF化	WindowsアプリのままUI設計を改善したい	MVVMやXAMLの学習コストがある
Web化	多拠点利用や配布負荷削減を重視したい	全面的な再設計が必要になりやすい

移行先を決める際は、単に新しい技術を選ぶのではなく、業務上の課題を最も安全に解決できる選択肢を選ぶことが重要です。

8. 段階的リプレイス

レガシーシステムの移行では、一括で全機能を置き換えるとリスクが大きくなります。そのため、機能単位、画面単位、処理単位で段階的に置き換える段階的リプレイスが有効です。

段階的リプレイスのメリット

移行リスクを分散できる
業務停止リスクを下げられる
利用者のフィードバックを反映しやすい
重要機能から優先的に改善できる
旧システムと新システムを比較しながら進められる

段階的リプレイスの単位

画面単位
機能単位
帳票単位
バッチ単位
外部連携単位
DBアクセス層単位
認証・権限管理単位

段階的リプレイスの例

第1段階：既存システムの機能棚卸し
第2段階：DBアクセス処理をRepositoryへ分離
第3段階：入力チェックをValidatorへ分離
第4段階：帳票出力処理を新ライブラリへ置き換え
第5段階：利用頻度の高い画面からWPFまたはWebへ移行
第6段階：旧画面を停止
第7段階：旧資産を削除またはアーカイブ

並行稼働時の注意点

旧システムと新システムで同じDBを更新する場合の整合性
どちらのシステムを正とするか
利用者が誤って旧画面を使わないようにする制御
データ移行タイミング
切り戻し手順
ログの出力先
問い合わせ対応の窓口

段階的リプレイスでは、旧システムと新システムが一時的に共存します。この期間のデータ整合性、運用ルール、利用者案内を明確にすることが重要です。

9. リグレッションテスト

リグレッションテストとは、修正や移行によって既存機能が壊れていないかを確認するテストです。レガシーVBシステムの移行では、非常に重要な工程です。

古いシステムでは、仕様書に書かれていない暗黙の動作が業務上重要になっていることがあります。そのため、移行後に「仕様書通り」でも、利用者から見ると「前と動きが違う」となる可能性があります。

リグレッションテストで確認すること

既存機能が従来通り動作するか
画面表示や入力制御が変わっていないか
DB登録内容が一致しているか
帳票出力結果が一致しているか
CSVや固定長ファイルの出力形式が一致しているか
エラーメッセージやログ出力が適切か
権限制御が維持されているか
処理速度が極端に悪化していないか

現新比較テスト

移行時には、旧システムと新システムに同じ入力を与え、結果を比較する現新比較テストが有効です。

比較対象	確認内容
DB登録結果	登録された値が一致するか
帳票	金額、日付、明細、レイアウトが一致するか
CSV出力	項目順、文字コード、改行コード、値が一致するか
画面表示	一覧件数、並び順、初期値が一致するか
エラー処理	エラー条件とメッセージが妥当か

リグレッションテスト設計のポイント

重要業務から優先的にテストする
利用頻度の高い機能を重点的に確認する
過去障害が多い機能を含める
帳票やファイル出力は現新比較する
自動化できる部分は自動化する
利用者による確認も取り入れる

移行プロジェクトでは、実装よりもテストの方が重要になることもあります。特に、業務上の暗黙仕様を見逃さないために、利用者ヒアリングと現新比較が重要です。

10. 技術的負債の可視化

技術的負債とは、短期的な都合で積み重なった設計上・実装上の問題が、将来的な保守コストや障害リスクとして残っている状態を指します。

レガシーVBシステムでは、長年の改修により技術的負債が蓄積していることが多くあります。これを感覚的に「古くて危ない」と言うだけでは、改善の優先順位を決められません。そのため、技術的負債を可視化することが重要です。

技術的負債の例

巨大なFormクラス
数千行の共通関数
SQLの文字列連結
Option Strict Offへの依存
COMコンポーネント依存
テストコードがない
仕様書が古い
担当者しか分からない処理がある
古い帳票ライブラリに依存している
手作業の運用が多い

技術的負債管理表の例

ID	負債内容	影響	リスク	優先度	対応方針
D001	画面クラスにSQLが直書きされている	保守性低下、SQL修正時の影響大	高	高	Repositoryへ分離
D002	古いCOM帳票ライブラリに依存	OS更新時に動作しない可能性	高	中	代替ライブラリ検証
D003	ユーザー登録処理のテストがない	改修時の回帰不具合リスク	中	高	単体テスト追加

技術的負債を評価する観点

業務影響度
障害発生リスク
保守担当者の属人化度
修正頻度
移行難易度
セキュリティリスク
外部依存の危険度
テストの有無

技術的負債は、すべてを一度に解消する必要はありません。重要なのは、見える化し、優先順位を付け、計画的に減らしていくことです。

11. モダナイゼーションでありがちな失敗

すべてを一括で作り直そうとする

全機能を一度に作り直すと、影響範囲が大きくなり、テスト量も膨大になります。結果として、スケジュール遅延や品質低下につながることがあります。

現行仕様を十分に把握していない

仕様書だけを見て移行すると、実際の業務で使われている暗黙仕様を見落とす可能性があります。現行システムの動作、利用者の運用、過去の改修履歴を確認することが重要です。

新技術の導入が目的になっている

WPF化、Web化、クラウド化などは手段であり、目的ではありません。業務課題を解決できない技術刷新は、単なる作り替えコストになってしまいます。

テスト計画が甘い

移行では、実装よりもテストが重要になることがあります。特に帳票、CSV、DB更新、権限制御、外部連携は、現新比較を含めて慎重に確認する必要があります。

旧システムとの並行運用を考慮していない

段階移行では、旧システムと新システムが一時的に共存します。この期間のデータ整合性、利用者案内、切り戻し手順を設計していないと、運用トラブルが発生します。

技術的負債を移行先にそのまま持ち込む

古いコードをそのまま新しい環境へ移すだけでは、技術的負債は解消されません。移行と同時に、責務分離、テスト追加、DBアクセス分離、ログ改善などを段階的に行う必要があります。

12. 安全な移行プロジェクトの進め方

レガシーVBシステムの移行は、技術だけでなく、業務、運用、利用者、テスト、リスク管理を含む総合的なプロジェクトです。

推奨される進め方

1. 現行システムの棚卸しを行う
2. 利用状況と重要度を整理する
3. 技術的負債を可視化する
4. 移行対象と対象外を決める
5. 移行先技術を選定する
6. 小さな機能で技術検証する
7. テスト方針を決める
8. 段階的にリプレイスする
9. 現新比較テストを行う
10. 利用者へ展開する
11. 旧機能を停止する
12. 移行後も改善を継続する

移行前チェックリスト

現行機能一覧は整理されているか
利用者と利用頻度は把握できているか
DBテーブルと外部連携は整理されているか
帳票とファイル出力仕様は確認済みか
COMや外部ライブラリの依存は洗い出せているか
移行しない機能は明確か
リグレッションテスト計画はあるか
切り戻し手順はあるか
利用者への説明計画はあるか

安全な移行では、いきなりコードを書き始めるのではなく、まず現状を可視化し、リスクを把握し、移行計画を立てることが重要です。

13. 演習課題

演習1：VB6とVB.NETの違いを整理する

VB6で作られた既存アプリケーションをVB.NETへ移行する想定で、型、例外処理、配列、COM、UI、DBアクセスの違いを整理してください。

演習2：既存資産の棚卸し表を作成する

画面、バッチ、帳票、DBテーブル、外部連携、COMコンポーネントを対象に、機能棚卸し表を作成してください。利用状況、重要度、移行難易度も記載してください。

演習3：移行方式を比較する

一括移行、段階移行、ラッピング、リホスト、リライトの5つについて、メリット、デメリット、向いているケースを整理してください。

演習4：Windows Forms継続・WPF化・Web化を比較する

既存Windows Formsシステムを対象に、Windows Forms継続、WPF化、Web化のどれが適しているかを、利用者数、利用場所、端末環境、保守性、移行コストの観点で比較してください。

演習5：リグレッションテスト計画を作成する

ユーザー登録、売上CSV取込、請求書出力、権限管理の4機能を対象に、移行後に確認すべきリグレッションテスト観点を整理してください。

演習6：技術的負債を可視化する

既存VB.NETコードを読み、巨大Form、SQL直書き、COM依存、テスト不足、例外握りつぶしなどの技術的負債を洗い出してください。それぞれにリスク、優先度、対応方針を設定してください。

演習7：段階的リプレイス計画を作成する

既存のWindows Forms業務システムを段階的に移行する想定で、第1段階から第5段階までの移行計画を作成してください。

14. まとめ

本章では、VB6や古いVB.NETで構築された既存資産を、安全に保守・改善・移行するための考え方を学習しました。

レガシーVBシステムは、古い技術で作られている一方で、長年にわたり業務を支えてきた重要な資産です。そのため、単純に新しい技術へ置き換えるのではなく、現行業務、利用状況、外部連携、帳票、DB、運用手順を正確に把握する必要があります。

VB6とVB.NETでは、実行基盤、型システム、例外処理、メモリ管理、オブジェクト指向の考え方が大きく異なります。 VB6からVB.NETへ移行する場合は、機械的な変換だけでなく、設計思想の違いを理解したうえで見直すことが重要です。

COMコンポーネントやActiveXを利用している場合は、移行先環境での動作可否、32bit / 64bit対応、ライセンス、代替手段を確認する必要があります。短期的に残す判断もありますが、長期的には.NETネイティブな代替へ移行する計画が望ましいです。

移行計画では、一括移行、段階移行、ラッピング、リホスト、リライトなどの方式を比較し、業務影響とリスクを踏まえて現実的な方法を選択します。特に業務重要度が高いシステムでは、段階的リプレイスによってリスクを分散することが有効です。

.NET Frameworkから.NETへの移行では、参照ライブラリ、COM依存、帳票ライブラリ、設定ファイル、ビルド方式などの互換性を事前に確認します。 Windows Formsを継続するか、WPF化するか、Web化するかは、技術的な新しさではなく、業務要件と運用要件に基づいて判断します。

リグレッションテストは、移行プロジェクトにおいて非常に重要です。旧システムと新システムで同じ入力を使い、DB登録結果、帳票、CSV、画面表示、権限制御などを比較することで、移行による不具合を検出しやすくなります。

また、技術的負債を可視化することで、改善すべき箇所の優先順位を明確にできます。巨大Form、SQL直書き、COM依存、テスト不足、例外握りつぶし、仕様書不足などを整理し、計画的に解消していくことが重要です。

本章のゴールは、既存VB資産を安全に保守・改善・移行できるようになることです。レガシーシステムのモダナイゼーションでは、技術力だけでなく、現行業務を尊重し、リスクを管理し、段階的に改善していく実務的な判断力が求められます。

これまでの章で学習した、VB.NET高度文法、オブジェクト指向設計、UI設計、DB連携、例外処理、非同期処理、外部連携、セキュリティ、テスト設計の知識は、すべてレガシーVBシステムの改善とモダナイゼーションに直結します。 VB.NETを単なる古い業務言語として扱うのではなく、既存資産を理解し、現代的な設計へ橋渡しできる技術として活用することが重要です。