巷では，特に管理者層の間では，「Visual Basicを使うと，開発効率が上がる」と盲目的に考えられている部分がありますが，そんなことはありません。
　確かに「とりあえず動くものを作る」のは，非常に楽です。しかし，「きちんと動くものを作る」のは，Visual Basicを使っても楽になるとは限りません。
　Visual Basicが効果を発揮するのは，次のような部分に限られます。

1. 画面の外枠の作成。

間違っても，画面全体の作成ではありません。「アプリケーションで必要な画面表示を提供してくれる，既存のカスタムコントロール」が存在してこそ，Visual Basicは威力を発揮します。
実際に，私が過去に関わったプロジェクトでは，「画面仕様書に書かれた使用を満たすカスタムコントロールが無かったため，結局コントロールからＣ＋＋で作成し直した」場合がありました。
2. プロトタイプの作成。

これは，よく言われてる事ですね。
3. コンポーネントを組み合わせた処理。

もっと言えば，ActiveX(OLE)オブジェクトを組み合わせて行う処理。
ある意味バッチファイル的なものと言えるかもしれません。
4. 半自動のメモリ管理。

このおかげで，不用意に変なメモリを潰して，怪しい動きになってしまうことは基本的にありません。
逆に言えば，malloc相当の事すらできないわけで，特に不定形のデータを処理する場合は，Ｃ＋＋のように，簡単にごまかすことができないということでもあります。

• 速度

これは仕方がありません。問題なのは，「パフォーマンスが必要とあらかじめ分かっているにもかかわらず，Visual Basicで作ろうとする」開発者・設計者の姿勢です。少なくとも，現状のVisual Basicでは，マルチスレッド化してごまかすこともできません。
• マクロが無い

ある意味，このおかげで，とっつきやすい部分があるのかもしれませんが，小細工をしにくい部分があります。
• エラー処理
  Ｖisual Basicが検出したエラーは，関数などの戻り値ではなく，イベントとして処理されます。

実際に困る原因なのは，「エラー処理をきちんと行わないと，あらゆる所で実行時エラーとなり，いきなり終了してしまう」事です。私の今までの経験では，「インデックスの範囲が不正です。」「型が一致しません」「オブジェクト変数または With ブロック変数が設定されていません」のエラーで終了してしまうのが御三家でした。
また，このエラー処理というのも，On Error Goto文でイベントを処理するか，On Error Resume Next文でとりあえずエラーを無視してから，後からステータスを参照するかのどちらかです。
エラーを特に処理する必要が無くても，「エラーを無視する」という事を関数ごとに記述する必要があります。一方，基本的にＣ言語ではエラーを無視する場合には，何もしなければいいだけです。
On Error Goto 文は，Ｃ＋＋で言えば「構造化例外処理」に当たりますので，Ｃ育ちの人よりは，大昔のパソコンBasic出身者のほうがとっつきやすいかもしれません。。
• 特に，Ｃ＋＋の関数に渡す文字列の扱いが厄介

これは，文字列としてBSTR型やUnicodeを使用しているためです。例えば，文字列の（ASCIIコードでの）バイト数を計算する場合には，次のようにする必要があります
• 文字数分ループ
• ASC（Mid$(文字列,カウント,1))が２５５以下なら，１，それ以上なら２を足す。
• 以上を文字列の最後の文字まで繰り返し。
• 別のＶｉｓｕａｌ Basicで書かれたＤＬＬとのインターフェースに，構造体を使えない。

必要なら，構造体をすべてクラスとして置き換える必要があります。ここでも，結局ＯＬＥの知識が要求されてきます。

　ユーザーインターフェースに関しても，場合によっては，Visual Basic のほうが苦手なユーザーインターフェースもあります。これは次のようなものです。

• ショートカットメニュー
• ステータスバー
• （特にドッキング可能な）ツールバー
• １データに対して複数の参照・更新可能なウインドウが同時に開ける形

　以前は「他の言語（例えばＣ＋＋）より，初心者が開発しやすい」という点がありましたが，フリーウェアや単発ツールならいざ知らず，システムの開発で，１サブシステムが（特に計算主体の処理を）丸まるVisual Basicを使うのは適切ではないと考えます。ＤＬＬ１つ作るだけにしても，上で書いたようにプログラマにある程度のＯＬＥの知識を要求するからです。（設計レベルでコンポーネントとして分割されていない場合はプログラマが独自でコンポーネントの設計を行う必要があるため特にそうです。）
　おまけにVer4，Ver5となるにつれて，ますますＯＬＥとの関連度が高くなっています。（文字列をBSTR型で管理するとか，文字をUNICODEで扱うとか）

　例として，あなたは「オブジェクトの永続期間」という言葉を聞いて，何の事か判るでしょうか？
　また，あなたの設計orコーディングしたモジュールでは，グローバル変数を使用していますか？
「オブジェクトの永続期間」が判らずにグローバル変数を使用しているなら，あなたはＶＢでＤＬＬを設計・コーディングしたり，ＶＢのＤＬＬを使用したりしてはいけません。既にその時点で，あなたはバグを構造的に含めてしまっています。

　今までの関わってきたプロジェクトからは，
「VisualBasicをメインで開発するなら，機能設計・分割だけでなく，コンポーネント構成の設計・分割も必要だ」
ということを感じました。Visual Basicがメインのシステムを設計をされる方には，コンポーネントの集合として設計していただくことを強く望みます。また，開発を行う方たちは，ＯＬＥ（Active-X）の勉強をしてください。
　Ｃ＋＋では，Ｃ言語として扱うことで（実際，私が今までに関わったシステムで，Ｃ＋＋らしいプログラムは非常にわずかです。），コンポーネントとしての設計をせずに済ませることができましたが，VisualＢａｓｉｃではそうはいきません。

　果たして，私が今関わっているプロジェクトはどうなるんでしょうか…とりあえず，１９９８年１月１４日時点では，共通ライブラリ以外全てＶＢという，今までにも増してＶＢ依存度が高くなっていますが，相変わらず「オブジェクト」とか「コンポーネント」とか言う話はさっぱり聞こえません。「関数」というのはよく聞くんですが…
 
Shinonome's known problems に戻る