混沌を支配せよ：VBEオブジェクトを用いたコード解析によるリファクタリングの極意
Access開発の現場において、数万行に及ぶ「スパゲッティコード」の迷宮に足を踏み入れた経験はないだろうか。命名規則の崩壊、場当たり的なプロシージャの乱立。これらは技術的負債という名の時限爆弾だ。
今回は、IDE（VBE）の深淵を覗き込み、プロジェクト内のプロシージャ名を強制的に可視化・監査する、アーキテクト級のツールを紹介する。これは単なるコード抽出ではない。大規模開発における「コードの品質を統治するための外科手術」である。
1. VBEオブジェクトモデルという「特権階級」へのアクセス
VBAからVBE（Visual Basic Editor）を操作するには、参照設定で「Microsoft Visual Basic for Applications Extensibility 5.3」を有効化する必要がある。
しかし、ここで一つ重要な注意点がある。「信頼性」の問題だ。 Accessのオプション設定で「VBAプロジェクト オブジェクト モデルへのアクセスを信頼する」にチェックが入っていない限り、このプログラムは無力だ。システム管理者は、この設定をグループポリシーで配布するか、配布先環境のセキュリティ権限を厳密に管理しなければならない。
2. メモリ管理の極限：オブジェクトのライフサイクルを制御する
VBEオブジェクトはCOMである。循環参照や解放漏れは、Accessのメモリリークを招き、最悪の場合、IDEのクラッシュを引き起こす。以下のコードでは、`VBProject`や`VBComponent`を明示的に解放し、スタックをクリーンに保つ設計を徹底する。
コード解析エンジン：ProcedureLinter
以下のプロシージャは、全モジュールを走査し、命名規則（例：`Sub_`や`Func_`で始まらないもの）から外れたプロシージャを抽出する。
Option Explicit
‘ 参照設定: Microsoft Visual Basic for Applications Extensibility 5.3
Public Sub AuditProcedureNaming()
Dim oVBE As VBIDE.VBE
Dim oProj As VBIDE.VBProject
Dim oComp As VBIDE.VBComponent
Dim oCodeMod As VBIDE.CodeModule
Dim i As Long, startLine As Long, procName As String
Set oVBE = Application.VBE
Set oProj = oVBE.ActiveVBProject
‘ 出力用テーブル等の初期化はここで行う
Debug.Print “— 解析開始: ” & Now & ” —”
For Each oComp In oProj.VBComponents
Set oCodeMod = oComp.CodeModule
i = 1
Do While i < oCodeMod.CountOfLines
procName = oCodeMod.ProcOfLine(i, 0) ' 0: vbext_pk_Proc
If procName <> “” Then
‘ 命名規則チェック: “Sub_” または “Func_” で始まらないものを抽出
If Not (procName Like “Sub_” Or procName Like “Func_”) Then
Debug.Print “命名規則違反: ” & oComp.Name & “.” & procName
End If
‘ 次のプロシージャまでインデックスを飛ばす
i = i + oCodeMod.ProcCountLines(procName, 0)
Else
i = i + 1
End If
Loop
Next oComp
‘ 終了処理：メモリリークを許さない
Set oCodeMod = Nothing
Set oComp = Nothing
Set oProj = Nothing
Set oVBE = Nothing
End Sub
3. チーフアーキテクトからの助言：レガシーの断捨離
このスクリプトを運用する上で、いくつか現場の知見を授ける。
- APIによるウィンドウ制御: `FindWindow`や`SetForegroundWindow`といったWindows APIを併用すれば、解析実行時にVBEウィンドウを前面に強制表示させたり、逆にバックグラウンドでサイレント解析を行わせることも可能だ。
- 動的なコード生成の罠: `CodeModule.InsertLines` を使えば、コードの自動修正すら可能だが、これは諸刃の剣だ。VBAのコンパイル状況や呼び出しスタックを破壊する可能性があるため、必ずバックアップを取った環境で実行すること。
- 大規模環境への対応: 数十万行のコードを解析する場合、`DoEvents`をループに挟まないとAccessが「応答なし」になる。GUIのフリーズを防ぐには、シングルスレッドの限界を意識した非同期処理的思考が必要だ。
4. 最後に：技術は「規律」のためにある
コード解析ツールは、開発者の手元を離れた瞬間に「監視ツール」へと変貌する。しかし、真のアーキテクトは、これを「教育のツール」として使うべきだ。
「なぜこの命名規則が必要なのか」「なぜこのモジュール分割が保守性を高めるのか」。ツールが出力したリストを元に、チームで議論を行うこと。それこそが、技術的負債を解消し、システムを次の10年へ繋ぐための唯一の道である。
Accessという枯れた技術の中で、いかにモダンな設計思想を実装するか。その境界線にこそ、エンジニアとしての真価が問われている。さあ、今すぐプロジェクトをスキャンし、混沌に秩序を刻み込め。
