日々の破片

_ RPAとは何か？ EUCとは何が異なるのか？ なぜ誰も知らないのか？

羽生さんのいきいき塾特別編に参加して、羽生さんが見た聞いた実感した「これからはRPAですよ！」を聴講。その後で、酒匂さんやいがぴょんさんと少し討論。

おもしろかった。

RPAが何かは、なんとなく理解していたし、その点では「なんだやっぱりそうだったのね」なわけだが、羽生さんのユーザー環境体験を（UXではなくEUEXと呼んでみよう）聞いて目から鱗ばぼろぼろ落ちまくって足元に溜まりまくって身動きが取れなくなるほどだった。

そこに酒匂さんの懐疑的な見解が出る。

だが、それは違うと直観的にわかった。酒匂さんは、すごい人だが、ことこの点については宇宙飛行士観点でRPAをEUCの延長として捉えているのだ。つまり、エンドユーザーによる局地最適化（部分最適化に輪をかけて悪いレガシーの導入）という観点だ。でも、そういうことではない。

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)(バートランド・メイヤー)

(酒匂さんといえばメイヤーの訳業だが、地味だが、どう作るかではなく何を作るかをちゃんと考えようよ本は好き)

課題・仕様・設計―不幸なシステム開発を救うシンプルな法則(酒匂 寛)

EUC（エンド・ユーザー・コンピューティング）というのは、普通にイメージすれば良い。

経理のおっさんが、そろばんやら電卓やらで給与計算しているうちに、ふとExcelに着目する。

こいつで計算すれば良いのでは？

そこで、教本片手にExcelの関数を調べ、マクロを調べ、さらにはVBAで入力を簡単にするフォームを作り、それまで3日かけていた給与計算を2時間で終わらせるようにする。やった！

というのが、1995年前後のEUCで、適用分野が変わっても、それから30年たってもEUCはEUCで、全社システムと無関係、または全社システムがそもそも存在しない環境で、コンピューターのエンドユーザーである経理のおっさん（の必要はなくてお姉さんでも少年でもなんでも良いのだが、イメージは経理のおっさんだ）が自力で作ったシステムを指す。

それ自体は正しいコンピューターの使い方なので、どこにも問題はないのだが、問題または軋轢が生じることがある。

今、SIerが自社製品のERPを持ち込む、あるいはSAPなどのパッケージを担いで売り込みに来る。おお、これは素晴らしいと社長が言って導入が決まる。もちろん、現行システムの計算ロジックを踏襲するのだよね？ もちろんです！

そして地獄が始まる。

元の経理のおっさんが

・現存するが、非協力的。だって俺様が作ったExcelを排除する気なんだろう？

・すでに定年退職しているので、今いる人たちは何もわからない。とにかくExcelブックを開いて何か入力すると結果が出てくるということしか知らない。

という状態のときに、エンドユーザーならではの

・仕様書がない

ことにSIerは愕然とする。え、これで給与を計算しているんですよね？ 仕様書はどこ？

もちろん、仕様書なんかあるわけがない。元の経理のおっさんの頭の中にあり、VBAの中に時にはコメントアウトの固まりで、時にはバグが残ったまま、継ぎ足しと思いつきのテスト無しリファクタリングによる意図不明な関数化やその時その時の気分の変数名やらもろもろがすべてだ。

つまるところ、動いているプログラムは何よりも優れたドキュメントだからどうにかなりそうには見える。VBAはソースコードがそのまま残るし。

しかしおもしろいことに、現行システムの分析は要件定義（要件を現行踏襲で済ませれば、現行機能からの基本設計起こしでも別に構わんが）の範疇なので、いわゆる上流SEの作業となるわけだ。

もちろん、上流SEはプログラムを読めない。

いや、3か月ほどJavaの研修は受けたかも知れない。でも、VBAは読めない。

そうはいってもVBの文法は単純なのでどうにか読めはするだろう。しかしExcelのオブジェクトモデルは知らない。それでもMSDNを調べてオブジェクトモデルを理解したとする。でも、型がない。イベントドリブンによるプログラム構成を理解できない、Excel関数なにそれ？

まあ、能力不足なわけだが、そうは言っても予想もしていなかった、工数が必要となる。当然、プロジェクトの進捗に支障が出る。しかも経理のおっさんだけならまだしも、営業の部長かなにかが暇に飽かせてこしらえた営業支援システムが営業2部にはあり、営業1部には、独自に導入して何かどこかで設定を間違えたのを運用でカバーしているパッケージ（今、SIerが導入しているものとは縁もゆかりもない）が勝手に動いている……絶望だ！

