RPAは誰でも簡単に作れるという罠

## はじめに

みなさんはRPA使ってますか？

労働力不足にも関わらず、残業時間の削減が求められる日本において、「**プログラミング経験不要で、誰でも簡単に業務が自動化できるツール！**」という触れ込みで、RPAは働き方改革の特効薬として注目され、急速に広まりました。

一方、導入してみたものの、「思ったより作るのが難しい・・」「作ったロボが頻繁にエラーとなる・・」というように、**導入当初の想定よりロボの開発が上手く行かず、思ったような効果が出ていない**という方も多いのではないでしょうか。

本記事は、なぜこのような現象が起きるのかについて、RPAコンサルに転身した元エンジニアが、**RPAの開発に求められるスキル**の視点から書いて行きたいと思います。

本記事の対象読者は以下です。

* RPAの導入を検討している方
* RPA導入中・導入済みだが、開発がなかなか上手く行かないという方
* 業務担当者でのRPAの自主開発を進めたいが、なかなか上手く進まないという方

## RPAは誰でも簡単に作れる？

さて、巷でよく聞くようにRPAは誰でも簡単に作れるのでしょうか。
結論から言うとNoです。

もう少し言うと「プログラミング経験なしでも頑張れば一旦動くものは作れるが、運用に耐えられるレベルの品質で作る事はなかなか難しく、少なくとも作成者の異動時に引継ぐ事は難しい」という事になります。

時々「プログラミング未経験の事務職員がロボを開発し、年間〇〇時間の削減達成！」といった記事を見かけますが、一旦動くものは頑張ればなんとか作れます。しかし実際は、「もうリリースして数ヶ月経つが、まだロボが安定して動かない・・」「一旦作ったが、その後エラーが継続的に発生し、もう使うのをやめてしまった・・」というケースが多数です。

私が参画するプロジェクトでも、元々プログラミング経験はないものの、RPAのチュートリアルを一通り勉強してRPA開発の派遣社員として来た方や、社内でRPAの勉強会を実施し、業務の傍らRPAの開発に取り組んだユーザーの方の場合、そもそも開発完了まで辿り着けないか、一旦なんとか作ったものの、運用に耐えられず使用を停止したといったケースがほとんどでした。

## 簡単なはずなのに何が問題なのか？
これはRPAが簡単と言われている点がどこかを考えると見えてきます。
RPAが簡単と言われる理由でよくあるのが以下のようなものです。

- 複雑なコードを覚える必要はなく、ドラック&ドロップベースで簡単に作れる
- 処理の流れがフローチャートで表示されるため、直感的な操作が可能である

これはつまり何が簡単だと言っているのでしょうか。
これが言っているのは、ソフトウェア開発の言葉を使うと、「**コーディング(実装)**」が簡単だと言う事だけです。

では、コーディングが簡単であれば誰でも作れるという事になるのでしょうか。
残念ながらそんな事はありません。これはソフトウェア開発のプロセスを考えると見えてきます。

## V字モデルで考えてみる

以下の図はV字モデルと言われる、ソフトウェアの基本的な開発プロセスです。
分野によらずソフトウェアであれば、大きな括りではこの開発プロセスに従い、RPAの開発も同様です。
<img width=100% src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/431306/5116c2a5-535d-1b03-c0da-96022d0eb760.png>
ソフトウェア開発は、開発するソフトウェアで何を実現するかを決める「要件定義」から始まり、ソフトウェアとしての全体構成を決める「基本設計」、更に各部分の構成を決める「詳細設計」へと続き、詳細設計が終わった所で、ようやく「コーディング」が出てきます。そしてコーディングの後は、品質を担保するための各種テストへと移っていきます。

おわかりでしょうか。
RPAの開発に必要な全体プロセスの内、**RPAツールで簡単になったのは、実は**「**コーディング**」**の部分だけ**です。

<img width=100% src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/431306/ff4acb0a-733a-ef4b-38fe-0497d3fbe0a0.png>

ソフトウェア開発経験のない方々にとっては、「ソフトウェア開発＝プログラミング」というイメージが強くあるため、プログラミングに当たるコーディングの部分が簡単になったという事がそのまま、誰でも簡単に作れるという期待に繋がってしまったようです。しかし、ソフトウェア開発はコーディングだけでなく、既に説明した通り、要件定義・設計・テストも重要になるため、コーディングが簡単になったという事がそのまま、誰でも簡単に作れるという結果には繋がらず、当初の期待とのギャップが生まれてしまいました。

これは建築で考えてみると当たり前で、誰でも簡単に使えるブルドーザーや工具があれば、簡単に建物が建てられるでしょうか。もちろんこれはNoで、どのような建物を建てるかの「要件定義」と、建物の構成を考えて図面を作成する「設計」、建物の品質を検査する「テスト」なくして良い建物は立ちません。かろうじて建てられたとしても、欠陥が多くの箇所に潜んでいるため、長持ちする事はないでしょう。これが、RPAを一旦作ったものの頻繁にエラーが出てなかなか安定しないという事と同様の事象になります。

## まとめ
いかがでしたでしょうか。
RPA自体は素晴らしいツールで、正しく使えば大きな効果を生むのですが、RPAで何が簡単になったのかという事を正しく理解していないと、誰でも簡単に作れると思って取り組んでみたものの、期待したような効果が出ないという落とし穴にはまります。
このようなつまずきポイントに注意して、今後の取り組みに活かして頂ければ幸いです。


<参考>
参考書籍
・[プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則](https://amzn.to/3Jnoxcm)
・[先進企業の事例と調査から学ぶDX成功のカギ-デジタル人材 採用 育成 再教育](https://amzn.to/3JuEehW)

Qiita記事
・[VBAが組める人ならRPAは簡単に作れるという罠](https://qiita.com/jw-automation/items/38c28016bf5162e76c59)
・[UiPathのコーディングチェックツールを作ってみた【RPA】](https://qiita.com/jw-automation/items/003dd0ef116cf968c3a8)
・[RPAへの理解がぐっと深まる、RPAがよくこける理由](https://qiita.com/jw-automation/items/836391dfde3fb1ac83d6)
・[寿司打を自動化してみた【RPA×OCR】](https://qiita.com/jw-automation/items/a906f7a79e72add7b577)
・[RPAのオススメ書籍](https://qiita.com/jw-automation/items/3c141c50c7a163943fd9)
・[RPAの開発に向いている人、向いていない人](https://qiita.com/jw-automation/items/828933731611b9ec601f)
・[RPAの推進に必須なRPAOpsという考え方](https://qiita.com/jw-automation/items/53c45b7dfc7a5865c5ff)
・[【AI】Deep Metric Learning](https://qiita.com/jw-automation/items/7bbe1c872fcec7fa6c1d)
・[【AI】Deep Learning for Image Denoising](https://qiita.com/jw-automation/items/f942ea0c6a02e8e50fa2)
・[【AI】Deep Convolutional Autoencoderベースの教師なし異常箇所検知](https://qiita.com/jw-automation/items/aea08a5c915d0627803a)
・[【AI】Deep Learning for Image Inpainting](https://qiita.com/jw-automation/items/0131b24a0b5a4e6fd0a6)

デモ
・[UiPathCodingChecker](https://jw-automation.com/rpa/uipathcodingchecker)：UiPathのxamlファイルからコードを分析
・[AI Demos](https://jw-automation.com/ai/demos)：DeepLearningによる手書き文字認識・異常検知・画像のデノイズ
・[寿司打自動化(YouTube)](https://youtu.be/7l9FiPtPftw)：タイピングゲーム寿司打のRPA×OCRでの自動化