[RPA]PC自動化技術総合スレ[効率化] Part.5
■ このスレッドは過去ログ倉庫に格納されています
実際、ルーチンワークが1時間/日浮いたら相当うれしいだろ?
それがわからんてどういうことや? >>403
官庁は一太郎だろ
何も知らんくせに知ったかは恥ずかしいぞ 1時間/月かと思って皮肉かと思ってたわ
1日なら相当な効率化やんけ!かつストレス脱却!素晴らしい! 1日1時間位が丁度良い塩梅なのかもなー
あんまり効果ありすぎると、じゃあ仕事まとめて人減らそっか、と経営者が考えそう >>404
UIテストのように数日かかる手作業が自動化できるとかならともかく毎日1時間ぐらいじゃ今更なんともって感じ
しかも完成に1ヶ月もかかってるからその間にどれだけ工数を損したか考えると心が苦しい
毎日1時間の単純作業があると気付いたらその日のうちに自動化しないと >>408
1時間/日だと稼働20日×12カ月で年間240時間削減
試行錯誤込みで開発1カ月なら順当な所
自動化の横展も効けば◎
後は今後の業務の洗い出しで、似たような内容はノウハウが生かせるから
開発工数は基本的に早まる(初期開発は基本的に手探り状態だから絶対に時間かかる) 自動化に成功すると、次々に別の仕事がわいてくるのが日本の実情
労働時間は短縮しない 408頭沸いとるだろ
そもそも1ヶ月てスキマ時間にやってて開発専属じゃないだろ よりクリエイティブな仕事に従事できればそれだけで成功なんだぜ? 一ヶ月あるなら、最初の三週間でpythonをみっちり仕込んで、残り一週間でサクっと自動化かな
後々のことも考えると、これが最も価値の高い一ヶ月になる
>>410
確かになー
紙とペンの時代から今まで、人類がITでいったいどれだけの時間を削減したか検討もつかないけど、人類は未だに大忙しだ
下手すると昔より忙しいんじゃないか >>412
いままで単純作業に異を唱えず、甘んじて受け入れてきた人たちに、いきなりクリエイティビティを求めても・・・
正直、悲しいけど、リストラしかないと思う >>411
しかも、(気づいたらその日のうちに)自動化するって言ってるのに、今更なんともって…
ベストじゃないと絶対に認めないマンかな >>415
1時間の単純作業があるなら当たり前のように気付いたその日のうちに自動化して
自動化したらたかが1時間のことなどたいしたことはないので忘れていい 1時間/1月で評価されて、正直驚いた。ちょっと上司にマウントとってきます。 1時間/日 稼働20日×12カ月=年間240時間削減
1ヶ月で開発=160時間
単独稼働させたとしても8ヶ月でペイできるんだし普通に成功だろー
同じシナリオを10人で使いまわせるなら年間2400時間の削減だし1ヶ月も運用したら余裕で元取れる
1日12.5%の削減はでっかいよ その計算には重要な要素が抜けているね
ロボットによって手が空いた人員が以前と比べて全く劣化なく同じ成果を出して初めて1日1時間の作業を削減できたと言える
極端な話ロボットが動いてる間に人がサボったら全く削減効果が無い場合と同じ数字になる
そして急に仕事をロボットに取りあげられた単純作業員が別の仕事で同等の成果を出すことは非常に難しい ロボットを楽しそうに眺めるおばちゃん
こういうことだな
ロボットが1時間働いてる間このおばちゃんは何もしていない
しかし1時間分の賃金は相変わらず発生している >>420
ばーか
空いた分の時間と労務をどうするかの責任は
削減担当者になく、経営者や上司にある >>423
責任の話は誰もしてない
>>419にような皮算用は非現実的であると言ってるのだ 無根拠のイチャモンw
可能性を指摘するだけならなんとでも言えますわ
これでまともなこと言った気になってるってやばいな >>425
レス番がないけど
無根拠というのは>>419のようなレスのことを言っているのだろうね
この計算式はおばちゃんがロボット導入後も導入前と同じ生産性を発揮する(しかも今まで長年やってきたのと違う作業内容で)という前提がないと成立しえない
しかしおばちゃんがそのような生産性を発揮するという根拠は確かにどこにも提示されていない このスレの人はどうも数字にばかり興味が寄ってしまってる
計算モデルの妥当性や測量法などを軽視しすぎる傾向があるね
数字のトリックで騙されやすいタイプだから気をつけた方がいい
もっと抽象的・定性的な議論の経験を積んだ方がいい 毎月Excelを元にしてデータベースへ入力する作業があるんだけど
それをUiPathでやらせるようにした
二人で3日くらいかかっていたのが全自動になったのは嬉しいけど
それ以上に人がやることによる入力ミスが激減したのが一番でかい >>429
ExcelのフォーマットにおさまってるならRPA使わずにでも出来るのでは??
例外処理が多いのか? >>430
データベースへの入力をどう想定したか疑問だし、それしか想定できないのかも疑問 >>429
それデータベースから、エクセルファイルのシートをインポートかリンクで取り込めば
そのままデータとして使えるだろ >>428
最高のバカ
例えば今まで毎日残業2時間かかってたなら
残業1時間に減る
別に新しい作業を与えなくても効果が100%の一例 >>433
毎日2時間残業が当たり前のような異常で特殊なブラック企業も確かに存在するだろう
しかしそのようなイレギュラーな企業を前提に議論するのもおかしな話だと思うが? >>432
誰しもそう考えるし、確かにExcelからのインポート機能もあるけど
ものすごく中途半端にしかインポートできない仕様なんだよ
インポートした後に登録データを呼び出して修正する手順も凄く面倒だし 【みんなで応援しよう!】ついにハッカーVtuber 黛灰 がデビュー!!!!
情報学のエキスパートが豊富なPC知識で皆んなを虜にするよ!
7月28日(日)の22時20分〜23時に初配信!
みんな見に来てね!!
https://twitter.com/mayuzumi_X
https://twitter.com/5chan_nel (5ch newer account) >>432
それではアプリケーションが担保しているデータの整合性などが失われる可能性がある
最終的にはサイト構造によるが、この手の処理はPowerShellを使うのが簡単 プログラミングでできるのは当たり前で
重要なのはノンプロでも、自動化できた点だろ ベストじゃないと文句言いたがる奴ばっかだな
社風上司スキル等々、諸々の現状のもとで改善できりゃそれでベターやん 過去にベストを目指さなかった結果が今の手に負えない技術的負債システムに繋がった
妥協は停滞に繋がり停滞は相対的な退化に繋がる
経験から学ぼう RPAって所詮つなぎの技術だと思うんだがある程度の期間主流になる可能性あるの? 口だけで他責するでベストに導けなかった不甲斐なさなんじゃね 経験から学ぼう
つなぎ論ってここだと多いけど、通常のシステム化だと採算が取れない細かい業務が主戦場だから、今後も続くんじゃねえかな 守備範囲が違うから >>443
RPA自体は、「非プログラマによる定型業務の効率化」を目指す技術なので、今後も継続的に使用されるものだけど、現状は「非プログラマによる」って部分が不十分なので、「今のRPA」はつなぎだと思う。 問題は繋ぎのつもりで作ったロボットがいつまでたっても除去できずにシステムの発展を妨げる恐れがあるということ >>445
なるほど
ERP等がどんなに進化しても、拾いきれない業務はなくせないからね
>>446
大昔に初心者の頃にやっつけで作ったマクロが、未だに現役だったりするからなあ
拡張とか仕様変更一切考慮してないから、融通がきかなくて逆にボトルネックになってるけど、とりあえず動くから使ってますみたいな RPAへの配慮が必要でUIの変更に大きな負担が掛かると考えるとかなり厳しい もし某Rubyの人がRPAに興味を持って
自作RPアプリをRubyで作り上げたら システムの発展を妨げるのとrpaを一緒にしちゃいけないんじゃない?
erp導入でそもそもrpaを使った業務が無くなるかもしれないんだし erpとrpaじゃハードルが全然違うぞ?
erpは導入めっちゃ大変。 そりゃ、Amazon, Google, Heroku も、Ruby をサポートしてるから、
AI 以外は、Rubyが一般的
書き込めないので、全角に変換した ある画面を使うロボットをつくると
その画面を改修するときにロボットに配慮して慎重に改修しなければならない
その画面を使うロボットが増えるほどに改修が難しくなる
日本の業務システムは残念ながら品質が低い
本来なら分離したほうがいい画面ロジックとビジネスロジックが密接に絡み合っている
なので画面の改修が難しくなるとビジネスロジックの改修も自動的に難しくなってしまう
そしてビジネスロジックの改修が難しくなるということは業務改善も難しくなるということだ
なぜならビジネスロジックは業務を元として作られるのだから元になる業務が変わったらビジネスロジックも改修しなければならない
業務改善したいがビジネスロジックを変えねばならない
ビジネスロジックを変えたいが画面ロジックも変えねばならない
画面ロジックを変えたいがロボットにガチガチに抑え込まれて簡単には変えられない
とまあこういうことだ
とはいえこれはロボットを大事に保護する場合の話
ロボットはいくらぶっ壊れてもOK
事務員さんの自己責任で壊れたロボットをせっせと作り直してくれ
情シスはロボットにはいっさい配慮しない
このスタンスを最初から最後まで貫けるなら大丈夫 >>419
リースのPC 開発用1+10台
ライセンス 開発用1+10台 を加えても経費削減に十分になる?かな? Uipathの環境依存度高すぎて内政のシステム担当がいらついていてつらい。 定期的に浮上してくるプログラミングの方が簡単おじさんと数字のトリックおじさんジワるからやめて Uupath使い始めて一週間の素人だが、
これで作業時間の計算をuipathで一つずつやらせるより、
関数で計算結果を作業セルに出させるエクセルに貼り付けた方が、簡単で早いんじゃないか?
一応、他のシートにあるテーブル参照して係数呼んできたりもできるし、セルを再計算させてもエクセルの方が一括でできて速い
ただ、時間と日付はuipathとエクセルが勝手にフォーマット変えたり、アクテビティによって形式が違ったりやり難い いっそCSvに保存した方がいいのかね なんか分かりづらいな アドバイス欲しいという意図なら「現状どうで、改善をどうしたい」をもっと詳細に書けばしてくれると思われ
不透明だが今の書きぶりだとuipath使うまでもなくexcelの関数とかデータ形式で対応できそうに見える気がする >>458
すでに他のプログラム言語を知ってるならそっちでやったほうが良いよ
プログラムを知らない全くの初心者が初めて開発するならRPAという選択肢も有る
実際に簡単ということはないのだけどGUIで開発できるから簡単かもと思わせることは出来る
なので挑戦するときの心理的な抵抗感が少ないことは確かでこれは優れたポイントと言える uiparh使ってるけど、エクセルはマクロ推奨だよ
簡単な入力はできるけど
入力内容は関数とかで計算結果はあり RPAは自動化に最低限必要な部品が最初から揃ってるってのもポイントだと思う
簡単なものなら業務手順通りアクティビティ置くだけで成果物ができちゃうからモチベアップにも繋がるよね
変数、条件分岐、繰り返しーとかのロジカルな領域になると普通のプログラミングと一緒だから学習難度としてはあんまり変わらないかもね DIYが非現実的とわかったから今後は外注が増えていくだろう
専門家目線で快適な開発環境を提供できないベンダは売り上げ厳しくなるだろうな
UiPathがVisualStudioをサポートすれば有力な候補になるのだがなぜサポートしようとしないのか >簡単なものなら業務手順通りアクティビティ置くだけで成果物ができちゃう
さすがにこれはまだお目にかかったことない
どんな業務なのだろう >>458
釈迦に説法かもしれないけど
まず、EXCELと人手でやる方法を手順化する。テンプレート用ブックを用意したりもする
その後、その手順どおりにEXCELをUiPathで操作するようにする
出来たEXCELからデータを拾ってパワポなり何なりに貼り付けるのも同様 >>465
それダサいからいやで、CSVからデータテーブルに
取り込んで、その中で計算や並び替えを高速にやって最後
エクセルやCSVに出力したい
エクセル開いてコピペやらせたりとかWinActorなら抵抗ないがUipathではもっとスマートにやりたいやりたい
ってところであまりデータテーブル内でやれることは少ないと午前中判明
午後からはエクセルに吐き出して計算させて取り出す方式にする
ストレスで禿げそう エクセルに取り込むと時間を勝手に形式変えるからいやなんだよなぁ >>466
だって埼玉だもんって言われてもRPAツールの本来の使い方なので
不得意なことをやらせればはげるのは当然
EXCELがイヤならルビーで参考書(紙)片手に半日程度でつくってUiPathから蹴るか
いっそネットからパールのテーブル処理、集計、統計のサンプルを引っ張ってきて蹴れば
おしゃれではげなくて済むけど
UiPathだけで完結したいならしょうがないのではげて下さい >>466
それならPowerShellでいいと思うよ
無理してRPAにこだわる必要はない
なんだかRPAを使うことそのものが目的なっちゃってる人が多い印象を受けるね >>469
違うんだ
カッコ良くやりたいんだ
プログラムをやりたいんだ俺は
高速な処理を!
ぽちぽち1セルずつ基幹システムに入力させて
4時間とかいやなんじゃ
どうせ VB.net使うならプログラミングやりたいんじゃ >>466
uipathでエクセルなんて間延びして全然おしゃれじゃないぞ
マクロの記録でもしてそれ起動させるだけの方が簡単だぞ >>468
パールは学生の時かじったけど硬派な感じでいいわ
コボルとか
いやーわかってるねん
薄々感じててWinActor使ってた時は
コピペとかファイル操作だけやらして、
計算とかはエクセルにやらしてた
だって、関数入れときゃ複数のセルの計算一瞬で終わるし、
アクテビティもほしいのがなかったりしたし
でも、おっそいのよ
UIPATHは高度なこともできると
聞いて使ってみたんだけど
こいつで計算やら何やらまでってのは
やっぱり使い方間違えてるのね
本当のところ聞けてよかったわ
どこもかしこも、いいことしか言わんから
経営者が前のめりで辛い >>471
知ってる
でも、マクロの保守費用の見積もりと請け負う会社が少なくてやっぱりマクロはあかんなみたいな流れになっとる社内で。
個人的にはきちんとドキュメントとか整備したり、
変数名やフローをわかりやすく作らなかったら
VBAでもなんでも理解しにくいと思うんだよな
RPAでグラフィカルだから保守しやすい
と思ってるんだろう
しかし、ど素人がUIPATHはきついわ
変数型やメソッドが一から覚えなきゃならんし
エラーメッセージは意味わからんし
どこが事務職でもできる!や
うちの事務所では俺とシステム課意外無理や
俺も禿げ始めてる >>469
会社の命令なんだ•••
好きでやってるんじゃないんだ
みんなバブルに踊らされて
年間は100万以上払うことになるけど
元がとれるのは何割の企業だろ
うちはおそらく無理
一つロボット作って事業所全部で利用できるとか
じゃないとむりや
おばちゃんが月末1時間かけてやってる仕事の
ロボ作ってどうするんや••• これ営業にほっぽり投げてやらせる難易度じゃないやろ
エクセルなんか関数に詳しいだけでマクロなんかコピペ
なのに社内じゃパソコンの大先生扱いでRPA専任になってもうた
田舎のしょぼいゼネコンもどきには
VBAやらロケットマウスやらで十分なんだと思うよ
導入に至らなかったら俺の責任になるんかな••• ワークフロー系のシステムってのは本来なら粒度の大きなブロックを組み合わせて業務フローをモデル化するための道具なんだ
RPAのように細かい処理をワークフローでやろうとするのは実は正しい使い方ではない
細かい処理はプログラミングで作ってカプセル化する
ワークフローはそれらを組み合わせて大きな全体の流れを定義するために使う
というのが王道なんだ
ワークフローはクリック1つとか代入1回とかセル1つとかそんな小さな粒度で書くべきものじゃない >>476
客先からの伝票類のOCR絡めると途端にセル同士の細かい作業出てくるんだが、そもそもRPA以外で下処理すべきで正しいんやな だいたい安心して気が済んだわ
ありがとうありがとう\(^^)/ 結局フリーターや外国人を安く買い叩いて
作業させた方がコスト削減になるって落ちかもな https://www.meti.go.jp/policy/anpo/kanri/catch-all/frouzu.pdf
RPAの前段として、この類のシンプルな論理フローって、
ホワイトカラー職で働いているリーマンなら作れると思って良いのか? >>473
わいも事務職ど素人やぞ
同じく変数、メソッドと必死学んでる最中だ
エクセルも同じく壁にぶつかってるけど基本的には出力したデータを別のシートにペタっと、貼れば本番用にできるように関数で調整するくらいだと思ってる 素人DIYなんてやめて外注すればいいよ
本格的なシステムを作るわけじゃないんだから外注しても大した値段にはならない
それに1時間/1日でも削減できれば外注に払った分はすぐにペイできる >>480
作れると考えていいと思う
もちろんフローの書き方は覚える必要はあるが、おばちゃんでも料理作るときに頭の中でフローが描かれてるようなもん
たから、おばちゃんでも誰でも、よほど頭悪くなければフロー書けると思ってる フローが書ける≒プログラムが書けるだぞ?そんな甘くない。 >>487
≒なわけがない
≒なのは、プログラム書ける人から見たときの話 プログラム書けるけどフロー描けない人いっぱいいるし どっちもかけるけどフロー描くのめんどくさい人なら沢山いる
テキストの方が遥かに楽だからね とりあえず、Uipathは普通にプログラミングと変わらないから事務職でも出来るという幻想は捨てて欲しい。もう無理だよ… 事務職でも出来る(出来るとは言ってない)のがRPA 事務で苦しんでる人へのアドバイスだけど、まずは変数をしっかりと理解する所に時間を使うべきだよ
プログラミングでもRPAでも共通する話だけど、変数って全ての土台となる考え方だし、ここがしっかり理解できないと後々絶対詰まるんだよね
なのにRPAってなまじレコーディング機能とかでしっかり変数を理解できてなくてもシナリオ組めちゃうからいざ自力で1からシナリオ組む段階になるとコケやすいんだと思う
教える人も、まさか変数が理解できてないとは思わんから教えても教えてもなぜか理解してもらえず結果、教師生徒共に「なんでわからんのかすらわからん」って状況になるんだよね
最初に「変数は数値を入れる箱みたいなものでーす。」で、「へーそっかー。かんたーん。」と軽く流してた人こそ基本に立ち返って変数と変数の型についてしっかりと理解してみよう。。
メソッドとか制御構造とかアクティビティ覚えるのなんて二の次、三の次だよ プログラムよりRPAのほうが制限きついしテキスト打つみたいにスラスラ書けないしエコシステムが揃ってないし色々あって難しいと思う
なのでRPAで挫折した人はプログラムの勉強をしてみることをお勧めする
焦りは禁物で最初からGUIを操作するぞとか考えずにまずは入門書をきっちり修めることが大事
RPAと違って様々なレベルや目的の読者に向けた参考書やウェブサイトが沢山あるので勉強もしやすい
質問するなら荒くれ者ばかりの5chではなくちゃんとした質問系ウェブサービスを使ったほうがいいだろう >>489
>>490
なぜか難しいんだよな。
俺も昔、大学の課題で出されて、先にプログラム書いてから、
フローに翻訳したわ。 作図という大きな負担がかかるから思考に集中できないのだろうね >>494
逆になんで小学生がやるプログラミングがあの猫が動くようなやつだと思う?テキストじゃなくて >>497
子供だから質よりも面白さ重視なんじゃないか?
大人はプログラムを学ぶ動機があるからつまらなくても努力する
けど子供には積極的にプログラムを学ぶ動機が無くてあくまで大人から授業として押し付けられてやってる(むろん例外はいるだろうけど)
なのでまずは興味を持たせるところから始めなきゃならない
黒い画面にHello, world!を表記しましょうなんてやっても眠くなっちゃうだろ あとはキーボード打てないとかか?
子供は色々とプログラム学習以前の基礎能力が足りないからGUIにして誤魔化すしかなかったのかな for each rowでうまくいかないからdo whileにしたけどカウント増やすの忘れてクソ無駄な時間使ったわ
fof each rowすげえよなあ foreachですげえならLinqを知ったら腰抜かしそう ■ このスレッドは過去ログ倉庫に格納されています