■RPAで疲れ果てた

物流会社の事務員なんだけど会社がRPAツールを導入するってんで定型作業を自動化しろって話しでRPAプログラミングをやらされてたんだわ。

それで色々クソな点があったのでシェアします。

1、実務の合間にやらないといけない

マネジメントの問題でもあるけど、そういうことなんだよな。

現場がクソ忙しい時に悠長にデバッグとかやってられん。あとデバッグみたいな作業は見た目何もしていないように見えるからここぞとばかりに仕事振られたりする。

2、本番環境とか開発環境とかない。ぶっつけ本番で稼働→失敗→デバッグを繰り返さないといけない。

これは自動化する仕事によると思うんだけど、実際に現場で使うデータをRPAプログラムに投入しないとそもそも要件がわからないことがある。データの特性というか、物流事務なんかだと8割がシステム化されているけど2割は荷主や配送先のわがままで特徴的なデータの不備があって、それに対応するのが事務屋の仕事なんだけど、そういう面倒な作業を自動化しろとか言ってくる。そもそもRPAなんてシステム化のスコープ外の面倒な事務を(金をかけずに)自動化することが目的だから当たり前なんだが。

そうすると要件の洗い出しとかできない。ベテランのオペレーターにはそういうの全部頭に入ってるからマニュアルとか作ってないことが多い。実際新人に教えるときもぶっつけでやらせてわかんなかったら聞けみたいな世界だし。

3、(2)みたいな事象があるからソースコードがぐちゃぐちゃになる。ぶっつけ本番でプレッシャーがある中実行してその場凌ぎの改修して保守性皆無

4、状態管理ができない

RPAツールってWindowsのUIをいじって業務を行うプログラムを作るんだけど、結局今どの画面を開いているのかとか、どのエラーが出ているのかとかプログラム上で管理できない。既存のソフトウェアUIがたまたま運良くRPAツールと相性が良ければいいけどそうじゃなければめちゃくちゃやりづらい。特にIBMのPCOMMとかはツールとの相性が悪くて地獄だった。

5、操作してるソフトウェアのUIが変わったらお釈迦ポン。

書かなくてもわかると思うけど、業務で操作するソフトのUIが変わった瞬間にそのRPAプログラムはゴミになる。

6、再現性の低いバグが出る

(4)に関係するんだけど、RPAプログラムが立ち上がった時のパソコンの状態によって処理速度にムラがあるので、プログラム上このステップまで進んだらウィンドウはこの状態にあるだろうと仮定してプログラムを作ったところ、実際100回のうち99回はそうなんだけど、1回だけ処理がもたついてその状態にならなかったからバグって処理が停止する。みたいなことがある。

もちろんツールではウィンドウが操作可能になるまで待機、みたいなのはあるけど操作可能、全面にある、みたいな粗い粒度でしか状態管理できない。

7、こう言うのをちょっとパソコン得意とかEXCEL VBA かけますみたいなやつにやらせることの矛盾

うまくいくわけない。(4)(6)のところでウィンドウの状態管理とそれに起因するバグについて書いたけど、こういう時RPA担当は一般のプログラミング言語でいうsleepで職人芸的に時間調整するんだぜ？こんなのもう(3Dリアルタイム)ロボットプログラミングでしょ。

結論を言うと2022年の馬鹿みたいに複雑化した物流の事務(そしてそれは主に荷主と物流会社の主従関係によるわがままに起因しているのだが)をRPA化するのは無理だしもうやりたくないね。

Permalink | 記事への反応(15) | 18:32

ツイートシェア