RPA SUMMIT 2017 in Osaka
私は今、ご紹介いただき、RPA SUMMIT 2017 in Osaka に参加しました。この記事では、有償のセッションAルームの各講演を拝聴した上で、それらを元に各講演に関わらずレポートしてみようと思います。
なお、基調講演については別記事に書きました。
RPA 驚異の威力
まず、どの講演でも強調されていたのが、RPA の導入容易性とそれに対する効果です。要するに費用対効果がよいということです。
その効果が広まり、多くの問い合わせと事例が急増中であることを4月から6月の3ヶ月と、その後の7月から9月の3ヶ月を比較して解説がありました。
7月〜9月までの期間にて:
・導入に向けた問い合わせ数: 1,300件以上
・導入実績件数: 150社以上
また、金融での RPA 導入が注目を増した要因として認知されているが、今では業種に問わず注目されているというデータも示されました。
主な RPA の問い合わせ（業種別）:
・メーカー系: 60%以上主な RPA の導入企業（業種別）:
・メーカー系: 40%以上
・金融: 15%以上
・サービス業: 10%以上
また規模でも大規模企業からの導入から、徐々に中規模、小規模な企業での問い合わせ件数が増加傾向であることも示されました。
主な RPA の問い合わせ（会社規模別）:
・1,000人以上の規模: 40%
・300 〜 1,000人規模: 27%
・100 〜 300人規模: 20%
要するに大きな規模の企業には認知が行き渡りつつあり、導入も増えていること、その余波が中小規模の企業にもきていることが見えていきます。
そして驚くべきは、その成果です。
RPA の効果ついて:
・96% の導入企業で 50% 以上の実務工数の削減RPA 導入の期間ついて:
・4週間以内で導入: 77%
早いところでは、2週間以内に導入もあるとのことで、導入と効果がでるまでの期間が短いことも特徴のようです。
また、バックオフィスでの需要が高いと見られる RPA ですが、営業事務作業での導入が増えているとのことでした。
実務の100%の自動化を求めない
RPA に期待するのは、業務の自動化ですので、業務自体を100%自動化しないと意味がないのではという議論があります。ただし、多くの講演では、100%の自動化を追求しておらず、業務のうち効果がでそうな業務の一部を自動化する形で成果を得ているケースが多いと感じました。
業務のうちの85%が自動化によって削減されれば、複数人でこなしていたことが一人でこなせる可能性がある
RPA は早期に着手できればできるほど効果を得る機会を秘めている
という言及があったように、大きく始めることを考えるより、できるところで導入して効果を得てから考える方が得策のようです。
RPA は業務の見直しの機会を作るのが本質
RPA によって人を削減するのが目的ではなく、また上述のように100%の自動化を求めるのではないとすると何が本質なのかが問われます。講演では、しっかりとその辺りについても言及されていました。
RPA によって業務を自動化していてわかることは、従来の業務に如何にムダがあることだ
人間がすべてやる前提で業務プロセスや成果物が成立しているので、ロボットにやってもらうことでプロセス自体の見直しに気づくことができる。
業務をロボットにやってもらうことで、従来の業務プロセスの問題が顕在化されることを意味していて、RPA による効率化は直接的なメリットではあるが、それ以上に、業務の見直しを推進できることが本質であると多くの講演者の気づきであり、主張であると読み取れました。
ムダな業務をロボットにやらせるだけなら結局はムダなんだ
RPA の良さは、導入の容易さであり、容易に導入できることで、従来業務のアラが見えてくるわけです。それをそのままヨシとするのではなく、業務のあるべき姿を考えていくことこそが本質であり、RPAの効果でもあり、未来でもあるということですね。
RPA の導入がきっかけに人が成長してきている
ロボットにできることはロボットにやってもらい、業務を見直し、人だからこそできることに注力できるようにすることが RPA の本懐であるということですね。
ユーザー部門主導 vs. 企画 (IT) 部門主導
RPA 導入ケースでは、業務を行なっているユーザー部門が主導するケースとシステムを見ている企画、IT部門が主導するケースと大きく分かれているようです。
企画、IT部門が主導する場合は、より広い範囲で利用できるロボットの作成や統制が可能というメリットある反面、実業務への即応性に欠けるところがあるようです。
ユーザー部門が主導した場合は、野良ロボット化の懸念、業務をこなしながらのロボット作成の時間の捻出が課題となります。
どちらがよいというよりは、企業文化や重要度に応じたやり方で行い、それをふりかえり、見直していくのがよいようです。
例えば、最初はユーザー部門でやんちゃにロボット化していき、それをあるタイミングで、IT部門に委ねるという形です。もちろん、その道筋をしっかり握っておくことが大切になります。とっちらかった後で任されてもマネージできるわけではないためです。
RPA はユーザー部門で導入しやすい。費用対効果ではなく、業務へのモチベーションで推進できるからだ
マネージメントは、メンバーがロボット開発に使える時間を捻出してあげられることが大切。初期に携わった人を『マイスター』として顕在化してモチベーションをあげてもらったりすると良い。
RPA ツールの現状
講演を聞いていると、Windows 上で稼働するツールが多いように感じました。
RPA ツールは、大きく分けると、デスクトップで自動化を行う（操作のキャプチャとリプレイによる自動化）ものが多く、それ以外には、サーバー上で稼働するスクリプトタイプとなるようです。
ただ、RPA ツールは、多くのクライアントOSに対応する必要はなく、自動化したい業務が遂行できればよいので、普段使っているプラットフォームだけに対応していればよいというメリットがあります。
RPA ツールといっても大きく分けると2つのタイプにわける場合もあるようです
- RPA: Robotic Process Automation
- RDA: Robotic Desktop Automation
講演を聞いているとその多くが RDP なのが現状なのかと感じました。
また、前述のように業務の 100% を自動化するわけではないことから、切り出せる業務の一部を自動化していくケースが多いようです。例えば、
- データを吸い上げる
- SAP に登録する
- メールに添付して送信する
などを各ロボット化するということです。
すると、必然的にロボットの数が増えていくと統制をどうするかが課題になります。それぞれをいちいち人がキックしていくのもよいのですが、人でがいることと、各ロボットの作業終了を監視・管理しなければならなくなり、まだまだ人が人間らしい仕事に従事できなくなるからです。
そこで、管理統制するロボットを設けることが増えてくるそうです。現にツールもそのように進化しているとのことです。管理統制するロボットとシナリオ実行できるロボットに分けることで、人は、前者だけを見て指示をだせばよいようにできるのが理想となりそうです。そして、BPMと前者を連動させるとより業務プロセスを遂行するロボットらしくなるようです。
RPA ツールの課題、そして使いこなすべき人の課題がまだあると感じましたが、本質が業務の見直しにあると捉えるとその可能性は大きのではないかと感じた RPA SUMMIT でした。
