RPAのソフトウェアロボットとは？

RPA（Robotic Process Automation）とは、ソフトウェアロボットにデスクワークの一部を任せることで効率化やコスト削減を実現するソリューションです。従来、パソコンを操作する事務作業は人間が手を動かして実施していました。つまり、人間がアプリケーションを起動し、人間がマウスやキーボードを操作し、人間が必要な手続きを済ませていました。これら一連の作業を、ソフトウェアロボットによって自動化するのがRPAです。

近年のIT化によって事務作業は大幅に効率化されましたが、RPAを導入することでさらなる効率化を期待できます。現在の日本企業は人手不足を背景に、業務効率化、働き方改革など、様々な対策が求められています。これらを実現するソリューションの1つとして、RPAが注目を集めています。

では、RPAにおけるソフトウェアロボットとはなんなのでしょうか？また、ソフトウェアロボットが得意なこと、不得意なことはなんなのでしょうか？

ここではRPAにおけるソフトウェアロボットについて解説します。ソフトウェアロボットの本質や得意・不得意を理解することで、RPAの導入を検討するときに正確な判断を下せることでしょう。

今日の産業界では、多種多様なロボットが幅広く活用されています。例えば自動車の生産ラインでは、溶接作業を行うロボットが高速かつ正確に自動車のフレームを溶接していきます。 食品を製造するラインにおいてもロボットの導入が進んでおり、箱詰めや仕分けといった作業を高速かつ正確に実施できるようになっています。 最近では小売店などで揚げ物をつくったり寿司を握ったりするロボットも登場しています。かなり生活の身近なところまで、ロボットが活躍し始めているのです。

従来は人間が行っていた反復的な作業を、正確かつ高速に実施してくれるのが産業用ロボットです。ソフトウェアロボットの本質は、産業用ロボットと同じです。異なる点は、産業用ロボットが処理するのが「モノ」であるのに対し、ソフトウェアロボットが処理するのは「情報」である、というところです。

広い意味での「ソフトウェアロボット」は、実のところ目新しいものではありません。例えば1990年代に登場した検索エンジンですが、インターネットを巡回してWebサイト上の情報を自動的に集めるプログラムは「クローラー」と呼ばれ、これはソフトウェアロボットの一種です。

コンピューターゲームの操作を自動化するプログラムの「ボット」はロボットの略称であり、これもソフトウェアロボットの一種です。人間が行うことを自動的に行ってくれるプログラムは、すべて広い意味での「ソフトウェアロボット」なのです。

RPAにおけるロボットは、パソコンのアプリケーションを自動的に操作してくれるソフトウェアロボットです。RPAにおけるソフトウェアロボットと従来のソフトウェアロボットとで大きく異なる点は、RPAにおけるソフトウェアロボットを作成するときにはプログラミングの知識が不要である、というところです。

しかしながら、プログラミング不要のロボットと言っても導入後、いきなり勝手に仕事をしてくれるわけではありません。 RPAにおけるソフトウェアロボットは、業務のことをなにも知らない新人である、と考えるとわかりやすいでしょう。新人に業務を教えるときは、まず初めにパソコンの画面を見せ、実際にアプリケーションを操作する手順を教えるかと思います。 必要なファイルがどこにあるか、ある状況ではこのように操作し、別の状況ではこのように操作する、といったことを教えることでしょう。

RPAにおけるソフトウェアロボットは、RPAツールを介して作成しますが、その作成手順も新人に教えるのと同じです。ソフトウェアロボットにパソコンの画面を認識させ、アプリケーションを操作する手順を記録させます。必要なファイルがどこにあるかを記録させ、状況に応じて処理の手順を変えさせます。

ひとたびソフトウェアロボットを作成したなら、業務の手順が変わらない限り、ソフトウェアロボットは高速かつ正確に業務を実行してくれます。
人間と違い、長時間働くことで疲れることもないので、作業は常に一定ですし、ケアレスミスもしない、時間帯も問わず働いてくれることも大きな魅力です。

ソフトウェアロボットが得意な業務は、以下の条件を満たすものです。

これらの要件はRPAに関する記事などでしばしば目にする言葉です。本記事ではこれらの要件が具体的にどのような業務を指すのか、という点にフォーカスして解説します。

「手順が明確である」という言葉をより正確に表現すると「手順をすべて言葉で言い表すことができ、それを読むだけで誰でも同じことができる」ということになります。RPAツールのソフトウェアロボットは記録された手順（言われたこと）を正確に実行できますが、記録されていない手順（言われていないこと）は実行できません。

