TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼
テストしにくいコードをテストする方法 その2
C++相談室 part150
米国国防省の標準高等言語エイダ（Ａｄａ）を語れ！
Ruby 初心者スレッド Part 63
Flutterやろうよ！！！
【Delphi】Embarcaderoオッチャ その33【C++ﾋﾞﾙﾀﾞ】
NetBeans Part7
【計測】LabVIEW相談室【制御】
スレを勃てるまでもないC/C++の質問はここで 25 [隔離病棟]
VB.NET質問スレ(Part44)

[RPA]PC自動化技術総合スレ[効率化] Part.3


1 ：
語りましょう。

2 ：
前スレ
[RPA]PC自動化技術総合スレ[効率化] Part.2
https://mevius.2ch.sc/test/read.cgi/tech/1550156285/

3 ：
ASCII.jp：日本のITは20年間進化していない──野口悠紀雄が語る (1/6)
https://ascii.jp/elem/000/000/151/151210/

4 ：
wsh(vbscript,jscript)とuwscでだいたいのWinアプリやWeb入力は自動化できるけど、
この技術でバイトとか出来ないかな？

5 ：
特集・RPAで仕事が変わる： 「幻滅期」は来るのか？ RPAの未来を予言してみる (1/3)
https://www.itmedia.co.jp/news/spv/1904/03/news034.html
> RPAが大きな注目を集めているが、ロボットが当たり前にいる時代の私たちの働き方は将来どうなっていくのか？ 「新しい働き方」について具体的に考えてみたい。
https://image.itmedia.co.jp/l/im/news/articles/1904/03/l_rpa_khai_01.jpg

6 ：
>>4
ランサーズかココナラ辺りでどーぞ

7 ：
wshはいいけどUWSCはサイト死んでるから商売道具にするにはちょっと・・・気持ちはとてもわかる

8 ：
クラウドワークスとかのバイト考えたことあるけど、依頼主のあーでもないこーでもないみたいなムチャぶりに当たるとシンドイとかいう体験談見て萎えたな システム系あるあるかな

9 ：
https://coconala.com/search?keyword=UWSC
腕さえあればそれなりの稼ぎにはなるよ

10 ：
なるほど

11 ：
WSH(VBScript) が出来るなら、Ruby をやれば？

VBScript のスレ主のピッコロ大魔王なんて、
他人の書いた、Rubyコードを見ただけで、書けるようになったほど！

Ruby, Nokogiri, Selenium WebDriver で、スクレイピング・ブラウザの自動操作ができる

Rubyをやれば、jQuery, PowerShell も出来るようになる

12 ：
uipathだけど、作ってる時は上手く回るのに何故か翌月動かすと所々止まっちゃう。。
また同じようにセレクタとかアクティビティ選び直すと動くのに

13 ：
>>12
ページがアップデートされたとかじゃなければページが日付に依存してるんじゃないの？
ログみた？

14 ：
スクレイピング防止に、毎月IDやクラスやフォントを微妙に変えて来るページとか
有るかもしれない

15 ：
期限付きクッキーの期限切れという罠もあるぞ

16 ：
>>12
セレクタの中身見ないと分からんけどウェブサイトならIDが年月日とか連番振られてないかな
そうであれば動的な要素の一つ上を指定して配列の1番目を取るとかの工夫がいるかもね

17 ：
IDやNameが一見意味のない数字の羅列だったら要注意
不変の要素をアンカーにして指定するか諦めて画像指定にするよろし

18 ：
コードとフローチャートの互換性みたいなのあるんかな 既存のExcelマクロとかの資産をRPAに置き換えたいとか 逆に、RPA資産が溜まってるけど、サービス停止とかで別のRPAに移行せざるをえないからいったんコードに変換したいとか
この辺がRPAの特殊性でもあるよね まぁERPと同じといえば同じか

19 ：
12だけど原因はある程度わかっている
マックスウィンドウを入れるの忘れて毎回ウィンドウの大きさが変わってしまうのと、、自分がコントロール上下で拡大縮小をよくやるからなんだ。。

20 ：
>>19
は？

21 ：
そういうとこやぞ

22 ：
すまんな

23 ：
原因わかってるのになんでそれを組み込んで作んねえの？

24 ：
5人くらい釣っておいてすまんなは草

25 ：
こういうトラブルが日常的に発生するのか
情シスは大変だこりゃ

26 ：
もっと酷い人もいるだろうな おばさん「何もしてないのに動かなくなったの！」
まぁ情シスというより周りの若者が見てやれるのもRPAの良いところなんかな

27 ：
こういうトラブルはガチで起こる
ただ今まで何となくメモのようなマニュアル見ながら操作していた作業
エクセルの簡単な集計転機の作業
定期的にダウンロードする作業
がポチで終わっていくのはストレスフリー

今後は3人でやってた仕事を例えば1人に集約してロボット管理とロボットトラブル対応にしたいな

28 ：
>>18
>>27
RPAの前に日本語勉強してくれないか

29 ：
web系ならpyhtonでかなりのことができるね
なお画面

30 ：
>>26
それ見過ごすと徐々に教える方にストレス溜まってくるから良くないよ
なんでこんな簡単なことがわかんねえんだ聞く前に調べろ俺は自分の仕事してえんだよお前の介護職員じゃねえぞってな
中にはそれが嫌になって辞めちゃう人もいる

31 ：
>>14
その程度の変更ならRPAの修正も別のRPAで出来そう

32 ：
>>30
うーん、確かに情シス系のことってパソコンの大先生に負担きがちだよな 仕事の指導とかは既定の上下関係ベースだからそれも仕事のうちと言えるけど、こっちはそうもいかんな １回マクロ作ってあげたら搾取され続けてキレたみたいな話よく見るし

RPAに限らずだけど、この辺のこと上手くやれてるところあるんやろうかね

33 ：
むしろ普通はうまくやってて話題にもならないだけでは
面白おかしい失敗談はよく上がるけどってことね

34 ：
身も蓋もないこと言っちゃうと
成功失敗の前に話題になる程導入されてないんだろな

35 ：
導入はされてるんじゃない?
使われてないだけで。

36 ：
Excelマクロの運用について見てた時、「明らかにしたために搾取された人」と「搾取されるのを見越して隠してる人」の２大派閥だったんもんで、なかなか上手く運用できないもんだねとは思ったんだよな うちの会社もそうだし
まぁ多くは上手くいってるのかもしれないけどね それはわからんな

37 ：
時間が掛かろうが楽な仕事をやりたい奴にとっては大きなお世話だから
導入に反対されても不思議はない

38 ：
ググれない事務BBAにはおまえのマグナムで云うこと聞かすんやで

39 ：
自然会話AI「commubo」 テレビショッピングデモ
https://www.youtube.com/watch?v=4GMXcpLciV0

和製“Google Duplex”？ ソフトフロント社の「commubo」
https://ledge.ai/aiexpo-2019-day-2/
https://www.youtube.com/watch?v=VyTtZRa_Oq8

これはRPAと呼ぶのだろうか

40 ：
常識で考えろカス

41 ：
こういうのは成功例しか載せないからなぁ・・・・

42 ：
導入したけど使えなくて毎年2000万円ムダにしてる、
とかそういう話を反面教師として聴きたいよな

43 ：
それな

44 ：
それはRPAに限らずSAPとかでもあるな
運営側の問題で、ツールのせいじゃないけどな

45 ：
リアルな話は聞きたいな 基幹システムは導入したら使わざるを得ないけど、RPAは使わなくても済むからな

46 ：
導入実績を報告せよ
費用対効果を検証せよ
なに～！使ってないだとぉ？

47 ：
やる気満々だけど、普通の業務こなしながら時間が取れない

48 ：
それはRPA導入以前にブラック体質どうにかしないとな
日でも週でもいいけど導入の為の時間作る事も出来ないくらい仕事きついのは異常だと思うよ
本人が要領悪いのか会社が悪いのかは知らないが…

49 ：
素人おばちゃんレベルの人が楽々導入できるならブラックでも片手間でできるやろ？

50 ：
ブラックに片手間と言う余裕はないんやで…

51 ：
導入研修を半日できればあとは使いながら覚えるでいけるけどなあ
初めのうちは外部の詳しいとこにサポートしてもらいながらやるのが現実的かな

52 ：
いや素人でも直感で簡単にすぐ作れるのが売りなんだろ？
そこで有識者に頼ったら意味ないじゃん

53 ：
直感でできなくはないが導入期には有識者つけてたほうが統制取れて後々楽なんだよ
ERPでもSFAでもCRMでも同じ話

54 ：
いくら簡単とはいえ初期投資が必要だからなー 学習時間、作成時間、やる気、労力など
恒常的に忙しくて疲弊してるところは難しいかもね 逆に閑散期と繁忙期がハッキリしてるところは向いてるんだろう

55 ：
sikulix
をちょっと触ってみたけど、これはええね
Jythonだから今までのPython資産(Excel読み書きとかWebアクセスとかftp転送とかDBとかemailとか…)がばっちり使える
JRubyもあるのでRuby凶徒もニッコリ
GUI自動化部分だけこれでなんとかすればいい、シンプル

56 ：
UWSCで良いだろ。

57 ：
>>55
画像認識ベースか…
ちょっと残念

58 ：
>>48
会社やろ。

59 ：
UWSCがOSSだったらなあ…ほんと罪深いわ

60 ：
>>59
え？
あるから使うけど
何かできない処理ある？

61 ：
画像認識って、社内でウインドウのデザインを統一しておかないと難しいんじゃないの?
クラシックだろうがAeroの派手なやつだろうが、関係なく動いたら凄いけど。

62 ：
>>60
まともな企業のISMS的にはもうUWSCの導入はさせてもらえない、って話じゃね

63 ：
>>61
sikulix とか画像認識系は、どのPCで動かすのかガチガチに決めて使うものだわな
デスクトップのアイコンダブルクリック…がある場合
ショートカットの青矢印(圧縮されてます表示)あるじゃない、
あれの有り無しとかですぐ動かなくなる
壁紙変えれば脂肪だし

64 ：
>>63
デスクトップのショートカットでしか起動できない超特殊なアプリでもなければopenAppでよくね

>>61
sikuliに限らずWindowsのバージョン跨がれるとちょっと辛いから、解像度やテーマは最初にアジャストするようシナリオ組んだ方がいい
openCVなので類似度設定で多少は自動で認識もしてくれるけど、アイコンはともかくテキスト周りはフォントが違うと認識できない事も多い(OCR使う手も無くはない)

普段使いまで統一しなくていいけどスクリプト作成の時は同様の環境に変更してからとか、いっそ仮想マシンでやると安定度高くなる

65 ：
聞くからにつらそう。なんでUiPathがやってるみたいな仕組み入れないんだろ？
そんな実装大変な技術なの？

66 ：
画像認識は課題が多いなあ
そこまでやるなら素直にAppium弄ったほうが確度高いし配布考えてもやりやすそう

67 ：
>>65
UiPathのどの仕組みのこと？

68 ：
>>65
実装大変なのもあるが、別にRPA用のソフトじゃないから必要ないのでは？
何でも出来るではなく画像認識でPC操作しようぜってコンセプトでしかない

余談だけどこのスレも別にRPA専スレではない

69 ：
役所と銀行はIT素人おじさんばかりやし、この手のツールは導入し易い
(使い易いとは云ってない)

70 ：
ベンダーロックインさせて身うごきとれなくしてから
乾涸びるまで絞り取るみたいな経営戦略はありかもしれないね
技術者の良心が心配だが嵌ればウマイ

71 ：
>>67
UiPathの仕組みは知らんが、UIAutomationか、ウィンドウハンドル+SendMessage系か、画像認識+SendMessage系以外に仕組みって無いと思うんだが。
UIAutomationはAccessibilityの上位互換だよな。

72 ：
安定させようとしたらサーバー化、仮想化が必須だな
画像認識系は特にそうだし画像認識系以外でもアプリの依存性を事務員全員のホスト直上で管理しようとするとすごく大変

73 ：
UiPathで出来ることをまとめて、買い切りでC#のサンプルとライブラリで売る
なんて商売してるところないすかね

74 ：
>>70
良心は兎も角、干からびるまでやって成果上がらない無能ベンダーと誹られるがうまいかそれ？

75 ：
>>74
長期にわたって安定した収入源をキープできるのは美味しい
今後は不況が加速するからなおさらね

76 ：
画像認識技術の限界を見ると、これでよく自動運転の車なんか作る気になるよな、と思う。
道路にレール引いた方が早いんじゃないの。

77 ：
>>76
自動運転において画像認識がメインってわけじゃないから心配すんな
カメラによる画像認識は天候とか夜間にどうしても弱いのと解析が高コストだから、ミリ波（レーダー）とか、レーザー測距が主に使われる
ちなみに道路にレールは工事大変だから難しいけど磁気マーカーを埋め込んで誘導する実験は日本でもやってるね

78 ：
>>76
画像認識で50m先の交差点を認識するのは不可能だよな？
どうやって人間が交差点を判別してるのか画像だけではわからない
頼りのGPSもラグが秒単位であるなら車の運転なんかには全く使い物にならない
道路自体に仕組みを入れる必要がある
その周辺のデータを絶えずダウンロードできる仕組みが必要
500m何秒で走行して進行方向2km程度の情報を何秒で収集できるか？
全てにおいて足りてない
基本的なスピードが全く足りない

79 ：
>>77
俺は高速道路をライントレース？で走ってくれる程度でいいんだが

80 ：
>>76
GPSとかの測位システム使うのもアリだし
車同士で通信すればさらに改善できるだろう
前の車から歩行者情報をもらえば
後ろの車がカメラで直接歩行者を見られなくても
事故を回避できる

81 ：
>>78
5Gだと走行中の新幹線と通信できるとか
300km/hとかなら可能じゃね

交差点にカメラとかセンサーつければ良い
Nシステムとか既にあるし

82 ：
>>81
最大速度だけ速い系だろ？
アクセススピードまで上がった経験ないし
使い方は考える必要あると思うな

83 ：
RPAってパズルみたいで、作る分にはちょっと面白いな。

84 ：
三ヵ月に一回、スタッフの情報が最新か確認してね！とか
ワーニング画面出てくるソフトあってクッソイライラするわ

85 ：
ウォーニング画面、な。
warnをワーンと読む奴はworld warをウォールド ワーって発音してんのか？ｗｗｗ

86 ：
書くときはwarning　または ワーニング またはウォーニング
発音は　わーにんぐ

warm と書いて　ウォーム(うぉーむ、暖かい)
worm と書いて　ワーム(わあぁぁぁむ、むしだあぁぁぁ)

英語は不合理な言語として有名

87 ：
>>85
こういうこと言うやつには「ｗ」ってなんて発音してんですかって聞いてみたい

88 ：
>>87
すたーわーず？

89 ：
アップルのことアポーとか書いちゃうのかな？

90 ：
アポーといえばジャイアント馬場

91 ：
>>82
まだ5Gは日本ではサービスされてないから経験ないのはそうだろうね

92 ：
>>91
そういう期待させておいていつもクソ

93 ：
>>79
ほんとこれ
なぜ一般道までやろうとするんだろ
高速自動運転にすれば渋滞も減るし観光地も潤うだろうに

94 ：
>>92
実験済みだから今の4Gよりは良くなる
基地局とかがちゃんとあればだけど
地方はもっと時間かかるかもね

95 ：
GPSは準天頂衛星システムで精度が数センチに向上する

96 ：
いい加減スレチ

97 ：
自動車の自動化スレ

98 ：
RPA女子は誰得か
https://www.orangeitems.com/entry/2019/04/10/182952

99 ：
>>86
最近のアメリカの若者言葉だと、スペルを発音に合わせて変えるみたいだね。

100 ：
>>77
RPAに複合技があってもいいかもな。
人間の視線を追うとか。

101 ：
画面OCR機能を自前プログラムに組み込みたい場合、
やっぱTesseractがいいかな？
スクリーンショット→特定の文字列検出、座標取得してその右何ピクセルかにマウス移動してクリック、したい

102 ：
Microsoft OCRでいいんじゃね
ただtesseractもだけど座標取得するには大分手を加え必要があってイマイチその用途にOCRは向いてないと思うが…

103 ：
>>102
Google Cloud Visionあたりが簡単で良いかもと思った
画像渡すとJSONでずらずらと、文字列+座標戻ってくる
有料だけど月に1000枚までフリー、その後1000枚で$1.5だから安いし
トレーニングとか面倒ですからな

104 ：
無人ではなくログインユーザーが動かす点とUiPathみたいなツールを使う点が
RPAと無人スケジュール起動のバッチ処理の違いということでいいのかな？

バッチ処理のことをRPAと呼ぶ人が増えてきて違和感を感じる。
それとも、バッチ処理やらVBAもRPAに含まれるでいいのか？

105 ：
バッチ処理をRPAという人を見たことないのでちょっと分からんけど、単一のバッチをRPAというなら違和感はある

本来の意味だと何らかのプロセスの一形態としてバッチ処理があって、その他のプロセスを組み合わせて自動化するのがRPAってイメージ
だからそのバッチをRPAという人は単一のバッチじゃなくて組み合わせたものを言っているのでは？

実行ユーザーやツールはあんまり関係ないと思う

106 ：
UiPathやWinActorがわずかでも絡んでいればRPAで良いと思う。
なぜなら、(この板ではなく) 世間一般の理解では、UiPathやWinActorがRPAである、として列挙するのが定義だから。
単純化すると、RPAは商品カテゴリーの名前

画面も含めて同じ動作をするPython + 各種Libで作っても、世間一般ではRPAと言わないと思う。

>>104さん>>105さんが、現に困っているうそ、おおげさ、まぎらわしいを例示してくだされば
すぐに引っ込めます。

107 ：
システムがRPA入れてくれない。Sさんケチすぎる。

108 ：
>>101-103
OCRってRPAの用途としてよく例に上がるけど、環境が実用の域に達してない

GoogleやMSは日本語に弱いし、
国内ベンチャーのOCRは利用料が高額でコスト面でパートのおばちゃんに負ける

109 ：
>>105 >>106
ここで意図しているバッチ処理というのは、
自動化した処理の流れをまとめた仕組みのことです。
C#で実装した.exeやExcelVBAでメール送信するといったものです。

RPAツールを使う自動化した仕組みのことをRPAと呼ぶで認識合ってると思います。

RPAツールのいいところは本来相性の悪いOffice製品と他のツール

110 ：
途中で書き込んでしまいました。

互換性のない他のツール(アプリケーション)でも画像認識で無理やり自動化した処理に仕立て上げられるできるところだと思います。

表面上同じ自動化でもPythonやWindowsのbatなどを組み合わせた既存の仕組みのみでRPAツール無しの自動化はRPAではないということで納得しました。

111 ：
RPA製品のシナリオ実行が世間で言うRPAだから

112 ：
ロボットは人間の代替
APIではない、プログラムから呼び出すことを想定していないヒューマンインターフェイスを操作するプログラムをRPAと言うんだよ
それ以外はなんの特徴もない普通のプログラムだ

113 ：
>>108
Google Cloud Visionは日本語でも精度高いですよ
嘘つかないでくださいね

114 ：
手書きもOK？　＞Google Cloud Vision

115 ：
>>114
手書きは英語しか今のところ無理

116 ：
>>109-110
うーん、まぁたかが2chの1意見なので無視してくれてもいいけどRPAツールの介在はあんま関係ないと自分は思ってるよ
例えばVBAだって実はExcel機能とVB言語によるプロセスオートメーションなのよね、それをボタン付けて自動運転させたらRPAでしょう
RPAツールはそういったプロセス同士の繋ぎに特化したツールで確かにそれで作ったものは概ねRPAだけどさ

117 ：
>>116
それは単なるguiツールだ

118 ：
プロセス同士の繋ぎに特化した物をRPAというならbashやpowershellもRPAになってしまうな

119 ：
>>118
だからそれで何が悪いのと言ってるんだけど…
拡張子とか決まったフォーマットを指す言葉じゃないんだから手段と目的がRPA的ならRPAと呼べばいいじゃん

別に自分だって単にExcelのボタン押したらCSV読み込むのをRPAと言ってもいいとまで言ってなくて、
読み込んだものを加工して別フォーマットに落とし込んで書き出したりするならRPAと言えるでしょってことなんだけど伝わってる？

120 ：
>>119
＞読み込んだものを加工して別フォーマットに落とし込んで書き出したりするならRPAと言えるでしょってことなんだけど伝わってる？

いや言わねーし伝わらねーよ
プログラム入門とかでやる奴じゃん
めちゃくちゃ普通の古典的なコンソールプログラムじゃん

121 ：
>>119
なんでもかんでもRPAと言ってしまうと
ありとあらゆるコンピュータ処理がRPAになってしまう
COBOLやCのアプリケーションでも自動化できるので、COBOLやCもRPAツールで良いのかい？

年次のバッチでのBS/PLの作成は、昔は経理の　現場で手でやったのが自動化されたからRPA
月次の給与の支払いも、昔は手渡しだったのが自動で振り込みなったからRPA
御承知のようにまだ他にもたくさんあるけど、これらを全部RPAで良いのかい？

自分は全部がRPAだといわれると、ちょっと困る。話が通じないから。

122 ：
>>120
まぁ例が悪かったかも、あるフォルダのCSVまとめて読んでExcel帳票に書き出すなんてRPAシナリオとしてよくあるでしょ
それをVBAで実現したってRPAツールの機能使ったっていいじゃんって言いたいだけ

伝わらないならしょうがない、君とは話ができないようだ

>>121
だから全部がじゃなくてRPA目的で作られたらだっつーに、ちゃんと読んでくれよ
逆にRPAを目的として作ってもRPAツールを使わなかったらRPAじゃありませんっておかしいだろ？ｗ

そもそもRPAって言葉が後付けなのになんで専用（？）ツールじゃなきゃRPAじゃないのさ
例で挙げられたものは今だって専用にオフコンまで作りこんだらRPAとは言わないだろうけど、
Excelやらブラウザ自動実行の仕組みで作ったらRPAって言われるでしょうよ

123 ：
>>122
おめーの言い分は「RPA目的」がフワッフワで意味わからねーんだよ
それじゃあ「俺様がRPAと思えばRPA!」と言ってるのと大差ないぞ？

124 ：
ベンダー側にも責任がある
ユーザーインターフェイスの操作がRPAの本質なんだがベンダーとしては便乗して儲けたい
エクセルの読み取りだのRest API呼ぶだけ、あげく単なるグラフィカルプログラミング環境みたいなものまでひとまとめにしてRPAという名前でパッケージングしてしまった

125 ：
>>123
少しニュアンスが違う、ただ「RPA目的」が曖昧なのはその通り（だってRPAが曖昧な後付け造語だから）

>「俺様がRPAと思えばRPA!」
ではなくて、「人様がRPAというものをRPAではない！」と言う必要はなくない？　って言いたいだけ

自分の主旨は曖昧だったりそれっぽいものを全て「RPAと言え（呼べ）」じゃなくて「RPAって言ってもいい」ってだけ
最初から言ってるけど全てのスクリプトやらバッチやらがRPAっていうのは自分だって違和感あるし違うと思ってる
ただ話しの流れとして業務なり作業の自動化の一環として出てきたなら話しは通じるし困らないよねって
後からRPAについての認識合わせなりはご自由にと思うけど、その場で「いや何それRPAじゃないじゃん」とか言って話し止めるほどじゃない

126 ：
>>122
＞だから全部がじゃなくてRPA目的で作られたらだっつーに、ちゃんと読んでくれよ

この一文は、RPA目的の何かをCOBOLで作ったら、COMOLもRPAツールであることを認めている。

127 ：
126　タイプミス COMOLもRPAツール　→　COBOLもRPAツール

ところで、自分がお勧めの着地点としては、
RPAであるかどうかは、造語したベンダーの言い分に従うようにするのが一番良い。

ユーザー側で「RPAである」「RPAではない」と議論したところで、
何かが解決するかというと、二つの例外を除いてなにも解決しない。

例外の一つは、ベンダーに「これからはRPAです」といわせれば予算が取りやすい。
もう一つは、「RPAだから簡単です」と言わせれば、システム屋以外の人の興味を引きやすいということ。

128 ：
RPAなんてただのバズワードなんだし定義について追求しても意味ないよ
そもそも「日常業務を自動化できるツール」くらいのイメージ持たせるのが目的だし
AIやらIoTと一緒の使われ方

129 ：
いやRPA製品使わないのはRPAとは普通言わないでしょ

130 ：
画面操作で業務プロセスをオートメーションすればええんやなかろうか
たとえばPythonしか使ってなくても

131 ：
人に代わってユーザーインターフェイスを操作するプログラムがRPA

132 ：
rpa否定するのってos必要ないみたいな感じ？
マウス必要ないみたいな感じかな？

133 ：
>>132
？？？？

意味わかんないから詳しく説明を頼む

134 ：
RPAツールに必要不可欠な機能は？
1.プロセスを実行できること
2.データをそのプロセスに渡せること
3.その結果を受け取れること
4.結果によって処理を分岐できること
くらい？

画像認識とかはプロセス実行や結果受取の手段の一つだよな

上の4つを備えてたらRPAツールじゃね？

135 ：
>>129
RPA製品って何？
OSSでもRPA製品なんじゃね？

136 ：
1のプロセス実行は、自分ではなくて独立に開発されたアプリとかOSのサービスとかに限定されるだろうな

ここがRPAかそうじゃないかの大きな違いだと思う

自前で作ったものなら単なる機能拡張でしかない

137 ：
>>134
ただのプログラムじゃん

138 ：
ソフトウェアロボットによる業務自動化

それ以上でもそれ以下でもない
定義なんて存在しない

139 ：
そもそも最初聞いた時ロボティックに違和感があったなぁ ロボ感ないやろと 何がどうバズったんやろう

140 ：
>>134
それって excel のマクロ記録で済む話なのでは？

141 ：
>>134
君が挙げた特徴はあらゆる手続き型プログラムの定義にもあてはまる
抽象化のトレーニングをした方がいい

狭義のRPAの特徴としては、GUI操作を介する定型処理をエミュレートすることで人間によるデータ処理を代替する効果をもたらす業務ソフトウェアとしてパッケージされたもの、とかでいいんじゃないの

142 ：
>>139
コグニティブ技術や機械学習とセットにしてRPAが宣伝されてたから、世間的にはペッパー君みたいなのが業務をやるんだと思われたんじゃね
案の定文系の論壇()ではシンギュラリティがどうのとかいう頓珍漢な言説が流行ったし

143 ：
>>135
だから普通はシナリオ作成していくツールの事だろ
おまえは何が言いたいのか
世間一般とズレた事言っても意味ねーわ

144 ：
突き詰めて考えていくと、ヒュマンインターフェースをプログラムから呼び出しやすいAPIにラップすること、がRPAのエッセンスだ
このラップ作業を支援するツール群と、全く関係ないツール群を抱き合わせでパッケージングしたものがRPA製品となる

145 ：
>>143
シナリオを作成するツールはRPAではない
RPA製品にシナリオを作成するツールが抱き合わせで同梱されている、と言った方が正確
Windowsワークフローはシナリオ(ワークフロー)を作成できるがそれだけではRPA製品とは言えない

