Google

HOME
office
Google
RPA導入に於ける注意点

2019年3月22日 / 最終更新日時 : 2021年12月30日 officeの杜 Google

RPA導入に於ける注意点

大昔のこと。それまで平和に過ごしてたある日、別のお仕事で東京に異動し、そこで告げられた内容が「1月の残業時間は80時間オーバー。ここに放り込まれて、最初のミッションはこのどうにもならない状況をなんとかしてほしい」でした。

現在は、労基法の制限で月45時間の制限が設けられていますが、当時は毎日がきつい日々でした。アプリを作り、完全マニュアルを整備し、平均残業時間は10時間/人まで減らす事が出来たのは、徹底した業務自動化と最適化でした。

さて、昨今はRPAという新たなツールが出てきていますが、当時はバリバリVBAでコードを書かないと実現出来なかった事が、ノーコードで実現できつつありますが、ここには大きな注意点があります。今回のエントリーはウェブに溢れてる様々な意見や見識をまとめ、誇大広告に踊らされないように見極めるために、整理してみることにしてみました。

まずは、この面白ツイッターを読んでみて、自分の組織に過去こういうことがなかったか？見つめ直してみてから導入は考えましょう。こちらの知恵袋もネタとしては面白いです。また、RPAに対するコメントも面白い。

1 Windows10に無償の公式RPAが搭載されます
2 概要
3 ExcelマクロやVBAとの比較について
4 技術的側面からの考察
5 経済的側面からの考察
6 導入する際の問題についての考察
7 個人的見解と結論
8 RPA製品買う前に試すべきアプリ一覧
9 関連リンク

Windows10に無償の公式RPAが搭載されます

本項目を見て、RPAを試したい方は、まず以下のPower Automate Desktopで色々と検証をしましょう。間違ってもベンダーなどに相談したり、なんの躊躇もなくいきなり購入は、あとで必ず後悔とお金の無駄遣いにつながるでしょう。無償で利用が可能ですので、良い検証に利用することが可能です。

Microsoft Power Automate DesktopでRPAを実現してみる

Power Automate Desktopで学ぶRPAテクニック

概要

業務時間が削れましたと言うけれど

昨今のニュースでピックアップすると、これだけ業務時間を削減できましたというニュースとともに、近い将来事務員は大幅に削減されて不要の存在になるというもの。これそのものは事実です。そもそも、人手不足という話がありますが、事務職に関しては有効求人倍率は他の職種と比較してもともと高くありません。介護職の募集をしても人は来ません。。

Google Newsでピックアップしてみると

しかし、これらに対するウェブのナマの声は

今頃こんなことやってるの？今まで何してたのこの企業・・・
90%も業務時間削減できましたというのは、正直、恥ずかしいことを宣伝してるのと同義なんですが・・・
削減してどうするの？市役所なんて事務職の人、他に何をするの？
Excel VBAで最適化をしてきた上で、RPA導入するならともかく、RPAが出て飛びついたってのが正しいな。

結構辛辣な意見が出ています。他にも、現場でこれまでの20年もExcel VBAで部分最適化してきた人いるでしょう。兼ねてよりVBAで内製し省力化の努力をして来た。三井住友海上という企業ですが、こういった企業はリスペクト対象ですね。

一方、横浜市のRPA検証試験、事務作業を84.9%削減したという資料だそうで。それに対する楽しいコメント。ただ内容を見ると、費用対効果が薄いのでシステム化に向いていない案件ということで列挙されてる項目なんですね。もともと、他社ではそういう分野をVBAや自動化ツール達で現場の事務員の方々が細々と実現してきていたものなのです。今の今まで何にも手を付けてこなかったという証左。

さて、ここで注意点。素人がRPAでシナリオ作ったところで、ここまでの業務改善ができるか？といったらNOです。また、では外部に依頼すればできるかといったらYESですが、ここには別問題が付きまといます。

今まで何をしていたのか？

そもそも、加熱していた頃のRPAは「RPAで何でも実現できる」とまことしやかに語られ高額なソリューションを売り込む様子に、プログラマの方々は正直、疑問の目を向けていました。ただ、このRPA、厳密に言うと人間の模倣しかできない、つまり「自動化」というジャンルを担ってるだけのアプリケーションになるため、ソレ以上の事を求めるとなると、RPAでは実現は出来ません。とりわけ、ここで話題に上るのが「Excelマクロ / VBA」です。

実のところ自動化という分野は、はるか昔からとっくに別の選択肢で実現できていたものであって、RPA導入しないと出来ない事ではない。もっと言えば、「ロケットマウス」や「UWSC」、MacならばAutomatorなど自動化アプリって昔からあります。VBSって選択肢もありますね。CUIの世界なら大昔から、シェルスクリプトがありますし、Windows7からはPowerShellも選択肢の一つ。場合によってはRPA使うほうが効率悪化につながるケースもあります。っていうか今更感満載です。

なんかRPAなるものがバズワードになってるんですね。知らんかった笑。もうずっと前から我々プログラマはRPA的なことをプログラミングで実現してましたんで今更感バリバリです。最も優秀なプログラマは最も怠惰な人間だ...…
「いま」... https://t.co/qDPvvbRozc

— 堀江貴文(Takafumi Horie) (@takapon_jp) 2019年3月23日

ここでの注意点はあまり声高に数値を掲げて「〇〇％の業務時間削減できました」と公表するのは、株式会社ならば控えるべき事項です。株主からしたら「今まで何してたの？この企業」という事になりかねません。

唐突に出現したブーム

唐突に出現したRPAブーム

まずは、このGoogleトレンドのグラフを見てみたい。過去5年に於ける「RPA」と「働き方改革」「人手不足」で検索したトレンドサーチの結果です。

この中で働き方改革と見事にRPAの動きが一致してるのが見て取れます。しかし、注目すべき点はそこではありません。2017年初頭に唐突にRPAのワードが湧いて出てきている点。しかし、ITウォッチしてる人間は知ってると思いますが、諸外国ではRPAはその数年前からすでに導入したりしてますが、ここまでの動きにはなっていません。2019年頃までは東京オンリーでしたが、その後東京のムーブメントは下降、なぜか2021年時点では、富山県がやたら数値として出てきている謎。

なぜ、日本ほど導入で過熱していないのか？理由は普段から或いは全体最適化やシステムに業務を合わせる合理化をしているからです。RPAを積極的に導入するまでもないという事。故に、唐突に始まったこのブーム、アメリカなどで導入は先行してはいるものの、ブームになって日本で流行ったものではない。明らかに仕掛けられたブームと言えます。バレンタインデーやクリスマス商戦みたいなものです。

海外企業では普通に内製し、そして常に全体最適化を実践しています。ゴリゴリ内部でプログラム作成をIT部門が頑張ってます。これ当たり前のことです。しかし日本は未だに、外部ベンダー依存とエンドユーザコンピューティングによる部分最適化支えられてたりします。この下りは後述。

ベンダーおよびコンサルが働き方改革という政府のワードに乗っかりブームを仕掛けた。これが真実です。

#RPA は日本🇯🇵だけのトレンドです。海外のメンバーにRPAといっても何それ？？という感じです。 #ガラパゴス #ITガラパゴスニッポン

— Atsushi Yamakawa (@AtsushiSolCtr) 2019年3月18日

ExcelマクロやVBAとの比較について

WinActorのようなメジャーなRPAツール以外にも、有象無象のRPAを謳った商品がやたらめったら出てきています。選択肢がたくさんあることは良いことですが、ここで大きな注意点があります。これらの企業の営業は素人、さらに言えばコードも書けないようなITリテラシーの低い人間が相当数いるという事実を忘れてはいけません。

