持続可能なVBA

最近「SDGs（持続可能な開発目標）」という言葉が広がってます。是非については、目的と実際の行動とか、建前・本音論とか、色々議論が発散しまくって自分1人の手には負えないのですが、それはそれ。
「物事が持続可能である」こと自体は、その物事が悪（犯罪とか）でない限り、肯定されるべきことでしょう。

なんですが、最近どうも、VBA（ExcelとかWordとかについてるマクロ機能。Visual Basic for Applicationというやつ）界隈で、「そりゃあかんだろ、そんなやり方してたら長期的にはVBAが悪者にされたり、淘汰される原因になるぞ」という話を見かけるので。ちょっとベストプラクティス的なことを書いておこうかな、と思ったわけです。

前提条件

ここに書くのは「継続的に使うVBA（マクロ）」についてです。単発で「目の前にあるデータをちょっと処理したい、使い捨てのマクロでやる」場合は無視して構わんと思います。

・VBAを業務に使う上でやるべきこと

上長の許可をとる（必須）

「どんな作業を」VBAで自動化するか、許可をとってください。黙ってやるのはNGです。事前にやるの推奨。
何故かというと、実際の作業者は「作業というタスクが終われば良い」という視点に縛られがちですが、管理職は「業務が円滑に、かつ安定して維持される」ことを担保する必要があります。
そこで自動化が行われると、「VBAの修正ができなくなったら業務が継続できなくなる」とか「具体的な手順を複数のメンバーで共有されなくなる」というリスクは存在するわけです。もちろん「メンバーの手が空くため、他の作業ができる・残業などが減る」というメリットもあります。
肝心なのは「上記のメリット・デメリットを天秤にかける権限がある人によるGOサインが必要」ということです。
黙って自動化して、何かしらのタイミングでそれが立ちゆかなくなった場合、自動化した人は「その部署の業務を妨害した」に等しい評価を、往々にして得ます。今までうまくいってたとしても、まあマイナスのほうが大きいでしょう。そういうことです。
あと、たとえば貴方の知らないところで、Web版のOfficeとか、あるいはGoogleSuite等、VBAが使えない環境への移行が進行しているかもしれません。そうなった場合、黙ってVBAを作るのに使った時間は、結果として「サボってた」のと同義になります。

セキュリティ設定（必須）

バージョンによって開き方は違うかもしれませんが、
オプション→トラストセンター→マクロの設定で、次の設定をしましょう。
（理想）「デジタル署名されたマクロを除き、すべてのマクロを無効にする」
（現実的な選択）「警告を表示してすべてのマクロを無効にする」

マクロの設定

「デジタル署名を～」は、開発時にデジタル証明書を使用できるならベストです。ただまあ、証明書作るのもお金かかるんで、あまり現実的ではないかなと思います（オレオレ証明書はまた別の問題があるし）
「警告を表示して～」は、実際には警告表示で「マクロの実行」を選べば実行できるので、問題はありません。

まかり間違っても「すべてのマクロを有効にする」とかやってはいけません。やろうとしてる人がいたら力づくでも止めてください。「不便だから」とかいう理由なら特に。
多少の知識があれば、たとえば「そのExcelファイルを開いたら、ドキュメントフォルダにあるファイルを片っ端から暗号化する。解除キーは作者に金を払わないと教えない」みたいなマルウェアをVBAでも作れます。メールに添付されてきた、出所不明なExcelファイルを迂闊に開いたらPCのファイル全滅しました、とか嫌でしょ？
「そんなの迂闊に開かないから大丈夫だ」とか思った人、そういう人が間違って開くんだよ。マジで。全然大丈夫じゃないからな。

ドキュメントを残す（ほぼ必須）

