RPA開発を行う際に、「ドキュメントをどこまで作りこんだらよいのか」や「上手く保守をしていくために必要なものが何かわからない」と困る事が多いと思います。スモールスタートをして、必要な物を徐々に追加や整理していくのが良いですが、その際にも整っている状態はどのような状態かを知っているのと知らないとでは対策の速さに差が出てきます。今回は保守に必要な情報が整っている状態がどのような状態なのかと、各情報のドキュメント化の必要性を判断するための考え方を説明していこうと思います。
<目次>
保守とは？
まず、この記事内で説明する保守の定義について説明します。開発を終えて本番環境にリリースをした後は運用と保守の作業があります。企業によって運用と保守の定義がばらばらなため、この記事内では下記で分類をします。
運用：システムが停止しないようにする業務。起動や停止、バックアップ、システム監視、ログ分析、パスワード変更、ライセンス更新等を行う業務です。
保守：不具合の原因究明や対応、バージョンアップ、機能拡張を行う業務です。
この記事では、上記保守の部分に対しての内容を引き続き説明していきます。
一般的なシステム開発とRPA開発の違いについて
次にRPAへの保守の考え方を身につけるために、RPA開発の特性を大規模システム開発との違いを交えて説明します。大規模なシステム開発では、開発に時間が掛かるのと今後の保守の事を考えて、開発環境と本番環境を用意して開発及び保守を行っていきます。本番で何か問題が起きた時は開発環境でバグ修正した後にテストをしてから本番環境にリリースを行います。重要又は並行開発があるシステムの場合は更に検証用の環境が用意される事もあります。しかしRPA開発は下記の特性があり、開発環境が用意されなかったり、用意できなかったりする場合があります。
<RPA開発の特性>
・小規模な開発を求められやすい
→RPA開発用の開発環境は準備しようとすれば出来るが費用対効果が出にくくなるので敬遠される事が多い。
・自動化対象システムの開発環境が存在しない事がある(クラウドのシステム等)
・RPA開発者とシステムや業務担当者が違う人で、業務担当者側は自動化対応工数の割り振りが少ない又はそもそもない
上記の理由でRPA開発現場では、全て本番環境であったり、一部が本番環境であったりした状態での開発が必要となる場合が多いです。開発環境が存在していても、元々RPA用に準備されているものではない場合があるため、どちらの環境を利用するにしても下記のような一定の制限が掛かる事が多いです。
<環境利用時の制限例>
・環境利用時は業務やシステム担当者の許可を得る必要がある
・データ更新は禁止
・データ更新が許されるのはRPA用に用意されたデータのみに限られる
RPA開発をしていく際には上記のような情報を確認してから開発をしていきますが、この情報をどこかに残しておかないと、トラブル修正や改修があった際に利用許可を得るのを忘れてしまったり、更新してはいけないデータを更新してしまったりの事故が発生します。また、保守の担当者が変わった際にこの情報が残されていないと、修正時にこれらの情報を確認する所から始まり、自動化対象業務やシステムに精通している人でなければ、どんなRPA開発プロフェッショナルでも対応するまでに時間が掛かってしまいます。いわゆる保守作業の属人化が起きます。
保守に必要な情報について
RPA開発の特性を理解頂いたうえで実際に必要なドキュメントや整理すべき内容について説明をしていきます。個人的には業務担当者がRPA開発を行う場合は、マクロやVBAの保守に必要なものとイメージ的には同じなのではないかと考えています。業務担当者以外がRPA保守をする場合は、「マクロやVBAの開発・保守を他部署の人が可能にするために必要なものは何か」を考えていけば必要なものが整理できるのではないかと思います。(RPAはシステムよりに考えられ監査対象となりやすい点で明確な違いがあるのでそこは注意です)
「マクロやVBAもただ作成されているだけでドキュメントはなく、属人化して保守できる人いないけど正常に動いているから使い続けているよ」という現場もあるかと思いますので、一から整っている状態がどんな状態なのかを説明していきます。
まず、属人化しない状態で保守が可能にするためには下記の情報が確認できる状態になっている必要があります。業務担当者がRPA開発と保守する場合と業務担当者以外がRPA開発と保守する場合で、業務への理解度が違うため必須の情報に違いがでます。業務担当者が開発と保守する場合もすべての情報が揃っている方が、属人化を未然に防ぎ担当者変更時の引継ぎを効率良く行えるため望ましいですが、工数とのトレードオフになるためこれから説明する情報を参考にして自分のチームに必要なものを選定頂ければと思います。
<保守に必要な情報一覧>
上記必要な情報について、確認できる状態(ドキュメント)が存在しているとどんな時に役に立つのか、逆に存在していないとどのように困る可能性があるかをそれぞれ説明していきます。作成しない場合には、困る事に記載している内容を許容する事になります。
UiPathメソドロジーはUiPath社公式が無料で公開している開発フレームワーク(ドキュメント)です。下記サイトからダウンロードする事ができます。各ドキュメントのクオリティがそれぞれ高いためお勧めです。(UiPath以外での利用は禁止されているので注意)
「運用研究会 / 日本UNIXユーザ会：運用ドキュメントのあり方と課題」という2011年に公開された運用ドキュメントの考え方や課題を整理した上で、 「手軽にスピーディに継続的に保守できるドキュメント」 を実現するために必要な「情報の構造化」「再利用」「ドキュメント管理」について、説明されている資料があります。少し情報が古いですが、考え方はとても参考になります。この中で「使われない情報に価値はない」と説明されていますが、誰もどのフェーズでも使わない、使いにくいものも改善すべきと思います。
https://www.nic.ad.jp/iw2011/nee4X/t3-01.pdf
(1)業務の重要度、複雑度
<存在していると役に立つ時>
・改修や障害対応があった際に、適切な開発レベルの担当者に作業を割り当てる事ができます。
<存在していないと困る事>
・重要度や複雑度の高い業務を不適切な開発レベルの担当者に割り当ててしまい、重大な事故を起こしてしまったり、想定以上に作業に時間が掛かってしまったりしてしまいます。
(2)個人情報等セキュリティに問題のあるものを取り扱っているか
<存在していると役に立つ時>
・上記(1)の記載内容に加え、担当者が作業に関わる際に「慎重に作業をしないといけない」という意識を持たせることができ、情報漏洩リスクを軽減する事ができます。
<存在していないと困る事>
・上記(1)の記載内容に加え、開発者が情報漏洩に対しての意識が足りず、情報漏洩リスクが増加します。
(3)法令・規則の影響有無
<存在していると役に立つ時>
・法令・規則(内部統制)への影響がある業務なのかどうかによって、会社内で定められた統制のルールに従って、ロボットが行う処理が正確かつ網羅的であることを説明可能なドキュメントの対応が必要となるものがあります。財務報告に関わる業務が対象とされている場合が多いです。情報が存在する事によりこれらのドキュメント対応漏れを防ぐ事が可能となります。内部統制対象業務はドキュメントに記載しなくてはいけない粒度が細かくなる事が多いです。実施者が何故こんなに細かく作らないといけないのか不満に感じる場合があるので、内部統制の対応であることを説明しておくと不満を解消させることができます。
<存在していないと困る事>
・内部統制の対応漏れが内部監査の時に発覚して急遽対応が必要になったり、監査で問題を指摘された場合は、是正の計画や報告、ガバナンス修正が必要となったりします。そもそも統制がとれていない事で、重大な問題を引き起こしてしまう可能性もあります。
(4)業務担当者と障害時の問い合わせ先
<存在していると役に立つ時>
・問題が発生時や問合せ時の対応を確実にスムーズに行う事ができます。
<存在していないと困る事>
・問題が発生時や問合せ時の対応が遅れてしまうリスクが増加します。
(5)接続システム、アプリケーションが何か
<存在していると役に立つ時>
・接続システムや、アプリケーションの問題発生時やシステム改修があった際に、ロボットへの影響特定を容易に行う事ができます。
<存在していないと困る事>
・接続システムや、アプリケーションの問題発生時やシステム改修があった際に、影響調査をワークフローの中を見て調査する等、影響調査に時間が掛かります。
(6)利用している共通部品
<存在していると役に立つ時>
・共通部品に改修があった際に、ロボットへの影響特定を容易に行う事ができます。(ログに必ず共通部品を使っている事を出力するようにして、ログから収集する方法も可能)
<存在していないと困る事>
・共通部品に改修があった際に、ロボットへの影響特定をワークフローファイルを検索して調査する等影響調査に時間が掛かります。
(7)業務の対応時限、手動切り替え可否
<存在していると役に立つ時>
・障害時にいつまでにどのロボットを復旧させなくてはいけないのか、復旧を待てない場合人の手で代替する事が可能なのかが確認でき、誤った優先順位でロボットを復旧させたり、対応が遅れてしまったりの事態を防ぐ事ができます。
<存在していないと困る事>
・障害時に対応時限を過ぎて業務に支障が出てしまうリスクが増加します。
(8)実行スケジュール(稼働日、開始、終了予定時刻)
<存在していると役に立つ時>
・どのロボがいつ動くのか把握できる事により、メンテナンスを実施しても良い時間やインフラの障害発生時の影響調査を早く行う事ができます。(各端末でいつどんなロボが動作するかは纏まったスケジュール管理表を作成すると、どのロボをどの端末で動かすのか計画や管理も行う事ができます)実行トリガーが何か分かるようにもしておきましょう。
<存在していないと困る事>
・メンテナンス可能な時間や、インフラ障害時の影響調査に時間が掛かってしまいます。またライセンスの使用状況が把握できず、不必要にライセンスを購入してしまう事も起きてしまいます。
(9)現在のステータス(開発中、稼働中、利用停止中)
<存在していると役に立つ時>
・各ロボの利用・開発状況を容易に把握する事ができます。
<存在していないと困る事>
・各ロボの状況が現在どんな状況なのか(停止中なら何故停止中なのか)が分からず、ロボの棚卸時に状況を担当者に問い合わせをしなくてはいけなくなります。
(10)自動化業務の概要や現状の課題と要件が後で追える事ができる事
<存在していると役に立つ時>
業務ヒアリング時に業務概要、業務手順、現状の問題点や目的、自動化する箇所としない箇所とその理由を整理すると思いますが、こちらの情報を整理して残しておくと後で見返した際に、何故この手順は自動化対象から外されているのか等を知る事ができ、改修時の対応内容を決めていくのに役に立ちます。
<存在していないと困る事>
初回の自動化で対応していない箇所もRPAの進化によって自動化できるようになって業務を再度見直していく必要があったときに初めからヒアリングをしたり、当時何故ここは自動化していないのかの議論をしたりする工数が発生します。また、保守担当者が変わった際に、業務概要を業務担当者に再度確認が必要となる場合もあります。
(11)自動化前後の業務フローや手順
<存在していると役に立つ時>
自動化前の業務フローや手順が既にある場合はその資料がどこにあるのか、存在しない場合既存手順を整備しておく事が理想です。手順は必ず必要となりますが、業務フローは簡易版だけでも存在していると全体を把握する速度を早くする事ができます。手順が一覧になっており繰り返し条件や条件が記載してあってもそこから流れを把握するのは時間が掛かってしまいます。フローはStudioで作成後にイメージ抽出する事もできるので、なるべく設計書には細かく記載しすぎない方が良いと思います。
<存在していないと困る事>
手順が整備されていない場合、人の手作業で作業が必要になった場合や既存業務のRPA以外の見直しが入る際に、ワークフローから手順を把握していかなければならなくなります。理想は既存の業務手順が完全な状態になっていなければ、自動化する際に既存の業務手順書も最新化しておくことが望ましいです。既存の手順書がしっかりしていれば、ロボの設計書の手順個所は全ての処理を細かく記載する必要はなく、どこからどこまでが自動化の範囲なのか、既存の運用と自動化後で変わる箇所はあるのかの情報を記載できていれば良いと思います。RPA設計書の手順の粒度をどれだけ少なくできるかで設計書に掛かる工数は大きく左右されます。
(12)想定されるエラーや例外パターンと対応内容
<存在していると役に立つ時>
・エラーにはRPA起因のエラーと業務上で発生するエラー(利用システムのチェックエラー等)の大きく2パターンが存在します。両方のパターンの時にそれぞれどのように検知をして、いつまでに誰がどのように対応を行うのかが決まっている事で誰でも正しい対応を行う事が可能となります。
<存在していないと困る事>
・対象ロボに対しての知識がある人でないと対応に時間が掛かってしまうようになります。また、誤った対応を行ってしまうリスクも増加します。
(13)扱っている入出力ファイルの一覧
<存在していると役に立つ時>
・フォルダが変更になった際の影響調査や、どの処理でどのファイルを入出力しているかの把握を早く行う事を可能とします。また、取り扱いに気を付けなくてはいけないファイルを認識でき、誤った更新や利用を防ぐ事にも繋がります。
<存在していないと困る事>
・フォルダの影響調査やファイルの使われ方をワークフローから検索して、把握しなくてはいけなくなります。入出力が複雑なロボの場合、保守担当者が変更になった際、それぞれのファイルがなんのために扱われているものか(参照or更新)、仕様を把握するために時間が掛かります。
(14)どのようなテストが実施されているか
<存在していると役に立つ時>
・本番で障害が発生した際に、テスト考慮漏れだったのか、テスト時は正常だったがどこかのタイミングで変わったのか、何故UATで気づけなかった等分析をして、再発防止策や横展開を実施する際に、テストに問題があったかの特定が可能になります。
<存在していないと困る事>
・本番で障害が発生した際に、テストに問題があったかどうかの特定が難しくなります。
(15)ロボットの資源とドキュメント、設定ファイル等の最新管理場所
<存在していると役に立つ時>
・本番で現在動いているロボット資源とドキュメントの保存先が誰でも最新だと把握できるような状態である必要があります。ライブラリ管理ツール(SVNやGit)で管理できるのが理想ですが、ファイルサーバ上で管理する場合は最新バージョンが分かり難い状態になりやすいので、注意が必要です。また、プロジェクトフォルダ以外の場所で初期設定ファイルを管理している場合や、入出力ファイルがある場合は一覧で整理しておくと良いです。管理場所のルールはロボット毎ではなく、統一したルールを作成してそこに配置させる運用もありかと思います。
<存在していないと困る事>
・どこのフォルダに最新の資源が格納されているのか、格納されている資源は最新のものなのかの確認に時間が掛かったり、誤ったバージョンの資源を修正してしまったり、デグレーションが発生してしまうリスクが増加します。
(16)ロボ実行前のあるべき端末状態(実行手順)
<存在していると役に立つ時>
・ロボが実行可能な前提条件がある場合のロボが存在しますが(Outlookが起動済等)、そのようなロボを動かす際に、準備不足でロボを実行してしまいエラーとなるケースを防ぐ事ができます。
<存在していないと困る事>
・ロボが実行可能な前提条件がある場合、準備不足によりエラーとなってしまうリスクが増加します。また属人化の原因にも繋がります。
(17)仕様面で理解が難しい個所が理解しやすいように整理されたもの
<存在していると役に立つ時>
・各画面に入力する前に値を変換していたり、途中新たに作成したVBAが存在していたり、他システムのインターフェースが複雑な場合は、作成者以外の人でも理解ができるように入出力画面項目定義書やインターフェース仕様書、VBA仕様書の作成が必要となります。作成されていると仕様の理解や本来あるべき正しい状態を確認する事ができます。
<存在していないと困る事>
・保守担当者が変わった際に仕様が難しい個所の把握に時間が掛かります。また難易度が高い場合はドキュメントがなければ高レベルの開発者ではないと扱えなくなってしまう場合もあります。
(18)テスト環境の有無及びテスト方法の注意点やテストデータ
<存在していると役に立つ時>
・トラブル修正やテスト、動作検証時に、注意しなくてはいけない事を担当者が把握可能になります。
<存在していないと困る事>
・担当者が変更されここの引継ぎを受けていない場合、この情報を業務担当者に再度確認したり、フォルダの中を漁って調べたりとかなりの調査時間が必要となります。整備されていないと結構実施者にストレスを与えます。また、注意点を知らず更新してはいけないデータを更新してしまったり、送ってはいけないメールを送信してしまったりといったリスクが増加します。本番、テスト環境の切替作業がある場合はその箇所と手順を纏めておく事が必要です。差分がないワークフローをテスト用、本番用で重複して別資源管理するのもお勧めしません。
(19)複数端末やライセンス毎のスケジュール表
<存在していると役に立つ時>
・各端末やライセンスの空き状態、UiPathバージョンやライセンス期限を容易に把握する事ができます。スケジュール表を作成しておく事で、障害時の影響調査や対応を効率的に行う事もできます。
<存在していないと困る事>
・各端末やライセンスの空き状態や利用状況が確認できず、不必要に端末やライセンスを手配してしまったり、スケジュールを重複して計画してしまったり、リリース直前で利用できる端末やライセンスが足りないといった事が発生してしまう原因となります。
(20)変更管理フローや保守内で対応できる工数の取り決め
<存在していると役に立つ時>
・リリース後に改修できる保守工数が決まっていないと、「業務担当者は本番で何か起きてから修正してもらおう」という気持ちがありUATでしっかりと確認してくれていない事が起きやすくなります。その結果、計画外の保守作業が増えて保守チームの作業が逼迫してしまう原因にも繋がります。定義や整理できる状態にしておく事で何故変更管理が発生してしまったのかの分析や保守チームの作業を適切に運営していく事が可能となります。
<存在していないと困る事>
・上記で記載の通り、本番での障害検出率が高くなる傾向があります。また何故要件定義や開発時に要件の取りこぼしが起きてしまったのか、反省されず同じミスを次の案件でも起こしてしまったり、保守チームに改修依頼が大量に来て作業が逼迫したりしてしまうリスクが増加します。
(21)ロボが稼働している端末、管理者、アカウント、ライセンスの管理
<存在していると役に立つ時>
・ロボが稼働している端末のホスト名やアカウント名、管理者やライセンス利用状況を把握しておくことで追加や更新、バージョンアップ、故障時の手配を漏れなく行う事ができます。開発機と実行機はなるべく近い機種や画面サイズで合わせたほうがロボの動きは安定するため、そこの違いによる障害切り分けにも役に立ちます。
<存在していないと困る事>
・ライセンス更新やバージョンアップの対応をどの端末に実施しなくてはいけないか、誰に連絡すればよいのかの把握を一から実施しなくてはいけなくなります。管理できていない事で突然ライセンス期限や証明書の期限が切れてロボが動作しなくなったり、手配する端末の機種を誤ってしまったりするリスクが増加します。
(22)ロボ端末、サーバーに入っているべきアプリケーションとそのバージョン、設定されているべき情報
<存在していると役に立つ時>
・新規で環境を増やす際に、アプリケーションのインストールや設定漏れを防ぐ事ができます。構築手順も作成しておくのが推奨です。また、Windows updateによって設定が初期化されてしまった際に どこの設定が戻ってしまったか早く問題個所を特定する事ができます。(インターネットオプション等の設定はレジストリという場所に設定が保存されており、それはエクスポートしておくことができるため正しい状態のものをエクスポートしておくと、影響調査の比較作業を容易に行う事が可能です)
<存在していないと困る事>
・新規で環境を増やす際に、作業漏れやミスが発生しやすくなります。また構築作業の属人化もします。また、正しい設定がどの状態なのか分からないため、一度検討したはずのどの設定が正解なのかの調査に多くの時間を消費してしまいます。
(23)Orchestrator端末、サーバーに入っているべきアプリケーションとそのバージョン、設定されているべき設定値
<存在していると役に立つ時>
・上記(22)と同様
<存在していないと困る事>
・上記(22)と同様
さいごに
「こんなに整備しなきゃいけないのか、、、」とげんなりしてしまった方もいらっしゃると思いますが、会社の文化や、保守する人のレベルや環境によって必要な情報やその粒度は変わってきます。一つずつ現在の現場にこれまで説明してきた情報は必要なのか試行錯誤して取り入れて頂き、最適な保守が実施できるようになればと思います。長く保守していくものに対しては整備してドキュメント化しておいた方が有効だと思います。UiPath社が提供しているメソドロジーのドキュメントに沿って作成していけば『保守に必要な情報一覧』の『UiPathメソドロジーのドキュメント内に記載する場所有無』項目が有のものは考慮できているので、無の部分をどうするかを追加検討頂ければと思います。ドキュメントは作る事自体が目的になってしまいがちですが、なんのために必要なのかを考え、不必要な情報は極力無くすようにしましょう。
この記事には記載していませんが、各ロボ毎の案件フォルダにルールがないとどこになんの情報が入っているのか分からず、同じく保守作業が大変になりますので、フォルダはルールを設けて運用する事をお勧めします。下記記事の『2.案件フォルダ』にフォルダサンプルを記載していますので、参考にして頂ければと思います。皆様の高品質な保守運用のための参考になっていれば幸いです。
また、UiPathについて他の情報の記事も下記リンク一覧に纏めてありますので、興味がある箇所を是非確認頂ければと思います。
