RPAを入れて止まる会社の共通点

RPA——画面を人の代わりに操作して自動化する仕組みは、はまると強いです。既存システムに手を入れずに済むので、稟議も通りやすい。

そのぶん、数年経って止まっている現場も多いです。止まり方には共通点があります。

共通点1：壊れる前提になっていない

RPAは、画面の見た目に依存します。だから、こういうときに止まります。

• 業務システムがバージョンアップして、ボタンの位置が変わった
• ブラウザが自動更新された
• 画面に「お知らせ」のポップアップが1つ増えた
• 月末だけ表示される確認ダイアログがあった

これは不具合ではなく、仕様どおりの挙動です。RPAは画面を見ているので、画面が変われば止まります。

なので、導入時に決めるべきはこれです。

• 止まったとき、誰に通知が届くか（管理者ではなく、その業務の担当者本人に）
• 止まっているあいだ、手作業に戻せるか。その手順が1ページあるか
• 月に何回まで止まったら、作り直しを検討するか

3つめは特に効きます。「たまに止まるので毎回手で直している」状態が1年続くと、自動化する前より総工数が増えていることがあります。基準を決めておかないと、その判断は誰もしません。

共通点2：作った人しか直せない

RPAの開発ツールは「誰でも作れる」と紹介されますが、誰でも直せるとは限りません。

止まる現場の共通点は、

• 変数名が 変数1 変数2 のまま
• なぜその待ち時間を入れたのかが書かれていない
• エラー時の分岐が無い（あるいは、握りつぶしている）
• 同じ処理が複数のロボットにコピーで散らばっている

これを防ぐのは、技術ではなくルールです。

• 1ステップ1行のコメントを残す（何をしているかではなく、なぜそうしたか）
• 変数は日本語にする（対象年月 未処理件数）
• 待ち時間を固定秒で置かない。「この要素が出るまで待つ」で書く（固定秒は、遅い日に必ず失敗します）
• ロボットの一覧を1枚作る（名前・何をするか・作った人・今の担当・止まると困る度）

最後の一覧は、内製化が続かない会社と、続く会社の違い にも書きましたが、2年目に効きます。

共通点3：RPAでやらなくていいものをRPAでやっている

これがいちばん大きいかもしれません。

RPAは最後の手段です。他に手がないから画面を操作しているのであって、他に手があるならそちらが確実です。

判断の順番はこうです。

1. その作業自体をやめられないか（誰も見ていない資料を作っていないか）
2. 元のシステムに機能はないか（CSV出力、スケジュール実行、通知設定。意外と付いています）
3. ファイルやAPIでやりとりできないか（CSVを1枚挟めば、画面操作は不要になります）
4. それでも駄目なら、RPA

現場で見ていて多いのは、2番を確認せずに3番を飛ばしてRPAにしているケースです。「そのシステム、CSV出せますか」と聞いたら出せた、ということが普通にあります。

画面操作は、動いているあいだは完璧に見えて、壊れたときのコストが高いという特性があります。他の方法があるなら、そちらのほうが長く持ちます。

それでもRPAが向いている場面

否定ばかりでは片手落ちなので、向いている場面も書きます。

• CSVもAPIも出せない古いシステムが相手（これが本命の用途です）
• 複数のシステムをまたいで、人が転記しているだけの作業
• 期間限定の作業（移行期間だけ、繁忙期だけ）。壊れる前に役目が終わる
• 業務を変えられない事情がある（相手先の指定様式など）

このうち3つめは見落とされがちです。「3か月だけ動けばいい」なら、雑に作ってよいんです。長く使う前提で丁寧に作ると、割に合いません。

費用の話を少しだけ

Windows に付いてくる Power Automate for desktop は、自分のPCで、自分が見ている前で動かすぶんには追加費用なしで試せます。人がいないところで自動実行するところから有料です（Power Automate、追加費用なしでどこまでできるか）。

なので順番としては、

1. まず手元で動かして、本当に効果があるか確かめる
2. 効くと分かってから、無人実行の予算を取りにいく

先に予算を取ってから効果を確かめると、効果が薄かったときに引き返せなくなります。

まとめ

• RPAは壊れる前提で設計する。通知先・手作業に戻す手順・作り直しの基準を先に決める
• 成功したときも記録を残す。止まったことに気づけないのがいちばん怖い
• 変数は日本語、待ちは固定秒にしない、ロボット一覧を1枚作る
• 使う前に、やめられないか／元のシステムの機能／CSVやAPIの3つを潰す
• 向いているのはCSVもAPIも出せない古いシステムと期間限定の作業
• まず手元で無料の範囲で試して、効果を確かめてから予算を取る

「これRPAでやるべきか」の切り分けからでも構いません。元のシステムの仕様が分かれば、その場でだいたい判断できます。