人気ブログランキング | 話題のタグを見る

パジャマシステム


メモと日記帳
by parshyu
S M T W T F S
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
カテゴリ
以前の記事
フォロー中のブログ
メモ帳
ご意見、突っ込みは以下へ
parshyu@gmail.com
その他のジャンル
ファン
記事ランキング
ブログジャンル
画像一覧

Uipathを3日程さわってみて思ったこと。野良アプリが増える職場で野良撤廃目的なら逆効果

ホワイトカラーにおける業務の効率化・自動化のケースで"理由ありきでサーバー型のRPAを選択する"話がちらほらあったりする。
動機として
 「野良アプリがあると管理しきれなくなるから、一元管理する」
というものである

そして、WinActorとかBlue PrismとかUipathとか、RPAのツールベンダーからお買い上げでシステムを入れる目的として
 「野良アプリは作った本人がいなくなったらサポートできないけれど、ベンダーお買い上げならサポートがある」
というもの。また、より高価なサーバー型を導入する目的としては
 「デスクトップ型だとユーザーカスタムされて、ここでしか動かない野良RPAができてしまうので、サーバー型だと一元管理できる」
といったものがあるそうだ。

そんな話をききながら、Uipath Studioを3日程さわってみて思ったこと

 「野良アプリの一元管理システムへの移植は、Uipathとかじゃなくても、やれるトコなら、できたのでは。」

そこから、邪推したこと

 「現場の要望を聞いて、業務の効率化・自動化するというお仕事を
 いままでできていない事を、現行ツールがだめだったから、こういうのがなかったから開発追いつかなかったんです
 って言い訳するために、お金使ってRPAの仕組みいれたんじゃないの?」

ということ。

まず根底に思うのは
野良アプリの撤廃をしたいって思ったら、開発部門で管理しているアプリをまとめあげた後、
「使っているアプリを集計しまーす。みなさん協力してくれたら、めんどうな手作業楽になるシステムが構築できまーす」
って声をかけていって、あつめて
開発部門で開発していない、野良アプリ一覧ができる

野良アプリだけではよくわからんから

その野良アプリを必要として動かしている人がいるんだから
そのアプリを動かしている人に、必要なのか、わからず動かしているのか、背景をきいて
動いている状況をみせてもらって
ソースがないなら動作内容から、設計から
ソースがあるなら、そのまま開発部門が推賞するプラットフォームへの移植
なんてかたちでやっていけば、大半がなくなる。

全部門の共通項に自動化できていない部分がみえてきて、それが野良アプリだったりするので
全部門にあたらしくできたアプリなり、Webシステム上の追加機能なりをリリースして
ざるでさらうように、けれど虱潰しのようになくしていけば
おのずと、野良アプリ数は減っていく。

世界は変化する可能性があるのに、開発していないから、現場でフリーウェアなりVBAなりでなんとかした苦肉の策があって
そこを野良アプリって呼んで、現場の声をきかないし、リリースした後の様子を確認していないまま
過ごしていたことが一因だったんじゃないかと思う。大きな一因。


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 | φ(・ω・ )
<< Uipathでサインオフの処理... Uipathでユーザー認証のよ... >>