RPA導入で処理時間が人力の2倍になった……、失敗しないためのRPA開発虎の巻

RPAの活用現場では、想定以上にコストがかかる、ロボットが止まる、他人が作成したロボットをメンテナンスできないといった問題が起きている。課題を解決するために、今からマネできるポイントを紹介しよう。

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

　働き方改革の決定として注目を集めるRPA（Robotic Process Automation）。最近では、PoC（Proof of Concept、概念実証）を終えて本格導入のフェーズに入る企業も増えてきたが、RPAの知見を十分に持たないために、「思ったようにいかない」という話も聞く。

　RPAを活用する現場では、「想定以上にコストがかかる」「ロボットが止まる」「他人が作成したロボットをメンテナンスできない」といった問題が起きているのだ。時には、人手で30分かかる業務をRPA化したところ、作業に1時間を要するようになり、逆効果になってしまった事例もあるという。

　こうした課題を解決するにはどうしたらよいのか、SHIFTでサービスプロモーション部の菅 仁氏が語った。SHIFTは、年間で4000件にものぼる開発プロジェクトのソフトウェア品質保証およびテストを手掛ける企業だ。その知見をRPAにも適用できるとして、2018年1月にRPAテクノロジーズとの提携を発表し、5月にはRPA診断改修サービス「ROBOPIT！」をスタートさせた。「止まらないRPA」を目指すために必要なノウハウとは何か。

本稿は、2018年6月29日に開催されたセミナー「RPAをスケールさせるための“品質保証”とは？〜RPAロボットの品質保証の在り方、お伝えします〜」（SHIFT主催）の講演内容を基に構成した。

初期投資の回収に200カ月？　RPA推進にブレーキをかける要因

　「RPA推進のネックになるのは、RPAの適用範囲を拡大（スケール）した後に、思ったよりもコストがかさみ、効果が小さくなることです」と菅氏は話す。

　要因は、運用や保守の工数だ。ロボットは、業務フローの変更や連携先システムの変更といったことの影響を受けやすく、止まったり、エラーを起こしたり、間違った結果を返したりするため、常にメンテナンスや改修が必要だ。実際にRPAの処理の結果にミスがあり「現場が顧客に提示する金額を誤った」ケースもあり、場合によっては致命的な失敗につながりかねない。

　特に、現場が中心となってRPAの開発などを担う「現場主導型」の企業の場合、RPAの保守や運用までを考慮して開発する視点に欠ける傾向があり、頻繁にロボットが止まる現象が起きるという。保守を考慮せずに作られたロボットは、改修をしようにも、開発担当者以外の人がさわれない「ブラックボックス」と化している場合も多く、継続的な利用が難しい。

　今企業では、上記のような事態が多発していると菅氏は話す。しかし、RPAに特化したエンジニアがユーザー企業内にいるケースは少なく、開発担当者は新しいロボット開発に追われ、保守に当てられる時間も少ない。結局、工数が上昇するにつれて、保守や運用を外注せざるを得ず、全体のコストも跳ね上がるという。

　一方、こうした事態を懸念して、トップダウンで大規模導入を決め、具体的な開発を外部ベンダーに委託するパターンのアプローチを採用する企業も多い。しかしこの場合は初期コストが膨大になる危険性をはらむと菅氏は警告する。

　「導入時に投資をして慎重にルール作りをしながらプロジェクトを遂行するため、後戻りが必要になっても簡単にはいかない『重厚長大』なプロジェクトになる傾向にあります」（菅氏）

　菅氏の経験では、3年間で1000人分の労働時間削減を目指したものの、実際には300人分の削減にしかならないことが分かった事例や、通常のシステム開発では開発者単価が約120万円のところ、RPA開発で150万円もの必要が必要になったという事例、仕様書作成工数に開発の70％を費やした事例、人手で30分かかる業務をRPA化したところ、作業に1時間を要するようになり、逆効果になってしまった事例などがあるという。RPA導入を通常のシステム開発と同等に考えた結果、初期コストが上昇するという「失敗事例」は枚挙にいとまがなく、当初期費用を回収するに当たって、当初の計算では4カ月と予想していたものが、最終的に200カ月と診断されたケースもあった。

