VBA 他人のコードはどうせ誰も読めないという前提に立って考える

この記事は事務員・運用担当者など、非開発職の方々を対象としている。
プログラマーとして雇われ、業務でプログラムを作成している場合はここに書いていることは当てはまらないので注意してほしい。

さて、VBAでは、IfやForなどの基本的な構文と、RangeやWorkbooks、SheetsといったExcelオブジェクトの基本的なメソッドの組み合わせだけで、色々なマクロを作ることができる。

このブログではClassモジュールやPropertyなどの利用方法なども説明してきたが、本格的なプログラマーならともかく、事務や運用でプログラミングをしているとそこまで高度な技術が必須というわけではない。

ではなぜそれを承知であえてブログで紹介しているのかというと、必須ではなくても非常に役に立つからである。

もし高度なテクニックが無かったら

入門レベルの知識で、ある程度高度なマクロを作成しようと思うと、だんだん頭がこんがらがってくる。
もちろん、できないことはない。ただ、複雑な概念を平易な言葉で説明するのが難しいように、複雑なマクロを入門レベルの知識でどうにかしようというのも非常に難しいことなのだ。

そのマクロはきっとIf文だらけで、変数がいくつあるのか、何に使われているのかわからず、一つのプロシージャで軽く200ステップを超えるものも出てくる。

そういった複雑さをより扱いやすくするためにFunctionプロシージャがあり、モジュール分割の考え方があり、Classモジュール、Propertyプロシージャなどの高度な機能が用意されている。いちおうインターフェースもある。

そんなものを使ったら、他の人がコードを読めなくなるという批判もある。
しかし、たかがマクロといってもある程度複雑なプログラムは存在するし、そもそも他人が作った数百ステップもある複雑なプログラムなんてもともとVBAの初心者には読めないだろう。

問題は、そのようなごちゃごちゃしたコードは、自分も読めなくなるということ。
Selectの中身が100ステップを超え、さらにその中のIfが複雑にネストしてループまで入っていたらもうお手上げだ。
一か所直すだけでも場合によっては解読に丸1日かかってしまう。

高度なプログラミングテクニックはそれらの複雑さを軽減してくれるし、一度概念が身についてしまえば何年かしてコードを見返してもスッキリ理解できる。

マクロはあくまで補助手段

マクロを作りはじめるきっかけは、自分の業務を手早く終わらせたいというのが最初の動機である。会社の業務改善の為などと本腰を入れて勉強する人も居るかもしれないが、圧倒的に多いのは面倒くさい仕事を少しでも楽にしたいという極めて個人的な理由である。

マクロを少し覚えたら、自分だけが使う小さなツールを作成する人が多い。この時点ではまだ自分の個人的なツールだから、多少バグがあってもクリティカルな被害を出さないのであれば、使うときに気を付ければ良いと考えるかもしれない。

そのうち同僚にシェアしたくなる。バグを修正し、誰でも簡単に使えるようにボタンやフォームなどのユーザーインターフェースを用意する。そして実際に同僚に使ってもらったところ評判が広まり、やがて部門全体で使われるようになる。

問題はここからだ。マクロで業務を便利にするのは良い。でも決して、業務をマクロに依存させてしまってはいけない。既存業務のやり方が変わったら、マクロで対応するだけでなく、人手で対応する場合の手順もメンテナンスしておく。

マクロはあくまで補助手段としておくことが肝心だ。なぜなら自分がいなくなった後、そのマクロがメンテナンスされる可能性は極めて低いからだ。

どうせ誰も読めないという前提に立つ

Excel VBAは特殊な境遇にあると思う。CやJavaのように系統立って解説された書籍が少なく、逆にアマチュアプログラマーがネットで配信している記事をベースに学習している人も多い。だから学習者のレベルもまちまちで、IfとForとマクロの記録を組み合わせてなんとかプログラムを作るというレベルから、少し関数やプロシージャの分割を覚えた人、マイナーな機能も駆使して効率よくプログラムを組める人まで様々である。

この状況に対するアプローチは2つある。ひとつは自分の後任者がメンテナンスできるように、易しい文法・機能だけを用いてプログラムする方法。もうひとつは、どうせ他人のコードは誰もメンテナンスできないという前提に立って、自分にとってのメンテナンス性だけを考えて高度な機能も積極的に用いてプログラムする方法である。

このブログはもちろん後者の立場である。

実際に、基本的な分岐・ループだけを用いて作られたプログラムをメンテナンスしたことがあるけれど、相当に難しかった。コードが部品に分かれていないので、どこを直すとどういう影響が出るのかさっぱり掴めないのだ。分岐とループだけしか使われていないとはいえ、基本的な知識だけでプログラムを組んでいるレベルの方にこれをメンテナンスするのは無理があるだろう。

