RPAは、エンドユーザーコンピューティングの悲劇を繰り返すのか?

初めて、「野良ロボット」なる言葉を聞いた時、私は、「なるほど、上手いことを言う人がいるものだ」と感心した。

野良ロボットとは、会社が管理しきれていないRPAロボット(デジタルレイバー)を指す。野良ロボットは、RPAを使い始めた現場の人々が、「こんなロボットがあれば、もっと便利なのだけど」という向上心が生みだしたものではある。しかし、野良ロボットをいたずらに許してしまうと、既存業務へ悪影響を及ぼしたり、もしくは業務全体の最適化を阻害するボトルネックにもなりうる。

 

同様の課題は、Excel VBAなどでも、過去に発生してきた。
歴史は繰り返すと言うべきか。RPAは、かつてExcel VBAなどが直面してきた、エンドユーザーコンピューティングの課題を再現しつつある。

RPAをより有用に活用するために、RPAを使う現場が招く、エンドユーザーコンピューティングの問題について考えてみよう。

 

ひとりのファイルメーカー信者がもたらした、光と影

もう20年ほど前の話だ。

私の在籍していた事業部に、ファイルメーカーの猛烈な信者がいた。ご存じない方に説明すると、ファイルメーカーとは、データベースソフトであり、MicrosoftのOffice製品で言えば、Accessと競合するものだ。

事業部では、日々の在庫、売上などの営業データの取りまとめに手間が掛かっていた。
地域営業部のマネージャーが部下から口頭でヒアリングした実績を、本部の事務担当に口頭で伝え、本部が取りまとめる、というアナログなことが、日々行われていたのだ。
営業部損益もしかり。
当時、九州営業部のマネージャーを務めていた私は、週末になると、実績を拾い、経理データと突き合わせながら、せっせとExcelでPLを作成し、本部へと提出していた。週明けに行われる週次会議に備えるためだ。

先のファイルメーカー信者は、この状況を一変させた。ファイルメーカーを用いて、実績集計ツールを作成したのだ。
用意された日々の実績入力フォームに、私たちマネージャーが入力を完了すれば、本部が予め取り込んでおいた経理/在庫データと突き合わせ、PLはもちろん、月末の売上着地予測、昨対比/昨月比など、営業会議に必要な資料が、すべてアウトプットされるようにしたのだ。

当然、私たちは狂喜した。
「これこそが、業務改善であり、生産性向上だ」、事業部長のみならず、経営陣も、この取り組みを絶賛した。

 

が、その状況は長くは続かなかった。
ファイルメーカー信者当人が、会社を退職したのである。

管理部門にいた別メンバーも、ファイルメーカーの作成ができないわけではなかった。しかし、そのスキルは、退職したファイルメーカー信者には、はるかに劣る。日々業務の中で求められる、実績集計ツールの改修要望に、残されたメンバーは対応できず、実績集計ツールは、徐々に現実の業務内容と乖離していった。

しばらく混乱が続いた後、結局、件のファイルメーカーによる実績集計ツールは放棄され、営業報告のプロセスは、口頭伝達とExcelに戻った。

 

余談だが、ファイルメーカーは、その使い勝手の良さによって、中小企業を中心に、業務や在庫、経理などの管理システムの代用として使われてきた(現在も使っている企業もあるだろう)。

数年前、ある中小企業から相談を受けたことがある。
同社では、かつて在籍した社員が作成したファイルメーカーによって、経理や給与、もしくは営業管理などの基幹系業務を管理していた。ファイルメーカーからの脱却を目指し、あるシステム開発会社に再構築を相談したところ、500万円ほどの見積もりが出てきたというのだ。

「これって、高すぎじゃないですか!?」

言わば、基幹システムをスクラッチで構築するのだ。高くないどころが、安いのではないか?
そう答えた私に、相談者は不満げに、このようにつぶやいた。

「もともと、社員が給料の範囲で作ったものが500万円なんて・・・」

 

