「とりあえずVBA」が危険になる業務パターンと設計の分かれ道

― Excel自動化を壊さずに育てるための設計視点 ―

「VBAで作れますよ」が失敗の入口になることがある

Excel業務改善の相談を受けていると、
かなりの頻度で出てくる言葉があります。

「それ、VBAでいけますよね？」

この一言自体は、決して間違いではありません。
実際、VBAはExcel業務を自動化するうえで、今でも非常に強力な手段です。

ただし問題は、
「VBAで作れるかどうか」と「VBAで作るべきかどうか」が混同されやすい点にあります。

本記事では、
「とりあえずVBA」で進めた結果、
後から重く・壊れ・触れなくなる自動化が生まれてしまう
業務パターンと設計上の分かれ道を整理します。

結論を先に断定することはしません。
代わりに、
「この業務は今、どこに立っているのか」を判断するための
思考の軸を提示していきます。

✅ 「とりあえずVBA」が選ばれやすい背景を整理する

まず前提として、
なぜ現場で「とりあえずVBA」が選ばれやすいのかを整理しておく必要があります。

これは技術的な怠慢ではなく、
極めて自然な選択の積み重ねであることがほとんどです。

Excel業務改善の初期は、VBAが最も現実的に見える

• Excelはすでに使われている
• 新しいツールを導入するハードルが高い
• すぐ効果を出したい

こうした条件が揃うと、
「Excelの延長で何とかする」＝VBA、という判断はごく自然です。

問題は、
その判断が“一時的なもの”なのか、“今後も前提になるもの”なのか
が整理されないまま進んでしまうことです。

✅ 危険パターン①：業務の全体像が見えないままVBAを書き始める

「とりあえずVBA」が最も危険になるのは、
業務の境界が曖昧なまま自動化を始めるケースです。

業務が「点」でしか認識されていない状態

例えば、

• この集計が面倒
• この転記を自動化したい

といった部分最適の視点だけでVBAを書くと、
そのマクロは業務全体の流れから切り離された存在になります。

最初は便利です。
しかし後から、

• 前工程が変わる
• 後工程が増える

といった変化が起きた瞬間、
VBAは業務を止める存在になりやすくなります。

✅ 危険パターン②：判断や例外処理をVBAに押し込めてしまう業務

VBAは「処理」を書くのには向いていますが、
「判断そのもの」を抱え込ませすぎると危険です。

人の判断をそのままコード化している場合

• この場合はA
• ただし例外としてB
• さらに〇〇のときはC

こうした判断は、
業務としてはまだ固まりきっていない可能性があります。

この段階でVBAに落とし込むと、

• 判断がブラックボックス化する
• なぜそうなっているか分からなくなる

という状態に陥ります。

結果として、
「誰も触れないVBA」が生まれます。

✅ 危険パターン③：将来の増加を想定しないままVBAで固定する

VBAが危険になるかどうかは、
処理量と利用範囲の見立てに大きく左右されます。

今は少ないが、増える可能性が高い業務

• 対象ファイルが増える
• 担当者が増える
• 頻度が上がる

こうした可能性がある業務を、
「今は小さいから」という理由だけでVBAに固定すると、
後から構造そのものを作り直す必要が出てきます。

問題なのは、
VBAが悪いのではなく、成長を想定しなかった設計です。

✅ 危険パターン④：属人化を前提にVBAが組まれている業務

「このマクロは〇〇さんしか直せない」

この状態は、
すでに業務改善としては黄色信号です。

スキル依存と業務依存が重なっている場合

• 業務を知っている人
• VBAを書ける人

この2つが同一人物の場合、
VBAは短期的には最速で進みます。

しかしスケールを考えると、
その人がいなくなった瞬間に業務が止まる設計になります。

✅ 「とりあえずVBA」にする前に考えるべき設計上の問い

ここまでの危険パターンを踏まえると、
VBAを書く前に立ち止まるべき問いが見えてきます。

• この業務は、今後どれくらい変わりそうか
• 判断はまだ人に委ねる余地があるか
• 増えたときに誰がメンテナンスするのか

これらに答えられないまま始めるVBAは、
高確率で「とりあえずVBA」になります。

✅ Excel → VBA → 他ツールは「逃げ」ではなく設計の延長

ここで重要なのは、
「VBAを使わない方がいい」という話ではないことです。

むしろ、

• Excelで業務を整理する
• VBAで安定した処理を固める
• 他ツールで実行や連携を担う

という役割分担として捉えると、
VBAは非常に健全な位置づけになります。

「とりあえずVBA」が危険になるのは、
VBAに役割以上のものを背負わせてしまったときです。

「とりあえずVBA」を選ばないという判断も立派な改善

実務では、
「今回はVBAにしない」という判断そのものが、
最も重要な業務改善になることもあります。

• まだ業務が固まっていない
• 判断が人に依存している
• 増える前提が強い

こうした状況では、
Excelで可視化を続ける、
あるいは別ツールを検討する方が、
長期的には健全です。

まとめ｜この記事は「VBAを否定する」ためのものではない

本記事で伝えたかったのは、
「VBAは危険だ」という結論ではありません。

• 危険になるのは、どんな業務か
• どこで設計判断が分かれるのか

を整理することで、
VBAを“使い続けられる選択肢”に戻すことが目的です。

次にVBAを書こうとしたとき、
「これは“とりあえず”なのか、それとも“設計された選択”なのか」
を一度問い直してみてください。

その一呼吸が、
Excel自動化を資産にするか、負債にするかを分けます。

本記事では、「とりあえずVBA」がなぜ失敗につながりやすいのかを、
業務パターンと設計判断の分かれ道から整理してきました。

ただ実務では、VBAを使うかどうか以前に
「この業務は本当に改善すべきか」「どこまでを自動化に任せるべきか」
という判断で迷っているケースも非常に多いです。

ツールや実装の話に入る前に、業務改善そのものの考え方を整理したい場合は、
「Excel業務改善をどう考えるか｜ツール・自動化を選ぶ前の設計思考」 を
先に読んでおくと、VBAを選ぶ／選ばない判断がブレにくくなります。