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