------
VBAでシステムを作る際の考慮点 その5


まずは、この壁から。
 ・消費税が上がるけれど、どれだけ影響範囲があるのかわからない。

これと類似したところでは
 ・そこらじゅうに同じような処理があり、どこがどうなっているのか分からない。
 ・修正してみたけれど、結果が変わらない。
 ・この処理は無駄なのかもしれないけれど、今となっては分からない。
などがあるだろう。

これは、「ソースコードが整理整頓されていないから」である。記録したものをそのまま使ったり、ネットにあるソースや時には自分自身のコードをコピー&ペーストしてみたりを繰り返すとこういう事態に陥ることが結構ある。

ただ、こういう一般論を述べても「で?具体的には?」となるだろう。少し具体的に攻めてみよう。

1.消費税が上がるけれど、どれだけ影響範囲があるのかわからない。

消費税率は過去3%だったが、5%に引き上げられている。近くまた上がるとか・・。そういう消費税率が、コード内の式の中にそのままの値で、例えば 0.05 とか × 5 ÷ 100 のような形で記載されていると厄介である。もしかするとそれは消費税以外の目的の計算かもしれない。しっかりと読み解く必要が出てくるからだ。(ま、消費税ごときでこれは大げさだが・・)
こういう場合は
 ・定数として消費税率を定義しておく
といいだろう。
例)
Public Const SHOUHI_ZEI_RATE As Integer = 5

ただ、過去には「自動車とそれ以外の製品で消費税率が異なる」という時期もあった。今となっては歴史の遺物かもしれないが、今後商品によって消費税率が変わる可能性はないとは言い切れない。その時はターゲットをはっきりさせた定数を使うようにしよう。
例)
Public Const SHOUHI_ZEI_NOMAL As Integer = 5
Public Const SHOUHI_ZEI_CAR As Integer = 6
Public Const SHOUHI_ZEI_FOOD As Integer = 3

なお、消費税に限らず、定数化できるものは定数化してしまう方が分かりやすいだろう。


2.そこらじゅうに同じような処理があり、どこがどうなっているのか分からない。

同じ処理なのか、似て非なる処理なのか。どちらにせよ、まとめられるならまとめるに限る。このとき、プロシージャではなく関数、つまり Sub ではなく Function を使って処理を切り出し、切り出す元では Function の戻り値を使うようにする方がまとめやすいだろう。

中にはファイルの読み書きやデータベース接続のように、すでにオープンされていると使えないよ、というものもある。これはいずれ述べるが、クラスモジュールにすれば解決できる。

3.修正してみたけれど、結果が変わらない。

これも困った問題である。おそらくステップ実行をしても修正個所を通っていないか、その修正個所の結果が上塗られたり選択されなかったりなどの理由で無効になっているからだろう。

Debug.Print文やウォッチウィンドウを使って値の変遷を確認するといいだろう。


4.この処理は無駄なのかもしれないけれど、今となっては分からない。

これがあるとプログラムがどんどん肥大してしまう。

プロシージャ名や関数名をプロジェクト全体で検索するとか、Debug.PrintやMsgBoxで「通ったらわかる」ようにしておくのもいいだろう。

ただ、ワークシート関数として使われていたり、イベントであったりするかもしれないので、ワークシートモジュールに書かれている場合は注意が必要である。
前回までに、VBA利用者のなすべきこととして正しいアウトプットを導くため、インプットを正しい順序、正しい方法で処理するようにしてやらないといけない、と説明した。また、その際には、より適切な方法を採ることが大切である旨も述べた。

適切、のあたりを何度かに分けて説明していこうと思う。


------
VBAでシステムを作る際の考慮点 その4


話は飛ぶかもしれないが、VBAでプログラムを作った経験者なら「VBAでコードを書いていて困ったこと」にぶち当たったことはあるのではないだろうか。

多いのは「どう書けばやりたいことを実現できるのか」だろう。それでとりあえずは動くようになったとする。しかし、新たな壁が立ちはだかったりしないだろうか?例えば次のようなこと。
 ・消費税が上がるけれど、どれだけ影響範囲があるのかわからない。
 ・結果が出るまで30秒かかるが、そんなにお客さんを待たせられない。
 ・OSやExcelのバージョンが変わったら思い通りに動かなくなった。
 ・機能追加をしたいけれど、触れない。
 ・ときどき思惑通りでない結果が出てくる。
 ・画面や印刷物がみずらい。

このあたりを解決したくても、そういった情報がそうそう見つからないだろう。


家を建てるとき、現場の人が適当に建てていることは現代社会においてはそうそう見つけることができないのではないだろうか。通常、設計という工程を経る。
文章作成においても、清水幾太郎氏の「私の文書作法」という書籍の中で「設計図」を作成することを勧めている。特に論文であれば、どういう材料をどういう順序で出していくかを吟味しておくべきだろう。

先ほど出したような壁にぶち当たったなら、おそらく「設計」という工程が存在しなかったか、十分でなかったか、ではないだろうか。

では、上記のような壁にぶち当たっても途方に暮れないために、具体的にはどうしてゆけばいいのかを、次回以降掘り下げていこうと思う。
今回は本題ではないもの。よって3.5とした。

------
VBAでシステムを作る際の考慮点 その3.5(休憩)


前回の最後に「VBAコードにおける、適切な方法とは?」に触れようと、ということで終わっているが、さて、どうネタを出していこうか?と思案している。

おそらくはソフトウェアの品質特性について触れることにはなる。ベームの考え方をベースに書こうかと思っていたが、ISO/IEC 9126 やISO/IEC 25000:2005 の方が今は適切か。また、SQuBOK と絡めた方がいいのか、範囲を広げてテスト等とも絡めた法がいいのか、などなど。

そうすると不足している知識もあるので補完する、となるとブログが停滞する。

なら、いっそのことベームの考え方でまずは書いてみて、必要があればいずれ修正する、ってことにしようかなとも思う。
ただ、品質の部分はそれだけで大きな研究テーマとなり、深入りするのも面白どうだが一般受けはしないだろう。その折り合いを考えながら、とりあえず進めてみようかと思う。