このページで説明しているように、ある業務ワークブック特有のマクロでもアドイン化することで改廃に対する対応が楽になり、複数のワークブックに対してもアドインが一つで済むためリソース軽減にもつながります。ここではその実装方法について説明します。

単純なものではないため、サンプルを用意して「はいどうぞ」という訳にはいきません。ですが「たたき台」となるサンプルは最後に用意いたしました。

まず、「アドイン」の説明からしておかなければなりません。別に「アドイン」とはこういうものだ、とか、こうあるべきだ、を論議するつもりはありません。「配布の問題」で取り上げる「アドイン」とはこういうものを指しているという説明です。

オプションにある「アドイン」のこと？

マクロを使わない方でもExcelを操作していて、「Excelのオプション」の中に「アドイン」という項目があるのをご存じの方も多いと思います。



下の方の「管理」の「設定」ボタンをクリックすると、



「アドイン」のダイアログが表示され、Excel標準で搭載されている追加機能や、「管理」プルダウンの「COMアドイン」では他アプリのプラグインが選択できるようになっています。
ここにユーザーが「便利機能」などの汎用的なマクロを作成し、アドインとして保存したものをインストールさせて、このリストに追加させることもできますが、この章で説明しようとしている「アドイン」はちょっと違います。 Excelの起動時から「常駐」させる目的ではありません。
ですから、このダイアログのリストに追加することもしません。

目的は「データ」と「仕組み」の切り離しです。

前の章で説明している通り、目的は「ユーザーデータが入力されるワークブックと主機能マクロの切り離し」です。



つまり、データのワークブックと、マクロのワークブックがあって分離されて機能すれば目的は達せられますが、マクロのワークブックが「ワークブック」としてExcelのウィンドウに表示されてしまうのは不都合です。
「アドイン」であれば、他のワークブック同様にマクロからOpenメソッドで開くことができますが、Excelのウィンドウにはワークシートとして表示されないのです。開いているワークブックの数をWorkbooks.Countで調べても計上されません。

ですから、特定の機能を要求するワークブックが開いた時だけ「専用のアドイン」をバックグラウンド的に開いて機能させて、要求ワークブックを閉じる段階では他に同じ要求のワークブックが開いていなければアドインも閉じてしまうというのがここでやろうとしている方法なのです。

同じ特定の機能を要求するワークブックが多数配布されてしまうことを考えると、個々のワークブックに主機能マクロを実装させるような「従来的」な方法ではマクロ側の変更が発生した場合に苦慮することは以前のページで説明した通りです。 アドインに分離させることで主機能の変更が発生した場合でも、アドイン側の修正だけで対応でき、呼び出し側の個々のワークブックの修正は不要になるというものなのです。

さらに、これも以前のページで説明しましたが、社内で複数の部署に同じ機能のワークブックを配布するような場合は、アドインを全社のどこからでも参照できる配置にできて、ワークブック側のアドイン呼び出しパスを統一できれば、 そのアドインは社内で一ヶ所だけに集約できるというようなメリットになるということです。
機能変更があった場合は統一ヶ所にあるアドインの入れ替えを行なえば、それらを呼び出す各ワークブックは修正済みの最新のマクロ機能が利用できる状態になります。

アドインだとワークシートが使えないわけではありません。

前項の図だとアドイン自体ではワークシートが使えないように見えてしまいますが、アドイン内のワークシートはExcelのウィンドウには表示されない(運用現場の利用者からは見えない)もののマクロのコードからは参照・更新させることはできます。

たとえば「年間カレンダーの作成２」で説明している「祝日パラメータシート」などはマクロのコードからしか参照しないので、 カレンダー処理自体がアドイン側に実装されるなら「祝日パラメータシート」もアドイン側に配置させた方が良く、運用現場から見たら祝日の改廃もアドインの再配置だけで更新できることになります。 「祝日パラメータシート」のようなものを各運用現場にワークブック内に実装させて配布させてしたったら、変更が起きた時に配布したすべてをどうやって更新させるのか、すべてを更新させることができるのかを想像して下さい。

