Visual Basicトラブル
シューティング 傾向と対策

酒井法雄 SAKAI, Norio norio@int21.co.jp　　

Visual Basicを使うワケ

　パソコン環境の進化は速い．OSやインターネットなど，パソコン環境は根底の部分から新しくなってきている．そして，Visual Basicもバージョン5.0になって，さまざまな新機能が搭載され，より柔軟な開発環境へと強化された．一連のActiveX技術やデータアクセス，インターネット／イントラネットへの対応などの他，AddressOfなどより低レベルな処理も可能になった．
「カンタンにWindowsアプリケーションを作ることができるツール」であったVisual Basicが，今や標準的なWindows開発ツールとなりつつある．なにせ，本誌のようにVisual Basicで一冊の月刊誌ができてしまうほどである．
　では，どうしてVisual Basicはここまで普及したのであろうか．いろいろな要因はあるだろうが，何よりも「Microsoftの製品であるから」という理由が大きいのではないだろうか．
　今や，ハードウェアは高性能で安くなり，やれダウンサイジング，C/S（クライアント／サーバー）だインターネットだと，従来はPCに関係なかった分野までをもWindowsでやろうという話になってきた．今までCOBOLでシステム開発をしてきたような開発スタイルは，OSのインストール，ネットワーク管理，設計，コーディング，メインテンナンスといったことが，細かく分業化されていた．ところが，Windowsの世界では，そこまで細かく分けられていない．今までは知らなくて済んだところまでを，開発に関わる人間すべてが知らなくてはならない状況になってきているのである．一方，今までPCでスタンドアロンのプログラムを作ってきたようなところでも，ネットワークやRDBMS，さらにはインターネットなどの知識や技術が欠如している．やはり，従来よりもずっと広い知識が必要になるのである．
　このように，Windowsでのソフトウェア開発といっても，多様な分野があるのだ．それをすべて分かるようになるのは，非常に困難なことである．
　一番基本的な部分であるOSレベルを考えてみよう．Microsoftの供給するWindowsというGUIベースのOSになってから，DOSなどのCUI環境に比較すると，APIが非常に増えた．これは，メッセージベースのマルチタスクで，ウィンドウベースですべてを処理していくからである．そして，その仕組みはどんどん複雑化し，APIセットも増加の一方である．そして，その供給元はMicrosoftなのである．
　こうなってくると，少しでもカンタンなもので，かつ進化著しいOSの提供元であるツールを使おうというのは，ごく自然な話である．カンタンな開発ツールとは，いわゆるRAD（Rapid Application Development）と呼ばれるものである．厳密な設計をしていた従来の開発スタイルではなく，いちはやくプロトタイプを作り，スクラップ＆ビルドでとにかくモノを作っていける．あまり細かいことを知らなくても，とにかくモノができるというのがRADの魅力である．RADと呼ばれるツールには，Visual Basicの他にBORLANDのDelphiなどがある．たとえば，ツールとしてのデキという話になれば，Delphiの方が圧倒的にデキがよい．しかし，安心のためには，OSを提供しているMicrosoftの製品で，RADツールとしてはデファクトスタンダードで，今後も最新の機能にいちはやく対応することが期待できるVisual Basicを選ばざるを得ないのである．
　今までの話から，Visual Basicが選ばれる要因としては，次のことがあげられる．

RADであること

理由：面倒なことを知らなくてもとにかくモノができる
メリット：教育コストが低減できる．開発期間やコストの低減ができる

Microsoftの製品であること

理由：OSと整合性が取れていて安心できる
メリット：安定して動作する．将来に渡って動作が保証される

　これらは，決して誤った選択ではない．たしかにそうである．しかし，現実にはこのようなメリットがないケースも多いのではないだろうか．RADとはいえ，その内容は膨大であり難しい．OSに取り入れられた新機能はたしかにスグに取り入れられるが，バージョン間での動作の違いなどがあり，旧バージョンからの移行は決してたやすくはない．おまけに新しいものにはバグがある．しかも，OSレベルでの問題を抱えているものすらあるのだ．
　つまり，上記の選択理由はVisual Basicの一面的なものであり，メリットだと思ってきたものは，あくまでもその一面から出てきた判断だったのである．他のことと合わせて総合的に判断していくと，これらのメリットは必ずしも出てこないし，むしろその反対であることも少なくないのだ．
　ならば，何を使えばよいのか？ 用途にもよるが，一般的にものであれば，私はやはりVisual Basicを選ぶだろう．なぜなら，カンタンだとナメてかからなければ，そしてMicrosoftのものだからという過度の期待をしなければ，Visual Basicはとても便利なツールだからである．
　では，どのようにVisual Basicと付き合っていけばよいのか．それが今回のテーマなのである．今までの話からは，次のようになる．

Visual Basicはムズカシイのだ．ナメてはいけない．
Microsoft製品だからといって安心するな．

　ということは，つまるところVisual Basicユーザーの態度にも問題があるということだ．

甘えてはいけない．もっと勉強せよ．

　とっても偉そうだが，あえてこう書かせていただく．
　こういうのが嫌いな方もいらっしゃるかもしれないし，私も偉そうなことを書きたくない．しかし，今まで数々のセミナーやコンサルティング，PCDNのNetNewsなどで得た感触からすると，失敗しているユーザーに足りないのは技術力だけではない．心構えの問題が大きいのである．だから，あえて最初にこの問題を述べておくことにしたのだ．
　では，次にVisual Basicでの，というよりは，Windowsソフトウェア開発に関わる問題を系統的に分析してみよう．そして，どのような心構えや準備が必要なのかについて述べることにする．

問題の傾向と分類

　ソフトウェアを作るには，まずは環境が必要である．当然ながら，パソコンがなければソフトウェアの開発はできない．それと同レベルで，資料や開発環境が整っていないと話にならない．まずは，そういった環境が整備されていないことには，問題解決ができない．
　前提条件があれば，一般的な開発の流れに沿って話を進めることができる．これは，一般的に次のような流れになる．分析，設計，コーディング，デバッグ，運用，メインテンナンス，バージョンアップ．もちろん，問題は必ずしも明確にこの通り分類することはできない．これらのうちで，あちこちに出てくる共通の問題もあるからである．
　その中でも重要なことは，情報の収集である．開発環境の構築からはじまり，実際に開発していく過程での問題解決に役立つような情報を，いかに効率よく集めてくるかということだ．
　以上をまとめ，次のような流れで問題を追ってゆこう．次に概要を示す．

開発環境の整備
　パソコン，周辺機器，OS，ネットワーク環境，ドライバ，ツール，コンポーネントなどの部品など，最低限必要なハードウェアやソフトウェア環境を揃える必要がある．効率よい開発には，一見贅沢とも思えるほどの投資も必要だ．

資料の整備
　本当は開発環境に含まれるものと考えるべきだが，技術資料となるソフトウェアや雑誌，書籍なども必要である．これがないと，すべてが他力本願になってしまう．他人からヒントをもらうのは結構だが，その後に自力でなんとかできる程度の資料とスキルは備えたい．

情報の収集
　分からないことがあったり，問題が発生したときに，効率よく解決するには自力だけでなく，第三者からの情報が重要である．インターネットのMicrosoftのサイトや，PC Developer NetworkなどのNews GroupやMailing List，無料・有料サポート，セミナー，コンサルティングなどから効率よく情報を集めたい．お金がかかるものもあるが，自力でやることを思えば，結局はコストを下げることができるのだ．

分析・設計
　目的となる業務を実現するために必要なことをまとめる必要がある．当然ながら，このときにはOSやツール，ハードウェア環境の選択が必要になるし，本当にそのツールでできるかを最低限検証しておかなくてはならない．ここが不十分だと，途中で「できませんでした」などということになりかねない．

コーディング・デバッグ
　実際にコーディングに入ってくると，プログラマ個人のスキルがいよいよ問われてくる．効率よいコード，バグの出にくいコード，エラーハンドリングなどをしっかりとコーディングできるかが問われる．また，いかに設計がしっかりしていても，そこで初めて露呈する問題もある．それらをいかにうまくこなしていくかが重要だ．

