最初に謝りたい。

今回は１００％私見である。

いつも私なりの意見を書いているので、いつも「私見」なのだが、今回は特に鵜呑みにするのはよくない内容を書く。

だが、私が常日頃から思っていることなので、あまり暴論ではないと自分では思っている内容だ。

あくまでも「こういう考えの人がいるんだー」っていうレベルで読んで欲しい。

というか、どのメディアもこの視点で読むことをオススメする。

日本がクリスマスにフライドチキンを食べるようになったのは、ケンタッキー・フライド・チキンがテレビで嘘をついたからというエピソードが有名だ。

なので、世の中に溢れている情報をインプットするだけではなく、「本当にそうなのか？」という視点で色んな角度から見てみる姿勢が大事だと思う。

ロボットって何だよ

言いたいことが山ほどあるが、書き始めるとシリーズ化しそうだ。

そこで、メッチャ言いたい３つに絞ってみようと思う。

「思う」なので、もしかしたら書き始めると５つ、６つ、７つとなるかもしれない。

その時はシリーズ化しよう。

 

さて、本題に入っていこう。

１番言いたいのは、「ロボットって何だよ」ってことだ。

いや、分かるよ。

「ロボティック・プロセス・オートメーションの略なので、ロボットです」ってことですよね？

分かります。

ええ、分かります。

でも、だからといって、いないロボットをあたかもいるかのようにセールストークするのは、どうなんですか？って話です。

デジタルレイバーとかパトレイバーかよって思いました。

従業員の代わりになりますって言っている人もいましたが、なるわけねーじゃんって思って話を聞かせていただきました。

C#やVBといったプログラミング言語で作られていることが多いと思いますが、同じ言語で作られている基幹システムはロボットですか？と聞きたい。

ただのシステムやんけ。

そんな言葉を使ってITリテラシーのない人を騙すな。

真っ当に営業しろ。

 

おっと口が悪くなった。

大変失礼した。

効率性が悪すぎて笑える

次に言いたいのは、効率性の悪さである。

RPAは確かに自動化を行うサービスで、業務効率性を向上させることに効果があるだろうと期待できる。

事実、多くの企業や市区町村にも取り入れられており、効率が向上したという事例がある。

２年前の記事ではあるが、このような事例が紹介されていた（【22年11月最新】自治体でのRPA活用法5選！導入事例やおすすめツールを紹介）。

たとえば

• 石川県加賀市：介護保険の３業務で年間１５９時間の削減
• 新潟県長岡市：１８業務で年間４１３６時間の削減
• 兵庫県伊丹市：２１業務で年間８３０時間の削減

このような事例が紹介されている。

だが、「RPA普及しない理由」と検索すると一番出てくるのが、「効果を実感できない」という結果である。

そりゃあそうである。

頑張って頑張って導入して、「これだけ？」っていうのが現実である。

先に挙げた事例３つも大した削減ではない。

たとえば石川県加賀市を例に考えよう。

１５９時間の削減となるが、月にすると１３時間（13.25）である。

３業務なので、１業務あたり月間４時間程度の削減ということになる。

こうみると、「あれ？」と思うだろう。

弊社の事例で申し訳ないが、弊社では以下のような事例がある。

• 毎日３時間の残業時間が１０分になった事例（月間６０時間が２０分）
• 毎日４時間の業務が３０分になった事例（月間８０時間が１０時間）
• 毎月１０日の業務が１０分になった事例

上記はいずれも１業務の事例で、それを３つ並べただけである。

年間にしよう。

• ７２０時間業務が４時間（７１６時間の削減）
• ９６０時間業務が１２０時間（８４０時間の削減）
• ９６０時間業務が２時間（９５８時間の削減）

となる。

削減効果が高いのはどちらの方が高いのかは明らかである。

RPAは大した削減効果を発揮できないのだ。

こういうと、「OCRが使える！」と言ってくるんだが、そもそも「DX化しよう！」「デジタル化しよう！」という流れにおいて「OCR」を武器にすること自体が誤りである。

ちゃんとシステム化していればOCRの入る隙間なんか１ミリもない。

