RPA導入後、エンジニアをどう選定するべきか【エンジニアは兼任でも問題無し】

choice_picture

こんにちは、佐藤です。
現役RPAエンジニアとして働いています。

今回は実際にRPAを導入した後の話をしたいと思います。
導入後の体制について様々な成功と失敗事例を見てきましたので、何かしらの参考になれば嬉しいです。

まず結論から。RPAエンジニアを誰が担当すればいいのかについては以下になります。

  • 必ずしもITリテラシーが高い人間が担当しなくてもいい
  • 自動化する業務の担当者がRPAでロボットを作れるようになるのが望ましい
  • 専任のRPAエンジニアを任命または新規採用しなくてもいい【兼任でも社内業務のロボット化は進む】

ただしこれには前提条件があります。というのも、よくありがちなパターンとして、

  1. RPAを導入する
  2. 情報システム部署が取り扱う
  3. 思ったよりも自動化する業務が少ない
  4. 結果、いつまで経っても効果が出ない

というものがあります。

まず最初に言いたいのが、誰の何の業務を自動化しようとしているのか考えてほしいということです。

例えば読者の方が所属している企業にRPAを導入したとして、突然経営者または上司から、

『今日から業務を自動化するツールを導入した。自動化は情報システム部がやるから、お前は自分の業務を洗い出して、自動化出来る業務は全てRPAにやらせろ』

と言われたらどうしますか?

少なくとも私なら、協力的な対応はとれないと思います。理由としては、

  • 自分の業務は機械で出来るほど単純なものではない
  • そもそも、自分の業務を知られてあれこれ言われるのが嫌だ
  • 情報システム部(RPAエンジニア)からのヒアリングが面倒くさい
  • 仮に自動化出来たら自分はどうなるのだろう

こんなところです。極端な話、自分にメリットが見出せなければ社内的な取り組みだとしても関わろうとしないでしょう。

それによって給料が上がるわけでもないし、職位が上がるわけでもありませんしね。

そもそも『仕事がRPAとやらに取られる?』とも考えてしまえば、むしろ否定的にもなるでしょう。

もしRPAの導入について事前に社内説明がない、または誰か(主に経営層)の一存で決まったのであれば、上記パターンに陥りやすいです。

つまり、誰をRPAエンジニアとするかではなく、そもそもRPAを導入するメリットについての説明をしなかったことによる失敗です。

誰がエンジニアになろうがRPA導入は失敗に終わります。この記事はあくまで、

  • RPAはあくまで単純作業を自動化するツールである
  • 単純作業をRPAに移行した後、その人用にクリエイティブな仕事を用意しておく
  • 今後RPAを企業としてどう活用していくのかきちんと説明する

などの取り組みを行い、RPAに対してポジティブになっている前提での話となります。

それでは前置きが長くなりましたが、本題に入っていきます。

必ずしもITリテラシーが高い人間が担当しなくてもいい

専門性の高いRPAは別として、RPAは基本的にノンプログラミングツールとなります。

プログラミングなどの知識がない人間でも、ある一定レベル(そこそこ難しい構築も可能なレベル)のロボット構築が可能です。

これは純然たる事実ですし、実際に私はプログラミングなどの知識はありませんが、RPAエンジニアとなって1年半程度経っており、100体以上のロボット作成に成功しています。
※そもそも私は、販売職→管理職→営業職→RPAエンジニアという、プログラミングとは無縁の経歴からRPAエンジニアになっています。大学も工学部なのでプログラミングとは無縁です。

勿論、ITリテラシーは高く、プログラミングスキルを持っている人の方がRPAスキルを習得するスピードは早いです。これもまた純然たる事実です。

しかしそれはRPAエンジニアになるための絶対条件ではありません。

PRAエンジニアに任命する大切な要素は、RPAを活用して業務を自動化するという意欲を持ち、新しい知識を学ぶことに抵抗がない方を選ぶということです。

スキルの伸ばし方については前回の記事で触れているので、まだの方はこちらも参考にどうぞ。

自動化する業務の担当者がRPAでロボットを作れるようになるのが望ましい

これは何故かというと、自動化しようとする業務のことを一番良く知っているのがその担当者だからです。

逆を言うと、その担当者でなければ分からないことの方が多く、その状態でRPAによる自動化に着手したところで、大したロボットは作れないとも言えます。

突然ですが質問です。

読者の方が会社で異動になり、前任の担当者から業務を引継いだ時、円滑に業務が行えるようになるまでにどれぐらいの期間がかかりましたか?

分からない、または引継ぎ時に教わっていない場面があれば、前任の方に聞きに行きますよね。

それと全く同じことがロボット作成時に発生します。

RPAエンジニアが自動化する業務の担当者ではない場合、まずはその業務についてヒアリングを行います。その内容をもとにロボットを構築して運用した場合、ほぼ100%エラーが発生します。

理由は前述した業務の引継ぎと同様、教わっていない場面にロボットが遭遇した場合、適切な処理が出来ないからです。

つまりこの場合、

ヒアリング~ロボット再構築のサイクル

という流れになり、ロボットがエラーを吐き出さなくなるまでにかなりの時間と労力が割かれます。

これこそが、自動化する業務の担当者がRPAでロボットを作れるようになるのが望ましい理由となります。

専任のRPAエンジニアを任命または新規採用しなくてもいい【兼任でも社内業務のロボット化は進む】

これについては、前述した、

  • 必ずしもITリテラシーが高い人間が担当しなくてもいい
  • 自動化する業務の担当者がRPAでロボットを作れるようになるのが望ましい

この2つの意味を理解していただければ答えが出ると思います。

既存社員をPRAエンジニアとして専任にしても、外部から新規で採用したとしても、ロボット化する際のヒアリングからエラーを吐き出さないまでの道のりは長く、多くの時間とコストが発生します。

それよりは、簡単なロボットを作れるようになるのに時間がかかっても、兼任でRPAエンジニアになり、自身の業務を自動化する方が総合的に時間とコストの削減が出来ます。

1人より2人、2人より3人の兼任PRAエンジニアが創出できれば、業務のロボット化のスピードは早くなりますし、何よりもRPAエンジニア同士がロボット構築の知識を共有していけば、RPAエンジニアとしてのスキルは更に加速していきます。

或いは専任のPRAエンジニアを置くよりも高い効果を上げる可能性があるこのやり方は、注意するべき点として、成功するハードルは高いということです。

兼任でRPAエンジニアになるのは、根気と努力が必要ですので、挫折しないためのフォローを手厚くするといいかもしれませんね。

最後に

自動化したい業務量に対し、企業には人的リソースも予算も限られています。

ここまで説明しておいて何ですが、仮にRPAを導入したとして、RPAエンジニアはどのように選定したらいいかの模範解答はありません。

当記事はあくまでヒントとして受け止めていただくことを推奨します。

また、これからもRPAに関する何かしらのヒントを発信していく予定ですので、お付き合いいただければ幸いです。

それでは、ここまで読んでくださりありがとうございました。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です