日本の「RPA」は正しいRPAではない？
「日本のRPAは他国のRPAと違うものだ」「日本ではRPAが正しく活用されていない」ということがよく言われる。外資系ベンダーのグローバルにおける日本市場の売上比率は5%程度が一般的な値であるが、RPAに限って言うと日本市場はグローバルの25-30%程度あるという、まさに他ではない規模の大きさを誇っている。それだけRPAは日本で特別に注目されていることである。ただ、それは日本が何か先進的な導入を行っているからというわけではなく、「ひとまず流行っているから」と飛びついて間違って入れてしまうケースが多い、とも言われている。そしてそれを理由に「RPAなんで入れないほうがいいのである」と言っている人たちもいる。これらの事柄を筆者の経験から考察してみた。
日本と世界で違うRPA導入意思決定の仕方
米国や英国で進んでいるRPAは、業務整理/標準化と自動化を一体のノウハウとして、ある程度のガバナンスをもってトップダウンで導入する手法がとられることが多いようだ。一方、日本では業務が標準化されていない企業が多く、「IT部門ではなく、ユーザー部門で業務を自らが安価に自動化できるという期待」から、ゲリラ的に今ある業務を局所的に効率化しようとボトムアップで進められるケースが主流のようである。また、RDA (Robotic Desktop Automation)という言葉も日本では使われている。これはボトムアップで個人単位で1台のパソコンにRPAを導入する手法に使われている。ボトムアップによる意思決定だったがゆえに、日本ではRPAが劇的に広まったともいわれている。
なぜ日本と世界は違うのか？
これは「日本のユーザー企業におけるITの無理解」および「標準化すべき業務仕分けができていない」に尽きるのではないだろうか。これは何もRPAに限ったことではなく、IT全般について言えることである。たとえば、パッケージソフトは業務のベストプラクティスを実装しているので、本来は導入と同時に自社の業務を整理/標準化してパッケージに合わせるべきであるが、日本ではパッケージソフトをそのまま導入せずに逆に自社の業務にあわせてカスタマイズしようとするなど、ITに対する考え方が根本的に間違っているケースが少なくない。特に、経営層のITに対する無理解からくるITに対する「リーダーシップ」「戦略とビジョン」の不足も課題となっている。
加えて、日本におけるIT人材の所在はIPAの『IT人材白書』から引用すると、日本のユーザー企業には、欧米諸国と比べてIT人材が極端に少なく、システムの開発や導入は外部のIT企業に大きな部分を委託しているケースが多い。
そのため、ITについて自社で考えることがそもそもできず、第四次産業革命と叫ばれている現在も、自社のビジネスモデルとITを結び付けることができずにデジタルトランスフォーメーションが遅れているという現実もある。(詳しくはこちらの記事を参照)
RPAの開発をアウトソースすると、普通のSIと何が違うのか？
話をRPAに戻すと、よくロボットの作成は誰がやるべきかという議論になる。さまざまな「RPAツール」が出回っているが、「RPAはユーザー部門が自分で開発できる」「RPAはプログラミングの知識は必要ない」という触れ込みのものもあるが、実際に導入して細部を触ってみると、VBScriptやVisual Basic.NETのコーディングが求められるなど、通常のユーザー部門の平均的なメンバーが太刀打ちできる代物ではないものが多い。特に、日本ではRPAツールと称して玉石混交の様々な**「RPAもどきの開発ツール」**が提案されていることも状況を分かりにくくしているものと思われる。
そして、そのような「コーディングの知識が必要」なツールを使うとすると、日本の場合は結局のところIT企業にパートナー企業として面倒を見てもらうことになる。ユーザー企業としては常駐なのかアウトソースなのか、いずれにしてもRPAツールのライセンスに加えて外部エンジニアの人月を継続的に買うことになる。そうしたときに、ユーザー企業から見るといままでのシステム開発と何か違うのであろうか。RPAツールによってパートナー企業における開発コストが下がってユーザー企業が買う人月が下がるのであろうか。答えは否である。この構図に陥ってしまうと、いままでのSIと同じになってしまう。「RPAは意味のないもの」といわれても仕方がないだろう。
RPAの「ロボット」の必要条件って何だろうともう一度考えてみる
それでは、RPAがユーザー企業にとって意味があるものとなるのに必要な条件とは何だろう、ともう一度考えてみよう。パソコンの画面の中でアプリケーションを操作するというしくみは、OSのAPIを呼べば実現できる汎用的な技術で、プログラミングがちょっとできれば誰でも比較的簡単に作成することができるものである。中には、このレベルのものをRPAと呼んでいる人もいるが、単にAPIを呼んでいるレベルではロボットとは言えない。
ロボットといえば思い浮かべるのは「ドラえもん」「鉄腕アトム」のような、人と言葉、しぐさ、表情等の「ユーザーインターフェイス」で会話をして問題を解決してくれるものを想像するだろう。現実的には現時点でここまで高度なインターフェイスは実現されていないだろうが、ロボットとそうではない機械を差別化する一番の要因は、何ができるかというよりは、「プログラミング言語などとは無縁のごく一般的な人でも簡単にコミュニケーションを行って命令できる」という高度で使いやすいユーザーインターフェイスを持っているというのが、多くの人が想起するロボットに必要な条件であろう。仮に人の形をしていても、人間が直接C言語を書いて命令しないと動かないようなロボットは、一般の人にとって使えるロボットとは言えないだろう。
以上を元に、RPAのロボットについても考えてみると、「RPAはユーザー部門が自分で開発できる」「RPAはプログラミングの知識は必要ない」というところで想定されている条件は、まさに先ほどのロボットと同じで、高度で使いやすいユーザーインターフェイスを持っているというのが一番の必要条件となってくる。このようなインターフェイスを持っている製品は、実はとても限られている。まず手でコーティングをしなければいけないような製品/手法は除外される。少なくとも、レコーディング機能や部品のドラッグ＆ドロップでロジックの相当部分が完成するものでなければならないだろう。また、環境が変化しても自動的に適応してユーザーの手を煩わせない機能も必要である。
RPAは入れるべきでないという意見
ところで、日本ではRPA不要論も根強い。中を紐解いてみると、今までに出てきたような、「日本のボトムアップによるRPAの浸透」や「外注に頼る日本RPAの」に対して懸念を表明している。たとえばということで、RPA不要論の例として①『RPAを導入すべきではないこれだけの理由をまとめてみた - officeの杜』と②『日本だけでバカ売れするRPA、愚かな結末を改めて警告する- 木村岳史の極言暴論！ - 日経XTECH』を参照させてもらい、ポイントをピックアップしてみた。
①の主な論点
- RPAにも変数やら繰り返し処理やら普通にプログラミング知識要求するものが存在します。これを使わずにシナリオ作るとかあり得ません
- ウェブアプリケーションをマウス操作でどうこうするケース。それそのものはノンプログラミングでもできるでしょう。しかし、外部委託した場合普通、REST API叩く機能で構築します。ウェブのUIやフローは日々進化します。しかし、もっとも根源であるREST APIは通常機能強化はされても、大きな変更はなされません。
- そもそも、業務用プログラム作る上で最も時間を使うのはプログラミングではなく、業務フローの断捨離と整理。そしてそれに基づく、業務をプログラム化する為の論理的思考能力。現場の事務員にコレできるんですか？SIerでも最も気を遣う所で、最も面倒な作業ですが（多くのケースで、現場の事務員が自分の仕事をきちんと分解して、整理説明、断捨離できるケースは存在しません）。これをやらずにプログラムなりRPAやると、間違いなく破綻します。
- うまく動かなかった時のデバッグ作業。そもそもデバッグって意味わかってますか？なぜか知らないけれど動かない、、だと詰みます。
- プログラミングと違ってメンテナンスフリーだと思い込んでる人がいる。ケースによっては、VBAよりもメンテナンス面倒ですよ。
- 現場の事務員でも作れるという触れ込みにも関わらず、ある程度ITリテラシーある人、プログラミング知識ある人に任せる・・・属人化やブラックボックス化云々の話どこに行ったんですか？
それぞれのポイントは至極真っ当な指摘である。RPAツールと呼ばれているものの多くは、宣伝している内容に機能が追い付いていなく、プログラミングの知識や場合によってはコーディングまで求められる。
今RPAであれこれ自動化って、はるか昔からとっくに別の選択肢で実現できてたものであって、RPA導入しないと出来ない事ではない。もっと言えば、「ロケットマウス」や「UWSC」、MacならばAutomatorなど自動化アプリって昔からあります。VBSって選択肢もありますね。CUIの世界なら大昔から、シェルスクリプトがありますし、Windows7からはPowershellも選択肢の一つ。
VBAでもディープに操作可能な、ウェブアプリケーションの自動テストでも用いられる「Selenium」にて、Chromeを自動操作などは、画面認識でやらせるタイプのRPAよりはるかに正確で確実に処理が可能です。その為の自動テストアプリなんですから。Selenium Basicを用いる事で、VBAから、マウス操作ではない形でブラウザを遠隔操作可能です。
自動化の方法としては、そもそもRPAだけではない。API連携とかプログラミングができるのであれば、より確実性の高い手段をとるべきだというのもその通りだと思う。
ただ、結論の方向性は共感できるだろうか、考えてみてほしい。
- 素直にプログラミングくらい勉強すればよいのでは？結果的にコストも時間も少なくて済む
- VBAってもともと現場事務員向けの簡単にプログラムを組める仕組みで、これまでも広く深く普及し自動化に貢献してきたものなんですが。
- 目の前の価値の低い反復業務の解決にRPAを用いるより、VBA組める人財育成したほうが早い。
- 自分で作れるコントロールできるという事に勝るものはない。
- RPA使うくらいなら、VBA、VBS、Google Apps Script覚えたほうが業務効率化には遥かに大きなメリットがある。
- また、ベンダーにとって客は基本、鴨葱です。また彼らは業務改善のプロでもなんでもありませんし、下手するとコードすら書けないような素人がいたりします。ベンダーの言うがままに導入すると痛い目に合う事になります。
- 買切りのロケットマウスで出来るなら、ロケットマウス買ったほうが何万倍もマシです。
- プログラムが書ける人間にとってRPAはそもそも使うシーンも理由も殆ど存在しない。そもそも、RPA自体、挫折者多数じゃプログラミング勉強させるのと変わらない。
これは完全に「プログラミングができる個人から見た目線」である。そもそもIT企業であってもエンジニア部門でない従業員は、たとえば営業、管理部門、人事などを考えたときにExcelマクロ/VBAができる人ですらかなり少数派である。残念ながら全員にプログラミングを習得させるのは難しいと考えざるを得ないだろう。そういう人たち向けのソリューションとして、現状のRPAが完璧かどうかはさておき、存在するのがRPAという位置づけなのだろう。また、個人でRPAを使うレベルではなく、組織全体で使う際には、効率を見たり管理監督を行ったりする「サーバ機能」が必要になってくる。これも、プログラムを書いて自動化する方法では簡単に実現できない仕組みである。
②の主な論点
本当にこのまま無原則にRPAを導入してよいのか。RPAは伝票などのデータ入力など、オフィスのパソコンで人によって行われてきた業務作業を自動化する。そして自動化の先にあるのは、業務のブラックボックス化だ。RPAを導入して半年、1年たてば業務作業の手順どころか業務の内容そのものが、誰にも分からなくなるぞ。そんな状態でRPAに何かトラブルがあれば……考えるだけでも恐ろしい。 改めて断っておくが、私はRPA自体が駄目だと言っているわけではない。日本企業の導入のやり方がこのままではまずいと言っているのだ。
これも至極真っ当なご意見。欧米のRPA導入方法のように業務整理をやらずに小手先のツールだけでなんとかしようとしていることに警鐘を鳴らしている。
日本企業の場合、ほとんどのRPA導入は合理的判断によるものではない。部分最適あるいは属人化した複雑な業務作業は「余人をもって代えがたい」担当者の長時間労働によって処理されてきた。RPAのソフトロボに置き換えれば、複雑な業務でも一気に効率化できる。だから日本企業はRPAに飛びついたわけだ。 ...業務自体も業務を支える基幹系システムもブラックボックス化しているのに、さらにRPAでブラックボックス化を推し進めようとしている。これを不合理な判断と言わずして何を不合理と言うのだろうか。
ひとまず流行っているツールがあるから現場判断でボトムアップでRPAを入れてしまったことに対する不合理ということだろう。これもその通り。
基幹系刷新に伴う業務改革が現場の抵抗で挫折するのは、これまでの業務のやり方を変えたくないからだ。だが、どうせRPAで自動化してしまうのなら、業務のやり方を変えたところで、現場には何の問題もないはずだ。そうすると、RPAの導入は基幹系刷新と同時に進めるのがベストソリューションとなる。これでどうだ！
これも至極真っ当である。
以上みてきたことからまとめてみると、「いままで日本のRPAは業務整理をせずにボトムアップでツールだけ導入されてきたが、それだけだと効果が薄いので考え直したほうがいいよ」ということだろう。また、RPAツールは何か特別なことができるわけではなく、あるとすれば「プログラミングしなくてもよいインターフェイスをもっている(べき)」(RPAの価値があるとすれば、ここが差別化要素となる) ということだろう。
いまのRPAはまだ一部の部門でしか使われていない
さて、RPA不要論まで極端なことを言っていない人たちの間でも「RPAの効果が見えない」という論調は多いのだが、その原因を別の角度からも考えてみよう。データで見てみるとRPAの導入を始めている1,000名以上の大企業はすでに95%を超えているにもかかわらず、投資対効果がわからないという企業は40.5%、全社展開まで進んでいる企業は3%しかないという深刻な状況である。状況としては、数台のロボットをいくつかの業務に使っているだけなのである。
効率化ツールは全社で使われないと効果が測りづらい
業務効率化ツールというのは、たとえばMicrosoft社のOfficeやGoogle社のG Suiteなどもそうであるが、ワークシートツール、クラウドストレージ、情報共有ツールなどの便利なしくみがあるが、1人もしくは数人で使っている限りはその個人で感じる利便性はあるかもしれないが、会社として費用対効果があがっているかを見るのはとても難しい。より広く、部門単位、もしくは全社単位でツールが使われてこそ、組織全体としての効率性が見えるようになってくるのである。
RPAはAIエンジンを実用的に展開するためのツール
また、RPAツールは「プロセスの実行をする」ツールであり、人型ロボットでいえば「手足」に相当する。RPAツール自体は考えないが、同様にここ数年流行っているAIと組み合わせることで「思考ロジック/言語解析 (脳)」「画像認識/OCR (目)」「音声認識 (耳)」「音声合成 (口)」等、人が行っているインテリジェントな作業を置き換えることができる可能性を秘めている。そういう意味で、RPAとAIは組み合わせの相性がよいのである。もちろんプログラミングでも同様のことを実践できるのだが、人が命令するインターフェイスがプログラミング不要なものであるならば、エンジニアでない人にとってもAIはより身近で使いやすいものになるだろう。
結論
まとめると、日本では他の世界とは違う「ボトムアップの手法」によって業務整理がされないまま現場でRPAツールが急速に普及してきた。RPAツールが身近になったという意味ではよかったが、RPAの効果が良く見えない形で導入されてしまっているところも多くあり、その効果をみえるようにするには、組織内でより広く使われるような導入手法が今後取られていく必要があるということになる。そのためにはRPAツール側にも条件が求められ、より広いユーザーが使えるような優れたユーザーインターフェイスが提供され、さまざまな業務ツールやAIを現場でより使いやすく、かつ効率的に自動化できるような仕組みが求められ、それができるとRPAの導入も次のステージに進むといえるだろう。