図1　RPA導入の2つのパターンと拡大期の問題点、コスト傾向

　こうした先人の苦い経験を踏まえれば、RPAはまず導入して使ってみることが重要だと菅氏は話す。しかし同時に、本格的にRPAの適用範囲を広げる際には、「RPAの保守や運用に気を配り、ロボットの品質を高めるという視点が必要です。運用コストの上昇も抑えられます」と説明した。

他人がメンテナンスできる、ブラックボックス化しないロボットの作り方

　ロボットの品質を上げるポイントは「保守性」だ。ロボットは開発の時点から保守を考えて作成しなければならない。同氏は、入門レベルの開発担当者が作成したロボットと、熟練の開発担当者が作成したロボットを比較して、ロボットの動作を定義するシナリオに必ず盛り込むべきことを挙げた。

1. グルーピング：「システムにログインする」といった汎用的な機能のグループを作成しておく。このグループが多数蓄積されると、「共通部品」として他の業務を自動化する際にも再利用でき、開発効率が上がる
2. コメント：シナリオの要所に処理の意味を記述する。これにより保守担当者が「なぜこの処理があるのか」を理解しやすくなる
3. ラベル：処理ごとに適切な名前をつけることで、見やすさ、理解のしやすさが向上する
4. ラベル（GoTo処理）処理の名称をラベルとして記しておけば、処理を別のフローにジャンプさせるGoTo処理の際にも、処理フローの全体を理解しやすくなる。なお、このポイントは、「BizRobo!」の操作性を前提にしている

　以上のポイントに気を付ければ、ロボットがどのように動作しているのかを明確にでき、開発担当者以外の人でもシナリオを見れば修正すべき箇所が特定できる。保守や運用に配慮した作り方を徹底すれば、稼働後のメンテナンスを外注する必要もなく、コストを抑えられる。

図2　初心者と経験者が作成した処理フロー

図3　保守しやすい処理フロー作成のポイント

止まりにくく、エラーを起こしにくいロボットの作り方

　上記では保守のしやすいロボットの作り方を紹介した。では、止まりにくいロボットを作るためのポイントは何だろうか。同氏は、ロボットが正常に動くために気を付けるポイントを「正常系」、ロボットがエラーを起こしても回復させるためのポイントを「エラー系」に分け、2つの観点から品質の高いロボットの作り方を説明した。

【正常系】外部ファイルの利用時は要注意――機能が正しく動作するか

　RPAツールのデバッグ機能を十分に活用していれば、機能の問題が原因でRPAが止まるということはほとんどない。ExcelやVBAなどの外部ファイルを利用する場合には「バグが出やすい」という。対策として、以下の適切な観点からテストを行い、問題がないよう設計し実装する必要がある。

集計処理のテストの場合

• 集計範囲が正しいか
• 集計の計算式が正しいか
• 集計した結果が正しい箇所に出力されているか
• データの最大桁、少数桁で正しく動作できるか
• ゼロ除算（異常終了につながる）を正しく動作できるか

【正常系】処理量の多い月末のチェックも――業務プロセスが正しく回るか

　人が実行した結果と、ロボットが作業した結果に差異がないかどうかを突き合わせ、RPA化をしても業務プロセスが正しく回るかを検証しておくことも重要なポイントだ。例えば、異なる拠点で同じ業務を行っているはずでも、使用するメールのフォームに違いがあったり、業務の順番が前後していたりする場合がある。この差異が原因でロボットが止まることもあるため、同じロボットを別の場所で展開する際にも動作を確認しなければならない。他にも、ロボットが処理するデータ量の多い月末などを想定した検証をすべきだと菅氏は説明した。

【正常系】異常処理を起こしたロボットは人間がチェック――きちんと停止できるか

　ロボットが異常な結果を出すリスクを減らすために、業務によっては、ロボットを一度停止させて、整合性を確認してから次のフローに移るという処理も必要だ。そこで、シナリオを設計する段階で、ロボットが停止し、人間が確認するフェーズを設ける必要がある。テストの段階でも、正しく停止できるかどうかを確認しておきたい。

