VBAの変数名の付け方｜実務で迷わない命名設計・ルール・具体例

VBAの変数名が実務で重要になる理由

VBAでは、ルール上使える名前であれば短い名前でも長い名前でも処理できますが、実務では「動くこと」だけでなく、後から読んだときに意味を復元しやすいことまで含めて変数名を決める必要があります。

変数名は処理結果そのものを決める機能ではありませんが、修正箇所を探す時間、レビューで意図を確認する時間、引き継ぎ時にコードを読み解く時間には直接影響します。

とくにExcel VBAは、小さな集計マクロから複数シートや複数ブックを扱う業務ツールまで同じ言語で作れるため、最初は数十行だったコードが改修を重ねて大きくなることがあります。

そのため、作成時に数秒だけ意識して付けた名前が、半年後や担当変更後の保守時間を何度も節約するという考え方が実務では有効です。

動けばOKの変数名は後から読む時間を増やす

a、b、data1、tmpのような名前でも、作成直後は「何を入れているか」を頭の中で覚えているため、問題なく作業できることがあります。

しかし、lastRow、rowIndex、salesData、targetSheetのように役割が読み取れる名前なら、宣言行や代入行まで戻らなくても処理の意味を推測しやすくなります。

たとえば「最終行」と「現在処理している行番号」がどちらもLong型だからといって、lng1とlng2にすると、型は分かっても役割を毎回確認しなければなりません。

lastRowとrowIndexに分ければ、IfやForの途中で登場しても、どちらが処理範囲でどちらが現在位置なのかを判断しやすくなります。

実務で避けたいのは短い名前そのものではなく、「その名前を見ただけでは複数の意味に取れて、周辺コードを読み直さないと役割を確定できない状態」です。

変数が一度しか登場しない短い処理と、複数のプロシージャで似た値を扱う処理では必要な具体性が違うため、名前の長さではなく確認回数で判断すると過不足を減らせます。

たとえば売上集計で最終行を取るだけならlastRowで十分ですが、売上シートと顧客シートの最終行を同時に保持するならsalesLastRowとcustomerLastRowまで具体化すると、比較や転記条件を読み違えにくくなります。

同じ名前を使い回す方が短く書けても、処理対象が切り替わるたびに頭の中で意味を再定義する必要があるなら、その省略は保守時間を増やす可能性があります。

作った本人でも数か月後には他人のコードに近くなる

自分だけが使うマクロであっても、数か月触らなければ、変数へ何を入れたか、なぜその順番で処理したかという記憶は薄れていきます。

そのときdata1とdata2よりsalesDataとcustomerDataの方が、コードを開いた瞬間に当時の設計を思い出す手がかりになります。

「未来の自分も初めて読む人に近い」と考えると、変数名を少し具体的にする意味が分かりやすくなります。

保守では新しく書く時間より、既存コードの意図を安全に理解する時間が長くなることがあり、変数名はその理解コストを下げるための小さな設計情報として働きます。

とくに似た処理が連続するマクロでは、sourceSheet、destinationSheet、targetWorkbookのように対象と役割を組み合わせると、操作先を取り違えるリスクも減らしやすくなります。

まず知っておきたいVBAの変数名の基本ルール

VBAで使える名前には言語上の制約があり、Microsoft Learnでは、先頭を文字にすること、空白や一部の記号を使えないこと、名前を255文字以内にすることなどが示されています。

また、同じスコープ内で同じ名前を重複して宣言できず、Visual Basicは大文字小文字を区別しないため、CustomerNameとcustomerNameを別変数として使い分けることはできません。

詳しい制約はMicrosoft LearnのVisual Basic naming rulesで確認できます。

Microsoft Learnでは、言語やホストアプリケーションが持つ関数・ステートメント・メソッドなどと同じ名前を避けることも案内されており、既存名を隠してしまうような命名は保守上も避けた方が安全です。

ここで重要なのは、言語として「使える名前」と、実務で「読みやすい名前」は別の問題だという点で、文法上有効なdata1でも保守しやすいとは限りません。

