Automation 360の開発標準

RPAツールを使っての自動化業務を遂行するにあたって、日ごろから様々な問題に直面するかと思いますが、例えば以下のような様々な問題に悩まされてはいませんでしょうか。

• 新規メンバーの参入による教育実習や前任者からの引継ぎ作業
• バージョンアップによって再発してしまった不具合対応
• 環境差異によって頻発する類似の不具合

など…。

今回の記事では、様々な問題において、開発メンバー間での成果物品質のバラつきを抑えると共に、技術的リスクを回避し得る「開発標準」というものについて、Automation Anywhere社の自動化ツール「Automation 360」の事例を挙げながらご紹介させていただきます。

開発標準についての基礎知識

開発標準とは？

開発標準とは、一言でいうとロボットの品質を維持したり、開発者ごとでルールを統一したりするための開発時の決まりごとです。

各人毎に異なったルールに基づいたロボット作成をすると、第三者がロボットの仕様を確認する時間が大きく増えてしまいます。
開発標準をガイドラインやノウハウとして全員に周知・活用していくことで、組織単位での効率を高めることが可能です。

なぜ開発標準を決めるのか？

ひと言でいうと、開発標準を決める主な理由は、「属人化」を回避するためと「品質を保持」するためです。
具体的に、開発標準を定めることで得られる4つのメリットと開発標準を使わない場合の2つのデメリットをご紹介したいと思います。

開発標準を定めるメリット

特定の指標を提示することにより、開発を進める人物が複数人でも同じ視点をもって開発に携わることができます。

開発標準を定めないことによるデメリット

1. 属人化
   特定のメンバーしか情報を握っていないため、その特定のメンバーしか業務を進められず、異動や退職といったことが発生した際にプロジェクトが止まってしまう問題を抱えている状態で、ブラックボックス化を招きます。
2. 不要なタスクの消化
   既にあるものと同じようなものを一から作ってしまうことによって、時間と労力を無駄にしてしまいます。

開発標準を策定する際に押さえるポイント

「可読性」を意識する

可読性が低いと、第三者にロボットの仕様が正しく伝わらず、ブラックボックス化の危険性があります。
ロボットを運用していく上で改修が必要になった際に、多くの時間を掛けず、不要な箇所の改修をしないようにするためにも、作成者だけが把握しているような個別のルールでの開発を行わず、適切に整理されたフォーマットを組織単位で運用することが重要です。

「安定性」を意識する

ロボットが安定しているということは、ロボットの品質が担保されているということになります。
公式で推奨されている安定性の高い動作を優先的に使用することや、各業務部門や業務プロセスごとにフォルダを分けるなど、その場その場でのルールも存在しますが、ここで大事なのは「安定性の高いロボットを作成するにあたっての考え方やルールを共有する」ということです。
開発標準を策定することは開発メンバー間の「品質保持」「安定性の確保」の認識の統一を促進し、結果的にロボットの安定した運用に帰結します。

「メンテナンス性」を意識する

メンテナンス性が高い状態というのは、役割ごとにロボットが分かれていたり、ロボットの動作に対して適切な整理が為されており、誰が見てもどこで何をしているかの可読性が高いというところにもかかってきます。
また、BATファイルやVBScriptなどの専門知識が必要とされる設定も極力避けて作られていることで、特定のメンバーのみが業務を進められる「属人化」の状態を作らない土台があるということでもあります。

Automation 360における開発標準の事例

Automation Anywhere では「Bot 設計のガイドラインおよび標準」について、旧バージョンのV11はマニュアルに記載されていたものの、Automation 360では日本語化されたドキュメントはないようです（本記事を作成した時点）。
そこで今回はV11で使用されていた開発標準を基に、弊社がAutomation 360で使用している開発標準の一部を事例としてご紹介させていただきます。

ステップ・コメントの設定

ステップやコメントといったアクションは、ロボットの仕様の可読性を向上させるアクションです。
どこで何の処理を行っているかが分かりづらいと、作業が処理の特定からになってしまう＝本来想定していないタスクを抱えてしまうことになるので、都度ステップやコメントを入れることが重要です。

ステップ・コメントの入れ方

　ステップ：設計書の業務フロー図に準拠した粒度で、入力値を統一して入れる。

設計書を見て、フロー図に記載されている文言を検索すれば、目当ての処理の場所にすぐ辿り着くことが出来るでしょう。

コメント：ステップで説明しきれない、詳細内容を記載する。
　　　　　HowだけでなくWhy, Whatを記載する。
　　　　　また、Howについても何故そのアプローチを選んだかを記載する。

コメントで適切な説明が為されていれば、開発者のみならず、第三者がロボットを確認した際に、どこで何を行っているか、より理解し易くなります。

