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

業界の通念は、優秀なプログラマほど沢山のコードを書く、というものでしょう。生産性の指標として行数やコミット数が引かれることもあります。けれども 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 道具立ての設計まで一貫して通っていることを、複数の歴史的事例で確認してみます。

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

Eric 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 を例に取れば、その構成要素の大部分は 書かれていない のがわかります。

機能	借りているコード	書く側の作者
音声認識	Whisper	OpenAI チーム
文脈解析・構造化	Claude API	Anthropic チーム
組版	LuaTeX (Lua + TeX)	Knuth + 後継者たち
動画エンコード	ffmpeg	Bellard ほか
GUI フレームワーク	PySide6 / Qt	Qt Company + The Qt Project
画像処理	OpenCV	OpenCV.org コミュニティ
字幕形式	SRT	SubRip 開発系譜

本パイプラインで「書いた」のは これらをどう接続するか だけです。それぞれの層は、既に世界中で何百万人に検証され、長年の保守を経て安定した「優秀なプログラマのコード」だといえるでしょう。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 時代になってますます ── 重みを持ち続けていると整理できるでしょう。

参考文献