RPAツールを用いてソフトウェアロボットを作成するときは、代行させる業務の手順をすべて言葉に言い表すことができるかどうか、検討する必要があります。表現を変えるなら「業務の棚卸し」が必要なのです。

業務の棚卸しを行っていくと、しばしば特定の個人が状況に応じて、経験と勘に基づいて判断しているプロセスが見つかります。 いわゆる「属人的なプロセス」です。人の感覚によって判断しているような業務はそのままではソフトウェアロボットに代行させることは困難です。

RPAによって自動化したい業務の中に属人的なプロセスが存在する場合、対処方法は大きく分けてふたつ存在します。

ちなみに、RPAを導入するために行う「業務の棚卸し」には、よい副作用も生まれます。業務の「手順をすべて言葉で言い表すことができ、それを読むだけで誰でも同じことができる」ようにする、ということは、マニュアルを作ることと同じです。

最終的に「RPAを導入しない」と判断したとしても、「業務の棚卸し」を実施した結果はマニュアルとして残すことができます。業務に携わっている社員が退職したとしても、明確なマニュアルをもとに代わりの社員が業務を続けることができます。

また、「業務の棚卸し」を行うと「どのプロセスが効率化のボトルネックになっているか」ということもわかります。 すべてのプロセスを効率化しようとすると大きなコストがかかってしまいますが、ボトルネックになっているプロセスへ集中的にリソースを投入することで、費用対効果の高い効率化を見こむことができるのです。
そして、そもそも全てRPA化することが必ずしも正解であるとは限りません。人間が実施する作業を工夫することで十分改善が見込めることもあるでしょう。その点でも「業務の棚卸し」はまず、必須の工程となります。

とはいえ、「業務の棚卸し」は実務と並行して行うことになるため、現場にかなりの負担を強いることになります。現場の負担を減らすことが目的なのに、現場へ負担を強いてしまっては本末転倒です。 しばしば、外部のコンサルタントに棚卸し依頼し、コンサルタントが現場にヒアリングを行っていく方法もありますが、時間が掛かるという点と、どうしても人が行うため、誰が誰にヒアリングするのかで結果が大きく変わってしまいます。 したがって「業務の棚卸し」も、可能であればツールを用いて自動化したほうがよいでしょう。

例えば「D-Analyzer」 （ディーアナライザー）は、従業員がパソコンを操作した履歴を自動的に取得・蓄積し、自動的に「業務の棚卸し」を行ってくれます。「D-Analyzer」のようなツールを利用することで、比較的短期間で課題が浮き彫りになり、よりスムーズにRPAの導入が進むでしょう。

「反復性がある」という言葉をより正確に表現すると「頻繁に、繰り返し行うものである」ということになります。1日に何度も同じことを行っているなら、その業務はソフトウェアロボットに向いている可能性が高いといえます。

例えば、顧客から受け取った発注情報を会計システムに登録して関係部署に伝える、という業務は1日に何度も発生するでしょう。 人間が処理すると数分ほどかかってしまう業務ですが、適切に処理内容を設定されたソフトウェアロボットなら一瞬で済ませてしまいます。 仮に1日に100件の発注があるなら、RPA化によって文字通り桁違いの効率化を見こむことができるのです。

逆に反復性がないか、反復の頻度が低い業務に対してRPAを導入してもメリットは薄いといえます。

一方でソフトウェアロボットが不得意な業務は、先にも少し触れていますが、ひとことで表現すると「人間の判断を多く必要とする業務」です。自動化したい業務のうち、ある程度まとまった部分的に人間の判断を必要とするのであれば、ソフトウェアロボットと人間が協力することで解決できるでしょう。 自動化するプロセスと人間の判断を必要とするプロセスを組み合わせれば、十分な効率化が見こめます。

ですが、何度も人間の判断が必要となるのであれば、その業務はソフトウェアロボットにとって不得意な業務です。RPAツールを導入するときは「自動化したい業務」が「自動化できる業務」かどうか、正しく見きわめる必要があります。
不得意な業務を無理やりRPA化してしまうと、全て人間が作業した場合より余計に時間がかかることも起こり得ます。

「自動化したい業務」が「自動化できる業務」なのかどうかを見きわめるためのポイントをひとつご紹介しましょう。そのポイントとは「あら探し」をして問題点が出てくるかどうかです。

「表計算ソフトウェアを操作して、社内システムに顧客情報を登録する」という作業をソフトウェアロボットに代行させるケースを考えてみましょう。手順は以下の通りです。