「上長の許可を取る」でも触れましたが、業務継続性は重要です。
マクロの作成者が、いつまで会社にいるかはわかりません。あるいは社内で部署異動するとか、病休を取るとか、事故で仕事ができないとか、本人の意思に関係ない理由でマクロの維持ができなくなることもあります。
そういう場合に、マクロを修正できる人を雇うなり、あるいは誰かに技術として習得して貰うなり、色々と対応策はあり得ますが、総じて「作成者の意図までは伝わらない」ケースがあります。
というか、マクロ作者自身であっても、何日も経てば、細かい仕様やら何やらは忘れます。よほど熟練した人でもない限り、プログラミングの技術も向上するので、昔作ったマクロはただでさえ「イケてない」ことは多々ありまして、その上、実装の意図もわからないのでは修正に支障があります。
（ちなみに、「MicrosoftでWindowsのソースコード書いてたぜぇ」とか「AWSでバリバリにクラウド部分の開発やってるよ」って知り合いが居ますが、「少し前の自分が書いたコードが理解不能」は、そのレベルの猛者でさえも普通にあるそうです。つまり、よほど極まった天才でもない限り、自分の書いたコードの意図がいつでも読み解ける、なんて傲慢な考えを持つべきではありません）

故に、マクロを作成するときは、最低限、以下の情報を残しましょう。

• 前提条件（～にファイルがあること、入力ファイルのフォーマットが正しいこと、等。「フォーマットが正しいこと」には具体的なフォーマットの要件もきちんと書くこと）

• 関連するファイルの一覧

• 内部での具体的な処理（どのような作業をしているか。何ならその文章だけで同じ処理のVBAが書けるレベルで）

• その作業の目的と手作業でやったときの想定時間（マクロが壊れた・業務変更で使えなくなった際のインパクトの把握に必須です）

「いちいちドキュメントなんか作ってる余裕がない」とか「面倒くさい」とか考える人も居るかもしれませんが、自動化という「仕組みの変更」には本来必要なものですし、前述のように手作業に比べて継続性を欠くことがあれば、それはリスクになります。故にドキュメントの作成が必要なのです。

セキュリティ機構として使うな（必須）

VBAでログイン制御するとか、ユーザー認証するとか、ファイルへのアクセスを制御するというのはやってはいけません。
何故かというとVBAは簡単に動作をねじ曲げることができるからです。パスワードプロテクトかけても総当たりで結構あっさり破れたりするし、そもそもパスワードプロテクトをかけているVBAコードでも実行中の外部からのアクセスは可能（例えば別のVBAコードでグローバル変数を読み取る等）なケースがあって、そこら辺を適切に設計するのは至難です。
ぶっちゃけ「セキュリティ上の漏れがない」ことを確認する工数を考えたら、別の言語・方法で作るほうが遙かに無難なので、VBAを使うメリットがありません。
そうでなくともVBAの実行自体を無効化してしまえば、機能不全になるわけで。まあ機能不全ならアクセスできない、という方法論も可能ですが、すべてのリソースにプロテクトかけられるわけではありません。（たとえばVBAを動作不可にして、完全に非表示にしたExcelシートがあっても、外部から読み取ることは簡単にできます。オープンソースのExcel読み取りライブラリ使うとか）

もちろん、必要なセキュリティ強度というのは、守るべき情報の漏洩や破損・改ざんのリスクに応じて定められるべきであって、「割とどうでも良いけど、まあなんとなく全員に見られるのは嫌だなー」ぐらいなら、VBAで作ったセキュリティ機能で良いこともあるかもしれません。
が、裏を返せば、どう逆立ちしたところでVBAで実装できるセキュリティ機構なんてたいしたものではないので、そんなものをセキュリティとして使うこと自体が間違いです。

あ、もちろん外部のセキュリティ機構と組み合わせるならOKな場合はありますよ。たとえばExcel VBAでログインダイアログを出して、入力された認証情報でデータベースサーバーに接続し、データをとってくるとか。
ただ、その場合も「悪意あるユーザーが入力された認証情報を別の場所に保存するロジックを追加するのが簡単にできる」みたいな話は視野にいれる必要があります。
直でアクセスしに行くアプリケーションを使うこととの違いとして、そこを疎かにしてはいけないし、そういったリスクをきちんと洗い出せないなら、セキュリティが絡む分野にマクロは使うべきではないでしょう。

