VBA を扱う人をエンジニアだと思う企業は非 IT 企業 – 技術職の理解不足を見抜く

VBA を扱う人をエンジニアだと考える企業があります。これ自体は、単に言葉の使い方の違いに見えるかもしれません。しかし、実際にはその企業が IT や技術職をどの程度理解しているかを示す、かなり分かりやすいサインです。最初に明確にしておくと、VBA そのものを軽視しているわけではありません。VBA は業務改善の道具として有効です。Excel 業務を自動化し、手作業を減らし、現場の作業効率を上げる力があります。

問題は、VBA を少し扱えることと、エンジニアリング全体を同じものとして扱ってしまうことです。

VBA が悪いのではなく、技術職の定義が粗いことが問題

問題は、VBA を使えることをもって、ソフトウェア開発、システム設計、インフラ設計、運用設計、セキュリティ設計まで含むエンジニアリング全体を理解しているかのように扱うことです。VBA は業務現場の改善に強い道具です。帳票作成、集計、自動化、入力補助、定型処理の削減には大きな価値があります。ただし、部門内の Excel 業務を効率化することと、組織全体で長期運用されるシステムを設計することは別の話です。必要な責任、品質、保守性、セキュリティ、変更管理が違います。

観点	VBA の価値	エンジニアリングとして見るべき観点
対象	Excel 業務、帳票、集計、定型作業	業務全体、データ、権限、運用、障害対応
責任	個人または部門内の効率化	組織全体で継続利用する仕組み
品質	動けば便利になりやすい	保守性、監査性、変更管理、セキュリティが必要
評価	現場改善として評価できる	技術職全体の代替にはならない
リスク	属人化しやすい	設計、レビュー、テスト、運用責任が必要

非 IT 企業で起きやすい誤解

非 IT 企業では、IT に詳しい人、Excel が得意な人、VBA が書ける人、システム管理者、ソフトウェアエンジニアがまとめて「IT に強い人」として扱われることがあります。現場感覚としては理解できます。IT に詳しくない人から見れば、Excel を自動化できるだけでも十分に専門的に見えるからです。しかし、この分類が粗い会社では、技術職としての役割、評価軸、育成、責任分界も粗くなりやすいです。本人がどれだけ努力しても、会社側が技術経験の違いを評価できなければ、キャリアとして積み上がりにくくなります。

VBA が社内システム化すると危険になる

VBA が便利なのは、現場の小さな改善にすぐ効くからです。一方で、その便利さのまま重要業務へ広がると危険になります。作った人しか分からない。ソース管理がない。テストがない。権限管理が曖昧。誰が保守するのか決まっていない。こうした状態で部門の重要業務を支えるようになると、VBA は便利な道具から属人化した社内システムへ変わります。

VBA ができる人とエンジニアは何が違うのか

VBA ができる人は、現場の業務を理解し、Excel 上の処理を効率化できる人です。これは価値のある能力です。一方で、エンジニアは、目的、制約、データ、権限、運用、障害対応、セキュリティ、変更管理を含めて、仕組みとして成立するかを考えます。もちろん、VBA からエンジニアリングへ進む人もいます。大切なのは、VBA を入口として、設計、テスト、レビュー、保守、責任分界まで視野を広げているかどうかです。

見る観点	VBA の範囲で止まりやすい状態	エンジニアリングに近づく状態
設計	目の前の処理を動かす	データ構造や業務フローを整理する
保守	作った人だけが直せる	ソース管理、レビュー、引き継ぎがある
品質	動作確認が属人的	テスト観点や変更管理がある
責任	困ったら詳しい人に聞く	運用責任と障害時の対応が決まっている

求人票や面接で確認したいこと

求人票で VBA、Excel、業務改善、社内 IT、情シス、エンジニアという言葉が混ざっている場合は、実際の役割を確認した方がよいです。

確認したいこと	見るべき理由
VBA 以外に何へ関われるか	技術経験が Excel 業務に閉じないかを見る
業務改善なのかシステム設計なのか	役割の期待値を確認する
属人化したツールをどう管理しているか	保守性と責任分界を見る
ソース管理、テスト、レビューがあるか	エンジニアリングとして扱っているかを見る
技術職としての評価軸が具体的か	便利な人として消耗しないかを見る

まとめ

VBA は便利で価値のある道具です。現場の業務改善、集計、自動化、定型作業の削減には大きな力があります。しかし、VBA を扱えることをもってエンジニアリング全体を理解していると見なす企業は、技術職の解像度が低い可能性があります。VBA を否定する必要はありません。見るべきなのは、その企業が技術の種類、責任、品質、保守、運用を分けて考えられているかです。エンジニアとして働くなら、VBA ができるかどうかだけでなく、技術判断、設計責任、変更管理、責任分界に関われる環境かを確認することが大切です。