ローコード開発ツールが注目を集めています。
ローコード開発ツールは、高度なプログラミングスキルがなくとも、プログラムを開発できるプラットフォームのことです。Kintone（サイボーズ）や、Microsoft PowerAppsなどが代表的なツールです。
システム開発会社に依頼しないと開発や修正ができない（※控えめに言っても「限りなく難しい」）会計システムや人事システム、基幹システムや、物流企業であればWMS、TMSといったシステムと違い、ローコード開発ツールは、少ない教育・トレーニングで、業務において有効に活用できるアプリケーションを作成することができます。
一方、ローコード開発ツールによって、EUC（エンドユーザーコンピューティング）の課題が再燃するのではないかと心配する声もあります。
本稿では、EUC問題について、解説・考察します。
EUCが話題になったのは、1990年代後半から2000年代初頭にかけてです。
主として対象となったのは、ExcelVBAです。
ExcelVBAは、ローコード開発ツールとは違い、しっかりと勉強する必要があるプログラミング言語です。しかし、Excelの利便性を高めることができることから、プログラマーではない営業や経理、総務といった職務の人たちが、ExcelVBAを学び、業務で活かせるアプリケーションを次々と生み出すケースが発生しました。
かくいう筆者も、そのひとりです。
筆者が初めて作成したExcelVBAアプリは、販売実績の集計ツールでした。
当時、筆者は携帯電話の販売代理店で、量販店向けの卸部門に在籍していました。キャリア別、端末別、量販店別、店舗別、営業別といった切り口から、集計データを自動生成するアプリケーションを作成したのです。
他にも、トラックの運行実績をドラレコのGPSデータから取得し、配送先や高速利用の有無まで確認した上で請求明細を作成するツールを作ったこともあります。
ここまで複雑なものではなく、システムAからシステムBにデータを取り込むために、データのフォーマットを整形するExcelVBAは、いくつも作成しました。
筆者もそうでしたが、日本人ってExcelが大好きですよね。なんでもかんでも、とにかくExcelで行おうとするのは、世界的にも日本人だけだという話を聞いたことがあります。
業務系システムではできないことや、日常の業務において発生する「面倒くさい」を解消するために、ExcelVBAはとても使い勝手が良かったのです。
筆者の場合もそうですが、このようなExcelVBAアプリケーションは、従業員が、「業務を効率化したい！」という向上心を原資に自ら学び、自発的に作成したものです。
この向上心が災いし、企業（＝経営陣）からの業務命令として作成されたわけではない、言わば「勝手アプリケーション」がEUCという課題を引き起こしました。
最大の課題は、属人化です。
勝手に作成されたアプリケーションなので、「○○さんが作成したVBAだから、私は分かりませんし、修正もできません」となるのは当然です。そして作成した当人が異動してしまうと、アプリケーションの修正ができなくなります。
ところが、得てして「勝手アプリケーション」は現場課題の解決策としてとても有効で、現場で重宝に扱われているケースもあります。当然です。課題を感じていた当人が作ったアプリケーションなわけですから。
作成した当人が異動すると、「勝手アプリケーション」が徐々に不便になり、その不便さを補うために、手作業が増え…、といった具合で、長い目で診れば、「勝手アプリケーション」によって生産性が向上したはずの業務が以前の状態に戻ったり、かえって効率が下がることもあります。
次の課題は、セキュリティやトラブルの原因となることです。
「勝手アプリケーション」を作成した人は、プログラミングはできるかもしれませんが、システムマネジメントにおいては素人です。システムは動けば良いというものではなく、経営資源のひとつとして、きちんと統治され管理される必要があります。
- 正しい動作をしているようで、実は間違った動作をしていた。そのため、手作業で行っていたときにはあり得なかったミスを、長年に渡り引き起こしていた。
- 作成したExcelVBAがウイルスに感染し、情報漏洩を引き起こした。
- ネットワークに予想外の負荷を与え、社内ネットワークに障害をもたらした。
「勝手アプリケーション」は作成した当人にとっては業務改善や生産性向上につながっても、企業全体の状況を診れば最適とは言えない結果や被害をもたらすことがあります。
部分最適化が、必ずしも全体最適化につながらないことは、間々あることですから。
ちなみに、「勝手アプリケーション」のような、本来システムを統治・管理されるべき情報システム部や経営サイドが把握できていないITツールのことを、シャドーITと呼びます。
EUCの原因となってきたのはExcelVBAだけではありません。
Microsoft Access、FileMakerなどのデータベースアプリケーションや、他のプログラミング言語（例えば、GoogleAppsScriptやPythonなど）で作成された「勝手アプリケーション」もEUCの原因となってきました。
誤解しないで欲しいのですが、本稿は、EUCのリスクを知らしめることで、ローコード開発ツールの普及に警鐘を鳴らすことを目的としているわけではありません。
EUCという過去の課題を知っていただくことで、業務改善や生産性向上の可能性を広げるローコード開発ツールを適切に使って欲しいと考えています。
「ローコード開発ツールを導入したから、後は煮るなり焼くなり、君たちの裁量で自由に使ってよ！」──一部では、上司からこんなことを言われたという話が、既に聞こえ始めています。このような丸投げする姿勢では、かつてのEUC問題を再発させる可能性が高いでしょうね。
ExcelVBAにしても、ローコード開発ツールにしても、目的は業務改善や生産性向上のはずです。それなのに、例えば「改善はボトムアップで行われるべきだよね」などと言い訳して、従業員に丸投げするのは、ライン職や経営陣の怠慢です。
ボトムアップで業務改善・生産性向上を図るのは良いですが、その過程と運用は、ライン職・経営陣（あるいはしかるべき部門）のマネジメント下にあるべきです。
もっとも、ローコード開発ツールの中には、開発されたアプリケーションを管理者が一元管理・監視できるものもありますし、そもそもローコード開発ツールを購入するのは企業でしょうから。
「後は現場の君たちに任せた！」的な丸投げが発生する可能性は低いとも言えます。
従業員自らがアプリケーションを開発することができるローコード開発ツールは、企業の業務改善やデジタル化を推進し、生産性向上を飛躍的に向上させる可能性を秘めています。
ただ、過去の事例からEUCなどのリスクをきちんと把握した上で、適切に取り組んでいきたいものです。
