RPA開発に失敗する典型的な5つのパターン

自動化はやめてください！　世間一般に言われているように「RPAは非IT部門の人でも簡単にロボットを作れて、人の代わりに24時間365日働かせることができる」と考えていると必ず失敗します！

本記事ではRPAの開発に失敗するパターンを5つに分けて解説します。

開発することができない
開発効率が悪すぎる
現場が混乱する
統制がとれない
費用対効果が出ない

失敗するパターンとともに、「どうすればいいのか」も書いていますので、「RPA導入に失敗したことがある」もしくは「これからRPAを導入するけど失敗したくない」という方は是非お読みください。それでは、どうぞ！

RPA開発に失敗する典型的な5つのパターン

[1] 開発することができない

IT 会社の協力のもとPOC（Proof of Concept：概念実証）を行い、3つの業務の自動化に成功した。成功を受けてRPAツールを導入したが、半年経った今もシナリオが増えていない。

RPAは「ロボット」と呼ばれますが、最初から動くわけではなく、業務に合わせたシナリオを組む必要があります。RPAベンダーは「ノンプログラミングでシナリオ設定ができるため、プログラマーでない現場の実務者でも自動化できる」と説明するかもしれませんが、実際にはそう簡単にはいきません。

本当にRPAが「ロボット」であり、導入するとすぐに仕事を覚えて働き始める、と考えている方は少ないとは思いますが、中には「自動車を買う感覚」で購入し、すぐに使えると勘違いする人もいるので、そうなると悲劇です…。

非エンジニアの実務者にRPAツールを渡しても1つも作れないこともあります。そのような場合、ヒアリングすると以下のような意見が出てきます。

何を作ったらいいのかわからない
何から始めたらいいのかわからない
時間がない

業務を行っている実務者の方々は皆忙しく、自分の業務以外のことを１から勉強して身に付ける時間をとるのは難しい。また、プログラミング未経験者にとって、開発画面を触ることは非常に高いハードルです。いくら簡単に操作できるように工夫してあるRPAツールであっても、です。このため、RPAツールが導入されたものの、まったく動かさないまま放置されるケースも少なくありません。

情報システム部門がRPA導入に主体的に関わっていたとしても、業務に詳しくないため開発が進まないこともあります。情報システム部門が現場の責任者を集めて「RPA化できる案件を提案してください」と呼び掛けても、結局は、「何を自動化したらいいのか分からない」ということで、ほとんど集まらないのではないでしょうか。

なぜ現場からRPA案件が集まらないのか？　では、どこに注目して案件を掘り起こせばいいのか？については、こちらの記事も参考ください。＞なぜ現場からRPA案件は集まらないのか？

[2] 開発効率が悪すぎる

自動化したい業務はわかっている。RPAツールの使い方も学習した。しかし、シナリオの開発に1 ヶ月以上かかってしまった。2 本目のシナリオも1本目と似ていたが、また1から作り始めないといけないので、同じくらい時間がかかった。RPAツールを使って自動化するのに工数がかかりすぎるので、手作業で業務を行ったほうが早い。

シナリオを効率的に作れないので、1件1件の自動化に莫大な工数がかかり、「結局手作業で業務を行った方が早い」という結論に達して、あきらめてしまうパターンの失敗です。

1) 技術力が足りない

開発技術が足りず、開発に時間がかかりすぎるため導入を断念するパターンがあります。自動化したい内容は分かっていても、それを実現するためのスキルが足りないので時間がかかってしまうのです。最初の段階で書籍で勉強するか研修を受けるなどのトレーニングが重要ですね。

開発しながら、疑問点を聞けるエンジニアを見つけることも解決策の一つです。マイクロソフトのデスクトップ型RPA「Power Automate for desktop」の場合、当サイトでサポートしています。

また、開発速度を速めるには複数人でチームを作って開発することになりますが、チームでスムーズに開発を進めるには以下のような知識が必要になってきますので、身に付けましょう。

共通処理のライブラリ化
プログラムソース管理
設計書の作成

