ツール選定の失敗、運用の挫折 RPAの落とし穴を避ける方法

RPAを導入し、全社展開に取り組むものの思ったような効果を得られない。これからRPAの全社展開を目指す企業が、必ず押さえて欲しい項目を紹介する。

[土肥正弘，ドキュメント工房]

　メガバンクの取り組みを皮切りに、RPAのブームが巻き起こった2017年には業種や規模を問わず多くの企業がRPAの導入に着手し、情報収集やPoCを行った。そうした企業は現在、全社展開に向けて取り組みを進めているが、中には思ったような成果を出せない企業もあるようだ。今回は企業のRPA導入を指揮するベンダーやコンサルティング会社に、RPAの落とし穴とその回避方法を聞いた。

RPAの認識不足は失望を招く

　導入企業の中で、RPAへの失望感があるとすれば、その原因の1つはRPAへの認識がずれていることにあるという。

　RPAは「デジタルレイバー」と呼ばれ、人間がPC上で行う作業を代替する仮想従業員に例えられる。その本質は従来の業務システムの導入とは異なる。

　周知の通り業務システムは、カスタマイズやスクラッチ開発により数カ月から1年以上の期間をかけて作り込む。構築時点で想定された目的・用途で常に安定して動くというメリットがある一方で、変化するビジネス事情に追随し、エンドユーザーのさまざまな個別ニーズに対応するのは難しい。

　そこで、費用対効果などの問題から業務システムではカバーできない部分を、担当者自身がExcelなどを駆使して埋める必要がある。その作業に含まれる単調なコピー＆ペーストや集計などの定型作業をロボットに任せ、人間はより付加価値の高い仕事をしようというのがRPA本来のコンセプトだ。

　図1はシステム開発とRPAの違いを簡単に示すイメージ図だ。RPAは、システム開発（SI）とはスコープや目的が違う。現時点ではあくまで業務プロセスを局所的に改善するツールであり、現場の業務効率化やミス発生防止、リソース不足解消を目的とするものであり、短いサイクルでトライ＆エラーを回して改善できることがメリットだ。このコンセプトをはき違えると、必要以上にプロジェクトを長期化させたり、効果の出ない業務を選定したりといった失敗を招く。

図1 システム開発（SI）とRPAの違い（出典：ビッグツリー テクノロジー＆コンサルティング）

　以降では、具体的にRPA導入で失敗しやすいポイントを紹介しよう。

業務選定の失敗

　RPA導入でまず失敗しやすい点として挙げられるのが、業務選定だ。RPAによる自動化に適さない業務を選定すると、思ったような費用対効果が得られないという失敗につながる。業務を選ぶ際には、次のポイントを押さえておくべきだ。

（1）現場の人の仕事がラクになる業務を選ぶ

（2）業務プロセスの全体ではなく一部の人手作業を自動化するものであることを理解する

（3）例外の発生しにくい作業に適用する

　まず（1）に関して。投資対効果を上げるには、多くの人が長時間行っているボリュームの大きい業務を選ぶだけではなく、継続的にRPAによる自動化をスケールさせ、小さくてもさまざまな業務の人手作業をつぶすことも肝心だ。

　そのために、まずは成功例を作り、従業員の口コミによってRPAが他部署に展開するシナリオがベスト。社員のモチベーションを上げ、RPAが無理なく展開するように、人手作業が業務全体のボトルネックとなっている部分を探し出し「現場の人の仕事がラクになる」業務を選びたい。参考として、社員に簡単なアンケートを募るケースもある。

　また一部の人手作業に適用するという（2）のポイントも注意点としてよく語られる。業務プロセス全体をカバーするロボット化を企図すると、動作を定義するシナリオが複雑になり、一部を直すと全体のテストが必要になり、工数増加のもとになる。結果、作成や運用の途中で挫折する可能性が高い。自動化の際には、業務プロセスの中でもRPAを作成、管理しやすい一部の作業を選ぶべきだ。

　例外が発生しにくい業務を選ぶという（3）のポイントも重要。RPAは定義されたこと以外はできず、フローの途中で例外があった場合には、エラーを起こして止まるか、間違いを繰り返し続ける。例外の発生しにくい作業のみをロボットに任せ、それ以外は無理に自動化せず人に任せ続けるという判断が必要だ。

RPAツール選定の間違い