運用・メインテンナンス・バージョンアップ
　システムができても，実際に運用を開始してから露呈する問題もある．ここまでくると，設計が悪かったでは済まない．いかに問題を回避するかが重要である．また，メインテンナンスやバージョンアップをいかに効率よく行なうかも重要な問題だ．
　では，個々の内容について吟味していこう．

開発環境の整備

　開発環境と一言で片づけてしまうと，ツールを主体に考えがちである．しかし，そうではない．ハードウェア環境も重要である．もちろんソフトウェア環境も万全にしたい．
　個々に注意点を述べていこう．

ハードウェアは慎重に贅沢に選ぶ
　パソコンは資産であり，減価償却は5年である．しかし，はっきりいって現実的に第一線で活躍できるには2年がいいところだろう．だからといって，ハードウェアをケチってはいけない．ソフトウェアはどんどん巨大化しており，OS環境は複雑化している．古いマシンを使っていては，効率よい開発は望めない．
　では，高いマシンを買ってくればよいのかといえば，必ずしもそうではない．有名メーカー製マシンに限って，コストダウンや高性能化のためにカスタムチップを多用していたりして，コンパチビリティが下がることがあるからだ．オーソドックスなマザーボード，ビデオカード，SCSIカード，ネットワークカードといったものを使っているマシンをチョイスしたい．しかし，新しすぎるものや，安物では問題が起きることがある．あくまでも実績をベースに考えるべきだ．
　たとえば，東芝のBREZZAなどはMMX Pentiumが出たおかげでスタンダードなPentiumマシンはたたき売りされていたが，このマシンはケースもよいし，マザーボードはIntel製のオーソドックスなものだ．モデムカードやUSB系のデバイス，IDEのハードディスクなどは外してしまえば，とてもよいベースマシンになった．
　しかし，本当に重要なのは，ベースになるマシンからのグレードアップである．今やOSもツールもさまざまなバージョンがあり，SP（Service Pack）も次々と出ている．問題解決のために調査をしたり，クリーンな環境を維持するためには，ひとつのマシンに複数のOSを入れる必要がある．厳密にいろいろなケースをテストしたいならば，OSとSPとツールの組み合わせで10種類くらいは必要だ．ふつうはそこまで必要はないだろうが，2種類くらは最低必要だろう．また，ツールやOS自体のサイズも大きくなっている．
　というようなわけで，ハードディスクは4GBから6GBはふつうに入れたい．当然ながら，MOやDATなどのバックアップデバイスも欲しい．また，メモリも開発マシンならば，最低64MB，できれば128MBくらいは装備したい．ソフトの動きが遅いと思っていたら，メモリが足りないせいだったというのは，実にありがちである．メモリが大きくなれば，仮想メモリのサイズも大きくなるから，ハードディスクのパーティションのサイズも，思いきって1GBから2GBくらいはとりたいところだ．
　今やディスクもメモリも安いので，これくらいは当然である．
　また，マシンもできればひとり2台以上はほしい．1台は枯れた環境として死守する．もう1台には最新の怪しいものも入れるというような使い分けだ．もちろん，複数のマシンはネットワークで接続されていることが望ましい．いや，いまなら当然そうなっているべきだ．
　ちなみに，私はサーバー以外の開発用マシンやテスト用マシンとして，ひとりで3台のデスクトップと2台のノートパソコンを使っている．これらはすべて自分で実績のあるパーツを買ってきて組み立てた．デスクトップマシンはPentium 166MHzでディスクが6GB，メモリは128MBである．CPUはそこそこ速いので，これで困ることはとりあえずない．ただし，ディスクはSCSIカード2枚差しでWindows NTのストライプセットにして高速化している．
　ノートパソコンは1年以上前のPentiumマシンだが，メモリを40MBフル実装し，ディスクは2GBに載せ換えている．しかし，この程度のメモリではテストマシンにしか使えない．
　また，モニタは長い時間使うものだから，なるべくよいものを使いたい．今や17インチのモニタがふつうだろうが，安いモノだと1280×1024ドットがきれいに出ないし，周波数範囲も狭い．どうせならば，一番高くて品質のよいものを選ぶべきだ．高いと言っても，今やモニターもとても安くなっている．万が一目が悪くなることを考えれば，モニタに数万円余計に金を出すことなどなんでもないことだ．

ソフトウェアはプリミティブなものは揃える
　ソフトウェアには，過剰に凝りすぎる必要はない．ヘタにヘンなものを入れてしまうと，他に影響が出るということもあるからだ．しかし，Visual BasicならはEnterprise Editionをおごろう．Visual Studioを買うなどして，VisualC++やSDKも手に入れるべきだ．その他に必要なものといえば，情報収集のためにインターネットに接続できるようにした上で，ちゃん使えるWebブラウザやNews Reader，Mailerを揃えるくらいである．
　あとは，必要に応じて足していけばよい．

資料の整備

　資料というと，Visual Basicの入門書に毛の生えたような書籍を想像するかもしれないが，はっきり言ってそのようなものはほとんど必要ない．もし，あなたがVisual Basicの初心者なら，なおさらそのようなものは必要ない．
　というのも，Visual Basicにはマニュアルとオンラインヘルプが完備しているからだ．Visual Basic 5.0になって一番困ったのは，このオンラインヘルプが遅くなったことだ．そして，情報としての品質は確実に劣化している．ましてやVisualC++のInfoViewerなどはHTMLベースで話にならない品質だ．とはいえ，最低限必要な情報はここにある．マニュアルを読んでも分からないという人は，入門書を買ったらよいだろうが，そんなことより自分で触って反応を見て慣れることが一番である．
　そんなことより，本当に必要なのは，次のものだ．

『Windowsユーザーインターフェイスデザインガイド』（アスキー刊）
　Microsoft Pressの本で，アスキーから発売されている．Windowsでどのようにアプリケーションのユーザーインターフェイスを作るべきかが書かれている．これを読まずして，Windowsのプログラミングをしてはいけない．
　この本の効用については後ほど述べる．

図1：Win32SDK

SDK
　Windows Software Development Kit．Visual Basicがいかに高機能になったとはいえ，できないことはまだまだある．そんなときにちょっと使うと便利なのがWindows APIである．SDKは，Windows APIやメッセージについての解説やCのヘッダファイル，ツールなどから成るものだ．
　よく，APIを使いこなすための書籍はないかと聞かれることがあるが，書籍はどれも中途半端であったり，新しいものが掲載されていなかったりするので，お勧めできるモノはない．また，Visual Basic附属のAPIビューアはVisual Basicで使うときのAPIの宣言や構造体や定数の定義があって一見便利なのだが，誤りが多いし，新しいAPIは載っていない．SDKにある資料が大元であり，すべてが揃っているし，ヘルプの形で提供されているので検索性やコピー&ペーストもカンタンだ．APIビューアを使うにしても，APIのヘルプで確認すべきだ．
　SDKは今は単体売りをしていないので，VisualC++またはMSDN（Microsoft Developer Network）のプロフェッショナルサブスクリプション以上に附属しているものを使うことになる．しかし，SDKのヘルプはほとんどが英語である．以前のVisualC++2.0附属のものは日本語であったが，今となれば足りないモノが多く役に立たない．これは単なるヘルプファイルなので，新しいものと併用することもできる．

VisualC++
　SDKが入っているばかりでなく，さまざまなツールや，当然だがC/C++コンパイラが装備されている．Visual Basicだけでできないことで，ある程度まとまった処理が必要なときには，APIコールをしまくるよりも，VisualC++でDLLやActiveX Serverなどを書いた方がよいケースも多い．どうせなら手に入れたい．

MSDN
　MSDNには，次の4種類のサブスクリプションがある．CDは2ヶ月に一回アップデートされる．

・ライブラリ：DeveloperライブラリCDおよび，紙ベースでのニュース，E-Mailでのニュース配送がある．このCDには，Microsoft WebサイトにあるKnowledge Base（KB）の内容やWhite Paper，ドキュメント，ツール，セミナー資料，サンプルプログラムなどが入っている．特にKBにはバグ情報やHow toもののFAQが豊富である．Microsoftのサポートに問い合わせるより，これで検索した方が速い
・プロフェッショナル：ライブラリに加えて，各国語版OSやSDK，DDKなどの開発キットが附属する
・エンタープライズ：プロフェッショナルに加えて，サーバー系の製品も配布される
・ユニバーサル：エンタープライズに加え，VisualC++やVisual Basicなどの開発ツールも配布される