146 ：
>>141
それを実現するのに必要な機能は？

147 ：
>>143
シナリオ作成でよければパワポでもいいだろ

148 ：
>>143
その作ったシナリオを自動的に実行する機能の方に価値を認める人が多いだろ

149 ：
＞シナリオを作成するツールはRPAではない
揚げ足
シナリオを作成する機能はRPAに不可欠だが、作成するツールだけではRPAではない
承
プロトタイピングツールというのが一世風靡
転
現実が先にあるのがRPA、これから作るのがプロトタイピングツール
結
組み合わせ自在になると玄人受けも狙える（UNIXとウィンドウシステムみたいな）

150 ：
>>147
そういうくだらな揚げ足取りするレベルかｗ
顔真っ赤だなｗ

151 ：
>>147
おまえさー
俺は一般論で言ってるのにパワポはねーだろ
アホじゃねーのｗｗ

152 ：
>>149
シナリオ作成ツールは不可欠ではないね
普通のプログラムやスクリプトでほとんど事足りるし
ロングランのジョブ管理も最近はyamlを手書きする方式が主流になってしまった
難解なXMLや独自形式のデータファイルでシナリオを表現するタイプだと入力補助としてツールが欲しくなるがそういうのは衰退傾向にある
だからわざわざツールを導入してまでシナリオを書く必要性はない
もちろん必要性がないだけであってやりたけりゃやってもいいけど



組み合わせ自在のツールは実はとっくに存在してて
それは普通のプログラム言語やスクリプト言語などと呼ばれて世界中で使われてる
例えばpowershellやbashとかね

153 ：
>>142
どもども ペッパーくんの例はわかりやすいね
ペッパーくん的な感じで人間(の単純作業)の代用してくれますよ、っていうイメージ戦略が生きたんかなと思った

本質的にはプログラム全般がそういう性質を持ちえるわけで、今更何言ってんねんっていうツッコミがここでも多いけど、往々にして素人に響くのはイメージなんだろうね

あとは、素人の持つシステムのイメージって専門業務に特化した基幹システムだから、幅広い単純作業をペッパーくんにやらせるようにシステム化できるっていう発想も効いたのかもなー

154 ：
新しい技術でもなんでもないただのGUI自動操作ツールを
"なんか凄そう"に聞こえさせるためベンダーによって造られた言葉がRPA
日本で流行らせたのはRPAテクノロジーズ社なんだし同社HPに乗ってる説明がRPAの定義でいいじゃん
もっとも、バズワードにしっかりした定義を求めるのなんてナンセンスだが

155 ：
それが何なのか、既存のアイデアと何が違うのか、違いがどんなメリットデメリットを生むのか、突き詰めていかないとダメだ
自分が何に金を払っているのかも理解しようとせずにぼったくられるとかねーわ

156 ：
ヒューマンインターフェイスしか無いプログラムと連携して情報処理を実現できる点
これがRPAの本質かな

この領域では紙帳票を扱えるようになったら更に有益なものになるだろうな
カメラとかで認識して情報を取り込む→サイバー領域で情報処理→現実世界にフィードバック
DXだな

157 ：
>>156
＞カメラとかで認識して情報を取り込む→サイバー領域で情報処理→現実世界にフィードバック
ここ20～30年でその能力、特に「情報処理」」の部分で革命的な進歩があったのですか？特に事物を判断する能力、が格段に進歩したのでしょうか？最終判断はいまだに人間がするものだとばかり思っていましたが

158 ：
>>157
車の自動ブレーキとか顔認証とか

159 ：
>>151
お前の小物臭さがハンパないな

160 ：
>>158
アンチロックブレーキとかは有名でしたね…
海外では監視カメラで評価ポイントが上下する（アニメにそんなのがありましたね…）というのもありえるらしいですから、どこも（内心の自由を一部放棄して）遅かれ早かれそうなるのか…
ブルームバーグですが真に受けちゃっていいのかな？https://www.bloomberg.co.jp/news/articles/2019-02-25/PNBKQ26TTDS901

161 ：
QZって宿題スレのあのQZ?

162 ：
>>161
宿題スレは潰れて今はお題スレにいますが、最近のお題は難しくってもう無理ですね…

163 ：
QZってプロのプログラマだったの？
RPAで食ってるの？

164 ：
>>156
すでにAI-OCRが

165 ：
過疎スレ

166 ：
オワコン？

167 ：
もうあらかた自動化できそうな作業は自動化し終わっちゃったんだろ？

168 ：
仮想スレ

169 ：
俺の代わりに通勤して給料貰ってくるロボ作れや

170 ：
仮装スレ

171 ：
>>156
これ入れようとしてる
https://www.konicaminolta.com/jp-ja/rbpo/index.html
具体的には各月の決まりきった請求書を自動で読み込んで自動で費目付けて自動で支払いする
経理からうざいおばちゃんを人員削減するw

172 ：
>>169
そのロボ高そう

173 ：
はよシンギュラリティで労働から解放されたい。
最近シンギュラリティってあんま聞かないけど

174 ：
>>173
超AIの行動規範は犬の本能をベースにすべき
「よーしよしよしよし偉いねーいいこいいこ」
と褒めると張り切ってウレションしちゃう系ね、
猫ベースだと人間に無関心な奴が発生する可能性がある

175 ：
応用情報処理技術者試験にも出ちゃうRPA

176 ：
Pythonでデスクトップ常駐型の自動化支援ツール作ろうとしてるんだが無謀？
大人しくC#使った方が良さげかな

177 ：
なんでわざわざPython使いたいん？

178 ：
特徴とメリットは？

179 ：
C#俺は好きだけどね。
Pythonは型がコードに明記してないのがちょっとヤダ。

180 ：
明記すればいいじゃん

181 ：
不正送金や支払先改ざんを引き起こす：
RPAで深刻化、仕事の手順を勝手に変える「ビジネスプロセス詐欺」（BPC）とは？
企業の支払いフローを改ざんし不正送金させる「ビジネスプロセス詐欺」（BPC）のリスクが、ロボティックプロセスオートメーション（RPA）ツールの普及とともに増加する恐れがある。具体的な対策は何だろうか。
https://techtarget.itmedia.co.jp/tt/spv/1904/16/news04.html

182 ：
WinActorを導入した弊社、ソフト専用のSEも動員されてるんだけど他もそんな感じなんですかね…

これって非エンジニアがちょっとした作業を自動化できるのがメリットなんじゃないのって静観してたんだけど
他のことしてたエンジニアが非エンジニアのために余計に工数取られてる感がするんだよなぁ

183 ：
コードなら吸う行で済む処理が画面でガチャガチャだからむしろ効率下がるよな
メンテナンス性も悪いし

184 ：
RPAが流行するとプロセスを改変する攻撃が広がるという罠
https://www.orangeitems.com/entry/2019/04/23/102025

185 ：
>>182
特定の製品に限った話ではないけど本職のエンジニアだったらRPAよりコードを書いたほうが楽だしコスパも良いと思う
だからRPAをやるなら最期まで本職に頼らず自分たちでやりきるっていう覚悟が必要
エンジニアからしたら要件にプログラミングより扱いにくいRPAが入ってるってわかった時点で大幅に見積もりを積み上げざるを得ない

186 ：
RPAを入れることが目標になってる弊社は…
馬鹿に音頭取らせるなよ

187 ：
RPA導入が目的化してると普通にベンダロックインされるか低ROIのゴミになるかして終わる

188 ：
なんもかんもRPA導入を検討されてしまうほど情シスに発言力がないのが悪い
導入を阻止できたところで情シスに予算は降りてこねーよ

189 ：
RPAの定義とはなにか
既存技術との違い、メリット、デメリット
突き詰めて考えないから、簡単にカモられる

190 ：
うんこみたいな単純入力作業がなくなるならいいことだと思うよ

191 ：
>>185
俺自身はマじゃないけど、簡単なマクロや自動化スクリプトくらいは従来から組んでたから、メリットなさそうだし色んな理由をつけてRPAからは逃げたｗ

言うとおり本職が使わされるRPAって意味あんの？
って思うし導入が目的感出てしんどいなぁって思うます。
似たような境遇の人、どう無能な上に対して対処してんのかなーってのが気になる

192 ：
>>186
うちもそんな感じ
RPAに社運をかけるとか言い出す始末

193 ：
君自身が作業は自動化完了してると思ってるのならその無能な上司は君のアウトプットに満足していない 、作業が多くて手が回っていないと思われてるってことだろ

君自身じゃなくて部全体の話かもしれんが

194 ：
>>193
>>191じゃ無いけど、たぶん上司は知らないんだろう
今どの程度まで自動化しているのかを。
普通、上司は中については興味が無い。
外から流行りで聞こえてくる耳障りの良い話には興味が有るけど。

