はじめに
みなさんはRPA使ってますか？
労働力不足にも関わらず、残業時間の削減が求められる日本において、「プログラミング経験不要で、誰でも簡単に業務が自動化できるツール！」という触れ込みで、RPAは働き方改革の特効薬として注目され、急速に広まりました。
前回、「RPAは誰でも簡単に作れるという罠」というタイトルでプログラミング未経験の人がRPAの開発をする場合の注意点について書きましたが、今回はその話に絡んで必ず出ると言っていい、「VBA(マクロ)が組める人ならRPAが簡単に作れるのか？」という事について書いて行きたいと思います。
本記事の対象読者は以下です。
- RPAのユーザー開発を進めたい方
- RPAのユーザー開発を進めているが、思うように進んでいない方
- RPAの開発に興味を持っている/取り組んでいるユーザーの方
本記事における「VBAを組める人」の定義ですが、VBAも組めるプロのエンジニアではなく、RPAのプロジェクトで最も一般的なケースである、プロのエンジニアとしての経験はないものの、業務の傍らVBAを習得した人とします。
VBAが組める人ならRPAは簡単に作れる？
さて、RPAのプロジェクトであれば必ず一度は出るであろうこの話題ですが、VBAが組める人ならRPAは簡単に作れるのでしょうか。
結論から言うとNoです。
もう少し言うと「一旦動くものはかなり早く作れるが、リリース後のエラーが多く、安定稼働まではかなり時間がかかる。更に、作成者の異動時に引継ぐ事は非常に難しい」という事になります。
現場でよく「RPAの開発はプログラミング未経験の人には確かに難しいかもしれないけれど、VBAが組める人なら大丈夫だろう」という声を聞きますが、このように甘く考えていると大きな落とし穴にはまります。
VBAを組める人によるRPAの開発を進める場合は、VBAが組める人とはどういう人なのかという事を正しく理解した上で、プロジェクト側できちんとした対策が必要になります。
では、VBAが組める人はどういう人なのかという事ですが、これはVBAが組める人とプロのエンジニアの違いを考えると見えてきます。
VBAが組める人とプロのエンジニアは何が違うのか？
VBAが組める人とプロのエンジニアは何が違うのでしょうか。
ソフトウェア開発のバックグラウンドがない方にこの質問を投げかけてみると、結構困る方が多く、「経験がある？難しいプログラミングの方法を知っている？」のように答えられる方が多いです。
もちろんそれもあるのですが、この文脈で理解しておくべき決定的な違いは「自分以外の人が見てもわかるコードが書けるかどうか」という事です。
以下、簡単な比較表です。
| 自分が見てわかるコードが書ける | 自分以外の人が見てもわかるコードが書ける | |
|---|---|---|
| プログラミング未経験者 | × | × |
| VBAが組める人 | ○ | × |
| プロのエンジニア | ○ | ○ |
プログラミング未経験の人は自分で作る事はできませんが、VBAが組める人はコードを書くことができます。しかし、VBAが組める人は自分が普段やっている業務の範囲で独自に効率化をしてきた方なので、そもそも自分以外の人がコードを見る想定はなく、自分が見てわかるかどうかという事を基準に作ります。自分が見てわかるかどうかが基準のため、自分の異動後の引継ぎまで意識して作っているわけではありません。
一方プロのエンジニアは、「コードは引き継がれていくもの」という前提のもとで、自分以外の人が見てもわかるかどうかという基準で作ります。またこの基準を満たすための訓練を受けています。
ソフトウェア開発の現場では、自身でコーディングをして終わりではなく、コードレビューと言って自分以外の人(主に自分より経験のある先輩)にコードをチェックしてもらい、エラーが発生しそうな箇所やわかりにくい箇所の指摘を受けて直すというプロセスがあります。ここで先輩方から有り難い指導を受けてエンジニアとして成長し、自分以外の人が見てもわかる、つまり引継ぐ事ができるコードを書くスキルを習得して行きます。
しかし、VBAが組める人で自分が組んだVBAのコードを自分以外の人にチェックしてもらった経験がある人はほとんどいないでしょう。つまり、自分以外の人が見てもわかるコードを書く経験を積んでいないため、その人の異動時に引き継げないという事象が発生します。実際、VBAをよく組んでいた人が異動になった際に、そのVBAが引き継げなかったというケースを経験している人も多いのではないでしょうか。
私も実際にいくつかの現場でVBAを組める方が組んだコードを見る機会があったのですが、中を見てみると完全にブラックボックス化しており、本人以外まずわからないなという状態がほとんどでした。結局、少しずつ動かしながら、そもそも何をやるための処理なのかという事を理解した上で、ブラックボックス化しないように一から作り直すという事も経験しました。
VBAが組める人にRPAを作ってもらうと、一旦動くものはかなり早く完成するため、「なんだ、こんなに早く作れるじゃないか。この調子でどんどん作ってもらおう！」という風になってしまうのですが、これはある意味で時限爆弾をどんどん仕込んでいるようなもので、そもそも作り込みが甘いためリリース後のエラーが頻発する上に、作成者の異動時に引き継げないという事象が発生します。特に、特定の方が何十体もロボットを作っていたという場合、その方が異動になると一気に何十体ものロボットが修正不可能な状態になってしまいます。慌ててプロのエンジニアに修正を依頼しても、他の人が見てわかるようになってはいないので修正には想定以上の時間がかかり、実際には、そのロボットを廃棄して、一から作り直すというケースの方が多いです。
RPAのプロジェクトで重要なのは、単純に何台のロボットを作れたかという事ではなく、特定の人に依存しない会社の資産としてロボットを管理できているかという事になります。
VBAを組める人はプログラミング未経験者に比べて適正が高いのは間違いないのですが、この辺りをきちんと理解してプロジェクト側で対策を立てていないと、ブラックボックス化したロボットが量産されるという大きな落とし穴にはまってしまいます。
VBAが組める人を上手くプロジェクトに巻き込むには
ではVBAが組める人にRPAを開発してもらう場合、プロジェクトではどのような対策を立てれば良いのでしょうか。効果的な対策は以下の3つです。
- 処理が簡単かつ処理時間が短いロボットをまずは作ってもらう
- RPAの開発標準を事前に渡して開発時に守ってもらう
- ロボットの完成時に有識者によるリリースチェックを行う
1つめですが、まずは処理が簡単で処理時間が短いロボットを作ってもらうのが良いです。まず初めに、RPAとは何かを理解してもらう良い場になる上に、リリースまで辿り着ける可能性が高いため、プロジェクト側での運用や管理方法について理解を深めてもらう良い機会にもなります。更に、最悪その方が異動になって部署内で引き継げなかったとしても、処理が単純なためプロジェクト側で巻き取れる可能性が高いです。処理が簡単でも処理時間が長いロボット(帳票を繰り返し100個ダウンロードなど)は、動作確認にそのつど時間がかかるため、最初は避けたほうが無難です。
2つめですが、RPAの開発標準に自分以外の人が見てもわかるように作るための方法(ブラックボックス化させない方法)について記載しておき、事前に渡して開発時に守ってもらうのが良いです。変数の命名規則やコメントの記載など、言語化可能なものは全て記載し、言語化が難しいものについては良い例と悪い例のサンプルの図などを載せておくと良いでしょう。よくある「RPAの作り方」といった初学者向けの研修ではなく、「どうすれば良いロボットが作れるか」という名目の研修を実施して、開発標準について理解してもらうのも効果的です。
3つめですが、これは既に説明したソフトウェア開発におけるコーディングチェックに当たります。出来上がったロボットを有識者が見て、運用に耐えられるレベルであるか、他の人が見てもわかるように作られているかという事をチェックし、修正が必要な箇所についてフィードバックをして直してもらいます。この過程で作成者のスキルが大きく向上していきます。ここでスキルアップされた方については、処理が複雑なロボットや処理時間の長いロボットに徐々にチャレンジしてもらっても良いでしょう。
更に理想的なのは、このような経験を経た方に、その部署でのRPAの伝道師となってもらう事です。
このような方は、そもそも業務知識がある上に、リリース経験を経てロボットの運用や管理方法についても理解しているため、プロジェクトにとって大きな味方となってくれる場合が多いです。
まとめ
いかがでしたでしょうか。
VBAが組める人とはどういう人なのかという事を正しく理解せず、「RPAはそもそも簡単なんだからVBAを組める人なら大丈夫だろう」と安易に進めてしまうと後から大きな落とし穴にはまります。
このようなつまずきポイントに注意して、今後の取り組みに活かして頂ければ幸いです。
<参考>
参考書籍
・プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則
・先進企業の事例と調査から学ぶDX成功のカギ-デジタル人材 採用 育成 再教育
Qiita記事
・RPAは誰でも簡単に作れるという罠
・UiPathのコーディングチェックツールを作ってみた
・RPAへの理解がぐっと深まる、RPAがよくこける理由
・寿司打を自動化してみた【RPA×OCR】
・RPAのオススメ書籍
・RPAの開発に向いている人、向いていない人
・RPAの推進に必須なRPAOpsという考え方
・【AI】Deep Metric Learning
・【AI】Deep Learning for Image Denoising
・【AI】Deep Convolutional Autoencoderベースの教師なし異常箇所検知
・【AI】Deep Learning for Image Inpainting
デモ
・UiPathCodingChecker：UiPathのxamlファイルからコードを分析
・AI Demos：DeepLearningによる手書き文字認識・異常検知・画像のデノイズ
・寿司打自動化(YouTube)：タイピングゲーム寿司打のRPA×OCRでの自動化