はじめにと言う名の記事の目的
約1年ぐらい常駐していた勤務地から新しい職場へと異動しました．
新しい職場ではGitを使ってバージョン管理をし，Dockerを使って環境構築をし，マークダウンで資料を作成する．連絡事項はSlackを使ったオープンチャット，という割と今時の職場．勤務体系はフレックスで，私服で問題なし．エディターも好きなものを使ってよく，おすすめなものや技術はお互いに教えあっています．
そのような環境になったおかげで，今までの環境がどれほど時代錯誤だったのかを痛感しました．
しかし，そんな環境にいたからこそ，現実というか，この業界のリアルな部分に触れられた気がして楽しかったことも事実としてあります．
なかでも，VBA開発における知見は自分の中で相当蓄積され，割と気軽にポンポン作れるようになったのは大きな財産です．
今回はそんなVBA開発においてホント糞だったというか大変だったものを７つ提示したいと思います．そして，もし同じような境遇に陥った際の覚悟を決める材料にしてほしいなと思います．
これは注意しろシリーズ
Excel（もしくはWindows）のバージョンが違う問題
トップバッターはこれ．
私のいた環境ではExcel2003とExcel2007，Excel2010が稼働しており，またそれを扱っているOSはWindowsXP，もしくは7というカオス空間と化していました．
しかしそんなカオスでも，ツールは正常に動作しなければいけません．
そんなときどうするか．
楽なのは一番バージョンの低いExcelでマクロを制作することである．
Excelは多くのソフトがそうであるように，下位互換なんてものはほとんど機能しません．使えないこともないのですが，100人規模で使われるマクロでは当てにできるものではありません．しかし一方で，上位互換は下位互換と比較してしっかりしているため，一番バージョンの低いもので開発するとうまく行きます．
しかし，それで全てが解決するのであれば苦労はない．
Excelの機能の中では互換性がないものはゴマンとあり，中でもハマったのは「色」と「図形」．
この2つは割と何気なく使う上に，マクロに関係ない（表示に使ったり，項目の強調に使ったりするだけで実際にマクロで編集しない）にもかかわらず，うまく動かない原因である可能性が非常に高かったです．
実際に起こったのは，
- Excel2003では正常に動作し保存したものが，Excel2010では破損扱いになっている．
- Excel2003で作成したものがExcel2010だと数時間経っても開けない．
- 同じマクロなのにExcel2003とそれ以外のバージョンではマクロ実行時間に大きな差がある．
調べると，マクロでのファイルオープン，クローズの際，互換の修正が入るそうなのですが，それがうまく起動しないために発生するバグらしいです．
このパターンになってしまった場合は，それぞれのバージョンで開いた上で，Excel2003と互換性がある「色」だったり「図形」を選び，再度Excel2003で試してみる．といった方法を取っていました．
互換性の問題なら，メーカーが保証しているものだけを使えばなんとかなるだろと言った考えで，実際なんとかなります．その前にバージョンぐらい揃えろ
マクロ途中で落ちる問題
これもExcelのバージョンが違うことによって発生するバグなのですが，実際はExcel2010固有バグなので別枠にてご紹介．
Excel2010では，マクロ実行中にオープンクローズを100回以上繰り返し行うとリソース不足によってマクロが途中で落ちてしまいます．
そのため，ちょっとした細工が必要になるのですが，具体的な対処法は公式が言及しているのでそちらを参照してみてください．
Windows 7 および Windows Server 2008 R2 環境の Excel 2010 または Word 2010 で、連続したマクロ処理を実行するとマクロが停止する場合がある
私の場合はこのサイトに書かれている
方法 2 : DoEvents 関数をマクロ内に挿入する
でだいたい解消していました．
最初は原因がわからずひたすら頭を抱えていました．
その後解決策がわかっても，なんだかコードが汚くなるのでちょっと別の方法ないのかなと思ったりもしたのですが，背に腹は変えられずこの方法で対処しました．
日付問題
これはVBAを業務利用したことがある人なら，誰もが一度はハマる問題ではないかと思っています．
VBAの日付問題は闇が奥が深く，特にわけのわからない数式とただの文字列と関数が入り乱れているファイルに対して操作しようものなら地獄です．
色んなサイトでこの問題について取り扱っていますが，個人的にはこちらの記事をいつも参考にしていました．
比較がわかりやすく，結局うまく行かないこともあるということがわかります．本当におせわになりました
この問題はしょっちゅう遭遇する割には，状況によって解決策が異なるので，うまくいかないときは思い切ってファイルの方を変えて固定してしまうのもありだと思っています．
Option Explicitがない問題
その場でしか使わないような一時的なマクロであれば目くじらを立てる必要はありません．自由に書けばいいと思います．
ただし，他人の成果物に触れる場合，二回以上の使用が確定している場合は必ずつけましょう．
間違っても，他人に配布するツールに「Option Explicit」を記述せず納品するのはやめましょう．
デバックするときは大変ですし，自分以外が修正する場合はもっと大変です．
実際，「Option Explicit」がない負の遺産を見つけたとき，挙動を追うのに想定以上の時間がかかり苦労しました．
人にやさしくすると自分にも帰ってきます．その逆も然りです．
同様に不用意なVariant型の連発もやめましょう．便利さは諸刃の剣であることを知っておくべきです．
もし「Option Explicit」を知らない場合はこちらを参照ください．
マクロ高速化がんばりましょう問題１
マクロ作成に慣れてくると，Selectして，Copyして，Pasteするといったコードを見るだけで吐き気を催します．
邪悪なコードだ．すぐさま除菌をしなければ...
そこでよく出てくるのが配列にぶち込むか，コレクション型を使うかの二択と思いますが，私は直感的でわかりやすい配列をよく好んで使っています．
しかし，まぁ，諸事情により，配列よりコレクション型のほうが楽な場合も多々あります．例えば，Map型で管理したいだとか，List型で管理したいだとか．
そういうときは参照設定を使わずに「Object」で型宣言しましょう．
たまに，Excel2010で開発されたコードを見ると参照設定を使って「New」でコードが書かれていたりしますが，Excel2003では非対応です．初見だと割とハマりやすい罠なため気をつけると良いかと思います．
マクロ高速化がんばりましょう問題２
マクロ高速化とググると色んなサイトが出てきます．
実際に速度を検証しているサイトなどもあり，これが良い，あれが良いなど書いています．
しかし，それらの記事のとおりに実装してもあまり速度性能が上がらないときがあります．
なぜか？
環境が，扱っているファイルの中身が，違うからです．
当たり前ですけど，本当に見落としがちです．しかも，急いでいるときなどはろくな速度検証なんてしないので，
「なんかそこまで速くないけど，まぁいいか」
となります．なりました．
そこで是非とも「Debug.Print Time」を一行加えて検証してみてください．
取り扱うオブジェクトの数や実装方法，PCスペックなどにより，なぜか配列とかコレクションよりただのペーストのほうが速かったりします．そういったときの徒労はなるべく少なくしたほうが健康的な社畜ライフを歩めます．
Excelファイルのフォーマットやらシート名やら変更しちゃう人
もうヒューマンエラーで技術的な問題でも何でもないですが，プロジェクトによってはいます．そして，ある意味一番厄介です．
なんでマクロで自動化しているファイルをコードの中身も見ずに変更するのか理解できませんが，仕方ありません．
そういうときは勇気を持って注意しましょう．いくら下っ端でペーペーの新人でも成果物には責任がつきまといます．
非推奨の操作をした上で言いがかりをつけられた日には自分の評価にも繋がります．
毅然とした態度で立ち向かいましょう．
大丈夫．
VBAが何かがわかっている人はみんなあなたの味方です．
おわりに
本当は実際にコードを持って示したかったが，大人の事情によりそれができず片手落ちのような記事になってしまって申し訳なく思います．
Excelはまだまだ多くの会社で使われており，そして使っている人の大半はVBAなんて名前しか知らないような人ばかりです．実際に使えるようになれば，虚無しか産まないような作業でも多少のコーディング力向上に繋がります．また，簡単なツール程度であればコーディング規約もないので趣味プロのように書けます．（私はどこまでワンラインコーディングできるかで遊んでいました）
今後業務でVBAを使う予定の方も，もう結構使っている方も，この記事が何かの一助に慣れれば幸いです．