RPAの失敗事例

 皆さんおはこんばんにちは! やっぱりまだまだ殻が取れてないITヒヨコの佐助のおっかあです!

 先日、我が家の海里(セキセイインコ♂・5歳)が座布団の上に降り立ちながら『チャクチ!!』と言い放ちました。ビックリ。教えたことのない言葉なのに、何故? しかもタイムリー・・・謎が尽きません。

 さて! 表題にも書いたとおり、RPAでございます。
 コイツは何ぞや?と言いますと・・・簡単に言ってしまえば『仕事をよりやりやすくするための、デジタルツール(道具)。ボタンひとつであら不思議。いくつものアプリが連動して、手間のかかる仕事を自動でやってくれちゃいました!』てな感じのシロモノです。

 今話題の映画『AI崩壊』で描かれている”AI”と何が違うのか? 実はコレ、けっこう単純なコトであるんだとか。
 いわく、AIは【膨大なデータの中から、自分で答えを探して決める】ことの出来るもの。時々将棋とか囲碁とかで人間と対局しているアレ、アレはまさにAIです。あのロボットアームを動かしているシステムは対戦相手である人間に勝利するために「天文学的な数ほど存在している」という指し方の中から自分で最適な一手を思考し選択しているのです。こんなとんでもないコトが出来るAIは、いずれ彼らを生み出した人間さえも超えるのではと囁かれています。【その日】が訪れるのは予測では2045年・・・果たしてどんな世界が広がることになるのでしょうか?
 RPAの方はというと、こちらは一定の作業を一定のルールに沿ってこなす、単純作業に適性があります。データ入力など決まった型が存在する仕事に向いており、そうした業務を中心とする職場であれば比較的導入しやすいとも言えるそうです。作業場所と素材、道具、完成までの解説書を用意してあげれば「後は任せておいて!」と請け負って見事完成させてくれる、それもたくさん・・・そんなイメージですかね。

 とまぁ、RPAとAIについての解説はこのくらいにしておきましょう。コレ、語り出すと長くなりますから・・・絶対長くなりますから! ものっそいザックリしてるけど、許してくださいね!orz

 ごほん。
 今回の主役・RPAがどの程度普及しているかを調べた、非常にわかりやすい(かつ有難い)データがこちら。


画像引用元:ZDNet Japan

 これを見ると、大手企業はもちろんのこと、中小企業でもかなりRPAというシロモノが普及してきているのがわかります。RPA導入には、実はさほど費用はかかりません。やらせる事の内容によるとは思いますが・・・それでもAIを導入して同じ作業にあたらせるより圧倒的に、経費を安く抑えられるでしょう。これが恐らく、資金的にどうしても大企業より余裕度の低くなりがちな中小企業においてもRPAが普及している一番の理由だと思われます。
 中小企業では人件費の問題も良く発生してしまいますが、RPAはそれまで『簡単な作業でありながら、人員を割かなければ出来なかった業務』を肩代わりしてくれるモノなので、導入に成功すれば、その作業の分の人手を他の業務にまわすことが出来ます。だからこそ、たとえ導入までの過程で費用がかかったとしても、長期的に見れば費用をかける価値がある・・・そう考えて導入に踏み切るところも多いのではないでしょうか。

 また、導入に踏み切った企業は複数のRPAを併用しているところもけっこうあるようです。それが、こちら。


画像引用元:ZDNet Japan

 さてさて。業務の効率化に役立ってくれる”魔法のツール”RPAですが、そんなにホイホイ導入出来るものなのでしょうか? そして、せっかく張り切って導入しても上手くいかない、なんて悲しいコトはあったりしないのでしょうか?

 これ、実はけっこうありがちのようです・・・
 海外のデータなのですが、RPA導入プロジェクトが失敗だったという結末になってしまう率・・・まさかの50%だとのこと。( ゚Д゚)
 まぁ高くても3割くらいだろうなーなんて思いながら調べてたんですけど、予想をはるかに上回る失敗率。そんなに甘くはないみたいです。一気に『ハイリスク・ハイリターン』なイメージが出来上がってしまいました。おふう。
参照:TechTargetジャパン

 では何故、苦心して作り上げたはずのプロジェクトが失敗してしまうのか。
 RPA導入・運用に伴う失敗例を上げていきますね。

十分に活用出来ず、導入効果が感じられない

 これが一番多い失敗例だそうです。
 たとえば、『残業が多い職場で、残業を減らすためにRPA導入。しかし、残業を発生させている原因の業務が人間の臨機応変な判断を必要とするもので、RPAで捌き切れるものではなかった』など。
 また、現状で負担になっていない業務をRPA化しても「導入してからラクになった!」というような解りやすい成果を感じることは出来ません。
 これだとせっかくのRPAが無駄になってしまいかねないので、任せる業務を厳選するなどの対応が必要になります。

