仕事の効率化にエクセルマクロを使って自動化している現場も多いのではないでしょうか。
VBAが使えることで、主にマイクロソフト製品の全般を自動化して動かせるのはVBAの大きなメリットであります。
エクセルが代表的でありますが、PowerPointやOutlookもVBAで自動化が可能です。
おそらく、エンジニア以外の人でも学習しコーディング出来る人が多いのではないでしょうか。
しかし、部署内で仕事をするときに個人利用以外では使わない方が良いです。
確かにマクロになる事で他の人の仕事も効率化出来るのであれば、コーディングするに越したことはないのですが、実態としてはマクロをシステムと同様に扱うのには無理があります。
便利な機能であるがゆえに、逆に問題が起きることも多かったります。
そこで今回はエクセルマクロを業務標準化に使わない方が良い理由を書いていきたいと思います。
私もVBAを使って効率する事もあれば、依頼を受けてVBAでツールを作る事もあります。
ですが、使い方を誤ると問題が起きることの方が多いと思っています。
エクセルマクロを業務標準化に使わない方が良い理由
VBAを読み書きできないとトラブルになる
当然ながら、業務の標準化にVBAを使用してしまうとメンテナンスが出来ないといけません。
一生動き続ける仕様があれば良いのですが、残念ながらVBAはそのように作られていません。
VBA自体がそういったものではなく、Officeのバージョンが上がる事、ビット数の違いがある事、ライブラリが変わっていく事でソースコードが古くなると正常動作しないケースが多いからです。
時代が変わると共に技術も変化していきます。
その変化に対応できる人間が常にいないと、VBAで業務を維持していく事は難しいです。
VBAで書かれたソースがブラックボックスになってしまった時に、正常に動作しない事態に陥ると最悪業務が停止してしまいます。
つまり、VBAで業務を標準化するとVBAを読み書きできない人が後任となった場合はトラブルの原因にしかなりません。
ソースコードだけ置き去りにして引き継ぎなどをするのは非常に危険な行為です。
Javaなどプログラミング言語であれば、最悪古くてもプラットフォームに実行環境さえ整っていればサポート無しでも動作します。
残念ながらVBAをシステム同様に扱うのは最終的には「非効率」や「トラブル」になります。
自分の仕事を効率化するためだけに使用するようにしましょう。
マクロからの脱却が困難になる
エクセルマクロ自体は便利で使い勝手が良いです。
しかし、あまりに膨大なソースコードが書かれていて、解読するのに時間がかかるようになるとシステム化するのにもハードルが上がってしまいます。
根本的な問題ですが、エクセル業務は出来るだけ排斥してシステム化する方が生産性が向上します。
エクセルでちまちまデータ加工をしていたのをマクロ化するよりも、システムから直接欲しいデータ形式で受け取れる方がよっぽど生産的で処理も早いです。
マクロはローカルPCのメモリを使用して動作するので、サーバを用いたプログラムの動作速度と比べても性能は明確に差があります。
マクロの加工処理をサーバプログラムに置き換える時にVBAの処理が多すぎると変換するのにも時間がかかります。
すると、結局マクロを捨てられず、OSのバージョンやOfficeのバージョンが上がり、動作しなくなり多大な工数をかけてメンテナンスする必要が出てきてしまいます。
まさしく悪循環であると言えます。
複雑な処理こそプログラミング言語
エクセルマクロのあるあるの一つとして、VBAがメモリを使用し過ぎてPCが重くなったりフリーズしてしまう事があります。
そもそも、プラットフォームがPCであるのでやはり性能には限界がありサーバの処理速度と比べる大きく劣ります。
つまり複雑な処理こそシステムで対応すべきです。
システムだとミリ単位で処理できしまう処理をVBAで数分かけて実行するのは非効率で、それを他人の環境に移して正常に動作する保証はありません。
標準化するのであればシステムで全員が共通の処理が出来るようにするのが最適で、メンテナンスは専門のシステムエンジニアと相談すれば個人で思うままに書いたソースコードよりも修正が効きます。
エクセルマクロで複雑な処理を大量に実行しそれを他人と共有してもいつか破綻します。
システムは必ずリプレースがあり専門で対応できる人がしっかりと対応します。
しかし、エクセルは忘れ去られたらおしまいです。
出来るだけ複雑な処理はシステムに移行する事をお勧めします。
エクセルは誰でも削除できる
エクセルは結局のところファイルですので、マクロを作っていてもエクセル自体が無くなってしまえば取り返しがつきません。
誤ってファイルを削除したり、ファイルサーバの障害で消失してしまうなど、様々な問題に直面しやすいです。
また、エクセルはファイルサイズが大きくなると開くのも困難になる事があります。
その反面システムは簡単に消せません。
確実に残す事が出来るのがシステムで、システムが活きていれば業務は止まりません。
しかし、不特定多数でエクセルマクロを共有しているとどうでしょうか。
「誰が開いている」や「ファイルが無くなった」や「動かなくなった」など問題を抱えやすいです。
また、何度も書いてきていますがメンテナンスが出来る人間がいるのか、または誰がメンテナンスするのかなど扱いが難しくなります。
個人業務以外でマクロを使用するのであれば、最後まで責任をもって管理しないといけません。
属人化を後押ししてしまう
VBAを扱える人が、部署内に一人しかいない時に、その人のマクロに頼ったりその人自身の仕事を誰かが引き継ぐときにVBAにされると属人化してしまいます。
個人で共有する必要もない業務であればVBA化して効率化するのは良いでしょう。
しかしVBAの仕様やメンテナンスを業務としてしまうと属人化が進むだけです。
誰がいつどんな業務の影響でソースコードを変更したか、第三者が理解できるようにしないと本人しか分からない状態になります。
また、VBA自体が読めてもどんな業務に使っていて、その業務がどういった内容か把握しないとコーディングの意図も分かりません。
個人的な経験則ですが40代以上の社会人はマクロを多用し過ぎていると思います。
時代背景的にVBAが流行っていたり、Accessなども登場して知識を養った人が多くいるのかもしれません。
しかし、私のような平成生まれのエンジニアはAccessなんか使わずにPostgresやMySQLなどデータベースを利用します。
なぜならそちらの方が処理が早くシェルスクリプトなどはプラットフォームがLinuxであればどこでも動作するからです。
シェルスクリプトやミドルウェアは専門の技術者がいれば何とかできますが、VBAは専門家の技術者はほとんどいません。
後世に業務を引き継ぐのであればすぐにでもマクロを辞めてシステム化することをお勧めします。
また、無理にVBAを覚えようとせずにエクセル業務から脱却しシステムで生産性の向上を訴えた方がよほど時代に即しています。
最後に
VBA自体は非常に素晴らしい技術で私も多用しております。
しかし、ここまで書いた通り、あくまで個人使用で他社にVBAのコーディングなどを強いることは絶対にしてはいけません。
何ならVBAが出来る人が後任で来たのであれば「運が良かった」と思っておくべきだと思います。
その運が良い時だけマクロを引き継いでも良いでしょう。
VBAは事務職などでも利用している人もいると思いますが、OSやOfficeの進化に合わせていける自信がないのであれば他人と共有することはお勧めできません。
10行程度で簡単で単純な処理をするVBAであれば業務で共有しても良いでしょう。
しかし、たくさんのプロシージャを作ってしまったり、ループにループを重ねてエクセルの参照なども用いて複雑なデータ加工をする場合は、それを「業務」として引き継ぐのは辞めましょう。
良い技術は正しく使用してこそ効果が得られます。
使い方を誤ると避けな工数やトラブルにしかならないので、私はエクセルマクロは個人利用に留めて頂きたいと思っています。