というわけで、利害関係がある連中（ERP系SIer、パッケージ業者）が声高に排斥するのがEUCということだ。

でも、RPAは全然違う。

EUCとの共通点は、現場で作って現場で運用しているという、ただその1点だ。

本質がまったく異なる。

EUCは、それそものもがシステムだ。しかし、RPAは、それはシステムではなく逆にエンドユーザーの作業でしかない。エンドユーザーのPC上のエージェントとなって、代理するだけなので、正しくロボット（機械労働者、当然、どこにも頭脳（システム）は存在しない）なのだった。

だから、端的に言えば、RPAはエンドユーザーにとってはブラックボックスではなく（この比喩で言うと、EUCはエンドユーザーが自分で作ったブラックボックスである）、エンドユーザーが正しくコンピュータを利用するための初めて目にするツール（いや、当然なのだが、エンドユーザーには「ツール」という概念がそもそも存在しない）なのだ。

コンピュータは、人間の能力を解放するわけで、それはシステムにからんでいれば普通のことだが、エンドユーザーにとってはそうではなく、それは上から押しつけられた新たな労働（作業）で、そこに対してボタンを押したりキーを押したり、デバイスから何かを読み込ませる、ことで賃金がもらえる何かの機械でしかない。

でもRPAによって、コンピューターを利用できるようになったのだ。

これは大いなる意識改革だし、すごいことだ。

そういうことだったのか！

（RPAの本質はつまり、エンドユーザーがコンピューティングを獲得するための手段であり、システムを自分事として理解するための取っ掛かりで、これがあって、初めてなるほどコンピューターというのは便利なものですな、と発見することなのだが、では具体的に……となる前に疲れたのでとりあえずここまで）

_ RPAとは何か？ EUCとは何が異なるのか？ なぜ誰も知らないのか？(続き)

RPAは、スクリーンスクラッチャー（今作った言葉）だ。やれることは、PCの画面の上を引っ掻いて回ることだけだ。どこにもインテリジェンスがない。

たとえばSeleniumを知っていれば話が早いし、Win32APIを知っていれば、GetWindowHandleしてSetFocusして、SendInputするプログラムをエンドユーザーがお絵かきツール（というよりも、eToyを想像すると良いかも知れない）で作ると考えれば良い。

つまり、人間の操作の自動化である。

羽生さんは、UIPathでメモ帳を起動して文章を入力して名前をつけてファイルに保存するデモを見せてくれたが、重要なのは何をするかではなく、それがお絵かきツールで作れるということだ。

これは明らかにEUCではない。

なぜなら、こうやって作られたRPAの成果物（以降、スクリプトと呼ぶが、もちろん、PythonやRubyで作るプログラムを想像してはならない。せいぜい、パイプを使う#!/bin/shスクリプト程度だ）には、どこにもビジネスロジックがないし、データもない。あるのは、ユーザーオペレーションを再現するためのスクリプトだけだ。それは、まともなシステムであれば、マニュアルに記載されている。したがって、レガシーにすらなりようがない。

想像するに、RPA作りにはそれなりのノウハウは必要だ。だが、それは一般化できない現場オリエンテッドなものなので継承する必要すらないものだろう。

たとえば、メモ帳でファイルを名前をつけて保存をすることを考える。

Alt-Fに続いてAを送る。ここまではOKだろう。

しかし次の一手としてファイル名を入力したり、文字コードを選択するには、モーダルダイアログのオープンを待つ必要がある。それが1秒か3秒か0.5秒かは、利用しているマシンのスペックに依存する。

そこで、たまたまsleep(1)で、動いてるからといって来月もそれでいけるかどうかは誰にも保証できない。仕込まれているウィルス検索機のダイアログオープン時の処理が重くなるかも知れないし、Windows Updateでメモ帳のダイアログの形式が変わるかも知れない。

でも、大丈夫。もしエラーになったら、作り直せば良い。そのためのRPA IDEだ。テストくらいはするだろうが、リリース管理もバージョン管理も必要ない。なぜなら、上で書いたタイミング調整のようなものはビジネスロジックではなく、単なる運用上の差異だからだ。

RPAは単に人間の操作を再生するだけのスクリプトだから、スクリプトが失われても何もビジネスは失わない（3秒のボタン操作が、30分の人間操作に戻るので、時間は失うかもしれないが、EUCの仕様のなさとは次元がまったく異なる）。