まず公式の最低条件を守り、その上で役割、一貫性、読みやすさを設計するという二段階で考えると、命名規則の話を整理しやすくなります。

実務ではさらに、予約語や組み込み関数と紛らわしい名前を避けることで、コードを読んだ人が「これはVBA標準の機能か、自作した変数か」を迷いにくくなります。

たとえばLeftのようにVBA側ですでに意味を持つ名前を変数へ使うより、leftTextやleftPositionのように役割を明確にした方が、標準関数との区別を保ちやすくなります。

VBAの変数名には時間を使いすぎないことも重要

分かりやすい名前を付けることは重要ですが、変数を一つ宣言するたびに最適な英単語を探して何分も悩むようになると、開発速度は落ちてしまいます。

実務では完璧な名前を毎回発明するより、よく使う役割を定番化し、迷う回数そのものを減らす方が再現性のある方法です。

命名候補が複数あるときに毎回ゼロから比較するのではなく、既存のコードから同じ役割の名前を探して再利用するだけでも、作成速度と一貫性を同時に確保できます。

名前を考える時間をゼロにする必要はなく、「保守で意味を取り違えない最低限の具体性を確保したら先へ進む」という終了条件を持つことがポイントです。

よく使う変数名は毎回考えず定番化する

最終行ならlastRow、最終列ならlastColumn、行番号ならrowIndex、列番号ならcolumnIndexのように、自分やチームで基本形を決めておくと毎回の判断を減らせます。

シートやブックも、targetSheet、sourceSheet、destinationSheet、targetWorkbookのように「対象」や「役割」を表す語を組み合わせれば、多くの業務マクロへ流用できます。

この表をそのまま絶対ルールにする必要はなく、既存コードですでにwsSrcやwsDstが定着しているなら、そのプロジェクトでは既存の形式を優先する方が一貫性を保てます。

定番化の目的は名称辞書を大きくすることではなく、頻繁に起きる小さな判断を減らして、処理ロジックや例外処理へ集中できる時間を増やすことです。

定番名は一度決めたら永久に固定する必要はなく、実際の保守で意味が曖昧だと分かった場合は、次の改修でより具体的な名前へ更新し、以後の新規コードへ反映する運用が現実的です。

完璧な英語より意味が伝わる名前を優先する

変数名を英語にするときは、英文として自然かどうかより、コードを読む人が何を保持しているか判断できることを優先します。

customerName、productName、totalAmount、folderPathのような一般的な単語の組み合わせでも、役割が一貫していれば十分に実務で使えます。

逆に、辞書で見つけた難しい単語を使った結果、チームの誰も意味を即答できないのであれば、英語として厳密でも保守には向きません。

社内VBAでは同じ人たちが繰り返し読むことが多いため、洗練された語彙より、全員が同じ意味で理解できる語彙を選ぶ方が判断を速くできます。

命名で迷ったときは役割・対象・補足の順で考える

名前が決まらないときは、まず「何の役割か」、次に「何を対象にしているか」、必要なら最後に「どの状態や方向か」を足すと整理しやすくなります。

たとえばcountだけでは曖昧ならprocessedCount、sheetだけでは曖昧ならsourceSheet、pathだけでは曖昧ならoutputFilePathのように必要な情報だけを追加します。

この方法なら最初から長い名前を考えずに済み、意味が不足している部分だけを後から足せるため、命名に時間を使いすぎにくくなります。

「半年後にこの名前を見て、宣言行まで戻らずに役割を推測できるか」を最後の確認にすると、完璧さではなく実務上の十分さで判断できます。

さらに、候補が二つあって迷うときは、既存コードで多く使われている方、チーム内で口頭説明しやすい方、検索置換したときに対象を絞りやすい方を優先すると決めると、命名で停滞しにくくなります。

VBAではstrなどの接頭辞を命名の定番として使う方法もある

