今、RPA (Robotic Process Automation) が大きな注目を集めています。私の理解では、RPA 推進派は（私の立ち位置である）超高速開発と同じ問題意識を持っています。
- 基幹系ではカバーできない、現場独自の IT は山ほどある。
- これらの業務は「利用者は一部」「利用頻度は多くはない」「変化が早い」ため基幹系に取り込むことが難しい。開発コストをかけられない。
- しかし業務としては必要であり、間接コストの増大を招いている。
システム開発に関わるエンジニアは、このような現状をなんとかしたいと考えます。そこで二つの流派が登場しました。
| RPA | 超高速開発 | |
| 方針 | 現行システムは維持し、その操作を自動化する。 | 現行システムの再開発を行う。 |
| 特徴 | 現行システムに手を入れないので導入負荷が低い。 | 超高速開発なので変化の速さに対応できる。 |
| 自動化の対象 | 運用者の操作手順 | システム開発工程全般 |
いずれも「システム開発には時間もお金もかかる」という前提を問題とし、その解決をはかるものです。オフショア開発は根本的な解ではないと位置付け、自動化の仕組みを積極的に取り入れていますが、自動化の対象が異なります。
このように両者は目線が異なる手法なので併用可能です。しかし超高速開発より RPA の方がより「現実解」とみなされているように感じます。何が現実的かというと、システムの再開発は非常に困難だが、現行システムを維持したまま業務効率を上げられるという点です。
思い起こせば、過去にも同じような現象がありました。仮想化技術です。このときは現行システムに手を入れず、最新ハードゥエアに旧環境を再現することで延命できるというセールストークでした。
超高速開発の推進派は、システム開発工程そのものを見直すことで、再開発も現実的になりましたよ、というセールストークになります。特に現行システムの保守費が無視できないほど大きく、企業の体力を奪っていることを憂いており、ここに手を入れない限り競争力を高めることは難しいと考えています。つまりシステムの再開発は不可避という立場です。
しかし注目されるのは常に「再開発を避ける技術」です。私は RPA を羨んでいるわけでも、否定しているわけでもありません。少ない投資で大きな効果を得ることができることは重要で、RPA が大いに役立つところはあると思います。ただ、それが現行システムの温存につながってしまうことを懸念しています。
RPA 導入の果実をどう捉えるか
ここからは私の見解です。少なくない企業で、RPA によって解放された現場のスタッフを配置転換して営業部に異動する、という話があるようですが、実にもったいないと思います。
私ならこうします。RPA の導入効果の一つに、RPA 化された業務は何だったのか、という洗い出しが行われています。それにこれまで携わっていたスタッフは、その業務に習熟していました。彼らの知見、ノウハウを活かして、次は「現行システムの見直し」に着手するのです。
企業が「再開発を避けたい」理由の一つに、現場が日々、多忙で、再開発をするにもそもそもどうするべきか、という議論を行う時間がないという実態があります。その結果、例えば現行システムをそのまま Web 化するといった延命措置のためのシステム開発案件が生じてしまい、投資にみあう効果を得られないという嘆きにつながっています。
RPA の導入によって、ようやく「我が社の業務プロセスはどう進化させるべきか」を現場主導で議論できる環境を整えることができます。つまり次のようなストーリーです。
1. RPA導入で、現行業務を整理、可視化する。
2. 現行業務を自動化しつつ、次に「現行業務の進化版」を議論する。
3. 2のシステム化によって現行業務をアップデートする。
このストーリーは、1. で導入したRPA対象業務そのものをなくすことを視野に入れます。RPA は現行業務ありきですが、システム化とは現行業務そのものの見直しだからです。その見直しでは、次の視点を積極的に取り入れます。
a. 伝票入力の業務をなくしていく。AIベースのOCR活用、顧客がスマホで入力したデータの活用、外部クラウドシステムとのAPI連携といった最新技術を駆使して、入力工程というプロセス自体を見直す。
b. ヒトの判断ルールを BRMS に移譲していく。複雑なルールを可視化する。
c. 経営陣が欲しいアウトプット作成に BI ツールや ETL ツールを活用する。
そして、これらの開発基盤には超高速開発の手法を採用します。これは開発後の保守コストを低減化させる効果があるためです。外部SIerによる丸投げではなく、自社が積極的に関わり、イニシアティブをとるように進めていきましょう。自社の CIO を中心としたチームで業務全体を俯瞰し、業務データの構造と流れを把握できるようになることを目指すのです。そこをゴールに位置付けることが本命です。
RPAを「システムの再構築から逃げる」ためではなく、「システムの再構築に向き合うために活用する」という視点で捉えることで、両者は強固な関係になりえます。現行業務の自動化(RPA)と、業務の仕組みそのものの迅速なアップデート化(超高速開発)が、これからのエンタープライズシステムの両輪になっていくと面白いと思います。
