なぜExcel/VBAは軽視されるのか：技術ヒエラルキーと現場・管理の非対称性

はじめに

私は日頃、C#を用いた画像処理やPythonによる文字列解析やクラウドAPIの利用、またGeminiやNotebookLMを活用したAIエージェントの構築など、いわゆる「モダン」で「高度」とされる技術スタックに好んで触れています。一方で、予算や権限が厳しく制限された業務現場において、ExcelやVBAを駆使して「今日そこにある課題」を突破するハックも同じ熱量で実践してきました。

その両方の世界を跨いで活動する中で、どうしても拭えない違和感があります。それは、「技術の内容（何を実現したか）」ではなく、「技術の種類（何を使ったか）」によって、エンジニアの価値が品定めされてしまうという、目に見えないヒエラルキーの存在です。

なぜ特定の技術は軽視され、現場の切実な改善が「属人化」という言葉で片付けられてしまうのか。
その裏側には、技術者の心理的防衛、そして「管理」と「現場」という立場の違いが生む、構造的な衝突※が隠れています。

• 現場：改善の成果が「属人化」として一蹴されてしまう
• 管理：善意の現場改善が「負債」になって降ってくる

本稿では、この不毛な対立の正体を解き明かし、どうすれば異なる立場の人々が協力して「持続可能な業務改善」に向き合えるのかを考えてみたいと思います。

この記事で学べること

• エンジニアが陥りがちな「特定の技術（Excel/VBA等）を軽視する偏見」の心理的背景
• 技術の選定を決定づけているのは、技術力ではなく「組織内での立場（現場 vs 管理）」であるという現実
• 持続可能性の確保という難易度の高い課題に、現場側と管理側が協力して取り組むことの重要性

1. 技術界に存在する「目に見えないヒエラルキー」

現在、クラウド、分散DB、 Rust といった技術は「高尚」とされ、そういった技術を使っているだけですごく高度なエンジニアとみなされます。一方で、 Excel や VBA を使っていると、「古臭い」「非エンジニアの道具」と軽視され、それだけで技術力が低いとみなされてしまいます。
例えば現場部門でマクロ付きの Excel のテンプレートファイルを展開することで業務の水準と確実性を向上させ、そのテンプレートファイルをバージョン管理し、そのテンプレートの更新も、その理由となった業務上の課題も、それらの対応関係も、課題管理システム（例：Redmine, Backlog）で網羅的に一元管理する体制を敷いていてすら、 Excel を使っているというだけでバージョン管理ができていないはずだと管理部門やシステムベンダーのエンジニアから決めつけられたり、更にはデータや数式の載ったシートと合わさって初めて価値を発揮する VBA のコードだけを取り出してきちんと git でバージョン管理 すべきだと、実情から乖離した提案をされたりしてしまいます。
しかも、このような 偏見を持つ のは人間だけではありません。 ChatGPT や Gemini といった AI に技術的なアドバイスができるのは、 Stack Overflow や Qiita といった技術コミュニティーへの 書き込みを大量に学習 しているお陰ですが、それゆえにそうした空気感を反映した回答を返すことがあります。（※AIの性質上、特定の立場を擁護したいわけではなく、学習元の議論の傾向が反映される、という意味です）

結局のところ、技術の内容、つまりその技術を使って何を実現したかではなく、使った技術の種類でエンジニアの価値が品定めされてしまっているわけです。私の場合だと、解決したい課題に合わせて様々な種類の技術を適宜使い分けたり組み合わせたりすることで解決してきましたので、その度に扱いが大きく変わることがどうしても気になってしまいます。

ただ、広く人間社会を見渡せば、中身を見ずに外形的情報のみで判断されてしまうのは一般的な現象です。例えば人ならば能力や人間性ではなく容姿・年齢・性別・経歴などで判断されてしまいがちです。評価対象の一つ一つに対してその内容を詳細に吟味するだけの時間や労力が割けない以上は仕方がないのかもしれませんが、これによって偏見が生まれてしまいます。

2. 偏見の正体を解剖する：心理的防衛と「ドメイン恐怖症」

