「RPAは簡単に作れる」に潜む落とし穴、回避の心得とは？

RPAの運用が予想以上に重労働だ、夜間や休日にロボットが止まって仕事にならない――今回は、RPAの“こんなはずじゃなかった”を回避する2つのポイントをご紹介します。多くの企業が重視するRPAのある機能が、運用を複雑化することはご存じない方も多いのではないでしょうか。

[志村裕司，Blue Prism]

　こんにちは、Blue Prismの志村です。前回はエンタープライズRPAの導入と運用が成功した場合のメリットをご紹介しました。大きな成果を得るためには全社的な自動化の取り組みが必須であるという私の説明に対して、「日本企業は現場主義、縦割り、ボトムアップの文化なので、実際のところそれは難しいのでは？」というお声をいただきましたが、決してそんなことはありません。

　例えば、幾つかの部門で個別にデスクトップ型のRPAツールを導入しているために、業務全体のプロセスではなく単なる一作業の自動化しか実現できないと悩む企業が増えています。こうしたケースでは、社内にロボットが乱立し、ロボットの一元管理ができていないことで内部統制上の課題を抱えていることも珍しくありません。最近では、状況を打破するために、経営企画部やIT戦略部といった組織横断の部門で提案をまとめて経営層から承認と予算を獲得し、全社的なプロジェクトとしてRPAに取り組む日本企業が増えていると感じます。

　特に日本はこれから労働人口の減少が一気に進んでいきますので、企業が生き残るためにも業務の自動化というのは必ず取り組まなければいけないテーマになります。もしかしたら、経営層はあなたの提言を待っているかもしれません。

TCO／ROIに影響する「拡張性」と「耐障害性」

　さて今回は、RPA導入時の製品選定に必要な視点である「拡張性」「耐障害性」についてご紹介します。全社的な自動化の取り組みであるエンタープライズRPAを成功させるには、この「拡張性」と「耐障害性」を欠かすことはできません。

　ここでいう拡張性とは、「いかに効率的にデジタルワーカーの数を増やしていけるか？」という観点を指します。デジタルワーカーは、業務プロセスや操作対象のシステムが変更される度に修正が必要ですが、数を増やせば増やすほど、それに比例して運用・保守の工数が上がってしまうようでは、全社規模での導入は難しくなります。

　日本の企業は導入時にこの視点が抜けがちで「業務部門のユーザーでもいかに簡単にロボットを開発できるか？」ということばかりを重視するため、いざ自動化の対象を広げようとしたときに拡張性の問題に直面する例が後を絶ちません。

　一方、RPAの文脈でいう耐障害性は、インフラ面で冗長構成を組むことによりミッションクリティカルな業務にも対応できるという意味だけでなく、それ以上に、自動化したプロセスが途中で止まらずに最後まで実行できる能力のことを指します。

　例えば、100件の請求書データを社内システムに登録する業務の場合、51件目がエラーデータだったためにプロセスが止まってしまい、人が対応しなければ再始動できないようでは、夜間や休日にスケジュールを組んで実行を任せることはとてもできません。しかし、エラーデータなどが原因で自動化のプロセスが止まってしまうケースは、実は珍しいことではないのです。

悪しきレコーディング信仰

　拡張性を確保する際に、落とし穴となりやすいのが「レコーディング」です。以下では、ロボット開発のトレーニングを最小限にして手っ取り早くRPAを導入したい欲求にかられ、レコーディング機能を必須と考えることがいかに危険であるかを説明したいと思います。

　レコーディングとは、人間がPCで行った操作を、そのまま自動化のシナリオとして再現する手法です。レコーディング機能を使えば、録画ボタンをクリックするだけで自動化のシナリオを作成できるため、業務にすぐ適用できるメリットはあるのですが、適用範囲を広げるときに課題が顕在化してきます。

　例えば「Salesforce」にログインして請求書のデータを登録するような業務を自動化した場合、登録の業務プロセスが変わったり、Salesforceが設定変更やバージョンアップなどの理由により変更されたりしたときが問題です。

　レコーディング機能によってシナリオを作成すると、裏でプログラムコードが自動生成されます。もしSalesforceにアクセスするロボットが数十台もある場合、同じようなコードが各ロボットに散在するため、Salesforceで処理を行う全てのロボットが修正対象になります。プログラミングスキルのあるエンジニアが影響箇所を特定し、自動化のシナリオが記述されたロボット定義ファイルの修正とテストを多大な工数をかけて行うことになるのです。

　再びレコーディングし直す方が、工数としては少なく収まるかもしれませんが、前回レコーディングしたものとまったく同じ内容で登録できる保証はないため、これは正確とは言い切れません。

　業務プロセスやシステムの変更は必ず発生します。レコーディング機能は数台レベルの導入では有効かもしれませんが、その後の拡張を考えた場合はロボットの運用負荷が上がる要因となるため、使わない方が良いのです。

　とはいえロボット開発がボトルネックになってしまってはその活用も広がりません。業務部門主導でいかにロボットの開発・運用を効率よく行うかについては、第4回の記事で詳しくご説明したいと思います。