195 ：
RPAに社運をかけるっ！(ｷﾘｯ

196 ：
「そのRPA、DXの足を引っ張ってない？」――企業考えるべき現実的な組み合わせとは
https://www.itmedia.co.jp/enterprise/spv/1904/24/news003.html
> 「RPA（Robotics Process Automation）」は、うまく活用しなければ、「デジタルトランスフォーメーション（DX）」の足を引っ張ることになりかねません。RPAとDXを理想的な形で推進するために注意すべきポイントとは？　現状の問題を洗い出しつつ、考察してみしょう。

197 ：
仕事の量や内容や方法が全社的に可視化されてて、かつ、ガバナンスがしっかりしてる、という理想的な状況では最適解はRPA導入じゃないのかもしれんね
まぁでも現実はそんな会社は少ないだろうしな

198 ：
>>194
売る方としてはありがたい
搾らせて頂きます

199 ：
ガバナンスが効いてるならRPAより普通にシステム化した方がいい
ガバナンスが効いてないならRPAは破滅への片道切符

200 ：
PRAみたいにパパっと組めるのが意外と生産性の本質なんだぜ？
Perlとか

201 ：
即興のワンライナーとか使い捨てのスクリプトの代替品って立ち位置なら、まあアリかな

202 ：
>>198
初期投資代だけで勘弁してクレメンス

203 ：
>>182
最初は説明が必要でしょ。応用は自分で出来るはず

204 ：
保守担当が動員されるのはまだ解るが、
ソフト屋がRPAロボの作成をさせられるのは本末転倒過ぎる。
8割の作業を現場で完結させられないなら導入すべきではない

205 ：
自分で組んでいかないと使いこなせないままになるね。
教育する時間試行錯誤する時間も与えず、RPAで仕事が減ったら、誰か首切られるんじゃない？
それが会社の真の目的なら怖いね。

206 ：
>>204
「Code Invokeだけやぞ？他は頑張れや」
で行けるならいいと思うのよね
でも実際はあっちこっち教えて！わからないの！てなるよね

207 ：
>>205
経産省も終身雇用はもう終わりって見解らしい
だからこれから先はガンガン首切られていくんだろうね

208 ：
ぶっちゃけ、自動化して美味しい業務ってそんなにたくさんあるわけじゃないから
めぼしいの一回作ったらあとは保守だけみたいな感じじゃない？

209 ：
ちょっと調べてみた
組み込みの西暦和暦変換機能が無いらしい
RPAユーザーが自力でライブラリを使えるはずも、作れるはずも無いので別にいいのかな

WINACTOR
TOP > ユーザーフォーラム > 和暦を西暦に変換するには？
https://winactor.com/questions/question/%E3%80%90%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%80%91%E8%A5%BF%E6%9A%A6%E3%81%8B%E3%82%89%E5%92%8C%E6%9A%A6%E5%A4%89%E6%8F%9B%EF%BC%88%E6%97%A2%E5%AD%98%E3%81%AE%E3%83%8E%E3%83%BC%E3%83%89%E3%81%A8/?order_by=voted

UiPath
ソフトウェアの新元号(令和)対応について
https://www.uipath.com/ja/resources/knowledge-base/2019-04-02

210 ：
ドトネトが対応したらUIPathも対応できそうなもんだけどな？
そんな甘くないのか

211 ：
そうか？ 少なくとも公務員系のうちの会社は山ほどありそう まぁまだRPAなんて話にはなってないんだけどね

申請書のExcelからシステムへの転記(履歴書とか口座とか)
申請書のExcelが指定のルールで記載されてるかのチェック(記載漏れだったり特定の文言が必要だったり)
色んな相手にメール送信(採用結果とか審査結果とか)

212 ：
>>210
ああ、ごめん
変換する部分を一人ひとりがごりごり書く必要があるという意味　>>209

UiPathは.Netを呼び出してごりごり書く方法が紹介されているから
＞＞【できるUiPath】変数とインスタンスを使って西暦を和暦に変更しよう (URL省略)
一度ごりごり書けば、変換部分に限っては修正不要

WinActorは呼び出さずに、自力で判定をごりごり書く方法を紹介している　>>209のリンク先

213 ：
ここでもWinActorとUiPathの差が如実に表れてしまったか。

214 ：
.Netライブラリが使えるのは正直でかいよな。

215 ：
Microsoftのおかげだな
WWFという基盤が優秀だった

216 ：
パンダが何の関係が？

217 ：
【金融】三菱UFJ、本部人員を半減　営業などに異動
https://egg.2ch.sc/test/read.cgi/bizplus/1556409013/

RPAで6000人が震えてるっぽいな

218 ：
RPAではなく不景気のせいでは？
RPAに6000人消せるほどのパワーは到底ないと思う

219 ：
不景気がRPA導入のきっかけだとして半減が結果でしょ。
記事ではRPA などとなっているから他にもありそうだね、メインはRPAかもしれないけど。

220 ：
もともとなにも仕事してないような遊びの人員がかなり居たはず
終身雇用だと自然とそうなる
そこを無慈悲に切っただけだろう

221 ：
RPAを導入したという建前があれば余剰人材異動させられる
実際に効果があったかどうかは実は重要じゃない

222 ：
そんな建前無くたってできるよ人事異動くらい。

223 ：
>>220
誰も見ない資料作ってるやつとか居るよな

224 ：
>>223
そうそう
意味ない仕事で時間を潰してる人はかなりいる
酷いと一日中ネトゲやってるジジイとかたまにいる
そういうのはRPAが効果を発揮しようがしまいが関係なく単に切り捨てるだけで十分
ただ何もなく切り捨てると反発や外聞がよくないからRPAやAIの効果が出たという建前があると切り捨てやすくなる

225 ：
うちもRPA導入で効果出たことにして異動出してんなぁｗ
ただRPAって業務は残った人に追加で重しになってるけど。

226 ：
事務職なんてもう電話番とお茶だしくらいしか仕事なくなるやろな

227 ：
事務職がホワイトカラーみたいなオーラ出てたけど実質ブルーカラーだからそこが自動化でカットされるだけの話。
工場の現場なら当たり前の話をしてるだけだよ

228 ：
転記や集計なんて現場で言うﾋﾟｯｷﾝｸﾞなんだから、そんなので年収300万以上もらってたﾊﾞﾊﾞｱの存在がおかしいんだわ

229 ：
RPAは経営者にとって本来の用途とは異なる意味で救世主だな

230 ：
>>226
お茶出しは接遇のスペシャリストの秘書を数人雇ってやってもらえばええし電話番はBPOでええ
つまり事務職なんて要らん

231 ：
確かに人減らしや人事異動の建前として経営者に使われるのかもね そうすると困るのは現場の人か

232 ：
なんでも屋の事務員より、一日中、同じことやってる経理やデータ入力に効果的

233 ：
UiPathで今いるページのHTMLを丸ごと変数に取り込むにはどうしたらいいの(画面操作無しで)？

234 ：
そう考えると何でも屋的な総務系が復権するのかね
今だと、総務は雑用で無能(職務分掌上は上だけど)、人事財務は専門性が高くて有能、みたいな印象のようだな うちだけかもしれんけど

235 ：
こんな話題になりがちなのは、何や？

236 ：
効率化すればするほど首になっていく人がいるんやで

237 ：
人手不足()の業種に人的資源()がリリースされるなら良いんじゃね

238 ：
三菱UFJ銀行、本店社員の半数を電気やネットがなくAIでは代用できないシベリアなどの海外へ異動 [422186189]
https://leia.2ch.sc/test/read.cgi/poverty/1556550491/

シベリアへリリースされてるw

239 ：
スレタイ速報やん
ソース読めへんのか

240 ：
俺の務め先みたいに、まず人を抜いてから後を考えるパターンもあるぞ
当然抜かれた直後はガタガタ
職場的にPCでの作業比率が高めだったから自動化で乗りきれたが
その自動化プログラムは業務時間外に俺一人で作らなければならず、苦しい戦いだった

241 ：
>>240
詳しく語られよ

242 ：
なろう、で連載→書籍化→日経BPデビュー

243 ：
1人で乗り切れたのなら240の能力と仕事を判断して上が240だけ残した好采配じゃん

244 ：
無理やり乗り切っちゃうからそれが普通になっちゃうんだよ
>>240はバカの典型

245 ：
本来240のような人が優秀と言われるべきなのにバカとバカに言われるのはかわいそう

246 ：
技術的な能力とマネジメント能力の違いだよ
頑張るのは良いけど次はもっと厳しくなるぞ
それを繰り返して最終的に行き詰まった例を何度も見てるし

247 ：
業務時間外に自動化プログラムを作らせてるのが日本企業の駄目なとこだな

248 ：
「現場の頑張りで上手いこと何とかな～れ♪」に応え続けると上層の脳細胞がどんどん死滅していくのだ
まるで現代日本そのものだな！

249 ：
240みたいに個人の能力に頼り切った綱渡りは他人事じゃないから笑えない
それを見て賞賛するお花畑が居ないだけマシだけど

250 ：
業務時間外系の話だと資格試験の勉強とかどういう扱いなんかね
評価とかビジョンありきの人員削減ならマシなんだろうけどね 240をRPA責任者にして手当出しつつ、○○業務は何時間削減△△業務は何時間削減とかね 実際は無給で役割だけやらすし実態も調べず一律何％減が目標とかだよね

251 ：
経済活動での属人的な曲芸を称賛するお花畑って、考えてみたらまさしくアレじゃん
「世界が称賛する日本の職人さん」みたいなジャンル

252 ：
240以外誰もメンテ出来ないのが容易に想像できる…

253 ：
職人さんがひとりいるだけでもマシだよ
属人性の排除と言い続けて職人さんを消していって誰も居なくなったのが日本のIT業界
素人だけでは世界との戦いにはとてもついていけない

254 ：
>>253
それはそうなんだし俺も同意見なんだけど
問題はその必要とされてる職人技術にお金が支払われないことだよ

同じ給料で高スキルやっちゃうんだから経営者にとっちゃ美味しいだけの話だし、労働者全体で見れば技術を安売りされて損

255 ：
属人性を排除して業務を標準化しよう！→金も人工も時間も掛けたくないし、標準化とかマヂ無理…
→属人性の排除だけやりました！（成し遂げた顔）

256 ：
評価者側に部下の職人芸を評価しなければ転職されたり360度評価等で刺されたりするというプレッシャーがなく、ゆえに職人芸を評価するノウハウが蓄積されてこなかった
労働者側も職人芸が評価されないという理由だけでは転職や苦情申し立てを行うことにメリットを感じられない

こういう糞な状況を生んでるのは正社員解雇規制を前提とした年功序列・終身雇用という腐りきった制度なので、未来永劫こんな状態が通用するとは思わないけどね

257 ：
専門家としてある程度の訓練と経験を積んでれば誰でもできるようにするのが正しい属人性の排除なんだが
猿でもできるようにするのが属人性の排除と考えるバカが多すぎる
そんなもんありえねえのに無理してやろうとするからすぐに破綻する

258 ：
職人界なら職人界で、それ用のメカニズムがあるだろうからねー 徒弟制度、本人のやる気、周囲からの評価や自己肯定感などなど

こういうのの結末はどうなるんだろうね？
・240が辞めた際に崩壊し経営者がしっぺ返しを食らう
・240が辞めてもなんとなく回る
・でも負債を蓄積していつか破綻する 回んねえんだからバケツでウラン掻き混ぜるしかねえぞ的な

259 ：
>>240
残業代もらえよ
ブラック企業だな

260 ：
帰省より帰還。レス遅れて申し訳ない。

まず、仕事は非IT系で実作業とデータ入力が1：3位の割合。
「こうしたら自動化できるのでは？」というアイデアは事業発足時から在るが
俺が作ってしまうといざという時に困るからという事で
上司を通じてしかるべき部署に提案はしていたんだよ。

しかし忙しさを理由に何年経っても進めては貰えず、悶々とした日々を送っている内に
上層部から「●月にこの部署から○人抜け」と指令が下った。
現状でもかなり逼迫した状況だが、上司は「皆で力を合わせれば何とかなる」としか言わず
このままでは地獄が始まるのが目に見えているので仕方なく自分が作る事に。

クライアントPCで修正し易くライブラリが豊富なPythonで組もうとインストール申請をした。
が、またしてもここで大きな壁が出現。
どうも管理上パッケージ販売されたソフトしか許可が下りないらしい。
社内製ソフトなら通り易いという話を聞き、暫し考えた後C++で組むのを決意。

1週間位で何とか作り、自作制御スクリプトで各プロセスを順次作成しつつ現在に至る。

261 ：
皆が言う通り、自分が居なくなった時の事を考えると
個人でやらず社内プロジェクトを立ち上げてやるべきだと思う。
自動化できる部分は他の部署でもたくさんあるから価値はあるはず。
そう提案はしてきたが、どうも効果が薄いと見積もられているみたいだ。

今回自分が作成する時もそうで、業務時間内にやるべく上司に相談したら
「その分他の所を手伝った方がいいだろう？」としか言われなかった。

262 ：
令和終わったら本気出す

263 ：
自分がいなくなった時の事なんて考えなくていいよ。

264 ：
会社は特定の社員が居なくなって困るなら、その社員の待遇を上げてちゃんと確保しないとな

265 ：
>>260 Python のインストール許可が下りないって可愛そうだな。
世界一人気のある言語で有り、Google の3大公用言語の１つで有り、日本の情報処理試験の日本を代表する言語なのにな。
ちなみに情報処理試験の言語は、C Java Python アセンブラのみ。 COBOL が無くなってPython が入った。
つまり日本の公式言語とも言える言語なのに。

AI をやろうとしたらPython 無しではできないぞ。

266 ：
263と同じ事昔言われた
自分が居なくなったら大変なんて考えるのは厚かましい
そんなのは上司が考えればいいし、やればいいって

267 ：
>>261
はやく会社を辞めればいいのに
もっと条件のいい会社はいくらでもあるだろうに
馬鹿の相手をしても時間の無駄だよ

268 ：
計画的にシステムに投資する正常な企業で働きたいよね

269 ：
確かに、本来的には上司がやるべき事だけど、現実的に(日本では？)上司目線で働くことが求められてるようなところあるから、なんかあったら240が責められることになりそうだな
その辺の長期的ないしリスク的な話はどうなんだろ 今うまく行ってるからいいじゃんなのかな 似たような経験あるから気になる

個人的には240は純粋に偉いと思うが、見合った評価が得られてないよなぁ 数百万浮いただろうに特別ボーナスとかすらなく、なんなら「今まで何してたんだ」と責められそうな印象だ(上司が、かな)

270 ：
RPAに話を戻すと、メンテナンスという意味ではやっぱりメリットがありそうって感じかね
C++なりPythonなりで組まれてると(少なくとも240の周りでは)理解不能の魔術みたいなもんだもんな
そういうスキルがある人を雇ったり派遣してもらったり(そういう派遣サービスがあるか知らんが)土壌もなさそうだし

271 ：
c++を採用した意味は正直わからんがpythonならメンテ要員を集めるのは簡単
RPAツール開発者なんて探したってそうそう見つからん
しかし一般的なプログラミング言語なら人材はいくらでもいる
人材というのは当然、教育担当者やトラブル対応できる御用聞きも含まれる

272 ：
>>263
それを考えるのは経営者や管理職の仕事だな

273 ：
自分が退職した後はその会社が倒産しても関係ないだろ
企業年金とかある場合は除いて

274 ：
そんな人材いるん？ うちは非ITのお役所系の事務だけど、基幹システムと手作業の間に大きな断絶があって、せいぜい社員自作VBAツールが社内コンペで見出されていくつか共有されてるだけだな
結果、ルーティンの手作業を気軽に効率化したいみたいなRPAが入る余地は大きいみたいな状況

まぁ人材は存在しているとしてもマッチングなりなんなりが上手くいってないのかもね 情シス部門とかも作れるスキルはあるけど作ろうとするわけではないし 240の会社もそう見えるけど経営層もニーズを自覚してないし

275 ：
>>264
それは経営者としては無能
その人が事故とかで急に亡くなったとしても事業を継続可能にしておく

276 ：
ブラウザ操作の自動化をSelenium+Chromeriverでやってるんだけど
reCaptchaを組み込んでるサイトだと突破できないです
しかも、reCaptchaの認証部分だけでも人力でやってみても開けないサイトがたまにある

reCaptcha作ってるのもChromeDriver作ってるのもGoogleだから
ロボットが動かしてるのがバレバレなんですかね？

なんかいい対処方やアイデアがある方居たら教えてください
Selenium以外の方法でもいいです

277 ：
レスありがとう。
会社は仕事上アレな面が多いけど福利は割と充実していてそれ程ブラックでもないんだよ。
無暗に残業したくないし、できる事はなるべくやっておきたいだけ。

今回C++を選択したのは画像認識やExcel操作等の自作ライブラリが豊富で現在最も早くできるから。
自作スクリプトエンジン+IDEもスクリプト作成時に楽できる様カスタマイズした。
ただ独自言語のままでは他に誰も触れなくなるので、その内PythonやLuaに置き換えるつもり。
上の方も地道に説得する。

RPAのメリットは確かにある。が、高額過ぎて導入を躊躇うケースが多いんじゃないかな。
提案してみたら即却下されたよｗ

278 ：
>>276
https://stackoverflow.com/questions/50466238/how-to-bypass-google-recaptcha-for-testing-using-selenium

279 ：
>>276
アクセス頻度を減らす
画像認識(AI)

つうか、そういう高負荷対策、ロボット対策してるとこはロボットお断りの意思表示をしてるわけだ
だから突破できたとしても、やり過ぎると最悪の場合、業務妨害と言われる可能性もありえる
素直に公式APIを使うか、サイト管理者に問い合わせてクローリング許可の交渉をしたほうがいい

280 ：
>>277
240さんに質問よいですか？
・得られたことは？ ボーナス、査定、周りからの評判など
・失ったことは？ メンテ係を押し付けられた、他にも作らされそう、上司からウザがられたなど
・「皆でやればなんとかなる」と言っていた上司にどう対応しましたか？ 説得、無視など

281 ：
>>271
うちだと逆の印象
RPA開発者やvba書ける事務員はいくらでもいるが、開発経験あるプログラマーは市場にいない

282 ：
>>281
vba事務員はそこそこいるかもだがRPA開発者は居ないよ
RPA自体がマイナーなジャンルだから仕方がないけれど
なのでどうしても素人の教育から始めなければならない

283 ：
>>280
同僚と上司Aからの評判は上々だよ。
実作業だけでなくPCの台数分だけデータ処理が並行して行えるからかなり効率は上がった。
俺の所属しているグループだけで見ても発足当時の10倍は違う。
上司Aは残業が格段に減った。
評価とボーナスは少し色を付けて貰えたかな。
後は上司Bが表彰台に上がって賞金が皆と来客の飲み代に変わった位か。

失った事は無いかな。
俺は仕事の事なら上司でもお構いなしに言うタイプだから元々ウザがられているだろうし。
「皆でやればなんとかなる」と言っていた上司Bは内心そうだと思っている。
俺の所属している所だとプログラミングは仕事の範囲外なので「仕事して欲しい」という気持ちは分かる。
でも「情シスや技術が動いてくれないから仕方ないね」「こういうのは会社の責任」で済ませるのは納得がいかない。
我慢してストレス溜める位なら無理にでも行動した方がマシ。
もちろんコンプライアンス違反にはならない程度にね。

他にも結構作っているよ。
勿論それ等も強引に進めた。
成果は出しているから文句は言われていない。

284 ：
有識者がプログラミング言語を使ったほうが手っ取り早く安く高品質にシステム化できるってことだね

285 ：
>>283
どもども 相応とは言わないけど一応それなりの有形無形の評価はされたのか良かった まぁ240さんはやる気も能力もあるからなんとかなるのかな

286 ：
>>284
それは独裁政治か民主政治かみたいなもんでしょ
天才が独裁するのがベストだけど、天才が常にいる保証はないから安定性を重視するなら民主政治なわけで
ベストエフォートは独裁の方が高いけど、ワーストは民主政治の方が圧倒的に高いみたいな

287 ：
>>286
普通の開発手法で普通のプログラムを組める、広く替えの効く標準的なスキルの人材を雇って作らせるだけじゃないの？
その人が退職したら、いくらでも居る、同等のスキル水準の普通の開発者を雇う
それだけだと思うんだけど、なんで天才とか独裁とかでてくるのか、意味わからん
GoogleやMicrosoftのエンジニアみたいな隔絶したスキルの人材に依存しようって話じゃないんだけど？

288 ：
「文句をブツクサ垂れながらも最終的には従順で低賃金でも働く天才が次も欲しい」

289 ：
俺はC++やC#がメインでPython・Lua・Kotlinは触り位、
JavaScriptやRubyはやった事がないという底辺プログラマだから代わりはいくらでもいるはずなんだけど
非IT系企業には全然入ってこないし、上もどういうのが必要なのか分からないから外注もしない。
そこを何とかしない所だが、平の内はダメかね。

UI操作エミュレーションによる自動化は実行中そのPCが使えないのが痛い。
だからシステム側を改善してバックグラウンドで処理できたら一番いいんだけどな。

290 ：
>>287
非IT経営者がプログラマを入れたらどれだけ改善されるかみたいな視点があると思うわけ？ さらに、仮に1人だけ雇うとして、安定して継続できるの？ 退職後すぐにトラブルが起きたら？

そんな理想的な話をされてもねっていう印象 なんかそういう標準的なスキルセットを持っててドキュメントの作り方とかも統一された人材サービスとかあれば仰る通りのことができていいかもね

291 ：
RPA専用のpc 用意するのが
定石やで

292 ：
一台多く保有するのコストじゃん？

293 ：
負荷が高くないのであれば、virtual PC (仮想マシン)でもいいんじゃね？
ソフトウェアのライセンスの問題が出るかもしれんけど。

294 ：
>>290
プロ雇っても出来ない経営者が素人RPA集団をコントロールして上手に自動化できるわけがないということは理解しといたほうがいい
RPAは魔法のツールじゃないぞ

295 ：
>>294
そんなこと言ってないんだけどね RPA反対派は人の視点に立てない人が多いのが勿体ないね まぁ話ができないなら失礼します じゃ

296 ：
RPAがどこまでできるのか分からないけど
運行費や実行速度を考えるとやはり中間解としか思えないな。
その金でシステムの改善をした方が結果的に安くなるのでは?

各製品の情報をExcelワークシートに入力して統計処理をする作業があるんだけど
入力自動化だけでも確かに速くはなる。
が、C++で専用ソフトにしたら更に高速化した。
特に統計処理は圧倒的で十数分掛かっていたのが数秒になった。
ここまで差が出ると考えてしまうんじゃないかな。

297 ：
中間解でもほどほどの費用で手をつけられるならば、着手も出来ない最安価で最適な解よりマシだと思うの

298 ：
普通にプログラミングすればRPAより簡単に高速な解を無料で得られるのだけどね

299 ：
社員みんなにPython を教えた方が良いのかも。
アメリカの企業で入社の条件にPython が出来ることとしてるのがある。
アメリカの大学だと殆どの大学でPython を教えてるからそれ程大きな垣根じゃないみたい。

Excel が使えて当たり前と同じだな。 東大のコンピュータ教育もPython がメインになってた。
自分の出身大学のプログラミング基礎講座もPython になってた。

300 ：
そうなった時にRPAは莫大な負の遺産になる可能性が大きいね

301 ：
Excelが使える=罫線やセルのマージを使ってうつくしい表が書ける！
方眼神Excelを作れる！

Pythonが使える=1から100まで足し合わせてprintできます！

てことなんや

302 ：
>>63 silulix と、PyAutoGui はどっちが使いやすい？

>>72 どうして仮想化したら安定するの？ 何も変わらない気がするが。 勿論バージョン管理が楽だし元に戻すのも楽だけど。
サーバー化はやるべきだとは思うけど。

303 ：
>>302
環境の再現性と隔離性が高いから安定する
サーバーはデスクトップよりはるかにマシだけど仮想化よりは弱い

304 ：
>>297
だよね 悪く言えば中途半端だけど手軽なところが受けてるんだろうし 仕事でもそうだけど「とりあえず急ぎでほどほどのクオリティで」な感じ

305 ：
とりあえず急ぎでならpowershellがいいよ

306 ：
PowerShellはバージョン更改時に謎の仕様変更があるので恐ろしい

307 ：
>>302
SikuliXはコードエディタに画像が貼られるから分かりやすい
find(画像アイコン)
とか

308 ：
>>299
良い案だけど、それをどの程度どういうやり方でやるべきかねぇ
Excelの機能(フィルタとか関数とか)ですらまともに使えない人も多いし全員義務化よりは周りに何人かいて相談できるようにするとかがよいのかね 資格手当みたいにインセンティブつけて
あるいは、大企業なら複数人雇って専門の部署作ってもペイするんだろうけど、経営者は人雇うの嫌がりそう

309 ：
>>304
安価ならやる価値はあるが、Blue PrismやUiPath位の価格になるとね。
しかも年単位でライセンス料が発生するのでしょ？
業務を考えたら1台だけという事はないし、下手すると年間1000万円位飛ぶんじゃないか？
そんなにするなら自分でそこそこのを作った方がマシ。

310 ：
Part 1から言われてることだな
大規模なシステムなら普通システムを組まないと破綻する
手っ取り早く手頃な作業を雑に自動化をするには価格が高く導入の敷居が高い
帯に短し襷に長し

311 ：
>>308
よく言われる話だけど日本はExcel文化を捨てるべきじゃないかな。
勿論ちょっとした表を作成する位ならいいけど
日常業務でデータ集計等をやらせるには重過ぎる。365以降は特に。
TSVに変換してPythonで処理したら数十倍速くなったよ。

312 ：
>>311
＞TSVに変換してPythonで処理したら数十倍速くなったよ。
でも、そのpython を書くのに数十倍時間が必要なら考えます…

313 ：
>>312
2～3回の事ならExcel上で済ますよ。
でも毎日になると業務効率に響いてくる。
俺は処理時間が数分にも及ぶなら置き換えを検討するな。

314 ：
元々遅いのはコード書いた奴が糞だからでしょ。
それか、重いGUIが欲しかったとか。

大抵は糞コードのせいだけどね。

315 ：
・そもそも集計のコーディングにそんな時間は掛からない
・実用性を考えるとどうせ集計以外の処理が絡んでくる
・別の集計でも再利用しやすい

スクリプトでおkだな

316 ：
じゃあ空いた時間にやっといて（時間を空けるとは言ってない）

317 ：
既存の置き換えは元がブラックボックスでなければ大抵アルゴリズムが分かっているからそんなに時間が掛からないよね。
>>311の時はコア部分で15分、GUI込みで2時間位だった。
職業プログラマでもない俺でこの時間だし、プロならもっと早くできそう。

318 ：
>>309
人件費も結構かかるからね 募集から教育から色々面倒だろうし
uipathって実際いくらくらいかかるんかね？見積もりとかとったの？ まぁ規模感や業務内容によるんだろうけど、仮に1000万円くらいだとするとペイするところも多いししないところもある感じかね↓

【2019年版】RPA導入事例と効果・効能 | RPA テクノロジーズ株式会社「BizRobo!（ビズロボ）」
https://rpa-technologies.com/insights/rpacases_2019/

319 ：
>>311
Excel文化を捨てて、より習得が難しいPython文化にするとな？ まぁできる人はそっちの方が良いのかもしれんけどね
どの層(IT強者、事務のおばはん)に関しての話をしてるのかだよな

320 ：
RPAの事例って既存システムとの違いがよくわからん事例ばっかりなのはなんでだろう

321 ：
誰にやらせるかが違ってる罠

322 ：
>>310
＞ 手っ取り早く手頃な作業を雑に自動化をするには価格が高く導入の敷居が高い

この辺の記事とかあるなら教えてくれません？
むしろ手頃に雑に安価でっていうのがRPAのイメージなんだよね

323 ：
>>322
各ベンダーのライセンス料一覧とか見てくれば？
個人だと無料の物もあるけど商用だと結構お高いよ

324 ：
>>319
オペレータが組む必要は無いかと。
全員Python覚えるのも無駄だし、その分時間も取られるから業務効率も悪化するから
社内に専用の部署を作るのが一番だろうね。
特にGUIの設計はノウハウが詰まっているから直ぐには無理。

325 ：
集計業務の自動化には
・あちこちから出力を集めてDBに入れる、Python
・PythonとSQLで変換、集計を書く、期間形式宛先などのパラメータは引数で与える
・別途、GUIで呼び出すのを作ってもよい
・PythonでExcelやPDF、CSVやTSVを作成して配信
で大抵なんとかなるよね

326 ：
>>324
理屈は分かるけど じゃあ社内専門部署で→じゃあ専門業者に外注で→今に至る(小回りが利かず非効率が放置される) ってなりそう
気軽に頼めるのは担保しつつ、一旦ツールを作ったら保守はたまにすれば良いくらいの感触だとヤクルトのおばさん的な人材派遣なんかな

327 ：
>>323
この辺見ると大規模でも500万円程度なのかね 正社員1人分程度と考えると大したことないような


【UiPathの特徴】その４：構成価格（値ごろ感） | 業務可視化Note
https://kashika.biz/sps_uipath_feature_04/

328 ：
>>326
業務効率を引き上げるなら常駐プログラマは必要不可欠だよ。
経験上ボタンの位置や入力順等、UIの最適化だけでも効果があるのは分かってる。
マウスオペレーションをなるべく省くとか、長時間見続けても目の負担にならない配色にするとかね。
外注だとそういう細かい改善はまずやらないのでは？
それに機密情報を扱うケースを考えるとやはり正社員で固めておきたいよね。

329 ：
RPAは末端の職員が気軽に開発できることがセールスポイントの1つ
だから開発者数が増えやすくライセンス料も高くつくのでは?

330 ：
俺が誰が作ったかわからん既存の社内謎システムを読み解き一から業務を見直してクラウドERP入れたいけど超面倒、人も予算も時間もない、それに失敗して決算発表遅れたらダサいし嫌だし、今のシステムいかして安価で時短になるRPAサイコーっていう事でしょ。

331 ：
事務をやっているような女の子にＵｉＰａｔｈ等が使えるわけねーだろ
プログラマーの自分でも悩むくらいだぞ

332 ：
>>328
常駐プログラマ方式がベストってのは一事務社員としては同感だけどこの辺りをクリアしないとうまくいかなそう
・今その方式になってないのはなぜ？
・今後その方式に移行＆維持するためにはどうしたら？

＞ 外注なら細かい改善はまずやらないのでは？
そうだと思うけど、これも逆に言えばそれだけの費用対効果がないと発注者側が認識してるというわけで この辺の認識ギャップがどうしようもないと思うんだよね
240さんの事例もたまたまIT人材がいて、今のところ上手くいってるだけだしなー

333 ：
>>331
プロ向けと事務向けのRPAがあるから仕方無いよ

334 ：
RPA否定派って、玄人と素人とか複数種類の人種なり作業なりがあるのを区別しないよな 331がそういう意図じゃなかったらすまない

「プログラマの俺でも悩むような(難しい)処理を事務の女の子ができるわけがない」←そりゃそうやろ
「プログラマが使ってないんだから役に立たないはず」←そもそも素人の事務向けだろ

335 ：
>>332
>>・今その方式になってないのはなぜ？

ケース分けすれば128や256はあるけど3つだけ
case-01　そもそも (IT以前の) システム化の必要性が無い
～略～
case-16　必要性はわかるが投資対効果が不明
～略～
case-32　うさん臭くて嫌い

>>・今後その方式に移行＆維持するためにはどうしたら？

Step-01 予算が立てやすくて、コンピュータに何をやらせているかが明解なRPAの導入
～略～
Step-04 いくつかの道に分かれる
　Root-01 経営者が意識改革して、システム部を作る、アウトソーシングなどをする
　Root-02 経営者が意識改革をして、それでもなおシステム化不要
　～略～
　Root-64 RPAやPythonに下手に依存しすぎてサポート切れ、提供会社の倒産などのあおりを食って事業継続不能

(ここまで15分ででっちあげ)

336 ：
Pythonでやるにせよ最終的には商用RPAと同等の処理になるのでしょ?
PyautoGUIを使うならそうなるよね。
ならRPAそのものを否定している訳じゃないのでは?

素人目には商用RPAの為にプログラマを置くなら、その人達がPythonで似たようなのを組めばいいと思うんだけど
実際携わっている人の意見はどうでしょう。
それでも商用RPAを導入するだけの価値はある?

337 ：
商用RPAをプログラマー「しか」触らない、なら意味ないかと
Pythonでいいよな

RPAいじるメインは今までExcelのマクロくらいは書けてたあんちゃん達で
プログラマーはあくまでもお手伝いレベルならあり

338 ：
専門家をずっと雇っておくだけの金がないということだろ
昔は専門家が社内にいたが、経費削減で外注に変えた
長い目で見てどっちが得かはなんともいえない

339 ：
>>337
あんちゃんたちみんなの分の開発者ライセンスを買ったら幾らになりますか？

340 ：
金はないのに開発者ライセンスは沢山買ってもらえるの？
それともやっぱり金がないから開発者ライセンス数をケチって少数精鋭でやるの？
開発者ライセンスは末端の下級職員でも気軽に開発できるってメリットを潰しちゃってる気がする
開発者ライセンスぐらい気前よく無料にしてくれないのかね

341 ：
毎回同じ話になるんだけどVBAが叩かれるのと全く同じなんだね。
手軽に作れるけど、その為に腐ったコードが乱立して、言語が悪いわけじゃ無いのに忌み嫌われるという。
結局、ちゃんとしたプログラマーが組まないと碌でもないものが出来上がってまわりが迷惑する。

値段も首を傾げる。
これを採用した奴に20年くらい前に安い時給でソフトウェア評価の仕事してた時にやってたことを見せてやりたい。
そうすれば、こんなものに高い金出さなくても、いくらでもやりようがあると分かるだろう。

342 ：
はっきり言ってRPAに積極的な会社は経営層のITリテラシーが異常に低いんだなと思ってる

343 ：
システムのおじさんが見せてこなかったから、現場主導で導入できるRPAが流行ってるんだよ。
見せたら～とか20年間何してたんだと非難対象やで。

344 ：
そういう会社だとWindows PCの標準搭載アプリでスクリプト作成できることすら知らない人間が経営者だったりするから

345 ：
>>343
いやいや、そういう仕事じゃないし…
そもそも、IT殆ど知らない奴(上司)は関わるなよっつう話。

346 ：
>>343
IT屋としては何度も見せてきたのだけど
わからないものは関わりたくない
動いてるなら別にいいじゃん
そう言って拒絶を続けてきたのは経営ほうなんだよね

347 ：
非難対象？？
物知らずの素人に教えてやってるのに何だその言い草は？
20年間技術一本でやってきた人間をシステムのおじさん呼ばわりとか
警備員か何かと勘違いしてるんじゃねーか？

348 ：
末端の職員達が気軽にRPA開発できるように開発者ライセンスを行きわたらせたら幾らになるのか誰も知らないのですか？
導入企業の社員はここにはいないのだろうか

349 ：
Part1の一桁台見ただけでも分かるが当初は技術者のスレだった
今はIT素人のレベルの低い話題ばかり
俺も金輪際関わらないようにするわ

350 ：
システムの改善はユーザー目線じゃないと分からない事が多いから難しいよね。
しかし大半のユーザーは知識と経験が無いからどう直したらいいのか分からない＆気付かない。
そうなると当然そちらからの提案が出ないので改善されないまま時間が過ぎていくパターンが多いんじゃないかな。
実際俺の周りはそうで、とにかく手順を覚えて速く手を動かす事に終始しがち。
で、「いや、普通に使えてるし特に不満は無いよ」となる。

351 ：
具体的な金額出す人いないよな

経営者とプログラマ側が(どちらが悪いにせよ)協力できずに非効率が放置されてきたという現状があって
RPAをネタに(他にも方法があるにせよ)それを改善をしようとする動きが生じるんだからもはやそれはRPAが有能ってことに等しいやろ

352 ：
>>349
変な話題にして申し訳ない。
技術的な話の方が面白いので是非そちらの話をお願いします。

353 ：
開発と運用の歩み寄りは世界的にも進んでるけど海外はDevOpsが中心
テクノロジを否定せずに根本的な組織改革を進めてる
それに比べてRPAによる臭いものに蓋をするような雑な対応で戦っていけるのだろうか

354 ：
RPAってテストツールとかには良いと思うけど、業務で日常使い続ける意味があるか？ 改善できるのならなんでシステムを改善しない？
明らかにシステム屋がサボってるとしか言えない。

355 ：
改善してやりたいのだが経営がお金もったいないから勝手に改善するなって言うんだよ

356 ：
>>353
まぁ世界と戦うみたいな視点もないし、ITを戦略的に使う意識もないんでしょう(もしあるなら既に効率化が進んでるはずでRPAがバズらないはず)
いかにも日本っぽいじゃん 理想とか合理性とかを追うんじゃなくて現実とか手頃さが響くとかさ
とはいえ、それでも現状よりマシになりそうっていう意味では良いと思うけどね

357 ：
なんかおかしいなと思うんだが、数年間もシステムや基本ソフトが固定されてる環境ならそれなりに効果があると思うけど、年々変わるシステムにどれだけの効果があるだろ。
苦労して動くようにしたら壊されたとかで不満だけ高まるのでは？

358 ：
手頃ではないかな

359 ：
>>354
システム化しにくいのもあるんじゃね？ RPAって塵も積もれば山となる的な発想もポイントで 多数の事務のおばはんが各自色んなサイトからデータをダウンロードして色んな整形して色んなものに転記するみたいな
ダウンロード→整形→転記というガワは同種の作業だけど、具体的な各工程の作業内容は違うから、それをシステム化しようとするとRPAみたいなものになるんじゃないの？

360 ：
>>359 スクレイピングといって大流行り。

361 ：
>>359 そんなものをRPAでやるなんて大馬鹿じゃないの？

362 ：
うーんでも
その塵みたいなおばさんでもキッチリ一人一人にライセンス料がかかるんだろ？それって本当にお得なのか？
部署や会社単位でライセンスを買って何人開発者が居ても料金固定ってシステムなら人海戦術もまあ理解はできるんだけどさ

363 ：
あ、もちろん、理解できるってのは、将来のこと全く考えてないその場しのぎとしてはアリかな、ぐらいの理解ね

364 ：
なんかRPA反対派って文句しか言わないよね

スクレイピングがどうしたの？RPAも大流行りだね
大馬鹿じゃない人はどういう代案あるのかね？聞かせて欲しいなあ

365 ：
いやRPAは別にそんな流行ってないだろう
まだまだスターターだよ

代替案はお手軽で無料のごく普通のプログラムね

366 ：
それで経営者を動かせばいいんじゃない？
動かせてないんでしょ 346に書いてあるけど
普通のプログラムが代案→経営層に響かない→じゃあRPAがいいんじゃない？→普通のプログラムの方が良い→最初に戻る

367 ：
とにかく値段が高いわな
そのうちＭｉｃｒｏｓｏｆｔあたりがＯＳに標準でのっけてくるだろうから、
そのあたりがブレイク点かも

368 ：
値段が高いって人件費に比べたら全然安いだろ？
事務のおばちゃんにいくらかかってると思ってるんだ

369 ：
ていうか、単純入力作業を人間にやらせるのは人権問題。
社会から糾弾されるぞ？

370 ：
>>366
経営にはわからんからなぁ
情報系の意思決定機関を経営とは別に置くべきなんだろうな

371 ：
>>368
おばちゃんが開発するんだからおばちゃんのコストは変わらないのでは？
おばちゃん切る前提だとおばちゃんはロボット作ってくれないだろうし
そこにライセンス料、マシンリソース料、教育費、既存資産メンテ費用、セキュリティ事故リスクなどが上乗せされる

372 ：
ITリテラシーの無い経営陣の考え方なんて「快適な事務所でPC弄ってるだけの給料泥棒」程度だからな

373 ：
>>369
それは同意

374 ：
導入した奴の体験談がないんだが
肯定派も否定派も全員使ってないんじゃないかと邪推しちゃうぜ

375 ：
>>370
そんな「本来はー、理想的にはー、アメリカではー」みたいな夢物語語られてもね
普通のプログラムが代案だっていうなら、最低限経営層に響かせるための方策とか、仰ってる情報意思決定機関を実現するための方法とかをセットで語ってくれんと

376 ：
>>371
働き方改革がらみで流行してるから首切りがゴールではないと思うよ。

377 ：
働き方改革とかどうせぽしゃるだろ

378 ：
まあRPAは一定の効果はあるとは思うがな

379 ：
>>376
結果的に首切りがゴールになると思うよ
人がいらなくなるから

380 ：
ここには管理部門・事務系の人はいないかな？正直自社がERPやRPAとかAI導入決めないか危機感ある
せめてRPA使える様に勉強しとく位しないとね

381 ：
働き方改革で「社内」向け資料にチカラ入れてんじゃねえよ！
という考えが広まると、日本ではRPAより効果が有るのではないかっ(看破)

382 ：
>>371
システム詳しい人はシステムのリスクだけを詳細に語り出しがちだけど、人雇うのも十分リスクやし金かかるわ
退職リスク、休職リスク、ハラスメントリスク、犯罪リスク、給与、法定福利費、教育費、端末費 しかもコントロールしづらいタイプが多いというね

方法にしても、超勤を減らす、派遣を減らす、自然に辞める人がいる、採用数を絞る、とか直接的に事務のおばはんを切るだけじゃないし

383 ：
>>382
なので少数精鋭で普通のシステムを組む、が正解になる

384 ：
>>383
じゃあ今できてないのはなんで？
その原因を解決する方法は？

385 ：
>>384
たぶん経営が無能なんじゃないかな

386 ：
>>384
俺の所は粗削りでもとりあえず作ったら後はそれっきりで
煮詰める事無くそのまま運用し続けてしまうケースが多いよ。
作業者の動きを追っていくと違う解決策が見えてくる事もあるからかなり大事なんだけどね。

387 ：
>>384
少数精鋭のチーム組むには最初にエンジニアスキル見極める人がいないと無理だが、
普通の会社には採用面接でスキル見極められる人がいない
経歴書に開発言語とそれっぽい経験書いてあったら通して痛い目を見てるケースがままある

388 ：
>>366 python にRPAをやらせれば全て解決。
おばさんはおばさんなりに、プログラマはプログラマなりに使えるだろ。

389 ：
>>385
ん？経営が無能という原因を解決する方法が書かれてないよ？正解とやらを教えてね

>>386
まぁそうなりがちだよね うちも10年以上前の担当者が作ったマクロが利用だけされ続けてるし、導入後のERPなんてほっときゃ動き続けるくらいに思われてそうな感触

390 ：
>>389
転職

391 ：
>>384 モノタロウが一つの解では？ モノタロウでは全てのコンピューターシステムをPythonに移行した。
もちろん専任のプログラム部門が開発してる。
Python のプログラムの遅さは、サーバを増やすことでカバーしてる。 多少ハードに金がかかっても開発効率が高くなることには変えられないという考え方。

392 ：
先日行った勉強会では某新興大手IT企業ですらか外国製RPAを導入していた。
使い方はまだ模索中みたいだが、面白い使い方してた。

393 ：
>>390
経営が無能という原因に対する解決策になってないよ？

>>387
それだけなら単純に実技検査とかして採用の精度を上げりゃいいと思うんだけどね 傍から見ればそれだけのコスパはありそうだけど

>>391
へぇー、おもしろいね！ ERPで内製から外注に移るところもあると聞いたことあるし、内製向きと外注向きを分ける基準はなんなんだろうなー
モノタロウで上手くいった理由とかも知りたいね

394 ：
>>393 モノタロウでPython に移行した理由は、先ず教育コストが低いこと。 少しの時間で使えるようになる。
新人が入ってきても直ぐに使える様になる。

開発効率が高いこと。ライブラリーが揃ってて何でも出来るし、インタープリタの特徴として試行錯誤が簡単。

この二つみたいだけど。

395 ：
>>394
やっぱり普通のプログラムが正解だったということか

396 ：
モノタロウの成功はまず第一に社長をはじめ上層部の意識が高いことにあるね。
急成長しているし外注では改良スピードが間に合わないのかもしれない。
社員の2割がIT関係に携わってるらしい。
ジャストインタイムで日々改善をし続けてるし。　よく回転してる。

397 ：
トップが有能でアクティブだと従業員は幸せだね

逆に下から一生懸命説得しなきゃ動けないような愚鈍な経営者はダメだな
従業員の方からNOを突きつけて転職すべき
無理して動かそうとせず淘汰されて消えたほうがいい

398 ：
言語の比較でPython優位なのはわかるとして、他の方法との比較で内製にしたのはなんでなんだろうね？ 396の言うスピード重視なのかな？ 長期的に見れば安上がりなのか

経営者の説得について 仮に「いくら投資してシステムを改善すればいくら人件費が浮きます」みたいな正攻法の説得ができたら経営者も動きそうなもんだけど、何が悪いんかね？ 具体的なデータを出しづらいのか、経営者が過小評価するのか

399 ：
>>392
＞ 面白い使い方してた
詳しく

400 ：
何にもしらない奴(経営、上司)に流行りを見せて飛び付かせたというだけ。
まずね、ITに関係有るんだから何にも知らない奴はITに詳しい奴に相談しろよ。
といっても、詳しいとされてる奴が実は大して詳しく無かったりもするんだけどさ。
実際にこういうツ－ル無しで他アプリを操作するプログラム組んだりするのは難しいかどうか検討しないのはどうしてなんかね。

テレビでも漫画でもIT絡むと滑稽なのばかりなのはどうしてなんだろう。

401 ：
>>980　穴の深さは50cm位かな。　コンポストの直径は60～70cm位？　大きな部類のコンポスト。
コンポストの上に半分位溜まった頃に埋め戻して別の所に移している。　ミズアブとかが完璧に消化してくれるから殆どたまらない。

402 ：
誤爆

403 ：
>>398
何言っても
そんなのワシ分かんないよ～
でおしまい

404 ：
>>400
日本の情シスって外注に仕事投げるだけのおじさんが大量にいるから、その連中に聞こうとも思わんのだろう

かといって、RPAコンサルに騙される経営者は不動産投資営業に騙される連中と変わらん

405 ：
>>403
安くなるんだったら良きに計らってやっちゃってよ～、とならないのは何故？

406 ：
>>405 1円も出したくない。

407 ：
システムに金出したがらないのは悪しき風潮だよな
ま、経営者視点じゃブラックボックスだしROIが見えにくいからいいようにボラれそうって心理になるんだろ

その点RPAは既存業務の自動化ってことで時間削減効果が目に見えて分かるから経営者が飛びつきやすいんだろう

408 ：
少なくともIT担当重役か部長が1人位いないとIT革命は進まないだろうな。
わからない人間は判断できっこないんだから。

409 ：
>>406
トータルで安くなる(って部下から提案されてる)のに？
まあ、失敗のリスクを過大に見積りがちってことなのかね そんな上手い話言ったって失敗したら無駄金じゃないの～、みたいな
あるいは、新たな出費は嫌だけど現状の無駄遣いは構わないという判断の不合理性みたいな

確かに管理職の昇格条件とかにするべきだよな

410 ：
決算が赤字の場合は、訳解らない人間が残業代を垂れ流してるより首を切った方が直接的な利益になるからな。
後の事などケセラセラ

411 ：
モノタロウは利益が急成長し続けていると言うのも大きいだろうな。 プラスがプラスを生む良い回転に入ってる。

412 ：
>>405
何故か？
企業が広告を出してないから

413 ：
>>398
現場からすると経営と情シス双方が過小評価しているように思える。
よく聞くのが「たかが数秒速くなったところで変わらないだろう？」というセリフ。
改善の効果を見積もるのは難しいので予算を取ろうにも
「そんな不透明なものに金は出せない」と言われてしまう。
しかし無から始まるものは分かり易いのでそのまま通る事が多い。

後はそもそも情シスが多忙でやりたがらないケース。
「今動いているから別にいいよね？」で終わる。

414 ：
>>413
正攻法じゃ何を言っても無駄
広告を出して流行ってるような記事をばらまかなきゃ購買意欲が湧かない
専門知識ない企業幹部なんてただの消費者と変わらない
消費者に物を売るにはとにかく宣伝だ

415 ：
>>413
情シスの立場からすれば、将来かならず問題が起きて負債になるのが見えているから嫌
だから、現場の人が情シスを飛び越えて
「我々でずっとやります。情シスなんて頼りにしません」
と一筆入れないと無理

416 ：
>>415
RPAって情シスと現場が歩み寄って連携しないと、絶対にうまくいかないのに、
なんだかRPAそのものが争いの火種になってるよね。

現場「情シスが働かねえから、おれらがRPAでやってやる。エンジニアは不要だ。」
情シス「無知な現場の暴走で俺達の負担が増える。ふざけるな。あとで泣きついても、絶対に面倒みねえぞ。」

このジレンマを解消しないかぎり、RPAに未来はないのではないか？

417 ：
だって情シスが考えてるのは自分達の事だけで、会社の利益じゃないもん。

現場: 定型業務を自動化したい。RPAでどうだろう？
情シス: RPAはダメ。やるなら自己責任でやれ。
現場: なら何がいいの？
情シス: 知るかボケ。自分達で考えろ。
現場: .....
情シス: Pythonでも覚えて自分達でどうにかしろ。キレイなソース書かないと許さないからな。

これが現実。

418 ：
分かってね―な。
情シスにそれだけの予算があれば自動化だってやるだろう。
もっとも、その力量があるかというと疑問符が付くけど。

結局、経営と現場と情シスの連携が出来ないという組織の問題。

419 ：
まだRPAやってないけど、情シスとしての心配事いくつかある
・イレギュラーが洗い出しきれず、エラー停止＝即メンテが日常化
・エラー対応を現場に理解してもらえないとロボット増＝情シスの運用工数増
・Excel大好き企業なのでExcelからExcelへの転記は一瞬で要望出てくるが投資効果なし

今の所インターネット上の客先システム自動化だけにしとけ！って脳内で叫んでる

420 ：
>>417
まるで情シスの不利益は会社の不利益じゃないみたいな言い方だけど
情シスがRPAに工数を取られて基幹システム等々に工数を割けなくなったら会社の不利益になる

将来的に重大なリスクになりうると指摘されてるのに無視して自分達が楽することしか考えない
現場のほうが会社のことを考えてない

421 ：
情シスがそのシステムを組んだのなら商用RPAに頼らず改良の道を選んで欲しいんだがなぁ。
ExcelのデータをUIエミュでコピペしていくのと
システムにそのままインポートするのでは
どちらが効率的か分かるよね。

422 ：
RPAをプロトタイピングツールとして使うのがいいかも
まずなにか一つをRPAでやってみて効果ありなら情シスにリクエストとして上げる
仕様はRPAでやっている通り
毎月１つずつでも12個はできる

423 ：
excel入れたとき勝手に現場が使っていったああいう感覚だけどなあ、なんでこんな反対なの。とにかく触って欲しい。

424 ：
>>421
うちは中間方式だな、
Excel何々フォーマットからA-J列をコピペすれば一括投入出来るよ、
みたいな画面をいろいろ作った
ロジックとしてはTSVファイルのインポートと同じでGUI付けただけとも言える

425 ：
>>423
外部サービス都合で壊れやすい
自社システムの更新を難しくする

426 ：
excelのimportごときに年間何百万も使うのかブルジョワすげえな

427 ：
付加価値の低い事務作業のために数百万で派遣入れてるような状態に比べればマシだぞ

428 ：
>>417
まさにこれの現場側なんだけど、人手不足という表現が正しいかわからないけど、やっぱり作業に時間取られる事が多すぎる。
でもこんな作業に人は増やせない。

情シスは投資対効果の高いシステム開発メインで、１つの仕組みで30分自動化されますみたいな事まで回ってこれない。

じゃあどうすればいいのさ？

429 ：
>>428 python を覚えて自分たちでやれ

430 ：
>>428 RPA がダメと言ってるのは金がかかりすぎるからじゃないの？ python と各種RPAツールを使えばタダでできるからやってみたら？ PyAutoGui など

431 ：
>>427
派遣と比べる必要はない
正社員が隙間時間とかでpythonでもなんでも使ってサッと作ればいい
たかが15分や30分の余裕もないブラック企業というわけでもあるまい

432 ：
pythonでもなんでもいいけど
簡単なプログラムすら習得できない学習能力と意欲の低い人材はそれこそ人件費の無駄だな

433 ：
このご時世、管轄外の新規分野を業務の隙間時間に意欲的に取り組んでモノにして下さる人材なんか高望みだよ
「お前の代わりなどいくらでもいるんだ！」と若手を千切っては投げしてた氷河期世代採用と同じ感覚でいらっしゃる？
それはご愁傷様（周囲が）

434 ：
普段している学習時間の何割かをプログラミング学習に割り当てるだけだろ
たったそれだけのことが出来ないのは普段から全く学習に時間を使ってないからではないかな
社会人として普段から全く学習してないというのはありえないブラック人材だ

435 ：
新しいことを覚えてできることが増えていくのは誰にとっても楽しい事だよ。
出来れば情シスを少しおだてて、時々見てもらうとかすれば協力してくれるんじゃないかな。

勉強時間を少し取られても将来的に残業も少なくなるなら上の方も認めてくれるだろ。

436 ：
大規模な工数管理というか人員管理レベルの話なんだから本来は経営層マターなのに、事務部門vs情シスっていう同階層間の抗争になってしまう構造がおかしいわな

なので、責任は一義的には経営層にある それは当たり前
だが、一方で情シスは情シスでなんやかんやリスクや多忙等の理由をつけて守りに特化しがちだから文句言われるんでしょう
「RPAじゃなくてプログラム組め」とか言うけど、じゃあスクレイピング用の簡単なツール作るので年間何百時間浮きます、みたいな攻めの試みはしてないんでしょう もしそういう試みをしてたら経営層もRPAよりまずそっちを考えるだろうし

437 ：
>>422
これ結構良いアイデアだと思う まぁ勿体ないけどね 無料のVBAでプロトタイプ作る方が理想だろうけど、現実的じゃないしな
単にRPA入れるな、よりはこういう戦略の方が生産的かと

438 ：
>>436
真面目に計算したらマイナスなんでな
短期的にはプラスかもしれんがそれは俗に言う技術的負債というものだ

439 ：
>>286
何を目指せばいいのか価値観が多様でわからないから民主主義が採用されているだけ
なにを目指せばいいか明確ならその実現方法は時間的経済的なコストがかからない方が良い
一人でもチームでもどっちでも良い

440 ：
各部署で好き勝手に作ると狭い範囲で使うには良いだろう
各部署が連携する場合は
ある部署での変更の影響が波及する可能性を考慮しておいた方が変更に強いものを作れる可能性が高い

RPAが頻繁な変更に耐えられるとしたら
そんな考慮は不要かもしれない

441 ：
>>311
excelの処理を早くすると言う解決策も考えられる

442 ：
>>317
ユーザインターフェイスはどうしてるの？

443 ：
>>325
それ全部excelで可能じゃね？

444 ：
>>440
変更に強いとか考え出すと真面目にシステム化してapi提供するとかそういう方向にすすむ
なので使い捨ての雑なバッチ処理みたいな使い方するしかないんじゃねえかな
雑な作りで長期間残るのが最悪なんでこれだけは避けなきゃいかん

445 ：
>>417
情報システム部門って全社的なことを考えているから
一部門に合わせたら全社的なシステムが維持できなくなる心配がある
だから自己責任でやる分には構わないって事だろう

どうすればいいのかは
自分たちがどうしたいのかわからないのに
提案できないんじゃね？
それを調査検討する工数も取りにくいだろう

自分たちで調査検討できない部門が
自己責任で導入したら
問題発生時に自分たちで対応できない可能性が高い

情報システム部門からすると歓迎できないんじゃね？

446 ：
>>444
だから狭い範囲で自分達だけで対応するようなものには適しているだろうね

447 ：
>>190
一度だけ、家の鍋持参しておでん買ってるおばちゃん見たことある

448 ：
↑ごめん誤爆

449 ：
UiPath　communityって実名じゃないと登録しないといけないの？
ググっても出てこないわ

450 ：
>>266
厚かましいじゃなくおこがましいでは…

451 ：
>>311
何のためにPowerQueryとPowerPivotが実装されたのか分かってなさそう

452 ：
>>446
徹底できるならいいよ
でもできないでしょ

453 ：
>>438
長期的な収支でマイナスだっていう量の話したいなら量についてどう計算したのか語ってくれんとな 「俗に言う技術的負債だ」とか言うだけじゃあねぇ

じゃあ技術的負債にならないためにどうするのとかも言わないし 文句言うだけで生産的な話がないんだよな(別にこう判断したからってのがあれば手作業継続にしたとしても生産的だが)

454 ：
>>439
何を目指せばいいか(利潤追求？)が明確だとしても、不明確な点が一杯あるでしょ 理念的に1人でもチームでもいいってのは同意するけど、現実的に総じて1人はないだろうね
1人に任せられるスキルがあるのか、不正しないのか、
レビューどうするのか、評価どうするのかとか
小さい会社で、社長も詳しくて、信頼出来る友人1人に頼むとかの限定された状況ならわからんでもないけど

455 ：
>>417
RPAって現場要望というより経営者要望だろうね 現場で効率化したいって人はVBAやるんじゃないかなと

RPAにせよVBAにせよPythonにせよなんかツールを作る以上、情シスが絡まないって選択肢はないと思う
下手な繰り返し処理とかで基幹システムのサーバダウンとかしてみろよ 仮に事前に各自の責任で使うことって取り決めしてたとしても、そもそもそんな取り決めアホか責任放棄だろとか経営者あるいは外部から言われるに決まってるじゃん

RPAにせよVBAにせよPythonにせよニーズの高いものを厳選して現場と情シスが協力して作るしかないんじゃないかね 厳選するのはどっちか、作るのはどっちかとか細かい話はあれど

456 ：
ニーズが高い、てのもくせ者で、
声のでかいやつ「だけ」が見てる三ヵ月に一回のレポート、誰も見ていない
とかあるよな
声の小さいやつが毎日三回作業してるものは無視とか

457 ：
スレが伸びてると思ったらｗ

458 ：
なんにせよ、やらせてみて人を育てないと駄目だよ～

459 ：
>>441>>442>>451
>>311のを作った時はまだPowerQueryは無かったし
そもそも会社の環境だとExcelの起動が遅くて閲覧するだけでも時間が掛かるのがまずい。
>>311ではPythonと書いたけど運用はC++で組んだのを使用している。
社内外システムへの入出力が多いからなるべく速度を稼いでおきたいんだよ。
1台のPCで並列処理できるようにしたいしね。

UIはデータファイルをフォームかあるフォルダにD&Dすると内容に応じて処理する物とか
ゲームパッドで開始するとか色々あるかな。
職業柄、常時PCの前にいる訳でもないのでK/Bやマウス以外の操作も取り入れている。

460 ：
正直、技術的負債っていってるやつも>>422には反対しにくいだろ？
となるとあとの問題はコストか？

461 ：
そうね、コストが安ければ全く反対はない
何千万かけてそんなものを入れるぐらいならエンジニア一人雇った方が安い

462 ：
お、議論が一歩前進したな。

463 ：
事務のおばちゃんがRPA書けるようになればおばちゃんの付加価値も上がるんだが、育てる気はない？

464 ：
おっとこれだとRPAのコストの問題から外れるか。
うーん。

465 ：
お前らそんな予算の無いの？

466 ：
上層部からの人件費削減で派遣二人切った代わりにその半額くらいの維持費かかるRPAさんがやってきて負担が増えたよ！！
ちなみにRPAさん今の所使用用途はないよ！！！

467 ：
>>466
いや、買う前に用途検討しとけよｗ

468 ：
>>454
不明確な点って
それが何を目指すか判らないって事
最終的なゴールが同じだとしても
ルートが違えばマイルストーンは違う

技術的な事は
調べる試す相談する依頼するとかで解決するしかない
手段をどうするかはコストの問題

469 ：
PythonやVBAばかり出てくるけど、他のスクリプト言語で組んでいる人居る？
LuaJITやJuliaはどうなんだろうか

470 ：
powershellもええぞ
.net使えるし、開発環境も標準で入ってる
非IT社員が使うなら検討対象に入っても良いと思う

471 ：
powershell慣れるまで奇異に感じるけどオブジェクト指向とか割とちゃんとしてて慣れればいい感じだよね

472 ：
>>460
RPAの成果物は個人・特定領域に寄りすぎる傾向があるからシステム化の候補とするには向かないだろう
API化の需要を測る程度になら役に立つかもしれない

473 ：
>>443 スピードがとんでもなく遅いじゃん

474 ：
>>460
基本的には賛成 各事務所で同じRPA作ってたわ、それならまとめよう、って感じでシステム化が進められるはず(RPAなしでもできるのが理想だろうけど 各事務所で同じ作業してるからシステム化してくれみたいな)

一方で、懸念点としては必ずしもシステム化向きとは言えない作業(つまり、RPA向きの作業)があるんじゃないか、ってことかな スクレイピングとか転記とかひとくちに言っても、取得先HPとか転記先システムとかに拠るからまとめづらい、みたいな

要は、同じやり方で大量にやるタイプの作業はシステム化向きだけど、似てるけど違うやり方で各自が少量ずつやる(けど塵も積もれば的に全体としては大量となる)タイプの作業はシステム化に不向きだろうと

475 ：
Excelはデータ増えてくるとどんどん遅くなるからな
お試しはおkなんだけどいずれ破綻するみたいな

476 ：
>>467
そんな頭が良い上層部なら真っ当にシステムを更新するんやで………

導入が目的の悪い見本だね。うん。
上層部と業務改革推進なんとかが喜んで買って与えてきた…けど、現場では使うマシンも用意してなければ用途もないのに削減目標だけ先に実行されててんやわんややでー。

477 ：
>>476
派遣2人の半額っていくらくらいなんかな？
派遣2人にやらせてた仕事をRPAでやる算段だったんだろうけど何がダメだったん？

478 ：
>>475 Excel VBA は、プロトタイプだと理解してれば解決法は自ずから出てくるけど、慣れ過ぎてるとおかしいとも思わないのが危険。

479 ：
> 現場: 定型業務を自動化したい。RPAでどうだろう？
> 情シス: RPAはダメ。やるなら自己責任でやれ。

情シスが正解

> 現場: なら何がいいの？
> 情シス: 知るかボケ。自分達で考えろ。

情シスが正解

> 情シス: Pythonでも覚えて自分達でどうにかしろ。キレイなソース書かないと許さないからな。

情シスが正解

これが情シスの職責。

おまえら病院行ったら医者の言うことに従わないのか？
法律事務所言ったら弁護士の言うことに従わないのか？

さっさと無能経営者にゴミツール返品するよう言ってこい
それがお前らの職責。

480 ：
>>474
独立にやってる事業所で偶然同じツール作ってたなんて滅多にない
そんなレアケースのための何百万(いや多事業所だから桁が増えるか？)かけてプロトタイプとかもったいなすぎ

481 ：
RPAと基幹システムでは要求される品質が全く違うから
はいこれプロトタイプって気軽に渡されてもそんなに簡単には取り込めんよ
RPAでは単純な処理がシステム化する際にはそれだけでちょっとしたサブシステム程度の規模になる場合も多々ある

482 ：
>>479
お医者さんならなんで定型業務の自動化してくれないのさ！

483 ：
>>482
だって定型定型って言うけどウソばっかりじゃん、
「あ、この場合はですね」とか
「この客先は、特別でー」とか
後出しばっかでなんにも定型じゃない

484 ：
>>483
素人の思いつきレベルだからねぇ

485 ：
>>481
RPAでのプロトタイピングから、そのままの動作をするクライアントをVBやPython等と .Net、OpenCV等で作るのは可能だと思う
もしも処理的に問題があるなら却下＆禁止する
サーバーサイドでシステム化するのが適切なら、どうぞよしなに

大事なことは、ルーチンワークのリストアップをすると同時に
要件と所在を明確にして野放しにしない
一通り終わったらRPAを用済みにして二度とお金を払わない

ついでに処理速度が上がったり、クライアントのバックグラウンドで動かせれば、なお結構

486 ：
>>483,>>484
後出しを現場の人たちが自分でやる分には別に構わないはず
どんどん後出しして出来上がったものをプロトタイプとして見せてもらえばいい
プロトタイプも出来ないようなのは放置で

487 ：
>>482 お薬出すだけの定型で済むなら楽だろうな。

そう言えばカルテは皆んな電子化になったけど、口頭筆記はあまり使われていなさそうだな。
アメリカではかなり多いと聞くが。 医師が口頭で言ったものを助手がカルテにすると言うのがかなり進んでるらしい。

事務所の中で口頭筆記なんてしたらうるさくて仕方ないだろうな。

488 ：
>>485
まあ悪くない
情シスと隔離するのと金を使わないのが大前提
ただそれだとプロトタイプもpythonや他の簡単で無料の言語でやったほうが良さそうだ
金は正式なAPIや他のサービスに課金したほうがお得

489 ：
>>480
はぁ、「滅多にない」という根拠は？同じ業務してたら同じようなツールになるはず 多少のブレはシステム化で吸収できる前提ね

高い高い言うけど人件費も高いからね 社員一人当たり500万円かかるのはざら 首切れないだろとかそういう単純な話にしなくても、超勤削減とか派遣削減とかの効果をまとめて結果として数人分浮かせるという話も含めてね

490 ：
>>473
>>475
遅いのは殆ど組んだ奴が悪い。
RPAが駄目なのと一緒。
言語のせいにされるのも一緒。

491 ：
>>489
そんなのはとっくにシステム化されてる
残ったのは地方や人によってことなるローカル最適化された雑務ばかり

人間はロボットと違って柔軟にスマートに様々なことができるので高くついて当たり前だろ
ロボットと人じゃ単純なコスト比較はできん

492 ：
>>485
まぁ基本的に賛成だけど現実的にはなし崩し的に使い続けることになりそう
一度便利ツールを与えられて各自なりの効率化を図った後、システム化できなかったものは取り上げられるわけだけど、そこで(仮に事前の取り決めがあっても)異論が出そう
まぁそれはそれでそこで経営判断をすればいいだけだからなんら致命的ではないけど

493 ：
>>489
そりゃ、組まずに買っただけで何でもやってくれるなら高くないわな。

実際は組む作業、組めるようにする作業が必要。
で、事務のおばちゃんでも組めるなんていうとVBAとそっくりでね。
で、ここでもVBAが遅いとか吐かしてる奴もいるわけだ。
そりゃ組んだ奴が腐ったコード書けばいくらでも遅くなる。

RPAが駄目なんじゃない。
これで夢のような未来があると思ってる奴がアホ。
実際には他の言語と同じように組める奴(プログラマー)が組まないと碌でもないものが出来上がる。

494 ：
>>492
絶対にごねる奴いるよな
おばちゃん首にしちゃったから動かないと困るんだよ～今回だけ特別にお願い
みたいな

495 ：
っd

496 ：
計画的な合理化を行ってる企業は、とっくの昔にシステム導入してるからRPAいらん。
RPAを使えそうなタスクが多い企業は
無能社員に仕事を与える意味でルーチンを人にやらせてるからRPAいらん。

497 ：
>>491
RPAというトピック自体がそんなシステム化進んでない前提でしょ まぁそちらの優秀な組織だとそうなんでしょう
「高い」→「単純なコスト比較はできん」ってなんじゃそら

>>493
組む作業はVBAより超簡単超早いという想定だろうね
こればかりは実際に導入したところの体験談が蓄積してこないと話にならないかもな

498 ：
>>493

＞RPAが駄目なんじゃない。
＞これで夢のような未来があると思ってる奴がアホ。
＞実際には他の言語と同じように組める奴(プログラマー)が組まないと碌でもないものが出来上がる。

これが正解
PythonだろうがC#だろうがRPAだろうがただのツール
PythonならOK、RPAはNGではなく、誰がどのように設計して組立てるか、だ

499 ：
まあUiPathとか中身は.Netやしなあ
素のPuthonとどっちが速かったっけか

500 ：
Puthonとか書いてしまった
おいは恥ずかしか！生きておられんごっ！
https://i.imgur.com/VaHMh5P.png

501 ：
無能な経営者がロボットとかAIが来れば社員の作業量が減ると思ってそうだな。
RPAはロボットらしいから働いてくれるから金を出してもよいが社員には辞めてもらおう、とか。
社員が手取り足取り教えないといけないことを知らずに採用してそう。　
うちのRPAはAIがやってますとかいう営業マンにころっと騙されそう。

502 ：
>>500

503 ：
>>500 携帯からだろ。　俺もそう打ち間違える頻度が半端じゃない。　だけ打ち間違えるんだな。

504 ：
>>477
月ひゃくまんくらい。シナリオ作成と実行ワンセットね。
シナリオ実行するだけでも一台あたり10万とかかかるっぽくて一台にまとめないと使えない。

データ打込みの定型業務やってる扱いになってるけど…（言うて派遣半人分の作業量）
データ自体は社員（派遣も一緒に）がゼロから作る品物だから、構成表と打合せで済んでたのを
しっかりしたデータパッケージに落としこんで正確に作る必要が出た。

505 ：
>>504
RPAは何を使っていたの？
UiPath? Blue Prism? WinActor?

506 ：
>>497
VBAも超簡単なんだよ。
「マクロの記録」で、操作を記録してくれる。

でも、それを元にしたコード見せられるとウンザリ。
大昔に、そういうコードをメンテナンスする仕事をしたことあるが見た瞬間に全部消したくなる。

507 ：
>>505
ういんあくたーだね。
別部門の上層部の方々はJavaアプレットで動いてるシステムの自動化に適用できるつもりだったらしい（多分その上層部システムを触ったことすらないと思う）

508 ：
>>504
月100万円か これは貴重な体験談だね
実行するのに1台10万円ってのは使いづらいね

意外とシステム化進んでて定型化できない業務しか残ってないって感じかね にしても経営層が現場の意見聞かずにGOしたのかねぇ

509 ：
いや、vbaは如実に遅いでしょ…
コンパイル言語に書き直せば10倍とかの差がでるよ

510 ：
>>506
VBAはマクロの記録があるから超簡単って言う人よくいるけど、仰る通りマクロの記録なんかじゃ使い物にならんわけでしょ？
それなら、VBAは超簡単なわけではない、とみなした方が良いのではといつも思うわ

511 ：
>>507
ありがとう

WinActorは不器用なのに値段がするからね
UiPathなりBlue PrismだったらRPAに対する感想も違ったかも

NTTデータの知名度でWinActorを選定してしまった会社はホント可哀想

512 ：
>>510
その通り。
だからRPAも...

という話なんだな。

513 ：
>>512
GUIの操作を記録するマクロの記録とRPAにどう類推が成立してるんかね RPAはVBAにおいて(コードを打つのではなく)マクロの記録に相当するってわけ？

むしろRPAは素人を初級(基本的な構文を覚えたレベル)までブーストしてくれるイメージなんじゃね

514 ：
>>504
ライセンス数はどれぐらい買った？
末端のおばちゃんにも行き届くぐらい開発者ライセンスを買ったのか
チームを組んで少人数分の開発者ライセンスを買ったのか

515 ：
>>508
システムが独自開発品で
設計が悪く自動化にトコトン向いてないのが実情

業務改革的な部門が導入決めて各事業部門に使えって押し付けてきた感じね
現場の声は初期コスト高いけどシステム一新してくれだよ

>>514
１部門で開発実行一式のみだなー。効果でそうなとこだけ、実行のみのライセンスおばちゃんに配る感じ。
開発側を触る人は限られてるからほんしつとはずれてるし明らかに投資効果には見合わないって感じるね

516 ：
>>515
おー、ありがとう 体験談はありがたい 絵に書いたような失敗パターンっぽいね
・システム側の改善が望ましいが場当たりのRPAに手を出す
・誰でも開発できる謳い文句のRPAで開発権限が限られる(まぁこっちは限定した方がいいって言う人も多そうだけど)

上が現実見れてないっぽいから成果出てないとかシステム改修しろとか言うのも怒りそうやし仕事だけ増えて地獄やな

517 ：
>>515
1ライセンスで事業所内の何人でも何台でもOKならRPAの構想にマッチするのにね
おばちゃんとパソコンの数に依存して金がかかるんじゃ本末転倒
ベンダーはライセンス料金をスケールによらず固定にすべきだ

518 ：
BluePrismだと1ライセンスで何台でもインストールは出来るけどね。
同時に立ち上げられるのは一台だけだけど、時間をずらせば別の社内PCやサーバーで
別タスクを走らせる事が出来る。
3ライセンスあれば、実行用と開発用には使えるかな。

519 ：
>>513
比較がおかしい。
RPAはVBAに相当する。
だからおばちゃんが簡単に組めるなどというマクロの記録に相当するような組み方じゃあ駄目と言ってる。
素人を初級までブーストしてくれるってのはマクロの記録が正にそれ。

520 ：
>>519
マクロの記録に相当する組み方？
これ埋めてよ
VBA＝RPA
マクロの記録＝
初心者によるコード作成＝
プログラマによるコード作成＝

521 ：
VBAっつってもExcel VBAとWord VBAでしか通用しない話なんだよなこれ

522 ：
>>518
同時に立ち上げられるのは1台だけって面倒やねえ
スケジュール実行にする場合はいちいち被らないように社内調整しないといけないし、トリガーを人力(ボタンクリック)にする場合はたまたま時間帯が被ってたら実行できないのか
トライアンドエラーで気軽に実行と修正を繰り返せるのが売りだと思ってたんだが、それも占有しすぎで怒られたりするんかね

523 ：
>>520
これまでの話で分からんの?

厳密に言えばそれぞれが完全に一致するわけじゃ無いけど。

マクロの記録のような初心者のコード=素人のおばちゃんが作るようなコード

プログラマーによるコード作成=RPAのことをよく分かってる専任のプログラマーを高い金で雇ってコード作成

524 ：
よくわからないけどrpaと称して改めて業務の棚卸とBPR、BPOが進むのは何千万の価値はあるわ(笑)

525 ：
無料のBPMシステムとGUI操作系ツールを組み合わせるんじゃダメなのかい?
RPA製品のやってることってほぼそれだけだよね

526 ：
>>524
なら実際にはRPAを導入しなくても良いんじゃね？
RPAを導入する予定があるからプロセスを整理しろって言えばいい

527 ：
だれか今まで挙ったRPAの問題点を箇条書きにしてくれんか？

528 ：
>>527
なんでお前がやらないのか

529 ：
>>522
その場合は複数ライセンスだな
ウチの会社は実行用RPAは24時間割り振って動かす用と都度トリガー実行用、開発用の3種類に分けて使ってる
都度トリガーの調整と言っても、一回あたり数分～数十分程度だから今のところは困ってない
トライアンドエラーは開発用でやってる

あ、ウチの場合は少人数のRPA開発専用チームがあって、各部署のRPAを作成してる

まだトライアル的な部分があるから、今後拡張して続けるのか、止めるのかは様子見状態

530 ：
少数精鋭スタイルだと社内の趣味グラマ探してやらせたほうがコスパ良さそう

531 ：
>>523
マクロの記録作コードと素人おばさん作コードが似ている似ているって主張するだけで、どういう点で似ているか根拠を示してくれてないじゃん

マクロの記録なんて繰り返しとか条件分岐とかすらまともにできないでしょ 初学者用のテキストに必ず載ってる初歩すら実現できない

一方、RPAはできるわけで↓ このような実現できる内容的にRPAは「(VBAの場合で例えると)初級者によるコード作成」に近いと言ってる 構文は知ってるけど、効率性やメンテ性の作法を知らないくらいの意味ね

【できるUiPath】ExcelのデータをWebアプリに自動で入力。UiPath Studioで繰り返し処理を行う | できるネット
https://dekiru.net/article/17690/

532 ：
そうだよね、少数精鋭で完結するならRPAじゃなくて良いような… 後で一般社員にも展開する見込みがあるとかならわかるかなー
RPAのウリって「作成者＝利用者」っていうとこだと思うのよね 距離が離れれば離れるほど、頼みづらいから多少不便でもいっか、となりがち

533 ：
そこそこできる方のプログラマでもRPAの力を借りなければ自動化は実装できないという現実。

534 ：
>>531
あのねえ...

似ているんであって、完全に一致してるわけじゃない。
マクロの記録そのものじゃない。

だいたい、そのRPAの例って超簡単じゃねーだろ。
それが超簡単ならマクロの記録じゃなくてVBAも超簡単だろ。

535 ：
そんな事より、みんなでpythonやろうぜ！

536 ：
RPAの作成者はスーパーハカーでも事務のおばちゃんでもなくそこそこ出来るプログラマ、という案を提案したい。

537 ：
>>533
えっ？

538 ：
>>525
このスレの中でも混在してるけど、トップダウンでプロセスの見直しからやらされる人と
自分の作業を効率化したいだけの人ではツールも発想も違うよね
無料のBPMシステムって微妙にどちらにも採用できなさそう

539 ：
>>533
どんな現実なんだよ、、、、

540 ：
>>533
ｗｗｗ

541 ：
>>535
ここのウンコPGが商用RPAレベルを作れる訳ねえわ
画像認識とかやってもどうせ糞精度w

542 ：
>>538
トップダウンじゃなくてもプロセスの見直しは必須だと思ってるよ
今の業務のまま自動化なんてナンセンスでしょ

現実的にはやっぱり
>>530の言う通りかもしれんな。。
趣味グラマーによる他部署横展なのかもしれん。
趣味の人可哀想だけど

543 ：
>>534
だからさ… 似ている点を示してくれよ
こちらも完全に同じとは言ってないから「完全に一致してるわけじゃない」と言われてもそらそうよとしか思わんよ
こちらが言ったことにその都度その都度イチャモンつけてるだけじゃん

544 ：
このスレでまともにRPAを使ってみた人ってどんだけいるんだ？
特に否定的な意見の人達。
もしかして憶測？

545 ：
>>518 どんだけの小企業だよ。

546 ：
UiPathライセンス有るけど、「うぜえ…コードで書かせろ…」と思った
各社からのPDFの請求書をUiPathロボのメールアドレスに転送すると
「共有Excelに書き出しましたので確認ください」とか「未対応のフォーマットです」
とかメール返ってくる
溜まったExcelはコピペで会計システムに放り込める
俺氏は逃げたので対応フォーマットを増やしてる兄ちゃんがいる

547 ：
>>543
???
既に示してるだろ。
荒らしたく無いけど頭悪いの?
今までの話の流れで分からないんじゃ話にならんよ。

548 ：
簡単だと言って素人が組んだものは、どれも碌でもない。
よってRPAが簡単だと言って飛び付いたような所は碌でもないものばかりになる。

プログラマーってのは腐ったコード書くとこき下ろされるし、自分も物凄く恥ずかしい。
今だにプログラミング方法論で喧々囂々の議論がされるほど各々拘りがある。
素人が同じような考えで組めれば良いけどVBAの例で分かる通り、多分そういうことにはならんだろう。
動けばOKなどという奴の組んだものがまともになる筈が無い。

549 ：
明らかに業務中にレスしてる人暇そうだね
その時間でpython覚えたらいいのでは？

550 ：
>>549
4末で会社辞めたんで、暫く暇だね。

551 ：
巷で、RPAは確かに過大評価されてるが、
導入方法を明らかに誤った企業が「使えねー」と言ってると弁護してやりたくなる

552 ：
NTT-ATのRPAソフト「WinActor Ver.6.0」、Google Chromeの操作自動記録に対応
https://cloud.watch.impress.co.jp/docs/news/1183377.html

NTTデータ、前期純利益14%増　企業向けシステム開発好調
https://r.nikkei.com/article/DGXMZO44583430Z00C19A5DTD000

553 ：
素人が使うと意味不明な使い方して使えねー
プロが使うと足かせにしかならず使えねー

いったい誰がターゲット層なんだ？
マーケティングの段階から失敗してねえか？

554 ：
>>547
同じ言葉返すわ あなたは「それ感想ですよね」ってことばかりよ 主張↓だけ言ってて根拠が示されないんだもん

＞ 素人を初級までブーストしてくれるってのはマクロの記録が正にそれ
＞ マクロの記録のような初心者のコード=素人のおばちゃんが作るようなコード


私が言いたいのはこういうことね
RPAは主体的に初級レベルの操作が作れるという点で初級プログラミングに例えるのが適切である(gui操作の再現でしかなくできることも少なくコードの吟味なぞ不可能なマクロの記録ではなく)

初級までブーストされれば面白がって作法を学んだり周りと相談しあったりしてレベルも上がるという好循環が生じる可能性がある(これは普通のプログラマと同じね >>548 で触れてらっしゃるような)
もちろん初級プログラマが事務部門に大量にいる世界ってのは(VBAですら実現できてない)未体験の領域なわけで実際どうなるかは善し悪し含めて色んな可能性がある これは単なる一例ね(これを否定しても意味ないよ)

あなたの言ってるマクロの記録の例えだとこういう可能性はゼロになってしまう どう例えるかで議論が変わるわけ だから何に例えるかの根拠を聞いてるのよ

555 ：
そもそもみんな馬鹿だという視点で考えてみれば良い。
(利口ならPython が使える)

RPAだと言えどもマニュアルの通りにやって、つっかえつっかえすればもうやらないよ。
やっても全く動かないだろうな。

556 ：
>>555
真理をついてる感じがする

557 ：
>>544
逆にお尋ねしたい。
現在自動化ソフトを作成・運用しているからRPAが便利なのは分かる。
エディタもちゃんとしたのが付いているだろうからね。

しかしそれは人力で行っていた作業を置き換えた時の話。
大抵の場合はRPAの処理をシステムに取り込む事が可能で更にパフォーマンスも上がる。
しかも商用RPAは毎年高額なライセンス料が発生する。

それでも尚商用RPAを導入する価値はどれ位ありますか？

558 ：
rpaの処理をシステムに取り込むための工数の対する費用はいくらなの？

559 ：
社会人になっても会社に属しながら勉強できてる層ってリテラシーとか相当上位だと思うの
世の中案外ばかばっかでも回ってるんだなあって働き始めて７年目の感想

560 ：
・開発や実行は無料のツールを使う
・金はRPA以外の代替困難な有料サービスやAPIに使う
・プログラムは出来ないではなく出来るはずだと考えまず着手する
・普段してる学習の何割かをプログラムに回すだけ
・普段から学習してない怠け者は解雇せよ

561 ：
いつやるの！？

562 ：
明日できることは明日でしょ。

563 ：
>>558
自社製なら社員の時間給分だけ。
場合によっては2～3時間で済む場合もある。
手入力している項目をTSVに置き換えるのはそんなに手間が掛からないよ。
主要な処理はそのまま使えるからね。

外注だったら足元見られるかもね。

564 ：
じゃあなぜ今までやらなかったの！？

565 ：
>>559 馬鹿じゃなくても会社の日常に埋もれてしまうと、利口も馬鹿もやってる仕事の80％は同じ。

566 ：
明日できるからいいだろ。
今日しなきゃいけないことで手一杯なんだよ。

567 ：
やらない理由は経営上の判断かな
正解がわかってても実際にやるには大変なんだよ
バカを説得してハンコを集めるの怠いから見送り
そんなんばっか

568 ：
しかしさ、RPA を導入してる会社がハンコを使ってたら笑っちゃうよな。
まずそこからやれよ。

569 ：
ハンコはせめて電子印鑑にしろよな。

570 ：
>>564
他はともかく俺は情シスの開発環境を借りてやったよ。
もちろん成果も出した。

571 ：
UiPathコミュニティ版使ってみたが思ったよりプログラマ寄りだな
これを使いこなせる事務員はエンジニアとして働かせた方が良さげ

572 ：
これがメンタリズムです

573 ：
前にも少し話題になったがUipathから入ったやつとWinActorから入ったやつでRPAの印象大分違うんじゃないか？

574 ：
素人には難しすぎて挫折
プロにはただの足かせになる
どうすりゃいいんだこれ

575 ：
>>574
育てろ

576 ：
てかそもそもお前ら優秀な感じで書いてるけど、SEだってピンからキリまでおるからな
それこそRPAの方が優秀のパターンだってありえるだろ

577 ：
>>575
育てる前提ならプログラム覚えたほうがいい
他に流用できんからやめたら全てが無駄になる

578 ：
流用できんというのがよくわからんな。
論理的な思考法という点では応用効くだろ？

579 ：
>>578
例えば？

580 ：
まあ育てるっつってもRPAも含めプログラミングの類はど素人から一人前になるまでに5年10年かかるからな。
難しいところではある。

581 ：
>>579
処理の流れとか考えるのはRPAもプログラミングも全く同じだろ？

582 ：
プログラムのほうが遥かに効率よく論理的思考力を養えそうだ
RPAはアルゴリズムはほとんど使わんだろうからね

583 ：
>>581
頭を使うようなロジックは部品に隠蔽されるからほとんど訓練にならんと思う
どこにあるかわかりにくい目的の部品を根気よく探す忍耐力とかは鍛えられるかも

584 ：
RPAはレスポンスがわかりやすいから作ってて楽しい。
動くもの作ってるって手ごたえがある。
それが素人を成長させる。

585 ：
>>554
ちゃんと人の書いたことを読め。

>初級までブーストされれば面白がって作法を学んだり周りと相談しあったりしてレベルも上がるという好循環が生じる可能性がある

VBAで同じ状況が否定されてる。
「マクロの記録」だけを特別視してるようだが、繰り返しや条件分岐を含んだものでも初心者レベルじゃ糞ばかりだ。
だから完全に一致していないと言ってる。
まあ、やってればレベルは上がるだろうね。
腐ったプログラムを量産しながらな。

>もちろん初級プログラマが事務部門に大量にいる世界ってのは(VBAですら実現できてない)未体験の領域なわけで実際どうなるかは善し悪し含めて色んな可能性がある

事務部門のおばちゃんが手を出さないようなVBAに手を出してる人ってのはむしろレベルがかなり上。
で、そういう人の書いたコードの殆どが糞なのが現実。

586 ：
糞なコードをざんざん書き散らしたあとで初めて綺麗なコードが書けるようになるんやで？

587 ：
だいたいさ
プログラマってフローチャートを書くのでさえ死ぬほど面倒くさいと感じるんだよ

箱を作って属性入れて線引いて～って一生懸命マウスをポチポチポチポチ延々と時間かけてお絵描き
それで時間の感覚がなくなるくらい集中してようやっと出来上がるのがコード換算にして100行に届くかどうかみたいな想像を遥かに下回る短いフローなんだよな
え？あんなに頑張ったのに…たったこれだけ…？嘘だろ…ってな
それでこんなんじゃバカバカしくてやってられんって開発されたのがPlantUMLやMermaidみたいな簡易なテキスト記法から図を生成すりツールなんだな

プログラマってのは一般職とは桁違いに大量のグラフを作図し続けてきた作図界のエリート集団みたいなものだ
そして世界中のプログラマ達が出した答えが「GUIは非効率的なのでテキストでやろう」これなんだな

588 ：
>>586
だから、最初に言った通り。

RPAが駄目なんじゃない。
これで夢のような未来があると思ってる奴がアホ。
実際にはまともに組めるようになるまで長く苦しい修行が必要ということさ。

589 ：
なんか意見が入り乱れててどれが誰の発言だかよくわからんな。
まあ匿名掲示板だからしょうがないかもだが。

590 ：
>「GUIは非効率的なのでテキストでやろう」
プログラマー離れてだいぶ経つけどすげー分かるわ

591 ：
RPAは日本ではここ最近だけど、海外では2000年代初頭に生まれて、一応生き残っているんだよな
ホントに非効率で使い物にならなかったらとっくに絶滅しているだろう

592 ：
UIPathは一見GUIに見えるが書き心地は非常にテキストに近い。
フローチャートもあるけどそっちは使わなくていい。

593 ：
>>591
ベンダーロックイン

594 ：
ちゃんと教育を受けたプログラマーには物足りなくて
ろくな教育を受けてない事務員には使いこなせない

インターン受け入れて学生にやらせるのが適当

595 ：
>>586 VBAでいくら書いたって綺麗なプログラムなんて書けないよ。
綺麗なお作法を覚えるには、それなりの礼儀作法が必要とされる言語で書かないと。

初心者にはPython が一番良いだろ。

596 ：
このスレにはUIPathユーザ多いよな？
>>592の援護、頼む。

597 ：
>>587 おいおい、現代でフローチャートを描いてるプログラマなんているのか？ 俺なんか半世紀前に書かなくなったよ。
どうしてもドキュメントが必要だと言われれば、オートフローチャートで出力してたこともあったが、そんなことも言われなくなったな。

プログラム上のコメントが一番だよ。

598 ：
UiPathは大人のScratchって感じ
しかも売り上げ5億以下の会社なら無料で使える
実際の業務を自動化するっていう喫緊の課題に対してコミットするからモチベも保ちやすい
ついていけない奴はそもそも論理的思考が向いていない。脱落してもらうが吉
生き残った奴はプログラミングの基本構文がわかってくる頃にはもうロジック組むのが楽しくなってるはず
ここでRPAをデリート！！pythonに移行！！！！！
ぼくのかんがえたさいきょうの1億総活躍戦略

599 ：
>>585
あなたもちゃんと読んでね 根拠を書いてくれって言ったのに主張を声高に繰り返すだけで↓ その主張の根拠はひとつも書かないんだもん 主張と根拠の区別がついてないのかな

＞ VBAで同じ状況が否定されてる
＞ で、そういう人の書いたコードの殆どが糞なのが現実

否定されてるという根拠は？ 同じ状況というけど事務部門にVBAできる人が大量にいる環境ってあった？ コードの殆どが糞だという根拠は？

別に定量的な根拠でも定性的な根拠でもなんでもいいけどね あなたの経験上そうだって言うならそれでも構わないけど、「どういう仕事をしてきて、どれくらいのVBAユーザーと関わってきて」とか書いてくれればそれはそれで有意義な情報になるだろうね
現状のあなたは「クソはクソだ」って叫んでるだけよ

600 ：
データベースをCUIで構築しろ、パソコンをCUIで操作しろって言われても無理ってなるけど
AccessやExcelで(なんちゃって)データベースは作れるし、Windowsは操作できる

GUIは偉大 まぁ言い過ぎだろうけど基本的にはそういうイメージだと思うけどね

601 ：
>>597
おじいちゃん！

602 ：
フローチャートの最大の欠点って、ちょっとアルゴリズムが複雑になると
結局図で見ても全然わからなくなることなんだよな
複雑なものはどう表現しても複雑
当たり前のことなんだけどな

603 ：
>>602 そう、プログラムをわかりやすく書いてコメントを丁寧につけることが一番。
フローチャートなんてなんどもメンテナンスしていくと同時更新なんて不可能に近くなる。 詳細フローチャートは要らないな。

604 ：
でもRPAではフローチャートで作るんだろ？

605 ：
AはXという前提においてBだからYになるみたいな
原始的な論理式の組立が苦手な人が多いので、フローチャートは良い道具

606 ：
そんな複雑なのはRPAでは作らないのがいいだろう
あくまで業務改善ツールの１つて事だろ

607 ：
事務員の素人がつくったVBA見てきたけど、
マジックナンバーが多々あったり
変数がaとかbで命名されてて何に使ってるか分からなかったり
無駄な繰り返し処理が多くて遅かったり
適切に処理を関数化されてなくただひたすらメイン処理にすべて記述されてたり
可読性が恐ろしく低くインデントもされてない
そんなのばっかだったな。

608 ：
>> 607
あなたはどういう立場で、どういう職種の人達を見てきた感じ？


ちなみに、公務員の事務員を数年やってる私の感触としてはこんな感じ↓ 数百人程度接してきたかな

Excelを使える(初級 sum関数 フィルタ程度) 50%
Excelを使える(中級 vlookup関数 ピボット等) 40%
Accessを使える 9%
VBAを使える 1%

AccessとかVBAを使える人は向学心の特別強い人たちだからコーディングルールとかの作法にも気をつけてる印象 完全個人使用のものは別だが
こういう低レベルな環境からするとRPAは神だと思うよ

609 ：
>>608
自分の実感ともおおむね一致なのだけど、
vbaやる人のコーディングルールってハンガリアン記法とか変数を関数の先頭に全部書くとかそんなレベル
しかもコピペがベースだからあんまり統一したルールもない印象
個人とか周り数人レベルで使うならまあいいんじゃないのって感じ

610 ：
>>599
完全一致しか認めないバカとしか言い様が無い。
全然分かってない。

611 ：
>>608
そのVBA1%は職場にもよるわけで、10%の所もあれば30%の所もある。

で、その10%や30%の内で、コ－ドを見て、出来ると思うことが殆ど無い。

612 ：
>>609
コーディングルールもそうだけどね。
処理の内容が一番ダメ。

ピタゴラスイッチのようなコードなんだよね。
たまたま動いたという感じ。

他アプリの操作で言えば、平気でSendkeysとか使うのは見た瞬間にアウト。

613 ：
ようするに俺様スゲーって言いたいのかな

614 ：
そのようだね 手当り次第俺スゲーやってるね

615 ：
まぁここに書き込んでるSEは他の業種、経営層にマウント取りたいだけだからな(笑)

616 ：
sendkeysの何がいけないのか謎
キーボード入力イベント必要ならsendkeys以外の選択肢なくね？

617 ：
>>616
フォーカス周りで不具合出る
ウインドウへ確実に入力できる保証がない

618 ：
プログラマはシステムとの比較を念頭に置きがちっぽいけど、正しくは手作業との比較なわけだからなあ

619 ：
>>608
元々システム開発やってて情シスに移ってきた人間。

620 ：
>>617
そんなこと分かり切ってるが代替策ないんだし使わざるを得ないだろって話
keybd_eventなんてもっとひでえし
sendkeys後に要素値チェックいれるのが現実的じゃないかね

621 ：
SendMessageでは入力された事にならず、キーボードエミュレーションでしかだめな時がある

622 ：
>>619
どもども RPAを語るのにかなり適切な立場の人なんだね
印象としては誰かがテキトーに作ったのが残っている感じなのかねー それで情シス(RPA？)にお呼びがかかったとかかなー なんとなく
まぁもしお時間があればその辺の経緯もお願いします

623 ：
基本的にRPAを選択した時点でかなり追い詰められてると思う
RPAが良いか悪いかは置いておいてスタート地点が既に詰んでる

624 ：
>>608
>RPAは神だと思うよ
R
RじゃなくてR
お前公務員じゃなくて会社員だろ
ステマ情報書きこんでんじゃねーぞゴミクズが
その数字はRPAの良し悪しと何の因果関係も無いだろうが

そもそも成功している人間がこんな掃き溜め掲示板に
情報提供しにくるインセンティブなんてあるわけないだろ

RPA関係者なんて極少数
特定したら　ブチ殺しに　行ってやるよ

625 ：
馬脚を現したか

626 ：
やべえ奴いるな 1人かな
システム会社にリストラでもされたんかね

627 ：
www

そもそも、導入しようとしている人たちは、
RPAが良いらしいぜ、って情報を、
一体どこで見つけてくるんだろうね。

逆に、このスレに書かれているような現実も、
すぐにわかりそうなもんだが。

628 ：
>>627
広告とか営業とかからだよ
「導入してこの数字だけ効率化」みたいな検証方法を隠蔽して結果だけ提示するITメディアの記事は分類としては広告な
追い詰められてるから夢を見るのがよっぽど心地よかったんだろうな

629 ：
現実問題、RPAはノンプラグラミングでは無く
開発支援ツールといった位置付けと考えています。
エンジニアが使っても、pythonで1から作るよりはるかに開発効率がよく、短期間で量産できる点で優れています。
一般事務員ができる範囲としては、エクセルのマクロ記録レベルのものでしかなく、
その枠を超えた自動化はある程度プログラムを組めないと無理ですね。

630 ：
現実問題、RPAはノンプラグラミングでは無く
開発支援ツールといった位置付けと考えています。
エンジニアが使っても、pythonで1から作るよりはるかに開発効率がよく、短期間で量産できる点で優れています。
一般事務員ができる範囲としては、エクセルのマクロ記録レベルのものでしかなく、
その枠を超えた自動化はある程度プログラムを組めないと無理ですね。

631 ：
ごめんなさい、連投してしまいました...
>>622の方への返信のつもりです。

632 ：
>>629
エンジニアだけどGUIのプログラミング難しすぎて全く効率が上がらない
どうやったらあんなので開発効率をあげれるのか秘訣を教えて欲しい

633 ：
>>632
どのRPAツールを使っているかにもよると思います。
少なくとも、今使っているツールを使ってwebスクレイピングを実現するにあたって非効率と思ったことはないですね。
ステマっぽくなりたくないので、製品名は控えてさせていただきます。

634 ：
>>633
秘訣を聞いたのですが？

635 ：
こんなところで有益な情報を得ようとしている時点間違っていると思います。
自分の頭で考えられない人には、どんな魔法のツールを使おうが成果は出ないと思います。

636 ：
>>633
ありがとうございます 変な人はスルーした方が良さげですね

エンジニアも(分野によっては)RPAの方が開発効率が良い、ってのは斬新な意見ですね 実はRPAはエンジニア向きだった！？、みたいな スクレイピングだと要素の指定がしやすいとかでそうなのかな ちょっと調べてみます

637 ：
>>635
そういう誤魔化しじゃなくて秘訣を答えられないの？
まあどうせ実際にはRPAを使ってもいないんだろうな
だから答えられない

638 ：
ここRPAを流行らせたい人達がまあまあいる印象がある

自分は一度RPAの導入コンサルみたいな人のレクチャーで
無料版使って動かしたけどフローチャートぽいのをGUIで作って条件分岐とか例外処理みたいなのを体験したぐらい

感想としてはちょっと微妙かなって感じ
ウインドウハンドルつかんでメッセージ送ったりする方が楽で安定してるし、お金もかからんのではってことで全く学ぶ意欲が湧かんかった

639 ：
まあぱっと見RPAは夢の魔法のように見える。
事務員でも使えますは嘘だが、プログラマに使わせれば一定の成果は出すだろう。

640 ：
>>638
＞ウインドウハンドルつかんでメッセージ送ったりする方が楽で安定してるし

激しく同意
BizRobo使って画面掴もうとしても上手く行かない
IEの類いは動くけどsapやProActiveなんかはログインすら困難
バッチ組んだ方がマシに動く
相性とかクセとかがありすぎる

641 ：
太古のシステムでウインドウハンドル掴んで特定の要素にメッセージ送ろうとするとセレクターの解析がめんどい
RPAならそこんとこワンクリで解決するから単純な使い捨て自動化ツールをパパっと作るには便利だとは思う

642 ：
とりあえず動くじゃダメだ技術的負債だってやつがいるけど、まず動くことが大前提だからな。

643 ：
そもそも、すべてのオブジェクトに名前つけときゃいいんだよな。
IEでタグ調べて、innerTextが〇〇だったらクリック、
とかやってるけど、アホかと。

644 ：
>>638
＞ウインドウハンドルつかんでメッセージ送ったりする方が楽で安定してるし

RPAのGUIだけで作れば裏でRPAがやってくれそうなものだけど

645 ：
Japan IT Week春で感じたRPA業界３つの変化
https://rpahack.com/ai-rpa

646 ：
RPAでWeb画面の画像認識で動かしてるのがあったわ
デザインすぐ変わって速攻で動かなくなるわな

しかも「今週の通貨換算表」とかいうやつで
そんなんは銀行やら証券会社の会員画面からCSVで落とせるんや…

647 ：
bizroboがダメなんだろ

648 ：
>>612
すみません、もしよかったらアドバイス頂けませんか？

いまpythonとseleniumを使ってウェブページにsend_keysで入力しています
今のところは何千文字の入力を扱っていないのでいいのだけど、文字数増えるとsend_keysでは遅すぎるとサイトで見ました
入力速度を上げるにはコピーペーストのような処理をしたりするのでしょうか？？

649 ：
>>646みたいな例って
RPAの営業がRPAの営業しかしておらず、
顧客の課題解決の為の包括的な提案を出来ていないことに問題あるような　

650 ：
技術的なサポートは窓口あるんじゃないのかね

651 ：
>>621
ダメなのは知識が足りてないだけだ。
Sendkeysは制御出来ないから動作中にマウス触ったりして別にフォーカスが移動するなど最悪なことがある。
触らなければOKでも、そんなプログラム組むのは恥ずかしいと思わないようじゃダメだね。

それに「平気で」使うのはアウトだが、自分のスキル不足で仕方無く使うのはアウトじゃねーよ。

652 ：
>>648
あなたの言ってるのはSeleniumのsend_keysで、自分の言ってるSendkeysとは違う。

色々なSendkeysがあるが、どこに入力するかが固定されている(制御出来ている)なら問題とは思わない。
一方VBAで使われるSendkeysのように「どこに」が無く、その前に「どこ」の部分にフォーカスを移す等して制御しようとするものは、実際には制御になっておらず、動作中にマウスクリック等で別にフォーカスを移すとそこに入力しちまう。
勿論、それをさせないように頑張る方法があるかもしれないが、それを筋悪として却下出来ない人は、他のコードも推して知るべしだ。

653 ：
>>645
既にこんな導入されてんの？↓
導入から活用にテーマがシフト ＭＭ総研が2019年2月に行った調査では、年商1,000億円以上の大手企業で39％、年商1,000億円未満の中堅・中小企業では27％がRPAを利用

こういうのもあるのね↓
「誰でも使える・Excelの延長」を打ち出すSCSK株式会社のCELF RPAブースが盛り上がっていたのも印象的でした。CELFは1端末あたり年間利用料35,000円

654 ：
宣伝うぜー

655 ：
RPAって、RPAから始まったのかな。
オンラインゲームで、自動でモンスター狩るツールが元とかじゃなく。

656 ：
RPA業界の現状ってこんなところか？

- RPAを使うにはそれなりに技術が必要だと知れ渡ってきた
- 誰でも簡単にできるの売り文句は通じなくなってきた
- 誰でも使えると思ったけど実は難しかったRPAをゴミにしないためにどうするか?
　- RPA人材教育サービスを買う
　- RPA特化人材派遣サービス買う
　- 難しい既存RPAと比較して誰でも簡単なRPAを諦めずに探す

とにかく買わせてロックインさせて人材を送り込み長期間に渡って集金する
数多存在する既存のノンプログラミング開発環境と全く同じ手口
ベンダーの計画通りってとこかな？

どうせ後で高額なRPA人材教育サービスやRPA特化人材派遣に頼るぐらいなら
最初からpython教育したり通常のSEを雇ったほうがいいんじゃないか？
もう買ってしまった企業はもう止められず行くところまで行くしかないんだろうけど
これから始めようとしてる企業は先を見据えた賢い買い物をしてほしい

657 ：
>>656
＞- RPAを使うにはそれなりに技術が必要だと知れ渡ってきた
＞- 誰でも簡単にできるの売り文句は通じなくなってきた
＞- 誰でも使えると思ったけど実は難しかった

ここ同じこと繰り返してるけど、根拠は？

658 ：
>>652
VBAってSendkeys、SendMessage、keybd_eventの他に要素指定してキー入力できるプラクティスあったっけ？
外部アプリ操作にVBAを選択した時点で失敗してるって話なら納得だが…

659 ：
>>658
UIAutomationは？

660 ：
>>652
なるほどですね！send_keysと勘違いしていました…
いまは望んだ通りの動きを、プログラムがしてくれるので良かったです
自分のレベル上げられるよう頭使って書いていくね！ありがとう~

661 ：
>>658
SendMessageで何通りもあるし、キー入力前に対象にフォーカスを移さないと成功しない場合もあれば、フォーカス有ってもマウスカーソルがその場所に無いとダメな場合もある。

662 ：
>>659
UIAutomationの場合もフォーカスやカーソル問題はあり得る。

フォーカス問題で勘違いして欲しく無いが、フォーカス問題で入力出来ないなら良いけど、他へ入力出来るのは問題。

663 ：
>>662
マウスとキーボード操作するならともかくコントロールにテキストセットするタイプなら問題なくね？

664 ：
>>657
根拠は
①実際に自分で使ってみた感想
②同じく使ってみた人に聞いた感想
③教育や派遣が有料サービスとして成立して注目されだしてるから(誰でも簡単にできたら商売にならない)

665 ：
>>662
では662が考えるVBAで外部アプリを操作をする場合のベストプラクティスは何？

666 ：
>>658
IE限定で、getElement(s)By()。

667 ：
>>666
MS製品はDOM弄れるから自動化楽だよなあ
実情はIE非対応のサイトやらの都合でChromeかFireFoxが自動化対象になることが大半だし結局Selenium触ることになるけど

668 ：
スクレイピング目的ならJavaScriptを流し込むのが実は一番楽
seleniumはテストのために操作をエミュレートするって目的が強いから多少面倒なところがある

669 ：
javascriptというかpuppeteer

670 ：
>>27 そもそも3人の仕事がRPAです1人になるとしたらそれは、元々システム化されていないんだから、基本から見直すべきだぞ。
そんなことで喜ぶのでは無く悲しむべき事態だと思うけどな。

671 ：
>>664
返信ありがとう そういう根拠なら位置づけを限定的にすれば真っ当な話だと思う 「現状の問題点は」とか、「現状上手くいってないところは」とか

本題に入ると、意外と難しいにしても使いこなす人も出てくるはず 割合次第だけどそれだけで既にペイする可能性もある(ここがPythonなりVBAより敷居が低いメリット)
勿論殆どの社員が見向きもしなかったらまずは社内で対策やろうね 教育とか派遣とか含めて 推進部署がやらされるかな
それでもダメなら仰る通り外注だろうね ここまで来たら教育は効果なさそうやし 派遣も導入だけ１ヶ月数十万とかで済むならペイしそうだけど(RPA自体に月100万とかかけるわけだから)、恒常的にとなると仰る通り計画破綻かもしれない(勿論それでもペイする可能性はある)

金額の話になっちゃうと極端な話ケースバイケースとしか言えないから難しいね
「RPAがペイするかどうか」じゃなくて「ベストなのはどちらか」が重要だと言われそうだけど、経営者的に手を出しやすいのはRPAの方なんだと思う 理由聞きたければ別途聞いてくれ とりあえず長くなったからこんなもんで
賢い買い物して欲しいのはほんとそれ

672 ：
つかRPAに積極的に投資できる中～大企業ならフロア内にプログラミングできる社員数名は絶対に隠れてっからそいつら探したほうが早い

673 ：
（絶対面倒を押し付けられて現場で矢面に立たされた挙句にロクな対価もないから黙っとこ）

674 ：
ExcelのVBAだって、共用テンプレートには書かないよな
自分用のPersonal.xlsに書いて、使えるのは自分だけにする

675 ：
システム部がロングテール的な事務作業を自動化してこなかったのが悪い

676 ：
自動化したら職を失う人がいる
彼らに配慮してワザと手作業の余地を残した
日本企業はカンタンに首を切れないからそういう判断も時には必要

677 ：
特に政権よりの企業は雇用率維持のために頑張ってるからね

678 ：
よりクリエィティブなポジションに異動するんやで。

679 ：
RPA否定してるのも日本の雇用のためを思っているって事か！？

680 ：
>>672
>>673
ホントそれ。
俺も、見つかる(プログラムが書けるのがバレる)まで、5年くらいかかったわ。

681 ：
会社が探してるならとっとと名乗り出て待遇アップの交渉すべきだと思うけどな

682 ：
>>681
履歴書に得意言語書いたのに、しばらくバレなかったの。

683 ：
「待遇アップしてくれないとやりません」
（こんなやつだったのか）

「やるけど待遇アップしてください」
（しめしめ）

情シスの人より功待遇になることは無いと思うの
（情シスが厚遇されているとは言わない）

684 ：
サービス残業がまかり通ってるような会社だと、現場従業員達は日常業務だけでキャパオーバーしてる
そこへ「（現場と板挟みになる）新しい仕事を（タダ働きで）やりたい人この指とーまれ♪」と言ったところで
誰が立ち上がるというのか

685 ：
なんでタダ働き前提なんだ？
rpaへの投資をそいつらに割振れよ
通常業務は減らすに決まってるじゃん
キャパオーバーならpythonだろうがrpaだろうが関係ない

686 ：
確かに趣味グラマーはそれなりにいるだろうからそれを活かすスキームが作れれば最終的に安上がりだったりそれこそ商売になったりするだろうね

うちも社内コンペでたまに趣味グラムが受賞してるけど、賞金(待遇)は数万、それを元にプロジェクトが起こるわけでもなく、メンテも不十分 要は、継続性がない Excelレガシーの話とか上の方にいた趣味グラマーとかそういうとこが多い印象

理由は何だろうね 誰か分析して

687 ：
>>685
ぐうの音も出ない正論だわ
「サービス残業がまかり通ってるような会社」という前提を投げ捨てればの話だがｗ

688 ：
>>663
普通は、コントロールにセットするタイプでコードを書く。
しかしそれで動かないことがあって、フォーカスやマウスカーソルが無いとセットされないパターンと、フォーカスやマウスカーソルが無いとセットされてるのにその後の遷移で受けとらない場合がある。

689 ：
>>665
ベストなんて1つに決まるものじゃ無い。
まずUIAutomationでノーマルに動くならそれで、ダメならウィンドウハンドル、それでダメならキ－ボ－ドエミュレーションや画像認識を使う等になるだろうけど、それぞれの中でも何通りか試すことになる。

自分の認識ではUIAutomationはAccessibilityの上位互換だけどウィンドウハンドルの場合はどっちが上とかではないと思ってる。
例えばハンドルを持たないオブジェクトの場合はUIAutomationの方が優位だけど、UIAutomationはPatternにない操作が出来なかったり、何故か動かない場合もある。

690 ：
UiPathでもネイティブ、シミュレーション、SendMessageの3つから選べるな。
加えて画像認識も。使わんけど。

691 ：
あっごめんクリックの話じゃなかった

692 ：
>>689
ありがとう。
やっぱり一概にコレ！ってのはなかなかないよなあー
現状最もスマートと思われるUIAutomationですら不安定なとこあるし
なんにしてもトライアンドエラーで動くまで試行錯誤するしかないのよな

UiAutomationキマれば一番いいけど内部仕様コロコロ変わったりするアプリだと
ユーザー入力遮断してTabでフォーカス移しSendKeysが一番安定する場合もある

このへんの選定って勘と経験がモノ言う部分だし経験薄い人事務方が適切に設定できるかと言われればかなり難しいところだよね

693 ：
ロボットがGUIを操作するという前提条件がある以上
どうしてのアーキテクチャはダーティになるし仕様も動作も安定しなくなる
これはpythonかrpaかはあまり関係なくどうしてもハマるポイント
対策としてはapiやコマンドラインクライアントを使う(自社システムなら作る)しかないと思う

694 ：
PCってロボットなの？

695 ：
つまり普通のプログラム書けばいいって話だよな

696 ：
APIが整備されてるシステムなんてそんなないだろ？

697 ：
>>686
趣味では継続的な改善がなされないって分かってるからじゃない？
一時的な改善には一時金が妥当

698 ：
>>696
今は主要な外部サービスはほぼ揃ってる
社内システムはRPA分の投資を回したらいいんじゃねえか？

699 ：
>>697
別に趣味として取り組ませずに仕事として継続的に取り組ませればいいのに、と思ってな >>685 と同じような趣旨ね メンテしたり他のツール作ったり

もしかして趣味グラマーという言葉が誤解を招いてたらすまん 業務外(主に趣味)で身に付けたプログラミングスキルを持つ人、くらいの意味合いのつもりだった
会社にとっては教育コストかけなくて済むから好都合な人材であるとは思うんよね

700 ：
古い社内システムをベンダーに改修してもらおうと思うとDB検索ボタン一個追加するようなごく単純な機能追加だけですら云十万とかかってくる世界だしな…
RPAって最小構成なら年間100万以下とかだし、その費用をシステム改修に回したところで焼け石に水

C#なりPythonなり触れるエンジニアがいるなら手回して貰って、いないならRPA使うなりなんなりで既存システム騙し騙し使って
予算がついたらレガシーはごっそり更新するってのが現実的じゃね

いずれにしてもGUI自動化系の処理は繋ぎとして使うべきだなー

701 ：
古い社内システムこそ「巨大な技術的負債」だわな
そこにRPAでさらに「技術的負債」がくっついてくるわけや

702 ：
>>700
RPAに依存するほど既存システムの改修費用が膨れ上がっていくんだけど
その問題にはどう対処するの？

703 ：
RPAはその場でスクラップアンドビルド
作る費用ゼロだから負債なんてゼロだよ

704 ：
>>700
ええやん 小回りの効きづらいシステムと小回りの効きやすいRPAを組み合わせればええんや

705 ：
>>703
1週間で自動消滅する機能とかあったらいいかもね

706 ：
伊達みきおが居るな

707 ：
>>702
古いシステムは治すんじゃなく捨てるってことやで…
外部アプリで使いやすいように拡張しまくって、用済みになったらポイーってわけ
RPAに頼らざるを得ないようなクソシステムを治そうとすること自体が間違い

708 ：
>>700
システムを構築する＝工場を建設する、みたいな喩えかね
建築や改築するのは金がかかるから滅多にできない だから、個別に小さな機械(RPA？)を買ってきたり手作業したりする そうやって、古い工場を騙し騙し使いながらさすがにもう無理やなとなったらまた新しい工場を建設するみたいな RPAを上手く喩えられないかな

709 ：
>>655
JavaのWebアプリテスト自動化ツールは昔からある

710 ：
Java製のWebテストツールといったらSeleniumだな

711 ：
テストツールならそれなりの存在価値があるんだが、事務現場はそんなに定型的な利用じゃないし、利用してるプログラムもしょっちゅう変化してるから難しい。

712 ：
>>707
それなら最初から新しいシステムに移行したらいい

713 ：
にっちもさっちもいかなくなった最後の希望がRPA
これであと10年戦える

714 ：
10年の猶予の間に予算付けて次のシステム作ってくれたらなぁ

715 ：
>>708
RPAで例えると
異なる生産ラインを何も考えずにくっ付けて自動化きゃっきゃしてる感じかな
動線が潰される
メンテ技師が入れない
やたら電気代がかかる

716 ：
経営者は生産ラインの周りで働いてる労働者がロボットに変わった様なイメージを持ってそうだけどそうじゃない

717 ：
いいえRPAは神です

718 ：
RPAは救世主です

719 ：
わたしはRPA。すべての不要人材を消し去り そして わたしも消えよう

720 ：
RPAとはいったい…うごごご

721 ：
NTT東日本 千葉事業部、158業務にRPAを導入　約2万時間の稼動を削減
https://cloud.watch.impress.co.jp/docs/news/1184411.html

722 ：
2万時間を超概算で言い換えるこんな感じ？
20000時間 ÷ 1600時間(年間労働時間) = 12人分
20000時間 × 1000円(時間単価) = 2000万円

代金(1000万くらい？)と導入人件費とか考えると、とりあえずはトントン 今後はペイする見通しって感じかね(メンテの手間次第)

「稼働を削減」って不思議な言い回しだけど専門用語かなにかなのかな

723 ：
RPAソリューションを商品にしている自社導入記事より
それを信じて導入した人の実体験が聞きたい

724 ：
単純作業の自動化はやってもいい
やってもいいがRPA製品だけは使うな
普通のPG雇って普通のプログラミング言語を使って作れ

間違ってもRPA製品だけは使うな、便利と感じるのは最初の半日だけだ
あれはほんの少しでも複雑な業務になると一瞬で無能になる
そこからは無能ロボットの介護地獄が始まる

ここで普通の言語が使えればまだ救いはあるが
RPA製品で作っていると「ノンプログラミング」が完全に裏目に出て生産性が急減する

具体的には介護によって規模が増えると指数関数的に、それも従来のプログラミング言語よりも
はるかに大きなオーダーでシナリオの複雑性が増大する、理由はいちいち書かない。

RPAはスケーリングしないっていうのはまさにこういうこと

だったら最初からロケットマウス使ってそれでできる範囲で止めておく方がはるかに投資効果が高い

725 ：
そのうちMicrosoftがVisual RPAとか作って無料で配り始めるやろ

726 ：
>>724
落ち着け
単純作業といった直後に複雑な業務の話しとるぞ

727 ：
>>725
もうあるぞWWF
あとはレコーダーとか使ってお手軽にアクティビティつくる
無料でおk
年間1000万とかアホくさ

728 ：
年間10千万てソフト何？

729 ：
間違えた笑
10百万ね

730 ：
RPA否定派の常套戦術
・単純作業と複雑作業、事務員とプログラマ、通常と例外、などの区別を無視
・理由や根拠を書かない
・記事は宣伝ステマ扱い かといって代替ソースを出す訳でもない

731 ：
理由も根拠も書いてるが推進派がアマチュアだから理解できてないだけでは？

732 ：
>>730
区別を無視してるのは推進派だな
企業システム一部としてどうしたって考えなきゃいけないことを悉く無視している

733 ：
>>712
最初から新しいシステムに移行できる予算があるならそれがベスト
ただそれには最低でも1000万、下手すりゃ億単位の費用がかかってくるわけで・・・

そのシステム移行の予算を捻出するまでの”繋ぎ”がRPAや自動化プログラムってわけ

あとなぜかここではRPA＝年間1000万とか言われてるが、この基準はサーバー型RPA（blue何某やら）の金額であって・・・
クライアントタイプ（Win何某）は最小構成で年間100万以下で使える
開発ライセンス～70万、実行ライセンス～30万ってとこかな。

因みにここでよく名前の挙がるUi何某の年間費用はWin何某の半値くらい
おまけに年商5億以下の会社なら無料で利用可能

もちろん、社内にUiAutomation触れるような人材がいるならRPAなんかに頼る必要はないが、
仮にそんな人材がいなかったとしても年商5億超えの会社なら年間50万なんて屁みたいなもんだし
サポートが充実してる有能仕入先捕まえられれば”繋ぎ”としてのコスパはいいと思うよ

734 ：
WWFってWindows Workflow Foundation？
出来合いのプログラム用GUIが見つからない
GUIで処理を組み立てられなければRPAではないと言って良いと思う

735 ：
>>734
Visual Studioにあるよ。もちろん自動操作用のライブラリは入ってないからそのままじゃなんもできん
自動操作用アクティビティを自前で用意できるならこれでもいいかもね。現実的に考えて難しいけどね。

WWFに自動操作用のアクティビティ一式とレコーディングツールなんかの入力支援機能を追加したのがUi何某だね
作成画面とか全く一緒でびっくりするよ

736 ：
えらい人にVisualStudioのWFの画面とUi某を並べて見せて、
「Ui某はご覧のコレに色々被せたものですから、値段に付いてその辺よくご理解の上で」とか
Webから読んでExcelに書き出すのをUi某で書くとこんなになる、
一方コードで書くとこれだけで済む、
とか説明したところ、かなり熱も冷めたしどう使うかはお分かりいただけたのではないかと淡く期待してる

737 ：
RPAにまつわる社内的なすれ違いの根本的な原因は、経営と情シスの乖離よね
経営が予算を付けるなり情シスが汗をかくなりして歩み寄らないと、肥大化した糞システムと心中だ

738 ：
>>733
ようやくまともに導入している人の意見が出た感じだな

他はRPA？プログラミングの方が有能！みんなプログラミングやれ！て言ってるだけで前に進まない

739 ：
IT側としてはコードアクティビティは書くけど
それを使って実際書くのはユーザー部門ですよ、
外注で作るものじゃないですよ、
あたりが落とし所だろうなあと

あとはこれはバッドプラクティスなのでこうしてね、
みたいな負債回避を書いておくべきか

740 ：
>>733
システム刷新は別に全部いっぺんにやらなくてもいい
サブシステムに区切って価値の高いとこから小さく置き換えるってのを繰り返すだけ
なんなら刷新する価値が低いサブシステムは無理にやらなくてもいい
欲しいとこに集中して素早く刷新すれば繋ぎは別にいらんのだ

最小は最小
実際にこのスレでも小規模で導入して使いにくいって意見がもう既に出てるな
それとライセンス料以外にも金はかかるね

741 ：
>>733
非常に良い意見 具体的だし建設的

これって１台あたりの価格よね そうすると実行台数をまとめたがるはず 定時実行ならまとめやすい
一方、トリガーが一定でない単純作業はまとめづらいから向かないのかもな まぁ価格次第だけど デメリットじゃなくて単なる特徴づけの話ね

742 ：
やっぱり無料で簡単に小学生でも使えるプログラミング言語のほうが現実的だね

743 ：
>>740
もちろん全部いっぺんにやる必要はない。
現状で困ってる部分が10万そこらで改修できて以降は一切手直しの必要無しってんならわざわざRPAなんか入れる意義も意味もないな

だがそもそもそもの話、
>>サブシステムに区切って価値の高いとこから小さく置き換えるってのを繰り返すだけ
>>なんなら刷新する価値が低いサブシステムは無理にやらなくてもいい

ここでいう刷新費用をペイできないような糞サブシステムが大量に積み重なってボトルネックになってるから現場は困ってるって話なんだよね。
そこをなんとか凌ぐツールとしてGUI自動操作系ツールは使われるってわけ

例えるなら
ボロ家だけど使い勝手悪い所は都度大工にリフォームしてもらってずっと使っていこうよ　ってのが740の言い分だよね
対して
とりあえずヤバいところはDIYでごまかして、浮いた金貯金して新築買おうぜ　てのがGUI自動操作系の考え方なんじゃないかなあ。リープフロッグ現象的な感じ

DIYで使うツールがプログラミング言語なのかRPAなのかはもう使い手の技量によるとしか言えないね
プログラミング言語バリバリ使える人はそっちのが楽だろうし、経験薄い人はRPAとかの補助ツール使うほうが楽だし
うまいこと使い分けるのもありかもね。ぶっちゃけどっちでもいいんだけどね。どうせ繋ぎだし

DIYでなんとかなったからずっとボロ家使っとけばいいや！！　みたいなのが真に危ない考え方ね
元がボロ家でさらにDIYでツギハギなんていつかは破綻する　RPAでもプログラミングでも同じ話ね

744 ：
>>743 核心をついてる。 DIY でツギハギするにしてもスブシロがやるとやらない方がマシだったんじゃないかというくらい効果がなく、逆効果も多い。

それよりは、1人でも2人でもそれなりのRPA専任(多分pythonでやることになるだろうけど)の人間を置いた方がマシ。 その方がペイすると思うけどな。

745 ：
Python好きだけど配布面でメンドクサイのよね
C#とかで今作るとしたらWinAppDriverなんかがトレンドなのかな？？UIAutomationはさすがに枯れてそう
UWSC復活してくれれば一番いいんだけどなー

746 ：
>>743
しかし最後に言及したタイプのユーザーが多数派なのでは？
動けばいいじゃんでずっと放置してきたから藁にも縋る思いでRPAに手を出してるわけだからな
RPAに手を出したからってその習慣が綺麗さっぱり改善するとはとても思えん

747 ：
まともな(建設的な)RPA否定論ってどんなもんなのかね 試算でも経験談でも記事でもいいけど根拠と代案が明確なやつ

普通のプログラミングおじさんは大工になるのは簡単だみたいな教育コスト度外視の現実離れなことしか言わないし
現実的な話だと、何人かプログラマ雇う(社内にいれば使う)方がRPAより安い説くらいかね 根拠次第だが

748 ：
普通のプログラミング言語は無料の良質なドキュメントがいくらでも落ちてる
ユーザーが多いから学習を支援してくれるコミュニティも強い
学習環境の構築も無料でカンタン
当然だけど教育コストはRPAより遥かに安くつくんだな

何より無限の応用力と可能性を秘めた普通のプログラミング言語とRPAでは魅力が雲泥の差だ
くだらない作業の自動化なんて面白くもなんともない
勉強するなら一生使える楽しい道具の方がいいよね

749 ：
>>748
＞普通のプログラミング言語は無料の良質なドキュメントがいくらでも落ちてる
C++11or later では、そんな話はきいたことがありません…

750 ：
pythonとかなんであんな人気なのかわからんわ、人工知能方面とか。
なにがいいんだろ？ライブラリ？

751 ：
>>750
じゃあ何がいいの? perl? ruby? go? rust? shell script?

752 ：
>>751
rubyは好き。

753 ：
高速且つ軽量なLuaJITが好き
今はJuliaに期待してる

754 ：
プログラミングの話がしたい奴はどっかいけ
RPAの事例を聞きたいんじゃ

755 ：
>>750 RPA と同じような自動化が楽なんだよ。 何でもかんでも取り込めて相性が良い。
例えばExcel を扱うなんてVB よりまし。

覚えるのが楽。VB を教えるくらいならPython を教えた方が良いのでは？

言い換えればPython は、自動化ツールそのものではないかな。

756 ：
例えばpythonでIEを立ち上がてgoogleで「RPA」を検索するコードはどんな感じになるの？

757 ：
プログラミングを理解することはRPAを理解することにもつながる
中身一緒なんだから…

758 ：
ふーむIEを使うという発想がすでにRPAに毒されてるのかもしれないなｗ

759 ：
>>747
典型的な失敗事例だが、うちは1億円以上RPA導入コンサルみたいなものに払って何の業務効率化にもならなかったよ
ゴミが残っただけ

だから結果的にはその費用やプロジェクトにかかった時間で自動化できるエンジニアを採用したり教育した方がよほど良かった

760 ：
商用RPAを導入している会社は何台のPCに入れているの？
どんな作業をやらせているかも知りたい

761 ：
ソフトウェアは人間社会の複雑さを取り込んで肥大化していく性質を持つ

RPAでは高水準言語と違ってソフトウェアの複雑さに対抗する手段がない
おまけにソース管理、構成管理ツールの支援も受けられない

繋ぎに使えれば良いというが、そんな寿命の短いソフトウェアに存在価値はない

762 ：
>>758
from selenium import webdeiver
driver = webdriver.Ie(ドライバのパス)
driver.get('https://www.google.co.jp/search?q=RPA')

763 ：
>>759
導入責任者が一回でも実際に開発してみれば現実が見えるのになんで確認もせず突っ走っちゃうんだろ

764 ：
>>762

僅か３行。Win32 + C++だと200行はいるかも

765 ：
ほう、これは思ったよりはるかに簡潔だ。
なかなかやるね、python。

766 ：
なんかスペルミスない？
webdeiverってwebdriverだよね多分。

767 ：
それ以前にseleniumがないって言われる？
pip installしたんだけどな？

768 ：
お、動いたよ～
なかなかやるね、python

769 ：
>>763
上層部のゴーサイン出た後には、後に引けない中間管理職の必死さが現場の意見を無いことにする（うちも同様の失敗事例）

770 ：
ふーむ万事こんな感じで簡潔に書けるならpythonもありかもしれないな。
APIが用意されてないアプリをどう自動化できるのかはまだちょっと想像つかないが。

771 ：
>>769
うちはRPAの導入を目的化してて、効率化を目的としてなかったのが原因かな
発注した連中はitに詳しくないかつ現場などどうでもよくてRPAを入れさえすれば目的達成で、
RPAコンサルの連中は導入実績作りのためにうちをカモにしていた
利害関係はある意味一致していたから効率化が未達成なのは必然だった

772 ：
ワイはRPAの黒船が来そうな気配があったし、やりたい自動化はその手のアプリじゃ到底無理と思ってpython覚えたな
Rとかでもいいんやろうけど、ライブラリが一杯で探せば大抵何とかなるのはすごい

配布はしたくないし、する気もないから完全自分用だけどね
今では自動化でそれなりに時間浮かして、次のプログラムの勉強する時間確保できてるわ

773 ：
>>771
心中お察しします
うちも一緒や、導入が目的で入れることが成果なんだよね………

導入後に何ができるか考えたり、開発用にSEコンサルから連れてきてた
あとは現場が努力で数字を弄くり回して報告用の工数削減時間の捻出………って見てると色々仕事真面目にするの馬鹿らしくなるわな

774 ：
>>759
>>769
>>773
へー 失敗例は有意義だね せっかくだから詳しく語ってよ↓ (もしかしたら >>466 さんかな) 既に書いたのはいいので
にしても1億ってヤバいな こういう経験したらRPA否定派になるのもわかる気がする

・基本事項(会社規模 導入前の状況 システム化や手作業等々)
・導入詳細(費用 クラサバの別 台数 プロジェクト体制等々)
・導入後(導入後の状況、敗因、代案)
・気になるのが、上層部の浅はかさはさておき、一般社員がある意味勝手に「おっ、便利なおもちゃくれたやんけ 使いこなしたろ」ってなりうるのが長所だと思ってたけど、そういう動きはなかった？
十分合理化できてたか、RPAの敷居が高いかくらいだと思うんだけど…

775 ：
>>774
うん、聞きたい。
どのようなRPAがゴミになったのか、どういった業務はRPAすべきでなかったのかなど

776 ：
なんやこれ意味わからんわむずすぎ
つーか開発したら首切られるんだろ？
切られないにしても別のクリエイティブな仕事を要求されるとかムリムリ
ぜってーやんねーよみんなもそれでいいな？
いいともー

今までダラダラ単純作業してきた一般社員なんてこんな感じじゃないの？

777 ：
RPAなんて泥縄に頼らざるを得ないような粗末な会社の従業員は待遇が悪いから、当然会社を信頼していない
別分野の新業務に対して相応の報酬が支払われるなんて思ってないし、実際支払われたとしても寸志程度だろう
業務の最適化が終わったらさらに待遇が悪くなると考えるのも当然のこと、これで頑張る方が異常、そういう世界

778 ：
RPAはソフトによって性能がピンキリだからなー
Win何某はまだかわいいほうで、下手すりゃ画像認識で座標クリックしかできないような糞RPAもあるし
そんな糞RPAでも「他社には負けない、絶対の自信があります！」とか言って売られてるんだから怖いわ・・・

失敗事例の方は是非、何のRPAを導入したかも示唆してほしい

これから選ぶ人、
ttp://rpachallenge.com/?lang=ja
このサイトの目的のフォームに正確に文字が入れられるかどうかで大方の性能が評価できる。トライアル中にでも是非試してみてほしい

name属性が動的に割り振られたり、アクセスする度レイアウトが変わったりする糞システムを再現してる
腕試しにPythonでもやってみても面白いよ。

779 ：
>>762
urlのquery文字列としてRPA渡すんじゃなくRPAっぽく検索ボックスクリックしてRPAを入力、エンター（または検索をクリック）ってやると？

780 ：
>>778　面白いな。

781 ：
>>778
糞システムを再現www
草不可避だわ

782 ：
ブラウザ操作の自動化をseleniuumでやってます
今度はPC操作全般を自動化したいと思っていますが
みんなが知ってる以下の条件に合うのソフトやツールを教えて

・操作の記録機能がある
・自動生成したフローチャートやコードの手直しが少なくて済む

783 ：
UiPath
UWSC

784 ：
>>782 PyAutoGUI

785 ：
普通に考えて費用対効果が高いから 具体的には、導入費用〇円、削減が見込める超勤代や派遣費用△円、という見込みを立てて導入しそうなもんだけどな 流行りだからやっちゃう？みたいな感じなんかね ワンマン中小企業なのか？

配置転換とか首切りとか効率化後のデメリットが予想できると効率化するわけないってのは確かにそうだね
そこまで期待するのか、単に超勤削減程度を期待するのか(その程度ならやる人多そう)、そういったビジョンも求められるわけか 特に実行部隊が多数一般社員だしな

786 ：
>>785
具体的な機能一個も出してない状態で見積もり出してもな…
肯定派の皮算用には現実感がないんだよ
買ったらあとは何事もなく全て上手くいって幾ら儲かるって論調

787 ：
>>779
from selenium import webdriver
driver = webdriver.Ie(ドライバのパス)
driver.get('https://www.google.co.jp')
driver.find_element_by_name('q').send_keys('RPA')
driver.find_element_by_name('btnK').click()

788 ：
elemet_by_nameの引数のqはどこから来たの？

789 ：
あ、find_element_by_nameか

790 ：
>>788
インスペクタでポチポチしたら見えるよ

791 ：
ブラウザの要素の検証機能で特定することもできる
name属性が毎度変わるようなクソサイトには別のアプローチ考える
このへんは勘と経験がものいう部分

792 ：
>>790>>791
ふーむ、なかなか面白いなｗ

793 ：
エクセルとかもこんな感じでpythonで自動化できるってこと？

794 ：
>>793 Excel とPython は完全に相性が良いよ。

795 ：
HTTPって文字列のやり取りなのにわざわざwebブラウザ起動してボタン押すとかアホみたいよね

796 ：
>>794
VBAよりも？

797 ：
>>796
PythonはWebDriverをサポートしている
逆に言えばWebDriverが使えればなんでもいいって事
同じようにExcelならCOMが使えればいい

798 ：
ほほう、このスレ結構勉強になるな。

799 ：
Pythonバカは、都合の良いことしか考えて無いよ。
実際はどんな言語でも一長一短あるし、それだったらRPAの方が良いという結論に成りかねない。

実際はどんな言語でも良いし、RPAでも良い。
ちゃんと考えて組まれてるなら。

800 ：
>>793
Excel用のライブラリでセルごとに読み書きとか出来るよ
.Netでも出来るよ

801 ：
https://imgur.com/a/0RA039a

頑張った
ちなみにエクセル読み込みも計測時間に含む

802 ：
>>801
早すぎて笑う
C？

803 ：
>>783
>>784
ありがとうございます
各ツールの操作記録に記録できる操作対象の指定方法ですが

・UiPath
　画像
　座標
　ウィンドウやDOM

・UWSC
　画像
　座標

・PyAutoGUI
　画像
　座標

操作の記録時に、「操作対象の指定方法」を「画像認識や座標」だけではなく
「Windowsの画面の構成要素(ウインドウ)」で記録できるものはこの中だと

804 ：
推敲してたら書き込んじゃった

>>783
>>784
ありがとうございます
各ツールが操作記録時に記録できる「操作対象の指定方法」はどのような感じでしょうか？
↓みたいな感じで分かる限り教えてくれたらうれしいです

・UiPath
　画像認識
　座標
　ウィンドウハンドル
　DOM

・UWSC
　画像認識
　座標

・PyAutoGUI
　画像認識
　座標

805 ：
>>804
・UiPath
Ui element セレクタ自動生成○
　画像認識 座標
　ウィンドウハンドル DOM セレクタ自動生成○
Invoke Codeで色々できる

・UWSC
　画像認識 座標 自動生成○
ウィンドウハンドル DOM セレクタ自動生成△
PowerShell経由で色々できる

・PyAutoGUI
　画像認識 座標
PythonだしSeleniumやらUIAutomationCoreやらと組み合わせて色々できる

単純な楽さでいうとブラウザ、Windowsアプリ問わず最適なセレクタを自動生成してくれるUiPathが頭一つ抜けてるかな。ただGUI自動操作以外の部分がちょっと弱い。上で散々言われてることだね。

UWSCはIEやらExcelのDOM操作する分にはメチャ楽だけどWindowsアプリをちゃんと操作しようと思うとわりとめんどい。あとIE以外触ろうと思うと結局Selenium経由することになる。RPAとプログラミング言語の中間くらいの位置付け

Python、、っていうかプログラミング言語はなんでもできる代わりにセレクタも自力で解析せにゃならんからめんどくさい。
その代わり既存のライブラリ利用したり複雑な処理させる場合にはめっぽう強い。TesseractのOCRで出てきた糞微妙なデータをDBにあるデータリストとレーベンシュタイン距離で類似度算出して正確に分類～とかが簡単にできちゃう

小規模利用なら全部無料だし目的に応じて選択すべし

806 ：
>>770
それやるのがRPAだろ
馬鹿かよw

807 ：
>>802
C#+JavaScript

808 ：
uipathいいよ本当
適当に作っただけで作業ストレス軽減したわ
ちなプログラミング知識はない
月次業務の中で10時間くらい削減したかな

809 ：
>>796 一時Microsoft が、Excel マクロとしてpython を入れる事を検討していたことがあったが、現在のところPython の既存パッケージを使ってくれと言う見解見たい。

https://qiita.com/yniji/items/b38bc312e860027108ac
In the meantime, these are some great tools you can use like PyXLL and XLWings

Excel チームから名前を挙げられた PyXLL と xlwings ですが、PyXLLの方は優れた製品なのですが、商用で年 $330 の使用料が必要になってくるので、個人や一般的な会社で手軽に使えるものではないと思います。
それで、xlwings を使ってみました。使ってみると xlwings 便利なのがわかりました。

Excel で Python を使いたいのならば、xlwings を使いましょう。

python には、xlwings 以外にも次のような Excel を操作できるライブラリーが存在するので、それらもインストールしておきましょう。Anaconda の場合はそれらも標準でインストールされます。

openpyxl Excelファイル（.xlsx）の読み書きが可能
xlrd Excelファイル（.xls, .xlsx）のデータを読むことが可能
xlwd Excelファイル（.xls）にデータとフォーマットを書き込むことが可能
xlswriter Excelファイル（.xlsx）にデータとフォーマットを書き込むことが可能

(使用例なども書いてある。)

810 ：
>>808
経験談は参考になるからお時間があったらテキトーに語ってくれよ >>774 のあたり ノンプログラマーの話は少ない気がするし

811 ：
RPAって実装まで踏み込んで議論しにくいよな
グラフィカルだからコードスニペットを書き込んで議論とかできない
XMLを見てもなにがなんだかわからない
スクショは撮るのもうpるのも見るのも大変

812 ：
>>810
トライアンドエラーで自動化作れたことが良かった
今までの自動化システムだと、情シスと緻密な業務の説明、フロー作成などとにかく会議アンド会議だった。

uipathは自分でしかも費用対効果が少ない業務から適当に作って走らせることができた。
しかも業務工程の中の前後は手作業で本当に転記だけの中間工程だけとか

10分の作業だけだとしても、何個か作れば月次の忙しい時間の短縮はかなり意味がある。
精神的に(笑)

813 ：
RPAを一気通貫にさせるのが今の課題だね
後はよく書かれてるけど自分しかわからない負債にしない事だな

自分は好き系だけど、興味ない人への教育が大変

814 ：
>>805
かなり詳しい説明ありがとうございます
使用感がなんとなく想像できました
とっつきやすそうなUiPathを軸に他も試してみようと思います

815 ：
なんかこいつ中の人っぽい感じがする

816 ：
ステマなの？

817 ：
>>812
>>813
説明ありがとう 好きな人はプログラミング知識がなくてもできるし興味ない人はやらないってところか
繁忙期と閑散期があるタイプの業務だと特に作り置きしやすいから導入しやすそう

導入体制みたいなのはどうなってるん？「興味ない人の教育が大変」ってのも関係あるけど、製品導入して勝手にやれとかプロジェクトチーム組んでるとか、目標置いてるかどうかとか

818 ：
画像認識とか座標とかで自動化なんて汎用性無さすぎじゃね？
端末変えたら動かない

819 ：
例えばだけど、人間なら100%間違えずに使えるけどRPAじゃ絶対自動化できないシステムって原理的に作れるの？

820 ：
すまん、意外と哲学的な問題なのかもしれないｗｗ

821 ：
>>819
今のRPAはテキストを抽出してもテキストの意味を理解していないので、
例えば「これは人名？地名？商品名？」とかの判別は無理。

822 ：
>>821
人工知能まで含めて実装すれば可能かも？

823 ：
しろよ。実装。お前が。

824 ：
>>819
reCAPTCHAとか画像認証系も無理

825 ：
>>818
比較対象が手作業やからなー
毎日メンテしてるようなもんの手作業と比べたら、端末変更時のメンテくらいいいんじゃね

826 ：
人工知能実装とか最早RPAじゃなくて草

827 ：
>>821
> 今のRPAはテキストを抽出してもテキストの意味を理解していないので、
> 例えば「これは人名？地名？商品名？」とかの判別は無理。
それは人間でも100%の判別は無理じゃね？

828 ：
>>826
RPAと名乗ればどんなプログラムもRPAだぞ？

829 ：
>>819
チート防止でゲームが頑張ってる
ゲームだから人間でも100%は無理

実はEXCELでも人間は間違う
計算式をセルに書き込むのを忘れる
計算式を間違う
数字入れなければいけないのに、計算式で同じ数字がそのセルに表示されているのに気が付かない

830 ：
そうそう、自動化すればミスらない訳じゃないからね
ミス減らす工夫やらチェック、リカバリフローは必要

831 ：
人間なら100%間違えないタスクというのが実はない

832 ：
>>821
RDBである程度は補間できる

833 ：
>>829
人間はそのミスを逃さないために
確認プロセスを実行する

確認プロセスを自動化すれば良い

834 ：
事務のおばちゃんが作ったRPAプログラムは入力データのバリデーションまで真面目にやってくれるんか？
変なデータを送信しまくられたら困るぞ

835 ：
>>819
エクセルで作った用紙を印刷して
判子を押してからスキャンしてデータをサーバーに保存する作業

836 ：
事務のおばちゃんまでは作らせないよ
修正くらいはするかもしれんが

837 ：
末端の職員が人海戦術でRPAプログラムを作らないならRPAを導入する意味がない
スキル持ちの少数精鋭にとっては足かせにしかならないからね

838 ：
しかし末端の職員まで開発者ライセンスと実行ライセンスをばら撒くと高くつく
無秩序にツールを作られると管理不能になってあとで困る

どうすればいいんだ
このジレンマ

839 ：
そういう会社は勝手につぶれてくれ
会社をやめるという選択肢はあるな

840 ：
部署で1人でいいだろ

841 ：
ほんとお前らプログラミングは論理的とか言うくせに運用になると言われたことしかできねぇな

842 ：
>>841
まさにそうやな
お高いとか言う割には具体的な値段の話はしないわ、(お高いはずなのに検討した上で導入したであろう数多ある)導入事例は宣伝扱いだわ

843 ：
まあ普通にプログラム組んだらタダなわけで
最小規模でも100万からなら比較するだけ馬鹿馬鹿しいな

肯定派は具体的な数字に拘ってるが、数字を出してる記事にも問題があるよ
測定対象のシステムがオープンになってるわけでもない
運用体制も不明、開発者の人数も経験も不明、具体的な業務内容も不明、測定方法も不明
実験レポートとしては全く意味をなしてないのだけど、結論だけは数字で出してるから信用する？
前提も測定方法も結果データもありませんが、結果はこうですって言って信じるのは文系だけだろう
だから科学的な教育を受けてない連中はカモなんだよ
最低でも第三者機関が再現可能になるぐらいの情報が提示されてから数字を信頼しろ

844 ：
プログラム1から組む工数くらい考慮しようや

845 ：
プログラムのほうが工数も少ないな

846 ：
やれる人がやれることを、会社が潰れるよりましだから、仕方なく嫌々でもやる
とにかくやらないと、らちが明かない
やる人に、これなら出来るというツールを、せめて選ばせてあげよう

847 ：
はぁ…
東京都のレポートなり他のものでもいいけど詳細なレポートでも読んだら？としか

まぁそれだけ厳密な手法を取りたいなら別にいいけど、当然プログラミング側にも公平に適用してるんだよね
「普通にプログラミング組んだらタダなわけで」という主張について「最低でも第三者機関が再現可能になるぐらいの情報」を勿論提示してくれるんだよな これで上に言えるわ！ 助かる！

848 ：
>>847
ライセンス料のことでは？>無料

849 ：
>>847
数字をピックアップするとこんなところか？
・約3ヶ月かけて業務分析等々(業者共同)
・8回の研修(基礎5回+フォロー3日)
・1つあたり1時間～40時間かけて実装(業者支援)
・年間283時間の作業時間削減

850 ：
支援業者に実験じゃなく仕事として同じ作業を要求したら幾らになるか興味があるね

851 ：
>>849
「運用体制も不明」「具体的な業務内容も不明」とかは嘘だったってことね？

最低でも第三者機関が再現可能な代案はまだかな？

別に東京都のレポートの話してもいいけど、そちらの言い分だと数字自体が信用ならないから話しても無駄だよね それは主張しないってことでいいのかな？ 食い散らかすだけの人が多いから一応ね

852 ：
>>851
嘘？
そのあたりは読んでもよくわからなかったね
概要しかわからなかった
あれで第三者が検証用のロボットやプログラムを書けるならそいつはエスパーだと思うぞ

853 ：
さっきも言った通りこれだけじゃ全く検証しようがないから信用はしない
しかし信用したとしてもこのスコアではな……
推進派の人はこの数字で満足なのか？

854 ：
・公開されたシステムで行う
・人力で作業する際の手順書を公開する
・作成したロボットのソースを公開する
・検証したテストデータを公開する

実験なら少なくともここまではやって欲しい
そうしたら実験結果を信用できる
別に難しいことじゃないと思う

本当は業務分析や教育の費用も余さず公開して欲しいが
そういうのは公開されても検証しようがない(人や業者の能力に依存し変動する)からまあいいや

855 ：
>>851
俺は数値以外信じないぜ！
そのレポートの一次資料共有してくれ

856 ：
RPAチャレンジというサイトがあるがああいうのでいいんだよ
あれを現実の業務用クソシステムにもっと似せて
良くある業務パターンごとに多数用意する
そうすれば導入検討を考える企業も気軽に検証しやすくなって嬉しい
RPAを推進したい人も誰でも検証可能かつ具体的な数字を使って宣伝できるから嬉しい

857 ：
uipath academyのレベル3受けた奴いる？
あれむずかしいのかな
非エンジニアなんだけど理解できるかな

858 ：
RPAチャレンジ試してみれば顕著だが ああいう単純なGUI自動化だけで言えばプログラミングよりもRPAのが早く組めるんだよなー
主に解析部分で差が開く。自動でセレクタ生成できるか否かの差は大きいよ
ただ完成品を比べると当然プログラミング産のが実行速度は早い
一長一短だし、どっち使うのが適してるかなんて何をやりたいかで変わるしなあ
その辺の判断含めて、RPA売るだけが目的になってない、まともな支援業者捕まえるのが良いね

859 ：
だから、厳密にやりたいなら構わないけど、じゃあ厳密な代案出してくれんかね？

だいたいそちらの言うレベルで詳らかに企業が開示するわけないじゃん メリットは何？金になるの？わざわざ社内情報晒して 難しくないって言うなら自分でやってどうぞ

東京都のは全庁に展開したら話は別だけどね 所々書いてあって端的なのがここね↓ 批判するならまともにしてどうぞ
https://i.imgur.com/bRA7lsG.jpg

文句言いたいだけやな 反論しやすそうなとこだけつまみ食いして食い散らかすだけ

860 ：
>>859
代案は出してんじゃん読めよ

誰でもアクセスできるオープンなフェイクシステム
そのシステムを使った人力の作業手順書
その人力作業を自動化するロボットのソース
ロボットに食わせるテストデータ

これ用意するだけだろ？
誰でも検証できるようになる
真実の数字を知りたけりゃデータとロボットをダウンロードして実行すりゃいい
これ以上に公正な検証方法があるか？


下の画像はお前が何を言いたいのかわからん
何が具体化されたんだ？
その画像を見れば第三者が検証できるようになるのが？

861 ：
>>860
いや、検証のための代案じゃないよ RPAじゃない業務効率化ツールの代案ね 信用に足る代案どうぞ

検証はそちらが勝手に言い出してんじゃんw やってみれば？

全庁に展開したら△1,275 △1,443 つまり、20倍以上の効果が出るものがあるって書いてあるじゃん 少なくともそちらの挙げてる283時間なんてもんじゃない効果が期待できるって書いてるわけだよね 分からないかな

862 ：
>>859
コストが書いてあるページないの？
というかなんで出し惜しみ…

863 ：
もういいわ鈍臭い
http://www.metro.tokyo.jp/tosei/hodohappyo/press/2019/03/27/19.html
http://www.metro.tokyo.jp/tosei/hodohappyo/press/2019/03/27/documents/19_01.pdf
http://www.metro.tokyo.jp/tosei/hodohappyo/press/2019/03/27/documents/19_02a.pdf
http://www.metro.tokyo.jp/tosei/hodohappyo/press/2019/03/27/documents/19_03a.pdf

期間は5か月と書いてあったけど人数が分からん
どこだ

864 ：
>>861
へー出る「かも」なんだー

865 ：
>>858
UiPath初心者の感想ですが、ひとつひとつ画面をクリックして設定するの面倒くさくないですか?

866 ：
http://www.metro.tokyo.jp/tosei/hodohappyo/press/2019/03/27/documents/19_02a.pdf
業務フローやユーザーのハマりポイントが書いてあって参考になるな
具体的なコストには触れてないが、コストが課題の一部だと認識しているのが好印象だった
否定派も「RPA導入前の作業プロセス」を自分ならどう自動化するか考えてみると面白そう

>>859のPDFは提灯記事と変わらんゴミ

867 ：
>>864
典型的なイチャモンだねぇ 読めなかった理解できなかったのにね
ま、確かに全庁に展開する際にトライアルでは怒らなかった問題は起こる可能性はある でもトライアル以上の検証なんて出来ないし、プラスマイナスはあれどこれをベースとするしかないだろうね

仮想環境での検証の話とか面白かったけど、まぁそんなもんなんだね ご苦労さん

>>862
具体的なコストなんて当事者は出さんでしょ
業者側は今後高く売り付けたいし、ユーザー側は人件費とかバレたくないし

868 ：
結局のところ分析と設計が大半であって実装する部分は瑣末な問題なんだろうな
都の実験でも数ヶ月かかった全体プロセスの中で実装はたったの数10時間(しかも素人作業)という具体的な数字が出ているわけだし
だとしたらやはり最初からプロを雇って分析と設計に加えてついでに実装もやって貰えばいいね
プロなら実装も数10時間と言わず数時間でできるだろう
もちろんライセンス無料のプログラミング言語でね
逆に全体のプロセスをプロ抜きでやろうとするのは危険とわかった
ちゃんと金を払ってプロを雇おう

869 ：
ちゃんと人を育てることを考えないといかんぜよ。

870 ：
http://www.metro.tokyo.jp/tosei/hodohappyo/press/2019/03/27/documents/19_03a.pdf
電子化したデータあるけどOCRで読めねーよとか
縮減率すげーけど許容工数がシビアすぎてペイするのに数年掛かるとか
あるある
と言うかこれだけ要件定義できるおばちゃん居たらSEで活躍して欲しい

871 ：
＞ 前提も測定方法も結果データもありませんが、
＞ 結果はこうですって言って信じるのは文系だけだろう
＞ だから科学的な教育を受けてない連中はカモなんだよ
＞ 最低でも第三者機関が再現可能になるぐらいの
＞ 情報が提示されてから数字を信頼しろ

最初はこんなにイキってたのになw

872 ：
>>871
＞最低でも第三者機関が再現可能になるぐらいの
＞情報が提示されてから数字を信頼しろ

今の nature や science のペーパーですら再現可能じゃないものが多い、とか言われちゃう時代ですからね、理系の世界も大して変わらないのでは？
査読論文による評価体系も崩れてきつつあると思います、ハゲタカジャーナルとかもその表れでしょう

873 ：
>>872
そういう気がする 門外漢なのであれだけど

研究に対するような姿勢は立派だとは思うけど、仕事はそこまで要求水準は高くないでしょ RPAにせよ他の方法にせよフェアな基準で見ることが大事

874 ：
上がRPA導入しろって言ってるので…
導入実績さえ有ればいいんですよ！
(弊社の場合)

875 ：
>>835 そんなのは簡単にできるぞ。 そんなのをいまだに手作業でやってることに驚き。

876 ：
いや、そもそも特定の人しか承認ボタンが押せないシステムを作ればいいわけで
パフォーマンスや鯖資源が大きく違う

877 ：
>>873
生き残りたいのなら理想は高く保つほうがいい、とは考えています
そして再現可能なデータを提示するのは最高級に難易度が高いとも思います

878 ：
ハンコが諸悪の根源
ファイルの属性を変えればいいだけなのに

879 ：
>>878
公的な承認システムを整備すればいいと思います
pdf を登録すると pdf の同一性＝ハッシュと登録日時・時刻と保障する公的機関を整備するべきです
公文書も電子ナショナルアーカイブに登録して一定期間（50年）後には全部公開するべきかと

880 ：
だめだRPAやっぱり難しい
週末を使って地道にトレーニングを続けてるけど全く生産性が上がらん
頭の中にあるロジックを図にするだけでも凄い手間がかかる
最初は何をどう配置したらどうなるかがわからず生産性が上がらなかったけど
ある程度わかってきた今は単純に作図作業そのものが辛い
テキストならあっという間にタイプできるのに同じ事がRPAの作図だと時間がかかる
これ絶対にテキストでプログラミングするオプションを提供すべきだよ

881 ：
>>880 どんなツールを使ってる？

882 ：
プログラムが高いレベルで書けるのにRPAが書けないってことはまずあり得ないんだが。

883 ：
ん～と
プログラムが高いレベルで書けるからこそ、RPAで正確で誤解の余地のない図なんか面倒くさくて冗長でとても書けない
みたいな？

884 ：
>>866
P35のは確認依頼してその結果がOK/NG/途中とかの管理をする必要がある
件数が少なければいいけど件数が多いと手間がかかるしミスも起きやすくなる

885 ：
>>880
blueprismだかautomationanywhereだかどっちかは完全にスクリプト式じゃなかったっけ？

886 ：
>>866
VBAで実現可能なものもあるな
マクロの記録でできるかもしれない

実装の容易化がRPA製品の価値の一部かな

シナリオを実行するVBAのライブラリを作れば
良いだけな気もする
RPA製品をコア事業にしている会社は厳しい気がする

887 ：
>>875
紙をファイリングしてISO監査で見せる必要あるからこうなるんやが
電子保存と紙保存の二重を求められるからほぼできんやろー

システムや仕組み変えろやこの作業の意味について問うのは別の話なので…

888 ：
監査はISOに限らず紙を要求されるか事が多いから厄介だよな

889 ：
>>882-883
描けなくはないけどテキストと比べて手間がかかるからストレスフル
メールでリンゴって言葉で伝えればいいのにリンゴの絵を描いて添付ファイルするようなとでも言えばいいのか
凡人並みにコードが書けるなら誰でも作図は遠回りに感じると思う

>>885
そういうのもあるのか
後でやってみよう

890 ：
>>880
確かに色んな意味でビジュアルとテキストの変換できるといいだろうなー↓ メーカー側のメリットが薄そうだから難しいそうだけど
・テキストに慣れたプロが使いやすいように
・上で出てたRPAのプロトタイプからシステム化に移行しやすいように
・RPAサービス終了時にシステム化して緊急避難できるように
・RPA製品間の移行ができるように

891 ：
>>887
印刷物をハンコを押す人の前に届けるとかハンコを押すとかの物理的な操作以外は簡単に出来るだろ
物理的な操作が必要ならペッパーとかで頑張れw

892 ：
>>891 電子印鑑を押してプリントしたものでも何ら問題ないぞ。
勿論電子書類でそのまま送れるところには、そのまま送るが。

893 ：
>>892
お前の所の運用なんて>>819の話に関係ないからどうでもいい

894 ：
導入失敗談待ってるぞー

895 ：
失敗したっていってる企業だいたいWinActor

896 ：
>>866
RPA導入を通じて、紙やハンコが業務の阻害要因だと気づけてるのが良い傾向

897 ：
3大RPA(Automation Anywhere, Blue Prism, UiPath)以外は全部パチモンだし…

898 ：
pythonは優れたRPAツールだ

899 ：
ユーザー自身が必要なシステムの仕様書を書けない問題に対する回答として
・メーカー寄りの回答がアジャイル開発(メーカーが作るがユーザーレビューを頻繁にする)
・ユーザー寄りの回答がRPA(ユーザー自身に作らせる)

とか考えてみたが、システムの規模とか違うな

900 ：
>>899
全くの別物なので同列に並べないほうがいいぞ

901 ：
>>896
業務の都合ではなくて
社外とか他の要求によるもの
変えるとしたら議会とか外部を変える必要があるモノもある

902 ：
価値あるシステムを作るのがアジャイル(というかアジャイルに限らず一般的な開発)
システム同士を推奨されない方法で無理矢理繋ぎ合わせるのがRPA

903 ：
>>902
言っている意味がわからないんだが

904 ：
明確な定義じゃなくて、みんながいろんなのを「これぞRPA]と言っているから
「RPAはあいうえお」と理解している人に
「RPAはあいう＋うえお」と説明しても、理解できるはずが無い

