Excel VBAを長く使うブックでは、機能を追加するたびにコードの置き場所や命名が変わると、読み解きと修正に時間がかかります。AIと一緒に開発する場合も、暗黙の書き方では既存コードとのずれが起きやすくなります。
チームや個人の規約を短い資料として残し、作業前に読む手順にすると、同じブックを継続して変更しやすくなります。以下は一つのExcel業務ブックで使われた規約の一般化例です。名前や番号体系は既存プロジェクトに合わせて決めてください。
モジュールごとに責務を分ける
業務機能、データ取得、画面部品、開発時だけ使う処理を別モジュールに分けます。シートイベントには対象イベントを受け取る入口だけを置き、複雑な処理は標準モジュールの手続きへ委譲します。
Private Sub Worksheet_Change(ByVal Target As Range)
Call Handle07_SearchInput(Target)
End Sub
データ取得や列定義を一か所へ集めると、表の構造を確認する場所が分かりやすくなります。開発時だけ使うモジュールは運用コードと区別し、ブックへ取り込む共通部品は配布元を明確にして手修正を避けます。
名前定義とEnumで位置の直書きを減らす
セル番地や列番号を処理のあちこちへ直接書くと、表に列や行を挿入したときに参照がずれます。基準セルにはシート単位の名前定義を付け、DBの列はEnumで意味のある名前にします。
Public Enum Enum_Income
IncomeId = 1
RegisteredDate = 2
Amount = 3
End Enum
Dim Cell_Start As Range
Set Cell_Start = Sheet.Range("IncomeTableStart") ' B6
名前定義が不足すると処理できない場合は、実処理の前に必要な名前をまとめて検査し、足りない名前を示して終了します。コメントには現在のセル番地も残し、レイアウト変更時の確認を助けます。
入口と内部処理を命名で区別する
ボタンやメニューから呼ぶPublic手続き、シートイベントから呼ぶ処理、データ取得、Private補助関数で命名パターンを分けると、呼び出し元と責務を検索しやすくなります。たとえば機能番号を付けたRun07_...、イベント用のEvent07_...、取得用のGet03_...のような体系が考えられます。
変数も型や用途の接頭辞を揃えると、配列・セル・行番号の取り違えを見つけやすくなります。大事なのは特定の接頭辞そのものではなく、既存コードと一致した一貫した規約を選ぶことです。
共通部品の一覧を先に探す
フィルター、配列の切り出し、セル範囲取得、ファイル入出力などは、各モジュールで似た関数を作る前に既存の共通部品を検索します。部品一覧には関数名だけでなく、引数、戻り値、配列の添字、空データ時の動作、注意点も記録します。
共通部品が使えない環境向けの代替と、実際のExcelバージョンが必要な関数を分けて記載すれば、AIや新しい担当者も誤った実装を避けやすくなります。共通関数を変更する前には、利用箇所を検索して影響範囲を確認します。
表への出力は配列単位にする
多くのセルへ値を一つずつ書くより、二次元配列を作って範囲へまとめて出力します。必要に応じて画面更新・自動計算・イベントを一時停止し、エラー時にも元の設定へ戻す後処理を用意します。
表の行数が変わる処理では、数式や書式が引き継がれる挿入位置を決め、余った行をどう扱うかもルール化します。ユーザーが追加した列へ影響しないよう、出力範囲を明確にすることも大切です。
編集単位と検証範囲を明記する
一回の変更をモジュール単位にし、配布元のコードとブックへ取り込んだコードを混同しないようにします。VBAモジュールのエクスポート形式、文字コード、シートモジュールの取り込み方法など、実際の環境で決まっている手順はプロジェクトのREADMEや手順書へ記録します。
Excelを起動してコンパイル・実行していないコードは、動作確認済みと表現しません。静的確認、コンパイル、実ブックでの操作確認を分けて報告し、利用者に必要な確認手順を渡します。
まとめ
VBAの保守性は、モジュールの責務、参照方法、命名、共通部品、出力方法、検証範囲を規約として共有することで高められます。規約は一度決めて終わりではなく、実際に起きた失敗を既知の注意点として追記し、次の変更前に参照できる形に保ちます。