VBA マクロが遅い・速いという議論は、要件ありきの話

VBAのコードについて、よく、この手法は遅いから使うなという話を聞く。高速化万歳！
またはその逆で、高速化のためにわかりやすさを犠牲にするなどナンセンスだ！という話も聞く。

この記事では前者を「$バンザイ」、後者を「$ナンセンス」と呼ぼう。

$バンザイと$ナンセンスはどちらも自分の考えが正しいと信じており、否定しようものなら青筋を立てて反論してくることだろう。
問題はそこにある。あまりにも感情移入しすぎている。

私が思うに、$バンザイと$ナンセンスはどちらも正しくない。個々の要件、シチュエーションが考慮されていないからだ。

$バンザイは、マクロが高々1分速くなったところでビジネス的には大して変わらないという観点が抜け落ちている。
実行に15分かかる処理が14分になったところで、気づきもしないだろうし、そのような高速化にあまり意味はないと思う。
また、月に1度しか発生しない作業なら、2分を1分に短縮したところで高々知れている。
$バンザイは、そのような高速化のためにコードをひどく分りにくくしてしまうことがある。これは全くもってナンセンスだ。

一方で$ナンセンスは、たった1分でも人間は待たされることを苦痛に感じ、ストレスを溜める生き物であるという観点が抜け落ちている。
$ナンセンスは、「業務上の影響」だけを意識するため、5分も10分も変わらないじゃないかと思うようになる。確かに月に数回ならね。
しかし毎日何回も繰り返し実行するマクロでは、5分と10分の差はとてつもなく大きい。
5分と6分で感じるストレスは大差ないかもしれない。しかし1分と1秒で感じるストレスは、1分のほうが遥かに大きい。

3秒と10秒の差も無視できない。一瞬と1秒の差も大きい。

打てば響くようにキビキビ動くマクロは使っていて気持ちいいものである。仕事のリズムが良くなり、集中力が増す。
$バンザイの主張にもうなずけるものがある。

このように、マクロが遅い・速いという議論は、ユーザーが求めるスビード感(つまり要件)ありきの話なのだ。だから、個々のコーディングテクニック、作法を指して、これは遅いから絶対ダメ、これは分りにくいから絶対ダメという主張は鵜呑みにしないほうが良い。

さて、私は最近「ハッカーと画家」という書籍を読んだ。

ハッカーと画家 コンピュータ時代の創造者たち

どの章も面白かったが、特に気に入ったのは第11章「百年の言語」だ。

その中でも格別に素晴らしいと感じた箇所を引用する。

インフラが整った現在では、長距離電話をかけている最中に時間を分刻みで気にするなんて些細なことのように思えてくる。資源があれば相手がどこにいようと電話をかけるというのはひとつの均一な行為だと考えるほうがエレガントだ。
良い無駄と悪い無駄があるってことだ。私は良い無駄のほうに関心がある。贅沢に使うことで、より単純なデザインが得られるような無駄だ。新しい、速いハードウェアのマシンサイクルを無駄に使えるというチャンスをどんなふうに利用できるだろう。

本当の非効率性とは、マシンの時間を無駄にすることではなく、プログラマの時間を無駄にすることだ。コンピュータが速くなればなるほど、このことははっきりしてくる。

※マシンの時間とは、おそらく我々の考える「時間」を指して言っているのではない。CPUやメモリの使用率の話だと思う。

私もこの意見に同意する。これは$ナンセンスが言う、5分も10分も変わらないという意見ではない。
時代の進歩とともに、それはやがて1分になり、30秒になり、一瞬になるだろうという話である。

$バンザイが目指す高速化至上主義が時代によって自動的に解決されるのであれば、これからのプログラミングはわかりやすさ、メンテナンスしやすさ、プログラマの効率にフォーカスを当てたものになるだろう。

だから、原則としてはより抽象化されたメンテナブルなコードをデザインすべきだと思う。
$ナンセンスはここでしたり顔で「ほらね」というかもしれない。

でもそれは違う。

現代においては依然としてそのような高速化は実現されておらず、たとえばExcel VBAではセルを個別に読みにいくような処理はすこぶる遅い。
そこで、配列転記のような高速化テクニックが必要になってくるわけだ。

でも最初から高速性ありきで考えるのではない。
まずはエレガント!!なグランドデザインがあり、求められるパフォーマンスが出ないときのチューニングとしての高速化テクニックを使用するのだ。

マクロの速度に関する議論は要件ありき。ただし、高速化テクニックはあくまでパフォーマンスチューニングであることに留意したい。コンピューターの、あるいはExcelの過渡期における必要悪である。決してそれがグランドデザインであってはいけない。