通常のアプリケーションソフトウェアでは，データを操作する機能はアプリケーションプログラムに集約され，データそのものは独立したファイルとして管理されます。たとえば，ワープロは編集や印刷などの機能を提供し，編集される文書データは別ファイルに管理されます。フォトエディタ，メディアプレイヤーなども同様です。
|
Excelにしてもフォーマット付きの表データのみを含むワークブックを考えている限りは同じ構図です。しかし，Excelをただのアプリケーションではなくプラットフォームととらえ，アプリケーションに必要な機能をVBAを使って実装し始めると事情は変わってきます。なぜならVBAコードはデータファイルであるワークブック側に組み込まれているからです。この構造は，ワークブックファイルさえあれば，Excelがインストールされている環境でアプリケーションが動作するという点では便利ですが，同時に大きな問題も内包しています。
たとえば，Excel＋VBAで作った見積もりシートアプリケーションを使って，100枚の見積もりシートを作ると，100個のVBAコード付きのワークブックが生まれることになります。ここで見積もりシートアプリケーションに新たな機能を追加するにはどうすればよいでしょうか。少なくとも新しい見積もりを作るとき使うテンプレートワークブックのコードを修正する必要があるのは明らかですが，それでは更新が適用されるのは新たに作成する見積もりシートに対してのみです。すでに作成した見積もりシートで同じ機能を使えるようにするには，個々のワークブックを開いてコードを変更していくしかありません。新機能ならばあきらめるという選択肢もありえても，バグ修正のためにコード変更がどうしても必要な場合は困ったことになります。これが，プログラムコードとデータが共存していることのデメリットです。（コードがデータの中に埋め込まれているという意味ではJavaScript付きのHTMLソースなども同じです。しかし，通常ウェブページはブラウズするたびに読み込みなおすのでこのような問題は起きません。また，同じコードが多数のページに組み込まれているケースでも，サーバ側が動的に作成されているのであれば修正すべきソースコードは限定されます。） 個人で1つのワークブックを更新し続けるなどの限られたケースを除いて，Excel＋VBAのアプリケーションでは，このようなバージョンアップやバグ修正に伴うコード変更をどう反映するかという問題が常に付きまといます。この問題に対する解決策が，このトピックで扱うプログラムとデータの分離です。 |
(a) 通常のワークブック 
(b) 通常のExcel＋VBAアプリケーション 
(c) VBAコードを分離した場合 |
以降では，最初にいくつか考えられる実現方式を紹介するとともにメリット，デメリットについてまとめます。（1. 実現方法の検討）続いて，ここで採用する自動AddIn読み込み方式の実現方法とその後のワークブック管理について具体的なコードとともにみていきます。（2. アドインの登録）いったん読み込んだAddInを自動的に開放するための仕組みについては考慮点が多いので，独立した節として検討します。（3. アドインの切り離し）最後に，今までの議論を踏まえた完成版のフレームワークをご紹介します。（4. 完成版フレームワーク）
