しかも，旧版のExcelで開発したシステムのほとんどがそのままでは新版の上で動かない，というバージョンアップ問題がある。プログラムを改修すれば稼働するが，改修する暇や改修できる人が異動などでいなくなると，古いバージョンのまま利用しなくてはいけなくなる。また，開発したExcelシステムをファイル・サーバーに保存し共有する企業は多いが，その運用も厄介である。

バージョンアップでいつも苦労
　Accessがバージョンアップするたびに変換で苦労してます。Excelでもコード（VBA）を書いていれば当然のことのように動きません（たぶん）。おかげでいまだにAccessのVer.2があります（もう10年以上も前の製品だぞ）。
（40代，システム・インテグレーター，システムエンジニア）

対策に追われる
　Excelに限らず，サーバーの共有フォルダに置いてあるファイルに直接リンクを張ってしまうため，サーバー更新やフォルダ名の更新などを整理すると，業務部門から動かないと連絡があり，修正しなければならない事例が多々ある。
（30代，その他，情報システム部門）

　Excelレガシー問題は以前から存在していた，と指摘する読者もおられた。これもその通りと言える。EUC（エンドユーザーコンピューティング）という言葉は昔からあったが，90年代のパソコン普及とともに，EUCは本格化した。その結果，Excelを使った業務システムの利用者数も右肩上がりに増えていった。

新しい問題ではない
　Excelレガシーは決して新しい問題ではない。内部統制以前，90年代のEUCとパソコン教育が進んだ頃から，ユーザー部門の理工系出身者などがExcelの関数やマクロを駆使したシステムを作成したあと，開発者が転属などで「ブラックボックス化」することは発生していた。
　ユーザー部門で作成したExcelまで情報システム部門で管理することは，時間と人材の面から問題がある。ユーザー部門で作成したものは，ユーザー部門でメンテナンスができないと業務変化などにタイムリーに対応できない。情報システム部門は，ユーザー部門でのメンテナンスができる方法を教授するべきと考えます。
（50代，ユーザー企業，システムエンジニア）

EUCの価値を継承する
　今や「Excelレガシー」は企業情報システムにおける負の資産となりつつある。さらにそれが，企業の現場における情報システムのイノベーションの阻害要因となっているのも事実だ。しかしながら，マクロなどを含む複雑なExcelを使うという「技」は，1990年代のEUCの頃から培われたものである。したがって，情報システム部門に限らず他の業務現場におけるITスキルの向上は好ましいことと捉えることもできる。
　今後は，Excelの新バージョンがSOA（サービス指向アーキテクチャー）などの仕組みを実装することを通じ，他の新しいシステムとの連携を容易に図れる仕組み，あるいはExcelマクロをリバースエンジニアリングしてモジュールないしはサービスへと切り出す仕組みなどが求められるだろう。
（40代，その他，コンサルタント）

　レガシーとは遺産という意味であり，それ自体に悪い意味はない。遺産を将来にわたって活用できればそれにこしたことはない。ところが，遺産が重荷になってしまう現状があり，それを問題視しているわけである。さらに昨今の内部統制を巡る対策の一環として，Excelに代表されるスプレッドシートの管理を徹底しなければならなくなってきた。Excelレガシー問題への対処は，法的にも待ったなしになっている（関連記事「スプレッドシート統制，連結決算業務に注意」，「銀行はスプレッドシート統制に本腰を」。

　レガシー（遺産）はやみくもに否定すべきものではない。EUCやExcel利用を否定することばかりを考えては対策を見誤る。業務部門からExcelレガシーを取り上げても，問題は解決しないであろう。情報システム部門がExcelに変わる新しいツールを用意して業務部門に押し付ければ，現場は反発しかねない。そもそも，Excelの普及率を考慮すると，既存のExcelレガシーをすべて捨て去ることは現実的ではない。

　解決策として，上記の読者から「情報システム部門が，ユーザー部門でメンテナンスできる方法を教授するべき」，「Excelマクロをリバースエンジニアリングしてモジュールないしはサービスへと切り出す」といった意見が出た。他の読者の意見を以下に紹介する。