905 ：
つまり＋はdistinctの中置演算子なんだね！

906 ：
じゃあ自分なりの定義を説明しろよ
その例だと理解し合えそうだし

907 ：
>>902
価値あるアジャイル
推奨されない無理矢理RPA
開発手法の話に価値観をぶっ込んでくるのがなんとも香ばしい ネガキャン乙ですね

908 ：
>>907
はぁ？
アジャイルは迅速に価値あるシステムをユーザーに提供するために発明され、発展してきた開発手法で、それが存在理由そのものとも言える
RPAがやってるような無理矢理プログラムで画面操作なんてのは、誰が見たってまっとうじゃない汚いやり方であって、本来ならプログラムから呼び出されることを前提にしたAPIを提供・利用すべきところだ
キミはちょっと粋がる前にまずITの常識を身につけてくれ

909 ：
>>908
ITの常識であることを示してくださいよ
RPAを進めてる企業はITの常識がないんだね 常識人様かっけー

RPAは迅速に価値あるシステムをユーザーに提供するために発明され、発展してきた開発手法で、それが存在理由そのものとも言える ←これでええんちゃう

910 ：
RPA進めてる企業はITの常識がないと思うよ
大部分の企業はRPAが流行っているから取り入れてるだけ
事業部門で乱造されたvbaのマクロが技術的負債となっていて、
それに代わるRPAが技術的負債とならない理由を明確に説明できる導入担当者は滅多にいないと思う

