Scribble at 2022-03-25 11:50:26 Last modified: 2022-03-25 14:08:08
The size of the RPA market increases by orders of magnitude every year. RPA platforms today are far more powerful than they were back in 2017. As an RPA developer, this makes it tempting to 'specialize' in RPA and not stray outside its boundaries. I now outline 3 reasons why thinking that way is a mistake.
システム開発の実務家として読めば「何をいまさら」と言えなくもないが、RPA のルーティンだけを組み立ててきた人たちには、こういう視野狭窄が起きるリスクがあるという点では、よい参考になる。はっきり言わせてもらえば、Excel の関数しか扱えない、大企業の経理とかによくいる人たちや事務機屋の自称プログラマとか、あるいは VB の経験だけで開発の実務を語るゼネコンの自称プログラマとかにも、目にメンソレータムでも塗ってから上の記事を丁寧に読んでもらいたいという気分だ。
ちなみに、RPA については僕も３年くらい前に幾つかのサービスを調べて、それこそブラウザでフォームにテキストを入力して送信するという手順を記憶させて自動実行するルーティンを Python + Tk で組んであるツールを使って試していたことはある。データを送り付けるだけなら POST 送信を偽装してやった方が早いし、いちどに大量のデータを送れるわけだけど、たいていのフォームというのは（まともに設計してあれば）きちんとセッションを生成して自動投稿を抑制しているはずだ。そういう無効な相手に闇雲にデータを送り付けるなんてことをやってると、当たり前だが送信元の IP アドレスを遮断されたりする。それなら、メールの大量送信サービスでも使ってフォームではなくメールとしてスパムを送った方が、まだマシであろう。
ともあれ、RPA のルーティンを他にも組んで試してみたのだが、正直なところコマンド・ラインで仕事をしているところに使う気にはなれないのがプログラマというものだし、GUI で作業している業務についても、言っちゃ悪いが俺の方がコンピュータなんかよりも仕事が早いし、同じルーティンが別のフォームに使えるかどうかの判断も正しいので、特に自分の業務に限って言えば、RPA は大して効率化の役に立つとは思えなかった。まぁ、３年前の RPA アプリケーションなんてものは、せいぜい MMORPG のボットていどのものでしかなかったからだろう。いまなら、もうちょっと動きも判断もよくなっているのだろうけど、それを改めて調べる工数自体が無駄なんだよね。コンピュータを超える人間としては。