人間、やる気がなくなるというのは、どういう瞬間に起こりえるのでしょうか？
ある人曰く、『期待値に対して、それを大きく下回った時』なんだとか。
逆に言えば、期待値を正しく持っておけば、挫折しずらくなると言えるでしょう。
また、その瞬間が突然ではなく、事前に心の準備が出来るものであれば、これもまた挫折しずらくなるでしょう。
突然殴られると、大した力でなくても倒れてしまいますが、殴られる準備が出来ていれば痛くても倒れずに済むかもしれません。
ですので、今回の記事は、「RPAをやっているとあるある」をテーマに語ってみたいと思います。
RPAをやっていると、よくあること
RPAメーカーが提供している学習サイトや動画などが、とても分かりづらい！
私が最初に挑戦したのは、UiPathでした。
日本法人もあり、多くの動画もアップされており、他のRPAメーカーよりも進んでいると聞いて、挑戦したのです。
その結果・・・
学習カリキュラムを２周も終わらせましたが、よく分からないままでしたね（苦笑）
当時、英語サイトに字幕を付けた形で提供されていましたが、「本当に、多くの人はこれをみてマスター出来ているのか！？」と不思議に思ったものでした。
その後、VBAのエキスパート資格を取得し、WinActorのRPAエンジニアとして働き出した後、改めて見直しましたが、ようやく理解できる内容でした。
つまり、分かっている人が見ると理解できるが、分からない人が見ると重要なところがチンプンカンプンなものでした。
自分達で作っているのか、それとも外部の会社に任せているのか分かりませんが、もうちょっとノンプログラマー目線で作れるでしょ！？と思わされます。
といいながら、UiPathはまだ良い方です。
日本No.1シェアを誇る「WinActor」なんか、そんな学習サイトすら提供していませんから！（苦笑）
売る気が無いのか、法人向けのみに絞っているから必要ないと思っているのか、わかりません。
ひょっとしたら、代理店に教育ツールの販売を促す為に、敢えてやっていないのかもしれませんね。
アプリとRPAツールの処理が上手く一致しない
これは、かなり初期の段階で感じることになるでしょう。
RPAツールが入っているPCにインストールされているアプリを自動化する場合には、さほど問題にならないのですが、ネットワーク、特にインターネットを介してのサービスとなると、途端に問題が出てきます。
つまり、RPAツールの処理が先走り、アプリの処理が追い付かないという状況です。
各RPAツールごとに、複数の「待機」ツールがあるので、それを駆使してタイミングを取る調整を行うことになります。
また、通常は、１，２秒の待機を設定すれば、問題なくロボは進むようになるものですが、数百人、数千人のユーザーが使うような社内ネットワークなどでは、調子の良い日と悪い日（一度に多くのスタッフがアクセスする日）の差がとても大きかったりします。
かといって、調子の悪い日に合わせると、通常稼働の時に、余計な待機時間が発生することになるため、設定に一工夫必要になったりします。
RPAツールの知識だけでは、作業が進まない
一番あるのは、Web（もしくはブラウザ）からの情報取得ではないでしょうか。
社内システムにしても、IEやChromeで表示しているケースが多くなっています。
その際に、ブラウザに映っている文字や数字、もしくは画像を取得したいが、簡単に取得できないケースがあります。
そこで必要とされるのが、HTMLやCSSといったホームページ作成の知識です。
HTMLやCSSというのは、プログラミングではなく、エンジニアの世界では、とても簡単なものだという位置づけがされていることが多いのです。
しかし、プログラマーでもない一般の人達にとっては、よくわからない英単語や記号、数字が並んでいるので、とてもハードルが高いと感じるでしょう。
あと、HTML・CSS以外には、やはりエクセルの知識でしょうか。
なぜエクセルなのかというと、多くの事務で使われており、自動化を目的としたRPAツールとは切っても切れない縁があるのです。
RPAツールによって、かなり異なってくるのですが、標準装備されているエクセル操作パーツだけでは、充分ではないと思う時があります。
その時どうするか？
VB（Visual Basic）でパーツを作成するか、VBAでエクセルに直接設定してしまうか？というのが、一般的でしょう。
こういった対応が出来るようになってくれば、脱中級者といえるのではないでしょうか。
VDI（仮想デスクトップ）環境が厄介
VDI環境を使っている企業となると、会社の規模がそれなりに大きいところが多いため、上記２つのケースに比べて出会う頻度は少ないかもしれません。
まず、VDIとは何か？
VDI :Virtual Desktop Infrastructure とは、エンドユーザに、物理パソコンに代わる、仮想的なデスクトップ環境をネットワークを通じて提供するITシステムです。セキュリティ向上、管理コスト削減、在宅勤務支援など効果を得ることができます。（https://tintri.co.jp/blog より）
これを使うとどうなるか？というと、自宅パソコンから、会社のパソコンの画面を見て、操作するといったことが可能になってきます。
つまり、上記の場合、実際に処理をしているのは会社のパソコンで、自宅のパソコンはその画面を映しているだけという仕組みです。
これの何が厄介なのかというと、各RPAツールが標準で用意しているパーツの多くが機能しなくなるということです。
どういったことかというと、ちょっとイメージしてみてください。
通常の利用方法では、画面に映るものには、起伏があるイメージです。
ボタンの個所は浮き出ていて、文字の部分も平面に置かれているので、すこし浮いている。
つまり、背景と文字やボタンには、明確な境界線があり、コンピュータは認識できるという状態です。
一方、VDIの世界では、ボタンも文字も背景も同じ平面になっているイメージです。
なので、コンピュータがそれぞれの絵柄や文字を明確に区別しづらいという状態です。
ここで出番となってくるのが、「画像認識機能」です。
画像認識機能は、事前に画面に映る全体、もしくは一部分を切り抜いてセットしておき、その画面が表示されるタイミングで、同じものが画面上にあるかどうか？を識別するものです。
こう書くと簡単そうに思う人もいるかもしれません。
しかし、その判定がシビアであり、ユーザー側で微調整しながら、設定していく必要があるのです。
そして、１か所や２カ所設定するのであれば、別に気にならないかもしれません。
でも、VDIの世界では通常の認識パーツが利用できないため、画像認識機能の利用個所が多く、途中、一カ所でもうまく認識しなかったら、そこでエラーとなり、ロボットが止まることになります。
RPAツールによって、この画像認識機能の性能は異なっており、ものによっては諸条件により、ループ１周目はちゃんと認識したのに、ループ２周目は認識せずという状況も起こりえます。
また、自分のパソコンで開発した時には、ロボットが問題なく動いたのに、納品後にユーザー側で動かしたら、すぐ止まる。
こんなジレンマも珍しくありません（苦笑）
これに関しては、数多くの事例を処理しながら、各RPAツールのクセを覚えて、「どうやったら上手く思った通りに認識してくれるのか？もしくはしてくれないのか？」ということを試行錯誤で研究していくしかないでしょうね。