その他のエッセイはこちら
はじめに：箱という言葉の乱用？それとも抽象化の本質？
クラスは箱。オブジェクトも箱。関数も箱。変数も箱。
プログラミングの世界では、なぜかあらゆる概念が「箱」として例えられる。初学者向けの教材でも、上級者向けの設計論でも、箱という言葉が頻繁に登場する。思わずツッコミたくなる——「全部箱かい！！！」
筆者は自動車業界でエンジニアとして働いており、プログラミングだけでなく、制御理論や数理モデルの設計にも日常的に関わっている。変数や関数は、単なるコード上の構成要素ではなく、物理現象やシステム挙動を記述するための数学的な道具でもある。そうした立場から見ると、「箱」というメタファーには、便利さと違和感の両方がある。
このエッセイでは、主要なプログラミング概念における「箱」メタファーの意味と限界を探りながら、抽象化と構造化の本質に迫ってみたい。
クラス：設計図という箱、だが中身は空
クラスは、属性と振る舞いを定義する「型の箱」として語られる。中身は空っぽだが、構造はある。まるで折りたたまれた段ボールのように、オブジェクトという実体を生み出すための枠組みだ。
このメタファーは教育的には有効だが、実際のソフトウェア設計においては、クラスは抽象的な契約であり、箱というよりは「鋳型」や「設計図」に近い。箱と呼ぶことで、クラスが持つ動的生成性や継承・ポリモーフィズムといった性質が見えにくくなる危険もある。
さらに、クラスは静的な構造でありながら、動的な振る舞いの起点でもある。これは「箱」というよりも「スクリプト付きの型紙」だ。箱というメタファーが、クラスの振る舞いの抽象性を過小評価してしまう可能性がある。
オブジェクト：状態を持つ箱、しかし箱の中身は見えない
クラスから生成されたオブジェクトは、状態（変数）と振る舞い（メソッド）を持つ実体。これは「箱」のメタファーに最も忠実な存在だ。中にデータが詰まっていて、外からメッセージを送ることで動作する。まさに「箱入りの機械」と言える。
しかし、オブジェクト指向の本質はカプセル化にある。つまり、箱の中身は外部からは見えない。これは「箱」というよりも「金庫」や「密閉容器」に近い。箱という言葉が持つ「開ければ中身が見える」という直感と、実際のオブジェクトの振る舞いにはズレがある。
また、オブジェクトは状態を持つエージェントとして振る舞うこともある。これは「箱」というよりも「振る舞いを持つ存在」としての擬人化に近い。箱というメタファーが、オブジェクトの能動性や自己変容性を捉えきれない可能性がある。
関数：箱か？メッセージか？それともプロセスか？
関数もまた「箱」として語られることがある。入力を入れると出力が出る、内部の処理は隠蔽されている——これはブラックボックス的な構造だ。
しかし数学的には、関数は「写像（mapping）」であり、ある集合（定義域）の要素を別の集合（値域）の要素に対応させる構造である。これは、単なる箱ではなく「空間間の対応関係」を記述する枠組みであり、関数の本質はこの構造的な対応にある。
$f: X \rightarrow Y$ は、各 $x \in X$ に対して $y \in Y$ を対応させる写像
一方、OOPでは関数（メソッド）はオブジェクトに対する命令であり、箱というよりは通信の手段に近い。関数型プログラミングでは、関数は第一級市民であり、値として扱われ、他の関数に渡されたり返されたりする。この文脈では、関数は「箱」というよりも流通するメッセージや処理の流れのノードとして捉えられる。
※ 関数は「命令」としてオブジェクト間を流れる
さらに、関数は副作用の有無によってその性質が大きく変わる。純粋関数は「完全に閉じた箱」であり、外部に影響を与えない。一方、副作用を持つ関数は「穴の空いた箱」であり、外部との相互作用を持つ。つまり、関数の「箱性」は純粋性の度合いによって変化する。
変数：値を保持する箱、しかし時間に依存する
変数は、値を格納する「記号的な容器」として説明される。これは箱のメタファーに最も馴染みやすい。だが、実際には変数も時間や文脈に依存する関数的な性質を持つことが多く、単なる静的な箱ではない。
筆者の業務では、例えばエンジンの温度、車速、トルクなどの物理量を変数として扱うが、それらはすべて時間 $t$ や状態 $x$ に依存する関数である。つまり、変数はしばしば動的な関数の一時的なスナップショットに過ぎない。箱というよりは、流れる値を一時的に捕まえる網のような存在だ。
制御理論では、これらの変数は状態空間モデルの一部として扱われ、状態 $x(t)$ や出力 $y(t)$ は時間とともに連続的に変化する。変数は単なる箱ではなく、システムの内部状態を記述する「動的な座標」として機能する。
また、変数にはスコープやライフサイクルがあり、それによって「箱の寿命」や「箱の見える範囲」が決まる。これは箱というよりも「一時的な保管庫」や「限定された領域」としての性質を持つ。
歴史的背景：なぜ「箱」メタファーが広まったのか
「箱」というメタファーは、単なる教育的工夫ではなく、人間の認知構造に根ざした説明手法である。認知科学の研究によれば、人間は抽象的な概念を空間的な構造に置き換えることで理解を深める傾向を持つ（Lakoff & Johnson, 1980）。箱はその代表的な構造であり、「入れる」「出す」「閉じる」「開ける」といった操作が直感的に理解可能であるため、情報の隠蔽や構造化を説明する際に非常に有効である。
また、情報理論や制御工学においては、システムを「ブラックボックス」として捉えるモデルが一般的であり、これが関数やモジュールの説明に転用されてきた経緯がある。教育工学の分野においても、視覚的に理解しやすい「箱」の図解が多用されてきた。Scratch や Blockly などのビジュアルプログラミング環境においては、ブロック＝箱のような構造が採用されており、教育現場での定着を促進している。
こうした背景により、「箱」はプログラミング教育において自然かつ強力なメタファーとして定着した。しかしその一方で、箱というメタファーが持つ静的・閉鎖的なイメージが、動的で相互作用的なソフトウェア構造の理解を妨げる可能性もある。したがって、箱はあくまで説明のための道具であり、概念そのものではないという認識が重要である。
なぜ全部箱なのか？——抽象化と境界形成の欲望
「箱」というメタファーは、抽象化と境界形成の象徴である。プログラミングでは、複雑な構造を分離し、隠蔽し、再利用可能にするために、何かを「箱」に入れる必要がある。箱は、中身を守り、外部とのインターフェースを定義する。
この構造は、情報理論やソフトウェア工学において非常に重要だ。モジュール化、カプセル化、関心の分離——すべては「箱を作ること」によって達成される。
情報理論の観点では、箱は「エンコーディングとデコーディングの単位」としても捉えられる。つまり、情報をある形式に変換し、再構成するための構造体であり、抽象化とは情報の圧縮と選択でもある。
しかし、箱というメタファーには限界もある。箱は静的で、閉じた構造を想起させる。実際のソフトウェアは、動的で、相互作用的で、時には自己変容する。箱という言葉が、動的性質やネットワーク的構造を見えにくくしてしまう可能性もある。
さらに、箱というメタファーは教育的には便利だが、誤解を生む可能性もある。初心者が「すべてが箱」と思い込むことで、概念の違いや設計の意図を見失うことがある。箱はあくまで説明のための道具であり、概念そのものではない。
そこで、「箱」以外のメタファーが重要になる。以下に、より動的・構造的な理解を促すメタファーを紹介する。
グラフ（Graph）：関係性と構造の可視化
関数呼び出しの関係やオブジェクト間の通信は、ノードとエッジで構成されるグラフとして捉えることができる。例えば、関数 f_main が f_init や f_process を呼び出す構造は、箱ではなくネットワークとして表現される。
このような視点は、依存関係の可視化や再帰構造の理解に役立ち、設計の柔軟性を高める。
場（Field）：連続的な変化と分布の表現
制御系や物理モデルでは、温度や速度などの物理量は空間や時間に応じて連続的に変化する。例えば、温度場 $T(x, y, z)$ は、空間座標に対する関数として定義される。
これは「箱」ではなく「場」として捉えることで、勾配や分布、連続性を直感的に理解できる。特にセンサーネットワークや流体解析では、場のメタファーが不可欠である。
流れ（Flow）：データや制御の動的な伝播
関数型プログラミングやストリーム処理では、データが関数を通じて流れる構造が重要になる。例えば、センサーデータがフィルタ関数を通じて処理され、意思決定ロジックを経てアクチュエータに出力される流れは、以下のように表現できる。
このような「流れ」のメタファーは、動的な処理やリアクティブな設計において、箱よりも適している。
メタファーの選択が設計思想に与える影響
「箱」は静的・閉じた構造を想起させるが、「グラフ」は関係性と構造、「場」は連続性と分布、「流れ」は動的な伝播と変化を強調する。それぞれのメタファーは、設計や理解の方向性を大きく左右する。
抽象化とは、単に隠すことではなく、構造を選び取ることでもある。箱に閉じ込めるだけでなく、関係性を描き、分布を捉え、流れを感じる——それが、より深い設計と理解につながる。
結論：箱というメタファーの力と罠、そしてその乗り越え方
「全部箱かい！！！」というツッコミは、単なる冗談ではない。それは、プログラミングにおける抽象化の本質を突く問いでもある。箱というメタファーは、わかりやすさと構造化の力を持つ一方で、概念の違いを曖昧にしてしまう危険もある。
それでも、我々は箱を使い続ける。なぜなら、箱は人間の思考にとって、最も自然な抽象の形だからだ。だが、箱に頼りすぎることで、本質的な違いを見失うリスクもある。箱の中身を理解すること、そして箱の外にある構造を見渡すこと——それが、ソフトウェアエンジニアに求められる視点なのかもしれない。
筆者のように、プログラミングと数理モデルの両方を扱う立場から見ると、「箱」というメタファーは、抽象化の入り口としては有効だが、出口としては不十分である。数理的な関数は、変数間の関係性を記述するものであり、箱に閉じ込めるよりも、空間的・時間的な広がりを持つ構造として捉えるべきだ。
特に、システム全体をネットワークとして捉える視点では、関数や変数はノードやエッジとして機能し、情報や状態が流れる構造を形成する。こうした視点では、「箱」よりも「グラフ」や「場（field）」といったメタファーの方が適している。
また、制御系や物理モデルでは、関数や変数は連続的な変化を前提とする。箱という静的なイメージでは、こうした動的な性質を捉えきれない。むしろ、流れ、ネットワーク、場といったメタファーの方が適している場面も多い。
おわりに：箱を越えて、構造へ
「箱」は、プログラミング教育において非常に強力なメタファーである。だが、箱に閉じ込められたままでは、複雑な構造や動的な関係性を見失ってしまう。クラス、オブジェクト、関数、変数——それぞれの概念は、箱として捉えることもできるが、それ以上の意味と構造を持っている。
エンジニアとして、そして数理的な視点を持つ者として、筆者はこう考える。箱は出発点であり、目的地ではない。
箱の中に何があるかを知り、箱の外に何が広がっているかを理解すること。それが、より深い設計と理解につながる。
その他のエッセイはこちら
コメント