そのリテラシーの低い人間を見分ける一つのポイントがこの「Excelマクロ/VBAとの比較」のお話。プログラミングやっていない人間が書いてるんだろうなぁと思わしき、オカシナ比較検討資料が出回っており、ここには釘をさしておく必要があります。とあるサイトに掲げられていた比較資料をぶった切ってみたいと思います。

プログラミング知識の必要性

「プログラミングは不要」というワード。たしかにこれそのものは事実です。問題はここには教習所の効果測定試験レベルの引っ掛けがあります。「プログラミングの知識は必要」という事です。多くの企業で導入をしくじってるのがまずココです。プログラミング知識ない方の作ったシナリオは・・・

プログラミングに対する初歩的な知識も持ち合わせていないような人間でもプログラム作れるなんてものはこの世に存在しません。理由は大きく以下の点

RPAにも変数やら繰り返し処理やら普通にプログラミング知識要求するものが存在します。これを使わずにシナリオ作るとかあり得ません
ウェブアプリケーションをマウス操作でどうこうするケース。それそのものはノンプログラミングでもできるでしょう。しかし、ウェブのUIやフローは日々進化します。それにユーザが追従して変更しなければならない。通常はREST APIで組むところを。
そもそも、業務用プログラム作る上で最も時間を使うのはプログラミングではなく、業務フローの断捨離と整理。そしてそれに基づく、業務をプログラム化する為の論理的思考能力。現場の事務員にコレできるんですか？SIerでも最も気を遣う所で、最も面倒な作業ですが（多くのケースで、現場の事務員が自分の仕事をきちんと分解して、整理説明、断捨離できるケースは存在しません）。これをやらずにプログラムなりRPAやると、間違いなく破綻します。
うまく動かなかった時のデバッグ作業。なぜか知らないけれど動かない、、だと詰みます。
プログラミングと違ってメンテナンスフリーだと思い込んでる人がいる。ケースによっては、VBAよりもメンテナンス面倒ですよ。
現場の事務員でも作れるという触れ込みにも関わらず、ある程度ITリテラシーある人、プログラミング知識ある人に任せる・・・属人化やブラックボックス化云々の話どこへ？

などなど。そもそも、プログラミングというものに対しての日本と海外の間には大きな錯誤と認識相違、さらにはそこに対する価値観に大きな乖離があります。日本の場合、プログラミング = 特殊能力と思ってる方や、学習に膨大な時間が掛かると思ってる人いますが、大きな間違いです。

大量データの処理

とあるサイトにこう書かれていました。データ処理で低速と・・・。RPAはどこまでいっても人間の操作を模倣して動かすのが中心です。しかし、RPAの多くは中身がVBSをラップしたもので構成されていたりします。

プログラミング、とりわけVBAできちんとデータ処理を行う場合、マクロ的な書き方はしません。でかいデータはメモリに配列として読み込み、メモリ上で処理をし、書き込みも一発で書き込みます。マウス操作を記録したコードが遅いのは当然。プログラミングではガッツリメモリ上で配列等を操作して処理を行うのが定石なので、VBAのほうが遅いということはまず有りえません。

会計ソフトなど様々なソフトとの連携

RPAが様々な会計ソフトと連携できますと宣伝してるものがあります。しかし、これ注意が必要です。さらに言うとVBAでは連携できないとまで書いてるサイトまで存在します。そもそもRPAが会計ソフトに対して何してるか知ってますか？連携できると謳ってる製品の多くは

マウス操作で会計ソフトを動かしてる
データのやり取りに関しても、マウス操作もしくは会計ソフトが持ってるAPIを利用している

画面認識で言えば、マクロで出来ないというのは事実です。よってここで会計ソフトを操作するRPAに軍配があがるのはその通り。一方、２番目のデータのやり取りに関してですが、マウス操作でCSV出力の動作をやらせて終了というRPAをよく耳にしますが、その動作を最適化してどれだけの効果あるの？というのは疑問です。

また、今時の業務用アプリケーションは普通にデータ連携用のAPI持っています（いわゆるSDKやライブラリです）。さらに言えば、CSVでのデータ入出力に対応しているので、そもそもインプット部分を人間がやったり、それをRPAで組むって行為自体が、無駄以外の何物でもない。人間がやったとしても大した時間を消費するタスクじゃありません。

他のアプリケーションの操作

これもよく言われているものですね。VBAは他のアプリケーションを操作できない。ましてやウェブアプリケーションは操作できない等。VBAで他のアプリケーションを操作するでも列挙していますが、VBAでは昔から他のアプリケーションの操作をしてきています。

加えて、VBAでもディープに操作可能な、ウェブアプリケーションの自動テストでも用いられる「Selenium」にて、Chromeを自動操作などは、画面認識でやらせるタイプのRPAよりはるかに正確で確実に処理が可能です。その為の自動テストアプリです。Selenium Basicを用いる事で、VBAから、マウス操作ではない形でブラウザを遠隔操作可能です。

また、この他のアプリケーションの操作についてなのですが、よくよく考えた場合、他のアプリケーションを操作して自動化でターゲットになるアプリケーション。その殆どのケースが「Microsoft Office」とせいぜい2,3個の業務用アプリだったりします。つまり、他のアプリケーションを操作と言うほど、他のアプリケーションを実際に操作するものって限られていて、尚且つ自動化で問題になるのは、その他のアプリケーション自体が原因だったりします。これどういう事かというと

他のアプリケーションが機能不足もしくは十分なメンテナンスや更新をされておらず、足りない機能を事務員がExcelで作らざるを得ない状況を作ってる。
他のアプリケーションを新規導入したは良いものの、予算不足でカスタマイズが十分にできず、結局、Excel使ってる。
本来であれば他のアプリケーションで機能として取り込むべきものを要件定義せずケチり、結果、事務員に負担がかかり、新規に導入のシステムなのに早速、機能不足の状態に陥ってる。

などなど。これ、とある有名一流企業での現実だったりします。その結果、アプリ間連携という話が持ち上がったり、さらにはExcelで自動化といった話が新規システム導入前から出てて来るなど日常茶飯事です。カスタマイズって言うほど簡単じゃないのと、お金が掛かることを忘れてたり、要件定義不足で載せることが出来なくなったり。本末転倒だと思います。

このケースでは結局、Microsoft Officeが穴埋めしてるわけで、その自動化ならRPAよりVBAのほうが遥かに効率よく自動化可能です。ちなみに、VBAからは他のアプリケーションのAPIも普通に使えたりするので、他のアプリケーション操作って得意分野だったりします。

Webページから指定した情報を取得

ならば、という事で無理やり持ち出してきたものがウェブページからの情報取得に関してはRPAが得意だという文言。前項でも記述しましたが、そもそもVBAは大昔からウェブページのスクレイピングや操作を実現しています。また、昨今のウェブアプリケーションは他のウェブアプリケーションやローカルのアプリケーションと連携できるように、REST APIを装備していたりしますので、マウス操作で作業を自動化は悪手です。

故に、RPAのいくつかはこのREST API連携できる為のシナリオパーツが用意されているのです。しかし、ITリテラシー低い現場の事務員に扱えるのでしょうか？それを避けてマウス操作をRPAで実現するのは、不確実な操作をシナリオで組んでいるに等しい。

また、Google Apps Scriptのようなサーバサイドスクリプトはこの手の連携を最も得意としています。非常に短いコードで大幅な自動化と高速化が可能です。下手にRPAで組むより、素直にプログラミング学習したほうが結果的にコスト低減や工数の削減に繋がります。

製品が消えたらどうするのか？使い手は？