図2：MSDN Library

　MSDNに入ると，開発用限定ながら，製品を買うより安くMicrosoftの製品を入手できる．ただし，実際には一般公募するβ版や，製品の発売より遅れて送られてくることが多く，腹立たしい．開発者用のプログラムなのだから，一般より速く届けるべきである．結局市販されているものも買わなければならないケースも多かった．しかし，これも徐々に改善されてきている．
　というわけで，ユニバーサルとは言わないが，プロフェッショナル以上には必ず入るべきである．ただし，MSDNの資料のほとんどは英語である．最近ではかなりの部分が日本語化されてきたが，まだまだ英語が必要である．
　しかし，臆さずに読んでみよう．ほとんどがテクニカルタームなので，実はそんなに難しいことはないのた．

ReadMeとBooksOnline，Visual Basic CD-ROMの中身
　これらはあらためて用意するものではなく，Visual BasicのCD-ROMに含まれている．
　フルインストールすれば，ReadMeやBooksOnlineはインストールされる．ReadMeは，Visual Basicを使う上でのさまざまな注意点が述べられている．Books Onlineには，Visual Basicのヘルプやマニュアル+αの情報が収められている．すべて検索できるので，これも開発には便利だ．
　CD-ROMの中には，インストールこそされないが重要なデータやツール，ドキュメントが入っている．一度じっくりと時間をかけて中身を見ていただきたい．

図3：Visual Basic BooksOnline

　これ以外にも，必要に応じて書籍などを揃えるとよい．Microsoft Pressのものは，Microsoftに近い筋の人間が書いているので，詳細だし信頼性が高い．ここで注意が必要なのは，「Visual Basic」と銘打ったものではなく，「Windowsプログラミング」や「OLE」あるいは「COM」，「ODBC」といったレベルのものを選ぶことだ．Visual Basic自体のことは，ほとんどヘルプとMSDNで分かるからだ．
　Visual Basicという名前がついている書籍は，具体的に役立ちそうなサンプルプログラムがあるようなものを選ぼう．
　さて，ここまで揃って，初めてプロのVisual Basicの開発者の環境と言える．しかし，開発に入る前にやっておかなくてはならないことがある．まずはそれを述べておこう．

開発に入る前にWindowsプログラミングとは何かを知ろう

　開発環境や資料が揃ったからと言って，すぐに本格的な開発ができるわけではない．もちろん，あなたは今までにもそれなりにプログラミング経験があり，自信を持っているだろう．
　しかし，一般道しか走ったことのない人が，突然F1マシンを手に入れてもサーキットでシューマッハと戦えるわけがないのと同じで，マシンのセッティングやドライバの訓練をする必要がある．もしかしたら，あなたはインディカーの経験があるかもしれないが，F1はまた別の世界であるといったようなものだ．
　ここで言いたいことは，あなたはVisual Basicのプログラミングをしようとしているのではなく，Windowsのプログラミングをしていることに気づいてほしいということだ．Visual BasicはF1と言えるほど難しいものではないだろうが，Windowsプログラミングのエキスパートになるためには，かなりの知識とスキルが必要になるということだ．
　そんな面倒くさいことをしたくないからVisual Basicを選んだと言う方もいるだろうが，現実的には面倒くさいことをクリアしないといけないのが現状なのだ．
　次に，開発者がしておくべきことを述べる．

Windowsユーザーインターフェイスデザインガイドを読破する
　まず最初にしなくてはならないのは，Windowsのユーザーインターフェイスを知ることである．そんなことはとっくに知っていると言う人に限って，資料のところで紹介した『Windowsユーザーインターフェイスデザインガイド』（前述）を読んでない． 何気なく使っているマウスを使った操作やGUIのデザインのしかたについてここには書いてある．
　Windowsでは複数のアプリケーションがウィンドウを持っているのが普通だ．そしてマルチタスクで動作する．こうした環境をキーボードとマウスでどのようにして破綻なくユーザーインターフェイスを実現するかということが書かれているのである．これはごくふつうに思えるが，実は，かなり綱渡り的なところがあるのだ．あるルールを守ってこそ，この環境が破綻しないのである．それを明確に知っておく必要があるのだ．
　斜め読みでもよいから，この本は必ず読んでおかなくてはならない．ユーザーから無理なユーザーインターフェイス，たとえばキーで次のフィールドに移動してくれなどという仕様をつきつけられたときに，この本を根拠にして断ることもできるハズだ．

Cを使ってネイティブなWindowsプログラミングを体験する
　Visual Basicはしょせんブラックボックスであり，その中ではWindowsネイティブなメカニズムで動作している．その内部の動きを知らなくて済むのがVisual Basicだが，知っていればもっと効率よくプログラミングできるし，やってはマズそうなことも分かる．
　このメカニズムを知るには，まずは『プログラミングWindows95』あたりのWindowsプログラミングの入門書を斜め読みする必要がある．間違っても読破しようと思わないことだ．この厚い本は実によい睡眠薬になるからだ．そして，基本的なところからC（C++ではない）を使ってプログラミングしてみよう．このためにもVisualC++は必須である．Cを使って冗長なコードを書き，やっとウィンドウとAboutBoxを出すことができれば，Visual Basicのありがたみも分かるというものだ．そして，その内部動作がどうなっているのかも見えてくる．徐々に目からうろこが落ちていくような感覚を味わえるハズだ．そして，その過程で，数々のAPIやメッセージ，そしてそれらの基本的な使い方や一般的な作法などを知ることができるハズだ．この経験こそ，その後のVisual Basicでの開発に生きてくる．
　そもそも，Visual Basicほどブラックボックス化されたものを，平気で，全幅の信頼をもって使うことができるなら，その人は探求心のないプログラマである．もちろん，お金をもらうためだけのプログラマをしているならそれでもよいだろうが，自分の仕事，自分のスキルに自信と誇りを持ちたいのならば，それではいけない．この手の入門書のすべてを読破して，すべてのサンプルプログラムを経験する必要はない．興味を持ったところだけでもかまわない．これからあと，もうCなど使うことはないかもしれないが，この経験はスキルフルなWindowsプログラマには必須である．少なくとも，一人はこうしたことが分かる人がいないと，まともなプロジェクトにはならないだろう．
　情報の収集については最後に回すことにして，次からは，実際の開発に関わる部分の内容に入ろう．

分析・設計

　ソフトウェア開発の第一歩は，業務の分析である．たとえゲームを作るにしても，分析は必要である．そして，綿密な分析をした上で，設計に入っていくことになる．
　いかにVisual BasicがRADツールだとはいえ，本当に何も考えないではプログラムの作りようがない．仮にカンタンなプログラムであっても，頭の中ですべきことを分析し，プログラムがどうあるべき設計しているのである．ましてや，複雑なシステムであれば，頭の中で考えただけではなく，きちんとドキュメント化しなくてはならないのは当然だ．たとえメモ程度でもよいから，こういうことはきちんとしておくべきだ．その過程で，「これはどうやったら実現できるか」「パフォーマンスは大丈夫が」「メインテンナンス性はよいか」「コストはどれくらいかかるか」といったことをひとつひとつ解決していくのである．ここが不十分だと，後になって泣くことになる．
　以下，分析・設計段階でしなくてはならないことをまとめてみた．

Windowsでよいのか？
　まず最初に考えなくてはならないのは，本当にWindowsでよいのかということだ．たとえば，GPIBなどのカードを使ってリアルタイムに機器制御をしなくてはならないといったときには，そのカード専用のデバイスドライバが必要だ．
　こういったリアルタイム処理には，Windowsは向いていない．すでにDOSベースで動いているものがあるのだったら，わざわざWindowsを使う意味はないと言ってもよい．ただし，このようなドライバもだんだん増えてきたので，いちがいにダメということではなくなってきている．
　また，Windows95，WindowsNTともにOS自体の信頼性やVisual Basicの信頼性の点で，まだ信用できない部分が多い．どこかでメモリがリークしていたり，リソースが減り続けるといったことがありがちだ．24時間，365日稼動といったシステムにはリスクが高すぎる．せめて週に一度くらいはリブートするなどの処理が必要である．それが可能な業務かも見極める必要がある．
　インターネットのサーバーとするといったことであれば，これはもうWindowsは危険すぎる．セキュリティの面でも柔軟性の面でも，今のWindowsNTはまだまだだ．イントラネットならまだしも，インターネットのサーバーとして使うのは危険だ．

