――なぜExcelマクロだけが生き残ったのか
業務可視化のためにPython製の常駐ツールを作ったが、社内承認で止まった。なぜExcelマクロだけが生き残ったのか。DXと統制の評価軸が切り替わる瞬間を、実体験から整理する。
「まずは業務を可視化しよう」
DXや業務改善の話になると、
だいたいこの一言から始まる。
正しい。
正論すぎて、反論の余地がない。
ただし問題は、
その先に進もうとした瞬間に何が起きるかだった。
業務は誰も正確に測れていなかった
TPSのテーマを考えていたとき、
ごく当たり前の疑問が出た。
- どの業務に
- どれくらい時間を使っていて
- それは本当に価値のある時間なのか？
誰も答えられない。
忙しいのは事実。
でも「何に忙しいのか」は、
各自の感覚の中にしか存在していなかった。
ここで、よくある解決策が出る。
「自己申告でExcelに書こう」
この時点で、結果はほぼ見えている。
続かない。
理由は単純だ。
「思い出して書く」という行為自体が、
すでに業務の実態からズレている。
人を信用しない設計は、AIっぽい解に行き着く
じゃあどうするか。
人に書かせない。
人に操作させない。
仕事をしているだけでログが残ればいい。
設計や実装は、AIに相談しながら詰めた。
- どの粒度で取れば改善に使えるか
- どこまで取ると過剰になるか
- PC負荷はどこまで許容されるか
その結果、出来上がったのが次のようなものだ。
- Windows常駐
- アクティブウィンドウを自動取得
- exe名・タイトル・開始／終了時刻を記録
- CSVでローカル保存
- PC負荷はほぼゼロ
人は何もしない。
ただ仕事をするだけ。
TPS的にも、
業務可視化としても、
かなり筋のいい解だったと思う。
しかもこれはアイデア段階じゃない。
もう普通に動いていた。
システム部に相談した瞬間、評価軸が切り替わった
さすがに勝手に使うわけにはいかない。
そう思って、本社のシステム部に相談した。
返ってきた指摘は、冷静で妥当だった。
- 非標準ツールは増やしたくない
- 常駐アプリはPC影響のリスクがある
- OSアップデート時の対応ができない
- 保守が属人化する
- 個人監視に見える可能性がある
- コンプラ・組合説明が必要
……全部、正しい。
ここで重要なのは、
話がズレたわけではないということだ。
評価軸が
「良いか悪いか」から
**「会社として扱えるか」**に切り替わっただけ。
本社システム部の本音は、DXより「統制」
この時、はっきり分かったことがある。
本社システム部がDXと言うとき、
本音はだいたいこれだ。
把握できないものを増やしたくない
これは保守的だからでも、
やる気がないからでもない。
役割として当然だ。
彼らが一番怒られるのは、
- 古い
- 使いにくい
ではなく、
- 何が動いているか分からない
- 誰が作ったか分からない
- 止め方が分からない
という状態だからだ。
DX推進と言いつつ、
最優先されるのが統制になるのは、
構造的に避けられない。
なぜExcelマクロはOKで、PythonのEXEは止まるのか
ここで誤解されがちだが、
「Excelは安全で、Pythonは危険」
という話ではない。
本質はこうだ。
Excelは“社内標準”という免罪符を持っている
Excelはすでに会社の中に存在する。
だから事故が起きても、
- 「Excelを使っていました」
で話が通る。
一方、PythonのEXEは、
- 「個人が作った実行ファイルを配布しました」
という扱いになる。
同じ事故でも、
説明コストと責任の重さが違う。
実行ファイルは「管理対象」になる
EXEは、
- 配布
- 更新
- 停止
- 影響範囲
を説明しなければならない。
Excelマクロも危険になり得る。
でも、
- ファイルとして存在が見える
- 消せば止まる
- 想定内の事故で済む
会社が嫌うのは、
危険そのものではなく、
制御不能になることだ。
決定打は「監視に見える」ことだった
自動取得ログは、価値が高い分、
見え方が強い。
- 常時
- 本人操作なし
- 行動内容を記録
技術的には業務ログ。
でも社内では、行動監視に見える余地がある。
一方、Excelの開始／停止は、
- 本人が押す
- 同意しているように見える
- 粒度が荒い
この「見え方」の差は、
AIの精度より重い。
じゃあ、なぜRPAは安易にDXとして進められるのか
ここでどうしても違和感が残る。
PythonのEXEは止まるのに、
RPAはDXとして推される。
理由は単純だ。
RPAには最初から「統制の器」がある。
- ベンダーがいる
- 管理画面がある
- 権限管理・ログがある
- 導入実績がある
価値の話ではない。
責任を外に出せるかどうかの話だ。
結果として起きるのは、
- 本質に踏み込む案は止まり
- 画面操作をなぞる自動化がDXになる
という歪み。
こうして残ったのがExcelマクロだった
最終的に残ったのは、
- Excel
- マクロ
- 手動開始／停止
AIとしては弱い。
DXとしては地味。
でも、
- 誰も怖がらない
- 説明がいらない
- 統制の枠内に収まる
会社の中では正解だった。
それでも、EXEが通るとは思っていない
正直に言うと、
この話は「EXEを通したかった」という話ではない。
多くの会社で、
個人が作った常駐EXEが通らないのは当然だと思っている。
インフラ系や大規模組織なら、なおさらだ。
だから、
「器を用意すればEXEがOKになる」
とは最初から思っていない。
たぶん結論は変わらない。
EXEは、ダメだ。
欲しかったのは、EXEを通すことじゃない
それでも違和感が残った理由は、そこじゃない。
欲しかったのは、
- EXEはダメ
- でも、何が問題で
- どこまでなら試せて
- 次にどうつながるのか
その道筋だった。
EXEがダメでもいい。
常駐がダメでもいい。
自動取得がダメでもいい。
でも、
「それはダメ。以上。」
で終わってしまうと、
発想ごと消える。
この話の本当の失敗
この話の失敗は、
- AIの使い方を間違えた
- 技術選定を誤った
ことじゃない。
本当の失敗は、
試して、ダメだったものが、
次に何も残らなかったこと
だ。
EXEは通らなくても、
「人を介さずに業務を計測したい」という発想は、
どこかに残せたはずだ。
- OS標準のログ
- 既存ツールの利用統計
- 粒度を落とした集計
- 期間限定の試行
そういう形に翻訳される回路があれば、
この話は「失敗」で終わらなかった。
それでもDXと言うなら
だから、DXに必要なのは新しい技術じゃない。
- 試して失敗していい範囲
- 野良な発想を、試行に変える回路
- 統制の論理と、改善の論理をつなぐ設計
その器だ。
EXEを通すための器じゃない。
発想を殺さないための器。
コメント