2) 業務整理できていない

RPA初心者の多くは、作業手順をそのままレコーディングする機能が付随しているRPAツールを手にすると、業務整理せずに自動化できると考えがちです。

「ああでもない、こうでもない」と試行錯誤を繰り返して、結果的にまったく整理されていない「スパゲッティシナリオ（※1）」を生み出してしまいます。

そして、過去に開発したシナリオと同じような動作を行うシナリオを開発することになった場合でも、スパゲッティシナリオになってしまったシナリオは再利用しづらいものです。

複雑に絡んだシナリオを解きほぐして使える部分だけを探すよりも、新しくシナリオを開発した方が早い、ということになります。こうして、毎回似たようなシナリオの開発に膨大な工数をかけてしまうパターンにはまります。

「業務整理」と「シナリオの設計」が必要です。

※1）スパゲッティーシナリオ：皿に盛りつけたときのスパゲッティのように、複雑に入り組んで読みにくいソースコードのことを、ソフトウェア開発では「スパゲッティコード」と呼びます。これにならって、複雑に入り組んで読みにくいシナリオのことを「スパゲッティシナリオ」と呼ぶことにします。

[3] 現場が混乱する

RPAを導入したため、かえって現場が混乱するパターンです。

1) RPAがすぐに止まる

基幹システムからデータを抽出し、各種帳票を作成するシナリオが10 本ある。ある日、いつものようにシナリオを実行すると、10 本中7 本が止まってしまい大混乱に陥った。RPA 推進部署が緊急で対応したが、営業部の業務が大幅に遅れてしまった。

シナリオがたびたび止まるので「使えない」という結論に達して、RPA開発をやめてしまうパターンの失敗です。シナリオが止まってしまう理由は、大きく分けると（1）例外と（2）変化です。

「例外」とは通常実行時とは異なる事象が発生することです。例えば、「シナリオが正常に動作するために必要なファイルを誰かが削除してしまった」、「操作する対象としているアプリケーションがメンテンナンス中で正常起動しなかった」、などのケースです。

「変化」には、例えば「OS のアップデートにより、RPAがアプリケーションのボタンを突然認識できなくなった。認識方法を変更しないといけない」、「組織が変更になったので、業務方法が変わることになり、シナリオを急いで変更する必要が出てきた」、といったケースがあります。

「例外」と「変化」は業務を自動化するソフトウェアであるRPAには、常について回る問題です。「止まらないRPA」を実現するには、エラー処理を正しく行う知識が必要です。

また、RPAが止まる前提で設計することも重要です。そのためには以下のような知識が必要です。

止まった場合に正しく終了処理する設計
エラー箇所を特定しやすいログ管理
万一に備えたバックアップ
リカバリーしやすいRPAフロー構成
それらを運用できる人材

2) エラーが起きてもRPAが止まらない

売上日報を作り、自動的に配信するシナリオがある。この売上日報は社長にも配信されている大事な帳票だ。いつも通り、問題なく配信は完了したのだが、営業部から「売上がおかしい！」とクレームが入った。

「シナリオがすぐに止まる」で述べたように、シナリオは外部の変化で止まってしまうことがあります。しかし、「データ内の数値がおかしい」などの論理エラー（※2）が発生しても自動的には止まりません。「止まってほしいときに、止まらない」という皮肉な失敗です。

例えば、「基幹システムから、CSVデータをダウンロードして集計しているシナリオがあるが、ある日CSVデータの列の並び順が変更されて、参照している列がずれてしまっていた」といったケースがあります。

人間が集計を行っている場合は、「なんとなく集計値の値がおかしい」と気が付くかもしれませんが、RPAは当然気が付きません。

データ集計程度ならば、大きな問題とはなりませんが、会社の基幹に関わる数値の場合は大変です。特に財務諸表に関わるデータで、この問題が起きるリスクには注意しなければなりません。

