VBA業務マクロの関数命名をレイヤーと責務で設計する

モジュール名を業務上の住所にし、関数名で対象物と仕事を読めるようにする

Copyright © 2026 LWP 山中 一弘

本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。

記事要約

VBA業務マクロの関数名は、英語としてきれいに見えることだけを目的にしても足りません。業務マクロでは、ボタン、シート、表、CSV、出力帳票、業務判断、金額計算、ログ出力が近い距離で混ざります。そのため、関数名を見ただけで「どの業務領域に属し、どのレイヤーで、何を対象に、何をするのか」が分からないと、保守時にコード全体の地図を失います。

この記事では、VBA業務マクロの命名を、モジュール名と関数名の組み合わせとして整理します。モジュール名は業務上の住所です。関数名は、3文字接頭辞でレイヤーを示し、対象物と動作名詞で処理内容を示します。Public関数は外から見ても一意にし、Private関数はモジュール文脈を使って短くします。

結論は単純です。業務マクロの命名は、見た目の統一ではなく設計情報です。関数名には、処理の居場所、対象、副作用、呼び出し範囲を表す責任があります。命名を整えると、関数一覧、コールツリー、モジュール構成、改修影響を追いやすくなり、業務マクロを引き継げる資産にできます。

本記事の対象とゴール

想定読者

• Excel VBAで業務マクロを作っている人

• Main、処理1、データチェック のような名前が増えて、後から読みづらくなっている人

• Public関数とPrivate関数の名前の粒度を分けたい人

• 業務ロジック、データ操作、共通関数、計算関数の置き場所を整理したい人

• 既存マクロを改修するとき、いきなり全関数を変えずに命名規約を導入したい人

本記事で得られること

1. VBA業務マクロで、関数名に何を含めるべきか判断できます。

2. UIF、BIZ、DAT、MTH、COM などの3文字接頭辞を、レイヤーと責務の表示として使えます。

3. モジュール名と関数名を組み合わせて、長すぎないが意味が欠けない名前を付けられます。

4. Public関数はプロジェクト内で一意にし、Private関数はモジュール内の文脈で短くする判断軸を持てます。

5. 既存マクロへ命名規約を入れるときの改修順序を決められます。

1. 命名規約は業務マクロの地図である

業務マクロの命名で重要なのは、英語として自然か、日本語として読みやすいか、型が分かるかだけではありません。

もちろん、構文上使える名前であること、読みづらい省略を避けること、組み込み関数やExcelオブジェクト名と衝突しないことは必要です。しかし、それだけでは業務マクロの保守には足りません。

業務マクロで本当に知りたいのは、次のような情報です。

• その処理はどの業務領域に属するのか。

• どのレイヤーの処理なのか。

• 何を対象にしているのか。

• 何を行う処理なのか。

• 読むだけなのか、書き換えるのか。

• どのモジュールに置くべきなのか。

• 外部から呼ばれる処理なのか、内部補助処理なのか。

この情報が名前から読めないと、関数一覧を見ても地図になりません。マクロを修正するたびに、呼び出し元を探し、シート操作を追い、同じような処理を何度も読むことになります。

この記事で採用する基本思想は次のとおりです。

モジュール名 = 業務上の住所

3文字接頭辞 = レイヤー

対象物 = 操作対象または業務対象

動作名詞 = その処理の仕事

関数名だけで全部を語らせようとすると、名前が長くなりすぎます。反対に、モジュール名だけに意味を押し込めると、関数一覧を見たときに処理内容が分かりません。そこで、モジュール名と関数名を組み合わせて意味を作ります。

2. 関数名には分類と動作を持たせる

構造化言語における関数名は、単なる処理名では不足します。

関数名には、少なくとも次の2つの情報を持たせます。

1. その関数がどこに属するか

2. その関数が何を対象に、何をするか

これは、二名法的な命名と、オブジェクト指向的な命名を組み合わせる考え方です。

二名法的な命名とは、関数がどの分類や領域に属するかを示す考え方です。たとえば、次の名前はまだ動作ではありませんが、分類としては意味を持っています。

sales_record

billing_amount

journal_entry

sheet_header

file_path

match_result

ここに動詞を足すと、処理名になります。

sales_record_validate

