VB.NET移行の最大のハードルはオブジェクト指向プログラミング

文化オリエント(株)
ツール開発部 部長
鎌田 明
2001/02/22


 Visual Basicの登場以来、VBコンポーネント専業のソフトウェア・ベンダとして、数々のコンポーネントを開発し、VBとともに成長を続けてきた文化オリエント社。同社は、Microsoft.NETの登場を期に、開発リソースを全面的に.NET向けに集中させ、CLR(Common Language Runtime)をベースとする新しいマネージド環境に製品を移行させる計画である。従来のコンポーネント開発ではVisual C++を使用し、C++向けの独自のクラスライブラリも構築したが、.NETへの移行にあたって、同社はこれら既存資産とは別に、C#を使用する新しいフレームワークを構築するという。VBを知り尽くした同社のツール開発部長である鎌田氏に、VBの現在と未来について語っていただいた。

(聞き手:デジタルアドバンテージ 遠藤孝信)

―― Visual Basic(以下VB)は、数あるプログラング言語の中でも、プログラマが最も多い言語の1つだと言われます。世界および日本国内で、VBプログラマはどれほどいるのでしょうか?

 プログラマの数については、さまざまな情報があります。全世界で600万人という話もあれば、300万人という話を聞いたこともあります。残念ながら正確な数は分かりませんが、私たちの見たところでは、日本国内では、いわゆるサンデー・プログラマなどを含めて30万人、ビジネスで利用しているプログラマだけなら10〜15万人程度だと認識しています。これらの数字が正しいかどうかはともかく、プログラマ人口がかなりの数にのぼることは間違いありません。

―― プログラマにとって、VBの魅力とは何でしょうか?

 一言でいえば、優れたRAD(Rapid Application Development)環境だということでしょう。フォームと呼ばれるウィンドウにさまざまな部品(コンポーネント)を貼り付けていくだけで、簡単にユーザー・インターフェイスを構築することができます。このため小規模なスタンドアロン・アプリケーションや、クライアント/サーバ・システムにおけるクライアント・アプリケーションなどを効率的に開発できます。これだけ手軽にWindowsアプリケーションを開発できるのは、VBを置いてほかにはないでしょう。

 私たちの製品も、表計算のビューを簡単に作ることができるスプレッド・コンポーネントや、Microsoft Officeと同等のツール・バーを実装するツール・バー・コンポーネントなど、ユーザー・インターフェイスの構築にまつわるものが中心になっています。

 VBで最も効率のよいプログラミングは、既存のコンポーネントをうまく組み合わせて、自身でのコーディング量をなるべく減らすことです。ですからVBでのプログラミングは、「コーディング」というより、コンポーネントを組み立てるという感じに近いかもしれません。

VBでのプログラミングは、「コーディング」というより、コンポーネントを組み立てるという感じに近いかもしれません

―― それでは逆に、VBの欠点は何でしょうか?

 VBの通常の使い方を超えた、高度な処理や複雑な処理、具体的に言えば、Windows APIを駆使するような処理は、言語仕様としては可能ですが、効率的ではありませんし、プログラミングも簡単ではありません。

―― インターネットやWebが急速に普及したことから、ミドルウェア市場の関心は、従来のクライアント・サーバ・モデルから、Webテクノロジを応用したWebソリューションへと移りつつあると聞きます。この流れから、ミドルウェアの開発言語としてはJavaが採用されるケースが増えているようです。こうした動きは、文化オリエントさんの事業に何らかの影響を及ぼしているでしょうか?

 一部サーバ・サイド向けの製品もありますが、私たちが主に開発しているのはクライアント向けのコンポーネントなので、あまり影響はありません。文化オリエントは、VBが初めて登場した当初からコンポーネント開発に携わっており、長きにわたってマイクロソフト・テクノロジ一筋でやってきました。しかし1つのテクノロジに依存する体質に対して、社内でも議論があり、1年ほど前からJava向けの製品開発を始め、いくつかのコンポーネント製品を販売しています。

 そこで分かったのは、VBプログラマが求めるものと、Javaプログラマが求めるものは違うのだということです。プログラマの質が違うといってもよいかもしれません。具体的にどこが違うと指摘するのは難しいのですが、これまでの経験でいえば、VBプログラマとJavaプログラマはまったく別のターゲットだと感じます。

 実際、弊社が開発したポピュラーなVB向けのコンポーネントとして、スプレッド・コンポーネント(表計算スタイルのビューを提供するコンポーネント)がありますが、これをJava対応にしてほしいという声はほとんど聞こえてきません。ニーズが似かよっていれば、当然そういう声がもっとあってもいいはずです。