911 ：
何故その組織でRPAが推し進められるかって、そこにRPAを斬って捨てられる「お前ら」が居ないからだしな
だからいくら否定したところでRPAは導入される、ここで否定している「お前ら」がその組織内で矢面に立って
RPAを斬って捨てられる抜本的改修を行ってくれるわけではないからだ

912 ：
抜本的な改革ができなければRPAを導入する
この戦略は推進派が仕掛けた大胆なミスリードだろう

この戦略ではRPAを導入したら黒字になるって前提を何の保証もなく受け入れてしまってる
実際には野良マクロと同じで借金(技術的負債)になる可能性を大いに孕んでるわけだ
導入したら赤字にだってなりうるのに推進派はなぜかそのリスクを完全に無視して話を進めようとする

とまあここまでちゃんと考えてる人なら
代案がなければ導入を見送って現状維持という選択肢が見えてくるわけだな

913 ：
RPA進めてるのはプロが沢山いるシステムメーカー企業もだけどな

野良マクロが残ってるのは、(リスクがありつつも)トータル収支がプラスだからでしょ トータルマイナスなら使うのやめて手作業すればええんやし

914 ：
上に出ている 19_02a.pdf を読んで感じたのは、言われるほど迅速でも簡単でもない事かな
製造・販売元のフルサポート約4か月と業務分析を丸投げをした上で284時間の削減だし
RPA担当者を決めて育てないと非効率じゃない？

