Visual Basic 2005でVB 6プログラマーの時代がやってくる

――　VB 2005＋コンポーネント開発なら、OOPを強く意識しなくてもアプリケーションを開発可能　――

鎌田：結論からいえば、5年前に想像していたほど移行は急ではありませんでした。5年前の想定では、3年後（2004年ごろ）までには、VB 6向けのActiveXコンポーネントと、.NET向けコンポーネントの売り上げ比率は1対9程度になると考えていましたが、現時点での売り上げ比率は3対7と、いまなお30％はActiveXコンポーネントになっています。

鎌田：2年ほど前だと思います。それ以前から.NETへの移行は徐々に進んでいましたが、特にそのころから加速してきた感じがします。

八巻：私も最初は、VB 6対応製品をお持ちのユーザーが、少しずつ.NET対応製品に移行するのかと思っていたのですが、展示会などでお客さまに直接聞いてみると、どうもそうでもありません。どうやら最初のうちは、JavaやC++言語のユーザーが新しい.NETの世界にまず飛び込んできて、その後VB 6プログラマーが移行しつつあるという感じがします。

鎌田：当社のテクニカル・サポートにお問い合わせいただいたユーザーの使用言語を過去3年にわたり調査した結果があります（図「グレープシティのテクニカル・サポートにおけるユーザーの使用言語」）。2003年から2005年までの変化に注目すると、VB 6は21％減少し、VB.NET（VS 2002、VS 2003、VS 2005のすべてのVBバージョン。以下“VB.NET”と表記した場合は同様）は16％増加しています。一方C#は7％増、JavaとVC++ 6はそれぞれ1.5％減、1.0％減です。VB 6の減少分すべてがVB.NETの増加につながっているわけではありませんが、この差分の5％に加え、JavaとVC++ 6の減少分（2.5％）がC#に移行したと考えると、おおよそつじつまが合います。

鎌田：先に述べたとおり、現在でも販売額の30％がActiveXコンポーネントですから、多くのVB 6プログラマーがいることは間違いないでしょう。しかし移行は着実に進んでいますし、これは新しいVS 2005でさらに加速すると期待しています。

鎌田：業務アプリケーションでは、昔もいまも変わらない普遍的な部分が多いというのが1つの理由だと思います。実際、エンドユーザーから見ればVB 6で作ろうと、VB.NETで作ろうと、簡単には違いは分かりません。

八巻：.NETが登場した最初のころは、よくお客さまから「.NETで作るとどんなよいことがあるのか？」と聞かれました。これには簡単には答えられませんでした。特にエンドユーザーの方々にメリットを説明するのは難しいです。

鎌田：VB 6で開発したクライアント／サーバ型アプリケーション（以下C/Sアプリケーション）をWebアプリケーション化するという話をよく聞きます。その際苦労する点を聞くと、「Enterキーで次の入力項目に移動させたい」「ファンクション・キーを使って操作させたい」など、従来の使い勝手をどうやってWebでも実現するか、というものが多いのです。

　これらはWebアプリケーションで実現するには大変な手間がかかるのですが、エンドユーザーは従来どおりのインターフェイスを求めています。つまりテクノロジーが変わっても、業務アプリケーションのニーズはあまり変わらないということだと思います。

八巻：そうですね。VB.NETの開発効率は間違いなく高い。けれど初期の学習コストはかかりますから、VB 6を長年使い慣れたプログラマーにとっては、結果的にVB 6で作った方が効率的ということでしょう。

鎌田：間違いではなかったと思いますが、少々過大に取り上げられすぎたかなとも思います。VB.NETでも、フォームにコントロールを貼り付けて、イベント処理を記述するという点ではVB 6と同じです。

　オブジェクト指向プログラミングを知っていた方が効率的な開発が可能だと思いますが、「OOPを知らなければ始まらない」という先入観につながってしまっているとすれば、それは行き過ぎです。

八巻：弊社のサポートに届く声を聞いていても、「.NETはOOPが前提で難しい」という先入観ばかりが先行してしまっているように感じます。特に、すでにあるコンポーネントを使うだけなら、独自のクラスを作成しないで済みますから、VB.NET環境でもVB 6的なアプローチでアプリケーション開発ができると思います。

八巻：私の場合、.NETを始めて最初に困ったのは、砂時計カーソルが出せなかったこと、次に困ったのは「vbRed」という定数で色を変えられなかったことでした。どちらもつまらないことですし、分かってしまえば何ということはないのですが、こういうちょっとしたつまずきから抜け出せないで挫折する人が少なくないように思います。

　考えようによっては、「OOPが分からない」というのもつまらないつまずきの1つといえるでしょう。第1段階の小さなつまずきを1つ2つ超えたら、後はVB 6で培ったことが変わらず使えると思えるようになるでしょう。まぁ最初は、つまずいて転んでみるのも悪くないですよ。自転車だってさんざん転んで乗れるようになるわけですから（笑）。

鎌田：社内で数人のプログラマーにプログラミングの課題を出したことがあります。課題というのは、Enterキーで次の入力項目に移動するようなアプリケーションを、VB 6とVB.NETの両方で作るというものです。これを実現する方法はいくつもあります。

　VB 6では、KeyDownイベントで、TabキーをSendKeysステートメントで送るか、コントロールのSetFocus関数を呼び出すかすることで、入力フォーカスを移動できます。VB.NETでもこの方法はそのまま使えます（具体的にはSendKeysクラスのSendメソッドや、コントロールのFocusメソッドが使える）。しかしVB.NETではこれらに加え、フォームやコントロールのProcessDialogKeyメソッドのオーバーライド、拡張プロバイダ（＝プロパティをほかのコントロールに追加する機能）でコンポーネントを作って実現する方法などでも可能です。

　結果、VB 6プログラマーは、VB 6とVB.NETのどちらの場合でもSendKeysステートメント（SendKeysクラスのSendメソッド）などを使う同じ方法を取りました。しかし、VB.NETプログラマーは、VB 6ではSendKeyステートメントを使い、VB.NETでは（OOPの知識が必要となる）ProcessDialogKeyメソッドのオーバーライドを使うというように、それぞれのコンテキストに合わせた方法を採用しました。つまり、OOPを身に付けている.NETプログラマーの方が、実装方法を柔軟に選択できるということです。

鎌田：そうですね。VB 6プログラマーはこの課題後、「ああ、.NETにはそういう実現手法もあるのか」と驚いていました。どちらが正しいということではありませんが。