VBA Engineering VBAテクニック集 VBA一覧

【VBA】短いコードより読みやすいコードを優先する理由｜保守性を高める実務設計とは

VBAを書いていると、「もっと短く書けないだろうか」と考えることはありませんか。

実際、VBAには1行で書ける構文や、コード量を減らせる書き方が数多くあります。そのため、コードが短いほど優れたプログラムだと思われがちです。

しかし、実務ではコードを書く時間よりも、コードを読む時間や修正する時間の方が圧倒的に長くなります。

私自身も、以前はできるだけ短く書くことを意識していました。しかし、数か月後に自分でコードを見返したとき、「何を考えてこの処理を書いたのか分からない」と悩むことが何度もありました。

それ以降は、「短いコードを書くこと」ではなく、「誰が見ても理解できるコードを書くこと」を優先するようになりました。

この記事では、なぜ実務では短いコードよりも読みやすいコードが重要なのか、実際の開発現場で意識している設計の考え方を紹介します。

✅ 短いコードが必ずしも良いコードではない理由

プログラミングを始めたばかりの頃は、「コードは短いほど優秀」と考えてしまいがちです。

確かに、不要な処理を減らすことは大切です。しかし、必要以上にコードを短くすると、可読性や保守性が大きく低下することがあります。

実務では、一度完成したコードを何度も修正・流用するため、「短さ」よりも「理解しやすさ」が重要になります。

・読む時間の方が圧倒的に長い

VBAは、一度作って終わるものではありません。

例えば、

  • 新しい機能を追加する
  • 不具合を修正する
  • 他の業務へ流用する
  • 他の担当者へ引き継ぐ

といった場面では、まずコードを読むことから始まります。

つまり、コードを書く時間よりも、読む時間の方が圧倒的に長くなるのです。

そのため、「短く書けたか」ではなく、「すぐ理解できるか」を基準に設計した方が、結果として開発効率は高くなります。

・数か月後の自分も「他人」になる

実務で意外と多いのが、「自分が書いたコードなのに理解できない」というケースです。

私も以前、数か月前に作成したVBAを修正する機会がありました。

当時は「これ以上短く書けない」と満足していたコードでしたが、いざ見返してみると、

  • なぜこの変数を使っているのか
  • この条件分岐は何を判定しているのか
  • なぜこの順番で処理しているのか

が分からず、結局コードを読み直すことになりました。

この経験から、「未来の自分も他人だ」と考え、後から見ても理解できるコードを書くことを意識するようになりました。

・短く書くほどコメントも減りやすい

コードを1行へまとめると、コメントを書く場所も少なくなります。

すると、

If x = 1 Then Call ProcessA Else Call ProcessB

のように、動作は理解できても「なぜこの処理をしているのか」が分からないコードになりやすくなります。

実務では、処理内容よりも処理の目的を理解できることの方が重要です。

そのため、適度に改行し、コメントも添えながらコードを書く方が保守しやすくなります。

コードを短く書くことよりも、後から修正しやすい構成を意識する考え方は、Selectを使わない設計にも共通しています。保守性を高める実務的な考え方については、「【VBA】なぜ私はSelectを使わなくなったのか｜保守しやすいコードを書く考え方」もぜひご覧ください。

✅ 私が読みやすさを優先するようになったきっかけ

今では、コードを書くときに「短く書けるか」を考えることはほとんどありません。

それよりも、「半年後の自分が理解できるか」「他の担当者が修正できるか」を基準にしています。

この考え方になったのは、実際の業務で何度も失敗を経験したからです。

・修正に時間がかかるコードを何度も見てきた

以前の私は、

  • If文を1行で書く
  • 変数を極力減らす
  • 処理を詰め込む

ことが効率的だと思っていました。

しかし、実際には処理を追加するたびにコード全体を読み直す必要があり、修正のたびに時間がかかるようになってしまいました。

短く書いたことで、かえって開発効率を下げていたのです。

・レビューで指摘されたのはコードの長さではなかった

社内レビューや他の開発者とのやり取りでは、

「コードが長い」

と指摘されることはほとんどありませんでした。

