5月 16, 2008

VBAの復活

先日(5月14日)、マイクロソフトから発表があり、Mac用Officeの次期バージョンでVBAが復活することが明らかになりました。

「VBAで作成された自動処理の機構はAppleScript/Automatorに全面移行すべし」、という従来の方針が転換されたわけで……結局はユーザーの利益にかなう決断がなされた、と好意的に理解しています。各メディアの論調も、歓迎するものが多いように見受けられます。

VBAからAppleScriptへの書き換え資料を作っていて思うのは、そもそもまるっきり別のものなので、「置き換え」になりにくいということです。VBAがOfficeの内側に存在して、各Officeアプリケーションを「拡張」するものであるのに対し、AppleScriptはあくまでもOfficeの外側にあって、他のアプリケーションと「つなぐ」「連携させる」ものであるということがいえます。

おそらく、VBAのプログラムをそのままAppleScriptに移植しても、十分なスピードを発揮できないというケースが多々あると思います。相当のパフォーマンス・チューニングを行わないと、遅くて使えないとかいったことすらあるでしょう。命令体系がどうとかいう問題ではなく……アプリケーション内部で実行され、あくまでもアプリケーション上のマクロ言語という扱いで動いているOffice:macのVBAでは、動作の仕組み自体が違いますし、同種の命令を実行するための処理コストが段違いです。

Office:mac上のVBAがExcel内のデータにアクセスする分には、同じアプリケーション内のデータにアクセスすればよいだけです。他のアプリケーションの都合など考えず、自分の都合だけで処理できます。一方のASでは、外部の独立した実行アプリケーションが、OSやOfficeアプリや他のアプリと同期をとりつつ、命令発行とデータ転送を同一の経路で行っています。同じ処理を行わせても、おのずと処理速度に差が出る可能性が高いのです。

そのうえ、Office 2008のAppleScript用語辞書ではVBAと1対1対応するように命令が用意されている印象があります。移植性を考慮してのことでしょうが、そもそもVBA向きの命令/オブジェクトになっているものを、AppleScript用に無理矢理実装しているわけで……効率的に処理できない可能性がいっそう増すことになります。とくに、User Interfaceの状態(ツールバーなど)を確認したり変更するような種類の命令が目につき、それはVBA的なアプローチとしては「必要」なのかもしれませんが、AS的なアプローチでは比較的「どうでもいい」と判断される種類の命令やオブジェクトです。

なんにせよ、ここ2・3年の間は現行のOffice:macをコントロールする手段としてVBAを使用できないわけで、VBAで処理すべきことについては前バージョンのOffice 2004などで行い、Office 2008でなければできない機能を用いてシステム化するような場合には……AppleScript/Automatorの出番となることに変わりはありません。VBAからASへの完全移行ではないため、「切迫感がやや薄れた」程度と感じています。より、Microsoft Officeの魅力を高めるソリューションを提供できれば、と考えているものです(N)

Leave a comment