[RPA]PC自動化技術総合スレ[効率化] Part.3
■ このスレッドは過去ログ倉庫に格納されています
>>421
うちは中間方式だな、
Excel何々フォーマットからA-J列をコピペすれば一括投入出来るよ、
みたいな画面をいろいろ作った
ロジックとしてはTSVファイルのインポートと同じでGUI付けただけとも言える >>423
外部サービス都合で壊れやすい
自社システムの更新を難しくする excelのimportごときに年間何百万も使うのかブルジョワすげえな 付加価値の低い事務作業のために数百万で派遣入れてるような状態に比べればマシだぞ >>417
まさにこれの現場側なんだけど、人手不足という表現が正しいかわからないけど、やっぱり作業に時間取られる事が多すぎる。
でもこんな作業に人は増やせない。
情シスは投資対効果の高いシステム開発メインで、1つの仕組みで30分自動化されますみたいな事まで回ってこれない。
じゃあどうすればいいのさ? >>428 RPA がダメと言ってるのは金がかかりすぎるからじゃないの? python と各種RPAツールを使えばタダでできるからやってみたら? PyAutoGui など >>427
派遣と比べる必要はない
正社員が隙間時間とかでpythonでもなんでも使ってサッと作ればいい
たかが15分や30分の余裕もないブラック企業というわけでもあるまい pythonでもなんでもいいけど
簡単なプログラムすら習得できない学習能力と意欲の低い人材はそれこそ人件費の無駄だな このご時世、管轄外の新規分野を業務の隙間時間に意欲的に取り組んでモノにして下さる人材なんか高望みだよ
「お前の代わりなどいくらでもいるんだ!」と若手を千切っては投げしてた氷河期世代採用と同じ感覚でいらっしゃる?
それはご愁傷様(周囲が) 普段している学習時間の何割かをプログラミング学習に割り当てるだけだろ
たったそれだけのことが出来ないのは普段から全く学習に時間を使ってないからではないかな
社会人として普段から全く学習してないというのはありえないブラック人材だ 新しいことを覚えてできることが増えていくのは誰にとっても楽しい事だよ。
出来れば情シスを少しおだてて、時々見てもらうとかすれば協力してくれるんじゃないかな。
勉強時間を少し取られても将来的に残業も少なくなるなら上の方も認めてくれるだろ。 大規模な工数管理というか人員管理レベルの話なんだから本来は経営層マターなのに、事務部門vs情シスっていう同階層間の抗争になってしまう構造がおかしいわな
なので、責任は一義的には経営層にある それは当たり前
だが、一方で情シスは情シスでなんやかんやリスクや多忙等の理由をつけて守りに特化しがちだから文句言われるんでしょう
「RPAじゃなくてプログラム組め」とか言うけど、じゃあスクレイピング用の簡単なツール作るので年間何百時間浮きます、みたいな攻めの試みはしてないんでしょう もしそういう試みをしてたら経営層もRPAよりまずそっちを考えるだろうし >>422
これ結構良いアイデアだと思う まぁ勿体ないけどね 無料のVBAでプロトタイプ作る方が理想だろうけど、現実的じゃないしな
単にRPA入れるな、よりはこういう戦略の方が生産的かと >>436
真面目に計算したらマイナスなんでな
短期的にはプラスかもしれんがそれは俗に言う技術的負債というものだ >>286
何を目指せばいいのか価値観が多様でわからないから民主主義が採用されているだけ
なにを目指せばいいか明確ならその実現方法は時間的経済的なコストがかからない方が良い
一人でもチームでもどっちでも良い 各部署で好き勝手に作ると狭い範囲で使うには良いだろう
各部署が連携する場合は
ある部署での変更の影響が波及する可能性を考慮しておいた方が変更に強いものを作れる可能性が高い
RPAが頻繁な変更に耐えられるとしたら
そんな考慮は不要かもしれない >>311
excelの処理を早くすると言う解決策も考えられる >>317
ユーザインターフェイスはどうしてるの? >>440
変更に強いとか考え出すと真面目にシステム化してapi提供するとかそういう方向にすすむ
なので使い捨ての雑なバッチ処理みたいな使い方するしかないんじゃねえかな
雑な作りで長期間残るのが最悪なんでこれだけは避けなきゃいかん >>417
情報システム部門って全社的なことを考えているから
一部門に合わせたら全社的なシステムが維持できなくなる心配がある
だから自己責任でやる分には構わないって事だろう
どうすればいいのかは
自分たちがどうしたいのかわからないのに
提案できないんじゃね?
それを調査検討する工数も取りにくいだろう
自分たちで調査検討できない部門が
自己責任で導入したら
問題発生時に自分たちで対応できない可能性が高い
情報システム部門からすると歓迎できないんじゃね? >>444
だから狭い範囲で自分達だけで対応するようなものには適しているだろうね >>190
一度だけ、家の鍋持参しておでん買ってるおばちゃん見たことある UiPath communityって実名じゃないと登録しないといけないの?
ググっても出てこないわ >>311
何のためにPowerQueryとPowerPivotが実装されたのか分かってなさそう >>446
徹底できるならいいよ
でもできないでしょ >>438
長期的な収支でマイナスだっていう量の話したいなら量についてどう計算したのか語ってくれんとな 「俗に言う技術的負債だ」とか言うだけじゃあねぇ
じゃあ技術的負債にならないためにどうするのとかも言わないし 文句言うだけで生産的な話がないんだよな(別にこう判断したからってのがあれば手作業継続にしたとしても生産的だが) >>439
何を目指せばいいか(利潤追求?)が明確だとしても、不明確な点が一杯あるでしょ 理念的に1人でもチームでもいいってのは同意するけど、現実的に総じて1人はないだろうね
1人に任せられるスキルがあるのか、不正しないのか、
レビューどうするのか、評価どうするのかとか
小さい会社で、社長も詳しくて、信頼出来る友人1人に頼むとかの限定された状況ならわからんでもないけど >>417
RPAって現場要望というより経営者要望だろうね 現場で効率化したいって人はVBAやるんじゃないかなと
RPAにせよVBAにせよPythonにせよなんかツールを作る以上、情シスが絡まないって選択肢はないと思う
下手な繰り返し処理とかで基幹システムのサーバダウンとかしてみろよ 仮に事前に各自の責任で使うことって取り決めしてたとしても、そもそもそんな取り決めアホか責任放棄だろとか経営者あるいは外部から言われるに決まってるじゃん
RPAにせよVBAにせよPythonにせよニーズの高いものを厳選して現場と情シスが協力して作るしかないんじゃないかね 厳選するのはどっちか、作るのはどっちかとか細かい話はあれど ニーズが高い、てのもくせ者で、
声のでかいやつ「だけ」が見てる三ヵ月に一回のレポート、誰も見ていない
とかあるよな
声の小さいやつが毎日三回作業してるものは無視とか >>441>>442>>451
>>311のを作った時はまだPowerQueryは無かったし
そもそも会社の環境だとExcelの起動が遅くて閲覧するだけでも時間が掛かるのがまずい。
>>311ではPythonと書いたけど運用はC++で組んだのを使用している。
社内外システムへの入出力が多いからなるべく速度を稼いでおきたいんだよ。
1台のPCで並列処理できるようにしたいしね。
UIはデータファイルをフォームかあるフォルダにD&Dすると内容に応じて処理する物とか
ゲームパッドで開始するとか色々あるかな。
職業柄、常時PCの前にいる訳でもないのでK/Bやマウス以外の操作も取り入れている。 正直、技術的負債っていってるやつも>>422には反対しにくいだろ?
となるとあとの問題はコストか? そうね、コストが安ければ全く反対はない
何千万かけてそんなものを入れるぐらいならエンジニア一人雇った方が安い 事務のおばちゃんがRPA書けるようになればおばちゃんの付加価値も上がるんだが、育てる気はない? おっとこれだとRPAのコストの問題から外れるか。
うーん。 上層部からの人件費削減で派遣二人切った代わりにその半額くらいの維持費かかるRPAさんがやってきて負担が増えたよ!!
ちなみにRPAさん今の所使用用途はないよ!!! >>454
不明確な点って
それが何を目指すか判らないって事
最終的なゴールが同じだとしても
ルートが違えばマイルストーンは違う
技術的な事は
調べる試す相談する依頼するとかで解決するしかない
手段をどうするかはコストの問題 PythonやVBAばかり出てくるけど、他のスクリプト言語で組んでいる人居る?
LuaJITやJuliaはどうなんだろうか powershellもええぞ
.net使えるし、開発環境も標準で入ってる
非IT社員が使うなら検討対象に入っても良いと思う powershell慣れるまで奇異に感じるけどオブジェクト指向とか割とちゃんとしてて慣れればいい感じだよね >>460
RPAの成果物は個人・特定領域に寄りすぎる傾向があるからシステム化の候補とするには向かないだろう
API化の需要を測る程度になら役に立つかもしれない >>460
基本的には賛成 各事務所で同じRPA作ってたわ、それならまとめよう、って感じでシステム化が進められるはず(RPAなしでもできるのが理想だろうけど 各事務所で同じ作業してるからシステム化してくれみたいな)
一方で、懸念点としては必ずしもシステム化向きとは言えない作業(つまり、RPA向きの作業)があるんじゃないか、ってことかな スクレイピングとか転記とかひとくちに言っても、取得先HPとか転記先システムとかに拠るからまとめづらい、みたいな
要は、同じやり方で大量にやるタイプの作業はシステム化向きだけど、似てるけど違うやり方で各自が少量ずつやる(けど塵も積もれば的に全体としては大量となる)タイプの作業はシステム化に不向きだろうと Excelはデータ増えてくるとどんどん遅くなるからな
お試しはおkなんだけどいずれ破綻するみたいな >>467
そんな頭が良い上層部なら真っ当にシステムを更新するんやで………
導入が目的の悪い見本だね。うん。
上層部と業務改革推進なんとかが喜んで買って与えてきた…けど、現場では使うマシンも用意してなければ用途もないのに削減目標だけ先に実行されててんやわんややでー。 >>476
派遣2人の半額っていくらくらいなんかな?
派遣2人にやらせてた仕事をRPAでやる算段だったんだろうけど何がダメだったん? >>475 Excel VBA は、プロトタイプだと理解してれば解決法は自ずから出てくるけど、慣れ過ぎてるとおかしいとも思わないのが危険。 > 現場: 定型業務を自動化したい。RPAでどうだろう?
> 情シス: RPAはダメ。やるなら自己責任でやれ。
情シスが正解
> 現場: なら何がいいの?
> 情シス: 知るかボケ。自分達で考えろ。
情シスが正解
> 情シス: Pythonでも覚えて自分達でどうにかしろ。キレイなソース書かないと許さないからな。
情シスが正解
これが情シスの職責。
おまえら病院行ったら医者の言うことに従わないのか?
法律事務所言ったら弁護士の言うことに従わないのか?
さっさと無能経営者にゴミツール返品するよう言ってこい
それがお前らの職責。 >>474
独立にやってる事業所で偶然同じツール作ってたなんて滅多にない
そんなレアケースのための何百万(いや多事業所だから桁が増えるか?)かけてプロトタイプとかもったいなすぎ RPAと基幹システムでは要求される品質が全く違うから
はいこれプロトタイプって気軽に渡されてもそんなに簡単には取り込めんよ
RPAでは単純な処理がシステム化する際にはそれだけでちょっとしたサブシステム程度の規模になる場合も多々ある >>479
お医者さんならなんで定型業務の自動化してくれないのさ! >>482
だって定型定型って言うけどウソばっかりじゃん、
「あ、この場合はですね」とか
「この客先は、特別でー」とか
後出しばっかでなんにも定型じゃない >>481
RPAでのプロトタイピングから、そのままの動作をするクライアントをVBやPython等と .Net、OpenCV等で作るのは可能だと思う
もしも処理的に問題があるなら却下&禁止する
サーバーサイドでシステム化するのが適切なら、どうぞよしなに
大事なことは、ルーチンワークのリストアップをすると同時に
要件と所在を明確にして野放しにしない
一通り終わったらRPAを用済みにして二度とお金を払わない
ついでに処理速度が上がったり、クライアントのバックグラウンドで動かせれば、なお結構 >>483,>>484
後出しを現場の人たちが自分でやる分には別に構わないはず
どんどん後出しして出来上がったものをプロトタイプとして見せてもらえばいい
プロトタイプも出来ないようなのは放置で >>482 お薬出すだけの定型で済むなら楽だろうな。
そう言えばカルテは皆んな電子化になったけど、口頭筆記はあまり使われていなさそうだな。
アメリカではかなり多いと聞くが。 医師が口頭で言ったものを助手がカルテにすると言うのがかなり進んでるらしい。
事務所の中で口頭筆記なんてしたらうるさくて仕方ないだろうな。 >>485
まあ悪くない
情シスと隔離するのと金を使わないのが大前提
ただそれだとプロトタイプもpythonや他の簡単で無料の言語でやったほうが良さそうだ
金は正式なAPIや他のサービスに課金したほうがお得 >>480
はぁ、「滅多にない」という根拠は?同じ業務してたら同じようなツールになるはず 多少のブレはシステム化で吸収できる前提ね
高い高い言うけど人件費も高いからね 社員一人当たり500万円かかるのはざら 首切れないだろとかそういう単純な話にしなくても、超勤削減とか派遣削減とかの効果をまとめて結果として数人分浮かせるという話も含めてね >>473
>>475
遅いのは殆ど組んだ奴が悪い。
RPAが駄目なのと一緒。
言語のせいにされるのも一緒。 >>489
そんなのはとっくにシステム化されてる
残ったのは地方や人によってことなるローカル最適化された雑務ばかり
人間はロボットと違って柔軟にスマートに様々なことができるので高くついて当たり前だろ
ロボットと人じゃ単純なコスト比較はできん >>485
まぁ基本的に賛成だけど現実的にはなし崩し的に使い続けることになりそう
一度便利ツールを与えられて各自なりの効率化を図った後、システム化できなかったものは取り上げられるわけだけど、そこで(仮に事前の取り決めがあっても)異論が出そう
まぁそれはそれでそこで経営判断をすればいいだけだからなんら致命的ではないけど >>489
そりゃ、組まずに買っただけで何でもやってくれるなら高くないわな。
実際は組む作業、組めるようにする作業が必要。
で、事務のおばちゃんでも組めるなんていうとVBAとそっくりでね。
で、ここでもVBAが遅いとか吐かしてる奴もいるわけだ。
そりゃ組んだ奴が腐ったコード書けばいくらでも遅くなる。
RPAが駄目なんじゃない。
これで夢のような未来があると思ってる奴がアホ。
実際には他の言語と同じように組める奴(プログラマー)が組まないと碌でもないものが出来上がる。 >>492
絶対にごねる奴いるよな
おばちゃん首にしちゃったから動かないと困るんだよ〜今回だけ特別にお願い
みたいな 計画的な合理化を行ってる企業は、とっくの昔にシステム導入してるからRPAいらん。
RPAを使えそうなタスクが多い企業は
無能社員に仕事を与える意味でルーチンを人にやらせてるからRPAいらん。 >>491
RPAというトピック自体がそんなシステム化進んでない前提でしょ まぁそちらの優秀な組織だとそうなんでしょう
「高い」→「単純なコスト比較はできん」ってなんじゃそら
>>493
組む作業はVBAより超簡単超早いという想定だろうね
こればかりは実際に導入したところの体験談が蓄積してこないと話にならないかもな >>493
>RPAが駄目なんじゃない。
>これで夢のような未来があると思ってる奴がアホ。
>実際には他の言語と同じように組める奴(プログラマー)が組まないと碌でもないものが出来上がる。
これが正解
PythonだろうがC#だろうがRPAだろうがただのツール
PythonならOK、RPAはNGではなく、誰がどのように設計して組立てるか、だ まあUiPathとか中身は.Netやしなあ
素のPuthonとどっちが速かったっけか Puthonとか書いてしまった
おいは恥ずかしか!生きておられんごっ!
https://i.imgur.com/VaHMh5P.png 無能な経営者がロボットとかAIが来れば社員の作業量が減ると思ってそうだな。
RPAはロボットらしいから働いてくれるから金を出してもよいが社員には辞めてもらおう、とか。
社員が手取り足取り教えないといけないことを知らずに採用してそう。
うちのRPAはAIがやってますとかいう営業マンにころっと騙されそう。 >>500 携帯からだろ。 俺もそう打ち間違える頻度が半端じゃない。 だけ打ち間違えるんだな。 >>477
月ひゃくまんくらい。シナリオ作成と実行ワンセットね。
シナリオ実行するだけでも一台あたり10万とかかかるっぽくて一台にまとめないと使えない。
データ打込みの定型業務やってる扱いになってるけど…(言うて派遣半人分の作業量)
データ自体は社員(派遣も一緒に)がゼロから作る品物だから、構成表と打合せで済んでたのを
しっかりしたデータパッケージに落としこんで正確に作る必要が出た。 >>504
RPAは何を使っていたの?
UiPath? Blue Prism? WinActor? >>497
VBAも超簡単なんだよ。
「マクロの記録」で、操作を記録してくれる。
でも、それを元にしたコード見せられるとウンザリ。
大昔に、そういうコードをメンテナンスする仕事をしたことあるが見た瞬間に全部消したくなる。 >>505
ういんあくたーだね。
別部門の上層部の方々はJavaアプレットで動いてるシステムの自動化に適用できるつもりだったらしい(多分その上層部システムを触ったことすらないと思う) >>504
月100万円か これは貴重な体験談だね
実行するのに1台10万円ってのは使いづらいね
意外とシステム化進んでて定型化できない業務しか残ってないって感じかね にしても経営層が現場の意見聞かずにGOしたのかねぇ いや、vbaは如実に遅いでしょ…
コンパイル言語に書き直せば10倍とかの差がでるよ >>506
VBAはマクロの記録があるから超簡単って言う人よくいるけど、仰る通りマクロの記録なんかじゃ使い物にならんわけでしょ?
それなら、VBAは超簡単なわけではない、とみなした方が良いのではといつも思うわ >>507
ありがとう
WinActorは不器用なのに値段がするからね
UiPathなりBlue PrismだったらRPAに対する感想も違ったかも
NTTデータの知名度でWinActorを選定してしまった会社はホント可哀想 >>510
その通り。
だからRPAも...
という話なんだな。 >>512
GUIの操作を記録するマクロの記録とRPAにどう類推が成立してるんかね RPAはVBAにおいて(コードを打つのではなく)マクロの記録に相当するってわけ?
むしろRPAは素人を初級(基本的な構文を覚えたレベル)までブーストしてくれるイメージなんじゃね >>504
ライセンス数はどれぐらい買った?
末端のおばちゃんにも行き届くぐらい開発者ライセンスを買ったのか
チームを組んで少人数分の開発者ライセンスを買ったのか >>508
システムが独自開発品で
設計が悪く自動化にトコトン向いてないのが実情
業務改革的な部門が導入決めて各事業部門に使えって押し付けてきた感じね
現場の声は初期コスト高いけどシステム一新してくれだよ
>>514
1部門で開発実行一式のみだなー。効果でそうなとこだけ、実行のみのライセンスおばちゃんに配る感じ。
開発側を触る人は限られてるからほんしつとはずれてるし明らかに投資効果には見合わないって感じるね >>515
おー、ありがとう 体験談はありがたい 絵に書いたような失敗パターンっぽいね
・システム側の改善が望ましいが場当たりのRPAに手を出す
・誰でも開発できる謳い文句のRPAで開発権限が限られる(まぁこっちは限定した方がいいって言う人も多そうだけど)
上が現実見れてないっぽいから成果出てないとかシステム改修しろとか言うのも怒りそうやし仕事だけ増えて地獄やな >>515
1ライセンスで事業所内の何人でも何台でもOKならRPAの構想にマッチするのにね
おばちゃんとパソコンの数に依存して金がかかるんじゃ本末転倒
ベンダーはライセンス料金をスケールによらず固定にすべきだ BluePrismだと1ライセンスで何台でもインストールは出来るけどね。
同時に立ち上げられるのは一台だけだけど、時間をずらせば別の社内PCやサーバーで
別タスクを走らせる事が出来る。
3ライセンスあれば、実行用と開発用には使えるかな。 >>513
比較がおかしい。
RPAはVBAに相当する。
だからおばちゃんが簡単に組めるなどというマクロの記録に相当するような組み方じゃあ駄目と言ってる。
素人を初級までブーストしてくれるってのはマクロの記録が正にそれ。 >>519
マクロの記録に相当する組み方?
これ埋めてよ
VBA=RPA
マクロの記録=
初心者によるコード作成=
プログラマによるコード作成= VBAっつってもExcel VBAとWord VBAでしか通用しない話なんだよなこれ >>518
同時に立ち上げられるのは1台だけって面倒やねえ
スケジュール実行にする場合はいちいち被らないように社内調整しないといけないし、トリガーを人力(ボタンクリック)にする場合はたまたま時間帯が被ってたら実行できないのか
トライアンドエラーで気軽に実行と修正を繰り返せるのが売りだと思ってたんだが、それも占有しすぎで怒られたりするんかね >>520
これまでの話で分からんの?
厳密に言えばそれぞれが完全に一致するわけじゃ無いけど。
マクロの記録のような初心者のコード=素人のおばちゃんが作るようなコード
プログラマーによるコード作成=RPAのことをよく分かってる専任のプログラマーを高い金で雇ってコード作成 ■ このスレッドは過去ログ倉庫に格納されています