業務効率化の手段の1つとして、RPAが話題になっています。RPAを導入する際に必要になるRPAエンジニア、RPAコンサルタント※のニーズも高く、以前私が所属した会社でもどんどん人員が増えていましたし、転職サイトで検索すると多くの求人が出てきます。そのため、既にRPAエンジニアとして働いている、あるいはこれからRPAエンジニアになろうか検討しているという方も多くいます。RPAは最近出てきたツールで今後どうなるか不明瞭な点が多く、RPAエンジニアとして働くことがキャリアアップにつながるか不安に感じることもあるかと思います。私はRPAエンジニアとして1年ほど働いた経験があり、その経験をもとにRPAエンジニアの将来性について考えてきました。本記事では私の考えをお伝えし、RPAエンジニアの将来性について考えるヒントを提供できればと思います。RPAコンサルタントをまとめてRPAエンジニアとして記載します。区分が明確に定まっていないため、分ける必要がないと考えました。本題に入る前に、私がRPAエンジニアとしてどのような経験を積んできたかをお話します。新卒でシステム開発会社に入社して数年間はWebやスマートフォンアプリの開発をして、その後にRPAのプロジェクトにアサインされました。希望してのことではなく、突然会社から命じられRPAがなんなのかも良くわからず案件に入りました。RPAの案件に入ってからは、大手の企業数社をお客様とするPoC(概念検証)プロジェクト、本格導入プロジェクトに携わりました。ロボットの開発だけでなく、開発・運用環境の構築や運用ルールの検討なども行ったので、プロジェクトの立ち上げから運用まで一通りの流れを経験し、理解できました。その後は、RPAエンジニアの将来性に疑問を感じたので、RPAプロジェクトではない案件に異動させてもらいました。RPAの特徴RPAエンジニアの将来性について考える前提として、まずRPAの特徴を確認します。システムをまたいで自動化できるノンプログラミングで、業務を自動化するロボットを作れる「1.システムをまたいで自動化できる」ことで、今ままで自動化しづらかったシステム間連携をともなう業務を簡単に自動化できるようになります。「2.ノンプログラミングで、業務を自動化するロボットを作れる」ことで、場合によっては業務をするエンドユーザーが自らロボットを作れるようになります。エンドユーザーがロボットを作れれば、単価の高いSEを使わずに済みます。この2つの特徴により、今まで費用対効果が得られないためにシステム化できていなかった業務でも、自動化対象にできるようになりました。そのため、RPAで人件費の削減や業務品質の向上を見込めるので、多くの企業が導入するようになりました。RPAエンジニアとしていつまで働けるかここからが本題で、まずRPAエンジニアとしていつまで働けるのかを検討します。』の予想では、2018年度のRPAの市場規模は418億円、そして、2022年にはおよそ2倍の802億7000万円に成長すると予想しています。LeadersIT業界全体では、成長率は年間数パーセント程度なので、かなり高い成長が見込まれています。IoTNEWS予想が実現すれば、5年後には現在の2倍程度のRPAの案件があるということになります。調査会社の予測の根拠は分かりませんが、現場で働いていた実感として、RPAプロジェクトが想定よりも効果がでないために失望が広がり、市場が予想ほど大きくならないのではないかと考えています。想定より効果が出ない理由は、以下の3つです。業務ユーザーがロボットを作るのは難しいSEが作っても開発工数が大きい適用範囲が限られる1.業務ユーザーがロボットを作るのは難しい「RPAはノンプログラミングなので、プログラミングの知識がないエンドユーザーでも業務を自動化できる。」という売り文句を良く見ます。エンドユーザーにRPAツールの使い方を教育した経験上、業務ユーザーがロボットを作り上げるのはかなり難しいです。ノンプログラミングでできる範囲はかなり限られているので、実際にはほぼ確実にプログラミングの知識が必要になるからです。そのため、もともとITの知識がある人か、論理的思考力が高く、かつ研修時間を充分に確保できる(1-2カ月まるまるくらい)人でないと、身に着けられません。結果的に、内製化が進まず外部のSEに常駐をお願いし続けたり、内製化できてもスキルが高い人を常に張り付け続けたりすることになります。なると、当初予定していた費用対効果が出せないことや、リソースの確保が難しいことを理由に、RPAの適用範囲が狭まることにつながります。2.SEが作っても開発工数が大きい業務ユーザーがロボットを作るのは難しいという話をしました。SEなら少ない開発工数でロボットを作れるかというと必ずしもそうではありません。他の開発方法と比べればRPAツールでロボットをつくるのは簡単で、開発の難易度は低いです。業務を自動化しようとすれば細かいルールが沢山あり、それをロボット化しようとすると作成しなくてはいけないロジックは多くなります。なれば、SEが作っても工数は大きくなり、想定していた費用対効果が得られなくなります。適用範囲が限られるRPAが自動化対象にできるのは、人の判断が不要な定型業務に限られます。一見人の判断が不要にみえる業務であっても、詳細を確認すると人の判断が必要なことが分かり、自動化が難しいということが良くあります。自動化できる箇所のみを自動化したり、業務フローを変えたりして対応できる場合もありますが、それでも想定していた工数の削減効果が出なくなることにつながります。5年後もRPAエンジニアの仕事はあるが、あまり旨味がないのでは今後5年間は、RPA市場が拡大するので、RPAエンジニアとしての仕事は充分にあると思います。調査会社が予測するほど大きくならないため、引く手あまたという状況は続かないと考えています。RPAはSEにとって習得が容易なため参入障壁が低いです。そのため、多くの企業の参入が続き競争が激化する恐れがあります。すると、あまり大きくない市場で多数の企業が競争することになり、あまり旨味がない市場になるのではないでしょうか。RPAエンジニアを卒業した後に仕事を得られるかIT業界は変化が速いため、流行っていたツールがあっという間に廃れることは珍しくありません。RPAエンジニアとして働くとしても、今後数十年RPAだけで食べていけることはまずないと思います。そのため、RPAエンジニアの将来性を考えるにあたり、RPAエンジニアを卒業した後のことも視野に入れる必要があります。そこで、RPAエンジニアの経験を通して得られるもの・得られないものを整理し、それがどう評価されるのかをお話しします。RPAエンジニアの経験を通して得られるものRPAエンジニアの経験を通して得られるものは『顧客対応力』です。RPAプロジェクトでは、要件定義からテストまでを一人のエンジニアが担当することが多く、対象業務をしているエンドユーザーと接する機会を得やすいです。そのため、要件定義や受け入れテストを通して顧客対応力を高めるチャンスがあります。RPAエンジニアの経験を通して得られないもの逆に得られないものは以下の通りです。品質・進捗管理など)は習得しづらいです。実際どう評価されるのか(体験談)続いて、RPAエンジニアの経験がどのように評価されるのかを、私の体験をもとにお話しします。私は、RPAプロジェクトを1年ほど経験したのち、自分からRPA以外のプロジェクトへの異動を希望しました。RPAばかりやっていると、技術スキルを高められないため、できる案件の幅が狭まってしまうことが怖くなったからです。単純にRPAの開発が技術的につまらくて飽きてしまったのも理由の1つです。その結果、オープン系のシステム開発をするチームに異動できました。そのチームは、詳細設計以降のフェーズを主に担当していました。異動を受け入れるかどうかを決める面談で言われたのが、RPAの開発経験はオープン系の開発プロジェクトでは評価できないということでした。理由は、『RPAエンジニアの経験を通して得られないもの』で記載したものです。以前のプロジェクトでオープン系の開発経験があったので異動を受けれてもらえましたが、RPAしか経験していなければ難しかったはずです。そのため、開発を中心としたプロジェクトでは、RPAの経験はあまり評価されないと思われます。上流工程(要件定義など)に挑戦するための転職活動その後、上流工程に挑戦したいと思い転職活動をしました。面接では顧客対応の経験を問われましたが、それに対してRPAの話をしたところ充分に評価して頂き内定につながりました。上流工程の職種の募集であっても技術的なスキルは求められたので、RPAの経験だけであれば内定に至らなかったと思われます。そのため、RPAエンジニアだけしかやっていないと他のプロジェクトでは評価されませんが、それに加えてオープン系などでの開発経験があれば、上流から下流まで対応できる人材として評価が得られるというのが私の結論です。今後5年程度はニーズがあり、かつRPAエンジニアの経験を通して顧客対応力を高めることができるので、上流工程の経験を積むという目的でRPAエンジニアになるのはありだと思います。RPAだけをやっていると他のプロジェクトでは評価されにくいため、RPA以外の経験を積むことも意識してキャリアを検討する方がいいと考えています。コメントをキャンセルメールアドレスが公開されることはありません。音楽ポルノグラフィティこのサイトについて製造業のソフトウェア開発部で働くmura-hiroが、ソフトウェアエンジニアの目線で技術とキャリアについてお話します。