こんにちは！Geekly採用担当です。
今回はRPAエンジニアグループのチームマネージャー江本さんにインタビューしてきました！
RPAエンジニアというのは少々聞き慣れないのでどんなことをしているのか
RPAエンジニアの役割やチームについて聞いてみました！

ーまずは自己紹介をお願いします！

はじめまして！RPAグループでチームマネージャーをしている江本です。
2022年に新卒でギークリーに入社し、最初はBtoC領域のマーケティングを担当していました。
その後、RPAのプロジェクトが社内で立ち上がり、メンバーとして初期段階から参画し、
現在はチームマネージャーを務めています。

学生時代は地元の愛知県の大学に通いながら、NPO法人の支部立ち上げに関わり、採用部長や全体の統括を経験しました。
また、SNSを使ったビジネスにも挑戦したくさんの試行錯誤を重ねた日々を過ごしていました。

料理系YouTubeを見るのが好きなので、休日は動画映えするような凝った料理を作るのが楽しみです。
あとは「20代は勉強してこそ価値がある」と思っているので、カフェで朝活をして資格勉強や知見があまりないジャンルの本を読み漁って同世代に負けないように日々知識を蓄えています。
インドア派で、少し異色の存在かもしれませんが、そこが自分らしさだと思っています！

ーありがとうございます！
　RPAってあまり聞き馴染みがないですが、どういったことをするのでしょうか？

RPAとは、「Robotic Process Automation」の略で、直訳するとロボットによって業務プロセスを自動化するという意味です。このRPAの導入により、社員が日々わざわざ行う必要のない定型業務を代替できるため、業務の効率化と生産性向上が期待できます。

業務には2通りあって、企画や創造といった人がやらないとできない業務と、ひたすらこなさなければならない単純作業のような業務があると考えています。
そのうち後者にあたる、いわゆる「作業系の業務」は人ではなくてロボットに任せてしまおう、というのがRPAです。
おそらく、どこの会社でも「人がやらなくてもいい作業」や「単純作業」は存在していると思います。
そういった業務をRPAを使って業務改善をするのが我々の仕事です。

私たちはこの業務改善を通じて、リクルーティングアドバイザー（RA）やキャリアアドバイザー（CA）がお客様と向き合う時間を創出し、価値提供の機会をより増やしていくサイクルを構築したいと考えています。
そのために私たちは、RPAによる削減時間や作業量を目標として日々業務をしています。

私はRPAを中心に業務を行っていますが当社は人材紹介会社であるため、単に「RPAをつくったらOK」というわけではありません。
あくまで当社が成し遂げたいミッション達成のために手段としてRPAを活用しています。
私たちの目的は、求職者や企業の皆様に向き合う時間を増やし、関係性を深められる環境を整えることにあります。
実際に現場で活躍するリクルーティングアドバイザー（RA）からも、「RPAがない時代にはもう戻れない」「RPAがなかったら今頃、ノートPCと向き合ってる時間の方が長いかもしれない」との声があり、導入によるポジティブな変化を感じています。

ー確かにRPAがなかったら我々人事も困ることがたくさんあります・・・
　今ではなくてはならない存在ですよね。
　江本さんはどういった経緯でRPAグループに異動されたのでしょうか？

少々長くなってしまいますが、RPA外注時代→RPA内製化プロジェクト→RPAグループ誕生という、時系列で順を追ってお伝えできたらと思います！

私がBtoC領域のマーケティングをしていた時期まで遡ります。
もともとマーケティングの部署でRPAを利用していました。しかし、社内にRPA開発ができる人材がいないこともあって、RPA開発ができる会社に外注してRPAを利用していたんですよね。もちろん外注することにメリットもありましたが、多額のコストや運用サポート制限、そして社内の現場業務を外注先が理解するには限界もありました。（今思えば、それくらい複雑なRPAを利用していたのだと思います。。）
そこで、「内製化」するという動きがでてきました。内製化できれば、開発を依頼するコストもかかりません。また、現場の業務を理解している社員が行うからこそコミュニケーションのズレも少なく、かついちプロジェクトとしてスピード感をもって導入できるという見立てがありました。

その後、RPAの内製化プロジェクトのメンバーとしてアサインされ、私はRPAを一から学ぶことになりました。
実は私にはプログラミング経験がほとんどなく、学生時代に3ヶ月だけRubyで簡単なアプリ開発をした程度で、完全に初心者でした。
それでもアサインされた理由は、おそらく当時マーケティング部内で成果を出していたためだと思います。当社の好きなところは、成果を出していれば新たなチャンスをつかめる環境がある点です。
任された業務には常に責任を持ち、いちばんの成果を目指して取り組んでいた結果が実を結んだのだと思います。
実際にプロジェクトが始まると、最初は社内のエンジニアから週に2時間ほどレクチャーを受け、それ以外の日はレクチャーされた内容をもとにRPA開発を行いました。当時はマーケティング業務とRPA開発業務を兼任していたので、月に5～6つのRPA新規開発とすでに作成済みのRPAを運用保守する業務を行っていました。
その後1年経過し、RPAを導入した部署がマーケティング部以外にも広がり、全社的なプロジェクトになった頃に社内体制の変更も含めてRPAグループが誕生しました。

