【VBA】変数名が重要な理由｜実務で保守しやすいコードを書く命名設計

VBAでマクロを作成していると、処理そのものとは別に意外と時間を取られるのが「変数名を何にするか」です。

最終行を取得する変数をlastRowにするか、rowLastにするか。文字列だからstrを付けるか。対象シートならwsTargetなのかtargetSheetなのか。処理内容は頭の中で決まっているのに、名前を考えるところで手が止まることがあります。

しかし、変数名を考える時間がもったいないからといって、a、str1、data1のような名前だけで作り続けると、今度は完成後の修正に時間がかかります。

実務で重要なのは、毎回完璧な変数名を考えることではありません。

よく使用する名前やパターンをある程度決めておき、作成時にも保守時にも余計な時間を使わないことです。

この記事では、キャメルケースやスネークケースといった命名規則そのものではなく、なぜ実務VBAで変数名が重要なのか、どこまで具体的な名前を付けるべきなのか、そして命名に時間を使いすぎないためにはどう考えればよいのかを解説します。

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

VBAは、ルール上使用できる名前であれば、分かりやすい変数名でも分かりにくい変数名でも処理できます。そのため、作成中は「自分が分かれば問題ない」と考えがちです。

しかし、実務で作成したマクロは一度完成したら終わりとは限りません。数か月後に仕様変更が発生したり、別の担当者が保守したりすることがあります。その時点では、作成した本人であってもコードの細かな意図を覚えていないことがあります。変数名は処理速度にはほとんど関係しませんが、コードを理解して修正するまでの時間には大きく関係します。だからこそ「動くかどうか」だけではなく、「後から読めるかどうか」まで考えて名前を付ける必要があります。

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

たとえば、次のコードでも処理そのものは成立します。

Sub ProcessSalesData()

    Dim a As Long
    Dim b As Long

    a = Cells(Rows.Count, "A").End(xlUp).Row

    For b = 2 To a
        ' 売上データを処理する
    Next b

End Sub

作成している本人は、

a：最終行
b：現在処理している行番号

と覚えているでしょう。

しかし、数か月後にこのコードを開くと、aが何だったのかを代入部分まで戻って確認しなければならない可能性があります。

そこで、役割が分かる名前へ変更します。

Sub ProcessSalesData()

    Dim lastRow As Long
    Dim rowIndex As Long

    ' A列を基準に売上データの最終行を取得する
    lastRow = Cells(Rows.Count, "A").End(xlUp).Row

    For rowIndex = 2 To lastRow
        ' 売上データを処理する
    Next rowIndex

End Sub

処理内容は同じです。

それでもlastRowと書かれていれば「最終行」、rowIndexなら「処理中の行番号」と推測できます。

つまり、分かりやすい変数名にする目的はコードを格好よくすることではありません。

変数の意味を調べるためにコードを行ったり来たりする時間を減らすことにあります。

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

「自分しか使わないVBAだから変数名は適当でもよい」と考えることもあります。

しかし、実務では自分自身も将来の保守担当者になります。

作成直後なら、

data1
data2
temp
result

でも、それぞれの意味を覚えているでしょう。

数か月間まったく触らなかった後では事情が変わります。

たとえば、

Dim data1 As Variant
Dim data2 As Variant

より、

Dim salesData As Variant
Dim customerData As Variant

とした方が、コードを開いた瞬間に処理内容を思い出しやすくなります。

実務では、「未来の自分も初めてこのコードを見るかもしれない」という前提で命名するくらいが現実的です。

変数名だけでなく、Dimを使った宣言方法やデータ型、変数を利用できる範囲（スコープ）から整理したい場合は、「【VBA】変数宣言とは？基本構文・データ型・スコープの考え方まで徹底解説！」もあわせて参考にしてください。

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

変数名が重要だと意識しすぎると、今度は逆の問題が発生します。「この英単語で本当に正しいのか」「もっと分かりやすい表現があるのではないか」と考え、変数を一つ宣言するだけで手が止まってしまうケースです。

