  |
はてなキーワード: RPAとは
https://www.code-lab.net/?p=22058
マクロやRPAなどを使って業務を自動化して何十時間も節約しているのに給与は…みたいな話しを時折見かけるので、何故給与が増えないのか考察したいと思う。
マクロやRPAなどの活用による業務の効率化は二つの段階に分けられる。
・1stステージ
マクロやRPAを利用した自動化により、事務作業にかかる時間が削減されている状況。この段階は従業員個人の能力により業務時間の削減がなされている。作業負担の軽減により同僚からは感謝されたりはする。だがこの段階では会社の利益には繋がっていない。
・2ndステージ
自動化により削減された時間をより付加価値の高い業務に割り当てたり、あるいは余剰人員を人手の足りない部署に異動したり、従業員の解雇を行っている状態。
マクロやRPAの開発と維持には費用が発生している。作業時間の短縮により不要になった労働力を異動あるいは解雇するなり、短縮された時間を用いてより付加価値の高い作業を行うので無ければ、会社としては開発と維持にかかる費用分を損した状態になってしまう。
「マクロを勉強して自動化しました」という話しをしているとき、殆どの場合は1stステージの状態にあり、まだ会社に利益を生み出せていない。故に給与が増えることを望むなら、1stステージ→2ndステージへの移行が重要になるのだが、ここが難しい。
余剰人員異動や解雇には人事権が必要になるし、より付加価値の高い業務を生み出せる人材は自動化人材よりも貴重だ。2ndステージの実現には管理職の協力が必要不可欠になる。管理職者に1stステージで自動化の恩恵を見せて、2ndステージに移るための協力を得なければならない。
…が、そこで自動化を進められる素養を持つ上司なら、従業員に言われるまでもなくIT化を進めているはずだよね…的な達観があったり無かったり。
と言う訳でマクロを使えたり、RPAを使いこなせたからと行って突然に給与が増えることは無い。でも使える手札が増えれば、選択肢も増えるわけで、今後にチャンスをものに出来る可能性が増えるわけで、無駄では無い。
「【Mac】Kindle本も永久保存！自動スクショでPDF化する方法｜脱凡リーマンブログ」というブクマ。
https://b.hatena.ne.jp/entry/s/exit-bonbon.com/kindle-save-pdf-automatic-screenshots/
アウトなのは当然として。リアル画面表示でApple scriptか。なんてローテクな…90年代かよ。まぁRPAってこれだよな。
まあ、知らないことは誰にでもあるし、ありとあらゆる分野について知っている人などいない。
しかし、有名人が似たようなことを言うとそのファンやフォロワーたちがそれを一気に拡散し、あたかもそれが正しいかのように扱われてしまう。
それに逆らとめんどくさいことになるので、その「間違った解釈」に従って行動せざるを得ない。
これを正すためにはどうするのがいいのだろうか。
RPAに助けられた人もいるよって話だけど、RPAを盲信してるわけではないので大変だったことも書く(RPAが大変っていうより導入支援を担当してたITコンサル企業がクソ)
生存者バイアスだと思うのであくまでこういう人もいるんだくらいで読んでね
大手企業一般職(RPA業務経験)→中小SI企業SE→派遣RPAエンジニア
【経緯】
私は2016年に新卒で大手企業に一般職として入社して、2017年の1〜3月頃に所属部署にRPAが導入された。
最初はITコンサルが私の担当業務(日次で行う定型業務)を自動化して持ってきたのだが、正常稼働しないポンコツだったのでそれをまともに動くものにすることから始まった。
私は暇だったのでたまたま対応できたけど、多分他の人だったら積んでたと思う。(別の課にも導入されたが、動かないまま放置されてた)
なお、その時の私のスキルは、Excel関数は得意、VBAはボタンを押したらシートを印刷するマクロを作ったことがあるという程度のレベルだった。
当時の状況は以下だ(ツールはUipath)
・パソコンの処理速度によって、正常稼働したりしなかったりする。
→これはRPAで疲れ果てた方も言ってたやつ。
Delayで◯秒待機というのが置かれてたり、それすらなかったりしたのを、操作対象(ウィンドウやボタンなど)の存在を確認するまで待機するアクティビティを配置して対応した(タイムアウト時間を設定して、それを超えたらエラーとなる)
→これ自体は動作に影響はないのだが、同じ修正をそれぞれのプロセスにかけないといけないので、共通動作は1つのプロセスにまとめて、それを各プロセスから呼び出すように変更した。
→RPA化するにあたりITコンサルが作ってくれたのだが誤りだらけだったので組み直した。
上記に対応したらRPAとVBAのスキルが身につき、なおかつ担当業務が自動化されて更に暇になったので、新規でRPAプロセスやExcel,AccessVBAツールを開発したり、既存のレガシーExcel,AccessVBAツールの改修などを行っていた。
業務自体は楽しかったのだが、通勤時間が長く、低賃金で職場の近くに引っ越すこともできなかったので自宅(実家)から近い(それでも1時間弱かかる)会社(中小SI企業)に転職した。
本当はプログラミングをやりたかったのだが、そこではBIツールの画面開発とDBのテーブルやViewの作成とかをやってた。
1年ほど勤めていたが、体調の都合により退職した。
その後結婚をして半年ほど専業主婦をやってたが、体調も安定したのでフルリモートでできる派遣の仕事を探してたらRPAエンジニアを募集してたので申し込んだ。
無事受かったので、今は大手企業の業務部門内のRPA開発チームでRPAの開発を行なっている。(使用ツールは日本企業での導入が少ないので伏せます。)
業務の傍ではなく、主業務として開発を行なっているので、しっかりとしたプロセスができていて感心している。
今は派遣だが、社内試験を受かれば正社員になれるので、今後何事もなければここで働き続けるつもりだ。(育休産休時短勤務があるので、働きやすそう)
給料も高くなり、働く環境も良くなったので、新卒で入った会社でRPA担当できてラッキーだったなと思っている。
ちなみに私自身のRPAの認識は、システム化できないものをRPA化するというよりは、システムとシステムの橋渡しをしてあげるものだと思ってます。システム間の連携すら本来はシステム化されるといいんだけどね！
経理が初めてなのにいきなり頓挫したRPAツールのバグとシステム修正させられたことがあったわ
マジで業務何も分からないのに要件定義してくれとか地獄でしかなかった
自分もちょっとパソコン得意でEXCEL VBAかけます程度の人間だけどRPAまかされた。
バリバリのプログラマ雇ってその人に作ってもらってたのを見てググって教わって簡単な修正ぐらいはできるかなーぐらいになったところでバリバリの方が辞めてしまったので仕方なくRPA全部自分に回ってきた。ちな給料は変わってない。
お互いがんばろう。
はっきり言って、日本以外でRPAって全然流行ってないよ。理由として
・メンテナスをする者のスキルアップ、モチベーションに繋がらない
・自動化したところで、人が行う作業が減るだけで、そこからデータなどのインサイトが得られない
というのが主なんだけど、じゃあ海外だとどうやっているかと言うと、
・基本的にはUIを使って操作するのではなく、APIを使って操作する。
・よって、APIを有していない社内ツール等はなるべく導入しない
・社内で内製しているツールなどもAPIを開発する(今だとフロントとバックエンドは分離しているのが多いのでそのまま利用する)
として、極力一度作った物のメンテナンスを減らしている。(結局メンテナンスは必要だが)ただ、日本では経営者がITに弱いことが多いので、一見コストが減らせるように見えるRPAを選択してしまう。
物流と書かれているので、WEBアプリではなくWindowsアプリみたいのをポチポチしないといけないケースも多々あるかと思うしアプリがニッチ過ぎて、APIなんて付く見込み無いとかあるだろうけど、一人でやるのは心が壊れるのでRPAやるにしても、専任チームつくったり、派遣とかを雇ってチームで回すようにしてったほうが良いと思いますぞ。
きちんと設計するな
堅牢性とか柔軟性とか考えたら負けだ
きちんと設計せずに作れる程度の複雑さがRPAプログラムの上限だ
操作対象アプリのUIが変わって動かなくなっても諦められる程度の労力がRPAで元がとれる開発工数の上限だ
雑に作って雑に使え
RPAツールは現場のリーダーかちょっとした管理者相当がやらされるものだよ
PCOMM使ってるってことはメインフレーム的なホストがあるってことだから、そこそこ大きくてシステムが古くさい物流企業っぽいな。
物流会社の事務員なんだけど会社がRPAツールを導入するってんで定型作業を自動化しろって話しでRPAプログラミングをやらされてたんだわ。
1、実務の合間にやらないといけない
現場がクソ忙しい時に悠長にデバッグとかやってられん。あとデバッグみたいな作業は見た目何もしていないように見えるからここぞとばかりに仕事振られたりする。
2、本番環境とか開発環境とかない。ぶっつけ本番で稼働→失敗→デバッグを繰り返さないといけない。
これは自動化する仕事によると思うんだけど、実際に現場で使うデータをRPAプログラムに投入しないとそもそも要件がわからないことがある。データの特性というか、物流事務なんかだと8割がシステム化されているけど2割は荷主や配送先のわがままで特徴的なデータの不備があって、それに対応するのが事務屋の仕事なんだけど、そういう面倒な作業を自動化しろとか言ってくる。そもそもRPAなんてシステム化のスコープ外の面倒な事務を(金をかけずに)自動化することが目的だから当たり前なんだが。
そうすると要件の洗い出しとかできない。ベテランのオペレーターにはそういうの全部頭に入ってるからマニュアルとか作ってないことが多い。実際新人に教えるときもぶっつけでやらせてわかんなかったら聞けみたいな世界だし。
3、(2)みたいな事象があるからソースコードがぐちゃぐちゃになる。ぶっつけ本番でプレッシャーがある中実行してその場凌ぎの改修して保守性皆無
RPAツールってWindowsのUIをいじって業務を行うプログラムを作るんだけど、結局今どの画面を開いているのかとか、どのエラーが出ているのかとかプログラム上で管理できない。既存のソフトウェアUIがたまたま運良くRPAツールと相性が良ければいいけどそうじゃなければめちゃくちゃやりづらい。特にIBMのPCOMMとかはツールとの相性が悪くて地獄だった。
書かなくてもわかると思うけど、業務で操作するソフトのUIが変わった瞬間にそのRPAプログラムはゴミになる。
(4)に関係するんだけど、RPAプログラムが立ち上がった時のパソコンの状態によって処理速度にムラがあるので、プログラム上このステップまで進んだらウィンドウはこの状態にあるだろうと仮定してプログラムを作ったところ、実際100回のうち99回はそうなんだけど、1回だけ処理がもたついてその状態にならなかったからバグって処理が停止する。みたいなことがある。
もちろんツールではウィンドウが操作可能になるまで待機、みたいなのはあるけど操作可能、全面にある、みたいな粗い粒度でしか状態管理できない。
7、こう言うのをちょっとパソコン得意とかEXCEL VBA かけますみたいなやつにやらせることの矛盾
うまくいくわけない。(4)(6)のところでウィンドウの状態管理とそれに起因するバグについて書いたけど、こういう時RPA担当は一般のプログラミング言語でいうsleepで職人芸的に時間調整するんだぜ？こんなのもう(3Dリアルタイム)ロボットプログラミングでしょ。
結論を言うと2022年の馬鹿みたいに複雑化した物流の事務(そしてそれは主に荷主と物流会社の主従関係によるわがままに起因しているのだが)をRPA化するのは無理だしもうやりたくないね。
技術の進歩により機械的に置き換えられる仕事が減少していくとする。DXとか言って、既存の仕事をデジタルに置き換える側と思っていたプログラマーも、置き換えられる対象になるかもしれない。
よくよく考えると、プログラミングで実現される要件がしっかり固まっているとすれば、プログラムで作られる中間成果はもちろん、出力される結果のチェックだって自動化されてもおかしくない。そうすると、プログラミングの前後、要件を決めることと、成果物の使用者が残る。
使用者も業務の中でそれを使用するだろうから、RPAやらなんやらで置き換えられる。
要件を決める、これが残る。要件を決めるというのは、何のためにその業務を行うのか考えること。ビジネスの中での必要性、コスト、メリデメを精査する。そうしてビジネスの行く先を考える。つまりストーリーとプランを練る人。
そんな妄想。
さすがに20年は言い過ぎだけど
7年ぐらい前からDigitalizationっていうのをやたら言うようになってた。
その辺からDigital Transformationっていう単語が出てきてAIの次はこれだ！みたいになった。
流れとしては
「ビッグデータ解析したら新しい営業ができるぞ！（Amazonのレコメンドが契機かな？）」
→「ビッグデータの解析無理・・・AIってのが使えるらしいぞ！（画像系を中心）」
→「そもそもデータになってないことが多いな・・・業務を全部デジタル化や！」
っていう感じ。
欧米だとデジタル化の意味がよく分かってるから「そもそも20年前からずっとやってた」っていうのが正しい。
その上で「Digitalization出来てない部分をDigitalにしよう」っていう感じなんだけど
日本はそもそも嘘っぱちのデジタル化しかしてないから世界について行けてない。
それをデジタル化するときにちゃんとシステム構築したのが欧米。
「これがデジタル化や！紙がいらんで！」
ってやっただけ。
そのせいでDXってなっても
とかやっててアホかと思うね。
ごめん「障害点が増える」「難易度が上がる」って言ったほうがよかったわ
まさかここでそのあたりまでツッコめる人いないだろうと思ってたんでｗ
多重化をすれば回避できるのはソフトだろうがハードだろうが当たり前のことだけど、
ハードウエアであることによる発見の困難さ、ってのはSDSより難易度が上がるからね
OSを積んでるRAIDカードってのは初めて知ったけどｗ、そんな何百万もするハードはレアな運用になるし、
RHEL・MS・HCIメーカー提供のSDSより圧倒的に情報も少ないからね
ベンダーに言われるままにハード入れて某銀行のようなことが起きる
SDS万能って言ってるわけじゃないけどね
物理的なモノが増えればそれだけ厄介が増えるよて話よね
最近のホッテントリの傾向、昔は正気だったブクマカが党派性に脳をやられてキチガイ化してしまった様などを見るに
「このままこのサービスを使っていては遠くないうちに脳に致命的なダメージを負ってしまう」
と思ったので、はてなを退会することにしたのだが、アカウントが消えても増田は残るのでポンと退会できない。
愚痴ったら「同じ内容を連続投稿すればBANされるぞ」とトラバを貰ったが待てど暮らせどBANされない
仕方ないので色々試行錯誤してみたのだが、ITエンジニアでもないのにテキストベースでログインしてgrep使って一括削除など出来るわけもなく
結局Power Automation Desktopを使ってRPAで全部消した。
鉛筆マーク、削除ボタン、OKボタンの画像を認識させ、詳細で画像の表示待ちのチェックを入れたら、あとはひたすらループを回すだけ。
ハイクが終わった時点で辞めておくべきだったな、と思わなくもないが続けてしまったものは仕方が無い。
増田を全部消したい人は多分他にもいると思うのでこの増田だけは残しておく。
