RPA始動（RPA導入記）

RPAの環境

RPA導入にあたり言葉通り、
Robotic Process Automation
ロボットがプロセスを自動で実行するイメージが当初から明確にあったため、UiPathの構成は以下とした。（と言うか、これが当たり前だと思ってた）
・Orchestrator（管理サーバ）
・Studio（開発環境）
・Unattended Robot（自動実行ロボット）

Robotをひとつのサーバ、
サーバ＝ロボット　のイメージ。
処理＝ロボット　ではない。
例えばメール受信ロボット、Webサイト巡回ロボなど処理ごとにロボットと呼ぶのではなく、
ロボット（サーバ）がメール受信したり、Webサイトを巡回したり、いろんな処理を実行するイメージ。

このイメージが現在もRPAベンダーでもユーザーでも事例でも記事でも明確になっておらず、また人によっても違うため、ロボットという単位が統一されていないのが個人的にはとても嫌な状況だったりします。

上記のイメージから、PCではなくしっかりとしたサーバにインストールする必要があると考え、またちょうど当社でもVMwareの導入をしていたので、仮想サーバ上に構築することとした。
ちなみに当時はAttented Robot・Unattented Robot ではなく、Back Office Robot・Front Office Robotだったので、これらを略したサーバ名にしたのに途中で変えられしまったせいで今見るとよくわからないサーバ名になってる。（どうでもいいけど）

RPA導入サポート

初期の環境構築や設定、開発についての学習の仕方や教育等、UiPathを紹介してくれたところに依頼することにした。
最初のワークフローも作成してもらうことにした。
作ってもらうにはいろいろなノウハウを吸収したいと、元の業務内容よりより複雑で欲張った処理を追加して作成してもらった。
そのため大変苦労してたけど・・・

具体的にはとある業務の承認作業だったんだけど、今までは人が見てある程度内容からなんとなく良いか悪いか判断する結構アバウトな処理だったんだけど、ロボットが実行するとのことで、DBを参照して明確に判断することにしたため、処理の精度は格段に上がったが時間が掛かるプロセスとなってしまった。ただ、深夜に何時間も動き続け、人が頑張ってやっていた処理を自動で朝までに終わらせてくれて、精度も上がった事もありそれなりに評価される事になり、最初の処理としては良かったかなと。
また、システム会社がきちんとその会社の規約や基準で作ったシナリオはとても参考になり、のちの開発作業および規約等の作成に大いに役立った。

ちなみに紹介いただいた会社は現在プラチナパートナーだけど、当時はまだ代理店でもなく、UiPathのライセンス購入はまだ3社しかなかった販売会社さんを紹介してもらって購入しました。

誤りについて

前の記事で書いた誤りについてですが、紹介を受けた際、
「ロボット（Unattended Robot）はサーバスペックが許す限りアカウントを増やせばいくらでも増やせます。ロボットのライセンスはサーバ単位なので、1ライセンスでロボットがたくさん作れます。」
と。これは安い。
なので、かなり高スペックなサーバを用意してもらい、実行環境と開発環境が同じじゃないとまずいということで、Studioについても同スペックにしてたんですが、これが実は誤りでサーバ1台で1ロボットしか動かせませんと。
後にロボットを追加するときにアカウント追加したくてもできなくて正しい仕様が判明しました。

Unattended Robot1ライセンスでたくさんロボットが増やせると思ったのが1台となり、めっちゃコスト感が上がってしまったけど、まあそれでも年収で人と比較すれば、手間はかかるけど365日24時間働いてくれるロボットは十分安いのでよしとした。

ロボットの名前

イメージ的にロボットを擬人化するのはとても良いと思ってたので、ロボット名をつけるのは個人的には必須だった。
（最初に書いたロボットのイメージからも名前つけた方がわかりやすい）
課内で話し合った結果、同じシリーズでつけていこうということになり、何シリーズにするか案を出して投票した結果、植物シリーズになった。

個人的にはガンダムシリーズにして、
パナージが覚醒した!とか、マリーダさんが壊れた。とか、リディが暴走した!とかやりたかったんだけど（ﾏﾃ

RPA情報の整理について

最初やはりRPAとはいえ開発なので、規約が必要となった。
この辺は一緒に見に行ったPGの人の意見を中心に規約を作成してもらった。
変数の付け方やコメントの入れ方とか。
でもこの辺は進むに従って、RPAの開発により適したものや、UiPathメソドロジーを参考にしたりで、臨機応変に入れ替えています。

また情報の整理にはRedmineを用意して利用することに。
Redmineを入れる事により、以下のことが出来て情報の集約ができたのも良かった。

• wikiでアカウントやパスワード、規約などを一元管理

• ナレッジベースで作り方やテクニックの共有（PG初めてな人は最初は特に日付けの処理、今月の末日の取得方法などの考え方がとても参考になった）

• フォーラムで質問や回答

• チケットで案件の管理と開発工数の記録等

人の入れ替わり

当初7人で始めたけど、PG経験者は4人。私を含め残り3人は未経験。
PG経験者はアカデミーをどんどん進めて1ヶ月後には開発できるようにはなっていた。自分も未経験ながら頑張ってアカデミーは終わらせ一応作れるようにはなった。
残り2名の未経験者は全然学習が進まず、数ヶ月で見切りをつけ外れてもらった。声をかけられ当時はRPAは簡単!って謳われてたし、面白そうだから始めてみたけど、片手間で覚えられるほど簡単ではなくやる気も感じられなかったので早々に外れてもらって良かったかなと。

代わりに?声はかかってないけど、是非やらせてほしいと志願者が現れた。
PG未経験ではあるけど、やる気がぜんぜん違うので、しっかり学習し現在も課の中心人物として活躍している。
（先週面接だったが、RPAの開発に喜びを感じてるとのこと）

兼任体制の弊害

最初は練習も兼ねて、同じ情報システム部内の業務を自動化していこうとした。
各課にヒアリングして自動化できそうな業務を洗い出した。
しかし課が発足して4ヶ月経っても、最初に作ってもらったもの以外、他にはまだリリースも出来てなかった。
やはり全員兼任であるのと、正直現在も人で業務は滞りなく回ってる状態なので、無理して急いでやる必要もなく、兼任なので元の業務の方が優先となりRPAの開発はあまり進まなかった。

初リリース

4月になり途中まで作ってあったワークフローを引き継いで、やっと私が初めてのリリースをした。
ほぼほぼ出来上がってるといっていいくらいの物を引き継いだんだけどね。

業務としては社内のPCキッティング作業が完了したものを配送伝票番号と共に依頼者にメールで発送連絡する仕組みだった。

処理としてはPCのキッティング状況を管理しているシステムにログインし、管理DBから何十件も表示されてる情報を一瞬でスクレイピングして取り込み、それに対してまた別のグループウェアで1件ずつメールを送信する仕組みで、スピードが速く1通1通違う宛先に違う伝票番号を記載しながら送付するので、デモとしても見た目が良く、その後のRPAの紹介でも頻繁に使ってた。

つづく