※2）論理エラー：開発者の意図とは異なる結果を出力するエラーのことです。「シナリオがすぐに止まる」で解説したように、予期しない例外によって止まってしまうケースは「物理エラー」と呼ばれます。論理エラーは物理エラーとは違い、実際にシナリオが止まってしまうことがないため、発見しにくい厄介なエラーです。

[4] 統制がとれない

RPAの問題の多くは開発時ではなく、その後の運用で発生します。運用がうまくいかずにRPA開発もやめてしまうことがあるので、このパターンも「RPA開発の失敗」に含めて解説します。

野良ロボットのリスク
メンテナンスができない
RPAの引継ぎができない

の3つに分けて解説します。

1) 野良ロボットのリスク

野良ロボットというワードを聞いたことがある人も多いでしょう。どのPC 端末にRPAツールがインストールされているか、どんなシナリオが実行されているのか、会社組織として管理できていないという問題です。

どのような業務が野良ロボットによって行われているのか、ルールに従っているのかが管理されていない場合、ブラックボックス化してしまいます。

そのため、不正のリスクもあります。例えば、以下のような不正が考えられます。

大切なデータを扱うシステムのログインIDとパスワードがシナリオに直接書き込まれているため、システムへのログイン権限がない人が利用している。
セキュリティを考えて、少しずつしかデータを抽出できないようにしているシステムがあるが、RPAを連続稼働させてデータを抽出させている。

このように、人間が作業しているときには、起こらなかったリスクが起こり得るようになります。

2) メンテナンスできない

シナリオを運用している担当者が長期で休んでいるので、代わりにシナリオを動かしたが、エラーで止まってしまった。シナリオを読んでみたが、膨大な量のアクションが並んでいる。これを調査していたら、自分の業務も進まない。

「シナリオがすぐに止まる」で述べたように、「例外」と「変化」はRPAにつきものなので、シナリオのメンテナンスは常に発生します。

自分で開発したシナリオであっても、すでに動いているシナリオをメンテナンスするのは難しいものです。シナリオの内容をすぐには思い出せないことも多々あります。

他人の開発したシナリオはさらにメンテナンスが大変です。特に、すでに開発者が退職している場合などは、業務の理解とシナリオの解読から始めなければなりません。

「スパゲッティシナリオ」であった場合、解読は非常に困難です。

3) シナリオの引継ぎができない

経営者がRPAツールを導入する大きな目的は「標準化」です。属人化した業務を担当者から引きはがし、人材の流動性を高めることが求められます。業務を自動化することで、属人化はなくなるはずです。

しかし、実際はシナリオが担当者と一体になってしまい、属人化を強化する結果になることもあります。

こうなると、部署異動時にシナリオを引き継ぐことが困難になります。

また、引き継ぎやすいシナリオを開発できたとしても、これまでの人と人の引継ぎに加え、シナリオも引き継がないといけません。

引き継ぐ人のRPA スキルが低かった場合、シナリオを引き継ぐことができない可能性があります。

[5] 費用対効果が出ない

RPAは他のITツールに比べて安価で始められる点がメリットとされています。事実、数万円/月から始めることができるツールが多いです。しかし、RPAの台数が増えると費用が増え、それに見合った効果が得られているか不明になることがあります。

1) ２４時間３６５日働かせることはできない

ロボットが２４時間３６５日働くので、人件費に比べとても安価だという業者からの売り込みがあると思います。「出社前に終わらせておいて欲しい業務」「休日にも処理して欲しい業務」などをロボットにさせたいですよね。でも、うまくできたかは確認しなくてはなりません。

パソコンにインストール形のRPAはパソコン画面を人と同じように操作するという特徴上、「画面の配置が変わった（得にWEBサイトなど）」「ウィンドウズアップデート等で予期しないポップアップが出ている」「前のRPAの処理が失敗したまま画面に残っている」などの場合に対応しきれず失敗することがあります。しっかりと改修を続けてゆくことで、よくなってゆきますが、１００%うまくいく保証はありません。

２４時間３６５日働かせたい場合は、止まらないシステムと同様に中央管理できるようジョブ管理（外部からロボを起動でき、仕事が成功したか失敗したか、思いがけないエラーが起こっていないかを監視でき、自動通知する）を行い、運用監視体制を整える必要があります。

