>RPAを使えばエンジニア不要
というのは
>(極々単純なルーチンワークの自動化には)RPAを使えばエンジニア不要
という意味ですね
(簡単なホームぺージをつくるだけなら)WordPressを使えばエンジニア不要
(単純な表計算には)Excelを使えばエンジニア不要
と同じでエンジニアにコーディングを依頼せずとも目的が達成できるという意味
ベンダーがRPA売りたいがための誇張広告「エンジニア不要」が癪に障るのはとてもわかりますが、
システムを作る側（エンジニア/コーディング）と使う側（ユーザー/RPA）という決定的な差があるので
RPAをエンジニア視点で「システムを作るツール」としてみるならもちろん不十分だし
RPAをユーザー視点で「システムの使用効率を高めるツール」としてみたら便利に使える、と
> ソフトロボットの動作を記録するログについては「製品によっては動作の過程を含む詳細なログを取得できない」（同氏）という。
> 安部氏はこれらの要件を満たすRPAツールとして「BizRobo！」「UiPath」「Blue Prism」の3製品を挙げた。
あれ、ニッポンの埃WinActoなんとかは？ｗ
システム更改時にRPAが動かなくなるから画面を合わせろとか宣う顧客が出てくる定期
モニタの解像度変えたらロボット動かなくなってプログラマンに怒られました
>>582
Inspectは自分も使ってる。
UIspyは今はダウンロードできる?
持ってるけど挙動も少し怪しい。
自分が一番使ってるのは大分昔にダウンロードしたフリーソフト。
ハックツール扱いで使ってた人が多かった。
その人のHPが閉鎖して今は手に入らないな。
あとは自作した奴で、その言語用だけどソースコードを自動生成する奴。
他にもVBAで作った奴とかもあるけど完成したツールとは言い難い。
RPAはそれが無いと動かないのが。
ソースコード生成なら無くても良い。 >>607
もしやWinspectorでは…？
太古の記憶が読み覚まされてきた
うさみみとかollyなんたらとかで色々やってたわ…懐かしすぎてへんな汁出てくる
UiPathには専用のuiエレメント走査ツール組み込まれてて、調べると同時にセレクタに反映できて便利り スーパーコントローラーIIの、メモリー機能の使い方が未だにわからない。
操作を記録して、それをそのまま再現するものだと思ってるんだけど、違うかな?
RPGで、アイテム選択が楽にできるって箱に書いてあるんだけど。
余計な機能盛り込みすぎなんだよな
ジョイカードMK２で十分だろ
破産者マップは面白いアイデアだな
短時間しか公開されない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の設定を変更すべきでしたね
>>618
ツールに縛られて腰が重くなるのあるあるですね。
自分自身は日頃から簡単なスクリプト程度なら組んでるし、自分にメリットなさそうだから色々理由つけて導入蹴る方向にしよーっと >>620
昔、PCの電源24ピンのどのピンとどのピンを繋げたら電源入るかを調べたのよ。
で、電子工作でスケジュール通りにスイッチの入る基板作って英会話勉強用にNHKラジオ録音させてたな。
USBで繋がるコンポはPCからコントロール出来る奴だったのでPCの電源入ったら勝手に録音して、MP3に圧縮するプログラムと、起動してから30分後にシャットダウンするプログラム組んで。 >>624
その当時は出来なかったと思う。
その時はWakeup On Lanもマジックパケット流す側が無かった。 Automation Anywhere ジャパンの社長が業績不振でクビになったって本当ですか？
>>629
その当時がどの当時かは知らんし個人的な昔話ならチラ裏にでも書いとけよ >>614
技術者の場合は日報管理とかテーマ登録とか日常業務じゃないか
どちらにしても作業減らして考える仕事時間増やすのが目的なだけだから頭しか使ってないと自負できるなら導入無駄 うちもこういうのの成功例として記事になってるけど、
今は誰にも使われずにゴミになってるよ
特に実験とかPOCとかのワードで上手くいったとかはゴミプロジェクトの可能性がかなり高い
>>635
> うちもこういうのの成功例として記事になってるけど、
> 今は誰にも使われずにゴミになってるよ
> 特に実験とかPOCとかのワードで上手くいったとかはゴミプロジェクトの可能性がかなり高い
どうして誰も使わなくなったのか知りたい >>634
役所や中小企業は工員のような繰り返し作業をPCで丸一日やってたりするから、
RPA導入が効果を発揮することも有るかも
そして、ほとんどは、RPAではなく、シェルやExcelのマクロで代用可能 RPAの導入なんて目辺り次第に自動化してもダメだろ
まず今の業務が本当に必要か？とか見直すと、案外業務自体がいらなかったり単純化出来たりする
見直すキッカケになるのはいい事だけど
本当に必要な業務だけに減らして減らして減らして生産性を上げてきたのが日本
回りを見ても無くせる業務はもうないでしょ？
はんこ無くすなんて自社だけで出来ることではないし、現場でどうにかできるものでもない
>>640
お前さんの見ているところに(みつから)ないだけで日本中にいくらでもあるぞ >>640
本当に不要な業務が増え続けてるのが大企業な印象ある
特に腰が重いとこほど
自分は毎日「これ必要ですか？」って言い続けてるよｗ 業務をちゃんと理解していれば、不要なものは不要と断言できるから、やらなければいい
やらなければならないという事は、知らないだれかが必要としているという事
たとえば二重チェックなど、一見無駄な多重チェックを、責任を持って無くすのは、簡単ではない
年に一回ぐらい数量や品物をまちがえても良いようなおおらかな社会ではない
後始末の手順はあるから、後始末すればいいと考えるのは、ときに信頼を失う
ISOやプライバシーマークに関する手続きは、意味不明なレベルで実効性が無いけど、無くすと商売に差し支えるから、やる
けれども理屈はともかく、責任を持って無くせる業務なら、明日にでも無くそう
自動化と全自動はまた別のもの
それはただの出来損ない
不要だと思いながら、万が一ばかりを考えて業務が増えて行くのが日本企業。
万が一、万が一…
集めたデータも活用しなけりゃ、只のゴミだ。
>>613 あれは単なるウェブパースでRPA ではないでしょ？ 成果物の品質を緩くすれば、日本人はもっと楽に仕事ができる
自分は何もしないのに細かい指摘する阿呆が多すぎなんや
>>644
>やらなければならないという事は、知らないだれかが必要としているという事
皆んなお互いにそう思って仕事が減らないのでは…
何かあった時に責任も取りたくないから、外部コンサルに見直して貰って、
何かあればコンサルのせいに出来るようにしている会社も多いと思う >>648
自分がやったら何日もかかることを、他人にはすぐやれっつーキチガイサイコパス野郎ばっかだからな >>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の話になってんの?
image clickで頑張ったわ
とりあえずこの開発pcならいけたわ
解像度変わると動かなかったりするから気をつけろよｗ
部分最適化大好き全体の見通しが立てられない日本人だから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のスタートボタン押してもらわないとｗ
あとRPAがこけた時の報告
経理のおばちゃんだけどRPA研修受けて出来るようになったよ。
ただ自分でスプリクト?マクロ?を書くメニューはわからん、知識がないから。
エクセル関数と同じで既にあるものを組み合わせて使うのは余裕。
マクロとスプリクトの勉強は事足りててやんない可能性もあるけど興味は出たよ、こういうマクロ欲しいから教えてって言えるシステムの優しいお兄さんが社内にいれば良いんだけどねー、別に全部一人で出来る必要ないじゃない。
できるとうまくできるの差は天と地ほどあって
できるだけでシステムをせっせと拡張していくと後で困ることになる
事務ババア好きやで
エロいし巨乳だし時々お菓子くれるから
知識ないって開き直るなら手をつけないでもらえますかね？
どうせそれ手に負えなくなってIT部門に転がり込んでくるんで
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点満点の理想的本質的な解決策は今までも取れてなかったわけで、今後も取れる見込みは低いでしょう。
あらゆるＲＰＡは、ただのスクリプトをＧＵＩ形式に変換しただけ
画面構成が変わる、ＷＥＢのデザインが変わる、処理のフローが変わる、例外エラー
には全く対処できない
作業の意味を理解していないから、ちょっとでもエラーが出ると終わり
あくまでも友達の話なんだけど、こんな事が
・海上輸送されてるコンテナ番号から現在の動向を知りたい
・フォワーダーを何社か使ってるのだが、そっちへの依存は避けたい
・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つに一つじゃなくて段階的なものなんやで
やっぱみんなコード書かせろって思いながら使ってんのね
>>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
ねー なんで複雑なシステムを組んでわからなくなるみたいな想定するんだろうか
もちろんそう言うデメリットも生じるだろうけど、基本的な想定としては、１時間くらいかかる単調な繰り返し作業を10分にできます、しかも事務のおばちゃんでも誰でもできます、みたいなもんだと思うんだよな と思ってたらいつの間にか大きな複雑な処理に化けてる
システムってそういうもの
VBとか書いてある時点で地雷だって気付くよねふつうは
VB嫌いではあかんで
VB脳とHaskell脳をすぐに切り替えられるのがプロやっちゅうことやな(ドヤ顔)
気付いたら大きくて複雑な処理に化けるって発想がそもそもおかしい
"定型"業務の自動化なんだから「月末に請求書を自動作成」っていうシナリオを作ったとして
そのシナリオに関しては業務内容が根本的に増えない限りそれ以上変化することないよ
いつの間にか大きな複雑な処理になってるって、RPAの問題じゃなくてワロタ
プロジェクトか管理者の問題じゃん
野良ロボット、野良サーバーが知らない間に増えるのはガバナンスの効いていない駄目な組織やで
駄目な組織は何をやっても駄目、電話と手書きFAXを駆使し書類束を仕事の証として頑張れ
日本人は創意工夫(笑)で仕事のルールを増築していくのが既定路線やから…(震え声