これこそが、エンドユーザーコンピューティングの悲劇だろう。

 

エンドユーザーコンピューティングとは

エンドユーザーコンピューティングとは、本来企業の中で、システム開発や運用を主導すべき情報システム部などではなく、現場の担当者が主導し、システム開発を担当したり、もしくは自らプログラミングなどを行う行為を指す。

 

MicrosoftのOfficeアプリで利用できる、VBA(Visual Basic for Applications)は、エンドユーザーコンピューティングを引き起こしやすいツールのひとつだ。

それでなくとも、Excelが良くも悪くも蔓延している日本企業の現場においては、ちょっとITリテラシーに長けた人が、自分の業務に適したVBAを作成するケースがたびたび見受けられる。

もっと、業務を効率化したい。
もっと、事務作業の処理速度を上げたい。

先のファイルメーカーの例のように、エンドユーザーコンピューティングを行う人の多くは、向上心と課題意識を持っている人が多い。

しかし、最後まで、自分が作り出したツールの責任と面倒を持つことは、難しい。

 

これは私も経験がある。私自身、VBAを多用してきたからだ。
営業部の平社員だった頃だ。私が作成したExcel VBAに上長が注目した。製品別の売上を集計し、月末の売上予測などを集計するVBAである。

「俺も使っていいかな? 後、これこれこういうこともできるとありがたいのだけれども」

上長に渡したVBAは、あっという間に事業部内に拡散した。
当たり前である。
私が面倒だと思っていた業務は、他の人だって面倒だと思っている。楽をして、間違いも起こさず、しかも手作業よりも早いツールが目の前にあれば、誰もが使いたいと思う。

 

厄介になったのは、私が異動になってからだ。
私がいなくなってからも、件のExcel VBAは使われていた。異動した後にも、私のもとには、VBA改修の依頼が来ていたのだ。

体育会系の先輩後輩関係が強い、私が勤めていた会社では、先輩の要望を断ることができなかった。結果、VBA改修の依頼が来るたびに、私は週末を潰す羽目となった。

 

エンドユーザーコンピューティングのメリットとデメリットとは

◇ メリット

・現場の事情や状況を反映した、実戦的なツールであることが多い。
・営業や製造、品質といった、本来のシステムを担当する部門ではない社員が作成(担当)するため、開発コストが表向きは見えにくい。つまり、開発費のキャッシュアウトがない。
・作成者(担当者)本人の、ITリテラシーが上がる。

 

◇ デメリット

・属人化しやすい。開発したツールを、他の人が改修することは難しいケースが多い。
・エンドユーザーコンピューティングの対象となった業務が、ブラックボックス化することがある。
・ツールの使用が業務に組み込まれてしまうため、業務改善の妨げとなるケースがある。

例えば、自らVBAを書く人が目指すのは、あくまで自分の業務の最適化であり、省力化である。範囲が広がったとしても、せいぜいが自分が所属する部署の業務にとどまるであろう。

本当の業務改善とは、全社、さらに言えば、お客様や取引先も含めた業務全体の最適化である。ひとつの部門、ひとつの業務の最適化が、全体最適化とイコールであるとは限らない。
部分最適化は、必ずしも全体最適化と一致しないのだ。

 

このようにして、エンドユーザーコンピューティングは、時として、会社全体の業務改善におけるボトルネックにもなりうる。

そして、RPAも、かつてVBAが引き起こした、エンドユーザーコンピューティングの悲劇を引き起こす可能性がある。

 

RPAは、業務改善・生産性向上の手段に過ぎない

製品にもよるが、RPAはプログラミングに比べると、習得にかかる教育時間が比較的少なくて済む。
だから、世間では「RPAはカンタンだ」という勘違いが存在する。

RPAベンダーの中には、クライアントの社員に向けた教育プログラムを用意し、社員自身がRPAを作成し、必要に応じて改修することができるスキルを身につけることを推奨しているところも少なくない。