billing_amount_calculate

journal_entry_create

sheet_header_find

file_path_join

match_result_compare

一方、オブジェクト指向では、対象物に対してメソッドを呼びます。

File.Exists

Path.Join

Sheet.Clear

Table.FindColumn

Range.GetValue

VBAの標準モジュール中心の構造では、これを関数名に埋め込む必要があります。

file_exists_check

path_join

sheet_clear

table_column_find

range_value_get

したがって、構造化言語の関数名は、分類、対象物、動作を組み合わせて考えます。

分類 + 対象物 + 動作

上位層では、どの業務処理かを重視します。中位層では、どの業務対象に対する判断や加工かを重視します。下位層では、どの技術対象に対する操作かを重視します。

この違いを意識しないと、すべての関数名が「データ処理」「チェック」「実行」のような弱い名前に寄っていきます。

3. 日本語関数名の基本形

日本語の関数名では、英語の動詞に相当する部分が、動作名詞になります。

代表的な動作名詞は次のとおりです。

チェック

検証

判定

計算

算出

作成

生成

読込

保存

保管

出力

取得

設定

変換

整形

記録

確定

日本語関数名の基本形は次のとおりです。

3文字接頭辞 + 業務分類 + 対象物 + 動作名詞

例を挙げます。

UIF入力データチェック

BIZ入力データ検証

BIZ対象行判定

BIZ加工データ作成

DAT元データ読込

DAT加工データ保存

MTH金額丸め

COM空白判定

MTDシート最終行取得

UTL処理時間計測

業務分類は、モジュール名で明らかであれば省略してかまいません。ただし、対象物と動作名詞は原則として省略しません。

たとえば、LWP_3010BIZ_売上取込 というモジュール内であれば、BIZ売上取込入力データ検証 と毎回書く必要はありません。Private関数なら、BIZ入力データ検証 や BIZ必須見出し検証 で足ります。

ただし、Public関数は別です。Public関数はモジュール外から呼ばれるため、関数名単体で意味が通り、プロジェクト内で一意になる名前にします。

4. 3文字接頭辞でレイヤーを示す

3文字接頭辞は、関数のレイヤーまたは役割を示します。接頭辞はすべて大文字にします。

この表は、絶対的な正解ではありません。大切なのは、プロジェクト内で接頭辞の意味を固定することです。

補足しておくと、DCL と CFG は、実行処理というより、定義や構成情報の置き場所として使うことが多くなります。通常の業務処理を何でも DCL や CFG に入れないようにします。

また、COM はこの規約では Common、つまり汎用処理の意味です。WindowsのCOM技術と紛らわしい現場では、CMM など別の接頭辞へ置き換えてもかまいません。名前は規約を守るためにあるのではなく、誤解を減らすためにあります。

5. 標準モジュールは業務上の住所として使う

標準モジュールは、機能や役割ごとに分割します。

モジュール名は、次の形式を基本にします。

LWP_番号_機能区分

業務機能ごとに分ける場合は、末尾に業務名を付けます。

LWP_3010BIZ_売上取込

LWP_4010DAT_請求作成

標準構成は次のように整理できます。

LWP_1010DCL

  DCL - 定数、列挙型、共通設定値

LWP_2010UIF

  UIF - ユーザーIF、ボタン呼出し、上位制御

  UBZ - UIF分割、UIF下請け

  EVT - イベント関数

LWP_3010BIZ

  BIZ - 業務ロジック、検証、判定、業務計算、業務加工

LWP_4010DAT

  DAT - データモデル、入出力、表変換、シート・テーブル・配列操作

LWP_5010COM

  COM - 再利用可能な汎用関数

  MTD - 操作対象を指定したメソッド風関数

  MTH - 数値・金額・日付などの計算系関数

LWP_6010UTL

  TOL - 独立したツール関数

  UTL - 開発、検証、解析支援関数

LWP_9010CFG

  CFG - 構成情報、関数一覧、設計メモ、変更履歴

番号を付ける理由は、VBE上の並び順を安定させるためです。業務マクロでは、標準モジュールが増えるほど、どこから読めばよいか分かりにくくなります。番号によって、おおまかなレイヤー順で並べます。