実は一番理解されていない点がこれだったりします。まず、製品が消えたら問題。VBAは25年以上にも渡ってこれまで現場の業務自動化や効率化に貢献してきました。それが成し得たのは他でもない「Microsoft Office」が世界レベルでデファクトスタンダードであったからです。簡単に実現できるものではありません。しかし、RPAはどうでしょうか？まず、デファクトスタンダードが存在しません。さらに言えば、この先それら製品が生き残ってるとは言える保障はどこにもありません（Microsoft Officeが消えるよりも先に間違いなくそのRPAは消えるでしょう）。消える確率のほうが圧倒的に高いです。

これまで利用してきたVBAをRPAに置き換えてなんて取り組みをしてるような企業まで出てきてる始末です。その理由が「使い手がいないから」と・・・

さて、VBAは世界レベルでデファクトスタンダードです。使い手の数ははっきり言って圧倒的です。資料も桁違いに豊富に存在している為、現在でも使い手は新たに生まれています。当然、デファクトスタンダードであるので、他社に行っても基本通用します。しかし、RPAはどうでしょうか？会社毎に違う製品を使っていたり、使い手がそもそも導入してるのに居なかったり。会計ソフトウェアと違って、会計の基本がわかってればすぐに使えるというシロモノでもありません。結局育成が必要になります。

VBAの使い手が居ない企業は、RPAの使い手も育てられません。自分自らそれを証明してきてるのです。過去にいた人はどうされたんですか？その後は？VBAの使い手はいくらでもいます。外注先も星の数ほど。RPAはそういうステージには全く至っていない事を理解しましょう

技術的側面からの考察

シナリオ作成の外部委託

さて、ここまでのまとめを見ていて出てくるのが「外部委託しよう」という話。外部委託であればプログラミング知識も不要で、尚且つ安定的にRPAのメンテナンスも出来、様々な要求に応えられる体制が整うと。それは事実です。しかし、これ大きな過ちの第一歩です。まず、この選択をしている時点で「業務のブラックボックス化」「プログラム作成の属人化」が発生していて、RPAを使用する理由が破綻しているうえに、さらに付け加えると、「外部企業に自社コア業務のノウハウを握られ、ベンダーロックインされる」ことに繋がります。

既にもうRPA以前にこの状況になってる情報システム部身近にありませんか？これは別にRPAに限った話ではなく、アウトソースするってことは、その分野において自社では一切を捨てて依存するという意味を持ちます。また、専門の外部受託会社が作ったハイレベルのシナリオを、ITリテラシーもないような現場の作業員程度がカスタマイズやら修正は、ほぼ不可能です。

当然この状況になった場合、今後の保守費用の増加に対しても、委託側はNOと言えなくなります。しかもこれはランニングコストとして掛かってくるので、人間と違い削減が出来ません。削減するなら自分で作れ、メンテナンスをしろ。でも、それが出来てたら、そもそも外部委託していないですよね。

海外では、情報システム部門が内部でゴリゴリ内製してメンテナンスなんて当たり前のようにやっています。しかし、日本はなぜかそういったものを全部外部に放り出して、自由を失っていっている現実を見直しましょう。

複雑な条件判定にRPAを使ってはならない

事務作業には例外がつきものです。すでに法令からして例外規定や優先法があったり、また、法規に条文化されていない判例に従った処理など、今でも現場の事務員さんがいるのには理由があったりします。多くの業務用アプリケーションはそこまで面倒みません。あくまでも人間がそれを知っており、それをコントロールすることが前提になっていたり、ひどいものになると、最初からその為の仕組みすら持たないパッケージもあったりします。

企業によっては、交通費一つとっても、そこには複雑な条件判定があったりして、それらを現場の事務員の職人芸で回してるシーンは多々あります。知っているからこそ回せているのです。しかし、作業には時間が掛かるという事で、これをRPA化しようとなるわけなのですが、そこには大きな落とし穴があります。

この作業、プログラミングだと実はそこまで複雑化しません。コードが読めればそこで何の条件判定をしているのかは理解しやすいのですが、これがRPAとなると一見するとシナリオパーツによって図式化しているのでわかりやすいように見えますが、実際にはコードよりも理解しにくいものになります。フローチャートのようになるので、プログラミング知識のあるものは、論理的にそれを分解できますが、そうでないものは幾重にも判定が重なり、脳みそで正確な処理のルーチンを理解できなくなるのです。

こういった複雑な条件判定を伴うものを作り込む事は、それすなわちもうプログラミングと変わらないのです。現場の人はこれをよく理解しているという方がいますが、現場の人ほど自分の業務を理解できていない人が多い、それが事務職です。一部の職人だけなんですよね。なぜそのフローがありそういう条件判定をする必要があるのかを理解できて説明できる人は。

今あるレガシー環境延命の為のRPA

この事例多いんじゃないでしょうか？今ある基幹業務システム、入れ替える為には3000万円も掛かるから変えられない（既にサポートまで切れてるなんてケースもあったりします）。だから、これを延命する為に、RPAでサブシステム的に構築して延命させようと・・・

これExcelのVBAでもよく見かけるケースですね。あくまでも次の導入システム計画を策定した上で使い捨てのつもりで構築する分には良いのですが、明らかに基幹業務システムのメインプロセスを代替するようなものを作っているようなケースがあります（基幹業務システム側が現状の企業の規定や法規についていけてなく、それをExcelで構築してるなんてケースですね）

これが恐ろしい点は

現場でサブシステム的に組んだRPAやらVBAやらが基幹業務システムの一翼を担ってしまっている
何があっても、そのメンテナンスを確実に要求されるが、基幹業務システムの根幹など現場の作業員程度で維持していけるのか？
最新の基幹業務システムならば普通に実装してるものを、自分たちで延命の為に作るのは愚の骨頂。開発コストやメンテナンスコストを考えても、基幹業務システムをリプレースしたほうが遥かにメリットが大きい。
目の前の小銭節約のために、経営者がイニシャルコストの掛かる基幹業務システムの入れ替えを拒否するなら、クラウドのサービスに切り替えれば良いだけの話。

といった点。完全にRPAというツールの手段と目的をはき違えてしまってるケース。さらに言えば、最新システムなら標準でもっているものを自分で構築するなどは、車輪の再発明なだけでなく、きちんと整理された上で作られているならまだしも、複雑怪奇な現場フローをそのままロジックにして組んでしまうと、いよいよリプレースする時に困るのはユーザです。素人が手を出していい領域とそうではない領域の区別はつけましょう。

OCRと連携できるRPAは凄い？

ITリテラシーの低い事務員寄りの考えで業務最適化を行おうとするとぶつかるのがこの問題。そしてこれは本来RPAで解決するべき問題ではないのですが、なぜか進めようとする人がいるんですよね・・・

それが「現在のペーパー業務残したまま、それをOCR組み合わせてRPAでどうにかしようとする」という考えです。ペーパーレスが叫ばれて幾数年、既にワークフローシステムなどもある時代に、不確実な上にペーパー業務を残すこの選択肢は、いかにも現場事務員の考え方です。これに対する正しい決断とシステムの構築は

ワークフローシステム導入でペーパーレス化する（ついでに自動化もされる）
そもそも、紙をやめればOCRなど必要ない（しかもOCRは不確実なシステムです。）
例えば、G Suiteなどの場合、交通費のワークフローシステムは100円/人/月で簡単に導入できたりします@サテライトオフィス

また、普通はやらないと思いますがGoogle Apps ScriptもGoogleの画像認識APIを利用してOCRな仕組みはつくれますし、さらに簡単なワークフローシステムも作れます。OCRを業務に取り込むソリューションは色々見かけますが、これを使わざるを得ないケース以外で、この選択肢はすべきではありません。

Excelの操作に弱いRPA

