Visual Basic 6.0ユーザーはVisual Basic 2005に移行せよ（1/4 ページ）

Visual Basicによるアプリケーション開発の現場では、いまだに旧バージョンを利用しているところも多いと聞く。なぜ、最新バージョンへの移行が行われていないのだろうか。その理由を考えてみる。

[下村恭（ハンズシステム），ITmedia]

　社内システムなどビジネスアプリケーションの開発シーンでは、Visual Basic（VB）が利用されている。VBの現行バージョンはVisual Basic .NET 2003だが、開発現場ではいまだに旧バージョンのVB 6を使用しているところが多い。なぜ2003に移行していないのだろうか。

VB .NETに移行しなかった理由

　なかなかVB .NETに移行できないのには、どうも訳があったようだ。VB 6ユーザーのVB .NET 2003に対する不満点の中に、構造化言語であった従来のVBから、完全なオブジェクト指向言語であるVB .NETに変わってしまったからだ、という意見がある。確かにこの変化は大きなもので、移行にあたっての学習量も多く、なかなか踏み切れないというのもうなずける。

　だが、言語仕様としてのVB .NETや、CLR上で実行させるという.NET Frameworkの仕組み自体は、歓迎されこそすれ敬遠されるものではないだろう。VB .NETに移行できなかった本当の理由は、実際の開発作業の中では、VB 6のほうが生産性が高かったからではないだろうか。

　VB .NETで登場したクラスライブラリなど、“慣れ”の問題で片付けられる部分も確かにある。だが、VB .NETになって失われてしまった“VB 6の良さ”が、そこから離れられない理由だったのではないか。

　プログラマーは、VB .NETが登場した際に「共通のCLR上で動作するので、VBで書いてもC#で書いても、ソフトのクオリティも生産性も同じになる」と聞かされたはずだ。どの言語でプログラミングするかは、単に言語に対する慣れや好みの問題になるという話だった。だが、現場のプログラマはそう考えなかったのだろう。

　VB 6の良さとは、お手軽に必要な機能を実装できたという点に尽きると思う。VBがC++などの言語と比べて生産性が高かったのは、実現できる機能は少なかったかもしれないが、ビジネスアプリケーションで必要とされるコンポーネントが基本的にほとんど網羅されていて、それらコンポーネントを組み合わせるやり方で、さっさと機能を実現できたからだ。逆に、ちょっと複雑なことをしようとした場合、Windows APIを直接呼び出さなければならないなど、面倒なことも多かったのだが。

　これが、VB .NETに移行しようとしたときに、状況が変わってしまったことに気付いたのだ。何でもできる強力な言語となった代わりに、簡単なことをするにもクラスライブラリを参照し、長々とコーディングしなければならなくなっていた。

　また、デバッグ実行中にバグを発見したとき、実行を一時停止した状態でソースコードを変更し、そのまま処理を続行させることができるエディット・コンティニューという機能がVB 6にはあった。が、VB .NETではこの機能がなくなってしまった。これは言語ではなく開発環境としての話ではあるが、VB .NETに移行しなかった理由にはなり得る。

　ここで取り上げたような理由でVB .NETに移行していなかったVB開発者は、移行する環境にVisual Basic .NET 2003を選ぶべきではない。

　ではどうするか。答えは、「ダイレクトにVB 2005に移行すべき」だ。これには明確な理由がある。

VB 6と比較したVB 2005