この記事ではRPA(UiPath)案件の実践的な進め方や注意点について、説明していきます。これからUiPathを検証していこうとされている方や検証を終えて本格的に導入しようとしている方、導入済みだけど上手く運営できていないと感じている方、開発だけではなく計画にも携わっていきたいという方に読んで頂ければと思います。
【目次】
はじめに
RPA(UiPath)の開発をはじめていく際にどのように開発していくのか(アジャイル型?ウォーターフォール型?)や、どのようなドキュメントや管理が必要なのか等、分からないと思います。これらの問題を解決するためにUiPathでは高品質な開発や管理ができるように無料でドキュメントを公開しています。提供されている代表的なドキュメントは2020年8月11日現在では下記です。
0.政府CIOポータル「RPA導入実践ガイドブック」
各府省が業務改革の手段として RPA を導入する際の基本的な方針及び考慮事項を示すために作成、公表されているものです。RPAの特徴や注意点、進め方等が纏めてられている資料です。推進していく上で参考になります。
https://cio.go.jp/sites/default/files/uploads/documents/RPA-dounyu-jissen-guide_20210330.pdf
1.RPAガバナンス構築のためのガイドラインおよびRPAガバナンスハンドブック
どのように自社にRPAを取り入れていくか、セキュリティ面やその他のリスクはどのようなものがあるのかの考え方を、UiPath以外のRPAでも扱えるような汎用的な内容で説明がされています。戦略を考える人や全体コントロール(ガバナンス構築)する人、監査に関わる人は必読のものです。
ホワイトペーパー：RPAガバナンスガイドブック | UiPath株式会社
2.UiPathメソドロジー
戦略立案からPoC(導入検証)、スモールスタート、強化、制度化のフェーズに進んでいくにあたって必要な作業フロー例や案件で使用するサンプルドキュメント一式が格納されているものとなっております。利用規約上UiPath開発以外での利用を禁止されていますが、それぞれのドキュメントのクオリティが非常に高く、ルールやドキュメント作成を行っていくにあたり非常に重要なドキュメントです。ボリュームが多いため全てに目を通すのは大変ですが、パワーポイント(説明資料)だけでも読んでまずは内容を把握しておく事をお勧めします。このメソドロジーの登場で案件推進のし易さは各段にあがったと思います。逆に他のシステム開発にも流用できる部分は多いです。
3.UiPathコーディング規約とワークフロー品質評価キット
コーディング規約と品質チェックを自動で行ってくれるツールセットです。社内用に規約やチェック内容は変更して扱っていきます。命名規則が例しか記載されていないため命名規則を定義する際のドキュメントは別で作成する必要があります。
コーディング規約とワークフロー評価キットを無料公開 ―RPAユーザーの高品質な開発を支援 | UiPath
4.UiPathデリバリーアセスメント
UiPath導入プロジェクトにおける考慮漏れや準備不足を未然に防ぎ、高品質な開発を実現できるよう支援するものです。上手くいっていない案件にコンサルが入って改善点の洗い出しや改善提案を行う現場がありますが、このうちの改善点の洗い出しをセルフチェックできるようにチェックリストとワークフロー(作ったプログラム)チェックツールを提供する事で可能とさせるものです。あらかじめPMが内容を抑えておく事で問題になる前に対応を行う事もできます。
5.ワークフロー開発実践テクニックレシピ ～第1弾～ワークフロー動作安定化
RPAは開発時に扱いに気を付けなくてはいけないお作法なようなものが存在します。実際に経験して社内ナレッジ化する事で、問題を回避していくしかなかったですが、テクニック集をUiPath公式が公表をはじめました。ワークフロー開発を行う人やレビューをする人は必読のものです。第2弾以降も今後登場してくると思われます。
ワークフロー開発実践テクニックレシピ ～第1弾～ ワークフロー動作安定化 | UiPath
7.UiPath 逆引きTips集&トラブルシューティング集
UiPathのStudio、StudioX開発時に役に立つTIPS集＆トラブルシューティング集とサンプルワークフローが格納されています。サンプルワークフローは76機能分入っています。開発時に役立つ事間違いないので、開発者全員が扱えるようにした方が良いです。この資料をベースに修正や追記したり、TIPSを更に追加して育てていくと良いです。
UiPath 逆引きTips集 & トラブルシューティング集 | UiPath
8.UiPath Orchestrator スターターガイド
UiPathの管理サーバーアプリケーション(Orchestrator)についてのスターターガイドです。Orchestratorでどのような事ができるかを把握する事ができます。UiPathではクラウド版のOrchestratorのサービス展開も開始したため、スモールスタートがよりし易くなっています。今までは費用や保守面が不安でOrchestratorを扱っていなかった企業の利用も増えていくと思われます。
UiPath Orchestrator スターターガイド | UiPath
9.UiPath製品 バージョンアップガイド
UiPath製品のバージョンアップについてのガイドです。StudioとRobot、Orchestratorについてのバージョンアップ計画方法や手順について説明されています。作業自体は単純ですが、バージョンアップ後にまれに正常に動作しない処理が存在する可能性があるため注意が必要です。
10.インフラ系のガイド(ミドルウェア、AWS、Azure導入)
インフラ系のガイドが公式のナレッジベースにいくつか掲載されています。
自社内にOrchestrator環境を構築予定やされている方に必要なものとなります。
ミドルウェアのガイドリンクのみ参考で貼っておきます。
Orchestrator 管理者のためのミドルウェア（IIS, SQL Server）運用設定ガイド ver 1.1
案件推進/構築の考え方
上記「はじめに」で記載している内容を見ればわかるかと思いますが、UiPathでは案件の進め方や保守、運用に至るまでの情報提供がされているため基本的な考え方としては上記のドキュメントを使って案件を進めていく事が、最適解だと思います。量が多いため各役割別に確認した方がよいドキュメントをマトリクスに纏めました
<UiPath製品を導入するまでを提案・推進する>
BC･･･ビジネスコンサルタント(セールス)
TC･･･テクニカルコンサルタント(プリセールス)
<RPA開発/保守/運用>
BA･･･ビジネスアナリスト
SA･･･ソリューションアーキテクト
IE･･･インフラエンジニア
ただドキュメントは汎用的に扱える記載になっているので、利用する環境(会社)に合わせてカスタマイズをしていかなければなりません。また、実際に使っていかないと気づけない部分があるため一番初めから完璧を目指しているといつまで経っても導入が進まないという事にもなるので、最低限のものだけ整備して徐々に整備を行っていくやり方が推奨です。メソドロジーにも記載がありますが、下記のイメージです。
『UiPathメソドロジー_ver1.1.0.pptx p26から引用』
案件推進時の注意点
様々な案件に関わってきた中で、注意した方が良いものを紹介していきます。
0.RPAプロジェクト案件フォルダ
フォルダ階層ルールを決めておかないと後々整理するのは大変です。サンプルでRPAプロジェクト案件フォルダ例を掲載しておくので参考にしてください。
1.設計書の業務フローの粒度
設計書にはAs-Is、To-Beフローを記載する例が存在しておりますが、こちらの設計書の粒度を細かくし過ぎると作成やレビューに膨大な時間が掛かり、簡易的すぎると処理内容が分からず意味を成さないものとなってしまいます。設計書の役割としては、どのような手順でどのような条件分岐や変換をしているのか、業務ユーザと認識相違が起きないようにする事と保守の時に仕様理解できる事が目的となります。既存で作業手順書が存在している場合でRPA化後も処理内容が変わらない場合、その手順詳細を細かくRPA設計書に記載しなくても良いと思います。また、既存の手順書の記載が足りない場合、RPA設計書だけその内容を取り込む事がありますが、既存の手順書にも反映しておくべきです。自動化した後に人で作業を代替する必要になった時に対応できなくなってしまう(有識者がいない)事が起きてしまいます。
2.案件フォルダ
各ロボ事の案件フォルダのテンプレートが決めないまま開発を進めていくとどこに何のドキュメントがあるのかすぐに分からず、非常に非効率になります。案件フォルダテンプレートは初期段階でも用意しておくことをお勧めします。後で整備していくのは非常に大変です、、上記「0.RPAプロジェクト案件フォルダ」の「20.開発案件管理」フォルダ中に「プロセス管理番号.プロセス名_UiPath」等案件フォルダ名のルールも決めたフォルダを作成していくのが良いでしょう。
【案件フォルダサンプル(フォルダ名の例：001.勤怠登録(日次)_UiPath)】
3.保守が考慮されていない開発
開発した人が保守するから設計書や運用マニュアルを作成しない現場がありますが、この考え方は危険だと思います。開発ができる人が保守にいれば作ったものを見れば分かるからとも言いますが、何もない状態でワークフローだけ見ても業務が分からないと理解に時間が掛かったり、重大なミスを起こしてしまったりの原因となります。RPA開発は低コストでできる観点からテスト環境を用意せず、本番環境だけで開発やテストをするものも存在します。テスト環境がある場合も、テスト環境用に切り替えが必要なものがある場合もあります。このような内容がドキュメントとして存在していないと保守が対応しきれなくなる要因となります。少なくとも下記の情報はないとトラブル対応やバージョンアップ対応時に非常に苦労する事となります。作った人が現場から離れる事も考慮して運用、保守できる体制を構築する事が推奨です。
<ドキュメントとして情報がないと保守の時に困るもの>
〇改修をする際、どこの環境を使ってどのように改修すれば良いかの情報
〇ロボが扱うフォルダやファイル一覧
〇障害時の対応概要
〇そのロボ特有の注意点(実行時に事前承認が必要等)
〇業務担当者の連絡先
保守に関して細かく必要な情報と確認できる状態(ドキュメント化)していないとどのように困るかの記事を別で記載しているので、詳細知りたい方は下記記事をみて頂ければと思います。
4.ナレッジ管理
案件推進していくと、次の開発に活かしていった方がよいものが出てきます。この時誰かの頭の中だけにそのナレッジがある状態にしてしまうと、過去苦労した事を同じように違う誰かが苦労してしまう無駄が発生します。これを防ぐために皆がナレッジをとりあえず記載できる場所を早めに用意しておいた方が良いです。可能であれば更にナレッジを整理して皆が参照できる場所に掲載をしていく事で、教訓を生かした高品質の開発を行う事が可能となります。UiPath開発を初めてやる人はこのTIPS集を必ずみて下さいやこのシステムを開発する人はこのTIPS集を必ず見て下さいというものができれば、品質は向上し、開発速度も早めていく事が可能となります。整理したナレッジの掲載場所はシェアードポイントやAutomationHuB等を導入するのも良いでしょう。ナレッジ整備に時間を掛けてしまいすぎないようにするのが注意点で難しい所です。
5.手順書の作成
ナレッジと似ていますが、端末セットアップ方法や利用申請、Orchestratorの操作手順等は誰でもできるように、本格的な導入を始めていく前に整備しておいた方がよいです。特定の人に頼りすぎると、特定の人に負荷が集中してしまったり、その人がいないと端末を増やせなかったり、リリースができない等の問題が発生してしまいます。作成時に少し時間が掛かってしまいますが、ロボットの数が増えていくにつれて、手順が整備できている現場とできていない現場で、対応速度やミスの多さ等保守の品質に違いが出てきます。
6.なんちゃってアジャイル開発
アジャイル開発という名でただ計画が曖昧なだけのウォーターフォール型プロジェクトが存在します。端末やアカウント、権限の準備は直前にやるものではなく、申請期間も考慮して計画的に行うべきです。案件がスムーズに進まない事で開発者の人は並行で違う案件を進めたりして作業効率も落ちて、ストレスも掛かります。見積もりができないため、計画が立てられない所も多いですが見積もりはアクション数(操作数)、分岐数、扱うシステム数、入出力ファイル数、重要度、複雑度、開発者レベル等で計画と実績の評価を積み上げていく事で、将来的には概算見積もりを機械的に出していく事が可能になります。そのため見積もり表作成のために、案件に掛かっている時間は管理しておくことをお勧めします。PoCの段階で見積もりを任せられそうな人材にUiPath開発をさせておくと、初期段階でもその人が概算見積もりを作る事ができると思います。
7.メーリングリスト
何か全体に不具合があった際や、各業務単位に問題があった際に業務担当者に連絡が必要となります。その際連絡先が一覧化あるいは関係者宛のメーリングリストを作成しておく事で、迅速に対応できるようになります。稼働ロボット一覧に連絡先の情報はあった方が良いです。
8.共通部品や初期テンプレートの利用
UiPathにはUiPath Go!と言われるマーケットプレイスが存在します。ここに無料で使える初期テンプレートや共通部品が1000個以上存在しているため、初期段階から活用していく事をお勧めします。初期テンプレートについては別の記事で詳細説明していますが、初期段階ではとりあえずAttended Frameworkを利用すると良いでしょう。エラーハンドリングやロギングについてを一から考えて作るのは大変です。
9.工数と体制の管理
どの開発現場でも同じですが、今までどの作業にどれだけ時間が掛かっているか把握する事は重要です。保守するロボの数が増えてくれば当然保守や運用に必要な時間も増えていきます。過去分の作業時間を抑えておけば伸び率を把握する事ができて、事前に要員の調整や計画ができます。また、時間が掛かり過ぎている箇所に対して原因を調査して対策していくことも可能です。時間の管理ができていないといざ炎上気味になってきた際に、要員が足りないのか、無駄な作業をやってしまっているのかの把握から始まり、対策が遅れてしまい結果炎上してしまいます。しかし、管理できていれば、適切な時間の増え方をしている事、要員の調達が必要である事を会社側にも納得のいく調整が可能となります。
まとめ
UiPathの案件はUiPath社が公表しているドキュメントを活用していく事で、高品質な開発や運用をしていく事が可能です。但し、上手く活用していくにはシステム開発に必要な案件管理能力や調整力、あるべき姿を考えられるような人材が必要となります。初期段階や拡大期前は優秀なPMがプロジェクトにいるのといないのとで、その先の開発や保守効率に大きく違いが生まれてくると思います。また、上記「はじめに」に記載しているようなドキュメントの存在を知っているのと知らないのとでも大きな差が生まれます。「はじめに」に記載しているドキュメントは一通りダウンロードして必要な人が学習できる環境の提供(情報展開)をこのブログを読んで頂いた方に実施して頂ければと思います。
その他のUiPath情報も纏めています。下記リンク集の記事があるので、こちらから各場所に飛んで頂ければと思います。
