【Excel VBA】シートモジュール（Worksheet）は「View」に徹するべき！イベント処理の設計と書き方の注意点
Excel VBAで開発をしていると、シートごとに用意されている「Worksheetモジュール」にコードを書く機会があります。例えば、次のようなイベントプロシージャを見たことがあるかもしれません。
Debug.Print "Sheet1 Active!!!"
End Sub
このコード自体は「シートがアクティブになったときにイミディエイトウィンドウに文字を出力する」という非常にシンプルなものですが、ここに何でもかんでも書き込んでしまうのは、保守性の観点から大きなNGです。
この記事では、Worksheetモジュールとはそもそも何者なのか、そして「なぜビジネスロジックをここに書いてはいけないのか（Viewとしての役割分担）」を解説します。
1. Worksheetモジュールとは？（標準モジュールとの違い）
VBAのプロジェクトエクスプローラを開くと、通常の「標準モジュール（Module1など）」のほかに、各シート（Sheet1 (Sheet1) など）に対応した「シートモジュール（Worksheetモジュール）」が存在します。
- 標準モジュール：どこからでも呼び出せる汎用的なマクロや関数（プロシージャ）を置く場所。
- Worksheetモジュール：そのシート固有のイベント（セルが変更された、選択範囲が変わった、シートがアクティブになったなど）をフックして、自動実行させるコードを置く特別な場所。
冒頭の Worksheet_Activate も、シートが選択された瞬間に自動で発火するイベントプロシージャの一つです。
2. 「ここに書きすぎてはダメ！」な理由とビジネスロジックの分離
イベントを簡単に拾えるからといって、Worksheetモジュールの中にシートの判定処理、データの集計、データベースや外部ファイルとの連携といった複雑なビジネスロジック（処理の本質）を直接書き込んでしまうのはNGです。
理由は主に以下の通りです。
- コードが迷子になる：「あの処理はどこに書いてあったっけ？」となったとき、標準モジュールを探せばいいのか、特定のシートモジュールを探せばいいのか分からなくなります。
- 再利用性が低い：シートモジュール内のコードは、基本的に「そのシート」に紐づいているため、他のシートや別のブックから流用することが極めて困難になります。
- デバッグや保守がしんどくなる：イベントドリブンで勝手に発火するため、意図しないタイミングでロジックが走り、不具合の原因追跡（デバッグ）が難しくなります。
3. 「ここはView（表示・受付）だけよ」という設計思想
ソフトウェア設計の世界（MVCモデルなど）に倣うなら、Excel VBAのシートモジュールは「View（UI・画面の窓口）」として扱うのがベストプラクティスです。
シートモジュールの役割は、あくまで**「ユーザーの操作（イベント）を受け付け、標準モジュール側にあるメインの処理へバトンを渡すこと」**だけに留めましょう。
【正しいコードの書き方の例】
① シートモジュール側（Viewとしての受付のみ）
' 受付だけ行い、実際の処理は標準モジュールのプロシージャを呼び出す
Call MainLogic.InitializeSheetView(Me)
End Sub
② 標準モジュール側（ビジネスロジックを記述）
' ここにデータの取得や集計などのビジネスロジックをガッツリ書く
Debug.Print targetSheet.Name & " の初期化処理を実行中..."
End Sub
4. まとめ
- Worksheetモジュールは、シート独自のイベント（
Worksheet_Activateなど）を受け取るための「View（窓口）」として割り切って使う。 - 実際の計算やデータ処理などのビジネスロジックは標準モジュールに分離（カプセル化）する。
- シートモジュールから標準モジュールを呼ぶ際は、
Meキーワードなどを渡すことで柔軟に連携できる。
「シートのイベントだから全部ここに書いちゃえ」とコードを詰め込むと、後でメンテナンスに苦労することになります。役割をすっきり分けて、きれいなVBAコードを保ちましょう！