課題の顕在化を背景にさらに高まる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オートメーションの利用ではなく、これらライブラリを活用いただくことが、極めて重要なポイントになるものといえます」と井上氏は語った。
コンポーネントの積極的活用で"Excelライク"なシステム化を実現
続く2つめのセッションには、システムコーディネイトの赤羽根雅樹氏が登壇。「"Excel業務"を"Excelライク"にWebシステム化した話」と銘打つ講演を行った。システムコーディネイトは1983年に設立され、2023年には40周年を迎える、いわば老舗SIerで、システムにかかわるコンサルティングから設計・開発、運用保守に至るトータルなフェーズを網羅したサービスで顧客のIT活用を支援している。
今回のセッションでは、同社がある顧客において取り組んだ、Excel業務のWebシステム化にかかわる事例が紹介された。この顧客がWebシステム化により実現したいと考えていたのは次の3つの要求からだ。すなわち、メールにより日々やり取りされているExcelファイルの授受にまつわる手間の軽減、それらファイルの取りまとめにより実施される集計作業の効率化、そして集計された情報のリアルタイムな共有である。
「これらはいずれも、基本的にはExcel業務のWebシステム化を実現することで、特別な工夫を必要とせず解決できるものだったのですが、一方でこのお客さまでは、既存業務における3つの点をWebシステム化後も継承していきたいと要望されていました」と赤羽根氏は語る。その1つめが、データ入力について従来Excelで行っていたのと同様の操作感を踏襲したい、2つめは各人が手元で自由に実施しているExcel上での集計・分析、シミュレーションを引き続き行いたい、そして3つめが集計結果にかかわる表やグラフを極力そのまま会議資料として配布したいというものである。
まず、1つめのExcelライクな操作感の実現についてシステムコーディネイトでは、グリッドライブラリを活用するという方針を固め、検討の結果、顧客が別システムで利用していたグレープシティの「Wijmo」の採用を決めた。
「Wijmo自体は、業務アプリケーションの広範な要件に応える各種UI部品を備えるJavaScriptライブラリのスイート製品ですが、そこに含まれる『FlexGrid』や『FlexChart』といったグリッド、チャート／グラフ部品も強力で、その活用により例えば右クリックによるメニューから行の追加や削除を行える機能や、ドロップダウンメニューによる項目選択などの機能を実装するなど、Excelに近いリッチなUIを実現することができました」と赤羽根氏は紹介する。あわせて、Webシステム上に表示された表やグラフを同形式でExcelファイルに出力できる機能もWijmoを使って実装。会議資料として即座に活用できるようにした。
一方、ユーザーによる集計・分析、シミュレーションの実施については、サーバーサイドのデータを使ってExcelファイルを生成し、ユーザーが必要に応じてダウンロードできる仕組みを整えた。そこではグレープシティの「DioDocs for Excel」を採用し、開発に役立てている。
「DioDocs for Excelは、Excelファイルの作成・編集にかかわる支援機能を備えるライブラリですが、プログラムで表やグラフのレイアウトを作成することができるほか、必要な構文をテンプレートファイルとして用意してセルに埋め込み、データソースからそこに所定のデータを適宜当てはめていくという使い方が可能。行や列の追加などもテンプレートファイルから判断してDioDocs for Excelが自動的に対応してくれます」と赤羽根氏は語る（図2）。
このようなライブラリ製品を活用するというアプローチを核に、顧客におけるExcel業務のWebシステム化を支援したシステムコーディネイトでは、工期、品質面でスクラッチ開発を凌駕する大きなメリットが得られたものと評価している。
Excel環境の再現にとらわれ過ぎず、Excelとの共存も視野に入れた検討を
引き続き行われたこの日最後のセッションでは、グレープシティの森谷勝氏が「現場の課題から見える脱Excelの分かれ目とソリューション」と題するセッションを実施。グレープシティに寄せられるユーザーからの相談内容に基づき、Excel活用にまつわる課題をピックアップして整理したのち、その解消に向けたシステム化の取り組みに関するポイントを解説した。
Excelの運用をめぐる課題としてまずあげられるのが、Excelファイルを複数人で共有しているために同時編集ができないことだ。もっともこの問題自体は、必ずしもシステム化によらずとも、クラウドサービスなどを利用することで解決できる可能性もある。しかし、年々Excelデータが肥大化を続けている問題や、Excelデータの二次活用をめぐる要求、あるいは現場で多用されているVBAコードを作成者以外がメンテナンスできないという属人化の問題なども顕在化しており、それら課題の解消を考えるうえでは、Excel業務のシステム化が最も有力な選択肢となる。
「ただし、単純にシステム化によって"脱Excel"を図るよりは、Excelを継続的に利用しつつそれと連携するシステム構築したいと考えるお客さまの相談も実際には多く、例えばExcelで扱っているデータは部署単位で管理できていればいいのか、部署横断での利用が望まれるのか、あるいは同時編集の問題がどの程度業務効率の低下につながっているのかなど、Excelのデータ活用や運用をめぐる諸事情を詳細かつ複合的に吟味して、最適なシステム化の方策を検討することが重要です」と森谷氏は語る。
そうした中、ユーザーにとって1つの有効な選択となり得るのが、機能要件に沿ったシステム化のアプローチだ。これについて森谷氏は「『表』としてのExcelからのシステム化」「Excel帳票からのシステム化」「脱ExcelではなくExcelと共存するシステム化」という3つのアプローチを紹介。そのポイントを解説し、そこで推奨されるグレープシティのコンポーネント製品を紹介する。
まず「表」としてのExcelからのシステム化だが、Excelにおける表の利用には大きく2つのパターンがある。1つは列ごとに項目が決まっているケース。「このような場合には、スプレッドシートコントロールでExcelの操作性を再現するよりは、グリッドコントロールへの置き換えが有効だと考えます。その理由としては、表の入出力だけに機能を絞ることができ、ページングなどグリッドコントロールにしかない機能が使えること、コーディングがシンプルであるとことなどがあげられます」と森谷氏は語り、Wijmoに含まれるFlexGridの活用を推奨する。
またもう1つのパターンは、列が可変で増減する表であるケース。こちらについては、Excelのピボットテーブルの機能が再現できるコントロールが推奨される。具体的には、Wijmoに含まれる、ピボットテーブル機能に特化したOLAPコントロール、あるいはピボットテーブル機能を備えたスプレッドシートコントロール「SpreadJS」がこれにあたる。「これら両者の比較としては、Excelに匹敵する詳細な制御などを行いたい場合にはSpreadJSが、よりシンプルな実装を行いたいというケースにはWijmoのOLAPコントロールが、それぞれ適しています」と森谷氏は説明する。
続いてExcel帳票からのシステム化については、Excelで帳票をレイアウトして印刷やPDF化の用途に供しているケースだ。これに関しては帳票ツールへのリプレースを検討するユーザーも多いが、そうするとそのツールが提供する専用のデザイナでレイアウトを作成せねばならず、使い慣れたExcelでレイアウトすることのメリットが失われてしまう。
システムにExcelファイルを取り込んで、そこにデータベースから取得した値をセットして帳票出力するという流れを想定するなら、Excel UIの再現性が高く、PDF出力にも対応するSpreadJSの利用が有効だ。一方、DioDocs for ExcelにもExcelを読み込んで帳票化する機能が実装されており、テンプレート構文という文字列をExcelシートのセルに記述しておけばデータソースから構文の指定に沿って値をセットしてくれる。
「特にDioDocs for Excelは、.NET環境で動くサーバーサイドに実装する、UIを持たない製品であり、バッチ処理やサービスプログラムとして動くという意味では、よりExcel帳票作成に向いているものといえます」と森谷氏は語る。
そして、脱ExcelではなくExcelと共存するシステム化だが、このアプローチにおいてもサーバーサイドでExcelファイルを操作できるDioDocs for Excelが極めて有効なツールとなる。それについては、システムコーディネイトによる先のセッションで示された事例からも明らかだろう。DioDocs for Excelでは、Excelに依存することなく、Excelファイルを作成・編集することが可能。Microsoft AzureやAWS（Amazon Web Services）、GCP（Google Cloud Platform）などのパブリッククラウドに配置される.NETアプリケーションで利用でき、仮想マシンやコンテナ、サーバーレスなどの方法で配備できる点もその大きなアドバンテージだといえる。
「Excel業務のシステム化にあたっては、複雑な実装となり、工数もかさむExcel環境の再現にとらわれ過ぎず、Excelとの共存も視野に入れた検討が望ましいと考えます。そこではコントロールの機能を最大限に活用し、いかにコード量を減らせるかを検討する。それが、開発コストを抑え、将来的にはシステムの保守性を高めるうえでの重要なポイントになるわけです」と森谷氏は強調する。
以上、「GrapeCity ECHO 2022」で実施された3つのセッションの模様をレポートしてきたが、イベントの最後のプログラムとして、受講者からの質問に講演者が答える質疑応答のコーナーも設けられた。そこで印象に残ったやり取りについても触れておこう。
「Excel業務のシステム化にあたり、Excelとの共存を考える場合、システム化する部分と、引き続きExcelを利用する部分についての切り分けをどのような基準で判断すべきか」という質問が受講者から寄せられた。
これに対しまず井上氏は「そこは、ExcelのデータとUIを含めたかたちで機能として実装すべきかどうか、要するにユーザーがシステム上でデータ入力を行う作業があるのなら、当然ExcelライクなUIを含めてシステム化することになり、Excel自体はクライアント側に置いて、サーバーサイドのOneDriveなどのストレージに格納されたExcelファイルにアクセスし、何か別の処理を行うというかたちになるでしょう。そうしたUIの必要性といったところが1つのポイントになるものと思います」と答えた。
一方、赤羽根氏は「もちろん、絶対的な線引きは難しいのですが、Web化の対象は集計プロセスまでにするのが手堅いのではないかと思います。私の経験でいえば、Web画面にExcelライクなUIを実装するのは、何かと苦労が多くなってしまいます。ExcelライクなUIは実装せず、集計結果をExcelファイルで提供し、ユーザーが手元で自由にいじっていける運用が望ましいのではないでしょうか」と応じる。
さらに森谷氏は「Excelファイルにアクセスする人数や頻度がどの程度か、Excelが扱っているデータの二次利用が必要かどうかというところで、システム化するか、そのままExcelで使い続けるのか分かれ目になるのではと考えます」と語った。
DXをにらんだ全社的なビジネスデータ活用に向けた情報共有の観点からも、WebをベースとしたExcel業務のシステム化は重要なテーマと目されている。自社のデータ活用やデータ運用のあるべき姿を踏まえ、最適なシステム化の着地点を見定めていくことこそが肝要である。
