##はじめに
みなさんはRPA使ってますか？
労働力不足にも関わらず、残業時間の削減が求められる日本において、**「プログラミング経験不要で、誰でも簡単に業務が自動化できるツール！」**という触れ込みで、RPAは働き方改革の特効薬として注目され、急速に広まりました。
導入によって最初はどの企業でも一定の効果が出るため、「よし！この調子でどんどん開発しよう！」となるのですが、しばらくすると想定以上にロボットがよくこけるため、「どんどん開発するつもりだったのに、運用と保守に時間が取られてしまい、なかなか開発が進められない・・」という状況に陥ります。既に大規模展開を実施されている方は、当初の開発計画と大きく乖離した苦い経験をされている方も多いのではないでしょうか。
本記事は「RPAはなぜよくこけるのか」という事を正しく理解するために、簡潔に2枚の絵を使って書いて行きたいと思います。
本記事の対象読者は以下です。
- RPAの導入を検討している方
- RPAを導入したものの、想定以上によくこけるという事象を経験した方
- これからRPAの大規模展開を予定している方
##RPAの開発工数に対する運用・保守工数の割合
RPAは一般的なシステム開発に比べて開発工数が小さく、導入自体は容易です。しかし、運用・保守に必要な工数の割合は開発工数の約半分と言われており、システム開発における割合を大きく上回ります。
つまり、RPAは一般的なシステムに比べてよくこけるという事です。
ではなぜRPAは一般的なシステムに比べてよくこけるのでしょうか？
周囲の方々に聞いてみると、「開発が難しいから？」「開発者の単価が低いから？」「新しいツールでまだ安定していないから？」といった声をよく聞きますが、いずれも本当の原因ではありません。
これは仮想労働者と言われるRPAの立場を考えると見えてきます。
##RPAがよくこける最もな理由
仮想労働者と言われるRPAは、ユーザーによって使われるシステムとは異なり、システムを使う立場にあるため、周辺環境のあらゆる変化の影響を受けます。つまり、RPAはいわば弱い立場にあり、RPAの実行エラー率は、RPA自体の品質だけでは決まらず周辺環境の安定性に大きく依存します。そのため、RPAの実行エラー率は一般的なシステムに比べ必然的に高くなります。
RPAは指示された通り忠実に動くので、RPAの実行エラーの要因のほとんどはRPA自体のエラーではなく、周辺環境の変化によるものです。RPAがよくこけるからといって、やみくもに開発者も攻めても真の問題解決には繋がらない場合が多く、エラーの要因を分析し、要因に合わせた適切な対策を打っていく必要があります。
将来のあらゆる変化を想定した完璧に動くロボットを作る事は事実上不可能なため、RPAの大規模展開を進める場合は、ある程度のエラー発生は前提として、運用・保守の体制作りを進めて行く必要があります。
##まとめ
いかがでしたでしょうか。
RPA自体は素晴らしいツールで、正しく使えば大きな効果を生むのですが、RPAを使いこなしていくためには、仮想労働者と言われるRPAの特性を理解しておく必要があります。RPAはよくこけるものの、その多くはRPAが原因ではない場合が多いという事を正しく理解し、今後の取り組みに活かして頂ければ幸いです。
<参考>
Qiita記事
・RPAは誰でも簡単に作れるという罠
・VBAが組める人ならRPAは簡単に作れるという罠
・UiPathのコーディングチェックツールを作ってみた
・寿司打を自動化してみた【RPA×OCR】
・RPAのオススメ書籍
・RPAの開発に向いている人、向いていない人
・RPAの推進に必須なRPAOpsという考え方
・【AI】Deep Metric Learning
・【AI】Deep Learning for Image Denoising
・Deep Convolutional Autoencoderベースの教師なし異常箇所検知
デモ
・UiPathCodingChecker：UiPathのxamlファイルからコードを分析
・AI Demos：DeepLearningによる手書き文字認識・異常検知・画像のデノイズ
・寿司打自動化(YouTube)：タイピングゲーム寿司打のRPA×OCRでの自動化