原題: Out of the Tar Pit
著者: Ben Moseley, Peter Marks
公開日: 2006年2月
ソースURL: https://curtclifton.net/papers/MoseleyMarks06a.pdf
アーカイブ日: 2026-06-11
本論文は、大規模ソフトウェアシステム開発における最大の困難が複雑性（complexity）であると位置づけ、Fred Brooksの古典「No Silver Bullet」を批判的に継承する形で議論を展開する。
Brooksはソフトウェア開発の本質的困難として複雑性・同調性・可変性・不可視性の4つを挙げたが、MoseleyとMarksは複雑性だけが真の問題であり、残りは複雑性の一形態か、複雑性によって初めて問題になると主張する。より根本的に、彼らはBrooksが「本質的（essential）」とした複雑性の多くは実際には偶発的（accidental）であり、適切な方法論と言語設計によって除去可能だと論じる。
論文は複雑性の原因を3つに分類する。
1. 状態（State）
可変状態（mutable state）こそが最大の複雑性の原因だ。状態があるとテストが決定的に困難になる——ある状態におけるテスト結果は、別の状態での振る舞いを何も保証しない。「再起動してください」というサポートデスクの定番対応は、システムが状態の管理に失敗していることの証左に他ならない。
さらに深刻なのは汚染（contamination）の問題だ。自分自身はステートレスでも、どこかで状態を持つ手続きを呼び出せば（間接的であっても）、その手続き全体の理解には状態の文脈が必要になる。「ラクダの鼻をテントに入れると、後ろ全体がついてくる」のだ。
2. 制御（Control）
ほとんどのプログラミング言語は暗黙の制御フロー（逐次実行・分岐・サブルーチン呼び出し）を強制する。これによりプログラマは「どう実現するか」を「何を実現するか」以上に指定せざるを得なくなる。たとえば3つの代入文を並べただけで、プログラマは実行順序を指定していることになる——実際には順序に一切の意味がないにもかかわらず。コンパイラはこの人工的な順序を後で除去しようと余計な仕事をする。並行性が加われば事態はさらに悪化する。共有状態の並行処理では、同一の初期状態と同一の入力でテストを繰り返しても、同じ結果が得られる保証すらない。
3. コード量（Code Volume）
コード量そのものは多くの場合、状態管理や制御指定の二次的産物である。しかし複雑性はコード量に対して非線形に増大するため、コードを絶対最小限に抑えることが不可欠だ。Dijkstraの指摘を引用しつつ、適切な抽象化によりコード量に対する理解の負荷を線形に抑えられる可能性も示唆している。
論文は3つのパラダイムを検討する。
オブジェクト指向: 状態をカプセル化する点で非構造化命令型よりは進歩しているが、本質的に状態に依存しており、状態由来の複雑性から逃れられない。オブジェクト同一性（intensional identity）の概念はさらに複雑性を増す。
関数型プログラミング: 参照透過性（referential transparency）により状態の問題を根本的に回避する。しかし、現実のシステムで状態を扱おうとすると、関数の引数として状態を引き回すか、モナドに頼ることになる。モナド自体はエレガントだが、副作用のあるサブ言語を再導入する危険をはらむ。
論理型プログラミング: 理想的な形では制御の複雑性からの脱却を約束する。しかしPrologのような実際の言語では、節の順序やカット（cut）など操作的な解釈が避けられず、純粋な論理プログラミングの理想から乖離している。
論文後半では、純粋関数型プログラミングとCoddのリレーショナルモデルを組み合わせたアプローチを提唱する。リレーショナルモデルはデータの完全性制約の宣言的記述に優れており、オブジェクト指向のカプセル化では扱いにくい複数オブジェクトにまたがる制約も自然に表現できる。関数型の参照透過性とリレーショナルモデルの宣言的データ管理を組み合わせることで、状態と制御の両方に起因する偶発的複雑性を大幅に削減できる可能性を示す。
「Out of the Tar Pit」は、2006年の発表から20年近く経った今もなお、ソフトウェア複雑性論の参照点として読み継がれている。その最大の功績は、「複雑性の大部分は偶発的であり、取り除ける」という明確な主張を、状態・制御・コード量という分析可能な軸で提示したことにある。
Brooksの「No Silver Bullet」が銀の弾丸の不存在を説いて一種の諦念を生んだのに対し、本論文は「少なくともタールピットからの脱出経路は存在する」という方向性を示した。この楽観的なメッセージは、その後のClojureやElm、Haskellの実務採用の拡大など、関数型＋宣言的データ管理の実践的な流れの先駆けとして位置づけられる。
本論文の議論で特に重要なのは、汚染（contamination）の概念である。状態はその存在箇所だけでなく、呼び出しグラフを通じて周辺全域の理解可能性を毀損する——これは関数型プログラマの間で共有されている直感を明確に言語化したものだ。また、暗黙の制御フローを「オーバースペック」と喝破した指摘は、今なお命令型言語が支配的な現状に対して有効な問いを投げかけ続けている。
欠点を挙げれば、提案する関数型＋リレーショナルモデルの具体的な実装についての記述はスケッチの域を出ておらず、現実の大規模システムでどの程度のオーバーヘッドが生じるかの検証が不足している。しかしこれは論文の価値を減じるものではなく、むしろその後の研究と実践に委ねられた宿題として機能している。