　RPA製品に優劣があるわけではないが、自社に合わない製品を選んでしまうと、「ロボットが自社のシステムを動かせない」「できると思っていたことができない」「求めるROIに届かない」などさまざまな問題が起こり、最悪の場合には新たにツールを選定し直すという事態が発生する。以下では、ツールを選ぶ際に、軸となるポイントを挙げた。

既存業務システムなど、システムとの技術的適合性を考慮する

　まずは、ロボットが操作する自社の業務システムは何かを明らかにして、そのシステムに対応可能なツールを選ぶ必要がある。Webシステム、Windowsアプリケーション、メインフレーム、AS/400、シンクライアントシステムなど、既存システムへの対応度合いを確認しておきたい。これによって、「ツールとシステムの相性が悪く、RPAが画面上の特定のボタンが押せなかった」といった事件も防げる。

図2 技術的適合性のチェック事項（出典：ビッグツリー テクノロジー＆コンサルティング）

　ちなみに、自社の業務システムとの相性は、ツールの「認識方法」に依存する。RPAは業務の流れを「シナリオ」として覚え、これに沿って作業を実行する。そのシナリオを作成する際には、PCの画面上で操作する対象をロボットに認識させ、対象に対してどのようなアクションを行うのかを記録する。例えば、以下はRPAツール「BizRobo!」のシナリオ作成画面だが、「検索ボタン」といった操作対象と、「クリックする」などのアクションを指示して、フロー図を作成する。

図3 「BizRobo!」のシナリオの作成画面

　ロボットが操作の対象を認識する方式は、いくつか種類があり、例えばHTMLタグといった画面の構造情報を取得する方法や、ExcelやCSVファイルなどを専用に読み込むための方法、各アプリケーションのマークを画像で認識する方法、画面上の座標によって位置を認識する方法などがある。ツールによって、対応する方式やその精度に差があるため、必然的に認識できる対象やスピ―ドにも違いが出る。

　例えば、「htmlで書かれた画面は認識できるが、JavaScriptは難しい」といったツールもある。また、画像認識の方法を用意するツールも多いが、この方式はあらゆるアプリケーションを読み込める一方で、画面の解像度が変わると対象を認識しなかったり、そもそも他の方式に比べて動作に時間がかかったりといった問題がある。そのツールがどのくらいの割合で画像認識を必要とするのか、というポイントはシステムとの適合性と併せてチェックしたい。

プロジェクトの進め方に合ったツール形態やライセンス体系を選ぶ

　自社のRPA導入プロジェクトの方針に合わせて、サーバ型か、デスクトップ型かのツール形態を考慮することも必要だ。部門ごとにスモールスタートで導入するのか、導入当初から全社展開を行うのか――それぞれの進め方に適した形態を選び、ライセンス体系、価格を決めなければならない。

　現在、RPAツールは以下の2つの形態に分けられる。

• デスクトップ型：PCにインストールしてPC1台で動かせる。シナリオもPC内にある。なお、デスクトップ型に分類される製品でもサーバによるロボットの一元管理が可能なものもある（UiPath、WinActorなど）。
• サーバ型：サーバにインストールし、サーバにひも付くPCでシナリオを実行する。実行管理とシナリオはサーバ側がもつ（BizRobo!、BluePrismなど）。

　部門ごとにスモールスタートで導入する場合には、デスクトップ型でPoCなどを行い、全社展開に当たってサーバ型を利用する手法が適切だ。プロジェクトによっては、導入当初に数部門でデスクトップ型を入れ、スケールさせる段階で情シスがサーバ型を導入し、すみ分けて運用するというパターンもある。また最初からトップダウンで大規模展開を図るなら、RPAを一元的に管理できるサーバ型を選ぶべきだ。

　利用規模を明確にしたら、ライセンス体系も考慮したい。基本的にデスクトップ型は、RPAをインストールするクライアント単位でライセンスが発行されるが、サーバ型で利用するツールはライセンス体系も多用だ。例えば、小ロットのライセンス購入が可能な場合もあれば、ライセンスの最小単位が比較的大きいものもある（図4）。スモールスタートを望む場合は前者を選べばよいし、全社業務を対象とする中規模以上のプロジェクトでは後者が向く。また、ロボット台数やユーザー数ではなく処理量などで価格が決まる製品もある。ライセンス体系についてはベンダーが個別に情報を提供しているので、各社に問い合わせるのがよい。

図4 ライセンス体系の違いの一例（出典：ビッグツリー テクノロジー＆コンサルティング）

内製化のための必要条件は何か考える

