いくつかロボットを開発してきた中でやりやすかったお仕事を参考にし、
どうしたらプロジェクト終盤にユーザーも開発者もヒーヒー言わなくて済むのかを考え、まとめてみました。
（今後また良い事例があれば、都度追加していこうと思っております。）
あくまで開発者側の私が感じたことですので、絶対ではありません。
たまたまその案件ではその方法が正解だったというだけです。
普段開発をされている方、関係したお仕事をされている方からすると当たり前のことばかりかもしれませんが、
そうではない方も勿論いらっしゃいます。
今回はそういった方向けに書いたつもりです。
こういうやり方や考え方もあるんだ～ふーん程度で聞いてくださいませ
数日でできる小さな自動化ロボットもありますが、今回はどちらかというとそれよりも大きめのプロジェクトを想定して書いていきます。
依頼者（ユーザー）の認識
開発者ではない方の、RPA開発に対する認識についてのお話しです。
RPAハベンリ、スゴイ、スグデキル
RPA、ロボット、ロボットなら何でも勝手に判断して処理してくれる、万能！万歳！最高！
ヒューマンエラーが無くなり、時間短縮にもなる。その結果他の時間の使い方ができ生産性向上
確かにおっしゃるとおりです。
人がやると何時間もかかる作業を数十分に短縮！というのは実際に私も案件で経験しております。
完成したロボットを実際に使い、幸せな結果で終わった案件を知っています。
しかし、これに行きつくまでの過程は一朝一夕では出来ません。
ユーザーと開発者同士の協力プレー無くして成功しません。
（※決してRPA開発大変だからやめとけという記事ではありません※）
RPAロボットを作るのは人間
「ロボットだからすぐに出来る」、「ロボットだから始めから完璧な物が出来る」というイメージが強すぎる方がいらっしゃいます。
それでも開発をするのは人間です。
それもユーザーの手順も業界用語も何も知らない人間です。
物作りに関しては、ロボットだからとかはあまり関係ありません。
RPAを知ろう
ネットでの調査や勉強会等へ赴くといった手段で、RPAがどのようなものか、過去どのようなプロジェクトがあったのか、体験談といった物を把握すると良いです。
（UiPath社のサイトにもありました。）
少しの知識があるだけで、それはプロジェクトで大きな差となります。
またその知識をチーム内で共有すると尚良いと思います。
開発者からするとユーザーの方がRPA開発に少しでも理解があることは、とても救いになります。
自分たちで作ることもできる
勿論プロジェクトの大きさにもよりますが、自分たちで開発することもできます。
誰でもできるが本来のRPAの良さです。
自信のない方でも、WinActorなら作りやすいのではないかと思います。
UiPathは無料版が存在するので、実際に触れることができます。
人にも向き不向きがあるので、自動化する内容とを踏まえてツールを選ぶと良いと思います。
RPA開発の手順
ざっくりRPA開発の流れを書いていきます。
① どんな機能を自動化したいかをまとめ、厳選する
② 手順をまとめ、整理・改革をする
③ 作成した手順をRPA開発向きにする
④ 開発者に手順を説明する
⑤ 開発を開始する（認識のすり合わせ、仕様変更、機能追加）
⑥ テストを行う（修正、機能追加）
⑦ 引き継ぎを行う
ご覧の通り、他のシステム開発と似ています。
上の手順を細かく書いていきます。
（手順やら分岐の多い、開発が数日では終わらなさそうな案件を想定しています）
① どんな機能を自動化したいかをまとめ、厳選する
おそらく、あれこれ出てくると思います。
多くの機能を実装したくとも、初めから全てを導入するのはお勧めしません。
あっぷあっぷになり溺れてしまいます。
（今後導入したい内容も開発者に伝えると良いでしょう。
情報があれば、それを視野に入れた作り方もできるかもしれません。（必ずではない））
② 手順をまとめ、整理・改革をする
出てきた案を整理します。
そしてもっと手順が簡単になるなら、そもそもの従来の手順を改変します。
例）従来：①Webサイトから取得した情報をExcel_1.xlsxに転記
②Excel_1.xlsxからExcel_2.xlsxに必要事項のみ転記
③Excel_2.xlsxから必要事項を取得し、内容をメールで送信
改革後：不要なデータを削除し、マクロを用いてExcelの転記回数を減らす
=>別々に分けていた資料を一つのExcelにまとめ、管理するようスタイルを変更
もしこれが案件化されずとも、この作業は決して無駄ではありません。
RPA用に改造しているうちに手順が洗礼化され、開発項目には入らなかったものの、単純に人の作業が楽になったという話もあります。
無理に自動化する必要はありませんし、人間の判断がどうしても必要なものもあります。
柔軟に考えることが大切です。
③ 作成した手順をRPA開発向きにする
例えば分岐のルールの確立です。
恐らく多くの分岐ルールが存在すると思います。
人が無意識で行っていることを、ロボットに条件として指示するので、細かいところまでルールをしっかり決めることが大切です。
取得・保存ファイルの名前やパスといった事も、決められるなら決めておいた方が良いです。
またイレギュラー想定も必要です。
例えば取得すべきExcelがなかった場合、どういった対応をロボットにさせるのか。
そのままロボットを終わらせるのか、Excelがない旨を伝えるメールを送るのか。
細かいところも考えておくと良いでしょう。
④ 開発者に手順を説明する
ここで感じるのが、「当たり前を説明するのは難しい」です。
普段あまりにも何気なく行っている工程なため、ユーザー同士では見落としていた内容が出てきます。
何も知らない開発者に説明しているうちに、新しく追加ルール等が発覚するといったことは良くあることです。
早急に確認し、仕様書に追加しましょう。
「まぁこれくらいならわざわざ言わなくても大丈夫っしょ。見りゃわかるべ」
これ、すごく危険です。
認識の差異が生じ、誤った認識のまま開発が進むと大変です。
分かり切ってる事も、（序盤は特に）一つ一つ確認した方が安全だと思います。
一番良いのは、実際にその工程を見せることです。
手順のイメージ付けが大切です。
また資料に残すのも良いです。
「戻る」ボタンにしても、使用するサイト内に設置されている「戻る」ボタンなのか、IEに備わっている「戻る」ボタンなのかといった区別も必要になる時があります。
そんな時確実に伝えられるのは、画面キャプチャーを撮り、クリックするボタンなどに赤枠等の印をつけ、説明を近くに記載する方法です。
手間はかかりますが、操作関連の把握ミスを減らせます。
例↓
⑤ 開発を開始する（認識のすり合わせ、仕様変更、機能追加）
開発を開始しても、新しい問題は出てきます。
例えば、調査をしてみると、○○ツールのボタンのObjectが取れなかった（ロボットが認識できなかった）。
独自ツールの懸念点
独自のサイト、ツール、アクセス方法がリモートといったように、条件によっては開発がしづらいものもあります。
これは実際に使用するRPAツールで調査をしないとわかりません。
Excelのフォーマットでもありえます。
例えば、表の項目名。
ロボットが間違った認識をしてしまう記号があり、正確に取得できない時があります。（以前あったのは"#"や"."）
この場合項目名を修正したり、ロボット用の項目名の行を追加するといった方法があります。
他にも仕様に関する新しいパターンがみつかり、開発者から質問がきます。
これに対するユーザーのレスポンスは速ければ速いほど良いです。
⑥ テストを行う（修正、機能追加）
開発者側でも軽いテストは行っているかもしれませんが、
実際にその作業を行っているユーザー側のテストも必要です。
普段触れている者だからこそ気付くものがあるはずです。
それは修正個所だけではなく、使い勝手を良くするための追加機能もそうです。
（追加機能依頼が受理されるかはまた別の話）
この間に余裕があれば、開発者はロボットに関する手順書やロボットのコメントを追加しましょう。
⑦ 引き継ぎを行う
プロジェクト終了後、ユーザー自身が保守対応を行う案件が多い印象があります。
これに備え、開発者はロボット内のコメントだけでなく、何かしらの資料を残す必要があります。（=>「開発者向け」＞「作成しておくと良い資料」参照）
時間に余裕があるならば、簡単な追加機能だったりをユーザー自身が開発者と一緒に実装するのもよいでしょう。
実際に触れることで、RPAツールも作成したロボットも触れることが出来ます。
手順・仕様書を書いてみよう
「じゃあユーザーさん、開発者用に手順書を作っておいてくださいｂ」
と言っても、ロボット開発をしたことのない方からすれば
「え、どんな情報があるといいの？」
「このエクセルから取得して、あのWebサイトに貼り付けるっていう説明だけじゃだめなの？」
「粒度は？書き方は？？どんなのが好ましいのぉお!!??
（お手上げ侍）」
となってしまいます。
私は（時間があるならば）一つ一つの処理を書き出すのが好ましいと思います。
以前ユーザー様とともに作成した手順書エクセルは、以下のようなものでした。
| ロボット名 | 手順 | 必要な情報 | 共通ロボット名 |
|---|---|---|---|
| ○○操作 | ①Webサイトを開く | Login.xaml | |
| ②ID/PWを入力 | Login.xaml | ||
| ③「ログイン」ボタンを押下 | Login.xaml | ||
| ④以下の処理をExcelに記載されている分ループを行う | |||
| ・「新規登録」ボタンを押下 | |||
| ・結果.xlsxから以下の項目を取得し、入力する。 | ExcelGetDataTable.xaml | ||
| 「社員番号」←「社員No」 | 健康診断.xlsxの「結果一覧」シート | ||
| 「身長」←「身長」 | 健康診断.xlsxの「結果一覧」シート | ||
| 「体重」←「体重」 | 健康診断.xlsxの「結果一覧」シート | ||
| ・「登録」ボタンを押下 | |||
| ・「成果」画面を撮影、保存する。 | ImageSave.xaml | ||
| 保存先：C:\Users\temp*** | |||
| ・「戻る」ボタンを押下 | |||
| ⑤「ログアウト」ボタンを押下 |
確実に伝えることが難しい場合は、例を取り上げると良いです。
例えば、何かのファイルを保存する際、付ける名前に日付を入れるとします。
「"テスト資料 "+日付+".pdf"」だけでは、日付が0入りの8桁の表示なのか、記号を挟むのかといったあやふやな点がでてきます。
そんな時、「例）テスト資料 20180101.pdf」と書けば、確実に相手に伝えることが出来ます。
開発
開発環境
PCはおそろいで
開発、実行用PCは全く同じ種類のPCをお勧めします。
解像度等が違うと、不具合のもとになるからです。
開発用ツール・ロボット用アカウント
手順で使用する、Webサイトや独自ツールはテスト用の環境があると良いです。
本番での開発は制限がかかり、開発だけでなくテストもしづらいです。
可能ならばログイン時に使用するアカウント、OutlookといったメールのアカウントはRPAロボ用として新規作成すると良いです。
多重ログインの防止だったり、何か異常があった場合に調査しやすいです。
直ぐに話せる環境
手順、仕様を把握されている方と開発者がすぐに会話できる環境があると、とても良いです。
何事もすぐに解消し、その場で修正できた方が良いからです。
開発者向け
パフォーマンス
私はいつも、動いていることが直ぐに分かる機能（ログイン、ログアウト、画面遷移等）の流れが出来上がり次第、お客様にお見せするようにしております。
それまで仕様をまとめたり、開発者への仕様の説明、開発者とのパイプの役割といった事を長らく行っているユーザーに、ロボットが動いているところをお見せすると必ず喜んでくださるからです。
初めてロボットが動くところ見たお客様からは
「思っていたよりも速い！」「動いてる！」「自分たちの作業が形になっている！」
といった感想をいただけます。
これはお客様だけでなく、ユーザーが喜ぶ姿を見た開発者側のやる気向上にも繋がります。
今後を見通した開発を
案件によりますが、プロジェクト終了後ユーザー自信がロボットの保守をされることがあります。
その為、できるだけエラー調査がしやすく、またわかりやすいロボットにする必要があります。
一機能の名前の付け方
UiPathでいうActivity、WinActorでいうノードの名前の付け方についてです。
一覧表示などでパッと見てわかる内容に加え、最後にActivity名を付けておくと良いです。
例）「Excelの取得：Read Range」
「○○サイトを開く：Open Browser」等
コメントを残せるツールの場合は、できるだけ残すようにしましょう。
私は別ロボを呼び出すActivityでは、ロボの処理内容に加えて引数の説明を入れるようにしました。
ログの残し方
ログは多くの内容が出力されます。
画面名は"【】"で囲み、その中での処理は"＞"を先頭に書くといったように、
目が滑らぬよう工夫をしなければなりません。
例）UiPathの場合
09:54:44.4127 Trace {"【ログイン】画面~~~~
09:54:44.4127 Trace {"＞IDの入力~~~~
09:54:44.4127 Trace {"＞PWの入力~~~~
09:54:44.4127 Trace {"＞「ログイン」ボタン押下~~~~
09:54:44.4127 Trace {"【メイン】画面~~~~
作成しておくと良い資料
無難にあると良いと思う資料を上げていきます。
仕様書
情報を最新の状態で保ちましょう。
これはユーザーとともに都度更新していくと良いです。
更新の際は更新した日付も書くと良いでしょう。
確認表
仕様の質問から、テストで発生したエラー、直接口頭でお伺いして解決したことでもなんでも残しておくと良いです。
ロボット設計書
ワークフローで十分だと思います。
このワークフローを見て、ユーザーはロボットの作りを把握します。
同じ共通ロボの場合は色枠でくくり、ロボ名を記載しておくといった工夫をすると見やすいかもしれません。
例↓
ワークフローの横には、どの図形が何を示しているのか（分岐、ループ等）、
また各機能の簡単な説明も添えておくと良いです。
ロボット手順書
ロボットを実行するにおいて、必要と思われるユーザー向けの情報を詰め込みます。
UiPathであればUiPath Robotでの実行の仕方、使用するエクセルの決まりごと、開発環境、その他ユーザーに認識しておいてほしいものを記載しておきます。
シナリオテスト
開発者側でやるテスト項目。
ロボットなので、Webやスマホのように書く内容とはニュアンスが何となく違う気がしてきますが、基本的に同じようなもので問題ないと思います。
項目例：条件（分岐）内容・画面・どういったアクションがあって、その結果どうなるのか
ロボットのフォルダー構成書
どこにメインロボットやサブロボット、共通ロボットがあるか、またそれぞれのロボットの説明を記したものです。
図はパッと見てわかればいいと思います。
例）
○○ロボット
┣Main.xaml
┃
┣△△処理
┃ ┣△△_Main.xaml
┃ ┗画面遷移.xaml
┗共通処理
┣Login.xaml
┣Logout.xaml
┣GetExcel.xaml
┗ImageSave.xaml
他にも入出力やらといった、あると嬉しい資料はありますが省きます。
RPA開発って本当に必要？
これだけユーザー側のお仕事があるなら、無理して自動化する必要ない？
と思われてしまったかもしれませんが、そんなことはありません。
先述したように、数時間の作業を数十分で終わるようになった事例もあります。
大変な時期は確かにありますが、それを超えればしっかりと結果はついてくると思います。
まとめ
①コミュニケーションをしっかり取る
②仕様は可能な限りロボットに寄せる
どんなお仕事も人間同士のやり取りがあります。
ロボット開発においてもそれは同様で、むしろコミュニケーションがないと成功する確率がグングン下がると思っており、
ユーザーと開発者との協力プレイで成り立ちます。
お勧めサイト
こんなゆるい内容じゃなく、もっと詳しく開発の手順・進め方を知りたい！
という方は、以下のサイトをお勧めします。
私の伝えたかった内容以上の話が、ぎっしりと詰まっておりました。
【必見】大規模RPAプロジェクトの進め方