RPAにおけるPoCで”出口”を見つけるための3つの道しるべ：RPA導入ガイド（6）

RPA（Robotic Process Automation）とは何かという基本的なことから、導入するためのノウハウまでを解説する連載。今回は、筆者がPoCや導入支援を経験する中でぶつかってきた壁や問題を先回りして紹介することで、スムーズなRPAの導入を支援したいと考えております。

[西村泰洋，富士通]

今回の主な内容

• RDAから入るか、RPAから入るか
• 【1】RPAソフトウェアの構成
• 【2】「個人の仕事」と業務プロセスの違い
• ロボットマークを描く
• 【3】単体動作と「管理」の違い
• 先人の経験からの教訓
• 次回は、PoCによる全体計画の修正など

　RPA（Robotic Process Automation）とは何かという基本的なことから、導入するためのノウハウまでを解説する本連載「RPA導入ガイド」。前回第5回では、RDA（Robotic Desktop Automation）のPoC（Proof of Concept：概念実証）について解説しました。

　PoCに着手したいと考えると、RPA、RDAのいずれであれ、本格的な準備を進めていくことになります。第6回となる今回は、RPAのPoCに向けて押さえておくべきポイントと、PoCを通じて初めて理解するRPAということをテーマに解説します。

　RDAは、個別のデスクトップにインストールして利用するソフトウェアであることから、業務プロセスやワークグループを意識しなくても進めることができます。ところが、RPAの場合は、業務プロセスという観点に加え、システムとしてサーバからの集中管理も必要となることから、難易度は一気に上がります。

　PoCに関しては、RDAから入る企業や組織が大半ですが、多様な製品と使い方があるので、どちらを先にするか、どのように進めるか、悩まれることでしょう。そこで今回は、筆者がPoCや導入支援を経験する中でぶつかってきた壁や問題を先回りして紹介することで、スムーズなRPAの導入を支援したいと考えております。

RDAから入るか、RPAから入るか

　筆者の経験によるイメージをお伝えしますと、「RDAから入れば山を登るがごとく、RPAから入れば樹海を行くがごとし」です。

図表1　RDAから入れば山を登るごとく、RPAから入れば樹海を行くがごとし

　その意味は、RDAから入ると、RPAに向けて高い山や壁があるように難しく感じる。RPAから入ると、何がRPAなのか出口が見えないということです。

　もちろん、読者の皆さんにそのような苦労は必要ありません。山や壁の越え方、出口への近道を先回りしてお伝えします。

　ここからは、先ほどイメージでお伝えした山と樹海の正体を解説しましょう。大きくは「RPAソフトウェアの構成」「個人の仕事と業務プロセスの違い」「単体動作と『管理』の違い」の3点に集約されます。

【1】RPAソフトウェアの構成

　まず、ソフトウェアの物理構成に関して解説します。RPAやRDAのソフトウェアは図表2のように、大きく4つの物理構成あるいは機能から成り立っています。

図表2　RPAソフトウェアの物理構成

• ロボットファイル
  まさにRPAらしいロボットの実行ファイル。本連載では、ロボットの実行ファイルを「ロボットファイル」と呼ぶ
• 実行環境
  ロボットファイル専用のランタイムで、ロボットファイルを実行するためのプログラム
• 開発環境
  連載第2回でロボットのシナリオ作成の方法などを紹介したが、製品固有の開発環境でロボットファイルを開発する
• 管理ツール
  サーバから複数のロボットファイルの管理が必要な場合に必須となる。ロボットファイルの実行と停止、稼働状況の確認、スケジュール、ユーザー管理などを、この管理ツールから行う

　上記の4つの機能は、RPAベンダーごとの販売戦略の違いにより見え方が異なります。1つのパッケージになっている場合もあれば、それぞれ別に販売されている場合もあります。RDAソフトウェアの場合は「ロボットファイル、実行環境、開発環境までで、管理ツールはない」など、さまざまな違いがあることから、ユーザーからすると分かりにくくなっています。

　しかし、最初から上記の4つの視点を意識すれば、ソフトウェアの差分が理解できているので、山の越え方や出口もおぼろげながらでも見えるのではないでしょうか。「PoCをやらなければならない」と思うと、ソフトウェアの学習にも気持ちが入ることでしょう。