（ここでは便宜上、現場固有の前提を短時間で理解することへの強い心理的負荷を「ドメイン恐怖症」と呼びます。）
では、偏見の内容がなぜこうなるのでしょうか？その背景には、情報を発信するエンジニアの皆様の置かれた状況があります。
例えば医療や法律を扱う分野では、国家試験に合格した人のみが医師や弁護士と名乗ることを許され（名称独占）、法律で定められた業務が許可されます（業務独占）。一方、情報処理技術にはそういった制約が無く、誰でもエンジニアと名乗って技術を扱うことができます。情報処理技術者試験という国家試験はありますが、合格しても名称独占や業務独占はありません。漢検や英検を取得せずに漢字や英語を使ってよいのと同様に、情報処理の資格を取得していなくても、そして情報システムを扱う部門やシステムベンダーに所属していなくても、誰でも情報処理技術を扱うことができます。
そして、そういった人たちの中にも技術力の高い人がいたりします。そういった人は自分が担当している業務の分野に固有の知識（ドメイン知識）にも精通しています。それでいて技術にも明るいとなると、業務の内容や手順と擦り合わせながら技術を適用することで業務の水準や効率や確実性を向上させる（DX）上で非常に有利です。ドメイン知識を持たない人には、たとえ技術があっても到底太刀打ちできません。
更に、情報システムを提供し管理する立場にある人は、そのシステムを使う現場の人達から、その現場の分野に固有の ドメイン知識を理解することを要求されがち です。しかもそれは業務システムでトラブルが生じて切羽詰まった際に起こりがちです。現場の人がシステムを使うのはその現場の業務を進めるためであり、それには通常その現場のドメイン知識が必要だからです。でもそれは、その現場の人以外には概して理解が困難です。なのでどうしてもドメイン知識を恐れることになってしまいがちです。（ドメイン恐怖症）
こうした構造は、結果として「専門性の境界を明確にしたくなる」「守りの判断を取りやすくなる」方向に人を押しやすいのではないでしょうか。なので、現場部門でも使う技術ではなく、自分たちしか使わない技術の方が価値が高いということにしたくなり、それが技術コミュニティーへの書き込みにも反映されてしまうのではないでしょうか？

3. 管理部門の立場から考える統制と持続可能性

ただ、管理部門の役割はシステムの提供による業務の水準と効率の向上への貢献だけではありません。組織のセキュリティーやガバナンスを守るという重要な役割をも担っています。そのためには統制は組織の運営上不可欠ではありますが、現場部門側にどうしても何らかの不便を強いてしまいます。となると、現場部門にも詳しい人がいると管理部門に不満を訴えることになりがちです。ですが管理部門としては一部の技術に強い人がいる部門だけに特権を与えるわけにもいかず、組織を守るためにそういった不満を抑え込まざるを得ません。
現場側に技術に詳しい人がいると、管理部門側は頭の痛い問題を抱えることになってしまいがちです。それはその人の技術に依存してしまっている業務の持続可能性の確保です。現場には概して技術に強い人が多いわけではない以上、その技術に現場が依存すると、その人がいないと業務が成り立たなくなってしまいがちです。そして実際にそうなった時に、技術のことだからということで現場側はそれを管理部門側に要求しがちです。つまり、現場からの業務システムへの要求水準を物凄く引き上げてしまったわけです。ですが、その要求に管理部門側が対応するのは概して非常に困難です。なぜなら管理部門側はドメイン知識を持っていませんし、それに課題を現場のリソースで解決することになった理由は概してその課題の解決に要するリソースを組織として提供する余裕がなかったからであり、その人がいなくなったからといって急遽リソースを確保することは通常極めて困難だからです。
となると、その人がいなくなると業務ができなくなるのならばそれは業務の属人化であり、それは組織にとって大きなリスクなので、組織を管理する立場からは合理的に考えて排除しなければいけなくなってしまいます。なので現場部門の人が業務への強い責任感を以て業務システムを改善したとしても、ガバナンスを脅かす『シャドーIT』のリスクとして管理部門からは捉えられてしまいがちです。そうやって部門間の関係が悪くなってしまうと、組織運営のために管理部門が現場部門に統制を掛けることが困難になってしまいます。

4. 現場部門の立場から考える業務の改善と属人化の解消

