連載：熱血VBプログラマ応援団

第9回 顧客にとってのVisual Basic .NETのメリット ――　Visual Basic .NETを採用したくなる理由とは何か？　―― 株式会社ピーデー 川俣 晶 2004/07/21

　

− 今回のご相談 −

うちの会社ではずっとVisual Basic 6.0でやってきました。しかし、いつまでもVisual Basic 6.0では通用しないだろう、ということで新しい言語を勉強することにしました。候補にはJavaやC#も挙がりましたが、完全に新規の言語を勉強するのは無理だろうということで、現在Visual Basic .NETを勉強しています。最初のうちは細かい違いが多く戸惑いました。しかし、ある程度のところまでなら、Visual Basic .NETで組めるという自信も出てきました。 　そこで、そろそろVisual Basic .NETの案件に取り組んでみようか、という話になりました。しかし、システム開発を発注するお客さまの側は、ドットネットは怖い、実績のあるVisual Basic 6.0の方がよい、という意見が多く、受注してもVisual Basic 6.0で開発することになってしまうケースが多いのです。こちらとしては、ぜひVisual Basic .NETでやってみたいのですが、結果として出来上がるプログラムの機能が同じ場合、どうしてもVisual Basic .NETで開発する必要性を納得させることができません。 　いったい、どのようにすれば、Visual Basic .NETで開発するようにお客さまを説得できるでしょうか？ 川上巨人V9 より

C／C++とC#の場合であれば

　顧客の立場に立って考えれば、実績のある言語を使う方が安心できるのはもっともなことです。本格的な業務システムともなれば、システムは複雑なものになり、どんなトラブルが起こるか分かりません。できるだけ、リスクは小さいに越したことはありません。

　それにもかかわらず、言語が世代交代していくのは、新しい言語には、リスクを補って余りあるメリットがあるからだといえるでしょう。

　例えば、安全性という観点から見ると、どうしてCやC++といった古い言語からC#に移行する価値があるのかを説明するのは簡単です。ここでは、安全性から見た移行価値の一例について紹介してみます。

　世の中には、バッファ・オーバーランと呼ばれるセキュリティ・ホールが存在しますが、C／C++からC#に変更するだけで、このタイプのセキュリティ・ホールを作り込んでしまう可能性を大幅に低減させることができます。バッファ・オーバーランとは、確保されたメモリ領域を超えてデータを書き込むことによって、プログラムの正常な動作を阻害したり、不正なプログラムを実行させたりできるという問題です。

　CやC++では、いともたやすくバッファ・オーバーランを引き起こすプログラムを作成できます。例えば、確保した配列のサイズを超えてデータを書き込んでしまうようなプログラムを作成すると、それだけでバッファ・オーバーランの脆弱性を持つプログラムになってしまう可能性があります。

　しかし、C#の配列では、確保したサイズを超えて書き込もうとしても例外が発生し、書き込むことができません。そのほかのケースでも、C#で記述されたプログラムでは、正常な動作を阻害するような不正なメモリ操作ができにくくなっています。

　恐らく、CやC++ではなく、C#を使うだけで、バッファ・オーバーランの脆弱性が発生する確率は非常に低くなるでしょう。そのような点で、顧客に対して「CやC++よりもC#を使いましょう」と説得することは可能かもしれません。これは、ネットワークから攻撃を受ける可能性があるサーバで運用するプログラムでは重要なポイントになるでしょう。

　（もっとも、不思議なことに、世間の多くの人はC#よりもCやC++で書かれたプログラムの方を信用するようです。Visual Basic .NETだけでなくC#の世界でもドットネットは怖い、といった反応は珍しくありません。しかし、プログラマのちょっとした不注意で、いとも簡単にバッファ・オーバーランを引き起こせるようなCやC++の方が安全だと思うのは、あまり妥当性のあることではないでしょう）

この問題はVisual Basicでは最初から解決済み