【2】「個人の仕事」と業務プロセスの違い

　意外な盲点の1つを解説しておきます。

　RDAの場合は、単体のデスクトップや、2、3個の個別のデスクトップにおける検証が多いのですが、それらはあくまで「個人の仕事」の一部の置き換えや効率化であることは、前回第5回でも紹介しました。

　RPAの場合は、業務プロセス全体としての効率化や生産性向上を目指しているので、業務プロセスの意識で対象を見る必要があります。

　例えば、個別のデスクトップや人であれば、「私が、毎日3時間かけて、Excelと業務システムのデータを照合している仕事」で分かりますが、業務プロセス全体で見る場合には、「データ照合が、業務プロセスのどこに位置付けられて、どのタイミングで実行する」「次にどうつなぐか」などを関係者で共有、確認する必要があります。

　このような活動は必ず事前に行いますが、忘れてしまう方も多いようです。連載第3回の机上検証フェーズでは、業務俯瞰表の例を示して解説しました。今回は、より直感的に理解を深めていただくために、「ロボットマーク」を紹介しておきます。

ロボットマークを描く

　現行の業務プロセスはRPA導入前なので、人によるオペレーションや、既存のシステムの処理でプロセスが流れていると思います。RPAを導入すると、個々のプロセスの一部に入っていくことが多いのですが、それがどの部分かについて具体的にビジュアルで表現したのが図表3のロボットマークです。

図表3　ロボットマークを描く

　ワークショップの場などで、ホワイトボードに「人のマーク」と「ロボットマーク」を描いて関係者で共有し、最終的にはドキュメントに落とし込みます。顧客企業の方が筆者の描いたロボットマークを見て、「ロボットらしいですね」などと褒められたこともあります。「業務プロセスのどこにRPAを入れるか」「PoCにおいて、どのプロセスのどこで検証を進めるか」が共有できないと後で支障を来すので、必ず行ってください。

　ちなみに、図表3の中に「人」という文字が隠れていることは分かっていただけましたでしょうか……。

【3】単体動作と「管理」の違い

　RDAでは1個のデスクトップで検証を行うこともできます。

　検証用の端末が開発端末も兼ねる最小構成のケースなどでは、ロボットファイルを作成して、単体で実行するだけでも簡単な検証ができます。ところが、RPAでは、管理ツールで設定して各ロボットファイルを実行します。

　図表4でロボットファイルの稼働までのステップをあらためて確認します。

図表4　ロボットファイル稼働までのステップ

　図表4を見ていただくと分かりますが、RDAとRPAに共通なのは前半の2つのステップです。RPAであれば後半の2つのステップも必須になりますが、RDAでは状況によっては意識せずに動作させることができます。

先人の経験からの教訓

　ロボットファイルの作成と実行に関しての経験談を紹介しておきます。

　ロボットファイルの開発に際しては、デバッグ機能が付いていることから、その機能を使って「設計した通りに動作するか」を確認することができます。

　筆者は、所定のロボットファイルの作成を終えて、デバッグ機能で動作の確認も済ませたことから、予定時間に始動するロボットファイルの実行とそれによる結果を待っていました。

　ところが、予定時間の後で結果とログファイルを確認すると、ロボットファイルは動作していませんでした。動揺しながら、経験豊富なエンジニアに質問したところ、「管理ツールでの設定が行われていません」と回答が返ってきました。

　お恥ずかしい話ですが、図表4の最後のステップを失念していたのです。今でこそRPAの導入に関する連載の執筆などもしていますが、最初はそんな感じだったのです。

次回は、PoCによる全体計画の修正など

　今回は、RDAを経験されてRPAのPoCや導入に進まれる方が多いことから、その間に存在する「山」や「壁」などについて解説を進めてきました。

　次回はRPAのPoCの実践での留意点や、PoCによる全体計画の修正などについて解説します。

筆者紹介

西村 泰洋（にしむら やすひろ）

富士通株式会社　フィールド・イノベーション本部　シニアディレクター

顧客企業を全社的に可視化して経営施策の効果を検証するサービスの指揮を執っている。著書に『図解入門 最新 RPAがよ〜くわかる本』（秀和システム）、『RFID+ICタグシステム導入・構築標準講座』（翔泳社）、『成功する企業提携』（NTT出版）がある。