・歴史（メモがないので数字の正確性はあやしい）

羽生さんの調査によれば、RPAの歴史はものすごくいびつだ。

まず、ガートナーのハイブ曲線についていえば、2016～2018の間にグローバルでは一切存在しない。

日本固有のハイブ曲線についていうと、2017年にいきなり頂上にあり、2018年に安定の少し下がった位置につく。

日本固有のものか？ でも、上にリンクを張ったUIPathをはじめ、海外製のRPAツール（スクリプトを作成するためのIDE）がそれなりの数が出ている。日本だけでビジネスできるわけがない。したがって、動いている金額はグローバルでもそれなりのはずだ。

でも、もちろん、ガートナーのグローバルハイブ曲線は、われわれの感覚に近い。

つまり、RPAをシステム屋やソフトウェアは知らない。それがどこにあり、だれが買っているのか。

それは知らないうちに、ユーザー部門に入り込んでいるのだ。

でも、それをEUCの同類とみなして排斥するのは、愚かだ。

なぜならば、それはEUCとは異なるからだ。つまり、ビジネスとデータが存在しない。

なぜ、ガートナーのハイブ曲線ではトレンドとしてつかめないのか？ たまたま日本では、三菱UFJ銀行の事例が大きく取り上げられたからではないか、というのが羽生さんの見解だ。

もしそれがなければ、ユーザー部門主導（ベンダー主導でもなければ、プラットフォーマー主導でもなく、もちろんコミュニティ主導でも、技術主導でも、研究主導でもなければ、まあ目に入るはずないね。でも、その視野の狭さは我が事ながらおもしろい）で知らないうちに広範に利用されている実態がIT業界に見える化されることはなかったのだろう。したがって、グローバルなハイブ曲線には影も形も現れない。

次に、ProsとConsについて考える。

おれは基本的にConsは存在しないと考えている。

逆に、すべてを徹底的に管理したい人にとってはConsしかないだろう。たかがスクラッチャーなスクリプトとは言えソフトウェアである限り、バージョン管理、リリース管理、仕様書、QAが必要だと信じ込んでいればそりゃそうだ。ビジネスロジックはなくても、ビジネスのコンテキストで実行することに変わりはないわけだし。そもそもおれの目の届かないところで勝手にソフトウェアをインストールするんじゃねぇ、それはコンプライアンスに反しますると大騒ぎする連中もいるだろう。

したがって、三菱UFJ銀行の事例のように経営主導で導入すべきものではあるだろう。

だが、そこにはおれは興味はない。そうではなく、ユーザーの意識に与える自由が重要だと考えているからだ。

つまりProsは、ユーザーとビジネスで利用するコンピュータの関係の正常化にあるとおれは考える。

まず、ユースケースについて考える必要がある。

本来、システム間の連携はシステムで行うものだ。

しかし、そこに人間の介在が必要となるニッチが存在する。RPAはシステム化できなかったニッチを埋めるものだ。

たとえば、タイムカードの入力という簡単な処理を考えてみる。

従来は、事業所の入り口にあるマシンに退出側の箱から自分のカードを取り出して、マシンに通して打刻して、出勤側の箱に入れていたとする。それにしても何十年前のシステムなんだというのはおいておいて、そういうものだったとする。

システム化したから、もうカードと打刻機は不要となり、オフィスの机の前に腰かけて、PCの電源を入れて、デスクトップ上のショートカットをクリックしてIE11（Windows10になってよかったね。でもEdgeじゃなかったりして）を起動して、打刻ボタンを押して、もう使わないし、残しておくとメモリを食って次の作業の邪魔になるのでIEをクローズする。

まあ、この程度であれば、RPAも必要ないだろう。

しかし、すべての事業所がイントラネットで結ばれているわけではないものとしよう。さすがに東京と大阪の間には太い専用線を前世紀から利用しているので、大阪事業所の人たちも東京本社の打刻用Webサーバーにアクセスできることになっているとする。

でも、四国や九州の事業所ではそうはいかない。よくわからないがセキュリティが危ないので、東京本社の打刻用Webサーバーにはこれらの事業所からはリーチできない。VPN何それ？

というわけで、四国や九州の人たちは、代わりに出退勤をExcelに記録して、月末に本社の人事に各自メールに添付して送るというばかげた運用となった。まあ、送る人たちには我慢してもらうとして、本社の人事の人たちはどうするの？