915 ：
効果と用途が解りやすいから
RPAに興味を持つ企業が多いし営業も売り込みやすい

リレーショナルデータベースひとつとっても、
原理の理解が難しいユーザーにシステムをプレゼンして売るより楽

916 ：
売る方は楽そうだな
売る方は

917 ：
押し付けられる側は大変だぞ

918 ：
>>908
アジャイル＝手法
RPA＝ツール（python,VB,C#もツール）
何で手法とツールが比較対象になるかな。

アジャイルの比較対象はウォーターフォールとかだろ。

頭悪そうだな。

919 ：
RPAというツールは簡単に手早くというアジャイルを連想させる宣伝をしているけど
実際はアジャイルに向かないし、アジャイルの本質も外している
といいたいのでは？

ところで、ときどき引き合いに出されるVBAは、自分はシステム化使ったことはないけど
アジャイルに使えるようなもの？

920 ：
ま、RPA（GUIプログラミング）の比較対象は普通はPythonとかのコードプログラミングだろうな

誰もが知ってるソシャゲの最大手もRPAを社内業務に導入しているけど、ITの知識が足らないんだ
オマエらどんだけ凄いんだ？

921 ：
RPAの本質はGUIじゃないぞ？

922 ：
RPAの本質はグルー言語

923 ：
本来バラバラのツールを協調させられるってこと

