書かない設計 — 偉大なプログラマは優秀なプログラマのコードを利用する

優秀なプログラマほど、たくさんのコードを書く。業界ではそう考えられがちです。生産性の物差しとして、行数やコミット数が使われることもあります。けれども 1999 年、Eric S. Raymond は The Cathedral and the Bazaar で、正反対の命題を打ち出しました。偉大なプログラマは、書くべきものを知っているのではなく、書き直すべきもの (そして再利用すべきもの) を知っている²。

Good programmers know what to write. Great programmers know what to rewrite (and reuse)².

「書かない」ことを選ぶ勇気が、設計の核心にある。これが本稿の命題です。本サイトの基礎記事 決定論的にではなく、相対的に の言葉でいえば、「書かない」とは、自分で書かない部分の 媒介 を、他者の優秀な実装に任せる選択です。媒介とは、何が見えるか・何ができるか・何が考えやすいかを決める道具立てのことです¹。つまり書かない設計とは、「どの媒介を誰に任せるか」の判断です。この命題は、Unix の最古層からオープンソースの生態系を経て、いまの AI の道具立ての設計まで、一本の筋として通っています。本稿では、いくつかの歴史上の例で、それを確かめていきます。

「一つのことを上手にやる」── 原始的な再利用設計

Raymond の宣言より 21 年前、ベル研究所の Doug McIlroy は、Unix の設計哲学として一行を残しました。のちに世界でもっとも引用されることになる一行です。

プログラムを作るには、一つのことを上手にやるプログラムを作れ。新しい仕事をやるには、新しい「機能」を継ぎ足して古いプログラムを複雑にするのではなく、新しいプログラムを作って組合せろ⁴。

この考え方が、Unix の パイプ を支えました。grep は検索だけ、sort は並べ替えだけ、uniq は重複の除去だけをします。どれも小さく、使い回せて、自由に組み合わせられます。そして組み合わせ方は、使う人が工夫する場所として残されています。

書かないことの価値は、この時点で 既に内蔵されていた のです。McIlroy の主張を裏から読むと、「新しい機能が必要な時、まず既存のプログラムの組合せで実現できないか考えろ」になります。書く前に、書かずに済む方法を探す。Raymond がのちに再利用の原則として言葉にする発想の、もっとも古い表明です。

書く側の責任 ── Knuth の文芸的プログラミング

McIlroy は「組み合わせる側」の哲学を語りました。これに対して Donald Knuth は 1984 年に、「書かれる側」の哲学を示しました。文芸的プログラミング (Literate Programming) です⁵。

プログラミングを、コンピュータに何をさせるかをコンピュータに告げる行為としてではなく、人間に何をさせたいかを人間に説明する行為 として扱おう、と私は提案する⁵。

再利用の目で見ると、この発想の転換には深い意味があります。コードを他人に使い回してもらうには、まず 他者がそれを読めること が要ります。「動くコード」と「読めるコード」のあいだには、大きな隔たりがあります。後者を書く責任を引き受けるのが、Knuth のいう文芸的プログラマです。

Knuth が一人で書いた TeX は、いまも世界中の学術組版で使われています。一人の書いた約 25 千行のコードが、数十年にわたって何百万人に使い回されてきました。「書く側が負うべき責任」を、Knuth が極限まで果たした例と言ってよいでしょう。ここから一つの対称性が見えてきます。書かない設計 が成り立つのは、誰かが「書かれる側」の責任をまじめに引き受けているからです。

接続の哲学 ── 陶器と配管

書く側と組み合わせる側の分業を、もっともきれいに表しているのが、Git の設計用語として有名な 「陶器 (porcelain) と配管 (plumbing)」 です⁷。

• 陶器: ユーザに磨かれた表面を提示する高水準コマンド (git commit / git push)
• 配管: 陶器が背後で呼び出す低水準コマンド (git update-ref / git hash-object)

陶器は配管を 書き直さず、組合せる。配管の作者は、陶器が安心して頼れる、安定したインターフェースを用意する責任を負います。二つの層は、互いを信頼することで成り立っています。

Brian Kernighan と Rob Pike は The Practice of Programming (1999) で、この分業を「ライブラリとイディオム (定型の書き方) の活用」として、日々の実践に落とし込みました⁶。主張は単純です。標準ライブラリをとことん使え。書く前に、すでにあるかを確かめろ。書くものは最小限にしろ。

McIlroy (1978) → Knuth (1984) → Raymond (1999) → Kernighan & Pike (1999) → Git (2005)。書かない設計 は、Unix の最古層からオープンソースの生態系の中心まで、それぞれ独立に、何度も見つけ直されてきた命題です。

