「RPAをやってみたい」「RPAに興味がある」「仕事で触れることになりそう」といった方のためのアドバイスになれば、と思い、連連と書いてみます。
あくまで個人的な意見ですし、それぞれの組織のガイドラインに沿っていただくのが優先度としては高いですが、参考にしていただければ幸いです。
業務選定・要件定義
さいしょはカンタンな仕事から自動化する
RPAを導入するにあたり、最初に自動化する業務は出来る限りカンタンな仕事が良いです。カンタンな仕事、と一口にいってもさまざまな切り口があるかと思いますが、私としては次の条件に当てはまる仕事が良いかと思います。
- もし自動化できなかったとしても大きなリスクがない（作業できる人員がいる）
- すでに定型化され複数名が同じ業務を担当することが出来る
- 手作業であっても、30分〜1時間で終えることが出来る
- 業務のなかに分岐（判断を要するタイミング）がない、もしくは少ない
上記に当てはまらないような仕事というのは、意外と自動化する上でクセがあったり、あるいはプロセスが肥大化する傾向があるように思います。そのようなプロセスは、RPA導入における各ステップで工数を要し、また大変に苦労することが多いです。そうすると、仮に上手くローンチ出来たとしても同じようなRPAジャーニーを歩もうというモチベーションが生まれず、導入がリピートされません（＝拡大していきません）。
インプットとアウトプットにこだわり、既存の手順を鵜呑みにしない
RPAは人間の手順をワークフローに落とし込むことが出来る点が、親しみやすいポイントです。しかし、だからといって既存の手順を踏襲しなければならないわけではありません。
RPAに限らず、新しいシステムやツールを入れるときには、それによって何かしらのシンプル化を実装できるケースが多いです。例えば、下記の手順で実装されていた業務が存在したとします。
あるファイル（
dummy1.xlsx）をダブルクリックして開き、ファイル > 名前を付けて保存 の順にクリックする。ダイアログで、新しいファイル名（dummy2.xlsx）を指定して「保存」をクリックする。その後、開いているアプリケーション（Excel）を閉じる。
ほとんどのRPAツールであれば、上記の操作を差分なく実装することは可能です。しかし少し考えると、この手順は結局のところファイルをコピーしているだけであって、同様の作業は、RPAツールによっては「ファイルをコピーする」というパーツを実装することで出来てしまいます。
このように、ある手順または手順のまとまりを目の前にしたときに、それをそのまま実装するのではなく、その手順等のインプット（＝手順を実施する前の状態）とアウトプット（＝手順を実施した後の状態）を意識し、より効率よく実装できる方法がないか意識することが望ましいと思います。例えばドキュメントなどのアウトプットもシンプルになりますし、あるいは開発に必要な工数の削減にも繋がります。
開発・テスト
「パーツの組み合わせにすること」を意識する
少し言い方を変えると、「パーツとして作ること」と「繋げやすく作る」のふたつに分割できるかと思います。
「パーツとして作ること」を意識する
一般的なITシステムの開発においては、基本的に再利用できることを意識して開発することが効果的です。例えばあるシステムへのログインを行う業務が複数存在したときに、業務を自動化する都度、個別に開発してしまうと、その分の工数が発生します。それが、予め再利用しやすいワークフローを作成し、それを他業務の開発時にも流用できるようにしておくことで、その分の工数を削減することが出来ます。
またパーツとして作る上では、そのパーツの大きさも重要です。適切な大きさを定義するのは容易ではありませんが、私が開発で意識していることは、下記に該当する箇所でワークフローを分割することです。
- 「画面などUIを操作する手順」と「データを操作する手順」の境目
- アウトプットを作るために必要な中間データを出力する手順の直後
「繋げやすく作る」を意識する
パーツとして作ったとしても、それが他のパーツと連携しにくいものであったら活用されなくなってしまいます。活用されるためには、繋げやすい（＝連携しやすい）パーツにすることが重要です。
- パーツ間で、受け渡し用のデータの名称（変数名・引数名）や種類（データ型）を統一する
- そのパーツが、どのような手順を含んでいるのかを理解しやすいよう整える（名称やドキュメントなど）
テストのための環境・データを用意しておく
RPA においては既存の業務が存在する中で自動化を行うケースが多いため、その業務に支障が出ないよう十分に配慮する必要があります。そのため、データを追加・編集・削除する作業を自動化する際には、テストの環境やデータは必須と言っても過言ではありません。またデータを参照するだけの作業であっても、その参照先となるシステムやデータは出来る限りテスト用に容易すべきです。
またデータについては、少なくともユーザーが最終チェックをするときのために、次のふたつの観点を意識して用意しておくと良いと思います。意識されていないデータのみでテストすると、手戻りが発生するケースが多いです。
- 本番で利用するものと同等のボリューム
- 実装する手順のパターンをすべて網羅しているデータ
またテスト環境を用意しているチームには、予め「RPAで自動化を実装する」旨を伝えておくと良いです。
エラー・例外を「ありがたく」読む
前提として、開発して作成されたワークフローが、初回からエラー・例外を生じることなく動作することは極めてレアです（往々にしてそういうものです）。
その上で、エラーや例外のメッセージが表示された場合には、まずどういう内容であるかをじっくりと確認しましょう。ほとんどのエラーは、その発生理由をメッセージに含めています。このメッセージを読むことでおおよその問題を解決することが出来ますので、まずは抵抗感を持つ前に読んで見る、というのを意識づけしてみてください。
また読んだだけでは解決できないケースも存在します。そのときは、ぜひインターネットに頼りましょう。そのときも、エラーメッセージからキーワードを抜き出して検索することをおすすめします。
検索するときのみならずフォーラムなど質問を投稿する場においても、エラーメッセージは重要です。投稿時には、ぜひエラーメッセージをつけていただけるとありがたいです（答える身としても）。
ログは適切なレベルをつけて十分に出力する
上記とも関連しますが、エラーがなぜ起こるかを特定するためにはさまざまな情報が必要です。その情報は（私としては）多いほうが良いと思っています。そのため、ログするアクションはワークフロー内にこまめに実装しましょう。
その際に、ログレベルも合わせて検討してください。ログレベルとは、そのログの意味や重要度を決定する要素です。さまざまなWebサイトで言及されていますので参考にしていただければと思います。
どのような情報をログすべきかは様々な意見があると思いますが、「処理対象となるレコードの情報」「手順がどの位置まで進んでいるかの情報」などを入れるようにしています。また条件分岐の前に、その判断基準となる値を出力することもあります。
（ここから先はまだ書いている途中です。。。）