VBAではstr、lng、dbl、bln、ws、wb、rngなどを名前の先頭に付け、型やオブジェクト種別を見分けやすくする書き方が使われることがあります。

ただし、こうした接頭辞はVBAの言語仕様で必須とされる命名ルールではないため、採用するかどうかはプロジェクトの方針として決めます。

接頭辞は「付ければ読みやすくなる魔法の規則」ではなく、同じ形式を継続して使うことで初めて補助情報として機能します。

str・lng・wsなどを先頭に付ける考え方

接頭辞を使う場合は、strCustomerName、lngLastRow、blnFileExists、wsTarget、wbSourceのように、型やオブジェクト種別の後ろへ役割を続けます。

接頭辞を採用すると、宣言場所から離れたコードでも「これはWorksheetなのかLongなのか」を名前から補助的に判断できるため、古いVBA資産で継続利用されていることがあります。

一方で、As StringやAs Longの宣言が近くにあり、役割名だけで十分読みやすいコードでは、接頭辞なしのcustomerNameやlastRowを選ぶ方針も成立します。

str1では型しか分からないことに注意する

str1から分かるのはStringらしいということだけで、その文字列が顧客名なのか商品名なのかファイル名なのかは分かりません。

lng1も同様で、最終行、処理件数、現在行、エラー件数など複数の役割が考えられるため、型接頭辞だけで意味を代用しないことが重要です。

strCustomerName、strProductName、strFileNameのように役割まで含めるか、接頭辞を使わないならcustomerName、productName、fileNameのようにします。

接頭辞を付けたことで安心して意味部分を連番にしてしまうと、「型は読めるが処理は読めない」という状態になるため、実務では役割を表す語を主役に考えます。

接頭辞を使うかどうかはプロジェクト単位で決める

新規の小さなマクロなら、自分が継続して守れる形式を一つ決めれば十分です。

既存プロジェクトへ機能を追加する場合は、自分の好みより、そのコードですでに使われている形式へ合わせる方が全体の読みやすさを保てます。

接頭辞ありとなしを同じプロジェクト内で無計画に混在させると、「この違いには意味があるのか」と読む側へ余計な判断を発生させます。

採用判断では「型情報を名前へ入れることで読みやすくなるか」「既存コードと揃うか」「チームで無理なく維持できるか」の三点を確認すると過剰なルール化を避けやすくなります。

接頭辞を採用した場合でも、変数の型を変更したときに名前側の接頭辞を直し忘れると、lngAmountなのに実際はCurrency型というような不一致が生まれるため、リファクタリング時には宣言と名前を同時に確認します。

この不一致を避けるために接頭辞を使わない方針を選ぶチームもあり、どちらの方式でも「運用時に情報が古くならないか」という観点が重要です。

VBAの命名規則を覚えることと実務の命名設計は分けて考える

キャメルケース、スネークケース、ハンガリアン記法などの用語を知ることと、実務で保守しやすい変数名を継続して付けられることは別の課題です。

形式の名前を多く覚えるより、同じプロジェクトで表記と意味の付け方を揃え、読む人の判断を減らすことを優先します。

命名規則はコードを書く人を細かく縛るためではなく、同じ役割なら似た名前になる状態を作り、読み手が意味を予測できるようにするための仕組みです。

命名規則ではなく「判断回数を減らせるか」で考える

最終行はlastRow、転記元はsource、転記先はdestination、BooleanはTrueの意味が読める名前にする、といった少数の約束でも判断回数は減らせます。

ルールを増やしすぎると、新しい変数を作るたびに規約を確認する必要が生まれ、命名規則そのものが作業コストになります。

最初は頻出する役割だけを標準化し、実際に迷いが繰り返し発生した項目だけ後から追加する方が、現場に定着しやすい規則になります。

規約文書を作る場合も、抽象的な「分かりやすく命名する」だけでなく、lastRow、sourceSheet、processedCountのような代表例を数個入れておくと判断基準を共有しやすくなります。

