top of page

RPA(Uipath)って?【後編】

RPA(Uipath)って?【後編】

公開日:

2023.7.5

後半です。

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





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



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








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



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





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

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



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



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





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


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





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


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


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



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





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



 ここまで来ると専門的になってくるので、会社が1から育てるか、それともディベロッパーを雇うかどうかの話になってくるのです。最初は取っつきやすい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の番号が違うだけで、他に4つほど入力と5つほどチェックボックスを入れる必要がありました。


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


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


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





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



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






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


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



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

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




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






さて、これで最後のトピックになりますが、最近はCHAT GPTが流行り始めていますね。AIで絵が簡単にかけて実際に使っている企業もあります。



AIの進歩は今急激に発展しており、もしかしたら旧来のSEとは違うような働き方になるのかもしれません。ただ、AIがいくら進歩してもそれを使えなければいけません。



RPAのディベロッパーのように、AIに携わるスペシャリストが必要になってくるでしょう。少し前の話でAIが女性を雇用するべきじゃないと判断したことがありました。データだけで言っているので、今の世界の状況とは全く異なっています。




 最後に言いたいことはAIは完璧ではありません。ただ然るべき活躍できる場所ではとても使えるものだと思います。RPAはAIとは異なります。お互い活躍できる場所も異なってくるでしょう。






 RPAが流行りだしてからだいぶ立ちますが、まだまだ導入していない企業も多いと思います。私の文を読んで少しでも興味があれば一度調べてみてください。反復作業なんてRPAに任せればいいと考えが変わるかもしれません。私は少しでもRPAの普及に貢献できればと思います。




 ここまで読んでいただきありがとうございました。











legarea_banner01 (1).png
ブログページバナー_002.png

人気記事TOP5

2.png
3.png
4.png
5.png

SES業界に蔓延するロースキル層の闇

LEGAREAのSESは1人じゃない

高還元SES企業の見極めポイント

高還元SESエンジニアは本当にお金持ち?

(株)LEGAREA新採用基準

新着記事
フルリモートできる案件とできない案件の違い
まともなSESで働くメリット
【謹賀新年】あけましておめでとうございます
​おすすめ記事
エンジニア同士の人脈作り
高還元SESとフリーランスどっちが得?!
高還元SESで若手がスキルアップする具体的な方法
【自社エンジニア執筆編】未経験からエンジニアを目指そうと思ったきっかけ、実際にSES業界に入ってみての感想
未経験はインフラエンジニアがおいしい?
SES営業はブラックですか?
legarea_banner01 (1).png
ブログページバナー_002.png
bottom of page