代わりによく言われたのが、

  • 処理の意図が分からない
  • 変数名が分かりにくい
  • コメントを追加してほしい
  • 条件分岐を整理した方が良い

という内容です。

この経験から、実務ではコードの長さではなく、「読みやすさ」が評価されることを実感しました。

✅ 読みやすいコードは仕様変更にも強い

VBAは、完成した瞬間がゴールではありません。

業務内容が変われば、コードも必ず変更することになります。

そのため、最初から仕様変更を想定した設計にしておくことが重要です。

・変数名だけでも理解しやすさは変わる

例えば、

Dim x As String

よりも、

Dim departmentName As String

の方が、何を格納している変数なのか一目で分かります。

変数名を意味のある名前にするだけでも、コード全体の理解しやすさは大きく向上します。

・処理を詰め込みすぎないことも保守性につながる

実務では、後から処理を追加することが非常に多くあります。

そのため、

  • 適度に改行する
  • コメントを書く
  • 処理をまとめる
  • 役割ごとに整理する

といった基本的なことが、結果として保守性の高いコードにつながります。

読みやすいコードを書くためには、処理内容だけでなく変数名の付け方も重要です。実務で分かりやすい命名規則については、「【VBA】変数名の付け方｜キャメルケース・スネークケースなど命名規則を徹底解説」で詳しく解説しています。

✅ 私が現在意識しているコード設計

現在はコードを書くときに、「何文字で書けるか」ではなく、「半年後でもすぐ理解できるか」を最初に考えるようにしています。

実務では、一度作ったVBAを何度も修正したり、別の業務へ流用したりすることがほとんどです。そのため、最初から保守性を意識した設計にしておく方が、結果的に作業時間を短縮できます。

・処理内容が分かる変数名を付ける

以前は、

Dim x As String
Dim a As Long

のように短い変数名を使うこともありました。

しかし現在では、

Dim departmentName As String
Dim lastRow As Long
Dim targetWorkbook As Workbook

のように、変数名だけで役割が分かる名称を付けるようにしています。

・なぜこの書き方にしているのか

短い変数名は入力する手間を減らせますが、数週間後には「xは何を表していたのか」を思い出すところから始まります。

一方で意味のある名前なら、コードを読むだけで処理内容を理解しやすくなります。

実務ではタイピング時間よりも読解時間の方が圧倒的に長いため、多少長い名前でも可読性を優先した方が結果的に効率的です。

・実務で気を付けているポイント

変数名は「型」ではなく「役割」が分かる名前を付けています。

例えば、

  • departmentName
  • customerName
  • outputFolderPath
  • salesWorksheet

など、用途がすぐ分かる名称にすることで、仕様変更時の修正ミスも減らせます。

✅ コードを書く前に「処理の流れ」を考える

以前は思い付いた順番にコードを書き始めることもありました。

しかし現在では、処理の流れを整理してから実装するようにしています。

・いきなりコードを書かない

例えばCSVを取り込む処理であれば、

  1. 対象ファイルを取得する
  2. ファイルが存在するか確認する
  3. CSVを開く
  4. データを読み込む
  5. Excelへ出力する
  6. ファイルを閉じる

という流れを先に考えます。

その後で各処理をコードへ落とし込むようにしています。

・この考え方のメリット

処理全体を整理してから実装すると、

  • 処理漏れ
  • 同じコードの重複
  • エラー処理の抜け

などに気付きやすくなります。

また、仕様変更が発生した場合でも、「どこを修正すればよいか」が分かりやすくなります。

実務では、処理の流れを整理してから実装することで、条件分岐やデータ抽出も保守しやすくなります。具体的な実装例については、「【VBA】条件に合うデータを抽出する方法｜For文・IF文で実務データを自在に扱う」も参考にしてください。

 

✅ 短いコードを目指して失敗した経験

読みやすさを重視するようになったのは、実際に失敗を経験したからです。

今でも印象に残っている出来事があります。

・1行へまとめたことで修正が難しくなった

以前、条件分岐をできるだけ短く書こうと考え、

  • If文を1行で書く
  • コロン（:）で複数命令を並べる
  • ネストを減らすことだけを意識する

という書き方をしていました。

当時は「コード量が減った」と満足していました。