2) 意外に費用がかかる

１台のRPAのライセンス料が１台１０万円/月額だと仮定しましょう。人件費に比べて安いと思いますよね。しかし、パソコンにインストールする形態のRPAは、１つの業務が動いている間は他の作業は当然できません。ユーザーがロボットを動かすタイミングが不定期であることがほとんどですので、ぎゅうぎゅうにロボットを動かし続けていては上手くいきません。そうなると１台のロボットにさせる業務は多くても５つくらいになってきます。加えて、部署やオフィスの場所が違うと物理的にロボットの場所を分けないといけません。また、社内で開発する場合、業務実行用と別に開発用のロボットも必要です。

バックオフィスに１００人程度の会社であれば、業務数は１０００を軽く超えます。少なく見積もって５０業務をRPAで自動化するとすれば、１０台程度のロボットが必要です。たった０．５％の業務を自動化する為に月額１００万円（年間１２００万円）ですが、安いと言えるでしょうか？

本格的にRPAを運用し始めると、その威力から自動化したい案件があふれ出てきます。台数が増えるほど、当初の想定以上に費用がかかることに驚くことになります。RPA実行ライセンスのみだと、1台当たりの金額が抑えられるライセンス形態が多いので、うまく組み合わせてコストを抑えるなどの対策が必要です。

サーバー型のRPAソリューションの場合、RPAの実行台数に依存しないライセンス形態であることが多いので、RPA実行台数が増えてきたら、サーバー型RPAに移行するのも解決策の一つです。ただし、RPAの移行作業は簡単ではありません。大きな工数がかかるので、RPA導入段階で計画性を持っておくことが大事です。

3) 無駄なサブスクリプション費用が発生し続ける

RPA管理部署とRPAツールの利用部署が違う場合は、RPAツールがどれだけ利用されているかまで管理していないでしょう。

机の中に放置されているノートパソコン内に何カ月も使っていないRPAツールがインストールされていたとしてもおかしくはありません。サブスクリプション費用は使っていなくても発生し続けます（※3）。

※3）利用時間に対して費用が発生する契約であれば問題ありませんが、多くのRPAツールはインストールしたパソコンの台数に対して費用が発生します。

まとめ：結局システム開発の知識・技術が必要

本記事で分類したRPA開発に失敗するパターンは次の5つです。

1.開発することができない
2.開発効率が悪すぎる
3.現場が混乱する
4.統制がとれない
5.費用対効果が出ない

これまでにRPA開発に失敗した方はどれかのパターンにはまったのではないでしょうか。

RPAは確かにプログラミング言語を必要とするシステム開発よりも簡単です。

しかし、非エンジニアの方がプログラミングやソフトウェア開発の知識を全く持たずに成功できるほど簡単なものではありません。

少し込み入った処理をさせるためには、簡単な画面操作では対応できないことがたくさん発生します。例えば、基幹システムから売上明細をダウンロードする場合、当月の１日から前日までのデータだけにしたいなどの要望があると思います。そうすると日付の計算を何らかの方法で行い画面に入力することになりますが、日付計算するプログラム（通常、JavaScriptなどのスクリプト言語がRPAツールによりサポートされていることが多い）を記述しなければなりません。そうでなくても、条件分岐や繰返し処理などプログラムの基礎が理解できていないとシナリオを書きすすめることは困難でしょう。

また、「今行っている業務をそのままロボットのさせればよい」という売り込みもあると思いますが、システムのプロではない現場の方が作った現在の業務フローをそのままロボットに置き換えると大変な工数がかかる場合が多々あります。Excelの作業において本来Excelの機能や関数を使えばできることを手作業で苦労して行っていること等はたくさんあるからです。もしこのまま現場の方にロボットに置き換えるように指導すると大変なことになります。ロボットに置き換える時に適切な手順に組み替える必要があり、ここでもプログラムやITのスキルが必要となってきます。