元気しとーと？ 博多に住んどうUiPathプリシェールス @ManabuTechばい。
（お元気でしょうか？ 博多に在住しておりますUiPathプリセールスManabuTech です）
市民開発として業務担当者がRPA開発を推進する企業が増えてきました。
皆様の会社のルールは重いでしょうか？それとも緩いルールでしょうか？
RPAはルールにより、企業の展開のスピードが変わってきます。
重すぎるとRPA開発が進まない一方で緩くしすぎると、システムの誤入力やメール誤送信などにつながるリスクが上がります。開発者は楽に作りたいけれど管理者は正しく管理しておきたいという相反する要求を持っています。
UiPathのAutomation Cloudの機能を利用することで、管理統制をしながら気軽にRPA開発できる環境を作れ、RPA開発者と管理者の相反する要求を満足することが可能です。
もしも企業でRPA開発のルールでお悩みの方は、本記事が参考になるかもしれません。
こちらの記事はUiPath Automation Cloudの利用を前提とした内容であり、かつ個人的見解を多分に含みます。
RPA開発と管理の4大原則
RPA開発を企業が進めていく中で守るべき大原則が4つあります。
- RPA開発と一括りにせず、開発レベルを分けて管理すべし！
- タスクの自動化でも最低限の管理はすべし！
- ルールやチェックで縛らずにツールの機能で管理すべし！
- RPA開発を簡単にする機能はどんどん公開すべし！
原則1. RPA開発と一括りにせず、開発レベルを分けて管理すべし！
まず大事なことは開発者レベルを細かく分けることです。
図の例では開発者レベルを5つに分類しています。
- 実行者：RPAの実行やデータの確認など開発者が作成した自動化処理を利用できる
- 開発者レベル1：クラウドシステムを使用した個人タスクの自動化ができる
- 開発者レベル2：クラウドとデスクトップを使用した個人タスクの自動化ができる
- 開発者レベル3：業務の中で担当している一部を自動化できる
- 開発者レベル4：AIを活用して業務全体を自動化できる
なぜ細かく分けるべきなのでしょうか？
これは管理面と開発面でメリットがあるためです。
管理面のメリット1. ツールが幅広い自動化に対応しており、習得が容易
RPA開発は「個人タスクの自動化」から「業務の自動化」まで範囲が広いです。
開発ルールを作る時にRPA開発と一括りにしてしまうと、RPAの良さが無くなってしまいます。
ルールが重すぎると、自動化処理の開発が増えていきません。
例えば、個人タスクを自動化したいだけなのに、RPA開発ルールとして申請が必要となっていた場合、ただGoogleカレンダーから予定を取得したいだけなのに、申請書類を作ったり何を変更したか説明する文書を作成する必要があったり大変です。
これは、タスクレベルの自動化に業務レベルの自動化のルールを適用してしまっています。
これではルールが重すぎず、RPAが使われなくなってしまいます。
反対にルールが軽すぎると、システムの誤入力やメールの誤送信などが発生してしまう可能性が高くなります。
図の例のように開発者レベル毎にルールを設定することが大事です！
開発面のメリット：
開発レベルを分けることは開発面でもメリットがあります。
RPAでできることはAPI連携からGUIを使った自動化、AIとの連携まで様々です。
開発者の目的により、使用するツールも変わるべきです。
例えば、Outlookで自分の1日の予定を取得したいだけの場合、StudioWebで作れます。2024年6月にリリース予定のAutopilot for Developersの機能を使用すれば、対話形式で自動化処理を作ることができます。
Studio/StudioXの場合はインストールやライセンスアクティベーションなど環境構築作業から始まります。対話形式では作れないため、アクティビティを配置していく必要があります。
以前はこれでも十分なほど簡単だと考えられていたのですが、生成AIの出現でより簡単な方法で開発できます。
Autopilot for Developersを用いたStudioWebの開発は便利なのですが、自動化の範囲は限られます。
デスクトップの自動化を行いたい場合は、StudioWebでは自動化することができません。
デスクトップの自動化はStudioXやStudioが選択肢になります。
何をやりたいかによって開発ツールを分けるべきなのです。
クラウドでAPIが用意されているGoogleやOutlook、BoxなどのモダンなツールであればStudioWebで簡単に自動化できます。この自動化だけでいいという方もいると思います。
そのような人はStudioを勉強せずにStudioWebだけを勉強することで、自動化するまでの時間を短縮できます。
エラーハンドリングや安定化処理は業務自動化では大事な要素になってきますが、タスク自動化では不要です。
開発者レベルという概念が無いと、業務自動化に必要な知識まで習得しないといけなくなり、勉強する時間も膨大になってしまいます。
UiPathの強みはタスクの自動化から業務の自動化まで幅広く使えることです。
開発面のメリット２. 開発レベルの向上に伴う上位ツールの習得がスムーズ
タスク自動化できるツールはiPaaS製品として、UiPath以外にもあります。
クラウドシステムの自動化に慣れてくると、作成した自動化処理をデスクトップ操作につなげたいと考えるはずです。
例えば、Boxなどのクラウドシステムを操作する自動化処理を作っていたのですが、Excelで集計したいなどは少なくありません。
他のiPaaS製品の場合は、上位ツールが無いため、別のツールを覚えなければなりません。
UiPathの場合は、アクティビティなどの概念は同じため、スムーズに習得していくことができます。
この開発に幅広く使える点がUiPathを使うポイントかと思います。
また、自動化処理が流用できる点もポイントです。
StudioWebで作成した処理はStudioXやStudioで読み込めますので、今までの知識だけでなく作成した処理も無駄にならないのです。
原則2. タスクの自動化でも最低限の管理はすべし！
原則1.では、RPA開発と言っても、個人タスクの自動化から業務の自動化まで幅広いため、開発レベルを分けて管理した方が開発者も管理者も嬉しいというお話をしました。
では、タスクの自動化に求められる管理ルールとは何でしょうか？
・何を作るか申請すべき？
・変更があった際は変更点を明示して申請すべき？
これらは個人的には不要だと考えています。
タスクの自動化には、ルールが重すぎます。
タスクの自動化であれば、申請は不要でいいかと個人的には思います。
しかし、管理者としては最低限の管理はしておきたいです。
・誰がライセンスを保有しているのか管理する
・セキュリティなどの問題から処理の更新を義務化する
この2点は管理ツールのOrchestratorを利用すると簡単に実現することができます。
誰がライセンスを保有しているのか管理する
簡単なタスクの自動化だけを行う入門開発者としても、管理者は管理しておく必要があります。
管理ツール側からライセンスの管理が可能です。
MyWorkspaceにアップロードされた自動化処理を閲覧することもできますので、開発していなければライセンスを取り上げたり、上位ツールのライセンスを付与したりすることができます。
セキュリティなどの問題から処理の更新を義務化する
RPA開発は自動化対象となるシステムを画面で制御することが多いため、更新に伴い処理変更が必要になってくる場合があります。この時に管理ツールでバージョンアップを行うだけで実行PCでは次回の実行時に指定されたバージョンに更新されますので、各実行端末を管理者が回っていき更新作業をするような面倒な作業は無くなります。
セキュリティリスクのある処理を緊急アップデータしないといけないときも、バージョンアップしてくださいと連絡しても実行者が更新してくれるとは限らないので、この指定バージョンを強制的に使わせる処理は管理に必須です。
これに加えて、共通管理項目の他に、各開発レベルで個別のルールを定めることも重要です。
・開発レベル1：メールの送信禁止（下書きのみ）
・開発レベル2：基幹システムの操作禁止
こうすることで、開発レベルが低い時の誤操作や誤送信のリスクを排除できます。
原則3. ルールやチェックで縛らずにツールの機能で管理すべし！
原則2では、各開発レベルで各開発レベルで個別のルールを定めるべきと説明しました。
しかし、それだとルールを守っているか管理者がチェックしなければいけないのではと疑問に思った方もいらっしゃると思います。
これらをルール化したとしても、そのルールを徹底しない限り、意味はありません。
ルールが守られているかチェックするのは大変であり、性善説に任せてチェックしないと形骸化してしまいます。
ルールではなくツールで管理することは開発者と管理者にとって非常に大事な考え方です。
Automation Cloudに入っているAutomation Opsと開発ツールのワークフローアナライザー機能を利用することで、ルールをツールでチェックすることができます。
次の2つを例としてAutomation Opsとワークフローアナライザーの使い方を紹介します。
・メールの送信禁止（下書きのみ）
・基幹システムの操作禁止
StudioWebにはワークフローアナライザーが無いため、ルールを強制することはできません
メールの送信禁止
では、メールの送信を禁止したいとしましょう。
Automation Opsで各開発者レベルを定義し、低いレベルではメール送信を禁止します。
まずはワークフローアナライザーをパブリッシュ前に実行するように設定します。
禁止アクティビティにメールのアクティビティを設定して、逸脱時にErrorとなるようにします。
こうすることでルール逸脱処理の公開を防ぐことができます。
基幹システムの操作禁止
システムのパスやURLを指定することでアクセスを禁止することができます。
アスタリスクを用いることで、各端末固有の値が入るものをマスクすることができます。
例では電卓処理の操作を禁止しています。
公開時にエラーとなるため、管理者のチェックを介さずに開発者は禁止されていることに気づくことができます。
もしもパブリッシュではなくてもっと前の開発時に知らせたい場合は実行前のワークフローアナライザーの解析を有効にしておくことで実現できます。
他にも色々と強制させることが可能です。
レベルの高い開発者にはルールを強制というだけでなく、エラーにはならないけれどWorningとすることでより良い処理を作らせるという使い方もできます。
原則4. RPA開発を簡単にする機能はどんどん公開すべし！
RPA開発者は通常の業務と並行して開発することも多いため、楽に作成できる機能を求めています。
その1つのIntegration Serviceを紹介します。
現在使用している各人の認証情報を使って簡単にAPIを使ってクラウドシステムを操作することができます。
StudioWebはこの機能を利用して自動化処理を作っているのですが、StudioXやStudioでも使用することができます。
APIがあるシステムであれば、StudioやStudioXで画面操作で制御するよりも安定した処理を作ることができます。
個人の認証情報を使うため、ITのシステム管理者に設定変更を依頼したりしなくてもよいことは管理者にとってもよい機能と言えると思います。
ぜひ有効活用していきましょう。
Automaiton Cloudには開発、管理をするうえで便利な機能がたくさんあります。
隔週でバージョンアップされていくので、StudioWebも含めて最新機能を使えることは非常にうれしいですね。
StudioXやStudioも最新バージョンへのインストールを促すこともできます。
まとめ
今回はRPAの開発者と管理者の両者が喜ぶ運用は無いものかと再度検討してみました。
RPAが広まった2019年頃から比べて、社内で使用するツールもクラウド化が進んでおり、UiPathの開発ツールもStudioWeb、StudioX、Studioと増えました。
AIや生成AIも業務に活用できるレベルにまで進化するなど大きな変化があった中で、RPAの管理ルールは変わらなくていいのか？という疑問を持ち、考えをまとめるために筆をとりました。
オンプレとクラウドの両環境をハイブリッドで使うこともできますので、一部業務やタスクの自動化のみをAutomation Cloudにするなどセキュリティ要件が厳しい企業でも採用することができます。
個人的な見解も多くあると思いますが、現在のRPA開発や管理を見直すきっかけとなれば幸いです。