VB6を捨てられない本当の理由は「仕様書にないルール」にあった

　VB6で構築したシステムが現在も業務を支障なく処理できているなら、新しい技術で同じ機能を再現しても、売り上げの増加や業務効率の改善に直結するとは限らない。一方、VB.NETへの移行には開発費用がかかり、切り替え時に業務が停止するリスクもある。こうした事情から、既存システムの維持を選ぶ企業もあった。

　さらに、長年使われてきた業務アプリケーションには、ソースコードだけでなく、現場の運用に合わせて追加された細かな処理も蓄積されている。取引先ごとに異なる締め日や、翌月にまたがる返品処理、特定の商品に適用する端数処理などだ。こうした例外的なルールは、必ずしも仕様書に記録されているとは限らず、担当者の交代によって、その背景や必要性が分からなくなっていることもある。

　そのため、VB.NETへの移行では、通常の入力や集計ができるだけでは不十分だ。月末や年度末、まれに発生する訂正処理まで含め、従来と同じ結果が得られるかを検証しなければならない。さらに、データベースや帳票部品、バーコードリーダー、ラベルプリンタ、他システムとのデータ連携など、周辺環境への影響も確認しなければならない。

　企業が維持してきたのは、VB6という開発技術だけではない。その上に積み重ねられた業務のルールや運用の仕組みも含まれる。プログラムを新しくするだけでは、これらをそのまま引き継げるとは限らない。古い技術と分かっていても、VB6を簡単に手放せない背景には、こうした事情がある。

「まだ動く」と「保守できる」は違う

　では、現在も動いているVB6のシステムを、そのまま使い続けても問題はないのだろうか。

　Microsoftは、VB6のアプリケーションを開発するための環境（IDE）のサポートを終了している。だが、作成済みのアプリケーションをWindowsで動かすためのランタイムは、Windowsのサポート期間に準じてサポートを継続している。「Windows 11」でもVB6アプリケーションの実行はサポート対象だ。ただし、アプリケーションを動かせることと、新たに開発したり修正したりする環境がサポートされていることは別だ。なお、VB6のランタイムは32ビット版のみだが、64ビット版のWindowsでは「WOW64」という互換機能によって実行できる。

　また、ランタイムがサポートされていても、個々の業務アプリケーションや外部部品の動作まで保証されるわけではない。部品の提供元による対応状況も確認が必要だ。さらに、アプリケーションが現在動いていることと、将来も修正、復旧できることは別問題だ。ソースコードや必要な部品、開発環境がそろい、実行ファイルを再作成できるか。修正後のテストや障害発生時の復旧手順まで確保できているか。こうした保守体制も問われる。

　日常の運用が安定していると、こうした問題は見過ごされやすい。開発環境を再現できないことに気付かないまま運用を続け、担当者の退職や端末の故障を機に、修正や復旧が困難だと判明するケースもある。また、取引先との連携方式や社内の認証・セキュリティ要件が変われば、既存システムにも対応が求められる。今は問題なく動いていても、将来の変更に対応できるとは限らない。

　こうした課題に対し、仮想環境へ移行して既存システムを延命する方法もある。ただし、周辺機器や外部サービスへの依存、保守人材の不足まで解消できるわけではない。延命する場合は、維持できる範囲と残るリスクを明確にしておく必要がある。

　VB6を使っていること自体が、直ちに事業上の問題になるわけではない。だが、長期的にはシステムの移行や再構築、不要になったものの廃止を進め、VB6への依存を減らすことが望ましい。延命は、業務を止められない場合などに選ぶ暫定策と位置付けたい。その場合も、保守・復旧の体制とリスクを確認し、移行や廃止の期限を設けておくことが重要だ。

Visual Basic 6を捨てるか、延命するか？

　企業は、既存のVB6システムをどう扱うべきなのか。まずは、利用状況や業務への影響を把握する必要がある。どの業務で使われ、停止すると何が起こるのかを確認することが出発点だ。

　月に一度使う補助ツールと、出荷処理を支えるシステムでは、障害時の影響が大きく異なる。手作業で代替できるのか、どの程度の停止が許容されるのか、復旧や修正を誰が担えるのか。こうした業務上の重要度や復旧体制を踏まえ、維持費用と移行・検証費用を比較し、刷新の優先順位を決めたい。

　延命を選ぶ場合も、現状のまま使い続ければよいわけではない。ソースコードや必要な部品、開発環境を確保し、実行ファイルの再作成や障害時の復旧が可能かどうかを確認する必要がある。こうした準備は、日々の保守だけでなく、将来の移行にも役立つだろう。

　刷新する場合、全てを一度に作り直す必要はない。帳票出力など独立性の高い機能から置き換えたり、業務単位で段階的に移行したりする方法もある。ただし、新旧システムが同じデータを扱う場合は、データの整合性を保つ仕組みが必要だ。

　また、既存の機能を全て自社開発で再現する必要があるかも検討したい。一般的な業務はパッケージやWebサービスを活用し、自社独自の処理だけを開発する方法もある。長年の運用で追加された機能や手順を見直し、使われていないものを整理する機会にもなる。

　VB6のシステムには、長年の運用で培われた業務ルールや処理が蓄積されている。そのため、刷新にあたっては、単に新しい技術へ置き換えるのではなく、引き継ぐべき業務と見直すべき手順を整理しなければならない。

　重要なのは、システムが動いているうちに、次の環境でも業務を継続できる準備を進めることだ。VB6をどう扱うかは、古い技術かどうかだけで決められない。自社の業務をどこまで把握し、将来の障害や変更に備えられるかが問われている。

死神管理人：　開発環境のサポートが終わっても、かつて作ったアプリまで一斉に動かなくなるわけではないというところが、VB6アプリが今も残っている状況の根幹にあるのだね。

アンデッド管理人：　実行に必要なランタイムのサポートは別に扱われていて、少なくともWindows 11が現役の間は利用できそうだから状況は複雑だ。ただし、使っている部品や接続先まで、まとめて保証されているわけではない。

死神管理人：　それでも残っているのは、長く使われてきたからこそなのか。

アンデッド管理人：　そうだな。業務ルールや例外処理、周辺機器との連携まで積み上がっているからな。安易に刷新して、同じ仕事を正しく続けられるかどうかは分からない。

死神管理人：　ただ、開発環境のサポートがこれほど前に終わっている以上、動いているから安心とは言えないだろう？

アンデッド管理人：　ああ、なにせIDEのサポートが切れたのは2008年だからな。修正できる人がいなかったり、実行ファイルを作り直せる環境がなくなったりすれば、変更や障害に対応できなくなる。だからこそ、もし明日システムが止まったら……と考えたとき、業務への影響と、復旧できるかどうかを判断するために、現状を把握しておかねばならない。

死神管理人：　やはり移行、刷新するのが妥当ということか。

アンデッド管理人：　そうだろうな。最終的にVB6をどうするかは、そのシステムが支えている業務をこの先どう続けるかという判断が重要だ。情シスは刷新の見通しを示せるだろうが、どの業務を優先するかとか、どれくらい止まって大丈夫かといったことは、業務を担う側の判断も重要になるだろう。