2017年頃からよく耳にするようになったRPA。オフィスワークの自動化の一環として使いこなすためにどんなことを知っておくことが必要なのでしょうか。
今回は、実際にオフィス現場でRPA導入作業中(2019/11/10時点)の立場から気がついた、気を付けたい注意点について説明します。
目次
RPA導入前に知っておきたいこと
RPAはロボットではなく、プログラミングのための統合開発環境
RPAとはRobotic Process Automationの略です。いきなり本質を突きますが、RPAの実態は自動化ツールの統合開発環境です。統合開発環境とは、プログラムを書く場所（エディタ）であったり、プログラム上のエラーを検出したりする機能であったり、部分的に作業を記録してプログラムに変換すると言った、プログラムを作成するのに必要な機能を集めたものです。よって、ロボットではありません。
よくRPAベンダーの広告でプログラミングフリーを謳っていますが、それは商品を販売するための営業トークです。確かに作業を記録する、レコーディング機能はついているので、システムにログインする程度のことはレコーディング機能で可能です。しかし、レコーディング機能は多くの場合、クリックする場所の周辺の画像キャプチャを取って記録します。いつもと違う画面の見た目になっていたり、クリックする場所の周辺の様子が違ったら再現できなかったり、そもそも同じような処理を繰り返すようなことはできません。「プログラミングフリー」や「作業の記録だけで誰でも簡単に」と言った宣伝文句に騙されないようにしましょう。
とはいえ、私はRPAを否定している訳ではありません。憎むべきは「プログラミングフリー」を謳う宣伝文句や、「ロボットが自分で作業を覚える」様に感じる営業トークです。統合開発環境である、という認識をもってば確かにある程度のことはそれなりの工数でできるのも事実です。
RPAを統合開発環境と捉え、きちんとスクリプトを組み立てれば結構使える
RPAの謳い文句は当てにならないことが分かりました。とはいえ、RPA自体を否定するのは早いというのが私の考えです。なぜならば、統合開発環境と割り切って、しっかりとスクリプト*1を作り込めば、かなりのことができます。
営業トークで使われているレコーディング機能の本当の目的
営業トークに使われてしまっているレコーディング機能の本当の目的は自分でプログラムをする事です。レコーディングした内容をプログラミング言語に起こすことで、操作しようとしている対象のモノの名前が分かったり、作業そのものの命令の名前が分かったりします。これがレコーディング機能の本来的な使い方です。自動化するためにレコーディングをするのではなく、自動化プログラムを作成するために辞書的に使う、と言う事を覚えておきましょう。
「プログラミングフリー」はウソとは言い切れないけど・・・プログラミング的な思考回路は必要
ある程度までは、プログラミング言語を書く事なく、シナリオやスクリプトと言った処理の台本を記述する事ができます。処理の流れをフローチャートを書く様に、またはレゴブロックを積むように記述できるからです。
それでも、「もし○○だったら、△△する」という条件分岐や「○○が△△になるまでXXを繰り返す」と言う繰り返しのプログラミングの考え方は必要です。一時的に値を入力しておく「変数」や、何かの処理をするときに必要なデータを渡す「引数（ひきすう）」と言った概念の理解も必要です。とはいえ、これらは少し（おそらく30分～1時間くらい）勉強すれば理解できます。その30分～1時間の勉強すらできない人もいるので、「誰でも簡単に自動化が作れる」は言い過ぎという感じはします。
意外と早くプログラミング言語によるスクリプトの記述が必要になる時が来る
システムにログインするところまでは良かったです。例えば、先月の1日から当日までの何かのデータのダウンロードをしたいと思ったときどうでしょうか。作業の記録ではできません。明日になったら「当日」の日付が変わってしまうからです。来月担ったら「先月の1日」の日付も変わってしまいます。日付を指定するにはプログラミングの知識が必要です。
毎日、先月1日から当日までのデータをダウンロードすると言うような作業は結構存在すると思います。この時点でプログラミングの知識が必要になります。「プログラミングフリー」期間は案外早く限界を迎えてしまいます
腹をくくってやると決めるならあり
と言うわけで、「プログラミングを知らないからRPA」と言うのではなく、バリバリプログラミングするつもりで開発環境としてRPAと呼ばれるソフトを採用するのはアリだというのが、私の現時点（2019/11/10）での主張です。大切なことなのでもう一度言っておくと、RPAはプログラミングする為の統合開発環境です。ロボットではありません。
個人的な作業の自動化と組織として進める自動化は全く性質が異なる
これまでのところで、RPAはロボットではなく、プログラムの開発環境である事が分かりました。この認識を持った上で進めることが大事です。ここまで承知で進めるのであれば、腹をくくって進めましょう。進めると決めた人に向けて、自動化の留意点を説明します。
個人的な作業の自動化はどんどん進めて良いが、人や部門をまたぐ作業は注意が必要
これはRPAに限ったことではありません。個人的な作業は自分が責任を取れるので、自動化できるところは自動化すれば良いと思います。ただし、責任が取れることが前提なので、RPAのスクリプトがうまく動かなくて作業が完了できなかった場合は、自分でリカバリーができる事が前提です。
一方、個人の範囲を超えた自動化は自分でリカバリーができるとは限りません。後工程や他部門に迷惑が掛かる可能性があります。個人の範囲を超えた業務は、もし動かなくなった場合はどうするのか、プログラムの改修は誰がどのタイミングで行うのか、改修が完了するまでの期間はどうやって対応するのか、RPAのメンテナンスができる人材はどうやって育てるのか・・・
予め決めないと行けない事が多すぎます。RPAの導入を組織として進めるのは非常に難易度が高いです。上に挙げた運用面もさることながら、スクリプトの作成も困難です。
先述の通りRPAとはいえ、結局中身はプログラムなので、RPAの自動化プログラムを組める人が、さらに自動化したい業務を深く知った上でようやく自動化が実現するのです。
RPA導入前に知っておきたいことまとめ
以上の内容をまとめると下記の様になります。
- RPAはロボットではなく、プログラミングの為の開発環境
- プログラミングフリーはプログラムを書かなくてもある程度できると言う意味
- いずれはプログラムを書かねばならないときが来る
- 個人レベルならどんどん進めれば良い
- 人や部門をまたぐ作業の自動化は注意が必要
また、RPAは個人利用でも高額になることが多いですが、そんな方にはRPA Express(Workfusion Studio)がオススメです。商用利用も個人利用も無償です。（2019/11/10時点）
まずは無償なので、まずは触ってみて、使えそうだったら導入というのもアリだと思います。RPA Expressについては、スクリプトの作成方法の解説も行っているので、そちらで、RPAで自動化スクリプトを作成するとはどういう作業なのかを知りたい方はどうぞご覧下さい。
＜RPA Express(Work Fusion)関連記事＞
① エクセルを開く
② エクセルに書き込む
③ エクセルから値を取得する
④ 値の型変換
⑤ カスタムアクション
*1:RPAによって呼び方は異なります。作業する内容の流れの順を示したコードのこと
