VB6.0は早めにVB.NETに移行しよう！すでにサポート期限切れ、終焉はすぐそこ？かも。

「VBマイグレーション」と呼ばれる、旧世代のVBで作成された業務アプリケーションをVB.netやweb（ASP.net）あるいはjavaといった現役の環境に移行するソリューションは、VB6.0がサポート終了して10年以上たった今でも、ご相談の多い事例です。

つまり、VB5.0やVB6.0といった環境で作成されたビジネス用アプリケーションを利用継続しており、法対応や機能改善などを加えている企業はまだまだ多いようです。しかし、VB6の「開発環境」はすでにサポートが終了しており、そのまま使い続けることには、セキュリティ以外にも様々なリスクがあります。

できるだけ早く、後継となるVB.NETをはじめとした他の環境への移行を検討したほうがよさそうです。この記事では、VB6を使い続けることのリスクや移行の際の課題についてまとめ、スムーズな移行について考えます。

VB6.0の現状

VB（Visual Basic）は、Microsoftが開発し、提供しているプログラミング言語です。最初のバージョンであるVBが発表されたのは1991年で、VB6.0は1998年に登場しています。

VB6.0はVB1.0から続く「初心者向け」という特徴をもちながら、企業独自のWindowsアプリケーションの開発において、ActiveXに完全対応し、SQL ServerやOracle DBといったRDBを制御できるため、ビジネスの現場で広く使われてきました。現在でも、VB6.0で開発されたシステムは、特に工場内や支店などの部門システムを中心に多く残っています。

VB6.0はWindows10でも動作するのか？

VB6で開発されたアプリケーションは、Windows10でも動作します。2020年1月にWindows7のサポートが終了した際、多くの企業においてPCの入れ替え（主にWindows7クライアント端末の撤廃）を行う中で、「Windows10環境でVB6アプリケーションを動作させる」ことによるで暫定対応した結果、VB6からの脱却を、いったんは後回しにしたケースも少なくないようです。

ただし、Windows10でVB6を動作させるためには、OSに標準では入っていないランタイムライブラリをインストールする必要があります。

これはあくまでも実行環境（クライアントアプリケーションを利用する側の環境）の話であり、VB6アプリそのものの改修や機能追加といった開発する側の話は異なります。Windows10環境下においてVB6の「開発環境」を構築することは非公式には可能ですがサポート外であることもあり、ここでは割愛します。

VB6の開発環境のサポート期限は切れている

VB6とその統合開発環境（IDE）のサポートは、はるか以前の2008年に終了しました。VB6のIDEをインストールできるOSは公式にはWindows Vistaまでですが、そのWindows Vista自身も2017年にサポートが終了しています。

また、OSやVB6開発環境本体のサポートが切れているだけでなく、サードパーティ製のVB6に関する開発支援ツールもほとんどがサポート期限切れとなっています。

現状としては、すでにサポートが切れている開発環境で開発されたアプリケーションが、まだまだ多くの企業で動作していることになります。一切の機能追加・改修など、アプリに手を加えずに実行するだけであればまだよいですが、機能改修や追加にはさらにリスクが伴います。

VB6の後継となるプログラミング言語はVB.NET

VBの最終版はVB6.0で、それ以後の新しいバージョンは開発されていません。VBの後継となるプログラミング言語はVB.NETで、現在の最新バージョンはVisual Basic 2019（VB16）です。このVB.NETも、一般的には「VB」と呼ばれることが多くありますが、その言語の中身は旧来のVisual BasicではなくVB.NETです。VB.NETは、VB6までの系統とは言語仕様に多くの変更点があり、VB6以下との直接的な互換性はありません。

VB.NETは、「.NET Framework」を使ってコンパイルされ、動作します。Windows用のアプリケーション開発、Web用のアプリケーション開発、およびモバイル向けのアプリケーション開発などに使われています。開発にはMicrosoftの統合開発環境Microsoft Visual Studioを利用するのが一般的です。

VB6を使用し続けるリスク

VB6はリリースされてから長い時間が経っており、開発環境のサポート期限も切れています。そのようなプログラミング言語を使い続けることは当然ながら、さまざまなリスクを伴います。

VB6環境で作成されたアプリケーションを使い続けるリスクには、大きく分けてIT部門・開発側（主に経営部門・情報システム部門）と、利用者側（利用部門・ユーザー・一般社員）とに分けられます。

開発側に関するリスク

VBアプリケーションを提供するIT部門に関するリスクには、次の4つがあると考えられます。