924 ：
課題解決の手段の話だろ
開発体制で解決を目指してもいいし ツールで解決を目指してもいい あるいは組み合わせることも可能性としてはある

925 ：
まあGUIしかインターフェースのないクソツールが多いからGUIの側面が強調されるのはわかるが。

926 ：
グルー言語か
それは失礼した

927 ：
Pythonはインストールして環境構築しないといけないが
Powershellはインストールしなくても使用可能。

.netの豊富なライブラリも使える。

なのに人気のなさよ。

928 ：
pythonとRPAは対じゃないぞ
pythonはRPAにもなる包含の関係になってる
だからRPAをやりたければpythonを学べばいい

929 ：
>>928
その論法だと、ありとあらゆる言語、アセンブラがRPAにもなる包含の関係になってることになる
RPAはpythonを知らなくても使えるのが最大のメリットだから、pythonはRPAではない
異論は幾らでも
どうでもいいし

930 ：
高級言語＋プログラマ→システム構築（投資）
ノンプログラミング＋事務員→リストラ

付加価値の創出　vs　組織のスリム化

この２つは経営戦略上の狙いがまったく違う

931 ：
本当にお前らは頭が硬いなぁ
そんなんだから土方て言われるんだよ

932 ：
じゃあム板から出て行けよ

933 ：
>>929
その通りだよ
解ってきたようだね
普通のプログラミング言語はRPAのスーパーセット
ただパッケージの充実度や言語そのものの生産性によって利便性は大きく変わるだろうね
C++やアセンブラでもRPAできなくはないが高い生産性は期待できないからやるメリットはないと言える