例外処理

例外処理とは、エラーが発生した際に行う処理のことです。

エラーの発生によるファイルやウィンドウの未終了などで後続のデータ処理に影響を及ぼさないため、開いているウィンドウを強制的に閉じたりする動作や、エラー箇所を特定するための情報を出力する処理などが行われます。

エラーハンドラー

　キャプチャ取得：「スクリーン」パッケージの「デスクトップのキャプチャ」アクションを使用することで、エラー発生時の画面を取得し、状況理解に役立てることが出来る。
　　　　　　　　　画像ファイル名は重複を避けるため「Bot名・日付・時刻」というような情報を含めて保存する。

エラーログ取得：「ファイルに記録」パッケージを使用し、ログファイルを1日毎に分割するため、ファイル名に日付を入れて保存する。

メール送信（正常終了・異常終了）：「Eメール」パッケージを使用し、ロボットが正常に終了したのか、異常終了してしまったのか、通知で把握出来るようにする。

ログ

ログ出力には目標と、それを達成するためのいくつかのルールを設けております。
まず目標として「読み手の目線で出力する」ということですが、目標達成には下記の要素を満たすことが求められます。

1. 使用目的を意識し「分かりやすい」ログにする
2. 監査やパフォーマンス調査のためにツールやデータベースへログをインポートしやすいよう、ログはCSVとする
3. サブBotで外部のAPIやWebサービスを呼び出す場合、パラメータの値を出力する

そしてログにはいくつかの種類があり、使用目的も「監査」「履歴の管理」「トラブルシューティング」など様々です。
ここでは、エラーが発生した際にエラーの早期解決に役立てることが出来、かつロボット内にアクションとして組み込むだけで利用できる「プロセスログ」「エラーログ」の2つをご紹介します。

出力ルール

プロセスログ：何らかの処理を行う箇所の頭尾に入れることで、ロボットがどの処理を開始して、終了したのか、ロボットの実行状態を確認するために記録するログ。
　　　　　　　処理ごとで出力する（実行日時・Bot名・実施内容）

エラーログ：ロボットがどこで、何が原因でエラーになったかを確認するためのログ。
　　　　　　エラーハンドラーの中で値を取得し出力するため、エラーが発生したときのみ記録するようになっている（実行日時・Bot名・何行目・エラーメッセージ）。

また、下記の各種ログに利用する主なシステム変数は、エラー発生時に活用することで問題解決に役立てることが出来ます。

他にも、ロボットを作成するにあたって事前・事後に行う処理や、構造のテンプレートをまとめた「フレームワーク」についてはこちらをご参照ください。

＜フレームワークを利用したロボット開発＞

命名規則

命名規則とは、Botや変数が何を行っているのか、何を表しているのかを一見して分かるようにするものです。
これは複数人での開発や、ロボットを作成した人物とは別の人物が修正作業にあたる際に「分かりやすさ」という点で大きく効果を発揮します。

基本ルール

1. 一見してBotや変数の目的・中身が伝わる。
2. 決まったルールに沿って整った形になる。
3. 「保守性」「可読性」を意識する。

具体的なルール

1. 短く、簡単な名前にする。
2. アンダースコア(_)やスペースは極力使用しない。
3. ボットにはパスカルケース（PascalCase）を使用する。
4. 変数にはキャメルケース（camelCase）を使用する。

変数の命名規則

• プレフィックスを使用する。

※プレフィックスとは接頭語のことで、データの種類を一見して判別できるようにするためのものです。

Botの命名規則

1. Botのファイル名には頭に管理番号を付与。
   ※管理番号はBot管理簿のドキュメント内で管理する
2. 管理番号の番号体系を事前に策定する。
   例：XXYYYYZZZZBB_処理名
   -部門２桁（XX、共通なら00）
   -業務（YYYY）
   -連番（ZZZZ）
   -タスク/サブタスク識別子（BB、B0はメインタスク/B1～9はサブタスク）
   -処理名

今回ご紹介させていただいたのは、Automation 360での自動化業務を遂行する際の開発標準の策定に関するポイントや弊社で実際に使用している事例となります。
RPAツールによって開発標準は異なりますが、今回はAutomation 360を一例としてご紹介させていただきました。ほかにも弊社ではUiPathとBizRobo!を取り扱っており、それぞれの開発標準を以下のコンテンツでご紹介しておりますので、良かったらご参考ください。
＜UiPath＞＜BizRobo!＞

弊社ではRPAツールを利用しての様々な自動化業務に携わっております。RPAツールによる自動化に関する課題の解決方法や、RPAツールを導入後の運用体制の構築など、お悩み事がありましたらお手伝いさせていただきますので、お気軽にお問い合わせください。