---

　最近、「折角導入したRPAをやめた」とか、「RPAには結局使い道がないことがわかった」とか、導入企業の担当者が愚痴をこぼしていることやネットでそのような記事を見かけることが多くなってきました。でも、「なんだか20年ほど昔、EUCでも同じようなことが起きたな〜。」とも思いました。今回は、ここ数年、爆発的に浸透したRPAで、今いったい何が起こっていて、それは何が原因なのかを、昔起きた時のことを参考に考察していきたいと思います。

---

¶ EUCとは

---

　突然ですが、EUCという言葉をご存知ですか？Webのエンジニアでしたら、日本語EUCなど文字コードを表すものとして覚えている方もいらっしゃると思います。ただ、EUCには、もう一つの意味があります。End User Computing（エンドユーザーコンピューティング）の略としての意味で、SEなどの専門家ではなく、現場部門の方が、自らプログラミングし、利用する形態や手法を言います。

---

¶ EUCの始まり

---

　1970年代までの一般的なITシステムは、専門のシステムエンジニアが、ホストコンピュータを使って開発していました。
　ところが、1980年代初頭、PC（Personal Computer）登場を契機に少しずつ変わっていきます。但し、当初は、一部のマニアがゲームをプログラミングをしているくらいで、実態としては、ホビーの域を出ないものでした。さらに、1980年半ば頃には、表計算ソフト（Lotus123、Excelなど）が登場し、徐々にビジネス用途としても使われ始めます。実はこのころ既にマクロ機能を有しておりエンドユーザーによるプログラミングが可能になりはじめていました。ただ、ここでも、まだ一部利用に限られていました。
　1990年、この遅々とした状況が変わり始めます。Windows3.1の登場です。それまでひたすらキーボードだけでPCを操作していましたが、Windows3.1では、マウスでアプリケーションを操作するといった、ユーザーにとって直感的で操作しやすいインタフェースを有していました。同時にWordやExcelなどのOffice製品もマウスで操作可能となり、その利便性が再認識され、徐々にユーザーを増やしていきます。さらに1994年になると、本格的なプログラミング言語であるVBA（Visual Basic For Applications）がExcelに搭載され、EUCの準備が整い始めます。
　そして、1995年、Windows95が登場し、全てを一変させます。今まで、安定性に欠くということで、本格的なビジネスユースからは、敬遠されていたWindowsが大幅進化してリリースされたのです。その後は、Unixのワークステーションやマックを蹴散らして、ビジネスユーザーを大幅に拡大していきます。そして、この頃からが本格的なEUCの始まりとなりました。

---

¶ 行き詰まったEUC

---

　専門の技術者ではなく、一般ユーザーが、自らPC上でプログラミングし、業務を自動実行させる。これは、当初、人間とコンピュータの関わりにおける新しい時代を象徴していて、あたかもバラ色の未来を描けるような幻想を抱かせました。しかし、すぐに行き詰ります。原因は、次の通りでした。

---

　1.時間ばかり掛かり、完成しない。
　2.折角作ったプログラムがちょっとした事で止まってしまう。
　　または誤動作する。
　3.作った人がいなくなると、誰も修正できない。

---

　1の「完成しない問題」は、速習本やノウハウ本が出揃うに従い、徐々に解決していきました。（今だとインターネットがありますが、当時はひたすら、書籍の情報にに頼るしかありませんでした。）
　それに対し、2の「止まってしまう問題」は、なかなか解決しませんでした。これは、速習本やノウハウ本で、わかるものではなく、そもそもエラーパターンを想定したシステム設計をしていないことが原因だったからです。システム設計？！エンドユーザーコンピューティングと相反するものですよね。折角素人が作れる環境があるのに、なんでプロと同じ知識が必要となるんだと…まさにジレンマです。
　どうにかして、ここも頑張って乗り越えたとしても、次の難関、3の「誰も修正出来ない問題」は、解決しませんでした。作った人がいなくなると、そのプログラムはブラックボックス化してしまいます。ただ、ちょっと状況が変ると、プログラムが止まったり、誤動作することが、しばしば起こります。その時、元々作った人がいれば良いのですが、いない場合は問題が発生します。誰も中身がわからないため、修正出来ないという問題です。こうした場合、中身を解析するにはプロのSEの手が必要となるという、これまたジレンマに陥ってしまうのです。
　通常、システム開発では、仕様書と呼ばれる設計書に従って作っていくので、後々、変更が必要になった場合、それを紐解いて理解すれば良いのですが、EUCの場合、そんなものはありません。こうして、EUCによるプログラムは、一時的に増幅し、その後、人が入れ替わるにつれ、徐々に使えないシステムが増えていき、やがて埋もれていきました。

---

¶ 2000年、さらに行き詰まる

---

　2000年代になると、この状況が更に悪化します。個人情報や機密情報などの取り扱いに関する社会的なルールやモラルが声高に叫ばれるようになり、EUCにより作られたプログラムもその影響を受けることになります。第4の問題発生です。

---

　4.会社のセキュリティーレベルをクリア出来ない。

---

　当然、他のプログラムや利用されていた業務パッケージも、当初、新たなセキュリティーレベルのクリアは出来ていませんでした。しかし、プログラムはSEにより修正され、業務パッケージはメーカーやベンダーにより更新されることにより、確実にキャッチアップしていきました。ただ、ここでも、EUCにより作られたプログラムは置いてけ堀を食らいます。
　例えば、数十人の部下がいて、勤怠承認を毎日しなければならない上司がいたとします。かなり面倒な作業ですが、本来であれば、厳密に一人ずつ確認していかなければならないため、毎日かなりの時間を費やす必要があります。ところが、この上司、ちょっとブロラミングの腕には覚えがありました。面倒なため、一括で承認を自動実行するプログラムを作ってしまいます。これは、どうなのでしょうか？セキュリティー的にはグレイですよね。さらに自分の代わりに部下にそのプログラムを実行させたりしたら、それこそNGですよね。EUCでは、このようなプログラムの増幅を止めることが出来ませんでした。
　以上の通り、EUCの幻想は脆くも砕け散り、制御可能にするためには、専門の部門やSEの開発への集約へと1970年代のホストコンピュータの時代まで後戻りしていったのです。