さらに、規約では「略語を何文字までにする」といった細則より、同じ概念を同じ単語で呼ぶことを優先し、customerとclient、destinationとtargetのような近い言葉を無目的に混在させない方が検索性も上がります。

VBAで使える名前と読みやすい名前を混同しない

Microsoft Learnが示す命名ルールは、VBAで識別子として成立させるための最低条件であり、lastRowとdata1のどちらが保守しやすいかまでは決めてくれません。

そのため、公式ルールで「使えること」を確認した後、実務ルールで「役割が分かること」「既存コードと揃うこと」「必要以上に長くないこと」を確認します。

この二段階を分けて考えると、キャメルケースにするか、接頭辞を付けるかといった好みの議論が、言語仕様上の正誤と混ざりにくくなります。

Option Explicitは命名の分かりやすさとは別に宣言ミスを防ぐ

Option Explicitをモジュール先頭で使用すると、変数をDim、Private、Public、ReDim、Staticなどで明示的に宣言する必要があり、未宣言の名前を使うとコンパイル時にエラーになります。

これは分かりやすい名前を自動で作る機能ではありませんが、タイプミスで意図しない変数名を使ってしまう問題を見つけやすくするため、命名と合わせて使う価値があります。

詳しい挙動はMicrosoft LearnのOption Explicit statementで確認できます。

Option Explicitを使うと、たとえばlastRowと書くべき場所でlastRwoとタイプした場合、それが暗黙の別変数として進むのではなく未宣言名として検出されるため、命名の揺れを早い段階で見つけやすくなります。

ただし、Option Explicitが検出するのは宣言漏れであり、customerDataという名前に実際は商品データを入れているような意味上の不一致までは防げないため、宣言チェックと命名設計は補完関係として考えます。

また、変数宣言やスコープから整理したい場合は、サイト内の変数宣言の解説と合わせて確認すると、名前、型、スコープを一続きで理解できます。

VBAでは変数の型より役割が伝わる名前を優先する

StringやLongなどの型情報は重要ですが、保守時に知りたいのは「何型か」だけでなく、その変数が処理の中で何を表しているかです。

同じ型の変数が複数登場するほど、型だけでは区別できないため、名前には値やオブジェクトの役割を持たせます。

型接頭辞を採用する場合も、接頭辞は補助情報として扱い、意味部分を具体的にするという順番を崩さない方が読みやすくなります。

同じ型でも役割によって変数名を変える

最終行、現在行、処理件数がすべてLong型でも、lastRow、rowIndex、processedCountなら用途を区別できます。

lngLastRow、lngRowIndex、lngProcessedCountのように接頭辞を使っても構いませんが、lng1、lng2、lng3では役割が残りません。

日付でもtargetDate、startDate、endDateでは意味が違い、文字列でもcustomerName、fileName、folderPathでは後続処理が異なるため、「型が同じだから似た名前でよい」と考えないことが重要です。

名前を決めるときは「この値は何型か」の次に「何を保持するのか」「どの処理で何の判断に使うのか」まで一度確認すると、役割語を選びやすくなります。

Boolean型はTrueになったときの意味を名前にする

Boolean型はTrueとFalseの二値で条件分岐に使われるため、flagやblnFlagだけでは何を意味するTrueなのか判断できません。

ファイルが存在するときTrueならfileExistsやblnFileExists、処理が完了しているときTrueならisCompletedのように、Trueの状態を読める名前にします。

isNotValidのように否定形を重ねるとIf Not isNotValid Thenのような読みづらい条件になりやすいため、可能なら肯定形で状態を表すと条件式を追いやすくなります。

Boolean名は「質問として読めるか」を確認すると判断しやすく、fileExistsなら「ファイルは存在するか」、hasErrorなら「エラーを持つか」と自然に読み替えられます。

WorksheetやWorkbookは対象と役割を組み合わせる

Worksheet型やWorkbook型は、同時に複数を扱うと参照先の取り違えが起きやすいため、ws1やbook1よりsourceSheet、destinationSheet、targetWorkbookのような役割名が重要になります。

