Martin Fowler の記事「What Is Code?」は、タイトルこそシンプルですが、かなり本質的な問いを投げかけています。
一見すると「コードとは、プログラマーが書く命令文でしょ？」で終わりそうです。でもこの記事は、そこから一段深く掘ります。特に生成AIやLLMが普及した今、この問いはかなり重い。コードを“書く”コストが下がったとき、何が本当に価値になるのか——その答えを探る記事です。
私はこの問題設定、すごく面白いと思います。というのも、AIがコードを書けるようになった今、私たちは「コードを書く仕事」そのものではなく、「何をコードにさせるべきか」を考える仕事へ、少しずつ寄っているからです。
記事の中心的な主張はとても明快です。
コードには2つの役割がある、という話です。
機械への命令
これはいわゆる「プログラム」です。データを動かし、処理を実行し、保存し、通信する。コンピュータを意図通りに動かすための指示ですね。
問題領域の概念モデル
こっちが記事の肝です。コードは単なる命令列ではなく、現実世界の問題をどう理解するかを表す「モデル」でもある、という考え方です。
たとえば Customer、Order、Payment のような名前が出てくるとき、それはただの変数名ではなく、私たちがその業務をどう捉えているかを示しています。
この視点はとても重要です。
雑に言えば、コードは「コンピュータ向けの説明書」であると同時に、「人間向けの地図」でもあるんですね。
個人的には、後者を忘れるとコードはすぐに“動くけど意味不明なもの”になりがちだと思います。
記事では、コードの本質を vocabulary（語彙） という言葉で説明しています。
ここでいう語彙は、単に単語の集まりではありません。あるドメインで共有されている概念のセットです。
たとえば、英語がわからないとこの記事は読めません。
でも、英語がわかるだけでも足りない。ソフトウェア開発の文脈で abstraction という言葉が出たとき、それは単なる「抽象化」という日本語訳以上の意味を持っています。業界の歴史や設計上の含意まで背負っているわけです。
つまり、ドメインには固有の言葉がある。
そして、良いコードはその言葉をそのまま反映している。ここがすごく大事です。
たとえば retail の世界なら、customer、product、order、shipment、payment といった語彙が中心になります。
一方、web 開発の側では、GET、POST、PUT、DELETE のような HTTP メソッドや、resource の考え方が効いてくる。
ここで起きているのは、業務の言葉を技術の言葉に翻訳する作業 です。
そして、その翻訳結果がコードになる。記事はこの点をかなり強調しています。
私はこれ、ソフトウェア開発の本質をかなり言い当てていると思います。
プログラミングって、キーボードを叩く作業に見えますが、実際は「異なる世界の言葉をつなぎ合わせる仕事」なんですよね。
ここで出てくるのが、Domain-Driven Design の bounded context です。
日本語にすると「境界づけられた文脈」ですが、少し硬いので、ざっくり言えば “この範囲ではこの意味で使う”と決める境界 です。
たとえば、同じ Order という言葉でも、
のように意味がズレることがあります。
このズレを無理やり1つの万能定義に押し込めると、だいたい失敗します。
記事は、ドメインの核心に近づくほど、抽象化はローカルに発見される と言います。
つまり、最初から「世の中すべてに効く完璧な設計」を作るのではなく、その現場、その業務、その文脈の中で、本当に使える言葉と構造を見つける必要がある、ということです。
これはかなり現実的な話です。
「万能フレームワークがないのはなぜか？」という問いに対して、記事は「語彙が安定していないから」と答えています。かなり納得感があります。現場ごとに意味が違うものを、1つの抽象で全部まとめるのは無理筋なんですよね。
記事では、TDD や Agile の考え方にも触れています。
TDD は Test-Driven Development の略で、ざっくり言うと「テストを書いてから実装する」やり方です。
ここで面白いのは、TDD を単なるテスト技法としてではなく、語彙を試し、磨くための反復作業 として見ている点です。
コードを書いて、動きを確認して、違和感を感じて、名前や境界を直していく。この往復によって、モデルが洗練されていくわけです。
Agile の
といった価値観も、単なるプロセス論ではなく、フィードバックを通じて語彙を発見する方法 として読める、というのが記事の見方です。
この解釈、かなり好きです。
Agile を「会議を減らす方法」みたいに雑に扱うと本質を外しますが、本来は「現実と対話し続けて、モデルを育てる」ための態度なんですよね。
記事はさらに一歩進んで、Programming Languages As Thinking Tools という見方を提示します。
これはつまり、プログラミング言語は「考えたことを表すための道具」であるだけでなく、考え方そのものを形づくる道具 でもある、という話です。
たとえば：
言語が違うと、同じ問題でも見え方が変わるんですね。
これ、開発者なら心当たりがある人も多いと思います。「この言語だとこう考えるしかない」という感覚です。
記事では、Future の API 設計や snapshot isolation の仕様検討の例も出てきます。
要するに、複雑なものをうまく理解するには、自然言語だけでは足りないことがある。
ときには pseudo-formal spec のような、少し形式的な書き方が思考を助ける。ここはすごく実践的です。
個人的には、これは「コードを書く」のではなく「理解可能な形に落とす」作業の話だと思います。
人間の頭は曖昧さに強い一方で、曖昧さのままでは設計の穴が見えにくい。だから、言語の制約がむしろ思考を助けるんですよね。
記事の現代的な核心はここです。
LLM は、巨大なテキストやコードのコーパスから学習して、Controller、Repository、Reducer、ConsensusModule、TransactionLog のような言葉と、それに結びつく構造を知っています。
つまりLLMは、ある意味で 語彙のパターンを大量に持っている。
だからこそ、見た目のコード生成は得意です。
でも、記事が言いたいのはたぶんそこではありません。
LLMが強いからこそ、私たち人間には「何をモデル化するべきか」「どこで境界を切るべきか」「どの語彙を採用するべきか」がますます重要になる、ということです。
これはかなり鋭い指摘だと思います。
AIがコードを書くようになると、単純なタイピング作業の価値は下がる。
でも逆に、設計の責任 は薄まるどころか、むしろ重くなるんじゃないか。
なぜなら、生成されたコードが正しいかどうかを判断するには、こちら側に概念モデルが必要だからです。
LLMは、既にある語彙を再構成するのは上手い。
でも、その場の現実にぴったり合う新しい語彙を、責任を持って選び抜くのは、まだ人間の仕事だと思います。
記事の終盤では、コードを shared Conceptual Model として捉えます。
これはつまり、コードは単なる実装ではなく、チーム全体で共有する「この問題をどう理解するか」の合意でもある、ということです。
この見方を採ると、コードレビューの意味も少し変わります。
単に「動くか」「バグがないか」を見るだけじゃなく、
ここは、かなり重要です。
良いコードとは、機械にとって正しいだけでなく、人間同士の認識のズレを減らすものでもあるからです。
この記事を通して見えてくるのは、コードの価値は「書けること」そのものではなく、複雑な現実を、みんなで扱える形にすること にある、という考え方です。
LLM がコード生成を安くした今、コードはますます“ただの出力物”ではなくなっています。
むしろ、
私はこの記事を読んで、コードを書く仕事はなくならないけれど、コードを作る前の思考の価値はむしろ上がる と感じました。
そしてその思考を支えるのが、domain の語彙であり、bounded context であり、プログラミング言語そのものなんですね。
AI時代の「コードとは何か？」に対して、この記事はかなり筋のいい答えを出していると思います。
コードは命令である。けれど同時に、世界を理解するためのモデルでもある。
この2つを忘れないことが、これからますます大事になりそうです。
参考: What Is Code?