Windows95かWindows NTか
　Windows95とWindws NTのどちらを選択するかも重要な問題だ．はっきり言うと，Windows95は安物OSである．開発にも運用にも，Windows NTを使うべきである．もちろん，Microsoftの戦略もWindows NTにシフトしていることは明らかだ．
　Windows95では，従来の16bit Windowsとの互換を取るために，システムは二重構造になっており，16bit APIと32bit APIが混在している．32bit APIをコールしても，実際には16bitに変換され，16bit APIが呼び出されるものが多い．もちろん，16bit APIは32bit APIよりパフォーマンスが悪くなる．また，16bit to 32bitの変換をするためにオーバーヘッドが生じる．
　たとえば，DOSプロンプトでWindowsのSystemディレクトリで「dir user*.*」「dir gdi*.*」としてみよう．次のようになるだろう．

95/10/03 00:00 552,352 USER.EXE
95/10/03 00:00 45,568 USER32.DLL
95/10/03 00:00 556,368 GDI.EXE
95/10/03 00:00 136,704 GDI32.DLL

　この*.EXEは16bit APIが入っているものであり，*32.DLLは32bitのAPIが入っているものだ．KERNELこそ全部32bitだが，他のサイズからも，Windows95は32bit OSではなく，むしろ16bit OSであることが分かるだろう．
　Windows 95からはWindows NT同様にプリエンプティブなマルチタスクとなっている．つまり，ひとつのウィンドウの処理中であっても，タイムスライスでタスクが切り替わるようになっている．ならばパフォーマンスがアップしているかといえば，実はそうではない．16bit APIは，ノンプリエンプティブだった過去のWindows同様，再入ができない設計である．したがって，ある16bit APIが呼び出されているときにタスクスイッチングされて他のプロセスから同じAPIが呼ばれても，そのときにはWin16MuTexと呼ばれるセマフォが動作し，実際には呼び出されずに次のタスクスイッチングまでチャンスが回ってこなくなってしまう．したがって，ケースによっては非常にタスクスイッチングに問題が生じることになる．
　この差は，特にマルチスレッドプログラミングをしたときに歴然とする．せっかくのマルチスレッドも，安物OSでは台なしである．いくらがんばって高速に動作するようにプログラミングしても，Visual Basicがマルチスレッドに対応しても，Windows 95ではその真価を発揮できないのである．
　なるべくWindows NTを使うようにすべきである．少なくとも，開発者がWindows 95をメインで使っているというようなことは避けなければならない．

ドライバはあるか？
　OSはWindows NTにしたいということになっても，実際にはそうはできないケースがある．たとえばプリンタやスキャナなどのデバイスドライバがないことがあるのだ．また，Windows NT用は機能が劣るということもある．
　この状況は，MicrosoftがWindows NTを積極的に売ろうとしているために，徐々に改善されてきてはいるが，十分に調査をしておく必要がある．
　というのも，ドライバのテストが十分にされていないことがあるからだ．信頼性の高いWindows NTの方がドライバの信頼性は低いこともあるのだ．

Visual Basicでよいのか
　Visual Basic Magazineにこんなことを書くのもヘンな話かもしれないが，本当にVisual Basicを使うべきなのかも吟味する必要がある．
　Visual Basicのメリットは，ウィンドウのデザインやちょっとした制御をカンタンに書くことができることだ．しかし，細かいことは苦手である．Windows APIを駆使しなければならないようなプログラムのときには，Visual BasicよりもVisualC++を使った方がよいケースも珍しくない．Visual Basicを使ったばかりに，かえって大変になってしまうこともあるのだ．また，Visual Basicは高度にカプセル化されたブラックボックスである．Cで直にWindows APIを呼ぶならば，うまく動かない原因の大半はプログラマの責任になるだろう．しかし，Visual Basicはカプセル化された中身で何をされているのか分からない．バグがあったとしても，動作が妙だったとしても，プログラマはどうすることもできないことがある．そういったブラックボックスの不安は，常につきまとうことになる．
　しかし，うまく動かないならばそこは使わないようにすればよいという割り切りさえできれば，こんな便利なツールはないというのがVisual Basicである．
　だが，それでも問題になるのは，動作保証の問題である．たとえば，Visual Basic 5.0の動作保証は，Windows 95，Windows NT 4.0 SP2以降，Windows NT 3.51 SP5以降ということになっている．また，5.0はちょっと怖いから4.0でということなると，これはWindows NT 4.0では動作保証の対象外である．さらに，16bit Visual Basicとなると，話はややこしくなってくる．現実的には，Visual Basic 4.0 16bit版やVisual Basic 2.0はWindows NTでの動作保証がされていないから，使うべきではない．Visual Basic 3.0のβ版とも言えるVisual Basic 2.0や，一応互換のために作ったVisual Basic 4.0 16bit版は，バグが多い上に今後のサポートも期待できない．今からこれらを使うことは考えない方がよい．また，Visual Basic 4.0とOffice 95あるいは，Visual Basic 5.0とOffice 97は共通のDLLを使うが，Visual Basic 4.0とOffice 97あるいはVisual Basic 5.0とOffice95の組み合わせでは異常が発生する．また，とりあえず動いていても，そういった環境でセットアッププログラムを作ると，再配布モジュールに本来配布できないものが入るといった問題もありうる．
　このようなことも知った上で，Visual Basicを使うか，Visual Basicのバージョンはどれにすべきかを考える必要がある．

仕様を満足することができるかの検証
　OSおよび開発ツールが決定したら，概要仕様を決定し，さらに内部仕様を検討していく．このときに重要なのは，要求される仕様を満足するプログラムを作ることができるかの検討である．つまり，Windowsそのものの動作やVisual Basicなどのツールでどのようなことが実現可能で，どのようなことが難しくて，さらには実現不可能なものはないかといったことを調査することだ．
　このためには，Windows自体あるいはVisual Basicなどについての十分なノウハウが必要である．ノウハウの獲得方法については後ほど述べることとして，ひとつひとつの問題点を明らかにし，最小レベルで実現するサンプルプログラムを作ってテストすることが重要である．こういった積み重ねをした上で，はじめて実現可能だと判断してその先に進むべきだ．きっとなんとかなるでは，後で泣きを見ることになる．もし，うまい方法がみつからないときには，後ほど述べるように外部から情報を得るのもひとつの方法である．
　内部仕様の検討をしていくと，ほぼ100%Visual Basicだけではできないことが出てくる．このようなときには，Windows APIを使ったり，カスタムコントロール（ActiveXコントロール）を使って解決することを考える．

APIコールで実現するか？
　APIはWindowsの基礎となっている関数であるから，これでほぼ何でも実現できる．特にVisual Basic 5.0からはAddressOf，VarPtr，ObjPtrなどが使えるようになったため，以前にもまして，Visual Basicで何でもできるような気分になる．
　たしかに，Visual Basicでできる範囲は増えた．しかし，だからと言ってVisual Basicが万能であると思ってはいけない．仮にどんどんAPIを使っていこうということにしても，どんなAPIがあってどんなときに使えばよいか分からなければ話にならない．特に普段からVisual Basicしか使っていないようだと，APIのことやWindowsそのものの仕組みが分かっていないケースが大半である．そうした意味でも，先に述べたようにCでの開発を経験すべきだ．
　しかし，APIセットはMicrosoftから新しいSPやDKが公開される度に増えるような状態であり，一度覚えておけばOKというようなものではない．新しいものが発表されたら，どのような機能があり，ぞのようなAPIが実装されたかを確認しておく必要がある．そこまではなかなかできないにしても，とにかく一通りどういった系統のAPIセットがあり，どのようなことができるのかを見ておく必要がある．最初はVisualC++2.0附属の日本語のもので概要をつかみ，最新のものはVisual Studioなどで英語の最新版のもので確認するといったことでもよいだろう．とにかく，APIにどんなものがあるかを知っておこう．
　次に注意しなくてはならないのは，凝りすぎないことだ．APIを使うと確かに何でもできるような気になり，どんどんAPIを使うことになる．しかし度を越すと，これなら最初からC/C++で書いた方がよかったということになりかねない．それでは本末転倒である．また，よくよく調べてみると，実はVisual Basicでできることだったりすると，かえって手間ばかり増えたことになってしまう．最近のVisual Basicはバージョンアップごとに機能が増えているので，Visual Basic自体の機能についても十分に知っておく必要がある．
　さらに，APIを使えば何でも速くなりそうな気がするが，実際はそうでもない．APIをコールするときには，Visual Basicの言語仕様と合わせるための処理が介在し，厳密にはオーバーヘッドが生じる．これが意外に大きいので，高速な処理を必要とする部分で何回もAPIコールをしていると，思ったほどパフォーマンスが上がらず，Visual Basicが最初から持っている似たような機能を使った方が速くなるというケースもある．APIは数個で実現できる程度のものだけを使うべきであり，あまりにも面倒になってきたら部品化を考えるべきである．つまり，そのような機能のActiveXコントロールを使うとか，作るということだ．自分で作るときには，ActiveXサーバーやActiveXコントロールとして部品化して，後から再利用できるようにすることを考えて設計すべきだろう．