ただし、番号は設計の本体ではありません。番号だけ整っていても、中の関数が混ざっていれば意味がありません。番号、機能区分、接頭辞、関数名が同じ方向を向いて初めて、モジュール構成が地図になります。

6. モジュール名と関数名を合わせて意味を作る

関数名が長くなりすぎる場合は、業務分類をモジュール名に逃がします。

たとえば、完全名をそのまま書くと、次のように長くなります。

BIZ売上取込入力データ必須見出し項目検証

これは意味は分かりますが、長すぎます。読み手が毎回この長さを追うのは現実的ではありません。

この場合は、モジュール名に業務分類を持たせます。

LWP_3010BIZ_売上取込

その中で、Private関数は次のように短くします。

Private Function BIZ必須見出し検証() As Boolean

End Function

Private Function BIZ入力行検証() As Boolean

End Function

Private Function BIZ対象行判定() As Boolean

End Function

意味上は次のように読みます。

売上取込の必須見出し検証

売上取込の入力行検証

売上取込の対象行判定

つまり、モジュール名と関数名を合わせて意味が決まります。

意味上の完全名 = モジュール名 + 関数名

ただし、VBAでは標準モジュールが強い名前空間ではありません。Public関数については、関数名単体でもプロジェクト内で一意になるようにします。

実装上の安全名 = Public関数名単体でも一意

ここを曖昧にすると、別モジュールに同じPublic名がある、Application.Runで呼びづらい、ボタン割当でどれを指しているか分からない、といった問題が起きます。

7. Public関数とPrivate関数は粒度を変える

VBAでは、標準モジュール内のPublic関数は広い範囲から参照されます。そのため、Public関数とPrivate関数では命名規則を分けます。

Public関数では、次を重視します。

• プロジェクト内で一意にする。

• 業務分類を省略しすぎない。

• ボタン割当、Application.Run、外部呼出しに耐える名前にする。

• 関数名単体を見ても、何の入口か分かるようにする。

Private関数では、次を重視します。

• モジュール内で一意ならよい。

• 業務分類はモジュール名に逃がしてよい。

• 関数名は短くしてよい。

• モジュールの責務から外れる名前を付けない。

たとえば、売上取込の業務ロジックでは次のように分けます。

' Module: LWP_3010BIZ_売上取込

Public Function BIZ売上取込入力データ検証() As Boolean

End Function

Private Function BIZ必須見出し検証() As Boolean

End Function

Private Function BIZ対象行判定() As Boolean

End Function

UIFの場合は、利用者が実行する入口と、その下請けを分けます。

' Module: LWP_2010UIF_売上取込

Public Sub UIF売上取込入力データチェック()

End Sub

Private Sub UBZチェック条件取得()

End Sub

Private Sub UBZ結果メッセージ表示()

End Sub

UIF は利用者やボタンに近い入口です。UBZ はUIFを分割した下請けです。UBZ をPublicにして外から呼ぶようになっているなら、それは本当にUI補助なのか、BIZへ移すべきなのかを見直します。

8. DAT、MTH、BIZの境界を決める

DAT と MTH は混同しやすい接頭辞です。さらに、業務ルールを含む計算は BIZ に寄せる必要があります。

判断基準は次のとおりです。

例を見ます。

DAT元データ読込

DAT入力表To加工表変換

DAT加工データ保存

MTH金額丸め

MTH税額計算

MTH比率算出

MTH経過日数計算

BIZ請求金額計算

BIZ締対象判定

BIZ入力データ検証

同じ「計算」でも、業務ルールを含むなら BIZ です。単なる数式処理であれば MTH です。

たとえば、消費税額を四捨五入するだけなら MTH税額丸め で足ります。しかし、請求対象の明細だけを集め、取引先ごとの端数処理ルールを適用し、締日条件を見て請求金額を決めるなら、これは BIZ請求金額計算 です。

DAT は、データの入出力や変換を扱います。BIZ の判断を DAT に混ぜると、どこで業務ルールが変わったのか追いにくくなります。反対に、単なるシート読込を BIZ に置くと、業務ロジックがExcel操作に引きずられます。

9. 状態語でデータの段階を表す

業務マクロでは、データがどの状態にあるかが重要です。そのため、対象物には状態語を積極的に使います。

例を挙げます。