これ非常に有名な話ですね。画面認識やマウス操作を主とするRPAでは画面のサイズや解像度一つ違うだけで、クリックする位置がずれたりする。故に細かなセルの操作や微妙な操作、またパラメータの指示を必要とするExcelの操作に非常に弱いです。しかし、残念な事にRPAを一番必要であろう職種の現場作業で最も多く利用されているのは、Excelです。文書ですらExcelで作ってる始末です。通称Excel方眼紙。

ただ、Google Apps ScriptなどでPDFなどの文書生成では扱いにくいドキュメントよりもキッチリレイアウトの組めるスプレッドシートのほうが扱いやすいのでこれ自体否定できるものじゃないのも事実ですけれどね。

さて、そんなExcelの操作。人間ならそう難しいものじゃないのですが、RPAは以上の理由により下手に操作をRPAに任せるとドツボにハマります。というか、ExcelといったOffice製品の操作はVBAの独壇場なわけでして、わざわざRPAでやらせるほうがどうかしてる。ツールってのは得手不得手もありますが、使い所というのもあります。VBAというプログラミング言語を避けてRPAでっていう、薄ら甘い考えでは現場の業務自動化や最適化は無理でしょう。

RPAは想定外の操作である

通常のプログラミングの場合、相手のシステムもそれに対応したAPIを用意しており、サポート対象として含めています。REST APIも然りです。ゆえに、VBAなどで他のアプリケーションを操作したり、ウェブサービスへ接続してデータのやり取りをするのは、相手のシステムの想定の範疇にあります（その為にドキュメントも用意されていて、メソッドやパラメータのつけ方も記載されています）。

しかし、RPAによる操作の自動化というものは相手のアプリケーションやウェブサービスからしたら「想定外のハッキング行為」です。よって、当然ながら、自動化の名のもとにマウス操作やキー入力の送り付けによる操作というものは「保証対象外の行為」となります。これまでは情報システム部などではこれらに該当するため、現場からの要望があっても、この手の操作自動化のアプリケーションを認めてこなかったのにはこういう理由があります（それでしくじってサポートしろと電話されても迷惑な話です）。

APIで操作できるようにしてあるものを、わざわざマウス操作という非効率且つ不確実な手段で、業務用アプリケーションに操作されてもメーカーは対応しません。当然ながらクラウドのサービス側もRPAに対しては「REST APIで操作しろ」と突っぱねます。

※ですので、例えばクラウドのサービスや基幹業務システムがアップデートで、RPAが動かなくなっても「完全自己責任」です。サポートセンターに電話などしないように。

REST APIの操作について

最近のクラウドサービスはほぼほぼREST APIを装備しています。一般的な基幹業務クラウドなのに、REST APIも装備していないようなショボいサービスは見限ってオッケーです。メジャーどころならGoogleやSAP、SalesForceであったり、専用システムならfreeeやSmartHR、勘定奉行などなど。さらに言えば、G SuiteではGoogle Apps Script上でdoGet/doPostを用いたり、Google Apps Script APIを用いて自前でAPIを装備することも可能。昔のASP時代のような閉じた世界とはもう違うのです。これら、REST APIは、VBAからも、Google Apps Scriptからも、そしてRPAからもアクセス可能です。

故にこれらAPIを備えているクラウドサービスに対して自動化処理をしたいのなら、マウス操作などという原始的且つ不確実（おまけに遅い）さらには実装の面倒なやり方をRPAでやるなど愚の骨頂以外の何者でもないです。RPAにもREST API叩くインターフェースついているんですから。これであれば、RPA利用も選択肢として悪くない。しかし、現場の事務員がOAuth2認証やらAccess Token、エンドポイントを理解してなんてやれるとは思えない。つまり、情シスの手伝いは必須なのです。

「うちは自前で構築したシステムなのでAPIは無い！！」という企業もあるでしょう。作ったシステムにもよりますが、それがウェブアプリケーションなのか？DBサーバとのクラサバなのかにもよりますが、答えは「だったら、API装備すればいいのでは？」。Node.jsなどはExpressを利用して自前でREST APIを装備できます。そして装備したAPIに対して、RPAなりVBAなり、GASでアクセスさせれば良いのです。自前で作ったのなら、つくれますよね。

「社内のサーバは捨てたいが、プライベートクラウドとしてそのまま活かしたい！！」という企業は結構あります。自前で構築して十分機能してる、素晴らしい環境だと思います。そこにAPIを設けてRPAと連携させたいが、サーバは捨てたいからここにAPIを構築はちょっと・・・今はGoogleやMicrosoft、Amazon上に仮想環境で構築できる時代です。また、VPSサーバを借りる選択肢もありますね（ただセキュリティを考慮すると価格は安いですが、GoogleやAmazonで借りたほうがよいかと）。まずはそこへシステムを移行し、そのタイミングでAPIを自前で設ければ良いでしょう。自前鯖と違い、パワー足りない、ディスク容量足りなくても、都度スケール出来ます。ハードリプレースの必要もありません。

「うちは古いパッケージのシステムだから手が出せない！！」という企業さん。これに対する答えは、それ、いい加減に最新のシステムにリプレースすべき時期ですよ。未だにCitrix使ったリモート接続で使ってる所ありますが、それクラウドに乗り換えでもういいでしょ。乗り換えるまでいかずとも、ウェブアプリケーションパッケージにリプレースすれば良い話です。古いシステムは企業の業務改善の足ひっぱる足枷でしかありません。

「うちは予算がないからリプレースなど出来る余裕はない！！」というカツカツの企業さん。これに対する答えは、「だからクラウドに乗り換えれば？」です。自前でサーバ持つ必要もなければ保守要員も必要ありません。イニシャルコストは低い上にリプレースも必要ないので、ハードウェアの次期リプレースやランニングコストも不要です（利用料はサブスクリプションなので毎月のランニングコストに含まれます）。そもそも、金ないのにオンプレミスでサーバ持って自前でサーバ保守がどれだけ贅沢な事なのか。。。

自分の場合、GASでこれらAPIを利用しシステム間を連結させたり、場合によってはAccessからREST API叩いてデータ収集やデータ送り込みをこれまでも作って来ています。なので、RPA使うまでもなくエンドユーザはボタンぽんで終わりです。本気で業務改善したいならば、こうしたバックエンドの準備も必要になってくるのです。

※企業では利用しないと思いますがさらにREST APIを複数またいでチェーンでつなぐタスクランナーというサービスもあります。

専用PCの用意と並列実行不可について

RPAの致命的な点がこれです。専用のPCが必要であるという事。ある処理をするにしてもすべてにおいてマウスによる画面操作や画像認識などを伴う為、作業中は別の作業が出来ません。下手に操作をするとRPAの実行シナリオに割り込みを掛けることになり、オカシナ挙動を招くことになります。また、それが故に並列実行もできません。

一方VBAなどで同じようなプログラムを組んだ場合、キー操作やマウス操作などでプログラムを組まずに実現する場合は、複数の処理を並列実行可能ですし、専用のPCなど用意する必要はありません。みなさんの手元のPCで何個も実行させておけば良いだけです（よほどの巨大なものでなければ、並列でプログラムを実行するまでもなく終わるので、RPAのような莫大な待ち時間は不要です）

RPAでは誰かがRPA処理をしている間はそのPCは使えなくなるので、ライセンス料をケチって専用PCでやらせるなんて事になると、作業は軽減化できても、無駄な待ち時間は発生することになり非常に非経済的なことになります。

ゾンビのように生き続ける野良ロボ

日本の情報システムの多くは現場最適化を避け、例えばExcel VBAで作られたアプリケーションのメンテを引き受けない。これがそもそも、RPAの導入に繋がっている理由の一つでもあったりします。

中には、こちらのケースのように攻めの姿勢を構築し、現場最適化をも巻き取り、情報システムで面倒を見て会社全体でその業務の重要性を認識してる素晴らしい企業もあるのですが。