読みやすいコードを書くことは重要ですが、変数名そのものが成果物ではありません。数秒で十分な名前を付けられるところに何分も使えば、開発全体の効率は落ちます。そこで有効なのが、よく使用する変数名をある程度パターン化してしまう方法です。毎回ゼロから考えるのではなく、「この役割ならこの名前」と決めておけば、読みやすさと開発速度を両立しやすくなります。

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

VBAでは、何度も登場する変数があります。

たとえば次のようなものです。

役割	名前の例
最終行	`lastRow`
最終列	`lastColumn`
行番号	`rowIndex`
列番号	`columnIndex`
対象シート	`targetSheet`
転記元シート	`sourceSheet`
転記先シート	`destinationSheet`
対象ブック	`targetWorkbook`
ファイル名	`fileName`
ファイルパス	`filePath`
フォルダーパス	`folderPath`

毎回、

「最終行だからendRowかな」

「いや、lastRowの方が自然か」

と考える必要はありません。

自分やチームの中でlastRowを使うと決めたなら、基本的には次のマクロでもlastRowを使います。

これには読みやすさだけでなく、名前を考えるという小さな判断を何度も繰り返さなくて済むメリットがあります。

実務では、こうした小さな迷いを減らすことも開発効率につながります。

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

英語の変数名を付けようとすると、「英語として正しい表現にしなければ」と考えてしまうことがあります。

しかし、変数名で優先したいのは英文としての完成度ではなく、コードを読む人に役割が伝わることです。

たとえば、

customerName
productName
totalAmount
targetSheet

のような一般的な単語の組み合わせでも、十分に役割を判断できます。

特に社内ツールでは、チーム内で同じ意味として理解でき、一貫して使用されていることが重要です。

命名に迷ったときは、

「数か月後にこれを見て、何が入っている変数か分かるか」

を一つの判断基準にすると、必要以上に悩まずに済みます。

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

VBAでは、strやlngなどを変数名の先頭に付けて、データ型を判断しやすくする書き方を目にすることがあります。ただし、これはVBAで必須とされている変数名のルールではありません。接頭辞を使わなくても、正しく型を宣言していればコードは動作します。

また、接頭辞の種類を細かく覚えること自体が目的になると、かえって命名に時間を使うことになります。実務で採用するなら、「名前を見たときに型を判断しやすい」「いつも同じパターンを使えるので命名に迷わない」といったメリットがあるかで判断するとよいでしょう。接頭辞を使う場合でも、型だけでなく変数の役割まで分かる名前にすることが重要です。

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

たとえば、文字列を格納する変数ならstr、Long型ならlngといった接頭辞を付ける方法があります。

Dim strCustomerName As String
Dim lngLastRow As Long
Dim dblSalesAmount As Double
Dim blnFileExists As Boolean
Dim wsTarget As Worksheet
Dim wbTarget As Workbook
Dim rngTarget As Range

代表的な例を整理すると、次のようになります。

種類	接頭辞の例	使用例
String	`str`	`strCustomerName`
Long	`lng`	`lngLastRow`
Double	`dbl`	`dblSalesAmount`
Boolean	`bln`	`blnFileExists`
Worksheet	`ws`	`wsTarget`
Workbook	`wb`	`wbTarget`
Range	`rng`	`rngTarget`

このような型を示す接頭辞は、VBAで見られる命名方法の一つですが、VBA自体が要求しているわけではありません。(Microsoft Learn)

たとえば、

Dim customerName As String

でも、

Dim strCustomerName As String

でも構いません。

重要なのは、接頭辞を付けることより、採用した方法を途中でころころ変えないことです。

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

命名時間を短縮するため、

Dim str1 As String
Dim str2 As String
Dim str3 As String

としたくなることもあります。

確かにstrからString型であることは分かります。

しかし、

「何の文字列なのか」

は分かりません。

たとえば顧客名、商品名、ファイル名を扱うのであれば、

Dim strCustomerName As String
Dim strProductName As String
Dim strFileName As String

とした方が役割まで判断できます。

接頭辞を使用しない方針なら、

Dim customerName As String
Dim productName As String
Dim fileName As String

でも十分です。

つまり、実務で優先したい順番は、

型が分かることより、まず役割が分かること

です。