DAT元データ読込

BIZ入力データ検証

BIZ検証済データ作成

BIZ加工データ作成

DAT加工データ保存

DAT出力データ書出

DATエラーデータ出力

データ という語だけでは、どの段階のデータか分かりません。元データ、入力データ、検証済データ、加工データ のように段階を分けると、処理の流れが読みやすくなります。

状態語を使う目的は、名前を長くすることではありません。処理の前後関係を見えるようにすることです。状態語があると、検証前のデータを保存していないか、加工済みデータを再検証していないか、確定前に出力していないか、といったレビューがしやすくなります。

10. 動作名詞の意味を固定する

動作名詞は、意味を固定して使います。

特に注意したいのは、チェック です。

チェック は便利ですが、内部処理に多用すると意味が薄くなります。利用者向けのボタンやUI入口では チェック でよい場面があります。しかし、内部処理では、仕様に照らすなら 検証、Yes/Noを決めるなら 判定、値を求めるなら 計算 または 算出 に分けます。

良い例です。

UIF入力データチェック

BIZ入力データ検証

DAT見出し項目検証

COM空白判定

弱い例です。

BIZデータチェック

DATデータチェック

COMチェック

弱い例は、何を見て、何を返し、何が失敗なのかが読めません。名前が曖昧な関数は、後からエラー処理、メッセージ表示、ログ記録まで抱え込みやすくなります。

11. 副作用を名前で明示する

業務マクロでは、読むだけの処理と、書き換える処理を名前で区別します。

例を挙げます。

DAT設定値取得

BIZ対象行判定

BIZ入力データ検証

BIZ加工データ作成

DAT加工データ保存

DAT帳票PDF出力

UTL処理ログ記録

BIZ請求データ確定

取得 という名前の関数がシートを書き換えると、読み手は裏切られます。判定 という名前の関数がメッセージを表示して処理を止めると、呼び出し側から見た副作用が読めません。

副作用がある処理は、名前でそれを示します。保存するなら 保存、外部へ出すなら 出力、ログを残すなら 記録、業務状態を進めるなら 確定 とします。

この規約は、純粋関数だけを書くためのものではありません。業務マクロでは、シートを読む、書く、ファイルを作る、画面に出す処理が必要です。だからこそ、副作用がある処理を隠さないことが重要です。

12. A To B変換は変換元と変換先を明示する

データモデル関数では、何から何へ変換するかを明示します。

英語名では次のように書けます。

input_table_to_output_table

csv_to_record

record_to_journal_entry

日本語名では、VBA上の扱いやすさを考え、次の形を基本にします。

DAT入力表To加工表変換

DATCSVTo元データ変換

DAT加工データTo出力CSV変換

アンダースコアを使う案もあります。

DAT入力表_To_加工表

DATCSV_To_元データ

ただし、VBAではアンダースコアがイベント名や Implements 周りで意味を持ちます。標準モジュール中心であれば採用してもよいですが、クラスやインターフェースを多用する場合は、To を使う形の方が安全です。

また、変換 と 作成 を分けます。入力構造を別の構造へ移すなら 変換 です。複数の情報を組み立てて新しい成果物を作るなら 作成 または 生成 です。

DAT入力表To加工表変換

BIZ請求データ作成

DAT帳票PDF出力

この違いを残しておくと、後から処理を読んだときに、単なる形式変更なのか、業務判断を含む成果物生成なのかを区別できます。

13. 依存関係は上位から下位へ流す

モジュール間の依存関係は、上位から下位への片方向にします。

UIF

 ↓

BIZ

 ↓

DAT

 ↓

COM / MTD / MTH

DCL は全体から参照されます。UTL と TOL は開発、検証、解析用であり、原則として本番処理から呼び出しません。CFG は構成情報であり、実行処理の中心に置きません。

避けるべき依存は次のとおりです。

DAT から UIF を呼ぶ

COM から BIZ を呼ぶ

MTH から DAT を呼ぶ

UTL が本番処理に必須になる

これを許すと、処理の入口、責務、依存方向が分からなくなります。

たとえば、DAT から UIF のメッセージ表示を呼ぶと、データ読込処理が画面表示に依存します。後からバッチ処理やテストで使おうとしても、画面が出る前提になってしまいます。

