RPA開発は一般的なシステム開発よりもランニングコスト比率が高い
一般的なシステム開発では、システムをリリースするまでに要したコスト（≒工数）を100％とするなら、リリース後には毎年それの20％近く発生すると言われています。たとえば、あるシステムを構築したとしましょう。サーバー、データベース、監視ツール／ジョブスケジューラーなどの各種ミドルウェアをセットアップし、システム要件を変更しない限り、同じ設定を使い続けます。システムリリース後の作業は、定常的なヘルスチェックやデータの整理整頓が中心で、プログラムバグ／リソース不足によるインシデント対応、セキュリティパッチ適用などが不定期に発生する程度です。
一方、RPA開発では、リリースまでに要した工数を100％とするなら、リリース後に発生する毎年の工数は50％にも達することがあります。
たとえば、人手で行っているある業務をRPAツールに置き換えたとしましょう。メールや特定のフォルダに置かれたファイルをイベントトリガーとして、インプットに応じたデスクトップ上の操作が自動実行されます。作業対象ウインドウのフォームやデータ項目は、テキストコード／画像／座標によって読取り／入力処理を行います。デスクトップ上のアイコンが変わった、バージョンアップで見た目（GUI）が変わったというだけで、RPAツールのスクリプト処理は止まります。メールの読み込みや特定アプリケーションの動作が遅延しただけででも思い通りに動かなくなるスクリプトもあるでしょう。この結果、その都度、保守担当者によるスクリプト／パラメーターの修正が発生します。
出典:アクセンチュア作成［画像クリックで拡大表示］
個々のRPA開発の案件というのは、実はそれほど規模が大きくありません。数FTE（Full Time Equivalents:フルタイム当量）で少しずつリリースするようなものばかりです。一方で一般的なシステム開発はその数倍の規模になるケースが多数あります。ある営業支援システムは導入に60FTE、保守運用は12FTE／年を掛けていました。一方、そのシステムを使用する営業社員の入力支援をRPAツールで置き換えたとき、RPA導入時は6FTEで済みましたが、その後の年間の運用保守にはその半分に当たる3FTEを掛けています。
このことから言えるのは、マニュアル業務をむやみにRPAツールの処理に置き換えてしまうと、逃れることのできないツール保守運用のボリュームが肥大化し、戦略的な投資への配分がどんどん目減りしてしまうという事実です。業務の生産を高めて戦略的な投資余力を捻出するはずのRPAが、その余力を削り取ってしまうのですから、皮肉というより外にありません。