strを付けることで毎回の命名パターンを決めやすくなるのであれば採用する価値があります。一方、接頭辞を考えること自体が負担になるなら、無理に導入する必要はありません。

strやlngなどの接頭辞を使う場合は、その前提となるString・Long・Double・Booleanなどの違いを理解しておくと、変数の役割を整理しやすくなります。詳しくは「【VBA】データ型の違いを徹底解説｜正しい使い分けでエラーと不具合を防ぐ」で解説しています。

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

変数名について調べると、キャメルケースやスネークケース、ハンガリアン記法など、さまざまな用語が出てきます。しかし、これらを詳しく知っていることと、保守しやすい業務マクロを書けることは必ずしも同じではありません。実務では、命名規則の名称を覚えることより、プロジェクト内で表記が統一されていることの方が重要です。

また、命名規則を増やしすぎれば、新しい変数を作るたびに「この場合はどのルールだったか」と確認する作業が発生します。ルールは多いほどよいのではなく、迷いを減らすために存在すると考えた方が実践しやすくなります。特に既存システムを保守するときは、自分の好みより既存コードとの一貫性を優先する判断も必要です。

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

たとえば自分の中で、

最終行はlastRow
行番号はrowIndex
転記元はsource
転記先はdestination
Boolean型はisやhasを使う
型接頭辞を採用するなら同じ形式で統一する

といった最低限のパターンを決めておきます。

そうすれば、新しいマクロを作るたびに命名方法をゼロから考える必要がありません。

ここで重要なのは、

「一般的に最も正しい命名規則を探すこと」ではなく、「自分やチームが迷わず同じ基準を使えること」

です。

承知しました。後半は既存の「キャメルケース・スネークケースなど命名規則」の記事へ寄らないよう、実務での判断・保守・引き継ぎ・既存コードとの一貫性を中心にします。

キャメルケースやスネークケースなど、変数名の具体的な表記方法や命名規則については、「【VBA】変数名の付け方｜キャメルケース・スネークケースなど命名規則を徹底解説」で詳しく解説しています。本記事では命名方法そのものではなく、実務での保守性や命名にかける時間とのバランスを中心に考えています。

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

変数名を決めるとき、StringやLongといったデータ型だけを意識すると、str1やlng1のような名前になりがちです。しかし、コードを後から読むときに本当に知りたいのは「この変数は何型なのか」だけではありません。むしろ、「何の値を保持しているのか」「この処理の中でどのような役割を持っているのか」の方が重要です。

同じLong型でも、最終行と処理件数では意味がまったく異なります。特に変数の宣言場所と使用場所が離れている長い処理では、役割が分からない名前ほど確認作業が増えていきます。型を表す接頭辞を利用する場合でも、型だけで終わらず役割まで伝わる名前を意識しましょう。

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

たとえば、次の変数はすべてLong型です。

Dim lng1 As Long
Dim lng2 As Long
Dim lng3 As Long

型だけを確認するなら問題ありません。

しかし、この3つが「最終行」「現在の行番号」「処理件数」だった場合、コードを読むたびにそれぞれの意味を確認する必要があります。

そこで、接頭辞を使う方針なら次のようにします。

Dim lngLastRow As Long
Dim lngRowIndex As Long
Dim lngProcessedCount As Long

接頭辞を使わない方針なら、

Dim lastRow As Long
Dim rowIndex As Long
Dim processedCount As Long

でも構いません。

どちらもlng1より処理上の役割が明確です。

つまり、変数名を決めるときは、

「何型か」→「何を保持するのか」

まで考えることがポイントです。

型を示す接頭辞は補助情報として利用し、変数の意味そのものを連番に置き換えないようにしましょう。

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

実務で特に名前の影響が大きいのがBoolean型です。

たとえば、

Dim blnFlag As Boolean

では、何を判定するフラグなのか分かりません。

ファイルが存在するか確認する変数なら、

Dim blnFileExists As Boolean

のようにすると意味が明確になります。

さらに条件分岐でも、

If blnFileExists Then
    ' ファイルが存在するときの処理
End If

となり、コードを上から読んだときに処理内容を理解しやすくなります。