　さて、もちろんこの連載は熱血VBプログラマ応援団ですから、C#の話ばかりしても意味がありません。ここでは、C／C++よりもC#の方がバッファ・オーバーランの脆弱性の危険が少ないことを説明しましたが、同じ説得がVisual Basic 6（以下、VB 6）とVisual Basic .NET（以下、VB.NET）の間でも可能でしょうか。

　もちろん、答えはノーです。VB 6でも、そう簡単にバッファ・オーバーランの脆弱性は作り込めないからです。VB 6も確保した配列の範囲を超えて書き込もうとすればエラーになります。C／C++系の言語がC#（あるいはJava）でやっと獲得した安全性も、Visual Basicでは最初からそうであった当たり前の機能に過ぎません。少なくとも、この点に限るなら、VB 6の方がCやC++よりも安全性の高いプログラム言語だったといえます。この点で、VBプログラマは胸を張ってもよいでしょう。決して、すべての点でVisual Basicが他言語よりも優れていたというわけではありませんが、誇れる美徳がなかったわけではありません。

　とはいえ、最初から解決済みという結論は、ここでは大きな問題です。VB.NETならではのメリットにならないからです。継承が使えるといった純粋にプログラミング上のメリットを除けば、恐らく、C／C++ではなくC#を使うメリットの数よりも、VB 6ではなくVB.NETを使うメリットの数の方が少ないかもしれません。

　では、あらためて別の角度から、顧客にとってのVB.NETのメリットがどこにあるか考えてみましょう。

VB.NETで本質的に違うのはどこか

　そもそも、VB 6とVB.NETの最も根本的な相違はどこにあるのでしょうか。それを把握することが、VB.NETのメリットを探る早道となるでしょう。

　ではいったい何が根本的に違うのでしょうか。恐らく、基本設計が行われた年代が違う、ということが根本的な相違といえるでしょう。年代が違えば、その年代ごとに要求も違います。最初のVisual Basic（Visual Basic 1.0）が生まれたころは、まだインターネットは一般の利用者が使うものではなく、LANがやっと普及し始めたころに過ぎません。複数のパソコンをネットワークに接続して使うだけで、その便利さが驚きとなっていましたが、あくまでネットワークに接続していなかった時代の開発スタイルが継続していました。

　それに対して、VB.NETが生まれた年代は、すでにインターネットは確固たる通信インフラの地位を固め、同時にさまざまな脅威もインターネット経由でやってくる時代です。そして、パソコンをネットワークに接続するのは当たり前のこととして、その管理コストなどが問題にされるようになったのです。また、ネットワークによって機能を分散させるプログラミングも要求されます。

　以上のような背景を踏まえて、どこに顧客のメリットを見いだせるか考えてみましょう。

顧客にとってのVisual Basic .NETのメリット

　最もアピールする可能性があるのが管理コストの問題でしょうか。例えば、.NET Frameworkさえ入っていれば、Webブラウザ経由で応用ソフトを起動できるノータッチ・デプロイメントなどは、Webアプリケーションよりも良好な使い勝手を維持しつつ管理コストを下げる効果が期待できます（ノータッチ・デプロイメントについては「特集：ノータッチ・デプロイメント」を参照）。

　ノータッチ・デプロイメントを使うようになると、次に気になるのがセキュリティです。利用者が、何らかの方法で外部のサイトに誘導され、悪意を持ったプログラムを起動させられる可能性がないともいえません。その場合でも、VB.NETは.NET Frameworkの強力なセキュリティ機構の上で動いているため、安全度は高いといえます。ネットワーク上から起動されたプログラムは、標準状態ではローカルにあるファイルを自由に読み書きすることすら許されません。VB 6で作成した応用ソフトをネットワークから起動するような使い方では、このような制約を課すことはできません。VB.NETならではのメリットといえます。