接頭辞を使うならwsSource、wsDestination、wbTargetでもよく、重要なのは「どのオブジェクトを指すのか」を名前から予測できることです。

RangeもrngDataだけで十分な場面はありますが、入力範囲と出力範囲を同時に扱うならinputRange、outputRange、rngInput、rngOutputのように関係を分けます。

オブジェクト型の命名はデータ型の違いより操作対象の違いが事故につながりやすいため、長い処理ではとくにsource、target、input、outputなどの役割語を明示する価値があります。

複数ブック間の転記では、sourceWorkbookとdestinationWorkbook、sourceSheetとdestinationSheetのように同じ方向語を階層ごとに揃えると、SetやCopyの行を追うときにデータの流れを読みやすくなります。

一方、targetを「検索対象」と「転記先」の両方の意味で使うと同じコード内で意味がぶれるため、source・destination・targetの使い分けもプロジェクト内で簡単に定義しておくと安全です。

VBAの変数名は処理が大きくなるほど具体的にする

短いマクロでは一文字の変数でも意味が分かることがありますが、処理が長くなり、ループ、シート、ファイル、配列が増えるほど短すぎる名前は追跡しにくくなります。

必要な具体性は一律ではないため、コードの規模、変数のスコープ、宣言場所と使用場所の距離を見ながら調整します。

「長い名前ほど良い」と考えるのではなく、読み手がその変数を誤解する余地が増えたときだけ情報を足すのが実務的です。

短いループならiを使う判断も間違いではない

数行だけのForループでiが明らかにカウンターとして使われているなら、iをrowIndexへ必ず変更しなければならないわけではありません。

一方、行と列の二重ループ、複数のカウンター、離れた位置での再利用があるなら、rowIndexとcolumnIndexのように具体化した方が読みやすくなります。

短い名前を使える条件は「意味が慣習で明らか」「有効範囲が短い」「似た役割の変数が近くにない」の三つで考えると判断しやすくなります。

この条件を外れたら、i、j、kを増やすより、rowIndex、columnIndex、itemIndexのように対象を表す語を追加します。

スコープが広い変数ほど名前へ情報を持たせる

プロシージャ内の数行だけで使う変数は周辺文脈から意味を補えますが、モジュールレベルや複数処理から参照される変数は、見る場所によって周辺文脈が変わります。

そのため、使用範囲が広い変数ほど、target、current、default、source、destinationなどの補足語を使い、単独でも役割を判断しやすくします。

スコープの考え方は命名だけの問題ではないため、必要なら変数宣言とスコープの基礎も確認し、そもそも変数の有効範囲を狭められないか検討します。

長すぎる名前は分解できない処理のサインになる

currentProcessingDestinationWorksheetRowNumberのように説明を詰め込みすぎると、名前を読むこと自体が負担になります。

名前が極端に長くなる場合は、変数名だけで問題を解決しようとせず、処理を小さなプロシージャへ分ける、対象をオブジェクトとしてまとめる、スコープを狭めるといった設計も検討します。

長い名前を短くするために意味を削りすぎるのではなく、文脈を小さくして短い名前でも誤解されない状態へ変えるという考え方です。

プロシージャを分割した結果、その中ではrowIndexだけで十分に意味が通るようになるなら、名前の長さを減らしながら可読性も上げられるため、命名と処理分割は別々に考えすぎない方がよいでしょう。

命名はコード設計の結果でもあるため、適切な名前がどうしても見つからないときは「この変数は本当に一つの役割だけを持っているか」を確認すると改善点が見つかることがあります。

たとえばdataというVariant変数へ配列を入れた後で件数を入れ、さらに結果文字列まで入れる設計では、どんな名前を付けても途中で意味が変わるため、変数をsalesRows、recordCount、resultMessageのように役割ごとへ分離する方が明確です。

名前を改善する作業は、単なる表記修正ではなく、一つの変数へ複数の責務を持たせていないかを見直す機会にもなります。

