[RPA]PC自動化技術総合スレ[効率化] Part.4
レス数が900を超えています。1000を超えると表示できなくなるよ。
>>837
いいえ
めちゃくちゃ高いです
前提が分かってる人なら高いとわかります
(バカバカしいのでいちいち説明はしません) 会社の金なんだし高い低いの議論より投資対効果だろ
プログラミングが優秀なのは当たり前だけど、結果効率化が進まないからなぁ RPAは基本的に新しい物を作るには全く向いてない
なので投資対効果もすぐに頭打ちになるため低い
1-αを1にすることはできるけど1から増やすことが極端に難しい uipathでどうにかして欲しいのが条件分岐とかの計算式でA = Bとかで真偽ができないのがある(ような感じがある)のをなんとかして欲しい…
あと、スイッチで文字列でのcaseでvbaの様に""使ってしまうと全てデフォルトに行くのも…
あと、計算式にカーソル合わせたら中身が表示されるようにもしてほしいなぁ…
そういえば2019.6.0にアップデートされてアイコンとか変わった…
何にもしてないのに勝手にアップデートされるのはどうなのだろう… >>832
普通の大企業ならいくら無料で便利でも、まともサポート窓口もなく、
問題があっても全部自力でどうにかして下さい的なフリーソフトを業務には使いにくいだろう
有償でも多少不便でも何かあった時のためにライセンス費用が発生するソフトを使うんじゃないか >>843
実際問題、それでまともなサポートが受けられず、しかも場合によってはそのソフトを販売してる会社自身がフリーソフトの方が優秀と認めるような事案さえ発生してるわけだが。 うちからライセンス購入しないで、優秀なフリーソフト使って下さい、なんてどんな糞営業だよ… >>845
このスレは企業の論理なんか眼中に無いって感じの人が多いからなー だから寝首をかかれるんだって誰かが言ってたな >>841
RPAは視覚的に効果が解りやすいから
実演するとパン職さんが固まっていて面白い 個人レベルの視点で見ればフリーソフトやプログラミングとの比較になるから100万は高いと感じるし、
企業としてみれば年間100万は安い。レガシーシステム改修…例えば印刷ボタン追加するだけで15万とかポンポン出してたりするしそういう費用との比較になるから当然っちゃ当然な話 >>848 年間ライセンスだぞ、それも1台で使う場合年間50万位だが、まともに使おうとしたら、年間400万円近くだぞ。
https://i.imgur.com/2gE4p2O.jpg
https://i.imgur.com/RN0LIEO.jpg
ま、そのうちオープンソースに駆逐されるだろう。 金が取れるのは、クラウドとか、人員派遣とかそんなものが残るんだろうな。
そのクラウドもバカ安な高性能なのが出回り始めてるから、儲けるのは辛そう。 >>842
〉A = Bとかで真偽ができないのがある(ような感じがある)
文字列や浮動小数点、十進型で気をつけることはあるけど…
具体的例が欲しいとこです
〉あと、スイッチで文字列でのcaseでvbaの様に""使ってしまうと全てデフォルトに行くのも…
バグに近いですよね。変数が使えませんから。修正要望に入れます。
〉勝手にアップデートされるのはどうなのだろう…
せめて通知はほしいですね。シーケンス選択の色が水色に変わって、「ライセンス更新が近いから?」とか思って色々調べて時間無駄にした。
(古いの使いたければ残ってるけど) 少し前までUiPathのあった会社で働いてた。
でも俺のまわりは誰も使って無かった。
俺が他アプリ操作の経験あるのを話したらVBAでUIAutomationの使い方は聞かれたけど。 >>848
それでは比較対象が間違ってるのでは?
RPAと比較するならプログラミングの方も既存システムには手を付けずにオートメーションする方向性で考えるのがフェアだろう
その場合のプログラミングのライセンスのコストはゼロ
人件費や分析のコストはどっちも同じ
実装はプログラミングのほうが楽だと思うが百歩譲って同じとしよう
ほらね
RPAはライセンスの価格の分まるまる高く付く 前にも書いたけど、上司がインシデント管理の為にNotes買ってきた。
何でNotesなのか、何がやりたいのかをよくよく聞いてみたらオープンソースで十分な内容だし、Notesで構築する奴もいないしで、何もせずに数年経ってゴミ箱行き。
買う前に詳しい奴に相談しろよな―。
そのソフトの営業以外に。
RPA買ってる奴らにも同じ匂いがする。 それはお前が信頼されてないんじゃ、、、
インシデント管理の重要性があるのに言われないからやらないイコールできないんだから 使えない奴ほど会社の中で物事を静観するからな。
で、会社側なり上司が何かを導入すると批判する。
そして最後にはお決まりの「それは自分の仕事じゃないんで」。
会社側としたら高い金払ってでもよく分からんRPAを導入して自動化なりしたいんだよ。
プログラミングで自動化できるヤツが最初からやってればRPAは導入されんだろ。 >>856
このスレで批判ばかりなのもまさにそれだな
建設的な話するより批判の方がべらぼうに楽だからね >>855
>>856
バカなの?
俺じゃなくても他の誰かに相談すればいいわけだが。
あと、Notesの話はすごく昔なので俺に相談されても困る。
でも、すぐ近くに詳しい人がいて、その人が実験的にフリーソフトで組んだのを見せられたら、買った本人がこれで良いじゃんと言ってたな。 >>857
へー、誰にも相談せずに買ってきて、使える奴が居なくてゴミ箱行きでも批判するなってか。
とんだ大名商売だな。 uipathの先週の大阪のイベント資料が公開されてます
技術的なことは少ないですが、導入や進め方など、色々参考になると思います >>856
バカに巻き込まれないように立ち回ったほうが大抵はコスパいい >>857
建設的なツールだとごく自然に建設的な話題がぽんぽん出てくるんだけどね
それが出てこないってことは…… >>842
>uipathでどうにかして欲しいのが条件分岐とかの計算式でA = Bとかで真偽ができないのがある(ような感じがある)のをなんとかして欲しい…
真偽判定が狂うのは基本的にデータを疑った方が良い
UiPathでよくあるのがエクセルの値を読み取った時に
見かけ上の値と実際に記入されてる値が違う場合だな
入力値:0.125
エクセルでの表示上:0.13(小数点が切りあがってる状態)
UiPathで読み込んだ時は
表示形式を保持するオプションのチェック無し:0.125
表示形式を保持するにオプションのチェック有り:0.13
っていう風になるから、予期せぬ判定結果になるのは十分ありえる
他にも文字列で大文字/小文字で判定できてないとか
エクセル上は小文字で入力されて、画面上では大文字表示になってて
そこの判定で食い違う……っていうのもよくある実装ミス うーむ
作業用のブックを用意すると、判定、変換、ソートの仕様齟齬を避けられます
なのかなかな >>842
>あと、スイッチで文字列でのcaseでvbaの様に""使ってしまうと全てデフォルトに行くのも…
状況がよく分からんけど、たぶんこういう実装してるって事?
https://i.imgur.com/WUpN4TD.png
これでDefaultルートに行くのは正しいぞ
Switchアクティビティで指定するのはリテラルだから、caseに「""」って書いたら、文字列としての「""」の意味になるから
ブランクとは別物になる
ブランクを正しく判定したいならcaseはemptyを選択しないといけない
https://i.imgur.com/OfHp22a.png 批判は建設的な意見だぞ
批判すれば課題が見え課題が見えれば進むべき先も見えるということだからな ポジティブシンキング一辺倒の弊害が認知されたからこそクリティカルシンキング体系化されたんだよね マイクロソフトはどうする気だろう・・。
WindowsにRPAを標準搭載する気は無いんだろうか・・。
WindowsでWindows動かすのが、一番簡単だと思うんだけど・・。 >>868
もうすでに搭載されてるよ
UI Automationってやつ >>866
これのどこが建設的な意見なん?
>>853 >>866
「批判」と「改善案」の組み合わせなら建設的だな >>870
ある目的に対してより低コストな方法を模索するというのも建設的な議論だと思うよ
>>871
俺は何度か改善案まで合わせてレスしてんだけどステマさんは都合の悪いレスは見えなかったらしい
というか推進派こそ批判的な意見に対して
その課題はこうすればいいのではないか
などと建設的な意見を言っていいのだよ?
なんで推進派もほとんど建設的な意見を言わないんだ? 例えばほら
RPAすなわちビジュアルプログラミングはテキストプログラミングに比べて情報の発信と検索が難しいため
初心者が参照できる文書が圧倒的にすくないため学習困難である
などと批判しされたら
推進派はその問題はこれこれこうすれば解決できるはずだとか
実際にサービスを作ってみたから使って実証に付き合ってくれとか
そういう建設的な意見を出せばいいんじゃないか?
なんで黙ってるばかりで建設的な意見を出さないんだ? >>869
いやそれRPAじゃないし、簡単でもないから。
VBAから使ったことあるけど、
ボタンを押せるまでDoEventsループで待機しないとコケるとか、
Invokeが時々失敗するとか、凄く大変だった。 >>872
> ほらね
> RPAはライセンスの価格の分まるまる高く付く
こんな言い草で模索する気ないでしょw
プログラマーが社内にいる前提のようだけどその費用考えてないじゃん 雇うなり教育するなり 要は初期コスト無視
これもこのスレでずっと言われてるけどずっと無視し続けてるじゃんw >>874
.NET系だからC#のほうがいいよ
待機系はWaitWhile(Func<bool>)的な汎用Waitを書けば後が楽だ
不安定なのはRPA全般の宿命だね >>875
無視してるのは推進派だろ
教育コストはRPAだってかかる
むしろ入門書を読めば十分なテキストプログラミングと講習を受けないとキビシイRPAじゃ教育コストの比較でもRPAに分が悪いと思うがね >>877
> むしろ入門書を読めば十分なテキストプログラミングと講習を受けないとキビシイRPAじゃ教育コストの比較でもRPAに分が悪いと思うがね
まぁそう思いたければそう思っとけばいいんじゃないの 根拠ねえけどそう思うのは自由だ お邪魔しましたー >>875 そもそも社内にプログラマがいない位の企業規模でRPA やって効果があるのかな? >>877
素朴な疑問なんだけど、自動化の需要が増えてる中でなんでRPAが注目を集め始めたの?
プログラミングが入門書を読めば十分なら、RPAがこんだけ騒がれてる理由が分からないんだけど。
プログラミングは趣味程度しか出来ないオレだけど、会社でRPA触ってみて良くできてるなーと感心したよ。 ちなみにRPAもテキスト演習だけで講習は受けてない。 >>879
社内にプログラマっているもんなん?
うち数千人規模だけどプログラマはいないな たぶん経験者はいるんだろうけどそれ用のポストではないという意味でね PG言語知ってれば業務改善出来る訳じゃないからなあw RPAで一つ気になるのは結局頑張って覚えてもベンダーロックイン?の状況に陥るだけなのでは?
てとこ
どうなんだろうRPA一つ使えれば他社製品とか製品→ossとか簡単に以降出来るんかな >>874
DoEventsループで待機とか、根本的に分かって無いの丸わかり。 >>884
実際はUIAutomation覚えた方が汎用的に応用出来ると思うね。 >>875
社内研修をしたらその分は社員の能力向上になるから
組織の能力が向上するメリットもある
単に商品にお金使うのとは違う
RPAもその製品を使うのに必要な知識を研修なりで身につけなければならない点では同じじゃね?
その結果がRPA製品を使えるようになるだけという限定的なメリットしかない >>880
バズってるだけでの可能性がある
自動化の需要があるとしても
その実現手段はいろいろある >>882
会社の役割なんてその会社だけで簡単に作れるだろう
必要なら作ればいいだけ >>883
業務改善を実現する手段としてプログラミングを選択肢に加えることができる
良い方法があってもそれを知らなければ選択できない >>886
汎用プログラム言語を超える汎用性があるの? だからプログラミングで効果出るなら早くやれよ(笑) >>877
>教育コストはRPAだってかかる
>むしろ入門書を読めば十分なテキストプログラミングと講習を受けないとキビシイRPAじゃ教育コストの比較でもRPAに分が悪いと思うがね
凄まじい机上の空論をかましてる感が半端ない
何というか成果物に対するコストを考えて言ってるのか分からん
例えばRPAだと以下のような案件がよくある
@検索対象のExcelリストを読み込む
AシステムAを開き、@で取得したリストのデータをダウンロードする
Bダウンロードしたデータを結果一覧に転記する
C転記後、特定データ(例:期限が近いデータ)の場合が存在する場合は
連絡先のリストと突合してメールを送信する
このぐらいの規模ならRPA専門要員1人で制作〜リリースまで大体一か月ぐらい(1人月)
システム部門と調整する時間も合わせてこれぐらい
で、これを普通のプログラミングでやるならどのぐらいの見積もりになるん? >>893
そんな個人の業務をわざわざSEがプログラミングするわけないだろ!
ちょっと運用変わって止まったって度に電話されたらたまらんわ! >>894
おまえ大企業のオンボロポンコツシステム舐めるなよ!
こんな作業を10人も20人もやってんだぞ!
システムが違っても同じような運用やってんだぞ! >>893
システムAの仕様と結果一覧がどんなものかで結構変わるね
感覚的には普通レベルの開発者なら0.4〜06人月あれば十分そう
外注すると1人月で請求(80〜100万)くらいかかる 結局、RPA だと、RPA アプリの使い方を覚えるだけ。
そのアプリの仕組みを理解したり、そのアプリそのものを作ったりできない
異なるアプリに変われば、またそれを学習しないといけないから、
学習コストが掛かるため、移ることができない(ベンダーロックイン)
Ruby, Selenium WebDriver, Nokogiri, CSV では、小回り・応用がきく。
とにかくデータを、CSV にすれば、テキスト処理できる。
JSON, XML でも良いし
また、Ruby に似ている、JavaScript, Kotlin にも応用できる
RPAを10年やっても、仕組みがわからず応用もできないから、
社員のキャリアパスが成り立たない
RPAを10年やってる人を昇進させるのですか?
何も出来ないし、何も知らない人だけど
情報処理資格も取って、データベース設計もできるのなら、使えるけど >>893
プログラミング初心者に毛が生えた程度の俺でも1週間あれば組めそう
業務の合間じゃなくて作成に専念していいってなったら2日でやれる自信ある Ruby では、
# CSV ファイルを、1行ずつ処理する
CSV.foreach( "a.csv" ) { 処理 }
ダウンロードは、wget, curl
ファイル操作は、File, IO モジュール
メール送信は、Mail モジュールかな? 自動化技術の根本を勉強したいけど
とりあえずPython辺りの言語と
UiAutomation勉強すれば良い? >>878
同じく君がRPAが簡単と思い込みたいならそうすればいい君の自由だバイバイ
>>880
注目された理由は宣伝されたからだろう
>>884
90年代に流行ったビジュアルプログラミング環境がまだ生きててエンジニアを苦しめてる現場を知ってる
RPAはこれからだから必ずしも同じとは言えないが類似性が高いのは確かだろう
>>893
要件確定して作るだけって状況でその仕様なら1日でおk
調整も込みなら2週間ぐらいかな >>880
> 素朴な疑問なんだけど、自動化の需要が増えてる中でなんでRPAが注目を集め始めたの?
> プログラミングが入門書を読めば十分なら、RPAがこんだけ騒がれてる理由が分からないんだけど。
これに対してバズってるだけ宣伝しただけっていう勢は導入企業をアホだとみなしてるわけだが、それって建設的じゃないよな 一貫はしてるけどね >>891
UIAutomationってのは他アプリを操作するためのライブラリ。
だから殆どの言語がこれを使うことになる。
RPAもあなたが言う汎用プログラミング言語もこれを使って組むことになる。
もう1つウィンドウハンドル使う方法もあるけど、これは操作対象の部品によってどちらを使うかが決まる。
だから他アプリを操作するならこのライブラリとウィンドウハンドル使う方法を知っていれば言語が変わってもつぶしが効く。 >>902
RPAは詳しくない人に訴えかけやすいんだね。
VBAがこれほど使われてるのと同じ。
取っつきやすいんだ。
しかし、それで出来たものについては詳しい人ほど糞と分かる。 プログラマーをたくさん抱えている某ソシャゲ最大手の会社も社内業務用にRPA導入してるけどな… >>905
プログラマーでも全然違う。
昔、テスト技術者をしていた頃、当然プログラマー等とは全く呼べないし、技術も無かったけど、そこに来たプログラマーに他アプリ操作関連のツール見せたらびっくりして、売り物になると言われたことがある。
全くそんなことないし、大したもんじゃないわけだけど分野が違えば全く分からないもんだ。
Windowsで、しかもある程度そういう方面をやったこと無いプログラマーにはちんぷんかんぷんだよ。 球団持ってるとこ
今はソシャゲじゃないのかな?自動運転とか色々やってるよね あとは知ってる限りだと国内ECの最大手もRPA導入してるか
まぁ、プログラマーと一概に言っても分野が違えば出来る範囲が全然違うだろうけど PythonでもC#でもRPAでも一番大切なのは効果が出る事。
次にメンテナンスのしやすさ。
PythonなりC#の方が優れていても、やってくれる人がいないからRPAが導入されてんじゃない? >>904
正確に言うととっつきやすく「見える」
実際にはpythonなどのほうが入門しやすいんだが黒い文字だけの画面に恐れをなしてしまうのだろうな
やってみたらあっけないのだけどね >>904
> 詳しい人ほど糞と分かる
ここでも出てきてるんだよな 俺スゴいお前アホ感が
導入企業がアホばかりなんじゃ、って現実的な意見じゃないな
取っ付きやすくて、詳しくない人が満足できれば十分って考える人が多いってことじゃないの〜 >>913
気付いてないだけでは?
自動テスト、CI、ビッグデータやAI学習データ収集、等々
テキストプログラミングベースのオートメーションは社会で活躍してるよ 例えば、Ruby, selenium webdriver で作れば、
element = driver.find_element(:css, 'input[name="userid"]')
element.clear
element.send_key "123"
driver.find_element(:css, 'a.btn').click
これを、selenium IDE で作って、selenese という言語に置き換えられるけど、ほぼ同じ。
結局、CSS Selector の意味がわからない人には、出来ない
同じクラス名を付けたりして、バグってしまう。
規則がわからないから
CSS Selector を使うのは、RubyのNokogori, JavaScript のjQuery でも同じ! DeNAはRPA導入します宣言しただけ
いったいどのシステムRPAに移行てきたんだい?
ソフトバンクのハゲがRPA導入じゃあ!って社内恫喝してんのと同じレベルでっせ >>893 1日で出来ると思うけど余裕を見て3日あれば十分すぎるだろ。 色々議論されていますが、uipathについてはトップページの
#UiPathForward Osaka開催のご報告
の 6つくらいのpdf見れば、疑問のいくつかは解消します
ITサイトの記事を参照するなり、個人意見に必要以上に関わっても切りがありません >>914
CASEツールをソフト開発専業会社が導入して捨てた過去もあるから、今はまだなんとも言えない
いくつか実験と評価のレポートもあるようだけど、その後を聞かない
ERPパッケージも導入しきれず断念することもあるように、RPAの導入を断念するところも出てくるかもしれない
管理をどうしているか、今後のメンテナンスどうするつもりか
RPA導入に成功した事例から、知りたいものである >>893 そもそもそんな誰でもやるような作業はプログラムのツールも出来上がってるからそれこそ簡単にできる世の中なんだよ。
そんな事をRPAだなんてのでやってる方がおかしいと思う。 比較する対象を知らないから当たり前と思ってやってるのがよくない。
新人研修として、初めてのプログラム初心者に練習問題としてその問題を与えて教育期間を含めて1月あればできるだろ。
仕事の合間の教育なら2~3カ月かかるかもしれないけど。
この仕事ならRPA、この仕事ならプログラムと言う感触くらいは持っておいた方が良い。 >>917
DeNAはRPAセミナーで自社の導入事例を紹介してたぞ >>908
そういう話じゃ無くて、ソシャゲじゃプログラマーとは呼べないというくらい分野、技術が違う。
そういう所を例に出す所を「笑うとこか?」と言ってる。 >>893 どのくらい簡単かと言うと、
Excelファイルを操作しよう
https://www.sejuku.net/blog/75536#Excel
ここから例題を見てこのままコピペすれば全くの初心者でもできる。
色んな処理をする必要もあるから基本的なプログラム教育は必要だけどね。
メールを出す処理は入っていないがそんなのは数行書けば済む話。 >>919
PDF眺めてみて一般的な内容でビビっとこなかったんだけど、どの辺りが疑問解消できそうな感じ? >>924
そりゃーエクセル弄るくらいPythonでもVBAでもなんでもできるっしょ
ざっと見ただけだけど、>>893の処理で最もコアな機能ってエクセル操作でもメール送信でもなく
>>AシステムAを開き、@で取得したリストのデータをダウンロードする
どう考えてもここでしょ…
エクセルから取得したデータ群を検索キーとしてシステムAを"自動操作"によって検索後、出てきたデータをダウンロードするってことじゃないのん?
ってなると、システムAがもしWebシステムならSeleniumで楽勝なんだろうが、この場合レガシーなWindowsネイティブアプリを指してるだろ
そうなるとWinAppDriverの知識も必要になるしこのサイトに書かれてる内容じゃ到底実装できないよ。まさかPyAutoGUIでなんとかなると思ってる感じ? Pythonなんて碌に使えない俺だが、少しクグレば、Win32APIも使えるし、UIAutomationも使えるじゃねーか。
じゃあ、すべてOKだな。
WinAppDriver?何それ。 RPAで簡単にできるような画面ならプログラミングでも同じように簡単にできる
それはブラウザでもデスクトップでも同じことで大差はない
もちろん複雑な画面は複雑なロジックを容易に書けるプログラミングが優位であることは言うまでもない しかも古くさい業務系デスクトップなんてのは複雑で大きな画面である傾向が強い
チュートリアル教材や宣伝用に恣意的に選ばれたオモチャみたいな画面ならともかく
現実世界のレガシー業務系デスクトップアプリのカオスUIにRPAなんかで本当に立ち向えるのか? RPAの利点である、いままで使っていた画面が目に見えるように自動操作されるというのは
なかなか他に代えがたい強み
正しい結果が得られるかどうかは
いままでと同じ操作がきちんと行われるかどうかにかかっている
代々引き継がれたマニュアルと同じ操作がされるなら検証不要
裏で動いて出てきた結果を疑わずに信じられるまでになるのは、いささかハードルが高い
マニュアルが1行になってしまうというのも良かれ悪しかれ >>929
PythonなりC#なりでレガシーWinネイティブアプリ自動化した経験の上で語ってる??
インスペクタとにらめっこしながらめっちゃくちゃなElement特定しなきゃならんのってすごい骨折れる作業だと思うけどなあ
画面がどんだけカオスだろうがIDが可変だろうがそもそも存在しなかろうが脳死ワンクリックで一発セレクタ生成してくれるのは正直楽だよ
その点だけは流石にUiPathに分があると思うな >>931
929じゃ無いけどinspectじゃ取得出来ないのもあるし、inspect以外にも数種類のオブジェクト取得ツ―ル使ってるけど、骨なんか折れねーよ。 >>931
RPAで簡単に取れるようなものはプログラミングでも簡単に取れるよ 逆にUiPathのセレクタ部分だけフリーで作ればUiPathいらないよね >>931
どんなに非効率なことでもそれが当たり前だと思っている時点ではそれが苦だとは感じないもんだよ
だが冷静に考えて要素一つ取るだけなのに複数のツール使いまわしてトライアンドエラー繰り返すのって効率悪いと思わん?
その作業がワンクリックで済むならそっちのがいいっしょ
>>932
君が妄想で話してるのはよく分かった
Inspect、spy++、WinAppDriver UI Recorderあたりでの要素取得と自動化経験を経てから出直してどうぞ
>>934
これはぶっちゃけその通りだと思う
UiPathでいうUIExplorerがC#に最適化されてVSに組み込まれたならUiPathいらないね
誰か作って欲しい売れるぞ >>903
UIAutomation以外にもライブラリはあるんじゃ無いの? レス数が900を超えています。1000を超えると表示できなくなるよ。