・開発（アプリ改修）を継続することに関するセキュリティリスク
VB6の統合開発環境は2008年に延長サポートが終了しています。開発環境にもセキュリティリスクがあり、安全とは言い切れません。また仮想化で延命させるなどの策をとっているとはいえ、統合開発環境をインストールできるOSも公式にはサポートが切れています。
VB6の全盛期にはいくつものサードパーティ製開発支援ツールがありましたが、こちらも現在はほとんどはサポートが切れています。

・仕様に関するリスク
VB6は1998年にリリースされたこともあり、古い仕様も多く残っています。たとえばVB6の特徴の1つであるActiveX対応です。ActiveXはMicrosoftが開発したInternet Explorer用のソフトウェアコンポーネントですが、2015年にはMicrosoftのブラウザMicrosoft Edgeでも非対応になっています。さらに、サードパーティ製のActiveXコントロールの多くはすでにサポート期限切れの状態です。
VB6を使い続けると、このような「すでに使われていない技術」「現在ではメジャーではない技術」を使っての開発継続というリスクもあります。これでは、日々の機能追加や修正にも不便です。

・実行に関するリスク
VB6を動作させるためには、独自に開発したアプリケーション以外に、Windows10では標準でインストールされていないVB6.0の実行環境（ランタイムライブラリ）が必要です。
MicrosoftはWindows10のサポート期間内はVB6のランタイムをサポートすると表明していますが、それ以降のサポートは明言していないのが現状です。今後のランタイムのサポートがいつまで続くかも不明です。また、Windws11も同様です。今は動作しても、この先は、どうなるかわかりません。

・システムの維持運用に関するリスク
VB6は古いプログラミング言語ということもあり新規に習得するプログラマは少なくなり、結果的に扱える技術者は少なくなりました。企業によっては自社開発したアプリケーションの保守運用が自社要員や当時委託した外部のベンダーのSEでまかないきれなくなり、外部から新たに調達することになります。これは時間やコストのアップにつながります。

以上のことから、VB6で開発したアプリケーションを今後も安定して運用し利用部門に提供するのは、年々難しくなってきています。

ユーザーに関するリスク

利用部門側に関するリスクには、次の2つがあるといえるでしょう。

・セキュリティに関するリスク
VB6開発環境のサポートが切れていることもあり、今後新たな脆弱性が発見されたとしても、Microsoftからセキュリティ更新プログラムが提供されることはありません。そのため、VB6を利用したアプリケーションを使い続けたり、開発環境を使ってアプリケーションを修正したりすること自体がセキュリティリスクを増やすことにつながります。たとえば、情報漏えいや不正アクセス、それらをきっかけとしたサービス停止などです。これは、サードパーティ製の開発支援ツールについても同じことが言えるでしょう。

・業務内容に関するリスク
VB6のアプリケーションには古いものが多く、仕様や要件も開発当時の業務に合わせて開発されています。そのため、想定されている業務内容や機能が現在の業務にそぐわないものも多いかもしれず、結果的に業務の効率を落としていることもあるかもしれません。

VBマイグレーションの課題

VBマイグレーションとは、おもにVB6からVB.NETへの移行を指しています。マイグレーションとは、既存のシステムを前面あるいは部分的に再利用したうえで最新環境へ移行することで、ITモダナイゼーションとも呼ばれています。

VBマイグレーションは、過去にWindowsXPやWindows7などのOSのサポート終了前後に盛んに実施されました。当社もOSのサポート終了に合わせる形で、多くの企業様のVBマイグレーションを手掛けてきました。現在は多少下火になってきていますが、

まだまだVB6アプリケーションが各企業で現役で使われている、IT課題としての対応優先度が低いために後回しになっている、のが現状です。これを読まれている読者の方々にも、手を付けたいけど塩漬けになっているVBアプリケーションがあるのではないでしょうか？

MicrosoftではVB6からVB.NETへの移行のための公式な移行ツールを提供しており、VBマイグレーションには、このツールを利用するのが一般的です。しかし、移行ツールそのものも発表されてから年月が経っており、VB.NETも、その間に何度もバージョンアップを繰り返しているため、一筋縄では移行できない、さまざまな課題があります。

VB6からVB.NETへそのまま変換することができない

VB6とVB.NETは設計思想が異なっており、その結果言語仕様が大きく異なる部分が多いため、上位互換性が十分でなくそのまま変換することはできません。さらにMicrosoftが提供している公式の変換ツールの「アップグレードウィザード」は、もっとも新しいもので2008年版という、いまから10年以上も前のものです。

そのため、VB6からVB.NETの最新版に移行するには、次のような段階を踏んだ変換を行う必要があります。

VB6.0→VB.NET 2008→VB.NET最新版

※VB6から直接最新バージョン（記事執筆時点はVisual Studio 2019）への直接アップグレードをすることはできません。

アップグレードウィザードを使うだけでは大量のエラーが発生