信頼の基盤としてのオープンソース

書かないことが成り立つには、もう一つ前提があります。再利用先のコードが信頼に足ること です。動作の保証、API の安定、保守の継続、セキュリティの透明性。これらが揃っていなければ、再利用はリスクを持ち込むだけの行為になります。

オープンソースの生態系は、この信頼を 可視性 で支えています。コードが公開されていれば、誰でも読み、確かめ、フォークし、改良できます。Linus Torvalds の有名な命題、「目の数が十分にあれば、すべてのバグは浅い (Linus’ Law)」は、使い回されるコードがオープンソースであることの、認識論上の意味を短く言い表しています³。

書かない設計は、コードを効率よく書くための技法であるとともに、オープンソースという信頼の基盤への依存と参加の宣言 でもあります。使い回すだけでは足りません。バグを報告し、ドキュメントを補い、必要ならフォークして改良し、その成果を上流に返す。そこまでして初めて、書かないことの倫理は閉じます。

実装例 ── AI の道具立てにおける「書かない」

AI の時代になって、書かない設計は新しい局面に入っています。本サイトの既掲記事 記録を標準化する で扱った media-scribe-workflow を例にとると、その部品の大半は 書かれていない ことがわかります。

このパイプラインで「書いた」のは、これらをどう接続するか だけです。どの層も、世界中で何百万人もの手で確かめられ、長年の保守を経て安定した「優秀なプログラマのコード」です。Raymond の命題に沿っていえば、接続部だけを書くという選択 こそが、偉大さを実際に形にしたものです。

LuaTeX を Docker でリモート実行する の構成も同じです。TeX Live 一式も、和欧のフォント群も、Docker、SSH、rsync も、何一つ自前では作っていません。書いたのは、これらを「リモートホストでコンテナを起動して同期する」という一連の処理に束ねる、薄いシェルスクリプト群だけです。書かない選択を突き詰めたとき、ローカル環境を汚さない学術組版環境という、独自の機能が立ち上がります。

ここからは、書かない設計が倫理の面でどこまで届くのかを考えてみます。

書かない選択は、コードの生産性だけの話ではありません。再利用とは、他者の労働の蓄積に乗ること です。これは、本サイトの基礎記事 決定論的にではなく、相対的に でいう 媒介性 の、社会に広がった一面です。媒介性とは、道具やメディアが認知を組み立てる部品として、何が見えるか・何ができるか・何が考えやすいかを決めることを指します。Clark & Chalmers が認知科学の側から「拡張された心」として論じたものと、本サイトが媒介性と呼ぶものは、同じ事態への別の入口です¹。

書かない設計は、その媒介を 他者の優秀な実装に委ねる やり方です。他者が書いたコードが、私の認知システムの構成要素として組み込まれる のです。grep を使うとき、私は McIlroy の思考を借りています。LuaTeX で組版するとき、私は Knuth の思考を借りています。Whisper で音声を文字起こしするとき、私は OpenAI の数千 GPU 時間を借りています。借りた媒介は中立ではありません。「grep で考える」「TeX で考える」という形へ、私の思考を寄せていきます。だから「何を借りるか」は、効率の問題であると同時に、「思考の形」の問題でもあります。

この関係が 公正に成立する には、二つの条件が要ります。

第一に、借りている側 (再利用する側) が借りていることを意識すること。ライセンスを守る。貢献を表示する。必要ならお金でも還元する (オープンソースへの資金提供など)。これらを、無自覚にではなく、自覚して行うことです。

第二に、書く側 (再利用される側) が、再利用される前提で書くこと。Knuth の文芸的プログラミングの倫理、テストとドキュメントの整備、API の安定を保つこと、後方互換性への責任。どれも、書かれる側が果たすべき責任です。

書かない設計は、書く側と書かない側の対称的な責任 を前提にした生態系として成り立っています。では、AI 時代に LLM が「書く側」として加わったとき、この対称性はどう保たれるのか。AI が書いたコードを使い回すとき、私たちは何を借りていて、その借りにはどんな返済が求められるのか。これは、いまの知的な営みが向き合っている、まだ答えの出ていない問いです。

「書かない」ことは、技術の面では効率の話、生態系の面では信頼の話、倫理の面では責任の話です。Eric Raymond の 1999 年の宣言は、この三つを同時に背負った命題として、いまも重みを持っています。LLM の時代になって、その重みはむしろ増しているのかもしれません。

参考文献