RPA製品を選定する際に持つべき2つの視点と業務プロセスの観点から考えるRPAの本質：RPA導入ガイド（2）

　RPA（Robotic Process Automation）とは何かという基本的なことから、導入するためのノウハウまでを解説する本連載「RPA導入ガイド」。連載第1回では、RPAに関しての基本的な事項と導入に際して押さえておきたいことを解説しました。

　第2回となる今回は、RPAをより深く理解するために、RPAソフトウェアを選定する上で持つべき視点や項目を中心に解説を進めていきます。

RPA製品を選定する上で持つべき2つの視点

　現在、さまざまなRPA関連製品が提供されています。

　導入を真剣に検討し始めると、「RPAの利便性は理解できたが、自社での導入や活用にどんな製品が適しているのか？」という悩みを持たれるのではないでしょうか。

　これは「さまざまな企業の導入に際しての最初の壁」とでも言いましょうか、皆さん必ず通る道です。そこで参考となる切り口である基本的な視点と項目を紹介していきます。

　初動で重要なのは、どのレベルで活用するかを示す導入の形態と、ロボットによる自動化のシナリオの作成です。

【視点1】導入形態

　大きく分けると3つの形態となります。簡単に言えば、何人（何台）でどれくらいの規模で使うかということですが、導入形態に応じて導入の規模は大きくなっていきます。

（1）個別デスクトップ

　特定の個人の作業を軽減・効率化するための自動化の実現として、特定のデスクトップPCに導入する。

　陸上競技に例えると、個人競技における1人の走者のようなイメージです。

（2）デスクトップリレー

　あるデスクトップでの作業が終わったら、さらに次のデスクトップというように、リレーで次の走者にバトンを渡すように、個別デスクトップのシーケンスとして導入する。

　400メートルを100メートルずつ4人で走る、400メートルリレーのランナーたちの姿を想像してみてください。

　現実の業務では、前のデスクトップから後ろのデスクトップに、完了合図を送る、共有ファイルを活用する、タスクスケジューラーを活用する、などで、バトンを渡しています。

（3）集中管理

　業務プロセス全体での自動化を目指して、複数のデスクトップとプロセス全体を集中管理するサーバなども含めて、人で言えば関係者全体で活用する形態です。

　400メートルリレー競技は、主役であるランナー、ランナーをコースに案内する人、スターター、記録計測者、審判、他のたくさんの人による役割の分担で成り立っていますが、それぞれの担当プロセスは明確であり、全体の進行管理をしている競技委員もいます。

図表1　導入形態の概要

　なお、後ほど解説しますが、（1）個別デスクトップと、（2）デスクトップリレーはRDA（Robotic Desktop Automation）に、（3）集中管理はRPAのカテゴリーに位置付けられます。

　従来は、個別デスクトップと集中管理の大きく2つに分けて語られていました。本稿では実際の活用シーンから、デスクトップリレーをあえて分けて整理しています。

【視点2】シナリオ作成

　ロボットによる動作の自動化の集積をシナリオとして定義して作成します。作成の方法は製品によりますが、以下のように大きく3つのタイプがあります。自動化の内容を定義するシナリオの作成ができないと、ロボット化は進まないので、極めて重要なポイントです。

　誰がシナリオを作成するか、どこまで細かく定義したいか、シナリオや定義レベルの標準化、などの観点で選択がなされます。

（1）画面キャプチャータイプ

　デスクトップで実際に操作している画面を、紙芝居のように並べて、操作順に記憶させるものです。例えば、「Excelのファイルを開き、次に、Webシステムも起動して、ExcelシートのB2セルのデータをWebシステムにコピーする」という流れを、操作画面を基に記憶させます。

　まさに、RPAらしい機能です。画面キャプチャーですと、プログラミングやシステム開発の経験などがなくてもシナリオの作成を進めることが可能です。

図表2　画面キャプチャータイプのイメージ

（2）オブジェクトタイプ

　先ほどの、ExcelからWebシステムに入力する例で言えば、以下のように、操作を対象と動作に分解して、製品で提供されているテンプレートを活用して定義するものです。

図表3　オブジェクトタイプのイメージ