　また、ネットワークの存在を前提としたシステム構築が、格段にやりやすくなっていることもメリットといえるかもしれません。本連載でも取り上げたスマート・クライアントも、VB.NETによって実現しやすいシステムの1つです。システムを3階層に設計し、太りすぎていたクライアントをスリム化することができます。それによって負荷バランスの良い分散もでき、システムの使い勝手や、管理運用のやりやすさというメリットも生まれるでしょう。

　スマート・クライアントに使用されるのはもとより、遠隔地のシステムの機能を呼び出すために使われるWebサービスを容易に作成できるのもVB.NETのメリットといえるでしょう。付加価値の高い重要な情報を持ったシステムが、遠隔地の他企業などにあり、それを利用するようなケースがしばしば見られるようになってきました。その際、ファイアウォールやプロキシ・サーバを越えて通信できるWebサービスが利用される場合がありますが、VB.NETであればたやすくそれに対応することができます。

未来の可能性

　話はこれで終わりではありません。まだはっきりと姿を見せてはいませんが、未来に向けた布石がVB.NETには打ち込まれているのです。いま現在は、まだ効果を発揮していないものの、近い将来メリットとして浮上しそうなことを2つ紹介しておきます。

　1つは、新しいCPUへの対応です。前回で述べたように、VB.NETは中間コードにコンパイルされ、実際に実行されるパソコン上でネイティブ・コードに変換されます。これにより、実際に実行するCPUに合わせて最適なネイティブ・コードに変換することが可能となります。

　例えば、アーキテクチャに互換性がない古い32bit CPUと新しい64bit CPUが混在するようなシステムでも、（API呼び出しなど個々のシステム固有のアーキテクチャに依存する機能は使わないといった制約を守る限り）VB.NETでは1種類の実行ファイルを作成するだけで済みます。つまり32bitパソコン上では32bit版の.NET Frameworkがネイティブ・コードへの変換を担当し、64bitパソコン上では将来リリースされる64bit版の.NET Frameworkがネイティブ・コードへの変換を担当することで、それぞれ最適なネイティブ・コードを得ることができるわけです。これによって、VB.NETでは再コンパイルすることなしに、最新のCPUのパワーを発揮するようなプログラムも開発可能となるわけです。

　もう1つは、次世代のWindowsといわれるLonghornへの対応です。Longhornの多くの部分はVB.NETが生成するコードと同じマネージ・コードで書かれているといわれています。つまり、LonghornというOSと、VB.NETで作成されたプログラムはダイレクトに接続され、最も効率よく動作することになります。

　現在は、VB.NETで作成されたプログラムはクラス・ライブラリとWin32 APIを経由してOSの機能を呼び出していますが、LonghornからはWin32 APIを経由することはなくなると思われます。さらに、Longhornの新機能はWin32 APIではアクセスできず、Longhornのクラス・ライブラリを経由してアクセスするのではないかと思われます。もちろん、そのようなアクセスは、VB.NETならたやすく達成できるでしょう。Longhornの能力をフルに引き出すならVB 6からVB.NETに乗り換える必要がある、ということになるかもしれません。

より現実的な視点から見ると

　未来の夢はさておき、もっと地に足が着いた現実的な視点から見てみるのも悪くないでしょう。

　古い言語を使い続けることには、いくつかの懸念があります。それを踏まえると、新しい言語に移行することが、消極的ではありますが肯定される場合もあるでしょう。

　懸念の1つは、細かい点で時代の要請にそぐわないことが生じることです。昔は、年号の追加（平成が追加された）といった問題などがありましたが、最近ではこの種の情報はOSが一括して管理しているようで、プログラム言語側では問題にならないかもしれません。しかし、しばしば細かい修正に迫られる可能性がないともいえません。Visual Basicの場合、Service Packを通じて、そのような修正は行うことができたと思いますが、サポートが切れ、Service Packなどの供給が止まると保守に苦労する可能性があり得ます。