Excelの問題はExcelで解く
　解決方法はない。通常のシステムでもレガシー対策はないのに「Excelだから」という方法は考えられない。ただひとつ言えるのは「これを機にシステム化」という方向に走るのは誤りだということ。ExcelでできていることはExcelでやるべきで，それをWeb化することで問題が解消するような錯覚に陥る可能性が高い。だからマメにリファクタリングするのが最善策だと考える。そのためにソースコードをドキュメント化してくれるツールは有効かとも思う。ツールが効かないようなマクロはどのみち書き直すしかないのだから。
（30代，ハード・ソフトベンダー，システムエンジニア）

バランスが重要
　ユーザー部門所属だが，趣味がプログラミングだったりするのでExcelに限らず，WSH（Windows Script Host）などで小さなプログラムを作って自分や他のユーザーの業務に役立てている。あまり統制が強くなっては業務の改善が進まないし，逆に業務効率が落ちることが予想される。だが，管理する側の理屈も理解できるし，野放図なのは確かに危険なので，ある程度の管理の中でうまくバランスがとれるとよいのだが。
（30代，ユーザー企業，一般ユーザー部門）

　ここまで紹介した意見を読むと，利用部門がExcelアプリケーションを自分で作成すること自体は否定すべきではない，という点については一致している。業務に密着したアプリケーションを柔軟に改変していくには，メンテナンスも業務部門でやったほうがよい。情報システム部門は，Excel業務活用の支援組織と，従来よりは緩やかな管理組織として，自らの役割を考えることになるのだろう。

　読者意見にあったように，Excelレガシー問題を解く鍵は「バランス」にあると記者も考える。業務部門だけ，または情報システム部門だけが問題に取り組んでも解決することは難しい。本当は，経営部門まで巻き込んで対処策を考えるべき案件である。また読者が分類したように，一般的な業務アプリケーション，支援ツール（管理，設計など），個人レベルの便利ツールと，保有するExcelレガシーを分類し，それぞれにあった対策を講じる必要がある。

　ただし，経営者や業務部門が情報システム部門とともに，こうした問題に取り組んでくれるかどうか，となると現実にはそう簡単ではない。ある読者は次のようなメールを送ってこられた。

EUCはリスクそのもの
　EUCを排除する立場なので，Excelレガシー対策については意見を出せません。「人は間違える」が原則です。EUCは属人的にすぎ，リスク以外のなにものでもないと思っています。
（30代，製造業，情報システム部門）

　補足すると，この読者は自社の業務全体を細部まで熟知した上で，基幹システムを開発・運用している人である。現場に役立つシステムを提供できている，という自信あるいは意気込みをに裏打ちされたEUC否定意見なので，誤解されないようにしていただきたい。

経営のミスだが，“レガシー即廃棄”とはいかない
　タイトル自体は正直なので好感をもってアクセスしてみたが，中身は今ひとつであった。EUCを推進した組織であるほど，当然，Excelをはじめとしたマクロも多いことだろう。しかし，ひとことでいえば，経営側のミスである。
　組織で行動する前提の枠組みの中で，個人行動を促した労務管理・人事制度自体に欠陥があったのだ。短期的には，マニアを含めてIT知識が社内では上位の者に任せておくことで一定の効率化を見ることができるが，それはとうてい大局的見地とは言えないものである。
　命名自体には反対しない。記者以外を含め，新しい商品や造語は日々作成されている。もし多くの賛同が得られない用語であれば，一人言い続けても無視されるだけのことである。その立場にたったうえで，「レガシー」とされる機器類へのやみくもな否定的見解自体には反対したい。
　PBXのIP化が時期尚早であったのと同様，レガシー機器を使い続けることも経営的に戦略的な選択肢の一つである。汎用機ではコンピュータウイルス対策を事実上考える必要がなかった，といったようにレガシー機器の利用は悪いことばかりではない。私の勤務先では，特定の機器を制御するためにMS-DOSやWindows3.1が細々と動き続けている環境が残っている。スタンドアローンならば，動いている限りは更新するより絶対に安価だといえるからだ。
(40代，その他，情報システム部門)

　以上の指摘は，Excelレガシーに限ったことではない。個人の尖（とが）った活動を組織の大局的見地に合致させる舵取りが今後の組織運営の重要テーマである。また，レガシー機器についても，「経営的」「戦略的」なバランス感覚が求められる。報道においても同様と思うので自戒したい。