つまり、高度な機能を使おうと、基本的な機能だけで書こうと、どのみち誰も他人が書いたコードなんて理解できないのだ。もちろん読める人だっているからこれは事実ではない。でも他人のコードは読めないものだと仮定して割り切ってしまった方が対策はシンプルになる。

問題は、業務をマクロに依存させてしまうことである。マクロはあくまで業務を手早く終わらせるための、個人的な便利ツールに過ぎない。業務の変化に合わせて未来永劫メンテナンスしていこうなどと考えるからおかしくなる。そういうことは、業者にお金を払ってきちんとしたシステムでやることなのだ。

マクロとの正しい付き合い方

マクロのメンテナンスは作者一代でおわり。その人が辞めたら、使えるところまでは使って、あとは業務の変化に対応できなくなった時点で捨てる。もちろん運よくメンテナンスできる人がいればしてもらえば良いし、作り直してもらう手もある。しかしそれでも所詮個人ツールの延長にあるものなので、いつかは捨てるつもりで使うのが良い。

要はパッケージソフトの考え方である。業務が変化した時点でそのソフトでの対応が困難になることはよくある。新バージョンがそれに対応していなければ、代替製品に切り替えるか、我慢してむりくり使うしかない。

知識さえあれば、マクロは他の人でもメンテナスできてしまう。そのことが、マクロのメンテナンスを引き継ごうなどというおかしな考え方を生む。マクロ作者にメンテナンスを引き継ぐ義務はないと思う。

ただし、現状復帰義務はある。業務の変化にマクロのコード変更だけで対応してしまった場合は業務手順が実質コードの中にしか存在しないことになる。これは業務がマクロに完全に依存しており、マクロなしでの業務遂行が実質不可能になってしまう。この状況を自分が作り出したのなら、マクロのメンテナンスを引き継ぐなり、手動で対応するためのドキュメントを用意するなりといった対応はするべきだろう。

先にマクロはあくまで補助手段としておくことが肝心だと述べたのは、そういうことである。

もっと自由にプログラミングして良い

もしあなたがプログラマーとして雇用されているのでなければ、マクロ作成は業務命令ではないだろう。だったら、マクロの引き継ぎのことなど考えなくて良い。
どうせ誰もメンテできないという前提に立てば、使って良い機能・悪い機能ということを考えなくて良くなる。

仕事は遊びではないが、それでも楽しく働くに越したことはない。マクロを書いて自分の手で業務を改善するというのは楽しい作業である。「好きこそ物の上手なれ」というが、まさにそういうことで、楽しんでコードを書くから上達し、さらに業務改善できるようになる。

より良いやり方、楽なやり方を知っているのにそれを制限するというのは苦痛だ。コーディングを楽しむためには積極的にVBAを学び、新しい知識を試してみて、上達を実感することである。

正しく学び、リスクを理解して使う分には、どんな機能でも自由に使えば良い。もっと自由にコードを書いて良い。

おわりに

冒頭でも述べたがここで書いたことは全て、個人的な業務改善の延長としてマクロを活用する話である。プログラマーとして給料をもらい、製品としてマクロを開発している場合は当然、自分以外のメンバーが見て何が書かれているのかを把握できる必要があるし、コードの細部まで引き継ぎを行う必要がある。

また、自由に書いて良いと述べたが、自分で理解できないコードは使うべきではない。いくら業務が効率化してもバグの混入で業務上の損失を出せば信頼は地に落ちる。自分が完璧に理解しているつもりのコードでも、そうしたことは起こり得るのだ。まして自分が理解できないコードをそのまま利用するなんて危ないことはやめておいた方が良い。

最後に、この記事と正反対の主張がなされている「迷惑をかけないExcel」という書籍を紹介しておく。

迷惑をかけないExcel

この書籍では、業務だから他人にメンテナンスできないようなコードは書くべきではないと主張されている。

しかし私はむしろ、業務をマクロに完全依存させてしまうことが問題であり、個人的に行った改善がたまたま会社全体の業務効率化につながったとしても、それを恒久的に使い続ける前提は間違っていると思う。

会社が正式なツールとしてメンテナンスしたいと思っているなら、作者に正当な対価を支払ってプログラマーとして雇い直し、他のプログラマーでもメンテナンスできるようにドキュメント作成の義務を課せば良いのだ。その人が辞める場合もドキュメントとソースコードがあれば他のシステム会社に依頼するなり、新たにプログラマーを採用するなりできる。

ただし、何事も鵜呑みにするのは良くない。反対の主張を読むことで複眼的な思考が養われるので、ぜひこの本も読んで見てほしい。