業務自動化のテクノロジーRPAについては、各開発会社は「プログラミングの知識は不要です」「簡単に業務が自動化できます」「操作をレコーディングするだけです」など、あたかもITリテラシーが高くなくてもRPAを導入さえすれば、業務の自動化が実現できるかのようにPRしています。
デジタル活用の有用性は説いても、ITリテラシーの高い人材育成・確保する重要性はあまり説明されていません。
はたして、RPAは本当に導入するだけでどの会社でも効果が得られるものなのか、簡単に次々と社内の業務を自動化できるものなのか。
この記事で解説します。
RPAはプログラミングそのもの
RPAはプログラミングツールそのものです。プログラミング知識がなくても簡単に自動化を実現するようなツールではありません。少なくとも、現代においてプログラミング知識を必要とせず、実用性の高い自動化を実現するテクノロジーはありません。
では、なぜ「プログラミング知識が不要」などというPRが流行したのか、まずそこから解説したいと思います。
RPAはビジュアル化されたプログラミングツール
一般的なプログラミングとRPAを図で比較すると下記のようになります。
両画像は、同じ処理を比較したものではありませんが、①と②は決定的に異なっていることが分かります。
「①プログラミング言語」に関しては、一般的に想像するような構文（英語）で記述されています。一方、「②RPA」は、ビジュアル化されたブロックが並べられており、それぞれのブロックにはウィンドウを閉じるなどの動作と思われる説明書きも表示されています。
一見して、全体的にどのような処理が行われるのか、イメージできる程ではありませんが、「①プログラミング言語」よりは馴染みやすいでしょう。
そして、多くのRPAソフトウェアではプログラミング言語を直接記述する必要はなく、上記のようなブロックの組み合わせで自動化プログラムを作成することができます。
部分的に、プログラミング言語をブロック内に記述する必要があるRPAソフトウェアも存在します。
ブロックをどう組み合わせるのか
ここが一番のポイントです。
RPAは、直接、プログラミング言語を記述する必要はありませんが、ブロックをロジカルに組み合わせる必要はあるのです。当然、適当に組み合わせると適当な動きをする結果にしかなりません。
RPAを正しく動作させるためには、正しくブロックを組み合わせる必要があるのです。
この正しくブロックを組み合わせる作業こそ、プログラミング的思考そのものなのです。次節のサンプル業務で体感していただけます。
プログラミング的思考をサンプル業務で体感
下記の業務をRPAを使って自動化することをイメージしてみましょう。
＜請求書発行業務＞
- 請求書の送付通数を確認する
- 発行する会社に前月以前分の未納額がないか確認する
- 未納額があれば今月の請求額に上乗せする
- 請求書を発行する
- 次の会社分を作成する（②に戻る）
RPAを使って自動化
まず、業務がどのように流れているのか、処理を繰り返す回数・処理範囲、処理の分岐条件・分岐箇所、をロジカルに整理する必要があります。最もよい方法は、フローチャート化です。
実際に、この業務のフローチャートを書いてみましょう。
〇に関して、イメージし辛いかもしれませんが、1回目の処理のときには「1」を当てはめてください。処理の最後に〇+1の処理がありますので、2となり、2件目の処理に移ります。同様に3、4件目と処理が進んでいき、最初のブロックで取得した請求書の送付通数分、繰り返されます。
赤線の箇所は繰り返し処理の範囲、緑線は分岐処理となります。なお、値が変動する〇については、プログラミングの世界では、『変数』と呼ばれます。
フローチャートの先にRPAの自動化
前節、サンプル業務で体感いただいた方は、だいぶご理解が進んだかと思います。
このように、業務手順をロジカルに細分化しなければ、どのようなITツールを使っても自動化はできません。そして、わたしの感覚では、RPAを活用できていない企業の多くは、ここで躓いています。
「RPAの操作は少し覚えたけど、実際に作ろうとすると・・何をすればよいか分からない」となる訳です。
ご納得し易いのではないでしょうか。
RPAで自動化したサンプル動画
RPAは難しいのか
本題です。RPAは難しいのか、について。
RPAソフトウェアによって、初級者向けと呼ばれるもの、中級者以上向けと呼ばれるもの、様々ありますが、総じて前章で解説したようなプログラミング的思考は必要です。
わたしの考え方ですが、RPAはソフトウェアの操作以上に、業務手順のロジカルな整理、フローチャート化といった工程が難しいのです。
人間が、長年処理をしてきた業務は「担当者依存型」の業務になっており、処理の判断基準などを明確にすることは意外に難しいのです。
例えば、5年間、ある担当者のみで対応してきた業務を業務手順書のみで引き継ぐことを想像してみてください。
簡単ですか？難しいですか？
結論として、RPAは難しい部類に入るでしょう。
しかし、プログラミング的思考については、おそらく世間が想像しているよりも難しくありません。要は日常的な考え方をロジカルにしたものがプログラミング的思考であり、実は大半の方は習得可能なレベルなのです。
そして、RPAはプログラミング思考が必要といっても、本格的なプログラミングのレベルは不要です。前章で説明したような、繰り返し・条件分岐・変数、といった初歩的なレベルで十分です。
得意・不得意が顕著に表れる分野ではありますが、学習方法さえ間違えなければ、プログラミング的思考を含めたRPAのスキル習得は、十分に手の届くレベルなのです。