934 ：
補足
その通りと言ったのは>>929の前半な
後半は間違いだ

935 ：
RPAで自動化出来る仕事の半分はそもそもビジネス上価値が無く
やらなくてもいい仕事であるという統計がありま

936 ：
実行できる機能的な話でいえばpythonはRPAと包含の関係になってるが、
RPAにはコードやセレクタの自動生成やGUIプログラミングっていうPythonには無い要素を持ってるわけで、
且つ上記二点の特徴がRPAの主軸機能ともいえる点から総合的に見れば完全な包含関係とは言えないと思うよ

937 ：
ソースよろ

938 ：
>>936 そりゃ違うだろ。　何もpythonの生の機能だけで使うわけじゃないからな。

939 ：
>>938
？？？？？
Pythonにもコードを自動生成したりGUIプログラミングができるパッケージがあるってんなら納得だが、現時点でそんなのないよね
そもそも、RPAでできることはPythonでもできるから初めからPython学ぼうって理論が成立するなら
PythonでできることはCでもできるから初めからC学ぼうってことになるよね
じゃあPythonの存在意義は無いのか？って言われるとそうじゃなくて、PythonにはCには無い学びやすさとパッケージの豊富さがあるから価値がある
RPAにも同じように、Pythonには無いGUI自動操作に特化した機能があるから価値があるってことなんだよ

どっちが良くてどっちがダメってんじゃなく適材適所の話ね
実際のところ、PythonってSeleniumのおかげでWebアプリには強いけど、Windowsネイティブアプリの自動化ってなるとめっきり向いてないよね
ペイント開いて「貼り付け」ボタンを押下するだけ単純な処理のコード貼ってみ？？
え、めんどくさ　って思ったっしょ？その時点でもう向いてないってことだからね

940 ：
やっと主観的なRPAはダメ！的な盲目的コメントから冷静なコメントが出てきた
勉強になる

941 ：
>>936
それらはRPAの要件ではないよ
一部のRPAを名乗る製品がそれらをサポートしているというだけだ
人間が手作業で行っていたような作業を自動化するもの、ヒューマンインターフェイスを通じてプログラムをコントロールするプログラムがRPA

942 ：
>>939
RPAでできることはパイソンでできる
パイソンでできることはcでできる
パイソンはRPAより簡単で生産性が高いので前者は成立するが
cはパイソンより難しく生産性が低いので後者は成立しない

パイソンにもGUI操作に特化したパッケージは無数にある(このスレでも散々既出)

ポチポチの生産性が高いのはごく小さな画面小さな処理短い寿命のツールだけだよ
ポチポチのために他の素晴らしいプログラム体験を犠牲にするのは目先の利益しか見えてない証拠
GUIポチポチでパス解析したいならインスペクタツールを使えばよろしい
それかSikuliXとかそっち系のツールもなんかあるだろ

943 ：
いや、結局ライブラリの問題でCだろうがPythonだろうがVBAだろうがRPAだろうが同じ。
RPAはライブラリが揃っているのは有利かもしれない。
結局、どんな言語でも組む人の問題。

で、出来た物がダメな可能性が高いのはRPAだろうね。

944 ：
プログラム知識が互いにゼロの状態から自動化を行う場合、即戦力としては
RPAに軍配上がるだろうね
何年後か先を見た場合RPAだけ使える人とプログラム使える人とでは
汎用性やスキルの差が目も当てられないことになってそう

945 ：
プログラム知識が無い人は、ゴミなので意味が無い。

RPAやってプログラム知識を積むんだが、敢えて言えばVBAやってプログラム知識積んだ人が後からやった方が良いし、Pythonの方が更に良いし、Cの方がと続く。

946 ：
え～
ぼくのかんがえたさいきょうのRPAの議論をやるの？
不毛だよ
RPAとして売っている、配っているものがRPA
でもね、気をつけて
「PythonこそがRPA」とか言ったらコミュニティでBANくらっても文句言えないレベル

947 ：
>>942
>cはパイソンより難しく生産性が低いので後者は成立しない
全てのC使いに謝れ（笑）Cは難解だがPython以上の自由と実行速度がある。結局どこに重きを置くかで使うツールの最適解は変わってくるってこと
現状ではWindowsネイティブアプリの自動化に関してはUiPath使うのが楽だよねって話（3大RPA以外のRPAツールが生産性低いのは同意）

因みにPythonのGUIに特化したパッケージとは？？？
全然思い当たらん。スレにも出てないよ。PyAutoGUIの事言ってる？？？あれイメージマッチングしかできないからね。
UIAutomation叩けって話？それならPythonじゃなくC#でいいよね。それにしてもいちいちInspectで解析とか生産性低すぎだけどね。
SikuliX？？あれこそ画像認識しかできない糞RPAの代表格みたいなツールじゃん。

948 ：
Windowsならpythonより.NETの方が簡単
インスペクタでポチポチ調べてpowershellに貼り付ける
RPA製品のポチポチと比べてそんなに生産性が劣るとは思えない
それにプログラムならポチポチ以外の解析方法もあるしね

949 ：
>>948
インスペクタでAutomationIDがブランクになっててNameも付いてないような場合でも自動化ってできるの？？
できるとして、どうやって要素特定するの？

950 ：
>>949
他の属性、親子、兄弟

951 ：
インスペクタよりはRPAの方が全然良いだろ。
RPA否定派だけど公平じゃないのはいただけない。

952 ：
でも、インスペクタみたいなのは簡単に作れるので、自分に合ったのを作っとけば良い。

953 ：
構造が綺麗かつ静的なUIならRPAもinspectも作業量は大差ないかと
複雑なUIをRPAで操作したことがないので、その場合は比較できないけど・・・
例えば>>949のように内部構造が不親切なUIやコントロールが動的なUIは、RPAの場合どうなる???

>>952
コード生成も簡単な割に効果が大きいのでオススメ

954 ：
>>950
やっぱりそうなるよね…
他の属性もNullで周辺に手頃なアンカーになる要素がない場合はツリーの上の方から指定する感じですよね
この要素の3番目の子要素の孫要素の2番目の子要素の…みたいな
めちゃくちゃ大変そう

>>952
インスペクタ的なの自作できるんですね！！
FindAllで要素列挙する感じ…？？このへんの情報ってWeb上にあんまり転がってないから詳細気になります！！！

955 ：
RPAでやるこの作業をPythonなら(Pythonでも)こんな簡単にできます、だからベストプラクティスはこれなんです、みたいな話がこんなふうに載ってるとRPA肯定派も減るかもな 私はRPA肯定派だけど

956 ：
>>954
とはいえクソUIの自動化が面倒くさくなるのはRPAも同じだからな

957 ：
SEにRPAを作らせるような本末転倒な現象があちこちで起きてるから
RPA＜PGみたいな当たり前の比較が出てくる

窓際じじいやパートのおばちゃんが作れないなら、その時点で導入を諦めとけ

958 ：
WinAppDriverはXPathをサポートしてるからクソUIにも比較的対処しやすい
デスクトップアプリ自体の需要が激減してるからだろうけどMicrosoftがあまりWADに熱心じゃないのが残念

959 ：
他は知らんがUiPathなら美UIだろうがクソUIだろうがワンクリックでセレクタ自動生成よ
構造解析に頭使わなくて済むってだけで使う理由に足る

960 ：
UiPathだけじゃなくて、Blue PrismもAutomationAnywhereもそう
三大RPAは楽々セレクタ自動生成
他は知らん

961 ：
───────→〇

┌──┐
　　　　 └─┐┌→×
　　　　　　　 └┘

まっすぐ行きますか?
曲がりながらたどり着きますか?
マウスカーソJは。

962 ：
RPAが簡単ってのはちょっと信じられん
もう何日か弄ってるが全く思い通りに快適に処理を組めない
とにかくGUIでプログラミングってのが思ってたよりずっと難しくて苦痛に満ちてる
なにがどこにあってどうしたらどうなるのか直感ではサッパリわからない
じゃあ調べるかってググるんだけどなんも出てこねえの
スクショとか動画は時々出てくるんだけど
それじゃ検索できねえし視聴するのも大変

それと使いかたがわかっても生産性はあまり期待できない
GUIエディタの操作感がいまいちだから作図そのものの労力が思ったより大きい
調査を済ませて手を動かすだけの状態でも実装に時間がかかる
キーボードでテキストを打つよりもマウスとキーボードで作図するほうが大変なのは考えてみたら当たり前の話なんだけど
しつこく簡単だって言う人が居るからその労力を過小評価してしまっていた

963 ：
RPAがテキストプログラミングよりも簡単というのはRPAベンダーの意図的なミスリード
テキストプログラミングがわからない人でもGUIエディタで何とか組める、というのが正解
両方できる人にとってどちらが簡単かという視点で評価されてるわけじゃない

964 ：
>>963
しっかり教育した上でセンスのある何割かが何とか組めるって感じなのでは？

例の導入実験レポートでもベンダーのサポート無しで最後まで組めたロボットは1体だけだった
研修を受けた人の感想も簡単楽勝即戦力という印象ではなかった

965 ：
とりあえず何のRPAだったかくらい書こうぜ
UiPathなのかBlue PrismかWinActorなのかさ

966 ：
テキストプログラミングにもPython,VBA,Cとか色々あるようにRPAにもUiPathとかBizRoboとか色々ある

967 ：
>>964
自分素人でuipathで今組んでるけど、とにかく技のレパートリーが少ない状態
やることは難しくないけど、こういう時どのアクティビティてどのような.netで記述すればいいのかわからない
型とかも馴染みないし、変数の概念もまだ染み付いていない

ゲームと同じで雑魚敵倒してレベルアップ期間が必要。
急にボス戦(会社の課題解決)突入しても勝てないね

968 ：
組めないマンは詳細書けよ
どんなものを組もうとしてるのかとか
どの製品使ってるかとか
具体性がないからモヤモヤする

969 ：
結局.NETライブラリを使える奴しかUiPathをまともに使いこなせないという話なのかね

970 ：
RPAもピンキリ
たぶんここで簡単生産性高い言われてるのは3大RPAツール（Automation Anywhere, Blue Prism, UiPath)のどれか
難しいわからん情報少ない言われてるのはそれ以外のRPAツール（WinActor,BizRobo,NICE,RoboPad,Auto〇〇名人..等）

3大RPAの中でもUiPathは無料ライセンスある分頭一つ抜けて情報量多い
機能的には横並び

まとめるとこんな感じかな？

971 ：
uipathの業者によるまとめ

972 ：
ステマの言ってることと実際にやってみた感触が全然違うから何を信じていいのかわからねえ

973 ：
こういう時言われても分からんわなw

974 ：
これだけ具体性なく書けるってすごいな
使い手は問題ないんだろうか

＞頭の中にあるロジックを図にする
＞何をどう配置したらどうなるかがわからず

＞全く思い通りに組めない
＞なにがどこにあってどうなるのか直感ではサッパリわからない
＞ググるけどなんも出てこねえの

975 ：
実際のところRPAツールのシェアってどんなもんなんだろう
国産ってことでWinActorが多そうだけど…
ライセンス的に個人でも気軽に試せるのはUipathだし、
費用的にAAとBPは大企業での導入が大半かな？
展示会によく出店してる名も知らぬツールのシェアもそこそこありそう
導入してるとこは何入れてるかと使い心地聞きたいなー

976 ：
>>953
>>954
RPAにそんなに詳しく無いけど、自分がRPAを作るとしたら>>949みたいなのは簡単に出来るので、恐らく一般的なRPAもそうしてると思う。
人間が複雑と思ってるのって機械にとっては複雑じゃないので機械的に親、子、孫でも良いし、コントロール属性で何番目でも良い。

>>953
コード生成はIE系では既に作ってる。
けど作ったの10年以上前でUIが糞なんで作り直そうと思ってる。
通常アプリでも作るつもり。

>>954
FindAllは個人的にはお勧めしない。
自分の組み方が悪いのかも知れないけど見つからない時が結構有った。(ツール作ってる時じゃなくて操作するための検索時ね)
FindFirstで兄弟見つけてそれぞれに対して自分を呼び出せば良い。

977 ：
>>976
主要なRPAツールだと>>949みたいなアプリの要素をクリックした時にどんなセレクタが生成されるんだろ？
サンプルアプリと実際にワンクリックで作ったセレクタを並べて比較したいが面倒くさい

978 ：
>>977
コード書かない人にとってはオブジェクトの情報は寧ろ無い方が良い。
オブジェクト名1個とアイコンぐらいの方が理想的でしょ。
親とか子とか属性とかは見えない方が良いと考えるんじゃないかと思う。

一方、コード書いてきた人にとっては情報は有るほど良い。
その方が対応出来る幅が拡がる。

979 ：
誰か各製品のチュートリアルのアドレスをまとめて下さい

980 ：
1903でまた仕事が増えるべ

981 ：
1903ってなんや？

982 ：
RPAは情報交換しにくくて不便ですね
気軽にコードスニペットを貼り付けて議論したいけどXMLでは見てもわからない…

983 ：
ウインドウズアップデートか
ググっちまったぜ

984 ：
>じゃあ調べるかってググるんだけどなんも出てこねえの

ホントそれ。
結局はユーザー数なんだよな。
VBとかCなんか、多少難しくても、ググればすぐ作例が出てくるからな。

985 ：
>>977
でさ、慣れてくるとHTML丸ごとテキストに落としてREGEXでごにょごにょしてINVOKEしちゃうという
一体俺は何をしてるんだ地獄に落ちるのだ。

986 ：
後きっと何言ってんだお前と言われること必定だけど、
要件分析が糞だと結局道具何使っても同じ。

987 ：
>要件分析が糞だと

糞程度ならまだマシな方。
ウチなんか、要件分析なんかしないで丸投げだもんね。

プログラムと魔法の区別がつかないっていうか、
マジックの種がなくても空中浮遊できると思ってるレベル。

988 ：
まあ、マジックの観客のつもりなんだろう。
種はお前が用意するんやでｗ

989 ：
新人や派遣の方が入られた時に指示するようにお話ししてください
てやったら結局ヌケだらけだというね....
もちろんこちらの経験でこういうこともありませんか、こんな例外は
ありませんかとか力の限りは尽くして拾い上げたつもりでもネ。

要するに業務の棚卸経験、適性の差がもろにでるというね、って40
年前から進歩してないじゃん。

SEが偉いって訳じゃないよ。むしろサービス部隊なんだからね。

楽天が英語力とプログラミング能力とかを採用で重視とか、いつもな
ら眼にも留めない提灯記事を見入ってしまう今日この頃（っていうか今日）

990 ：
>>984
ユーザー数が少ないマイナージャンルというのも理由の一つだけど、
それ以上に、プログラミング言語みたいに、気軽にテキストでコミュニケーションを取れないことが最大の課題
このスレだって、もう3スレ終わるけど、具体的なRPAプログラムをUPして議論になったこと、一度もないよね
ここと同じ、事務員が多いVBAスレですら、コードを通じて具体的な議論が交わされている
RPAスレはそういうの、まったくない
コミュニケーションの労力が大き過ぎるから誰もやろうとしない

991 ：
情報発信のコストが大き過ぎるから誰もやろうとしない
だからググっても何も出てこない

992 ：
>>959
Webならブラウザの機能で同じことができると思う

993 ：
次スレ
https://mevius.2ch.sc/test/read.cgi/tech/1558568756/l50

994 ：
>>992
Webなら、ね。
Windowsネイティブアプリで同じことができるツールはそうそうないよ

995 ：
>>991
地味だけど致命的な課題
言ってしまえばインターネットの力の大半を封じられたようなもの

996 ：
>>994
inspectもあるしレコーダーもある
そもそもデスクトップアプリは極一部なのでそんな気にしなくていい

997 ：
>>996
Webアプリて流行りだしたの最近だし、まともなやつならAPI揃ってること多いからRPAなんてそもそも必要ない事が多い
今問題になってるボトルネックになるような基幹システムは殆どがデスクトップアプリだと思うよ
inspectって構造が見れるようになるだけで解析やセレクタ作成は自力でやんなきゃだし、そういう非効率な部分を解決する手段としてRPAは使えるというお話

998 ：
おもいつき
ハードウェアとアプリケーションの間を埋めるOSとミドルウェアのように
アプリケーションとユーザーの間を埋めるのをRPAということにしたいと思う
この観点からRPAベンダーは作り直せ

つまり、何かをするボタンというのがあって、人間はそれをクリックするだけでよいし
タスクスケジューラでクリックするプログラムを起動しても良い

999 ：
>>997
非効率かなー
構造がわかれば解析やセレクタ作成は秒単位の作業だろ？
その些細な作業のために全体的に非効率なRPAを導入するのはもったいないよ

1000 ：
埋め

1001 ：
2ch.scからのレス数が1000に到達しました。

Win32API質問箱 Build124
HSPだって
【論理】Prolog【初心者】
ATL/WTL Part7
Ruby 初心者スレッド Part 63
今までみた絶望的なソースコード
プログラミングを勉強したいのだが
【Intel】OpenCV総合スレ 5画素目【画像処理】
StackOverflowについて語るスレ
VisualBasic6.0　対　VisualBasic .NET 2003
--------------------
【不定愁訴】嫌儲いつも体調悪い部 [297142216]
12.9インチiPad Pro Part66
[NETGEAR] ReadyNAS総合 Part42 [X-RAID/RAIDiator]
【8591】 オリックス 23
【デレステ】スターライトステージ★11332
テキストエディタをまた～り語ろう ver.34
23日にもらった給料が残り3万になった
【Dota2】Dota Auto Chess Part8【MOD】
【テレ東水24】レンタルなんもしない人【増田貴久・比嘉愛未・葉山奨之・古舘寛治】
佐藤「まーの印象変わった？」北川「え……クルクルパーでした……」佐藤「おい！」石田「殴っちゃダメ！！手は出しちゃダメ！」
борщにsurströmmingを入れて納豆をかき混ぜた箸で、良くかき混ぜるスレ１
〔愛知〕美味しいランチ☆三河 Part2☆
萩生田「いいかい学生さん、身の丈に合わせた受験しろよ」発言　謝罪へ [594632409]
社台ＳＳの種牡馬たちが１７歳前後で死んでしまうのは何故なのか？
イニシエダンジョン　地下206階
意外と語られていないプリンストン大学
松倉海斗
　　　 ヘバーデン結節について語ろう
【芸能】ローラが突然の海外移住した真相は…　ハリウッド女優としての今後も激白
赤毛のアン 第48章「マシュウ我が家を去る」
TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