実録！RPA内製化のすすめ（前編）

TAG
UPDATE
2019/12/03

内製化の背景
RPA技術者研修開催へ
研修受講者の反応はいかに？！
RPAコンサルタントの役割
関連記事

皆さん、こんにちは。急激に寒さが身に染みる季節になりましたが、お風邪など召されていませんか？

今回はRPAの「内製化」の実現可能性について、実例の取り組みをベースに検証してみたいと思います。

話はとあるお客様先A社での出来事から始まります。

そのお客様先においては、トップダウンで試行錯誤しながら、RPA導入を進めてきました。しかし、２年間の導入推進を経た最近において、ユーザ部門のIT化推進リーダー役のMさんからエンドユーザによる「内製化」の要望の声が上がってきました。

確かに、昨今の地方自治体におけるRPA導入レポートにも、職員主導による「RPA内製化」の試みがチラホラ見受けられます。

内製化の背景

A社の「内製化」検討の背景については、以下が挙げられます。

高額な開発費用。RPAを導入するためには、ベンダーの開発費用のみならず、膨大な運用費がかかります。また、最近は下落傾向にありますが、RPA技術者の単価についても軽視できません。

　→　費用対効果を高めるためにはどのような工夫が必要かどうか、Mさんは考えていました。

思ったよりも安定稼働しないRPAの性質。RPAは導入資源に同居しているシステムの影響を大きく受けます。例えば、OS、Office、操作対象システムのバージョンアップ。動作しなくなる都度、RPAエンジニアに改修見積りを依頼している実態であり、ユーザ側のRPAに対する期待感も薄れている状況。

　→　継続して運用してゆくためには、ユーザ側のRPAに関する知識・理解を深める必要があることを、Mさんは実感していました。

大きいのは世の中の流れ。人口が減少してゆく中、企業にはDXを駆使して合理化や自動化できる業務について、整備を進めていく命題がありました。

　→　コンサルタントやエンジニア任せではなく、あくまでユーザ主体であることが成功の必要条件であることにMさんは気づいていました。

RPAを内製化できないかどうか、また、どのようなプロセスを踏むとRPA内製化が上手く浸透してゆくか、Mさんから相談を受けた私は、ユーザ部内の状況を鑑みて、RPAの技術者研修の提案をし、その開催に漕ぎつけました。

RPA技術者研修開催へ

RPA技術者研修のメニュー策定のポイントは以下の３点になります。

研修題材は、製品が提供している教材ではなく、ユーザ部が利用している基幹システムの操作をベースに作成。また、研修完了後には受講者が作成したRPAが実運用できることをユーザメリットとして付加。

　　→ ユーザ自身が作成したRPAが実運用されるという体験を通して、自ずと最終的には保守運用をユーザ側で行っていくことを想定。

あらゆる知識をあえて網羅しすぎない。あくまで題材を通して、利用する主要アクティビティとその実装のみを解説し、後はユーザの好奇心に委ねる。

　　→ ユーザの中にあるエンジニアとしての種を引き出し、植え付ける。知らないことは星の数ほど出てくる。ユーザ自身が調べて解決する癖をつけられない限り、内製化への道は険しい。

いかにシンプルなRPAを作成するか。例えば、極端な話、基幹システムの操作のみに限定。または、極力、カウンター変数などを不用意に利用しなくてよいように周辺ファイルを整備。RPAで実装しなくてよいものについては、その他（基幹システムやマクロ）に任せる。

　　→ ユーザはそれぞれの職種の実務担当者であり、エンジニアにはなりえない。エンドユーザが出来ること出来ないことの棲み分けを明確に。

様々な課題を解消しつつ、RPA技術者研修会が全５回で開催されました。

研修受講者の反応はいかに？！

研修の受講者は７～９名であり、システム部門でもなくシステム経験のない事務方の女性が中心となりました。立ち上がり、自分たちで簡単なRPAを構築し、自動で動くことに体験し、感嘆の声が飛び交いました。また、一方で、研修の終盤に向かうにつれ、安定して動作させることの難しさも痛感しているようでした。

まずまずの反応で５回の研修会は無事に終わりました。そして、最終フィードバックの面談の際、研修会において一番呑み込みの早かった一人の受講者が遠慮がちに言いました。

「…RPAでできることはよく分かりましたが…現状業務で適用できそうなものがありません。」

彼女が言うには、現状業務においては、個別対応が多く、一つ一つのオペレーションに対する一般化・定型化・ルール化が思ったよりも難しく自働化に適さない、というのです。それを聞いたMさんの顔に、内製化に舵を切ったことへ後悔がうっすら見受けられました。

RPAコンサルタントの役割

さて、私達の出番です。RPAは３段階の進化を遂げていく、と言われてきました。真の意味で進化を遂げられるよう推進してゆくためには、RPA化の前に、まずは細切れとなっているユーザの手元業務をつなぎ合わせ、一般化により近づけることが必要です。

「RPA化は実現できました。」しかし、業務の掘り起こしと整備が不十分なままRPA化を行い、効果が得られず、次の段階に踏み込めずにいる企業はまだまだ多いのではないでしょうか。

局所的にRPA化を実現しても効果は得られない。技術支援や構築することのみならず、その効果を最大限にするために、RPAに適した業務の掘り起こしを行い、前段の業務整備を提案する。それを、顧客の事情や意向に沿った形にサイジングし、適用範囲拡張の可能性も鑑みつつ、継続的に支援していくことがRPAコンサルタントの役割の一つです。

「内製化」そのものの方向性は、企業内の業務合理化に向けた一つの選択肢であり、今後、増えていくことが予想されます。私達の役割も、業務コンサルタント寄りにシフトしてゆくことを再認識した出来事でした。

「内製化」のその後において、Mさんのとった行動とは？！後半へ続く。。。