一見すると、ソフトウェアロボットが代行しやすい業務であるように思えます。業務に携わっている人も「自動化したい」と考えていそうな内容です。 ですが実際には、あちこちに落とし穴が存在する可能性が高い業務です。どのような落とし穴が考えられるのでしょうか？

先ほど述べたように、この業務に対して「あら探し」をしてみましょう。

まず、各部署から送られてくるファイルの形式が統一されているかどうか確認するべきでしょう。顧客の氏名を記載した列が部署ごとに異なっていたり、日付の書式が部署ごとに異なっていたりすると、自動化することは困難です。
場合によってファイルではなく、チャットで文章化されて送られてくることも考えられるケースは、そのままでは自動化できません。

困ったことに、おうおうにしてそれぞれの部署には部署ごとの流儀があります。「現在の形式が一番やりやすい。他の形式には変えたくない」という意見が強いと、ファイルの形式を統一することは困難です。 それでもRPA化するなら「部署ごとにソフトウェアロボットの処理方法を変える」という対応が考えられますが、あまり効率的ではありません。

ファイルの内容を確認する、という点も要注意です。例えばファイルの内容に欠けた箇所がある場合、欠けた情報をどのように処理するのか、ということまでソフトウェアロボットに教える必要があります。

最も手堅い方法は「ファイルの内容が不完全です」と通知してファイルを送ってきた部署へ差し戻すことでしょう。しかし、登録作業を行っている人が「よしなに取り計らって情報を埋めている」のであれば、ソフトウェアロボットは対応できません。 「よしなに取り計らう」というのは、まさに人間の判断です。ソフトウェアロボットは「よしなに取り計らう」ことができません。

ファイルに記載された情報を顧客情報管理システムに登録する、という作業にも注意すべき点があります。例えば、メンテナンスのために顧客情報管理システムが停止する、という状況が考えられます。 顧客情報管理システムが常に稼働していることを前提にしてソフトウェアロボットを作成してしまうと、顧客情報管理システムが停止したときにソフトウェアロボットはどうすればいいのかわからなくなります。

ソフトウェアロボットの処理が停止するだけならよいのですが、停止したことを無視してソフトウェアロボットが動き続けてしまうと、一見すると問題なく稼働しているようでも、顧客情報管理システムが停止していた間の情報はシステムに入力されなかった、といった事態になりかねません。

以上のように、ソフトウェアロボットが得意であると思える業務も、詳しく見ていくことで実際にはソフトウェアロボットが不得意とする業務だった、と判明するケースは多くあります。 RPA化を検討するときには、あらゆるパターンを想定して「自動化したい業務」と「自動化できる業務」の区別を明確にする必要があるのです。

RPAとソフトウェアロボットは、現在のところ注目を集めすぎているきらいがあります。さも万能のツールであるかのように語られることもあるのですが、実際にはそうではありません。RPAツールを用いてソフトウェアロボットに代行させるのではなく、別のソリューションを採用したほうがよいケースも多くあります。

例えば、名刺管理は完成度の高いソリューションが多く存在します。名刺を読み取り、名刺の内容を登録する、という業務をわざわざRPA化する必要はないでしょう。

むしろ、名刺には多様な情報が記載されているため、必要な情報を正確に抽出するためには画像処理などの高度な技術が必要です。ソフトウェアロボットは「アプリケーションを正確に操作する」ことに特化しているため、得意・不得意の観点からしても、名刺管理はRPAには向いていないといえるでしょう。

ほかにも、経費精算の処理をRPA化したい、という要望が想定できます。ですが、経費精算処理もまた、完成度の高いソリューションが多く存在します。 経費精算処理はお金を取り扱う業務ですから、なにより正確に処理することが重要です。また、経費として認めるかどうか、というプロセスは決裁権を持つ人間が判断すべきことです。 経費精算処理については、専用のソリューションを利用したほうがよいでしょう。

RPAにおけるソフトウェアロボットは、パソコンのアプリケーションを自動的に操作してくれるものです。RPAにおけるソフトウェアロボットは「手順が明確」かつ「反復性がある」業務に対して、大きな効果を発揮します。

一方で、ソフトウェアロボットには不得意な業務があります。特に「人間の判断」を多く必要とする業務は、ソフトウェアロボットには不向きです。また、そもそも他のソリューションを利用したほうが効率的な業務もあります。

業務内容を整理し、課題を認識したうえで、RPA化の向き不向きを見極め、費用対効果をよく検討することで、RPAを導入すべきかどうかの適切な判断につながることでしょう。