そんな情シスは前述のように現場でどんなマクロやVBAアプリが動いているかを把握していませんし、現場業務の知識も持ち合わせていません。ゆえにRPAを導入しても彼らは、PCに関する知識はあっても、現場の知識ゼロ・下手するとプログラミングの知識も持ち合わせていないだけでなく、RPA自体もメンテナンスを引き受けないでしょう。

そうなると、発生するのがExcelマクロでもお馴染みの野良プログラムの量産と氾濫。すでに担当者もおらず、しかし前の担当者からそう言われたからという常套句を免罪符に、野良ロボがゾンビのように生き続け、業務の一翼を担ってる（俗に言うExcelレガシー問題）、統制の効かないラクーンシティのような状態に（10年前に書いたVBAが未だに改変されることなく動いているケースも）これは内部統制上非常に問題です。。無事に動いてる分にはまだ良いのですが、これが一度破綻を招く外部環境の変化があった時、現場の担当者や上司は唖然とするわけです。バージョンアップなど到底不可能でしょう。

RPAはシステムを作れません

そして、RPA界隈のITリテラシーの低い経営者あたりから聞こえてくる話題の一つに「RPAがあれば何でもできる」と思ってるケースです。

例えば、VBAやGoogle Apps Scriptはプログラミング言語であるため、自動化の他に通常のアプリケーションの作成が可能です。業務で利用する様々な管理アプリケーションを構築するにはプログラミング言語は当たり前ですが必須です。その下位互換でしかない、また人間の業務フローの自動化しかできないRPAにはアプリケーションの作成など到底できません。

なんでもできるどころか、ピンポイントで自動化に特化しているのがRPAであり、反復作業を伴う業務に使うべきものであり、あくまでも業務効率化の１選択肢でしかないということを忘れてはいけません。RPAはあくまでも別のアプリケーションがあって成り立つもので主人公ではないのです。プログラミング言語はそれそのものがアプリという主人公を作る為のものです。その機能の１つに自動化もあるのです。

また、これが故に、VBA等でガッチリと作り上げたアプリケーションで自動化をしている場合、RPAを導入して同じことをやらせようとすると、まったく手も足も出せなかったり、よしんば作れても、VBAと異なり処理速度では比較にならないほど遅いものが出来たりします。プログラミングとRPAとの間には越えられない壁ってのがあるんです。

業務の抜本的見直しを伴わないRPA導入には疑問を感じる。IT案件を丸投げする傾向にある中小企業では特に。そんな状態でのRPA導入は非効率な業務を見えなくするだけで、穴だらけで積まれたテトリスの様にいつか破綻すると思う。#RPA #業務改善 #中小企業

— Higurashi (@Higurashi_0229) 2019年3月23日

経済的側面からの考察

RPA製品は決して安いものではない

コストのお話。この点についてきちんと説明してるベンダーの資料を見たことがありません。話を別の方向に持っていこうという悪質な例もあったりします。そもそも、Excel VBAの場合、既にもう現場の全PCに入っており、PCの購入費用の一部として買い切りで導入されています。Excel単体で見れば、2019などは2台（しかもWin/Mac両方版）で、1本15,000円程度です。さらに言えば、VBAに関するドキュメントの量は膨大で、またよくも悪くもVBAはこの20年殆ど進化していないので、平然と20年前のコードでも通用したりします。

一方、RPAは製品が出たのはここ最近。おまけに一般に普及しているものではないため、ドキュメントの量は極めて少なく、国内企業のRPAなど資料なんてあるのか？ってレベルです。いざ作ろうとした時にこのドキュメント量の大小は見えないコスト、学習コストとしては非常に高く付きます。

また、Excel VBAの場合、すでにもう現場のPCすべてにExcel（買切り）が入っているので自動化を実現する上での追加のソフトウェアコストはゼロです。しかし、RPAは1台当たり実行版でも250,000円～。。フル機能に至っては900,000円もします。しかもこの価格は買い切りの価格ではなく、年間コスト。ExcelもMicrosoft365ならばサブスクリプションのプランによりますが、それでも買い切りよりも初年だけなら安く購入が可能であり、自動化について言えば、それそのものを実現するのに追加コストなどないわけです。

他にもVBSといったスクリプト環境はWindows標準で搭載されてるものですから、テキストエディタ一本で書けるわけでして。またこのコスト試算に於いて、営業は非常に狡猾な営業トークをするわけです（これで人件費が削減できれば安いものでしょ？とね。）。ですが、それはVBAでも同じなわけです。さらに言えば、専門の担当者置くならば、殆ど意味をなしません。

人員削減につながるとは限らない

多くのITに精通しないでRPAに飛びつく経営者は「RPAで人件費を大幅に削減することができる」と思い込んでいます。しかし、サービス残業を強いてきた日本の企業の多くではそもそも、削減するだけの人件費の余地はほとんど残っていません（というか、違法にRPAで削減出来る分の人件費をこれまでも搾取していた）。RPAで人件費削減というのは法令遵守していた真っ当な企業に言えることで、搾取してた企業が、昨今の働き方改革で残業代払うようになり、RPAで削減した所で今までとコスト的には変わらないという事です。

さらにこれで例えば残業時間分を削減できたとしても、現代日本の場合、１人に対して単純労働で固めてやらせているわけではないので（海外と違い総合職と称して一人に色々やらせちゃってる問題）、結局はコアタイムに少し余裕ができた程度の削減では、人員をカットなど出来ないのです。時間をカットできても人をカットはできるとは限らない。人がカットできないならば、年間給与の固定費分が減ることはないのです。

しかし、RPAはすべての業務をカットできるような能力はありません。定時の時間より前に終わった程度では意味がないのです。その間を他の業務と言っても、そのような業務があるんでしょうか？それらを固めれば人を削減できるといいますが、それって一人に多大な担当を兼務させること（労働強化）になり、ジョブローテーションをしていない場合逆に、人員喪失時のリスクをどんどん高めているだけでは？結果、人員を雇うことになるわけです。（エンジニアに焼きそば作らせ大量退職問題）。

また、24時間365日動くから夜間にバッチ処理的に流すことが出来るので、結果的に人件費削減が出来るというのを謳い文句にしている事例も多いですね。しかし経験上、事務職にそんなバッチを流すほどの大量単純な作業は昔と違ってほとんどありません。また、VBAでやった場合、時間内できっちり終えることも可能。よほどの少人数で数万人クラスを相手に事務やってるというのなら無くもないですが、それらも都度リアルタイムに処理をすれば良いので、むしろ昔のようなバッチ処理やらDBのトランザクション処理的なことを人間がやるケースなど、少数です。普通はそういったものは、例えばネットショップのオーダーを処理するサーバ側のバッチで行う作業です。

これはこれまでのコンピュータによるオートメーションでも数々いわれてきた事です。コンピュータは進歩しているのに一向に楽にならないなんて言われてきた事ですね。

官公庁の障害者雇用率水増しが問題になっていますが、下記の記事でRPAの対象になっている仕事が、障害者雇用で採用した人に任せている仕事と被るんですよね…。業務効率化を推進すればするほど、障害のある人に任せる業務の切り出しが難しくなるというジレンマ。 https://t.co/TEoBDam1OZ

— 松本太一@アナログゲーム療育 (@gameryouiku) 2019年3月23日

RPA入れたのに残業代が減ってない不思議

前述の項目の今度は逆バージョン。RPA入れて作業時間を減らしたはずなのに、残業コストが比例して減っていない・・・逆バージョンと言った理由は、これ「生活残業」ということです。RPAで削って部分最適化して残業減ったらその分、RPA以外の業務の濃度を薄めれば良いだけです。

