| OfficeのためのVBA？ |
|---|
VBA（Visual Basic for Application Edition）というと，最初に連想するのは，Excelの表を自動的に操作したり，Accessでプログラミングしたりすることなのではないだろうか．もちろん，そのような認識は正しい．Excelをマクロで操作するのも，Access（ver.7.0以降）でプログラミングをするのも，VBAで記述されたプログラムにより実行されている処理である．
しかし，Visual Basic 4.0で開発されたプログラムも，またVBAアプリケーションなのだというと意外な気がするのではないだろうか．このあたりはMicrosoftの発表においても混乱が見られた時期があった．
|
多くのモジュールの集合によって 構成されるパッケージ |
|---|
もちろん，厳密にいうならば，Visual Basic 4.0とVBAは別物である．Visual Basic 4.0はActiveXコントロールや開発環境などがパッケージされた製品であり，VBAは単体では販売されていないソフトウェアモジュールである．同じようにExcelやAccessとVBAも別物なのだということができる．
現在のプロダクトは，単一のアプリケーションだけで成りたっているものは少ない．特に開発ツールともなれば，数多くのユーティリティやアプリケーションの集合によってひとつのパッケージを成している．VBAのモジュールはプログラムアイコンにすら表示されないモジュールのひとつなのである．
| VBA = Visual Basic |
|---|
結局のところ，VBAプログラミングとは，Visual Basicプログラミングにほかならない．Microsoftの正規マニュアルにしても，しばしば，VBAのことをVisual Basicと呼んでいる．つまり，VBAとはVisual Basicのことであり，Visual Basic 5.0には，その最新型の言語エンジン（これはVBAとは呼ばれないようである）が搭載されているのである．こう考えると，Office製品の次のバージョンのではVisual Basic 5.0のエンジンが搭載され，Excelマクロがネイティブコンパイルされて動作するようになるのかもしれない．その必然性についてはともかく，すごいことだ．
|
Office製品を プロクラミングオブジェクト化 |
|---|
図1：Office製品に付属のVBA開発環境
|
Microsoftは32bitのOffice製品を開発するに当たって，プロダクト全体をCOMコンポーネントとして再設計した．COMアーキテクチャに従って，コンポーネントはAPIを公開し，コンテナからの操作を可能にした．オートメーションである．これにより，COMコンポーネントを操作できる開発ツールならば，これらOffice製品の機能のほとんどを外部から操作することができる．もちろん，その時に開発者の念頭にあった最有力な言語がVisual Basicであったことは言うまでもない．
そしてこのコンセプトはさらに押し進められ，開発ツール製品ばかりでなく，Office製品自体にもVisual Basic（VBA）をサポートする開発環境が搭載され（図1），自分自身を操作することができるようになったのである．ここで，理解してほしいのは，Visual Basic 5.0でExcelの提供するオブジェクトを操作しているときも，Excelのマクロでワークシートを制御しているときも，Officeオブジェクトをオートメーションで操作しているという構図には差がないということなのである．
|
言語とオブジェクトは 相互に独立している |
|---|
Visual Basicでプログラミングをするときに，プログラムコードとActiveXコントロールは，それぞれ独立した存在である．Visual Basicが存在しなくてもActiveXコントロールは存在し得るし，その逆もまた可能である．OfficeオブジェクトとVBAについても同様のことがいえる．つまり，VBAでOfficeオブジェクトを操作するという処理は，VBAという側面とOfficeオブジェクトという側面の両方からとらえることができる．“VBA = Visual Basic”と書いたように，言語としてのVBAには，Visual Basicと比較して特に語るべきことはない．したがって本稿では，Officeオブジェクトを中心に据えて話を進める．
|
オートメーションに比重が 置かれたコンポーネント化 |
|---|
オートメーションとはその名の通り，処理を自動化することである．アプリケーションで行なえるさまざまな処理を外部から制御することでオートメーション化を計るのである．これを内部的に実行しているものをマクロだということができる．アプリケーションをコンポーネント化するというと，プログラムを部品化して再利用性を高めるというイメージがある．しかし，Office製品のコンポーネント化に関しては再利用性というよりは，オートメーション化に比重が置かれている．もちろん，オートメーションが実行された時点でコンポーネントが再利用されたという言いかたもできる．しかし，再利用性を追求したのならば，設計の時点で，もっと効率を考えて分割されたはずである．
| 追いついたマシン環境 |
|---|
Office製品のオブジェクト階層図を見ていて気づくのは，多くのオブジェクトがApplicationオブジェクトから派生していることである．これでは，何か簡単な処理をひとつするにしても，巨大なOfficeアプリケーションをロードする必要がある．これでは，利用の効率が悪い．
Visual Basic（VBAではない）から，Office製品のオートメーションを利用しようとしたとき，結局，最後まで問題になるのが，この，アプリケーションオブジェクトのロードの問題である．確かに，Visual Basic 4.0発売当時のマシン環境に比べて，メモリ32MB以上が期待できる現在では，Visual BasicアプリケーションとExcelが同時にメモリ内に常駐することに無理はなくなった．
|
再利用の目的には不適切， やはり，オートメーション |
|---|
しかし，些細な計算処理のために数MBのメモリを消費するモジュールをメモリにロードするのは，健全なプログラマならば避けたいだろう．たとえば，Excelに用意されている関数のひとつをVisual Basicのプログラムから利用したいとする．もし，関数コンポーネントがApplicationオブジェクトとは別に単体で公開されていれば，Visual Basicのプログラム内でコンポーネントのインスタンスを作成し，目的の関数を呼び出せばよい．しかし，現実には関数をひとつ呼び出すためにExcelの本体を読み込まなければならない．結果として，Officeオブジェクトを利用するプログラムは，機能の一部をコンポーネントとして利用するというよりも，おのずと製品の機能を存分に使ったオートメーションプログラムになってしまうのである．
|
Windowsプログラミングには アイデアが不可欠 |
|---|
Windowsプログラミングをするうえで，アイデアは不可欠である．特にVisual Basicのような高水準のツールで開発する場合にはアイデアが決め手になる場合が少なくない．以前のプログラミングは，正しくアルゴリズムを理解して積み重ねるようにコーディングをしなければならなかったが，現在では複雑な部分は開発ツールやコントロールが処理してくれる場面も多い．しかし，「好事魔多し」というように，高級で複雑なツールにはバグがつきものである．カプセル化されている分だけ，内部に障害があったような場合に回避することが難しくなる．しかし，このようなときでも，アイデアで障害をかわせることも少なくない．このようなアイデアは正当な発想からはなかなか出てこないものである．
|
「あの機能が使えれば」 がチャンス |
|---|
もちろん，発想するためには，元になる知識が必要である．Officeオブジェクトを使うには，何よりもまず，Office製品を知ることがポイントになる．OfficeオブジェクトのAPIも多くは手動でオペレーションしている内容を自動化するためのものが多い．プログラムを作っているときに「ああ，いつもWordで使っているあの機能が使えればなぁ…」と思ったときがOfficeオブジェクトを使う機会である．
Officeオブジェクトを使う理由としてファイルの取り扱いがある．Microsoft Officeは大変普及した製品であり，多くの企業で利用されている．製品が使われているということは，当然，Office製品対応のデータファイルがあるということである．当然のことながら，OfficeオブジェクトはOfficeドキュメントを取り扱うことに慣れている．たとえば，Microsoft Wordで作成した文書ファイルの内容を読みこむプログラムを記述するのは容易ではないが，Wordオブジェクならば何の苦労もなく，このような処理が行なえる．
| 定型業務と否定形業務の間で… |
|---|
エンドユーザーが日々生産するドキュメントとカスタムプログラムを結び付けるのも，Officeオブジェクトのミッションのひとつだろう．しかし，これらの製品を操作して作成される不定形の文書と，定型的な処理を結び付けることは簡単ではない．もちろん，テンプレートを作成しておいて定型的に扱えばいいのだが，Office製品自身でテンプレートの改ざんが可能なことや，ユーザーが気まぐれに命名するファイル名にアプリケーションが対応するのは簡単なことではない．
今のところ，Officeオブジェクトを利用したプログラミングは，現実的なソリューションというよりは，与えられた可能性にとどまっているということができるだろう．
| for Example |
|---|
では，VBAではどのようなことができるのか，具体的に考えてみよう． Microsoft Office Developer Edtionにも付属しているマニュアルに『Microsoft Office 97プログラマズガイド』（アスキー刊）があり，このマニュアルは市販もされている．Officeを使ったプログラミングを進める上で有用な資料だが，多くがVisual Basic（VBA）についての説明に費やされている．つまり，For Loopについてとか，変数の型についての説明が多いのである．
巻末に付録として収録されているオブジェクトの階層図は有用な資料だといえるが，そこに記されているオブジェクトがどのようなメソッドを提供しているのかについての完全な解説はない．各アプリケーションのヘルプを参考にするしかないようである．
それでも，サンプルコードが掲載されているので，それらが何を実現しているかを見てみよう．紹介例のオリジナルは，それぞれのアプリケーションからVBAを使用して操作しているが，Visual BasicからOfficeオブジェクトのインスタンスを利用して操作する場合もコードは初期化処理を除いて同じである．
Microsoft Excel
たとえば，Excelを用いたサンプルでは，ワークシートを開いて特定のセルに値を代入し，任意の名前でファイルをセーブする方法についてのサンプルが掲載されている．この方法により，プログラムでExcelシートが作成できる．
その他，表の値を自動に計算する方法のサンプルや，処理する範囲を特定する方法などついて説明されている．
Microsoft OutLook
OutLookのサンプルでは，メッセージストア内にある任意のフォルダを取得する方法についてのサンプルコードが説明されている．その他，アイテムに関連づけられているインスペクタが閉じるときに自動的にセーブする方法や，アイテムのアラームの設定を無効にする方法などが解説されている．私はOutLookを使わないので，ここで説明している処理が何を意味しているのかわからないのだが，これらの処理の自動化を必要としている人ならば，きっと，意味がわかるだろう．
グループウェアクライアントであるOutLookは，メール送信の機能などを有しているので，当然，それらの処理をVisual BasicやVBAで記述することもできる．
Microsoft Power Point
Power Pointの自動化に関して，私はPowerPointを利用した自動紙芝居の作成くらいしかアイデアがない．しかし，VBA自体はPowerPointのオートメーション化のために考案されたという噂もあるくらいだから，きっと，画期的な使い道があるのだろう．
PowerPointを使ったサンプルとしては，次のようなものがとりあげられている．「プレゼンテーションシートをオープン．Wordのアウトラインから内容をインポートし，特定のスライドをアクティブにしてから，番号，サイズ，向きを設定して，スライドショーを実行した後で保存して閉じる」．ほら，やはり，自動紙芝居のプログラミング方法について解説してある．
その他にも，自動的に統一されたデザインに変換する方法だとか，背景と配色を設定する方法についても触れている．スライドが100枚以上あるような場合には便利だろう．
考えてみれば，PowerPointにはスライドショーという機能があるのだから，スライドショーの最中にオペレータが起こしたアクションに応じて，何かの処理を行なうというのが正当な利用方法かもしれない．つまり，オートメーション化というよりもスライドショーの表現能力の拡大である．たぶん，米国ではもう普通のプレゼンテーションでは誰も見向きもしなくなって，過激な表現が求められているのだろう．そう考えると，PowerPointにオートメーションという概念をもちこもうとした理由がわかる．
Microsoft Word
想像がつくように，Wordも文書を開いてから印刷し，保存して文書を閉じる方法の解説から始まっている．Visual Basicは伝統的に印刷機能が弱いので，Visual BasicからWordの強力な印刷機能を利用するというのは有効そうである．また，Word文書をテンプレートとして利用できるできるので，フォーマットを作る場合もレポートプログラムを作るより簡単かもしれない．
もちろん，Word文書に値を出力したり，文書の内容を取得するようなことも可能である．また，特定の範囲だけを処理の対象にすることもできる．ただ，これらの処理を正確に行なうには，Wordの文書のフォーマットを正しく理解し，それに合わせて処理を記述する必要がある．
特定の文字列を探し出してカウントしたり，書式を変更するようなこともできる．このような処理を必要とする学者や編集者も多いのではないかと思うが，彼らが自分が望む処理をプログラミングできるまでの道は険しそうである．
その他
ここで紹介した製品以外にも，メニューとツールバーを扱う方法やOfficeアシスタントについても説明がある．Microsoft Accessは当然大きく説明されているが，Access自身が開発ツールとしてメジャーであり，一般的に知られている以上のことは記載されていなかったので割愛した．
興味深いのはDAO（Data Access Object）が，Accessとは別項で大きく扱われていたことである．Office製品とデータベースのデータが緊密に連携を取り合う時代がくるのかもしれない．しかし，インターネットアプリケーションの開発方法にも多くのページが割かれているのは，単にVisual Basicにもバンドルされているインターネット関係のActiveXコントロールが，Office Developer Editionにも付属しているからである．
Wordがブラウザの機能を有しているとか，Office製品がHTML文書の形式でファイルを出力できるとかいうことを除けば，Office製品がインターネットに対して特別な機能をもっているということはない．
ただ，Jetデータベースエンジンがインターネット経由でレプリケーションができるというのは，画期的である．
| やはり，アイデアが大切 |
|---|
優れたアイデアさえ思いつけば，Officeオブジェクトはプログラムを支援する強力なコンポーネントになってくれるだろう．少なくとも，アイデアを提供するための豊富な題材を，これらのオブジェクトは提供してくれる．おそらく，開発しているMicrosoftも，何か決定的な利用方法を想定していたわけではないことは確かである．何に使えるかはわからないけれど，とりあえず何でもできるように用意しておくことは，システムアーキテクトとして良心的な姿勢である．
とはいっても，用意されているのだから使わなくてはいけないというものでもない．私はこのアーキテクチャにずっと注目してきているが，この2年間で使用したのは，本誌のサンプルで一回と，インターネットサーバーのログレポートを生成するプログラムで使ったのみである．
int21 ホームページ | PCDN ホームページ
Copyright (c) 1998 PCDN All Rights Reserved.
For questions or comments, please send mail to: pcdn@int21.co.jp