---

¶ RPAでも…

---

　今、RPAでも、特にデスクトップで動くタイプのRPA（このタイプはRDAとも言う）では、まさにかつてVBAを使ったEUCと同じような状況が起きているように感じます。ここ数年は、ベンダーの「誰でも簡単に出来る」という言葉に踊らされ、「時給に換算すると、人間と比べ格段に安い費用」だとか、「働き方改革の起爆剤」だとか甘い言葉で、RPA をやり始めたユーザー企業のなんて多かったことでしょう。
　もし、あなたの会社が、RPAを導入していて、エンドユーザーによるプログラミングをしている場合は、前述したチェックポイントを確認してみてください。

---

　1.時間ばかり掛かり、完成しない。
　2.折角作ったプログラムがちょっとした事で止まってしまう。
　　または誤動作する。
　3.作った人がいなくなると、誰も修正出来ない。
　4.会社のセキュリティーレベルをクリア出来ない。

---

　心当たりはないでしょうか？もし、1点でもあるのなら、そのRPA導入プロジェクトは、失敗する可能性が非常に大きいと思われます。特に、3の「誰も修正できない」問題は、痛恨の一撃になり得ます。なぜなら、それが問題となっていた1990年代は、まだインターネットが行き渡っていない時代でしたので、アプリケーションや業務の変化のサイクルが、比較的長めでした。従って、失敗が判明するまで、ある程度時間を要していました。ところが、現在は、ビジネスを取り巻く環境が猛烈な勢いで日々変化しています。従って、明日何がどう変わるかを誰も明確に予測出来ません。あなたの会社のRPAは、今日は動いていても、明日は動かなくなり、その時、誰も修正できないかも知れないのです。

---

¶ さらにRPAの場合は…

---

　さらにRPAの場合は、前述したこと以外の問題もあります。それは、「人間の代わりにロボットがPCの仕事をしてくれる」という幻想です。人間と同じことをやるようにプログラミングしたつもりでも実はそうなっていないところが数多く残されています。なぜなら、PC操作の合間合間で、人間は知らず知らずのうちに判断をくりかえしているからです。例えば、作業に必要になるファイルの名前が「入力ファイル20190501.TXT」の場合で考えてみましょう。しかし、実際は「入力ファイル190501.TXT」で、西暦の上2桁が欠け落ちた名称になっていたとします。その場合、人間であれば、「ああ、ちょっとファイル名が違うけど、このファイルだなぁ〜。」と判断し、次の作業に進めることが出来ます。しかし、この一見単純な判断が、RPAには出来ません。従って、RPAでは、このような場合を想定してエラーとしたり、絶対このようなファイル名の変更が起きえないよう前処理を変更しなければなりません。このように、RPAに適した業務の再設計をしなければならないのです。つまり、それが出来ないのは、以下の問題があるからだと言えます。

---

　5.RPAの特性を理解していない。

---

　RPAの難しさは、ここにあります。つまり、人間が通常何気なくやっている判断が不要になるように、業務を整理しなおさなければならないのです。このためには、人間とRPAの違いを理解した上で設計出来るかなり高度な知見や能力が必要となります。

---

¶ RPAで、EUCは2度死ぬ

---

　POC（Proof Of Concept）と称して、販社やベンダーは、簡単なプログラムで動作を実証し、RPAの本格導入へとユーザー企業を誘い込みます。それに安心したユーザー企業は、優秀な社員を集め、本格展開し始めます。ところが、販社やベンダーが、前述した課題を、ユーザー企業に共有することは、現状ほぼ有りません。ExcelのVBAで経験してきたことを顧みれば、自明の理のことなのにです。もう一度、先ほどのチェックポイントを見てみましょう。

---

　1.時間ばかり掛かり、完成しない。
　2.折角作ったプログラムがちょっとした事で止まってしまう。
　　または誤動作する。
　3.作った人がいなくなると、誰も修正出来ない。
　4.会社のセキュリティーレベルをクリア出来ない。
　5.RPAの特性を理解していない。

---

　RPAの販社やベンダーは、もう過去にあったVBAでの苦い経験を忘れてしまったのでしょうか？20年も前のことですので、確かにそうかも知れません。いや、実は、RPAのトレンドに乗ることが優先で、わかっていて販売しているようにも思えます。なぜなら、彼らの行う研修はツールの使い方だけで、肝になる部分は教えてくれません。そして、開発の場合は、瑕疵担保補償がない契約や、成果物が出来るかどうかさえ保証していない時間貸しの契約を要求します。これは確信犯かも知れません。そうです。彼らはRPAでの開発が、工数さえも計算できないと考えているので、このような契約形態を取りたがるのではないでしょうか？これでは、導入企業は、RPAの本格導入を開始するやいなや失敗するということが目に見えています。そして、いずれユーザー企業の数を減らしていき、販社やベンダー自身の首を絞めることになってしまうだろうと思われます。今後は、彼らが、過去の苦い経験を思い出し、または志のある販社が登場し、こうした障害を取り除くようなソリューションを展開してくれることを期待します（ただ、その際は、ユーザー企業側も、大幅に進化しなければならないとは思いますが、、、）。そうでなければ、残念ながら、「RPAで、EUCは2度死ぬ」日が来ることは間違いないと思います。

---