Microsoft AccessでGOTO文を多用するプログラムは問題？保守性を高めるVBA設計の考え方

Microsoft AccessのVBAでプログラムを作成していると、GOTO文を使って処理を移動させる場面があります。しかし、GOTOを多用したコードを見ると「保守性を考えていないのでは？」と疑問に感じる人も少なくありません。

実際には、GOTO文そのものが必ず悪いわけではなく、使い方や目的によって評価が変わります。この記事では、Access VBAにおけるGOTO文のメリット・デメリット、保守しやすいコードを書くための考え方について解説します。

Access VBAでGOTO文が使われる理由

GOTO文は、プログラムの途中から指定したラベル位置へ処理を移動させる命令です。古いBASIC系の言語では一般的に使われており、Microsoft AccessのVBAでも利用できます。

例えば、エラー処理では以下のような形でGOTOが使われることがあります。

エラーが発生した場合に「ErrorHandler」というラベルへ移動し、エラーメッセージ表示や後処理を行う、といった使い方です。このような用途では現在でも実務コードでよく見られます。

問題になるのは、通常の処理フローを制御するためにGOTOを大量に使用するケースです。

例えば、処理Aから処理Cへ飛び、途中で別のGOTOによって処理Bへ戻るようなコードになると、プログラムを読む人は実際の処理順序を追いにくくなります。

特にAccessのように、数年単位で業務システムとして使われることが多い環境では、作成者以外の人が修正する可能性があります。その場合、複雑なジャンプ処理は修正ミスの原因になります。

「GOTOを使っている＝保守性を無視している」と判断することはできません。重要なのは、GOTOを使う目的です。

例えば、VBAでは次のようなエラー処理は一般的な書き方です。

「On Error GoTo ErrorHandler」のように、エラー発生時だけ特定の処理へ移動する使い方は、コードの可読性を高める場合もあります。

一方で、処理分岐やループ制御の代わりにGOTOを多用する場合は、If文やSelect Case、関数分割などで整理できないか検討した方がよいでしょう。

Accessの業務システムでは、単純に動けばよいだけではなく、後から修正しやすい構造にすることが重要です。

保守性を高めるためには、以下のような設計が役立ちます。

例えば、顧客登録処理、帳票作成処理、データ更新処理を1つの長いプロシージャに書くより、それぞれを別のFunctionに分けた方が、後から変更しやすくなります。

Access VBAでは、以前から存在する業務システムを引き継ぐケースも多くあります。そのため、古い開発手法で書かれたコードを見る機会もあります。

昔のプログラミングでは、処理速度やコード量を優先してGOTOを利用することもありました。しかし現在では、読みやすさや変更しやすさを重視した設計が一般的です。

そのため、既存システムのGOTOをすべて削除する必要があるとは限りません。安全に動作している部分を無理に変更すると、別の不具合を発生させる可能性もあります。

既存のAccess VBAでGOTOが多く使われている場合は、数だけで判断するのではなく、コードの理解しやすさで判断することが大切です。

例えば、エラー処理用のGOTOが数か所あるだけなら問題にならないことが多いです。一方で、処理の流れを追うために何度もジャンプしなければならない場合は、リファクタリングを検討する価値があります。

改善する場合も、一度にすべて書き換えるのではなく、変更が必要な部分から少しずつ整理していく方が安全です。

Microsoft AccessでGOTOを使うプログラムが必ずしも保守を考えていないとは言えません。エラー処理など適切な目的で使われるGOTOは、現在でも有効な場面があります。

ただし、通常処理の流れをGOTOで複雑に制御すると、後から読む人にとって理解しづらいコードになり、保守性が低下します。

大切なのはGOTOを完全に禁止することではなく、必要な場所だけで利用し、関数分割や分かりやすい構造を意識してAccess VBAを設計することです。