こんにちは！開発エンジニアの辰巳です！

今回はRPA開発視点として、開発・保守・運用の経験を経て感じたことを書いていきます。

私が感じたRPAの易しい点

・学習コストが低い
・UI操作なので視覚で情報を得られる

コーディングとは異なり、RPAはコーディングが必要ないという面での学習コストは低いと感じました。
それに加えてUI操作がメインとなるため繰り返し処理や分岐処理、その他含めた処理において、
目で見てわかりやすいことも学びやすさの一つだと感じました。

そして、学習コストが低いことでより別のことに時間を割くことができました。

私の場合だとロジック面の深堀です。
ロジック面の深堀としては①無駄を減らすこと②応用が利くフローを考えることです。

ただ、先輩社員や上司に意見を仰ぐと新たな方法を知ることがあり、
視野を広げることも重要だと学びました。

私が感じたRPAの難しい点

・エラー原因が特定しにくい

RPAの比較として、ここではVBAを例に上げさせていただきます。

VBAは基本的に、対象はエクセルになってきます。
ですのでエラー時の選択肢としてはコーディングか対象のエクセルのどちらかにエラー原因があるのが大半でした。

それに比べてRPAはPC内のすべてのアプリを操作できるため、
エラー時の選択肢がPC内のアプリかロボットの設定かというVBAよりも広い範囲となりました。

そのため、RPAのエラー原因の特定がVBAよりも難しいことがありました。

しかし、ログの設定で処理過程を可視化するなどの対応策でエラーの切り分けの難易度を下げることができました。
また、こういったエラーのおかげでRPAに限らず幅広く知識を得ることができました。

そして、こういった経験のおかげで次の開発時によりエラーが発生しにくい開発ができるといういいサイクルができたので、
トライアンドエラーをすることもRPAの効果を上げるためには重要だと学びました。

　

まとめ

働き初めの頃は技術力がとにかく一番と思っていましたが、
あくまで道具の一つなんだと実感しました。

ゲームで例えると

・攻撃の技 ：技術力→選択肢を増やす
・敵の弱点を探す ：理解力→課題の本質を見極める
・敵の弱点と相性のいい攻撃を選択する ：思考力→課題に対しての最適解を導く

　といったイメージです。この3つはどれが欠けていても強い敵には勝てなくなります。

つまり、何が一番というよりどれも大事なんだと実感して
学習→実践→フィードバックのサイクルが私自身の成長の肝だと思っています。

技術力=1、理解力=1、思考力=１で実践してフィードバックをする。

次に技術力=2、理解力=1、思考力2で実践して理解力が1では駄目だとフィードバックして
また次に繋げる。

こういったトライアンドエラーが自分の成長かつ、より効果的なRPAの運用では重要だと感じました。

ですので、このブログを読んでくださっている皆さんもどんどん積み上げて行きましょう。