RPA実践論。第1回～RPAは“魔法の自動化ツール”ではなく、現場業務の翻訳作業である～
RPAという言葉を聞くと、「人がやっている作業をロボットに置き換えるもの」というイメージを持たれがちです。
もちろん、それは間違いではありません。
ただ、実際にRPAを構築している立場から見ると、RPAの本質はもう少し地味です。
RPAとは、現場の人が無意識に判断している作業を、一つひとつ分解し、ロボットでも迷わず実行できる形に翻訳する仕事です。
そして、この「翻訳」が思った以上に難しいのです。私自身、RPAは当社で提供しているため、お客様へ導入・実装・保守をしております。
その体験談からお話しようかと少しお話しようと思います。
RPAで一番難しいのは、ツール操作ではない
RPAツールの操作自体は、ある程度学べば使えるようになります。
画面をクリックする、文字を入力する、ファイルを開く、データを転記する。
こうした基本操作は、手順を覚えれば少しずつ組み立てられるようになります。
しかし、RPAで本当に難しいのは、ツールの操作そのものではありません。
難しいのは、業務の中にある「人間の判断」を見つけることです。
たとえば、請求書を処理する業務ひとつでも、現場では次のような判断が自然に行われています。
「この取引先は例外」
「この金額なら確認が必要」
「この欄が空白なら前回のデータを見る」
「たまにファイル名が違う」
「この場合は先に担当者へ確認する」
人間は、こうした曖昧さを経験や感覚で吸収しながら作業しています。
しかし、RPAは曖昧さに強くありません。
指示された通りには動きますが、空気を読んで判断することはできません。
だからこそ、RPAを作る前には、業務を丁寧に聞き出し、例外を洗い出し、処理手順に落とし込む必要があります。
RPA構築とは、単に操作を自動化することではなく、業務の中に隠れている判断を見つける作業でもあります。
現場の「いつも通り」は、ロボットには伝わらない
RPA構築のヒアリングでよくあるのが、
「いつも通りやれば大丈夫です」
という言葉です。
現場の方にとっては、本当にいつも通りなのだと思います。
毎日やっている作業であり、特別なことをしている感覚はありません。
しかし、その「いつも通り」の中には、実は多くの判断が含まれています。
どのメールを対象にするのか。
添付ファイルが複数ある場合はどうするのか。
同じファイル名があったらどうするのか。
エラーが出たら誰に連絡するのか。
処理済みかどうかをどう判断するのか。
データが不足している場合は、止めるのか、飛ばすのか、確認するのか。
人間なら、状況を見て自然に対応できます。
しかし、RPAは空気を読みません。
「たぶんこれだろう」
「前回と同じでいいだろう」
「この場合は確認したほうがよさそうだ」
こうした判断は、ロボットにはそのまま伝わりません。
ルールとして明確にしなければ、RPAは迷うか、止まるか、間違った処理をしてしまいます。
そのため、RPAを作る作業は、現場の「なんとなく」を「明文化」する作業でもあります。
普段は言葉にしない判断を一つひとつ確認し、
「この場合はこうする」
「この条件なら処理を止める」
「ここまでは自動化し、ここからは人が確認する」
という形に整理していきます。
この作業こそが、RPA構築の大事な部分です。
RPAは作って終わりではなく、育てるもの
RPAは、一度作れば永遠に動き続けるものではありません。
ログイン画面が変わる。
ボタンの位置が変わる。
Excelの列が増える。
取引先のフォーマットが変わる。
担当者の運用が変わる。
システム側の仕様が少し変わる。
こうした小さな変化で、RPAは止まることがあります。
人間であれば、画面が少し変わっても「ああ、ここを押せばいいのか」と判断できます。
Excelの列が一つ増えていても、見た目である程度対応できます。
しかし、RPAは決められた条件をもとに動いています。
その条件から外れると、処理できなくなることがあります。
だから、RPAには保守が必要です。
むしろ、作った後にどう運用するかが重要です。
RPAを業務に定着させるには、次のような視点が欠かせません。
エラーが起きたときに誰が確認するのか。
ログをどこまで残すのか。
手動対応に戻す基準は何か。
業務変更時に誰がRPA担当者へ連絡するのか。
担当者が変わっても運用できる資料があるか。
止まったときに、現場が状況を把握できるようになっているか。
RPAは「完成品」ではありません。
現場と一緒に使いながら、少しずつ育てていく仕組みです。
実際に作ってみて感じるRPAの価値
ここまで聞くと、RPAは面倒に感じるかもしれません。
実際、簡単ではありません。
画面が変われば止まります。
Excelのフォーマットが変われば修正が必要になります。
想定外のデータが来れば、例外処理を追加しなければなりません。
作ったものの、現場で使われなければ意味がありません。
それでも、きちんと業務にハマったときの効果は大きいです。
毎日10分の作業でも、月にすれば数時間になります。
複数人が関わる作業であれば、削減効果はさらに大きくなります。
そして、RPAの価値は単なる時間削減だけではありません。
作業ミスが減る。
処理のタイミングが安定する。
業務手順が見える化される。
属人化していた作業を整理できる。
人が判断すべき仕事に時間を使える。
RPAを作る過程で、業務そのものの改善点が見えてくることもあります。
「この確認作業は本当に必要なのか」
「このExcelはなぜ毎回手で直しているのか」
「この作業は担当者しか分からない状態になっていないか」
「そもそも、この手順を見直せばもっと簡単になるのではないか」
RPAは、単に人の作業をロボットに置き換えるだけではありません。
業務を分解し、整理し、改善するきっかけにもなります。
RPA実践で大事にしていること
私がRPAを構築するときに大事にしているのは、「とにかく自動化すること」ではありません。
大事なのは、現場にとって本当に使える形にすることです。
そのためには、次のような考え方が必要です。
小さく作る。
例外を想定する。
止まったときの対応を決める。
現場の人が理解できる説明を残す。
自動化しない部分も判断する。
すべてを自動化しようとすると、かえって複雑になります。
例外処理が増えすぎて、保守が大変になることもあります。
人が判断したほうが早い部分は、人に残す。
ロボットが得意な繰り返し作業は、ロボットに任せる。
この切り分けが、RPA実践ではとても重要です。
RPAは、人の仕事をすべて奪うものではありません。
人がやらなくてもよい作業を減らし、人が本来考えるべき仕事に時間を使えるようにするための仕組みです。
RPAは、現場で動かしながら育てていくもの
RPAは、華やかな技術というより、現場業務に寄り添う地道な改善活動です。
作ってみると、思ったより止まります。
思ったより例外があります。
思ったより人間の判断が多いことに気づきます。
でも、その過程で業務が整理され、無駄が見え、人が本来やるべき仕事に集中できる環境が少しずつ作られていきます。
このブログでは、RPAを実際に構築している立場から、成功事例だけでなく、つまずいたこと、工夫したこと、現場で感じたことも含めて書いていきたいと思います。
RPAは、導入して終わりではありません。現場で動かしながら、育てていくものです。
それが、私の考える「RPA実践論」です。
次回は、「RPA化しやすい業務・しにくい業務」について書いてみたいと思います。
どの業務でも自動化できるわけではなく、RPAに向いている業務、向いていない業務があります。
実際の現場で感じた判断基準をもとに、整理していきます。
当社ではRPAの提案から保守まで承っております。ぜひ、お気軽にご相談ください。（T.S）
コメント
まだコメントはありません。