[RPA]PC自動化技術総合スレ[効率化] Part.5
■ このスレッドは過去ログ倉庫に格納されています
>>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を知ったら腰抜かしそう >>502
変数名ならcodicっていうクソ便利なサイトあるぞ Uipathの例外処理ってどうしている?もうクリックとか不安要素を全て囲いたい。 >>504
和英辞典じゃないですか
それ以上の便利な点は? >>507
詳しい事はマニュアル見て欲しいけど
・パスカルケースとかにデフォルトで対応(選べる)
・メソッド、bool名を自動補正
・独自に単語登録も可能 >>506
囲んでどうすんだ?
やみくもに囲んでも意味ないよ >>509
まるっとすべて囲ってやったぜ。不安定なUipathはこれがデフォだろ。 >>510
TryChathで括りすぎるとエラーが握り潰されるから
原因特定するのが難しくなったり、本来止まるはずだった個所から変な風に進んで止まったりしてくちゃくちゃになるぞ
クリックが不安定っていうのも、ちゃんと原因調べてから対応しないと
保守するタイミングでクソ大変になるぞ >>511
あれ、あまり多用するのはやめた方が俺もいいと思う Juliaで自動化ツールを作ってみたのだが
モジュールロード時に結構時間が掛かるのは痛い
速度を求めるならPyPyでも使うべきか? >>516
PC自動化目的で速度を求めるなら脱GUI操作のほうが効果あるよ
ボトルネックはほとんど全て外部アプリ操作だからね
他の対策した上でロードがボトルネックになってるならまずはサービス化かな 今ユーアイパスの展示会きてるんだけど君らはいるのかな? >>495 今時フローなんか書かないだろ。 概要説明程度なら意味あるが詳細フローなんてまったく意味ない。
ソースを完全なドキュメントにすることが一番。 どうしてもフローチャートが必要なら自動作成すればよい話。
>>497 子供には先ずプログラムの考え方を教えるんだよ。 いきなりアルファベットとか英語が出てきたら戸惑うだろ。
でも2020年から小学校でも英語もプログラミングも習うようになるから問題なくなるかな・
ブロックプログラミングでもちょっと複雑な事(例えばループなど)をやろうとするとテキストで書きたいなとなってくる。
>>500 何十年前のBASIC時代でも小学1~2年生ならBASICでゲーム位作れたぞ。(最もコピーだけど).
キーボードなんてすぐにブラインドタッチができるようになる。
>>504 codicって殆ど和英辞書じゃん。そもそも言語の指定がない。
>>507 外人に見せるんじゃなければ日本語でもローマ字でも良いじゃん。 >>519
それがね、書かされたりはするんだよね。
全く、アホらしいこの古典的悪習慣はどうにかならんのかね。
百害あって一利なしとまでは言わんが、意味が無いことが殆どだ。 ワークフローをマウスで組み立てるのはきついよな
すぐに腱鞘炎になっちゃうよ お前ら小学生より大人の方が優秀だと思ったら大間違いだそ >>522
いえおれたち小学生ではありません!(`_´)ゞ 今、uipathで作った後に仕様書でフロー描いてるわ…
メンドクサイ… 論理的思考が育つのは、中学生以降!
だから、小学生には無理
小学生はプログラミングできないし、
小学生には、プログラミングなど教えない! >>525
2階層目くらいまでのシート画像 + コメントくらいで済ませたいよね 先週、動いた処理が動かなくなるのがUipathです。もうやめたい。 >>530
俺も最初そう思ってたけど単純にセレクタ の問題だったわ。。
セレクタ の初期値がクソすぎる
後文字欠けとか 小学生は、集合・ドモルガンの法則・対偶とか知らないだろ。
条件、not, and, or がわからないだろ
条件(A or B)の否定が、
A でもなく、B でもないって、わからないだろ 単純な論理式が理解できない大人が多い感は有るな
知っている外国人が同業者か優秀な奴しか居ないので、日本人固有の症状か解らんが >>534
教えられてないから知らないだけで
概念自体は分数の割り算なんかより余程わかりやすい
プログラミング義務教育に向けて
算数の範囲も変えるんじゃないかな 小学生に集合を教えた現代化カリキュラムというものが過去にあってだな... なんでも向き不向きってもんがあるからなあ
子供も大人も関係なくね 小学校のときにベン図をやった記憶が
バナナ、うさぎ、うま、うしの仲間はずれをやった記憶もある
将棋と百人一首もやった
人生ゲームは無かった 一歩一歩ステップアップするのが大事。
目標が大きすぎると躓きやすい。
適切な指導者の下、適切な課題を与える必要がある。 >>538
もうどうやっても向いてないってのがいるからね 正直なところだけど、uipathのおかげで自動化進んでるよ
適性があるやつにはプログラミングの方がいいのかもしれないけど、それは社内情シスてなると思うし、間接部門全展開できるほどだとは思えない
何十年も展開できないプログラミングの話してもなぁ >>543
こちらも色々作って随時稼働(UiPath)
既に先行して作られてたロボや共通ワークフローが、正にコボルライクでメチャ腹立つわ ワークフローはもろに手続き型だからコボルみたいになるのはしょうがないよ >>546
いや、それはいいのよ
初期処理で、外部から取り込んだ20個くらいの値を、わざわざ各変数に全部代入してんのよ
Dictionaryからわざわざ(つまり、それだけで (public)変数 20個)
dictionaryのままにしとけってヽ(`Д´)ノ
さらに、そのdictionaryから取り出す処理がわざわざ共通ワークフローになってる orz >>528 何言ってるんだ? 小学校でプログラミング教えるにきまってるぞ。
すでに教材もでき先生たちには講習会も始まってるのに。 こんな大人がいるから子供がばかになる。
こんな時代遅れがいるとは。 どこから小学生が論理的思考ができないなんておもうんだ?
多分お前より賢い子が山のようにいるし、うちの子は小学2年位でBASICでプログラム組んでたぞ。
鶴亀算は十分に論理的思考だよ。
ちゃんと教科書には Pythonのプログラム例も出ているよ。 主には Scratch等のブロックプログラミングだけどね。
小学校プログラミング教育の手引
http://www.mext.go.jp/a_menu/shotou/zyouhou/detail/1403162.htm
小学校プログラミング教育の手引(第二版)
http://www.mext.go.jp/component/a_menu/education/micro_detail/__icsFiles/afieldfile/2018/11/06/1403162_02_1.pdf
算数の授業では 正三角形を書くプログラムの例も出ている。(ブロックプログラミング)
小学校プログラミング教育に関する研修教材
http://www.mext.go.jp/a_menu/shotou/zyouhou/detail/1416408.htm >>542 そりゃ仕方ない、 算数もできない子がいるからね。 でもそんな子でもある種のプログラミングはできると思う。
>>543 Excel マクロくらいは現場で組めるのが何人かいるだろ。 先ずはそこからなんだけどな。 >>547
設定ファイルの読み込みとかかな?
スコープが広すぎるのは問題だが、それとは別軸で辞書をそのまま使うのも問題だよ
型管理が杜撰になって静的解析が効かなくなるからね
型安全な変数に入れつつスコープを絞るのが正解だ >>547
辞書のままはないな
構造体なりクラスにまとめて管理するのが普通
理由は>>551の言う様に型安全 .NETで設定読み込みするなら定石はIOptionsを使うことだけどワークフローでインジェクションってできんのかね 今の所メールの宛先や本文など文字列だけなので、型は意識してない
日付とか入ってくると型変換ついでにエラーチェックになるけど、小さいロボなので、処理で使うときになってエラーでええやんとw
一時間動いて 55分で型エラーになるなら先にチェックするけど…な感じ
基本的にあまりガチガチには考えてません。それ以前なとこが他にいっぱいあるので そうやって小さな妥協、怠惰を積み重ねてできあがったのがメンテ不能のクソ基幹システムなんだけどね
君たちはまた繰り返すのか? 完全に完璧なシステム開発のために
無限の工数をください RPAって基幹システムになり得るの?
基本的には飽くまでERP等で拾いきれない、現場主導のニッチなシステムだと思ってるんだけど >>556
実はそれが正解
日常的に無理なく小さな改善を積み重ねる==無限の工数 >>555
基幹と比べるなんて大きな勘違い
基幹となるものを現場の人に作らせると本当に思ってます? >>559
スケールが違うだけで同じことをしてるのは間違いない
お前は1から10までぴたりと同じじゃないと過去の教訓を活かせないほどに柔軟性が無いのか? >>560
同じことをしてても、基幹とロボで同じ品質を求める必要無いのさえわからないのかね〜
都市銀行や上場企業の基幹システムにも関わったこともあるけど、求められる品質はロボと全く違う
スケールや求められる品質によって、作り込みが変わるのは当たり前。同じことをしようと固執する方がどうかしてる(もちろん同じ部分もある)
お前は1から10までぴたりと同じ作り込み、品質が必要とも言い張ってるわけだが、そんなバカとは議論しない >>563
全くとんちんかんなレスをしてる
だれが基幹システムとロボに同じ品質を求めてると言った?
妥協と怠惰の積み重ねがメンテナンス性を悪化させて後で困るぞ
基幹システムでやった失敗をまたやる気なのか?
これだけの話がなぜわからない? >>554
うちで使ってたUiPathのフレームワークも設定ファイル(Excel)読込→辞書型に突っ込む形式だったな
流石に全変数をpublic変数に入れ直す所はやってない(面倒)
初期処理で必須入力チェック/必要に応じて型変換して変数格納ぐらいだな
一応UiPathでも構造体的に扱う方法もあるっぽいから一回提案して見たら?
https://qiita.com/Honoka/items/c3df53bf6692ba906e6f >>566
酷すぎる
Item1, Item2, なんて適当な名前のプロパティを他人に使わせる拷問はよくない
POCO定義してマップするだけなのになんでそんなに横着して自滅したがるんだ >>568
名前付きタプルはランタイムではなくコンパイラとIDEの領分なので使えないだろ それに仮に使えたとしてそういう風に使うための言語機能じゃねえからな >>568
>>569
会社に着いたら早速調査します ■ このスレッドは過去ログ倉庫に格納されています