これまでの経験でいえば、VBプログラマとJavaプログラマはまったく別のターゲットだと感じます

―― クライアント・サイドは分かりました。サーバ・サイドの展開はどうでしょうか?

 Webサーバにおけるサーバ・サイド・テクノロジとして、マイクロソフトはASP(Active Server Pages)という機能をIIS(Internet Information Server)に搭載しています。しかしインターネット全体でみれば、ASPを活用したサイトというのはまだごく少数ですね。しかし最近弊社でも、ASPと組み合わせることで、サーバ側でグラフのイメージを展開し、これをクライアントであるWebブラウザに送るというサーバ・コンポーネントを開発しました。

 また弊社の別部門では、マイクロソフト・テクノロジをベースとするECサイトの構築なども手がけています。書籍のECサイトである翔泳社のSEshop.com、シーブック24ドットコムのcbook24.com、ソフトバンクのSOFTBANK BOOKSは、いずれも弊社が手がけたECサイトで、Windows OSやIIS、ASPなど、100%マイクロソフト・テクノロジで構築されています。日本国内では、このようにASPを活用したサイトも増えてきています。

マイクロソフト・テクノロジだけで構築されたECサイト、cbook24.com
文化オリエントでは、コンポーネントの開発ばかりでなく、ECサイトの構築なども手がけている。SEshop.comやcbook24.com、SOFTBANK BOOKSなどの書籍販売サイトは、いずれも文化オリエントが開発したもので、ASPなどのマイクロソフト・テクノロジのみで構成されている。

―― VB6からVB.NETに移行するためのハードルは、他の言語に比較して高いと言われています。この際、プログラマにとって障害となることは具体的に何でしょうか? そのインパクトはどれほどのものでしょうか?

 VB6と比較すると、VB.NETでは言語仕様が大きく変更されました。ここで最大のポイントは、VB.NETが完全なオブジェクト指向言語に生まれ変わったということです。

 今までのVBでは、特にオブジェクト指向など意識しなくても、手軽に使うことができました。しかし今度のVB.NETでは、オブジェクト指向プログラミングの流儀に従って、常にクラスやオブジェクトを意識するなど、オブジェクト指向プログラミングの概念をきちんと理解しておく必要があります。既存のVBプログラマにとっては、これが最大のハードルになるでしょう。

VB.NETでは、オブジェクト指向プログラミングの概念をきちんと理解しておく必要があります

―― VB6にもクラスを作成する機能は用意されていますが……。

 残念ながら、そうした機能を使うプログラマはあまり多くないようです。逆に、オブジェクト指向プログラミングの機能をすでに積極的に活用しているプログラマにとっては、それらの機能が完成されるという意味で、VB.NETへの移行には大きなメリットがあるでしょう。

―― VBで開発された既存のソフトウェア資産を、VB.NETに持ち越すことは容易でしょうか? それとも困難でしょうか?

 まだベータ1の段階ですので、はっきりと申し上げるのは難しいですが、現時点での判断としては、残念ながらソフトウェア資産の移行は容易ではないと思います。

 まず、テキスト・ボックスやリスト・ボックスなどという標準コンポーネントですら、VB.NETでは仕様がかなり変更されています。この理由は、プログラムのベースとなるフォームが従来とは異なるからです。従来のVBプログラムでは、VB Formsと呼ばれる、VB独自のフォームを使い、これに各種のコンポーネントを貼り付けてアプリケーションを開発していました。これに対しVB.NETでは、C#やVC++でも使用する、Windowsアプリケーション共通のWindows Formsを使用するようになります。また、新たにWebアプリケーション用のWeb Formsと呼ばれるフォームも追加されました。このWindows FormsやWeb Formsは、.NET Framework上に構築されたもので、生成されたプログラムはCLR上でのみ実行可能なマネージド・コードになります。これらのフォームに対応したネイティブ・コンポーネントは、すべてマネージド・コードで作成されています。このように、プログラムのベースとなる環境(フォーム)がまったく異なるということが、互換性の維持を難しくしているものと思われます。

 また細かいことを言えば、任意の型の値を代入できるというVariant型が廃止され、変数の型定義をより厳密に行う必要があるなど、言語仕様自体の変更も無視できません。

現時点での判断としては、残念ながらソフトウェア資産の移行は容易ではないと思います

 

 

 INDEX
  [Keyman Interview]
  1.VB.NET移行の最大のハードルはオブジェクト指向プログラミング(1/2)
    2.VB.NET移行の最大のハードルはオブジェクト指向プログラミング(2/2)

 



Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間