Boolean型では特に、Trueのときに何を意味する変数なのかが名前から読み取れるようにすると、後から条件分岐を修正するときの負担を減らせます。

変数名では型だけでなく役割を伝えることが重要ですが、そもそもVBAでデータ型を指定する理由も理解しておくと設計の判断がしやすくなります。「【VBA】データ型はなぜ必要？処理速度・メモリ・エラー観点から徹底解説」では、型を指定する意味を実務目線で解説しています。

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

短いマクロと数百行に及ぶ業務ツールでは、必要になる変数名の具体性も変わります。数行しかないループならiだけでも意味を理解できますが、複数のループやシート操作が組み合わさると、短すぎる名前では役割を追いにくくなります。だからといって、すべての変数に長い名前を付ける必要もありません。

重要なのは、コードの規模や変数の有効範囲に応じて「どこまで説明しなければ意味が伝わらないか」を判断することです。実務では一律のルールに当てはめるより、読み手が確認に使う時間を基準に考えた方が現実的です。短くても明らかなものは短く、複数の意味に取れるものは具体的にするという使い分けができます。

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

たとえば、非常に短い繰り返し処理なら、

Dim i As Long

For i = 1 To 10
    Cells(i, "A").Value = i
Next i

でも、iがループカウンターであることは容易に判断できます。

このような場面で、

Dim currentProcessingRowNumber As Long

のような長い名前を付けても、必ずしも読みやすくなるとは限りません。

一方、行と列を同時に扱ったり、複数のループが存在したりする場合は、

Dim rowIndex As Long
Dim columnIndex As Long

とした方が役割を判断しやすくなります。

命名で重要なのは、

「短い名前を使ってはいけない」ではなく、「短くしても意味を失わないか」

という判断です。

ここでも完璧な名前を考えるのではなく、読む側が迷う可能性があるところだけ具体的にすれば、命名に必要以上の時間を使わずに済みます。

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

自分で新しいVBAをゼロから作る場合は、自分のルールで変数名を決められます。しかし実務では、他の担当者が作成した既存マクロを修正するケースも少なくありません。このとき、自分が普段使用している命名方法へすべて変更したくなることがあります。

しかし、命名方法を途中から大きく変えると、一つのプロジェクト内に複数の書き方が混在することになります。

また、変数名の一括変更は本来必要だった機能修正とは別の変更を増やすことにもなります。「自分ならこう書く」という好みだけではなく、既存コードとの一貫性や変更による影響まで考えて判断することが重要です。

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

たとえば既存コードが、

Dim wsSource As Worksheet
Dim wsTarget As Worksheet
Dim lngLastRow As Long

という書き方で統一されているとします。

自分は普段、

Dim sourceSheet As Worksheet
Dim targetSheet As Worksheet
Dim lastRow As Long

と書いていたとしても、既存コードへ機能を追加するなら、前者へ合わせる選択肢があります。

どちらが絶対的に優れているという話ではありません。

途中から、

wsSource
wsTarget
outputSheet
lastRow

のように混在する方が、プロジェクト全体としては分かりにくくなる可能性があります。

実務では、個人として好きな命名方法より、既存コードを読む人が迷わないことを優先した方がよい場面があります。

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

古いマクロを見ると、

Dim a As Long
Dim b As String
Dim c As Worksheet

のような変数名が残っていることがあります。

読みづらいからと、機能修正のついでに大量の変数名を変更したくなるかもしれません。

しかし、修正範囲を必要以上に広げると、

「本来変更したかった処理」と「読みやすくするために変更した処理」

が混在します。

小さな修正であれば、既存部分はそのままにして、新しく追加する処理だけ読みやすくする判断もできます。

大規模なリファクタリングを行うのであれば、機能追加とは分けて実施した方が変更内容を確認しやすくなります。

変数名は保守性を高めるためのものなので、名前を改善すること自体が保守リスクにならないようにすることも重要です。

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

コメントを追加すれば、分かりにくい変数名でも説明できると思うかもしれません。しかし、変数を使用するたびにコメントを確認しなければ意味が分からないコードでは、保守時の負担はあまり減りません。

