プログラミングの前に RPA を学ぶと最強になれる理由を解説

FacebooktwitterredditpinterestlinkedinmailFacebooktwitterredditpinterestlinkedinmail

ノーコード、ローコードと呼ばれる開発ツールが広く使われる RPA (ロボティクス・プロセス・オートメーション)。しかし、道具があるからといって、本当にPCの操作を自動化できるのかと不安に思うかもしれません。

そこで、長年、単独でプログラミングによる開発や、 RPA という言葉が生まれる前からPC操作を自動化してきた経験を持つ筆者が解説したいと思います。

 

プログラミングができなくても RPA の自作はできるか?

この記事が役に立つ人

  • RPA の導入を検討している、または職場の命令などで導入の推進を行っているものの、プログラミングには詳しくない人。
  • または、自身がプログラミングができる、システム部門に所属していて「自作に不安はないが、現場で運用できるか」懸念がある人。

ざっくりと結論

  • 頑張ればできる!
  • さらにプログラマ・エンジニアの思考まで一緒に学べる!
  • RPA の経験を活かしてステップアップもできる

 

未経験からRPAづくりが学べる連載の目次

【無料RPA】Pulover’s Macro Creator まとめ【ゲームマクロ】

 

ノーコード・ローコード RPA ツールとはなにか?

No Code, Low Code な RPA とは、つまりどういうことか? ノーコードだから簡単、ローコードだから簡単、とは言いますが、本質は少し違います。

かんたん、というよりは、「プログラミング的・エンジニア的思考がそなわっている人が」【楽】に RPA , プログラム・スクリプトを作成できるという意味です。どう楽か、というと、文法やメソッド(関数)といった、単純に暗記しなければいけない約束事を覚えなくてもすむ、といった楽さです。

論述試験で、辞書を持ち込めるか、持ち込めないかの違いのようなものだと思っていただければ、「確かに楽だけど、辞書があるだけで論述試験は合格できないな」ということが分かっていただけると思います。

つまり、「なんだか凄そうな RPA 制作ツールがあって、誰でもかんたんに作れると言ってるけど、ほんとう?」と感じていたあなたの疑念は正しいです。ざんねんながら、話はそれほど単純ではありません。

 

本当に楽なツールは?

実は、GPT-3というAIを用いて自然言語からプログラムのコードを生成することができるようになっています。自然言語というのは、私たち人間がふだん使っている言葉です。

これが高性能になり、様々な言語(自然言語という意味でも、プログラミング言語という意味でも)に対応するようになれば RPA の自作は飛躍的に楽になるでしょう。

ただ、そうなってもこの後に記載する、「エンジニア的思考力」や「業務を棚卸しする能力」は依然として必要なままでしょう(しばらくは)。

 

じゃあ、素人に RPA は自作できないの?

そんなことはありません。ノーコード・ローコードツールに限らず、1からシナリオスクリプトを書かないといけない RPA ツールであっても頑張れば作成できるようになります。

「いやいや、そりゃ頑張ればできるでしょ」とは思います。ただ、キーボードを叩いてプログラムするにしても、 RPA はWeb アプリケーションやスマホアプリの作成よりもずっと楽に学習することができます。

 

RPA の作成が学習しやすい理由

RPA は動作が目に見える操作がほとんど

一番大きい理由はこれかもしれません。 RPA は普段の繰り返し作業を楽にするため、みなさんが日頃行う、キーボード操作やマウス操作を自動化します。

そのため、なにか動作がおかしいときも、原因を究明して解決する、デバッグという作業を目で見て行いやすくなります。一般的なプログラミング言語では、デバッガという専用のツールを使って、プログラムを少しずつ動かして原因を探ったり、内部状態を覗き見たりする必要があり、実際には、キーボードを叩いてコードを書いている時間よりも、デバッガで挙動を確認している時間の方が長いことが普通です。

 

RPA はロジックよりも業務の再現性が大切

プログラミングは、論理や数式を組み合わせて制作を行いますが、 RPA は「操作」の組み合わせで構築します。これが何を意味するかというと、極端な話、「そこで何をしているか、理解していなくてもいい」のです。

普段の業務で、理由は分からないまま、なんとなく設定を変えたり、値をコピーしたりしている部分があったとします。プログラミングの場合は、それを適切なロジックに落とし込む必要がありますが、 RPA の場合、普段の業務と同じで「とりあえずその操作をしておけばいい」のです(業務としてどうかとは思いますが……)。

そういう意味で、完成品を作り上げる難易度が低いといえます。

 

RPA はとりあえず動けば OK

とある大規模なシステムの障害で、原因に「データ入力の不備」を挙げる例がありました。エンジニア、とくに Web 系のエンジニアにとっては信じられない発表です。というのも、インターネットに接続されたシステムでは、いつでも悪意のある攻撃者にさらされる危険があるため、ユーザーからの入力は厳格にチェックしているからです。

