これはExcelVBAに限った話ではないと思うのですが、何も考えずにある程度の規模のツールやシステムを作ろうとすると、コードの行数がどんどん膨張していってしまいます。
コードが無駄に増えすぎると、後で仕様変更があったりバグの修正をしなければならなくなったときに直すのが大変になってしまいます。
こういった問題を解決するためにいくつか方法があるのですが、例えば同じようなコードが何箇所にもあった場合、CallやFunctionを使って別プロシージャを作ってコードを共通化するといったやり方があります。
また、多くの箇所で変数を使っても、一番最初の部分で中身を入替えるだけでそれ以外の箇所全てに反映されるようにすれば、変更する箇所は最初の大元の一箇所だけで済む、というやり方もあります。
ツール・システム作成後のメンテナンスのしやすさ、労力を考慮するとなるべくコードは短く単純な方がいいわけです。
自分は今までいろんな本やサイトを見てきましたが、基本的にはコードを短くする必要性や理由については、ここまで書いてきたようなことが書いてありました。
しかし、最近になって気づいたことがあります。それはコードを短縮化するよりも「そもそも記述するコード自体をなくすことができればいいのではないか」ということです。
このことについて自分が気づいたことを書いていってみます。
ExcelVBAで一般的に言われているコードの短縮化の方法
これはExcelVBAを勉強してきた人であれば、コードの短縮化という点において次の事はよく見かける内容だと思います。
- 同じコードは別プロシージャに分けて共通化する
- 長文のコードは変数に置き換えたり、withステートメントで短くする
- For…NextやFor…Each、Do…Loopなどの繰り返し処理のコードや配列を使う
以上の具体的な内容については別サイトに詳しく書かれているので説明はそちらにお譲りしますが、ある程度以上の規模のシステムをつくろうとすると「コードの短縮化」というのはいろいろ重要になってくるわけです。
例えば全体で1万行のコードでできているシステムがあって、そのコードの中で10箇所に同じコードが10行ずつあったとします。これを別プロシージャに分けてcallで呼び出せるようにすれば全体で90行ぐらいは減らせます。
Withを使えば、最初のオブジェクトのコードの部分だけ抜き出せて横に長いコードを短くできるので、行数はそれ程変わらないかもしれませんがコードの可読性は上がります。
For…NextやFor…Each、Do…Loop等を上手く使えれば、例えば1から100までのコードを全部記述する必要はなくなります。もちろんコードの短縮化、可読性の向上のためには上記以外にもたくさんの種類のコードがあります。
自分も今日までいろいろなツールを作ってきましたが「コードの短縮化」のためにコードを工夫して記述するというのは、プログラマーにとっては非常に重要な能力のひとつだと感じています。
自分が実際にコードをVBE上に考えながらコードを記述できるようになる前、VBAというものを全然知らなかった頃は「コードを記述できる」というだけでとんでもなくすごいことだと思っていました。
しかし実際にVBAを勉強してそこそこコードを記述できるようになってからは今回の件でもそうですが、「全体を考えてコードの記述も工夫する」ことも重要なんだなと考えられるようになっていきました。
きっかけはツールを使う対象のフォーマットが新しくなった時
少し前に、とあるフォーマットのチェックツールを作っていたときのことです。このフォーマットの指定の部分をVBAでチェックできるようにして、不備があった場合はその部分を別シートに記録、何も問題なければ通過させる、みたいなツールを作っていた時がありました。
このフォーマットのチェックツールを作り始めてすぐに新しいフォーマットに変わって、自分が作っていたツールのコードもそれに合わせて修正しなければならなくなりました。
フォーマットの内容が一部変わったのだから、それに合わせてコードも一部修正しなければならなくなるのは当然です。今までの例を考えるとツールの依頼者からの仕様変更と同じようなものだと思っていたので、最初は「あぁ、面倒くさい。またか・・・」と思っていました。
けれども今回は違っていました。確かにフォーマットの内容は変わっていたのですが、それによって既に自分が記述していたコードから数百行ぐらい削除できる部分があったんです。
この時は結構感動したというか、「あぁ、こういうこともあるんだな」と思いました。なぜこんなことが起きたかというと、新しいフォーマットはExcelを使っていたのですが、そのシートの中で上手い具合に「関数」が使われていました。
例えばAの場合はA1セルに「1」が入って、Bの場合はB１セルに「2」が入って、それがフォーマットの指定の箇所に自動で入るような仕掛けになっていました。
これをVBAでやろうとするとひと手間、ふた手間かかるような内容なんです。しかしそれが関数によって既に処理されているので、その分のコードを記述する必要はないというわけです。
もうひとつコードの短縮化に繋がったと思うことは、フォーマットが以前と比べて整理された、見やすくなったということにもあると思っています。
以前のフォーマットは、なぜだかわかりませんが微妙に配置がずれていたんです。A1セルに「1」を入れたらA2セルに「2」を入れればいいのに、B3セルに「2」を入れさせるみたいな構成になっていました。
最初は自分も「なんでそこなんだ？」と突っ込みたくなりましたが、依頼されたものを作るしかないと思い込んでいたので、とにかくフォーマットに合わせてチェックできるようにコードを記述するしかありませんでした。
しかしこれが、新しいフォーマットへの変更でちゃんと入力欄が整然と並べられるようになったので、全部の箇所をコードで記述するのではなくFor…Nextで記述できるようになったという感じです。
そもそも事前に関数の駆使やフォーマットを標準化しておけば、コード自体を書かなくてよくなる
ここまで書いてきたように、「コードの短縮化」には「コードの記述を工夫する」というプログラマー側の工夫が必要でした。
けれども、Excelのフォーマットで「関数を上手く使う」といった方法や「フォーマットを標準化する」と言う風に「ユーザー側」の工夫でも「コードの短縮化」は図れるわけです。
システムを作った人ならわかると思うのですが、やはりコードが長くなるよりは、短く出来たほうがメンテナンス的にも労力的にも楽になります。
このブログでは以下のような過去記事を書いてきました。
引用した過去記事では、どのような業務をVBA化するとより業務効率化が図れるのかについて書いてあります。
例えば月に1回しか発生しない月次業務よりも毎日発生する日次業務をVBA化した方が業務効率化が図れます。更に言えば、日次業務の中でも手間がかからない業務よりも手間がかかる業務をVBA化できればより業務の効率化が図れると言えます。
そのようなやり方や考え方を補完するという意味で、今回の件は非常に勉強になりました。
例えば手間のかかる日次業務があったとします。その業務はExcelを使っており、VBAで自動化したいが関数や標準化はあまり駆使されていないということであれば、まずはそこから手をつけてみた方が良いかもしれません。
その部分に手をつけた後であれば、さらにさらに楽にVBAで効率化が図れて、業務をする人もより楽ができるのではないでしょうか。
まとめ
今回書いたことは、VBAで自動化する前に関数を駆使したり、フォーマットの標準化をしておくと自動化するためのコードも短縮できる、プログラマーも楽できる、それによってユーザー側もより楽に業務ができる、といったお話でした。
今回の件で思ったことは、ユーザー側でできることは別に関数を使ったりフォーマットの標準化だけではないはずです。Excelには非常に豊富な機能が搭載されています。むしろありすぎると言っていいくらいです。
例えばフィルターとかピボットテーブル、グループ化とか、最近ではスライサーとかスパークラインといった機能も追加されています。本当に全部を把握しきれないほどの機能があります。
これらの機能を使っても尚完全には自動化できない、という時にVBAを使えれば、ユーザー側、開発者側の両者にとって一番利益が得られるのではないかと思います。
こういった考え方・やり方が周知されていけば、多くの人が幸せになれるのにと思います。
コメント