図4：標準のコントロール

カスタムコントロールやDLLを使うか
　Visual BasicにはさまざまなActiveXコントロール（OCX）が附属してくる．しかし，それらの大半はオマケである．これには2種類あり，Microsoftのコピーライトがあるものと，サードパーティ製のものがある．プロパティウィンドウで「バージョン情報」をクリックしてみれば，ダイアログが出てくるので分かるだろう．Microsoft製のオマケは，とりあえず作ってみましたというものである．サードパーティ製のオマケは，実際には製品があるのだがそのサブセットがバンドルされているものである．サブセットだから，本当に必要なところが入っていなかったり，きちんとサポートされないことがある．
　よく，「サードパーティ製品を使わないでMicrosoftの純正品だけで開発する」といった方針を立てるところがあるが，これはとんだ的外れな方針だ．そもそもオマケが純正品だと思うことが間違いである．このようなものを，仕事で使ってはいけない．もっときちんとした機能があるものを使うべきである．最近ではこのようなツールも増えてきたので，選択肢も広がってきている．ただし，Visual Basic 5.0に対応したものはまだ少ないので，きちんと対応するバージョンについて確認する必要がある．
　このようなものは，市販されているものの他に，シェアウェアやフリーソフトもある．もちろん，規模と用途によっては自分で作ったり，外部に作成を依頼するのも手だ．もしかしたら，お金をかけないために標準のものだけという発想になるのかもしれないが，これはかえってお金がかかることになる．バグが見つかって仕事が停まり，その回避策を探す．ことによっては使えないことが判明して別の方法を取る．そのために多くの時間と労力がかかることになる．
　考えて欲しい．市販品と同じコントロールを作ったらどれくらいのコストがかかるかを．プログラマに支払っている1ヶ月の給料の半額以下で，数人月分のコストを節約できるかもしれないのだ．どっちが得かよく考えてみよう．

印刷などのツールを併用するか
　Visual Basicは高機能になってきたが，それでもまだまだ弱い部分がある．たとえば印刷である．Printerオブジェクトは代々のVisual Basicの弱い部分である．元々があまり使いやすい仕様ではない．バージョンが上がるごとに機能アップはしているが，バグも多い．また，データベース系の印刷には，バンドルされているCrystal Reportsを使えばよいということもあるのかもしれない．しかし，現実的には，Crystal Reportsは「おまけ」であり，機能的にも満足できるものではないし，バグがあってもMicrosoftがサポートしてくれるわけでもない．つまり，Visual BasicにバンドルされているActiveXコントロールなどと同じであり，「おまけ」を見てよいと思ったら本物を別に買ってくださいというものだ．
　ところが，Visual Basic4.0のときにバンドルされているもののバージョンと，市販品のバージョンに整合性が取れず，そのまま製品版をインストールするとDLLがうまく書き変わらないために正常に動作しないということもあった．
　また，Crystal Reportsの製品版とて万全なものではない．結局のところ，印刷関係はVisual Basicの標準機能あるいはバンドルされているCrystal Reportsではダメで，用途によって他のツールを考えた方がよいだろう．

ミドルウェアは何を使うべきか
　RDBMSへのアクセスが必要であれば，ミドルウェアの選択は重要である．
　Visual Basic 4.0以降には，RDOと呼ばれる機能が追加されている．これは，C/S型RDBMSへアクセスする汎用なオブジェクトであるが，その下の階層ではODBCが使われる．ODBCはオープンとは言っているが，現実的にはMicrosoftがしょっちゅう仕様を変えるものであり，他のベンダーがすばやく追随していけてはいない．たとえば，Oracleを使おうというのであれば，Oracle提供のODBCドライバはRDOの機能のほんの一部分しか使えない．これは，ODBCの新しいレベルについていけないからである．これについてOracle筋からの流れてくる話を聞くと，「OracleはODBCは一応対応すると言いたいからやってはいるが，こんなオープンでないものに真面目に対応する気はない」ということらしい．
　InterSolvのODBCドライバは，RDOの機能の一部を使うことはできたが，パラメータクエリーなどは動かないし，ライセンス料がかかるから，この選択は現実的ではない．
　最近のMicrosoft提供のOracleドライバでは機能的には満足できるものだという話も聞くが，そもそもがレイヤーが増えるODBCはパフォーマンスが悪くなりがちである．
　そこで，OracleであればOracle Objects for OLE(OO4O)を使うとか，SQL ServerであればRDOでよいといった判断になる．OO4OはOracleを使うという前提ならば非常に自由度が高いし，構文もDAOライクなものなので馴染みやすい．ただし，いくつかクセを知っておかないとDAO以下にパフォーマンスが下がるので注意が必要だ．
　ここで間違ってもやってはいけないのは，「Accessがカンタンそうだしプロトタイプが作りやすいからAccessでいこう」とか，同じような理由で「DAOがカンタンだ」といった判断である．Accessは，パーソナル向けのデータベースツールであり，C/S向けのものではない．たしかにできないことはないが，大量のデータを扱い始めると破綻してしまう．
　そのときどきに応じて，最適なミドルウェアを選択すべきである．もっとも，こうしたミドルウェアはISAM風にアクセスできるというのが売りである．しかし，本来C/SではRDBMSにSQL文を投げてやり，主要な処理はRDBMSにやらせてやるというものであり，いちいち必要な大量データをクライアントに持ってきて処理するようなISAM的なやり方はパフォーマンスを落とすだけだ．なるべくSQL文だけで勝負するという方針も，ここで確認しておくべきだろう．

怪しい技術ではないか
　Visual Basicには，いつも新しい技術が投入されている．Visual Basic 5.0であれば，ActiveXまわりの技術などがそうだ．
　確かに，MicrosoftはWindowsというOSを供給しているベンダーだ．MicrosoftがActiveXだといえば，これからはそうなるに違いないと思うのは，PCのソフトウェアを作ってきたベンダーにとっては当然かもしれない．しかし，考えてみてほしい．Microsoftの提唱した技術がすべて生き残っているかを．たとえば，WinGは2.0で消失し，DirectXへ移行した．そのDirectXとて，次々とバージョンアップし，しかも互換性が乏しく，せっかく買ったゲームが軒並み動かなくなるといったことがあった．それに付き合わされたベンダーはたまったものではない．私は最初からこのあたりの技術は怪しいという臭いがしたので，一切使ってみようとも思わなかった．
　したがって，ActiveXだって怪しいものなのだ．私が思うに，Visual Basicで再利用するコンポーネントとしてのActiveXは生き残るだろうが，インターネット技術としては怪しい．
　そもそも，MicrosoftはPCのソフトウェアベンダーであり，UNIXからスタートしているインターネットについてはまったくのシロウトである．しかも，PCでは好き勝手してきた王様だから，仁義もクソもない．結果として，今までインターネットを育ててきた人々から白い目で見られることになってしまった．しかし，それをMicrosoftは対等な立場だと勘違いして土足でさらに踏み込もうとしている．そのために市場は混乱しているのだ．こんなことがいつまで続くか分からないが，Microsoftがシロウトである限りはこの混乱は続くのだろう．だから，私はこういったMicrosoftの不得意な分野には関与しないことにしている．DirectXと同じである．
　新しいシステムの提案には，こうしたMicrosoftの提唱する新しい技術を使うというのが開発会社としての売りにもなるだろうが，それは堅実なことではない．結果的には，ユーザーにも迷惑をかけることにもなりかねないし，あなたの会社の信用も落としかねない．君子危うきに近寄らずである．このような怪しい技術でないかを見極める必要がある．もちろん，オモチャを作るならそれでもよい．新しい技術は楽しいし，オモチャは楽しければよしで，壊れたってかまわないのだ．しかし，実運用されるようなシステムならば，なるべく枯れた技術を使って安定したシステムを作ることこそ重要なのだ．

