[RPA]PC自動化技術総合スレ[効率化] Part.2
レス数が1000を超えています。これ以上書き込みはできません。
マクロも使えない中学生でも使える一番簡単なモノは? マカーがMacには標準てAutomaterがあるからRPAなどいらない!Windowsザーカス!!って言ってるんだけど反論できないよね? 業務のプロセス改善が出来ない日本でしか受けないRPA(笑) Robo-Pat使ってる人いる?
使用感とか、周りの評判を知りたい。 結局のところRPAがGUIを取っ払ったAPIに勝ることは無いんだよね
RPAを推進すよりもAPIをサポートしないツールの購入を意図的に避けて企業にAPIのサポートするように牽制するのがベターじゃないかな 黒い画面でcurl叩くようなのじゃダメだよ。
なんか画面が勝手にガチャガチャ動いてザ・自動操縦!みたいのじゃないとウケないんだよ。
費用負担部門は十中八九技術の分からない部門なんだからw winactor使いたかったんだがキントーンになりそう(´;ω;`) キントーンってRPAだったっけ?
なんか別のものだと思ってた。 業務プロセス改善のために行動したという実績が欲しかっただけってパターンやな うちの会社の話をしてるんじゃないかと思うことが時々ある。
>>13とか。 >>12
別物なの?
金d使ったことないんだが誰か導入した人感想教えてホスィ 筋斗雲は簡易クラウドアプリ構築プラットフォーム
様々なテンプレを組み合わせてノンコーディングで手軽にテンプレアプリを作ることができる
テンプレの組み合わせでどこまでできるかはわからんが
これのおかげで業務系のプログラマが大量に解雇されたという話は聞いたことがない kintone、ググってみたけど、記事広告が多すぎて解らん。
誰か突入して クラウド系RPAでまともに業務改善された試しがない
使える範囲が限定されすぎる
営業に騙されちゃ駄目だ 業務の自動化って難しいんだよね、みんなそこまで単純な仕事してるわけじゃない 業務を自動化するという発想だとすぐに壁にぶち当たる
業務で扱ってるファイル形式やツールをAPI化するという発想が大事 >>22
それ誰もやらんまま開発した奴が抜けたか死んだかで仕方なくRPA使うしかない無能経営者たちがRPAすげええええ!ってなってる うおおおパワードスーツすげええおじいちゃんでも重い荷物が持てる!俺たちの未来はこれからだ!
これがRPAの本質だと思う >>16
RPAでないの?
システム部がテンプレをクラウド上で組み合わせてアプリをつくって(経費精算とか債権管理とか勤怠管理とか?)それを社員が使う感じなのかな?
つまり今ある手動のシステムが自動化されるわけではないと??
(´・ω・`)システムの乗り換えを弊社はやっていると言うことなのか? >>8
RoboPatとEzAvaterで社内検討したけど
Ezのほうが痒い所に手が届くっていうか
同じロボット作るにも簡単にできる印象
特にIE操作は断然Ezが楽チンで安定してる >>25
RPAという言葉に踊らされてないか?
RPAってなんなの?
従来のシステムと何が違うの?
なんでそれが画期的なの?
そういうことをしっかり考えたり議論して
自分の中あるいは組織の共通認識として明確化したほうがいいぞ
そうしないと営業マンに簡単にカモられてしまう UiPath Academy の Level3 Advancedムズー
今日中に課題提出クリアしようと思ったけど明日までかかりそう 前スレから大雑把に見たけど、なかなか辛辣な意見が多いな
弱小中小だけど社長筆頭にPPA導入に意欲的
完全にカモですね でもRPAうまく使えばクリエイティブでない仕事は確かに減ると思うよん RPAはツールだからな
作り手によって大きな違いがでる でも各ツール毎にクセが強い
IEとかならともかく
他のアプリだと画面を掴めないものある
ツールの選定も難しいよ 内部的にどういう処理してるんだろ。
やっぱあれかな。
画面が表示されるまで、ひたすらSendKeysを連打してる感じなのかな。 windowhandle掴んでsendkeyとかかね?
そのレベルに何百万かけて購入して、トレーニングとか馬鹿馬鹿しいわな RPAとして売ってるソフトはSendKeysなんて不確実なモノはまず使わないはずだよ
馬鹿言うんじゃない どれも内部でやってることはロケットマウスに毛の生えたようなもんだろ
何百万もかけるまえにロケットで業務改善できるか試してからでいいんじゃね? モダンブラウザは自動操作用のAPIがもともと備わってるんだよ
WindowsのGUIプラットフォームも自動操縦がもともとサポートされてる
それらを使いつつサポート外の機能をシステムコールでダーティに対応する
まあだいたいこんなとこだろ
ちなみにSeleniumやWinAppDriver、UI Automationってのはそのもともと備わってる自動操作用のAPIを使うためのプログラム部品な
これが完全無料で提供されているのだからいい時代になったものだよ PDFから指定した文字列を抜き出すって内部的にはどうやるんだ? 暗号化されたり画像として文字を埋めてるものは画像解析
そうじゃなければPDFはオープンな仕様なので仕様の通り解析すれば文字を抜き出せる
逆に簡単な内容なら手作業でテキストエディタだけでPDFを作ることだってできる なるほど
源泉徴収票みたいに、なんとなく形式はどれも同じだけど各会社でフォーマットが違うPDFでもRPAで文字列取れるものなのかな
全く同じフォーマットじゃないと無理? Level3さん何処へいちゃたの。
(まあ大体想像はついてるけど)
AA,BPが全DOC公開しやがった。みてまうやろ。 .net,RegEx,HTML5
でやめとくつもりだったけど
OpenCV,JS,RESTまで
視界に入れないとダメか ウインドウハンドルが取れないのって、
もう神エクセルと同じだな。
ソフト作る側も少しは考えろと。 >>41
RPAは全く関係ない
フォーマットが違えば取り方も変わる >>46
まあそうだよな
上層部たちがフォーマット違ってもやれると思い込んでる
しかもFaxの読み取りまでやってくれと言われてる なんかRPA称賛するレスが全然ないがな
どこも上からの指示でやらされてる感が…
今参入するのってタイミング的にどうなん? そりゃプログラム板だし。
プログラムを書ける人の目線で言ってるから。
書けない人があつまるスレで聞いたら、違う答えが返ってくるかもしれない。
そんなスレ無いかも知れないけど。 RPAは単に高速な単純作業ロボだからな
こいつを導入したことで無駄な業務プロセスが残り続ける
数年後にRPAを批判する記事が溢れる未来が見える なんども書いてるが
業務プロセスの自動化ってスケールでロボットを運用すると破綻する
API未サポートなツールの疑似API化と考えてミニマルにロボットを活用することが重要
そうすれば業務の変更やツールのバージョンアップにも柔軟に対応することができるし
疑似APIをメンテナンスする要員と疑似APIを使って業務を自動化する要員で役割を分担できる
そしてもしツールが自社の資産ならロボットによるラッパーは一時的な物と考えること
本物のAPIをサポートするようにシステムをメンテナンスすることが急務
自社の資産なら絶対にロボットレスな方向に舵を切ったほうがいい SIerがメンテ改修費用でぼったくれなくなる可能性を作ったのは唯一の功績
ただRPA要員を1から教育してたら短期的にはトントンいくかどうか
結局、SIerが「改修か、RPAか」の選択肢を提示するようになるんじゃないの
こんな開発技術が要求されるようなアプリは本来ユーザー側が実装するものではない データにアクセスするのに、わざわざコントローラーや要素を順に探してやっとみつけて、取り出すとかほんとクソすぎる >>42
他のことしてたので、1日書き込みしなかっただけですよ。
WinActorの仕事始めました。やっぱ、WinActorダメダメです。
ダメなところを追記します。
Lソースに対する文字列検索機能がありません。
変数の代入をソースのどこでやっているか調べるには、変数使用箇所をファイル出力する機能があるので、
それでファイル化した後、ノードIDを使って、検索し直さなくてはなりません。
コメントなどの他のテキスト情報は検索できません。
UiPathなら、右上の虫眼鏡マークをクリックして検索すればすみます。(普通だ)
ところで、「AA,BPが全DOC公開」ってのは驚きました。やっとまともな比較ができますね。
できたら、UiPathとの比較を誰かやって欲しいものです。今は他人の書いたWinActorのソース解析で、手一杯です。 RPAって検索してもセミナーよろしくどうも胡散臭い記事しか出てこないから、
実態はどうなんだろうと思ってたけど、やっぱそんなもんなのね
5ch全体でもここくらしか機能してるスレないし、本当にこのスレは情報源として貴重だわ
スレ建ててくれた人には感謝
うちは補助金が出るだかで完全に導入する雰囲気なんで、今後も参考にさせていただきます >>55
「一括で置き換えできるじゃん。」って変数名の変更のこと?
それだったら、この機能と関係なく、変数リストの名前を変更すれば、特別な記法(%変数%)を使っていない限り変数名は一括置換される。
逆に、この変数使用箇所のファイル出力では、一括置換はできない。なぜなら、変数使用箇所のファイル自体を一括置換しても、元のプログラムには何の変化もないからだ。
どうも、わかりずらかったようだが、54で書いた「文字列検索機能」で知りたかったのは、変数にどのような値を代入しているかってこと。これを探すのにはWinActorでは、以下のステップが必要なのがめんどくさい。
@WinActorの「変数名使用箇所(CSV)」機能を使い変数名使用箇所をファイル化。
ID,種別,名前,コメント,変数名が出力される。ここにはどのような値を代入したかは出力されない。
A出力されたファイルをの「変数名」カラムから該当変数を探し、その行の「ID」カラムからIDを取得する。
BWinActorに戻り検索機能でAのIDを指定してやると該当のプログラム位置が表示できる。そこではじめて、変数にどのような値を入れているかがわかり、書き換えが可能になる。 BizRobo導入しようと思ったら、マニュアルがクソみたいに貧相なサイトにテキストファイル、PDFファイル、Excelファイルに別れていて自力でインストールすらできなかった
Excelファイルにもシートが10くらいあって適当な説明があってその中には設定ファイルを自力で書き換えろとか
それでも不明な点は別のナレッジサイトがあってそこに書かれてるかもしれないと代理店に言われた
結局インストールすらできなくてインストールするには数十万のサポートが必要とか言われたよ
こんなもんなの? >>58
まぁ知ってて言ってるんだと思うけど
BizRoboってKOFAX Kapow のOEMだよ。
本家にいけばなんかリソースあるんじゃね。 蛇足兼大きなお世話だけどその代理店は早く切った方がよいと思うよ。 >>60
インストーラーくらい作れよって思う
他社がインストール時に苦労したインストール成功方法を「○○だとうまくいくって聞きました〜」と教えられたけどコイツら売る気あるのか インストールすら苦労する作りになってるとかw
クソ杉w >>60
NICEやblueprismの可能性もあるかも。RPAテクノロジーズ社って、自分の会社で扱っているものをなんでも、BizRobo!って名前で売ってない?まあ、KOFAX kapowの可能性が高いのだろうけどね。 やっぱ ”ユーザー部門でも運用できます” いう売り文句は
いろんな意味であまりにも罪深いとおもわざるおえない。
なんでKapowまで1年無償trialとかやってんだよ。
RPA暮らしの手帳をImpressあたりでやってほしい。 >>59
「LIXIL、RPA人材をグループ内で700人育成」ってすごいね。
http://jbpress.ismedia.jp/articles/-/55306?page=1
しかも業務部門への教育なのだから、おそれいる。派遣会社を作れそうな勢いだ。
これくらいの力があるなら、プログラマもいらないかもね。
ちなみに、LIXILの平均年収は1195万円。すごいもんだ。 中央値マジックがあったとしても平均1200は凄いな… 2日間の集合研修でRPA人材を育成できるならば
この研修システム売りで世界に打って出られるレベルだお。
36種の部品というのは非常に興味がある。 おれも自動化の部門とかになりてーなー
そんで女事務員どもの仕事を奪ってやるんだ >>73
そうだよな。どんなにがんばっても
”ただしイケメンに限る”
だもんな。 人を増やせばうまくいくような単純な世界ならシステム開発はもっと幸せな仕事になっていたはずだ
野良VBA資産乱造によって生じた混乱が頭をよぎる >>73,>>74
上司に申告してなったら?で、女事務員のRPA作成を補佐する。
有名どころの企業は美人が多くて驚くよ。
あからさまに顔で選んでるんだろって感じだからね。
>>75
EUCという言葉と共にMS-AccessとかVBA系の技術者がたくさんいたころと同じだよね。
ベンダーはOrchestratorのような中央管理の機能を持ち出して「今回は違う」というのだろうけど、それだけでは無理で、設計書などの整備が必要だと思う。 何だか今までのレスを見る限り
C++&Python・Lua・Juliaで組んだ自前の自動化ツールで十分じゃないかと思えてくる 他人が使えるようにドキュメント整備した?
インストーラーは完璧?
サポート体制は? >>26
画像処理でブラウザを操作するのって結構あるんすね。
てっきりキーボードで操作する方が多いのかと思っていた。 >>69
LIXIL以外でも研修進んでるけど、業務改善というより、
事務系の派遣やアウトソーシングが無くなりそう >>79
いや、ブラウザはIEを直接コントロールしてるようだ。
最小化してても動くし。
画像処理だけでブラウザコントロールはさすがに厳しいと思われ。
てかそんなツールあるの?あったら地雷だと思うw でも、ロボパットのマニュアル読んでるけど
画像認識にステータス全振りしてる感じ。
一応、画像認識を使用せずに操作するために
プラグインが用意されているけど、まんまSelenium。 pythonとseleniumでブラウザ動かして、基本driver.execute_scriptでjavascriptで要素取得とかクリックしてる。
必要に応じて画像認識とUIAutomationを使う感じ。 Ruby で、Nokogiri, ERB, selenium webdriver で良い。
driver.execute_script で、javascript も実行できる
漏れは、Ruby で、自分のPC 内の画像も、ブラウザで見てる >>84
うわー。ロボパットってそうなん?
年間数十万でそりゃないわwww こんなスレがあったんだな
前にゲームを自動化したけどパターンマッチング部分が面倒だったし
PCのパワーを思ったより喰うのので時間マージンの調整がめんどくさかった
そこらへんもちゃちゃっとやってくれるツールってでてるの? WinActorもUiPathもコントロールを操作するのに以下の方式がある。
@オブジェクト指定による操作
Aショートカットキーによる操作
B座標指定による操作
C画像認識による操作
画像認識による操作を行うとロボットが不安定になるので、
なるべく、オブジェクト指定による操作を選ぶべき。
UiPathの場合、IEなら大抵コントロールをワンクリック(Indecate on screen)で選び、
解析が終了するが、WinActorは細かいコントロールが選べないことが多い。
結局、画像認識を選び、ロボットが不安定になる。
ここらへんは、実際に製造してみないとわからないので、高いの買わされてから、
なんか、不安定、RPAってこんなもん?ってことになる。
(まあ、RPAは一般的に不安定だが・・・) >>90
参考までにどんなツール使った?
ロケットマウスとか?
もっとゲームに特化したやつ?
RPAはビジネス用途なので向かないとは思うけど。 >>91
今日某社営業と話したんだけど
まさにWinActor導入済社にUiPathのデモやったんだって。
そしたら
”途中で止まらないんですか?”
と真顔で聞かれたと。守秘義務案件じゃないよね。 なんかコメントするとネガキャンみたいになっちゃってつらい。
頑張れMADE IN JAPAN。 >>92
c++とc#で自作
パターンマッチングはc++でDLL作った windowsでは他のアプリを操縦するには仕組み上メッセージを送るしかないんだけど
その仕組みが雑なので非常に不安定なんだよな
OSが問題でうまくいかないんだから新しいAPIを提供してほしい >>95
それじゃーそれ以上のパフォーマンスやカイユいところに手が届く対応はパケージの時点で無理だよ。
それと年間最低100万とかペイしないでしょ。(決めつけでもの言ってごめん)) 15年ぐらい前には業務ソフトでcsvインポートがなかったので
登録フォームに外部からCSVの内容に基づいてデータを入力するソフトも作った
会社やめたけど今も使ってるらしい あとは楽天証券のマーケットスピードというソフトを自動化するのも作った
windowsの仕組みが悪いのでこちらもたまに失敗する windowsがちゃんと仕組みを作って自動化を推進したらいいだけの話
タブオーダーいじれるようにするとかそういうのだけでもずいぶんと違う マカー上司がMacの標準機能のAutomatrが優秀だからUIPathなんていらねえ!って言ってるんだけど、そんなにすごいの? >>101
Automatrなんてたいしたことできないよ。
アプリ側がAutomatr用に設計してくれてないと。
Macにもロケットマウスがあればと思うくらいだから。 >>94
現在、WinActorを使用している会社に入って、作業をしている。
WinActorのロボットは、時々停止するので、運用は慣れたものになっている。
既存のソースを見ているところだが、ちょろちょろと画像認識が使わていて、
これが停止の理由だなってのは思った。
91で書いた通り、WinActorはオブジェクト認識ができないことが、結構あるので、
どうしても、画像認識に頼るのが原因。
UiPathは、UiExplorerで、ちょっと画面を触って、ちゃんとコントロールがとれていたら、
その後は、画像認識はほとんど使わない。WinActorと比べて安定になる。
もちろん、「比べて」であって、RPAは、所詮、不安定なもんだ。
UiPathの場合は、回線速度、アプリケーション側の処理速度の問題で不安定になることが多い。
ただ、これは、WinActorでも同様におこる。 >>103
は
>>93へのレスポンスの間違いです。 >>102
しかしマカー上司はものすごくMac推しだからMacすげええええ!RPAいらないっすね!!って言っといた ところでRPAの画像認識ってどういう仕組みで認証してるんだろ?
プログラマーとしては気になる >>106
認識と認証は別の話だが何が気になるの?
ちなみに認証機能なんかないよ(capchaとかのはなしなら) 結局UiPathにしたって回線速度やアプリの処理速度で不安的になってしまうようなシロモノだからねぇ。
WinActorに至っては止まり過ぎて論外だけれども。
まあうちの会社は安いシェアウェアで十分役立ってるし、画期的なツールが登場するまでもうこれでいいや。 MSがRPAに本格参入すれば一気に解決?
>>109
OpenCVの画像認識は、2色(白と黒)ですら怪しいレベル >>110
それは言い過ぎじゃないか。
実際につかったことある? OpenCVで画像認識は機械学習的な手法を除くと凡そ以下が可能
1.ピクセル比較
2.テンプレートマッチング
3.位相限定相関法
4.特徴量抽出
どれもググればC++とかのサンプルが出てくると思う。 >>96
メッセージってWinAPIのこと言ってる?
UI Automation(これももう枯れてる)とWinAppDriver(新しい)ってのがあるから知らなかったら試してみては
>>110
MSはUI AutomationやWinAppDriverみたいな普通のプログラムから使う道具を推してる
オフィスVBAが代表例だけどMSは昔から自動化するならCOMなりPSコマンドなり普通のAPIを使ってくれって方針
なのでMSが本気を出したら逆にRPAは駆逐されるんじゃないかな? >>113
いやー、VBAやCOMが使えない既存のアプリケーション郡(MSオフィス以外の大多数)の自動化はどうするんだい?
ほとんどの中小は古〜いシステムのやり取りを自動化するためにRPAを導入したがっているんだが。
すると結局API叩いてボタン押したり、他のRPAと大差ないことになりそうな気がする。
MSがやるなら恐らく自動化されることを前提にアプリの開発環境自体に何か新しい仕組みを組み込んでくるんじゃないかな。
古いアプリはなかったことにしてw >>114
UI AutomationやWinAppDriverなら
古いアプリも再開発なしで自動操縦できるよ
まあ正直に言って古いアプリの中には自動操縦がめんどくさいものも確かにあるけど
これはUIAやWADが悪いというわけじゃなくてアプリ側の問題で本質的に自動操縦が難しい場合が殆ど
だからそういうのをRPAにしたからと言って劇的に楽になるというわけではない UI AutomationとWinAppDriverはただメッセージの仕組みを使いやすくしてるだけで
OSのAPIセットじゃないような >>114
MS Flowはどういう位置づけなんだろうな。
今のところ、アプリ間をまたぐ業務フローの自動化がメインで、デスクトップの自動化はほとんどできないみたいだが。 今日もWinActorで製造してきた。
WinActor、動作が鈍い。
表からデータ取得するのに、表の件数とるだけで、1秒、
1行1カラムデータとるだけで、1秒とか時間かかってる。
マシンの性能ちゃんと見てないし、UiPathと比べてないが、
WinActorって動作が遅い気がする。みんなはどう思う? 動作を視認できるようにわざとコマ送りにしてるんじゃないか?
1行が1秒だからって100行が100秒かかったりせんだろ? >>119
一応、処理速度を遅くするオプションは切ってある(設定0)
後、どこを処理しているかをブリンクさせる表示も切った。
しかし、遅い。明日、5カラムで何秒か調べてみるよ。
下手すると100カラム100秒かかるかも。 >>118
今の現場ではWinDirectorは導入されてますか?
もしされていたらOrchestratorと比べてどんな感じですか? >>107
は?なんでいきなり認証がでてくるんだよ?
いつどこで認証の話した?
お前頭大丈夫か 俺もどこから認証なんて出てきた?ひまわり学級か!?と思ったがよく見たら
>>106に書いてあるんだなw >>120
カラムやレコードを個別に取得しないでテーブルをまとめて1つの命令でガッと取ってきて
取ってきた後にテーブルをインメモリで高速に処理する
プロセス間通信なんだからこうしないとどう設定したって遅くなるよ >ひまわり学級
言いたいことはわかるが、ローカルすぎだろwww >>121
WinDirectorは導入していないのでわからない。
ところで、WinDirectorにしろOrchestratorにしろ、そんなに必要かな?
相当でかい会社じゃなきゃいらないと思うのだけど。
「野良ロボット」というのが、ベンダーの次の殺し文句だけど、
ドキュメントとかでなんとかすべきものじゃないかな?
いや、あまりでかい仕事したことないのでわからんのだけど。 >>125
その通りだが、WinActorにはHTMLのTABLEルやOLを一挙にとってくるライブラリがなく、
基本、1カラムづつの取得になると思う。
この点に関して、WinActorのウィザード(魔法使い)がいたら間違いを指摘して欲しい。
ちなみに、UiPathなら、ウィザード(対話機能)を使い、一挙にとってこれるので、高速だ。 それがマジならWinActorクソってレベルじゃねーぞ? ちなみにOrchestrator高いよ。年間250万円。入れたら、幸せになるかな?
UiPathも年間50万円で、野良ロボットが生まれるほど、みんな買うのかな?
小さな会社なら1ライセンスで充分じゃないかと思うのだが。 >>129
前に指摘したように変数型が貧弱なのがネックなんだと思う。
データをとってきて、入れるところが用意されていない感じ。
一応、2次元配列は扱えるみたいだけど、ライブラリ利用で主流じゃないんだよね。
ちょっと推測でいっているので、WinActorのウィザードに訂正してもらいたい。 Winactor使いやすいよ
事務員だから難しい話はわからんけど〜
最初簡単な使い方習ったらあとは動きに合わせてノードを組み合わせていくだけ。
レゴ遊びみたいで楽しい。
けど、自動化し終わったらどうなるんモヤる。 ここらへん、ロボパッドはどうなんだろ。
たとえば、HTMLのTABLEのTDに書いてある価格すべてに対して、
消費税を計算して出力するってのをやる場合、
テーブル取得は、TD単位になるんだろうか?
それとも、TABLE単位で取得できるのだろうか?
マニュアル読んだ人、教えて。 >>133
WinActorは、おそらく、133さんのような人向けのソフト。
ただ、高くてUiPathの2倍近くする。
簡単に扱えるという観点で、UiPathにない便利な機能がWinActorにはある。
それは、「データ一覧」の機能だ。
入力データとして、CSV、Excelなどの2次元データを一つだけ設定すると、
レコード取得のルーチンを省略して、プログラムが書けるという機能だ。
UNIXを知っている人に向けていうなら、AWKのGUI版って感じのものだ。
これは、便利だが、単純なことしか書けない。
WinActorの当初の目的は、この程度の自動化だったのではないかと思う。 前から少し気になっていたのだが
Webサイトに対してRPAする際にWebサイト管理者に許可取ってやってる?
企業としてクローリングしてるわけだからまんがいち威力業務妨害なんてことになったら大変だよね >>116
OS上で動作している以上OSに管理されているはず >>136
大企業の従業員多数が手作業でアクセスしたのと
中小企業のロボットがアクセスしたのと
法律的にどこで線引きをするのか判らない
過去に裁判にでもなってたら判例があるかもしれないけど クローリングに関してはrobots.txtという紳士協定がある ここで話してるWEBサイトに対するRPAってスクレイピングだのクローラーだのじゃなくて、自社業務サイトの操作が主では? >>128
> WinActorにはHTMLのTABLEルやOLを一挙にとってくるライブラリがなく、
> 基本、1カラムづつの取得になると思う。
まじで!!??
とんだ地雷ツールだな。ありえねぇ。 RPAが流行る時点で日本の業務ITは世界から益々取り残される >>143
それはあるな。
本来EDIやAPI等で連携しなくてはいけない部分を
無理矢理ロボット化はよくない。 面白いけど不気味だな
手打ちで1分以上かかるものが3秒で終わると気持ち悪い たまにwindows起動したら一瞬コマンドプロンプト出たりダイアログがでて消えることがあるだろ
あんな感じで不気味なんだ >>143
>>144
おまえらはいつ世界を見てきたのかと小一時間.... 海外ではAPIがしっかり整備されてるからRPA不要という印象を受ける 日本のITシステムはクソだからな
不動産情報サービスやお役所サービスは人間と同じく夜と土日祝日年末年始はきちんとお休みするし >>120
今日調べた7カラムで13.4秒だった。1カラム2秒というところ。
だから、100カラムなら、200秒=3分20秒。ありえないほど遅い。
100行レベルの表の場合は、一度クリップボードにコピーして、
Excelに張り直し、VBAで処理するなどの工夫が必要かも。
どうなんでしょ?WinActorマスター。 マジで笑いが止まらんwwwww
エンガチョwwww WinActorありえない仕様だな。
これが日本のRPAの主流とは… >>156
>ヒント: JavaScript
?でもWSHのJavaScript で処理したら数ミリ秒なんじゃね >>162
BizRoboじゃない事は確か
他の製品の実例を見てないから
何がいいかは何とも言えない
そもそもAPIやマクロが存在しない
システムの穴を埋める
隙間産業のような製品だから
まだまだ発展途上なのかも
ユーザー会に行ってきた奴の話しだと
大手で人数も多い所はスキルも高いとか
財力と本気度も多分に影響すると思う >>164
クソみたいなシステム作ったアホの尻拭い系のお仕事ツールだよな そしてRPA導入によりクソみたいなシステムが温存され続ける
データをわざわざWebに出力してRPAに入力させるバカシステムについて、中の人は誰も疑問を持たなくなる >>165
データの意味を自動解析ねぇww
またAIというワードに各社カモられるだろうなw >>118
ノードの数が多いと時間かかるよ
同じ取得結果でも取得方法で変わってくるよ RPAとAIは全く関係ないのだがね
イメージ戦略は大事だな >>143-144
バックグラウンドでシステムがサクっと動いて一気に処理する機能性って
業務に合わせたOwnシステムに拘った日本企業に理解出来ない カラクリ人形が日本人のオートメーションの原点なんだよね
お茶汲み人形とかとにかく日本は「遊び」が先にくる
なのでAPIのようにビジネスライクで実用一辺倒なテクノロジは日本ではウケが悪い
デスクトップアプリをガチャガチャ動かしたほうが楽しくて良い >>170
好意的に解釈すれば
RPAで取得したデータをAIで分類して
その結果によってRPAでの処理を変えるとかかな
パターンマッチをより汎化したもの
例えば入力値を肯定的か否定的か
分類して処理を分けるとか >>169
返答ありがとう。
ノード数は全体で300程度。ただ、1サブルーチンのノードは少ない。
それでも、遅いのかな?
正直、UiPathのほうが高速だよ。
逆に、169さん、UiPath試してみて。 >>175
教えてくれてありがとう。ネットの綺麗なページを見ると信用しそうになる。
現実に仕事している人間の感想としては、なんか、嘘くさい記事だね。 RPAじゃなくてRPJだと、偽物くさくて良い感じなのに。 >>169
標準ライブラリの「表の値取得(IE)」を使っています。
とても遅いです。
ミハル・ラトキエでしょうか?(謎) それは、素人ゆえの悲しい出来事であったかもしれない。
しかし、戦火の中に散っていったその若い命のことは、決して小さなことではなかった。
カイ・シデンの深い悲しみを慰めることなど誰にもできはしなかった。
スレ違いですな。 昨日は同僚のために、古いツールの自動操縦用のCOMクラスをC#で作ってあげた
3画面、とりあえず急ぎでとのことだったので、利用頻度の高いコマンドを選んで2時間ほどで完成
彼はその日のうちに、それとVBAを使ってエクセルを読み込んでツールに入力する業務を自動化したようだ
よくわからないRPAツールの使い方を覚えなくてもいいし、無料で作れるのが良い
使いなれたVBAだから、完成まで15分もかからなかった
次は何を自動化しようか、みんなにもこのCOMクラスを教えてあげよう
そう言って喜んでくれた Uipath level3が難しい!
どこか、詳しい説明サイトとか無いものか・・・
xamlがダウンロードできるとことか UiPathとWinActorが多いなー
BluePrism使いは少ないのかな
結構使いやすいと思うんだけど >>183
今まで本気で売ってないんだよ。
これかAutomationAnywhere,BluePrism巻き返してくるよ。 UI PathとWinActorの比較だと
製品自体の出来以前に
WinActorはネット上に情報がほとんどないのがつれーわ。
UiPathだと、調べれば大抵答えが出てくる。 BPとAAは値段が高いから敷居が高いよね。
サーバー型が必要な企業がどれくらいいるかが、巻き返しのポイントだと思うけど、
あまりいないんじゃないなか? >>188
そうなんだよね。だから、WinActorについて、ぼくは発信している。
まあ、ネガティブな意見がほとんどだが。 >>187
すげえ大雑把だけど.net開発経験者は最小限の費用でUiPath開発者にできると思うよ。
PGサイドから見たらAA,BP,Kapow,UiPathあたりは既存言語の包装紙を変えただけだと個人的には言いたい。
逆に事務員にC#で開発しろとはだれも言わない。
WinActorでももちろんものはできるんだけど、できる範囲がロケットマウスでできるレベルと大差ないんじゃ意味ないよね。 .NETというか開発者はそもそも自動操縦という目的を達成するのにいちいちRPAなんて壮大な遠回りはしない むしろエンジニアじゃないがUiPath使いこなせる事務員っているのかな?
もしいるならRPAにはエンジニア不要だということになる 使いこなせるがどこまでを指してるか曖昧だとなんともいえないね
@小規模な作業を間違いなく自動化できて個人として利用可能なツールを作れる
A大小様々な作業を間違いなく自動化し矛盾なく組み合わせて組織として利用可能なシステムを組める
B組み上げたシステムの性能、メンテナンス性、安定性、スケール性、等、非機能的な面まで保証できる
@は努力すれば誰でも行けそうだけど、この程度でエンジニア不要になるほど業務ドメインのIT化は単純じゃない
Bまで出来る人はおそらく一人も居ないだろう >>191
流石に、WinActorをロケットマウスと同列に扱うのは、間違いだと思う。
教えて欲しいのだが、ロケットマウスは、まともなIF文もループもないんじゃないかな?
ロケットマウスのIFは、処理の分岐といえるようなものではなく、
単にアクションの実行をするしないの条件だけだと思う。
ループに関しても、ロボット全体の処理ループがあるだけで、
ループを自分で定義することは出来ないんじゃないかな?
例えば、二重ループや、あるループが終わって別のループを行うみたいな記述。
これができないと思うのだけど、間違いかな?
非常に貧相な言語のように感じているのだが、ロケットマウス使っている人
教えてくれると嬉しい。
少なくともWinActorは、そこまで貧相な言語ではないよ。
(いつも、WinActorをバカにしているぼくだが。)
あと、前半の部分は、だいたい同意。
BP,UP,WAの言語は、フローチャート。AAは通常の言語っぽい。
だけど、Kapowは、かなり癖のある言語で、最初面くらうと思う。
経験者によれば、そのうち慣れるって話だけどね。 >>194
となるとRPAはエンジニアが使えないと意味がなく、しかもエンジニアはRPAを必要としていない
この矛盾が出てくるのか >>192
.NETの技術者でも、RPAの開発ツールは便利だと思うよ。
非常に短い時間でマクロを作成できるからね。
例えば、何等かのERPにログインする場合だったら、
ログイン操作をレコーディングするだけでいい。
画面の操作も、操作したいボタンをクリックした後、簡単な設定をするだけで、
動くものが出来てしまうからね。
技術の習得はプログラマにとっては、とても簡単だ。
RPA流行の一因は、.NETに比べて、開発速度が速く、容易に作れるところ
ではないかな。簡単なので、いままであきらめていた小さな仕事の自動化
を考えてもよくなったってところ。 >>196
RPA不要論の人は、まさに、そう思っているんじゃないかな。
ぼくは、.NETで書くより簡単で高速に開発ができるから、必要だと思っている。
(ただ、年間100万は高い。企業が購入するギリギリのところ狙ってるよね。) >>197
完同&感動
単純場合1時間で手順書付きでできましたよメール発信できる。 ここまでいまは亡きWinBatchに関する言及無し。
20年以上前に設計SYSからCADにデータ流し込んで目の前でにょきにょき3D機器が出来上がる”バッチ”を片手間仕事ととしてやらせれた。(片手間仕事なので行く末すら感知していない) >>197
プログラマにとってレコーディングはコーディングより面倒と感じます
実は本職のプログラマが使うSeleniumにもSelenium IDEというレコーディング環境があります(当たり前のように無料で日本人作だそうです)
しかしプログラマはこれは面白いなとは思っても頼ることは滅多にありません
なぜならレコーディングで出力したスクリプトは意図が読みにくくメンテナンス性が低く再利用しにくいからです
エクセルVBAの操作の記録を使うプログラマが滅多に居ないことと同じ理由ですね
無料でも使わないものを高いライセンス料を払ってまで使おうとはしません vbaでマクロ記録よく使うけど。
で、生成されたコード見て構造化したり修正。
api引くより速い。 >>201
レコーディングの例を出したのは、ちょっとまずかったかもね。
正直、UiPathでもレコーディングは使わず、手作業でプログラムは書いている。
(たぶん、他のRPA製造者もそうなんじゃないかな)
RPAの利点は簡単だってこと。大抵の人間にとっては、C#よりは簡単に作れる。
これが、企業が金を払う理由だと思うよ。 どうせ数年後にはメンテ出来なくなったRPAが大量に遺されるんやで どっかの記事でみたがUSAの部署には”技術者”がいてそいつがロボット作るってことらしい。
そいつらのバックグラウンド,役割がイマイチピンとこないが日本ではその立ち位置は存在しないよね。
マクロ使いおじさん(おばさん?)がいても、それはたまたまであってロールとして必須ではない。
で結果
”事務員でも使えます”
の殺し文句に導出となるが、TOOLのポテンシャルを使いこなせるかという観点からいうと
”....................................(沈黙)”
だよね。 >>204
そういういい方したらマクロ(VBA含む)なんかほぼ使い捨てやんけ。
もったいないけどそれで決算に影響があったという話は聞いたことはない。 >>203
そう感じるのはおそらくRPAが簡単というよりは便利な部品(アクティビティ)が揃ってるから簡単なのではないかな?
グラフィカルな開発環境が本当に簡単なら世界中のプログラマが自分たちで既に使ってるはずだ >>205
USA企業が実際に何してるかは知らないですけど
便利な部品を作ったり低品質な野良RPAを取り締まる立場の人間は必要では?
それはエンジニアにしかできないと思います
>>206
使い捨てるなら幸いにも問題はありません
問題になるのは資産として引き継いでいく場合 使い捨てであっても画面見りゃ何やってるのか判るんだから必要なら録画し直せばいいんでは 昔いわれたEUC(End User Computing)って、どれくらいの期間流行って、
どんな風に消えたんだろうか?RPAも同じように消えるんじゃないか?
想像するに、Excelのファイル共有やマクロでデータのやりとりをしていたのが、
あるとき社長がERPやWeb、サーバーDBなどの別の技術の導入することを決定。
外部からSEがきて製造したと思ったら、「そのマクロ、来期から使わないでね」
とか言われて終わりって感じゃないかな?要するにマクロは打ち捨てられたと。
RPAは、プロセス間通信としては、遅く、不安定でなので、
あまり、お勧めできる技術ではなく、次善策として存在していると思うので、
同様に打ち捨てられるべきものだと思う。
ところで、ぼくは、古い人間のせいかEUCっていわれると、
Extended UNIX Codeのほうを思い出すね。 ExcelVBAならWordも付いたOfficeサブスクリプションが月額900円だけど
RPAは・・・ 投資に見合うリターンがあれば金は問題にならない。
リターンがあればね。 RPA以前に野良エクセルを撲滅させることにしました >>212
プログラマーなので、あまり、この手の計算はしないのだが、ざっくり考えてみる。
とりあえずの前提条件は以下。
a.事務員およびプログラマの時給=4000円(手取りではなく、会社が払う単価)
b.RPAの年間値段100万円→月8万3千円
c.ロボット一体の製造日数5日
d.ロボット一体が一日に省力化する時間30分
e.月の労働日数20日
f.作ったロボットを使う年数10年
g.開発期間1か月
開発費は4000円*8時間*20日=64万円。10年間使うのだから、
一月の値段は、5万3千円。これにロボットの月値段を足すと13万6千円。
つまり、ロボットのコストは月13万6千円。ロボットは4体できているから、
月の省力時間は4体*30分*20日=40時間。事務員の単価で計算すると、
4000円*40時間=月16万円の省力化。
ところで、ロボットのコストは月13万6千円だから、
(16万円-13万6千円)*12か月=年間28万8千円得する。
まあ、パラメータしだいだけど、計算式は、こんなもんじゃないかな? ツッコミどころ満載だな
・c,d,fの根拠が全く無い。
・初期投資と、ランニングコストは別にしろ
・文章が長い、要点が掴めん 皆さんはRPAソフトを使ってどの様なことを自動化してるんですか? 数字はでたらめかもしれないけどそれっぽい計算だせるの地味に尊敬するわ。
教科書でもないと、まずそういう発想が出てこないからな俺は。 UiPath製品開発トップが語る「エンタープライズRPA 5つの柱」
https://it.impressbm.co.jp/articles/-/17493
>>218
昔Googleが採用にフェルミ推定取り入れてたけどあんまり当てにならなかったようで今はやってないらしい フェルミ推定って当てずっぽうをカッコよく言っただけだからな
分からんことは適当に答えないでちゃんと調べたり実測できる人がマトモな社会人 >>220
フェルミ推定したら「マトモな社会人」じゃないってのは、狭量だなー。
経営の面では、実測できない将来のことに関して、
ざっくり計算していくってのも必要になると思うよ。
じゃないと、決定に論理性が一切なくなるからね。
RPAを採用するかどうかってのはまさに、
そういう場合じゃないかな? 何のための推定かにもよるだろうね
他人を巻き込まない範囲でやる分には好きにすればいい
でも例えば工数見積とかでミスると簡単に他人を窮地に追い込みかねないし最悪の場合過労死とかあるからな
そういう場面で根拠もサンプルも無しにザッとで答えを出しちゃう無責任野郎はマトモじゃないと俺は思う >>221
あるよ。そういう風にしか返せないところ。
自分で足りないところ考えようとしないところ。
そもそも、相手に分かりやすく伝えようとする意思が感じられないところ。 >>220
推定するのと当てずっぽうは違うと思うけどな
推定することを諦めて当てずっぽうするより
フェルミ推定の方が良いだろう
実測する時間や費用があればいいけど
現実は色々と制約がある >>210
表計算ソフトを駆使して、視覚化したり管理したり予測したりいろいろやる
目玉として、仕様があやふやで思いつきの 非定形分析 を、やりたい人がパソコンで自由自在
そのためにCSVやODBCでデータを提供する
BI (Business Intelligence)、EUD (Developing )みたいなのに呼び名を変えて生き残っている
滅ぶどころか、ますます販売攻勢が盛ん winactorはNTTの営業が功を奏して見事に「誰でも使える=バカ向け」のイメージを確立したね
ユーザーフォーラムの民度があまりに低い aの段階でもう...
作らせようとしている事務員の時給(労務費込)2000円程度じゃない? >>214
どうも無用な誤解と混乱を招いたようだね。関係者のみなさんごめんなさい。
議論したかったのは、RPAを導入する際の数式が正しいかどうか。
214の文章を数式に直して、記述し直すので、
数式が正しくないと思う人は意見してくれないかな?
(RPAによって節約できる一月分のお金)>(RPA導入による一月分のコスト)
ならRPAを導入してもよい。
RPAの一月分のコスト=(RPAの年間値段/12[月])
+((プログラマの時間単価*8[時間]*開発日数)/ロボットの使用年数/12[月])
RPAによって節約できる一月分のお金=(開発日数/ロボット一体の製造日数)[体]
*ロボット一体が一日に省力化する時間*事務員の時間単価*月の労働日数 俺もこの手の計算は詳しくないけど、そんなに外れてはいないとは思うけどね。 人を雇うと健康保険、年金保険、労働保険、税金の手続きとか色々必要になる 余った人員をよりクリエイティブなところに配属して生じる損害が組み込まれていなくない? >>235
細かいけど開発期間分のツール使用料が入ってないかな
あと省力化がコストゼロにまでになるのは違和感ある 日本の業務システムは1980年代のホストコンピューター〜オフコンが有った時代のOA化(笑)の発想のままなんだな
日本人は合理思考ではない人が大多数だから、日本人自身がどこか効率化を否定している側面もある
だからいつまで経ってもAPIによるデータ連携という考えに至らない
プロセスの途中で必ずどこかで人の手が入る >>239
>あと省力化がコストゼロにまでになるのは違和感ある
の意味をもっと詳しくお願いします。
開発期間のツール使用料は、後で計算式を直します。
ちなみに、開発期間が一月だったら、試用版を使って開発するって手もあると思う。 メンテナンスコストと将来の別テクノロジへの移行コストも計算して >>241
>コストゼロ
動かす人、監視する人、業務知る人がいなくていいわけでもないから減りはしてもゼロにはならないよね?
さらに言えば10年ノーメンテも無理では、ということ
試用版での開発はどのツールがどんな制限あるか知らんけどね、製品版への移行作業が多少でも発生したりしそうなら選択肢にないかなー 日本人は10年以上ノーメンテで出来るようにしてくれ、
が本音じゃね 出来るわけないじゃん
もっと言えばメンテどころか運用自体10年持つわけがない
業務が変わればさっさと捨てて作り直すものでしょ?
旧来のシステム開発、運用コストみたいに試算するのはまさしく皮算用にしかならない >>245
できるわけないなんてみんな分かってるわ
くだらんレスすんな 分かってないのがいるから10年運用の試算なんていうレスが出てくるんじゃないの?
誰もその辺突っ込まなかったら5chで情報収集しちゃうようなのが鵜呑みにしちゃうじゃん 分かってない人=顧客のエンドユーザと権限の無い御用聞き情シス部門 フローチャートやレコーディングはメンテナンスが大変そうだな >>235
そもそもRPAが流行りだしたのは
コスト削減が目的じゃないからな。
こういう計算してどれほどの意味があるのか考えた方がいいよ。 いやコスト削減が目的でもっとはっきり言っちゃうと人員削減が目的だと考えるが別の目的なんてあるのか?
いやもちろん目的はともかく手段としてお粗末ってんならわかるけど >>250
うちの場合はただRPAを業務に利用していると宣伝するためだけにやってる
実際にどれだけ時間削減されたかなんか興味ない
うちみたいなとこ多いんじゃないのかな うちの会社にはRPA使えるような業務専門の課があるが コスト削減、人員削減したい人もいれば手元の作業楽にする為の手段でしかない人もいるんじゃない?
後者を大袈裟に、みんなでやったら大規模なコスト削減、人員削減になると言い出したのは誰なんだろうね
てか前から言われてるが空いた時間でクリエイティブ(笑)じゃなくてもいいからより別の仕事すればいいのになんで人員削減するのか分からん
単に経営不振で仕事ない、予算ないってだけなんじゃ? 人が足りなくなってきたから
ゴミ作業は機械にやらせましょうっていうのが今の流れ。
人員削減が目的とは意味がちょっと違うわな。 あと、導入する企業の規模によって効果が違うから。
大企業ほど、業務フローがドキュメント化されていて
どこにRPA導入したらいいか、イメージがつきやすい。
同じ作業をする人員も中小と違って、複数人、場合によっては何百人となるから
この点でも大企業の方が効果が出やすい。 業務のこと考えずに
単にコストだけみて試算して、導入の判断してどーすんの。
だから、ツッコミどころ満載なのよ。 >>243
意見を数式にとり入れてみた。他に意見があるなら、またください。
(RPAによって節約できる一月分のお金)>(RPA導入による一月分のコスト)
ならRPAを導入してもよい。
RPAの一月分のコスト=(RPAの年間値段/12[月])
+((プログラマの時間単価*8[時間]*開発日数)/ロボットの使用年数/12[月])
+((RPAの年間値段/365[日]*開発日数)/ロボットの使用年数/12[月]))
RPAによって節約できる一月分のお金=(開発日数/ロボット一体の製造日数)[体]
*ロボット一体が一日に省力化する時間*事務員の時間単価*月の労働日数
-(プログラマの時間単価*8[時間]*月あたりのメンテ日数) >>247
適当に書いた数値に関して、いつまでもいわれもなー。
数値を決めて、計算式の話をしたかっただけなんで、正直、なーんも考えて
なかったから、まさに、業務が変わるとか考えない奴とかいわれたらそうなんだけどね。
ただまあ、計算式に1年(もしくはそれ以下でも)っていれて計算すればいいと思うけど、
また、何か取りこぼしがあるかな? >>258
「業務のこと考えずに 」ってのは、まさに、今、ぼくは、考えていないんだけど、
もうちょっと詳しくは、どういうことかな?
教えてくれたらうれしい。 RPAが本来なんのためのものかは知らないけど、過去やったRPAの仕事の導入目的は、以下
・ガッツリ、リストラのため、単純作業をやる従業員をカットして、収益力をあげたい。
・高学歴な従業員に単純作業をやらせているため、離職率が高くなるのをふせぐため。
・将来、作業量が増える予定なので、ロボットを使って高速化したい。
まあ、どの目的でも、ソフトを導入するには、簡単な、コストの計算はすると思うよ。 >>250
ところで、「そもそもRPAが流行りだした」ときの「目的」ってなに? うちは人が足りないから自動化せざるを得なかった
RPAって用語は後から知った 退屈なことはPythonにやらせようという本があったな
読んでないけど 既存技術がAIブームに乗っかっただけという気もする 昔からあったWeb系のテスト自動化ツールを業務システム向けにリブランドしてるだけやで >>259
開発期間も業務してるからそこのコストも…とか言い出すとキリがないがどこまで精度高めたい?
てかもっと単純にならないかな
節約できるコストってのが状況次第すぎて全くピンとこないのもあるが
人間がやる場合のコスト > RPAの場合のコスト
という図式が分かりやすい
まあ、したら結局はシステム開発と同じで短期(特に一年未満の運用)では逆転するってだけで面白くないか
現実的には今のあり物をRPA化するのは早々に廃れるので、RPA前提のシステム/業務プロセス設計込みで数式化できたら役に立つ場面もありそう
というかゆくゆくはそういう為の設計だとかテクニックの話をしたいもんだけど RPA前提…API製造禁止とかですか?
うわーさすが科学技術大国日本 何寝ぼけた事言ってんのさ
RPAでAPI叩いてもいいしAPIで連携したアプリのコントロールやインターフェースの仲立ちさせたっていい
細かな業務処理をマイクロサービスに分割してAPIで公開してRPAで業務プロセスをデザインするのもいい
GUI操作がRPAだとでも思ってるクチかね?
そんなのAIと関連付けるレベルの勘違い 今関わってる会社は部署によりけりだが、上手くRPAを活用してるけどな
15時間とかぶっつづけで回して、結構な処理をさせてる
社内システムへの入力業務や、物流データ整理とか >>270
ヒューマンインターフェイスの操縦をやるからロボットっていうんだよ
それ除いたら普通のシステム化と全く区別が付かんよ
はっきり言って今の業界のRPAの拡大解釈にはうんざりしてる
そう言った方が素人をカモりやすいんだろうけどさ システム監査の観点では、
RPA導入によって解決できるタスクがPCを使った業務に存在する時点で
全体設計に対する減点になるけど、現実はツギハギだから 前にも言ったけど
RPAに手を出すユーザーってRPAの宣伝に踊らされて思考停止してる感がある
RPAって結局なんなんだ?
従来のシステムと何が違うんだ?
違いからどんなメリットが生じるんだ?
逆に何が同じなんだ?
同じものになぜ違う名前を付けたんだ?
同じところは要らないから違いだけ安く導入できないか?
代替となる技術はないのか?
どんな時にオワコンになるんだ?
ひとつひとつ疑問を持って突き詰めていかないと簡単にカモられちゃうぜ 例えばさ
毎日フォルダに追加される定型のエクセルファイルを読み取り
読み取ったデータをビジネスルールに則り加工して
加工したデータをAPI非対応のウェブサイトに画面経由で入力する
このアプリはRPA開発ツールを使っても実装できるし
ごく普通のプログラミング言語でも実装できる
同じ仕様のアプリを作って全く同じ動作をしてるのに片方はRPAでもう片方はRPAじゃないのか?
この2つのアプリの違いは一体なんなんだ?
RPAと名乗ったツールを使って開発すればアプリの内容に関わらずRPAになるのか? >>272
そんな定義はじめて聞いたけど、それに拘る意味も区別する必要もなくない?
拡大解釈や勘違いはいらないけど出来ることは呼び名がなんだっていいじゃん
>>274
どうぞ好きなだけ深慮遠謀なさって下さい
僕らは好きなように、使えるもの使ってお仕事出来ればなんでもいいんで RPAは所詮ツールなんだから、別にそんなに嫌悪しなくてもいいじゃん
業務に使えそうなツールが増えるのはいい事だと思うぞ
目的に合った使いやすいのを使えばいい
.NetFrameworkでもPythonでもVBAでもRPAでも
コレじゃなきゃダメ!おかしい!って方が変だ 大方、Winactorでもつかまされたあげく工数削減を迫られて逆恨みしてるんだろう。 RPA導入で奪われるような単純な仕事でもしてたんじゃないの? RPAの普及で困るのは、野良マクロを量産して優位な立場を確保していた人々 今はRPAを売ったもの勝ちみたいなところがあるからダメなの
将来に禍根を残す事が理解出来ない経営者 Office系ソフトのどれかのVBAアドインを配布するだけで解決するようなソリューションをRPAで実現しようとするの、本当に金の無駄だよな RPAを入れると無駄な作業が減るとかいう世間の思い込みは何とかならんのか
RPAに任せた作業そのものがプロセスの全体最適の視点からすると無駄だったとかいう事例が山ほどあるだろう
もっとシステム監査とかでボロクソに叩かれないとあかんぞそういうの 世間がそんなこと思い込んでるという思い込み何とかならんのか 野良RPAと言うが、他のプログラムなら野良にならないのか?
不思議だぜ… RPAはコードレビューとの相性が最悪だからすぐに野良になる
他の言語ならレビュー環境すぐ作れるからあとは情シスのやる気次第 最近になってもてはやされてるけど、こんなのはやってる人は20年以上前からやってるだろ。
ツールが無くて自作してた人もいるだろうし。
Windows3.1のレコーダーは音声だけじゃなく操作も記録してくれたから、それ使った記憶がある。 クラウドガークラウドガーって盛り上がってたときもおんなじこと言ってたなお前ら >>283
ならないわな。
エクセルだって、わざわざ神エクセルを作って、マクロでどうにかしろって発想だしな。 >>293
それは間違い
クラウドはもともとあったwebの概念に新たに名前を付けただけ 3.1の頃からあったかどうか、ではなくて使い物になるかどうかだろう
ツールを作れば、よりもツールを作らずに済むは大きい
WinActorは3.1のやつと大差ないかもしれんが… 90年代にオンラインゲームで寝マクロ用にRocket Mouse使って
普通に自動化してたからほんと今更感が強い。
自動化ソフトが昔からあること知らない人多いのね。 人不足と人員削減とプロセッサの性能向上とか
様々な要因が組み合わさって
浮き上がる要素が大きくなったと思う
自社システムならともかく
他社システムがGUIしか提供してない場合も多いし もともと性能はそんな必要ないんだがな
要するに自動化したい対象が動くスペックにほんのわずかなリソースを追加するだけだから
なのでスペック進化がうんたらという理論はウソ 既存の枯れた技術を売るためにパッケージしなおして販売戦略としてAIで注目を浴びたキーワードであるロボットってラベルを付けただけ WinActorとかはRPAの流れにのって急いで作られた中途半端品だが、
BluePrismとかは15年以上前に最初のバージョンがリリースされてるぞ
2003〜4年頃なんてまだAIは注目されていなかった そもそもRPAとAIなんて1mmも関係ないって思うのは俺だけかな? >>302
OCRがAIで性能アップしてるので、
データエントリー(入力作業)をRPAでって、連想の関係
紙文化の国は入力作業が多い >>303
ソリティアすらまともに処理できないのは
このライターがアホなだけだな
ソリティアごときにOCR使うとかほざいてるし >>306
> OCRがAIで性能アップしてるので、
もうそこから騙されてるだろw 世間で言うAIって、ニューラルネットワークと機械学習が一緒になってるよね ちょっと複雑な条件判断があるだけでAIって言ってる人もいそう ちょっと複雑な条件判断が出来るだけで無能社員より優秀そう ガチ無能は居るだけでマイナスだから、コケシ置いとく方が何もしないだけ優秀ってなる チューリング完全なら文句ないわ。
チューリング完全未満はゴミ。 証明支援系のcoqは停止性保証のためにチューリング完全にならないよう設計されたとか聞いたことある ほう、まさかそんな高度なレスがつくとは思ってなかった。 uipath導入したけど、自動化できる業務が思いつかんのだが、 普通にクライアント端末でスクリプトを書いてWindowsのタスクスケジューラに定時実行させるだけで終わりそうな自動化処理をわざわざRPA発注して実現しようとしてる所って本当に何を考えてるんだろうな
発注したシステムも使用者側に案の定ある程度のシステム管理のセンスや知識がないとパラメタ設定とかワークフロー設計とかうまくこなせないし
ほんと無意味 情弱を騙して金を巻き上げるビジネスっていくらでもあるからね
胡散臭い健康食品とかと似たようなもんでしょう
流行ってればいいものだと考える程度の知性しかない会社が買う 本職のプログラマが全く使ってないんだからお察しだよな 本職のプログラマが必要ない時点でいいんじゃないか?
そこそこの知識と経験は必要だけど End User Computingの悪夢の再来
ExcelマクロやNotesスクリプトの悪夢を思い出すんや 未だに320みたいな阿呆もいるし再来と言うほどでも プログラマ不要とか言って調子こける規模の小さいアプリならRPAなんて使わずともスクリプトで十分
今はもう小学生がコード書く時代だからな
規模がでかくなきゃ素人でも簡単に書けてしまう
小さいアプリならと言うとじゃあ規模が大きくなったらRPAが効果を発揮するのかと聞かれそうだが
残念ながらそれはそれで全然効果を発揮しない
規模が大きくなると個々のアプリより増えすぎた資産をどうやって管理・制御するかが課題になるがRPAエコシステムはその辺りガバガバなんだよな 環境依存の野良マクロを蔓延らせて技術的負債を不動のものにする糞商品 近代的プログラミングツールのほぼ全てを無力化する独自仕様のプラットフォーム。
そして凄まじく貧弱な言語仕様とIDE。90年代かよ。
マトモな技術者は絶対逃げると思いましたまる ベンチャーでもない限り技術者にRPA導入の可否の権限なんてない気がする
そもそもベンチャーならRPAなんて必要ないし 売るならともかくエンジニアが自分達で使う理由がない 「事業部門主導のRPA導入」に多い勘違い
https://www.itmedia.co.jp/enterprise/spv/1903/06/news014.html
Accentureが発行したレポートによると、初期のRPAプロジェクトはIT部門の介入なしに進められると誤解してしまうことが多いという。
RPAツールは侵略的ではなく、従来のアプリケーションに統合する必要がない上に、どのデスクトップにもインストール可能だからだ。
またIT部門は、RPAはサポートされていないマクロと「スクリーンスクレイピング」で構築されていると仮定して、非常にマイナスな先入観を持っている。
しかも、自分たちがビジネスプロセス管理システムに投資しているため、RPAは不要だとも考えている。
Accentureのオートメーションエンジニアリングサービス事業のマネージングディレクターを務めるジェームス・ホール氏によると、IT部門はRPAについて、企業をリスクにさらしかねない本質的に粗野なアプローチだと考えがちだという。
「RPAはずさんな問題解決方法だと考えられている。アプリケーションを拡張したりAPIを取り入れたりする方法を強化できれば、望ましいアプローチになるという。
IT部門には、事業部門がデスクトップで何やら良からぬことをしているという認識がある。不正なアプリケーション、Excelマクロ、さまざまなサポート対象外のソフトウェアを使っているという疑いを持っている。
責任者が退職した後にそれが動作不能になったら、誰がそれを修正するのかを懸念している」(ホール氏) IT部門の回避
Capgeminiでグローバルビジネスサービス部門の最高技術責任者(CTO)を務めるリー・バードモア氏は、RPAの魅力の一つとして「IT部門を介さなくてよいことが約束されている」点を挙げた。
企業人はRPAについて、IT部門と話し合うことなく手短に成功を収める方法と見ている。
その考え方は賢明とはいえない可能性がある。
「このことが今の最も大きな学びの一つだ。RPAはIT部門とその厳しさを免れるための言い訳ではない」
「RPAを素早く配信できるのは確かだが、スケーリングとなると途端に頭打ちになる。
IT部門のシステム配信に関する古くからの規律、つまり『堅牢(けんろう)な導入にまつわるあらゆるもの』という観点から考える必要がある。
先陣を切るのは基幹業務だが、どこかの時点で前に進めないことを理解する」(バードモア氏)
同氏によると、RPAの取り組みが事業部門のみによって主導され、自動化が秘める広い可能性が見過ごされていることが問題だという。
既存のAPIのみに基づいて自動化を行ったのでは、プロセスの効率化や転換に失敗してしまう。
同氏は次のように語る。
「アプリケーションがプロセスを効率化するとしても、プロセスの構築自体はまだ人間が中心だ。
それはRPAソリューションの単純な展開をサポートしていない。
つまりプロセスを変更する際は、まず自動化することを考えるべきだ。
その手段がRPAなのか人工知能(AI)なのか機械学習なのかということだ。
これはわずかに異なる考え方、そして働き方だ」
RPAは大量データの処理には適しているが、特定の基準に基づいて主観的なルールを適用するのには向いていない。
企業がRPAの利点を最適化するには、プロセスをシンプルにしなくてはならないことが多い。
自社独自のプロセスを細かく把握する必要があるが、ほとんどの企業は理解が不十分だという。
「ロボットを構築する際は、全ての画面、全てのフィールド、キーストローク、人間がタスクを完了する順序を知らなければならない。
細部の重要性は過小評価されることがある」 なんかお粗末なレポートだなあ。
RPAがダメなんじゃ無くて具体的なRPAの製品群がどれも出来が悪くて、複雑な処理を複雑にしか組めない、必要とされないほど簡単な処理を簡単に組めるようなもんなのが不要な理由だろ。 仮にRPAの製品群がいくら高いプログラマビリティを備えていようとも、発注側がRPAで自動化しようとしている業務プロセス自体が部分最適の産物で無駄なコストやリスクを内包するものばかりなら、結局RPAは世の中に価値をもたらすものにはなりえない
自動化するとはどういうことなのかを本質的に考えないとプロセス管理のスケーラビリティが頭打ちになるというのはそういう話で、要は事業部門側が業務効率化を手作業の高速化と考えてるのが良くないわけ まぁよくわからんけど、ボタン1つでit部門に依頼することも無いちょっとした業務が自動で自分で作れるようになったのはいいことだよ
今日2時間かけて作って1時間/月は浮くことになったし RPAが駄目なんて何処にも書いてないのに…結局言いたいのはいつもの製品ガー?
もう君来なくていいよ 製品の質の問題じゃなくて市場側の戦略投資の成熟度の問題なんだよ >>340
なんかすごいこと言いだしたな。
ここでいう戦略投資って具体的にどういう感じのものなのよ? >>337
RPAて1時間とか30分とかの積み重ねかと思ってたんだけど違うんか?
大きい業務は既に自動化しとるし >>342
一概には言えない
代替的な方法で業務効率化を進める場合(スキルの高い人を雇う、業務用機器の処理性能を上げる、BPOを使う、等)の予測限界効率との比、当該作業一単位のもたらす会社収益上の価値等のパラメタによっていくらでも評価が変わる 今動いてるRPAは36時間くらいぶっ続け。しかも毎週。
かなり働きもの。
他にも15時間ぶっ続けとか。 RPA大流行の影でこっそりと公式HPごと消滅したUWSCに闇深さ感じる
どっかのベンダーに潰されたか、あるいは吸収されたか...
いずれにせよ今世に出てる云百万するRPAツールとほぼ同等かそれ以上の
ことを無料でやれちゃう存在が邪魔だったんだろうなあと邪推 質問1:
いま話題の元号対応、例:生年月日の入力では
1:入力しない、OCRも無いなどで、そもそも不要
2:RPAアップデートで対応
3:現場で改修して対応
4:さあ? 質問2:
日付計算関数(リードタイム、勤続日数、年齢など)の元号対応は
1:使わないなどで、そもそも不要
2:RPAアップデートで対応
3:現場で改修して対応
4:さあ? そんなの有るの? >>346
さあ?になるんじゃね?
OSの改修とかアプリの改修は自社開発とかでないとできないと思う 質問3:そもそもWindowsの時刻が狂ったり、アップデートせず2038年以降も使い続けたら
1:時刻を使わないので、そもそも不要
2:RPAが時刻合わせする
3:現場で気をつける
4:心配しすぎ 何を想定しての4択か伝わってこないからコピペかと思ったらそうでもなさそう
ただただ頭悪い設問だった RPAって実際便利だけどな
不平が出てるのは高額ゆえに高望みし過ぎてるためじゃないか?
うちはロケットマウスなんで費用もそんな掛かってないし費用対効果で十分満足してる
これが年間数百万とかだったら確かにもっとすげー自動化を期待しちゃうのかもなw 導入して一年半経つけど、最初の頃は手探りで小さなクソ業務ばかり自動化してた。
半年くらい経ってから、対象業務を吟味して開発を進めてみたら、結構な効果が出てきた。
今は大きな業務を中心に進めてる。 【AI活用】行政にもRPA導入の波 「あらゆる業務が対象になり得る」──神奈川県の実証事業で見えてきたもの
https://egg.5ch.net/test/read.cgi/bizplus/1551933657/
\(^_^)(^_^)/ >>353
まだ上がとりあえずやってみろ段階でじっくりと考える時間も貰えないよ。。
効果が大きいのを業務から見直してrpa に乗せれれば大きそう >>356
オレんとこも最初はとりあえずやってみろ、だった。
んで、結局効果測定の際に上が開発コストをペイすんのに時間かかるってのを理解して、
業務の吟味が始まった感じだよ。
質より量から、量より質に変わった。
数ヶ月かけて運用の仕様決めと開発をし、一個大きな業務を自動化した。
結果、導入により人件費以外の削減も含めて数百万/月の削減効果が出て、色々な部署から注目を集めるようになった。
ちなみに最初に作ったクソ業務のRPAは今は動いてない。
使ってるのは海外製のRPAソフトね。 生産管理と在庫管理と物流。
今までがまともに出来てなかっただけかも知れないが。 それじゃ抽象的すぎてわからないよ
RPAで何をどう自動化したのかがみんなの興味あるとこ すまんが、あまり会社の詳細業務は書けんよ。
モノを作るメーカーだから、毎週膨大なデータをRPA使って処理させて人件費以外に在庫数最適化で費用削減にも繋げた、とだけ。
人が今やってる業務の自動化ではなくて、量が多すぎて人だと間に合わなかった処理かな。
本来なら専用システムを導入すればいいんだろうけど。 そこまで詳細じゃなくていいよ
テック系のウェブサイトの記事みたいに、固有名詞を出さなくてもイメージが思い浮かぶ程度には事例紹介できるでしょう
RPAで何をどう自動化したの?
大規模業務のシステム設計をやり遂げられた勝因は?
人件費以外になにがコストカットできた?
削った人件費分の従業員は解雇した? >>351
1 対象業務に和暦や時刻が無いケース
2 RPAが賢いケース
3 RPAが賢くないので現場でやるしかないケース
4 >>350,>>351のような人のケース 寧ろ今までが非効率的過ぎただけだろう
本来達成して然るべきだった効率化水準に近付いているだけなので負債を返済しているに近そう >>361
毎週膨大なデータはどういう形で供給されたの?
RPAでどんな処理をしたの?
処理したデータを最終的にどうしたの? >>364
そうだね。今までが非効率だった。
本来であればもっと早くにシステム導入とかで効率化に投資すべきだったと思うよ。
>>365
データはRPAが社内システムに定期的にアクセスして勝手に入手。
それを製品毎に各子部品に分解して、在庫データとかと比較させる。
んで、条件分岐で各部品毎に詳細な生産計画表まで作成して、各部署へ出来た計画表をメールで自動配信。
元々人じゃ捌ききれない量で過剰在庫で対応してたから、人件費の削減効果はそこまでないよ。
実際は作ってはテストして現場から修正依頼貰ったて、またテストしての繰り返しだよ。
現場の協力と、各部品ごとに最適な生産計画が欲しいって言う意思が強かったのが良かった。 >>366
なるほど
その社内システムへのアクセス以外も全てRPAでやったの? MRPシステムは古いの多いからrpaでかいと思うわ まぁ、大手メーカーなら数千万〜数億円かけて製造システムを導入して、とっくに効率化している事だろうけど、
ウチみたいな中堅メーカーはそこまで初期投資出来なくて結果無駄だらけだったんだよ。 >>367
社内システムへのアクセスからメール配信まで全部自動だよ。
スケジューラー組んでるから、毎週決まった時間に勝手に動いてる。 それってRPAでやるべきことなのかな?
データ分析も表作成もメール送信も普通にコード書けば簡単にできるよね まぁね。
RPAじゃなきゃいけない理由はどこにもないね。
たまたま使ったツールがRPAだけだっただけだよ。 >>373
スクリプトのほうが製造も管理も簡単ですよ
RPAのほうが優れてるなら世界中のエンジニアが率先して使ってるはずです >>371
逆にコード書くよりRPAの方がいいのってどんな内容だ? 知りたいので成功事例の話をもっと聞きたい
けど聞くといつもガッカリする スクリプトのほうが製造簡単は無いだろ?
RPA使った時と同等の機能組もうと思ったら俺なら10倍以上工数かかるわ。
まあ、>>374はスクリプトに長けているから簡単に感じるのかもしれないが。 >>374
RPAは生粋のエンジニア向けではない
エクセルマクロが出来る程度の人向けのツール
「〜のが優れてるなら」なら、マシン語で直接CPUでも叩いていてくれ
ほぼ何でも可能だぞ 言語はなんでもいいというひともいる
一番大変なのは仕様書を書くこと
その次が仕様を取りまとめること
それらよりもっと大変なのがハードウェアの老朽化に伴う移行に十分な予算をもらうこと 問題はちゃんと組めば使えるんだけど、その場合は簡単ではないということ。
で、UWSCでも良いじゃんってことになる。
スクリプトだって記録して実行することもできる。 >>379
俺は参考になったぞ
なぜならプログラミングが本職じゃないから
本籍が生産管理、経理とかならrpaで自動化の方が楽だしな
ここにいる人たちはSEで素人でもRPAで自動化できる事で誰でもできるSEの仕事が無くなるのが怖いんじゃないかな
俺は経理だけど誰でもできる仕訳の自動化とかの時、リスクやらなんやら反対する人いたし >>383
きちんと作らないならUWSCで良いと思うし、そういうフリーソフトは昔からたくさん有ったぞ。 結局RPAの用途だとUWSCが最適解だった気がする
なんで消えてもうたんや・・・ >>383
本職が恐れてることはむしろ逆に仕事が増えることだよ
将来手に負えなくなったrpa資産のメンテナンスの案件に当たってしまったらどうしよう嫌だなぁって気持ちさ
仕事は増えても厄介な仕事はゴメンだからね >>385
俺のPCの中ではバリバリ現役だがな
ただあれはウィンドウ位置を固定しないといけないのがアレなのと
Webページがなかなか返ってこない前提でタイミング調整しないといけないから
早いときでも遅くしか動かないのがアレ RPAはエンジニア以外の職種が楽になる技術
エンジニアは余計な仕事が増えるだけ >>387
うちのPCでもバリバリ現役
ただああいう現状だし会社として使うのはちょっとなぁ
IE前提だがUWSCならBusyWait取るの簡単じゃね >>389
IEだとそんなことできるのか、、
ま、IEじゃないけど、、、 >>383
RPAなんかなくてもエクセルvbaで似たようなことやってる素人はたくさんいる
んでエンジニアがその素人が作ったクソマクロの尻拭いをさせられることがかなりある
ネットに落ちてるサンプルコードコピペしてとりあえず動かして、後々悲惨なことになる 素人のRPAで仕事なくなるほどITは簡単じゃないからなぁ RPAプログラム自体の環境依存性だけじゃなくてRPAで動かしてるアプリケーションの環境依存性を両方管理しなきゃならないからな
画面処理なんて解像度や画面寸法が変わると直ぐに駄目になるし大変だぞ imacroはHTMLのdom要素指定だから
ブラウザ画面が裏にあっても動いてくれて便利だったんだけどな Seleniumはヘッドレス(画面なし)モードも対応してますよ 今後はRPAサーバーが主流になっていくだろう
エンドユーザーの仕事は
RPAを学習してRPAプログラムを描くことではなくなり
RPAサーバーが提供するAPIを学習して一般的なプログラムを書くことにシフトしていく
そうすればわざわざ高度なRPAスキルを身につけなくてもVBAマクロが書ける程度のスキルで十分に業務を自動化できるようになる
インストールされてるツールや画面サイズ、アップデートなどといった厄介な環境依存の問題に悩まされることは無くなる
RPAサーバーのメンテナーには比較的高スキルな人材を割り当てるか外注する
彼らの仕事はAPIを開発して安定稼働させることだ
そのことだけに集中してもらう >>392
そうだな。
少なくとも、今時注文書をFAXで送ってくるような老害が定年になるまではな。 あと義務教育でアルゴリズム習ってくる世代が上がってくると
自動化サクサク進みそう >>399
RPAはサービス(アプリ)の利用形態の1つでしかないからサービス(アプリ)を提供する側とはそもそも競合しないものだ
なので仮にクライアント全員がRPAを覚えたとしてもITの仕事は殆ど減ることはない
むしろ減らないどころかRPA資産管理という新たな課題すなわち新たな需要が生まれる
おじいちゃん達が現役を退いても変わりはない 残念ながらIT系の会社でもない限り一般的にな会社のIT部門は社内業務サポートだ。
凄く雑に言えば総務と一緒。
企業の目標は売上を立てて、利益を生み出すこと。
売上を直接立てる部門が効率化の為RPAを導入したいと言ったら、IT部門は頑張ってサポートしてくれ。
君たちの給料は会社の売上と利益がないと支払うことができない。 IT系の会社に勤めてます
RPAを導入する企業様は最期までセルフサービスでお願いしますね 君の会社がRPA導入サービスしない限り関係ない事でしょ
逆にそこで儲けてる会社もあるわけだし 今までシステム部は何をしてきたか。
企業内の困ったを率先して聞き取り能動的に解決してきていればRPAが蔓延る事はなかっただろうなあ。 >>405
幸いにもまだそのような話は出てきません
とはいえ数年後はわかりませんね
手に負えなくなったRPAのメンテナンスを任される恐れはあります >>406
そうは言ってもねぇ
経営者側にITリテラシーやIT統制に対する責任意識がなく、問題が起きたときに即IT部門の責任にされる企業が多かったんじゃないのかね
システム開発時にユーザー部門の出してくる業務要件も抜け漏れだらけでフィージビリティーのないものだったって所が多そうだし >>407
嫌なら断ればいいじゃん。
依頼のきた仕事を断って好きな仕事だけ選んで食えるなら、これ以上良いことはない。 >>409
人間関係があるのでそういうわけにもいかないです
複数案件抱えててもう無理って状況なら断りますが 自動化やってるけど俺以外に判る人間がいないし教育時間もない
今の所好きなようにやらせてもらってるよ >RPAを導入する企業様は最期までセルフサービスでお願いしますね
金貰って仕事するのであれば、個人的な感情を抜きにしてプロとして仕事して欲しい。
対価が見合わないなら、営業なりに文句を言ってくれ。 >>412
そりゃもちろん仕事が来たら対応はしますが
だからと言って積極的にやりたい仕事ではないです
なので企業様には最期までセルフサービスで賄えるように努力して頂きたい >>408
経営者も社員も専門じゃないんだから教えないと。。 >>414
そうならないように、むしろ最初からセルフサービスで賄うことやめて欲しいなら分かるけど
つまんないRPAやりたくないから自分達でやってね、手に負えなくなっても知らんけどって酷すぎない?w >>416
そうでしょうか?
最初からやめろというのもどうかと思います
なんであれやりたい人がやるのは勝手です
でも自分たちのやったことぐらいは最期まで責任を持ってやってください
これってそんなにおかしい事ですかね? 仕事として外注受けてるんならおかしいだろ(笑)
設備売って保守は自分でってないだろ
マザックやら飛んでくるぞ 認識に齟齬があるようですね
自社商品でなくてもメンテナンスの依頼が来ることは珍しくないんです RPA保守だけ請け負ったときって旨味ないからな
ベンダーやユーザーの適当な仕事が原因で起きた問題も保守側の責任にされたりするし >>417
そのやりたい事が失敗したり損しそうなら止めてやろうよ
逆に言えばだね、止めないのは勝手だが、止めないからにはいざとなったら助けてやるのが止めなかった奴の責任なのでは? >>421
相手の言ってること理解できてなくて草
他社ベンダーのRPAを入れて既に保守不能になった状態でファーストコンタクトを取ってくる糞客の話をされてるんやぞ ITエンジニアって自分達の知識や経験が世の中の常識的に語るよね。
経営陣や別の部署にITリテラシーが低いだの、なんでそんな事も出来ない、知らないんだの。
じゃあ逆にあんたらは会計知識や法務行政やらの分野で同じ事を言われたらどうなんだ?といつも思う。
好き勝手やられて困るのであれば、最低限の事を教えればいいじゃん。
いかにも知らない方がおかしい!みたいな目線じゃなくてさ。
オレ自身は電気電子系のエンジニアだが、別に他人に電気系の最初から知識は求めんよ。
知らなくて普通で、必要であれば教えるだけ。 >>422
こっちが草だよ、何も話し分かってないじゃん
まあそう言う仕事ばかりで腐心しているなら心中お察ししますとしか言えないが…
もうちょっと前向きになってそう言うケースを防止する為に歩みあって行こうと言いたい 会計知識や法務行政等の知識は全うなベンダーのITエンジニアなら当たり前に習得してるし、寧ろメインの顧客の業界からヘッドハンティングとかして人材確保をしてるぞ
その手の知識を知らなければ開発においてシステム要件の前提になる業務要件を理解できないので
あくまで、全うなエンジニアならという条件付きだが
ただそういう話とは別に、ことITに関してはあまりに顧客側のシステムに対するリテラシや統制意識、取引上のモラルが低いなと感じることがある そんな仕事受注する会社に問題があるだけでRPAとは関係なくて草 顧客側なんて自分達のやりたい事が最優先で、その仕組みやら導入による潜在的なトラブルなんて度外視は普通。
だから知ってる側がちゃんとリスクなりどうすれば要求を実現出来るかなりを教える必要があるんじゃないか。
リテラシーがー、とか上から目線で言ってないでさ。
好き勝手やられて壊して連絡が来るのなんてIT以外の分野でも普通。 ちなみに自社製品以外の問題でも普通に相談に来たりする。
可能な限りは対応するようにしているよ。
仕事だからな。 ビジネスは金次第
それはそれとして、RPAはただの詐欺。
1体でもロボット作れば分かるが、理由はこれ
>>329 >>425
全うてのは真っ当って言いたいのかな?
真っ当なエンジニアの定義がスーパーすぎてちょっと困る
もうちょっとエンジニアのハードル下げてくれよw
閑話休題、ことITに関してはというけどそれ本当? というかどうやって比べたの? コンサルがHeartCore持ってきて導入する事になったんだけど、これどうなんだろ
誰か試したことある? >>429
作ったことあるよ。
すげー力技だなー。と別の意味で驚いたが。 >>431
コンサルが持ってくるのはそこが販売契約してるから。
RPAに限らず夢のような事しか言わないから気を付けて。 rpaてプログラマーじゃない間接部門が使うためのツールだから本職の人は関係ないんだろ >>423
ITリテラシー関係なく、普通に考えればわかるようなこともわからなかったりするからな。
商品名 数量
りんご 1
みかん 5
バナナ 3→6
計 ?
こんなエクセルの表作って、
おまえそれどうやって計算するんだよ?
みたいな。 自動車が一個、ゴルフボールが一個、
合わせて二個! >>436
さすがに足しはしないが、
同じ列にジャンル違いのものが混ざってる事も普通にあるな。
何で混ぜていいと思うのかわからん。 >>435
それ!
RPAロボのシナリオ作成とも共通するけど、
ユーザー部門は単純なロジックが理解できない。
大企業は地頭が多い奴が多いので、ましだけど、中小になると壊滅的 文系の方は理系の方と比べて次元に対する認識が甘いのではないでしょうか
100円+50人がおかしいこと
100円*50人がおかしくないこと
実用上の数字には基本的に書かれていなくても単位(次元)が付属している
そういったことをシビアに認識していないのだと思います 文系理系関係ない気がするが
まあ、話が逸れるけど単位系の違いはよく悩まされるよね
100千円だったり100万円だったり1個だったり1グロスだったり
またちょっと違うけど1ヶ月後(+30日)だったり1ヶ月後(翌月の同日)だったり… 金額で正規化すればいいじゃん
つーかなんでこのスレでそんな事話してんの RPAといえども扱う業務ロジックや計算アルゴリズムなどは従来のプログラムと大差ないはずです
なので開発全般の知識を共有する意義はあります 風袋が段ボール箱で大きさ一緒だったらリンゴ+ミカンは間違いでもなかったりする
まともな伝票なら項目を横に掛けて縦で足す 問題は、こういう技術ってのは大昔からあって、昔からやってた奴に言わせるとフリーソフトで十分じゃないの?ということ。
そして、じゃあちゃんとしたものを作るとなると結局高度なスキルが必要になって、大金払うならRPA自体作っちまえば?ということなんだよね。
フリーソフトより高機能だとしても便利に使っているという所がフリーソフトでは足りないほど高機能な所を使ってるかと言えば疑問だな。 UIPath使うのとUIPath作るのじゃ必要な技術力全然違うぞ? 古いフリーソフトは部品化が難しい点で弱いですね
SeleniumなどモダンなOSSのRPAツールを使えば部品化して共有することが簡単にできるので便利ですよ こういうツールをそれなりに触ってる奴なら内部で何をやってるかはほぼ分かってると思うぞ。
だからこそ、そんなに大金を払う気持ちにはなれねーな。 UiPathとフリーソフトじゃ流石に違いすぎるぞ。
WinActorなら同レベルだが。 >>450
上司の顔色を伺うとかロボットじゃ無理だからな。 >>453
昔、上司が凄い便利だと言ってNotes買ってきたんだ。
で、上司がそれで何をやりたいか聞いたらExcelでも十分にできるような内容だった。
NotesはExcelじゃ出来ないことも出来るけど上司の望みがショボかった。
RPAも似たようなもんじゃね?ということ。 Notesはワークフローの共有と資料置き場としてクソ有能だから、、 >>455
うちもそれやりたいからやり方教えてくれ UiPathなんかのまともなRPAと、その他のナンチャッテRPAツールをごっちゃに話してるから齟齬が生まれるんだよ。
そりゃネットにリファレンスも公開されてないような糞RPAツール使ってりゃこんなもんフリーソフトで十分だわってなるし、
まともなRPAツール使ってるならなるほどこりゃ確かに便利かもしれんわってなるよ。 RPAなんか必要ない、と思うなら必要だと思っている部署に進言するなり、代替ツールの紹介なり、スクリプトを組んであげれば?
必要だと思う人達は代替案を知らなかったり、スクリプトを書けない人達だろうから。
知らない方が悪いのでは無くて、彼らの業務はシステム系統じゃないから。 うちの社長なんて本当のロボットがパソコン操作すると思ってたくらいだからな >>460
それな。システム部のプログラマーが仕事して来なかったからRPA流行ってるんだよなあ。 保守以外は俺たちの仕事範囲じゃない!
と言って会社が勝手に導入したシステムに文句を言いながら結局メンテナンスをせざるおえないのが仕事
先に問題を潰せはいいのに…、とは見てて思う パソコンの相談していい人
パスワード解除する人
定時で帰る人
と思われている予感 >>460
弊社では使ってないです
いちおう本職ですので見えてる地雷に突っ込む人は居ません このスレ開いてレスつけて興味ないみたいな反応
ツンデレおっさんやな >>473
興味はあるんですよ
Seleniumなどデファクトスタンダードの自動化エコシステムに代わりうる物がもし在れば面白いなと思ってます >>473
興味あるっていうか凄く嫌悪してるんじゃない?
聞かれてもないのに>>470みたいなコメントとか
動きを静観するんじゃなくて、阻止しようとしたいのかな seleniumってアプリケーションも自動化できますの? てかブラウザにしたってseleniumはもう時代遅れでは…
puppeteerとか色々楽でいいよ ほ、本職の人が言ってるからアプリケーションも自動化出来るんだと思うの… いやできるけど…
あくまでウェブテスト自動化のソフトだぞ
そんなこといったらエクセルマクロで機械学習もできるが。
専用のソフト使ったほうが楽だろ このスレでも何度かかいてるけどデスクトップアプリもスマホアプリも自動化できますよ
もちろん無料です >>478
日本製システムはIE以外の動作は保証しないのがスタンダードなんやで ちなみにウィンドウズデスクトップ環境ならMicrosoftがWinAppDriverというSelenium互換のドライバを提供しています
レコーダーも出たようですね(自分はレコーダーは使ったことないですが)
Selenium互換ではありませんがUI Automationという前世代のツールもMicrosoftのものです
UI Automationはウィンドウズなら特別なツールをインストールしなくても最初から使える点で価値があります >>486
WinAppDriverは管理者権限ないとだめじゃなかったっけ? SeleniumはそもそもC#なりRubyなりPaythonなりで書く必要があるから一般の事務職ではハードルが高いのでは? >>486
WinAppDriverが引っかかる人もいるかもね。
でも結局、複雑なことをしようとすれば複雑に組むことになる。
そういう意味ではUWSCなんかと一緒でしょ。
>>488
やる内容次第で、どんなツールも複雑になると思う。 >>488
RPAユーザーがグラフィカルプログラミング環境でプログラミングしているような(そうですあれらはノンプログラミングではないのです)簡単な処理ならすぐに他のプログラミング言語でも書けるようになりますよ
覚えて仕舞えばむしろ他のプログラミング言語の方が簡単だと感じるかもしれません
簡単な処理は何を使っても簡単なんですね >>490
同じプログラミングなら何でグラフィカルのRPAだと地雷になって、コードだとならないの? >>493
人類が磨き上げてきたプログラミングのエコシステムというのは基本的にテキストファイルをベースに設計されているんですね
それらの恩恵を得られない事は非常に大きなデメリットとなります
それを抜きにしても単純にGUIプログラミングは編集しにくく読みにくいのですよね >>494
過去の資産は納得。
読みやすい、読みにくいは慣れじゃないの?
オレは本職のプログラマーじゃないから、フロー式のグラフィカルプログラミングのRPAの方が分かりやすいけどなー。
使ってるのはBlue Prismだけど。 書ける書けない以前にそもそもプログラミングって開発環境を用意する時点でハードルだからなあ
専門職以外の人が「GitからWindows Application Driver入手して..」とかの説明見ても「?????」だろう
で、苦労して環境構築していざコーディングできる段階になっても次に待ってるのは「UI要素の解析」だろ???
ここまでで大抵の人は脱落するだろうが、仮に一連の処理書き終えたとして、今度はコードの保守管理の問題が出てくる
一方でインストールするだけで使えて小学生でも分かる「グラフィカルプログラミング環境」
を用いて設計するRPAは現時点では一般企業にとっては妥当な選択なんじゃないかな さらからインストールしてって普通の人もできるの?
zipを解凍するだけでも場所がわからなくない? RPA作ってクッソ安く売れば暴利RPAを駆逐できるんじゃね? >>499
今のRPAは単なるコンサルが作った流行りだから原価はあまり関係ない
ロケットマウスで業務自動化ではなくてコンサルがRPAソフトをすすめるから予算が下りる
みんなが流行やブランドを見ずに品質を見極めて買うことにしたらアパレルブランドは軒並み潰れる >>496
逆に言うとそういった難しい部分をクリアすればスキルがなくても出来るということです
前に何度か書き込んだことですが、比較的難しい部分を部品化して管理するスキル若干高めのチームと、部分を利用して具体的な業務を自動化する一般職とに分けて、役割分担する
後者は少しVBAを知ってる程度でも十分に通用します
保守管理については、グラフィカルプログラミングになったからといって放棄できる問題ではありません
何にせよ保守管理の必要があるなら、便利なエコシステムから様々な恩恵を得られるコードのほうが優れています 業務区側だけどさすがにレコーダーなんて使えないやろ >>503
"後者は少しVBAを知ってる程度でも十分に通用します"
確かに一般職でもVBAを理解する程度の知能と意欲があるという前提ならコードのほうが優れていることは確定的に明らか
だが現実はそう明るくなくて、VBAはおろかExcel関数ですらまともに使えないのが一般職のほうが多いってのが今の日本の現状
だからこそこうして視覚的にわかりやすいRPAなんてものが流行ってきてる
ぶっちゃけ私はUiPathしか触ってないから他のツールは分からないが、
あれの中身ってWindows Workflow Foundationをまんま移植してUI操作用のアドオン加えただけみたいなものだし
要は開発の際に「サクラエディタ使うか?」「VS使うか?」「UiPath使うか?」っていう差でしかないよ
RPAてどっちかというとUI自動化に特化した有償IDEの枠かと思う(その割に価格が法外に高いのは棚上げ) 流石に日本を低く見過ぎでは?
PGなんてきっかけが無いだけでやれば誰でもできるものだ
大卒エリートで溢れかえってる日本人が出来ないわけ無いだろう UWSCしか知らなくて、UiPathもWinActorも触ったこともないけど
修正箇所を洗い出すのに文字列検索(find)みたいな機能はあるのでしょうか 修正対象と箇所が洗い出せればなんでもいいんです
漏れがないように出来ますか?
漏れても良いところにしか使わないように周知できればそれでも なんか日本がって言ってるけどRPAてuipathとか海外からの輸入ものだろ?
そこにNTTかなんかが乗っかっただけで >>513
UIPath は ユニバーサルサーチというのがあるらしいですね。
自分のブラウザだとNoScriptのせいで英語しか表示されないので、おそらく、ですが。
Winactor ノード検索 で問い合わせたところ
ユーザーフォーラムに
>どのシナリオで使われているか調査から行うので大変面倒に感じております。
なんてのを見つけました.。 どういうシチュエーションを想定してるのかいまいち掴みきれないけど、
自作関数の仕様変更を全スクリプトに反映させたい感じかな?
共通部品はベタ打ちせずに別ファイルに分けて適宜callするのがマストでuwscでもそうしてると思うけど(してるよな?)、uipathでも同じことができる。
参照先の共通部分を変更したらもちろん
参照元にも適応されるよ。
引数の増減なんかで参照元部分を弄る必要が出てきたとしても、
uipathならそもそものファイル形式がxaml(xmlみたいな感じ)だから普通に横断検索でもなんでもできる。
WinActorは使ってないからよくわからんけが、、色々調べてみると、自作ライブラリを使うときは実質各スクリプトにベタ打ちしてるような処理内容になってるっぽい???
そんなわけないと思うが、仮にそうなら導入企業様ご愁傷様案件、笑 何かコードを変更したらリアルタイムで静的エラーを検知してエディタ上の該当箇所を赤波線で装飾
すべての静的エラーについて該当箇所のファイル、行数、エラー詳細をテーブル形式で表示
>>512方は、本当はこういうことをしてほしいのでは?
検索という言葉で濁してますが、要するにコードを静的解析したいという要望でしょう >>507
やろうと思えばやれる。でもやりたくない人ばっかり。
大学卒業したら勉強はオシマイだから、既得知識で出来る非効率な働き方に流されていく感じ
1人当たりのGDPが壊滅的なのもこの気質のせいじゃないかな >>518
"何かコードを変更したらリアルタイムで静的エラーを検知してエディタ上の該当箇所を赤波線で装飾 "
であれば、UiPathでは可能。フロー図の該当部分に「!」が付く
"すべての静的エラーについて該当箇所のファイル、行数、エラー詳細をテーブル形式で表示"
エディタで開いていないファイルまで網羅しようと思うとUiPath単体では不可能、、、というかUWSCでも無理じゃないか。。
Xamlが読める静的コード解析ツールを探すか作れば一応可能ではある >>517
uipathはテキストベースなのね。
うちで使ってる製品はそうじゃないから、diffすらとれないかなしみ
テキストにエクスポートする機能はあるけど、
苦労して設定した各コマンドのプロパティ値が出力されないので
技術的には意味のないシロモノがでてくる・・・ 経営がうまくいかなかった奴らが言っても説得力が…w RPAを使いこなせる会社だったら、RPAを使わずにシステム化している。 rpaじゃなくてもデータ読み込んで1個ずつ会計アプリに項目を入れていく仕組みを経理とかの人はつくれたんかや?
エクセルの関数は使えても他のアプリとの連携は俺には無理だったからrpa有難いが
uipathだけども >>525
社内で勝手にシステム作ったら怒られるねん プログラマならRPAの可能性に夢を膨らませないなんてことがあるだろうか? プログラマはRPAのばかばかしさを理解できてしまうので逆に夢を見れません プログラマはプライドが謎に高いのでRPAを認めません 社長からyou自作してって言われたらどうする?
面倒じゃん素直にRPA入れたくねえ?金はあるんだし導入はベンダーもいるし、これからは小学生でもプログラムかける時代来るんだよ。 社長に限らず、魔法とプログラムの区別がつかなそうな人からの依頼は、
全部RPAにぶん投げたいな。 >>531
RPAだと面倒だから素直にプログラミングするほうが良いです まぁ今後RPAが根付くか根付かないかは結局はユーザーなり導入した企業が決める事だからな。
プログラマはRPAが嫌いだろうが何だろうが関係ない。
所詮ここでイヤイヤ言うしか出来ない。 会社もプログラマーももっと大きいシステム導入やってて裾野の作業の自動化まではやってくれない
それなら業務区で導入から保守までしやすいRPAは便利。
導入支援から保守販売しちゃうような乗っかり商売のシステム会社はあかんだけだろ >>528
RPAが内部でやってることと同じ処理を自前で作るよ。
どんな開発言語でも大抵は出来る。
開発ツール使えない環境でもPowerShellでも出来るし、VBAでも出来る。 >>535
保守がしにくいから問題だと思うんだが。 ショボグラマはRPAの可能性に脅威を感じております 問題は資産が増えてきて非エンジニアの手に負えなくなってきた時に表面化するのでしょうね プログラマに気を使って業務効率上がるなら、そうした方がいい。
残念ながらそうじゃないとこが問題なんだが。
RPA嫌いなプログラマはRPA導入の前に各部署の業務サポートに回った方がいいぞ。 Excelマクロと同じく、先を見通せない池沼に毛が生えた程度の社会人には丁度いいツール
でも将来RPAの存在が邪魔になっても助けてやらん ローカル用語じゃね?
業務側システム側的な意味でしょ。 >>542
面倒くさいヤツだな。
もしかしてプログラマが会社の中心だと思ってるのか?
会社なんて人それぞれ役割があって成り立つんだぞ。
まともな社会人で先を見通せてるなら先に問題が起きないように文句ばかり言ってないで何か手をうて。 >>540
RPA導入企業と将来メンテナンスする企業は同じになるとは限らないですよね
まだ契約もなにもない他社の各部署のサポートなどできるわけがありません
ですので将来メンテナンスするエンジニアの立場から他社企業のRPA導入を未然に防ぐことは不可能です >>545
そう言う場合はメンテ会社としては仕事が貰えるから、それはそれで大変かもしれないが、いい事なんじゃない? プログラマなら夢のような簡易プログラミングツールに騙されたことが一度や二度はあるので
それは夢だと知っている
ちょちょいと作って腐ったら捨てて、新鮮なのを作り直せば良いから楽な範囲では便利 プログラマはRPA使わない理論って、
プログラマがWordPress使わないのと一緒じゃん
本職以外の人でも比較的簡単に構築できるから重宝されるのであって、
プログラマの世界でRPAがディファクトスタンダードになるわけないし誰もそれを望んでないだろ
ここでRPA執拗に否定し続ける人、某タクシー業界を見てるようで悲しくなってくる
RPAが流行ってもプログラマの仕事はなくならないし、
RPA保守のニーズが新たに生まれるくらいだから安心していいよ
保守の仕事が嫌ってんなら別に受けなきゃいいだけの話だしな プログラマが個人用途の趣味でブログを作る場合、今時だとStatic Site Generatorを使うのかね >プログラマはRPA使わない理論って、
>プログラマがWordPress使わないのと一緒じゃん
>保守の仕事が嫌ってんなら別に受けなきゃいいだけの話だしな
まさにこれ。 rpa導入する→導入サポートできるね!
動かない→保守できるね!
仕事増えて売上増えてWinWinなのに何めんどくさがっているんだよ! ストレスフルで生産性の低い仕事では金を積まれても気が進みません >>552
出来ませんって、断ればいいじゃん…
そんなに立場弱いの? >>554
仕事なんて金貰う以上、ストレスフルでも気が進まなくてもやる事があるなんて至って普通じゃないの?
プログラマの世界は違うの? >>556
仕事選べる立場じゃないからRPAを執拗に否定してるの?
そんなの保守したくないー、って。 細々した定型業務を自動化するのにRPAより良い選択肢あるなら逆に教えてほしい。 Microsoft、google、facebookと渡り歩いたレベルの高い俺みたいなエンジニアにとってRPAの仕事なんざ工場のライン工やるぐらい苦痛だね
あんなんの保守の仕事は富士通とかの日本レベルのエンジニアやらせとけって話だわな
まぁ、全部嘘なんだけどね >>559
10年くらい前に導入されたERPの値取ったり転記したり…
あとはIE使えないセールスフォースとかのデータスクレイピング、書き込み自動化
他にも営業部門や管理部門が抱えてる定型業務(専用ソフト間の転記やメール送信、締め処理とかの定時作業)
セレクタがころっころ変わるサイトの対応…等
COM弄れるIEやEXCEL間の処理はUWSCで自動化済みなのですが、度重なるサイト側の仕様変更追いかけるのめんどくさくなってきて、
スクリプト使う人が自分でメンテしてくれないかなぁでRPAに行き着いた感じです コードで全て解決します!
この宇宙もプログラマが作りました。
コードを信じて下さい。皆幸せになります。
コード書けない人は地獄に落ちます。
RPAは悪魔の手先death。 まあ、正直に言うと、俺はRPAツールを使いこなせそうもないから、
プログラム書くわ。 RPAが駄目でプログラムがいいって理由がよくわからん。
本質的には同じものでしょ? >>564
いいんじゃなね?
人それぞれ自分に合ったツールを使えば。
コレじゃなくちゃダメって方がおかしいだろ。 >>562
サイトの仕様変更を各人が追いかけるのは良くないアイデアですね
そのサイトを利用しているユーザーが社内に100人いたら仕様変更が発生するたびに100人がそれぞれ抱えるプログラムをメンテナンスしなければならないため非効率的です
そのサイトへのアクセスをカプセル化したクラス部品を作って共有してはどうでしょうか?
そうすればサイトの仕様変更が発生してもクラス部品の修正は1回で済みます
クラスのパブリックインターフェースが変るような大きな仕様変更の場合は各人の作業が必要ですが
その場合でも各人がサイトの仕様変更を分析する労力は不要となります >>565
グラフィカル環境は単純に生産性の低いという事と、既存エコシステムとの相性不一致が主な理由ですね
また>>567で指摘したような問題もあります
全員がそれぞれ独自にサイトやツールの自動操縦処理を作り込むのは作業の重複となって非効率です グラフィカル環境が生産性低いってUIPath使ったうえで言ってる?
偏見じゃね? 例えばVisual StudioなんかでもGUI部品はGUIで組んだほうが全然生産性高いでしょ?
そりゃHTMLみたいなのシコシコ手書きするのも悪くないけどさ >そのサイトへのアクセスをカプセル化したクラス部品を作って共有してはどうでしょうか?
>そうすればサイトの仕様変更が発生してもクラス部品の修正は1回で済みます
まともなRPAなら同じように共有なところをクラス化出来るってか、そうやって作るけどね。 個人の好き嫌いがあるのは構わんが、現物を触ってもいないのに頭ごなしに否定しているのはどうかなー。 >>536
何で今までやってこなかったの?
プログラマーはサボリーマンなの? >>569
本当に生産性が高いならプログラマが自分達の職場で積極的に使ってますよ
でも100人いても誰も使ってないのが実情です
>>570
いわゆるRADは最近は見かける事も減ってきました
生成されるコードの品質がいまいち
要素の入れ子のコントロールが難しい
動的なUIを開発しにくい
マークアップベースのエコシステムの進化が著しい
など理由は多々あるようです
>>571
ブラウザやアプリとの相互作用という特殊な処理をクラス化すれば残った部分は純粋なビジネスロジックなります
これをRPA開発環境でやる理由はないと思われますが?
しかしそうするということはうまく部品として抽出できていないのでしょうね >>567
もちろん、配布したスクリプトで仕様変更の可能性があるセレクタ部分等は変数として共有サーバーに置いたiniから読み込むようにしてます。
スクリプト自体を書き換える事は滅多にないですが、セレクタの仕様変更のたびに毎度Chromeで要素解析するのがめんど…辛くなってきたので、他の人に振りたいというのが本音です。
専用ツールに関しては要素自体取得できないのでやむおえず画像のテンプレートマッチで自動化してますが、これもメンテに手間がかかりすぎて…
RPAなら専用ツールでもどっからでも値がとってこれるので楽と感じてたのですが、スクリプト組む場合、解析はどうするのがベストなのでしょう??
やはりSpy++ですかね… もしRPAがいらないほどの自作クラスライブラリを構築済みだというならそれで商売できるぞ?
いっそ起業しろよ >>574
まずRPAは対象がプログラマじゃないんじゃないの?
なんでアナタの目線は全部プログラマ中心なの?
そして、クラス化後の残った部分は純粋なビジネスロジックだよ。そうだよ。
RPA開発環境でやる必要がないって言ってもそのまま出来るんだから、それでもいいんじゃない?
一個でもまともなRPAを触ってなにか作ったことある?
オレは本職のプログラマじゃないけど、簡単なコードだけどプログラム経験は一応あるよ。
両方それぞれ利点があると思うよ。人それぞれ使いやすい方を使えばいいと思うんだけど。 >>573
君の前ではやってないけど、自分の仕事の前ではやってるよ。
別に俺はRPAが駄目だとは思ってない。
ちゃんと組むと結局プログラム組むのと同じだし、ちゃんと組まないとVBAが叩かれてるのと同じ理由で駄目なもんが出来上がるんじゃねって話。
>>575
Spy++より使い勝手の良いツールを何個か持ってる。
その内の1つは自作だけど。 >>580
UI走査自作できるの羨ましい
Spy++微妙だしであとはUIspyかInspectか…てところでUipathに出会ってもうこれで良いじゃん化した次第
都度変わって大量に作らなきゃならないアプリ間連携部分の処理を楽に構築からUipath気に入ってるけど私の知らない更なる楽な方法あれば是非知りたい はじめてのRPA体験がUIPathかWinActorかでRPAに対する印象が大分違うんだろうなww RPAの方が難しいように思えるが・・・。
プログラムは、無い機能も作ればあるから。 プログラムは自由度が高い分、何で出来るよね。
自由度がある分、使いこなすには経験とスキルをようするけど。
RPAは自由度が限られてる分、可能な範囲は限られてる。
でも機能が限られて目的がはっきりしている分、取っ付き易いし、間口が広い。
一般事務職に受け入れられてるのはこう言うとこだろう。
どっちも一長一短だ。 >>575
WinAppDriverにはレコーダーがあります
XPathをサポートして出力形式はC#ソースコードになります
VBAユーザーが得意なレコーディングから構造化するパターンの開発ならこれでしょうか
C#コードなので部品化もしやすいです
>>577
RPAで純粋なロジックを組むのは大変だと思いますけどね
例えばですけど
RPAでコレクションのクイックソートを実装できますか?
RPAでグラフの最短経路問題を解けますか?
もちろんInvokeCodeやカスタムアクティビティのような普通のプログラミング言語を呼び出す機能はなしでですよ クイックソートはまともなRPAであれば組めるけど…。
グラフの最短経路はわざわざRPAだけでやる必要ある?
それを求めるのがRPAを使うような人がやる仕事?
何度も言うけど、何で視点が全部プログラマ中心なの?
ちょっと考え方狭くない? >>587
RPAでロジックを書く難しさを想像してもらうために例えば〜と書きました
RPAでクイックソートや最短経路問題を解く需要は少ないでしょう
しかし業務ロジックにその程度の技量が求められることは珍しくないです >>586
WinAppDriverって管理者権限必要じゃなかったっけ? クイックソートもダイクストラ法も簡単に実装できるよ
そう、UiPathならね 何か勘違いをしておられるかもしれないが、
RPAでいう"業務自動化"って新たな業務システムを1から組み上げることじゃなく
既存ソフト上で行ってるルーチンワークの操作内容をただそのまま再現するBOTのことぞ
RPA側ででやるのは既存の業務マニュアル通りにシナリオ組むだけだしロジック考える技量は不要
マニュアルない場合も業務手順を担当に聞いてシナリオに落とし込むだけで終わり
コーディング支援ツールなんかではない。一般人のために作られたただの業務支援ツールそれがRPA おばちゃん達が一日中ポチポチやってデータ採りしてるのを、夜にパソコンで自動でやらせる
これが正しいRPAの使い方 RPA以前に業務プロセス見直したらその作業自体必要なかったりすることもしばしば まず業務プロセス見直しから入るべきって言われてるよね なにか矛盾してますよね
RPAを使えばエンジニア不要と言っているのに
じゃあいままでエンジニアが必死こいてやってきた業務分析やロジックの設計実装はどうするのと聞くと
そんなことはRPAのやることじゃない極々単純なルーチンワークの自動化に使うんだと言う UiPathなりちょっとでも使ってから否定すればいいと思うの… 業務分析て必死にヒアリングするだけじゃん
ほんで抜けもはあるフローが完成しちゃうくらいなら
RPAで業務担当が作った方がいいじゃんて事でしょ
確かに業務見直してあるべき姿にして、最低限の連携プログラムのみ作るのが1番だとは思うけど、運用変更、追加やら出てきたりしてやりきれてないのが現状でしょ システムは業務プロセス全てを俯瞰した全体設計を基づく
RPAは個人レベルのタスクのルーチンワークの補助
のような位置づけにすると、後者は利用者レベルで完結して貰わなければ変だな >>586
WinAppDriverありましたねそういえば!
出始めの頃使ってみたのですが、うまく動かず安定するまで寝かせたままですっかり忘れていました…
スクリプト言語しか知らないレベルなのでC#は正直1から勉強しないと厳しいですが、知識があれば色々と便利そうなので少し触ってみます >RPAを使えばエンジニア不要
というのは
>(極々単純なルーチンワークの自動化には)RPAを使えばエンジニア不要
という意味ですね
(簡単なホームぺージをつくるだけなら)WordPressを使えばエンジニア不要
(単純な表計算には)Excelを使えばエンジニア不要
と同じでエンジニアにコーディングを依頼せずとも目的が達成できるという意味
ベンダーがRPA売りたいがための誇張広告「エンジニア不要」が癪に障るのはとてもわかりますが、
システムを作る側(エンジニア/コーディング)と使う側(ユーザー/RPA)という決定的な差があるので
RPAをエンジニア視点で「システムを作るツール」としてみるならもちろん不十分だし
RPAをユーザー視点で「システムの使用効率を高めるツール」としてみたら便利に使える、と 「RPAの現場主導は非効率」、アビームが説明
アビームコンサルティングは2019年3月14日、定型業務を自動化する「RPA(ロボティック・プロセス・オートメーション)」の動向に関する説明会を開催した。
同社の安部慶喜戦略ビジネスユニット執行役員プリンシパルは「業務プロセス自体を変えない現場型のRPA導入は非効率」とクギを刺す。
https://tech.nikkeibp.co.jp/atcl/nxt/news/18/04432/ > ソフトロボットの動作を記録するログについては「製品によっては動作の過程を含む詳細なログを取得できない」(同氏)という。
> 安部氏はこれらの要件を満たすRPAツールとして「BizRobo!」「UiPath」「Blue Prism」の3製品を挙げた。
あれ、ニッポンの埃WinActoなんとかは?w システム更改時にRPAが動かなくなるから画面を合わせろとか宣う顧客が出てくる定期 モニタの解像度変えたらロボット動かなくなってプログラマンに怒られました >>582
Inspectは自分も使ってる。
UIspyは今はダウンロードできる?
持ってるけど挙動も少し怪しい。
自分が一番使ってるのは大分昔にダウンロードしたフリーソフト。
ハックツール扱いで使ってた人が多かった。
その人のHPが閉鎖して今は手に入らないな。
あとは自作した奴で、その言語用だけどソースコードを自動生成する奴。
他にもVBAで作った奴とかもあるけど完成したツールとは言い難い。
RPAはそれが無いと動かないのが。
ソースコード生成なら無くても良い。 >>607
もしやWinspectorでは…?
太古の記憶が読み覚まされてきた
うさみみとかollyなんたらとかで色々やってたわ…懐かしすぎてへんな汁出てくる
UiPathには専用のuiエレメント走査ツール組み込まれてて、調べると同時にセレクタに反映できて便利り スーパーコントローラーIIの、メモリー機能の使い方が未だにわからない。
操作を記録して、それをそのまま再現するものだと思ってるんだけど、違うかな?
RPGで、アイテム選択が楽にできるって箱に書いてあるんだけど。 余計な機能盛り込みすぎなんだよな
ジョイカードMK2で十分だろ 破産者マップは面白いアイデアだな
短時間しか公開されないPDFを収集してキャッシュ&検索可能にしただけでこの反響
RPAで最も成功した事例のひとつではないだろうか メカ系技術職だけど、本社でRPA導入が進められてて話がきそうなんで調べてるんだけどこれどういうとこに効果的なんだ?
導入しようものなら仕事作って工数削減目標ださにゃいかんから断り続けてるけど、いつまでいけるか………
社内のマウスぽちぽちしかうけつけん糞システム使おうにもOCRや画像認識に信頼持てんの?例外処理とかどうすんの?
って疑問が解決されねーから導入してるとこはそのへんどーしてんのか気になる。 UIPathなら例外は普通に使える。
OCRはちょっと厳しい。 Blue Prismもフツーに例外処理使える
RPA導入するなら、
• UiPath
• Blue Prism
• Automation Anywhere
あたりで検討進めた方がいいよ
変な国産RPAはオススメしない OCRとRPAの組み合わせはOCRソフトを間に一個噛ませないと厳しい
OCRは正直まだ相性良くないかも >>614
技術者なら不要かと
むしろ既存のエコシステムが使えなくなるデメリットのほうが大きいです 例外処理にも色々あって
・catch throw
・未知の原因で正常に終了したとき
・蕎麦屋の出前の依頼FAXが来たとき
・停電
・カレンダーに無い営業停止
・他
どれを問題にしているのかは知らない ある時間になったらパソコンを立ち上げたりログインするRPAできる?
電源いれるのは無理ぽ? >>620
Wake on Lanと自動ログインでできそうですね
何にせよRPAは関係ないかと いや何を言ってるんだ
普通にBIOSの設定を変更すべきでしたね >>623>>624>>625
ありがとーアリバイ工作に使います!dd >>618
ツールに縛られて腰が重くなるのあるあるですね。
自分自身は日頃から簡単なスクリプト程度なら組んでるし、自分にメリットなさそうだから色々理由つけて導入蹴る方向にしよーっと >>620
昔、PCの電源24ピンのどのピンとどのピンを繋げたら電源入るかを調べたのよ。
で、電子工作でスケジュール通りにスイッチの入る基板作って英会話勉強用にNHKラジオ録音させてたな。
USBで繋がるコンポはPCからコントロール出来る奴だったのでPCの電源入ったら勝手に録音して、MP3に圧縮するプログラムと、起動してから30分後にシャットダウンするプログラム組んで。 >>624
その当時は出来なかったと思う。
その時はWakeup On Lanもマジックパケット流す側が無かった。 Automation Anywhere ジャパンの社長が業績不振でクビになったって本当ですか? >>629
その当時がどの当時かは知らんし個人的な昔話ならチラ裏にでも書いとけよ >>614
技術者の場合は日報管理とかテーマ登録とか日常業務じゃないか
どちらにしても作業減らして考える仕事時間増やすのが目的なだけだから頭しか使ってないと自負できるなら導入無駄 横浜市がRPAの有効性を検証、導入した業務で平均84.9%、最大99.1%の作業時間を削減
https://it.impressbm.co.jp/articles/-/17606
長野県がRPA/AIの実証実験、RPAで作業時間を最大88%削減、AIで見積もりの正確性を向上
https://it.impressbm.co.jp/articles/-/17607 うちもこういうのの成功例として記事になってるけど、
今は誰にも使われずにゴミになってるよ
特に実験とかPOCとかのワードで上手くいったとかはゴミプロジェクトの可能性がかなり高い >>635
> うちもこういうのの成功例として記事になってるけど、
> 今は誰にも使われずにゴミになってるよ
> 特に実験とかPOCとかのワードで上手くいったとかはゴミプロジェクトの可能性がかなり高い
どうして誰も使わなくなったのか知りたい >>634
役所や中小企業は工員のような繰り返し作業をPCで丸一日やってたりするから、
RPA導入が効果を発揮することも有るかも
そして、ほとんどは、RPAではなく、シェルやExcelのマクロで代用可能 RPAの導入なんて目辺り次第に自動化してもダメだろ
まず今の業務が本当に必要か?とか見直すと、案外業務自体がいらなかったり単純化出来たりする
見直すキッカケになるのはいい事だけど 本当に必要な業務だけに減らして減らして減らして生産性を上げてきたのが日本
回りを見ても無くせる業務はもうないでしょ?
はんこ無くすなんて自社だけで出来ることではないし、現場でどうにかできるものでもない >>640
お前さんの見ているところに(みつから)ないだけで日本中にいくらでもあるぞ >>640
本当に不要な業務が増え続けてるのが大企業な印象ある
特に腰が重いとこほど
自分は毎日「これ必要ですか?」って言い続けてるよw 業務をちゃんと理解していれば、不要なものは不要と断言できるから、やらなければいい
やらなければならないという事は、知らないだれかが必要としているという事
たとえば二重チェックなど、一見無駄な多重チェックを、責任を持って無くすのは、簡単ではない
年に一回ぐらい数量や品物をまちがえても良いようなおおらかな社会ではない
後始末の手順はあるから、後始末すればいいと考えるのは、ときに信頼を失う
ISOやプライバシーマークに関する手続きは、意味不明なレベルで実効性が無いけど、無くすと商売に差し支えるから、やる
けれども理屈はともかく、責任を持って無くせる業務なら、明日にでも無くそう 自動化と全自動はまた別のもの
それはただの出来損ない 不要だと思いながら、万が一ばかりを考えて業務が増えて行くのが日本企業。
万が一、万が一…
集めたデータも活用しなけりゃ、只のゴミだ。 >>613 あれは単なるウェブパースでRPA ではないでしょ? 成果物の品質を緩くすれば、日本人はもっと楽に仕事ができる
自分は何もしないのに細かい指摘する阿呆が多すぎなんや >>644
>やらなければならないという事は、知らないだれかが必要としているという事
皆んなお互いにそう思って仕事が減らないのでは…
何かあった時に責任も取りたくないから、外部コンサルに見直して貰って、
何かあればコンサルのせいに出来るようにしている会社も多いと思う >>648
自分がやったら何日もかかることを、他人にはすぐやれっつーキチガイサイコパス野郎ばっかだからな RPAは横浜市のノースキル職員に酷いことしたよね…
堂々と税金から給料もらえてたのにこれから何しろって言うんだよ!仕事ねーよ!
横浜市「RPAの有効性検証の成果について」を読んで、仕事とは何かを思い知らされる
https://www.orangeitems.com/entry/2019/03/19/201652?amp=1 >>657
お役所の人は人数が多い割に合わテキトーな仕事ばっかりやってるよな
税金で食ってるんだからもっと生産性のある仕事やってくれ
いくつもあるデータの単なる転記とかPythonで自動化しろ 公務員にはコスト意識が働かないので仕事の自動化という発想が無い
民間とは違う 票から表に転記する!
ファイルにパスワードかけてメール!
メールアドレス申請を見て、メールアドレスを作り、発行!
番号入力!クエリー!確認!
クエリー!まとめて一覧表!
エクセル見ながら画像をローカルに保管!(ローカル・・・)
ダウンロード!グループウェアに登録!
RPA関係なくてわろたw 関係なくないだろ。それをどう解決するのかという話で。
システム刷新してapi連携か、スクリプトか、はたまたrpaかとかいう話。 >>661
つまりこの事例の本質は容易にシステム化可能な定型作業多すぎってとこが本質であってそういう意味でRPA関係ないってわけ 今日の俺の仕事
webのとあるページにあるメニューを全て開き、
その先にある帳票を全てダウンロードw 何時間でやる仕事か知らないけど
業務時間外にダウンローダー作って
それ以降は本でも読んでるな (´・ω・`)調剤薬局の薬剤師をRPAしてコストダウンして安くしろ。 仕様書からエンドポイントのリストを引っ張ってきてループでcurl叩くだけやんけ クライアントにLinux入れられなければ出来ないな
フリーソフト入れさせないガチガチ事務環境に多い 仕様書からエンドポイントのリストを引っ張ってきてパイプラインでInvoke-WebRequest叩くだけやんけ >>668
┌──┐
├──┤┓
│II,,,┌──┐ チラッ
│ ;;;;|::━◎┥
└/ `ヽ.
__/ ┃ __i |
/ ヽ,,⌒)___(,,ノ\
┌──┐
├──┤┓
│II,,,┌──┐ ケハエ グスリ ダシテ オキマスネ
│ ;;;;|::◎━┥
└/ `ヽ.
__/ ┃ __i |
/ ヽ,,⌒)___(,,ノ\ >>668
もっとも低コストで完ぺきに自動化出来ますが、薬剤師さん達は法律でガチガチに守られてます。 あれまじで意味不明だよな
処方箋から調合するでもなく既存の薬取ってくる倉庫内軽作業相当なのにやたら時間掛けるシステム uipathで認識しない時どうしやいいの?
イメージクリックなんて使えるんか? スクリーンスクレイピング?で画面全体を認識しちゃってその中の選択したい要素を全く認識しないんだけど >>671
Windows10(アプデ済)ならcurl使えるけどね ”画像をクリックする”を負けだと思ってはいけない。
アンカーになりそうなものははそばにないか? 良くわからんWebの話ってどんな言語でも出来るでしょ。
何でLinuxの話になってんの? RPAの事例とツールをガートナーが比較・分析、「導入と運用の勘所」とは
https://www.sbbit.jp/article/cont1/35887
> IT部門を中心に現実が見極められてきたため、幻滅期に向かう位置付けだが、非IT部門の期待値は依然高い状況のようだ。 image clickで頑張ったわ
とりあえずこの開発pcならいけたわ 解像度変わると動かなかったりするから気をつけろよw 部分最適化大好き全体の見通しが立てられない日本人だからRPAが流行る 調べてたらjsで指定できるらしいけど、俺経理やしそこら辺わからんかったわ 日本企業では他部署はおろか下手したら部内の他チームの領空侵犯すら嫌がられるからな
全体最適化に照準したビジネスロジックよりも人間関係重視で、既存の業務の枠組みの中だけで効率化しようって話になる
つまりマネジメント不在 単に環境の変化が嫌なだけ
人間関係とかいって他者への配慮を建前にしてるけど本音は個人のわがまま
そして日本人はみんな同じことを考えてるから
民主主義的なプロセスを経てそんな個人のわがままが正当化されてしまう 変化が嫌いなのも非効率が許されるのも人に仕事が付くのも、全ては終身雇用だからなんだな Excelマクロの悪夢再来みたいなノリが多いような気がするんだけど、よくわからんのよな
Excelマクロがブラックボックス化するメカニズムはわかる 作成者(わかる人)が異動や退職でいなくなって誰もわからなくなるわけでしょ これは腐ってもvbaはプログラミングだからエセも含めてプログラマーしか使えないというスキル差に起因する
その点、RPAならguiで誰でもわかるようになってるという建付けなので大丈夫なような気もするんだけどな プログラミング言語が出来るかどうかって実は開発プロセス全体からすれば些細な問題なんだけど非ITの人からだとそれが全てに見えちゃうのかな OSのバージョンアップで動かなくなる、
逆に言えばOSのバージョンを上げると動かなくなるのでOSのバージョンを上げられない、
みたいなトラブルが用意に想像出来る VBAは作った奴が退職して誰も弄れないブラックボックス化するケースが実際にめっちゃよくある
他にVBA弄れる奴がいたとしても他人が自己流で好き勝手組んだコードを解析するのって単純に骨の折れる作業だし
その点UiPathなんかのフローチャート式RPAは業務フロー自体が自動化シナリオと完全にリンクしてるから管理はしやすいと思うよ
スクリプト方式のRPAに関してはまあExcelマクロと似たようなことになるのは否めないな フローチャートもプログラムも可視化の方法が違うだけで同じものだよ
なのでプログラムで起こっていた問題はフローチャートでも当然起こりうる フローチャートもフロー間の依存関係が複雑化したりフローの正規化が甘かったりしたら結局スパゲティコードを相手にしてるのと同じことになるんじゃないの? お金とってRPAとして売っているのはフローチャートも扱えると思うから
フローチャートを読み取って
画像認識と条件判断と変数、定数、画面操作のここをこう変えれば正解になるのが分かるスキルがあれば
柔軟にスピーディーにできて、別に困らない
RPA自体の操作はマニュアルを見れば良いし
講習会も頻繁にやっているみたいだし フローチャートだとあまり複雑なことはできないからドツボにハマりにくいだけじゃね?
同じような処理なら同じようになるとと思う フローチャートの欠点は大画面でないと全体がみえないから印刷することになったりすること
消極的な欠点といっていいのかわからないけど
フローチャートだと追加変更が簡単だから同じ処理を何箇所でもできるのも良し悪し
合流させたり、そこまで条件判断でスキップさせたり飛ばしたりしてくれると大丈夫 RPAとプログラムが別物のようにいうやつがいるが、
RPAでの実装は本質的にはプログラムそのもの >>698
RPA製品じゃないけどグラフィカルプログラミング環境を採用してスパゲティ化した資産を溜め込んじゃってる企業様なら知ってる
コードと同じようにフローチャートも仕様変更や拡張が積み重なるとすぐに成長して大きくなってしまう
そうすると例えるならまるで電子回路やニューラルネットワークみたいにグラフが複雑化しちゃってわけがわからなくなってしまうんだ >>699
スキルがあれば、研修を受ければっていう与件が既にコストになってるやん
そこいらのホワイトカラーの抽象化能力ってかなりお粗末だぞ >>699
>フローチャートを読み取って
コードを読み取って
>画像認識と条件判断と変数、定数、画面操作のここをこう変えれば正解になるのが分かるスキルがあれば
インフラとの相互運用方法、条件判断と変数、定数、ロジックのここをこう変えれば正解になるのがわかるスキルがあれば
>柔軟にスピーディーにできて、別に困らない
柔軟にスピーディーにできて、別に困らない
>
>RPA自体の操作はマニュアルを見れば良いし
インフラとの相互運用のAPIはマニュアルを見れば良いし
>講習会も頻繁にやっているみたいだし
講習会も勉強会も読書もトレーニングも頻繁にやってるみたいだし
おかしいなプログラマはみんなそれでも苦悩してるんだけど…? RPA導入時に考慮されなかった環境依存性についてはドキュメント化の対象外になるだろうからなぁ
利用部門側でその問題に直面するとなるとなかなか大変なことになると思うわ 非効率な仕事をやってた人間が
RPAを使いこなせるかと言われたら… >>703
そもそも電子回路も複雑化してFPGAとかはコードでしか表現できなくなってるしな 普通のホワイトカラーなり事務員にとってはvbaですら絶対不可能なラテン語みたいな扱いだからなあ 個人的な印象だけどね
その点、みんながわかるguiなら違うかなと
例えば、ラテン語なら読み解く気すら起きないけど、日本語の文章ならたとえ難解でもみんなで頭捻って考えて読み解ける、みたいな 甘いわ、GUIなら分かるってのも幻想
現にSAPやTableau、SharePoint、WordやExcelのGUIなんかが実にひどい使われ方をしてるだろ >>709
読む気が起きないが読んでみようかなに変わるだけで、そこから先の読んで見たら訳がわからないという問題は変わらない。
入り口の薄い障壁1つが取り払われたところで、その後の本質的な問題は変わらない。 というか、フリーでデプロイ・アクセスできるIT学習ツールがこれだけネット上にあるのにIT出来ない奴がこれだけいるのを見れば、世の中どうなってるか分かるよな 学習ツールが公開されてると世の全員がやるのか?
この合間合間におかしなこと言う人何なの Excelのピボットテーブルですら、
何回説明しても理解出来ない奴らおるやん
魔力がないやつには魔法は習得出来ないんやで(異世界脳) bizroboでいくつか作ったけど、辞めた後メンテナンス出来る人間いないだろうなってぐらい魔境と化してる。
VBAの方が文で作られてるだけ解読はしやすい気もする。 データベースは分かるけどピボットテーブルは分かんなかった >>715
リファクタリングツール使ったらどうかな
RPA開発環境にも当然あるんでしょそういうの? >>716
ピボットテーブルはクロス集計クエリ用のちょっと見た目が特殊なビューテーブルだって分かれば簡単だぞ 簡単な事が最初から理解しようとしない人達が多いって事だろ エクセルワークシートのIF関数やVLOOK関数が使えれば凄い、INDEX関数になると分かりませんっていうレベル感だから事務員におさまってるってパターンが殆どじゃん
事業部門側でリファクタリングツールとか絶対に使えるようになるわけないと思うわ
操作手順だけを丸呑みして覚えるタイプの無駄な適応反応をもたらすだけ >>721
それは単に職域の違いだろう
じゃあ君は経理の仕訳の事をちゃんと理解してるのか、と
まあこの程度は社会人として常識レベルだから知ってるとは思うが リファクタリングツール使えないなら手作業でリファクタリングすんの?
例えば拡張し続けてフローが長くなっていろんなことやりすぎるようになったとき
一部分だけを抽出して再利用可能なパーツにしたくなった場合は?
プログラムだったら範囲選択して右クリメニューで抽出できる
変数とかも全部解析して引数と戻り値に置き換えてくれるけど手作業だと結構難しいよね
ツール使ったほうが簡単じゃないかなあ
あとさプログラムだと出来の悪いコード書いたらこっちのがいいよって提案してくるじゃん?
昔は構文木のパターンマッチだったけど最近だとAIが提案してくれるようになったアレ
提案をクリックして受け入れたら提案通りの出来のいいコードに自動で直してくれるやつ
アレは結構便利だとおもうんだけどRPAでもそういうのやってくれるのかな? >>722
リファクタリングツールを使いこなすだけの論理的抽象化能力を大多数の事務員に期待できるかという問題についてエクセル関数の理解度を例として個人的に否定的な見解を示しただけだから、職域の違いだという指摘はあまり意味がない
RPAを事業部門側でメンテナンスするとなったららメンテナンス担当者の職域に論理的抽象化能力を要する業務フロー改善が含まれることになるわけだしね
それに、職域に限らず論理的抽象化能力は必要だろ、デスクワークなら特に
経理の仕訳について理解してるかどうかという具体的な質問に至ってはそもそも会話が成立していない >>709
VBAも簡単だよ。
マクロの記録と再生するだけ。
誰でも出来る。
でもそんなのじゃ大したことが出来ないよね。
RPAも一緒。
RPAも頑張って作れば誰もメンテナンスしたくなくなるものが出来上がる。 生産性が低いからシステム成長が遅くメンテしたくなくなるまで時間がかかるハズ
その点はRPAのメリットと言える >>722
経理の仕訳なら研修受ければ誰でも出来るようになるじゃん。
「誰でも出来る」を目指してRPAの研修もあちこちでやってるけど、
経理のように結果が出るかって話 20年同じこと繰り返してきただけでそこそこ年収もらってる事務ババアを絶滅させようよ 事務ババアにRPAのスタートボタン押してもらわないとw
あとRPAがこけた時の報告 経理のおばちゃんだけどRPA研修受けて出来るようになったよ。
ただ自分でスプリクト?マクロ?を書くメニューはわからん、知識がないから。
エクセル関数と同じで既にあるものを組み合わせて使うのは余裕。
マクロとスプリクトの勉強は事足りててやんない可能性もあるけど興味は出たよ、こういうマクロ欲しいから教えてって言えるシステムの優しいお兄さんが社内にいれば良いんだけどねー、別に全部一人で出来る必要ないじゃない。 できるとうまくできるの差は天と地ほどあって
できるだけでシステムをせっせと拡張していくと後で困ることになる 事務ババア好きやで
エロいし巨乳だし時々お菓子くれるから 知識ないって開き直るなら手をつけないでもらえますかね?
どうせそれ手に負えなくなってIT部門に転がり込んでくるんで このツールなんですけど、Twitter上で動作してくれません。
どうしたら良いでしょうか。
仕様ですか…?
使用目的は自動ツイートです。
https://amimilab.com/mytools/page-49/ RPAは積み木みたいなもん
既にあるパーツをどう積み上げれば目的が達成できるかを考えるのは一番やりたい事を理解してる事務のオバチャンがやるべきだし
足りないパーツが出た場合にInvokeCodeで新しい積み木パーツを創る仕事はプログラマに任せればいい
会社の強味ってそうやってお互い得意なことで助け合えるとこだし、それが一番効率的だと思うよ >>734
Twitter側で弾かれてるっぽい
単発の自動ツイート目的なら
「AutoTweet!」
とかが手っ取り早いのでは 積み木かどうかは業務の複雑性によるだろう
もし大半の業務が積み木で済むようなシンプルな世界だったならDDDのような開発技法は発明されなかった どんなに複雑でも定型化されてる以上は積み木と同等。いやプラモデルと言ったほうが適切か
いずれにせよ手順通りにパーツを組み合わせていくだけには変わりない
事務のオバチャンという名のドメインエキスパート自身がRPAのシナリオとしてドメインモデルをアウトプットすることになるし、
完成したドメインモデルはユビキタスなフローチャートとして表現され且つそのままXAMLコードとして機能する >>738
それってプログラミングもそうなんだよ。
君の言う通りなら事務員のオバチャンがC++で開発するって話でも問題無いんだよな。 >>740
本質はそうだよ。
でもその理論でいくと極論アセンブリ言語やらの低級言語でいいよねって話になるよ
現実はCなりC++なりの高級言語が主流だよね。なぜかって、分かりやすいもん。
それと同じで、高級言語よりも更に分かりやすいWWFベースで開発するのってそんなにおかしい流れかな 単純作業に見えて、ベテランが勘と経験でやってる
これちょっと違う、あやしい、要確認
あの人がいうアレは本当はコレなんだけど、違うって言うとうるさい。方言らしい
みたいなのも取り込めるなら最高 >>741
わかりやすさがスケールしない
わかりやすいけど変更が難しい
この辺りがポイントかな
プログラマがWWFを自分達の仕事に採用しなかったのは何故か? >>741
分かりやすいVBAは、やたら非難されてる。
VBAが駄目なんじゃ無くてスキルの低い奴のメンテナンスしようが無いコードが世の中に大量にあるから。
Excelを使ってる人は、自分がやりたいことだけできれば良いけど、世の中のたくさんの人達のやりたいことを実現させようとすれば複雑に成らざるを得ない。
RPAも世の中全体で言えばやりたいことが大量にあるから複雑に成らざるを得ない。
これは言語の難しさとは別の話だ。
複雑なのを良しとするか、あれも出来ないこれも出来ないとなっても我慢するかのどちらかだ。
結局、RPAも他言語と同様に複雑なんだ。 結局、大事なのはフローだからな。
作業フロー描け無きゃ作ろうと思っても無理。
行いたい命令を言語で組むか、泥アプリのFREPみたいなUIで組むかの違いだけ。 >>736
そうなんですね。
他を探してみます。
ありがとうございました。 オンプレミス環境で殆どの業務をこなしてた時代と違って、今はSaaSやPaaS(CaaS)やIaaS上のアプリケーションを使って業務をこなす時代なのにね
どんどんハードの制御が仮想化しているというのに、RPA流行は時代に逆行してる印象あるわ >>743
WWFが流行らなかったのは単純にプログラマがあえて使うメリットが皆無だったからだな
とはいえRPAみたいなライトな処理を事務のオバチャンが組むっていうユースケースではベストマッチだと思う
>>745
複雑の中にも程度がある
小学生のプログラミング授業になぜビジュアルプログラミングが用いられるのか
初めはみんな初心者なんだし視覚的に分かりやすいとこから入ってアルゴリズムの基礎を学んでいくってのもいいんじゃないか >>723
RPAはコーディング不要がウリで、ユーザーが設定(録画?)した操作を1つ目から順に逐次実行(再生?)するのが基本的な思想だと思う
コードを記述しないので文法もないし(設定の羅列は文法じゃなくてシーケンスだよね?)、ゆえに構文解析もないので構文木は作ってないんじゃないかな
単純に設定の1つ1つをオブジェクトに持たせてCommandパターンか何かで逐次処理してるっぽい気がする
何にせよ拡張性の余地がなさすぎてなーRPGツクールでスカイリムが作れるかー!っての
いや万一作れたとしてもツクールで挑戦しますか普通?
結局最後はSIerに泣きついてお金かかるやつじゃん プログラマ側の人って論理的に考えるからか評価が辛いんやね。
複雑さや属人化にもレベルがある。
まず「RPAでスパゲティにならない平易な処理」であればRPAが向いてると言える。
そして、仮に「RPAでスパゲティになってしまうような複雑な処理」であったとしても、「担当者の頭にしかない属人化」よりは「担当者作のRPAでの属人化」の方がマシだと思う。推測しやすいから。
もちろん解決策としては30点かもしれんけど、「業務を整理して…」みたいな100点満点の理想的本質的な解決策は今までも取れてなかったわけで、今後も取れる見込みは低いでしょう。 あらゆるRPAは、ただのスクリプトをGUI形式に変換しただけ
画面構成が変わる、WEBのデザインが変わる、処理のフローが変わる、例外エラー
には全く対処できない
作業の意味を理解していないから、ちょっとでもエラーが出ると終わり あくまでも友達の話なんだけど、こんな事が
・海上輸送されてるコンテナ番号から現在の動向を知りたい
・フォワーダーを何社か使ってるのだが、そっちへの依存は避けたい
・UiPathで頑張って船会社のWebから引っ張ってくる仕組みを作った、月二回手動→毎日自動、くらいに更新が速くなった
・だがちょっとまって欲しい、コンテナ情報は一本$1程度で海外の会社から買えたのだった、ロボットより安いし安定
ロボットが広まったら広まったで、「ロボットの削減」がコンサル商売のネタになりそうな気がして仕方ない RPA云々ってより会社の体質に依るところもある
入社10年で事務作業の流れ作業だけメインでやってる人より、入社2年でVBAもプログラムもできる人の方が給料も安いし役職も低い
2年目でできる人は出来ない10年目に合わせて動かなきゃならんから効率なんて上がるはずもない
解雇規制が共産主義的な生産性の低下を引き起こしている >>754
uiparhをそれ専用機にしてるんだったら今すぐrpaやめたほうがいいな(笑) よく考えたらオブジェクト指向をサポートしてない時点で論外だったわ
RPAとコードは本質的に同じものでただ可視化しただけだって意見は間違いだった >>753
あらゆるRPAって…。
UiPathとかBlue PrismみたいなRPA触ったことないだろ。
適当な事を言って断言するな。 >>754
ごく普通にクローリングすれば簡単に無料で実装できたのに…
高い買い物をしたね RPAは〇〇だから使えない〜って意見の人達は国産RPAでも掴まされたのかな
UiPath触ったことあればここで”できない”って言われてる事は大抵実現可能なことが分かるはず
個人利用なら無料なんだし一度触ってみてればいいのに 出来るんだけど、UiPathの画面が嫌いなんや!
中身は.Netなんだから直接触らせてくれ ○RPAは〇〇だから使えない
◎RPAは〇〇だから使わせてあげられない
未来に禍根を残したくない
作って3ヶ月で自動的に消えてくれるなら考慮の余地はある >>761
コード呼び出し機能を使わずにグラフィカル開発環境だけでオブジェクト指向と関数型できるの? マカー社長「なんでMacにはRPAないか知ってるか?」
俺「そもそもMacは業務用に使われてないし」
マカー社長「ちがう!Macには標準でキーフレームがあるからRPA業界が参入できないんだよウハハ」
俺「へえーでもたいしたことできなくない?」
マカー社長「ほら!クリックも記録できる!すげえええ!ガハハ!」
俺「すごいっすね。RPA不用っすね」
マカー社長「そういうわけでキーフレームでやってくれ」
俺「何を?」
マカー社長「業務改善」
イマココ >>768
なるほど悪くないね
PageObjectではない純粋な業務クラス、関数型のサポートはないのかな? ・リファクタリングツール
・バージョン管理と差分表示(当然グラフィカルに)
・オートフォーマッター
・静的解析ツール
・インテリセンス
・大量のウェブ情報
こういうのも有るのかな?
殆どできると言い切るぐらいだからきっとあるんだろうな >>771
・バージョン管理と差分表示(当然グラフィカルに)
・静的解析ツール
はある。
・大量のウェブ情報
大量ではないが、海外ではコミュニティは形成されている。
・リファクタリングツール
・オートフォーマッター
は知らん。 月末に請求書を自動作成させたり、中旬に在庫のデータを読み込んで資料作ったりして時短になるね、メンテも簡単自分で出来るもん。
こういうものなのにおばちゃんとお前らの温度差何なのこれ。 >>765
未来に禍根を残したくない
製品の正式な機能でないとこっちに文句が来る
ものによっては資産計上されてしまうものを、おれが消すわけには行かない >>716
SQLに似た機能を実現する命令あるだろ >>773
他は知らないが、おれに関しては
使える人が自力で使う分にはどうぞどうぞ。経営に買ってもらって存分に使い倒せばいい
おれも便利に使っている。ガントチャート更新、交通費清算などとっても便利 >>771
なんか上から目線感が凄いな。
プログラマーってのはそんなに偉いのか。
気になるならUiPathくらい弄ってみればいいのに。
興味ない?なら、なんでこの板を覗いてるんだか。 .NETならなんでも同じだが多分C#じゃない?
でもフローで書くエクスプレッションはVB.NET形式でしか受け付けてくれない。 VBとか何がいいのかさっぱりわからん
断然C#だろ? へえ、UiPath用のタイプライブラリを叩く感じなのかな
エクセル連携ニーズの多さやVBAに慣れてる事務員の多さとかを前提にした戦略的判断かね? >>777
いいね!あるべき姿だな。
基本的な使い方は教える、相談も受ける。
ネットにまとめサイトがあれば良いがまだググればかとは言えないのが面倒だが、エクセルと同じレベルで現場で使って欲しいわ。
ただ、プログラマーの素養がある人が使うことを前提とした玄人用RPAと事務員向けのRPAがあって前者は意味がわからないな。 玄人と素人はどっちか2つに一つじゃなくて段階的なものなんやで >>782
UiPathの回答では、フロー画面に使ってるMicrosoft Workflow Foundationモジュールの制限だとしているね。(その後突っ込まれてるけど…)
https://forum.uipath.com/t/coding-in-c-instead-of-vb-net/968
> Coding within the workflow (writing expressions in properties) can be done only in VB.NET 28. This is a Workflow Foundation limitation. やっぱみんなコード書かせろって思いながら使ってんのね >>786
使ったことないけどコード書きたいならCode Activity使えば普通にc#でかけるらしい。
そうではなくて俺がc#形式にしてほしいのはフローの穴埋め部に書くとかのエクスプレッション部分だよ。 >>787
InvokeCodeやCustomActivityを書くなら通しで普通のプログラムでいいじゃん
他人にアクティビティ売るわけでもないしさ
そうじゃなくてじゃなくてRPAに普通のクラスを生成して欲しいんだ
例えばホゲというショップサイトがあってこのサイトでは
ログインページにはユーザーidとパスワードとログインボタンが表示される
ログインボタン押すとメインメニューページに遷移する
という仕様だとする
↓そしたらこういうインターフェースを実装したページオブジェクトクラスを素早くいい感じに忖度して生成して欲しいんだわ
interface IHogeLoginPage {
public string UserId { get; set; }
public string Password { get; set; }
public IHogeMainMenuPage Login();
}
そいでその生成されたアセンブリを普通にコーディングで製造してるアプリロジック側に注入したいわけだ
今はこういうページオブジェクトを手作業で書いてるからちょっとめんどくさい
上で例示した架空のシンプルなログインページだと手作業で実装とxUnitを書くのにおそらく5分くらいかかる
RPAでこれが1分になるなら買う価値があると思う >>788
>>787の「そうではなくて」って読んでくれた?
コード書きたいわけでは無いの。
フローのちょっとした穴埋め部分にvbじゃなくc#の形式で書かせてほしいだけ。 >>773
ねー なんで複雑なシステムを組んでわからなくなるみたいな想定するんだろうか
もちろんそう言うデメリットも生じるだろうけど、基本的な想定としては、1時間くらいかかる単調な繰り返し作業を10分にできます、しかも事務のおばちゃんでも誰でもできます、みたいなもんだと思うんだよな と思ってたらいつの間にか大きな複雑な処理に化けてる
システムってそういうもの VBとか書いてある時点で地雷だって気付くよねふつうは VB嫌いではあかんで
VB脳とHaskell脳をすぐに切り替えられるのがプロやっちゅうことやな(ドヤ顔) 気付いたら大きくて複雑な処理に化けるって発想がそもそもおかしい
"定型"業務の自動化なんだから「月末に請求書を自動作成」っていうシナリオを作ったとして
そのシナリオに関しては業務内容が根本的に増えない限りそれ以上変化することないよ いつの間にか大きな複雑な処理になってるって、RPAの問題じゃなくてワロタ
プロジェクトか管理者の問題じゃん 野良ロボット、野良サーバーが知らない間に増えるのはガバナンスの効いていない駄目な組織やで 駄目な組織は何をやっても駄目、電話と手書きFAXを駆使し書類束を仕事の証として頑張れ 日本人は創意工夫(笑)で仕事のルールを増築していくのが既定路線やから…(震え声 >>794
擁護するつもりはないが、じゃあ「請求書のデータを引っ張ってくるところも」「メールで送付するところも」「基幹システムと連携するところも」ってなるケースもあるとは思う
でも、そうなるケースもあれば、そうならないケースもあるわけで、その懸念ばっかり強調してメリットを享受できないのもまたもったいないわけで なんか俺だけ論点がずれているのかな。
RPAだって、プログラマーのような技術カのある人が苦労して組めば良いと思うよ。
簡単に組めると言うけど簡単に組んだら碌でもないものが出来るというのが問題だと思うんだ。 誰が誰だか分からんのだが
今期も残すところあと2日だぞ
そんな装備(RPA)で大丈夫か? >>801
それくらいだったらマクロ出来ない事務員が作ってるからRPAやっぱスゲーと思う。 じゃあなんでフリーソフトじゃだめなのか
どうせ複雑なことしたいんでしょ俺は騙されないぞ 会社がRPA買ってくれるから、フリーソフトである必要ないんやで どうせならマシンスペックと有料サービスに投資したいかな
ちゃんとしたものを選べばCLIもAPIも完備してるからロボットの出番って… >>785
Uiのエンジニアがボコボコに叩かれてて笑った
他に優先順位があるから今は対応できない、Code Activity使えばC#でも書けるって言っても納得してもらえてなくて可哀想 画面認識系はSikuliX
Excel読み書きはClosedXML
WebはAPIとかAngleSharpとか
DBは普通にSQL
でええんやないかと思ってきて 最近2Lのペットボトルが、真ん中に窪みがついて持ちやすくなったけど、
そういう気配りが、これからのソフト開発にも必要だと思うの。
何が言いたいのかというと、
コントロールしにくい変な仕様のインターフェイス作るなってことね。
Windowハンドル取れないとか、ReadyStateが利かないHPとか、もってのほか。 WinAppDriver+Appiumの質問ってどこですればいい? それが何なのかわかりませんけどね、
例えば、冷蔵庫のドアをRPAで開けられるなら、
その質問をここでしてもいいと思うんですよ。 >>812
最初から自動化サポートを考えるならAPIでいいじゃん
RPAは遠回りだ >>756
最大の効率化は無能上司を首にすることですよ >>817
企業の目的は効率化ではなくて利潤追求
効率化は手段の一つ
効率化の観点で無能とあなたが評価する上司が
売上観点では有能かもしれない >>818 >>817 >>756
そんな上司には管理やらせずに営業だけやらしゃいい。 >>810
そりゃ最初に
This is a Workflow Foundation limitation.
なんて言いがかりつけたら叩かれてもしょうがないわな VisualStudioにWorkflow追加インストールして、新規プロジェクト作ってみたら
なるほどUiPathはまんまこの画面やないか、と理解したわ
逆にVisualStudioにUiPathのアクティビティは読み込めないんですかねw >>812
サントリーの南アルプスの天然水500mlペットボトルにも同じこと言えんの?
フタ開けようにも本体がネジれて開けられないんだぜ…… VBSでUIAutomationが使えれば、
こんなもん要らないんだけどな。 >>824
情シス部がWEBサイトアクセス部分を抽象度の高いCOMクラスとしてカプセル化して配布すればいいよ
事務のおばちゃんだってエクセルマクロは使えるんだろ? Webのアクセスはどう考えてもスクレイピングのライブラリ適当に使った方が楽よね、読むのも書くのも
RPAは「紙やPDFの申し込み書類読んでExcel化まで」とか用途絞りまくって作るのがいいと思うのです
その前後は普通にプログラム書けばいいので 普通にPDF読み取りライブラリ使えばいいじゃんそれか画像解析ライブラリ
RPAという括りにこだわる意味はないな
紙の読み取りはどうだろうな
紙セットしてスキャン開始するとこまでは手作業だろ
スキャンしたデータを集めて画像解析するとこは普通にプログラミングかな 俺はプログラマーじゃないけど、上にみんなが書いてあるようにプログラム組めと言われてもできない。
でもuipath用意されたら色々自動化できた
所詮そんなもん メンテナンスできないものが出来上がるのはプログラムでも一緒だし
RPAをくさす理由にはならないかな >>828
どんなこと自動化したの?差し支えなければ
プログラミングでいいじゃん、っていう意見はRPAの強みを見てないよな スキルがない人でも扱えるってのがウケてるんだと思うんだけど プログラミングよりもハードルが低い分、メンテナンス不能になったときの影響が大きくなる傾向はありそうかなと思う
もちろんRPAが社会的に普及すればそのぶん管理ノウハウも洗練される可能性高そうだけど
野良マクロの例があるので普及度と管理ノウハウが正相関するかはちょっと分からないね スキルがなくてもRPAで自動化できるような規模の小さいシンプルなタスクなんてのはプログラミングでも同じく簡単にできるんだな
逆にスキルがないと自動化できないような難しいタスクはエコシステムが未熟なRPAではしんどい >>826
スクレイピングは跳ねられるサイトも多い。
従ってRPAと併用すると良さげ >>833
一般的なスクレイピングで弾かれるなら原理的にRPAでも弾かれるだろう
そういうサイトでは正式な手続きを踏んでAPIを使うべきだ
APIでも制限かけてる場合があるのでその場合は負荷分散の処理が必要
RPAでもAPIラッパー的な部品なら同じ
ユーザーがこういった判断ができないところもRPAの限界だな
図書館クローリング事件みたいにいつか問題になりそう >>830
まだ全然だけど、一般的なのだよ
webシステムからデータダウンロードして、加工して配信
原価システムにテーマ登録や日報の転記とか、ダウンロードして加工して保管とか
本当に普段やってる業務洗い出して改めて改善しながら自動化してる
中には改善だけで十分てのも出てくる NEC、東大と共同で高速カメラ物体認識技術を開発--製造ラインの検品作業を効率化
https://japan.zdnet.com/article/35134977/ >>832
だから簡単な事務でもできるものが対象だってメーカーもいってるやん。 >>835
どもども だいぶイメージできた
基幹システムへの転記はありがちだなー 最初からシステムに入力すれば良いじゃんっていう指摘もあるが、端末環境だったり入力者と転記者が違ったりでなかなかそうもいかんのよなー そこで、システムの改修は金かかるから、小回りの効くRPAでってのは自然ではある
ブラウザや他システムとの連携はExcelマクロより強みがあるかも もちろん、Excelマクロでもできるだろうけど敷居が高い
やっぱ「できるできない」という視点より「敷居が高い低い、''簡単に''できるできない」という視点で考えた方が良さげだな マクロのほうが簡単だよ
GUI環境は正直編集しにくいだけだ 本当に簡単なら世界中のプログラマが既に採用してるはず
プログラマは自分が作りたいモノに付随するやりたくないけどやらなきゃならない作業を嫌う
だからプログラミングより簡単にその作業を取り払ってくれるなら間違いなく飛びつく
しかし現実は……まあそういうことです だからプログラマの作業を解決するツールじゃなくて事務員の作業を解決するツールなんだってば >>840
差し支えなければ、評価されたRPAの銘柄教えてください。 >>841
ほんこれ これを認めない人ってなんなんだろうな
プログラマー「プログラミング簡単」←これは別に構わんが
事務員「プログラミング無理」←これを頑なに認めないのな >>841
同じことだよ
プログラマが日常のPC作業を自動化しないとでも? Excelのマクロなら分かるがプログラムは分からない
と言うのは、(){}[] が問題なのではないか(名推理)
つまり、超シンプルに書いたVB.NETなら事務員でもなんとかなる!はず! >>840
使ったことないなら否定も肯定も出来ないという事実
ネットで得た知識や自分の勝手な推測だけで喋る、薄っぺらい人間になるなよ >>839
それは新しいものに対応できない老害なのでは。。
よくシステム導入しても頑なにエクセル管理に拘るおばちゃんのようだ >>843
他人に対する想像力が欠如していて、自分の考え方が絶対だと思っているやつなんだろうね。自分にとってはこうだから、他の人もそうあるべきと考えてそう。
それに加えて、話の流れについても、自分の思い込んでいる想定や前提が常に絶対で、他の人がそれと異なる前提での話をしている中でも一人ずれた前提で話をするから頓珍漢なことを言う。
そして本人にはその自覚がないから認識の修正ができず、話が通じないままになる。
困ったものです。 >>848
実を言うとGUIプログラミング環境はかなり古い
昔からあってプログラマ達に非効率的で苦痛に満ちてるものとして見捨てられた
これを新しいものと呼ぶには抵抗があるな >>849
同意
頑ななRPA信者には困ったものだね
こんなもの崇拝してるのは世界的にみても本当にごく僅かなマイノリティなのにさ ごく僅かのマイノリティなら放っておけばいいじゃん
もし放っておけない位に流行するなら君らの認識が誤ってるか、君らの持っている(かは知らんけど)より良いソリューションの喧伝不足なのでは
こんなネットの片隅で架空のRPA信者にgdgd言ってないでもっと違う努力しなよ >>851
同意されても困るな。俺が非難しているのはお前のようなタイプの方だ。
このスレを見ていても、RPAを崇拝している信者なんていない。「ある種の人にあるケースでは役に立つ」という意見があるだけなのに、お前はそれをすら、RPA信者と考えているのか?
お前がRPAを無価値なものとして毛嫌いするのは勝手だし好きにすればいい。 winactor以前触って驚愕したのだが、
な ん で 小 数 点 扱 え な い の か 実際にRPAがウケている風潮があって、その背景には内勤業務の現場レベルでの自動化ニーズやプログラミング人材の供給不足やら登用ノウハウの欠如やらがあるわけだよね
その風潮そのものがマやシステム管理者等のITプロパーから見ると野良マクロ蔓延の焼き直しとか流行技術のつまみ食いにしか見えないだけで まだ利用者は僅かだろうけどそれでも>>812のような意見が出てきてる
万が一普及していくとAPIのサポートよりもRPAのサポートを要求する奇妙な顧客が増えるかもしれないね そのうち、Webサイトのデザイン変えるとRPAで使ってるユーザーから猛反発が来るようになるのではないか? CUIとGUIみたいなもんだろ。
目的や用途によって使いたい方を使えばいい。 RPAてか業務で使われる前提のページ変更したらそりゃ文句もあるだろうけど
そんなのは変更しないかするなら影響先に事前に告知するだろうよ
無断でやってる奴らの面倒まで見る必要はないから心配しなくていいんじゃね 業務システムなら更新通知はするがRPA互換性は保証しないだろうな
真面目に保証しようとしたらわりとデカいテスト工数がかかる RPA絶対主義者ってのはいなくて、場面によっては使えそうだね、いいんじゃない?って感じ
逆にプログラム絶対主義者がケツ穴小さい
「世界中のプログラマーが使ってないから駄目」とか
当たり前だろ、同じPC作業でも目的が違うんだから 二三日止まっても問題が無くて、現場で解決できるならいいんだけど
上長経由で「何とかしろ」となるに決まっている
パソコンがぶっこわれたときも諦めてくれそうにないし >>862
そんな汎用性ないマイナーツール押し付けられてもなぁ >>864
今後RPA関連の仕事が来たら断れば万事解決
おめでとう
日本では職業選択の自由が憲法で保障されてるからな そういえばテスト工数に言及してるレスっていままでなかったな
ユーザー環境に死ぬほど依存してる素人が書いた副作用だらけのルーチン
当然ながら明確な仕様すら定められてない
そんな厄介極まりない無数のロボットのテストなんて実質不可能だよな
だから情シスとしてはサポート出来ますとは絶対に言えない
責任感があるなら出来ないことを出来ると言っちゃいけない
コスト削減って宣伝文句につられて導入しちゃったのに
そのせいでテストコスト爆上げなんてことになったら推進担当の顔に泥を塗ることになってしまう
だから情シス部としては人員を出してコストを増やすのは気が引けるね
なのでそっちでサビ残でもなんでもして低コストでやっちゃってくださいって感じ >>865
そりゃまず最初は断るけどさ
人間関係ってそんな簡単じゃないから断りきれないトキもあるんだよね
そうなったら犬に噛まれたと思ってやり過ごすしかないんだろうな 犬に噛まれても金ば貰えないが、嫌な仕事でも仕事であるなら金が貰えるからマシじゃん なんつーか見てると、「こうだからダメ」「それだからダメ」ばかりな意見が多いな。
RPA自体じゃなくて、結局は作る人の問題だろ?
マクロだってプログラムだって、結局は素人が作ったら糞だし。
RPAだってちゃんと仕様を決めて技術者が作れば使えるもんになるだろうし。
RPAの導入が良くないのではなく、導入時、運営時に気をつける事の方が大切じゃないか。 RPAという付け焼き刃を使ってでも何とかするしかない立場の人間に対して
「それって結局付け焼き刃だよねw後悔しても知らないよw」って指摘して回る奴は、
単に相手を見下したいだけよ、いくら突いたって実のある話なんて出てきやしない >>869
WinActorのWebでの説明だと素人さんにこそ!みたいな印象
https://winactor.com/column/about_rpa
|ノンプログラミングのRPAは、非IT部門でも使いこなせる|
一方、RPAであれば、現場のホワイトカラーが自らITによる自動化を行うことができるため、IT部門が制約とはならなくなったのです。
またIT部門にとっても、自動化のために現場から業務を巻き取る負荷が無くなるという点で、歓迎すべき技術となっています。 定期的に沸く「プログラマーが使ってないからGUIプログラミングは糞」マンはなんなんだろう
ラダーとSFC言語の存在知らんのか???
今も昔も "自動化" つったらグラフィカルな言語がメジャーなんだよ
視野を広く持て >>872
買い手が納得してくれるからの営業文句だろうに (騙す騙されるとは言わない) >>870
見下されているのはシステム部門のほうなんじゃあ?
>>871のページを読んでいると、システム部門は役立たずという気になってくる そりゃ役立たずでしょ、利益もあげないし改善もしてこなかった 有能な情シスなら社内定型業務くらい既に何らかの手を打ってるだろうしな…
察し システム部が十分に仕事をしている組織であれば、そもそもRPAなんて議題にすら挙がらなかったのでは >>877
>>877
世の中のFAシステムがCで動いてるとでも?冗談きついよ ネコも杓子もAPI、なっちゃらAsCode、小学生でもコード書くのが当たり前に普及した時代にまーだGUIプログラミングとか言ってんのかw >>881
https://trends.google.co.jp/trends/explore?geo=JP&q=C%E8%A8%80%E8%AA%9E,SFC%E8%A8%80%E8%AA%9E,%E3%83%A9%E3%83%80%E3%83%BC%E8%A8%80%E8%AA%9E,%E3%82%B0%E3%83%A9%E3%83%95%E3%82%A3%E3%82%AB%E3%83%AB%E8%A8%80%E8%AA%9E
メジャーwwwww 実際のところ、現場でRPAを導入したくて、現場で完結する体制を取れるなら、反対どころか大賛成
>>863の
二三日止まっても問題が無くて、現場で解決できる
をもう少し書き出すと
WinActorやUiPathの窓口と直接話し合って、導入、契約、質問、バグやクレームも各現場で
RPAツールのセットアップや、メデイア、マニュアル、保証書、契約書の管理も各現場で
内的(部署の分割、統廃合)、外的(取引先変更、法律改正など)の変化の対応も各現場で、
それぞれ完結させるようにおながいします
お勧めは、各現場にシステム担当を正副二人ぐらい置いて把握させること。兼任できるかは状況次第
それなら新人ユーザーの教育、新人担当者の教育も何とかなるでしょう
他にも、開発、テスト、バージョン管理、処理日付とデータ日付指定の処理変更、共通ルーチンの作成とリリースの管理などもあるけど、
スクラップ&レコーディングなら瑣末な問題
むしろシステム時刻が狂っていないかの指差し確認の徹底が大事 >>884
RPA導入に非協力的だと君の社内での存在理由なくなるんじゃない? >>884
自分達が特別だと思ってる情シスほどタチ悪いもんはないな システムリソースの機密性や可用性の確保、事業体レベルで決めたセキュリティポリシの履行確保、エンティティの責任追跡性の担保とか考えるといろいろと問題があるから、現場に全部責任持たせるのは現実的に難しくないかね ご心配ありがとうございます
RPAの後始末が嫌なのはシステム部でのコンセンサスは取れています
たとえ立場が悪くなっても、仕事はあふれているし、
むしろ立場が悪くなったほうが出世しなくて好都合だし、立場を利用して早く帰宅できるかも >>883
はずかしいからやめれ…
PLCでラダー使われてるのは常識だろ >>887
システム部はそういうルール、セキュリティ、優先順位、予算を盾にして願望をかなえてくれないから
現場からみると、仕事していない、お荷物らしいですよ
そこをさくっと願望通りのものが造れるのがRPAです
現場の人が飛びつく気持ちは良く分かります
分かりますから、システム部を飛び越えて導入するのは大賛成します システム部門の邪魔にならなきゃ別に構わないけど九分九厘邪魔になるの見え見えなんだよなぁ
他所の子の尻拭いで仕事増やされたら誰だって嫌だろう? 今までネ申エクセルを管理してきたように今回も現場側でうまくやるだろう
RPAってそういう泥臭い仕事に向いてる。もちろんいい意味でな システム部門いらないって人にひとつ聞きたいんだけど、クローリング業務を任されたRPAが未知のWebサイトにアクセスして社内の機密情報をPOSTするような事態とか、どうやって防ぐんですかね
パラメタ設定をミスすれば普通にあり得る事故なんだけど >>890
システム部門飛び越えてやってくれるのは大いに賛成
何かあってもCISOや信用管理部門が死ぬだけだから純粋なシステム側はノーダメ
ネットワークが重いだの何だの言われたらいっそのことインフラもお前らの責任で調達しろと言いたい 機密情報持たない、アクセスできないPCで実行するだけじゃね お前らそれが仕事なんだろ?
今までのやり方なら対応するけど
新たなシステム開発はソフトウェア会計にそって処理してね。システム売っても売上計上、原価積み上げてpl報告してね。もちろん会計基準、税制改正に対応お願いします。
後お金の回収支払いは各自お願いします。
交通費の立替?各々各自銀行から引落といて。
1つ1つチェックしておくと税務調査で指摘されないからチェックも大事
そんな事言ったって仕方ないだろう。。 >>896
機密情報を扱わない事務仕事なんて現実にはほとんどないだろう
外部ネットワークから遮断するのが一番だけど、処理の中で外部サイトにPOSTリクエストを送らなきゃならない場合もある
ホワイトリストに記載されたドメインのサイトでしかセッション確立出来ないようにファイアウォールの設定を調整する感じで対応せざるを得ない
そんな設定がシステム部の介入なしに出来るのかね >>894
機密情報気にしてる会社で設定ミスでRPAが外部のサイトに情報上げられるような環境とか今時ありえないだろw 監査も適当だからセキュリティインシデントに気が付かないんじゃないか?
気が付かないならお咎めなしだよかったな >>899
セキュリティを気にしてるのはセキュリティ部門や情シスだぞ
そこらへんが介入してRPA導入してるからまだ何とかなってるだけ
大概の事業部門はセキュリティに関してはとことん無知だぞ
ACLとかセキュリティグループとかの基本概念すら知らない人が殆どだろう システム部いらないとは全然思わないが…
想定から外れた挙動した時点でエラー吐くようにシナリオ組むだけだけだぞ
ページ遷移毎に要素チェック挟むだけ
必要ならホワイトリスト記載のドメインに限定する処理もRPA内で完結するぞ ホワイトリストをRPA内で完結
なんて強固なせきゅりてぃなんだ
さいつよ RPAの導入を防ぎたければ、システム部門が各部署の業務をヒアリングしてコード書いて自動化すればいいんじゃね?
会社としては定型業務に人を割かなくてよくなり、システム部門は自分達で管理できる。
皆んなハッピー! やっぱり末端の社員にセキュリティを預けるのは不安だと強く再認識してしまうね
セキュリティ系資格保有者のみRPAを解放などといったルール作りが必要であろう 今ある業務手動業務を自動化するんでしょ、そんなに怯えるのは何でなの?怖いの? >>901
だから勝手に入れたRPAで認証とかの設定も無しに外部にPOSTできる環境とかお笑いでしかないだろ
って話な >>907
いやいや、システム部門の介入要らないって要はそういうことだろって話じゃない
お笑い状態になるから要介入ってことになるのよ どっかの野党みたい
「RPAがー、RPAがー!」って
定型業務の自動化って目標があっても、反対ばかりで現実的な対案がない プログラマ以外の人間が簡単に使えるって前提条件だから
そもそもが現実的じゃない Excelのマクロ記録でなんとかかんとかマクロ書いてた人がRPAの対象だぞ!
VBAからCOMやDLLを駆使してた人は.Netのライブラリ買ってVB.NETに移行するべき、そうすべき >>911
同感 まぁそりゃシステム部が孤立して経営層から疎まれるわけだよなぁ(まぁ経営層のせいでもあるんだろうけど) 建設的な意見がありゃ議論も進むのになぁ 非IT部門の出身であることが多い経営層は情報セキュリティやシステム運用管理の基本とか自社の既存リソースの管理実態とかを把握してないことが殆どだからな
ITとの間で建設的な話を進めると言ってもそもそもリスクに対する認識が違うので難しい面はあるよ >>911
その、RPAがーがーって
「RPAがーがー簡単なんです、RPAがーがー誰でも使えるのです、RPAがーがー希望をかなえてくれるのです」
だよね?
RPAに問題点が有るとする人も、簡単に誰でも希望通りの点については反対しないと思うけど? >>914
いままでにも有った、ユーザー作成のEXCELマクロにもシステム部は関与していないけど、別に孤立はしていないというのに
RPAだと孤立、あげくに経営と対立するのは何故だろう
RPAの導入が経営上部からの号令なら
RPAの導入とその後についてスケジュールと、メリット、デメリット、リスクと、費用、体制を試算した資料をお持ちして説明するのが普通
ことがERPでも、AIでも、as a Serviceでも一緒 ExcelマクロはOfficeの標準パッケージに組み込まれてるから業務自動化ツール単体としての導入コストは事実上なかった
RPAの場合は敢えて行うIT投資になるので個別にROIがチェックされるし、セキュリティリスクの他にベンダロックインのリスクも伴うのでシステム部門としては賛成しづらい >>915
まぁその気持ちもわかるし、個人的には今の時代の管理職にはITリテラシーがかなり必要だと思うけどね
とはいえ、現実的には上の意向を汲むしかないからなあ
>>917
基本的にはRPAに限らないんじゃね
ITを魔法のツールばりに認識して攻めを重視したい経営層とITのリスクや現実が見えていて守りを重視したいシステム部との対立という一般的な構図なのでは
RPAの特殊性としてはハードルが低い点にあるので >>831 さんが言う通り問題の発生頻度が上がることだろうね 要は、もっとめんどくさいことになりそう、なんじゃないか システム化できない細々した定型業務の解決手段としてRPAが推されてるわけだけど
ここでRPA否定派の人はRPA以外で現場サイドの定型業務を解決する対案持ち合わせているのかね?
現場側がプログラミングすればいいみたいな非現実的なことは抜きとすると俺ら情シスが社内の定型業務課題を取り纏めてスクリプト組むくらいしか思いつかんのだが
それだとヒアリングとコーディングの手間半端ないし結局はある程度現場サイドに任せられるRPAが楽じゃね?ってなってる
情シス部ではセキュリティ考慮したシナリオ作成ルールの共有と、ルールが守られてるかの管理に徹するのが現実的な役割分担じゃないか
RPAには色々懸念があるから反対だけど対案もないので皆今まで通り手作業で頑張って!なんて無責任なこと言えないしなあ おお。初めて情シスの人から建設的な意見が出た。
感動。 >>920
現場側がプログラミングすればいいよ
子供でもできることで、まったく非現実的じゃない
これから小学生でもプログラミングが必修になるということは、政府は小学生でもプログラミングできると判断してるわけだ
そんな中でいい年こいた大人がプログラミングできませんじゃ恥をかくぞ
なんども言われてるが野良の管理とセキュリティリスクのほうが問題
ヒアリングとコーディングで解決するならそれでいいよ
なにもUI操作からシナリオ作成まで全て情シスがやる必要はない
情シスは有用性の高い外部サイトのページオブジェクトなど、再利用しやすいクラスライブラリとして提供する(+ここでセキュリティと監査のアスペクトを仕込む)
ユーザーはクラスライブラリを使ってジョブを自動化する
このように情シスの作業量を減らしつつ、ユーザーのプログラミングを支援してやればいい
ちなみにグラフィカル言語はエコシステムが整ってないからコードと違ってレビューが格段に難しい
なのでロボットを全てチェックして、ルールを徹底させる工数は極めて大きいので非現実的だぞ
というか情シスとユーザーの人数比的にもそりゃ酷だろ
対案は普通にプログラミングな
まあ正直、素人の付け焼き刃のロボットで技術的負債を背負うマイナスになるよか、今まで通り手作業でプラマイゼロでもいいと思うがな >>920
目指すべきシステムのゴールとしては、
PCで行うタスクであれば、
システム内で全て完結させるよう業務プロセスの変更も含めて設計する。
RPAの出番は、それに至る経過の中での一時利用に限られる。
理想論だけど 結局、急造の素人プログラムでも色々文句を言われて、定型業務はそのまま残りそうな予感。
会社としては何も前進してない、みたいな。
もう情シスが会社の支配者だな。 >>922
子供でもできるんじゃなく、頭の柔らかい子供のうちからプログラミング的思考に慣れさせるための必修化だよ
もっと言えば子供のプログラミング授業は「Scratch」っていう教育用のGUIプログラミング言語を使う。実際にCやらJavaをがりがり書けるようになることが目的じゃないよ
ビジュアルでわかりやすい所からプログラミングの基礎を学ばせて、そこから他の言語に移行していくのが最良なカリキュラムだっていうのが政府の判断なんだろう
社員全員がスクリプト組めるようになればそれはそれは素晴らしいことだけど
頭の固まりきった大人が過程スッ飛ばしてすぐにコーディングできるのかって言われたらそりゃ無理な話で学習コスト考えるとやっぱり現実的じゃないねってなる。
サルでも3日で理解できるコーディング学習環境でもあるならそりゃそっちのほうがいいと思うが・・・
野良の管理とセキュリティリスクはVBAでも問題になってたようにRPAに限らず"素人プログラミング"全般の問題だし
寧ろちょっとでも規定外の動きになればエラー停止するRPAのが安全性は高いんじゃないか
サーバー機能付きのRPAなら野良の管理もできるし
>>情シスは有用性の高い外部サイトのページオブジェクトなど、再利用しやすいクラスライブラリとして提供する(+ここでセキュリティと監査のアスペクトを仕込む)
>>ユーザーはクラスライブラリを使ってジョブを自動化する
>>このように情シスの作業量を減らしつつ、ユーザーのプログラミングを支援してやればいい
こういうことを一番やりやすくするように最適化された形がRPAなのかなと思う。UiPathならXAML言語だから既存エコシステムの恩恵にもあやかれるし
現場サイドでプログラミングをするっていう前提条件ではやっぱり便利だと思うよ。日々変わる業務に流動的に対応できるし
最もベストなのはRPAが必要ないくらい最適化された環境を作ることだけどね >>923
これは本当にそう思う
RPAも所詮は部分最適化でしかないから原因を退治できるならそれが一番いい
だが今RPAが必要になってるようような糞システムも導入当初はちゃんと最適化されたものだったはずなんだ
結局業務内容自体が日々変化していっちゃうからそれに対応できないシステムとの差を埋めるために無駄な定型作業が生まれるんだよなあ
システムに合わせて不変の業務プロセスを組むか、変化を吸収できるシステムを組むか、RPAでひたすらその場しのぐか・・・ >>925
大人でも全然問題なくできるよ
まったくプログラミング経験ない新人が毎年入ってくるけど、1週間前後の教育で例外なく簡単なJavaプログラムぐらいは書けるようになってる
規定外の動きで止まるかどうかは処理の内容次第
例えば想定とまったく違う画面にアクセスして、期待する入力項目自体が存在しなかったらなにもしなくてもエラーで止まるだろう
でも例えば正しい画面に住所1と住所2があってこれを逆に入力してしまう処理を組んじゃったら、想定外だろうけど止まらずに動いちゃうよね
これはロボットでも通常のプログラムでも同じこと
RPAに特別なアドバンテージがあるわけじゃない
RPAが採用しているフレームワークに依存してるから部品の再利用性が低くなる
例えば特定のクラスの継承が必要でその制約にしたがう必要があったりね
これは分業には向かない設計だな
XAMLのエコシステムは全くなくはないがプログラミング言語のそれと比べたら有って無いようなもの 数学習ってるから中学生でも微積がわかるはず、くらいの暴論言ってる奴いるな
そりゃそういう会社に入るやる気のある大人なら学習できるさ それでも''新人''で1週間で''簡単な''プログラムなんだろ? じゃあやる気のないおばさんがまともなプログラム書けるようになるのにどれくらいかかるんだろうね?
まさに >>924 のように情シス帝国やな >>928
数年の積み重ねが必要な微積分と比べたらだめだろwww
事務のおばちゃんでも楽勝だよ
業務覚えるほうがよっぽど難しいわ 微分が傾き、積分が面積体積をイメージ出来れば楽勝やで メールの文面とか印鑑の押し方の掟・仕来りを学ぶより、プログラムの方が簡単だと思う
掟破りは社畜生命に関わるがプログラムのバグなら障害・対応書いて終わりだし >>931
対応しましたハイ終わりじゃないだろう
然るべき人がそれなりに責任問題に対応するんだぞ >>927
入社後1週間のJava研修ってことはシステム系かな?
本人にプログラミングを学ぶ意思があって且つビッチリ研修するならそりゃ1週間で基本構文くらいはできると思う
まぁその新人に「このGUIツールのこの要素をクリックする処理書いといて」って言ってもできないとは思うが・・・
もし仮にプログラミングに全く興味もない「OSって何?」みたいな3~50代のおっちゃんおばちゃん相手に1週間で自分の業務自動化できるようになるレベルの
研修ができるなら是非そのノウハウを社外に発信してほしい。それだけで一山当てれると思う 日本の業務システムは約半世紀前に完成しており、形だけオープン化してそのメリットすら享受してないレガシー企業が多いんや ASCII.jp:日本のITは20年間進化していない──野口悠紀雄が語る (1/6)
https://ascii.jp/elem/000/000/151/151210/
※2008年の記事 縮減率は平均66.8%:
RPAで年換算438時間の縮減、東京都が実証実験
https://www.atmarkit.co.jp/ait/spv/1904/01/news044.html
東京都は、RPAによる作業自動化の共同実証実験結果を発表した。主税局やオリンピック・パラリンピック準備局などの29業務を対象に実施した結果、25業務で年間換算438時間の縮減効果が得られたという。 年間なのか、438時間って
月間でもよさそうなくらいだが >>933
だから要素をクリックする処理書いて、じゃないんだって
このページオブジェクトクラスのこのメソッド呼んで、だからな
おばちゃんでも楽勝だよ 年間数百時間の削減と
正しいシステム化を阻む負の遺産、技術的負債を抱え込むことになるリスク
どっちが大きいのかねえ そうやって指導できる人材が居て大ナタを振るえる組織なら、そもそもRPAなんて泥縄には縋らんよ
失われた30年と引き換えに延命してきた非効率ゾンビ企業をナメるなよ? 438時間 ÷ 実働200日 = 2.19時間
2.19時間 ÷ 29業務 = 0.0755時間 = 4.53分
438時間 ÷ 29業務 = 15.1時間
15.1時間 × 時給2000円 = 30,200円
30,200円 − RPA年間費用 = 実装費用、メンテ費用、電気代、コンピュータリソース費用は? >>938
1事業所当たりの改善: 88時間
WinActorの年間ライセンス: 90万
運用保守サポートの工数: プライスレス
太陽光発電、売電…う頭が RPAってさ倉庫の運搬車を自動運転させるのに似てない?
この条件にあった貨物をここに書いてる場所に運搬してね、
明日様子見に来るからヨロシクって言って
あとは全自動で運搬作業をロボット運搬車にまかせる
結局、制御系のプログラミングになるよね
その辺をRPAツールがやってくれるならいいけど今のところ全部自前で実装する必要があるから。
曲がり角まがれなかったらバックして曲がり直しとか
20時過ぎたら通路Aは封鎖されるから通路Bを通ってねとか
おばちゃんにもできるだなんてとんでもない、かなりの熟練技術者を雇わないと
本っ当に単純なケースしか処理できない、スケーリングの全く効かないただのオモチャになってしまって、
その程度ならそれこそフリーソフトで十分ってわけで 東京都のレポート自体をちゃんと読んだ方がいいよ
まぁ若干提灯というかやったからにはいいこと書く的なバイアスはあるが ツールのスケーリングが必要になったらおばちゃんが額を寄せ合って物凄い工数をかけて四苦八苦しながら何とかやりすごすってのが日本企業!まの一般的な事務作業管理だぞ >>938
まあ別に記事としては間違いじゃないけど、報告書によると全体に適用したらもっと効果が出るらしいよ
https://i.imgur.com/7EHH10g.jpg
しかも、「RPA 削減効果」とかで調べるともっと効果的な事例は多いんだが 否定ありきで話してるのがモロバレなんだよなあ↓
RPAの活用で、年間約1100万円の削減効果 | RPA | 東洋経済オンライン | 経済ニュースの新基準
https://toyokeizai.net/articles/-/177416
茨城県庁、RPA導入で年間4万6000時間の削減効果を推定 - ZDNet Japan
https://japan.zdnet.com/article/35132390/
【11事例】RPAでどこまで業務効率化できているのか?(2019年版)|アスピック
https://www.aspicjapan.org/asu/article/838 無駄な仕事が減らせるならやっぱりRPAがすごいってことじゃんw RPAがくるまで減らなかった仕事がRPAが来て実際に減ってるんやで? 未達なら評価に関わるという状況の中で出された報告書に
信憑性は一体どこまであるのだろうか
削減効果はこれだけ出ましたっていうけどさ
算定基準は非公開なんでしょ、第三者の審査もまっとうに受けていない
一番ありそうで怖いのが、業者から何らかの形でリベート貰ってる可能性
内部告発がきっかけで独禁法やら不正競争防止法違反に発展しないのか不安になってくる
姉歯建築や耐震偽造問題を思い起こした上で考えて業者まで加担していましたとなると
思ったより闇が深そうで俺の中の危険察知アラートが鳴り始めてる >>953
たまたま導入したのがRPAだっただけでは? >>954
妄想の気と心配症で大変なんですね、カウンセリングをお勧めします >>955
たまたまでも結果が出たならそれでいいだろ。別にRPAでなくてもいいよ。
ただ、お前さんのいうおばちゃんにプログラムさせるという方法はそのたまたまの結果以上の効果がほんとに得られるのか?
実際どの程度効果が出るのか、それを示さない限りはいつまでたっても「ぼくのかんがえたさいきょうのりろん」でしかないぞ。 >>957
大丈夫か?
普通のプログラミングは世界中で成果出てるぞ 普通のプログラミングは普通の非IT系事務員も使ってるのか? >>940
ページって何?オブジェクトって何?クラスって何?メソッドって何?呼ぶって誰を?
おばちゃん相手だと間違いなくこうなるぞ…自分が理解できるからといって相手も当然分かると考えるのは理系の悪い癖だぞ
>>このページオブジェクトクラスのこのメソッド呼んで
この言葉の意味を理解できるようになるまでで余裕で1ヶ月以上かかるぞ >>960
はぁ?
ページオブジェクトはこれ
メソッドはこれ
って教えりゃいいだろ
お前ほんと大丈夫か? 教える、というプロセスが成立するかしないかというところで一つハードルがある
エクセルの記録マクロをやり方教わっても自分で作れない人は厳しい >>961
なら聞くけどキミのカーチャンが太古のGUIツールが絡んだ業務の自動化を"自力で"コーディングできるようになるまでを1週間で教えられるのか????
ページオブジェクトはこれ…でコードと言葉を関連付けるだけじゃ概念までは理解できないよ
キミの論は「英語なんて小学生でも話せるんだからオッチャンオバチャンでも1週間で話せるようになるよ」って言ってるのと同じ >>961
アンタの会社は優秀な人しかいないんだね。
羨ましいよ。
うちの会社は誰もが知っている大手メーカーだけど、うちの会社はそんな簡単に教えて出来そうな感じじゃないや。
教えてる途中でおばちゃん、おじちゃんが挫折する。 小学生でもプログラミングできるおじさんは何と戦ってるんだろうか
質問にもまともに答えず曲解して揚げ足をとるだけだし 天才過ぎるのかもしれんな >>963
おばちゃんをバカにしすぎだろ
できるよ >>966
あまりオバチャンのオバチャン力を見くびらないほうがいい・・・
システム系じゃない会社のオバチャンと話してみればわかる
最悪会話が成立しないまであるよ >>966
是非とも俺んとこの会社に来てIT研修の講師をして欲しい
一般事務職がプログラムが組めるようになったら、どんだけ楽か… 一般事務職に何を求めてるんだ?
野良プログラム作らせたいの? 何が楽になるの?
プログラム知識があればRPAにしろちょっとしたマクロにしろ役立つとは思うけど本当にイチからプログラム組めるレベルなんて必要ないでしょ、事務職には
現行の未熟なRPAツールがスクリプト必要っていってもよく使うテンプレ構文覚えればいいし本当によく使うならいずれツールに取り込まれるか、サポートツールを情シスが作れというお話しだよね
後たまに引っかかるんだけどRPAで作るのはアプリケーションじゃなくて業務プロセスだから、作りっぱなしは通用しない
だから情シスやIT部門、ベンダーにサポートしてもらいながら現場で運用し適宜改善するのが望ましい
コストの計算をソフトウェア開発の様に考えるのも下手の考え休むに似たりで意味がない >>961
ふうん。で、ページオブジェクトってどれ?
そもそもオブジェクトって何?
私おばちゃんです。教えてw IT部門に、
「日通の海外発送の見積、自動で取って来てくれるCOM?っての作って、Excelから使うの」
「yahooファイナンスから通貨取って来るなんか作って」
とか頼むと出来て来るかもしれん、それがオブジェクトとかや
サンプルのマクロに書いてあるのがプロパティやらメソッドやらや >>969
オバチャンでもプログラミングできるおじさん曰く、RPAはダメで その対案が現場で各自プログラミングすることなんだよ
仮に事務員全員がプログラミングできるようになれば、定型業務の自動化という点では確かに自分で組めるようになるし楽になるだろう
でも学習コストと実益そぐわなくね?って話になったら うちの新人は7日でできたからオバチャンも7日でプログラミングマスターできる って言うんだ
そりゃ7日でプログラミングマスターしたさいつよオバチャンエンジニア軍団を産み出すことができるなら業務自動化の枠を超え対外的にも色々できそうだし飛びつくだろ(笑)
ちなみに俺もRPAは現場と情シスやベンダーが連携取りながらうまく使えれば運用も現実的だし会社の生産性も上がるしいい選択だと思うけどな ところでRPAかプログラムかは関係なく素人による自動化がコンプライアンスやセキュリティリスクを軽視ないし無視している問題は解決したのかな?
素人任せじゃもし何か事故が起きた時に言い訳できないし技術的に正しい再発防止策も練れないよね
事故の損失をRPAツール販売元が全て補填し企業の信用を事故前の水準まで回復してくれるなら年間100万はマジで格安だと思うけどそういう保険的な商品ってある? >>973
ここでは主にお仕事の話をしているので曲がりなりにもプロがやることだし、ましてや業務を遂行する上でコンプラ無視とか論外だよね
プログラムもRPAも関係なくただの犯罪行為そのものに保証だ保険とか有るわけもなし、もうちょっと頭使ってくれる? コンプライアンスはちょっと何言ってるのかわかんないけど
セキュリティリスクについてはしっかり考慮すべきだなあ
IDとPassを直に組み込んじゃダメですよーとか、入力欄は毎度しっかり要素チェックかけてねーとか
基本的なとこは情シスないしベンダーがルール付けして管理するしかないんじゃね
というか玄人コーディングでも同じじゃないこれ?? コンプライアンスは個人情報保護法とか知財法関連じゃないの RPA肯定派だけど気になる点をいくつか
初心者にありがちなミスとしては無限ループかな 負荷がかかって基幹システムが止まるとかありえるかも
悪意ありきで考えると、手作業だと膨大な手間がかかる社員名簿とかのデータ収集を簡単にできるようになると情報漏洩のリスクとかは上がるかも
結局、基本的にはRPA特有のことってなくて、既存のリスクが規模マシマシになるイメージかね なので、元々セキュリティしっかりしてれば大した懸念はないのかもしれんね 既にレスがついてるけど
>>974
プロの人がやることでも、悪意だったり過失だったり釣られたりして
コンプライアンスやセキュリティの問題が現実に起きているから
RPAはプロの人より脆弱で危険だと考えなければならない
RPAに社員名簿はともかく、顧客リストへのアクセスを許すなら
ID/パスワードが、動作画面からも、中を覗かれても割れないようにする
ましてやRPAの開発、動作用のPCに共用IDを作らない、4など要対策
全社的に展開したら徹底するために抜き打ちチェックが必要かも 非効率なSQLリクエストがRPA導入以前には考えられなかったレベルで乱発されてDBサーバやネットワークが死ぬとかね
インフラ管理が甘い会社だとありそう 簡単な話で、効果が出るのは当然なのよ。
目に見えない負債が問題なんだろ。 上の方でVBAの話が出てたが、VBAの評価が糞になっていることを考えるべき。
プログラマーがRPAで組むなら分かる。
プログラミング出来ない奴が組んでもVBAと同じで、糞評価になるだけだ。 誇大広告出してる業者には何のペナルティも無いのか?
法人相手なら自由契約といっても実害を受けるのは従業員とその家族なんだぞ 鬼門はライセンス料かな
簡単にペイできるような業務はまっさきにシステム化されてしまうから 特定の事業部門でしか使わないようなRPAのフローに対するホワイトボックステスト実施とか現実には難しいしな 実際のところテストはどうしてますか?
コントロールができない外部システムに依存するテスト設計はコーディングの30倍ぐらい難しいと思います
素人のRPA従業員全員にテスト設計の教育を施すことは果たして可能なのでしょうか? 全員は無理だな、分岐網羅や判定条件網羅が覚束ない人が多いだろう
限界値テストとかになると更に望み薄
というか、典型ケースだけに準拠した手順理解をしていて例外の発生条件を想定できない人とか、パラメタの値域が把握できずまともに動く制御条件がそもそも書けない人とか多いよ、普通の事務員って 設計もテストもしない
セキュリティリスクは想定外なのでゼロ
なら俺らのシステム開発ももっと安く楽になるのになぁ羨ましい >>831
簡単に作れるんだから
メンテナンスが必要になったら
また新しく作れば良いのでは? どれくらい複雑なフローを作るかの想定がだいぶ違うように感じるな
基本的には単純な処理なんじゃね 上のリンクにあったように複数のサイトからひたすらダウンロードを繰り返すみたいな
勿論そうは言っても複雑なフローになってしまう場合があることは否定しないがそちらばかり取り立ててもなあとは思う DoS攻撃とみなされたり回線圧迫するリスクを避けるためにダウンロードの頻度を制御するにはどうすればいいか?
同僚も同じサイトでロボットを使ってるから事業所単位で負荷コントロールしないとだめかも…
ロボットは遅すぎるから夜のうちにファイルをダウンロードさせてローカルに高速な検索システムを作りたいな
ダウンロードひとつとってもいろいろ考えだすとすぐにカオス化するよ DDoS攻撃に対する面倒みてくれるCDNを間に挟むのが簡単。
例えば(てかこれしか使ったことないけど)cloudflareなら無料プランでもDDoS攻撃低減サービス付いてたよ。 >>994
それは攻撃される側の対策では?
RPAでは攻撃者になってしまうリスクへの対策が必要だけど
そっちも面倒みてくれるなら便利だね 「色々考え出す」のは誰?
想定ユーザーである事務員はそんなこと考えずに単に手作業を代替するくらいだと思うわ そんなこと考える人は既にExcelマクロとかやってるでしょ
負荷は確かに問題になりそう 自動でできるんなら3分に1回アクセスしたろみたいな RPA側でなんかできるんかね サーバー型RPAならできるんだけど大抵高いんだよなあ・・・ このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 47日 20時間 49分 17秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。