VBAの変数名は既存コードとの一貫性も重視する

実務では新規作成より、すでに動いているマクロへ機能追加や修正を行う場面が多く、そこでは個人の好みより既存コードとの一貫性が重要になります。

wsSource、wsTarget、lngLastRowで統一されているプロジェクトへ、突然sourceSheet、destinationSheet、lastRowだけを混ぜると、違いに意味があるのか読む側が迷います。

一貫性は美しさの問題だけでなく、「同じパターンなら同じ意味だろう」と予測できる状態を作ることで、レビューや修正時の判断を減らすためにあります。

自分の好みより既存プロジェクトに合わせる

既存コードが型接頭辞を使っているなら、新しく追加する変数も同じ形式へ合わせると、追加部分だけが異質に見えることを避けられます。

逆に既存コードが接頭辞なしで役割名を使っているなら、自分が普段strやlngを使っていても無理に持ち込まない方が自然です。

どちらが絶対に正しいかではなく、そのプロジェクトを読む人が余計なルール切り替えをせずに済むかを基準にします。

既存ルールが明文化されていなくても、複数のモジュールで繰り返し現れる命名パターンを確認すれば、実質的な慣習を見つけられることがあります。

機能修正と命名変更を無理に同時に行わない

バグ修正や仕様変更のついでに大量の変数名を変更すると、本来の機能差分と読みやすさ改善の差分が混ざり、レビューで変更理由を追いにくくなります。

命名変更自体に価値があっても、影響範囲が大きい場合は機能修正と分け、テスト対象を明確にする方が安全です。

変数名の変更後は、検索機能で旧名が残っていないかを確認し、コメントやメッセージ文字列まで機械的に置換していないかも見直すと、リファクタリングによる別の不具合を避けやすくなります。

とくに外部から呼ばれるPublicプロシージャや複数モジュールで参照される名前は、単純な置換では影響を見落とす可能性があるため、変更前に参照箇所を確認します。

「読みにくいから全部直す」ではなく、「今回触る範囲で誤解が起きやすい名前だけ直す」「大規模整理は別作業にする」と分けると、変更目的を保ちやすくなります。

チームでは最低限の定番だけ共有する

チーム規約は、最終行はlastRow、転記元はsource、転記先はdestination、BooleanはTrueの意味が読める名前にする、といった少数のルールから始められます。

さらにdata1やstr1のような役割不明の連番名を長期保守する変数では避ける、接頭辞を採用するなら同一プロジェクトで統一する、といった注意を共有します。

ルールが十数ページになって誰も見なくなるより、頻出する判断を一枚で確認できる方が実務では使われやすくなります。

新しい命名ルールを増やすときは、実際に同じ迷いが繰り返されたかを確認し、発生していない問題のために規則を増やさないことも大切です。

チーム規約には「推奨例」と「避けたい例」を対にして載せると、抽象的な説明だけより判断しやすく、lastRowは推奨、data1は長期保守では避ける、といった基準を短時間で共有できます。

また、既存資産を一斉に改名することを規約導入の条件にせず、新規作成や大きな改修から段階的に適用すると、命名改善のための変更量を抑えられます。

VBAではコメントで分かりにくい変数名をごまかさない

コメントを書けばxやdata1の意味を説明できますが、変数が何度も登場するたびにコメントへ戻る必要があるなら、保守負担は十分に減っていません。

変数名で表せる「何を保持しているか」は名前へ持たせ、コメントでは「なぜその処理をするのか」「なぜその条件なのか」を補うように役割を分けます。

コメントとコードは別々に更新されるため、名前が曖昧なまま説明だけをコメントへ依存すると、仕様変更後に説明が古くなるリスクもあります。

変数名には「何」、コメントには「なぜ」を残す

xという変数へA列の売上データの最終行を入れ、コメントで「xは最終行」と説明するより、lastRowという名前にして、コメントでは「A列を基準に処理対象範囲を決める」と理由を残す方が情報を分担できます。

