RPAの開発現場の仕事内容や内情を紹介します。

RPAの開発現場の仕事内容や内情を紹介します。

 

メンバー構成

小規模開発チームでした。

営業兼取締役の方1名

チームリーダー1名

開発メンバー6名～10名(流動性高)

開発メンバーとしてチームに入っていました。

 

実務の内容

 

案件の割り振り

案件ごとに役割を振り分けられます。

割り振りは取締役とチームリーダーが決定します。

メンバーは希望を言う空気感はありませんし、この案件をやりたいと希望を言おうと考えた事はありますが、そのタイミングで自分に振られていた案件が手いっぱいだったので辞めました。

例

A案件➡チームリーダーと開発者aさん開発者bさん

B案件➡開発者bさんcさん

C案件➡開発者dさんeさん

 

開発メンバーの具体的な業務内容

割り当てられた案件によります。

全体で見ると、RPAロボットの開発をしている時間は少ないです。

やむなくBizroboのDA(デザインオートメーション)を使用する場合は ロボットの作製に時間がかかりますがそれ以外はRPAを触っている時間は短いです。

業務の時間配分

1つのロボット作成に多くても1日の工数で行います。

他のツールのVBS、VBAやメールなどの仕様が変わったり、引数が変更されるとその都度変更しますが時間的にはRPAを触っている時間は少ないです。

たまたま扱う案件がExcel業務の自動化が多かったこともあり、VBAを組んでいる時間が60%仕様書20%その他(RPA含む)が20％という感覚です。

メンバーの中にはドキュメント要員に振り分けられたメンバーも居たため、その方は仕様書を作っている時間が90%です。

要件定義～基本設計、工数見積もり

基本的には営業の方とチームリーダーが話し合って決めます。

すでにRPAのロボットを導入している企業と週に1度会議があり、営業さんとチームリーダーも含めお客様と次の自動化する業務についての洗い出しと自動化するための準備を行います。

メンバーによっては、案件の基本設計から担当することもあります。

メンバーはチームリーダーから案件の内容を聞き「工数算出」をします。

この案件の内容を聞いた時に、メンバーは開発～導入に必要な手順を瞬時に計算し工数を算出しチームリーダーに発表します。

すでに最長の期間がチームリーダーの中で決まっているので、その想定の工数を下回るまで発表をやり直しを行います。

工数算出のやり取り

※この記事の内容はフィクションです。

 

※この記事の内容はフィクションです。

 

工数算出の練習と、期待の程度を表しているのかもしれません。

単体テストにかかる時間や、自分のできる事、業務の仕様を把握することが求められるので難しさを感じる業務の1つです。

 

RPA開発とプログラム

工数が決まったら、実際に開発していきます。

自分が使用していたRPAツールはVBSを使用してVBAを起動させることが多いため、VBSとVBAでやり取りする引数の数を確認し、VBSを組みます。

VBS,VBAだけで終わることは稀で、他にオンラインのログイン機能やAccessを使用することが多いです。

また、RPAの結果報告メールが欲しいと言うお客様が多いのでメールもRPAに設定します。

パラメーターシートなどを使用して、何かの値（メールアドレスやフォルダ構成）が変更されたときにメンテナンスしやすいように組みます。

コードレビューでは、汎用性、メンテナンス性について重視してレビューしていただきます。

RPA、VBS、VBA、どの手順でエラーが起きたのかログでわかるようにエラーを設定します。

１通りの開発が終了すると、単体テストを行います。

単体テストでは正常動作とエラーの閾値を意識して閾値の前後と0の値の組み合わせで全通りのテストを行います。

単体テストが終了するとレビューをします。

チームリーダーに報告しレビューをしてもらいますが、ここでテストの抜けや見落としがあると指摘を受けます。

コードの組み方についても基本的な事は指摘を受けます。

本当にありがたい事に、インデントの存在すら知らなかった自分にも優しく教えてくれる素敵なチームリーダーであり、現場でした。

 

結合テスト～保守運用

ツールが開発完了するとお客様と打合せし、結合テストを行います。

1～2日で設置を行います。

お客様先の環境が開発現場で作れない事がほとんどですので、この結合テストの時に不具合が出たり、エラーが出ることもあります。

保守については、お客様の企業内に保守チームが居る場合はお願いします。

居ない場合は、軽微な保守は行いますが、大幅な仕様、環境変更やエラーについては追加料金を頂いていました。

 

 

開発中の難しい点

開発現場に居て自分が感じた難しさを紹介します。

自分の技術者としての実力不足もありますのでご了承ください。

お客(エンドユーザ)様とのやり取り

開発中にエンドユーザー様からいただいたデータや資料を元に開発を行います。

しかし、セキュリティの関係上、本番データを貰えることは少なくテストデータで開発を行います。

テストデータで見つけた矛盾点や疑問点をお客様に質問して仕様を固めていくのですが、自分はRPAの専門用語を使わずに質問し、お客様の業務の専門用語での回答を理解することが難しいです。

解答を予測して、YesNoで答えられる質問をしたり、こちらから提案をすることも1つの手段です。

仕様変更が多い

開発中にチームリーダーから連絡が来て、仕様が変わることは日常茶飯事でした。

1度組んだロボットやプログラムの仕様を変えるという事は、時には１から作るくらい重労働な事もあります。

そもそもお客様自身が自分の業務の詳細（例外についてなど）把握していないことも多く、開発中に質問をすることで浮き上がってくることも多々あります。

開発者としては数をこなすことで、事前にそういったお客様の気づいていない穴に気づいて出戻りを減らす事が求められます。

 

RPAの開発現場で業務をしてみて感じた個人的な事

開発現場に初めて入った自分としては、初めてがこの現場で助かったという様な恵まれた現場でしたので大満足しています。

しかし、自動化を望むお客様の業務は多岐に渡ります。

一長一短のRPAツールが散在し、各ツールが高額の2019年2月現在、まだまだお客様が自分の企業に必要なツールにたどり着けていないのも現実です。

１～２強のツールが出現した時に、そのツールへの返還作業や中小企業のRPA導入が済むまでは、RPAエンジニア、特にコンサルの需要は高いままと感じます。

元々、「コードが書けなくても開発可能」が売りのツールなので、本当の意味で開発可能になるには時間がかかるのではと思います。

 

※この記事の内容は個人的な意見が多く含まれています。

 

 

[関連記事]

RPAのメリットやRPA開発現場の体験談RPAエンジニアの給料・単価について