教育プログラムを用意することそのものは、良いことだと思う。
だが、少し考えて欲しい。

RPAを企業が導入する目的は、業務改善や生産性の向上であろう。RPAは、その手段に過ぎない。すなわち、RPAを生み出す技術を教育することも、業務改善や生産性向上の手段に過ぎないはずだ。
だとすれば、RPAを作り出す教育を受けた社員は、業務改善や生産性向上を行うための知識も身につけなければならない。少なくとも、何のためにRPAを導入したのか、業務改善や生産性向上のロードマップを知り、ロードマップにそって、RPAを作成・改修しなければならない。
つまり、RPAを導入した企業は、RPAを使う目的であり、業務改善・生産性向上のロードマップを、RPA教育を受けた社員に共有しなければならない。

だが、RPA導入企業の中には、社員にRPA教育を受けさせただけで満足してしまうケースも少なくない。もっと言ってしまえば、業務改善や生産性向上について、明確なロードマップを持たずに、RPAを導入してしまう企業もいるであろう。

 

「便利だから使ってごらん」

そんなことを言われ、RPAを学んだ社員たちはどうするであろう。
向上心と課題意識を持った社員であればあるほど、目につく業務をこなすRPAロボットを、次々と作り出すであろう。
野良ロボットの大量発生である。

 

かくして、RPAは、エンドユーザーコンピューティングの悲劇を繰り返すのだ。

 

エンドユーザーコンピューティングの悲劇を繰り返さないため

RPAは、広く世間に知られるようになってきた。
私自身の感覚ではあるが、RPAというキーワードを知らない人も、だいぶ少なくなってきたように思う。

だが、まだまだRPAは試行錯誤の時期にあるのではないか。
だからこそ企業は、RPAとどのように向き合うべきなのか、柔軟に考えるべきだ。

 

RPAは、しょせん道具に過ぎない。
道具を活かすも殺すも、それは使う人次第である。

どんなに便利な道具であっても、使い方を誤れば怪我をする。
例えば刃物は、人類の進化を助けた偉大な発明のひとつだろう。だが、正しい使い方を守らなければ、自分や他人を傷つけてしまう。

「ナイフは危ないから、使うのをやめよう」というのは、問題の根本的な解決にはならない。大切なのは、正しい使い方を学ぶことだ。

これは、RPAも変わらない。

 

RPAによるエンドユーザーコンピューティングの悲劇を繰り返さないためには、どうすればよいのか?

ひとつは、RPAロボットを作成する人が、「これはRPAで行うべきことなのかどうか」、一度立ち止まり、ロボットを作成する前に冷静になって考えることだ。
繰り返すが、RPAは業務改善や生産性向上を実現するための手段に過ぎない。RPAロボットを作成する前に、他にもっと効果が高く、最適な方法がないのかどうか、考えれば良い。

ただし、そのためには、企業側が、あらかじめ業務改善・生産性向上など、RPA導入の目的に対するロードマップを用意しておく必要がある。社員は、ロボットを作成する前に、ロードマップを見て、そのロボットが必要なものかどうかを判断するためだ。

 

現在も、過去の先輩たちが作り上げたファイルメーカーやMicrosoft Access、VBAなど、エンドユーザーコンピューティングが生みだした、負の遺産に困っている企業は存在する。

RPAに同じ轍を踏ませないために、RPAを既に導入した企業、もしくはRPA導入を検討している企業は、過去にエンドユーザーコンピューティングが生みだした悲劇を、今一度かえりみて欲しい。

 

 

ライタープロフィール

坂田 良平

坂田 良平

Pavism代表。 一般社団法人グッド・チャリズム宣言プロジェクト理事、JAPIC国土・未来プロジェクト幹事。 「主戦場は物流業界。生業はIT御用聞き」をキャッチコピーに、ライティングや、ITを活用した営業支援などを行っている。 筋トレ、自転車、オリンピックから、人材活用、物流、ITまで、幅広いテーマで執筆活動を行っている。