RPA（Uipath）って？【後編】

2023年7月7日 09:49

後半です。

主題に入っていきましょう。

少し遅くなってしまいましが、RPAエンジニアはどういう仕事なのかということです。これは会社によって異なる部分があると思いますが、まずは要件定義からです。

そもそもRPAでできることというのは予め決まった情報を元に動くので、人の判断が必要なプログラムが作れません。予め情報をデータにして送ればプログラムの作成が可能ですが、例えば画像を見て、これがウェハの不良かどうかという判断に関しては完全に人任せになります。ただその前の段階まで簡単に導いてくれるのがRPAというものだと私は思います。

まずは一連の作業がプログラムに落とし入れられるか、工数はいくらかかり削減時間はいくらになるかなど詳細を詰めていきます。私は同じ会社内の要望で作っていたためプログラムの仕様がわかる状態で話し合うので、特に問題はありませんでした。

これが顧客となればまた別の話になります。しっかりとしたヒアリングを行い、顧客の意図を汲み取る必要があります。ここは上流工程と呼ばれ、他の会社の場合、これを専門に行う場合もあるそうです。自身が知らない顧客のプログラムを動かす場合などは綿密な相談が必要です。システムの機能や、開発に必要となる予算や人員もここで決めます。私の会社の場合はRPAの特性の問題もあり、一人で作ることがほとんどでした。

　次は基本設計でここでは実装する機能の洗い出し、必要なデータの明確化、整理

などを行います。私の場合は会社内のRPAを担当していたので、顧客との対応とは違い、使用するツールはわかるので、簡易的に作成していました。

というのもお互いの共通認識が直ぐに取れるのと、基本的に依頼してくる人は大変忙しいので、あまり相手の工数を割かないようなやり方を取っていました。

顧客の場合だと基本設計書などが必要となるため、この工程も長くなります。そういう意味もあってここまでの上流工程と下流工程に分かれている所が多いのでしょう。

　そして基本設計と詳細設計に入っていきます。私の場合は既に出力するデータや操作方法は相手側が理解しているので、一貫で作成していました。基本的に会社内で使われているプログラムを使うので、頭の中に設計書は既に出来ています。

それをアウトプットするだけの作業です。ただ、アウトプットするためにはRPAの知識が必要になります。やり方を知っていないと我流の書き方や実行時間が長いプログラムになってしまいますので、ここもRPAディベロッパーに依存するので、前述した餅は餅屋ということに繋がってきます。

　さてここでもさらに知識が必要になります。SQLを使う場合です。私の会社は前にも書きましたがデータの取り出ししかできず、書き換えは不可能でした。

前述したLOTをSTOPさせるプログラムもSQLで情報を書き換えれば実行時間が千分の一程度で済んだでしょう。つまりSQLで書き換えられる環境にあるかというのも設計に関わってきます。

そしてSQLで取得したデータはRPAで扱えるようにデータを変換する必要があったりします。データ型を変更する関数を使用する場合もあります。

また空欄が末尾についている場合があるので、SQL文で取り除いておくか、RPAで取り除くかという作業になります。つまりはSQLの習得は必要不可欠になるということです。

　またRPAに必要なものの最後の一つとしてVBAが挙げられます。RPA内に直接VBAのコードが書いたファイルを読み込めるので、汎用性がとても高いです。結論としてはRPAの知識の習得、SQLの習得、VBAの習得が必要不可欠になってくるわけです。

　ここまで来ると専門的になってくるので、会社が１から育てるか、それともディベロッパーを雇うかどうかの話になってくるのです。最初は取っつきやすいRPAですが、中々奥が深いことを分かっていただけたかと思います。

さて、少し話が脱線しましたが、次の工程はテスト工程です。

うまくサーバー上で動くか、テストしないといけません。これが割りと大変な作業で、内部のアプリケーションの状態を開発した際の条件と同じにする必要があります。

自分のPCでは問題なかったものが動かなくなるというのはよくある話です。ただ、最初のテスト自体は自分のPC上でやりましょう。

ケアレスミスによる動作不良等をここで潰しておかないとサーバーでのテストでサーバーの負担になります。そして問題が無ければオーケストレイターと呼ばれるプログラムを使用するサーバーを管理する場所で初期設定を行い、サーバー上でテストを行います。そしてバグがあれば修正し、リリースに至る訳です。

　ただリリースがゴールではありません。スタートラインです。帰るまでが遠足といいますが、プログラムが動いている限り運用保守が必要となります。遠足に例えると帰れない状況になってしまいますね。

冗談はさておき、保守運用が個人的には最も重要な工程だと思います。

