カテゴリ
以前の記事
2024年 03月 2024年 02月 2023年 12月 2023年 11月 2023年 09月 2023年 08月 2023年 07月 2023年 06月 2023年 05月 2023年 04月 2023年 03月 2022年 10月 2022年 09月 2022年 08月 2022年 02月 2021年 06月 2021年 05月 2021年 03月 2020年 11月 2020年 10月 2020年 08月 2020年 07月 2020年 06月 2020年 04月 2020年 03月 2020年 02月 2020年 01月 2019年 09月 2019年 04月 2019年 02月 2019年 01月 2018年 12月 2018年 11月 2018年 10月 2018年 04月 2018年 03月 2018年 02月 2018年 01月 2017年 12月 2017年 07月 2017年 06月 2017年 02月 2017年 01月 2016年 12月 2016年 11月 2016年 10月 2016年 06月 2016年 05月 2016年 03月 2016年 01月 2015年 06月 2015年 03月 2015年 02月 2015年 01月 2014年 12月 2014年 11月 2014年 10月 2014年 07月 2014年 05月 2013年 05月 2013年 03月 2013年 02月 2013年 01月 2012年 11月 2012年 10月 2012年 09月 2012年 06月 2012年 02月 2011年 10月 2010年 11月 2010年 03月 2010年 02月 2008年 03月 2007年 11月 2007年 07月 2007年 06月 2005年 03月 2005年 02月 2005年 01月 2004年 11月 2004年 10月 2004年 08月 2004年 07月 2004年 06月 2004年 05月 2004年 04月 2004年 03月 フォロー中のブログ
メモ帳
ご意見、突っ込みは以下へ
parshyu@gmail.com その他のジャンル
ファン
記事ランキング
ブログジャンル
画像一覧
|
ホワイトカラーにおける業務の効率化・自動化のケースで"理由ありきでサーバー型のRPAを選択する"話がちらほらあったりする。 動機として 「野良アプリがあると管理しきれなくなるから、一元管理する」 というものである そして、WinActorとかBlue PrismとかUipathとか、RPAのツールベンダーからお買い上げでシステムを入れる目的として 「野良アプリは作った本人がいなくなったらサポートできないけれど、ベンダーお買い上げならサポートがある」 というもの。また、より高価なサーバー型を導入する目的としては 「デスクトップ型だとユーザーカスタムされて、ここでしか動かない野良RPAができてしまうので、サーバー型だと一元管理できる」 といったものがあるそうだ。 「野良アプリの一元管理システムへの移植は、Uipathとかじゃなくても、やれるトコなら、できたのでは。」 そこから、邪推したこと 「現場の要望を聞いて、業務の効率化・自動化するというお仕事を いままでできていない事を、現行ツールがだめだったから、こういうのがなかったから開発追いつかなかったんです って言い訳するために、お金使ってRPAの仕組みいれたんじゃないの?」 ということ。 まず根底に思うのは 野良アプリの撤廃をしたいって思ったら、開発部門で管理しているアプリをまとめあげた後、 「使っているアプリを集計しまーす。みなさん協力してくれたら、めんどうな手作業楽になるシステムが構築できまーす」 って声をかけていって、あつめて 開発部門で開発していない、野良アプリ一覧ができる 野良アプリだけではよくわからんから その野良アプリを必要として動かしている人がいるんだから そのアプリを動かしている人に、必要なのか、わからず動かしているのか、背景をきいて 動いている状況をみせてもらって ソースがないなら動作内容から、設計から ソースがあるなら、そのまま開発部門が推賞するプラットフォームへの移植 なんてかたちでやっていけば、大半がなくなる。 全部門の共通項に自動化できていない部分がみえてきて、それが野良アプリだったりするので 全部門にあたらしくできたアプリなり、Webシステム上の追加機能なりをリリースして ざるでさらうように、けれど虱潰しのようになくしていけば おのずと、野良アプリ数は減っていく。 そこを野良アプリって呼んで、現場の声をきかないし、リリースした後の様子を確認していないまま 過ごしていたことが一因だったんじゃないかと思う。大きな一因。 Uipath およびUipath Studioにもどる。 機能はとても素敵。開発しやすい。 レコーディングでデスクトップにあるコントロールを拾ってフローにしてくれるところが素敵 VisualStudioで外部アプリのフォームを操作するアプリを開発しながら、Spy++で対象となるフォームのコントロールとか 調べているときに 「ああ、Spy++でチェックしたらこのDeclare Functionとかで最前面のフォーム名をチェックして該当だったらコントロールにSendMessageを送ったり、SendKeysでCtrl+Vみたいなのを送るようにしてくれるような関数をさくっと自動記述できれば」 なんておもったときの要望が目の前で実現されている感があって その便利さを想像するだけで感動する。 けれど、ちょっぴりGUI的なところを準備しようとするとUipath単体ではできない Visual Studioでクラスライブラリ書いて、VisualStudioでそのクラスライブラリを呼び出すテストアプリで動作するところまでもっていって、DLLつくって Uipathのカスタムアクティビティ用に変換して、UipathStudioに取り込んで UipatuStudioで動作させて ああ、このパターンとこのパターンあるから、引数足りないやってなったら またVisualStudioにもどって、クラスライブラリを・・・ ってやっていくことになり やっていくうちに 「細かい要望には、Uipath単体では、実装しきれないケースが多くて、VisualStduioで開発必須なんじゃないか」 ってことに気がつく 「Uipathだけで、すんげー効果がでました」 っていうのは、Uipath上の機能で実現できることに特化した作業内容の会社だったってこと。 「Uipathど導入して、すんげー効果がでました」 というのは、もともとガンガン効率化の開発をしている会社で、 「あとはアプリを呼び出して画像認識させて動作できるような機能がVisualStudio上のプラグインであれば」 なんておもっていたところにはまった もしくは、宣伝文句として効果が出たと盛っているか。 僕のようにやったことある人なら思い出せると思う。 Windowsのフォームアプリケーションの操作って、 VisualBasicでも十分できることがあるし シェル実行なりバッチ介してなりでアプリ起動できるし プロセス監視なり、起動フォーム一覧取得なりで、目的の画面が表示されているのを確認できるし SendKeysである程度操作できるし、 つくりによってはタブキー×規定回数でコントロールやハイパーリンクまで移動できるし ものによっては、SendMessageうけつけていたり、ショートカットキー実行受け付けていたり アプリ側でバッチやマクロもっていたりと 意外と、少し頑張ればそれにこたえてくれて、 自動化はできる部分があったりする ただ、対象アプリがバージョンアップしたらどうなの、Web画面のデザインかわったらどうなの そのたんびに、タブキー×とか、画面起動まちのSleep時間を調整するのは 追っかけきれずに疲弊するかもしれん だから、汎用システムにもっていくんだし開発しておくもんじゃなかろうか。 それをやってこずに、「RPAでできるんです。野良アプリもなくせるんです」って宣言しちゃうのは ちょっと残念な活動だと思う。 むしろ「野良アプリ万歳。このツールで野良システムいっぱい作って効率化してください」 「そのうちこっちにもらって、清書して共通化していきます」 なんてやったほうがいい。 UipathStudio3日さわってそうおもった。 3週間さわったらどんな感想になるかはわからんが。
by parshyu
| 2018-12-22 00:58
| φ(・ω・ )
|
ファン申請 |
||