lastRowは値の役割を説明し、コメントはその値を取得する目的や業務上の背景を説明するため、同じ内容を二重に書かずに済みます。

変数名だけで業務ルールの理由まで表そうとすると名前が長くなりすぎるため、「何」と「なぜ」を分けることで命名を適度な長さに保てます。

逆にコメントがなくても意味が分かる単純な代入へ、変数名と同じ説明を繰り返すコメントを付ける必要はありません。

コメントと名前が食い違ったらコードを読む人は迷う

仕様変更で基準列がA列からB列へ変わったのにコメントだけ古いまま残ると、実際の処理と説明が矛盾します。

名前が具体的であれば、コメントが不十分でも処理の役割を追える余地が残るため、コメントを補助情報として使う設計が安全です。

コメントは判断理由、例外条件、業務上の前提など、コードだけでは読み取りにくい情報へ使い、変数の型や単純な役割をすべて文章で説明する方法は避けます。

宣言・型・名前をセットで読む習慣を付ける

分かりやすい変数名だけでなく、Dimによる宣言、適切なデータ型、必要なスコープを組み合わせると、コードの意図をさらに追いやすくなります。

String、Long、Boolean、Worksheetなどの型の違いから整理したい場合は、サイト内のデータ型の違いを解説した記事も参考になります。

名前だけを整えても、Variantへ何でも入れる、必要以上に広いスコープで共有するといった設計が残れば、保守性の問題は解決しきれません。

命名は独立したテクニックではなく、宣言、型、スコープ、処理分割と合わせて「後から安全に理解できるコード」を作る要素の一つとして扱います。

たとえば変数名が明確でも、Publicで広範囲から書き換えられる状態なら値の由来を追う負担は残るため、必要以上に広いスコープを避けることが命名の効果を高めます。

VBAの変数名は他の人が保守する前提で決める

業務で使うVBAは、作成者がずっと保守できるとは限らず、担当変更、異動、休職、繁忙期の応援などで別の人がコードを読むことがあります。

そのため、自分だけが覚えている略語や一時的な連番より、初見でも役割を推測できる名前を選ぶ方が引き継ぎしやすくなります。

ただし、他人向けだからといってすべての変数へ長い説明を埋め込む必要はなく、一般的な役割語と一貫したパターンを繰り返す方が効果的です。

チームでは最低限の定番だけ共有する

複数人でVBAを管理するなら、lastRow、rowIndex、source、destination、isやhasを使うBoolean名など、よく出る項目だけを共通化します。

型接頭辞を採用するならプロジェクト内で形式を揃え、採用しないなら役割語を十分に具体的にするという方針も共有しておきます。

この程度の小さな共通ルールでも、コードレビューで名前の好みを毎回議論する時間を減らし、処理ロジックの確認へ集中しやすくなります。

レビューで命名について意見が分かれた場合も、「どちらが英語として美しいか」ではなく、「既存の命名と揃うか」「役割を誤読しにくいか」という基準に戻すと、好みの議論を短くできます。

略語はチーム全員が同じ意味で読めるものに絞る

ws、wb、rngのようにプロジェクト内で意味が共有されている略語は短縮に役立ちますが、自分だけが分かる略語を増やすと引き継ぎの障害になります。

たとえばcsをcustomerSheetの意味で使う人とcurrentSheetの意味で使う人がいれば、短くても読みやすいとはいえません。

略語を採用する場合は「別の意味に読み取れないか」「新しい担当者でも短時間で推測できるか」を確認し、曖昧なら単語を少し長くして意味を優先します。

レビューでは名前だけで役割を説明できるか確認する

コードレビューで「この変数には何が入りますか」と何度も質問が出るなら、名前が情報不足になっている可能性があります。

その場合は説明コメントを追加する前に、値、対象、状態、方向のどれが名前に欠けているかを確認します。

