[RPA]PC自動化技術総合スレ[効率化] Part.5
■ このスレッドは過去ログ倉庫に格納されています
>>744
どんなもんなの?って奴まで含めると
エキスポとかすごい多いわ
AI絡めると入場制限かかるわ
それは嘘だけど フリーランスのRPAエンジニアって儲かるのかな?
今ブームのように見えるけど将来どうなりそう?
ここにいる人たちはある程度知識がありそうだからぜひご意見聞かせていただきたい >>733
ステマと言われるけど、俺は会社から与えられたuipathは非常に便利だと思ってる
もはやこれなしで手作業には戻れないわ
単純な作業と思っててもクリックが仮に50個くらいある。その都度選択と正確な作業を知らず知らずにやってたわけだ。
そりゃ脳は疲れるよね
それがなくなるんだからそりゃ楽だわ 各個人が自分で組めなきゃRPAなんて無価値
RPA要員を雇うくらいなら普通のSE,PGを雇ったほうがいい RPAの、究極にし影の伝説の冒頭のシーンだけどさ、
←_ _─ 忍者
─_ _─
─_─
←─── 姫ょうもない使い方ってなんだろう? ↑ミスった。
RPAの、究極にしょうもない使い方ってなんだろう? RPAが安くなって普及する前に、機械翻訳精度が上がって
人件費の安い国に事務仕事を振る方が安く済むかもね。 どこの会社も毎朝8時に出社みたいだしな。
それも自主的に。
8時50分にノコノコ出てくると「今朝の動いてませんでした」のメールの嵐。
メール見てる間に別の奴から催促の電話w
既にあるあるだろw 初めは皆そうです
次第に安定して動かせるようになる
(その作り込みを最初からしたくない。いけるかな…だめだったか…で、そこだけ対処で済ませたい) >>762
でも「新しくコレ自動化したいんだよね」でまた8時出社。
おまけに自主早出だから早出残業つかないw
夏休みみ何故か交代。
(呼び出しアリ) 何で自動だと8時前提なんだよ。
アホばっかの会社か? あー、今日も来たらRPA糞詰まりで内線鳴りっぱなしだよw
稼働して2年経つから、データも滞貨が2年分かw
大量に積み上がって上手く動かないみたいねw
ちなみに金融ですが大丈夫?www ユーザー企業であってもRPAすら内製できない企業はもう将来性が無いような気がする ただ動けばいいという段階を超えて安定感が求められる段階まで来たなら、RPAを捨ててプログラミングに移行すべきでしょうね
安定させるためには細かく複雑な制御と非GUIのAPI活用が必須なので、プログラミングのほうが遥かに実装しやすいです
配線タイプの開発環境は細かい作業には向いてません なんでもかんでもRPAで済まそうとするから…
システム化までのつなぎっていう認識大事 システムシステム言うけど、
例えば各社仕入先から検収書や支払明細を色んな形で月30件ダウンロードしてるとした時にそれをシステム化するのか? RPAがなんでも解決してくれるってわけではないっていう指摘じゃないの?
そういう相手の都合でこちらが対応しなくちゃいけないようなものはRPAでいいんじゃない。
社内の業務システムのGUIをRPAで無理やり自動化してトラブってメンテナンスに時間かかるなら、
RPAでやりくりしてる間に業務システムにAPIを追加してもらった方が良い、っていうことでしょ。 短期間で消えるものはpythonでもuipathでもvbaでも作成者の好きに作ればいい
ただし短時間で消えるべきものを延命し始めたら危険信号
長期間メンテナンスするならベンダロックインを避けてちゃんとシステムに取り込もう そもそもRPAが流行り出したのが
・通常のシステム開発ではROIが確保できないような仕様への対応
(RPAでやれば安価で収まるからROIが確保できる)
・仕様追加が凍結された基幹システムに対しての疑似的なシステム拡張
っていう、既存のシステム開発に対する小回りの悪さから需要が出始めた代物だからなあ
立ち位置的にはちょっと便利な小道具がすぐに作れて、なおかつ管理ができるっていうものだから
ゴリゴリに作り込むようなRPAが出始めてる状況はわりとやべえんだよな
ロボットが多いほどそれだけギャップが生まれてるって事だし >既存のシステム開発に対する小回りの悪さから需要が出始めた代物
スクリプトでいいじゃん
小規模のちょっとした処理なんてのはスクリプトの最も得意とする分野だよ
RPAだとライセンスのせいで実行マシンが限られるのも痛い 例えるなら
ハサミを使うのにハサミ専用部屋で順番に使う
ハサミ要員を用意してハサミを使うときはその人にお願い
ちょっとした小道具を使うのにこんなありさまじゃ大変 >>775
問題を解決する手段としてはスクリプトでも良いかもしれないけど
誰が作るって管理して展開するのかっていう課題が解決できない
特にITリテラシーが低い現場だと
マジでボタン一個で動いてくれて、トラブルが起きたら電話一本で丸投げ出来る環境じゃないと全く浸透しない
RPA使っててもマクロやPowerShell動かすキャリアーみたいなロボットも結構あるけど
RPAとして維持保守体系に組み込めるから価値が出る RPAよりもシステム改修の方が適切だという正しい判断を下した場合、担当者は適切に評価されるのだろうか。 >>777
それはCIOのタスクです。(やらないけど)
下っ端はアホな上がRPAで行くと決めたなら黙って従うべきであります。 システム化でROI取れるものはシステム化
上記に当てはまらないもので自動化対象がMS関係とかのCOM操作できるものならスクリプト系(VBA,python,uwsc)
APIも用意されてないレガシーなWinネイティブアプリが絡むならRPA(uipath,BP,AA)
って感じで上から順に検討してくのがいいと思う
社内SE一人もいないようなとこはこういう振り分けまで世話してもらえる外注先探すといいよ >>776
>誰が作るって管理して展開するのかっていう課題が解決できない
ちょっとした小道具なら製造も管理も利用者本人セルフサービスがいいよ
へたに共有して社内資産にするとメンテナンス負荷が高まって面倒
共有する価値があるものなら社内リポジトリで管理すればいい
>特にITリテラシーが低い現場だと
>マジでボタン一個で動いてくれて、トラブルが起きたら電話一本で丸投げ出来る環境じゃないと全く浸透しない
そこまで頭が悪い人は現実に存在しないと思う
冗談ではなくそんな人が存在するならその人ははやく解雇したほうがいい
ボタン押すだけでトラブル対応もできないならいる意味ないよね
>RPA使っててもマクロやPowerShell動かすキャリアーみたいなロボットも結構あるけど
>RPAとして維持保守体系に組み込めるから価値が出る
RPAという維持保守管理対象レイヤが余計に増えるだけ
共有資産はリポジトリで管理すればいい >>779
>APIも用意されてないレガシーなWinネイティブアプリが絡むならRPA(uipath,BP,AA)
ここもプログラミングでOK
RPAでなければできないような印象操作はやめよう win32api使えばRPAと同等のことはできる
高いライセンス料なんかいらん 比較的簡単に実装できるのが強みなのにそれを言っちゃぁおしめえよ >>782
プログラミングでGUI操作==win32apiのような印象操作はやめよう
もっと高レベルで使いやすいパッケージは幾つもある >>777
上層部「RPAってのがいいらしいから検討して」
っていう指示だとなかなかシステム改修とは言いづらいわなー >>785
「RPAはプログラムに制限を掛けて有料化しただけのツールなのでプログラムのほうが良さそうですね
プログラミングはライセンス無料なので失敗してもリスクはありません
入門書やエコシステムも充実してるので初心者でも簡単だそうです
pythonなどはVBAマクロよりも簡単なので事務のおばちゃんや小学生でも出来ますよ
プログラマは飽和状態といっていいほど人材が豊富なのでもし外注することになったとしても競争原理で安くあがります
プログラムだとシステム改修になるんじゃないかって?
いいえRPAと同じように既存システムを外部からコントロールするだけです
それがシステム改修だと言うならRPAもシステム改修になりますね
その気があればRPAよりもスムーズにシステム改修に移行することもできます
RPAだとベンダーロックインして移行が難しくなります
」 RPAの実態は単なるバッチ処理
それをまるで特別なもののように思わせ買わせてしまう
商人という人種は本当に凄い RPAってプログラムするのと違って自由には作れないよな? 自前の情報システム部隊を持って、
事務屋の人員削減をするだけじゃないの?
RPAを使うにせよ、プログラム化するにせよ、
自分の所で判断して、切り分けて、
内製するなり、外注するなりすればいいだけで
その判断すら横着して、ITを分かっていない
人間が仕切りだしたり、外注しようとするから
ぼったくりや、泥沼案件になってしまうんじゃないかな >>788
大半の商売は今まであるものの組み合わせと
ガワを少し変えて売りつけるものじゃないの? RPAが役立つのは
前提として、プログラミングやスクリプトを仕事にしている人を使役しない、前提で(大事なので2回)
もうひとつ前提で、作業をやっている人が自らRPAツールで自動化(部分的自動化)する前提で()
これらの前提が崩れるならRPA以外も選択肢に入るが
あえてRPAを使うとして
それなりのプログラマーがRPAを駆使した場合の生産性はすさまじく高くて
その反面、機能拡張・修正、ドキュメント、管理、保守の生産性はすさまじく低い 面倒くせぇよなぁ。
ExcelやAccessには、標準でDB接続機能があるのに、
そういうのは、情シス以外は使わせてもらえないんだよなぁ。
あ゛ぁぁぁぁぁマジあほくせぇぇぇぇぇって思いながら、
システムのGUI操作するプログラム書いてるわ。
ウインドウハンドルとか、いちいち調べてよ!
おかげでUIAutomationも使えるようになったわwww >>792
それなりのプログラマならプログラムを書いたほうがはるかに生産性が高いよ
ビジュアルプログラミングは苦痛を感じるぐらいめんどくさい 作業者本人が個人的に自動化したい部分はRPA
RPAのレクチャーは、情シスが希望者に行う
ここでの作業者は、事務屋ではなく、何らかの専門分野の人に限る
上記の切り出し部分を多人数に展開したい時はプログラム化
DBアクセス権限は、プログラムごとの許可という感じかな、開発ツールの使用も含めて
協力会社等の人は厳しそうだけど >>793
DBは整合性維持のためにアプリケーションがあるから勝手にアクセスされてはこまる
アクセスコントロールしやすいAPIを整備すべき
>>794
アクセスコントロールしたいならAPIを整備すべき
APIのセキュリティ機構としてよく利用されるOAuthはも認可を細かく制御できるように設計されている >>796
そうなんだけどさ、APIも作ってもらえないから、
RPAなんて流れになってるわけでしょ!?
あーマジあほくさ。
情シスがDB操作するのが最速だって、どれだけの経営者が知ってるんだろう・・。 >>795
×作業者本人が個人的に自動化したい部分はRPA
○作業者本人が個人的に自動化したい部分はプログラミングあるいはRPA なるほど
結局、API化がキモなのかな
「UNIXという考え方」の要約のプレゼンでもすればいいのだろうか >>798
RPAに手を出すことから予想が付くがおそらく経営陣は情弱なのでAPIの存在を知らないのだと思う
なので要望か提案を出して経営陣にそういうのもあるんだと気付かせることがスタートかな
トップが愚鈍だと苦労するけど長く勤める気があるならやっておいて損はない
なんならRPAをダシにしてAPIに興味をもたせる手もあるな
プログラムだけでなくRPAからもAPIを呼び出すことができる
APIの呼び出しは画面を操作するより遥かに簡単でセキュアで安定して高速で柔軟なのでより高性能のロボットを安く作る基盤になるので是非とも検討してくれ
などと説明してみたらどうかな APIというより同等のCUIインターフェースでもあればバッチ処理で済むのにね 今後はRPA対応のExcelとブラウザが覇権とるぞい。 >>802
APIを整備すればCUIを提供することも容易になる MSが本気出して、RPA・OfficeOnline&365・ブラウザを
統合したら今のRPAツールの大半がゴミクズになる Microsoft的にはもう十分提供しているという認識なのではないかな
OfficeはVBA、COM Automation、Open XML、MS Graph API
GUI操作はUI Automation、WinAppDriver
ワークフローはAzure Durable Functions、WWF RPA対応の○○
手段と目的が逆転してる感が凄まじい
遊び好きな日本らしさが溢れていてイイね MS的には、Excelを正しく使いこなせば、その作業は一瞬で終わりますよ
と指摘したいこともあるだろう
マクロ以前の世界も少数派では無い さすがに、RPAでスーパーマリオをクリアする動画はまだないか。 設計詳細とかってやはりuipathで作る前にプロパティの内容まで作るもんですか?
フローチャートはわからんでもないけど、プロパティまで…ってなんかそれは無理なんじゃね?と思ってしまったので… >>811
RPAだと作りながら調整する事が多いから
プロパティの内容まで事前に決めても無意味 >>811
そういう従来プログラミングスタイルに当てはめて製造以外もキッチリやるならプログラマ雇ってプログラム書かせた方がいいよ
そういう堅苦しいことを抜きにしててきとーに作って動いたやったーで許されて初めてコスト削減になる
製造以外もキッチリやった上に製造が難しいRPAにしたら全体コスト増えてるじゃん >>812
>>813
ですよね。
なんかRPAの利点をことごとく潰してる気がしてます。
ま、契約更新する気は失せたのであとは頑張ってねーって感じですかね。 ネットワーク・サーバー構築やカスタムアクティビティ製造のために外注するなら何歩か譲って理解できるのだがワークフロー製造を外注する意味はまじでわからん とりあえず、設計書?のためのテンプレート作っている…
どっかに全部のアクティビティのテンプレート(大項目…その他とか入力とかから各内容とドロップダウンリスト内容とか)落ちてないかなぁ…w >>815
派遣入れた方が安く上がると思ったんじゃないですかね? >>816
設計書にアクティビティのプロパティまで書くなら詳細設計書く予定?
それとも、別の話し? >>818
そうです。
誰が見ても作れるようにしたいらしいです。 >>816、>>819
多分それ無用の長物になるぞ
というか単純に工数がアホみたいにかかるぞそれ
UiPathの場合
短いロボットでも100〜200アクティビティ
長いロボット(複数画面を跨ぐもの)だと500アクティビティは余裕で超えるから
そのプロパティを事前に全部書き出すとか狂気の代物だぞ
しかもこれをするのはRPA化対象の画面特性(データスクレイピングの可否、エレメント認識の可否、シミュレートクリックの有無)
を全部把握してないと、事前に設定したアクティビティが使えない事が十二分にあり得る
「シミュレートクリックが効かないから通常クリックにしよう」とか
「エレメント情報取れないから画像認識が必要になる、
そうなると確実に画面に表示されるようにウィンドウ位置を移動させておこう」
とか細かい部分は作りながら調整していくけど
そのたびに設計書直してたら開発工数かかりまくってパンクするぞ >とりあえず、設計書
>誰が見ても作れるようにしたいらしいです。
そういう局面は現実には無いような気がする
設計書があると思われない、探せない
設計書を見ても作れない >>820
えぇ。
自分は分かっているのですが、上役が用意しろと…
正直RPAってフローチャートは書いたとしてもプロパティは作りながらでないと意味無いよな…とは分かってるのですが、自分はエンジニアでは無いからとか言って詳細設計を作らせる上役でして…
さらにまだRPAでこのプロジェクトやれるかの承認すら取ってないんですよ…
なので、契約更新せずに終わろうと思ってます。
数ヶ月でほとんど進んで無いので、入った理由がわからんのですよ…
普通なら承認取れてから雇うと思うんですけどね… >>822
RPA作る時に必要になるのは
・画面遷移が分かる手順書
→スクリーンショットを取ってエクセルにペタペタ張って作る簡単な奴で良い
条件付きでポップアップ画面とかが出るならそれも張ってあると後で困らない
・最終的なアウトプット(とそのレイアウト)
→エクセルとかを別途出力するなら、どういうレイアウトで出力するのかを
実物を見せて合意を取る(大体
・細かい条件のすり合わせ
→例えば画面検索した時に結果が0件だった場合に
・0件はあり得ないからロボットを停止して担当者にメールを投げる
・0件な事はちょくちょくあるからそのデータをスキップして続行する
みたいに細かい要件を煮詰めてまとめておく
(この辺をサボると本番環境した時によく止まる)
この辺が重要になるからプロパティ値を書いた設計書書くぐらいなら
ユーザーからのヒアリングを細かく取った方が良いっていう uipathなら画像でフロー書き出しできるし、そこの空白に適当にコメント記載すればいいんじゃね? >>822
前に金融系で仕事してるって言ってた人かな?
私が昔某メガバンクで仕事してたときも、詳細設計きっちり書いてレビューしてました
まあ、メガバンクは止まると大変なことになるので、そこまでやるのは当たり前
ロボットも、止まったり間違った判定してたりしたら大変なことになるので、詳細設計書くのも、レビューもやるべきでしょう
夜間ロボで朝までに終わらないといけないなら、止まると非常召集かかって皆で解決にあたる。
そのとき、ソース見る人も、詳細設計見る人もいます
そういう現場なら、詳細設計は重要です
アクティビティとプロパティ一覧は作りたいと思ってるけど、まだ作れてないし公開してるのを見たことないな… >>825
そんなクリティカルな案件をRPAでやるとかちょっと頭おかしい >>826
まあ、あくまでこんな感じの一例ってことですからね
勘違いしないように いや、「そんな感じの案件」への適用の話な
勘違いしてるのはお前の方かとw >>828
あるかどうかわかんない例え話や昔話に、何マジレスしてんのw 金融は負の遺産が大きすぎて気軽にテストできないから、詳細設計書に異常なほどこだわって、事前に徹底的にレビューするしかないってのが実情
あくまで仕方なくそうしてるのであって、一般的に言って詳細設計書に膨大なリソースを費やすのは悪い習慣なので、真似しないように
そんなリソースがあるならテストを書きなさい はいはい、
頭おかしい奴へのマジレスは確かに恥ずかしいなw >>830
負の遺産というより、金融庁のお達しで省略できる工程は無いんです
一般企業は、ロボ化の内容、作りての技量など加味しながら適宜省略ですな >>831
あ、マジだったんですか
それは悔しいですねw
バカは相手しませんので、一人で踊ってください >>833
相手しないと言いつつレスしないといられないほどクヤシーってことはわかったよw 金融系はIT音痴を金とマンパワーで誤魔化していくスタイルだから踏襲すると金がいくらあっても足りずに品質だけが下がっていく >>835
こういうのって最後まで言い続けたら勝ちと思ってる
頭おかしいやつだから、関わったらくだらない話しに引きずり込まれます > こういうのって最後まで言い続けたら勝ちと思ってる
> 頭おかしいやつ
>>837のことですね、わかります >>825
ジャパンネット銀行や新生銀行が最初に日本でネットバンクやった時と、SMBCの最初の青い画面なんかの時代だと、設計書はロクに無かったらしいよ。
金融庁もネットリスクなんざ知らないし。
スキーム判ってないし。
2000年じゃ職員が自宅にインターネット引いてる人がいなかったらしいし。
黒船の技術だったんだろ。 >>842
2000年でインターネット接続してる奴がいないって
ガセネタだとなぜ気がつかない? ■ このスレッドは過去ログ倉庫に格納されています