依存しすぎることで業務が滞る

 便利だからといって何でもかんでもRPAに業務を振り分けていると、やがては会社全体がRPAに依存してしまう・・・ということにもなりかねません。
 予期せぬトラブルでRPAの動作が停止してしまったとします。これがすぐに修復出来るものなら特に問題はないかも知れないのですが、直せない場合は修復に人員を割かなければならないし、トラブった箇所を洗い出したり新しくプログラムを組まなければならなかったりと復旧にも時間がかかります。つまり、その間中ずっとそのRPAがまわしていた業務は滞る、ということに。
 更に、RPAは基本的に誰かが監督していなくても自動的に業務を進めてくれるので・・・導入当時にその業務を行っていた担当者が異動や退職などをしてしまうことは珍しくありません。すると、上記のトラブルの危険度はかなりアップします。復旧までの代替策として手作業で業務を行おうにも、その作業の正確な手順や注意点がわからない・・・といった事態にも発展してしまう場合があるからです。こうなったらもう目も当てられませんね。

頻繁なメンテナンスで業務時間が増えてしまう

  RPAにも、定期的なメンテナンスは必要です。業務手順やルールが変更になった時には、新しいものに合わせた再設定をしてやらなければなりません。
 メンテナンスには当然ながらある程度の時間はかかるワケなので、あまりにも頻繁に変更が起きるような業務を自動化してしまうとRPAが削減してくれた時間よりもメンテナンスに費やした時間の方が上回り、かえって業務時間が長くなることがあります。
 また、最近のRPAツールは簡単に操作出来る使いやすいものが増えてきているようなのですが・・・私のようなアナログ派タイプの人にとっては「? ??」となりがちなもの。いきなり「こうで、こうしたら、こうなるから。カンタンでしょ?」などと言われても理解するには時間がかかります。「壊したらマズい・・・」とビビり気味になって、ますます手が遅くなるかも知れません。簡単な(→機械やITに強い人にとってはそうでも、一部の人にとっては冷や汗かくほど難しいものに思える)設定変更でも余計に時間がかかってしまいそうです。

一部の部署は導入に成功したが、これを聞いて後から導入しようとした他部署が失敗

 これは、ある部署がRPAを取り入れて成功した話を聞いた他の部署が「じゃあウチも」と便乗した結果、足並みはバラバラ、ツールもバラバラでまとまりがつかず結局失敗・・・となった事例だそう。この例では最終的に会社のシステム部が出張ってきてツール選定からやり直すことになったとか。
 本当は会社の方針として段階的に理解度を深めながら少しずつ取り入れていくハズが、先行した部署の成功っぷりが劇的だったのかなんなのか我も我もとRPA導入に向けて雪崩のように動いてしまい、結果『RPAとはどういうものか』についての理解が追い付かないまま急激に広がってしまったことによる弊害です。

 他にも・・・

RPAツールが自社の業務内容に合っていない

 RPAツールにもいろいろと種類があり、それぞれに得意・不得意があるのだそう。
 苦手な仕事を任されたら、人間だって大変ですよねぇ。そりゃあもちろん仕事は仕事なんで逃げずに頑張って立ち向かうワケなんですけど、やっぱり得意な仕事より時間はかかってしまいます。それと同じコトなのではないか?と筆者は思います。
 恐らくですが、複数のRPAツールを導入している企業は、個々の特性に合わせて「コレにはこの仕事。アレにはあの仕事。」と使い分けているのかも知れませんね。

RPAを導入する業務範囲が適切でない

 よくありがちなのが、導入する側が最初に張り切り過ぎて広範囲の業務をRPAに任せようとしてしまうこと。あれもこれも、と詰め込んだ結果パンクしてしまい・・・ロボットが動けなくなって、かえって業務遂行に時間がかかったり、最悪長時間にわたるメンテナンスが必要な事態になるケースも。

 今更なんですけど、RPAの”R”って『ロボット』のコトなんですって。何も知らないまま使ってました・・・反省、反省。
 正式には、『Robotic Process Automation(ロボティック・プロセス・オートメーション)』と言うのだそう。ロボットって、目には見えないものも存在するんですねぇ。

 さて、ヒヨコがちょこっと賢くなったところで、話を元に戻しますね!

