RPAコンサルタントを辞めた話

新卒から丸3年、
続けてきたRPAコンサルタントという職を辞めた。

当時は日本でまだ市場が開かれたばかりの活気のある、それは新卒の自分にとっては願ってもないキャリアステップだと心躍らされた。

しかし年次を追うごとに違和感が増し、この春、私は社内異動をした。

それはRPAに絶望したからではない。

当然、地方市場が熱を帯びつつあり、長期出張が続き東京に住めなくなったからでもない。

RPAをコンサルティングするには、まだ未熟だったためだ。

これはRPAコンサルを目指したいと思う人、RPA導入や開発に携わり、どこか違和感を感じている人に読んでいただきたい。

尚、RPAに対するヘイト記事や、所属していた組織への不満ではないという事を、先に断っておく。

そもそもRPAとは、既存業務をソフトウェアに記録し、従来は手で行なっていた作業をいわゆるロボットに置き換え、業務の効率化が図れるというモノだ。

現場の社員が比較的簡単に実装でき、生産性向上が見込めるツールとして注目の的になっている。

私は日本でRPAが流行りはじめた2017年（RPA元年とも言われる）から、新規事業として立ち上がったRPA組織にコンサルタントとして配属された。

RPAツールの操作方法や、各種ドキュメントの作成はお手の物になったが、肝心の業務効率化をするというミッションにイマイチ貢献できている感がなかった。

※開発をするだけのプログラマーではなく、業務自体を再構築し、顧客からイニシアチブを得るということがミッションとして与えられていた

それっぽくフォルダの構成を変えてみたり、順序を変えたりはするが、ビジネスインパクトを与えるような再構築をできるようにはなれずに、悩んだ。

RPAに向いている人っていうのは大きく2パターンある。

一つは、システムエンジニア経験がある人。

二つ目は、業務に精通している人だ。

システムエンジニア経験がある人は、システムを構築するための要件を詰めたり、仕様を決めたりする能力に長けている。

RPAも結局はシステム開発のようなものなので、その手の経験値がモノをいうのだ。

じゃあ、システム開発経験がなくても開発できるといういつもの謳い文句は嘘なのかというとそうではない。

システム開発経験がなくとも、RPAは充分開発できる。

その助けとなるのが、業務経験だ。

そもそもRPAの発想は、既存業務をソフトウェアに“置き換えること”であるのは先に述べた。

しばしば業務プロセスを見直して業務自体を再構築するので置き換えではないとご指摘を受けるが、
あくまで、再構築した業務プロセスは手動で再現可能な事が前提であり、その上で高速化や正確性を求めてRPAに置き換えるのだ。

お気づきの通り、業務を再構築するにしろしないにしろ、この置き換え作業をする際、業務への理解、精通が必須になる。

それは表面的な作業理解に留まらず、なぜその業務が存在するのか、前後にはどのような処理が行われているのか、関係部署はその間どのような動きをしているのかなど、立体的に把握する必要がある。

ここで一番厄介なのが、会計などのようなそもそも作法があるような業務や、その業界独自の文化がある業務だ。

このような作法や文化は多くの場合、言語化されることはない。

そこが属人化するのだといったところで、言葉にするには情報量が多すぎて、言語化なんかできない。

そんなパワーは現場にはないのだ。

現場の社員が導入可能と謳われるのは、この背景や文化といった目に見えない要件を汲み取ることができるからだ。

自分の意図する動作だけを絶妙にロボットに置き換えて、自分で判断したいところだけを自分のタスクとして残す事ができる。

私にはその見えない要件を汲み取る力、経験が圧倒的に乏しい事に気付いた。

「そうだよねぇ、くぼくぼくんはこれまで業務をやったわけではないゆえ、本質的なところが見えない中でやっているから、大変だよねぇ、、、」

これは実際に要件定義の場で顧客が、私を案じてくれた言葉だったのだが、それは強く衝撃を受け、また、この違和感が一瞬で晴れる言葉であった。
（林さんありがとう）

つまり、私にはベーシカルな、社会人としての基礎的な業務スキルが無い、同時に、普遍的なスキルが無いのだという事に気付いた。

システム開発経験がRPA開発に応用が効くように、私にはそのような基礎的なスキルが無い。

ただ、ツールで遊べてちょっとIT周りに詳しくなっただけだ。

私はRPAを辞めた。

正確にいうと、辞めてみた。

ベーシカルなスキルを求めた先には、本質的な仕事ができる日が来るのだろうか。

いや、来てもらわないと困るか。笑