GoToとGoSubを正しく使うには
～構造化プログラミング以後の現実と誤解～
Copyright © 2025 LWP 山中 一弘 本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。
要約
GoToおよびGoSubは、かつて「スパゲッティコードの象徴」として批判され、構造化プログラミングの潮流において排除される対象とされてきた。特に1968年のDijkstraの手紙に付された扇情的なタイトル「GoTo Statement Considered Harmful」は、教育と言語設計に強い影響を与え、「GoTo＝悪」という単純なスローガンが広まった。
しかし、これは構造的・技術的な再検討を経ないまま固定化された誤解である。実際、VBAなどの命令型言語においてGoToは、エラー処理や共通出口処理、MECE的分岐制御において実用的かつ不可欠な構造である。またGoSubも、関数化のコストを抑えつつ、プロシージャ内の処理を整理するための実践的手段として再評価に値する。
本稿では、歴史的背景・誤解の構造・他言語における設計思想の比較を通じて、GoToおよびGoSubを正当な技術的視点から再評価し、現代的な制御構造選択の判断基準を提示する。
第1章 GOTO有害論の起源と伝播
1.1 スパゲッティコード批判の文脈
プログラミング言語が黎明期を迎えた1950年代から1960年代にかけて、制御構造の主流はGOTO文に代表される無条件ジャンプであった。初期の言語であるFortran、COBOL、BASICなどでは、関数呼出や制御構造が十分に整備されておらず、条件分岐や繰り返し処理もGOTOを用いたラベルジャンプに依存することが一般的であった。
このようなコードは、制御の流れが視覚的に錯綜し、ソース全体を上から下に読んでも意図が掴みにくくなるという特徴をもつ。複数のラベルやGOTOの絡み合いがもたらすこの混乱した構造は、比喩的に「スパゲッティコード」と呼ばれるようになり、1970年代におけるソフトウェア危機の象徴的問題とされた。
この批判が高まる中、構造化プログラミングの必要性が提唱されるようになり、if-then-elseやwhile、forといった明確な構文ブロックをもつ制御構造の導入が進んだ。その過程で、「GOTOは構造化に逆行するものであり、削除すべきである」という主張が、徐々に一般的な信念として定着していくこととなる。
1.2 Dijkstraの論文と編集者によるタイトル改変
この流れを決定づけたのが、Edsger W. Dijkstraによる1968年の短い投稿文である。本稿は元々、Communications of the ACM誌に宛てた**意見書（Letter to the Editor）**であり、タイトルは「A Case Against the GOTO Statement」であった。Dijkstraはこの中で、GOTO文がプログラムの構造を破壊する可能性について述べつつ、構造化制御構文の使用を推奨していた。
しかしながら、論文が編集部により掲載された際、タイトルは独断で**「Go To Statement Considered Harmful」**と改変された。これは技術的中立性を欠いた扇情的な表現であり、論文内容の穏当な主張とは乖離している。
この編集判断は、記事の影響力を高めることには成功したが、同時に「GOTOは害である」という単純で断定的なメッセージを広く流布する結果となった。Dijkstra自身は論文中で「GOTOの濫用」に限定して問題を指摘しており、適切な使用可能性について完全に否定していたわけではない。したがって、この標題改変は、著者の真意と実際の技術的立場を歪めた誤読の起点となった。
1.3 「Considered Harmful」言説の教育的スローガン化
論文掲載後、この「Considered Harmful」の文言は、教育現場や言語設計思想の中で急速に拡散していく。特にPascal、Modula、後のJavaなどの教育指向言語においては、GOTO構文そのものを文法レベルで排除する設計がなされ、構造化された制御構造を強制するスタイルが主流となった。
この設計思想は、初学者の混乱を防ぎ、コードの可読性・保守性を高めるという合理性を持つ反面、GOTOを一切使用すべきでないという断定的な価値判断を伴って拡張された。その結果、プログラミング教育において「GOTOは禁止すべき悪」とするスローガンが、技術的妥当性よりも倫理的信念のような形で内面化されていった。
この風潮により、GOTOは次第に科学的検討の対象からも外れた存在となり、「なぜ使ってはならないのか」を構造的に検証する機会すら失われていった。
1.4 誤解の構造：GOTOという語の一人歩き
こうして生まれた「GOTOは悪である」という命題は、元々の文脈を剥ぎ取られ、単なる象徴的否定語として一人歩きするようになる。本来、Dijkstraが問題にしたのは制御構造を壊すラベルジャンプの濫用であり、言語や文脈によってはGOTOが有効に機能し得ることを否定していたわけではない。
しかし、GOTOという語はその構文的形態により、「制御の不透明性」「可読性の低下」「副作用の温床」といった否定的イメージのパッケージとして捉えられがちである。加えて、教育用言語でのGOTO排除や、業務アプリケーションでの誤用例の影響もあり、GOTO構文＝悪という単純化された通念がプログラミング界全体に定着してしまった。
このように、GOTOをめぐる評価には歴史的誤解、編集上の誘導、教育的イデオロギー、表層的印象の複合的影響が絡んでおり、その排除論は必ずしも技術的妥当性に基づいていない。本章ではこの構造を明らかにし、GoTo再評価の前提を整理するものとする。
第2章 VBAにおけるGoToの実用構造と設計意義
2.1 GoToによるMECE分岐と出口制御
VBAにおける制御構造の設計において、GoToは分岐の網羅性（MECE）と処理の明示的な打ち切りを両立させる手段として実務的価値を持つ。特に複数の前提条件を連続して検査するような処理においては、各条件が成立しない場合に即座に処理を打ち切り、ラベルにジャンプさせる構造が有効である。これにより、ネストの深いif文を回避し、処理の意図を線形に表現することが可能となる。
このような設計は、「肯定条件を積み重ねていく」のではなく、「否定条件を先に排除する」形式となるため、処理の正常ルートが最短で記述され、異常条件が明示的に早期排除される構造となる。これはいわゆるガード節（Guard Clause）と同様の設計思想であり、手続き型言語における論理的整合性の高い設計といえる。
2.2 共通後始末ラベルと条件的中断制御
GoToは、後始末処理を関数末尾にまとめ、必要に応じてそこへジャンプするための手段としても有効である。たとえば、複数の条件で途中終了する可能性がある処理において、終了前にファイルを閉じる、オブジェクトを解放する、ステータスログを出力するなどの共通的な後処理を実装する際、GoTo ExitLabel による明示的なジャンプ制御は非常に明瞭である。
この構造により、同一の後処理コードが重複することを避けつつ、どの経路から来たとしても一貫した終了処理を保証できる。これは、構造的例外処理が備わっていないVBAにおいて、制御の整合性とリソース解放の安全性を両立するための、事実上の設計パターンとして広く用いられている。
2.3 エラー処理との分離：On Error GoToはGOTOではない
VBAにおける「On Error GoTo」構文は、言語仕様としてのエラー補足機構であり、通常のGoToとは意味的にも制御的にも異なる。On Error GoToは、ランタイムエラーが発生した際に指定ラベルへジャンプさせる例外的制御構造であり、明示的な条件判定とは無関係に非同期的に発火する。
この構文を通常のGoToと混同することは、構造設計上の混乱を招く。特に「GoToはエラー処理のために存在する」といった誤解は、VBAにおける手続き制御と例外制御の区別を曖昧にし、責務分離を妨げる原因となる。正確には、On Error GoToはVBAにおけるTry-Catchに相当する唯一の構文であり、その使用と設計上の判断は、業務ロジック上のGoToとは明確に切り離して検討されるべきである。
2.4 誤用の典型例とスパゲッティ化防止ルール
GoToの有用性は、その使用が構造的に管理されていることを前提とする。逆に、ラベルの多用やジャンプ先の無秩序な配置、意味不明な名称のラベルによる制御フローの錯綜は、可読性と保守性を著しく損なう。このような誤用がスパゲッティコードと称される構造を生み、歴史的なGoTo批判の根拠となってきた。
この問題を回避するには、GoTo使用時に以下のルールを徹底する必要がある。
（1）アルゴリズムを記述するための制御構造としてGoToを使ってはならない。
（2）ジャンプ先は常に明示的な目的を持ったラベルとする（例：ExitProc, ErrHandler）。
（3）ラベルは関数末尾に整理し、途中へのジャンプはRetryなどの確立した有効な手法で場合をのぞき禁止する。
（4）1プロシージャ内のGoToラベルは最大2つ程度（通常終了／異常終了）に限定する。
（5）ラベルの直後には必ず明示的な処理ブロックを記述し、副作用のない空ラベルを避ける。
これらを実装上の規約として採用することで、GoToは構造を壊すものではなく、むしろ手続きの見通しを保ち、制御構造を明確化する実用的なツールとなる。GoToの是非は乱用の有無ではなく、設計思想に基づいた使用か否かで判断されるべきである。
第3章 GoToの本質と多言語における設計判断
3.1 Java・Pythonにおける構造的排除と教育重視思想
JavaやPythonといった現代の高水準言語では、GoTo構文は明示的に文法から排除されている。Javaにおいてはgotoが予約語として確保されているにもかかわらず、実際には使用できない構文として扱われており、Pythonにおいても同様に任意のラベルジャンプは許容されていない。これは設計上の偶然ではなく、言語設計者が明示的にGOTOを不要または有害と判断し、教育的配慮のもとで意図的に排除した結果である。
この背景には、「初学者が制御フローの混乱を起こさず、構造的に明示されたコードを書けるようにする」という設計哲学がある。すなわち、構造化プログラミングを強制することで、可読性と保守性を担保し、教育的な一貫性を実現しようという思想である。ただし、このような設計はあくまで教育向け・汎用向けの方針に過ぎず、GOTO構文の本質的な是非を評価したものではない。
3.2 Go言語におけるGOTO許容：現実主義の系譜
一方、Googleによって設計されたGo言語では、goto構文が明示的にサポートされており、使用は自由である。Goの設計者であるKen ThompsonはUnixとC言語の創始者でもあり、現実主義に根ざしたシンプルな制御構造を重視していた。彼は、「GOTOは濫用されると危険だが、適切に使えば最も単純な制御を可能にする」という立場に立ち、GOTO排除のイデオロギーには与していない。
実際、Go公式ドキュメントでも、gotoは「複数のネストされた構造からの早期脱出」や「deferで囲まれたリソースの解放前に明示的な制御移動を行いたい場面」での使用が例示されており、その合理性は構文的にも保証されている。ここでは、教育的配慮よりも実装上の簡潔性・実用性が優先されており、制御の明示性を損なわない限りにおいてGOTOは有効な手段とされている。
このように、GoにおけるGOTO許容は、構造的安全性と制御の柔軟性を両立させようとする現実主義の姿勢に基づいており、GOTOを一律に排除する立場とは明確に一線を画している。
3.3 JavaScriptと非同期制御におけるGOTO的構造
JavaScriptにおいてはGOTO構文は存在しないが、その代替として非同期制御の構造がGOTOに類似する振る舞いを担っている。特にPromiseチェーンやasync/await構文は、プログラムの実行順序を明示的に操作するものであり、実質的には従来のGOTOによるジャンプと似た「制御の挿入・切替」の構造を持っている。
さらに、ラベル付きのbreakやcontinue文、例外処理構文によるtry-catch-finallyも、従来のGOTOが担っていた早期脱出や条件的分岐を構造的に代替する仕組みといえる。JavaScriptでは非同期I/Oやイベント駆動が言語仕様に組み込まれているため、制御の線形性がそもそも保証されず、むしろGOTO的な「制御の脱線」が自然な設計となっている。
このように、JavaScriptにおけるGOTOの不在は単なる排除ではなく、構造化された代替構文への置換として実装されており、言語文化としても「ジャンプ的な制御をどう表現するか」に関心が向けられていることがわかる。
3.4 Haskellなど関数型におけるCPSと制御の抽象化
関数型言語、とりわけHaskellに代表される純粋関数型の世界では、GOTOという概念自体が本質的に意味をなさない。なぜなら、関数型の計算モデルにおいては状態を持たず、副作用を排し、あらゆる制御構造が関数の合成と再帰によって記述されるからである。つまり、「ある位置にジャンプする」という制御構造が根本的に存在しない。
代わりに、Continuation Passing Style（CPS）やモナド（Monad）といった抽象構造を用いて、制御の流れそのものをデータとして関数に渡す設計が採られる。たとえば、MaybeモナドやEitherモナドはGOTOによる条件分岐・エラー分岐を安全に抽象化するものであり、ContモナドはCPSに基づいた継続制御を実現する。
このような構造は、GOTOによる「制御の非局所的な変更」を、安全な文脈管理のもとで抽象的に取り扱うためのものであり、GOTOの機能を否定するのではなく、高次構造として内包・管理しようとする思想である。結果として、GOTOの代替というよりも、制御フローそのものの再構成と捉えるべきであり、関数型言語はGOTOを拒絶したのではなく、別の形で包含していると理解すべきである。
第4章 GoSubの再評価：関数未満の構造分離と実務的意義
4.1 GoSubの構文とReturn機構の本質
VBAにおけるGoSubは、同一プロシージャ内の一部処理を別ラベルに分離し、処理後にReturn命令で元の呼び出し位置に復帰する構文である。関数呼び出しとは異なり、引数も戻り値も持たず、スタック的に実行位置を記憶して復帰するという挙動をもつ。これにより、関数を切り出すほどではない簡易な処理の再利用が、構造的に整理された形で実現可能となる。
GoSubの本質は、「呼び出し元の変数スコープを保持しつつ、制御を一時的に委譲する」ことにある。この構文は、ローカル変数やオブジェクトを引数なしでそのまま参照・更新できるため、手続き内の流れを大きく変えずに一部処理を分離するという設計上の自由度を提供する。
4.2 関数化との比較：文脈共有と可読性の両立
GoSubと関数の最大の違いは、文脈（Context）に対する取り扱いにある。関数を使用する場合、引数によって情報を明示的に受け渡す必要がある一方、GoSubでは同一プロシージャ内で文脈が共有されており、変数スコープの切断や状態の受け渡しが不要である。これは、簡易な処理分離や条件分岐付きの小規模ルーチンにおいて、大きな設計的利便性をもたらす。
また、関数化すると処理の流れが非線形になり、コードの読解に複数ファイルや離れた位置を参照する必要が生じるが、GoSubはあくまで「その場でのジャンプと戻り」であるため、可読性と追跡性を損なわずに処理のまとまりを示すことができる。とくに、プロシージャ全体の構造を維持したまま、論理的な段落に分けたい場合にGoSubは有効な手段となる。
4.3 実務における有効な利用パターンと禁止事項
GoSubはその特性上、適切な制約のもとで使用すれば、保守性を保ちつつ処理を分離するための優れた選択肢となる。実務上の有効なパターンとしては、
（1）大量の業務変数の転記の共通化。
（2）入力チェック処理の共通化。
（3）ログ出力などの軽微な処理の簡易再利用。
（4）共通的な条件分岐後の定型処理など。
（5）2条件多段IF文での同一処理2カ所問題に対する対応。
が挙げられる。これらは、関数に分離するほどの汎用性や外部再利用性がないが、処理の可視化や整理には有効である。
一方、GoSubには致命的な誤用パターンも存在する。代表的なのは、
（a）Returnの記述漏れによる暴走。
（b）複数のGoSubから一つのラベルに飛ばして状態を誤解させる構造。
（c）ラベルが乱立してジャンプの流れが可視化できないケース。
などである。これらの誤用は、GoSubを可読性向上のためではなく、制御の操作そのものに用いてしまった結果であり、GOTOのスパゲッティ化と本質的に同じ問題を引き起こす。
したがって、GoSubの使用には次のようなルールを設ける必要がある。
（i）1つのプロシージャにつきGoSubブロックは2〜3程度。
（ii）すべてのGoSub呼び出しはReturnで明示的に復帰する。
（iii）ラベル名は処理内容を明示する命名規則とし、実行順を誤解させない。
などである。
4.4 Gosubの構造設計と関数・Gotoとの補完関係
GoSubは関数のように外部からの呼び出しには不向きであり、Gotoのように任意の位置への非構造的ジャンプもできない。このことから、GoSubは「関数の構造性とGotoの簡便性の中間に位置する制御構文」として位置づけることができる。
具体的には、処理粒度の設計という観点から、次のように三者を補完的に用いるのが望ましい。まず、再利用性・独立性が高い処理は関数化してモジュール化する。一方で、文脈共有が前提であり処理の分岐構造が単純な場合にはGoSubを用いて処理を構造的に整理する。そして、条件分岐の網羅的制御や出口処理の一元化にはGotoを使って処理フローを集約する。
このように、GoSubは関数とGotoの中間にある設計装置として活用することで、処理構造の明瞭化と保守性の向上を両立させる。言い換えれば、GoSubは単独で評価されるべき構文ではなく、他の制御構造との役割分担と構造的補完性の中で適切に設計・運用されるべきである。
第5章 GOTO/GOSUBの利用判断と設計指針
5.1 「可読性」と「構造明示性」のバランス
GOTOおよびGOSUBの使用において最も重要な判断基準は、可読性と構造の明示性とのバランスにある。可読性とは、第三者がコードを追いやすく、意図や処理の順序が直感的に把握できる状態を指す。一方、構造明示性とは、処理の分岐や例外、終了位置が物理的にコード内に明示され、論理構造が線形的に表現されている状態を指す。
GOTOは非構造的なジャンプであるがゆえに、安易に使えば可読性を大きく損なう。しかし、設計に基づき使用箇所と用途を限定すれば、むしろ過剰なネストや重複コードを排除し、処理の流れを明示的にする役割を果たす。GOSUBも同様に、文脈を保ったまま処理を整理することが可能である一方、Returnの忘れやラベル乱用は可読性を崩壊させる。
したがって、これらの構文は「書く者の論理を他者に伝えるための手段」として位置づけられるべきであり、「読めるかどうか」だけでなく、「読みやすさの構造的根拠」が設計段階で示されていることが求められる。
5.2 関数分割 vs 手続き内再利用の判断軸
GOTOやGOSUBを使うべきか、それとも関数として切り出すべきかという判断は、主に処理の汎用性・独立性・文脈依存性という三つの軸で決定される。
汎用性が高く、他のモジュールや場面でも再利用される見込みがある処理は、機能の分離と抽象化の対象と捉え、引数と戻り値によって状態を受け渡す関数化が最も適切である。たとえば、数値演算、テキスト整形、ファイル読み込みといった独立性の高い処理は、この原則に従うことでモジュール性と再利用性が向上する。
一方、呼び出し元の変数スコープや業務状態をそのまま共有したい処理、つまり抽象化の必要がなく、むしろ文脈に密着した手続き的処理については、GOSUBによってプロシージャ内に一連の処理をまとめる方が、構造的に明快かつ実装コストも低く済む場合が多い。これは「関数未満の処理のまとまり」に対して最適な整理手段である。
また、複数の条件に応じて早期に処理を打ち切ったり、終了処理やエラーハンドリングなどのプロシージャ末尾に共通化すべき定型処理をまとめたりする場合には、GOTOによって明示的に終点へジャンプする構造が効果的である。これにより処理の意図が明確化され、過剰なネストや重複処理を回避できる。
要するに、「機能として切り離すべき処理」は関数化し、抽象化せずにその場で完結させたい一連の処理はGOSUBでまとめる。そして「複数の経路からの終点集約」はGOTOによって整理する。このように、関数・GOSUB・GOTOはそれぞれの制御粒度と設計意図に応じて役割を分担すべきであり、関数分割と手続き内再利用は対立関係ではなく、補完関係にある選択肢と考えるのが妥当である。
5.3 制御構造の分類と選択指針：GOTOはどこまで許容されるか
GOTOの使用は制御構造の一つであり、それが他の構造（If/For/While/Sub/Functionなど）と何を補完し、何を破壊するかを冷静に見極める必要がある。以下にGOTOの主な利用分類を挙げる：
（1）終了処理統合型GOTO：ExitPointなどにジャンプすることでリソース解放やログ出力を集中管理する。
（2）条件排除型GOTO：複数の前提条件を順次評価し、いずれかで外れる場合に即座に処理を打ち切る。
（3）例外移行型GOTO：正常ルートからの脱線時に異常処理ブロックへ制御を移す。
これらは構造的に設計されたGOTOであり、業務ロジックにおける意思決定の構造を明示するために有効である。一方、
（4）ラベル間移動型GOTO（処理途中から途中へ飛ぶ）。
は、論理構造が崩壊し、読み手の追跡が困難になるため、完全に禁止すべきである。
GOTOの許容範囲は、原則として上記に限定し、それ以外の制御は明示的な構文（If, Select, Doなど）で表現されるべきである。
5.4 組織的設計ルールとコードレビューポリシーへの統合
GOTOおよびGOSUBの使用にあたっては、組織として設計基準とコードレビュー指針を明文化しておくことが不可欠である。これは、経験の浅い開発者がGOTOを無自覚に誤用して制御構造を崩壊させることを防ぐと同時に、設計意図に基づく使用を正当に評価する文化を醸成するためである。
一方で、GOTOを使用しないことによってかえって深いネスト、過剰な条件分岐、重複コードの発生など、構造上の非合理を招くケースも多い。特にVBAのように転記処理や条件チェックが多く、共通化・中断処理の明示が求められる業務コードにおいては、GOTOやGOSUBの活用が処理の簡潔化と論理の明示に大きく寄与する場面も少なくない。
したがって、GOTO/GOSUBを禁止するか否かではなく、その使用を設計的に管理することが重要である。以下のような運用ルールを策定することで、安全かつ合理的な使用を可能にできる：
（1）GOTOは最大2～3箇所までを目処とし、正常終了（ExitProc）および異常終了（ErrHandler）に限定する。
（2）GOSUBを使用する場合は、必ずReturnによる復帰を明記し、処理ブロック単位で構造的に整理する。
（3）ラベル名にはExitProc、ErrHandler、CheckInputなど機能を明示する命名規則を適用し、意味不明な名称は使用しない。
（4）関数化が可能な処理は原則として関数に分離する。ただし、文脈依存の一連処理についてはGOSUBによる整理を例外的に許容する。
（5）レビューコメントにはGOTO/GOSUBの使用意図を明示し、構造設計に基づいた判断であることを説明可能な状態とする。
これらのルールは、単なる構文的禁止ではなく、制御構造の選択に設計的根拠を与えるための規律である。ルールの明文化によって、「使うかどうか」ではなく「どのような構造で、どこまで使うべきか」という判断軸を組織全体で共有することができる。
結果として、GOTOやGOSUBは「構造破壊の象徴」ではなく、「業務実装を構造的に整理するための技術的選択肢」として正当に位置づけられる。これこそが実務開発におけるGOTO/GOSUB設計の本質であり、その是非を論ずるべき対象ではなく、設計として管理すべき構造である。
第6章 終わりに：構造化の呪いを越えて
6.1 技術的視点からの再評価の意義
本稿を通じて明らかになったのは、GoToおよびGoSubに対する一律的な否定が、技術的根拠よりも歴史的な誤解と教育的スローガンに支えられてきたという事実である。確かに構造化プログラミングの発展は、プログラムの可読性や保守性に大きな貢献をもたらしたが、その一方で「GOTO＝絶対悪」という単純な価値判断が、制御構造の柔軟性や設計的多様性を不当に抑圧してきた側面も否めない。
特にVBAのような命令型スクリプト言語においては、構文の制約や例外処理の未整備を補う手段として、GOTOやGOSUBは今なお重要な設計要素である。技術的視点に立ち返って評価し直すことは、構文の本質を見失わずに制御構造を適切に選択するための第一歩である。
6.2 構文的単純化ではなく意味的設計へ
GoToやGoSubを拒絶する文化の根底には、「構文を単純にすれば、コードは自然と良くなる」という構文至上主義の思想がある。しかし、実際の業務コードにおいて必要とされるのは、構文の簡潔さではなく、処理の意味構造がいかに明示されているかである。処理の流れ、分岐の意図、異常時のハンドリングといった意味的構造を明確に記述できるならば、GOTOのような非構造的構文もまた構造的設計の一部となり得る。
構文の単純化と意味の明示は必ずしも一致しない。むしろ、意味構造を整理するために限定的に構文の自由度を活用する方が、実装上の整合性と保守性を担保しやすい。GOTOもGOSUBも、その使用が「何を意図し、何を明示するか」によって、評価は大きく変わるのである。
6.3 言語設計と業務実装の交差点に立つ選択の自由
VBAは、表計算業務に密接に結びついた環境である。転記処理、条件チェック、ログ出力、終了処理といった「分岐と中断の多い構造」を大量に扱うことが求められる現場では、GoToによる早期打ち切りや共通出口制御、GoSubによる簡易な処理分離は、むしろ業務コードをシンプルに保つための不可欠な設計装置となる。
言語設計は常に理想と安全性を前提にするが、業務実装は現実と速度を前提とする。その交差点において、GOTOやGOSUBを排除するのではなく、意味を理解した上で適切に使いこなす自由と責任こそが、現代のVBA設計者に求められる姿勢である。
構造化の「呪い」として形式的に排除されたGOTOは、構造化の「成熟」によって再び選択肢となり得る。本稿の議論が、読者の判断における自由の幅を広げ、現実的な実装判断の指針となることを願う。