RPAと基幹システム変更が衝突する場面

はじめに：製造業のデジタル化、そのジレンマ

製造業の現場では、近年デジタル化の波が急速に押し寄せています。
工場の自動化やIoTの導入、そしてビジネスプロセスの効率化を目的としたRPA（ロボティック・プロセス・オートメーション）は、今や現場改善の王道です。
一方、老舗のメーカーほど、長年使い続けてきた基幹システムを刷新することに大きな壁があります。
この守備範囲が重なったとき、「RPAと基幹システム変更が衝突する場面」が現場を悩ませます。

本記事では、調達・購買、生産管理、品質管理など、製造業の現場で私が長年目にしたリアルな課題や実例、そして現場がよりよく「新旧」を融合するための視点、業界動向までを、分かりやすく解説します。

RPAとは何か？現場目線での本質的な意味

RPAとは、定型的な業務をソフトウェアロボットが自動で実行する仕組みです。
「ロボット」というと大げさに感じるかもしれませんが、事務作業や手作業でのデータ入力、帳票の転記や照合など、人がPC上で繰り返している作業を代わりに担ってくれるものです。

製造業がRPAを求める理由

製造業の世界、とりわけ昭和から続く老舗企業では、ペーパーワークや手作業が未だに支配的です。
その背景には「前例主義」や「多層的な承認フロー」「紙帳票文化」「Excel地獄」など、変わりにくい企業風土があります。

このような状況下、若い人材は敬遠しがちになり、熟練者の定年退職は進み、現場では業務継続性・品質のバラツキ・属人化といった危機感が高まります。
そんな時に「とりあえず今の仕事のやり方はそのままで、面倒な入力や照合だけ自動化できるRPA」は、一気に救世主として各現場に導入され始めました。
現場の声をそのまま形にできる柔軟性も大きな魅力です。

基幹システム刷新の波と「昭和の壁」

巨大なエコシステム、動かせない現実

一方で、製造業の多くは1980年代〜2000年代初頭に構築した独自ERP（統合基幹システム）や、生産管理、調達管理などの社内システムを今なお使い続けています。

長年改修を重ね、ベンダーも入れ替わりながら、基幹システムは巨大化・複雑化し、「このシステムが止まる＝会社が止まる」という重大な責任を持つようになりました。
過去のレガシー資産の上に立つ基幹システムは、その両立で大きなジレンマを抱えています。
「変えたくても変えられない」現実。
「リプレースは想定外のコスト・リスク・ダウンタイムと直結する」という心理的バリアです。

「昭和の知見」が現代にも色濃く残る理由

なぜ、これほどまで変化を拒む空気が醸成されたのでしょうか？
理由は明快です。
製造業の成長期は、「一度作れば長期間安定して使い続けられる」設備と仕組みが最優先されたからです。
また、日本人らしい「失敗できない文化」「丁寧で慎重な品質管理」も、変化に対する拒絶感を生み出し続けてきました。

高度成長期から続く「一生このまま」「今のやり方を守ることが最優先」という価値観と、急速に加速するデジタル化の波が、真正面からぶつかっています。

RPAと基幹システム変更はなぜ衝突するのか？

変わらないことを前提に作るRPA、変化すれば崩れる自動化

RPAは「現状の業務フローをそのまま自動化できる」と言われます。
しかし、業務フローやシステム画面の大幅な変更があると、前提自体が崩壊します。

基幹システムを刷新すると、画面構成やデータベース情報、操作の流れが根本的に変わることが珍しくありません。
現場で作り込まれた「RPAシナリオ（ロボットのやる手順）」は、基幹システム変更で「使えなくなる」「全部作り直し」になることが多いのです。

「効率化」のために導入したRPAが、「システム刷新」という抜本的変化に対応できず、工数や混乱を生む。
このパラドックスに多くの現場が直面しています。

現場主導かIT・経営主導か、バトルが現場で勃発

RPAの開発・運用を現場（業務部門）が率先して「勝手に作る」ケースが増えました。
一方、基幹システム刷新プロジェクトは、IT部門や経営主導、外部コンサル主導で進みがちです。

