どうもmizukiです。RPA案件がほぼリカバリーの見込みがないくらい泥沼化したので、失敗理由を書いていきます。担当者はサビ残してRPA作って業務改善しています（本末転倒）
※この場合でのリカバリーとは「RPA年間費用」＜「RPAによる作業軽減時間」になること。作成時間と保守の時間だけが増えていく…。
RPA導入を失敗する理由３つ
僕の勤め先での失敗談になります。導入予定の方々は同じ失敗をしないで欲しいです。実務も大して削減できない上に下っ端のエンジニアや作業者が犠牲になります。
実務を無視したトップダウンで導入してしまう
トップが「RPAで●●時間削減しました！」と言う事例や営業の「プログラマーでなくても簡単に使えます」を真に受けて適応できる実務を調べないで導入したパターン。RPA化するのに適した作業が無い場合でもトップが決めたからと言う理由でRPAを使って実務の軽減を実現しなければならない悪夢となります。エンジニアであれば一番適した技術を提案しますが「RPAで作らなければならない」と言われます（言われた）
この場合ではエンジニアは本質的な改善が出来ずに、大して学習コストを払うリターンがあるわけでもないRPAを必死に習得することとなります。RPAの学習に対するリターンはかなり低いと考えます。そもそもRPAはツールによって使い方が全然違うので、プログラム言語と違い汎用性がほぼありません。多少学習する程度には良いですが極めるのはリスクが高い。
RPAの学習時間を考慮していない
新しい技術を学ぶという事は学習する時間が必要です。大抵RPAを実際作るのは下流のエンジニアか、実務の担当者です。指示するだけのオッサン連中は普段から勉強するという習慣すらないので「学習する時間」を考慮しません、組織として学習にコストを払わない場合では尚更です。RPAの担当者は普段の実務＋RPAの学習と作成を行うと言う恐ろしい事になります。当然はじめは残業が増えます。そして言われるのは「RPA導入したのにどうして残業が増えてるの？」
ある程度上の人たちも実際に触れば学習時間なども把握できるのですが、今の勤め先では口だけしか動かしません。他の企業ではどうなんでしょうか。他人を使えおじさん多い。
RPAを作っていた人が居なくなってしまい保守ができない
これから頻発するであろう問題です。現時点でVBAの担当者がいなくなって使えなくなりましたと嘆いている状態なので、今後はRPAでも同じ事態が予想されます。そもそも、学習意欲が高い勤勉な人は、それ以外の人よりもどんどんスキルを身に着けて価値を高めます。
学習意欲のある人ほど、会社からいなくなる確率が高いです。
RPA導入を失敗しない為に
- 導入よりも前に「RPAを適応できる業務があるか」をしっかりと確認して、トライアル期間で成果が出れば導入を決める。
- 技術力のあるエンジニアにRPAを使ってもらい評価してもらう
- RPAの習得には時間がかかる事を考慮する
まとめ
RPAはしっかりと業務の選定を行えば成果は出せます。ただ実務を無視して導入すると約束された失敗が待っています。
トップダウン式導入のRPAは本当に滅びて欲しい。VBAで作れば30分くらいかかりそうな処理をなぜかRPAで3時間以上かけて作っています。そしてRPAは恐ろしいくらい保守性が低いです（他人の書いたRPAとか解読できる気がしません）。大企業とかでは上層部の力が強すぎて下っ端のエンジニアではどうしようもないけど、立ち向かっていきましょう！
ここまで読んで頂きありがとうございました。エンジニアとして適切な技術を提案できるようになりたいです。明日もコーディング頑張りましょう。
コメント