過去にExcelレガシー問題と言われた、ExcelマクロやノーツDBを作成した人にしか内容が分からず、人事異動や退職などによって残されたエクセルマクロ（VBA）が変更出来ないブラックボックス状態になってしまった問題がありました。
最近話題になっているRPAの導入は同様の問題をはらんでいるのか、その対応策は無いのか、などこれからRPAソフトウエアを導入しようとされている企業の方々に向けたご説明をしいます。
Excel（エクセル）レガシー問題とは
過去にEUCブームと言われるブームがありました。EUCとは業務部門のエンドユーザ自身が自分で使うツールを開発しよう、という流れで
EUCとは、企業などで情報システムを利用して現場で業務を行う従業員や部門(エンドユーザ、ユーザ部門)が、自らシステムやソフトウェアの開発・構築や運用・管理に携わること。
【IT用語辞典より引用】
とされていますが、この時に実際に業務ユーザが作成するツールとして使われたメジャーなツールがエクセルマクロ（vba）やノーツDBでした。
このEUCの流れで、IT部門が関わらない形で業務ユーザー自身が作成した「業務ツール」が肥大化した状態で大量に存在し、
- 業務ユーザーが自分の仕事に必要な機能（のみ）を作った仕様のため、周辺業務のユーザーには不十分
- 結果的に周辺業務のユーザーは自ら似たような機能のツールを作成する
ことになり、結果的に
- どこで誰が作成・管理しているのか解らないツールが増殖
- いつまで正常に動作するものか不明
- 似たような中途半端なツールが大量に作成され、人事異動や退職などを期に更にブラックボックス化する
- しかし、業務のある程度を依存してしまっているため、後から異動して来た人はそのツールを使うしかない
- 仕様が解らないので、業務が変わっても修正出来ない状況
- IT部門も手が付けられない
となっているのがExcelレガシー問題です。
RPA導入とExcelレガシー問題の関係
この様な過去のEUCブームで問題となったExcelレガシー問題ですが、RPA導入においても同様の問題をはらんでいる事は確かです。ここで、RPAと過去のExcelレガシー問題の似ている点、違う点を整理しておきます。
RPA導入と似ている点
- RPAの場合も業務ユーザー自身がシナリオ作成可能
- システム化し難い柔らかい業務を対象としている柔軟性
- 必ずしも大規模なサーバー型のシステム開発が必要ない
RPA導入と違う点
- プログラミングの必要がない
- 業務処理フローを可視化し易い
- RPAシナリオ全体の動作監視、管理が可能
- Excel内やノーツDb内に閉じた管理、自動化ではなくRPAはPCソフトの殆どを自動化の対象に出来る
Excelレガシー問題の本質
ExcelマクロやノーツDB自体が悪かったわけではありません。今現在もExcelマクロで作成したツールを使用している会社は多いと思いますし、個人的には、これらのツールは使い方を間違わなければ今でも結構良いツールではないかと思っています。問題の本質は別のところにあります。
システム化出来ない業務がある
「RPAの普及は基幹システムの基本設計のまずさにある」との意見を最近聞くようになりましたが、私はそもそも、「基幹システムに実装するのに向かない業務」をRPAが受け持てるため価値がある、と考えています。
仕事には次の２種類があります。
◆ 固まった仕事
固まった仕事とは、
- 過去に起きた事実を正確に記録していくような業務 ⇒ 会計仕訳を転記していく経理処理、製造記録、品質検査記録などの実績・記録業務
- 定型化が可能であまり考える余地はなく、意思決定するか、ルール通りに処理する業務
これらの仕事は業務の流れや必要な記録項目、自分が記入した後に処理する人、処理する内容などが決まっている業務ですので、項目を最初から明確に決定してシステム構築するリレーショナル・データベースを中心としたシステム構築に向いています。
◆ 柔らかい仕事
柔らかい仕事とは、
- 主に将来に向けて無限大の選択があり、定型化し難い業務
- 現在の状況による制約はあったとしても、決められたルールや形はなく、自由に創造する業務
この様な柔らかい業務は基幹システムとして、リレーショナル・データベースを中心に構成するようなシステム開発には向かず、あるとすれば様々な過去実績や環境情報などのデータを切り口を変えながら分析し、将来の方向性を考えるためのDWH（データウエアハウス）と言われようなシステムや統計解析、AI分析のシステムなどになります。
【 固まった仕事 】をする基幹システムの間に抜けている【 柔らかい仕事 】をRPAが埋める
Excelマクロ開発を統制出来なかったことが問題
過去のExcelレガシー問題を繰り返さない為にも、EUCの何が問題だったのかを考えると、結局は【統制出来なかった事】にあるのです。RPAの導入・展開ではその点さえ注意して進めれば低コストで大きな業務効率化効果を得られるのではないかと考えています。
具体的には、
- 属人化をゆるしてしまった ⇒ 作成したRPAシナリオのドキュメント化、引継ぎを確実に行う
- RPAそのものに関する人材・ナレッジ管理 ⇒ IT部門が主導して人材・ナレッジを管理する
- RPAの動作監視・保守運用 ⇒ RPAの場合は各シナリオの実行、保守管理が可能
- 導入・展開プロジェクト統制 ⇒ 企画部門がプロジェクト全体を統制し、効率化効果（ROI）を管理する
結局これら全てが業務ユーザー任せにしてしまい、統制出来なかった事が全ての原因であり、逆に言えば「当初からしっかりと計画的に、統制のとれた状態で進める」事で全ては回避できる問題だったのです。
EUCには利点も多い
業務部門が主体
IT部門が主導して大規模なシステム開発を行うと、プロジェクトを進めている内にどうしても「システム導入が目的化」してしまいます。
対して、業務部門がプロジェクトを主導すると、ビジネス効果、作業効率にしか興味はないため、低コストで本当に効果の高いシステムになる傾向があります。
少なくとも、システム開発のための開発はなくなるものと思われます。やはり、業務に直結したシステムは業務部門が主導して導入すべきだと思われます。
柔軟性
なぜ業務部門でのシステム開発（≒EUC）が出来なかったのでしょうか？ それは、システムが難し過ぎたためです。この点もRPAは解決できそうです。RPAのシナリオ作成にはプログラミングは不要で、ドラッグ＆ドロップで部品を貼り付けて処理フローを作る方法です。
ExcelマクロやノーツDBを作成するよりも更に簡単で、業務ユーザー自身でRPAシナリオ作成・運用が可能ですので、「業務ユーザーが現在困っている手作業を自動化できる」のです。
RPAを使いこなすことで、業務ユーザーは自由になる
現代の業務に求められる要素
スピード
Excelレガシー問題は十分回避できる点は既にお伝えしましたが、RPA導入で得られるのは自動化効果だけか、と言われると、そうではありません。実は現状業務の自動化、効率化以上の効果が得られます。それは、
RPAによって得られる効果で最も重要なのは【スピード】
なのです。
従来からIT部門主導で企画・導入してきたERPなどのシステム導入に何年も掛けていました。しかし、その様に何年もシステム開発を行っている余裕はなく、そうしている間にビジネス環境は急激に変化してしまいます。
現代のビジネスにおいて最も重要なのはスピードなのです。同じビジネス施策であれば１秒でも早く意思決定して実行に移す。進めてみて問題があれば、修正を加える。競争優位にたつにはこれしかありません。
100%論理で説明できることはビジネスの世界にはありません。競争がある以上、常に不確定要素がありますから、戦略の正しさを論理的に説明出来る割合はせいぜい２０％程度と言われています。
と言うことは、競合よりも早く仮設・検証のループを回して修正していけるかが競合優位にたつ必須条件となっています。
RPAで柔軟性を手に入れる
上記の「固まった仕事／柔らかい仕事」にも拘わりますが、柔軟性も重要なカギとなります。固まった仕事は、「過去に起きた事象を間違いなく、正しく記録」していく仕事です。
過去は変えられませんから、必要な業務ではありますが過去の仕事には然程付加価値はありません。有るのは、過去の見直し、反省にたって将来を計画する事です。
従って、柔らかい仕事は企画部門が主にExcelなどのツールを使って手作業で行っているのです。基幹システムとの連携や、データ整理をRPAで自動化・効率化しつつも、そのような業務の柔軟性を手に入れることが出来ます。
業務処理統制を合わせて考える
RPAを導入するメリットとしては、その他に業務品質を向上できる点が挙げられます。
- RPAは決められたルール通りに処理をするため、間違いがあるとすれば、ルールの間違いか漏れ
- 人が介在しないことで、故意にデータを改ざんしたり、持ち出したり出来なくする
- RPAは処理結果のログが残るめ、業務処理の証跡として役立つ
業務効率化以外のRPA導入のメリットについてはこちらで詳しくご紹介しています。
