ExcelVBAプログラミングで仕様変更にも動的に対応できるコードという発想

最近ExcelVBAのプログラミングについて勉強していました。その勉強に使っていた本の中に「静的」という言葉を目にして、ふと思ったことがあります。

 

  • 「コードに静的も動的もあるのだろうか?」

 

静的という言葉の反対は「動的」になります。

 

動的に対応できるコードとはいったいどんなものでしょうか。自分も本を読み始めて1周目の時はいまいちわかりませんでした。「動的?コードが勝手に動いたりするんだろうか?」と。

 

しかし2周目にもなればなんとなく理解できるようになります。今回はこのことについて最近気づいたことを書いていってみます。

 

静的なコードと動的なコードの簡単な説明

勉強していた本というのは『続ExcelVBAのプログラミングのツボとコツがゼッタイにわかる本』という名前なのですが、本書において「静的」なコードというのは、直接的な数値や文字列が書かれているコードを指すようです。

 

つまり、この状態だと直接的な数値や文字列だと「その数値や文字列でしか動作しない固定化されたコードやプログラム」になってしまいます。本書の著者が言うにはこれでは突発的な仕様変更に対応できないし、後々の拡張性や柔軟性がないから良くないとのこと。

 

静的という言葉の反対語は「動的」になります。この「動的なコード」というのは変数や定数を上手く使う必要があります。変数や定数を利用することで、元の数値や文字列を変更することになった場合でもプログラムを動作させることができます。

 

この方法であれば最初の部分を変えさえすれば連動して他の部分にも変更が反映されるようになります。このことだけだったら、「プログラミングにはこういうやり方もあるんだな」ぐらいにしか感じなかったでしょう。

 

ですがプログラマーやシステムエンジニアのようなITの分野の専門的な職業の人だけではなく自分のような一般の事務的な労働者でも、実際の業務でこの部分の重要性に気づかされた時があったので「動的なコード」について書いておこうかと思いました。

 

きっかけ

仕様変更にも動的に対応できるコードというものについて考えさせられるきっかけのひとつは、実際の業務で上司からある指示をされた時のことです。

 

それは、とあるエクセルの表に請求書の金額を入力していた時のことです。特に難しいことではないのですが、ただ単純に金額を入力するだけではなくて、取引先ごとに請求書番号とか備考を入力する必要がありました。

 

そのためには一旦フィルターをかけて過去の入力した部分を確認しながらという方法をとっていたのですが、毎回毎回フィルターをかけて企業名を入れて他にもちょっとアクションがあって・・・という手順をとるのは面倒くさいので、この部分をマクロにしてショートカットキーで作業ができるようにしていました。

 

ですからマクロをつくる以前よりかは作業は楽になりました。しかしある日のこと、上司から次のような指示がありました。

 

「この表の○○の列に挿入して□□の項目を入れといて」

 

以上のような指示があったので、そのようにしてからいつものように請求書の数値を入力するためにマクロを使おうとした時のことです。

 

「あれ?なんで?」

 

その瞬間はなぜだかわからなかったのですが、いつもと同じ動作をしてくれないのです。何度か試行錯誤してやり直してもみたのですが、マクロが思ったとおりに動いてくれません。

 

この時あることに気づきました。

 

「そういえば新たに列を挿入したよな・・・」と。

 

そうです。新しく列を挿入したことによってマクロが当初の動作ができなくなってしまったのです。というのもこの時はまだ自分は未熟だったので、静的なコードと動的なコードの意味を理解しておらず、VBAのコードに直接的な文字列や数値を入れてしまっていました。

 

本来であれば「Activecell.select」と入れないといけないのに「range(“A1”).select」と入力されていたみたいな感じです。このような経験があったので、勉強している本を読み進める中ではっとさせられたわけです。

 

実際の業務において、例えば今回の件のように上司から少し仕事のやり方を変えて欲しいみたいな指示って結構あると思います。もしくは自分の意志で「こうすればもっと楽にできるようになるのに」ということで今までの仕事のやり方を変更、改善していく、という場合もあるでしょう。

 

そういった時に、仮に業務改善用にマクロを作っていたとして毎回一からコードを書き直していては、すぐに対応するのが難しくなります。特にそのマクロの規模が大きければ大きいほど。

 

変更の指示がある度にコードを修正するのは面倒くさいですし、時間をとられます。また、修正のたびに手作業でコードを修正していは誤字脱字などのミスが出る可能性もあります。

 

そうなったらマクロは動きませんし、また一から見直しをしなければならないなど「静的なコード」では柔軟性が高くありません。

 

以上のようなことから本書に度々出てくる「コードの整理」という言葉の意味が段々とわかってきました。

 