ソースコードにきちんとコメントをいれる（ほぼ必須）

VBAマクロのソースコードにも【きちんと】コメントをいれましょう。ドキュメントに書き切れない細かい実装意図を記載するのに役立ちます。
なおコメントに必要なのは「何をしているか」ではなく「何をしたいか」とか「何故それをするか」です。上で【きちんと】と書いたのはそこで、コメントをいれることが目的ではなく、有益な情報を残すことにフォーカスする必要があるからです。
例を挙げるなら、

CurrentLine = CurrentLine + 2　　　'CurrentLineに2を足す

とか書いてあっても、「見りゃわかるよボケぇ、なんで2を足すんだよ」になるわけです。これが駄目な例です。
対して、

CurrentLine = CurrentLine + 2　　　' 明細はExcelの表で2行単位なので、次の処理に移るため2を足す

これなら実装の意図がわかやすいかと思います。
この違いは、マクロの作成直後にはわかりにくくても、長期間メンテナンスを重ねていくとジワジワ効いてきます。
というか、こういった視点での注釈がないマクロは、どんどんメンテナンスのコストが増大したり、無駄なコードが増えていって手がつけられない負の遺産になりがちです。

ファイルを更新するときはバックアップをとれ（強く推奨）

ファイルを更新するロジックを組み込むのであれば、上書きする前にバックアップをとる処理を必ず組み込んでください。
もし貴方が「フォーマットの変更やユーザーの誤入力など、すべてのイレギュラーを察知して、正しい処理・対応ができる」マクロを書ける、スーパーウルトラセクシィプログラマーだというなら不要かもしれませんが、そんな奴はまずいません。居たら教えてくれ、金いくらでも積んで師事してもらうわ。
で、何が怖いかといえば「ファイルがぶっ壊れる」とか「変な上書きがされる」ことなわけです。そういう事故が起きると、周囲から見れば「マクロ怖いじゃん、危険じゃん」という認識になります。たとえそれが間違った入力により引き起こされた人災だったとしても。
だからマクロでファイルを更新する作業をやるなら、必ずバックアップをとる仕様にしましょう。

メール送信だけは自動化するな（強く推奨）

ファイル更新の話とも被りますが、事故った時の対処というのは重要です。その点、メールの送信、特に外部への送信は「何があっても取り消せないし、なかったことにできない」のです。
もちろん未然に事故を防ぐためのロジックを色々と用意することは可能ですが、それって面倒くさいし、熟練のプログラマーでも案外、漏れがあったりする分野です。況んや「ちょっとVBAが得意です」レベルでは、まず完璧な対応はできないわけです。
故に、メールの送信をマクロで行うのは原則として避けるべきです。まあ社内メールだけなら（部署を跨いだ情報漏洩とかなければ）大丈夫かもしれませんが。

最後に

他にも細かい「これやっとけ」はあるんですが、あまり大量に書くと読む気が失せるドキュメントになりそうなので。

こういう話を書くと「現実的に弊社ではそんなことできない」と言われるかもしれません。私が言えるのは「だったらそこではVBAマクロ使うのはやめとけ、あるいは徹底的に戦ってやれるようにしろ」です。
「やるべきことをやらずにマクロ使ってて事故った」話が出てくると、マクロの評判自体が下がります。下手すりゃ「マクロ使って何かする奴は危険」という風潮の原因にすらなりかねません。というか、既にそういう考えの人は世の中に居て、原因を繙いてみると「不適切なマクロの使い方をした人がいて、被害を被ったことがあるから」だったりするのです。

だからね、VBAが良いモノだって思ってほしければ。あるいはVBAが使えることに価値を見いだしてもらえる世の中にするためには。きちんとした使い方で、価値を出していかなきゃあかんのです。
貴方が「自分だけ楽をして事故り、会社に被害を出しても良いとか、同じ技術を使う人の評価を下げて良いと思ってる、無責任なサイコパス」でない、というなら特に。

続きこちら。