はじめに
情報システム部での話です。
扱っていたのは、マスター登録業務。
- 商品マスター
- 取引先マスター
- 各種コード体系
申請を受けて、確認して、登録する。
毎日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な評価制度
改善しても評価されない
↓
誰もやらない
■ あるべき評価構造
改善する
↓
成果が数値化される
↓
評価される
↓
さらに改善する
最終構造
おわりに
この経験で分かりました。
業務改善は「技術」ではなく「設計」で決まる
- 組織設計
- 統制設計
- インセンティブ設計
- 評価制度
そして最後に。
人は「正しいから」では動かない
「評価されるから」動く
もし改善が進まないなら、
それはスキル不足ではなく、
仕組みの問題かもしれません。