　前述したように、RPA導入の効果を上げるためには、さまざまな業務に横展開させることが重要だ。コストやリードタイムなどを考えれば、ロボットの開発やメンテナンスなどの運用を内製化することが成功への鍵となる。しかし、RPAツールによってはプログラミングの知識やスクリプトを操る勘所が必要だ。ITスキルの高い人材をどのフェーズからどのくらい調達できるかを考えて、自社で扱いきれるツールを選ばなければならない。

　RPA導入を指揮するコンサルティング会社では、次のようなポイントへの注意が必要だと説く。

（1）開発画面の扱いやすさ（日本語対応のレベルなど）

（2）プログラミング言語の知識が必要か

（3）開発環境・実行環境の構築が容易か

（4）自動レコーディング機能はあるか

（5）業務フローと操作オブジェクトを分けて管理できるか

　例えば、ロボットを開発したり実行したりする環境を構築するフェーズでITスキルの高い人材を調達できないのであれば（3）のポイントを考慮して、開発環境、実行環境の構築の容易なツールを持つ方がよい。ロボットが動くためのシナリオを作成する開発フェーズにおいても十分なスキル人材が投入できず、業務部門が主体で動くならば（1）や（2）、（4）のポイントを考慮して開発画面が分かりやすく日本語に対応しており、プログラミングの知識が必要なく、またPC上で人間が行った操作をそのまま自動化のシナリオとして登録できる自動レコーディング機能が必要だろう。

　また、運用フェーズでは、シナリオのメンテナンスを行うことが重要だ。業務システムの画面などが変わったり、業務のフローが変わったりした際には、シナリオを修正しなければならない。そこで、業務システムなどの操作対象と、その対象に対してどのようなアクションをとるかという業務フローを分けて作成、管理できる機能を持つツールが便利だ。既出の自動レコーディング機能よりは難しい方法になるが、開発フェーズや運用フェーズでエンジニアを調達できるならば、（5）のポイントを考慮してツールを選ぶ方がよい。

　いずれも会社の文化やITリテラシーに合わせて、RPAのどういったポイントを重視するのかを考えてツールを選択する必要がある。

メンテナンス不足でロボットが停止

　RPAは、継続して教育する必要がある新入社員に例えられる。前述したように、シナリオに組み込まれていない例外が発生すればエラーを起こし、正常には動かない。ロボットは1回作って終わりではなく、業務フローやシステムの仕様などが変わってもロボットが正常に稼働できるよう、継続的なメンテナンスが求められる。

　最近では、ロボットの稼働状況を診断し、メンテナンスを引き受けるサービスも存在するが、継続的に外注費が発生することを考えれば、メンテナンスも内製化できた方がよい。比較的規模の大きい企業であれば、専門部隊を設置し、RPAの運用を担いつつ、社内で継続的にナレッジを蓄積できる体制を組むことで成功しているケースが多い。

スケールに伴う管理の苦労

　RPAの数が増えていくと、ロボットをいかに管理するかという課題も生まれる。スケール後にロボットの運用が統制できず、動かなくなったロボットがそのまま放置されたり、誰が何のために作ったのか分からない「野良ロボット」が生まれたりするといった問題は、しばしば取沙汰される。RPAを全社展開するに当たっては、「ロボットの管理はどのように行うのか」「誰がロボットを作成するのか」「作成ルールはどうするのか」「ロボットがデータにアクセスする際のガバナンスはどうするのか」といった問題をつぶしていかなければならない。

　場合によっては、全社を横串にする専門組織などが中心となって、社内の運用ルールを適切に策定、順守を促すことが重要だ。どのようにルールを策定し、運用するかは企業によって異なるが、成功企業の事例は参考になるだろう。後編では、大規模RPA導入で成果を上げている電通の事例を紹介するので、チェックしてほしい。

コラム：中小企業を救うSaaS型のRPAサービス

　予算や人的リソースが十分ではない中堅中小企業では、開発、運用を内製化する負担も大きい。そうした課題を受けて、RPAをSaaS型で提供し、より利用しやすい金額に設定したサービスがある。SaaS型であるため、インフラの管理は事業者に任せることができ、運用の負担も減る。

　また、「Excelの入出力」や「Zip圧縮解凍」などの汎用性が高いロボットや、特定のクラウドサービスで使用できるロボットをテンプレート化してマーケットプレースで提供するサービスもあり、開発の工数を削減できる。中堅中小企業がRPAを内製化するに当たって、心強いサービスだ。