はじめに

情報システム部での話です。

扱っていたのは、マスター登録業務。

商品マスター
取引先マスター
各種コード体系

申請を受けて、確認して、登録する。

毎日1〜2時間、同じ作業。

だから思いました。

「これ、RPAでできるのでは？」

小さな検証

RPAを組んでみました。

データ取得
必須チェック
登録処理
ログ出力

問題なく動く。

技術的には、すぐに置き換えられる状態

提案

上司に見せました。

「自動化できます」

返ってきた答えはシンプルでした。

「やらなくていいかな」

止められた理由は4つの壁

壁①：人の問題

業務削減
↓
役割消失
↓
余剰人員
↓
配置・評価の問題

業務は消せるが、人は簡単に動かせない

壁②：内部統制の問題

統制変更
↓
監査対応
↓
証跡・責任の再設計

統制は壊せない

壁③：責任の問題

成功 → 人が余る
失敗 → 業務混乱

どちらでも責任が発生

壁④：コストの問題

コスト > 効果に見える

やる意味が問われる

優先順位（現場感）

① 責任
② 内部統制
③ 人
④ コスト

本質

最大の敵は「責任を取りたくない構造」

解決策：インセンティブ設計

「やると得、やらないと損」に変える

成果の可視化

時間 → 金額換算
年間効果で提示

責任の分散

個人 → チーム
承認・設計・運用で分割

小さく始める

低リスク領域
段階導入

やらないリスクを作る

手作業＝監査リスク
ミス＝可視化

統制と共存

ログ強化
証跡自動化

評価制度に落とし込む（OKR / KPI設計）

ここが最後のピースです。

■ OKR設計（例）

Objective（目的）

マスターデータ管理の品質と効率を両立する

Key Results（成果指標）

KR1：マスター登録の自動化率 50%以上
KR2：登録作業時間を30%削減
KR3：登録ミス件数を50%削減
KR4：監査指摘ゼロを維持
KR5：RPAログ100%取得

■ KPI設計（現場運用）

① 効率KPI

自動化率
削減工数（時間/月）
処理件数/人

② 品質KPI

入力ミス件数
差戻し率
データ不整合件数

③ 統制KPI

承認遵守率
ログ取得率
監査指摘件数

④ 改善KPI

自動化対象業務数
横展開数
改善提案数

■ NGな評価制度

改善しても評価されない
↓
誰もやらない

■ あるべき評価構造

改善する
↓
成果が数値化される
↓
評価される
↓
さらに改善する

最終構造

おわりに

この経験で分かりました。

業務改善は「技術」ではなく「設計」で決まる

組織設計
統制設計
インセンティブ設計
評価制度

そして最後に。

人は「正しいから」では動かない
「評価されるから」動く

もし改善が進まないなら、

それはスキル不足ではなく、
仕組みの問題かもしれません。