　なお、レコーディング機能によって作られた自動化プロセスには、人の作業に依存した不必要な待機時間が設定されるため、大量のタスクを実行する場合はその実行速度（つまり処理性能）に問題を抱えるケースが多いことも注意が必要です。

メンテナンス性を考える、Blue Prismの製品アーキテクチャ

　Blue Prismは、RPA化がある程度の規模を超えるとレコーディング機能では運用がまわらないことをよく理解しているため、レコーディング機能を提供していません。

　Blue Prismはドラッグ＆ドロップでフローチャートを記述することでロボットの作業を定義しますが、「プロセス」と「オブジェクト」を分けたアーキテクチャにしているのが他のツールとは異なるユニークなポイントです。プロセスは作業の手順、オブジェクトはロボットが作業する対象とイメージしていただければよいでしょう。

図1　プロセスとオブジェクトの分離イメージ

　　先ほどの例にならい、Salesforceの操作を自動化する場合を考えてみます。まず、Salesforceの画面単位でオブジェクトを作成して、ログイン、ログアウト、検索、請求データ入力などの単位でアクションを定義します。ロボットがSalesforceにアクセスするときは、プロセスからSalesforceオブジェクトと操作したいアクションを選んで呼び出せば、必要な処理が完了します。

　プロセスからオブジェクトを切り離す構成にすることで再利用性が高まり、Salesforceに仕様変更が発生した場合でも、そのオブジェクトを修正するだけで全ての対応が完了するのです。作成したプロセスは一切変更の必要がありません。

　また、一度作成したオブジェクトは使い回せるので、新しく他のプロセスを作成するときにロボット開発の効率が上がるというメリットもあります。

　実はこの考え方はJavaなどのオブジェクト指向型のプログラミング言語とまったく同じ発想のもので、プログラム開発の世界ではすでにデファクトスタンダードになっています。オブジェクト指向のプログラムはメンテナンス性がよく、変更に強いという特長があるため、最終的なTCO（総保有コスト）削減に大きく貢献する重要なポイントになります。

　プロセスやオブジェクトはスタジオと呼ばれる開発環境で作ります。コーディング不要で直感的にフローチャートを描けるため、ITのバックグラウンドがない現場部門の方でもツールの使い方さえ覚えれば開発は可能です。

図2　Blue Prism開発画面の例

スモールスタートでRPAを導入するとしても、対象を広げる計画がある場合は、ぜひ最初の製品選定時から拡張性という観点で検討を行ってみてください。

スケジュール実行に必須の「耐障害性」

　作業の途中でエラーが発生しても、最後までプロセスを止めずに実行できる能力のことを耐障害性といいます（これを回復性と呼ぶこともあります）。それを実現するためには、キューとエラーハンドリングを活用することがポイントになります。

　キューとは待ち行列のことで、タスクを順番に処理する仕組みのことです。前述の請求書を100件処理する例で考えると、Blue Prismであればキューを利用して51件目のエラーデータだけを例外としてマークしておき、残りのデータを100件目まできちんと処理できます。

　また、キューのデータを複数のロボット実行環境に割り振って、排他制御でデータの整合性を保ちながら高速に処理することも可能です。

　こうした機能によって、デジタルワーカーに自律性をもたせ、夜中や土日でも安心してスケジュールを組んで仕事を任せることができるわけです。例えば土日に発生した分のエラーデータは、月曜の朝に出社してから手作業で処理をするという運用ルールを作れば、対応としては十分でしょう。

　耐障害性が高い製品の場合、ミッションクリティカルな業務にも適用でき、24時間365日無駄なくロボットを稼働できることから圧倒的な生産性を発揮できるので、ROI向上にも大きく寄与します。

図3　デスクトップ自動化と比べた場合のデジタルワークフォースのメリット

　いかがでしたでしょうか。RPA導入において最も重視すべきTCO／ROIという観点で、少しでも参考になるヒントがあれば幸いです。

　次回も引き続き、RPA製品選定において大切な「コンプライアンス」「セキュリティ」の視点を紹介します。どうぞお楽しみに。

著者紹介：志村裕司

Blue Prism　ソリューションコンサルティング部長

野村総合研究所、セールスフォース・ドットコム、Box JapanといったIT企業で活躍後、Blue Prismに入社し、日本ビジネスの立ち上げメンバーとして尽力。プリセールス活動を中心に、導入プロジェクトへの参画やイベントでの講演も数多く務める。

企業紹介：Blue Prism

RPA（Robotic Process Automation）ソリューション、「Blue Prism」を提供する企業。2001年に創業以来、RPAのパイオニアとして、約15年にわたり世界中の企業における新たな働き方の実現を支援してきた。「エンタープライズRPA」というコンセプトのもと、拡張性、耐障害性、セキュリティ、コンプライアンスといった機能を提供し、クラウドやAI（人工知能）との連携もサポート。Coca-Cola、Pfizer、IBM、Nokia、Siemens、Zurichといった有名企業で多くの実績を持つ。