この５年くらいで急速に注目が集まっている、RPA（Robotic Process Automation /ロボティック・プロセス・オートメーション）。完全にブームが来ています。

特に日本はRPA先進国で、世界のRPAベンダーの売り上げのうち25％が日本市場、単純計算でRPAを導入している企業の４社に１社が日本企業という状況です。AIやIoTは米国が中心ですが、RPAは日本が中心という声も聞かれます。実際、NTTグループのＮＴＴアドバンステクノロジの「WinActor」など、日系企業の製品開発も活発です。

このようにRPAへのニーズが高まるにつれ、注目を集めている職種があります。それは、ずばり「PRAエンジニア」です。今回は、そんなRPAエンジニアについてご紹介いたします。

RPAとは？

RPAエンジニアについて、ご紹介する前に、そもそもRPAについてご紹介いたしましょう。

RPAのRはロボティック、つまり自動化ですが、RPAの本質は「人間がマウスとキーボードを使って操作していたパソコンの操作を、自動的に再現してくれるアプリケーション」です。ただ操作を再現するだけでなく、プログラミングやAIを組み合わせて“既定を満たす数値のときは［OK］をクリック、満たさないときは［却下］をクリック”といった動きを付けることも可能です。

日本でRPAは流行するきっかけになったのは、メガバンク三行が相次いでRPA導入成果を公表したことです。銀行では“間違いなく処理”していくことがもっとも重視されます。お金を扱う以上、正確無比な業務が求められるのは当たり前ですよね。

とはいえ、どれだけ気を付けていても、人間は失敗する生き物です。そこでヒューマンエラーを防ぐ仕組みとして、RPAが注目を集めたのです。

銀行業界第４位のりそな銀行では、一歩進んでRPAとリンクするロボットアームの導入を行っていることが明らかになっています。従来、PRAに伝票などの紙資料を読み込ませるのに、人間がスキャナー（OCR）の操作をする必要がありましたが、このロボットアームのおかげで、その作業も自動化し、まったく人手を必要としないRPAを実現できるとのことです。

金融機関以外でも、「繰り返しエクセルの出力結果を加工する」だとか「経費申請を許可または却下する」など日々の定型業務の負担を減らす特効薬として、各業界で導入が進められています。

RPAエンジニアとは？　どんなスキルが必要？

RPAについて理解できたところで、いよいよRPAエンジニアについて説明いたします。RPAエンジニアとは「RPA導入・構築・運用に特化したエンジニア」です。

RPAも結局のところ、一つのシステムです。他のシステム、例えば、androidアプリの開発や、お店の会計ソフトの導入と、RPAの導入との間でプロセスの違いはありません。そのプロセスは以下の通りとなります。

①クライアントの話を聞いて、どういうRPAにするのか考え、要件定義（基本方針の確定）をします。

②要件に合うように設計します。

③設計内容に問題がなければ、実際に作ってみます。

④作成後、テストをしてみます。

⑤テスト結果に問題がなく、お客様とも合意できれば納品します。

⑥必要に応じて、納品後、お客様が使っていく中で、なにかあればサポートします。

このようにプロセスに分けて考えると、RPAエンジニアのスキルは、次の3つと言えそうです。

A）クライアントがどういう課題を抱えていて、RPAでどういう風に解決できるか考えるコンサルティングスキル。

B)実際にRPAを開発するテクニカルスキル。

C)クライアントが実際に使っていて感じた疑問や課題に応えるサポータースキル。

未経験でもRPAエンジニアになれる？

「IT業界未経験でもRPAエンジニアになれるか？」というと、もちろんなることができます。

今どきのRPAは、キャプチャ機能（人間が実際にパソコンを操作し、その動きを記憶させて再現させる機能）が搭載されているなど、ITの専門職ではなくても、ある程度のRPAが作れるようになっています。

実際、銀行業界で第5位の三井住友信託銀行のRPA導入事例に、「現場の裁量で自由にロボットの開発を進めると、野良ロボットが生まれて業務品質が劣化してしまう。」という一文があります。とりあえず作るだけなら、ITエンジニアではない銀行員でもRPAが作れるのです。

もちろん、高品質なRPAを作れるようになるためには、プログラミングスキルが必要ですが、それよりも重要なのは、コンサルティングスキルです。

AIにも言えることですが、RPAの評判だけが独り歩きしていて、クライアント側から「無茶ぶり」と言える要件が提示されたり、クライアントの要求通り作ってみたものの「思っていたものと違った」と言われることがあります。

また、現在、人間が行っていた業務フローをそのままRPAに落とそうとして無理が出て破綻した、コストをかけた割に思ったような成果が出ない、という指摘は、RPA導入の失敗事例分析で繰り返し聞かれるフレーズです。

先ほど、「りそな銀行ではロボットアームで紙資料を読み込めるようにした」という事例をご紹介しましたが、最初から紙ではなく電子で資料を作れば、わざわざロボットアームの設置は不要ですよね？　このように業務プロセスの見直しを行うことで、より素敵なRPAが作れますし、逆に見直しをしないままRPAを作ると高コストで不完全なRPAができがちです。

それから、イレギュラーは発生したときの対応について、どこまで作り込むのかも重要です。業務をしていて、「これ、おかしいな」と気が付いたとき、人間ならば、その場で考えて適宜適切な動きをする、ということができますが、RPA単体ではそれができません。

乱暴に「イレギュラー発生時は、動きを止めて担当者に通知する」でも良いですが、通知がたくさん届いて自分の仕事ができないのも困りますよね。だからと言って、「こういうパターンは、こう処理する」と、考えられるイレギュラーパターンすべての対応策を作るのも、コストがかかり過ぎです。

このような“RPA運用にあたって考慮するべきこと”にも気が回せることがRPAエンジニアには重要なのです。業務の進め方が理解できるという意味では、むしろ、これまでITエンジニアではなかった人の方がRPAエンジニアとして成功するかもしれません。

RPAエンジニアの将来性は？

すでに日本はRPA先進国と言えますが、人口減少による労働力不足の解決策や生産性向上の切り札としてRPAが注目を集めており、RPAエンジニアのニーズは、当面、高まりそうです。

ただし、RPAは業務の属人化ならぬ、属RPA化、つまり「RPAが良い感じに処理してくれているけれど、どう処理しているか、社員は誰も分からない」という事態に陥る可能性があります。

欧米ではさらに踏み込んで、「処理の流れが分からなくなるということは、それ以上の業務改善が難しくなり、結果的に将来の進化の芽を摘み取るリスクもある」という否定的な見方が存在しています。この見方が原因で、RPAが日本ほど流行っていないのです。

今後、日本でも欧米のようなRPAに対する否定的な見解が広まる可能性は否定できません。とはいえ、現在のところ日本国内において、そのようなRPAに否定的な論調はなく、RPA導入を進めている企業が多数です。

非常に、将来性のある職種と言えるでしょう。

まとめ：RPAエンジニアはコンサルティングスキルが重要

繰り返しになりますが、良いRPA、高品質なRPAを作るためにはITのテクニカルスキルはもちろん重要です。しかし、それ以上に、RPA導入によって業務プロセスをどのように更新するのか、一歩踏み込んだところまで考える必要があります。

つまり、RPAエンジニアにはコンサルティングスキルがとても重要なのです。