RPAとは?“なんでも自動化”じゃない|向く業務の見極め方

RPA(Robotic Process Automation/ロボットによる業務自動化)と聞くと、「入れれば人手不足がまるごと解決する魔法のツール」というイメージを持っていませんか。セミナーで華やかな事例を見て、社内の業務リストを片っ端から自動化しようとした結果、数ヶ月後には誰も触らない“動かないロボット”が並ぶ——そんな話を、物流・製造の現場から見てきました。
物流センターと工場の管理システムを、SCM構築の立場から見てきた私に言わせると、RPAは「なんでも自動化」の道具ではありません。
RPAとは?—まず1分で
RPAとは、人がパソコン上で行う定型作業(データ入力、他システムへの転記、決まった条件でのファイル振り分けなど)を、ソフトウェアのロボットに操作手順として覚えさせ、代行させる仕組みです。プログラミングを新たに書くのではなく、「画面のここをクリックして、この値をコピーして、あちらに貼り付ける」という人の操作手順をなぞる点が、基幹システムの改修とは違います。だからこそ導入は速いのですが、その速さが「なんでも自動化できる」という誤解も生みます。
“なんでも自動化できる”という誤解
RPAの本質は、決まった手順を、決まった通りに、大量に繰り返すことにあります。手順が毎回同じで、判断が入らない仕事ほど強いです。逆に言えば、判断や例外対応が入る仕事は、ロボットに任せた瞬間に壊れます。
向いている業務
- 大量・定型の転記:受注データを基幹システムから会計システムへコピーする、請求書の金額を台帳に転記する、など。ルールが明確で、件数が多いほど効果が大きくなります。
- ルールが数値で書ける照合:発注書と納品書の品目・数量・金額を突き合わせる作業。「一致しているか、いないか」を機械的に判定できます。
- 決まった条件での振り分け:メールの件名や添付ファイルの種類で、保存フォルダを振り分ける。条件がIF文で書き切れる仕事です。
向かない業務
- 都度の判断が要る仕事:取引先ごとに与信をその場で判断する、クレーム内容を読んで対応方針を決める、など。ルール化しきれない“読み・判断”が入ります。
- 手書き・非定型の書類:手書き伝票やレイアウトが毎回違う書類。OCR(文字認識)と組み合わせても、精度が実務に耐えないことが多いです。
- 頻繁に画面が変わる仕事:対象システムの画面デザインが更新されると、ロボットの手順が追いつかず、修正コストの方が高くつきます。
私が現場で見てきた失敗の多くは、この見極めを飛ばして「とにかく自動化」から入ったケースでした。判断の要る仕事を無理にルール化しようとして、例外が起きるたびに担当者がロボットを止めて手作業に戻ります。結局、ロボットの面倒を見る仕事が増えただけ、ということが起きます。
見極めの軸 | RPAが効く | RPAが壊れる |
|---|---|---|
手順 | 毎回まったく同じ | 状況によって変わる |
判断 | 条件をIF文で書き切れる | 読んで意味を汲む必要がある |
入力データ | フォーマットが固定 | 手書き・レイアウトが毎回違う |
対象システムの画面 | ほぼ変わらない | 頻繁に更新される |
件数 | 多いほど効果大 | 少なく単発 |
一段深く:目的から工程を設計しなおす
ここが本題です。RPAを入れる前に本当にやるべきことは、「どの作業を自動化するか」を決めることではなく、その工程が、そもそも今の形である必要があるかを疑うことだと、私は考えています。
たとえば、A部門の入力ミスをB部門が目視でチェックし、C部門がRPAで転記する、という三段構えの工程があったとします。ここでRPAを入れるべきは転記の部分ではなく、そもそも入力の時点でミスが起きない仕組みにできれば、目視チェックも転記も丸ごと不要になるかもしれません。今ある工程を前提にロボットを当てはめるのではなく、目的(正確なデータを、必要な部署に、必要な形で届ける)から工程を設計しなおします。これが、物流・製造の現場改善でも、RPA導入でも変わらない順番です。
だから私は、RPA導入の相談を受けたとき、まず自動化の候補ではなく業務の棚卸しから始めます。誰が、何を、どんな頻度で、どんな判断を挟みながらやっているか。一枚の紙に書き出すと、「そもそもこの承認は要らないのでは」「この転記は、入力先を一本化すれば消える」という発見が、自動化の検討より先に出てきます。RPAは、その棚卸しの先に残った“純粋な定型作業”に当てる道具です。
- 対象になりそうな業務を、担当者・頻度・かかる時間ごとに洗い出します。
- その業務が「毎回まったく同じ手順か」を確かめます。人によってやり方が違うなら、まずやり方を揃えます。
- 判断が入る箇所を見つけ、条件として書き切れるかどうかを見極めます。書き切れないなら、そこはRPAの対象から外します。
- 書き切れない判断が多い場合は、先に入力や承認のルールそのものを変えられないか検討します。
- それでも残った“純粋な定型作業”だけを、最初のRPA候補にします。
受発注のやり取りでも同じことが起きます。取引先からのFAXやメールの注文書を、担当者が読み取って基幹システムに手入力する——ここだけを見てRPAを当てても、読み取りの精度が上がらなければ結局は人が確認し続けることになります。それより先に「発注はWebフォームに統一できないか」を考えたほうが、転記そのものが要らなくなることがあります。RPAは工程の“最後の仕上げ”であって、“最初の一手”ではありません。
よくある質問
Q. RPAとExcelマクロは何が違う?
A. マクロは主にExcel内の処理に閉じますが、RPAは複数の異なるシステム・アプリケーションをまたいで、人の操作そのものを代行できる点が違います。基幹システムと会計ソフトなど、別々のアプリを行き来する作業ほどRPAの効果が出やすくなります。
Q. 中小企業でもRPAは導入できる?
A. できます。むしろ人手が限られる中小企業ほど、定型作業からの解放は効きます。ただし最初から大規模導入をせず、棚卸しで見つけた「一番件数が多く、ルールが明確な一業務」から小さく始めるのが、失敗しない順番です。
まとめ
RPAは「なんでも自動化」できる魔法の道具ではなく、決まった手順を大量に繰り返す仕事に効く道具です。向く業務と向かない業務を見極め、その前に工程そのものを目的から設計しなおします。この二段構えが、遠回りに見えて一番の近道になります。まずは自社の業務を棚卸しすることから始めてみてください。
業務の棚卸しやRPA導入の見極めについては、業務改善・BPRのご支援やお問い合わせからお気軽にご相談ください。
あわせて読みたい
この記事を書いた人
小林悠真(こばやし・ゆうま)/LF&L株式会社 代表取締役。九州大学で音響設計・音楽マネジメントを学びデザイン思考を培った後、ヤマトシステム開発・バンテックで物流/生産管理、ラクスル等のITスタートアップで事業開発・SCM構築を経験。製造業・物流業のDXコンサルタントとして、現場の1歩から経営システムまでの全体最適を支援する。テューバ奏者・LFコンサート代表理事も兼務。