RPAの導入では、開発チームづくりが重要だ。RPAを適用する業務の特性などから、開発チームに求められるスキルを見極めよう。さらに、円滑に開発・運用を進めるためには、ユーザー部門など関係部署との役割分担を明確にし、全社的な推進体制を構築することが不可欠だ。
連載の第5回目となる今回は、第1回の連載で典型的な失敗パターンの1つとして紹介した「開発チームづくりに失敗」した事例をいくつか紹介しながら、失敗の原因について説明します。そして、この失敗を回避してRPA（ロボティック・プロセス・オートメーション）導入をスムーズに進めるためにはどのようにしたらよいのかについて解説します。
RPA導入では、ツール評価や選定、特定部門でトライアルを行う「準備フェーズ」、そして全社へ拡大する「展開フェーズ」と大きく2つの段階があります。今回は、その中でも特に問題が噴出しがちな「展開フェーズ」を中心に解説します。
準備フェーズでは試験的にRPAを導入するため、対象となる部門も業務も限られていました。問題が発生してもなんとか人海戦術で対応することで乗り切れます。しかし、展開フェーズでは、関係する部門や対象とする業務の数が格段に多くなります。RPAの接続先になる業務システムも多くなることから、問題が噴出し失敗してしまうケースが多く見られます。開発チームづくりに失敗した2つの事例を紹介します。
ユーザー部門の参画意識を高められない
ある企業では、IT部門主導で開発体制を整え、スタッフ系のA部門へ適用することになりました。A部門にとって、RPA導入は初めての試みでした。IT部門の担当者は、ユーザー部門の担当者から現状の業務についてヒアリングし、システムの操作手順を確認しました。その上で、RPAの対象範囲やロボットの動作シナリオを書面で確認しました。さらに、ユーザー部門の担当者のレビューを受けた上でロボットの開発に着手しました。
ロボット開発が完了し、ユーザーテストを実施したときに問題が起きました。ユーザーと認識の食い違いが判明したり、追加の要望が多発したりしたのです。結局、要件定義フェーズからやり直しになりました。
この失敗は、ユーザーの参画意識を高められなかったことに原因があります。RPAを初めて導入する部門のユーザーは、RPAに対する理解が足りなくて当然です。「RPAって言葉はよく聞くけれど実体はよくわからない」「結局、RPAでどのようなことができて、具体的に自分の業務のどこが変わるの？」など、RPAに対して不安を抱いていることもあります。また、「トラブルなく導入できて当然だろう」と考えるユーザーもいます。
ユーザー部門は通常の業務を抱えながらプロジェクトに入ることが多いので、参画意識が低いケースが多々あります。限られた時間の中で打ち合わせやレビューに参加しているので、ドキュメントを中心に意思を確認しようとしても、コミュニケーションの不足による認識の違いが発生しがちです。
このような状況で、ユーザー部門のRPAに対する理解を促進し、RPA開発でユーザー部門と協業体制を構築するにはどんな対策が必要だったのでしょうか。その1つの手段として、要件定義、あるいは開発の早い段階で、正常系の動作のみをパイロット開発し、RPAが動作するデモを見せる、というやり方があります。実物のRPAを見てもらい、具体的にイメージしてもらうのです。こうして認識の違いを早期に解消することがとても大切です。実際に動く状況を見ることで、ユーザー部門の担当者の参画意識が向上する効果もあります。
