VBA開発が進むほど、モジュールの数は増え続けます。
命名がバラバラ、役割が曖昧、どこに何があるかわからない……
そんな整理されていないプロジェクトは、保守性が低く、改修時のコストが一気に跳ね上がります。
この記事では、VBA プロジェクトを効率よく管理するための
「複数モジュールの命名ルール」 と 「役割の明確化」 を実務視点で解説します。
1. モジュール整理の重要性
VBAではプロシージャをカテゴリごとに分割せずに追加し続けると、
- どの処理がどこにあるかわからない
- 関数の重複・似た処理の乱立
- バグが発生しても原因箇所が特定しにくい
といった問題が起こります。
そこで鍵となるのが 「モジュール名と役割の一貫性」 です。
2. モジュールに名前を付ける基本原則
●（1）役割ベースで命名する
最も重要なのは、**「中身が何をしているかひと目でわかる」**命名です。
例：
mdl_Main（メイン処理）mdl_Utility（汎用関数・共通処理）mdl_FileIO（ファイル入出力）mdl_Calc（計算処理・ロジック）mdl_Const（定数だけをまとめる）
➡ 役割が明確なら、モジュールを開かなくても内容を想像できます。
●（2）接頭辞（Prefix）を統一する
モジュール種別ごとに接頭辞を統一すると、プロジェクト全体の可読性が向上します。
推奨例：
| 種類 | 接頭辞例 | 説明 |
|---|---|---|
| 標準モジュール | mdl_ | 基本処理 |
| クラスモジュール | cls_ | オブジェクト指向的な処理 |
| フォーム（UserForm） | frm_ | 入力フォーム |
これだけで一覧画面が圧倒的に見やすくなります。
●（3）役割が重複しないように分割する
以下のような“混ぜモジュール”は NG です。
- 計算関数とファイル処理が同居
- Excel操作と文字列操作が混在
- 定数が各モジュールにバラバラに記載される
特に初心者にありがちですが、
「ひとまずここに書く」 という運用を続けるとプロジェクトは崩壊します。
➡ モジュールの役割は必ず“1カテゴリ＝1モジュール”に絞る。
3. モジュール構造例（実務標準）
実際のプロジェクトでよく使われる構成例を紹介します。
●（例1）一般的な業務システム
mdl_Main … メイン処理、エントリーポイント
mdl_Utility … 汎用関数（文字列、日付、配列など）
mdl_FileIO … CSV/テキスト入出力
mdl_ExcelCtrl … ワークシート・セル操作
mdl_Const … 定数
cls_Order … 注文データを扱うクラス
cls_Logger … ログ記録クラス●（例2）小規模ツール
mdl_Main
mdl_Utility
mdl_Validation … 入力チェック関数
mdl_Const規模に応じてモジュールを分割し、自分のプロジェクトに最適化していくことが大切です。
4. 命名ルールの決め方とドキュメント化
プロジェクト初期に、以下を必ず決めてドキュメント化しておきます。
- 接頭辞のルール
- モジュール名のフォーマット
- モジュールの役割定義
- 新しい処理を追加するときの運用ルール
小規模プロジェクトでも、数ヶ月後にはルールなしでは崩壊します。
「未来の自分（もしくは別の担当者）」が読みやすい構成を最優先にします。
5. よくある悪い例と改善ポイント
●（悪い例1）Module1, Module2 のまま使う
➡ 中身がまったくわからず最悪。必ず名前をつける。
●（悪い例2）Utility モジュールがなんでも詰め込み状態
➡ “ごみ箱モジュール”になりがち。
改善策：
- Excel操作 →
mdl_ExcelCtrl - 文字列処理 →
mdl_String
など細分化する。
●（悪い例3）同じ処理が複数モジュールに散らばっている
➡ 一元管理できずバグに気づきにくい。
改善策：
- 共通関数は
mdl_Utilityに統一 - 定数は
mdl_Constに集約
6. まとめ
複数モジュールを整理するポイントは次のとおりです。
- 役割を明確にしてカテゴリごとに分割する
- 接頭辞を統一し、一覧で見ても理解できる構成にする
- 混在モジュールを作らず、1モジュール＝1役割に徹する
- 運用ルールを文書化し、プロジェクト全体で守る
モジュール構成は“プロジェクトの読みやすさ・保守性”を左右する重要な設計要素です。
システム規模が大きくなるほど、命名ルールと役割整理の効果が大きくなります。
コメント