[RPA]PC自動化技術総合スレ[効率化] Part.6
■ このスレッドは過去ログ倉庫に格納されています
>>255
だよね、容赦なくアクティビティの仕様とか変えてるし
たまらんだろうなぁ
でも新機能も魅力的なんだよねUIも変わってるし VSの方が開発しやすいね
ワークフローに限定してもVSの勝ち パターンテストと安定性テストはどう違うのでしょうか?
両方とも
データをかき集めて挙動を見る試験に思える
バターンテストは、データによる分岐が網羅されてるかどうかが肝心で途中でコケてもいい
安定性テストは、正常に動くことが大事で
分岐の網羅は無視ってこと?
揚げ足取り気味かも知れんか
異常系のテスト内容だと、名前に違和感
いや、テスト1回しかしないヘボに絡まらて
気を悪くしないでくれ >>266
>バターンテストは、データによる分岐が網羅されてるかどうかが肝心で途中でコケてもいい
まあ途中でコケたら一緒には直すけど
基本的には分岐網羅がメイン、1〜2回全分岐が動いてくれればOK
>安定性テストは、正常に動くことが大事で
>分岐の網羅は無視ってこと?
そんな感じ、単純に同じデータを10回流しても良いし、3パターンのデータ×3回とかでも良い
ぶっちゃけテストする時は実行機で放置してログと最終アウトプットしか見ない
全分岐パターン×10回とかやると放置でも恐ろしく時間がかかっちゃうので
ある意味で妥協した結果、パターンテストと安定性テストが分かれてる
(そもそも安定性テスト自体が初期ロボット群が本番環境で度々こけるっていう問い合わせに対応している内に生まれたので) 本番でこけるなら動作の様子を動画でキャプチャするのおすすめ。
再現させるのが難しい場合は特に有効。 1908になって、エラー時の動作停止でダイアログ表示されていたのが変数とかの値が表示されているトコに出てたりとかは今までの方が良かったな。
あと、代入のアクティビティでシーケンス終わりのアクティビティの結果が入れ子?の移動時に表示されなくなるのもなぁ…
いちいちメッセージボックスなりの捨てアクティビティ置くとかしないといけないのは…orz この手のソフトの動作確認ってモニター2台欲しいよな… 単独で動かして動作確認するのはもちろん必要だけどアクティビティ繋げても正常に動作するか確認するのも当然しなきゃいけないからテストは他のプログラミングとほとんど変わらないんじゃないの
例えばwebページ触るときはセレクターがきちんと取れているかの確認必要だしクリックアクティビティ単独だと動作確認できても前のアクティビティ次第ではselecter not foundでエラー食らったりするしね >>272
この手というより開発は2画面あると相当便利
hdなノートだけで開発なんて効率悪すぎだし、罰ゲームですかって思う
ちなみに自宅では3枚用意してあるけど、2枚しか使わなくなったな…
ゲームもしなくなったし… >>267
テスト環境構築についてあまりわからないのですが、テストフレームワーク(?)は何を使っているのでしょう?
c#の頃は unit test(?)とかいうの使ってたような気がするのですが >>275
RPAだとテストフレームワークは使ってないですねー
基本は目視かログ確認ですね
UiPath使ってる時はエラー処理用のxamlを専用で用意して
スクリーンショットとか追加のログとか必要なものを全部取るようにして、後から分かるようにしてます 問題はテスト内容よりもRPAだとテストの実装がめちゃくちゃダルイということだな
アレンジもダルイしアサートもダルイ
大量のコードを書かなきゃならないという場面でオレオレIDE(というかワークフロー)の生産性の低さが際立つ 今時点、人が行っている作業を自動化するのが目的でしょ
複雑なシナリオが必要、テストを繰り返して安定性が必要って
今、どんな作業を人にやらせているのよ
数々のRPAやってるが業務フローを改善して
なお複雑なシナリオが必要なんて見たことないわ
真面目にどういう業務に複雑なシナリオが必要なのか
本気で教えてほしいわ
Uipath、WinActor、Auto名人その他もろもろのRPA関係者が
まず、「業務フロー見直せ」っ口を酸っぱく言ってるけど
それは無視してる? >>279
情報を全部集めるのに別々の3画面を検索する必要があったりすると
自然と複雑になるんすよ(白目)
既存システムがクソとも言う >>268 こけた後に再現させようとしても再現できないのが面倒なんだよ。
単にそれまでの条件データやタイミングが若干違うだけで異なる動きをするからな。
全てのパターンをテストするなんてRPA使いには無理だろ。 システムの中身を知らないんだから。 >>279
もしかして調査レポート風の広告やチュートリアルで使われるようなドシンプル画面を想像してる?
もしそうなら業務系システムを甘く見過ぎ
ちょっとした作業でもめちゃくちゃ複雑になる
まあだからこそプログラミングでやったほうが良いし
APIをさっさと整備すべきなんだけどな で、結局winactorとかUIpath?とかそーゆうのって素人じゃできないの?プログラミングするより難しい? >>276
そうですか
studio起動して下の方にある ReFrameworkがテスト含んでるとか何とか検索で出てきたけど、ぱっと見ナンジャコリャで、テスト部分切り出して使えるかどうかも今のところわかってないです >>283
RPAもプログラミングと似たようなもの
プログラミングに向いてる向いてない人もいるし、呑み込みいい人悪い人、言語にもその人にとってわかり易いものそうでない物と多岐にわたる
これらは、将来的にも当たり前の建て前
なので、「素人でもできる人はいる。誰でもできるわけではない。難しさは言語自体とその人にとっての向き不向き次第」がFAQかな。(纏まってるかな…) >>282
申し訳なかった
業務システムを語って、私の意見に甘く見すぎとか書くから
なにかしら有意な見解があるかと思いきや
プログラムやAPIの整備をする「余地」があるのに
そこをほったらかしてRPAに走っちゃったパターンか
事情を知らずにきついことを言ってしまったな
自動化という目的を忘れて
RPAで複雑怪奇なシナリオを作ることを目指さないことを祈る
甘く見過ぎって突っかかる相手は、私ではなくて今の業務のほうでしょうね
>>283
素人というか勉強せずに使いこなすのは無理
だから会社で使うなら専門部門を作ったほうがいい
専門部門ってのは、RPAを作成やメンテしたら金もらえる環境作れってことね
極端な話、「営業のA君、RPAやって!あ、給料は営業成績の歩合だけね」
とかするなら勉強する意欲なんか湧かないから一生できないし、やる気が起きない
一般的にはプログラミング言語の習得と比べると簡単
あくまで学習量が少ないって話で努力は必要
知らないことを学ぶのは思いのほか覚悟はいる >>286
専門部隊ならエンジニアを雇ったほうが安くて確実
RPA製品も不要 やるべきことをやらずに少ないと錯覚してるだけだろうね
同じことしたらRPAはマウス介入率が多くて作業遅くなるし機能が揃ってないから大変 事務員を1人増やしたほうがコスパいい
だってRPAにはお茶くみやお使いは出来ないもの >>287
あくまで中小企業の話だが
パッケージソフトの中には
意図的なのか偶然なのか
プログラムじゃ動作させられないのがあった
例えばデータが専用のアプリでしか見れないタイプとか
だから、RPAを使うしかない
IT以外の会社に
エンジニアは来ないよ
人雇えって簡単に言うけど
どこも人こないわ >>291
それもプログラミングでできるよ
rpaは不要 上級向け:プログラミングでなんでもできるよ
下級向け:事務員でなんでもできるよ
中級向け:RPAでほどほどに効率化できるかも? >>294
>上級向け:プログラミングでなんでもできるよ
>下級向け:事務員でなんでもできるよ
>
>中級向け:プログラミングでほどほどに効率化できるかも? >>293
RPAかどうかは分からないけど転職はできる。
スキルは置いておいても、自分で自主的に完結したPG作って動画にして上げる行動力のある人間なんて100人に1人もいない。 >>291
そりゃ給料安けりゃ来ないだろ
事務員並み(よくて年収300万円台)の給料じゃな 今日UiPath使ってみたけどクソ重い
俺の貧乏PCには荷が重かったようだ >>299
元々メモリ8GB辺りが推奨なはず
実際の業務考えると複数のアプリを同時起動して動かすから
ある程度余力が無いと死ぬ >>292
なんでプログラムでできるって断言できるんだろう?
その「とある操作のプログラム化」をITベンダーに依頼してもできないという回答だった
「専用のアプリ」を解析するってことなら、ライセンス違反になるから手に負えない
本当にできるってのなら依頼したいよ
でも「できても、できなくても調査費は頂きます」ってのなら勘弁
そこはもう、何回か通ったので
>>293
それを人に教えること(要は10人くらいの前で話す)と
研修を数回受けて学習できるなら、それを使う会社に転職できる可能性は高いです
>>298
なんで給料安いって話に……
転職支援会社の相場情報を参考にするし
中小企業でIT化を目指すと助成金が付くから
平均より少し高めにしてる
が、長期雇用希望者は現実に来ない
派遣の話は多いがそれはパスするように勧める >>292でないですが、パッケージソフトの自動化ちょっと興味あります。
ちなみに私はこのPC自動化技術総合スレPart1立てた人間ですw
調査費など勿論不要です。
純粋に技術的に興味あるので。 >>301
rpaで出来るならプログラミングでできるよ
IT屋は建前でできないんでやりませんって断ること多いけど実際はあらかたできるからな
他に断られる理由があったんじゃないか? そもそもrpaはそのOSが出来ることしかしてないのだからプログラミングで同じことできないわけがない RPAはEUDだって言ってるのになんで外注に出したり、受注したりしてんまよ! エンドユーザーにはちと難しい
あと開発ライセンス高い >>305
結局管理や保守要件定義など車内では誰も出来ないか
余力がないから
システム部の手が回らないからエンドユーザーが作ればいいというところが多いんじゃないかね
で業務改善が本来の目的なんて言い出すから運用や管理もきちんとやらないとってなって
こりゃやってられんな
しかも開発も誰でもできると聞いてた割には
.netの知識必要じゃねーか
で挫折
らいせんすこうにゅうした手前、使わざるを得ない >>279
>まず、「業務フロー見直せ」っ口を酸っぱく言ってるけど
正論だが一番難しいタスク
勇気を出して見直したらRPAすら要らなかったりする無駄業務だったり >>308
業務の流れ変更するって大変だし、
いろいろしがらみがあってシステム改良もできないから
RPAにってケースだと
一気に難易度上がるんだよね 面倒臭いこと全部ロボットがやってくれるんやろ?
って、くっちゃくちゃのフローそのままでシナリオ作り始めるから…
ちゃんと最後まで組めたやつ見たことないわ。 >>301
待て待てw
RPAったって本体はプログラムなんだから…
RPAがプログラミングでできないことを実現できるなんてこたあないw 俺のいる自治体もRPA助成金出てる
当然限りがあるので早い物勝ち
RPAには無料のもあるのに知らない(覚えられない)バカもいるのな 助成金申請しようとしたら企業規模で制限あるのね
そりゃそうだよな 出来る出来ないの話を、技術的な可能性と
コストや効率考えた時の現実的な話とごっちゃにするから
おかしくなる 業務フローと密接に結びついてる業務システムとそのユーザーインターフェイスをロボががっちり押さえ込んでしまうと業務フローを改善したくてもできなくなってしまうのだよね >>303-304
働いてないのか?
技術的には可能ですが、その期間と費用ではちょっと…
とか
親会社から押し付けられてるツールで手を出せない
とか考えたこともないのかよw >>317
なんでツールに手を出すとか意味わからないことを考えてるんだろう?
ボタン押したりテキストを入力したりといったRPAでできることは
プログラムでもボタン押したりテキストを入力したりできるってことだと思って読んでたが まあ、そんなに揉めるような内容じゃない
落ち着こう 技術的なレスを返すとほぼ必ず非技術的な反論で粘着してくるから他所へ行けと言われるんだよ
おまけに人間の屑だの死ねゴキブリだの罵倒まで付いてくる >>317
要らないはずの費用かかるのでrpaはちょっと…となるな >>301
RPAソフトもプログラムと原理的には同じで対象プログラムのコンポーネント構成の解析情報をプロセス内のメモリに読み込んで処理しているからやはりライセンス違反になる可能性があるのでは?
プログラム間の連携とはいうけどAというプログラムはメモリダンプされDOMツリー上にひん剥かれたある機能をループ処理によって自動的にInvokeを繰り返すという使い方をされた時点で
もはや主機能Aをもつ部品に成り下がりそれを無許可で包含再利用してBというソフトウェアを新規作成し営業活動に利用しているととらえられなくもない気がする(詳しい人教えて)
パッケージソフトを作る側としては許可もなくそんな使い方されたらおこおこで使用差し止め請求どころか不正使用による逸失利益の賠償まで要求したくなるかも
ベンダーにチクったらどうなるのか興味があるので誰かやってみてください(他力本願 利用規約に書いてあるのでそれを読めとしかいえんな
ウェブだと規約以外にもrobotsやキャプチャで拒否する意思を示してる場合もある
意思表示は特に無かったけど後から通報されたケースも過去にあった
コンプライアンス重視のまともな企業ならクローリングする前に確認とってからやる
エンドユーザーに任せるとこの確認しないですごい負荷かけたりするからこわいね uipathで出来上がったけど、それからフローチャートとかよ仕様書作るのが時間かかる…
uipathで仕様書用にフローチャートをエクセルで使える様な図形で出力できる様にならんかな? >>316
ウチは手書き申込書の読込み断念したわ。
5人担当つけて1年掛かりでダメだった。
周りのプログラマは誰も助けてくれんのな。 >>327
手書き申込書なんてAI-OCR辺り使って読ませて、一回電子化しないと無理だろ
RPA単体でやろうとしてたなら最初から失敗するに決まってる、普通のOCRじゃまともに読めない >>326
同じフローチャートをまたEXCELに書くのは無駄
せめて画像保存貼り付けで押し通すべき
と思う >>327
pfu(だっけ?自炊で人気のあったとこ)のOCRのデモ見せてもらったけど良さげでした
高いかもしれんけど、1年かけてダメだったなら検討する価値あるかと uipathは確かフローチャートの画像出力できたな。 >>327
あー、多分人数じゃないのよねこういう開発って。
1人でも適性があれば。
>>328
各種比較したけど、一概にそうは言えなくて
手書き文字もtegaki に遜色ない従来のOCRはあるよ
逆にAIでもあまり認識良くない奴もある大手で。
>>330
そこのは、数字は手書きでもいける
漢字ひらがなは諦めたほうがいい
運用で全てコード化して書かせ流ことができれば安くてコスパいい >>319
だから技術的にできることと期間・費用を込でやるべきかを区別しろよ
って指摘されてるだろ 本屋にいったらドーンと一角がRPA関連だったけど
そんなに売れるジャンルなんだろうか? RPA導入の相談を受ける。
業務内容を聞いてると、それExcel単体で普通に出来ますよ?で完結する。
RPA導入が目的になってる会社が多い。
特に中小企業。 >>326
そのプロジェクトに関するものだけならまだいいんだけど、
立ち上げ当初というか今、運用から保守までガイドラインみたいなの作れと言われて困ってるわ
営業所事業所毎に管理するとなれば、シナリオの管理台帳もいるだろうし、ログ集計も独自のログファイルにロボットごとの稼働を吐き出させなきゃならんだ老子、オーケストレーター欲しいけど高い >>334
バブル崩壊前夜って様相
分かってるから販社は説明会バンバン開催して値下げして
そこに時勢に疎い経営者が今頃群がってる感じ
だけど採算取れる業務って限られてるのがバレてきてるから
最近は説明会でもやたら、導入挫折するよって煽ってコンサルや製作請負を勧めてくる
もしくは、業務全体の効率化が出来れば元は取れなくても意義があったんだ的な説明多いね
開発工数とか考えたら、企業規模大きくて単純入力作業抱えてないところは苦労するんじゃないかな マイクロソフトが新しい規格作ってそれに対応させるだけでいろいろ変わるのに
アプリメーカーはコンポーネントの名前を公表してそこに流し込むAPIと読み込むAPIとクリックAPIがあればそれでかなり楽になる
タブオーダー自由に変えれたりすると手入力も楽になるし >>335
経営者がね・・対外的に宣伝したいって思惑あったりする。
で、年間数十万の費用かけたんだから少しでもRPAを使えとなる。
金出したものが遊んでるのが我慢ならんと。
で稼働率だけ無理やりあげて、じゃあ費用対効果はどれだけ出たんだって段になって、なんでトントンナンダみたいなところまでが一連の流れ。
そもそも導入がまちがっていたという結論は皆分かってるけど、言えずに犯人探しが始まる。 よっぽどストレス溜まってるのか十一回も書き込んでたすいません 20年前に客先で発注用のファイルをエクセルでくれる人がいて
それを使って自社システムとアクセスのフォームに自動入力するアプリを作った
毎日の入力一時間が5分になったけどそのシステムを100万使って作るだろうか? >>336
ロボットの稼働ログは、uipathのログから掘り出すことにしました
既に何ヶ月も動いてたのもあって
前日までのデータで困ることはないだろと
いつでも掘り返せるので、開始終了エラーだけACCESS DBに。集計、リスト出しも簡単 >>336
うちもガイドラインボロボロだったから手直ししてるけど、素人向けにあれもこれも書いてたら、「これ見たらやる気無くすな」と思った
初心者が最低限守るべきものと、慣れた人の追加版みたいにした方がいいんじゃないかと思ったりもする
初心者が全部覚えられるわけないんだから >>343
開発者の育成は下地がない場合は研修行ってもらうしかないと思ってる >>331
画像で保存もできるけど、イメージで保存してエクセルにペタって貼り付けれるよ
余白にコメント追記していけば社内運用なら十分マニュアルになると思う >>329
>>336
さらに、各アクティビティのプロパティも載せろとか言うし…
なんでしょ、uipathで作るの2日半(そこそこテスト込み)なのに、仕様書?で2週間くらいかかりそうな気がして本末転倒ってこういう事なんだろうな…と思ってる… >>347
ドキュメントを作る上で重要なのが
これが無いと〜という場面で困る、っていうのがあるかどうかだ
UiPathならオーケストレーター無しなら作ったロボットを管理する台帳が無いと、後で作ったロボット群を確認できない
で、フローチャートとプロパティを乗せた資料を頑張って作ったとしても
「ソース見りゃええやん」で終わる可能性が非常に高い
(そもそもとして、ドキュメント作らないようにフロー図でソースが作らているので)
あとRPAは仕様追加/改修が結構な割合で入るので、その度に不毛な仕様書を書き直すと工数が溢れる
正直な所、このドキュメント作っても「RPAのソースがロストしたから一からノンヒアリングで作って」っていう状況でもない限り日の目を見ないと思うので
それに時間をかけるならTo-Beに関する資料をちゃんと作った方が良い
・RPA化対象の業務の概要と目的
・そのために必要な操作(スクショで簡単に撮影すればOK)
・データの例外処理(検索スキップやエラー扱いで止めるもの)の一覧
これらを整備しておいた方がまだ役立つ 今日のスレはためになるなぁ
しかしうちの組織の上の方も(RPAというより)一般的に費用対効果の見積とか検証とかはあんまり興味ないみたいなんだよな 謎だよ 業務改善系の評価基準って費用対効果しかありえないと思うが Uipathのライブラリで作った自作アクティビティは、
一度埋め込んだら新たにパブリッシュしても
シナリオ内のアクティビティは更新されずに
認識されなくなるだけか
全部、入れ直しか >>351
リビルドするだけじゃないのか?
参照してるプロジェクトを列挙して一個一個IDEで開いて参照のバージョン数あげてリビルドしてパブリッシュ
もしそれに依存してる他のライブラリがあればそっちも連鎖的に参照修正作業が入るということ?
VSで開発してる身としては信じられんな
やり方間違ってるんじゃないか? >>353
うーむ
シナリオ内のアクティビティは古いバージョンのままあるか、変更が大きければ認識されなくなるな
間違えとるのかね >>347
ログの仕様決めてライブラリ作って組み込むだけで4時間かかってる俺って >>351
古い自作アクティビティのパッケージファイルをその都度消すとそうなると思う
ファイル名にバージョン書かれてて被らないから、異なるバージョンのも残しとく
そうすると、前のバージョンあるから消えない
パッケージ管理でバージョン選べるのは、バージョン違いを選べるようにするため
「おそらく、そういう仕組みかなと思ってる」
なので、
古い自作アクティビティもそのフォルダにどんどん溜める
(どのロボットでも使わないとわかってるのは消しても可)
古い自作アクティビティを使ってるロボットをスタジオで開いて、パッケージ管理で新しい自作アクティビティのバージョンに更新
な手順になるかと なんか飽きてきたな
ステマも元気ないしここも潮時かな UiPath導入しようと計画たてたが、部署ごとに1ライセンス買っても(本当は複数買いたいのを抑えて)、
87.5万円 × 100部署以上で1億円以上かかることが分かった。
(減らせないけど))本社、支店・営業所ごとに買っても10以上で1千万円以上かかる。
こんなにかかるとは >>358
うちもっと安いけどぼったくられとるかネットの定価表示しか見てないんじゃない?
色んなライセンスパターンあるからちゃんと見積もり取った方がいいぞ
まぁアンチRPAの嘘だとは思うが ■ このスレッドは過去ログ倉庫に格納されています