幸い本社のWebサーバーにはExcelアップロードボタンがあって、ボタンを押すと、該当Excelの送り主の社員コードを入力し、事業所をドロップダウンリストから選択して、ボタンを押してExcelを選択して（ということは、メールの添付ファイルを一度ディスクに保存する必要もあるってわけだ）、そして送信ボタンを押すと、ダイアログがポップアップして、～事業所の社員コード～のExcelブック～をアップロードしますか？ OK/キャンセルが表示される。そんなことは言われんでも今入力したじゃないか、くそばかシステムのばーかばーかと思いながら、確認しないでOKをクリックする。ふー、一息ついてメールボックスを見るとあと138人分残っている。

なんか、前のシステムのほうが楽だったなぁ。で、一日つぶれる。明日の営業研修用の資料をこれからまとめなきゃならないのに、なんてこった！ 残業だよ、とは言っても、水曜日だから残業はないってことで（と、Webサーバーに本社勤務だから退勤ボタンをクリックしてから）資料作りを始める。（運が良ければ、各事業所内の所長が確認したこととして、所長からの1つのメールに全員分のブックが添付されているかも知れないが、そのメールを開くのは地獄の刑罰なみに時間がかかるだろうなぁ）

本来であれば、全事業所が仮想的であろうがそうでなかろうが、同じネットワークの中で利用すべきものが、予算の関係でそうなっていないような場合に、上記のような異常事態が生じる。

幸い北海道事業所は主要な取引先が多いので、前世紀から専用線が引かれている。32Kbpsだぜ。というわけで、タイムカードの打刻に20分かかる。そもそもマシンも前世紀に導入された512MBのP3マシンだ。OSの起動に5分、IEの起動に5分かかるからそりゃそうだ。おれの貴重な朝の20分の間にさっさと客先に行きたいのだが、たかが4回クリックするだけのためになぜ、これだけ無駄な時間を使わなければならんのか。これどうにかならんのか？

こういった状況に対してRPAが提供されれば、そりゃ救世主でしかない。

スクリプト実行ボタンをクリックすると、Outlookを開き、件名に【タイムカード】が入ったメールを開き、添付ファイルを保存する。保存した添付ファイルをエクスプローラで開いて、2番目のセルから社員コード、3番目のセルから事業所名を取りだす。（Excelブック内に入っているのに、アップロード時のダイアログに入力させることで確認しようという素晴らしいシステムなのだな）、デスクトップ上のショートカットをダブルクリックしてIEでアップロードページを開く。その前にログインページだ。ユーザーの社員コードとパスワードはスクリプト内に入っていて自動入力されてOKがクリックされる。アップロードページに遷移するまで10秒（長すぎるけどまあいいや。短いとエラーになるし）待って、Excelブックから取得した社員コードを入れて、タブキーを送って、事業所を選択して、タブキーを送って、クリックを送って5秒待ってファイル名を入れて、OKをクリックして、3秒待って次のポップアップのOKをクリックして1分待つ。IEのXボタンを押して終了して（というように、作ってしまうところがエンドユーザーならではだし、多少工夫して2度目のループからこの処理をスキップするように作る人もいるかもしれないが、どうでも良い）、ExcelのXをクローズして、保存しますかにNoをクリックして、Explorerで開いてある添付ファイルを選択、右クリック、削除、OK、Outlookに戻って次の【タイムカード】を選択……というのをPRA用マシン（これだけは新規に導入）に実行させておいて、自分の本来の作業に取り掛かる。その間5分。

もしかすると、ふとRPA用マシンを見ると、Excelが開かれたままになっていて、3個しか送れていないかもしれない。RPAにはインテリジェンスはないから、タイミングによってそりゃ起きる。でも、問題なし。Excelを終わらせてやって、状態を整えて、再実行すればよい。いずれにしても、このくらいの手間で済むなら大した問題じゃないね。

同じように北海道の人も、PCの電源を入れて、客先訪問の準備をしている間にマシンが立ち上がる。ボタンを押して、あとの処理よろしく！ と出かける。あとはRPAが勝手にやっておいてくれる。

ここで観点は3個ある。

