また同じ失敗を繰返そうとしている会社が実に多いようです。過去のEUC（エンドユーザ・コンピューティング）ブームの時もそうでした。単にノーツやExcelマクロの書き方を派遣会社で習っただけの派遣社員に現状業務の自動化を片手間でやらせようとして本人も苦労しています。
単に「ツールの初歩的な使い方を習った」派遣社員が一人二人いても、RPA化すべき業務を整理しプロジェクト全体をリーディングしていく事などまず不可能でしょう。そのアプローチが無理なことは既に結論が出ていることなのです。
RPAプロジェクト失敗の原因
最近RPA導入プロジェクトの事例も増えてきた事で、失敗に繋がる様々な課題が見えてきました。その様な共通するプロジェクト失敗の原因はこちらでご紹介しています。
要は、RPAは「ツールとしての使い方が簡単」を「導入が簡単」と混同し、多くの企業が折角RPAツールのライセンスを購入したにも関わらず、（派遣社員を含む）担当者に丸投げ、任せっきりで「出来たところまで」になってしまいます。
RPAの場合、それなりの範囲で自動化しようとするとどうしても（会社）組織横断で業務を整理し、RPA化する対象業務を切り出していくビジネス設計が必要となります。どう考えてもRPAツールの使い方を派遣会社で習っただけの派遣社員には荷が重すぎます。
どうして派遣社員のRPAプロジェクトは失敗するのか
プロジェクトをリードする人間が不在
日本のIT絡みの契約形態には、準委任契約／請負契約／派遣契約の３類型があります。詳しくはこちらを参照頂くとして、
派遣社員に何かをお願いすると言うことは、あくまで「派遣先（＝ 自社）のプロジェクト指揮命令の元、派遣社員が単に指示通り作業をする」ことを意味します。自社でRPAに関する十分な知識・プロジェクト経験があるのであれば、このアプローチで機能するのだと思います。
しかし殆どの場合、自社内にその様な知識・経験もなく、お願いした（RPAツールの使い方は一通り習った）派遣社員に丸投げで、自社の社員は殆ど関与せず、RPAツールの使い方も理解していないまま進めようとされているようです。
業務整理が出来ない
上でも書きましたが、RPA導入によって業務を自動化・効率化することで一定の成果を出していこうとすると、どうしても業務整理や組織設計といったビジネス設計が必要となってきます。ここにも、単にRPAツールの使い方を習っただけの派遣社員では進められない原因があります。
◆ 高い視座と広い視野が要求される
派遣社員の方々の多くは、実際の事務作業現場で実務をやっていますので、現場でどの様な（手）作業が発生していて大変なのかはよくご存じなのだとは思いますが、ご自身が関連された（狭い）範囲しか見えていませんので、どうしてもその狭い範囲内の考えに留まってしまいます。
やはり、RPAツールのライセンスを購入した以上の業務効率化の効果を出そうとすると、業務（組織）を跨いだ視点で全体を見渡して業務プロセスを整理していく必要があります。
◆ 業務（プロセス）設計は経験が求められる
RPAの導入プロジェクトをやっていて最近つくづく思うことがあります。「昔殆ど同じ様なプロジェクトをやっていたな！」と感じてしまうのです。よく考えると、それはERPを導入するのと同時に行っていた「間接業務集約化」プロジェクトです。
組織（関連会社を含む）横断で間接業務を棚卸・整理し、纏めていくアプローチ・アウトプットなど、今考えると殆ど同じなんだなとあらためて実感しています。
業務を幅広く理解し、全体を見回して同じ業務を整理していくことは、確固としたメソッドもなく単に「RPAツールの使い方を一通り習った」派遣社員にはハードルが高いのではないかと思われます。
◆ 派遣社員に派遣の仕事を無くすことは出来ない
これもよく言われることですが、誰しも失業したくは無いわけです。社員であれば、「自分がいなくても自分の仕事が廻るようにするのが仕事だ」と昔上司に言われてなるほどな、と思っていましたが、身分が保証されていない派遣社員に「自分が要らなくする」ことが出来るでしょうか？（どんな名外科医でも自分の腹は切れない）
数名働いている派遣社員の半分を不要にして自分はRPAの管理者として残る、と言うのであればまだ何となく理解できますが、「今後はRPA一本でやっていく」覚悟が出来ている派遣社員がどれだけいるでしょうか。
幅広いITの知識が要求される
この点も気になる部分です。RPAツールの使い方だけをよく知っていても十分ではなく、自動化する対象のITツール（アプリケーション）についての知識が必要になります。そして、その殆どは業務アプリケーションですから業務に関する知見が無ければ容易に理解出来ないものも多いかと思います。
メール（Outlookやノーツなど）やExcelなどに関しては殆どの方が使ったことがあるかとは思いますが、MS Access やOracleなどのデータベース、ルーターやスイッチ等のネットワーク関連機器、それらの通信プロトコルなどに関してもある程度理解していなければITの方の協力が必要にもなります。
RPAに関する知識・経験の蓄積・共有がない
派遣社員の方々の殆どは一人か二人単位で派遣元から派遣されているかと思います。特にRPAツールの使い方を習得したような派遣社員を最初から大量に依頼する会社は殆どないかと思われます。
ここで、本人が実際どの程度RPAプロジェクトの経験があるか判りませんが、使い方が簡単だと言われるRPAツールに関してもやはりある程度の経験・知識の蓄積が必要になってきますし、Excelマクロのように世界中で使われ一般化した言語と違いRPAの場合まだ技術情報が十分流通していません。
SI会社やコンサルティング会社であればそれなりにRPAナレッジを蓄積し、本人が解らない事が有ったとしてもバックサポートする体制を整えているのが通常です。しかし、恐らく派遣会社では元々その様な発想は無いでしょうし、実際に現場でIT導入プロジェクト指揮したことがある人もいないでしょう。その様なコストも掛けられないと思われます。
そのような、バックアップ体制も経験も無いまま一人で現場に行かされ、RPAの専門家として進めなければいけない当の本人も大変です。
まとめ：失敗しないRPAプロジェクトの進め方
やはり、対象が何であれプロジェクトは進め方・リーディングが最も重要となります。そして、その進め方やプロジェクトをドライブしていく体制などを最初に定義するのがプロジェクト計画です。
通常、どの様なプロジェクトであってもプロジェクトの成否は８割がたプロジェクト計画で決まると言われています。
それは、どの様な体制（要員）・スケジュールで、どの様なアプローチで進めるのか、達成目標とその時期等ということであって、決してRPAツールを使える派遣社員を何人依頼するかといった事ではありません。