RPAグループとして独立後、全社の生産性向上に寄与できたことを認められMVPを受賞することもありました。ただ、順風満帆なわけではなく、組織として独立したため、目標設計や評価項目、マネジメントなど多岐にわたる開発以外の業務にも携わる機会がありましたが、最初からうまくいくはずもなく試行錯誤していた毎日でした。
特に評価設計などは、事業会社におけるエンジニア組織なので評価者にどう評価されるのかを考えないと前提知識がない評価者にはRPAでやってきたことがうまく伝わらず、評価されにくいなんてこともあるので、RPAの価値をうまく表現できる定量的な指標づくりには特に苦労した記憶があります。
また、今となってはなかなかありえないと思うのですが、構築するためのルールをそこまで決めずに、属人化したRPAがたくさん完成していました。つまり、作った本人にしか運用保守ができず欠員がでると誰も対応できない・・・という状態に陥ってしまったんです。そういった組織の欠陥も埋めていくような作業も行っていました。

ーたくさんの試行錯誤を経て、現在のRPAグループが作られたんですね。
　エンジニア＝プログラミングのイメージが強いですが、
　RPAエンジニアはプログラミング技術が必要なのでしょうか？

私たちは、ローコードのRPA開発ツールであるMicrosoft社の「Power Automate」を使用しています。Power Automate内のアクション機能を活用することで簡単にRPAを作成できますが、場合によってはJavaScriptを用いたカスタマイズも行います。とはいえ、必要とされるプログラミング技術は高水準なものではなく、1〜3ヶ月の研修で十分習得可能なので自己研鑽が嫌でなければ全く問題ないです。

正直、プログラミング技術よりも上流部分になるビジネスプロセスや現場業務の理解が重要で、上流から下流まで一貫して1人の担当者が責任を持ってシナリオ作成からRPAの開発まで担当する。これが私たちギークリーのRPA開発です。
具体的には、現場から吸い上げた情報やRPAグループ内で収集した情報を基に、RPA化が必要な業務に対してシナリオを作成し、PowerAutomateでの構築やJavaScriptを用いたコーディングを通してRPAを作成しています。

そして、RPAを「運用する」という視点も非常に重要です。
せっかく作成したRPAも、正しく運用されなければ効果を十分に発揮できません。私たちは上流から下流まで一気通貫で開発・運用を行うことで、事業部がRPAに対して抱いている期待や、部署の業務改善ニーズを正確に反映できるよう努めています。
運用面では、単に作成したRPAを運用するだけでなく、自ら要件定義と設計を行い、余計な工数をかけないように工夫されたRPAを提供することが求められます。現在、大小合わせて数百種類のRPAフローを現場と私たちで管理していますが、運用工数を下げ、かつ効果的なRPAを提供していきたいですね。

また、現場の業務に即するという観点で、いわゆる情報システム部のような形ではなく、事業部の中にいることも当社のRPAグループの強みだと考えています。一般的には情報システム部などの中に配置されることが多いかと思いますが、どうしてもミドルオフィスやバックオフィスと現場ではコミュニケーションや方針に乖離がでてきてしまうものだと思います。
しかし、私たちの組織は現場の事業部に所属していることで、現場の情報をいち早くキャッチアップし、すぐに改善に繋げられます。改善までのスピード感が早いこともギークリーの特徴です。

ーRPAチームとして、今後の展望はありますか？

今のRPAチームの伸びしろは、運用体制です。
個別に担当者が運用保守はもちろんしていますが、本来はビジネスプロセス全体を俯瞰して、最適なRPA運用設計をしていきたいです。今のRPAはどうしても個別RPAの寄せ集めで機能がそれぞれのRPAで重複していたり、逆にA・A’・A”の類似した業務のうち、AとA’はRPA化されているのに、A”は他部署の業務などでRPA化されていなかったりします。
これらの問題を解決するには、ギークリーの業務を俯瞰で捉えて他のRPAの事例を転用することだと思います。RPA開発を、ユーザー部門から上がってきた要望をただ開発するだけ、という受け身の状態にするのではなく、全社RPAを集約している部署だからこそ各RPAを転用して最適なRPA体制を考えられる。
それがギークリーにとって理想のRPAです。
私たちの目的は業務改善であってRPA開発をすることではありません。業務改善のために手段としてRPAを使っているのに過ぎないため、そのほかのツールなども試しながら本質的な業務改善もしていきたいと考えています。

これまでRPAを用いて業務改善をしていた方はもちろんですが、RPAを手段に業務改善を行い、最終的に組織課題の解決に関わってみたい方、ITの力を使ってぜひ一緒にギークリーの生産性を向上させていきましょう！