現場部門が普段から自分たちに使える技術を使うのは、現場での持続可能性を最大限に追求したからです。特に Excel などは様々な業務に広く使われる以上、管理部門から禁止されずに持続的に使えます。しかも、現場開発が必要になったのは、業務用に提供されたシステムでは現場で必要とされる業務に不十分であり、システム改修を求めても費用対効果が悪いといった理由で却下されてしまったからです。それでもその解決のために自発的にシステムにリソースを投入するのは、業務上の課題を解決しないとその被害は自分たちに降りかかるからです。たとえ技術に詳しい人がいなくなって将来持続できなくなってしまったとしても、それまでは自分たちの業務を改善してくれるわけですから、解決できる技術が自分たちにあるならば自分たちで解決するという判断はその部門にとって合理的だといえます。
そして、一旦自分たちの部門の中で業務上の課題を解決できる体制を構築し、業務改善のPDCAサイクルが回り出すと、そのサイクルは管理部門やシステムベンダーに依存していた時とは比較にならないほど早くなります。何しろ業務改善のPDCAサイクルの中には、部門間や組織間での交渉と調整による責任分界点の決定や組織内での予算の確保といった月単位・年単位の時間のかかるプロセスが入らなくなり、自部門内での時間単位・日単位の作業のみで高速に回せるようになるからです。一旦この体制を経験すると二度と戻れなくなります。私の観測範囲では、部門間調整の工程が抜けるだけで体感速度が 桁 で変わることがありました。
なので、現場部門が高いモチベーションを以て、限られた権限内で最適解を実践していることを、管理部門が「属人化」という言葉だけで一蹴してしまうと、現場には大きな不満と、そして「事業価値を直接創出している現場をサポートすべき管理部門が逆に足止めしているのではないか」という不信感が残ります。
さらに、現場が技術を駆使して解決しようとしている課題の中には、皮肉にも「特定の人にしかできない」という現場業務の属人化の解消が含まれていることが多々あります。管理側の言う「技術の属人化」と、現場の言う「業務の属人化」。この「属人化」という言葉の定義のズレが、対話をさらに困難にしています。

5. 「技術力」ではなく「立ち位置」が技術の種類を決めている

このような現場部門で属人化しがちな自力解決に使われる技術の代表格が Excel と VBA です。だからこそ、情報処理技術を専門とする人達に統制リスクとして扱われがちです。更に都合の悪いことに、Excelはそれなりの量のデータや数式を扱うのに適し、「条件付き書式設定」や「データの入力規則」といった豊富な機能を用いて作り込まれていることも多いので、現場で使われているExcelファイルの内容やそのファイルが作られた意図は、その現場のドメイン知識が無いと理解が困難なことが多いです。
環境によっては FileMaker, Kintone, Google Spreadsheet と Google Apps Script (GAS) となることもあるかもしれません。技術の種類が偏るのは、現場部門で使える技術がこういったものに限定されているからです。一方、クラウド、分散DB、 Rust といった技術は通常現場部門で使われず、情報処理の専門家は習得が望ましい技術としてのみ触れることになりますから、大変高尚に映ります。
私はこれまで、C#での画像処理やPythonによる分析、そしてAI活用といったいわゆる『高尚』とされる技術も扱ってきました。その上で、厳しい制約下でのExcel/VBAハックも同列の熱量で実践してきました。その両方を経験したからこそ、この技術間の壁が技術力ではなく、単なる『立場の違い』に起因していることが見えてきたのです

6. 部門間の反発を協力に変えるには

ここまで述べた通り、現場には現場の合理があり、管理には管理の合理があります。問題は善悪ではなく、合理同士が衝突しやすい構造にあります。
技術を用いて業務を改善し、属人性を排して持続可能性を確保しようとする。その根底にある願いは、現場部門も管理部門も、そして外部のエンジニアも同じはずです。しかし、それぞれの「立ち位置」が生む構造的な衝突が、本来手を取り合うべき人々を遠ざけてきました。

この「不毛な対立」を「建設的な協力」に変えるために、私たちは以下のステップから始めるべきではないでしょうか。

「ハイブリッドな立ち位置」を公認する

現場で技術を振るう人を、単なる「詳しい人」として放置してはいけません。例えば、その人に管理部門への「兼務」や「技術アドバイザー」としての公的な役割を付与するのです。これにより、現場は「管理側の統制の意図」を理解し、管理側は「現場のドメイン知識」という聖域に触れるパイプを得ることができます。

技術の種類ではなく「解決の質」で語り合う

「Excelだからダメだ」という技術の種類によるマウントを捨て、「そのツールがいかに業務の継続性を担保しているか」を共通言語にすべきです。
現場が Excel を選ぶのは、それが現場にとって最も「持続可能な選択」だからです。ならば管理部門は、それを「禁止」するのではなく、「いかにして安全に、かつ属人化させずに運用し続けられるか」という技術的サポート（コードの共有方法やドキュメント化の支援など）を提示すべきでしょう。

結びに代えて

私自身、現場にも管理にも所属している立場として、どちらかを断罪するのではなく、衝突が起きやすい構造そのものを言語化したいと考え、この記事を書きました。
技術は、ドメイン（業務）を救うために存在します。そして管理は、その救済を持続させるために存在します。
エンジニアがドメインを恐れず、現場が管理を遠ざけない世界。その第一歩は、お互いが抱える「理不尽」を認め合い、技術のヒエラルキーという虚構を崩すことから始まるのだと私は信じています。