COM から BIZ を呼ぶのも危険です。共通関数のはずなのに、特定業務のルールを知っていることになります。その時点で、もう汎用関数ではありません。

依存方向を守ることは、きれいな設計のためだけではありません。業務マクロを安全に直すための条件です。

14. 禁止語と注意語を決める

次の語は、単独で使うと意味が弱くなります。

データ

処理

実行

メイン

サブ

ワーク

一時

チェック

完全禁止ではありませんが、単独使用は禁止に近い扱いにします。

悪い例です。

BIZデータ処理

BIZメイン処理

DATデータ保存

COM処理実行

UIF実行

良い例です。

BIZ入力データ検証

BIZ請求データ確定

DAT加工データ保存

COM空白判定

UIF売上取込実行

メイン や サブ は、作った人の作業順を表すことはありますが、業務上の責務を表しません。一時 や ワーク も同じです。何のための一時データなのか、何の作業データなのかを名前にします。

名前に迷ったときは、次の問いを使います。

6. これは何を入力にしているのか。

7. 何を判断しているのか。

8. 何を作っているのか。

9. 何を保存または出力しているのか。

10. この関数を呼んだ後、業務状態は変わるのか。

この問いに答えられない名前は、まだ設計が固まっていない可能性があります。

15. 英語名を使う場合の形

英語名を使う場合は、次の形を基本にします。

prefix_domain_object_verb

例を挙げます。

BIZ_sales_record_validate

BIZ_billing_amount_calculate

DAT_input_table_to_output_table_convert

MTD_sheet_last_row_get

MTH_amount_round

COM_blank_check

PascalCaseを使う場合は次の形にします。

BIZSalesRecordValidate

DATInputTableToOutputTableConvert

MTDSheetLastRowGet

英語動詞も、意味を固定して使います。

英語名を使う場合に注意したいのは、judge です。日本語の「判定」に近い語として使いたくなりますが、英語圏のコードではBoolean関数に is、can、has、exists などを使う方が自然な場面もあります。

たとえば、英語名中心のプロジェクトなら、次のような名前の方が読みやすいことがあります。

BIZ_invoice_target_exists

BIZ_can_close_billing

BIZ_is_excluded_row

この規約では judge を禁止しません。ただし、チームの英語命名に合わせる場合は、Booleanの名前を is、can、has、exists に寄せる選択もあります。

16. 売上取込マクロで命名を組み立てる

具体例として、売上取込マクロを考えます。

モジュール構成は次のようにします。

LWP_1010DCL

LWP_2010UIF_売上取込

LWP_3010BIZ_売上取込

LWP_4010DAT_売上取込

LWP_5010COM

LWP_6010UTL

LWP_9010CFG

UIFでは、利用者が実行する入口と、その下請けを分けます。

Public  UIF売上取込入力データチェック

Private UBZチェック条件取得

Private UBZ結果メッセージ表示

BIZでは、業務判断、検証、加工、計算を置きます。

Public  BIZ売上取込入力データ検証

Private BIZ必須見出し検証

Private BIZ入力行検証

Private BIZ対象行判定

Private BIZ加工データ作成

Private BIZ請求金額計算

DATでは、読込、表変換、保存、出力を置きます。

Public  DAT売上取込元データ読込

Private DAT元データ読込

Private DAT入力表To加工表変換

Private DAT加工データ保存

Private DATエラーデータ出力

COM、MTD、MTHでは、業務に依存しない部品を置きます。

COM空白判定

COM文字列整形

MTDシート最終行取得

MTD範囲値取得

MTH金額丸め

MTH税額計算

UTLでは、開発や解析のための支援関数を置きます。

UTL処理時間計測

UTL関数一覧出力

UTL呼出関係解析

この例で重要なのは、同じ売上取込でも、入口、業務判断、データ操作、共通部品、解析支援を混ぜないことです。

UIF売上取込入力データチェック は、利用者に近い入口です。BIZ売上取込入力データ検証 は、業務ルールに照らした検証です。DAT売上取込元データ読込 は、外部やシートからデータを読む処理です。名前が似ていても、レイヤーと責務が違います。

17. 既存マクロへ適用するときの順序