最初から『完璧な計画』を立て過ぎる

 コレは正直言うと、意外でした。だって、これだけ難易度が高いんですもん。一点の欠けもないほどの綿密な計画を立てて挑まなければ導入成功は出来ない・・・と身構えるのが普通だと思うんですよ。
 ところが、参考にした記事を読ませていただいて納得。
 RPA導入へ最初に舵を取るのって、多くはその企業のシステム開発部門や情報システム部門だそうなんですけど・・・その部署にいる社員全員が実際に導入を受ける部門・現場の仕事について熟知しているかと言ったら否、だったりするワケで。それでも『完璧な導入成功』を求めているうちに導入先との連携不足や解釈違い、もやっとした思い込みが原因となって、『現場社員が本当に欲しいRPA』とは乖離したものが出来てしまうことが多々あるそうなんです。無事に成功したとしても、時間がかかってしまうパターンも良くあるらしいです。
 なので、企画段階にいるだろう部署の人達だけでいきなり『完璧』を目指すのではなく、実際に扱う人達とじっくり話し合って少しずつ『完璧』に近付けていく・・・のが正解なのかも知れません。

 【失敗例あるある】をリストアップしているサイト様もあったので、そちらも引用させていただきますね。

・業務や取引先ごとにばらばらにロボットがなし崩し的に稼働して運用コストが増えてしまった。
・いろいろな業務でRPAが試されていて、全体を把握できない。
・現場のスキルやノウハウが不足していてなかなか進まない。使用率があがらない。
・個別のロボットの稼働状況を見てみたら、意外と稼働していなく最適化されていなかった。
・ITスキルが高いエンジニアがロボットを作ったが、その人の業務をRPA化しているだけで他の人には理解ができない。ますますブラックボックス化してしまった。
・ロボットを作成した担当者が異動してしまい、だれもそのロボットのことがわからなくなった。
・現場のメンバーのモチベーションがわかない。業務を取られるのではないかという反発が起こってしまった。
・ウォーターフォール型の開発プロジェクトを組んでしまい、スピード感がなくなるうえに成果物が現場のニーズと違ってしまう。

参考:ITトレンドITmedia ビジネスオンラインQiita

 では、せっかくの頑張りを水の泡にしてしまわないために出来ることは、なんでしょうか?
 まずは、失敗例を踏まえてからの注意点を、説明してくれているサイト様からご紹介。

RPAで自動化する対象業務の性質に着目する

RPAはあらゆる業務の自動化に対応できますが、場合によってはできないケースもあります。基本的にRPAを使って自動化できる業務は単純作業であることがほとんどです。
したがって、人の判断を毎回挟むような特殊な工程が必要な作業にはRPAは不向きです。どうしても自動化したい場合は、まずは現状の業務を整理しRPAに任せられるところまで簡略化する必要があります。
またRPAの開発に関する知識・技術があれば、複雑な処理もRPAが自己判断して進められるようにカスタマイズすることもできます。しかし、RPAツールの提供形態によっては自社仕様にカスタマイズすることにも限界があります。自社で開発を行うと膨大な工数がかかることにも注意しましょう。

誤作動やシステム障害の可能性を考慮する

RPAはITシステムであるため、小さなエラーや誤作動が起きる可能性もゼロではありません。また、RPAへの指示内容に誤りがあった場合でもそのまま機械的に処理が進んでしまうため、ミスが大量発生してしまう可能性もあります。
ヒューマンエラーに比べれば、RPAが起こす不具合や誤作動の割合はかなり少ないと言えます。しかし、完全にゼロにすることはできない点は考慮する必要があるでしょう。
企業にとって重要な業務を自動化している場合、システム障害が発生すると業務がストップしてしまいます。リスクと効率化のバランスを考えて自動化する業務を選びましょう。

RPAの維持管理費用を導入計画に組み込む

RPAは導入して終わりではなく、業務内容の変化に合わせて定期的なメンテナンスが必要になります。メンテナンス実施には知識と技術を持った担当者が必要です。ITリテラシーが全社的に高い企業であれば比較的容易かもしれませんが、そうでない場合は新たに人員を増やすことによるコストが発生します。
また企業としての業務内容に大きな変更があった場合は、これまで利用してきたRPAの機能だけでは不十分な場合もあります。既存のRPAをカスタマイズして自社仕様の機能をつけたり、新しい製品に買い換えれば大きな出費となるため、導入時にはなるべく追加でコストがかからないような計画を立てましょう。
引用元:ITトレンド

 筆者のようなITヒヨコにもちゃんと読めば理解出来るよう書いて下さってあるので、有り難いですね!
 ただ、理解出来るのと実際にやるのとではまったく異なるので・・・きっと大変な工程になるのでしょう。
 それから、【あるある】をリストアップしてくれていたサイト様に対策のリストもあったので、こちらも引用させていただきました。
 専門用語が多くてITヒヨコには完全に理解することは出来なかったのですが(-_-;)

