はじめに
みなさんはRPA使ってますか？
労働力不足にも関わらず、残業時間の削減が求められる日本において、RPAは働き方改革の特効薬として注目され、急速に広まりました。
RPAの普及速度はスマホ並みとのデータもあり、また、米国Gartner社は2020年度の企業や組織にとって重要なインパクトを持つ「戦略的テクノロジ・トレンドのトップ10」の第1位に「ハイパーオートメーション」を挙げました。このトレンドはRPAから始まっており、今後更に加速していくオートメーションの流れの中で、人力で頑張る企業は、自動化を使いこなす企業の圧倒的な生産性によって淘汰されて行くため、RPAにしっかり取り組んでおく事は企業戦略上必須と言えます。
今回は、RPA推進の成否を分ける大きなポイントの一つである**「開発者」**について、RPAの開発に向いている人、向いていない人(採用すべき人、採用すべきでない人)という観点で書いて行きたいと思います。
##RPAの開発に向いている人、向いていない人
RPAの開発に向いている人、向いていない人の主なポイントは以下です。
■ RPAの開発に向いている人
- プログラミングはあくまで手段であり、業務効率化の観点で考えられる
- 柔軟性があり、現場への適応能力が高い
- コミュニケーションに問題がなく、基礎的なビジネススキルを身に着けている
■ RPAの開発に向いていない人
- プログラミング自体が好きである
- システム開発の考え方が身体に染み込んでいる
- コミュニケーションが苦手である
以下、それぞれの詳細について書いていきたいと思います。
RPAの開発に向いている人
1. プログラミングはあくまで手段であり、業務効率化の観点で考えられる
「RPAはロボットの開発だから、とにかくプログラミング経験のある人が良い！」と考える人が多いのですが、実はこれは禁じ手になります。プログラミング経験のみで判断すると、とにかくプログラミングでなんとかしようとする人にあたる事が多いです。しかし、あくまで目的は業務の効率化・自動化であり、ロボットを作る事はその手段の一つでしかありません。業務の効率化・自動化という本来の目的に立ち返り、「ここはロボット」「ここはマクロ」「ここは手作業」「ここは業務の見直しが必要」といった、RPAに留まらない視点での業務の見直しや要件定義・運用設計を考え、業務自体を俯瞰して考えられるスキルが重要になります。
極端に言えば、不要な業務はなくせるならそれが一番良く、こういった視点も備えた、プログラミング一辺倒ではないジェネラリストタイプが活躍するケースが多いです。
2. 柔軟性があり、現場への適応能力が高い
RPAの開発方針は現場によって千差万別であり、「とにかくスピード重視」「絶対にエラーとならないよう品質重視」「ユーザの業務マニュアルに従って開発する」「そもそも業務マニュアルがないのでヒアリングが必要」等、開発者に求められる働きが各現場によって異なります。ある現場で活躍した開発者が、別の現場ではなかなかワークしないという事も多々あり、現場によって色は大きく異なるため、RPAの開発者は各現場のやり方を柔軟にキャッチアップして、適応して行く必要があります。
また、RPA自体がまだまだ新しい概念であり、日々進化を遂げて行っているため、今後の変化にも柔軟に適応して行くスキルが求められます。
3. コミュニケーションに問題がなく、基礎的なビジネススキルを身に着けている
RPAの特徴として、ヒアリングや要件定義、デモなどを実施する相手の多くは、システム部門の方達ではなく、実際に業務をやられている業務ユーザの方達となります。また、RPAは開発規模自体が小さいケースが多いため、V字プロセスを複数人で分担せず、1案件を1人で担当する事が多いです。
つまり、業務ユーザと開発者が直接会話する機会が多く、ITに詳しいとは限らない業務ユーザの方達とも会話ができるかという事が重要なポイントになってきます。
またRPAの推進において、業務ユーザの方が最もフェイスする機会が多いのはプロジェクトの責任者でもプロジェクトリーダでもなく開発者であり、開発者は業務ユーザから見たRPAの顔になります。業務ユーザの方達にとって、コミュニケーションに難があり、基礎的なビジネススキルを身に着けていない人に対して自身の業務を説明するのは非常にストレスのかかる作業であり、場合によってはそのような開発者とのやり取りを通してRPA自体が嫌いになってしまうケースもあります。専門用語をわかりやすい言葉に置き換えて説明したり、ITのプロからしてみれば当たり前である1つ1つの問いに丁寧に答えたりと、業務ユーザに寄り添う事ができる、人当たりの柔らかな人が向いています。
RPAの開発に向いていない人
1.プログラミング自体が好きである
プログラミングが好きでとにかくコードを書きたい！というタイプの人は実はRPAの開発に向いていません。あくまで業務の観点で要件定義や運用設計を行い、実装箇所(ロボット化すべき箇所)を正しく絞り込む事が重要なのですが、プログラミングが好きな人はとにかく全てをプログラミングしようとするため、ロボット化すべきでない箇所のロボット化や、エラーハンドリングの作り込み過ぎなど、ロボットが肥大化、複雑化する傾向にあります。そしてこれは、リリース後の保守・運用のコストにそのまま跳ね返ってきます。また、コーディングが好きな人にとって、ユーザ開発も意識したRPAのドラッグ&ドロップベースの開発は退屈に感じるケースが多く、どちらの観点で見ても適正は低いと言えます。
2.システム開発の考え方が身体に染み込んでいる
大規模システム開発のウォーターフォール型のV字プロセスを長く経験して来た人は、RPAの開発におけるアジャイル的な要素と求められるスピード感、業務ユーザとの直接のコミュニケーションに馴染めず苦労されるケースが多いです。「相手が要件を持っている」「仕様書に全て起こす事が重要」「1つ1つのプロセスを完遂しなければ次へ進めない」というシステム開発の前提で業務ユーザとのヒアリングに挑むものの、そもそも業務ユーザは何をどうRPA化すれば良いのか最初はわからないため、業務ユーザへのヒアリングと調整が長引き、いつまでたっても開発に入れないというケースに陥る傾向があります。まずは理解を深めるために、60点で良いので作ってみる。その振り返りを踏まえ次の開発で80点、その次の開発で100点といった小さいサイクルを速く繰り返すのが効果的ですが、こういった進め方に馴染めずにシステム開発の進め方に寄せてしまい、RPAで求められるスピード感が出せず、なかなかワークしない方が多いです。
3. コミュニケーションが苦手である
既にコミュニケーションについては何度も触れている通りで、コミュニケーションに問題がないかが最も重要な要素であり、最初に見るべき基準となります。開発・保守・運用において、業務ユーザとの会話は頻繁に発生するため、どれだけ開発能力が高くても、コミュニケーション能力の低さは最大のボトルネックとなります。そして「開発者は業務ユーザから見たRPAの顔」と書きましたが、コミュニケーション能力の低い開発者を揃えてしまったプロジェクトでは、RPAに対するポジティブなイメージが業務ユーザの間で広がらず、RPAプロジェクトの推進自体に大きなブレーキをかける事になります。
まとめ
いかがでしたでしょうか。
RPAの開発に向いている人、向いていない人という視点で書きましたが、
実は日本のSE市場において、RPAの開発に向いている人が意外と少ないという事に気が付いた方も多いのではないでしょうか。
私の経験としても、システム開発で長い下積みを経た方よりも、柔軟性を持った若手の方が、RPAの開発に上手く適応しているなと感じるケースが多いです。
RPAの開発者の採用で悩んでいる方、RPAの開発自体をやってみたいという方々に少しでも参考になれば幸いです。
<参考>
参考書籍
・プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則
・先進企業の事例と調査から学ぶDX成功のカギ-デジタル人材 採用 育成 再教育
Qiita記事
・RPAは誰でも簡単に作れるという罠
・VBAが組める人ならRPAは簡単に作れるという罠
・UiPathのコーディングチェックツールを作ってみた
・RPAへの理解がぐっと深まる、RPAがよくこける理由
・寿司打を自動化してみた【RPA×OCR】
・RPAのオススメ書籍
・RPAの推進に必須なRPAOpsという考え方
・【AI】Deep Metric Learning
・【AI】Deep Learning for Image Denoising
・Deep Convolutional Autoencoderベースの教師なし異常箇所検知
デモ
・UiPathCodingChecker：UiPathのxamlファイルからコードを分析
・AI Demos：DeepLearningによる手書き文字認識・異常検知・画像のデノイズ
・寿司打自動化(YouTube)：タイピングゲーム寿司打のRPA×OCRでの自動化