既存マクロにこの規約を適用する場合は、いきなり全関数名を変更しません。

手順は次のとおりです。

1. モジュール一覧を作成する

2. 各モジュールの責務を分類する

3. Public関数を洗い出す

4. ボタン割当、イベント、Application.Runを確認する

5. Public関数から優先して改名する

6. Private関数はモジュール単位で改名する

7. DAT、BIZ、COM、MTHの混在を整理する

8. CFGに構成情報と変更履歴を記録する

特に注意すべきなのは、ボタン割当とイベントです。

ボタンに割り当てられているマクロ名を変更すると、ボタンから呼べなくなります。イベント名を誤って変更すると、イベントが発火しなくなります。Application.Run で文字列指定している関数名も、検索漏れしやすい箇所です。

そのため、UIF、EVT、Public関数の改名は慎重に行います。

既存マクロの改名では、次の順序が安全です。

11. まず一覧を作り、現在の名前を保全します。

12. Public関数、ボタン割当、イベント、文字列呼び出しを確認します。

13. Public名の新旧対応表を作ります。

14. 入口から実行確認できる範囲を決めます。

15. Private関数は、モジュール単位で小さく改名します。

16. 改名後に、関数一覧と呼び出し関係を再出力します。

命名規約は、コードを壊してまで一括適用するものではありません。既存マクロでは、改名によるリスクを管理しながら、入口に近い名前、外から呼ばれる名前、業務上の責務が大きい名前から整えます。

18. 外部規約から取り込むものと取り込まないもの

一般的なVBA命名規約から取り込むべきものは、思想ではなく安全ルールです。

取り込む事項は次のとおりです。

名前の先頭は文字にする

使えない記号を使わない

組み込み関数名やExcelオブジェクト名と衝突させない

Option Explicitを前提にする

Public名の衝突を避ける

読めない省略を避ける

型だけを示す接頭辞に依存しない

取り込まない事項は次のとおりです。

すべて英語名にする

すべて動詞で始める

型接頭辞を大量につける

他言語の命名作法をそのまま持ち込む

この規約の中心は、プログラミング一般の命名ではなく、業務マクロの命名です。

Excel VBAの業務マクロでは、シート、ボタン、帳票、CSV、入力表、作業表、確認表がコードと密接につながります。したがって、名前はコードだけではなく、業務資料、関数一覧、モジュール構成、操作説明とも対応している必要があります。

英語名が悪いわけではありません。日本語名が常に良いわけでもありません。大切なのは、業務上の分類、対象物、動作、副作用、呼び出し範囲が読めることです。

19. 最終定義

この規約を一文で定義すると、次のようになります。

VBA業務マクロの関数名は、3文字接頭辞でレイヤーを示し、対象物と動作名詞で処理内容を示す。

モジュール名は業務上の住所として使い、関数名が長くなりすぎる場合は業務分類をモジュール名に逃がす。

ただしPublic関数は、VBAの弱い名前空間を考慮し、関数名単体でもプロジェクト内で一意になるようにする。

短く言えば、次のとおりです。

モジュール名 = 業務上の住所

3文字接頭辞 = レイヤー

対象物 = 操作対象

動作名詞 = 仕事

Public名 = 外から見ても一意

Private名 = モジュール文脈で短くする

この方式により、VBAマクロの関数名は単なる処理名ではなく、業務処理の地図として機能します。

名前を整えることは、表面をきれいにすることではありません。業務処理の入口、判断、データ操作、共通部品、支援処理を分け、後から読める形で残すことです。

業務マクロは、作った本人だけが動かせればよいものではありません。運用され、修正され、引き継がれ、別の業務へ応用されます。そのとき、関数名とモジュール名が地図になっていれば、コードは単なる手続きの集まりではなく、説明できる業務資産になります。

出典メモ

本記事は、LWP内部メモ「VBA業務マクロ 命名設計規約」を素材として、公開記事向けに再構成したものです。

原案の主張である「モジュール名を業務上の住所とし、3文字接頭辞、対象物、動作名詞で処理内容を示す」という骨格は維持しました。公開記事化にあたり、導入、想定読者、Public/Privateの判断軸、COM 接頭辞の注意、英語名でのBoolean命名、既存マクロへの適用順序を補足しました。