RPAをはじめるあなたが知っておいてほしいこと

「RPAをやってみたい」「RPAに興味がある」「仕事で触れることになりそう」といった方のためのアドバイスになれば、と思い、連連と書いてみます。
あくまで個人的な意見ですし、それぞれの組織のガイドラインに沿っていただくのが優先度としては高いですが、参考にしていただければ幸いです。

## 業務選定・要件定義

### さいしょはカンタンな仕事から自動化する

RPAを導入するにあたり、最初に自動化する業務は出来る限りカンタンな仕事が良いです。カンタンな仕事、と一口にいってもさまざまな切り口があるかと思いますが、私としては次の条件に当てはまる仕事が良いかと思います。

- もし自動化できなかったとしても大きなリスクがない（作業できる人員がいる）
- すでに定型化され複数名が同じ業務を担当することが出来る
- 手作業であっても、30分〜1時間で終えることが出来る
- 業務のなかに分岐（判断を要するタイミング）がない、もしくは少ない

上記に当てはまらないような仕事というのは、意外と自動化する上でクセがあったり、あるいはプロセスが肥大化する傾向があるように思います。そのようなプロセスは、RPA導入における各ステップで工数を要し、また大変に苦労することが多いです。そうすると、仮に上手くローンチ出来たとしても<u>同じようなRPAジャーニーを歩もうというモチベーションが生まれず</u>、**導入がリピートされません**（＝拡大していきません）。

### インプットとアウトプットにこだわり、既存の手順を鵜呑みにしない

RPAは<u>人間の手順をワークフローに落とし込むことが出来る点</u>が、親しみやすいポイントです。しかし、だからといって**既存の手順を踏襲しなければならないわけではありません**。
RPAに限らず、新しいシステムやツールを入れるときには、それによって何かしらのシンプル化を実装できるケースが多いです。例えば、下記の手順で実装されていた業務が存在したとします。

> あるファイル（`dummy1.xlsx`）をダブルクリックして開き、ファイル > 名前を付けて保存 の順にクリックする。ダイアログで、新しいファイル名（`dummy2.xlsx`）を指定して「保存」をクリックする。その後、開いているアプリケーション（Excel）を閉じる。

ほとんどのRPAツールであれば、上記の操作を差分なく実装することは可能です。しかし少し考えると、この手順は結局のところ<u>ファイルをコピーしているだけ</u>であって、同様の作業は、RPAツールによっては**「ファイルをコピーする」というパーツを実装する**ことで出来てしまいます。

このように、ある手順または手順のまとまりを目の前にしたときに、それを<u>そのまま実装するのではなく</u>、その手順等のインプット（＝手順を実施する前の状態）とアウトプット（＝手順を実施した後の状態）を意識し、**より効率よく実装できる方法がないか意識する**ことが望ましいと思います。例えばドキュメントなどのアウトプットもシンプルになりますし、あるいは開発に必要な工数の削減にも繋がります。

## 開発・テスト

### 「パーツの組み合わせにすること」を意識する

少し言い方を変えると、「パーツとして作ること」と「繋げやすく作る」のふたつに分割できるかと思います。

#### 「パーツとして作ること」を意識する

一般的なITシステムの開発においては、基本的に**再利用できること**を意識して開発することが効果的です。例えばあるシステムへのログインを行う業務が複数存在したときに、業務を自動化する都度、個別に開発してしまうと、その分の工数が発生します。それが、<u>予め再利用しやすいワークフローを作成</u>し、それを<u>他業務の開発時にも流用できるようにしておく</u>ことで、**その分の工数を削減することが出来ます**。
またパーツとして作る上では、その**パーツの大きさも重要**です。適切な大きさを定義するのは容易ではありませんが、私が開発で意識していることは、下記に該当する箇所でワークフローを分割することです。

- 「画面などUIを操作する手順」と「データを操作する手順」の境目
- アウトプットを作るために必要な中間データを出力する手順の直後

#### 「繋げやすく作る」を意識する

パーツとして作ったとしても、それが他のパーツと連携しにくいものであったら活用されなくなってしまいます。活用されるためには、**繋げやすい**（＝連携しやすい）**パーツ**にすることが重要です。

- パーツ間で、受け渡し用のデータの名称（変数名・引数名）や種類（データ型）を統一する
- そのパーツが、どのような手順を含んでいるのかを理解しやすいよう整える（名称やドキュメントなど）

### テストのための環境・データを用意しておく

RPA においては既存の業務が存在する中で自動化を行うケースが多いため、その<u>業務に支障が出ないよう十分に配慮する必要があります</u>。そのため、データを追加・編集・削除する作業を自動化する際には、**テストの環境やデータは必須**と言っても過言ではありません。またデータを参照するだけの作業であっても、その参照先となるシステムやデータは出来る限りテスト用に容易すべきです。
またデータについては、少なくともユーザーが最終チェックをするときのために、次のふたつの観点を意識して用意しておくと良いと思います。意識されていないデータのみでテストすると、<u>手戻りが発生するケースが多い</u>です。

- 本番で利用するものと同等のボリューム
- 実装する手順のパターンをすべて網羅しているデータ

またテスト環境を用意しているチームには、予め「RPAで自動化を実装する」旨を伝えておくと良いです。

### エラー・例外を「ありがたく」読む

前提として、開発して作成されたワークフローが、初回からエラー・例外を生じることなく動作することは極めてレアです（往々にしてそういうものです）。
その上で、エラーや例外のメッセージが表示された場合には、まずどういう内容であるかをじっくりと確認しましょう。ほとんどのエラーは、その<u>発生理由をメッセージに含めています</u>。このメッセージを読むことで**おおよその問題を解決することが出来ます**ので、まずは抵抗感を持つ前に読んで見る、というのを意識づけしてみてください。

また読んだだけでは解決できないケースも存在します。そのときは、ぜひ**インターネットに頼りましょう**。そのときも、エラーメッセージからキーワードを抜き出して検索することをおすすめします。
検索するときのみならずフォーラムなど質問を投稿する場においても、エラーメッセージは重要です。投稿時には、ぜひ**エラーメッセージをつけていただけるとありがたい**です（答える身としても）。

### ログは適切なレベルをつけて十分に出力する

上記とも関連しますが、エラーがなぜ起こるかを特定するためには<u>さまざまな情報が必要</u>です。その情報は（私としては）多いほうが良いと思っています。そのため、ログするアクションは**ワークフロー内にこまめに実装**しましょう。
その際に、**ログレベルも合わせて検討**してください。ログレベルとは、そのログの意味や重要度を決定する要素です。[さまざまなWebサイトで言及されています](https://www.google.com/search?q=%E3%83%AD%E3%82%B0%E3%83%AC%E3%83%99%E3%83%AB)ので参考にしていただければと思います。

どのような情報をログすべきかは様々な意見があると思いますが、「処理対象となるレコードの情報」「手順がどの位置まで進んでいるかの情報」などを入れるようにしています。また条件分岐の前に、その判断基準となる値を出力することもあります。

------

（ここから先はまだ書いている途中です。。。）

------

## 運用・保守

### できるかぎり見守りをする



### 止まったときのルールを決めておく



### 管理のしやすさにこだわる



## マインド

### すこしずつでも形にしていく



### 気になったことはすぐに実装・テストしてみる



###