WSH (Windows Script Host) のJScriptやVBScriptを触っていた頃からの不満なのだが、MicrosoftのEUC (End-User Computing) 向けプログラミング言語の教材は軒並み「プログラミング初心者向け」である。
いやまあEUCなので、幅広い層をターゲットにしようとした結果として、その辺のレベル向けの教材が大勢を占めるに至ったのは分かる。
なのだけど、なんだろう、本当に「プログラミング初心者向け」のものばかりで、そこからステップアップしていく部分の情報が非常に少ないのである。*1
（私は無茶苦茶C言語っぽいスタイルのJScriptでベタ書きされたWindows Server管理用スクリプトのことを決して忘れないだろう）
このことは、他のプログラミング言語の経験者が例えばVBA (Visual Basic for Applications) を学ぼうとした時に、必要とする情報のミスマッチに悩まされる――という事象に繋がる。
基本的にVBAの教材は「このAPIを使えば〇〇できる」とか「××したいなら△△のAPIを使おう」みたいな部分が多い。またサンプルコードはベタに書かれている。これはこれで情報源としては役に立つ。しかし例えば「〇〇と××と□□と▽▽を組み合わせたいが、プログラムが大きくなるので、メンテナンス性や効率性を考慮して構造化したい」というときに高確率で「この教材には参考になりそうな情報が欠けている……」と悲しみに包まれることになる。
では、例えばVisual Basic系以外のプログラミング言語での開発経験者がVBAにキャッチアップするには、どうすればよいだろうか？
先に挙げた「プログラミング初心者向け」の情報に容易にアクセス可能である（リファレンス本が手元にある等）という前提で、開発者が追加で参照すべき情報は、概ね次のように分類可能だろう：
- 開発環境およびプロジェクト構成
- Visual Basicの言語仕様と組み込み機能（Microsoft Formsを除く）
- Microsoft Forms
- 開発ターゲットのOfficeアプリ固有の機能
- 参考：Officeアプリ共通の機能
- 外部連携（特にデータベース）
開発環境およびプロジェクト構成
Visual Basic Editorなるものが存在することと、ステップ実行の方法、この2点は押さえておくとよい（起動方法や詳しい操作方法は都度ググってOK）。例えVisual Basic Editorで開発を行わなくとも、実際に問題が起きているコンピュータ上でVisual Basic Editorを起動してデバッグすることが可能だという点は、いざという時に役に立つかもしれない。
プロジェクト構成については――VBAのコードはOfficeアプリケーション用の各ファイルに格納される、という特殊な事情を念頭におくべきだろう。他の言語で言う「ファイル分割」をしたくなった場合の正攻法は「Visual Basic Editor上でモジュールを追加する」だろう。
今となってはVisual Basic Editorは使いにくいのだが、諸々の特異性より、なかなか他のエディタ等にスイッチしにくいという難しさがある（どうしてもインポート・エクスポート的な処理が間に挟まってしまう）。もちろん、例えばVisual Studio Codeで開発するためのサードパーティによる仕組みもあるのだが、その内部で「インポート・エクスポート的な処理」をやっている旨を把握しておかないと、何か問題が起きた時に場当たり的なアプローチに終始してしまいかねないだろう。
Visual Basicの言語仕様と組み込み機能（Microsoft Formsを除く）
Microsoft公式のVBAのリファレンスは、Visual Basicという言語に取り組む際に色々と参考になる。
言語の雰囲気が分かるし、組み込み関数などのリファレンスを見ることで意外な便利機能が見つかったりする。
公式の情報だということは、すなわち「VBAの言語開発者が考える『VBらしいコード』の書き方」がサンプルコード等に表れていると言っても過言ではないだろう。
なお、モダンな言語に慣れた身からすると、Visual Basicの各機能はプリミティブ気味に感じる上に、抽象化に使える手札が少ないので、コードを書いていて時々「ちょっと面倒だなあ」と感じる時がある。
Microsoft Forms
こちらもMicrosoftの公式情報を参照するとよいだろう。
GUIプログラミングの流儀はフレームワーク等によって随分と異なる。VBAのそれは、.NET以前のWindowsアプリ開発の経験があれば、何となく方向性が分かるのだが……。
開発ターゲットのOfficeアプリ固有の機能
VBAといったら十中八九Excel VBAなので*2、その手のリファレンス本との抱き合わせで、これまた公式情報も押さえるとよいだろう。
大まかな使い方はリファレンス本で十分だが、そこから先の細かい部分は公式情報でチェックすることになる。
参考：Officeアプリ共通の機能
ところでVBAはOfficeの各種アプリに組み込まれているのだが、その際の抽象化のアプローチとして「Officeアプリ共通の部分」と「特定のOfficeアプリ（例えばExcel）に固有の部分」みたいな感じに分けられている。
そのためか、Officeアプリ共通のカスタマイズ・ポイントに関する話題は、公式情報の中で独立した章立てとなっている。
ここまで手を出すことって、どのくらいあるのだろうか……？
外部連携（特にデータベース）
この辺もリファレンス本 + 公式情報の組み合わせで進める部分だろう。問題は、個々の技術（例えばActiveX Data Objectとか）の公式リファレンスを探すのが面倒なことだが……。
まあしかし、例えばMicrosoft SQL Serverとの連携云々とかそういう次元になってくると、クライアント側でVBAで頑張るのではなくて、サーバ側も含めた全体でのアプローチの見直しを検討してもよいかもしれない……ケースバイケースだけど。
足りないもの：VBAでのコーディング・ベストプラクティス
ここまでの情報で、言語の細かい部分や、具体的な「やりたいこと」実現のための情報などは網羅できるのだが、唯一知ることができないのはVBAでコーディングする際のベストプラクティスだと思う。
VBAだけでなく、VBScriptやVisual Basic .NETを含めて、VB一族のベストプラクティスに関する情報は非常に少ない。プロプライエタリな言語だからか、それともVBが「クールな言語」だった時代よりも後にインターネット普及期が来たからか……。
（プログラマには、後発の言語に飛びついて「こいつはクールだ。それに比べて――」と今まで使ってきた言語を腐す人も多く含まれているものだ）
一応Visual Basic .NETには公式のコーディング・ガイドラインがあるのだが：
VBAになると、個人レベルの情報に限られてしまいがちな印象がある。
まとめ
なお、このエントリを書いている人はVBAでの開発経験が無いことに留意すること。Excel VBAで書かれたツールを解析した経験はあるが、コードを書いたことはない。
私のVisual Basic系言語での開発経験は、VBScriptでサーバ管理用ツールを書いたことと、初期のVisual Basic .NETで開発されたASP.NETアプリケーションに後から機能追加を行ったことぐらいである。
*1:この点について、PowerShellでは幾分と改善されているように思うのだが、如何せんPowerShellそのものが割と独特である……。
*2:さすがに言い過ぎである。案件としてはAccess VBAもありうるだろう。それ以外のOfficeアプリのVBA案件は知らない。
