「Excel職人」という言葉があります。Excel上の定型作業を、複雑な関数機能やVBA（注1）を使って職人芸的に自動化する人のことをそう呼びます。ただし「職人」とはいうものの、良い意味で用いられることは少ないようです。多くは、個人に仕事が集中してしまう、いわゆる“属人化問題”を引き起こす原因として、揶揄する意味で用いられています。
　そうなってしまう原因は、Excel職人たちが、設計内容を周囲に共有することなく、独自のやり方で自動化ツールを作り込んでしまうことにあります。多くの場合、スキルが共通言語化されておらず、ツール自体も個人で業務の合間に作成できる規模であるため、そうなりがちなのが実情のようです。結果として作業内容がブラックボックス化し、Excel職人が抜けてしまうと、修正が必要となった際にツールの改修がままならず、「負の遺産」だけが残るといった問題が生じます。

　しかしこうしたExcel職人も、RPA（注2）の台頭によって、姿を消していくと考えられます。
　RPAはソフトウェア上で動くロボットを実現するための仕組みで、Excelだけでなく他のアプリケーションの定型作業も自動化する柔軟性を有します。設計もプログラミングのような専門性は要さず、フローチャート上の操作で直感的に行えることから、設計内容がブラックボックス化しにくいのが特長です。

　RPAの導入・運用を支援するサービスは存在しますが、RPAの設計・管理は容易なため、現場のユーザーが中心となって運用する場面が多くなると考えられます。その際、ロボットに仕事を学ばせる、あるいはロボットの仕事の仕方に間違いがあればそれを指摘する、いわば先輩社員のような役割が不可欠です。RPAのスキルは短期間のトレーニングで習得できるとされていますが、その役割の適任者はExcel職人なのではないかと考えます。
　彼らはおおむね、ツール開発への高い関心と自主性に基づいてスキルを身に付けており、えてして新しい手法を取り入れることへの抵抗がないことがその理由です。たとえ従来のスキルが通用しなくなっても、そうした姿勢はRPA導入にあたっても活きることでしょう。

　RPAは、業務効率の改善だけでなく、仕事の属人化を解消するポテンシャルも秘めています。今後は働き方改革や生産性向上のもとに、導入する企業も増えていくことでしょう。しかしルール整備や人材教育などの運用体制に不備があれば、次は「RPA職人」が生まれてしまう恐れもあります。その意味で、RPAはExcel職人の教訓を活かすべき存在といえるかもしれません。そしてExcel職人自身も、今後RPAと向き合っていくのであれば、同じ轍を踏まない姿勢が求められるのではないでしょうか。

注1：VBA（Visual Basic for Applications）
MS Office上で動作するプログラミング言語で、操作を記録するマクロ機能にも用いられる。

注2：RPA（Robotic Process Automation）
ロボットによるホワイトカラー業務の自動化や、その取り組みを指す概念。