6月25日に公開したコラム「記者のつぶやき」の中で,“Excelレガシー”に関するご意見を募ったところ,ITpro読者10人の皆様から頂くことができた。この場を借りてお礼を申し上げる。“Excelレガシー”は,企業の業務部門が表計算ソフトExcelとその関数やマクロを使って自ら開発し,利用を続けてきた業務アプリケーションである。先のコラムにおいて,日経コンピュータ誌は「Excelレガシーが継続利用できない状況にある」という問題を提起した。以下では,読者から寄せられた意見をもとに,Excelレガシーが直面する問題について一緒に考えてみたい。

 その前にお知らせが二点ある。ITpro読者からご意見を頂きつつ,日経コンピュータ7月9日号に「“Excelレガシー”再生計画」と題した特集記事を掲載した。Excelと上手に付き合っているユーザー企業やExcelの利活用に詳しい識者を取材し,Excelレガシーの問題に立ち向かうための十箇条をまとめたので参考にしていただけたらと思う。

 さらに本日7月10日から,特番WebサイトEnterprise Officeに,「Excelレガシー再生計画」というコーナーを開設した。ここでもExcelレガシーに関する情報を発信していくので,併せてお読み下さい。

 さて,Excelレガシーの継承性という問題そのものを疑う意見は無かった。読者の周囲で実際に問題が起きているからだろう。Excelレガシーについて発生原因まで含め,分かりやすくまとめてくれた読者がいるので,まずそのご意見を紹介する。

開発は楽,メンテナンスは大変
 Excelレガシー,非常にいい言葉だと思います。一般ユーザーの中に“Excel使い”がいると,関数などの機能をフル活用し,時にはマクロまで使って,あっと驚くような機能を実現している場合があります。それ自体はすばらしいのですが,Excelレガシーの問題点として,メンテナンスが困難という点があげられると思います。
 セルに関数が埋め込まれていたり,マクロを呼び出していたりすると,開発した本人でない限り,なかなか理解できません。通常のプログラムであればソースコードを見れば一発でわかりますが,Excelではそうはいきません。また,Excelの場合,データとプログラムが一つのファイルに合体しており,これも問題です。マクロを修正する場合,同じマクロを持つファイルが複数あると,すべてを修正しなくてはなりません。
 お手軽ではあるけども,メンテナンスが大変,これがExcelレガシーに対する私の結論です。所詮,Excelで複雑なことをやろうとするのは間違っていると思います。その一方で,Visual Studioなどできちんと開発すると手間がかかって仕方がない,というのも事実です。Excelのように簡単に開発できて,なおかつ,メンテナンスが便利なツールがあればベストなのですが。
(30代,ユーザー企業,情報システム部門)

 確かにExcelはとても便利なツールである。Excelを使って作ったアプリケーションと同等のものを,通常の開発言語を使って開発しようとすると,文字通り桁違いの工数が必要になるだろう。開発の生産性が高いため,エンドユーザーが本格的な業務システムを開発できる。ただ,その結果,Excelシステムが業務部門のあちこちで無秩序に作られメンテナンスできない事態に陥ってしまう。さらに,Excelシステムを開発した本人が異動などでいなくなり,メンテナンスができなくなる事態になる。このあたりの事情をアプリケーションのジャンル別に整理してくれた読者がおられたので,その意見を次に紹介する。

開発した本人がいなくなる
 VBA(Visual Basic for Applications,Excelのマクロなど)は,VB(Visual Basic)より旧バージョンとの互換性がある。この点は案外見直されている。ただしJavaやPHPなどのフリーソフト言語にくらべて言語としての人気は低下しつつある。LookupのようなExcelの関数まで対象とすると話が広がるので,「VBAアプリケーション」のみを対象とすると各ジャンルの状況と対策をまとめると次のようになる。

1)一般的な業務アプリケーション(会計・販売・人事・その他の事務)
 従来のVBやAccessアプリケーションと同様に,共有のアプリケーション資産として管理・保守すべき。ただしセキュリティにうるさい昨今,VBAで十分作成できる業務アプリケーションでも,データ保護の観点からWebアプリケーションとして本格的に開発されるものに移行されることも多い。
2)支援ツール(管理,設計など)
 プロジェクト作業などの管理資料や設計資料で,Excelシートが頻繁に使われるため,それに付随してVBAが多用される。ただし,プロジェクトの当初は,“VBA職人”がいたが,システム稼働後の保守段階に入るとVBA職人がいなくなりメンテナンスに困るケースも多い。
3)個人レベルの便利ツール
 VBAを使いこなせる器用な人が自分の業務を簡素化しようと自前で作ったアプリケーションなどを指す。本人だけが使っているうちはいいが,使い勝手がいいと他の人に渡った後に本人が異動してしまうとメンテナンスが不可になり,業務に若干支障きたすことも多い。
 対策としては開発者本人の手を離れて共有のアプリケーション資産となった場合に一応の管理対象とし,内容に熟知した本人が異動する際には内容を引き継ぐ。できれば情報システム部門にいるVBAのベテランのような担当者に,メンテナンスとバージョン管理などの引継ぎを依頼しておく。本来これは情報システム部門というより,各事業部門の管理職のチェック事項であろう。どんな資産があるか,最低限リスト化くらいはすべきである。
(40代,通信事業者,システム企画部門)

 事業部門の管理職が自分の部門で利用されているExcelレガシーのリストを作っておくべき,という主張はその通りであるが,現実にはそうなっていない場合が多い。また,「情報システム部門にいるVBAのベテラン」がそもそもいないこともある。こうした状況下にもかかわらず,何年も前に開発したExcelレガシーが現役で使われているケースはある。ひとたび不具合が起き,業務に支障が出るようになっても,直すことができない。まさにExcel版の2007年問題である。

次ページへ続く