　サポート切れは、ほかにもいろいろな影響を及ぼします。しかし、真の問題は、作成したプログラムの寿命の見積ミスにあります。2年しか使わないから、といわれて作ったプログラムが20年も使われたりすることもある世界です。サポートが切れる前に使用を終えるから、あるいはサポートが切れた後、長期間使うわけではないからといって古い言語を使うと、予想外に長い期間使い続けることになり、保守に苦労することが考えられます。そのため、できるだけ残されたサポート期間が長い言語を使っておくに越したことはありません（もちろん、出荷されたばかりの実績もない言語であれば、それは避けた方が賢明ですが、VB.NETはその域をクリアしているので選択肢に入れてよいと思います）。

　また、解説書などの技術情報も世代交代していくことに注意が必要です。例えば、昔筆者はVisual Basic 2.0の技術解説書を執筆しましたが、現在それを入手することは不可能です。古い言語は、保守などで技術情報が必要になっても、それを入手できないリスクがあり得ます。その点でも、いまはまだVB 6関係の書籍などが容易に手に入るからといって、いつまでもそれが続くと考えるのは危険です。

　これらの問題は、直接的には顧客の問題とはいえませんが、間接的に維持コストの増大というデメリットを顧客に与える可能性があります。消極的な理由ではありますが、顧客が負担するコストを低減させるという意味で、これもメリットと考えてよいかもしれません。

もっと単純な原則で

　以上、VB.NETを採用することによるさまざまな顧客のメリットを考えてみました。考えればいくらでも理由は思い付くことができるでしょう。しかし、筆者としては、そのような多くの理由とは別に、もっと単純な原則があるように思います。

　それは、プログラムは変化し続けていくしかない、というものです。時代の変化、ニーズの変化、環境の変化などによって、実際に使われるプログラムは一定というわけではなく、変化し続けるのが当然の姿ではないかと思います。そして、VB.NETという存在も、そのような変化の1つとして受け止めてよいのではないかと思います。もちろん、変化はより良く状況に適応するために必要とされるものです。VB.NETもまた、より良く「いま」という状況に適応するために生まれてきたものだと思います。

　そのように考えれば、VB.NETがどんなメリットを顧客にもたらすかは、必死に考えるようなものではなく、必然的に必要に応じて浮かび上がってくるようなものだといえるかもしれません。

　頑張れVBプログラマ、君たちが使うVisual Basic .NETは取り組む価値のある可能性に満ちたプログラム言語だ！

更新履歴

【2004/07/21】本記事の一部（下記の表を参照）に誤解を招く不正確な表現が含まれていました。お詫びして訂正させていただきます。 誤 　例えば、アーキテクチャに互換性がない古い32bit CPUと新しい64bit CPUが混在するようなシステムでも、VB.NETでは1種類の実行ファイルを作成するだけで済みます。個々のCPUに対応するネイティブ・コードへの変換は、実行に使用するパソコンに組み込まれたJITコンパイラが行うので、そのパソコンのCPUに適合したコードが得られます。つまり、VB.NETでは再コンパイルすることなしに、最新のCPUのパワーを発揮させられるわけです。 正 　例えば、アーキテクチャに互換性がない古い32bit CPUと新しい64bit CPUが混在するようなシステムでも、（API呼び出しなど個々のシステム固有のアーキテクチャに依存する機能は使わないといった制約を守る限り）VB.NETでは1種類の実行ファイルを作成するだけで済みます。つまり32bitパソコン上では32bit版の.NET Frameworkがネイティブ・コードへの変換を担当し、64bitパソコン上では将来リリースされる64bit版の.NET Frameworkがネイティブ・コードへの変換を担当することで、それぞれ最適なネイティブ・コードを得ることができるわけです。これによって、VB.NETでは再コンパイルすることなしに、最新のCPUのパワーを発揮するようなプログラムも開発可能となるわけです。

　

「熱血VBプログラマ応援団」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）