・RPA化を行う前に、まず業務の見直しを行う。BPOを行う際の業務整理のプロセスを事前に入れておくとよい。業務整理をしたうえで再定義されたタスクについて、汎用性が高い業務は市販のパッケージソフトを導入することを考え、その次にはシステム化することを考えるべきである。残りのシステム化できない部分は現場で同ハンドルするかをRPA、手作業の外注 (アウトソース)、従業員による手作業のどれでやるべきかを検討する。

・業務整理やRPA化にかかわる知識を社内で集める Center Of Excellence (COE) 部門を立ち上げる。メンバーには、コミュニケーション力とやる気が高い若手や女性をアサインしておくとよい。
・全体の把握ができるように、最初からサーバ型RPAを使う。PoC自体は最初は現場主導でやらせたり、目安箱を設けてRPA化/見直ししてほしい業務を募ってみてもいいだろう。プロジェクトが進んできたら、IT部門やCOE部門によるガバナンスを効かせていくのが良い。
・現場で高いスキルを持った人が継続的に活用できるとは考えないほうが良い。その人が異動してしまった場合のことを常に考えてみる。RPAツールは、高度なプログラミングスキルを持っていなくても扱えるものを選んで運用すべきである。
・ロボットの稼働状況は全体が見えるようにレポートを作成する。とはいっても、人間がロボットの稼働状況を調べて報告するようでは本末転倒なので、サーバ型RPAでレポーティングツールがついているものを活用して自動で見える化できるようにしておく。
・ロボットは作成する前に、まず誰にでもわかる形式で仕様書を作成する。
・RPAにかかわるメンバーや対象部門のメンバーには、RPA化/業務効率化することの意義を伝え、仕事を取り上げられるリスクがないことを伝える。うまく効率化できた場合には表彰したり、意識改革 (ジョブ・クラフティング)を行うなど、ソフト面でも部門で仕組みを作ってサポートをする。
DevOps型の開発手法を取り入れ、現場とロボット作成者が綿密に連携を取りながらCI/CDを行っていく。
引用:Qiita

 頑張ってじっくり読み込んでみると「そういうコトか!」となりました。
 まぁ・・・例によっていろいろ調べつつ、進んでは戻りの繰り返しになっちゃって時間がものすごいかかったんですけどね(;^_^A
 いつか、すんなりこういう記事が読める日が来るといいなぁ・・・

 リストのサイト様でも書かれていましたが、RPAはあくまでもツール。便利だし、上手く導入出来れば業務がラクになるし、などなど(語彙がなくてスミマセン・・・)いろいろと役立つモノであるのは確かだけれども、『導入すること』自体をゴールにしてはいけないのだと言います。
 何故なら、RPAツールは【業務効率化】という大きな目標のためのひとつの手段であって、実際に運用して成果を得られて初めて『ゴールした』と言えるのだから。【業務効率化】を達成するための手段は他にもあるし、もしかしたらそちらの方が適しているかも知れない。だから、【業務効率化】をひとつのプロジェクトとして立ち上げて、そこにRPAツール導入を含めることを勧める・・・という意見です。 

 アレか。『目的のためには手段を選ばない』が『手段のためには目的を選ばない』に変わったらアカンよ、という。・・・え? そんな殺伐とした内容じゃない、って?

 大したコトなど言えないITヒヨコが今回得たものは、RPAというものに対するざっくりしたイメージが少しだけ明確になったこと、そして意外なほど高い導入失敗率と成功した場合のリターンの大きさのこと、導入自体を目標にしてはいけないこととその理由。
 今お世話になっている現場でもRPAの導入を進めていて、現場の社員さん達が忙しなくやりとりをしているのですが、何故そんなことになっているのかの真相と大変さが少しだけわかりました。
 ヒヨコな筆者にはまだそれをお手伝いするだけの技量がなく、ただ日常業務をこなしていくしかなかったのですが、いつの日かかぶったままの殻が取れてRPA導入プロジェクトに参加出来るだけの力をつけられた時には、今回の記事で学んだことを心がけるようにしたいと思います。

 以上、途中まで冗談抜きでRPAの”R”の正体を知らなかった佐助のおっかあがお送りしました。

[執筆:佐助のおっかあ
[最終更新日:2020年2月14日]