「D-Analyzer」は、業務に利用しているPCに仕込むことで、利用実態や業務プロセスを収集・分析する。

「だいたい3カ月分析するのが基本ですが、最低限月末月初の繁忙期などを含む1.5カ月のログをとって分析します。余裕のある時期のログでは負担のある業務が見えてきませんし、逆に長期間のログをとっても変化が少なく、あまり意味がありません」と谷内氏は語る。

機械的に計測できる業務の負担具合を数値化することは、判断の大きな材料となる。しかし数値だけを頼りに上から順番にRPA化すればいいのかといえば、そういうわけではない。

「分析結果を材料に改めてヒアリングするべきでしょう。D-Analyzerでは、人のストレスは見えません。たとえば、請求業務や販売情報の登録業務というのは比較的RPA化されやすいですが、元の担当者に聞くと間違えられないプレッシャーが辛かった、1日中同じことを繰り返すのが辛かったというような声が出てきます。RPA化することでストレスが軽減できれば、退職者も減らせるかもしれません。RPA化するのかしないのか、やることでどういう影響があるのかを最終判断するのは人です」と谷内氏。

数値を根拠にすればヒアリングも具体的かつ詳細なものになり、効率的に行えるだろう。

使い続けるためのメンテナンス性を考えた導入

RPA化の価値がありそうな業務を見つけた後は、具体的な業務プロセスを検証し、ロボットを開発することになる。この時にも注意が必要だという。

「例外があるなど、人の判断が必要な部分がある業務は注意が必要です。人の判断が多いものはそもそもRPAに向いておらず、チャレンジしたがうまく業務プロセスが作れなかったという例があります。また、人の判断が数カ所挟まるようなタイプの業務は、そのタイミングで一度処理を切るのがいいでしょう。人が見て、次へ移行させるわけです」（大久保氏）

また、業務プロセス自体は構築できるとしても、それが長くなるものも単純にまとめて1つの業務として見るのではなく、適宜区切って複数のロボットとした上で処理を引き継いで行く形にするのがオススメだという。

「非常に長い処理、複雑な動きをしている処理のものは、後から修正するのも大変です。誰かが頑張ってうまく動くものが作れたとしても、その人がいなくなると誰もメンテナンスできないということになりかねません」と大久保氏はRPA化することだけでなく、使い続けて行くことを考えた上での導入が必要だと指摘した。

目的と手段の取り違えが危険！

RPA導入における課題や失敗例を聞く中で、繰り返し指摘されたのは「RPAを導入する」ことを目的としてしまっている危険さだ。

生産性向上や業務改善、働き方改革といったキーワードはどの企業にとっても無視できないものではあるだろう。しかし、そのために何が必要なのかは企業ごとに違うはずだ。

「企業にはRPA以外の解決法が向いている課題もたくさんあります。目的ではなく手段であることを忘れないで欲しいですね。考えるべきは、RPAで何が解決できるのかということです」（大久保氏）

「D-Analyzer」の分析結果はRPA導入に役立つものだが、中には負担は大きいがRPAには向かない業務なども出てくるだろう。その時は、人員増強やシステムの改変といった別の手段を模索すればいい。何を解決したいのか、どう改善が見込めるのかをしっかり分析した上で、魔法のツールではないRPAを、必要な部分にうまく適用するのが導入成功への道筋になりそうだ。