はじめに
VBAで業務改善をしたら、上司に怒られた。
「褒められる」と思っていたのに、返ってきたのはこんな言葉だ。
- 「勝手なことをするな」
- 「エラーが出たらどうする」
- 「人の仕事を奪うな」
……いや、それ怒るところか？
この記事では、私が実際に体験した「VBAで改善したのに評価されない」「むしろ怒られた」という理不尽と、その中で私がどう考え、どう生き残る方針に切り替えたかを書いていく。
結論から言うと、VBAそのものが悪いわけじゃない。職場の設計が終わってるだけだ。
ただし、終わってる環境で消耗しないための“戦い方”はある。
この記事はこんな人におすすめ
- 業務を効率化しようとして、上司や同僚に冷たい反応をされたことがある
- VBAやPythonで改善してきたのに、評価に結びつかなかった
- 「黙ってやれ」が正解の職場に違和感がある
- 理不尽にモヤモヤしているが、工夫はやめたくない
- 改善を“評価される行動”に変えたい
- いつでも転職できる強さを身につけたい
毎日2時間の手作業地獄
当時の職場は、毎日Excelで同じ作業を繰り返す環境だった。
数字の打ち直し、グラフ更新、フォルダ整理……これに毎日2時間。
月20日勤務なら、月40時間。年なら480時間。
もはや“人件費1人分”が消えている状態だ。
「これはおかしい」と思った私は独学でVBAを学び、作業を自動化した。
結果、2時間かかっていた作業は5分になった。
同僚からは「神すぎる」「助かった」と言われた。ここまでは良かった。
問題はここからだ。
VBAで改善したのに、なぜか怒られる
数日後、上司に呼び出されて言われたのは、まさかのこれだった。
- 「勝手なことをするな」
- 「エラーが出たらどうするんだ」
- 「社員が考えなくなる」
- 「人の仕事を奪うな」
はい、出た。
私は内心こう思った。
- 勝手？昼休みや家でコソコソ作ったからか？
- エラー？手作業のほうがミス多くないか？
- 考えなくなる？今は考えているの？
- 仕事を奪う？奪うべきは“無駄”だろ
しかも会議では「DX化を進めなきゃ」なんて言ってるのに、現場の自動化はNG。
言ってることと、やってることが真逆。これが一番しんどい。
このとき私は気づいた。
怒られた理由は「改善の質」じゃない。管理側が困る構造に触れたからだ。
これはもう、管理職の器の問題だと感じました。
「つくったマクロは使えない」と言われる理不尽
さらに別の日、ちょっとした初期バグでこう言われた。
- 「こういうのって、やっぱり使えないんだよ」
- 「自動化の悪いところだよね」
いわゆる「1ミス＝永久追放」理論だ。
人間の手作業ミスは“なかったこと”にされるのに、プログラムのミスは一発レッドカード。
理不尽にもほどがある。
VBAでの業務改善は、少しでもエラーが出ると「信用できない」と判断されやすい。
保守的な職場ほど、自動化やDXそのものに拒否反応がある。
「お前がいなくなったらどうするの」と言われた本音
さらに上司からこう言われた。
- 「独自技術でワンマンプレーをするな」
- 「お前がいなくなったら誰が面倒見るんだ」
この手の発言は、表向きは「属人化の懸念」っぽい。
でも実態は違うことが多い。
- 管理できないものが増えるのが怖い
- 責任が増えるのが嫌
- “自分の統制下にない成果”が気に入らない
つまり、あなたの改善が“正しい”ほど嫌われる。
もちろん属人化はリスクだ。これは事実。
ただし、だからといって「改善するな」は本末転倒だ。
属人化は、改善を止める理由じゃなくて、改善を“仕組み化”する理由だ。
日本の職場、思考停止してない？
改善提案が潰される。
波風を立てずに、言われたことだけやるのが正解。
そんな空気は、まだ根強い。
年功序列、前例主義、新しい技術への恐れ。
結果、現場で起きるのはこれだ。
- 改善しても評価されない
- 余計なことをすると怒られる
- 作業を減らすと“暇なやつ”扱いされる
こういう職場は、改善者にとって地獄だ。
ただし、地獄で消耗しない方法はある。
なぜ「改善すると怒られる」のか（結論：あなたのせいじゃない）
ここを言語化しておく。理由はだいたい次のどれかだ。
1) 責任の所在が増えるのが嫌
自動化すると「何か起きたとき誰が責任を取るか」が明確になる。
管理職はそれを嫌がる。だから止めに来る。
2) 業務がブラックボックス化するのが怖い
コードが読めない人ほど「怖いから禁止」にする。
理解できないもの＝危険、で思考停止する。
3) “仕事量”で人を評価している
効率化すると、頑張りが見えなくなる。
頑張り＝残業、みたいな職場ほど、改善は嫌われる。
4) 権力構造が崩れる
改善者が成果を出すと、現場の序列が揺らぐ。
それを守るために潰されることがある。
5) 会社が「DXごっこ」をしている
スローガンだけDX。現場は旧態依然。
これが一番タチが悪い。
それでも改善をやめなくていい理由
私は、ここで改善をやめなかった。理由はシンプルだ。
改善は、会社のためというより、自分のためだからだ。
- 自分の時間が増える
- ミスが減る
- 仕組みを作れる人間になる
- その実績は転職で武器になる
社内で評価されないなら、社外で評価される場所に行けばいい。
改善スキルは、環境を変えるための“逃げ道”にもなる。
生き残るための現実的な戦い方（これだけはやれ）
理不尽な職場で改善を続けるなら、やり方を変える必要がある。
ポイントは「正しさ」じゃない。「通し方」だ。
1) 事前に“許可”ではなく“合意”を取る
「作りました」だと揉める。
「こういうミスが多いから、対策として5分で回る仕組みを作りたい」で先に話す。
2) いきなり全自動にしない
まずは半自動（ボタン1つ、確認画面あり）でいい。
相手の恐怖心を下げるのが先だ。
3) ログとバックアップを用意する
「エラーが出たらどうする？」への回答は、精神論じゃなく設計で返す。
- 実行ログを残す
- 旧データを退避する
- 例外時は処理を止める
- 手作業の手順も残す（最悪戻れる）
4) 引き継ぎは“完璧”を目指さない
属人化をゼロにするのは無理だ。
だから「最低限、他人が触れる状態」を作る。
- 使い方1枚メモ
- 変更点メモ（更新履歴）
- 変数名をまともにする
- 1ファイルに詰めすぎない
これだけでも、文句は減る。
5) 味方を1人作る
全員に理解される必要はない。
評価してくれる人に刺さればいい。部署でも、別部署でもいい。
「VBAやめとけ」の本当の意味
タイトルは強くした。
ただ、私の本音はこうだ。
VBAは便利だ。現場の改善には今でも強い。
でも、“評価されたい”ならVBAだけで戦うのは厳しい職場がある。
VBAは「個人が便利にする道具」と見なされやすい。
一方でPythonや仕組み化は「組織のDX」として扱われやすい。
ここに“ラベルの差”がある。
だから「VBAをやめろ」じゃない。
VBAで作ってもいい。ただし、キャリアはVBAに閉じるな。これが言いたい。
余談｜Pythonに移行したら評価が一変した
私は後に、同じ文書自動作成ツールをPythonで作り直した。
すると状況が一変した。
- 「これはDXだ」と正式に認められた
- 展開の話が進んだ
- “個人ツール”から“会社の仕組み”になった
同じ改善でも、VBAだと便利な小技。
PythonだとDX。
この差は衝撃だった。
まとめ｜評価されなくても市場価値は高まる
VBAで改善しても怒られる職場は確かに存在する。
でも、それはあなたの価値を否定するものじゃない。
- 属人化は工夫で薄められる
- 小さな改善でも実績になる
- 社内で評価されなくても、社外では武器になる
理不尽な職場で消耗するより、改善を続けて強くなったほうがいい。
改善できる人間は、どこでも生き残れる。
