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

VBA を扱う人をエンジニアだと考える企業があります。これ自体は、単に言葉の使い方の違いに見えるかもしれません。しかし、実際にはその企業が IT や技術職をどの程度理解しているかを示す、かなり分かりやすいサインだと思います。

最初に明確にしておくと、VBA そのものを軽視しているわけではありません。VBA は業務改善の道具として非常に有効です。Excel 業務を自動化し、手作業を減らし、現場の作業効率を上げる力があります。

問題は、VBA を使えることをもって、ソフトウェア開発、システム設計、インフラ設計、運用設計、セキュリティ設計まで含むエンジニアリング全体を理解しているかのように扱うことです。ここにはかなり大きな認識のずれがあります。

VBA は業務改善の道具である

VBA は主に Microsoft Office、特に Excel を中心とした業務を自動化するための道具です。総務、経理、法務、営業、事務部門など、非 IT 部門の業務改善で使われることも多いです。

その意味で、VBA を扱える人は組織にとって有用です。手作業で繰り返していた処理を自動化できるなら、それは十分に価値があります。

ただし、その価値はあくまで業務改善や部門内自動化の文脈で評価すべきです。VBA を使えることと、エンジニアリング全体を担えることは同じではありません。

非 IT 企業では技術職の解像度が低くなりやすい

非 IT 企業では、技術職の分類がかなり粗くなることがあります。Excel に詳しい人、PC に詳しい人、プリンタを設定できる人、ネットワーク機器の名前を知っている人、VBA を書ける人が、まとめて「システムに強い人」として扱われることがあります。

もちろん、社内業務としてはそれで回る場面もあります。しかし、その分類のまま外部の技術職や IT 業界を理解しようとすると、かなり危うくなります。

• VBA で帳票を自動化すること
• 業務システムを設計すること
• アプリケーションを開発すること
• インフラを設計、構築、運用すること
• セキュリティや認証基盤を設計すること

これらはすべて IT に関係しますが、必要な知識、責任、設計対象、失敗時の影響範囲は大きく異なります。

問題は VBA ではなく、役割の誤認である

VBA を扱う人をエンジニアと呼ぶことが常に間違いだとは言いません。実際に業務アプリケーションを設計し、保守性や例外処理、データ構造、運用まで考えて作っている人もいます。

しかし、単に Excel マクロを書けることをもってエンジニアとみなすなら、それは技術職の理解としてかなり粗いです。

この誤認がある企業では、エンジニアに期待する役割もずれやすくなります。技術設計ではなく便利屋的な対応を求めたり、設計責任と作業代行を混同したり、専門性の違いを理解しないまま人を配置したりします。

エンジニアリングは目に見えない構造を扱う

非 IT 企業で起きやすいのは、目に見える操作や成果物だけで技術力を判断してしまうことです。Excel の画面、プリンタ、PC、ネットワーク機器、管理画面など、目に見える部分は理解しやすいからです。

しかし、エンジニアリングで重要なのは、むしろ目に見えない構造です。データの流れ、依存関係、責任境界、障害時の挙動、保守性、認証、権限、変更管理、運用設計などです。

VBA であっても、そこまで考えて作るなら設計の領域に入ります。一方で、単に目の前の作業を自動化するだけなら、それは業務改善スキルとして評価する方が自然です。

求人票や面接で注意すべきサイン

この認識ずれは、求人票や面接にも現れます。たとえば、エンジニア募集でありながら、実際の業務内容が Excel マクロ、社内問い合わせ、PC 設定、ベンダー調整、資料作成に大きく偏っている場合があります。

もちろん、それらの仕事が不要だという話ではありません。ただ、それをエンジニアリング経験として期待すると、キャリアの方向性がずれる可能性があります。

• エンジニア募集なのに技術領域が具体的に書かれていない
• VBA、Excel、PC サポート、社内調整が一括りにされている
• 設計、開発、運用責任の範囲が曖昧である
• 技術選定や改善提案より、便利屋的な対応が強調される
• IT 部門の役割が社内雑務に近い

こうした場合、その企業では技術職の解像度が低い可能性があります。

関連記事

• エンジニアと情シスの役割構造の違い – 技術設計と社内運用を混同しない
• 求人票で「高いコミュニケーション能力」と書く企業が危険な理由 – 要件定義できない組織を見抜く
• 日本企業でエンジニアが成長しにくい理由 – 技術より調整が評価される構造
• エンジニアのキャリアは良い経験を積めるかで決まる – 技術責任を持てる環境を選ぶ

まとめ

VBA を扱う人をエンジニアだと考える企業は、VBA の価値を認めているというより、技術職の区分を十分に理解できていない可能性があります。

VBA は便利で有用な道具です。しかし、それをエンジニアリング全体の代表のように扱うと、役割、責任、専門性の理解がずれていきます。

重要なのは、VBA を否定することではありません。VBA で解決できる業務改善と、システム全体を設計するエンジニアリングを分けて考えることです。この区別ができているかどうかは、その企業が IT と技術職をどの程度理解しているかを見る上で、かなり重要な判断材料になると思います。