VBAでツールを作るのはもうやめようか。

業務でしばしばエクセルVBAを用いたツールを作ってきた。
簡易ツールもあるが、かなり業務を遂行する上で必須となるようなツールも作ってきた。

はじめて触れたのは新人のころで実行環境と開発環境がエクセル１個で済み、
マクロの保存なんかですぐにコードが保存できる点なども勉強しやすくこれはいいと思って
食い入るように勉強したのを覚えている。

ただ、最近はVBAでツールを作成することに少し疑問を抱いてきた。（重要度が高いツールに限る）

業務上必須となるようなツール。
例えば開発ルーチンに組み込まれるようなツール。
ソースの自動生成とか。試験ツールとか。

こういったツールは、開発の状況次第でメンテナンスが頻繁に発生したりする物だと思う。
エクセルVBAをわざわざ使うということは、そのツールの扱うデータはエクセルである場合がほとんどである。
エクセルVBAはエクセルのデータを参照する場合にはとても楽で悪いところが見当たらないように思える。
だが、メンテナンスが頻繁に発生する場合に以下の観点でエクセルVBAはとても扱いづらい。

・バージョンの管理
・使用者へのアップデート通知とその徹底
・メンテナンスを行う人間の教育

バージョンの管理について

エクセルVBAは開発環境自体がエクセルのVBエディタ機能を利用する。
そしてツールのコードは、フォーム、モジュール、クラスと分かれるがこれはエクセル形式として
内部にまとまってしまっている。
これらのコードのバージョン管理をきちんと行おうとすると？
それらをエクスポートして別管理としなければならない。
しかもそれらはまたインポートするなんて手間もかかる。

使用者へのアップデート通知とその徹底

バージョン管理ソフトにツール本体を管理させておいて、周知して最新版を使って下さい。
これならあまり問題はないのだろうが、問題なのはファイルサーバなんかにおいてしまった場合。
エクセルなんて簡単にコピーができる。
どこに派生しているかわかったもんじゃない。
そして、同じ名前が付いたツールを使用者全員が最新版かなんて意識しているほうが珍しいだろう。
最新版とそれ以前のツールを混合して使用された場合、そのツールで一定の品質なんて保てると言えるのだろうか。

メンテナンスを行う人間の教育

メンテナンスを行う人は、いつまでも初期開発者とは限らない。
僕の従事するプロジェクトは主にJavaをメインに扱うプロジェクトであったため
エクセルVBAをコーディングできる人間は割と少なかった。（ちょっと書ける程度の人間は省く）
そういったプロジェクトでメンテナンスできる人間を育てるのは面倒である。

上記のような理由で僕は最近VBAでツールを作成することに少し躊躇する。
これからはなるべくJavaを用いて業務ツールを作成しようと思う。
POI、VelocityをはじめJavaでも実現が可能だから。
あとVBAはOSによっていきなり参照が効かなくなったりするしね。

長々と講釈たれたなぁ。
何年後かに自分で見たら違う意見を持ってたりして恥ずかしくなるんだろうな。