UiPathの開発標準

UiPathで初めてロボットを開発する際にルールやお作法が分からないということはないでしょうか。

また社内で他の人が開発したロボットを改修、メンテナンスする際に担当者ごとに設定の仕方がバラバラで仕様の理解に時間がかかって困るというとはないでしょうか?

そういった事態を防ぐために必要なのが「開発標準」です。

今回の記事では、UiPathにおける「開発標準」についてご説明させていただきます。

開発標準とその必要性

開発標準を厳守すれば品質が担保される!

そもそも開発標準とは?

IT開発の現場における開発標準とは、開発における細かい基準を定めることです。

定めた基準に沿って開発を行い、定期的に品質評価を行うことで、ロボットの保守性・安全性などの品質を担保することができます。

開発標準と品質評価がなぜ必要なのか?

開発標準を設ける目的は、開発の品質を向上させ、質の良いRPAツールを作成するためです。

具体的には以下のような効果が期待できます。

品質の確保

RPAはビジネスプロセスの自動化に使用されるため、開発されたロボットが正確に動作し、予期したとおりの結果を提供することが重要です。

開発標準に従うことで、ロボットの品質を向上させ、エラーや不具合のリスクを最小限に抑えることができます。

セキュリティの確保

RPAは機密性の高いデータを処理する場合がありますので、セキュリティ上の懸念があります。

開発標準は、セキュリティの最新のベストプラクティスを組み込むことで、データの保護やセキュリティリスクの軽減に役立ちます。

運用の効率化

RPAの運用には、ロボットの管理、監視、保守が含まれます。

開発標準に従うことで、ロボットの一貫した管理や運用を容易にし、全体的な運用効率を向上させることができます。

これらの理由から、RPAの開発標準は、品質、セキュリティ、効率性、相互運用性などの側面を考慮して確立され、適切に遵守されることが重要です。

またルールを定めた後には、そのルールが正しく運用されているか、定期的な品質評価が必要不可欠になります。

定めたルールが正しく運用されている状態がRPAの開発体制として望ましい状態です。

UiPathの提供する開発標準

UiPathはすぐに使える開発標準を提供している

UiPathの提供する開発標準の取得

開発標準をどうやって作ればいいか分からないというお悩みがあるかもしれませんが、UiPathでは開発をスムーズに使用できる「UiPath コーディング規約 と ワークフロー品質評価キット」を公開しています。

以下のページからダウンロードすることができます。

UiPathコーディング規約とワークフロー品質評価キット

提供されているキットの内容

UiPathコーディング規約

UiPathのRPA開発で推奨するルールや知識をまとめたものです。

ダウンロードしてそのまま規約として使用することや、既に独自で作られている開発標準を改良する際に参照することもできます。

UiPathコーディング規約には、規約以外にも開発におけるTipsも含まれているので、学習教材として活用することができます。

ワークフロー品質評価キット

ワークフローの品質を定量・定性的に評価するためのツールです。以下の3点が含まれています。

  1. コードレビューチェックリスト
    コードレビューを実施する際のチェック項目がまとまっているリストです。
    リストの各項目には「Must」「Should」という重要度のフラグがあり、重要度にわけて段階的にレビューをおこなうことも可能です。
  2. ワークフローインスペクタ
    コードレビューチェックリスト内のチェック項目の一部を、自動的にレビューすることができるツールです。
    コードレビューチェックリスト内のどの項目をワークフローインスペクタでレビューすることができるのかは、チェックリスト内の「確認方法」のフラグで確認できます。
  3. 品質評価キット用WI設定ファイル
    ワークフロー品質評価キットに沿ったかたちでワークフローインスペクタを設定するためのファイルです。

資料はUiPathの開発の助けになりますが、そのまま使えば良いということではなく、各社の状況に合わせてカスタマイズすること、また各社で決定した内容を全ての開発メンバーが遵守させる品質評価体制を構築することが重要です。

規約とチェックリストの運用やカスタマイズの例

提供されているドキュメントを活用しよう!

運用例の紹介

UiPathが提供している開発標準の中から、命名規則の部分について具体的な運用例をご紹介します。

命名規則

実際にコーディング規約を基に命名規則を定める方法について具体例を基にご紹介します。

私がお手伝いしているクライアントでは、ロボットで使用するフォルダを以下のような命名規則を定めています。

  1. 部署フォルダ [アルファベット][項番][部署]
    ロボットの動作の関係から部署が識別できる略称を先頭につけるようにしています。
    営業部署であれば、Salesの「S」、項番の「01」を組み合わせて「S01」と命名します。
  2. 業務フォルダ [項番][業務]
    項番と業務名を組み合わせて命名します。
    営業部署の販売リスト作成業務であれば、「01販売リスト」と命名します。
  3. プロジェクトフォルダ [部署フォルダ識別子(英数字)][業務フォルダ項番]_[プロジェクト名]
    部署と業務を判別できるように、部署フォルダ識別子と業務フォルダ項番をプロジェクト名の前につけます。
    営業部署の販売リスト作成業務のプロジェクトであれば、「S0101_リスト作成」と命名します。
  4. 使用ロボット [プロジェクトフォルダ識別子(英数字)]_[処理名]
    プロジェクトフォルダ識別子をつけることで、どの業務の処理かを見分けることができます。
    そして、処理内容が的確かつ、端的に理解できる処理名をプロジェクトフォルダ識別子の後ろにつけます。

フォルダ構成は以下のようになります。

カスタマイズ例の紹介

UiPathが提供している開発標準に説明はないですが、設定しておくとより良いルールがいくつかあります。

今回はロボットの動作やメンテナンスする際に必ず必要となるログの出力を2種類ご紹介したいと思います。

プロセスログ

プロセスログは、ロボットの操作がどこまで進んでいるのかを記載したログを指します。

プロセスログを設定することによって、ロボットでエラーが発生した際にどこまでの操作は正常に進んだのかを把握することができるので、次に紹介するエラーログとセットで確認することで、エラー箇所などをすばやく特定することができます。

プロセスログの設定方法はロボットのフェーズごとに、処理の内容をログに記載をします。

エラーログ

エラーログとは、何が原因でエラーになったか確認するための、プロセスログとは異なるログです。

エラーログを取得できることで、エラー内容が簡潔にわかり原因調査が容易になります。

出力する内容は「発生時刻、対象ロボット、エラー内容」としています。

例外処理の中に組み込み、エラー発生時にログを出力するようにしています。

実行ログとエラーログを比較するとエラー内容のわかりやすさが違うことが実感できます。

最後に

開発標準を定め、規約を厳守して開発することで効率良く、品質の良いロボットを開発することができます。

今回はUiPathの開発標準を一例としてご紹介しましたが、弊社では「Automation 360」や「BizRobo!」など様々なRPAツールでも同様に開発標準を定めて開発をしています。

Automation 360の開発標準

BizRobo!の開発標準

効率的に品質の良いロボットを開発するノウハウを皆さんに提供できると思いますので、気になる方はお気軽に弊社にご相談ください。

本記事の執筆者

ペネトレイター株式会社 小竹