VBAがオワコンなのか？という話題がTwitterで流れていたので、私の考えを纏めておこうと思う。
VBAの生い立ち
Visual Basic for Applications（以下VBA）の話しをするときに、Visual Basic（以下VB）のことを抜きにすることはできません。VBAは、いまはサポートが終了しているVBという開発言語を元にして生まれました。VBは、いまもMicrosoftが提供しているVisual Basic.NET（以下VB.NET）とはまったく異なる開発言語です。VBはWindows専用の開発言語として広く支持を集めました。その開発の平易さから、特に受託開発の現場で多く使われてきました。利用者がが増えれば、対応する事業者も増えます。多くのサードベンダーがVB用のコンポーネントを提供しており、当時としては開発しやすい環境が整っていたのです。
VB最後のバージョンとなるVB6.0はComponent Object Model（以下COM）に準拠し、Microsoft開発言語の中核となりました。どのような言語であってもにCOMに準拠したコードを書けば、使用する言語によらず機能を呼び出せるようになります。オーバーヘッドも比較的小さく、単にライブラリを呼び出せるだけでは無く、プロセス間の通信や、ネットワークを介してサーバー間の呼び出しも行えるものでした。多くのコンポーネントがCOMに準拠したものに置き換わり、様々なサードベンダーが提供するようになっていきました。
ところがその後にCOMの欠点が問題になっていきます。VB 6.0の発売された1998年はインターネットの黎明期にあたりました。今ほどセキュリティへの要求は厳しくない時代に設計されたため、セキュリティへの設計面での配慮がほとんど無かったのです。Microsoftはその後に多くのセキュリティ問題に苦しむことになります。
VB 6.0の発売から4年後、セキュリティを強化して再設計したVB.NET 7.0がリリースされます。Microsoftはそれまで、二年ごとに新バージョンを提供していたことを考えると、相当に苦労したことがうかがえます。ですがVB.NETにはVB6.0との互換性は全くありませんでした。互換性の問題からVB6.0からVB.NET7.0への移行は進まず、Windows 11となった今もVB6.0のランタイムライブラリがOSと共に提供され続けています。
VB.NET7.0が発表された後、当然ながらVBAについても多くの議論が巻き起こりました。セキュリティを考慮するならVB.NET7.0を基礎としたものに作り替えた方が良いのは分かっています。でも現実問題として互換性の全くない言語への移行は困難を極めるのは明らかでした。それに対する結論として現在の状況があります。
MicrosoftはVBAはその互換性を維持して提供し続けることを選択しました。同時に、セキュリティの問題に対応するためにデフォルト設定ではマクロ機能を無効にし、また電子署名を付けた出所の明確なマクロ以外では警告を表示するようにしました。拡張子もxlsx（マクロ無し）とxlsmx（マクロ有り）と分ける事でユーザーがマクロの有無を意識しやすくしました。ユーザーはマクロを利用するために設定を変更する事になりますが、それに伴うリスクはユーザーが負うものとなりました。
最近でもセキュリティ強化は続いていて、インターネットからダウンロードしたファイルや、共有フォルダ上のファイルについては、デフォルトではマクロが実行されないような改善が行われています。
VBAに変わる機能を提供する試みも繰り返し行われています。ファイル仕様が公開されオープン化したことにより、xlsxファイルを編集する事のできるライブラリが様々な言語で利用できるようになりました。またOffice製品を操作するために、Microsoft Office Interop、Visual Studio Tools for Office、Apps for Office、Excel REST APIと何度か新たなツールを提供を試みていますが普及には至っていません。Windows OSに比較的容易に使える開発言語としてPythonを組み込むと言ったことも行われています。最近あらたに提供しているのはPower Automateですね。
VBAを使い続ける事の何が問題なのか？
セキュリティ上のリスク
マクロの実行を許可することに伴ってキュリティリスクが発生します。VBAが含まれたファイルがコンピューターウィルスの感染経路となっている事は知られていることと思います。リスクを認識して電子署名の無いマクロの実行を禁止する等の対策を取っているなら良いのでしょう。ですが、VBAを使っている企業では利便性を優先して、どんなマクロも実行許可しているのが実情でしょう。
機能面の貧弱さ
VB6.0の頃には様々なベンダーがCOMコンポーネントを提供していました。これにより2008年頃までは拡張性の高いパワフルな言語となっていましたが、今は殆どのベンダーがCOMコンポーネントの提供から撤退しています。VBAで出来る事が縮小していっているのが実態です。
VBAの言語機能どのものの拡張も20年単位で行われていません。この20年間で多くの言語に取り込まれてきたような機能、完全なオブジェクト指向や無名関数、並列化などの機能が追加される見込は無いでしょう。ソースコード管理システムとの連携が極めて困難なのも生産性を大きく下げてしまいます。
本当に何処でも実行出来るのか？
VBAを利用する理由のひとつに「Excelはどのパソコンにもインストールされており、どのパソコンでも利用できる」というのが有る。Microsoftはサブスクリプションモデルへの移行を目指しており、従来の買切り型ライセンスのOffice製品は2025年でサポートを終了することになっている。現在はデバイスライセンス下で複数の従業員が共有しているパソコンについても、2025年移行はユーザーライセンスに移行する事が求められる。例え利用時間が月に30分でも、アルバイトが20人いれば20ライセンスを購入することになるが、はたして購入し続けるだろうか？
また年々セキュリティ意識が高まっていく中、VBAを実行するためにセキュリティ設定を緩めて貰う事が、いつまで受け入れられるでしょうか？VBAを完全に禁止している会社も少なからずあるのが実情です。
またランタイムを追加で導入する必要が無く、何処でも実行可能であることがVBAを選択する理由なら、JavaScriptでもPythonでも良いはずです。
VBAを使い続ける上で必要なこと
VBAを使い続ける上で必要なことは、リスクを正しく認識する事だと考えて居ます。以下の様な問題があることを踏まえた上で、バランスを取りつつVBAと付き合っていく必要があるわけです。
- VBAを使うためにセキュリティリスクを高めていること。
- VBAの生産性を高めるような言語機能の拡張は20年ほど行われておらず、多言語と比較して生産性の低い開発言語となりつつあること。
- VBAには将来に向けたロードマップが無く、今後もサポートが縮小していく可能性が高いこと。
- セキュリティ問題、ソフトウェア資産管理上の問題から、VBAの利用を禁止している企業も少なくない。
少なくとも僕個人の方針として、今から積極的にVBAで書かれたソフトウェア資産を増やしたり、今からVBAを学ぶというのは、リスクに対してベネフィットが合わなくなる可能性が高いと捉えています。
VBAによるソフトウェア資産の総量を、VBAを止める必要が生じたときに速やかに他の開発言語に移植できる程度の量に納める必要があるでしょう。ソースコードの総量をメンテナンス可能な範囲に納める必要があるいのはVBAに限った話しではありませんが、VBAの場合には生産性の低さや将来性のなさから、より少ない量に抑える必要があるはずです。
マクロの実行を有効にする上で、セキュリティリスクを下げるため、ウィルス対策ソフトを使用するのは当然として、それ以外にもアクセス権管理やコンテンツフィルタなど、多層防御できる態勢を整えておく必要があるでしょう。新しいウィルスがウィルス対策ソフトのパターンファイルをすり抜ける事は珍しく無いのです。