【RPA】シナリオ作成時に考えるべきこと ～ Why RPA People !!

#おことわり
UiPathのタグをつけていますが製品に関することには触れません。
質問されてもチョットデキル程度なのでご期待に添えるかわかりません。

# はじめに

VBAやC#などの自動化の延長で分からないながらも
UiPathのシナリオを作成するときに考えるべきことをまとめてみました。

# RPAに出会ったキッカケ
日頃から自動化ソリューションに携わっていた私は
ここ最近の成果で月間８０時間の業務効率化を実現していたこともあり

クライアントから「UiPathでRPAやってみない」と
まるで「今日飲みに行かない？」感覚でお誘いを受け
業務自動化や効率化の傍らでRPAのシナリオ作成を始めました。

# レッツトライ、そのまえに

UiPathとは何ぞやというところからのスタートでしたが
よくわからないソフトウェアやハードウェアを扱うことが多い人生を
歩んでいたこともあり

こういうハツモノやフメイな奴を相手にするときに重要なスタンスを
無意識にとっていました。

言葉で表すのであれば

**分からないながらも走りながら考える**

ということ

# 自動化において大事なこと
いくつかの業務自動化案件を実行に移してきて
シナリオ作成や自動化ツール云々の前に大事なことがあると私は考えています。

## そこにヒトがいるかどうか

自動化は主に２つに分類できます。

・無人の自動化を **Unattended**
・有人の自動化を **attended** 

と分類できます。

詳しく書くと一つの記事になってしまうので割愛しますが
要するに、自動化をキックする存在が機械か人間なのかということです。

タスクスケジューリングを設定して機械に定期的に動かしてもらうのか
それとも、人が動かすのか。

この点のユースケースを明確にしておかないと
どんなにすごいシナリオを作成しても**意味がありません**

**Unattended**のシナリオをヒトが実行する
ということが無いようにしっかり
**シナリオのユースケースを意識しましょう。**

## 何を目的とした自動化であるか(そもそも必要な自動化であるか)

自動化対象の業務のほとんどが
この質問ひとつでなくなることもある。
このようなことが起きる主な理由として

**業務従事者含め業務の目的が分からない**

ということ。
誰に必要とされている業務かわからないけど
研修時代に教わった仕事なので
継続してやってますというパターンがとても多い。

この点のミスマッチがあると
**意味のない無駄な自動化シナリオの積み上げ** をしてしまうということ

たくさんのRPAシナリオ作成や自動化ツールの作成を
やってきたと豪語される方には
こういう**真の自動化**について勉強されたほうが良いかと思います。

そうするとあなたはどうなのかという質問があるかと思いますが

**私は無駄だと判断できる仕事については
その理由を明確に述べたうえでお断りしています**

わざわざ無駄なことに時間を割くことはないですし
もっと重要なことに時間を使うべきだと考えています。


## ターンアラウンドタイムがどれくらいの自動化であるか

これはアプリケーションを作成する人も意識するところになりますが
キックしてから終わるまでのターンアラウンドタイムがどれくらいかというところ

このターンアラウンドタイムが長いと
**Unattended**の場合は他の自動化の妨げになる。
**attended**の場合はユーザが終了まで長いこと待つことになる。

これはツール開発、シナリオ作成におけるデメリットもあり
検証時の結合テストに時間がかかってしまうという業を背負ってしまう。

こういうときのベストプラクティスとして
**自動化する業務を最小限の工程に分離して独立させる**

例えば、作業工程の多い業務Xがあったとすると
それを頭から順に自動化するのではなく

業務XA,業務XB,業務XC という形に分離して自動化する。
そして、それらを順に実行するという形をとる。

プログラミングで表現すると

```
Sub Auto(工程番号 As Integer)

  Select Case 工程番号
  Case 1 :
    Call 業務XA()
  Case 2 :
    Call 業務XB()
  Case 3 :
    Call 業務XC()
  End Select

End Sub

Sub main()

    Call Auto(1)
    Call Auto(2)
    Call Auto(3)

End Sub

```

## 結合度

自動化対象の業務には
既に**秘伝のタレを使った味玉**のようなマクロやツールが存在する場合がある。
こういう場合はその**秘伝のタレを使った味玉**と連携をとることを
考えなければならない。

マクロと同じ内容を一から作り直すという発想もあるかとは思いますが
マクロで実行している内容を
一から組みなおすことは**業務従事者含め業務の内容が分からない**ということもあり
とてもリスキーなので連携をすることを先に考える。

このときに大事なことは
シナリオの中に**秘伝のタレを使った味玉**を混ぜないこと。

例えば、RPAのシナリオ作成においては
シナリオ内に奇妙なマクロやスクリプトを挟まないことが挙げられる

ここでそういった**秘伝のタレを使った味玉**入りラーメンを作ってしまうと
ラーメンそのものの味を確認することが困難になってしまう。

また、食べ方よっては
**秘伝のタレを使った味玉**を最後に食べたいという人もいるだろう。

なのでラーメンと**秘伝のタレを使った味玉**は皿を分けておくことがとても大事なのです。

ラーメンをシナリオ,**秘伝のタレを使った味玉**を奇妙なマクロやスクリプトと
置き換えるとお分かりいただけるだろう。

## 自動化対象のシステムが必ずそこにあるか

既に**ユーザ（ヒト）が扱うことを想定したWebシステム**を
導入している会社がほとんどだと思います。
案件の中には自社開発もしくはベンダー依頼のシステムを自動化することもあります。

このときに大事なことは
**RPAのシナリオを実際に扱うときそのシステムが必ず稼働しているかということ**

例えば、システムメンテナンス時のことを考慮せずに
RPAのシナリオを作成してしまうとエラーを吐いた状態で停止したり

接続できないことに気づかずにシナリオが何回もシステムに対して接続を試みて
メンテナンスページを繰り返し開いてしまうといったことが起きる。

そもそも、立ち止まって考えて欲しい話ですが
**ユーザ（ヒト）が扱うことを想定したWebシステム**は
ヒトが扱うことを想定しています。（当たり前かよw）

つまり、システムが使える時間かどうかと
そのシステムを使うかどうかはユーザの判断に委ねられている為
シナリオにもそういう旨の内容を定義すべきなのです。

**シナリオの実行環境が整っているかどうかという観点は絶対に忘れてはなりません**

# まとめ

長々と書きましたが、いかがだったでしょうか。

それではまとめです。

**・分からないながらも走りながら考える**
**・シナリオのユースケースを意識する**
**・意味のない無駄な自動化シナリオの積み上げをしない**
**・自動化する業務を最小限の工程に分離して独立させる**
**・シナリオの中に「秘伝のタレを使った味玉」を混ぜない**
**・シナリオの実行環境が整っているかどうかという観点を意識すること**

最後にひとつ大事なことを書いて終わります。

**RPAもマクロも万能ではありません。夢は見ず、現実を見ましょう。**
**シナリオがうまく作動しないこともちゃんと考慮してマニュアルを作成しておきましょう。**


# おわり