  |
はてなキーワード: RPAとは
いわゆるOA分野とか、コンピューターを主に使用する作業の、自動化が流行っている。
製品で言えば、RPAとか、ノーコード、あるいはSaaSやパッケージソフトとか。
OfficeについてるVBAを使うとか、Pythonでスクレイピングとか、そういうのも併せて。
いわゆるマクロ的な何かで、タスクを自動化する、という考え方だ。これは昔からあったとも言えるし、製品や方法論がここ数年、急激に増えて、環境が激変したとも言える。
さて、個人が、その責任の範囲で、自己のタスクを自動化するのは、組織が禁止しているやり方でなければ、それについてとやかく言うつもりはない。
問題は、組織内部での自動化の推進や、それを補助するコンサル、あるいはソフトウェアのメーカーやベンダーだ。
すべてが駄目というわけではない。
「自動化で単純な作業から解放されて、クリエイティブな作業をすれば良い」
言い換えよう。今挙げたようなことを言う（書く）メーカーやベンダー、あるいはコンサルから個人まで。それらは皆、地雷だ。関わってはいけない人だ。
====
何故か。それは彼らが現実を見ていないからだ。そして、その現実を見ていないことが、軋轢を生むからだ。もしかしたら現実を見た上で、しらばっくれてる人も居るかもしれないが、タチの悪さは変わらない。
困ったことに、彼らの言う「単純作業から解放されてクリエイティブな仕事を」は、一見、理想的な環境に見えるのだ。
いや、実際、理想的ではあるのだ。現実的でないという問題さえ目をつむれば。
「世の中には2種類の人間がいる」という、使い古されたレトリックを、労働分野に応用してみよう。
すなわち、言われたことを淡々とやり続けることを好む人と、抽象的な指示や課題に対して、具体的な対応を行うことを好む人だ。
もう少し具体的に書けば、「言われた作業を淡々とやる人」と「創意工夫して結果を出そうとする人」になる。
さて、前者の、言われた作業を淡々とする人にとって。自動化は、己の存在意義と競合する。つまり、自動化されてしまったら、仕事がなくなる。
意識の高い社員や、コンサル、ソフトウェアのメーカーやベンダーの言うような「クリエイティブな仕事」なんて興味がない。
そういう人を「意識が低い」「生産性が低い」と卑下するのは簡単だ。だが、それは何も事態の解決にはつながらない。
単純作業の自動化がなされた時、その人たちに襲いかかるのは、「クリエイティブな仕事」という、安定した手順も方法論もなく、それでいて成否は存在する、という苦痛のような仕事への移行なのだ。
そして少なからぬケースで、単純作業を淡々と行うことこそ仕事、と捉え、そう働いてきた人は、クリエイティブな仕事とやらでは成果が出せない。ただ苦しむだけになる。
おそらく組織としての生産性は上がるだろう。それをもって成果とするなら、それはそれで矛盾はない。
ただし「働き方改革」のような題目を掲げて、自動化を進めていたのであれば。それは善人面をして、人を地獄に蹴り落とす所業だ。本稿のタイトルで「信じるな」と書いたのは、まさにここにある。
この話には、日本の雇用に関する、法律、行政の態度や、判例なども影響してくる。
前述したような、単純作業を奪われ、苦痛に満ちた苦手な仕事にたたき落とされた人は、どうなるか。
第一に、会社を去るという選択肢はある。だが、このご時世だ。今と同等の条件すら見つかるかどうかは怪しい。
それを自業自得と嘲笑するのは簡単だ。改善を肯定し、生産性の向上を是とし、発展を求める価値観からすれば、矛盾はないのだ。それが倫理的に正しいことなのかは、私にはわからないが。
第二に、苦しみながら会社にしがみつくという選択肢もある。正規雇用の場合、これが簡単に成立してしまう。「クリエイティブな仕事」をさせた成果がボロクソに悪くても、本人の意図的な手抜きなどがない限り、会社は簡単には社員を解雇できない。
はて、本人も苦しんでいることが多い、機能不全の社員を雇用し続けることが、生産性の向上や、働き方改革、ワークライフバランスなどにつながるのか、私は甚だ疑問だ。
つまり、業務の自動化、省力化を目的にするのは、それ自体が破綻を招きやすいのだ。それで浮いた人的コストを、どのようにするか。適材適所で別の仕事をあてがえるのか、あるいは解雇して雇用コストを削減するのか。
どうあれ、簡単なことではない。配置転換の教育コストを見積もるのは簡単ではないし、非正規だからと大量に解雇すれば、それだけで負の風評が生まれたりもするのだから。
人は、自分と異質な人に対して、理解が及ばないことがある。これ自体は仕方が無いことと言える。誰しもがわかり合う、なんてのは現実的ではないからこそ、フィクションで度々取り上げられる題材なのだ。
しかしながら、業務の自動化を改善と捉え、自身が単純作業を嫌う人の中には、少なからぬ割合で、単純作業を延々と行い、その労働時間を以て成果となす考え方の人を、理解していない、あるいは想定していないケースが多い。
その不理解や想定不足は何を生むのか。自動化の導入失敗や、同僚からの強い反発だ。決してプラスの結果ではない。その現実から目を背けてはいけない。
だからね。
「単純作業から人を解放したい」とか「空いた時間でクリエイティブな仕事ができるようになる」なんて、手放しで言っていたら。
その人たちを、信じちゃあいけないよ。
蛇足。
筆者は、別に、「単純作業を淡々とやることで鬻ぎたい人」を肯定するつもりはない。
少なくともデスクワーク、パソコンでの仕事等であれば、そういった人は滅びるべくして滅びるだろうと考えている。
だが、彼らに引導を渡すのは、個人や、少人数程度による「カイゼン」的な何かではない。個人や少人数による「カイゼン」が引き起こすのは、せいぜいが内部分裂や、一部の人に苦痛を与えるだけなのは、前述した通りで。
引導を渡す、という次元の話で言うと、おそらくは、そういった非効率的な人員を抱え込んだ組織の崩壊（企業で言えば倒産など）のような、圧倒的かつ、個人で抗うことに意味がない流れになると考えている。
もちろんその場合、多くの社員が路頭に迷うだろう。クリエイティブな仕事がどうとか言っていられる状況ではなくなるのは明白だ。
そういう未来が見えているからこそ、ミクロな視点でしかモノを見ずに、「自動化で業務を改善して～」「クリエイティブな仕事を～」というおためごかしを唱える人には、関わってはいけないと考えているのだ。
ここでもよく職場の不満日記を目にするけど、たいてい仕事が増やされたとかそういうのが多い。
基本給10万、他は抱えてるタスク作業ごとに何万円、ってすればいいじゃん。
タスクが終わるなら何時間かけてもいいし、何時間休んでもいい。
これ究極じゃん。
あの人はあれだけもらってるのはタスク多いから当然だ、って納得するし不満もない。
あの人は家庭の事情でタスク少ないから給料も減るしみんな納得。
これでみんな納得で仲良しな職場になる。
今も使われてる「なんちゃら手当」だけにするイメージ。
ベースサラリー＋顧客Ａ見積作成手当＋顧客Ｂアフターフォロー手当、みたいな。
＜追記＞
手当が大項目だけだと、
顧客Ａ対応手当と顧客Ｂ対応手当は、規模が違うのに不公平じゃん！となる。
それさえしっかりできてれば、
まあこれができるのはせいぜい数百人規模の会社までかなあ。
＜追記２＞
https://youtu.be/iGZUJLjtGWo?t=213
＜Q＆Aコーナー＞
世の中のサラリーマンってそんな同僚の給料とか仕事量とか把握して
5000円でも違ったりするとギスギスする。
中途で入ってきて、役職が高かったりすると、まず古参の平社員とトラブルになる。
「なぜあいつのほうが多いんだ！」というのは、判断基準がクリアじゃないからで、
もしそれをクリアにできれば、
究極の民主主義じゃん？ってことで書いた。
基本は同じ発想ですよ。
営業マンと開発・間接部門がギスギスするのはコミッション性と固定給制の違いも一因としてある。
少なくとも不公平感がなくなるかなと。
これは書いた直後に思った。
少人数だと談合とかが起きるのは明白で、だから全社で透明にするしかないですね。
あと、給与も全員オープンにすることが前提となるので、まずそこがイヤな人は入ってこないから、
そういう人材がキックバックとか談合を好むとは思えない、ってのはあるかも。
「自分は今月これだけのタスクをやったので給与アップを希望します」
って言える人が入ってくる。
これを公平に達成するには、一社だけだと厳しくて、絶対にブラックボックス化する。
タスク内容を国レベルでオープンソースにしないとだめかもしれない。
ああいうかんじ。
「Ａ社ではこれこれタスクを〇〇円でやってました～」って実績で活動すれば、
「ウチでは〇〇円ですが大丈夫ですか？」みたいな。
それこそ資本主義じゃない？
「本日は良いお日柄で・・・」「趣味はなんですか？」「ｱﾊﾊﾊﾊ…（ちいかわ）」
そこでオープンソース化ですよ。
JDに書かれているタスクと募集職種でだいたい平均値に収れんしていくはず。
同業種で業務内容がめちゃくちゃ違うなんてことはないんだから。
まとめたら国が基準として発表する。
今までになかった新しいタスクの時にどうするか、は、
それをベースに毎月全社員で固定タスクの単金に落とし込んでいく、みたいな。
そのために、参考にできるオープンデータ（勘定項目）みたいなのがあればベスト。
50項目も抱えてれば、明らかに給料高くても誰も文句言えない、みたいな。
むしろ「この毎月発生してるトラブル解決タスクはなんですか？」と、
突っ込まれてやりづらくなりそう。
すべてガラス張りのタスクになるから、闇でやるのが好きな人はいろいろ不都合感じそう。
まあ実現性はともかく、
「スキルの希少性」は、その人の財産になるのでは？と思ってる。
今の正社員システムは、スキルの希少性がない人ほど、転職できなくなる。
他社で使いまわせないから。
逆に会社としては都合がいい。
とがった人材を作らせない。
これで飼いころしにできる。
成績表の英語数学美術体育でオール3の人材を作る。（忠誠度だけは5）
これがほとんどの会社員の、「月曜日に仕事にいきたくない病」の、
遠因なのではないかな？と思ってる。
今回は、どれかを5にしてほかは2とか1でいいという案ね。
タスク量を定量評価して、人事に反映させるのが上司の仕事なんだけど、日本の場合は給料払えば定額使い放題と思ってるから、優秀な人間の評価ができない。お金を稼ぐには残業。優秀かどうかは能力ではなく（時間）
ある意味、処女を開発して洗脳させるのが新卒採用だからなあ・・・。
経営者には都合がいいのだろうけど。
時間給だと、どうやって一つのタスクにかかる時間を延ばすか、にスキルポイントを振ってしまうのはあると思う。
結果として、その人の能力50%も使ってないってことになるのでは？
JDを明らかにして、その人が意識的にスキルをチョイスしたほうが、長期的にはいいと思うけどなあ。
完全歩合制みたいなの考えたりもしてたけど、結局それやりだしたら無能が弾きだされるし、
効率最優先になって、どんどんいらない仕事が減っていく（失業者だらけになる
そろそろおかしいんじゃね？と気づいていいんじゃないかっていう。
まあ効率最優先になると、国レベルでどんな弊害が出るかもしれないし。
なので10万円っていうのは、ベーシックインカム・セーフティネットのつもりで書きました。
まあAIやRPAが発達すると、多かれ少なかれそっち（効率優先）の方向になっていくのかと。
そういうことができなくさせるための仕組みづくりが、今回のアイデアって感じですね。
民主主義を捨てると何が起きるかってことが。
ほかの社員への協力というのもタスク化されるから、それも成果として可視化される。
あと、このモデルが仮に実践されるなら、教育も必要なくなると思ってる。
最初からタスク内容が100%分かって入ってくるのでミスマッチがない。
風通しについては、
給与とスキルデータが全社員に可視化されるから、全員スケルトン状態。
誰もやりたがらないタスクは少しずつ対価が値上がりしていく仕組みとか試してみたくはある
これは思いつかなかった。
これができれば究極だよね。
明らかなブルシットジョブでも、誰もビッドしなければ値上がりして、最終的に誰かが食いつく。
MSはバルマー時代にこういう評価制度を導入したら皆が自分の短期的成果に繋がる仕事だけする状態になったので、ナデラCEOが「他メンバーの評価に貢献したら評価ポイントがつく」という制度に改革したという逸話がある
「マネージャが自分の仕事やキャリアを助けてくれる」のあたり。
https://www.publickey1.jp/blog/22/1_regional_scrum_gathering_tokyo_2022.html
そんな回りくどいことよりやっちまえよ、セックス
やっちゃえ日産
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やるにしても、専任チームつくったり、派遣とかを雇ってチームで回すようにしてったほうが良いと思いますぞ。