しかし、日本企業はその硬直化した人事考課制度でこれを粛清する事が困難です。理由はこれまでも出てきましたが、管理者および経営層が現場丸投げで現場の仕事を知らない、また把握していないから。外資なんかではパフォーマンス低い人間は残業代支払った上で次期からの人事考課で粛清します。つまり労働単価下げられてしまうんですね。

でも、日本ではできない。そもそもエンドユーザコンピューティングで業務を支えている時点でお察しの事ではあるのですが、何をやってるか知らないわからないでは、人事考課で下げられようはずもありません。評価する素材がないんですから。これがVBAで効率化した人達を評価できない事にもつながってるわけですが。単純にITに疎くて理解不能という事だけではないのです。

RPAで浮いた分、これまで手薄だった業務の充実を図るであったりとか、出来なかった新業務に着手するとか前衛的な方針がきちんと図られているならこのお話に該当しませんが、そんな前衛的な方針打ち出せる企業は、とうの昔に全体最適化に着手しているでしょう。RPAなど使わないでね。株主さんはここ要注目です。

思ったほど使いみちがないケース

RPAはVBAと異なり「長時間掛かる同じような単純知的作業の反復を自動化」する為のものです。しかし、これ思ったほど今の業務には無いなんてことも職種や業種によっては有りえます。その代わり臨機応変に対応を求められるものや、反復する作業ながら大した時間のかからないものが細かくたくさんある場合（それは連続した作業ではない）、RPAでシナリオを作った所で、ほとんど業務改善に貢献しません。

いざ導入して使ってみたのだけれど、思ってるほど使いみちが無い・・・そんな形で利用をやめてしまうケースがあるということだけは肝に銘じておくべきでしょう。VBAのようなプログラムの場合はそれらに対して、アプリケーションとして構築する事で対応が可能ですが、アプリケーションを作れないRPAでは出番はないのです。

導入する際の問題についての考察

RPA導入で人間は恩恵も受けるが導入を阻むのも人間

なぜか、RPAは簡単に導入ができると思っているベンダーや現場が多いのに驚きます。通常システムの導入によって確かに恩恵はありますが、一方で必ずと言っていいほどこの手の現場サイドのツール導入は現場からの反発を招きます。主なケースは

これまでやっていたやり方を変えたくないという保守的な事務員の存在
自分の仕事を奪われる。これはちょっとした恐怖ですよ。故にシナリオ作成に協力しない。作り手が何も知らない場合この時点で詰みます。そもそも、自分の首が危うくなるようなお手伝いをするなんて、モチベーション低下、インセンティブもない、やるわけがない。依頼した次の月には退職して企業には何も残らないなんてことも起きるでしょうね。
思ったほど効率化につながらない、トラブルが多くて使うのをやめてしまい、二度と依頼しないケース。
導入前によく業務整理と内容の検討をしろというが、これが大仕事。結果途中で嫌になってやめるケース。
単純労働を削減して余った時間をクリエイティブなことにといってもその仕事がない。あっても適合しない人材である。事務員が明日からSEとして仕事やれ、営業として外回りしてこい。出来ますか？体のいいリストラでしょソレ。労働争議として外部労組や労働局、弁護士さんからお客様が来るかもしれませんね。
RPAで業務改善をしても評価されることはない。給与に反映しない。誰がこんなのに協力しようと思うのか？（VBAずるい問題）
っていうか、RPA用のシナリオ作成なんてものに現場の人間は時間割いてる余裕はない。

この7つになるかと思います。基幹業務システムのリプレースの場合「使わざるを得ない」ため、使わないという選択肢は出てこないのですが、それでも現場の不信感と不満を招き、イラぬ衝突を招くこともしばしばです。今までの旧システムでは出来ていたことが出来なくなり、仕事が増えたなんてケースもありますね。あなたは相手のこれらの作業きちんと手伝えますか？

そして得てしてこの手のツールの障害は１．や２．といった人的要因で導入が進まず、人間がその導入の阻害分子になるのは、この世界にいたら誰もが知ってることです。にも関わらず簡単に導入できる、簡単に使える・・・少し誇大広告をぶち上げすぎだと思います。この問題を解決する手段は、現場の信頼を常日頃得て起き、現場に多大なメリットがあることを言って聞かせてさせて見せの社内営業活動です。

エラーがなくなりセキュリティも向上？

あるRPA製品の謳い文句に、ヒューマンエラーがなくなり結果セキュリティリスクを低くできるなどとという謳い文句を掲げているものがありました。あたかもRPAは人間とは異なり完璧確実に高速で処理を実行してくれる救世主であるかのような謳い文句ですね。しかし、プログラミングを経験している人間はこの文言が嘘大げさ紛らわしいであることを知っています。

ヒューマンエラーがなくなるのは事実かもしれません。しかし、RPAはその性質上、VBAのようなプログラムとは異なり例外処理や想定外の要素を排除できません。よって、ヒューマンエラーはなくなるかもしれませんが、RPA自身がそれら想定外の事にぶつかりエラーが発生する可能性は、VBAよりもはるかに高いです。結果、人間がRPAがやった仕事のダブルチェックをやらないといけない、エラーで止まってもどこでどのような理由で止まったのかのトレースが非常にやりにくいです。

またロボットにやらせるから、例えば誤送信などが防げるという事を言いたいのかもしれませんが、それだけをもってセキュリティ向上と言えるのか？例えば、あるファイルを生成したらこれらを、Google Driveの各フォルダに格納するなんて業務があった場合、それを正確確実にできるのか？といったら疑問です。マウス操作の記録でこれをやらせた場合、想定外のフォルダに格納する可能性は大いにあります。しかし、VBAなどのプログラムの場合、フォルダのID直指定でHTTP通信でAPIを叩くので100%確実にそのフォルダに格納できます。エラー時はエラーステータスを補足できるので、リトライやスキップといった処理が可能です。それでもエラーが無くなることはありません。

RPAを導入すればだれでも簡単に業務を実現できる？

自動化といったものに付きまとう問題、それは業務のブラックボックス化。主な事例を言えば、経理業務なら簿記の知識も必要なくなるであったりとか、人事業務なら給与計算や労務の知識が不要になるだとか。また、業務用ソフトウェアについてもその使い方に深い見識が不要になるだとか。そい言った文言を口にしてしまう経営者が居たり。

これ、ある程度事実ですが、問題はこの文言は、人間をただのパーツもしくはコスト程度にとらえてるブラック企業の常套句だということ。誰でも出来る？どんなリテラシーや知識の低いものでも実現できるなら、人件費削れるじゃないかと・・・

さらに言えばこのブラックボックス化というもの。例外や制度の改変（労務関係は結構最近頻繁にありますよね）、さらには操作対象のアプリケーションの仕様変更などなど様々な変動要素があるわけですが、それらが発生した時に、メンテナンスが出来なくなります。

誰でもRPAを導入すれば莫大な人件費を削れ、そして簡単にそれが実現できる。しかし、その結果失うものがある、またRPA導入程度で削れるような業務だったという話になるだけの事です。RPAを導入したからといって、その業務や職種に精通した人間を排除する事は、近い未来に於いて業務破綻が待っているでしょう。

労働者にとってのRPAとは

さて、ここで最後に労働者個人にとってのRPAについて考えてみたいと思います。これまでのお話は技術的側面や企業側の問題、運用の仕方など「企業内では」というお話でした。ただ個人の目に立ち戻ってRPAを考えてみてください。

RPAは人員削減の為のツールとして企業は捉えているという事
これまであった「派遣に切り替え」「アウトソーシング」といった人件費コストを削るためのツールである
単なる事務屋は確実に終焉を迎えていくということ

この３点です。