レビューで頻繁に指摘される命名パターンはチーム規約へ昇格させる候補ですが、一度しか出ない例外まで規則にすると運用が重くなるため、繰り返し発生するかを見ます。

引き継ぎ前には、すべての名前を美しく直すことより、重要な処理で意味不明な一文字名や連番名が残っていないか、同じ役割に複数の呼び方が混在していないかを優先して確認すると効果的です。

とくにファイル削除、上書き、転記先変更など影響の大きい処理では、targetやdestinationの意味が曖昧でないかを確認し、操作対象を名前から追える状態にしておくとレビューしやすくなります。

まとめ：VBAの変数名は作成時間と保守時間の両方を減らそう

VBAの変数名で目指すのは、すべての名前を完璧にすることではなく、作成者が名前で迷う時間と、保守担当者が意味を調べる時間の両方を減らすことです。

まずVBAで使える名前の公式ルールを守り、その上で型だけでなく役割を示し、同じプロジェクトでは同じ考え方を繰り返すことが基本になります。

接頭辞を使うか、キャメルケースにするかといった形式は手段であり、最終的には「このコードを数か月後に開いても、変数の役割を短時間で復元できるか」で判断します。

実務で迷ったときは5つの基準で確認する

命名に迷ったら、役割が分かるか、同じ型の別変数と区別できるか、既存コードと揃っているか、必要以上に長くないか、Trueやsourceなどの方向が誤解なく読めるかを確認します。

この5項目を毎回すべて文章で検討する必要はなく、頻繁に使う名前は定番化し、迷ったときだけチェックする運用で十分です。

変数名を直すべきタイミングを決めておく

新規作成時は最初から役割が伝わる名前を付け、既存コードでは今回の修正に必要な範囲と、命名整理だけの範囲を分けて考えます。

保守中に意味を何度も調べた変数、レビューで説明が必要だった変数、似た名前を取り違えた変数は、命名改善の優先候補です。

反対に、何年も問題なく使われ、役割も明確な短い名前を形式だけの理由で変更する必要はなく、変更による確認工数と得られる可読性を比べて判断します。

一方、短いループのiのように文脈だけで明確な名前まで機械的に長くすると、修正量が増えるだけで読みやすさが上がらない場合があります。

「短い名前を禁止する」のではなく、「意味を調べ直す時間を減らせるか」を基準にすると、過剰な命名ルールを避けながら保守性を高められます。

命名はコードを長く使うための小さな設計として考える

変数名は一行ごとの小さな要素ですが、コード全体で一貫すると、次に登場する名前の意味を予測しやすくなり、引き継ぎや修正の負担を減らします。

よく使う役割名を定番化し、BooleanはTrueの意味を表し、接頭辞は使うなら統一し、コメントには名前で表しにくい「なぜ」を残すという考え方から始めれば十分です。

名前を決める時間を最小限にしながら、未来の自分や別担当者が読む時間も短くすることが、実務VBAで使いやすい命名設計の到達点です。

最初から大規模な命名規約を作る必要はなく、lastRow、rowIndex、source、destination、fileExistsのような頻出パターンを数個決め、実際の保守で困ったところだけ追加していけば十分に改善できます。

変数名を「見た目を整える作業」ではなく「読む人の確認回数を減らす設計」と捉えると、短さ、具体性、接頭辞、コメントのどこへ力を使うべきか判断しやすくなります。

迷ったときは、宣言行だけを見るのではなく、その変数が代入される場所、条件分岐で使われる場所、書き込み先として使われる場所を順に確認すると、役割を表す語を選びやすくなります。

最終的には、名前だけで処理を完全説明するのではなく、型、スコープ、処理分割、コメントと情報を分担し、どこか一つへ説明を詰め込みすぎないことが長期保守のしやすさにつながります。

この考え方なら、短いコードでは簡潔さを保ち、大きな業務マクロでは必要な情報だけを名前へ追加するという柔軟な運用ができます。

つまり、命名は固定的な正解探しではなく、読む状況に合わせて十分な情報量を選ぶ作業です。