ユーザーインターフェイスをどうするか
　先に述べたように，Visual Basicを知る前に，Windowsを知るべきだというのが私の持論である．その第一歩が，『Windowsインターフェイスデザインガイド』である．ここに書いてあるような例を参考に，ユーザーインターフェイスをどうすべきか検討するべきだ．
「今までDOSや他のOSでこういうUIだったから，Windows版でもこうしてくれ」というユーザーからの要望を飲んではいけない．これは自殺行為である．なぜならば，先に述べた通りWindowsのインターフェイスは綱渡り的なところがあり，1か所を崩してしまうと他の整合性がとれなくなってしまうのだ．その整合性を取るためにさらに姑息な手を使っていくと，さらにその先で… と際限なくなってしまう．それも本当に重要な機能ではなく，UIだけのためにである．最終的には，目茶苦茶にパフォーマンスが悪いものができ上がってユーザーから苦情を言われるのがオチである．
「Microsoftの資料でWindowsでのインターフェイスはこう規定されています．これが標準です．Microsoftの他の製品でもこうなっていますよね．ですからこのアプリケーションだけ違うインターフェイスにすると不整合が起きるのです．ユーザーも混乱します．プログラムでも必ずよくないことが起きますからお勧めいたしません．もし，そのようなインターフェイスにするというならば，工数は2倍になります」くらい言って，ユーザーに納得してもらうべきである．それがお互いの幸福というものである．
　次に，やってはいけない例をいくつか述べよう．

たくさんのコントロールを使うデザイン
　よく聞くのが，「Visual Basicではいくつまでコントロールを貼り付けられますか?」とか「いくつまでフォームを使えますか?」といった質問である．杓子定規に答えると，マニュアルに「Visual Basicの仕様，制限事項，およびファイル形式」という項目があるので読んでくださいということになる．すると，「そうですか，コントロール名はひとつのフォームで254個までだけれど，コントロール配列を使えばインデックスが32767までだから，200個くらいは平気ですね」と言われてしまう．これは大きな間違いだ．いったい，ひとつのフォームにそんなにコントロールを貼り付けて操作がしやすくなると思っているのだろうか？ コントロールは必要最低限にすべきである．そうでないとロードにも時間がかかるし，メインテンナンスも大変になる．
　そもそも，部品を組み合わせて作っていくという考え方の中には，構造化という概念が含まれており，処理をひとまとめに分けていこうという考え方をするものだ．
　Windowsのデザインでもまったく同じである．ウィンドウは最低限のコントロールがあり，それ以上に必要なものはダイアログで指定していくべきである．また，テキストボックスを100個使うくらいなら，グリッド系のコントロールを1個使った方がプログラミングがカンタンになる．メニューから複数のダイアログを出すのが面倒だとというような話ならば，タブコントロールを使って切り替えると言う手もある．
　このように，適材適所に割り振ることで，ひとつのフォームにたくさんのコントロールを貼らなくて済むようになるのである．

[Enter]キーでのフィールドの移動
　MS-DOSやオフコンでよくあったのが，Enterキーで次のフィールドへ進むというUIである．しかし，Windowsではキーで進むことになっている．確かに，キーで進むようにすることはできる．カンタンな方法としては，SendMessageでvbTabを自分自身に送ることだ．ところが，これだとIMEModeが正常に動作ない(VB5SP3でも確認済み)．
　そもそも，テキストボックスにフォーカスがあったときにキーが押されたときには，デフォルトのコマンドボタンが押されることになっている．これがWindowsの標準インターフェイスだ．その方が，効率よくオペレーションできるからである．しかし，上記のようなUIにしたとたん，このようなことができなくなってしまう．こうした不具合や不整合を補足しようとしていくたびに新たな問題が生じるのである．

ファンクションキーを使った処理
　これもMS-DOSやオフコンであったUIだが，ファンクションキーに特定の処理をやらせるというのがある．もちろんWindowsでこれができないことはない．しかし，Helpはキー， +キーはアプリケーション終了などといったように，あらかじめ決まっているものがある．これを無視しようというのは，やはりUIの破壊に通じる．
　また，その他のキーに割り当てるときにも，FormのKeyPreviewをTrueにして，KeyDownイベントなどで処理をするというのはダメだ．Windowsでは，メニューに機能を割り当て，そのショートカットとしてファンクションキーを割り当てるようになっているのだ．そもそも，画面上には何もガイドがないのに，キーボードに「実行」と書かれた紙を貼るといった発想自体がWindowsらしくないのである．
　 初めて使ってもメニューから機能がたどれるのがWindowsのUIなのである．ただし，これは完璧なものではない．まだまだ改良され続けている．しかしそのリファレンスはOSを作るMicrosoftが決めている．MicrosoftのOSを使う以上は，これを守らないと痛い思いをするのだ．よくVisual Basicにバグが多いと言われるが，その半分くらいは標準的なインターフェイスを無視した使い方をしたときに発生している．これは仕様と言われてもしかたないことなのだ．「標準的な使い方をしない」= 「リスクが増える」と考えて欲しい．

モジュールをどう分割するか
　UIにも関係するが，あまりにもたくさんのフォームを使うのも考えものである．適切なブロックに分けて別プロジェクトとして，うまくデータを分けていくように考えるべきである．

セミナー，コンサルティング
　設計や仕様を決定する段階では，今まで述べてきたような準備や注意が必要である．言葉で書くとカンタンだが（それでもここまで書き進むにはかなりの時間がかかったが），現実にこれを実践しようとすれば，結構たいへんだ．しかも，今までCでの開発経験がないままに突入しているとなると，社内ですべてやってしまおうということでは，いつまでたっても進まないということになりがちだ．そんな悠長なことはやっていられないということになってしまう．
　こんなときには，外部の力を借りるのもひとつの手である．たとえば，セミナーを受講するのはよい選択だ．ただし，これもMicrosoftなどベンダーの主催するような宣伝半分のものではなく，実戦的なノウハウが得られるような講師を使っているセミナー専門の会社のものがお薦めだ．ただし，実習セミナーを受ければ昨日までCOBOLプログラマだった人がVisual BasicでC/Sシステムを開発できるというほど甘くはない．セミナーの受講対象をよく読み，受講者のレベルに合わせて複数のセミナーを順に受けていくことや，よい講師を選ぶことが肝要である．
　また，コンサルティングを依頼するというのもよい手だ．私の会社でもコンサルティングをしているが，仕様レベルから話し合い，開発スタッフへのセミナーをし，実際の開発に入ってからもQ＆Aをしていくというスタイルを取ることが多い．場合によってはサンプルプログラムレベルではなく，システムの一部を作ることもある．
　このように，すべて自社内でなんとかしようと考えず，アウトソーシングするのも手である．契約次第では，システムのソースだけでなく，専用のActiveXコントロールも作ってもらい，そのソースも手に入り，将来的には自社のノウハウとしてゆくことも可能である．こうしたことには確かに金がかかるが，それでも社内だけでなんとかしようとして半年無駄にするよりは，はるかに効率的である．また，ある程度のノウハウをもってはいるが，ちょっとしたヒントが欲しいということであれば，PCDNのNews GroupやMailing Listのような会議室に質問を書くのもよい手だ．これについては，後ほど述べることにしよう．

コーディングとデバッグ