特に最近の銀行系はドラスティックにRPA導入で人を切ることを宣言しています。また、人手不足が叫ばれているのに世間では「45歳以上全員をリストラ対象とする」など、実はリストラも始まっています。いよいよ人件費削る手段が尽きてきているわけです。F通さんに至っては前回は12月頃でしたが、つづけざまに2回目のリストラがこの間ニュースになりました。

サラリーマンになって定年まで安穏と生活できる環境などもうないのです。そんな時代にRPAが出現しいよいよ事務職自体が消滅するかもしれないわけですが、これに協力するというのは言ってみれば、自分の首差し出しているようなもの。また、当然他社でも同様の事は起きているわけですから、リストラされたら、労働者は路頭に迷って終わるだけです。

そうならない為にはどうしたら良いか？だからこその世界で通用するプログラミング学習です。技術無きモノは行き倒れる。2つ以上の分野で能力を高めていかないといけない時代です。個人的には「エンドユーザコンピューティング大賛成」です。それが結果として企業が近い未来困る事になっても、労働者にとっては「知ったことではない」。なので、これまでの企業視点からみたRPAとは違い、労働者側からみたら、じゃんじゃん進めてしまって技術を身に着けて、次のよりレベルの高い企業に向かいましょう。

独学でやろうとして挫折するの巻

多くの企業があたかもビデオデッキを操作するがごとく誰でも簡単に出来るというフレコミを真に受けて、いきなりRPAを独学で担当者に「はい、やって」と渡すケースが非常に多いと思われます（場合によっては、労働契約法違反や適性を考慮しない業務命令によるパワハラに該当することも考えられる。）。だってそう謳ってんだもの・・・・担当者に耐性（適性とは言っていない）があれば回るかもしれませんが。

プログラムのUI見ればわかりますが、光の速さで挫折すること請け合いです。言ってみれば、教習所に通わずに運転免許試験場で資格取ってこいと言わんばかりで、確かにそれで取れる人もいるのですが、今どきの多くの人は挫折する事でしょう。プログラミングも同じです。いきなりエディタ画面だけ出されて、はいやってって言ってできる人間がどれだけいるのか？

Microsoft Accessですらノンプログラミングでデータベースアプリを作れるという話だったのに、Excelと似ているから簡単だと独学で初めて、単純な選択クエリで撃沈し、Excelに戻ってvlookupも使わずになんて光景を何度も見聞しています。VBAに入る前に挫折してるんですよ。。RPAの前にAccessの１つでもまともに使えるようになって見せてくれ・・・でもツールって昔からそういう物です。しかし、知り合いの薬剤師さんはモリモリ自分でクエリマスターしていったりしてます。地頭がなければ独学なんてするべきじゃないって事です。

ツールである以上、それを使いこなす上ではトレーニングつまり、教習が必須です。実践に勝る訓練無しという言葉はその素養がある人間にだけ許された格言です。またVBAと異なりコピペでなんとなく動いちゃうとかRPAには存在しないので、むしろそういったサンプルが少ないRPAは学習しにくく、よくわからないライブラリだけれど期待通り動くのでヨシといった点ではプログラミングのほうが楽です。そこから学ぶことができますから。

また、プログラミングでは自分で作ってきたモジュールを再利用する事で高速にプログラムを作り上げることができますが、RPAも同じです。問題はその積み上げには多大な時間が必要であり、そういった汎用モジュールは経験者でないと作れない。毎回そのシステム専用に作り込んでしまうと、使い回しが効かなくなってしまいます。でも、そんな事現場の事務員に言ってもわからないよね。

勉強したくない

何がなんでも、プログラミングやRPAなんて勉強したくないでござる。。。RPAもやりたくないでござる。

すでに手遅れのようなので、近い将来、倒産、吸収合併、リストラ・露頭に迷うなど好きな選択肢をお選びください。

システムに業務を合わせない日本

かつてエンドユーザーコンピューティングが流行ったことがありました。その結果がExcelマクロの氾濫につながるレガシーExcel問題やシャドーIT問題を引き起こしたわけですが、そもそもなぜ流行ったのか？それについて語られることは少ない。RPAによってこれが復活するわけです。自分たちはそうはなりませんよ← ソレ、正常性バイアスの典型的な症状です。

理由は主に２つかなと思います。

企業が使うなと締め付けるだけで、現場に十分なITリソースを提供してこなかった。また、担当する経営企画が意識高い系（実はこれ、セキュリティ向上どころか、シャドーITを自ら推進しているに他なりません。）
諸外国のようにシステムに業務を合わせることをしてこなかった。

結果、現場では部分最適化の為に、そうせざるを得なかった。それで回していたのが現実だったということです。また、日本はITリテラシーが世界レベルで最低レベルなので、経営者や現場の社員のITリテラシーは2019年現在も変わっていません。その結果一部の能力あるモノに依存し、エンドユーザーコンピューティングが始まりました。

一般ユーザのほうが先に行ってるって非常にマズイことです。結果シャドーITが蔓延ることになりました。

しかし、一方で現場サイドもシステムに業務を合わせることをしてこなかったのも日本です。おかしな転記作業、チェック作業、酷いのになると、Excelの表ですら関数も使わず電卓で計算して入力・・・経営側・労働者側双方のITリテラシーの低さが、エンドユーザコンピューティングという悪夢と負債で意見が一致し今に至るわけです（合成の誤謬ですね。）。

しかしエンドユーザコンピューティングは、部分最適化。全体最適化には繋がりません。日本でだけ流行ってるこのRPAは部分最適化の典型、エンドユーザコンピューティングの再来です。

RPAで画面ががんじがらめになり、オンプレITだけでなくB2B/B2E SaaSの画面変更にもクレームが来るようになりそう。SaaS開発者はそういうクレームとの付き合い方も考えないといけないか。本来RPAではなくデータ連携すべきところでのRPA乱用。ユーザーのITリテラシーの問題。 https://t.co/L8cp0p475N

— 石橋秀仁 (@zerobase) 2019年3月23日

ベンダーロックインとレガシーExcel問題

課題に対して、自分で作らずなんでも金にまかせてソリューション導入して解決した気になってる、こういうのってソリューション地獄に陥ること請け合いです。本来組織に必要なソリューションなんてそんなに必要ないです。内製の重要性を理解できない、自分で勉強もしない作ろうとしない、そういった組織はジャブジャブとベンダー営業の良いお客様になれば良いのではないかと。ベンダーロックインまっしぐらですね。

しかし、問題はそこでとどまりません。過去にも企業は愚かなことを繰り返している。その事例が「NotesDB作り込み」「レガシーExcel問題」です。前者は内製という点は評価できるんですが、非常にクローズドで使い手のいないLotus Notesにシステムをガチガチに作り込んでしまった悪いケース。結果未だにそれに引きずられて、他のソリューションへ移行できなくなってる。オープンな技術ではないもので作り込んだ末路ですね。

現場サイドだとこれまでも記述したレガシーExcel問題の勃発。つまり、前任者が作ったExcel VBAで業務効率化を図っていたが、退職した途端手出しできなくなり、原始的な仕事に回帰するという・・・プログラミングは現代リーマンの基本スキルですよ。問題は対象のExcel VBAが過去に情シスが作ったもの。今の情シスはコード書けないようで、面倒見れないという。何だソレ。。。

まだレガシーExcel問題については、VBA使える人は山程いるので、容易に解決できますが、Notes DBは致命的です。無理やりSharepointに移植しようとしてる様子は闇抱えてる人にしか見えません。ご愁傷様です。無理やり移植するよりフルスクラッチからウェブアプリケーションつくったほうが早いですよ。

ここで本題。RPAでも間違いなくコレが起きます。特定ベンダーのRPAなんて使ってると、互換性もへったくれもないので、乗り換えもできません（イチから作り直す根性あるなら別ですが）。VBAとはその地位と歴史が違います。VBAはMicrosoft Officeというデファクトスタンダードな製品だからこそ、作り込んでも他でも通用するのです。特定RPA製品のスキルを身に着けても他で通用しません。