【エラー系】エラーは必ず起こる――エラーを検知できるか

　菅氏は、ロボットがエラーを起こした場合の対処法を「エラー系」のポイントとして説明した。同氏によれば、ロボットはささいなことですぐにエラーを起こすという。

　「例えば、ロボットが使うファイルを人が削除してしまったり、画面の解像度を変更したりといった人為的ミスによってもエラーが発生します。ロボットの処理のタイミングとページのロード時間のずれによってエラーが起こる場合もあります。それだけでなく、1回目の処理でファイルが破損していてエラーになり、再実行で残存ファイルを処理できずエラーが重なるようなケースもあるのです。全てのエラーをあらかじめ予測することはできないので、発生後にエラーを検知し、大きな影響を引き起こさないことが重要です」（菅氏）

　菅氏は対策として、あらかじめどこでエラーが起きやすいのか「エラーの観点」を整理し、それぞれ通知方法を決めることを推奨する。また、その都度停止が必要なのか、停止せずに処理を継続するのか、処理を続ける場合の条件は何かを洗い出して、ルールを定めることが重要だ。

　エラー時に、ロボットを停止させるにしても、処理を継続する場合でも、ロボットに求める挙動を定義し、シナリオに組み込む必要がある。いずれも、あらかじめ定義した通りにロボットが作動するのかをテストで検証したい。こうしたテストを省略した結果、手戻りなどが発生し、開発期間が3カ月から5カ月に延びてしまった事例もあるという。

【エラー系】エラー処理の共通部品化で効率化――ロボットが処理を再実行できるか

　一般的にエラーの観点は200以上存在し、業種別によっても異なるという。最初から全てのエラー観点で必要な挙動を定義してロボットを作りこむことは難しく、テストを通じて整備することが一般的だ。その作業を軽減するために、菅氏はエラーの場合に使用する「共通部品ライブラリ」を蓄積することを推奨する。例えば、ロボットが処理する対象のファイルが重複していたり、削除されていたりする場合に必要な機能を、部品として再利用可能にしておくと、作成の工数を削減できる。

　「あるケースでは、共通部品を利用すると、エラー処理のフローを定義する行程が5分から1.5分に短縮できました。処理の箇所が90カ所あるとすれば、作成全体にかかる時間を450分から135分に削減できます」（菅氏）

　RPAツールを提供するベンダーの多くは、既に汎用的に使用できるロボットをシナリオの共通部品として提供しているが、エラー処理に特化した部品の提供はまだなく、ユーザー側でライブラリ化する必要がある。

大規模開発は分業体制でコスト削減

　菅氏は、社内でRPAの適用を拡大する際に、コストをなるべく抑える方法についても言及した。同氏によれば、大規模にRPAを開発する際には、上流から下流までの工程を1つのベンダーに任せるのが一般的だが、多数のベンダーによる分業体制を採用する方が、工数とコストが削減できるという。

　「上流から下流まで担当できる専門のSEは単価が高い。全体をカバーするスキルはなくとも、設計や開発、テストのスキルを持つ専門的な人材を活用して分業で開発に臨むことで、合計コストはかなり低く抑えられるでしょう」（菅氏）

　ただし分業開発を行う場合には、横串で工程管理や、進捗管理、品質の可視化といったことに配慮する必要がある。場合によっては、専用のツールを利用することも視野に入れ、ルールとツールの両輪で一元的に開発を管理する工夫が必要だと同氏は強調した。

　ちなみに、SHIFTではRPAの品質の問題に対して、ロボットの診断サービスである「ROBOPIT!」を提供する。これは診断対象のロボットを分析し、開発プロセスの診断やパフォーマンス診断、事故リスクの診断、業務運用リスクの診断、保守メンテナンスリスクの診断、ROIの総合判定などを行うサービスである。診断結果は最短5日で管理者層向け、実務者層向けのレポートとして提出され、修正の指針を示すという。今後は、実際にロボットを改修するサービスの提供も視野に入れ、企業のRPA推進に資する共通プラットフォームに育てていきたい考えだ。