連載：Excel VBAを「設計」してみよう #02
はじめに
前回は、AIがコードを書いてくれる時代に、なぜ私たち自身がプログラミングや設計を学ぶのかについて考えました。
今回から、少しずつ「設計」そのものに入っていきます。
ただし、まだクラスモジュールは使いません。
まず考えたいのは、もっと身近な問題です。
VBAを書いていると、最初は数十行だったマクロが、いつの間にか数百行になっていることがあります。
さらに機能を追加していくと、
「このマクロ、もう触りたくない……」
という状態になることもあります。
では、なぜ大きくなったVBAはつらくなるのでしょうか？
単純に、
コードが長いから
でしょうか。
今回は、ここから考えてみます。
よくあるVBA
例えば、受注データを処理するマクロがあるとします。
やりたいことは、こんな感じです。
- Excelから受注データを取得する
- 入力内容をチェックする
- 顧客を判定する
- 金額を計算する
- 結果をExcelへ出力する
- ファイルを保存する
最初は、すべてを1つのSubに書いていたとします。
Sub Main()
' データ取得
customerId = Cells(2, 1).Value
productName = Cells(2, 2).Value
quantity = Cells(2, 3).Value
unitPrice = Cells(2, 4).Value
' 入力チェック
If customerId = "" Then
MsgBox "顧客IDが入力されていません。"
Exit Sub
End If
If quantity <= 0 Then
MsgBox "数量を確認してください。"
Exit Sub
End If
' 顧客判定
If customerId = "C001" Then
discountRate = 0.1
Else
discountRate = 0
End If
' 金額計算
totalPrice = quantity * unitPrice
totalPrice = totalPrice * (1 - discountRate)
' Excel出力
Cells(2, 5).Value = totalPrice
' ファイル保存
ThisWorkbook.Save
End Sub
実際の業務では、もちろんこれだけでは終わらないでしょう。
例えば、
- 商品コードのチェック
- 在庫の確認
- 顧客ごとの割引
- 消費税の計算
- エラーメッセージの表示
- 別シートへの転記
- CSVへの出力
- ファイル名の生成
などが追加されていくかもしれません。
その結果、Mainが100行、300行、500行……と大きくなっていきます。
そして、いつかこう思います。
「このコード、分かりにくいな……」
でも、ここで一つ疑問があります。
本当に問題なのは、行数なのでしょうか？
短ければ分かりやすいのか？
極端な例を考えてみます。
例えば、1000行あるプログラムでも、
1～200行 データ取得
201～400行 入力チェック
401～600行 金額計算
601～800行 Excel出力
801～1000行 ファイル保存
のように非常にきれいに整理されていて、
「金額計算を確認したければ、ここを見ればいい」
とすぐに分かるとしたらどうでしょうか。
1000行あるので、決して小さくはありません。
それでも、何がどこにあるのか分かるなら、意外と読めるかもしれません。
逆に、200行しかなくても、
データ取得
↓
入力チェック
↓
計算
↓
また入力チェック
↓
Excelへ出力
↓
別の計算
↓
ファイル名を作る
↓
またExcelへ出力
↓
顧客を判定
↓
エラー処理
という状態になっていたらどうでしょう。
コード量はこちらの方が少ない。
それでも、
「結局、このコードは何をしているの？」
となりやすいのではないでしょうか。
つまり、
コードの分かりやすさは、単純な行数だけでは決まりません。
1つのSubが、いろいろな仕事をしている
先ほどのMainをもう一度見てみます。
Sub Main()
' データ取得
' 入力チェック
' 顧客判定
' 金額計算
' Excel出力
' ファイル保存
End Sub
コードそのものをいったん消してコメントだけにすると、あることに気づきます。
このMainは、
かなりいろいろな仕事をしています。
データを読む。
入力をチェックする。
顧客を判定する。
金額を計算する。
Excelに書く。
ファイルを保存する。
全部違う仕事です。
それらが1つのSubの中に入っています。
ここに機能追加が続くと、さらに仕事が増えていきます。
Main
├ データを読む
├ 入力をチェックする
├ 顧客を判定する
├ 商品を確認する
├ 在庫を確認する
├ 金額を計算する
├ 割引を計算する
├ 税金を計算する
├ Excelへ出力する
├ CSVを作る
├ ファイル名を作る
└ ファイルを保存する
これなら、長くなるのも当然です。
しかし、本当に困るのは「長いこと」だけではありません。
いろいろな種類の仕事が混ざっていることです。
仕様変更を考えてみる
と頼めば、処理を複数のSubやFunctionへ分けたコードを提案してくれるかもしれません。
そこで見たいのは、
「何個に分割されたか」ではありません。
例えば、
- なぜこの単位で分けたのか
- それぞれの処理は何を担当しているのか
- 同じ種類の仕事が複数の場所に残っていないか
- 変更するとき、修正箇所を見つけやすくなったか
という点を考えてみます。
AIがコードを整理してくれたとしても、
「なぜ、この分け方なのだろう？」
と考える。
これも、第1回でお話ししたAIの答えを評価するための判断軸の一つです。
まとめ
今回のポイントは3つです。
1. 大きなVBAがつらい原因は、行数だけではない
1000行だから、という理由だけで分かりにくくなるわけではありません。
異なる種類の処理が混ざり、どこで何をしているのか分からなくなることが問題です。
2. 「この処理は何の仕事？」と考えてみる
データ取得、入力チェック、計算、出力、保存。
まずは、それぞれの処理が何を担当しているのかを考えます。
3. いきなりクラスにしなくてもよい
標準モジュールでも、SubやFunctionへ適切に分けることで、かなり整理できます。
クラスを使うこと自体を目的にしない。
この考え方は、この先オブジェクト指向を学ぶ上でも大切にしたいと思います。
次回
では、標準モジュールとSub、Functionできれいに整理できるのであれば、一つ疑問が出てきます。
そもそも、クラスって必要なのでしょうか？
次回は、
「標準モジュールだけではダメなのか？」
を考えます。
あえて、
「VBAなら標準モジュールだけで十分では？」
という側から考えてみます。
クラスを使わなくても整理できる。
それでもクラスを使いたくなるのは、どんなときなのか。
オブジェクト指向を学ぶ前に、まずはそこを考えてみたいと思います。