| VisualBasic あんびりーばぶる |
仕事がら、大手企業の情報システム部の方や、コンピュータ会社のシステム開発部門の方と話をしする機会が多い。最近、ソフトウェア開発の話題の中心はマイクロソフト社のWindows対応言語VisualBasicである。「こんなソフトウェアをVisualBasicで開発中である」、「こんなシステムを計画しているが、VisualBasicでプログラミングして欲しい」など、マイクロソフト社の宣伝が行き届いているためか「Windowsのプログラム開発＝VisualBasic」と情報システム部門の方が思い込んでしまっている。
なぜこんなおかしな事になったのだろうか。
Windowsソフトウェアの開発方法はいくつかあるが、正統な方法はC言語とソフトウェア開発ツールであるSDKを使用するものである。そのほか、ボーランド社のCやC++を使用する方法や、WindowsMaker、SQL Windowsなどのプログラムジェネレータを使う方法もある。
VisualBasicはそのなかでいちばん簡単な開発手段である。ちょっとWindowsソフトウェアを作ってみようと思い立ち、今まで、データベース用の簡易言語である4GLを使っていた情報システム系の人などが、サッと入れる簡単さがある。ウィンドウを開いたり、ボタンやスクロールバーの付いた見栄えのよいダイアログを作るなど、Windowsが持っている様々な資源を、マウスを使った簡単な操作で活用できる。ツールや非定型業務のソフトをひとりで作る言語としては、最強の言語といってよいであろう。
では、何が問題かというと、ひとりまたは数人での開発は可能だが、ある程度の規模のソフトウェア開発には適していないのである。大規模でも完全に処理の分かれたプログラムを大量に作るのであれば良いが、ほとんどの大規模システムは、多くのモジュールやサブシステムに分けて、分担してプログラムを作っていく。Basic言語には、「ライブラリ」という概念が無いのである。行番号がなくなり、WhileやCase文で制御構造が表現できるようになっても、所詮はBeginners All Purpose Symbolic Instruction Code 。無理にBasicで作ろうとすると、ソースプログラムをマージしたり、お互いがソースプログラムを融通し合ったりで、プログラム開発に時間がかかるし、入り組んだスパゲッティプログラムができてしまい、ソフトウェアの改造や保守もままならなくなってしまう。Excelのマクロや、MicrosoftWordのWordBasicで大規模ソフトウェアを作るのも同類である。
少しかしこい作り方としては、共通プログラムをC言語で書き、Windowsの動的ライブラリであるDLLや、アプリケーション間メッセージ通信機構であるDDEにする。そして、VisualBasicは最上位のプログラミングのみに使用する方法もあるが、VisualBasicと相性のよいDLLやDDEの設計が案外むつかしい。
いざプログラムが完成しても、実行速度がいまいち上がらない点も問題である。VisualBasicは、コンパイラといっても最適化されたオブジェクトプログラムを生成するわけではない。Basic言語のソースプログラムをちょっと解釈しただけの中間コードが作られ、それをVBRUN.DLLという実行時ライブラリが一生懸命に解釈しながら実行していくのである。元々、インタプリタ型として設計された言語仕様なので、小さなプログラムサイズや高速な処理を期待するのは無理である。
また、完成したプログラムは、何百本もの実行形式プログラムとなり、その管理も容易ではない。
もうひとつ、VisualBasicの思想に合わない処理を行なおうとすると、とてつもなくプログラミングが難しくなる、という問題もある。これは、Windowsでのアプリケーションプログラム開発全体にも当てはまるが、特にVisulBasicは自由度が低い。簡単にプログラムが作れる分、例外は受け付けない。大規模システム開発になればなるほど、仕様決定者、SE、プログラマと階層化され、仕様決定者が顧客で、SE、プログラマがパソコンメーカやソフトハウスとなる場合が多いが、「こんな操作方法にして欲しい」、「この機能は必ず入れて欲しい」、「Windowsならこんなことも出来るはずだ」、「Excelでは出来ているではないか」と無理難題を押し付けられ、失敗が目に見えているプロジェクトをしかたなく遂行しているプログラマも多いと思う。
VisualBasicは「プロトタイプを作ったり」、「エンドユーザが自身でプログラミングを行なう」道具なのである。「自身で」というのが重要で、自分で作れば、実行速度も機能もあきらめがつく。「私はエンドユーザだがプログラムは作れない」といわれそうだが、VisualBasicはそういうあなたがプログラムを作るための言語なのである。非定型の業務など、プログラミングなどと肩を張らずに、マウスをポンポンと押していくと処理が出来てしまう言語である。数年後、ある程度のソフトウェアは、プロのプログラマなど必要とせず、ユーザレベルで作れてしまうようになるであろう。
このような用途のためのスクリプト言語として、VisualBasicは非常に重要な開発環境である。Excelマクロ、WordBasic、AccessBasicの言語仕様を統一した新しいプログラム環境の提供をマイクロソフトは約束している。WindowsソフトウェアのテストツールであるMicrosoftTestのコマンド類もなどもBasic風になっており、Basicが大好きなビル・ゲーツとしては、このプロジェクトを必ず成功させると思う。VisualBasicの最新バージョンである3.0では、VisualC++でもまだサポートしていないOLE2.0のクライアント機能も入り、Basicに対するマイクロソフトの思い入れの強さがうかがえる。いちばん一般的なコンピュータ言語であるBasicの言語構造を使って、Windowsのプログラミングを身近なものとし、将来は、「プログラマ不要」裏を返せば「すべてのエンドユーザをプログラマに」してしまうBillGatesの戦略商品なのである。
10数年前、誕生したばかりのパーソナルコンピュータには、ROMでBasic言語が入っていた。フロッピィディスクが登場するとDiskBasicという名のディスクオペレーティングシステムとなり、皆これでプログラムを作っていた。
初期のPC-9801用で販売された日本語ワープロであるアイ企画の「文筆」や高電社の「マイレター」はBasicで書かれていた。業務、業種のパッケージソフトもほとんどBasicで記述されていた。その後、アセンブラ記述の管理工学研究所の「日本語ワードプロセッサ」やエイセルの「Jword」が登場し、C記述の「JxWord」がとどめを刺した。Basic to Cコンバータなる奇妙なソースプログラムコンバータまで登場し、7、8年ほど前に、C言語がパソコン用のソフトウェア開発言語として、日本でも定着した。
10数年前と同じ状況が、Windows上のVisualBasicで再現しつつある。ただし、今回はその規模が数十倍に広がっており、日本中にスパゲッティの山ができつつある。一部は冷えて絡み合ったまま固まってしまい手がつけられなくなっている。
松田聖子はニューヨークの街角で「あんびりーばぶる」と力んでいたが、BillGatesもこの日本でのVisualBasicフィーバを知れば「Unbelievable」と、あの知的な猫なで声でつぶやくことであろう。
#5「たどりついたらVisual C++」