「なるほど、何らかの変更があってもすぐに対応できるようにこうやって変数とか定数とか『コードの整理』という項目が出てくるんだな」と。

 

以前から違和感はありました。『ExcelVBAのプログラミングのツボとコツがゼッタイにわかる本』とその続編の本を読んできて、これらの本にはやたら「コードの整理」という項目が出てきたからです。

 

「コードの整理」というのは、プログラミングを勉強してきた自分にとっては新しい概念で、それまではただ単純にどんどん新しいオブジェクトやプロパティ、関数、メソッド、ステートメントを覚えていけばいいと思っていたからです。

 

ですから「そんなにコードを整理する必要ってあるのかな?」となんとなく不思議には思っていました。ですがやっぱり実際に経験しないと、そのものの重要性とか必要性というのにはなかなか気づけないものです。

 

実際に経験することで、「あぁ確かに『コードの整理』って面倒くさいかもしれないけどいろんなケースを考えると必要なんだな」と納得しました。

 

Pathプロパティから「動的に対応できるコード」というものが理解できた気がした

実際の業務でちょっとした手順の変更があったからこそ、『続ExcelVBAのプログラミングのツボとコツがゼッタイにわかる本』の中の次の文章がより理解できるようになりました。

p.254

当年と翌年の祝日リストのCSVファイル名を現在の日付から動的に取得するようコードを変更できたところで、・・・

(中略)

現時点では、暫定的に祝日リストのCSVファイルはCドライブ直下に置き、その前提のもと、祝日リストのCSVファイル名の前に「C:\」を付加してファイル名およびパスの文字列を指定しました。

 

この「C:\」の部分を、ブック「スケジュール表自動作成」と同じフォルダのパスに置き換えられれば、仕様通りにブックと同じフォルダに置いてある祝日リストのCSVファイルを開くことができるようになります。

 

ブックが置かれているフォルダのパスは、Pathプロパティを使えば取得できます。

引用した文章の中に「動的」という言葉が出てきますが、この部分から次の点が理解できるようになりました。

 

  • 動的な言葉の意味
  • どういう時に「動的」な言葉を使うのか
  • 動的なコードの意味

 

また、引用した文章の状況というのは、「スケジュール表自動作成」というアプリケーションをつくるにあたって必要なファイルを、コードをわかりやすく記述するために便宜的にCドライブ直下に置いていました。

 

このアプリケーションを上手く動作させるために他にも必要なファイル(本書では「2009祝日.csv」とある)があるのですが、そのファイルと同じフォルダに一緒にする必要があります。

 

直接的に文字列や数値をコードに記述していたのでは、ファイルの場所を変えるたびにパス名も変える必要があります。しかしPathプロパティを使うことで、ファイルの場所を変えても(ドラッグ&ドロップなどで別のフォルダに移す)自動的にそれが反映されるようになります。

 

本書のこの部分の記述で感心しました。「確かに動的に対応できるコードって大事だな」と。

きれいなコードとは

どうしてこのことについて感心したかというと、自分は直接プログラマーとして働いたことはないのですが、プログラマーの仕事には仕様変更が頻繁に起こるとよく聞いたりします。

 

顧客の要望を聞いて、コードに落とし込んでも後になって「いや、ここはそうじゃない」とか「忘れていたんだけど確かここはこういう風にして欲しくて」みたいなことは確かにありそうな気がします。

 

そのような時に毎回毎回1から10まで全部直していては時間も労力もかかるでしょう。それにミスが出る可能性も高くなります。

 

そういった時に最初の「1」の部分を直すだけで、後の「2から10」の部分にも変更が反映されるようなコードであれば、直すのも簡単ですしミスも少なくなりそうです。

 

今回の件でもうひとつ思ったのは、プログラミングにおいて「きれいなコード」という言葉の意味についてです。最初この言葉を聞いた時は「プログラミングのコードにきれいも汚いもあるのか?」と疑問に思っていました。

 

最近までのきれいなコードというイメージは「コードの途中途中に1行ずつ空きがあったり、わかりやすいコメントがあったりして単純に見やすい」ものだと思っていました。

 

しかしプログラミングというものを勉強することによって、きれいなコードというのはただ「見やすい」だけではないんだろうなと思うようになってきました。

 

例えば、Ifステートメントやwithステートメントの入れ子とか全体的な構造、どこがどう対応しているのかがわかりやすいとか、今回の冒頭部分でも書いたように、仕様変更にも対応しやすいコードであるとか、

 

「きれいなコード」というのは多分そういった意味も含まれているんじゃないかなぁと思いました。

あわせて読みたい

こんな記事も読まれています

コメント