　プログラミングするよりもずっと楽で、記述のミスもありません。（1）と（3）の中間のタイプといえるでしょう。

（3）プログラミングタイプ

　プログラミング言語を活用して記述・定義します。

　Microsoftの.NET Frameworkを活用する製品、Javaを活用する製品、などがありますが、プログラミング経験が豊富な方には好まれます。

　シナリオ作成の3つのタイプを説明してきましたが、「このシステムやOAツールの、この画面で、この場所に、こうする」を、（1）は画面を基に、（2）は提供されているテンプレートを基に、（3）はプログラム言語で記述し、定義しています。

　3つを見ると、どれがご自身や所属している組織に合っているか、何となくイメージがつかめたかと思います。

　なお、たくさんのソフトウェアロボットが稼働すると、集中管理や運用管理にも目を向ける必要がありますが、これらは別の回で取り上げます。

業務プロセスの観点から考えるRPAの本質

　さて、ここまでRPA製品を選定する上で持つべき2つの視点について考えてみましたが、選定する上で必要となる「製品のカテゴライズ」の前に、「【視点1】導入形態の（3）集中管理」でも挙げたように、「RPAなのか、RDAなのか」というRPAの本質について、一度考察してみます。

　RPAの本質を理解するために、業務プロセスとの関係で考えてみます。例として、実績管理業務で見てみましょう。

　多くの企業で実績を管理する業務がシステムと手作業で行われていると思います。図表4は、A部、B部で注文実績を入力して、管理部門で統合して、全体で実績を共有する業務プロセスを、BPMN（Business Process Model And Notation）に従って整理したものです。

　現実感を持って想像してもらうために、A部、B部、管理部門が物理的に広いワンフロアに位置しており、同じネットワークで業務を行っているとしましょう。

図表4　実績管理業務のBMPN表記例

　ここで、ロボット化できる仕事を整理してみると、ほぼ全てが自動化できそうです。

ちまたのRPAは実はRDAでは？

　A部とB部の入力作業が大変なので、そこだけを自動化したい場合、具体的にはA部のPCとB部のPCに、ロボットソフトをインストールして対象業務を自動化するのは、「RDA（Robotic Desktop Automation）」と呼ばれています。

　管理部門の業務をしているPCに単独で入れる場合も同様です。それぞれは、まさにDesktopのAutomationで、BPMNの個々のアクティビティーを示す角丸四角形にとどまります。

　テレビ、雑誌、新聞などで、RPAの特徴がクローズアップされて伝えられてきたために、RDAがRPAとして捉えられてきたケースもあるのではないでしょうか。

RPAの定義は2種類

　対して、RPA（Robotic Process Automation）ですが、こちらは少し難しくなりますが、物理的な観点から2つの言われ方があります。

　2は、いわばシンクライアントとサーバの関係です。

　RPAは、Process Automationですから、個々の仕事というよりプロセスの自動化を指します。従って、BPMNでいえば、自動化できるアクティビティー全体と、つながりを表す接続線も含むことになります。

　RPAベンダー各社から提供されている製品も、デスクトップにインストールするRDA、サーバにインストールする、もしくはサーバに仮想ロボット群を備える、RPAなどに分かれています。

製品のカテゴライズ

　ここまで、RPA製品を選定する上で持つべき2つの視点とRPAの本質に関して整理してきました。

　連載第1回では、日本市場の創成期をけん引してきた製品やベンダーを紹介していますが、今回解説してきたRPA、RDAの視点で見ると、「BizRobo!」「Kofax」「Pega」などはRPAに、「WinActor」の現行版はRDAに、それぞれ位置付けられます。「【視点2】シナリオ作成」は、それぞれの特徴によって異なります。

　このように基本的な視点を備えることで、自社での活用イメージや適切な製品などを大まかにつかめるのではないでしょうか。

　ただし、製品を検討する上で重要なのは、現在において本当にやりたいことと、最終形はどうしたいか、というアイデアや意見をしっかりと持つことです。

次回は、5つの導入プロセスの机上検証（効果検証）に関して解説

　次回は、第1回で紹介した5つの導入プロセスの机上検証（効果検証）に関して解説を進めます。なお、次回以降はRPAとRDAという言葉の使い分けをしながら進めていきます。