RPAエンジニア不足のニーズに応えるべく、RPAエンジニア派遣サービスを行っているパーソルテクノロジースタッフは、現在67社に対し130名を超えるRPAエンジニアが就業中という実績を持つ。専門的知識を有するRPAエンジニアによるプロジェクトのサポートはもちろん、社内の開発体制の強化なども支援する。同社のRPA推進部 鈴木規文氏によると、RPAに求められるエンジニアはプロジェクトによって2種類あるという。それが、「運用・改善タイプ」と「システム開発タイプ」というパターンだ。

鈴木氏によると、小中規模・単一部署のプロジェクトに向くのが「運用・改善タイプ」で、既に使われているExcelやマクロを見直しながらRPAと連携するタイプのプロジェクトに適しているという。このタイプの人材としてはVBAやマクロ改修の経験者が適しており、RPAツールとしては主にデスクトップ型が多いという。

対して、大規模・複数部署間のプロジェクトに向くのが「システム開発タイプ」で、基幹システムとの連携や複雑な条件への対応が求められるRPAプロジェクトが該当する。このタイプはSEやプログラマなどプログラム開発経験を有する経験者が適しており、RPAツールはサーバー型が多いとした。

自社の内製が「追いつかない」「難航する」ときの解決策とは

続いて、鈴木氏は実際の企業事例を紹介。「運用・改善タイプ」の例として、大手金融企業がRPAの運用・追加開発フェーズで取り組んだ人材活用の事例を取り上げた。同社はコンサルティングファームの支援のもとRPA導入を推進していたものの、最終的には自社の社員で内製し、運用することを決めていた。ところが、そこで予想外の壁が立ちはだかった。自社社員の開発では追い付かなくなってしまうほど現場から開発リクエストが来てしまったのだ。

この段階ですでにRPAの骨組みはあったため、ゼロから開発する必要はなかったという。そのため、現場が使っている帳票やVBA、マクロ、Accessに強い「運用・改善タイプ」の人材を派遣。「自社社員の業務知識と外部人材のRPAや既存ツールの開発・修正力を合わせることで、運用体制の強化が実現した」と鈴木氏は語る。

「システム開発タイプ」の例としては、RPA推進体制を強化した大手メーカーの事例を紹介。同社は人事部門とシステム部門が共同で働き方推進を行い、外部人材を活用してRPAの導入を進めていく予定だった。しかし、当初想定していた外部人材ではシナリオ作成が難しく、開発が難航してしまったのだという。これは、現場のリクエストを踏まえて設計した際に、業務変更やエラー時の対応を踏まえた、応用的なロボット作成が必要となったためだ。

そのような状況に対し、「システム会社において大規模開発を経験しているエンジニアでないと難しいと判断した」と鈴木氏。「システム開発タイプ」のエンジニアを派遣することで同社が定めているRPA開発標準や設計を理解した上での開発が進み、今後の業務変更も見据えたRPA化が実現した。

鈴木氏はこれらの2つの事例を踏まえ、「自社で求められるRPA化の範囲や自社社員のスキルを考慮の上、外部人材を活用する際にどちらのタイプがフィットするのかを考えていただきたい」と語った。

RPAの社内運用に欠かせない「現場で使えるガイドライン」を作成する３つのポイント

外部の人材での体制強化も心強い方法だが、長期的な視点で見れば社内にノウハウを蓄積させていくRPA運用体制の強化も考えていきたいところだ。

RPA導入コンサルティングやRPAロボットの設計・開発・運用サポートを行う豆蔵のIT戦略支援事業部 第1グループ コンサルタントの中山尚子氏は、RPAの導入に関する課題に対し、解決の勘所は2つあるとした。1つ目は「RPAを正しく使うこと」であり、2つ目は「共通ライブラリーやノウハウのアセット化」であるという。

株式会社豆蔵 IT戦略支援事業部 第1グループ コンサルタント 中山尚子氏

「RPAを正しく使うこととは、“正しい箇所への正しい適用”ということ。でないと、かえって無駄が生じることになります」と同氏は語る。さらに「共通ライブラリーやノウハウのアセット化」については、社内にスキルを蓄積し、自社で継続してRPAを活用していくために欠かせない対応であるとした。

中山氏は、このいずれにおいても「専門家の手を借りる」ことで時間の節約が図れると語る。「とはいえ、専門家に“丸投げ”のような依頼をするだけではRPA化は進まず、社内にブラックボックスを増やすだけになりかねません。運用までを含めた長いスパンでの効果を出すには、自社主導であることが必要です」と、社内人材を育てながら外部リソースを利用することの重要性を説いた。

そして実際に、同社の専門家によるガイドラインの作成支援によってRPAのスムーズな導入が実現した某システム機能企業の事例が紹介された。その企業では、当初、他社の専門家にガイドラインを依頼したものの、その内容が自社の業務内容に即していない抽象的な一般論のみであった。そのため「具体的に何をしたらいいのかよくわからない」と現場でのRPA導入に滞りが生まれてしまったのだという。

この事例に対し同社は、「現場で使える」ことを重視したガイドラインの再構築を実践した。その「現場で使えるガイドライン」のポイントとして、中山氏は以下の3つを挙げた。

• それぞれの会社組織に応じた役割を設計する
• 迷いなく実施できるように、テンプレートなどを用いた具体的な手順をまとめる
• 開発、設計時につまずく要因や、運用プロセスで問題になりがちな点を“先読み”して対応をまとめる

中山氏は「実際の業務は社員でないとわからない」と「専門家への“単なる”依頼」でなく自社主導で依頼することの重要性を、ここでも強調する。その上で、「自社で業務フローを整理した上で、RPAの特性を活かしたToBe業務策定（業務のあるべき姿の策定）や、自分達ではできないと判断したRPAの開発や知識の習得について、自社主導で外部リソースを活用することが、高い品質でのRPA化を効率よく実現する近道です」と語った。

両社は、パーソルテクノロジースタッフのRPAエンジニアの人材提供力と豆蔵のコンサルティングの実績を活かし、これからRPAを導入する企業向けの「RPAアセスメントサービス＋RPA体制支援」、RPA導入中企業に向けた「RPA診断サービス＋RPAエンジニア派遣」により、“現場でRPAを使い続ける”ための支援を、今後とも強力に推進していく。