　今まで述べてきたようなことを実践していれば，いざ実際のコーディングに入ってきたとき，結構コトはスムーズに進むはずだ．しかし，予期しない問題が出ることもある．あるいは，プログラマのスキルなどにも影響される．社内でのコーディング規約などの問題もあるだろう．
　次に注意点をまとめてみた．

構造化を念頭におく
　Visual Basicは構造化制御構文を備えている．これはDOSのQuickBASICの時代からのものだ．しかし，こういった構造化といったパラダイムに慣れていないと，イベントプロシージャに大量のコードを書き，さらにはあちこちに似たようなコードがあるといったことになりがちである．まとめられる処理は別プロシージャとして汎用に呼び出せるような設計にすべきである．もちろん，ローカル変数をうまく使って，グローバルやモジュールレベルの変数を必要最小限にするといったことも重要だ．

再利用できる部品化を考える
　構造化の先にあるのがオブジェクト指向である．Visual Basicは厳密にはオブジェクト指向言語とは呼べないが，それでもオブジェクト指向の要素はかなり持っている．その中でも重要なのはコンポーネント化して再利用できる部品を作る方法だ．これはもちろん設計段階に考えなくてはならないことはあるが，実際にコーディングしていって見えてくる部分もある．こんなときには，先に述べた構造化を考え，もっと推し進めてコンポーネントとして独立させるのも，後々メインテンナンスをよくする方法である．

イベントのタイミングとデバッグ
　Visual Basicはイベントドリブンで動いている．LostFocusやGetFocusイベントでUIに関係するようなコード，たとえばMsgBoxだとかオプションボタンなどのプロパティを変更するなどを実行したり，重い処理を入れると正常に動かないことがある．このようなフォーカスがらみのイベントに書くコードは注意しなくてはならない．また，イベントであるプロパティを変更したために，予期せぬイベントが起きるといったことがある．このために不整合が起きることもある．これを調べるには，ブレークポイントを使い，コールヒストリーを出してみるという手がある．しかし，イベントによっては，停止させたときには発生しないというケースもあるから注意が必要だ．

クリーンな開発環境
　開発環境には余計なソフトウェアやドライバをなるべく入れないようにしよう．これは問題の解決を遅らせる原因になる．

運用環境と同じ環境でテストする
　開発環境と運用環境が同じとは限らない．あきらかにOSやSPのレベルが違うときには，運用環境と同じテスト環境を用意すべきである．そのためにも，一人につき2台以上のマシンは必須である．

最新のSP／最新のドライバ
　開発環境で問題が出たときには，最新のSPがインストールされているかを確認しよう．OS，Visual BasicともにSPによって大幅に動きが変わるので注意が必要だ．ただし，SPによって改悪される部分もあるから，このあたりも注意しよう．
　また，ビデオカードやプリンタのドライバは，常に最新のものを使うようにしよう．古いものは往々にしてバグがあるケースが多い．

インストール
　Visual BasicにはSetupWizardが附属している．このプログラム自体がVisual Basicで作られているので，カスタマイズも比較的容易である．ただしある程度コードを解析をする必要がある．しかし，これは用途によってはあまり向いていないものもある．特に複数のEXEをインストールしたり，ドキュメントの追加や，レジストリの登録などをするといったときには面倒くさい．このようなときには，サードパーティ製のインストーラを使うのも手である．これらは値段なりの機能を持っている．

　次に，実運用以降のシナリオを考えよう．

運用／メインテンナンス／バージョンアップ

　実運用に入り，安定稼働するまえでは，開発のときと同じスタンスで考える必要がある．しかし，その後安定してくると，メインテンナンスやバージョンアップなどの要望に答えなくてはならない．
　次に，これらについて述べよう．

きちんと部品化されていればOK
　メインテンナンス時に重要なのは，バグの位置の特定である．これについては後ほど「一般的な問題解決の手順」として述べることにする．
　しかし，基本的には部品化や構造化がきちんとされていれば，修正箇所は最小限で済ませることができる．あらかじめコンポーネントを意識した設計が重要である．

16bitから32bitへの移行
　これについては，別項で真崎氏が書いているので，詳しくはそちらをご覧いただきたい．現実的には，Visual Basic自体に新しい機能も追加されているし，32bit APIの仕様は16bit APIとかけ離れたものになっているものも多いので，ほとんど作り直しと考えるのが正しい．また，いまさらVB2からVB4 16bit版への移行は意味がない．このバージョンはバグが多くて問題だらけだ．そういう意味では，VB3の英語版は，レジストリに影響されないものなので，いまだに便利なツールとして使うことができる．

ActiveXコントロールの対応
　Visual Basic 4.0からVisual Basic 5.0へ移行するにあたっては，ActiveXコントロールの仕様が大幅に変更されている．このため，Visual Basic 5.0に対応しているかを明確に調べる必要がある．

DLLの対応
　この点もすでに設計のところで述べたとおり，バージョンの整合性に注意が必要だ．

ClassIDに注意
　ActiveXサーバーやActiveXコントロールをバージョンアップしたときには，ClassIDごと変わってしまうことがある．基本的には，プロジェクトのプロパティで「バイナリ互換」にしておけば，ClassIDは変わらない．しかし，メンバーとなるプロパティやメソッド，イベントなどを追加・削除したりすると，ClassIDが変わってしまう．またMsgBoxを使ったときにも変わる．
　いずれにしても，安全のためにはこのようなコンポーネントは再インストールする必要があるだろう．

一般的な問題解決の手順

　Visual Basicで開発する上での問題点について述べてきたが，ひとつひとつの細かい問題は数限りがない．事前に綿密な調査をしたところで，問題がまったく出ないというケースはまれだ．
　ここでは，そういった問題を解決するための一般的な手順を述べることにしよう．

目的を明確にする
　まず，何をやりたいのかを明確にしよう．それもなるべく単純化した方がよい．そして，その目的は，インターフェイス規約に合っているか，Visual Basicでやること自体にムリはなかったのかも確認しておこう．
　また，目的を実現するための手法がどこかに書いていないかを調べよう．Visual Basicなどのドキュメント，Readme，BooksOnline，SDK，MSDN，一般の書籍，さらにはPCDN のFAQやMicrosoftサイトのKBなども見てみよう．

問題のある場所を特定するには，必要最低限なコードを作る
　目的通りにならないならば，どうなることが問題なのかを明確にしよう．
　そして，問題のある場所を特定することを考えよう．Windowsアプリケーションで起きる問題といっても，ハードウェア，OS，Visual Basic，ActiveXコントロール，DLL，他のツール，コーディングなど，実に多様な要素がある．これらのうち，どこに問題があるかを絞り込んでいくのである．
　まず，最初にやらなくてはならないのは，「現象が再現する最低限のプログラム」を作ることだ．いろいろな要素を削っていき，極力小さなプログラムで再現するようにする．このとき再現するときの他の操作やプログラムの動作条件も重要だ．そこで，なるべくクリーンな環境でテストをすることが望ましい．
　これには，次のようなテストをする．

・他のアプリケーションなどは一切動かさない
・OS起動後すぐに動作を確認する
・OSのバージョンとSP状況，Visual BasicのSP状況の違いを確認する
・同じOSで同じSP状況の他のマシンで確認する
・他のOSやSP状況の違うマシンで確認する
・最新のドライバで確認する
・プリンタならば，他のプリンタで確認する
・描画でリソースが減るような問題ならば，ビデオドライバを疑ってみる．標準的なVGAドライバで確認する

　これらの過程で，多少コードを書き換えてみるのも重要だ．先に述べたようなさまざまな障害を起こしやすいコードになっていないか，あるいは同じことを別の手法で実現できないかといったことである．たとえば，Cで同じことをするコードを書いてみることも必要になるかもしれない．

問題解決の実例
　私は以前にVisual Basic 2.0でCircle文でごく小さい円が描けないバグを発見したが，Windows APIレベルで解決できないかと，Arc関数をためしたことがある．その結果，Windows API自体にバグがあったことが判明した．そのため，別のAPIを使って擬似的に円を描くプログラムを作って解決したことがあった．
　印刷時に位置がおかしいといった問題があったが，実は別のプリンタでは正常に動作し，ドライバの問題であったことが判明した．
　リソースやメモリが減るというバグを発見したが，実はビデオドライバの問題であった．WindowsのSPで解決したこともあった．このようなSPの状況は，Microsoftのサイトにバグフィックスの一覧があるので，確認しておこう．