しかし、 RPA に関しては外部に公開されるプログラムではなく、また基本的に「ユーザーからの入力」を受け取るシステムではありません。

そのため、運用上のルールなどは取り決める必要はあるものの、外部から攻撃される恐れのあるシステムほどは厳格である必要はほとんどありません。どちらかというと、その責は操作されるシステム側が背負うものになっています。

とはいえ、オンラインから RPA を起動できるようにする場合などは、当然セキュリティチェックは必要になります。

 

学習しやすい理由のまとめ

以上のような理由で、 RPA は実戦投入できる成果物を仕上げられるまでの時間が、プログラミングと比べて短い傾向にあります。それにより、試行錯誤や改修といった、学習のループを高速に回すことができ、結果としてより高品質な成果物を作り出せるようになります。

また、複数の部署やユーザーからの意見を取り入れることも多くなるため、業務に必要な能力を効率よく収集できます。

これが、 RPA がノーコードやローコードによらず、プログラムと比較して学習しやすい理由です。

 

RPA 作成がエンジニア育成になる理由

では、 RPA を作れるようになると、エンジニアとしてプログラミングが学びやすくなれる理由を解説します。

 

RPA のシナリオは、人間の操作をPCの言葉に翻訳している

現在の RPA ツールは、見た目の分かりやすさ・使いやすさ、サポート体制によらず、なんとなく「うーん、人間に説明するときはいちいちこんなこと言わなくていいのに!」ということが多いです。

これは、言外の言葉が伝わるとか、行間を読むとか言われている能力が、PCにはないというのが理由のひとつではあります。しかし最大の要因は表題の通りです。

そもそも、人間の言葉とPCの言葉は全然違います(これがプログラミング言語が必要な理由ですね)。

RPA ツールというのは、PCの操作をコンピューターに伝えるために「単語の翻訳をして」私たちに提供してくれています。中には、ことわざのような、「短いけれど複雑な意味をもつもの」もあります。

ただ、「文法」や「考え方」までは自動で変換しきれていません。

 

日本語から英語に翻訳することを考えてみましょう。諦めずに辞書を引けば、時間はかかりますが、単語の意味は大体伝わります。ただ、その調べた単語を日本語の順番で並べたら、相手の人がものすごく頑張ってくれたら伝わるかもしれませんが、大体の場合は意味が分からないですよね。

ちょっと複雑な構造の文章だったら、もちろん逆の意味に捉えられて相手を怒らせてしまうかもしれません。

 

RPA のシナリオを書くというのは、辞書を引く手間を省きますが、文法についてはツールにアシストしてもらいつつ結局のところ、 RPA シナリオを書く人が頑張って翻訳しているようなものです。

そしてこのPCの言葉への翻訳は、プログラマーやソフトウェアエンジニアが日頃やっていることでもあります。そのため、 RPA のシナリオづくりを通して、PCの文法の基礎を学んでいるということになります。

 

業務を分解して整理している

これは、先の項目と似ているようですが、すこし違います。

標準化が進められていない業務や、属人的でブラックボックス化している業務があると RPA 化は進められません(そもそも業務の標準化や属人化の排除は効率化の基本でもあるので、いずれ記事を書こうと思います)。

そこで、複数の部署とまでは言わないまでも、複数人がこれまで担当していたような業務を RPA 化できる人は、複雑化した業務を分解して整理できているということになります。

几帳面な方なら、フローチャートやスイムレーンチャートまで作成して資料化しているかもしれません。

これらは、業務用のアプリケーションを設計するのにも必要な行為であり、単純に「プログラミングができる」というのとは別の実務スキルとなります。

こういった実務スキルは、本人の意識しない強みとなることが多く、他社(他者)との差別化要因になりますので、かなり自信を持てる経験になります。

コンサル視点で解説する副業を始める人に欠けている1つの視点でも、他者との差別化の重要性について説明しています。

 

結論

RPA というのは、プログラミングを行う上での補助輪のようなものです。極論を言ってしまえば、RPA をつかって色々なソフトを操作して実現できる仕事を、1つのプログラムで実現できればそれがスマートでしょう。

ただ、現実は、「時間」「予算」「人員」といった制限があります(能力については、悲観することはありません! その他のリソースが充分ならいずれついてくるでしょう)。

そこで、 RPA を利用して許容できるリソースに抑えて業務を効率化し、生産性を最大化しています。

それだけでも充分ですが、それはつまり、プログラミング・ソフトウェアエンジニアリングの上澄みを経験している、ということでもありますので、それに留めないで RPA シナリオの作成とは本質的に何か? 生み出している価値について考えていただければ、よりよい業務・キャリアを作っていけるでしょう。

FacebooktwitterredditpinterestlinkedinmailFacebooktwitterredditpinterestlinkedinmail

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください

最新の記事