課題の顕在化を背景にさらに高まるExcel業務のシステム化ニーズ
企業の日々の業務に欠かすことのできないツールとなっているExcel。さまざまなビジネス領域における顧客や資産、売上、在庫など各種情報の管理をはじめ、集計レポートの作成、さらにはデータ分析といった用途に広く利用されており、ほとんどの企業がExcelの利用なしに現場業務が回らない状況だといっても過言ではないだろう。
ただその一方で、特にExcelデータを複数人で共有している際に生じる同時編集にまつわる課題やデータの肥大化など、いくつかの問題が顕在化しているケースも多く、かねてよりそうしたユーザーの間では、「Excelで行っている処理をシステム化したい」というニーズが根強く存在してきたのも事実である。さらに近年では「サーバーサイドでExcelを使いたい」という要望も急速に高まってきている。
そうした状況を受けて、Excel業務のシステム化を検討する各企業のシステム開発者の多くが、例えば「サーバーサイドでのExcel処理にどういう技術を採用すべきか」「Excelの利用とシステム化のすみ分けをどう図るか」といった難題に頭を悩ませている。今回の「GrapeCity ECHO 2022」は、そうした開発者の抱える課題を踏まえるかたちで、Excel業務のシステム化に向けた指針を示すことをテーマに据えて実施された。
Excelファイルの処理を可能にするAPIライブラリの活用がポイント
当日執り行われた3つのセッションの端緒を開いたのは、日本マイクロソフトの井上章氏による「Officeオートメーション技術とサーバーサイド コードでのExcel利用の課題」と題する講演である。
マイクロソフトでは1997年ごろに、対話可能なバイナリソフトウェアコンポーネントを作成するための分散オブジェクト指向技術として「COM（Component Object Model）」を確立した。「COM自体は、アプリケーション側のCOMクライアントが、リモートコンピュータを含む他のプロセス内に存在する、さまざまな機能を実装したCOMコンポーネントとの間で公開されたインターフェイス経由でプロセス間通信を行って、その機能を利用して必要な処理を行うという仕組みを実現するもので、ActiveXやCOM+、DCOM、さらにいえばWindows OSそのものの基盤ともなっている技術です」と井上氏は紹介する。
そうしたCOMの1つの機能として提供されているのが「オートメーション」である。これは従来OLEオートメーションと呼ばれてきたものだが、さまざまなアプリケーションが持つオブジェクトや機能を、他のアプリケーションやマクロ言語、開発ツールなどに公開して利用可能にする技術だ。このとき、サーバーサイドのASP（Active Server Pages）やASP.NETなどのWebアプリケーション、DCOM、COM+、Windows NTなどのサービスを介してその機能を利用するというかたちをとれば、すなわちそれが「サーバーサイドオートメーション」になる。
Excelを含むMicrosoft Officeには、このオートメーションの仕組みが実装されている。アプリケーションやマクロ言語、SDK、開発ツールなどからOfficeが備える各種機能を使うことができるようになっており、これは「Officeオートメーション」と呼ばれる。「例えば、皆様が開発するアプリケーションで、ExcelやWordなどのOfficeドキュメントを処理したいといったケースでは、このオートメーションの仕組みを通してOfficeの提供する機能をアプリケーションで利用することができます」と井上氏は説明する。
具体的には、アプリケーション側で"Excel.Application"といった指定で"CreateObject"によってOfficeオブジェクトを生成することで、対象のOfficeアプリケーション、すなわちExcelが起動され、アプリケーションとExcelのOfficeオブジェクトの間で関数命令やその結果にかかわるやり取りを行えるようになる。
「仮にこのプロセスをサーバーサイドオートメーションで実装するなら、サーバー側にWindowsの仮想マシンを用意して、そこにインストールされたExcelを起動してWeb APIなどを介してサーバー／クライアント間の通信を行い、同様のやり取りを進めていくかたちが一般的でしょう」と井上氏は言う。
もっとも、こうした仕組みの構築については、いくつかの留意すべき点があげられる。1つには、Office自体が、基本的にはクライアントPC上で動作するUIを持つアプリケーションとして設計されているということだ。つまり、ウィンドウ描画などのUIスレッドなどを持ち、かつその実行においては対話型のデスクトップとユーザープロファイルの利用が前提となる。
「ところが、サーバーサイドオートメーションでは、ログオンセッションが張られていない状態での無人での非対話型による実行も想定され、そうなると仮に予期せぬ内部エラーが生じた場合などにOfficeが実行する、モーダルダイアログを表示してユーザーに操作を促すといった動作に対応できない事態となり、デッドロック状態に陥ってしまうといったことも起こりえます」と井上氏は強調する。
またユーザープロファイルについてOfficeでは、レジストリ内の"HKEY_CURRENT_USER"配下のキー情報の取得などを行うが、サーバーサイドオートメーションではユーザープロファイルを持たないアカウントによる実行もあり得るため、初期化処理に失敗することも考えられる。
「さらに言えば、そもそもマイクロソフトでは、パフォーマンスの劣化なども含めて、さまざまな複雑な問題が発生する可能性があるため、すでに述べたASPやASP.NETなどのサーバーサイドコードからのOfficeオートメーションの実行を推奨しておらず、サポート外としています」と井上氏は語る。
このようにOfficeオートメーションをサーバーサイドで使うにあたっては何かと考慮すべき点が多いわけだ。これについては、サーバーサイドでOfficeオートメーションと同等の機能を実装するためのいくつかの代替手段が存在する。
「その1つが『Open XML SDK』の利用です。このSDKを活用すれば、C#などの.NETの言語群により、docxやxlsx、pptxといったOpen XML形式のOfficeファイルの処理を行うことが可能です」と井上氏は語る。そのほかにもExcelファイルをアプリケーションで処理するための、.NETベースのAPIライブラリといったものも商用製品ないしはオープンソースで提供されている（図1）。例えばグレープシティの「DioDocs for Excel」などはその代表例だ。
「そうした意味では、Excel業務のシステム化に関するサーバーサイドの仕組みの実装には、Officeオートメーションの利用ではなく、これらライブラリを活用いただくことが、極めて重要なポイントになるものといえます」と井上氏は語った。