もし入るとしても業務プロセスが誤っている可能性がある。

大した削減効果もないくせに、不利と思うや否やOCRなんて有害物質を振りかざしてくるなと言いたい。

勉強しても無駄になる

そして、最後に言いたいのは高すぎる学習コストと一瞬で無駄になるリスクである。

あれ、２つになった？

実は１つだ。

業務中に勉強する時間もないし開発する時間もない

RPAのセールスマンは

• 文系でもできます
• パソコンが苦手な方でもできます
• 年配な方でもできます
• エンジニアじゃなくてもできます

などなどと「簡単」推しでセールスしてくる。

で、買ってみると誰もできない。

何故か？

そもそもExcelをはじめとしたOfficeを扱うことができない人に、RPAを教えるのは難しいからだ。

ある程度のITリテラシーが必要である。

そのITリテラシーがない人でもできる、というのは余程の教育コストをかけないと無理であろう。

「そもそも業務中に開発できるか、こっちは忙しいんだよ」っていうのが多くの方の正直な意見だろう。

忙しい毎日を過ごしているにもかかわらず、研修と称して業務の邪魔をする。

研修で学んでもチンプンカンプンだし、分かったとしても業務中に開発にあてる時間はない。

もしあったとしても、我々エンジニアからしたら出来の悪いものしかできない。

製品を変えたら学び直し

そして、RPAはサービスの総称である。

もしサービスを変更したら、どうなるか？

１から学び直しなのだ。

RPAができるって言っている人を採用したけど、全然活躍できない。

それは、できるといったRPAの製品と会社で使っているRPAの製品が違うから発生する現象である。

一生懸命学んで学んで学んで、製品変えたらリセット。

スマホゲームでこんなことが起きたら、即アンインストールだ。

もう触らない。

これがRPAで日常的に起きる。

素人作品は出来が悪い

そもそも論だが、エンジニアでもない人が業務をしっかり自動化できるか？というと疑問しかないのだ。

エンジニアであれば、事前に考慮できる項目も素人であれば考慮できない。

予期できる不具合ですぐ落ちる自動化が大量に出来上がる。

業務をしっかりと仕組み化していて属人化なんて無縁である、という状態であれば素人でも何とかなるだろう。

だが、そこまでの仕組み化を実現している事例はほとんどない。

結果、出来の悪いものが出来上がる。

Aという業務全体の中の自分の業務にだけは対応できるかもしれない。

だが、別の人の業務も担当することになった瞬間、動かなくなる。

または、料金の桁が１つ増えた、減った、たったこれだけで動かなくなる。

こんなことは日常茶飯事である。

最後に

他にも言いたいことがある。

• マクロをバカにする割にやってることはマクロ
• 「ブラックボックス化しない」は嘘
• セキュリティを担保できない
• 紙文化を捨てきれない企業がやる対策に過ぎない
• Office製品をバカにする割にOffice製品で何ができるか知らない
• 結局本格的に使うなら開発するしかない

などなどある。

が、言い出すと溢れて止まらないので、この辺で終わろうと思う。

機会があれば、また書くかもしれない。

 

さて、ここまで私はRPAをディスってきた。

実際、RPAは大したことないと思っている。

エンジニアとして効率性を見た時、その程度なら「片手間」で作ったツールと同じくらいじゃん、と思うのだ。

それで何千万も請求するんだから、ぼろい商売だと思う。

 

だが、RPAを導入した方がよい部分もある。

基幹システム連携が多い業務や紙でのやり取りが多い業務、PDFでしかやり取りしない業務などだ。

これらはRPAによる自動化が効果的である。

このように業務によってRPAを使うべきかどうかを見極める必要がある。

何でもかんでもRPA！だと痛い。

また、パワーのあるパソコンやサーバーにRPAを搭載できるのか？というのもRPAを使う上で重要なポイントになる。

この辺についてはまた今度コラムにしようかと思う。

 

今回のコラムが気づきや学びになった方はシェアをしていただけると嬉しい。

また次回のコラムでお会いしましょう。