具体的な推進方法について記述する前に、まずはRPA推進のベースとなる考え方と本質について触れておきたい。筆者は、RPAは会社として取り組むべきだし、取り組む価値があると考えている。

その第一の理由だが、RPAベンダーはよく「RPAの開発は簡単」と説明するが、これは「(とりあえず作るのは)簡単」なのであって、何も考えなくて良いというわけではない。RPAを本気で導入しようと思ったら考えなければならないことは無数に存在する。

RPAは目に見えないソフトウェアとしてパソコンにインストールされ、現場のユーザーが使い、なおかつ開発が簡単と言われているので、その本質に反してライトに見られてしまう傾向がある。ただ、そもそもRPAは従来のソフトウェアのように何か既存のソフトウェアの代わりに導入するものではなく、あくまで人間の業務を代行する新しい労働力としてとらえるのが正しい。つまり、RPAは、「IT」「人」に次ぐ、「第三の経営資源」と考えるのが、RPAの正しい本質の捉え方だといえる。人材管理に人事部、ITに情報システム部門が存在するように、ITでも人でもないRPA(ロボット)には、RPA推進体制が必要になる。また、業務をRPAに代行させた後、人に何をやってもらうか、会社の経営方針とリンクした人材戦略を検討する必要も出てくるだろう。RPAの本質は、部や課の枠を超えている。よって会社として取り組むべきである。

第二に、RPAの推進には、現場発信のボトムアップ型と、社長からRPA推進の指示が下るトップダウン型が存在するが、結論から言うと、「最終的にはトップダウンとボトムアップの両方が必要」と考える。その理由を示すために、もし極端にどちらか一方に偏った推進をした場合、どういう問題が出てくるかを考えたい。

まず、完全にボトムアップにした場合、以下の問題が発生する可能性が出てくる。

• 現場が自分たちでできる範囲の業務の自動化しか出さず、取るに足らない成果しか得られない
• 現場担当が空いた時間を使って、片手間で自動化する場合、成果が出るまで時間がかかる(RPAは現場にとってやってもやらなくても現状維持になる場合、本業を優先して後回しになる可能性がある)
• ナレッジの共有や自動化ルールの統制が取れないので運用時に問題が出る

逆に極端なトップダウンで推進した場合に発生する可能性がある問題は以下となる。

• KPIを達成することに囚われすぎると、現場が望まない自動化が行われ、最悪、現場でロボットが使われない、または逆に現場の仕事が増えて、見せかけの成果に終わる

つまり、RPA推進には会社の後ろ盾と、自動化して楽になりたい、もっと重要な仕事に集中したいという現場の想い、の2つが必要だと考える。会社としてRPA推進の旗振りを行うことで、RPA導入の方針やゴールを設定しRPA推進体制をバックアップしつつ、現場もRPAの推進に深くかかわり現場の意見や要望を反映しながら推進していくことが、RPA導入効果を最大化する方法だといえる。

以上、2つの理由からここで言いたいのは、最終的には会社を巻き込んで会社として取り組むべきである点であるが、ただ、これを読んでいる読者の方が、RPA導入を考えている現場の一担当者であっても心配はいらない。現場から始めて最終的に会社を動かす方法をステップごとに後述していく。すべてを一人でやる必要は全くない。RPAの本当の価値を理解してもらえれば、いっしょに導入に取り組んでくれる仲間を増やしていくことは可能だ。RPAにはそれだけの魅力がある。

自社開発サポートも、開発をお任せ頂いても

RPA開発・保守サービス

UiPath、WinActorの開発・保守・サポートのための【RPA開発／サポートサービス】。15時間からの時間制サービスになっており、自社開発（内製化）するお客様は開発サポートデスクとしてご利用できます。

RPA開発／サポートサービスはこちら