また、後から処理内容だけ変更してコメントを修正し忘れると、コードと説明が食い違うこともあります。コメントはもちろん重要ですが、変数名で表現できる情報までコメントへ任せる必要はありません。名前には「何を保持しているか」を持たせ、コメントでは「なぜこの処理をしているのか」を補うように役割を分けると、コード全体を読みやすくできます。

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

たとえば、次のコードを考えてみます。

Dim x As Long

' xはA列の売上データの最終行
x = Cells(Rows.Count, "A").End(xlUp).Row

コメントがあるので意味は分かります。

しかし、その後のコードでxが10回登場すれば、そのたびに「xは何だったか」を思い出す必要があります。

そこで、

Dim lastRow As Long

' A列を基準に処理対象となる売上データの範囲を決める
lastRow = Cells(Rows.Count, "A").End(xlUp).Row

とします。

lastRowから「何を保持しているか」が分かり、コメントから「なぜ最終行を取得しているか」が分かります。

変数名とコメントに同じ説明を二重に書くのではなく、

変数名：値やオブジェクトの役割
コメント：処理の目的や判断理由

と分けると、後から読んだときにも理解しやすくなります。

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

業務で使用するVBAは、作成者がいつまでも保守できるとは限りません。担当変更や異動だけでなく、一時的に別の担当者が修正することもあります。そのとき、コードの読みやすさは引き継ぎのしやすさに直結します。

ただし、他人のためにすべてを細かく説明しようとして、巨大な変数名や大量のコメントを追加する必要はありません。重要なのは、一般的な名前を再利用し、同じ役割には同じ考え方で命名することです。初めてコードを見る人でも一定のパターンをつかめれば、次に登場する変数の意味も予測しやすくなります。個々の名前だけでなく、コード全体の一貫性まで含めて考えることが実務での命名設計につながります。

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

チームでVBAを管理する場合でも、細かな命名ルールを大量に作る必要はありません。

たとえば、

最終行はlastRowを基本にする
行番号はrowIndexを基本にする
転記元・転記先はsource・destinationで区別する
Boolean型はTrueの意味が伝わる名前にする
型接頭辞を採用するならプロジェクト内で統一する
data1やstr1のような名前は長期間保守する変数では避ける

といった最低限のルールだけでも効果があります。

ルールを増やしすぎると、今度はルールを確認するために時間を使うことになります。

命名ルールの目的は、開発者を細かく縛ることではありません。

誰が書いてもある程度同じ名前になり、誰が読んでも意味を予測できる状態を作ることです。

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

VBAでは、変数名が多少分かりにくくてもコードを動かすことはできます。しかし実務では、完成したマクロを後から修正したり、別の担当者へ引き継いだりすることがあります。そのため、変数名は作成時だけでなく、将来コードを読む時間まで考えて決めることが重要です。

一方、分かりやすい名前を付けようとして、毎回何分も命名に悩む必要はありません。よく使う名前を定番化し、必要なところだけ具体的にすることで、開発速度と保守性を両立できます。

変数名は型だけでなく、何を保持しているのか分かるようにする
str1やlng1だけでは、値の役割まで判断できない
str・lngなどの接頭辞を採用するなら、役割を表す名前と組み合わせる
短いループではiなどを使う判断もできる
処理が複雑になるほどrowIndexなど具体的な名前が役立つ
Boolean型はTrueになったときの意味が伝わる名前にする
既存VBAを修正するときは、自分の好みより既存コードとの一貫性も考える
機能修正と大規模な命名変更を安易に混在させない
変数名には「何」、コメントには「なぜ」を残す
頻繁に使う変数名を定番化して、命名そのものに使う時間を減らす

実務で目指したいのは、すべての変数に完璧な名前を付けることではありません。

作成者が名前を決めるために迷う時間と、将来の保守担当者が名前の意味を調べる時間。その両方を減らせる命名が、実務では使いやすい命名です。

キャメルケースやスネークケースなどの形式を決めることも大切ですが、その先にある「このコードを半年後でも迷わず修正できるか」という視点を持つことで、動くだけではなく、長く保守しやすいVBAへつなげられます。