この他本来利用現場には見せたくない「システムパラメータ」的や、勘定科目のような数年に一度程度変更があるかどうかの半固定的なマスタ情報があればその情報をアドイン側のワークシートに納めても良いでしょう。

さらには「アドイン動作のサンプル」のソースコードでは「初期処理」で呼び出しワークブック側にアドインのバージョンを表示させているのですが、 アドイン側ではマクロソースコードだけでなく、アドイン側ワークシートの更新の際にメインモジュールにあるバージョン値や更新日を更新させてから配布することで、 運用現場の担当者にも「アドインのバージョン」を通知させることができるので、問い合わせの時に「最新バージョンになっているのか」などの判断ができるようになります。

これらがアドインに「主機能」を分離させることの最大のメリットだと思います。

「アドイン」が良く解らない方のために、簡単な実験してみましょう。

まず、このように新しいワークブックを２つ開きます。新規にExcelを開いたところから行なうと、「Book1」「Book2」となると思います。





次にVBEを開きます。



このように左のプロジェクトエクスプローラには「Book1」「Book2」が表示され、表示メニューから「イディミエイト ウィンドウ」を選択して、開いているワークブックのカウントを見ると、「2」と表示されます。





ここで、「Book2」をアドインにして見たてますが、まず、簡単なマクロを仕込んでおきます。



Module1(標準モジュール)を追加して、簡単なマクロを書き込んでおきます。

次に、「Book2」をアドインにしてみましょう。

「プロパティウィンドウ」を表示させて、プロジェクトエクスプローラで「Book2」の「ThisWorkbook」をクリックします。プロパティに表示される項目の中に「IsAddin」プロパティがあり、「False」になっています。





これを「True」に変更すればアドインとして機能します。



「True」に変更しても、VBE側では何も変化が起きませんが、Excelのウィンドウに戻ると、



このように、「Book2」は消えてしまいます。（ウィンドウメニューにも表示されません。)

作成したマクロはどうなったかというと、

「Book2」で作成されたマクロは表示されなくなりました。では「Book1」側からどのように「Book2」のマクロを動作させるのでしょうか。





VBEに戻ると、「Book2」は閉じてしまったのではないことが確認できます。



では、「Book1」の方に標準モジュールを追加して、Runメソッドで「Book2」側の「TEST1」プロシージャを起動させてみましょう。このように記述できたら、もう一度Excelのウィンドウに戻ってマクロを起動してみて下さい。



このように、アドインとなった「Book2」のプロシージャ「TEST1」が動作したのが判ります。

本来の目的に利用できるでしょうか。

このサンプルでは、保存させていないのでブック名に拡張子がありませんが、「アドイン」だからと言って拡張子が「*.xla」でなければならないわけではありません。ですが、「*.xla」で保存させたワークブックは、開いた時にアドインとして認識されます。
Excelウィンドウから消えてしまったため、名前を付けて保存ができない状態ですが、空のワークブックにマクロだけを実装して、アドイン作成ツールを使えば、元のワークブックのコピーをアドインに変換できます。
このような方法で、アドイン呼び出し部分以外のメインとなるマクロプログラムをアドインにしてしまえば、機能の改変が発生してもアドインだけを変更するだけで済むわけです。
アドイン側からカスタムツールバーを表示させるようにしてしまえば、機能追加に対する起動ボタンもアドイン側だけで自在に追加・変更できるので、元のワークブック側に実装させなければならないコード記述はかなり画一化させることができるようになります。
当初の目的は「データ」と「仕組み」の切り離しです。そういう意味では、別にウィンドウが見えていて構わないのであればアドインでなくても構わないし、ワークブックのままでウィンドウを非表示にする方法もあるでしょう。 「アドイン」ということで拡張子が区別されるので、フォルダ内の「見た目」で区別しやすいなどというメリットもあります。