EUCツールは「悪」なのか？？
はじめに
EUCとはご存知の方も多いと思いますが、End User Computingの略称です。 エンドユーザの方々が、自分や部署の業務負荷軽減、ミスの軽減を目的として、ExcelやAccessなどのVBA（Visual Basic for Applications）、関数を駆使して業務特有のツール（＝EUCツール）を作られている事例は数多いでしょう。
筆者が大学4年生の時、内定をもらった会社から入社前研修のテキストとして郵送されてきたのは「エンドユーザーコンピューティングの基礎」というタイトルの本で、コンピューターの歴史に始まり、コンピューターの業務への浸透度合い、そして今やエンドユーザー自らが業務に沿ったツールを作成する時代である、という内容であったと記憶しています。
なお、当時の筆者にはチンプンカンプンな内容でした（笑）
EUCツールのメリット／デメリット
EUCツールは業務をよく理解しているエンドユーザが作成するため、業務への親和性が非常に高いという特徴（メリット）があります。
他にも
・業務内容に多少の変更があった場合でもある程度はエンドユーザにて改修可能
・基幹システムの機能を一部EUC化することで、基幹システム側の開発・保守が容易
・情報システム部門の負担軽減
などが挙げられます。
しかしながらデメリットがあることも事実です。寧ろ、そちらのほうが数多く挙げられるためか、「EUCツール＝悪」というような風潮があるように（個人的に）感じられます。
EUCのデメリットは多々ありますが、
①属人的側面が強い
②スクリプト言語でのコーディングのため処理が遅い
③情報システム部門管轄外のため、”野良ツール”が無尽蔵に生み出される④ExcelやAccessベースであるため、UI／UXを考慮したデザインがされない
という点についての対応案を少し考察していきたいと思います。
デメリットへの対応案
①「属人的側面が強い」というデメリットへの対応
EUCツールは作成者にしかロジックや機能の詳細がわからず、設計書はおろか、マニュアルが作られない事がほとんどです。つまり、作成者が部署異動や退職等で離任することで誰もこのブラックボックス化したEUCツールをメンテナンスしたり仕様変更への対応ができないという問題が発生します。（ソースを解析するにしても一からロジックを追って、内容を理解する時間が必要です）
これに対しては、全てを作成者に丸投げするのではなく、
・利用者からのヒアリングを実施し、「要件」をドキュメントとして残す
・概要設計書くらいは作成し、上席の方とのレビューを実施する
・マニュアルは実際の利用者と共に作成する（EUCツール作成者主観でのマニュアルは言葉足らずな場合が多いです）
等、利用部署全体で取り組むことが重要かと考えます。
②「処理が遅い」というデメリットへの対応
VBAなどのスクリプト言語は簡易的なプログラム言語であり比較的習得しやすいという反面、処理実行時に命令を逐次解釈するという「インタプリタ方式」を採用しているものが多いため、CPU、メモリをフル活用しているにも関わらず、処理が遅いという避けられないデメリットがあります。
ややもすれば、EUCツールを動かしている裏で別の業務をすると、パソコンの冷却ファンは「フフィーン」と悲鳴を上げ、ディスクのアクセスランプは小刻みに点滅し、パソコン本体は発熱、画面には「応答なし」のメッセージが表示されたまま画面が固まり、業務が全く進まないという問題も発生します。
これに対しては、EUCツールで担う処理を分割して、個々のEUCツールで実行する命令数を削減するのが良いかと思います。（複数のツールを同時実行してしまっては意味がありませんが。）
分割しすぎて業務の煩雑さが増してしまっては本末転倒ですが、適切なEUCツール分割を行うことで業務全体の効率化を図ることが可能かと考えられます。このEUCツールの分割についても、作成者が属人的に行わず利用部署全体で行なう必要があります。
また、スクリプト言語とは関係ありませんが、ExcelのシートやAccessに蓄積されたデータを参照している場合、その蓄積されたデータを削除することでもパフォーマンス向上が見込まれます。
なお、削除前にEUCツールとは別のExcelやAccessにデータを退避しておくと、万が一の際に元に戻すことが可能です。
③「”野良ツール”が無尽蔵に生み出される」というデメリットへの対応
業務に必要、または業務改善が見込まれるという理由で、都度新しいEUCツールが作られてしまいます。利用部署ではほとんど管理されていないため、同じようなツールが作成されたり、数えるほどしか使用されないツールも出てきてしまいます。
情報システム部門を巻き込んで管理するということも考えられますが、逆にスピード感が失われてしまうことも受け入れなくてはなりません。
したがって、結局はこちらも利用部署において管理することが王道では無いかと考えます。
④「UI／UXを考慮したデザインがされない」というデメリットへの対応
ExcelやAccessがベースであるため、オブジェクト（部品）のデザインが決まっており、単調な画面になりがちです。UI／UXが考慮されていない操作性や視認性の悪い画面は操作ミスを誘発し、その都度リカバリーに時間が掛かるようでは本末転倒です。
UI／UXを十分理解したデザイナーが介入すれば、ある程度見栄えの良い画面がデザインされるかもしれませんが、やはりオブジェクトのデザインが決まっていることから期待値ほどの効果は見込めないかと考えています。
UI／UXを反映させたデザインを取り込むことを望むならば、EUCツールは諦めてWEB化などを検討すべきでしょう。（WEB化することで今まで挙げたデメリット全てが解決されますが・・・）
最後に：EUCは決して「悪」ではありません
EUCツールには諸々の課題はあるものの、やはり利用部署にとっては業務への有効性、貢献度は高いでしょうから、全く「悪」ではありません。
ある程度しっかりした開発工程を踏み、要件定義からリリース後のツール管理において利用部署全体で取り組み、パフォーマンス問題やUI／UXを反映したデザインとしたい、といった場合は情報システム部門と協議の上、コスト、期間を十分勘案してWEB化のご検討をしてみるのが良いのでは無いでしょうか？
もしこの記事を読まれてEUCツールの改善を検討したい、ツールのWEB化を進めたいとお思いの方は是非こちらからお問い合わせください。
これまで、当社のnoteでは開発事例を上げてきましたが、今後はこういった考察記事も上げてゆく予定ですので、ご一読いただければ幸いです。