経営者観点からは、RPA用の金（専用マシン含む）、スクリプト作成のための作業時間を許容すること、がコストだが、VPNとかよくわからないものやセキュリティリスクがどうたらみたいなよくわからない話で積みあがる全社ネットワーク接続に必要なコストを無視できるだけで、それ以上でもそれ以下でもない。実際、なくても、サービス残業でどうにかしてくれるわけで、知ったことではない。（もしかすると、人事が地方から送られてくるExcelタイムカードをさばくために雇っていたアルバイト3人が不要となる可能性は高い）

システム部にとっては、ちょっと怖い。特に、なんだかよくわからないスクリプト内にタイムカードアップロード権限を持つユーザーIDとパスワードが平文で入れられるところとか恐怖だ。（が、実は、担当者の不在時に誰でもタイムカードをアップロードできるように、PCにはユーザーIDとパスワードを書いた付箋紙が貼られている実態を知っているので、要はシステムの結合が不完全なのだからしょうがないとわかっている上司が黙認しているので自分も黙っている）というか、ちゃんと期限内にデータがアップロードされていればどうでも良いというのが本音だ。

ユーザーにとってはどうだろうか？ 間違いなく楽になったので、それははProsだが、重要なのはおそらくそこではない。

そうではなく、RPA導入前には延々と決まりきった作業を繰り返させられていたのが、言い換えるとコンピュータ（というかシステム部が勝手に導入したなんだかわけのわからない勤怠システム）のために自分が奴隷のような作業をしていたのが、RPAツールを使って自らスクリプトを作ってそれを実行するようにしたことで、言い換えると自分が本来すべき処理をコンピュータが自動的に実行するようにすることで、コンピュータとユーザーの関係を180度転回したことにある。

これがEUCではないのは、システムそのものは何も変わっていないことから明らかだ。

では何かと言えば、ユーザーの作業の素朴な自動化に過ぎないわけだが、明らかにコンピュータとユーザーの関係が、主人と奴隷から、奴隷と主人に逆転している。

これはすごい。

システム的には、くだらないとは思う。まず、システム化が中途半端だし、インフラがそもそも不足しているのが問題だ。UXもよろしくない（大体Excelシート内の情報をわざわざアップロード時に入力させたり確認させたりすることがばかげている。そんなもの形骸化するのは自明過ぎる）。この運用（厳密なユーザー権限による運用が不可能という前提）であれば、アップロード処理はユーザーID/パスワードよりも、端末のアドレス縛りのほうがまだましだ。

いずれにしても、RPAのユースケースは上記のような、システムのニッチを埋めるために必要となる手作業の自動化にある。

このような手作業が必要となる主要因は2つある。

1つはシステム部の怠慢によるインターフェイスの設計ミスだ。しかし、その事情としてインフラにかけられる予算があるとすれば、次の原因と結びつく。

より重要な要因は、雇用形態にある。

終身雇用を前提とする賃金体系のもとでは、労働者に対する労働時間の増加は、勘定外として無視される。つまりシステムの不備による10分の作業量の増加は経営側からはないものとして処理されるということだ（人件費という一括りなうえに生涯で幾らという計算となるため、時間給的な発想とはならない。問題は、その発想のまま外部委託したりする点にもある）。付け加えると、これは、なぜ開発者に貧弱なマシンを与えるのか問題と軌を一にする。環境の問題で作業時間が伸びることによる非効率（生産性の低下といっても良い）は、労働者の問題であり、経営側の問題ではないと考えているからだ。少なくとも人件費（ここに職能に払っているのではなく、頭数に対して払っているという感覚があるわけだ）は織り込み済みだが、資産（たとえばコンピュータ）の導入は問題外となる。

したがって、現場における非効率的な作業の増大は企業システムとしては無視されることになる。

この発想のままなので、結果的にRPAは人減らしのためのツールとして導入されることになるわけだが、その一方で、すでにみたように、奴隷労働を主人労働に転換するものでもある。

少なくとも、同じ作業を繰り返すばかばかしさの解消、それを自力で成し遂げること、つまりコンピュータを入力作業のための奴隷労働の対象から、自分の力でコンピュータを奴隷として扱うようにするためのツール、それがRPAの価値だ。

それが可能となったのは、開発者の手作業によるテストから開発者が開発する自動化テストというテストに対する考え方の変化と、それに伴うOS操作のためのテストツールの充実と、プラットフォームとして利用できるIDEの出現と進展にあるというのが、おれにはとてもおもしろく感じる。

システムを作る側が楽をするためのツールの進展によって、システムを使う側が楽をするためのツールが出現して同じく楽になり、コンピュータが作る側からも利用する側からも道具となる、実に気分が良い。