この記事を読んだ方の中で、BizRobo!を導入したけど、どこから着手すればいいかわからないという方はいらっしゃいませんか？
どのツールに対しても、導入後にまず開発標準を定めることが大切です。
この記事では開発標準とはそもそも何なのか、どんな要素が含まれていればいいのか、弊社で定めているBizRobo!の開発標準を例にご紹介いたします。
目次
開発標準とは
開発標準があることのメリットとは？
開発標準とは何か？
開発標準の内容を説明する前に、そもそも開発標準とはいったい何なのかに触れておきたいと思います。
開発標準とは、その名の通り開発工程を標準化したものであり、開発をする際に必要不可欠な要素を取り入れています。 その要素に基づいて定められた取扱説明書、ルールのようなものです。
なぜ必要なのか？
開発標準が存在することで多くのメリットがあります。
品質が保証される
開発標準を守ってロボットを開発することで、ステップの詳細の記載がなく可読性が低くなる恐れや、エラー処理の精度が低くエラー原因の特定に時間がかかってしまうなど、標準未満のロボットが出来上がることを防ぐことができます。
開発における品質を誰が開発しても保証することが開発標準に求められます。
属人化のリスクを防げる
各々が自由に開発すると管理統制が効かなくなり、開発した本人しか内容がわからなくなってしまう場合があります。
また、その本人が異動や退社などなんらかの事情で管理者不在となった場合、野良ロボットが発生し、属人化してしまう可能性が高まります。 開発標準があることで、誰でも内容が理解しやすいような命名規則や開発ルールで管理されたロボットになるので、属人化するリスクを未然に防ぎ、運用管理がスムーズになります。
開発が楽になり、メンテナンス性が向上する
開発標準が存在することで、ロボット開発時にいきなり0から開発を始めるということがなくなります。 標準通りに設計をしていき、その通りに設定を作成していくことで、どんなロボットでも、誰が開発者でも、同じ方向性で開発に着手することができます。
これにより、開発標準を理解していれば、ロボットの読み込みも早くなり、開発やメンテナンスにおける手間を最低限に抑えることができます。
ここまでで開発標準とは何なのか、メリットはどんなものがあるかについてご紹介させていただきました。
上記により、ロボットを開発・運用していく上で開発標準はとても大事なものになってきます。
次のフェーズでは上記のメリットを踏まえて、実際に開発標準を設定する際のポイントについてご説明いたします。
開発標準に必要な要素の例
ここで紹介する要素は開発標準で抑えるべきポイント
コーディングガイドライン（命名規則やコメントのつけ方）
ロボットの内容を見た際に、どこで何が行われているか、ロボットの名前はもちろん、ロボットの動作（BizRobo!ではステップ）や変数の名前など、ロボットを形成する要素の命名規則の存在有無で、そのロボットに関わる方々の作業効率が大きく変わります。
ロボットの役割の明確化
ロボットを作成する際に1つのロボットにいくつもの処理を詰め込むと、どこで何を処理しているのかわかりにくくなり、可読性が低下やエラー発生時に影響範囲が拡大し、保守・メンテナンスコストが増大します。
上記のようなデメリットを避けるために、ロボットの役割を明確にする、単一役割の原則を開発標準に定めることをおすすめします。
特に様々なプロセスで行う動作については、ロボットを共通部品化することで開発の工数削減やメンテナンスコストの低下を見込むことができます。
例えば、ログイン用、ログアウト用のロボットを共通部品として作成し、親の制御ロボットでログイン用子ロボット、ログアウト用子ロボットを呼び出す親子構造のロボットにします。
こうすることで、どのロボットで何をしているかが明確になり、エラーの際にはそのエラー原因となった動作を行っているロボットを確認すればいいので、改修作業も容易になります。
親子ロボットの詳しい内容に関してはこちらをご参照ください。
エラーハンドラー、ログ
エラーハンドラー、ログ取得は明確に標準化することで、運用保守面で効率が良くなります。
なぜなら、そもそも実際にロボットを動かしたときに、100%成功するということはほぼ間違いなくありえないといえます。
その際に、エラーが発生し、そのエラーに対してどのように対応するかを考える必要があります。
しかし、そもそもエラーがどこで起きたのか、何が原因なのかがわからないと対応を考えることすらできません。
なので、ログの取得とエラーハンドラーの開発標準化は必須といえます。
ログの取得する際にどこに格納され、どのような要素をロギングするかを明確にすることで、エラーが起きた際にログの記録を見て原因の特定がしやすくなります。
また、エラー後に、キャプチャを取得し、ログと合わせてメールで報告するようにすることで、エラー対応のスピードを上げることにつながります。
ここまでで、開発標準とは何かがある程度つかめてきたと思います。
では実際に、必要な要素を踏まえたうえで、BizRobo!ではどのような開発標準を定めたらいいのか、弊社の開発標準を見ながら必要な部分を考えていきましょう。
BizRobo!開発標準
BizRobo!に合わせた開発標準をご紹介
開発標準は自社にあった標準を定めることが重要ですが、RPAには多くのツールがあります。
それぞれのツールに関してもそれぞれに適した標準を定めることはとても重要です。
ここではBizRobo!開発標準について、弊社ではどのように定めているか、一部をご紹介します。
ステップ・グループの設定
BizRobo!では、ステップを組み合わせて、開発を進めていきます。
そのステップの組み合わせをグループ化して、ひとまとめにすることで、ロボットの中身がコンパクトになり、ロボットの可読性が向上します。 ステップ、グループはそれぞれ名前を編集することができ、その名前の基準である命名規則を設けることにより可読性をさらに向上させます。
ステップ
ステップ名にはそのステップで行う動作の詳細の内容を記載します。
具体的には○○をクリック、A1セルに△△を書き込む等、その場で何をどうしているか、ステップの動作を明確にすることで前後のステップを見なくてもある程度ここで何を行っているか理解できます。
グループ
設計書のフロー毎に合わせてグループ名を作成します。
こうすることで、開発の際には設計書を軸に、その通りのロボットを開発することができます。
運用する際には、設計書を見てからロボットを見ると、どこで何をしているか理解することができます。
例外処理
上記のエラーハンドラー、ログで述べたように、ロボットは100%正常に動くとは限らないので、エラーに対してどのように対応するか、いわゆる例外処理を考え実装します。
この例外処理の対応が明確になっていない場合、エラーへの対処が遅れてしまい、ロボットが本来の仕事を行えなくなる可能性があり、そうなると本末転倒です。
そのためにもエラーの原因を速やかに特定し、対処することが不可欠です。
エラー原因の特定に役立つ開発標準を紹介します。
キャプチャ取得
エラーが起きた際、どこでどんな事象が起きたかを把握することはとても大切です。
そのためには発生した事象を画像として残しておくことで、誰が見ても視覚的にわかりやすく、エビデンスとしても優秀です。
では実際にどのようにキャプチャを取得すればいいのか。
ステップでエラー処理を設定することができ、エラー処理の次のステップをトライステップに設定することで実現できます。 下記に簡単な方法を乗せたので参考にしていただけると幸いです。
＜BizRobo!キャプチャ取得方法＞
- トライステップを設定し、エラー処理でDAを呼び出す
- DAで「画像を次に抽出」ステップで、画像ファイルを変数化
- DSに戻って「Write File」ステップを使用しファイルを保存
エラーログ取得
エラーログはエラー時に詳細なエラーメッセージを記載し出力します。
実行したロボットがエラーになった場合にエラーログに、「実行日時・ロボット名・ステップ名・エラーメッセージ」を書き込むことで、いつ、どこで、どんなエラー内容かを確認することができるので速やかにエラー原因を特定し、原因への対応に移ることができます。
メール送信
エラーがあった際に、メールで通知することはもちろん、正常終了した際もメールで通知するようにします。
こうすることで、ちゃんとロボットが動いているかを定期的に確認ができます。
また、エラーの際はエラーログと同じレベルの内容をメールで通知し、キャプチャしたエラー画像を添付することにより、発生ベースでエビデンスを残すことができ、原因の特定をより早く行うことができます。
メールアドレスなどの入力項目は、ロボット内に直接入力することを避け、変数で指定することで、担当者が変わっても対応することができ、開発標準として機能します。
ログ
プロセスログ・エラーログの2つを作成し、それぞれに出力ルールを設けます。
エラーログは上記に記載した粒度で作成し、エラー特定の確実性を向上させます。
プロセスログはグループごとで出力し、ここで何が行われているかを記載します。
内容としては、「実行日時・ロボット名・実施内容」を記載し、グループの開始、終了ベースで1行ずつ記載していきます。
こうすることで、詳細なパフォーマンス分析に使用することができ、エラーの際にもどこまで動いていたか把握しやすくなります。
命名規則
ロボット名
管理番号の番号体系を、事前に策定します。
これにより、ロボットを簡単に識別ができるようになるので、管理するのが簡単になり、ロボット名をログに記載することで、どのロボットがどの処理でうまくいってないかを把握しやすくなります。
＜ロボット名命名規則例＞
例: XXYYYYZZZZBB_処理名
-部門2桁(XX、共通なら00)
-業務(YYYY)
-連番(ZZZZ)
-タスク/サブタスク識別子(BB、B0はメインタスク/B1～9はサブタスク) -処理名
変数の命名規則
変数はプレフィックスで変数の種類がわかるようにします。
これにより、変数がどんなタイプで、何を示しているかを見ただけでわかるようになります。
開発標準を作成し、対象のロボットに関わる全ての人が開発標準を把握していれば、誰が見てもわかりやすく、各開発者に依存しないロボットになります。 また、問題が起きたときにどこで何が起きたかを把握しやすくなり、ロボット開発者が楽になるだけでなく、管理する側、運用する側にとってもメリットがあります。
この開発標準はあくまで現段階のものであり、RPAの発展、環境の変化によってはこのままずっとこれを使用していくのは難しくなる可能性があります。そのため、その時々で状況に合わせて変更する必要があります。
自社に合った開発標準を策定し、その時々でブラッシュアップしていくことで、ロボット開発、運用において、より洗練された良質なものを提供できるようになります。
今回はBizRobo!の開発標準を一例としてご紹介しましたが、弊社ではAutomation 360やUiPathなど様々なRPAツールでも同様に開発標準を定めて開発をしています。
BizRobo!やAutomation 360、UiPathなどのツールを使用し、これらの開発標準を用いて、様々な業務をRPA自動化する支援をさせていただいております。
自動化できるかわからないけど自動化できたらいいなと感じる業務や、条件や手順を整理しきれなくて自動化を諦めている業務などございましたら、一度ご相談ください。
内容をヒアリングしたうえで、自動化の可能性をご提案させていただきます。
ペネトレイター株式会社 井上