Excelでのマクロ作成時に、マクロ記録の位置づけをどうすべきか。現時点の考え方をまとめてみました。

正直に言います、私は長い間マクロ記録支持派でした

20代の頃から、独学で細々とExcelマクロと付き合ってきましたが、つい最近まではマクロを作る際には、マクロ記録を積極的に活用すべきというスタンスでした。

大枠の部分をマクロ記録で作成し、その上で条件分岐や繰り返しなどのマクロ記録で作成できない部分を、修正しながら作っていけばよいという考え方です。

ところが、昨年末頃にふと気づきました。「そういえば、Excelのマクロって最初から全部自分でかけるんだろうか?」と。

このように考えたきっかけは、昨年業務効率化を模索して、RPA(UiPath)やプログラミング言語(Python)に手を出したのですが、結局どれも中途半端に終わってしまい、そこで「そもそもExcelマクロをきちんと理解できているのか?」と自問したことでした。

いざマクロを作ろうとすると、マクロ記録してその意味を毎回調べるので、とてつもなく時間がかかる。時間がかかるので、積極的にマクロを活用しようという気になれない、という悪循環に陥っていたわけです。

そして、「マクロ記録ばかりしていたら、自分でコードを書く力がつかない。マクロ記録に頼るやり方では、マクロを効率的に作れない。」という考えに至りました。

どんなときに困るのか? コピー&ペースト編

マクロ記録を使うと、コードを書く力が身につかず、マクロを作成する時間を短縮できないこと以外にも、問題点はあります。マクロ記録でマクロを作成すると、コードが長く複雑になり、後のメンテナンスに問題が生じることです。

この点を簡単な例で確認してみましょう。

セルA1に「100」という数字が入っていて、これをセルC3にコピーする操作をマクロ記録で作成すると、次のコードが記録されます。

「これで何か問題があるの?」と思う方もいらっしゃるかもしれませんが、マクロでのコピーの文法をきちんと学ぶと、これは次のように書くことができます。

もしくはさらに省略して、次のように書くこともできます。

要するに、マクロ記録だと4行になるコードを1行で書くことができるわけです。

マクロ記録でマクロを作成すると、セルを選択する操作がすべて記録されてしまいますが、マクロを書く際にはセル選択の操作は不要なケースが多くあります。

「それでもきちんと動くなら問題ないのでは?」と思われる方もいるかもしれませんが、実際の業務で使うようなマクロは4行程度で済まないことがほとんどで、セル選択の操作が多くなると画面の切り替わりも増えて、マクロの実行速度が遅くなることもあります。

何より、マクロの行数が長いと、読み解くのに時間がかかり、メンテナンス性がよくありません。マクロの修正・変更が必要となったときに、時間がかかってしまうと、「手動でやった方が早い!」となってしまい、結局マクロを使わなくなってしまう恐れがあります。

結局マクロもプログラミング。その覚悟で臨むべし。

マクロはExcelに付属しているため、プログラミング言語という認識を持ちにくい部分がありますが、コードを書いてソフトウエアを動かすわけですから、れっきとしたプログラミング言語です。

重箱の隅をつつくような内容を学ぶ必要はありませんが、やはり基礎はきちんと学ばないと本当に活用することはできません。

コードを書く力が身についていないことに気づいた後、「まずExcelでどこまでできるのかきちん学ばないと、RPAやプログラミングを学んでも意味がない」と考え、昨年12月から1月にかけて、マクロのセミナーを受講しました。

きちんと学んだことで、「Excelの中で自動化すべきことはマクロを使い、Excel以外との連携部分はRPAを活用する」という方向性が自分の中で明確になりました。 このスタンス、書いてしまうと当たり前のように聞こえますが、ツールが色々あると、どのツールをどこで使うか悩むため、自分自身の立ち位置を明確にしておくことは重要です。

そして、「マクロに取り組む場合には、入門用のプログラミング言語を学ぶという意識を持つこと」、いろいろ回り道しましたが、これが今の結論です。

ちなみに、マクロ記録を全否定するつもりはありません。色や罫線のコードなどは、覚えるよりマクロ記録で調べた方が早いですので、その点最後に付け加えておきます。