　とにかくポイントは，「現象が再現する必要最低限のコード」である．ここまで絞り込むことができれば，問題点も洗い出しやすいし，とりあえずはそのようなコードは使わないで別の方法で実現して回避するということもできるのである．
　バグはたしかにあるが，バグだと騒いでMicrosoftに文句を言ったところで，すぐに直してくれるようなものではない．回避策があるならば，回避すればよいだけの話である．

情報の収集

　このようにして問題を特定しようと努力しても，回避策が見つからないときや，ある程度絞り込んでも本当の原因が分からないケースも少なくない．
　このようなときには，自分一人で悩むより，外部から情報を得た方が効率的だ．こういった情報としては，Microsoftのサポート，PCDNのようなNewsGroup/MailingListなどの会議室がある．また，コンサルティングに依頼するケースも考えられる．

マナーを守ろう
　ただし，それぞれ最低限のマナーを守る必要がある．たとえば，Microsoftのサポートには無料と有料がある．無料の電話は繋がりにくいといった問題もあるが，有料にしても答えるのは同じ人間である．「おまえのところのソフトがおかしい」といきなりどなり込んだのでは，相手だって心証を悪くするだろう．怒りたい気持ちは分かるが，怒るのが目的ではなく，問題を解決するのが目的のハズだ．あまりにも失礼な言い方をすれば，相手はだって腹が立つ．当然のことだ．問題解決の手伝いをしたいと思っていても，そういう気もなくなるというものだ．だいたい，あなたのコーディングや環境がおかしい可能性だってあるのだ．まずは，ジェントルにいこうではないか．
　また，仮にバグであることをベンダーが認めたとしても，リテール商品である以上，そうそうバグフィックス版がスグに出ることは望めない．「バグだからスグに直せ」と迫るのではなく，回避策があるならそれを使うことで納得すべきである．もっとも，最近ではインターネットを通じて修正版が素早く配布されるようになってきており，このあたりの問題は少しずつよい方向に行なっている．

適材適所のところへ聞こう
　Microsoftに限らず，ベンダーのサポートでは他社のソフトウェアと組み合わせたときにはサポートしないのが普通だ．これをやり出すと，あらゆるActiveXコントロールやミドルウェア，ツールなどの組み合わせをためしてゆかなくてはならないので，現実的に不可能だからだ． こういったもののときには，そのソフトウェアの供給元に聞いた方がよいだろう．
　また，NG/MLなどでは，実際に同じような問題を体験し，克服してきた人たちが集まっている．複数ベンダーに関わるような問題や，どれを使ったよいかといった質問は，このような場所の方がよいだろう．
　ただし，会議室やNGにはそれぞれ趣旨があるので，最適なところへ投稿しよう．複数のNGに同じ記事を投稿するのはよくない．

やることはやってから質問しよう
　さて，そこから先は，サポートだろうが会議室だろうが同じことだ．
　ここで，先ほど述べたような一般的な問題解決の手順を踏まないで，おおざっぱな質問をするのもよくない．実際のコードがないと答えようがないケースがほとんどだからだ．いきなり30KBもあるようなコードを送りつけられても，どこが悪いかわからないだろう．最低限，次のようなことは明記すべきである．

・環境( OS, SP, VB，ActiveXコントロール，DLL，ドライバ，ミドルウェア)
・やりたいこと
・やってみたコード(現象が再現する最低限のコード)
・問題点
・問題解決のためにためしてみたこと

　つまり，うまくいかないときにも，すぐに人に聞くのではなく，まずは自分でできることはやっておくべきであるということだ．そうでないと，誰も答えようがないのだ．いきおい，回答は不親切にならざるを得ない．それに対して不親切だなどと怒るのは筋違いというのものである．

過去記事やFAQを調べておこう
PCDNのようにあらかじめFAQがあったり，過去記事を検索できるところであれば，適切なキーワードを指定して，情報がないかをあらかじめ調べておくことも重要である．あなたに取って初めてのことでも，週に何度も同じ質問がされるようなケースもあるのだ．

情報は共有してこそ意味がある
　会議室やNG, MLはあなただけのためにあるのではない．参加している全員が情報を共有するためのものだ．分かりそうな人に個人的に直接Mailで質問したり，あるいは回答をしたりするのでは，参加者のためにならない．そもそも，そういったことを業務としてやっているわけではない，善意の人に対して，名指しで質問することはルール違反である．もし，その人に相談してほしいならば，会社を通してコンサルティングを依頼するというのが正しいやり方のハズだ．
　また，アドバイスを受けるだけで，あるいは「ありがとうございました」という表面的な挨拶で終わってしまうケースがある．これもよくない．そのアドバイスを受けてどういうことをしたらうまく行なったとか，問題点は実はこれだったとかいう報告をしなければ，情報共有の意味がないのだ．

図5：PCDNを各種情報のポインタ／共有の場として活用

開発者としての誇りを持とう
　PCDNでも，回答がぶっきらぼうだとか，不親切だと文句を言う人がたまにいる．それも，NG/MLに書くのではなく，主宰している私にMailを送ってきたりする．こういうのはルール違反だ．そもそも言いたいことがあれば，公開の場ですべきであり，このような小学生の優等生が先生にチクるようなことをしてはいけない．
　また，一見不親切に見えるような回答こそ，必要最低限の答えがあるケースが多い．たしかに初心者にとっては不親切なのかもしれないが，少なくとも会社のメールアドレスで質問を書く以上は，会社の看板をしょっているのである．開発者として最低限すべきことはやっておくべきであろう．
「○○株式会社○○開発第○部」などというSignatureをつけていながら，Windows APIの質問をし，これを使えばよいという回答を得ると，「Windows APIの資料がないのでパラメータを教えてください．できればVisual Basicで動くコードもおねがいします」などと書く人がいる．これは，「○○株式会社はMSDNにも入っていないし，ちゃんとした開発環境を与えていない情けない会社です」と言っているようなものである．既に述べてきたような環境を整備した上で，こういったNGやMLに参加すべきである．
　また，会社の仕事としてお金をもらってやっているのに，他人にはお金を払わないで自分の仕事をやってもらおうなどというのは，あまりにも虫のよい話だということに気づいていただきたい．そもそも，そんなことを聞く暇があったら，自分で試行錯誤してやってみるべきなのだ．そうしないと，いつまで経っても他人に依存するばかりになってしまう．悪い意味でのサラリーマンとしてならそれでもよいだろうが，向上心があるならばそれではいけない．
　たとえば，会社が買ってくれなくてもMSDNやPCDNのライブラリCD-ROM，資料，さらにはマシンのメモリなどは自前で揃えているという人も少なくない．さすがにそこまでやるべきだと言えないが，会社に対して必要なことにお金を出してもらえるような努力はすべきだろう．
　基本的には，NGやMLは助け合いの場であり，Give＆Takeが前提である．その精神を忘れないでいただきたい．

システマチックな開発スタイルを作ろう

　Visual Basicでの開発する上での問題点やその解決法について述べてきたが，これらは，Visual Basicに限定するものではなく，今のWindows用ソフトウェア全般について言える内容も多いだろう．
　ここまで書いてきて，私を含め，この業界はまだまだ職人技の世界になっているような気がする．効率よい開発スタイルを取るためには，みんなが職人になる必要はない．むしろ職人はいない方がよいのかもしれない．しかし，一人一人が流れ作業のひとつで終わるのではなく，仕事に誇りをもって，楽しんで仕事ができるようになるためには，職人的な考え方も悪くないのではないかという気がする．
　ともあれ，いきあたりばったりで問題解決をするのではなく，十分な準備と体制を作り，お金の掛け方を間違えないで開発していくことこそ，トラブルを起こさない，トラブルに勝つ方法なのである．
　あまり細かいことをTips的に扱った訳ではないので，今困っている人の助けにスグになるという内容ではないが，今後のソフトウェアの開発体制について参考にしていだだければ幸いである．

Copyright (c) 1997 int21 Corporation All Rights Reserved.
For questions or comments, please send mail to: pcdn@int21.co.jp