保守運用に関してはアプリケーションのアップデート、ブラウザのアップデートなどがあると動かなくなる可能性が高く、そこでまたプログラムの改修をしなければなりません。

ただ例えば、中身はそこまで変わらず、バージョン名が変わる場合はどうでしょう？

RPAにはセレクターと呼ばれる特定のアプリなどを特定する文字列が必要になります。インターネットエクスプローラーで言えば【Internert Explorer】という感じですね。

これにVer11.2などがつくと次のアップデートで使えなくなります。そこでワイルドカードが必要になってきます。

ワイルドカードというのはアスタリスク【*】移行の文字は識別しないようになっています。

例えば【Internert Explore Ver11.2】などと表記される場合は【Internert Explorer*】とします。

ここで注意したいことが、*を多用したり、最初の方で使うとそもそもインターネットエクスプローラーを認識できなくなる点です。

個人的にはVerまで行けば特定できるので、Ver移行につけることをオススメします。

ここまでRPAの話をしましたが、あくまで私の会社内での話です。

環境が違えば作り方も異なってきます。ウォーターフォールで開発するかアジャイルで開発するかというのも異なる点だと思います。違いを簡単に説明するとウォーターウォールは最初にすべての要件を明確にする要件定義を実施します。

それに沿って外部設計、詳細設計、開発、テストと順を追って進める開発⼿法です。アジャイルはターゲット業務を⾃動化し、できたロボットを動かしながら修正を加えていくスタイルです。どちらが合っているかは環境によって異なりますが、どちらも一長一短です。

ウォーターウォールでは要件が変わった際に柔軟な対応ができないなどの弱点はありますが、簡潔で分かりやすく、工数や、納期がわかりやすいメリットがあります。

アジャイルは多くのプログラムを同時並行で進めるため、管理が複雑になる上に納期も曖昧になりやすくなります。

私はRPA自体が複数人で作成したことがない、というよりもそういうプログラムがRPAではあまりなかったのでウォーターウォールを採用していました。これも環境によって違うところですね。

　さて、ここまでRPAの話をしてきましたが、どういうときに使うの？　という疑問が発生している方もいるいかもしれません。それを私や他のディベロッパーが開発したものに言及して話していきたいと思います。

まずRPAに向いている作業は単純作業です。私の元職場では似たような画像を大量にアプリケーションから取らなければいけない作業がありました。変更する項目が完全に分かっているが、一々それを入力しなければ画像にたどり着きません。

傍から聞いても生産性のない仕事です。そこで情報をエクセルに入力し、マクロのボタンを押すだけで、自動的に画像を取得し、それをVBAで貼り付け、実行者にメールを送るプログラムが出来ました。正直に言えば旧帝以上の学歴で入った人がやるべき仕事ではありません。こういう無駄なものはすべてRPAに任せるに尽きます。

またも単純作業の話に入ります。

前述したLOTをSTOPする仕事はLOTの番号が違うだけで、他に４つほど入力と５つほどチェックボックスを入れる必要がありました。

１LOTで三分かかる作業を数百LOT分手動でやるわけです。

とても馬鹿馬鹿しい仕事ではありますが、大切な作業でもあります。それを自動化するだけで週３０時間も削減出来たわけです。

もはや大企業にとってRPAは不可欠な存在になっていると断言してもいいでしょう。

　そしてよくあるプログラムはレポートです。毎回同じ所からデータや画像を持ってきてメールを送る全く無駄な作業です。こういうことに時間を割かれていてはクリエイティブな仕事は出来ません。RPA化すればすべて解決するのですから、RPA化しない道理はないでしょう。

　おそらくこれを読んでいる方も毎日同じような作業をしているかもしれません。エクセルならVBAで事足りますが、アプリケーションはそうはいきません。これを機にRPA化を検討してはどうでしょう？

RPAの導入の話に入ります。

ここはある程度ざっくりとしていますが、Uipathであれば無料で６０日間試せます。試しに入れてみて、簡単な作業なら勉強も含め３０時間以内に作れるでしょう。その結果を上司に見せてみてください。

これなら我が社も導入するべきだなとなるかもしれません。

そこでRPAディベロッパーとして歩みだすのか、はたまた私のような開発経験がある人に依頼するかは分かりません。ただ、確実に大企業であれば沢山の反復作業やつまらないレポートもあるでしょう。中小企業でも毎日同じエクセルで似たようなことをしているかもしれません。

　私は他の言語はできません。RPAでできることは例えばPythonでも可能かもしれません。ただ、サーバーでの実行や作成時間の少なさ、とっつきやすさがRPAの売りだと私は思います。RPAであれば私はあなたが悩んでいる仕事について相談と回答ができるかもしれません。気軽にコメントしてくださると助かります。