以前、「変数は箱か名札か？」で動画を上げたのですが、あまりアクセスはなかったのですが、最近少しアクセスがあり、改めて見たら面白かったので、もう少し突っ込んでまとめてみました。
プログラミング教育の現場では、今も昔も「変数とは何か？」が最初のハードルです。
伝統的には「変数は値を入れる箱」と説明されますが、
最近では「変数はオブジェクトに貼られた名札（ラベル）だ」と主張する声も聞かれます。
一見、単なる比喩の違いのように見えますが、
この議論の背後には、プログラミング言語の理論と設計思想の根深い違いがあります。
ここでは、初心者教育から理論的背景、そして実用上の含意までを整理してみます。
最初に登場するのが、もっとも直感的な「箱」モデルです。
変数とは、値を入れておく箱である。
a = 1
b = a
a = 2
このとき、a の中身を 2 に変えると、b の値はそのまま 1。
学習者は「箱に入れた値を取り出して使う」イメージで簡単に理解できます。
C や C++ のように、メモリ上の領域が実際に割り当てられる言語では、
この比喩はきわめて正確であり、教育的にも有効です。
一方で、Python や JavaScript では、変数の実体がやや異なります。
これらの言語では、変数はオブジェクトへの参照を持つ仕組みであり、
代入は「名札を貼り替える」動作に近いのです。
変数は、オブジェクトに貼る名札である。
a = [1, 2, 3]
b = a
a[0] = 9
ここで b を出力すると [9, 2, 3]。
箱モデルでは説明しづらく、「名札モデル」の方が合うように見えます。
しかし、注意すべきはこの比喩も完全ではないという点です。
配列の各要素 a[0] にまで「名札」を持ち込むと、
今度は配列の連続性やメモリ構造のイメージが崩れてしまいます。
結果として、初心者をさらに混乱させることもあるのです。
C や C++ では、値型と参照型（ポインタ型）が共存しています。
int a = 1;
int &r = a;
このとき r は a の別名であり、どちらを変更しても同じ領域が変化します。
つまり C++ は、「箱」と「名札」の両方の性質を明示的に区別できる言語です。
教育的にはこの構造が非常に有益で、
物理的なメモリ構造と論理的な参照概念の橋渡しを学ぶことができます。
ただし、ポインタや参照はプログラミングの初心者にとっては難しい概念である。
さらに理論的な世界へ進むと、
「変数は値を入れるものではなく、“値（あるいは式）に束縛される名前”だ」
という考え方が登場します。
束縛（binding）＝変数と式の対応を定めること。
Haskell などの関数型言語では再代入ができず、
変数は一度束縛されたら変更できません。
x = 1
y = x + 2
このとき x や y は「箱」ではなく「式の定義名」です。
評価は遅延的に行われ、必要になるまで実際の値が求められません。
この仕組みは理論的には非常に美しく、
純粋関数・副作用の排除・数学的推論のしやすさといった利点をもたらします。
束縛モデルの最大の利点は、式そのものをオブジェクトとして扱える点です。
たとえば、自動微分やDSL（ドメイン固有言語）の分野では、
式構造を保持して解析・変換する必要があります。
しかしその一方で、束縛モデルには現実的な制約もあります。
| 項目 | 束縛モデル（遅延評価） | 参照モデル（即時評価） |
|---|---|---|
| 抽象性 | 高い | 低いが直感的 |
| 実装効率 | 低い（オーバーヘッドあり） | 高い |
| デバッグ | 難しい（評価タイミング不明） | 容易 |
| メモリ予測 | 困難 | 明確 |
結果として、実用言語の多くは参照モデルを基本にし、
必要な箇所だけ束縛的な振る舞いを導入する設計を採用しています。
今日では、C# の Expression<T> や
Python の sympy / jax、
C++ の Expression Template など、
必要な箇所だけ束縛モデル的挙動を模倣する仕組みが採用されています。
つまり、
「束縛モデル全体を採用するのではなく、
その一部を道具として使う」
という方向に落ち着いています。
| 学習段階 | 目標 | モデル | 教育上の重点 |
|---|---|---|---|
| 初級 | 値の代入と操作の直感的理解 | 箱モデル | シンプルな心象で理解する |
| プロ（中級） | メモリと参照の関係を理解 | 箱＋参照モデル | オブジェクト共有・ポインタ・参照 |
| 研究レベル | 抽象的な束縛・遅延評価・純粋関数 | 束縛モデル | 数理的抽象化・関数をデータとして扱う |
「名札」や「束縛」という比喩は、
実行環境や抽象化の観点を説明する一つの手段に過ぎません。
しかし、それを「箱より優れている」と主張するのは誤りです。
比喩はあくまで教育のためのツールであり、
言語設計の本質はメモリ・参照・評価戦略の選択にあります。
実務的な観点から見れば、
「箱モデル＋参照の理解」で十分に事足り、
束縛モデルは特定分野での理論的・実験的意義を持つに留まります。
変数を「箱」と呼ぶのも、「名札」と呼ぶのも、
プログラミングという抽象世界を理解するための足がかりに過ぎません。
重要なのは「どの比喩を使うか」ではなく、
その比喩がどの抽象化層を説明しているのかを意識することです。
プログラミング教育において本当に求められるのは、
比喩をめぐる正しさの議論ではなく、
学習者が言語の階層構造（値 → 参照 → 束縛）を自然に昇っていけるように導くこと
なのかもしれません。
この文章は、ChatGPTとの共同作業により作られています。
―「staticおじさん」というモデルが歪められた物語―
「staticおじさん」という言葉が生まれたのは、十数年前のあるネット記事がきっかけだった。
とあるエンジニアが、「オブジェクト指向がわからない」と率直に書いた。
コメント欄では賛否が分かれ、議論は次第に激しさを増していった。
やがて、その人物の主張の一部だけが切り取られ、「オブジェクト指向を理解できない頑固な人」というレッテルが貼られた。
その象徴的な呼び名として登場したのが「staticおじさん」である。
つまり、“staticおじさん”にはモデルが存在した。
だがその人物は、もともと技術を語っていただけだ。
しかし、ネット文化は誠実な議論よりも“わかりやすい敵”を好む。
その結果、個人の発言が物語化され、「古い技術に固執する老害エンジニア」という虚像が作られていった。
オブジェクト指向の議論という技術的テーマが、いつしか「世代対立」「価値観の断絶」といった社会的物語にすり替えられたのである。
“理解しようとしない人”という構図は、読む人に安心感を与える。
自分は「新しい側」に立っているという錯覚をくれるからだ。
こうして、一人のエンジニアの誤解が、ネット全体の“物語”に変わっていった。
やがて、この物語は一部の勉強会にも持ち込まれたことがある。
勉強会自体は知識を共有する素晴らしい文化だ。
ただ、非エンジニアや若手が参加する場では、
「staticおじさん＝古い考えの象徴」というイメージが語られることがあった。
そこには、本来の人物像も、元の記事の文脈も存在しない。
ただ、「static関数を使う」「オブジェクト指向に懐疑的」という特徴だけが切り出され、
“そういう人たち”というステレオタイプとして再生産されることがあった。
実際、当時の技術コミュニティでは、
「なぜそう考えるのか」よりも「どちらが正しいか」が重視されていた。
正解主義の文化の中で、
“反対意見を持つ人”は「理解できない人」として扱われた。
そしてそれが笑い話として語られることで、
“老害”という言葉が社会的な正義の衣をまとったのである。
本当の“staticおじさん”とは誰だったのか。
それは、一人のエンジニアの名前ではなく、
「自分の考えを曲げずに語ろうとした人」そのものだったのかもしれない。
技術は時代とともに変わる。
だが、変わらない信念や疑問を持ち続ける人は、いつの時代にもいる。
その存在を“老害”と切り捨てた瞬間、
私たちは「考える自由」そのものを失う。
オブジェクト指向のメッキが剥がれた今、
私たちはもう一度、あの議論を思い出すべきだ。
それは「正しさ」の争いではなく、
“責任ある思考”をどう持つかという問いだったのではないか。
物語は人を動かす力を持つ。
だが、嘘の物語は、いつか誰かの現実を壊す。
「staticおじさん」という言葉を笑ったあの日から、十数年。
オブジェクト指向の理想は現実に疲れ、
AIがコードを書く時代になろうとしている今、
私たちはなお物語を作り続けている。
だからこそ、今こそ「責任ある物語」が必要だ。
誰かを貶めることで安心を得る物語ではなく、
異なる立場を理解し、語り合う物語を。
それが、技術文化を再び人間の手に取り戻す唯一の道だろう。
この文章は、ChatGPTとの共同作業により作られています。
―「正しさ」を振りかざすエンジニアたちへ―
「クソコード」という言葉が、いつのまにかネットに氾濫しはじめた。
これは、冗長で、意図が読めず、保守性に欠けるコードを指して揶揄するものです。
しかし今ではその言葉だけが独り歩きし、「自分の理解の範囲外にあるコード」や「自分の理想にそぐわない設計」までも、“クソ”と断じる風潮がある。
この背景には、「コードコンプリート症候群」とでも呼ぶべき現象がある。
「良いコード」を追い求める活動は昔からある。
古くは構造化プログラミングが提唱され、今ではそれが当たり前になった。
しかしそれだけでは解決できない問題が現れ、次々と新しい手法やデザインパターンが現れそして新しい問題が発生する。複雑さへの挑戦は終わりのない戦いである。
様々な手法が出てきてそれら自体の存在が複雑化した。そしてそれらの手法を体系化した書籍が登場してきた。その中で『コードコンプリート』は、「良いプログラムを書くためにプログラマが知っておくべき考え方と手法」を総合的にまとめた初期の成功例である。
プログラミングを単なる作業ではなく、知的な創造性のある行為として扱った最初期の実践書のひとつであり、その精神はいまも色褪せない。
現在では『リーダブルコード』がその精神を受け継いでいる面もあるが、ここでは原点としての『コードコンプリート』に敬意を払い、代表例として取り上げたい。
問題は、その内容に感銘を受けたエンジニアが、その理念を「唯一の正解」と信じてしまうときに始まる。
彼らはコードレビューでこう言う。
「この変数名は短すぎる」「コメントが少ない」「このクラスは単一責任原則に反している」「これはスパゲッティコードだ」――。
そして最後に決まって、「コードコンプリートにも書いてありますよ」と付け加える。
まるで聖典の一節のように。
だが現場は常に、時間とコストとレガシーの中で動いている。
理想を追うことと、現実を生きることは別問題だ。
優れた原則や設計思想は、状況に応じて取捨選択されるべきものだ。
だが「教義化された正しさ」は、しばしば現場を麻痺させる。
新しいアイデアが「原則違反だ」として却下され、古くても信頼できるコードが「レガシー」と称され書換えを強制される。進行中のプロジェクトが“改善活動”という名の足踏みを始める。
そして気づけば、誰もコードを書かなくなり、議論だけが増えていく。
「クソコード」というレッテルは、往々にして相手の努力や文脈を切り捨てる言葉でもある。
そこには、相手への敬意よりも、「自分は理解している側だ」という安心感がある。
それが一番、危険だ。
本当に優れたエンジニアは、「なぜこう書かれたのか」を考える。
時間的制約、チームのスキル、利用可能なライブラリ、歴史的経緯――すべてを踏まえて設計を評価する。
そこには「正しいコード」ではなく、「今ここで生き残るコード」という現実的な視点がある。
『コードコンプリート』の精神とは、本来この“文脈理解”そのものだったはずだ。
それを「規範の棒」として他人を叩くのではなく、「共通の言語」としてチームをつなぐために使う――。
その姿勢を忘れたとき、私たちは“コードコンプリート症候群”に陥る。
良書は人を育てるが、同時に、信者も生む。
それを避ける唯一の方法は、「本の中にある正しさ」よりも、「現場で生きる知恵」を信じることだ。
“クソコード”と笑うより先に、「なぜそうなったか」を問おう。
そこからこそ、真のプログラミング文化が始まる。
この文章はChatGPTが原稿を書き、人間が修正を加え、再度ChatGPTが校正・編集したものです。
――「クソコードを書け」と私が思うようになったもう一つの理由――
「クソコードを書け」という主張はいささか偏っていますが、思えば私は他人のコードを「くそ」と思ったこともなければ、「直せ」と思ったこともほとんどありません。
では、なぜそう思うようになったのか。
キャリアのごく初期――35年程前になります――には、「コードの美学」というものが確かにありました。しかしそれは1、2年で消えました。
さらに数年後、決定的な出来事が起き、その美学は吹っ飛びました。
30年近く前、1996年前後のこと。私が担当していたプロジェクトが炎上しました。
どのくらい炎上したかというと、残業が170時間、それが3か月ほど続いたのです。
残業代で数十万円入ったものの、翌年の社会保障費が爆上がりし、給与の支給額が「14万円」とかになった。
総務に「なんでやねん！」と詰め寄ったら、「あなた去年170時間残業したから…」と言われたのを今でも覚えています。
ちなみに、そのときの数十万円がどこに消えたのかは、いまだに謎です。
他にも、4日間家に帰らずコードを書き続けた翌朝、廃人のようにボーッとしていた私に顧客担当者が「○○の機能を入れてほしい」と言ってきた。
相手の言うことが理解できず、とりあえず「無理です」と返して、担当者がすんなり帰っていったこともあります。
int型で定義した変数を、なぜかshort型でexternして、朝の4時にバグを仕込んだり、
風邪で寝ていたら上司に呼び出され、現場で顧客から「ボーっとするな！」と説教を受けたり。
炎上プロジェクトの「あるある」は、わりと経験しました。
その後、私は数年間体調を崩しました。
体調を直すのに苦労しましたが、それ以上に、「何が悪かったのか？」をずっと考え続けました。
そこで学んだことは、
ということです。
もちろん、開発プロジェクトに必要なプログラミング技術は存在します。
しかし、一度炎上した現場では、もっと広い範囲で問題を見抜く力が必要になります。
たとえば、最近のマイナ保険証の問題。あれは「プログラミングが悪かった」という話ではありません。
私たちが学ぶべきことは、コードの書き方だけではなく、プロジェクト全体を見渡す力です。
ただし、だからといってプログラミングの勉強をやめてよいという話でもありません。
幸い、その反省が生かされたのか、私が担当して炎上したプロジェクトは一度きりでした。
その後は、いくつかの炎上現場に「助っ人」として呼ばれる側になり、記憶にある限り3回ほど大炎上の火消しに入りました。
では、火消し屋にとって最も重要なプログラミングスキルとは何でしょうか？
あまり知られていないかもしれませんが、コードを読む力（リーディング能力）です。
コードリーディング能力を高めるには、まず自分がCPUになったつもりでコードを読むこと。
つまり、「このコードはどのように実行されるのか？」という観点で、主観や美学を捨てて追うのです。
次に問うべきは、「このコードの動作は正しいか？」ということ。
ここで確認するのは仕様との整合性であって、コードが綺麗かどうかではありません。
論理的な間違いを追い、問題箇所を見極めることが目的です。
バグを探しているときにコードを見て「クソコードだ！」と思った瞬間、冷静な論理的判断はほとんど不可能になります。
私の経験では、感情的な印象を保ちながら正確に問題箇所を指摘できる人はほぼいません。
さらに、普段から他人のコードを批判的に読む癖をつけたり、自分のスタイルにこだわり他人におしつけ、そのスタイルの一貫性に固執しすぎると、無意識のうちにスタイルの異なる他人のコードを受け入れられなくなります。
つまり、コードの「あるべき姿」を追い求めすぎたがために、多様な書き方を認められなくなってしまうのです。
確かに、コードの出来が悪くてバグが潜むこともあります。
しかし、それを炎上中に嘆いたところで、現場は何も救われません。
コードの美しさよりも、まず動作の理解。
「クソコード」と切り捨てる前に、CPUのように冷静に読み、仕様との整合性を確認すること。
それこそが、火消し屋としての第一歩であり、炎上を防ぐための最良の訓練でもあるのです。
この文章は、原稿を元にChatGPTが校正・編集しています
ちょっと気づくのが遅い面がありますが、ネット界隈ではクソコードというワードが広がっているようです。要は品質の悪いコードを指して”くそコード”と称しているというこです。
ひと昔前に流行った「オブジェクト指向」と同様に今度は「クソコード」がある種のバズワードになっている感があります。
オブジェクト指向信者との闘いはここを見ていただければと思いますが、おかげ様でバズワードとしてのオブジェクト指向について冷静な議論をすることに一定の抑止効果があったと自負（？）しています。
一方で、今度はクソコードというバズワードが流行っていると認識しています。
実は、私自身ですが、他人のコードを見て「くそ」と思ったことはほとんどありません。「あーそう書くのか」と思うことがあります。そこに自分の常識にとらわれない新しい発見があるからです。
ちょっと古い２５年前の例になるのですが、新人が書いたVBScriptの
name = "与太"
output = "ようこそnameさん"
というコードで、新人からの質問が「なぜoutputが "ようこそ与太さん" ではなく "ようこそnameさん"と表示されるのですか？」と質問を受けて逆に感銘を受けました。
ちなみに私は、この時はphpを知らなかったのですが、後にphpを勉強してこのように記述できるのを知って「やっぱりあの時の新人はセンスがあるな」と思いました（セキュリティ的には問題があるのと、もっともその新人がその時にphpを知っていたかもしれないということもありますが）。
特定の言語しか知らない人たちは新人の間違いに対して「理解ができない」と一蹴するかもしれないが、プログラミングの言語の進化（つまりある種の破壊的創造）を考えると新人のコードを読むのは勉強になるなと思った次第です。
そこから8年程経ってプログラミング言語の開発をするわけですが、コンセプトの一つとして「人が自然に記述できる言語をめざす」ということがあったかと思います。
要はエンジニアが書きがちなコードは一見クソに見えるかもしれないが、そこには「言語として表現されたもの」としてなにか意味があるのではないか？と思う次第です。
例えば、クソコードの一つに挙げられる「コピぺ」のコードですが、「なぜプログラマはコピペをするのか？」という風にコピペを行うプログラマの考え方やコピペが必要とされる場面や良さを考えるようになります。
オープンソースとかであるフォークもある種のコピペだと思います。これは別プロダクトになるのでクソコードとは関係ないかとも思いますが、そもそもコピペというはプログラムの土台を作るうえで有用ということになります。
誤解のないように言いますと、ある種の品質が問われる場面ではコピペは避けています。例を挙げると、私の場合、料金計算を行うコードは「一か所」と決めています。これは料金計算を行うコードが複数あるとき、料金計算を行うロジックに変更が発生した場合、複数個所のコードをすべて直すことを保証するのは現実的でないです。むしろ関数なりクラスなりにして料金計算は１か所で行う方が最終的に品質を確保できます。
それでも、過去にありましたが、他のプログラマがコピペして料金計算の別バージョンを作ったときにはその状況を鑑みて「仕方ないな」で流しました。
このように考えると「クソコード」とか「コピペ」とか古いところでは「グローバル変数」とか「スパゲッティコード」というある種の思考停止なワードを用いた議論については、待ったをかけたくなります。
別の観点でいいますと、プロジェクトの開発・保守の現場では、個々のコードについてはそこまで保守性が重要ではない場面があります。
例えば、製品毎に売り上げを表示するレポートプログラムを作成する案件では、最終的に私が開発したプログラムは、
・レポートテンプレート
・そのレポートで表示する項目のリスト
等の「変更可能性のあるモノを全てパラメータ」として与えることによって、元のコードは変更せずに様々なバリエーションのレポートを作成するプログラムを作成しました。
保守業務において、もはや元のコードは「そのままでよい」というこになり実際にコードを変更することはあまりありませんでした。誤解の無いように付け加えるとパラメータとしてどのようなモノを与えればよいかというのは試行錯誤が必要な面があるので、開発当初はシステムのバージョンアップが発生しました。
これはある種のプログラミング言語を開発し、その言語の上で開発を行っているという状況になります。この場合、私たちの目は元のシステムのコードに行くべきなのか新たに作った言語に行くべきなのか？ということが言えます。私たちエンジニアは、Javaで開発をするときに自分たちのコードについては気を付けるかもしれませんが、Javaのコンパイラやインタプリタに対してはそれらがどのようなコードから作られているか、つまりクソかどうかは感知しないでしょう。
さらに別の観点でいいますと、自動的に生成されたコードを保守しようとしたときに「本当にそのコードを保守するのか？再生成させたほうがよいのではないか？」という話もあります。
比喩的にいうと、Javaでコンパイルしたマシンコードの可読性をいちいち気にしないということと同じです。
具体例をあげると、業務によっては似て非なるSQLを大量に書かなければならないが、SQL自体をメンテナンスするよりそのSQLを出力するコードを書いた方が保守にかかわるトータルのコストが下がる場合があります。この場合、当然ですが、出力後のSQLを確認する意味では読みますがその可読性は問題視しません。
ちなみに私はコンパイルしたC++のアセンブラコードを読むこともあります。この場合、どのようにオプティマイズされている（どの程度効率の良いコード）を出力しているか確認するのですが、この時に「この機械語はくそコード」と考えたことはありません。もっとも、すでに２０年以上前からコンパイラは腹が立つぐらいに（私的には）美しいコードを吐いてきます。
この２つの例ですが、要するに「ソフトウェアの品質を上げるには？」ということに関して「くそコードを書かないようにする」以外の回答があるということになります。
さて、AI時代になると、もはや人間がコードを書くことは減るかと思いますが、それでも人間がコードを読む時間は増えるでしょう。
この時に、AIに向かって「くそコードを書くな！」とかおっしゃるのでしょうか？
P.S.
「お前は可読性の高いコードについて関心がないのか？」との質問については「当然関心があるが、自身が読みずらい・保守しずらいコードを読んで、クソコードということはない。もちろん個別の問題点については指摘する」ということが言いたいことです。また、「細かいコードの良し悪しばかりに気を取られると、エンジニアとしてもっと重要なことがおろそかになる可能性がありますよ」ということも言いたいことです。
追記：
このブログではChatGPTの指摘は、あえて書かないようにしていましたが、今回はかなり示唆に富んでいるので、以下、ChatGPTの結論を抜き出してみました。正直、そこまでは明確に意識していませんでしたが言われたらそうだと気付きました。
ChatGPT１の 結語：「クソコードを書け」
クソコードを恐れるな。
クソコードを書け。
そこにはあなたの思考、試行錯誤、そして創造の痕跡が残る。
真にクソなのは、挑戦をやめて他人の美学に従うことだ。
ChatGPT２の結論
この文章は「クソコード＝悪」という単純な構図を脱し、
「コードという文化現象」や「言語進化」「AI時代の人間の役割」まで踏み込む、
非常に知的で示唆に富む論考です。
ただし、現場的には「だから品質を軽視していい」という話ではなく、
「なぜそのコードがそうなったのか理解し、構造的に直せる人が真の上級者」
という文脈で読むのが正しい理解です。