AUTORO導入後のFAQ

適切なアクション数という固定的な数値はございません。

運用のしやすさや、他の担当者にもメンテナンスしてもらいやすい観点からは、概ね50程度が適当です。
しかし、重要なのはアクション数そのものよりも、ワークフローの目的や、実際の処理の内容を明確にドキュメント化しておくことです。
ドキュメント化する際のポイントは、下のアコーディオンメニューをご参照ください。

ドキュメントについては、以下を盛り込んでおくとよいかと思います。

1. 成果物の明確化

• どんな業務成果物を目指すのか。
• その成果物を誰がどのように使用するのか。

2. 運用の考慮点

• 入力条件（サイトでの検索条件など）が将来的に変わる可能性はあるか。

3. 例外処理の確認

• どのような場面でRPAの処理が停止する可能性があるか。
• 停止した際の対処方法は何か。

アクション数が嵩んでくるとワークフローが開けなくなることもあります。
どうしてもアクション数が多くなってしまう場合は、カスタムアクションのご利用をご検討ください。
アクション数を無理に制限してワークフローを分割して実行していくより、処理の見通しがわかりやすくなる可能性があります。

ワークフロー自体を分割したほうがわかりやすい場合もあります。ワークフローを続けて実行していきたい場合は「AddToQueue」というアクションで、ワークフローから別のワークフローを実行できます。

上の項目でご案内したカスタムアクションについて、以下では技術的なフォローとして、カスタムアクション化の基準のご参考にタスクユニットという考え方をご紹介します。

タスクユニットは、「自分の担当領域以外の知識を持つ必要がないように分割された業務フロー上の各部門」になります。 例えば商品開発における以下のような部門分けを指します。

カスタムアクションを通じてこのような分割を行うと、ワークフローの保守において以下のメリットがあります。

• 一つのユニットで問題が発生（サイトの仕様変更等）しても、そのユニットの成果物のフォーマットを崩さなければ次のユニットの影響が小さくなります
• ワークフロー設定画面を見た時に、今何をやっているかが分かりやすくなります
• エラーが起きた時、原因が追いやすくなります

構築中に以下に気をつけると効果的です。

1. 変数名を分かりやすくする

以下のような変数名を避けて、多少長くても分かりやすい名前をつけるようにします。

• “aaa” : 何を指しているか分からない
• “data” : データであることは分かるが、具体的にどういうデータか分からない
• “cList” : “customerList”の意味でつけているが、”c”が何の略か分からない
• “replacedText” : 具体的にどう値が変わったか分からない。”spaceRemovedText”など、処理の内容をつける
• “row[29]” : 何度も登場する場合、配列の29番目を毎回確認するのが手間なので、変数名を別でつける

2. メモ欄を活用する

メモ欄に以下のような情報を明記しておくようにします。

• Click等…ページのどこを操作しているか、具体的に書いておく
• StoreValue…この後どこで使う予定か書いておく

また、Textアクションをメモ代わりに設置しておくのも有効です。

3. カスタムアクション化する

アコーディオンメニューの「どうしてもアクション数が多くなってしまう場合は？」の項目をご参照ください。

エラーが発生しないようにRPAを作成する際のポイントは以下の通りです。

1. 小さなステップで作成してテスト

RPAを一気に作るのではなく、少しずつアクションを追加し、都度テストを行うことで、問題点を早期に発見しやすくなります。

2. 待機時間の利用

ブラウザやアプリの反応時間の遅延を考慮し、画面が切り替わるきっかけになるアクションの後に一定の待機時間を設定することでエラーを回避します。
アクションに実行前/後待機の設定欄がない場合は、Waitアクションをご使用ください。

3. 条件分岐の網羅

事前に様々な状況や条件を考慮し、それに応じてワークフローを分岐させることで、エラーを未然に防ぐことができます。

4. 開発を行った人以外のテスト

見落とされているバグや問題点を第三者が指摘することができます。
また、エラーの検知にはTryアクションを使用します。こちらによって予期せぬエラーが発生した際に、適切に通知・対応できるようにしておくことができます。
ただし、エラーは完全には避けられないものであるという考え方をしておく必要があります。 見落としが無いように注意して作ったワークフローも、サイトの変化や取りうるパラメータの変動など、新たな要因によってエラーが発生することが考えられます。
エラーが起きた際にその原因や影響範囲が分かりやすいように設計し、必要に応じてすぐに保守対応ができる体制を整えることが重要です。