公式のアップグレードウィザードを使用したとしても、多くの場合、プログラムの生成時や実行時には数万件以上の大量のエラーが発生します。基本的には、これらのエラーはすべて手作業で修正しなくてはなりません。VB6とVB.NETの両方に経験豊富な技術者は限られているため、修正作業にはかなりの工数と時間がかかります。

現在の作業環境が変換後のプログラムに対応しているか不明

VB6で開発されたアプリケーションの多くは、その開発生産性を上げたり、独自アプリケーションとしての使用時の利便性を高めるために、サードパーティ製のハードウェアやソフトウェアを組み合わせて利用されてきました。サードパーティ製品も古いものが多く、最新のVB.NET環境に対応しているか、あるいは上位互換性が保たれているか（たとえば最新バージョンを導入して入れ替えるだけで動作するのか）どうかは、個別に確認する必要があります。

また、Microsoft公式のアップグレードウィザードは、サードパーティ製品には対応していません。VB6で開発したアプリケーションはサードパーティー製品を利用していることが多く、そのままアップグレードしても、システム全体ではこれまでと同じようには利用できないことが多々あります。

サードパーティ製品のアップグレードには上位互換性が保たれてないことも多く、エラー修正と同じように手作業でプログラムを修正する必要があるため、大きな工数と時間が必要になります。

VB6からVB.NETへのマイグレーションには十分な準備が必要

このように、VB6からVB.NETへの移行が不可欠な一方で、VBマイグレーションにはいくつもの大きな課題があります。公式のアップグレードウィザードがあっても、簡単に済ませることはできません。大きな課題があるからこそ、企業によってはサポート終了から何年もの間、塩漬けになってきたという側面もあるといえるでしょう。

開発環境を現在も保有している場合は、外部のITベンダーに頼らなくても、今のVB6製の自社アプリがどれだけ最新版のVB.NETに対応しているか、逆に言えば、どれだけ手修正で移行しなければならないか、をアップグレードウィザードで確認することができます。

おそらく大半のケースは大量のエラーが表示され、エラー修正や変換後のテストには多くの手間や時間がかかることが多くなるでしょう。サードパーティー製品を利用している画面や機能が多ければ、その分移行ボリュームを解析するのが大変になるかもしれません。その場合はVBマイグレーションの専門家のサポートを受けるのもよいでしょう。

なお、VBをそのままVB.netに移行するのではなく、ブラウザをクライアントとするwebアプリ化、という手段もあります。詳しくはこちらの記事をご確認下さい。VB6をweb化するという既存IT資産活用の選択肢。ASP.NET移行によるVBアプリ資産の再生

企業の情報部門や事業部門において、自力でVB移行をすることは不可能ではありません。VB資産の移行に投入できるリソースがあれば可能です。ただ多くの企業においては、そういった旧来のシステムの移行に人材を割けないのも実情です。

システムズでは、VBに限らず長年マイグレーションで培ってきたノウハウがあります。これらの技術やノウハウをVBマイグレーションに生かし、VBマイグレーションに関しても独自の分析ツール、変換ツールにより、８０％から９０％以上の自動変換が可能です。

また自動変換できないエラーに関しても、同種エラーを網羅的に解析する「パターン分析」を活用することで、より効率的で不具合の少ない修正が可能です。企業のビジネスの中で長年利用されてきたVBアプリは、これまでのIT資産としての価値だけではなく、その内部ロジックに「企業独自の業務ノウハウとしての資産が含まれている」という側面もあり、簡単には捨てて新たに新規で作りにくいという事情もあります。この場合、全機能あるいは本当に必要な一部機能だけをマイグレーションすることで、これを今後も有効に活用できます。

マイグレーションの第一人者である当社のVB板倉が2019年に寄稿した日経XTECHの記事も合わせてご覧ください。脱Visual Basicは茨の道、VB.NETへのマイグレーションに待つ「落とし穴」

実際のプログラム資産が膨大で、すべてを移行すると費用的にも大きくなりすぎて予算に合わない場合、あるいは先行プロジェクトとして一部のサブシステムのみ移行を実施して、残りのシステムはお客様企業で内製化して対応、つまりご自身の情報部門の体制の中でお客様がメインで作業されたいといったご相談、あるいは全量のプログラム変換と一部の抽出テストを外部に委託して残りのテストはお客様で実施、といった、「ITベンダーに丸投げではない移行」なども柔軟にご相談に応じます。

VBアプリからの脱却を検討する際には、ぜひ一度お問い合わせください。資産の規模や利用サードパーティー製品などのヒアリングをさせていただいたうえで概算見積を出させていただきます。もちろん見積費用は無料です。

VBマイグレーションのご紹介（VBモダナイゼーション）｜システムズ