私がRPA(UiPath)に携わって一年くらいが経ち始めようとしていますが、新しい領域へのチャレンジは内心やっていけるのかなという不安もありました。同じようにこれからRPA(UiPath)開発に関わっていく、IT経験者の方々向けへどの辺で苦労するのか、どうやって解決していったかについてのナレッジをこのブログで記載していこうと思います。「少し調べて見たけど難しいと感じた」という方も解決方法が分かれば不安が解消されるかもしれませんので、是非参考にして頂ければと思います。(本記事は2020年7月に投稿した記事です)
結論としては、見本となるドキュメントや情報、便利なツールが色々登場してきているので、2019年の夏頃よりかは、より理解し易い環境が整っており、学習すれば未経験者でも習得できるのでIT経験者の方は安心して頂いてよいと思います。(ただ開発以外も含めた上級レベルになるにはそれなりの努力は必要となります。製品や業界の成長スピードが速く、皆を先導し続けるような専門的な知識やノウハウを持ち続けるには情報をアップデートし続けなければいけません)
<目次>
- RPAの仕事をやろうとしたきっかけ
- RPA(UiPath)との出会い
- 苦戦1:開発画面が小さく、開発した内容を把握しづらい
- UiPathアカデミーで入社前に勉強
- 苦戦2:UiPathの標準機能で何がどこまで出来るのか分からなくて、開発のイメージがつかない
- 転職後にいざRPA開発!!
- 苦戦3:エラー時運用が見積もり時に顧客と握られていなく、妥当な工数も判断できずどうすれば良いか困惑
- 苦戦4:完成形のイメージができず、どうやって作ればいいか考えるのに時間が掛かる
- 苦戦5:単体テスト仕様書をどうやって作れば良いか分からない
- 苦戦6:開発機と実行機が違う端末を使っていて、開発機では動くのに実行機で動かない
- 苦戦7:バージョンや製品名(ロボット種類)とライセンスが複雑
- 苦戦8:コーディングレビューに時間が掛かる
- 苦戦9:解決が困難な問題が発生したときの解決が困難
- 苦戦10:製品や業界の進化が早く、学習量が多い
- さいごに
RPAの仕事をやろうとしたきっかけ
まず私がRPAの仕事をやろうとしたきっかけですが、2017年頃にRPAが日本でかなり流行り始めて、これからはAIやRPAの仕事ができた方が市場価値を上げやすいと世間が騒ぎ始めていたのと、私自身身近な業務を効率化していく方が見えない誰かが使うシステムを作っているよりもやりがいがあったので、業務改善系の仕事につきたいと思い、RPA導入が盛んな企業に転職して私のRPA人生が始まりました。(初めての転職だったため、他の会社でも自分の力が通用するのか試したいという気持ちもありました)
RPA(UiPath)との出会い
転職活動時に未知の技術であるRPAについてまずリサーチを始める事にしました。入ろうと考えている転職先がUiPathをメインに取り扱っている事を聞いて、他社導入事例の本と『できるUiPath』という書籍を購入し、どのような事ができるのか、どうやって開発していくかを理解しようとしました。
事例集は「削減時間すごいなぁ」、「いろんな業種に適用できるんだなぁ」とかやれることの大枠が掴める程度でした。『できるUiPath』の方はUiPathの開発ツールである「Studio」の使い方がメインで記載されており、フローチャートを作って、その中にやりたい処理(アクティビティ)を配置してオプションをいじるだけで簡単に作れるんだなぁという感覚を掴む事ができました。この時点ではJava開発を結構やってきたし余裕かなと思っていました。(まさかこれからこんなに苦労する事になるとは思ってもみませんでした)
無料で使えるコミュニティ版があるという事でコミュニティ版をインストールして『できるUiPath』に書いてある事をとりあえず試してみる事にしました。ここで早速1つ目の苦戦ポイントが、、
苦戦1:開発画面が小さく、開発した内容を把握しづらい
下記が実際のUiPathで開発を行う際の開発ツール(Studio)の画面です。
赤枠部分が実際にフローチャートを作り、処理ごとのパーツ(アクティビティ)を配置していく所ですが、見えている部分が少ししかなく、全体をぱっと見る事が難しいです。右下の表示倍率を調整する事で全体が見えやすいように多少なりますが、それでも小さいと当時は思っていました。さらにフローチャートを久しく書いてなかったので、完成後のフローチャートが頭に浮かばず、作成や確認するのに時間が掛かりました。
ここの苦戦の解決方法は慣れる事です。頭でフローチャートを作り上げる事ができない人は紙に書いてみてその紙を見ながら開発を行っていくと、そのうち自然と頭の中でフローチャートを描けるようになっていきます。
慣れたからといってフローチャートを全く書かなくなるかと言われれば、そうではありません。複雑な分岐の開発を行っていく場合に頭が混乱してきたときは、まず目に見えるところに書いて整理する事が大事です。誰かにフローを相談するときにも目に見える状態にして相談はしましょう。
赤枠部分で「右クリック」→「イメージとして保存(S)」を押すと画面の内容をイメージとして保存してみる事もできるので、確認する際にはこちらの手法を使うのも良いかもしれません。設計書に詳細の業務フローを作らないでこのイメージを設計書にペタッと張り付けて補足するのもありかなと思います。補足も注釈という機能を上手く使えば文字になりますので、Studio上で表現する事はできます。
UiPathアカデミーで入社前に勉強
UiPathでは無料でオンライン学習できるサイトを提供しています。入社後はこちらのアカデミーを使って勉強を開始していくという話を聞いていましたが、早く即戦力になってできるやつがきたというイメージをつけたかった私は入社前にアカデミーを使って個人学習を始めました。
変数やデータテーブル等の知識は持っていたので楽々進んでいきました。UiPathアカデミーは2020年5月よりリニューアルされており、一年前もクオリティが高かったですが、今は更に高くなっています。書籍を買って勉強を始めるよりもまずはアカデミーに登録(無料)して学習を進めていく事をお勧めします。
理解できてきたところで自分でなにか作ってみようと思い、開発し始めたところで2つ目の苦戦ポイント登場。
苦戦2:UiPathの標準機能で何がどこまで出来るのか分からなくて、開発のイメージがつかない
標準のUiPathでどこまでの事ができるのか把握できていない状態なので、この操作は標準のアクティビティでできるのか?どのアクティビティを使うのが良いのか?という判断ができなかったり、選んだアクティビティよりも優れたアクティビティがあり、選びミスをしてしまったりが多発しました。
どんなアクティビティが標準に存在していて、どの部分をどうやって作るのかがイメージできないと開発の見積もりもぶれぶれのものになってしまうし、そもそも実はこんな事はできませんでした。という事で開発が失敗してしまう事があると思い焦りました。
この苦戦の解決策はまず基本のアクティビティに慣れてどのような仕組みでUiPathが動いているのか把握した後に、アクティビティ一覧を確認してUiPath標準で出来る事を頭に入れておくことで解決する事ができます。UiPath公式が公表している日英対訳表のアクティビティ一覧か、一覧表を纏めてくれているブログがあるので、そちらを見て把握していくと良いと思います。(現在の私は後記で紹介するworkflowInspectorというUiPath社が無料で提供しているツールを改造して、アクティビティを一覧化してそれを見ています。いつか見やすく整理できたら展開しようかと思います)
UiPathで実現できる事について、更にレベルを上げていきたい方は旧UiPath Go!(現在はマーケットプレイス)というUiPathのマーケットプレイスで公表されている部品の内容も把握する事をお勧めします。標準機能では作りこみが必要なものや実現が難しい処理がマーケットプレイスの部品を扱う事によって、実現できたり、少ない工数で作成する事が可能となったりする可能性があるからです。会社で利用する際はセキュリティ基準を満たしているかや公式サポートがされているか、サポートが手厚いか注意してください。
RPA コンポーネント - コレクション、連携パッケージ | UiPath Marketplace
転職後にいざRPA開発!!
入社して割とすぐに早速現場で開発を行う事になりました。(2案件同時のリーダー兼開発者)いきなり2つの案件同時かよと思いましたが、できる人を目指すためにYESマン発動でとりあえずやってみる。1件目が要件定義からで2件目が提案(見積もり)からの案件でした。ここで3つ目の苦戦ポイント。
苦戦3:エラー時運用が見積もり時に顧客と握られていなく、妥当な工数も判断できずどうすれば良いか困惑
今までトラブルが許されないようなシステム開発ばかりしてきていたので、エラー時運用も考えた上で、開発を進めていくのが当たり前の世界で育ってきた私は要件定義からの案件で障害時運用を顧客と相談しました。すると顧客要望は複数手順(システム別)があって、各場所で複数明細の処理をしているが、どこの手順で失敗しても、各明細別に再実行可能な作りにしてほしいという要望だったのです。当時の私は初心者だったので、見積もりの工数を見て、こんな工数でもできるものだと思っていましたが、結果としては全然工数が足りなく、プチ炎上しました。
この苦戦の対応策は見積もり時に障害運用の大枠も顧客側と握った上で見積もりをする事が解決策となります。また、見積もりを正確に行っていくには、処理数(アクティビティ数)と分岐数、扱うファイル数、システム数、開発者レベル等々を係数で掛けて算出する見積もり表を作り、実際に使って実績と照らし合わせて微調整していく事で精度の高い機械的に工数を算出する見積もり表を作り上げていく事ができます。見積もりの根拠があれば顧客も納得感があるので、あると便利です。設計書や移行等の工数は自動化対象業務の設計書や手順が揃っているか等個別に変わってくるため、タスク積み上げで見積もりを算出します。(根拠のある見積もりができないと工数足りないのでそれはできませんと調整することすらできなくなってしまいます)
また、特に初期テンプレートが決まっていないのであれば、Attended Franeworkという初期テンプレートを使って開発することをお勧めします。初期設定ファイル読み込み、エラーハンドリング、ロギング機能が備わっており、初心者向けの作りになっているので便利です。初期テンプレートで決まったものがない場合是非活用してみて下さい。再実行可能とする仕組みは作りこみすぎると保守の難易度も上がりますので、再実行可能なポイントはあまり細かく設定しすぎないようにする事と再実行の仕組みは本当に必要かどうか確認して調整した方がよいです。顧客側は再実行できた方が嬉しいのは当然ですので、業務の重要度や障害時対応内容、開発工数によって、再実行処理実装有無と作りこみレベルを決める事が重要です。また、プログラムのデザインパターンを整えて、使いこなしていけば開発時間がかなり削減できていきます。
苦戦4:完成形のイメージができず、どうやって作ればいいか考えるのに時間が掛かる
入力ファイルを読み取って、結果を同じ入力ファイルの明細毎に書き込む処理や複数の入力ファイル情報をキーで紐づけて開発していくもの等様々な開発パターンがあるのですが、初めのうちは完成形がイメージできないのです。
その場は経験者の人にサポートに入ってもらって、完成したものを見る事で理解できましたが、この苦戦の対策としては誰かが開発したプログラムをたくさん見ておく事です。これは他のプログラム言語でも同じ対応策だと思いますが、完成しているものを見て理解していく事で、作り上げる完成形がイメージできるようになります。また、より効率的な作り方の方で各開発パターンを上書きしていく事で、効率的な開発を行えるようになっていきます。今回は説明を省きますが、ブラウザは何を使うのが一番効率的なのか、Excelアプリケーションスコープとワークブック機能のどちらを使うのがベストなのか等自動化対象や内容によって、ベストな作りは変わってきます。経験によりベストな作り方の法則が見えてきますので、それをTIPS化していく事で、皆が品質の高い開発が行えるようにしていく事が可能です。(UiPathナレッジベースにいくつか情報があがっています)
UiPathでは初期テンプレートをいくつか公式で用意しています。この初期テンプレートをまずは理解し、その後に誰かが開発したものを会社内で見たり、ネットに転がっているものをみたり、UIPath マーケットプレイス(結構難しい作りのやつ多い)のものを見て徐々に力をつけていくと良いです。初期テンプレート(フレームワーク)についてはしおちゃんさん(@Jun96427231)のブログを参照頂ければと思います。
UiPathあなたに最適なFrameworkはどれ? - Qiita
苦戦5:単体テスト仕様書をどうやって作れば良いか分からない
今までは決まったフォーマットが用意されており、過去作られているものを参考に作成していけばよかったのですが、テスト仕様書が顧客毎にフォーマットもばらばらだし、作ってあったり作ってなかったりして、どんな仕様書を作成すればよいのか悩みました。今までの経験を活かして独自のフォーマットを作り、細かい機能単位を単体とみなして当時はテストをしましたが、テストケースを一から作ったりするのに余計な時間が掛かりました。
この苦戦の対応策をしては、現在ではUiPathではUiPathメソドロジーという凄まじいドキュメントが無料提供されており、こちらを活用する事で解決する事ができます。このメソドロジーには、単体、結合、UATテストケースのフォーマットはもちろん、障害管理票やインフラ設計書、ロボット管理表、セキュリティ、ライセンスポリシー等様々なドキュメントが用意されています。色々調べて摸索しましたが、基本こちらのドキュメントを改造して自分達が使うドキュメントを整備していくやり方が最適解だと思います。単体テストケースは対象業務の重要性や開発者のレベルによって作る作らないを変えたり、チェックシートレベルの簡易版としてだけ作ったりするといったやり方もありだと思います。(UiPath以外の利用は免責事項で禁止されているので注意)
苦戦6:開発機と実行機が違う端末を使っていて、開発機では動くのに実行機で動かない
UATになり実際に扱う端末で動かそうとしたところ、開発時で動いていたものが実行機で動かない事態がおきました。「あれっ?誰かバグった資源を最新にあげたのかな?」と思いましたが、開発機では同じ資源で問題なく動作するのです。
UiPathではセレクター(画面上の構成要素を特定するための文字列)とOCR(イメージ)機能の2種類の仕組みで操作対象を特定して処理をしています。このセレクターが違う端末だと違う値になっている事があり、動かないのです。またインターネットオプションの設定が違ったり権限の設定が違ったりすると正常に動作しないパターンも存在します。全く同じ環境にする事でこの問題は解決できるのですが、アプリ単位(エクセル)のツールバーの表示有無でもセレクターが変わってしまったりしてかなりやっかいです。RPAが敬遠される大きな理由の一つはここです。
対応策としては開発機がそのまま実行機にできればよいですが、できない場合まずは端末間の環境差分を極力なくす努力をする事です。OSの言語設定やタイムゾーン、機種や画面サイズ、グループポリシー(権限)、等々や各Officeのツールバーや設定をあわせておくと同じように動作する確率が上がります。差分をあわせた方が良い項目をチェックリスト化すると良いでしょう。あとはセレクターに注意を払って開発をする事です。セレクター内に「はい」とか「データ」とか画面上他の場所にも登場していきそうな値が入っていれば、パターンによって画面上に2個その項目が出てくる可能性がないか考えます。
セレクターは画面上に同じ要素が2つあったりする場合、idxという連番を振る識別情報が付与されます。「idx=2」というセレクターは画面構成上2番目のものという意味になります。これが状況によって1だったり、3になったりする場合があるので、idxなしでも特定可能とできるか、idxの番号が変わる可能性はないかを考慮して開発を行う事で、環境の変化に強い開発を行う事ができます。ブラウザを扱う場合開発者ツール内でソース内を検索して調べると確実です。画面上に見えていないけど隠れて同じ項目名が存在している場合もあります。
また、特定できていてもオプションの内容によって動作したりしなかったりという場合もあります。対応方法の詳細は様々なブログやUiPathのナレッジベース等に情報があるので、そちらを見ながら環境変化に強い開発を行っていくしかありません。いつかUiPath公式か誰かが各アクティビティで環境変化に強いベストな作り方集を作成して展開されれば良いですね、、ここは扱うシステムによって対応も変わってきたりもするので今でも日々苦戦します、、(アンカー機能を使ったり親要素、子要素を活用したりjavaScriptを仕込んだり、イメージ認識にしたり様々)
苦戦7:バージョンや製品名(ロボット種類)とライセンスが複雑
UiPathには製品のバージョンとそれを扱うためのライセンスとロボットの種類が存在します。よくAR、UR、OC、STという言葉が飛び交います。初めは慣れないのでこの略称は覚えていた方が良いです。(URはとあるCMで良く聞いていたので聞く度に頭にであーる!が思い浮かんでいました)AR(Attended Robot)、UR(UnAttended Robot)、OC(Orchestrator)、ST(Studio)。
また、よくバージョンとライセンスがごちゃごちゃになってしまう事があります。ライセンスは各製品を使える権利の事であり、バージョンと関連しているものでありません。上記のAR、UR、OCのライセンスを購入し、選んだバージョンをインストールしてライセンス認証する事で利用できます。(ライセンスは正確にはもう少し細かいバリエーションがあります)
バージョンは下記公式の情報をみて覚える事ができます。(会社であればサポート期間が長いロングタームサポートを扱っていくのが多いです。バージョンアップ時には無影響確認やバージョンアップ作業をしないといけませんが、頻繁にあると保守工数が高くなるためです)
ライセンスは新ライセンスに変わってきているので、この記事内では説明を省きます。
Overview - Product Lifecycle (uipath.com)
UiPathのStudioやアクティビティパッケージのバージョンについては、下記Qiitaで解説している記事を別で投稿しているので、各バージョンについて知りたい方はこちらの情報もご活用下さい。
【RPA(UiPath)】各バージョンとアクティビティパッケージの解説(Orchestrator観点無) - Qiita
苦戦8:コーディングレビューに時間が掛かる
誰かが作ったワークフローの平仄が取れているか、変数名のスコープ(利用範囲)が正しいか等確認するのに苦労しました。Studioで一つ一つアクティビティにフォーカスをあてて移動しながらチェックしていきましたが、全体の平仄が取れているのか確認するのは辛過ぎました、、Excelにエクスポートしてプログラム上で纏めて確認できるものはチェックするような職人みたいなやり方をしていました。。。。
こちらの対応策としては、現在は2019.10のバージョンよりコードチェック機能(WorkFlowAnalyzer)がStudioに搭載されたのと、無料で公開されているWorkFlowInspectorというツールを活用する事である程度自動でチェックできるようになっています。WorkFlowAnalyzerで頻繁に実施者にチェックさせ最後にWorkFlowInspectorでチェックを行うやり方が個人的にお勧めです。コーディング規約も無料で公開されています。コーディング規約には開発のベストプラクティスの要素も入っているので、是非一読して頂ければと思います。
コーディング規約とワークフロー評価キットを無料公開 ―RPAユーザーの高品質な開発を支援 | UiPath
苦戦9:解決が困難な問題が発生したときの解決が困難
開発をしていくとたまに解決困難な問題が発生する事があります。このようなとき大体JavaとかCとかの開発現場では、詳しい人がいて聞いたり、インターネットで調べれば解決できるのですが、まだインターネット上に情報として存在していなかったり、誰も経験したことがない問題が発生する事があります。
この苦戦の対応策としては3つ。社内か知り合いの詳しい人に聞くか、UiPathコミュニティフォーラムに質問を投稿するか、UiPath公式のカスタマーサポートに質問をするかです。UiPathコミュテニィフォーラムには世界中のUiPathユーザーが質問に答えてくれます。社内で解決しない場合は、こちらに問い合わせして解決してみると良いでしょう。誤りが許されない重要な質問や社内機密等の重要情報に関わる質問、コミュニティフォーラムでも解決しなかったものは、UiPathカスタマーサポートで問い合わせすると良いでしょう。(但しカスタマーサポートはライセンスを購入している人しか問い合わせできません。Webのフォームから問い合わせを行い、メールで回答が返ってきます。メールでそのまま不明点をやり取りする事もできます)
Latest 日本FAQ topics - UiPath Community Forum
下記記事に分からない事の解決方法を別途纏めているので、解決方法をもっと抑えたい方はこちらの記事も参考にしてください。
UiPathコミュテニィフォーラムの過去質問と回答を頭の中にいれておくと、問題発生時にフォーラムにたしか書いてあったなとすぐ辿り着いたり、その場で解決する事ができるようになったりします。極めたい人はフォーラムの過去投稿分析もすると良いと思います。
苦戦10:製品や業界の進化が早く、学習量が多い
2019年以降UiPathは一気に成長し、公式サイトが見やすくなったり2020年に入ってからはプロセスマイニングやテスト自動化等の新製品が出てきたりと技術と共に成長していっています。RPAはAI-OCRやAIとも連携して活用されていくため、幅広い専門知識が必要となってきます。最新技術は常に学習が必要となる領域です。まだ誰も分かりやすく纏めていない部分も時には自分で調べて悪戦苦闘しながら進めていかなくてはいけません。チームを牽引していくような立ち位置を目指す方は、学習を続けていく覚悟が必要です。
UiPathの開発をやる方は、UiPath社の公式が出している下記の書籍を机の横に置きながら、分からない所があれば本を見ながら習得していくやり方がお勧めです。現在2バージョンの書籍があるので、最新と古いバージョンを間違わないようにお気を付け下さい。
さいごに
2019年中旬頃に比べて、2020年7月現在では当時苦戦していた事を苦戦しないようにUiPath公式や各ブログを発信されている方々、UiPath Friendsのコミュテニィの人が情報を発信していたり、オンライン上から遠隔サポートをしてくれるサービスを展開している企業やサービスが始まったり、開発の基盤は年々整ってきているのではないかと思います。
ただ、存在している情報に気付く事ができなければ、一から自分で作り上げたものが既に最適解が存在していた、、、というような事が発生してしまいます。このような事にならないようにどこに何の情報が存在しているのかを把握し、ナレッジベースや技術者ブログ、twitterを日々チェックする事はRPA推進者としてとても重要です。私のブログでもUiPath情報取得先を纏めていますが、自分なりに必要な情報を取捨選択して情報収集して頂ければと良いのかなと思います。
これからUiPathに関わっていこうかなと思ってブログを見てくれた人にとって働くイメージがつくような情報になっていれば幸いです。
↓私の方で収集した有益な情報はここに集めていきますのでどこになんの情報があるか知りたい方は参考にして頂ければと思います。ナレッジベースの更新情報とかその他の細かい情報はtwitterで何かあれば都度お知らせしていますので、自分で検知するのが面倒な方はフォローして頂ければと思います。RPA以外にもIT人材育成関連、DX関連等様々なITに関わる事を主にツイートしています。
twitter:@RPA_AI_it
⇩上記リンク先にはこんな情報のリンクが纏まっています。