しかし数か月後、その処理へログ出力を追加することになり、結局すべて通常の書き方へ戻すことになりました。

短く書くことを優先した結果、後から修正する手間が増えてしまったのです。

・「書く時間」より「直す時間」の方が長かった

実際の業務では、

  • 新しい機能追加
  • 不具合修正
  • 他部署向けへの流用

などが何度も発生します。

そのたびに短く書いたコードを読み解く必要があり、「最初に数分短縮した時間」よりも、「後から数時間かけて修正する時間」の方がはるかに長くなっていました。

この経験から、短さではなく保守性を優先する考え方へ変わりました。

コードを短くしようとして無理に条件をまとめると、ネストが深くなり読みづらくなることがあります。ネストを避ける考え方については、「【VBA】ネスト（入れ子）とは？IF文を正しく使うための基本と実務判断」もあわせてご覧ください。

✅ 保守性を高めるために意識していること

読みやすいコードを書くために、現在は次のような点を意識しています。

・コメントは「何をしているか」ではなく「なぜするか」を書く

例えば、

' 最終行を取得
lastRow = Cells(Rows.Count, 1).End(xlUp).Row

よりも、

' データ件数は毎月変わるため、最終行を動的に取得する
lastRow = Cells(Rows.Count, 1).End(xlUp).Row

のように、処理の目的を書くようにしています。

これだけでも、後から見返したときの理解しやすさは大きく変わります。

・処理ごとに区切って書く

長いコードを1つの塊で書くのではなく、

  • データ取得
  • 入力チェック
  • メイン処理
  • 後処理

というように区切って記述しています。

処理単位が明確になるため、レビューや修正もしやすくなります。

・流用できる構成を考える

「今回だけ動けばよい」という考えではなく、

  • 他のブックでも使えるか
  • シート名が変わっても対応できるか
  • 保存先が変わっても修正しやすいか

を意識して設計しています。

この考え方が、結果として再利用性の高いVBAにつながっています。

保守性を高めるには、条件式そのものも読みやすく整理することが重要です。複雑な条件を分かりやすく記述する方法については、「【VBA】IF文の括弧を用いた複数条件｜可読性と誤判定を防ぐ設計手法」で詳しく紹介しています。

✅ 私が実務で判断するときの基準

コードを書くときに迷ったら、私は次のように考えるようにしています。

  • 半年後の自分が読めるか
  • 他の担当者でも理解できるか
  • コメントがなくても役割が分かるか
  • 仕様変更があっても修正しやすいか
  • 同じコードを書き直さずに流用できるか

もしどれか一つでも不安があるなら、多少コードが長くなっても読みやすい形へ書き直します。

実務では、その判断が後々の開発効率を大きく左右すると考えています。

実務では、条件分岐の書き方一つでも保守性は大きく変わります。読みやすく壊れにくい条件分岐の設計については、「【VBA】IF文のElseIfを用いた複数条件｜ネストを防ぎ実務で壊れない条件分岐を書く方法」も参考にしてください。

「読みやすいコード」を実際の条件分岐でどのように実現するかを知りたい方は、「【VBA】Select Caseで文字列を判定する方法｜複数条件を見やすく分岐する実務テクニック」もぜひご覧ください。

 

✅ まとめ：読みやすいコードは未来の自分とチームを助ける

この記事では、短いコードよりも読みやすいコードを優先する理由について、実務での経験を交えながら紹介しました。

  • コードを書く時間よりも読む・修正する時間の方が長い
  • 短く書き過ぎると可読性や保守性が低下しやすい
  • 意味のある変数名やコメントは理解しやすさにつながる
  • 処理の流れを整理してから実装すると仕様変更にも対応しやすい
  • コメントには「何をするか」ではなく「なぜするか」を残す
  • 「半年後の自分が理解できるか」を基準に設計すると保守性が高まる

VBAは、「動けば完成」ではなく、「将来も安心して修正・流用できる状態」が本当の完成形だと私は考えています。多少コードが長くなったとしても、読みやすさと保守性を優先することが、長期的には開発効率を高め、トラブルの少ないシステムづくりにつながります。

    -VBA Engineering, VBAテクニック集, VBA一覧