とあるベンダーの比較資料について

あえて名指ししませんが、とあるベンダーのRPA製品についての比較検討資料が酷い。ある意味素直に書いちゃってるなぁとは思いますが、こういう比較検討資料を出してまで差別化を主張し、製品を売り込もうという意気込みは結構ですが、言ってる事がそもそものRPA製品全否定自分でしちゃってるって気がついてるのかな・・・特に気になったポイントをピックアップ

一般のRPAは「大きな業務改善を見込める複雑な業務の改善」⇔この製品は「単純な個人業務を自動化」
一般のRPAは「RPA機能のみ」⇔この製品は「システム開発も出来る」
一般のRPAは「高度なITスキルが必要」⇔この製品は「簡単に習得」
そして価格は数万円/年（G Suite Basicは8,160円/年〜です。どちらと契約しますか？）

さて・・・そもそも、これまでも書きましたが、RPAなどの自動化ツールに複雑な業務やらせること自体が間違いです。次に、システム開発も出来るとありますが、だったら、VBA使います（笑）。開発が加わった時点でRPAはその存在意義失ってるんですよ。そして極めつけは「高度なITスキルが必要」と・・ディスってますねぇ。でも、RPAって簡単にスキルない人間でも出来る事が売りでしたよね？。

つまり、RPAって開発だの簡単に使えないだの複雑なといった文言出た時点でアウト。RPAの機能強化の為に開発っぽいものつけ始めた時点で、すでにある開発環境使えば済む話なわけでして。隙間アプリって事忘れてませんか？ある意味ではこの製品の差別化主張は的を射たものです。

個人的見解と結論

さてここまで、個人的にウェブの情報をまとめていて思ったこと、さらに自分の経験を鑑みた時に、愚かではない冴えたやり方を書いてみたいと思います。

素直にプログラミングくらい勉強すればよいのでは？結果的にコストも時間も少なくて済む
VBAってもともと現場事務員向けの簡単にプログラムを組める仕組みで、これまでも広く深く普及し自動化に貢献してきたものなんですが。
目の前の価値の低い反復業務の解決にRPAを用いるより、VBA組める人財育成したほうが早い。
自分で作れるコントロールできるという事に勝るものはない。
RPA使うくらいなら、VBA、VBS、Google Apps Script覚えたほうが業務効率化には遥かに大きなメリットがある。
また、ベンダーにとって客は基本、鴨葱です。また彼らは業務改善のプロでもなんでもありませんし、下手するとコードすら書けないような素人がいたりします。ベンダーの言うがままに導入すると痛い目に合う事になります。
買切りのロケットマウスで出来るなら、ロケットマウス買ったほうが何万倍もマシです。
プログラムが書ける人間にとってRPAはそもそも使うシーンも理由も殆ど存在しない。そもそも、RPA自体、挫折者多数じゃプログラミング勉強させるのと変わらない。

という点でしょうか。プログラミングできる人間にとって、確実性に劣るRPAや本来の意味でのアプリケーションを作れない、応用範囲が狭いRPAになんの魅力も感じないのが現実です。VBAやGASでアプリケーションつくったほうが、遥かに高速で遥かに堅実で、遥かに低コストで作れるので。。。勉強を嫌がって楽に逃げようとするより、遠回りでも堅実にスキルとして身に着ける道を選ばない人は、RPAで自分の仕事を奪われる側になるだけじゃないでしょうか。

もう少し、エンジニア人財やIT周りについて、その価値を認め大切にする気風をまず作ることが必要なんじゃないの？って思う今日この頃でした。

RPA製品買う前に試すべきアプリ一覧

Power Automate – Microsoft Flowであったもの。現在はUI Flowを装備しローカルアプリの操作やSeleniumを使ったウェブの操作もできるようになってる。本業はタスクランナーサービスです。デスクトップRPAも登場しました。
Rocket Mouse Pro – RocketPlayer Pro(10台まで配布可能)でEXE化できるので組み合わせて使える。国産では一押しで歴史も長い。
Puppeteer – Googleが提供してるChromeの自動化を実現するNode.js用フレームワーク。Seleniumよりも遥かに扱いやすい。自分も実際に業務で利用。Chrome操作以外の部分についてはNode.jsにやらせてる（ローカルアプリの操作はVBAやVBSにやらせてます）.Puppeteer Recorderと合わせると最強。
UiPath Community Edition – 無償で利用できる比較的小規模な場合オススメのRPAツール。
Selenium Basic – SeleniumをVBAから利用できるようにしたWeb UI自動テストの為のライブラリ
VBScript – Visual Basicの書式でWindowsを操作するOS標準のスクリプト環境。テキストエディタだけで作れる。
PhantomJS Cloud − PhantomJS自体はChromeのヘッドレス機能の一部に取り込まれましたが、こちらはクラウド版。Google Apps Scriptでサーバサイドスクレイピングなどで使える。動的サイトにも対応してるみたい。
Automator – macOS付属のオペレーション自動化ソフト。コマンドを組み合わせる。GUI版シェルスクリプト。
UWSC – Windowsでは昔からある自動化を実現するソフト。画像認識も出来る昔からフリーで使えている。国産ソフトです。ただ公式サイトが消滅。無償版が使える。
HiMacroEx – マウスの動きを記録・再生するマクロツール。ゲームなどでよく使われているフリーソフト。
Pulover’s Macro Creator – お手軽にAutoHotKeyのようなマクロ記録再生を実現する。日本語対応（翻訳がやや怪しいが）。
AutoHotKey – スクリプトを書くことで自動化を実現するフリーウェア。Windows用。
Katalon Recorder – ChromeのアドオンとしてリリースされてるKatalon Studio（Selenium）向け自動化コードをマウス操作で作ってくれる便利な拡張機能
Windows Scripting Host – これもWindows標準装備のスクリプティング環境。シェル実行やファイル操作自動化ではよく利用する。
PowerShell – Windows7〜搭載している強力なスクリプト環境。シェルスクリプト書ける人向け。
cliclick – ターミナルから使うmacOS用キーボード、マウスをシミュレートする。
WinMacro – Windows操作をマクロ化することを目的とするオープンソース・ソフトウェア。
WinApp Application Driver – MicrosoftがGithubで公開してるWindowsアプリ自動テスト用のスクリプト環境。
WinAppDriver UI Recorder – MicrosoftがGithubで公開しているマウスコントロールをレコードするアプリ。
AutoIT – Basic構文で記述するタイプで、様々な拡張ライブラリが用意されている。海外では有名な自動化ツール。
iMacros – ブラウザに追加して利用するアドオン。簡単にブラウザ操作を自動化できる。Chrome用だとこちら。
Mouse Recorder Premium – 簡単なマウス操作だけだったらこのフリーソフト。高度な条件判定などはないけれど手軽。
SikuliX – Javaで作成されているOpenCV画像認識を利用した自動化ツール。macOSやLinuxでも利用可能だが難易度高め。
RPA-Express – 完全無料で使えるRPAというフレコミ。多機能ではない。

上記のうち、有償なのはRocket Mouse Proくらい。ほかは無償で利用が可能であり、Windows用 / macOS用 / ブラウザ用 / プログラムから利用など様々なものがすでに存在している。年間数十万〜数百万も払って使うのが嫌だという人はまず試してみたい。結局情シスで面倒見るだとか、専任担当者に任せるというならば、RPAなど使う価値は無いです。VBAとRocket Mouseで十分。

自動操作なんてソフトウェアのたかが1ジャンルであり、最新の技術でもなければ何百万も払って導入するようなものでもありません。