持続可能なVBA・Extended

下記「持続可能なVBA」の補遺として。
読んでない方は元記事を先に読んでください。

VBAでやってはいけないこと

本質的には元記事も「べからず集」でもあるので、こちらでは「やってはいけないこと」に絞ります。

悪いことをするな（絶対）

いやまあ、当たり前なんだけどね。
個人的には労力そのものに価値は全く感じないので、別に自動化を「サボり」とは思わないのですが。それでも業務指示に従わない、とか、自動化すべきでないモノまで自動化するのはNGですよってこと。

勤怠ソフトの打刻の自動化とか、本来人間がやらなきゃいけないチェックの自動化とか、そういうのだよ。ドリフのコントのフリじゃなくて、絶対にやるなよ。VBAユーザーの評判がどうこう以前に、法的な責任を負わされる、ことと次第によっちゃ前科持ちになるぞ、マジで。
人間がやらなきゃいけないチェックも、たとえ無駄に思えても、法令とか内部監査とかの絡みで「必須」になってる可能性があるから、それを現場の判断だけで勝手に自動化するのは、本当に危険なことなのです。（法令そのものに無駄があるケースもあるけど、だからといって法を破って良いものじゃあない）

パスワードや認証情報を埋め込むな（絶対）

表記の通り。何かしらの「自動ログイン」とかはVBAでやるべきではない。理由は主に2つ。
1つ目は、VBAのコード自体が秘匿性が低いので、パスワード等が誰でも読める状況になってしまっているのに等しいから。
2つ目は、VBAの実行者＝作者が意図した人物とは限らないから。つまり権限がない人が勝手に使う可能性があり、それが発生した場合、VBAの作者も加担してるに等しい状況になるから。そんなことが起きれば、それは「セキュリティインシデント（あるいはセキュリティ事故）」です。大げさでも何でもなく。
つまるところ「パスワードの共有はしたら駄目ですよ」というIT教育の基礎で必ず出てくる話の延長線上の話なんですがね。

どうしてもVBAで認証情報を使いたければ、ダイアログを表示する等で、都度入力させるべきでしょう。
あるいは、それが嫌なら資格情報マネージャーから取得させれば宜しい・・・ことはあります。まあWindowsに保存した資格情報なら、最低限、そのWindowsユーザーがログインできているわけだし、リスクは幾ばくか下がるので。コードの手間はかかるけど、VBAからでも、Windows APIのadvapi32.dllのCredReadとかCredEnumerateとか使えばとれるよ。

それでも（資格情報マネージャーを介す場合でも）最低限、上司と情シスの許可はとってからやるように。基本的には「やるべきではない」振る舞いなので。

テストの手を抜くな

テストはきちんとしましょうね、という話。

まず、コードカバレッジという概念があります。ざっくり説明すると、プログラム（この場合はVBA）のソースコードの、どれだけを実際に動かしてテストしたか、ということ。
分岐とかのない一本道なコードなら、1回、最後まで実行すればカバレッジは100％になりますが、普通は何らかの条件分岐はあります。
単純に「If～Then～Else～End If」のブロックが1つあれば、If文の条件式がTrueの場合（Then側）とFalseの場合（Else側）の2回、そこのコードが走らないと、テストを完遂したことにはならないわけです。

で、残念ながらVBAでは、システマチックにコードカバレッジが100%になっているかどうか、テスト中に計測する機能はありません。なので、内部にある条件分岐から、必要なテストケースを割り出して、漏れなく実施する必要があります。

OK？きちんとテストはするんだよ？

あと、テストに必要なデータとか、どのようにテストすれば良いかの資料も、きちんと残しておくこと。そこも含めてテストです。

「テストが無理だ」という部分があれば、少なくともそれは「テストされていない」ということの合意を、別途、然るべき関係者から取る必要があります。だって怖いでしょ？テストされてないモノなんて。

余分なことをするな

個人で遊びで作るマクロなら、どんな遊びを入れようと自由だけど。
業務で作るマクロであれば、余分な機能を入れてはいけない。たとえばイラストがピコピコ動いたり、不要なメッセージが出たり。
理由は「有事の際は、外部に解析や修正を委託することがある」から。まずそんなもんの解析を依頼する側が恥ずかしい思いをするし、それ抜きでも「その機能は妥当なのか？」「必要性はどうなっているのか？」とか真面目に検証させることは、会社に全くもって不要なコストを強いることになる。

