私、元々は某自動車会社にて、RPAエンジニアとして働いていたので、大企業での導入も経験しています。
大企業でのRPA導入は、システマチックに行うのですが、とにかく書類作成が多かったですね。
では、中小企業においても、そこまで必要あるのか？というと、個人的にはそこまで必要ないと思っています。
大企業では、１つの作業に対して多くの部署が絡んでおり、そのうえ人の異動も激しいので、責任の所在をハッキリさせておかなくてはいけないということもあるのでしょう。
しかし、中小企業においては、そこまで縦割り構造になっているところは少ないと思うので、効率を重視していけば良いと思うのです。
そのため、今回の記事は大企業ではなく、中小企業においてのRPA導入方法について、話していきます。
STEP-1 ■RPA導入初期段階
なによりもまず、
『RPAで自動化するに値する作業があるのか？』
という確認が大事です。
ルーティンワークとして、PC上で行っている繰り返し作業が皆無という会社は稀だと思いますが、それなりの量があるのかどうか？ということになると、業務の棚卸しをする必要があると思います。
手作業で行っても１０分くらいで、週に１回くらいしか行わないものを、RPAで自動化する必要性は低いでしょう。
逆に、月に１回であっても、複数人で丸一日掛かっているような作業や、半期に一度残業を数日して処理しているような作業があれば、これもRPA自動化の対象になりえるでしょう。
あと、請求書の作成など、人が行っているからこそ起こるミスを撲滅したい時にも、RPA導入の余地はあります。
こうして出てきた、「自動化されるといいなぁ」と思える作業を紙に書き出しましょう。
自動化したい作業を紙に書き出すと、なんとなく現実感が出てくると思います。
その一方で、見たことも無いRPAというツールで、どこまで自動化できるのか？という不安も出てくると思います。
現段階では、出来る・出来ないの明確な区別は気にしなくても構いません。
単純に
『RPAでは、ゼロから１を作り出すような作業はできない。
しかし、マウスとキーボードの簡単な操作による繰り返しであれば、ほぼできる』
と考えて頂いて大丈夫です。
実際の作業においては、そのままでは自動化できなくても、業務の方にひと手間入れて頂いて（元帳に1列追加するなど）、RPAで対応可能になることは多いのです。
STEP-2 ■RPA導入の方針決定
「自動化されるとかなり便利だ！」と判断されたら、次のステップです。
それは、RPAツールを社内に入れたあと、誰がそのRPAツールを使って自動化する（ロボットを作成する）のか？ということです。
選択肢は２つです。
・自分達でロボットの作成と運用を行う
・外注する（作成と運用を任せる）
ここを決定する必要があります。
「まず、自分達で試してみて、それから決めても良いですか？」という意見もあると思います。
はい、大丈夫です！
大体のRPAツールには試用期間があるので、それを試して自分達で何とかなりそうかどうか判断することが出来ます。
STEP-3 ■RPAツールの選択
外注する場合には、RPAツールに掛かる費用もひっくるめて考えれば良いと思います。
専門のエンジニアが責任を持ってロボットを作成・運用するのですから、そのRPAツールの操作方法が難しい・簡単は考える必要がありません。
「えっ、作成だけ外注して、運用は自分達でやりたいんですけど？」とお考えの方もいらっしゃるかもしれませんが、それはやめておいた方が良いでしょう。
ここでいう「運用」というのは、通常利用時にロボットが止まり、修繕が必要というケースを指しています。
正常に動く場合には、「スタートボタン」を押すだけなので、問題ありません。
しかし、RPAは作るロボットによって、利用環境が多少変わるだけでも、すぐ止まるようになっています。
そうすると、原因の個所を編集する必要があるのですが、RPAツールを使えない人だと、個所の特定から修繕方法まで分からないはずです。
なので、「作成は外注、運用は自社」というのは、あまり現実的ではないのです。
問題は、「自分達でRPAツールを使い、ロボットを内製化したい！」という場合です。
当然ですが、これは吟味が必要です。
RPAツールの価格はもちろん、使い勝手やサポート体制も大事です。
日本において、有名なRPAツールはどれも高額なので、費用対効果もしっかりと計算する必要があります。
RPAツールは、基本ライセンス制になっており、買ったら終わり！ではなく、毎年その金額が掛かってくるので注意しましょう。
また、価格が数千円/月額のRPAツールも見かけると思いますが、大半がクラウド型のRPAツールになると思います。
その際には、最低何ライセンスから導入可能なのか？とか、自動化したい業務に適合しているのか？といったことが問題になりますので、ご注意ください。
ココで１つ、内製化にあたっての解決策があります。
それは、自社でRPAツールを使える人を育てるという選択肢です。
安価で必要十分な機能を持ったRPAツールを導入し、自社スタッフがロボットの作成・運用を行うことが出来るようにする！というのが、言うまでもなくRPA導入の理想形です。
しかし、現実には
・巷で手軽に受けられる「RPAハンズオンセミナー」は、WinActor(NTT製）といった有名で高額なRPAツールしか対応していない
・そのハンズオンセミナーも、集団レッスンでノンプログラマーがゼロから習得するのに向いていない
という問題があります。
この問題をクリアする方法としては、
・安価で使いやすいRPAツールの個人レッスンを行ってくれる所を見つける
・社内にいるプログラマー経験のある人に、RPAツールを習得して貰う
が挙げられると思います。
ただ、いずれにせよ、通常業務の片手間に…というのは、極めて難しいです。
ましてや、困った時に聞ける人が周りにいない状況で、RPAを習得するというのは、とてもハードルが高いと言えるでしょう。
少なくとも、数か月単位でRPA習得・ロボット作成をメインとして、業務を割り当てるべきだと思います。
STEP-4 ■RPAツール決定後
実際に、RPAツールを社内に入れることが決定しました。
さあ、どうしましょうか？
この部分は、「外注」でも「内製化」でも同じになりますが、
『何から自動化しますか？』
ということになります。
リストアップした作業のうち、どれから手を付けていくのか？ということです。
やはり最初は、小さくスタートが基本です。
何事も最初はトラブルがつきものですから、作ったロボットが上手く動作しなかった場合でも、被害が少ない部分から切り替えていきましょう。
特にRPAが初めての場合、「RPAとはどういったものか？」ということが感覚的に掴めていないでしょうから、少しお試し的に導入することで、なんとなくにしろ、RPAの適用範囲も分かってきます。
そうすると、単純に手作業を自動化するだけでなく、「こういったこともできませんか？」と業務の改善案も出やすくなるという副次的なメリットもあります。
実際に私が担当した案件の中でも、「へぇー、RPAでそこまで出来るとは思っていなかった。出来るのであれば、ぜひそれもお願いしたい！」という話に発展したことも少なくなかったですね。
ちなみに大企業の場合、RPA導入はプロジェクトとして扱われることが大半です。
ですので、プロジェクトリーダーと言える責任者を立て、費用対効果を厳密に計測していきます。
分かりやすく言えば、
（現在）
スタッフ１人（時給1600円） × １時間 × ２０営業日 ×12か月
（自動化後）
RPAに掛かる経費
を比べてペイすると思える作業を自動化していきます。
厳密には、作った後のメンテナンスやドキュメント作成の手間もあるので、多少計算結果通りという訳にはいきませんが。
STEP-5 ■RPAでロボット作成後
RPAを説明する時に、Excelのマクロと比較されることがよくあります。
RPAは、Excelマクロほど高速に処理できませんが、アプリケーションをまたいで自動化できるという強みがあります。
一方で、Excelマクロの場合、あまりメンテナンスを意識することは無いと思います。
しかし、RPAの場合、汎用性の高さゆえに、作成時の環境と変わった場合や想定外の事象が発生した場合、エラーで止まります。
そうした場合、その部分を特定し、修正してやる必要が出てきます。
RPAツールにてロボットを作成する場合、小さな部分テストを繰り返しながら、完成形に近づけます。
そして、最初から最後までロボットを走らせてみて問題なければ、ダミーにてユーザー（そのアプリケーションをいつも使っているスタッフのこと）にテストして貰います。
そのダミー情報の中には、普段ではありえないような数字や文字を入れてみたりと、いわゆる「意地悪テスト」というようなことを行って貰います。
一応、ロボット作成時にも思いつく範囲で意地悪テストを行うのですが、やはり現場で実際に使っている人しか分からないような事象もありますから、最後の判断はユーザーにお願いせざるをえないのです。
また、ロボット作成者から見た場合、普通に走っているように見えても、ユーザー側から見ると、挙動がおかしいというケースもありますので、ここのテストは時間も掛かりますし、責任面からも重要なのです。
異常時の対応を「例外処理」と呼びます。
この例外処理を随時RPAのフローに入れていくことで、すべての事象を把握し、デタラメな処理がされないようにしていきます。
そのため、結果として純粋なロボット作成時間よりも、テスト＆修正に掛かる時間の方が長くなってしまうのも普通なのです。
STEP-6 ■RPAでロボット作成完了後
STEP-5において、一通りテストが完了し、ユーザーにロボットが「納品」として引き渡されました。
これで終わりか？といえば、まだ仕事が残っています。
それは、ドキュメント化（書類化）です。
簡単に内容を言えば、
『何の処理を、いつ、だれが、自動化したのか？
ロボット利用時の責任者は誰で、トラブル時にはどのように対応するのか？』
といったことをまとめておくのですね。
なぜなら、ロボット作成や、その時の利用者がずっとそこにいる訳ではありません。
企業も変化しますから、退職もあれば異動もある訳です。
その際に、業務がブラックボックス化してしまうということはとても多く、よく問題化されていますね。
RPAに関していえば、
①野良ロボットと呼ばれる、その存在と役目を会社自体が把握していないものがある
②そのロボットがトラブった場合、手作業でのやり方が分かる人がいない
というのが、ありがちなのです。
①の問題がある場合、会社の基幹業務などのシステム更改を行う際に、要件漏れを引き起こしたりとトラブルの種になります。
また、好き勝手にロボットが作れるというのは、セキュリティポリシーの観点からも問題がありますよね。
②の問題がある場合、会社の一連の業務すべてが止まる可能性があります。
大変危険なので、誰でも救急時の対応として手作業でも行えるようにマニュアル化し、その情報を共有しておく必要があります。
たとえマニュアルを作っていても、どこにあるのか誰も知らなかったという状況もあるあるです（苦笑）
以上、実践的なRPA導入の流れを書いてみました。
今、ちょうど社内にRPAを採用するかどうか検討中だった！という方にとっては、改めて課題点・問題点が出てきたと思います。
社内にシステム会社出身といった人がいらっしゃれば、その方をプロジェクトリーダーにして、ノウハウを蓄積していくのが好ましいと思います。
もし、そういったことに明るいスタッフがおらず、システム構築の知識ゼロからスタートでは、止まりやすいロボットになってしまったり、社内運用のルール構築がちゃんと出来ずに、担当者の手間ばかり掛かるということになりがちです。
ビジネスの世界でよく「走りながら考える」という言い方がされることがありますが、RPA導入に関しては、最初の方針を誤ると使われずに放置されたり、現場に混乱だけ巻き起こすことになりますので、事前の準備は十分に行うことをお勧め致します。