RPAはあらゆる業務を自動化出来るという幻想が広がり、RPAに向かない業務までRPAに無理やり実装しようとするのを見かけるようになってきました。やはり、全ての道具（ITツールも含め）には目的・用途があります。頑張ってロボットをつくれば出来なくはないのですが、「出来る」と「向く」は違うことを認識すべきです。
全ての道具には用途（向き不向き）がある
言うまでもありませんが、ハサミは何かを切るための道具ですし、缶切りは缶詰を開ける為の道具です。ハサミでも頑張って缶詰を開けることが出来るかも知れませんが、基本的にはその様な使い方には向かないのです。
震災の時など極限状態になれば人は頑張るのかも知れませんが、平常時であればその前に向いた道具を探すのが当然です。
向いていない道具を無理に使えば、その道具も痛めるかもしれませんし、怪我したり缶詰が食べられなくなってしまうリスクもあります。
RPAに判断業務は向かない
同様にITツールにも向き不向きが当然あります。その意味で、PC上の繰返し雑務を人に代わって行う目的で開発されたRPAに複雑な業務ルールに基づく判断は向きません。
RPAが業務ルールの判断に向かない理由
RPAの判断ロジック実装は、判断分岐用のノード（部品）を入れて条件（AND/OR/NOT）分岐を順番（多階層）に判断していきます。
これはプログラムの書き方と同じようなイメージです。どの程度複雑な分岐（判断）が入るかにもよりますが、個々の分岐判断のひし形（六角形）毎に下のような分岐条件を設定していく必要があります。
この分岐条件の設定画面は１つの分岐条件ですので、これが複数・多段階に条件判断されていくことになります。全体の条件がどの様に設定されたのか極めて見通しが悪いと言わざるをえませんし、これでは次のようなロジックミスが起きても何の不思議もないと思います。
- 作成した業務ルール条件のどのパターンにもあてはまらない条件がある
- 複数の結果に合致してしまう条件の組合せがある
プログラムを記述するのであればこれで良いのです。プログラマーは記述中のプログラムコードの中に深く入り込み、ロジックを構成していき完成すれば変更はまずありません。
しかし、ここで記述すべきはビジネス上の条件なのですから、ちょっとした取引の変化や価格変更、プロモーション適用条件の変更など日常茶飯事なのです。もし、この複雑な判断ロジックをRPAで全て実装していれば、上の様な条件ウインドウを１つづつ開きながら条件を確認し、変更していくことになってしまいます。
判断ロジックは専用ツールにまとめて記述して管理する
やはり、条件ロジック全体が見渡せる状態で、条件を確認しメンテナンス出来るように実装するほうが良いと思います。
向かない使い方をした結果起きること
上記の様にRPAには判断業務は向かないわけですが、頑張ってRPAに複雑な判断をやらせることも当然可能です。しかし、その結果は恐らく次のような結果となるのが見えています。
判断ロジックが判り難くなる
ビジビリティーが低い、等といいますが要は判断ロジック全体が見渡せる状態ではないため、非常に判り難いものとなるでしょう。
メンテナンス不能
結果的に、業務が変更になってRPAに実装したこれらの複雑なビジネスロジックを修正する必要に迫られても、全体がどうなっているのか解らないわけですから修正しようがありません。
ロジックミスの増加
ビジネスロジックを変更すべき時にタイムリーに修正出来ないのですから、ロジックミス（抜け漏れ／重複）などが頻繁に発生し、業務に支障をきたすようになるかも知れません。
高コスト構造
そこに書かれているのが業務判断にも関わらず、自社ではメンテナンス出来なくなり仕方なくベンダーに依存せざるを得ない状況になっていきます。そして、その様な状況が続くことをベンダーロックインと言われます。
Excelレガシー問題の再現
もしくは、過去のEUCブームの時の様なExcelレガシー問題に繋がるのかも知れません。