「ドキュメントは必ず作れ」と、以前の記事に書いたけど、そのドキュメントに、遊び要素まで仕様として組み込む、までやるなら、まあいいけどね？それで上司とかが、自動化の仕様として承認してくれるなら。

「車輪の再発明」はするな

「車輪の再発明」は、既に解決策（プログラムとか機能とか）があるものを、ゼロから作り直すことです。詳しくはWikipediaを読んでね。

他のプログラムでできる、或いは（費用対効果に見合わないような、よほど高価でなければ）既成の製品やサービスでできることを、開発するメリットは基本的にあまりありません。
自己研鑽のために作ってみる、みたいなのは大いにアリなのですが、業務として作る・使うのであれば、それはただの時間の無駄です。居眠りしてるのと大差ないのです。

Internet Explorerに依存するな

本稿執筆時点で「数ヶ月後には消える」ものなので、今から作るのであれば依存させるべきではない。ついでに、もし貴方が「Internet Explorerに依存したマクロを業務で作って使っている」なら、とっとと改修しないといけない。

当然だが

CreateObject("InternetExplorer.Application")

とか、Microsoft HTML Object Libraryに参照かけるのとかも駄目だよ。

まずもって、サポートが切れる（切れた）ものを業務で使うこと自体が、非常にリスクが高い。ついでに、Internet Explorerの廃止（OSのアップデートによる削除）後は、VBAでやっている操作をIEで検証することが非常に困難になる。（抜け道はなくもないが、正規の手段ではないので肯定されるべきではなかろう）

まあ、Active X経由よりは手間はかかるけど、SeleniumとWebDriverいれれば似たようなことはできるから、そっち使えばいいんじゃね？EdgeでもChromeでもFirefoxでも動くよ。

あ、会社の方針でWindow 7のExtend Support使ってやってます、とかなら、まあIEでもいいんじゃね？とは思います。それでも期限はあるけど。

最後に

いやね、最初は本当は、コーディング的なもの（「Variant・Objectは極力使うな」とか）も書こうかな、と思ったけど、それは探せば色々書いてあるから、あえて書かなくても良いかな、と思った次第。

それでも、ここまで読んで「うへぇ」と思った人は結構多いと思う。

あと「面倒だなぁ」とか。そうなんだよ、VBAって面倒なんだよ。まあVBAに限らず、業務のためにプログラムを作るって、そういうことなんだ。
残念ながらこれは、数年レベルではまずもって無理、もしかしたら数十年後には解消してるかもね、ってぐらいの、いわばプログラム開発という作業からは切っても切り離せない命題だと思う。
（何しろ、実は、前記事や、この記事に書いたことの大半は、「VBA」を「ノーコード・ローコード」とか「RPA」とか「PowerShellやバッチファイル」に置き換えても通用するのです。つまり実は「VBAに限った話」ではいんですよ）

ところで。実は、その面倒さを軽減する方法が、実は1つだけある。
それは「運用・保守する人や、その周囲との信頼」だ。

たとえばドキュメント。「どこの誰が見るかわからないフォーマルな内容」よりは、「同じ部署に居る、自分と同等以上にVBAができる人」が見る前提なら、多少、フォーマットがいい加減だったり、部署や会社内にある「暗黙の了解」を省けたりすることはある。
あるいはエラー対策やリスク回避についても、「自動化によるメリットが享受できるなら仕方ない」という合意や、あるいは「あの人が作ってるなら大丈夫だろう、何かあっても許そう」という関係性があれば、多少踏み込んだことがやりやすくなる。そういうものです。
もちろん程度問題だけどな？「法的・倫理的にやっちゃいけないこと」は絶対にやっちゃいけないし。

こればかりは、組織の環境や人員、置かれている立場などが千差万別なので、何とも言えない部分はあるけれども。それでも「周囲（自動化によって影響を受ける関係者）から理解されているか、良い関係を築けているかどうかで、自動化の難易度は少なからず変わる」ことは、忘れないでいて欲しいと思うのです。
VBAや自動化を悪者にしないためにも、職場や同僚に迷惑をかけないためにも、そして貴方自身を守るためにも。