振り返り ── 10の系譜
10話を歩いた。アテネの港でテセウスが船を残し、ウィトゲンシュタインがケンブリッジで建設現場を想像し、パチョーリがヴェネツィアで帳簿を書き起こした。ラッセルは1901年の夜にフレーゲ宛の手紙を書き、ゲーデルは1930年のケーニヒスベルクで会場の隅から発言し、偽ディオニュシオスは5世紀のアレクサンドリアで神を否定によって描こうとした。プラトンは洞窟の影を語り、ヘラクレイトスは川を眺め、ウィリアム・オブ・オッカムはエンティティを切り、カントは認識の中心を主体側へ移した。
これらの問いは、いつかの誰かが解いて終わったわけではない。形を変えて、コードの中で今も動き続けている。
mindmap
root((CS概念に\n宿る哲学))
DDD
第1話 テセウス → Entity
第2話 ウィトゲンシュタイン → Bounded Context
第3話 パチョーリ → Event Sourcing
型と限界
第4話 ラッセル → 型システム
第5話 ゲーデル → CAP定理
第6話 否定神学 → テスト
抽象と方向
第7話 プラトン → インターフェース
第10話 カント → DIP・TDD
時間と量
第8話 ヘラクレイトス → 不変性
第9話 オッカム → YAGNI哲学から CS への 4 つの継承パターン
10の系譜を並べてみると、「哲学からCSへの翻訳」にはいくつかの異なる形があることが見えてくる。
パターン1：直接的な継承（Direct Lineage）
歴史的に明確な引用と継承の連鎖がある場合。
- 第4話： ラッセルのパラドックス（1901）→ ラッセルの型理論（1908）→ チャーチの単純型付きラムダ計算（1940）→ Hindley-Milner 型推論（1969・1978）→ Haskell・ML・TypeScript・Rust
- 第3話： パチョーリ『算術全書』（1494）→ 商人の慣行 → ファウラー「Event Sourcing」（2005）→ グレッグ・ヤングの形式化（2010頃）
このパターンの特徴：論文や書籍の引用関係で系譜を辿れる。CSの中で「これは何々の応用です」と明示的に語られることが多い。
パターン2：構造的並行（Structural Parallel）
直接の引用関係はないが、同じ問題が別の文脈で再発見されている場合。
- 第1話： テセウスの船（古代ギリシャ）≈ Entity vs Value Object（DDD 2003）。エヴァンスはホッブズもプルタルコスも引用していない。
- 第8話： ヘラクレイトスの川（紀元前6世紀）≈ イミュータブル設計。Rich Hickey は Clojure の哲学を語るときヘラクレイトスに触れたが、設計上の発想は独立に到達している。
このパターンの特徴：同じ問いの形が、別の文脈で別の人によって、同じ答えに辿り着く。問いの形そのものが普遍的だから起きる。
パターン3：方法論の転用（Methodological Transfer）
哲学・神学の方法論が、別領域に意図的に持ち込まれた場合。
- 第6話： 否定神学（5世紀〜）→ ポパーの反証可能性（1934）→ プロパティベーステスト（1999）。「何でないかを語る」という方法そのものが工具として継承されている。
- 第9話： オッカムの剃刀（14世紀）→ Unix 哲学（1970年代）→ KISS（1960年代）→ YAGNI（XP, 1999）。「必要以上のエンティティを増やすな」という認識論的節度が、エンジニアリング上の節度に転用されている。
このパターンの特徴：哲学が提示したのは方法であって、その方法は領域を選ばない。神学にも、科学にも、コードにも適用できる。
パターン4：哲学的転倒（Philosophical Inversion）
「方向」や「中心」を入れ替える発想自体が、設計に持ち込まれた場合。
- 第7話・第10話： プラトンのイデア論（具体は抽象に従う）+ カントのコペルニクス的転回（対象は心に従う）→ 依存性逆転原則・TDD・ヘキサゴナルアーキテクチャ。設計の依存関係そのものを「逆向き」にする発想が、哲学から借りられている。
このパターンの特徴：哲学者が 何を中心に置くか を問い直したのと同じ問いを、設計者が 何が何に従うか として問い直す。問いの構造が転用されている。
まだ翻訳されていない哲学
10話を書き終えてもなお、CS に持ち込まれていない哲学的アイディアは多い。最後に、いくつか候補を残しておく。読者が次に「考古学」を始める起点になればいい。
物語論（Narratology）→ ユーザーフローの形式文法
ロシアの民俗学者 Vladimir Propp は1928年、民話の構造を「31の機能」と「7つの登場人物類型」に分解した。「主人公が欠乏を感じる」「助力者が現れる」「試練を経て解決する」。ユーザージャーニーマップが暗黙にやっていることを、形式文法として記述できる可能性がある。
ストア哲学の制御二分法 → 境界設計
「自分でコントロールできるものとできないものを分けよ」（マルクス・アウレリウス）。外部依存を「コントロール不能領域」として明示的に境界を引く設計哲学。Hexagonal Architecture が部分的に実践しているが、ストア的な枠組みとしては未整理。
修辞学（Rhetoric）→ AI 説明設計
アリストテレスの三要素（ロゴス：論理、エトス：信頼性、パトス：感情）。LLM がユーザーに何かを説明するとき、この三要素のバランスはほとんど無自覚に処理されている。Explainable AI の研究はあるが、修辞学の文脈での体系化は未整備。
パース記号論 → 型システム・プロトコル設計
二項モデル（記号と意味）ではなく三項モデル（記号・対象・解釈項）。型システムやプロトコル設計が「解釈項」を欠いていないか、という問いの起点になりうる。
複式簿記の保存則 → 権限管理の二重仕訳
第3話で取り上げた複式簿記の核心は「すべての取引には貸借両側の対応がある」という保存則だ。これを権限管理に適用できないか。権限の付与は常に「責任の付与」と対応していないか——監査ログを 借方／貸方の二重仕訳 として設計すれば、Confused Deputy Problem は「不正な転記」として検出可能になる。
一つの原則 ── 問いの形は再利用される
10話と4パターンが示しているのは、ひとつの単純な事実だ。
哲学・歴史・神学が解いてきた「問いの形」は普遍的で、新しい技術環境でも再現する。
人間が時間を扱うかぎり、ヘラクレイトスの川は必ず流れる。人間が同一性を扱うかぎり、テセウスの船は必ず板を取り換える。人間が形式体系を扱うかぎり、ラッセルの亀裂は必ず開く。これらは技術が変わっても消えない。技術はむしろ、これらの問いを 新しい場所で再現する装置 だ。
だから、設計で行き詰まったとき問うべきは「この問題を解いた人がもうどこかにいるんじゃないか」だ。たいていの場合、答えは「いる」だ。それは別の世紀の、別の言語を話す、別の問いの形をした人かもしれない——しかし、彼らが残した「問いの立て方」は、あなたの目の前のコードに翻訳できる。
考古学とは、そういう翻訳の作法だ。
参考文献・情報源
原典・思想史
- Plutarch, Vita Thesei (テセウスの伝記、紀元1世紀末)
- Heraclitus, Fragments (ディオゲネス・ラエルティオス『哲学者列伝』に収録、断片91)
- Plato, Republic (Book VII：洞窟の比喩) / Meno (アナムネーシス)
- Pseudo-Dionysius the Areopagite, Mystical Theology (5〜6世紀)
- Luca Pacioli, Summa de arithmetica, geometria, proportioni et proportionalità (Venice, 1494)
- William of Ockham, Summa Logicae (14世紀)
- Thomas Hobbes, De Corpore (1655、テセウスの船への二隻問題の追加)
- Immanuel Kant, Kritik der reinen Vernunft (Königsberg, 1781)
- Bertrand Russell, “Letter to Frege” (1902年6月16日付)
- Bertrand Russell, “Mathematical Logic as Based on the Theory of Types” (1908)
- Kurt Gödel, “Über formal unentscheidbare Sätze…” (Monatshefte für Mathematik, 1931)
- Alan Turing, “On Computable Numbers…” (Proc. London Math. Soc., 1936)
- Karl Popper, Logik der Forschung (1934)
- Ludwig Wittgenstein, Philosophische Untersuchungen (1953, 死後出版)
CS 側の文献
- Eric Evans, Domain-Driven Design (Addison-Wesley, 2003)
- Erich Gamma et al., Design Patterns (Addison-Wesley, 1994)
- Robert C. Martin, “The Dependency Inversion Principle” (C++ Report, 1996)
- Alistair Cockburn, “Hexagonal Architecture” (2005)
- Martin Fowler, “Event Sourcing” (martinfowler.com, 2005)
- Greg Young, CQRS Documents (2010前後)
- Kent Beck, Test-Driven Development By Example (Addison-Wesley, 2002)
- Kent Beck, Extreme Programming Explained (Addison-Wesley, 1999)
- Koen Claessen and John Hughes, “QuickCheck: A Lightweight Tool for Random Testing of Haskell Programs” (ICFP, 2000)
- Tim Peters, “PEP 20 — The Zen of Python” (1999執筆 / 2004公式化)
- Eric Brewer, “Towards Robust Distributed Systems” (PODC keynote, 2000)
- Seth Gilbert and Nancy Lynch, “Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services” (ACM SIGACT News, 2002)
- Rich Hickey, “Are We There Yet?” (JVM Languages Summit, 2009) — Clojure の時間と状態の哲学
関連する記事・シリーズ
- 本シリーズ前作：EvansとVernonで学ぶDDD
- 並行する深掘り：Event Sourcing Deep Dive ── 第3話の続きをここで掘る
最後の問い：あなたが次にコードで解こうとしている問題には、何百年も前にすでに名前が付いていないか。