はじめに
RPAの活用により、社内のクラリカルワークを削減し社員をより生産的な仕事に従事させようとするプロジェクトが４，５年前より急速に増えてきました。一つには、収益基盤の再構築を目指す大手の銀行が率先して活用する声を上げ、マスコミ等に取り上げられたことも影響していると考えています。
ただし、気をつけなければならないのは、いろんな成功事例と呼ばれるものの中には、実は政治的な要因によってその効果が多少バイアスをかけたものとなっている可能性があると感じられることが多いことです。
そこで実際にRPAの推進責任者（というかIT戦略の一環としてRPAなどの新技術を評価する責任者）としてプロジェクトに携わったものとして、その効果と課題について率直な意見を共有させていただきたく思います。もちろん、これもバイアスが全くないものとは言い切れず、私個人（会社としてはその評価を採用したわけだが）の意見であることはご承知ください。
１．RPAの仕組み
RPAは、人間がコンピューターに対して行う入力作業を基本とした操作を、プログラムが代わりに行うものとして捉えられる。数十年前から存在するキーボードエミュレーターが多少高度になったものと考えられ、全く新しい技術ではないが、事務処理を行えるところまで進化させたとところにその価値がある。
技術の基本は画面上のアイテムを認識して（どこに何が出力されているか）、その文字列を取得し、文字に応じた処理を動かしたり、入力フィールドに文字を入力するなどを行うものである。画面がHtmlでできておりcssのタグ（画面上の唯一の名前みたいなもの）を取得できるアプリケーションであればそれを利用してアイテムを認識し、できない画面であれば、画面の座標からアイテムを特定するものがほとんどであろう。このあたりの技術はRPA特有のものではなく、先に述べたようにこれらを利用して、画面を利用した事務プロセス全体をプログラミングできるまで進化させたところにRPAの意義がある。
基本的には、●画面上のアイテムの取得＝＞取得した文字を利用したプロセスの実行、●他のファイルから文字を取得＝＞取得した文字の画面上のアイテムへの入力、●特定のボタンなどを押すまたは新しい画面を開く、などの機能が自動化される。これを繰り返し処理したり条件分岐させたり、また変数に格納し再利用することができるのは通常のプログラムと同じである。
もう一点RPAがもつ重要な機能は、htmlの画面を操作しているときにexcelを開いて、双方の値をやりとりしたりできるという、PC上の複数プログラムのアイテムを同時に認識する機能である。excelマクロを実行し結果をHtmlの画面に入力するということも可能である。
ちなみにWEBの入力自動化はSeleniumインターフェイスによって作り込みが可能である。またExcelのみを利用する事務をRPAでつくる意味はまったくない。excelには強力なマクロ（VBA)があり、これを用いた方が確実に効果があり、さらにSeleniumとの連携も可能だったり、その他のAPI連携もあるので、RPAの導入を考えている方は、このような無料のソリューションを一度は検討してみてはいかがかと思う。
2．RPAのプログラミング
WinActor,UiPath,AutoMate という３製品の実装を行ったが、個人的な感想としてどれが一番よいとおすすめするものというのはなく、ここでは製品間の比較は行わない。excelのマクロのようにユーザー操作を記録して自動化する機能が優れている方がよいという方もいるだろうが、ほぼそれだけで利用できるようになることはなく、ほかのプログラムと同様、プロセスを記述する必要があり、その意味では初心者が訓練なしでできるということはほぼないであろう。
ある程度プログラムを構造化（再利用したり、繰り返しを記述したり）することはできるが、長くなればなるほど（たくさんの画面の処理があるなど）、プログラムも複雑になり、一覧性は失われてくる。（製品ごとにそれをサポートする機能はついているが、RPAもほかのプログラム言語と同様、複雑になると視認性が悪くなる）
画面の動きがわかって、プログラムを見ないと引き継ぎは難しいというのが率直な感想である。（業務要件がわからないとプログラムの意味がわからないのと同じか？）
3．RPAの効果について
特に気になるであろう費用対効果について、開発や保守関連の工数と事務削減効果という観点から述べる。
3-1. プログラム開発工数
RPAのプログラミングは、他のプログラミングよりも開発工数が少ないということはないと思える。やはり変数定義とか条件分岐や繰り返し処理があり、またどちらかというと手続き型のCOBOLのようなプログラムであり、それなりに複雑な構造になり得る。要件の定義から画面の分析、実装、試験に至る工程は他のプログラミングと同じであり、工数に見積もる必要がある。また特筆すべき点は、画面に表示されるエラーのメッセージのハンドリングは、要件の定義時にすべて把握するのが難しいものがあり、試験の工数およびリリース後の修正工数の増大につながりやすい。
RPAのベンダーに開発を委託したが、その場合の工数についても、RPAだから小さいとか大きいとかの印象はなかった。
3-2. プログラム保守工数
もちろん他のプログラムも同じであるが、一度作ったらほったらかしてもよいプログラムはなく、必ず変更が必要となる。OSやブラウザ、RPAプログラム自体のバージョンの変更による対応も必要になるし、もちろん元の画面が変更になった場合でも必要になる。とくにエラーメッセージとか何の前触れもなく変更になることもあり、毎日行う作業であれば、すぐに変更する必要も出てくる。これらの保守をどのような体制で行うかは、会社の規模やRPAプロジェクトの規模、自社開発要員を抱えるか外注するかなどの考え方により異なると思うが、RPAの効果を考える上で無視できない費用であり、これをどのようにコントロールするかによりプロジェクトの成功・失敗が決まるといっても過言ではないと考える。
3-3. プログラムライセンス
上記のプログラムの保守もあるが、この費用も費用対効果を計算する上で大事な費用である。ただし上記の保守のように人件費ではないので割合的には小さいが、開発ライセンスは実行ライセンスよりかなり割高で、保守の体制により費用が大きく変わるので注意が必要である。サーバーでプログラムを集中管理し同時ライセンスを基本とする製品もあるので、体制により最適化するよう考えなければならない。
3-4. 入力データ整備費用など
その他、RPAの主要な機能であるデータの入力補助を最大限に生かすには、入力データをテキストに落とす必要があるため、そのためのＯＣＲなどの周辺ソフトウェアやハードウェアが必要になる場合がある。AI OCRなどになればそれなりの費用になる。ただしこの機能はRPA以外で入力をシステムに置き換える場合にも活用できる。
3-5. 事務削減効果
ここでは、RPAを活用する目的の一つである、事務の削減効果について述べる。もちろんクラリカルワークからの解放とか、ミスの縮減とかの目的もあると思うが、人件費の削減または生産性の大きな向上が見込まれるかが導入の一番の関心事であると考えるからである。
以下にポイントを記載する。
●組織の中の１人や２人の行っている事務をRPA化してもその保守やライセンス料を計算すると費用対効果は限られ、どれだけ多くのスタッフが行っている事務をRPA化できるかが鍵となる。
そもそも、ある程度コンピュータ化されている世の中で、単純なコンピューターへの入力事務とかデータの取り出しのようなものをある人が一日中行っているようなことはないため（書類のチェックとか、仕分け、なんらかの計算等が伴っている）、その中で１人や２人のコンピューター事務をRPA化しても、費用対効果という観点からは効果が薄れる。
●できるだけ一連の作業を区切ることなくRPA化したほうが効果的である。
途中に人の介在があると、処理が正常に終わっているか確認する頻度が高くなるのと待ち時間が増加する傾向があるためである。ただし現在の事務プロセスがそれを困難にしてることもあるので、そのプロセスを変えても全体をRPA化するかどうかは、効果を推測して慎重に行う必要がある。（待ち時間を減らすため、PCにパトランプをつけたり、メールで通知したりという仕組みを導入することである程度改善できる部分もある）
●単に、めんどうくさい・・と思うところをRPA化するようなことで考えでは効果は期待できない。実測して費用計算すると期待するほど効果が出ないことが多い。また先に述べたように、Excelなどを利用しても代替できるものを高価なRPAを利用してやることはない。
●RPA導入前の事務にかかる作業時間を計測し、RPAによりどこが削減されるかを考えることにより、比較的容易に効果予測ができるので、このようなシミュレーションを行った上で、開発や保守との費用との比較を行うべきである。
●私の経験したプロジェクトでも、保守工数等を考えても効果の出ているもの実際にあった。ただしそれなりの工数の開発のものであった。事務に関わる人員の削減というレベルの目標を立てた場合、そのハードルは高くなり、本来のシステム開発とRPAによる開発との比較を、費用面のみならず、開発保守体制、開発のスピード等などから検討して導入するべきものと考える。
4．課題
RPAの課題は、保守であるといって過言ではない。
よく、RPAをエンドユーザーコンピューティングとして、事務作業を行う人またはその組織で開発、保守していくという考え方と、会社の組織としてRPAの部門を作り、集中して開発・保守を行う方法と、どちらがよいかという議論がなされる。
前者のメリットは、よく事務をわかっており要件をまとめるのが容易なことと、不具合があってもすぐに対応ができることである。後者のメリットは、RPAの開発の知識をもったものが集中することにより、開発の生産性が高く、知識の継承を容易に行えることである。
なぜ後者のような考え方が出てくるかというと、１．RPAは誰でも簡単に実装できるというレベルのものではなく、Excelのマクロと比較しても少々難しいものと考えられるため。2.システム開発における障害やセキュリティーの問題を回避するため、教育されたスタッフだけで開発しなければならないため。 3.RPAが操作するもとの画面の動きは、システム部門などが行ってるため、そこと常に意思疎通して変更情報などを共有しやすくしておくため。等が考えられる。
しかし、私はRPAはアジャイル的な発想が基にあるものと考えている。不具合や改善点があったらすぐに自分の組織で対応できることがメリットでありかつ必要条件であり、何か問題があっても開発部門がすぐに対応できずバックログに入ったり、保守するために別途開発者を手厚く用意しておくことなどはRPA導入の目的や効率性を無視することであり、おそらくそれであればRPAを利用するよりも、システムを作り変えた方が中長期的には効果が出るものと推察される。
ただし、自部門で開発・保守するには、スキルの取得と継承が必要となるため、その環境が整えられる場合にのみ積極的に推進することがよいのではないかと考える。欧米のようなJOB型の人事制度が浸透しており、同じ部署にパワーユーザーが長くいるようなところは心配ないのかもしれない。
RPAのベンダーや代理店は、業務効率化、ミスの削減、人員の創造的な業務へのシフトなどの効果を謳っているが、これらはシステム開発の意義とほぼ同じである。かつそれなりの開発や保守の工数が必要でかつイレギュラーな事象に対する対応などもあり、通常のシステム開発と同じまたはそれ以上の課題に直面する可能性もある。
バックログの解消や開発要因逼迫の解消策として考えることもできるが、RPAの開発が進むにつれ、同じよなうな課題が発生する可能性も否定はできない。
最後に
以上事業会社でRPAを推進した立場からの実際的な思いを述べさせていただきました。少しでも参考になれば幸いです。