命名規則は「哲学」である。Excel VBAを堅牢なシステムに変えるための思考術
VBAを単なる「マクロ」と呼ぶ時代は終わった。現代の業務自動化において、VBAは基幹システムとExcelを繋ぐブリッジであり、メンテナンス性を欠いたコードは、いずれ「負債」となってあなた自身を苦しめることになる。
多くの現場で散見される「変数名が適当で、中身が何かわからない」「ハンガリアン記法が形骸化し、かえって視認性を下げている」という現象。これは技術力以前の問題、すなわちコードに対する哲学の欠如だ。
今回は、チーム開発でバグを排除し、1年後の自分が読んでも即座に改修できる「極限の命名規則」を伝授する。
—
1. なぜ「ハンガリアン記法」を盲信してはいけないのか
かつてVBAの教科書には「文字列なら`strName`、整数なら`intCount`」と書かれていた。しかし、現代のIDE（VBE）は優秀だ。マウスカーソルを合わせれば型は表示される。
現代において重要なのは「型」ではなく「役割（意味）」だ。
- 避けるべき例: `strFile`, `intCount` （型が変わった途端、変数名が嘘つきになる）
- 推奨する例: `targetFilePath`, `retryCount` （何のためのデータか、という本質が残る）
ハンガリアン記法を捨てろと言っているのではない。「型」ではなく「意味」をプレフィックスに付与せよ。
—
2. チーム開発で絶対守るべき「3つの命名原則」
以下のルールをチームの標準として定義してほしい。これだけでバグは激減する。
① スコープと寿命を可視化する
モジュールレベル変数は、意図せぬ書き換えによるバグの温床だ。
- モジュールレベル変数: `m_` をつける（例: `m_wsConfig`）
- 定数: `k` または `c` をつける（例: `k_MaxRetryCount`）
これにより、メソッド内で変数を変更した際に「あ、これは広域で使っているものだ」と即座に脳がアラートを出す。
② 戻り値の役割を明確にする
関数（Function）の命名は「名詞」ではなく「動詞」から始める。
- `Get…`: 値を取得する
- `Is…`: Booleanを返す
- `Create…`: オブジェクトを生成する
③ コレクションには「複数形」を使う
`Dim sheet As Worksheet` に対して `For Each sheet In Worksheets` と書くのは、言語の仕様上間違いではないが、読みにくい。
- コレクション: `worksheets`（複数形）
- 要素: `sheet`（単数形）
—
3. 実践：保守性を極めたプロダクションコード例
以下は、ファイル連携時に「絶対にバグらせない」ための定数・変数定義のテンプレートだ。これを基準にコードを設計してほしい。
Option Explicit
‘ モジュールレベル変数には m_ を付与。初期化の有無が一目でわかる
Private m_isInitialized As Boolean
Private m_wsData As Worksheet
‘ 定数には k_ を付与。魔法の数字（マジックナンバー）を排除する
Private Const k_TargetSheetName As String = “MasterData”
Private Const k_MaxRetryCount As Integer = 3
”’
”’
Public Function GetTargetData(ByVal targetId As String) As Variant
Dim retryCount As Integer
Dim result As Variant
‘ 意味のある変数名により、処理の流れが自己文書化される
For retryCount = 1 To k_MaxRetryCount
‘ ここにAPIやファイル読み込み処理を記述
‘ … 処理 …
If IsSuccess Then
GetTargetData = result
Exit Function
End If
Next retryCount
‘ 失敗時は明示的にエラーを投げる
Err.Raise vbObjectError + 1000, “GetTargetData”, “データ取得に失敗しました”
End Function
—
4. 業務自動化エンジニアとしての「極意」
命名規則は、単なる「ルールの押し付け」ではない。「コードを読む人の脳の負荷を最小化するための設計」だ。
- ファイル連携時: パスをハードコーディングせず、必ず `k_` で始まる定数として定義し、Configシートや環境変数から読み込む構造にする。
- データベース連携時: フィールド名と変数名を一致させる必要はない。ロジック側の命名は、あくまで「業務上の意味」を優先せよ。
最後に
コードは「書く」ものではなく「伝える」ものだ。
あなたが書いたコードを、半年後に異動してきた後輩が読み、絶望せずにメンテナンスできるか？
その問いに自信を持って「Yes」と言える命名ができた時、あなたのVBAはプロフェッショナルな品質に到達する。
命名という小さな一歩が、巨大な自動化システムを支える岩盤となる。さあ、今すぐプロジェクトの命名規約をリファクタリングしよう。