現場がRPAで柔軟かつ属人的に業務を効率化する裏で、IT部門は「安全性」「標準化」「ガバナンス」を重視し、大規模プロジェクトを進めます。
このギャップが、部署間の摩擦、不信・不満、場合によっては業務停滞までもたらします。

実際に起きた衝突事例

生産計画入力の自動化が一夜でパーに

私が以前いた工場では、生産計画情報を専用システムへ入力する作業が非常に煩雑でした。
現場担当者がRPAを用いて、エクセル情報を自動で転記する仕組みを約1年かけて作り込みました。
結果、1日10人分の作業が2人に減り、RPAバンザイと多くの現場が喜びました。

しかし、経営方針で「システム刷新」が決まり、生産管理系の基幹システムの切替が実施されました。
新システムへの移行後、画面構成・入力項目・操作手順が根本的に変わり、RPAは完全に機能しなくなりました。
ロボット再構築には、外部エンジニアによる多額の再開発費と時間が必要となりました。

「現場が便利にした仕組み」は、「基幹システム刷新一発」で儚く消えました。
そして「今度は現場の声ももっと聴いてほしい」という声と、「場当たり的な自動化では困る」という経営・IT部門の温度差が、現場のモチベーションを下げるきっかけにもなりました。

購買部門でのRPA最適化競争、その結末

ある購買部門では、サプライヤーごとに異なる発注・納品管理の煩雑さから、RPAで入力～承認処理を大幅自動化しました。
サプライヤーにも「データフォーマットを合わせてください」と協力を促し、見事に「RPA前提の業務モデル」へと進化しました。

しかし、全社的な基幹システム見直しの一環で、「グループ全社統一基幹システム」(グローバルERP)の導入が決定。
従来の「サプライヤーごとに合わせたExcel台帳」から「全社統一のWebポータル」方式へ強制的に移行され、RPAありきの業務最適化は根こそぎやり直しへ。

サプライヤー側も「これまでの苦労は何だったのか？」と困惑し、購買部門から現場への信頼感低下、テクノロジー導入へのアンチ感情も少なからず生まれました。

どうすれば真のデジタルトランスフォーメーションに繋がるのか？

表面的な自動化にとどまらず、本質的なプロセス改革を

RPAは、確かに短期的な業務効率化や工数削減に劇的な効果をもたらします。
ただし、「今のやり方を前提とした一時しのぎ」になりやすいのも事実です。
現場の課題解決は、部分最適の繰り返しだけでは限界があります。

本当に必要なのは「どの業務プロセスが残すべき価値なのか、どこは廃止・整理・標準化すべきか」を、現場・サプライヤー・経営層がひとつのテーブルで徹底的に議論することです。

RPAと基幹システム刷新を連携させる工夫

RPAと基幹システム変更は、単なる天秤ではありません。
両方を並行・段階的に進める必要があります。

1. 基幹システム刷新計画を現場部門にもオープンにし、先を見据えたRPA設計を進める
2. RPA導入時は業務フロー自体をゼロベースで見直し、「今後の変化に耐える柔軟性」を組み込む
3. RPA開発はIT部門・現場・外部パートナーとの合同プロジェクト体制で実施
4. スモールスタート・仮運用を経て、基幹システム刷新との整合性を常に確認する
5. 新システムリリース後の早期段階で「RPA移行・再構築」の体制・予算も織り込み済みとする

このように、「大きな変化」と「小さな現場単位の自動化」とを”つなぐ”マネジメントが不可欠です。

これからのバイヤー・サプライヤーに求められる視点

今後、調達・購買部門、サプライヤー双方に求められるのは、「一歩先を読む」ことです。

・取引先からのRPA導入提案やデータ連携の相談は、基幹システムの刷新・DX戦略ともセットで議論する
・「その自動化は5年後も活きるのか？　新システムで生き残れるのか？」というラテラルな視点を現場・サプライヤー間で常にシェア
・現場独自の工夫・ノウハウをすぐに「全社標準」に落とし込まず、まずは仮運用・PDCAでフィードバックを積み上げる

「昭和の知恵」と「最新のデジタル知見」を融合したバイヤー、サプライヤーだけが、これからの荒波を乗り越えられるはずです。