ジョン・オースターハウト：実践的設計、Tcl、そして複雑性のコスト

なぜオースターハウトのメッセージはいまも重要なのか

John Ousterhoutは研究と実システムの両方にまたがるコンピュータ科学者・エンジニアです。彼はTclを創り、現代のファイルシステム設計にも寄与し、長年の経験を一つのシンプルでやや耳障りな主張に凝縮しました：複雑性はソフトウェアの最大の敵である。

このメッセージが今も有効なのは、ほとんどのチームが機能不足や努力不足で失敗するのではなく、システム（と組織）が理解しにくく、変更しにくく、壊れやすくなることで失敗するからです。複雑性はエンジニアのスピードを遅くするだけでなく、製品意思決定、ロードマップの確信度、顧客信頼、インシデント頻度、さらには採用にまで漏れ出します—オンボーディングが何ヶ月もかかるようになるからです。

中核テーマ：複雑性は全てに課税する

オースターハウトのフレームは実践的です：システムが特殊ケースや例外、隠れた依存、そして「今回はこれでいいか」という修正を蓄積するとき、そのコストはコードベースに留まりません。製品全体が進化させるのに高くつくようになります。機能は時間がかかり、QAは難しくなり、リリースはリスクが高まり、チームは何かに手を付けること自体を避け始めます。

これは学術的純度を求める呼びかけではありません。すべての近道には利子が付きます—そして複雑性は最も利息の高い負債です。

この記事での三つの視点

アイデアを具体化するため、以下の三つの角度からオースターハウトの主張を見ます：

• Tclの遺産：単純さ、合成性、そして“グルー”の考え方が言語を超えて広まった理由。
• ブルックスとの関係："No Silver Bullet"がオースターハウトの見解とどこで関係し、どこで差が出るか。チームが出荷する際に学べること。
• 実践的な設計ルール：特に「ディープモジュール」とAPI設計のテクニックで、次にシステムを変更する人（たいていはあなた）の認知負荷を減らす方法。

期待できること

これは言語マニア向けだけではありません。製品を作る人、チームを率いる人、ロードマップのトレードオフを決める人であれば、複雑性を早期に見抜き、それが制度化するのを防ぎ、単純さを第一級の制約として扱うための実行可能な方法を学べます。

日常のチームで「複雑性」は本当は何を意味するか

複雑性は「コードが多い」や「難しい数式」ではありません。それは、変更したときにシステムがどう振る舞うかとあなたが思っていることの間のギャップです。小さな編集がリスキーに感じられるとき、つまり影響範囲を予測できないとき、そのシステムは複雑です。

日々の仕事で複雑性が現れる形

健全なコードでは次の質問に答えられます：「これを変えたら他に何が壊れるか？」複雑性はその問いを高価にします。

よく隠れているのは：

• 隠れた依存：ある機能がコードからは明らかでないデータベース列、バックグラウンドジョブ、設定フラグに静かに依存している。
• 特殊ケース：「エンタープライズ顧客を除く」「2021年以前に登録した場合のみ」「モバイルからのリクエストなら例外」など、例外が積み重なり“通常の経路”が不明瞭になる。
• 不明確な所有権：ある領域に誰も責任を感じないため、修正が慎重なパッチになり、時間とともに最も安全な選択が「別の回避策を追加する」ことになる。

コスト：速度、品質、そして確信

チームは複雑性を出荷の遅れ（調査に時間を取られる）、バグの増加（振る舞いが予測できないため）、脆弱なシステム（変更に多くの人やサービスの調整が必要）として感じます。それはオンボーディングにも負荷をかけます：新しい仲間はメンタルモデルを構築できず、コアフローに触るのを避けます。

本質的複雑性と偶発的複雑性

一部の複雑性は本質的です：ビジネスルール、コンプライアンス要件、現実世界のエッジケース。これらは削れません。

しかし多くは偶発的です：わかりにくいAPI、重複ロジック、「一時的」なフラグが恒久化すること、内部詳細を漏らすモジュール。これが設計上の選択が生み出す複雑性であり、継続的に削減できる唯一の種類です。

Tclの遺産：広く広まった良いアイデア

Tclは実務的な目標から出発しました：ソフトウェアを自動化し、既存アプリケーションを再構築せずに拡張するのを簡単にすること。Ousterhoutは「十分なプログラマビリティ」をツールに与え、ユーザーやオペレーター、QAなどがワークフローをスクリプト化できるように設計しました。

「グルー言語」という考え方

Tclはグルー言語の概念を普及させました：小さく柔軟なスクリプト層で、より速い低レベル言語で書かれたコンポーネントを繋ぎます。すべてをモノリスに組み込む代わりに、コマンド群を公開してそれらを組み合わせて新しい振る舞いを作れます。

このモデルが影響力を持ったのは、実際の仕事の流れに合っていたからです。人々は製品だけを作るのではなく、ビルドシステム、テストハーネス、管理ツール、データ変換器、ワンオフ自動化を作ります。軽量のスクリプト層はそれらを「チケットを切る」から「スクリプトを書く」へと変えます。

Tclがうまくやったこと（そして広まった理由）

Tclは組み込みを第一級の関心事にしました。インタープリタをアプリに落とし込み、クリーンなコマンドインターフェースをエクスポートすれば、即座に設定可能性と高速な反復が得られます。

このパターンは今日のプラグインシステム、設定言語、拡張API、組み込みスクリプトランタイムの至る所に現れます—構文がTclに似ているかどうかは関係ありません。

また安定したプリミティブ（ホストアプリのコア能力）と変更されやすい合成（スクリプト）を分離する設計習慣を強めました。うまく行けば、ツールはコアを不安定にせずに速く進化します。

制約と関心が移った理由

Tclの構文や「すべてが文字列」モデルは直感的でないと感じられることがあり、大きなTclコードベースは強い慣習なしには理解しづらくなります。より豊富な標準ライブラリ、より良いツール、より大きなコミュニティを提供する新しいエコシステムが現れると、多くのチームは移行しました。

しかしそれはTclの遺産を消しません：拡張性と自動化が単なるオプションではなく、製品機能であり、システムを使う人や維持する人の複雑性を劇的に下げうるという考えを普通にしたのです。

Tclの哲学に隠れた設計教訓

Tclは一見厳格な考えに基づいて作られていました：コアを小さく保ち、合成を強力にし、スクリプトを十分に読みやすくして人々が常に翻訳を必要とせずに協働できるようにする。

合成を促す小さなコア

多くの特殊化された機能を出すより、Tclはプリミティブ（文字列、コマンド、簡単な評価規則）をコンパクトにし、それらを組み合わせることを期待しました。

この哲学は設計者を少ない概念に向かわせます。もし2〜3の一貫したビルディングブロックで10のニーズを解決できるなら、学ぶ必要のある表面積が縮まります。製品やAPI設計における教訓は明快です。

「使うのが簡単」と「実装が簡単」は違う

設計の罠は作り手の利便性を最適化することです。ある機能は実装が簡単（既存のオプションをコピー、特殊フラグを追加、角ケースにパッチ）でも、製品を使うのを難しくします。

Tclの強調はその逆でした：メンタルモデルを締めること（単純に保つこと）。実装が裏で多く働かなければならなくても、ユーザーが覚える概念を増やさない方が良い。

提案をレビューするときは問うべきです：これはユーザーが覚える概念の数を減らすか、例外を一つ増やしていないか？

小さなプリミティブは落ち着かせるが、鋭くもなりうる

ミニマリズムはプリミティブが一貫しているときに助けになります。似た二つのコマンドが端ケースで微妙に振る舞いが異なると、ユーザーは些細な知識を覚えざるをえません。少数のツールでも規則が微妙に変わると「鋭いエッジ」になります。

合成性とワンオフ機能（非技術的な比喩）

キッチンを想像してください：良い包丁、フライパン、オーブンがあれば多くの料理を作れます。アボカドだけをスライスするガジェットはワンオフ機能です—売りやすいが引き出しを散らかします。

Tclの哲学は包丁とフライパンを推します：汎用的な道具がきれいに合成できるようにして、毎レシピごとに新しいガジェットを必要としないようにする。

ブルックス一ページまとめ：「No Silver Bullet」とその主張

1986年、Fred Brooksは挑発的な結論を含むエッセイを書きました：ソフトウェア開発を一気に桁違いに速く、安く、信頼性を高める単一のブレークスルー（"銀の弾"）は存在しない、と。

彼の主張は進歩が不可能だという意味ではありません。ソフトウェアはほとんど何でも作れる媒体であり、その自由は独特の負担を伴います：我々は作りながら常に作る対象を定義しているのです。より良いツールは助けになりますが、最も難しい部分を消し去るわけではないと彼は言います。

本質的複雑性と偶発的複雑性

ブルックスは複雑性を二つに分けました：

• 本質的複雑性：問題そのものから生じる難しさ—現実世界のルール、エッジケース、相反する目標。
• 偶発的複雑性：我々の手法やツールが生み出す難しさ—扱いにくい言語、冗長なビルドパイプライン、手動デプロイ、詳細を考えさせるアーキテクチャなど。

ツールは偶発的複雑性を圧縮できます。高水準言語、バージョン管理、CI、コンテナ、マネージドDB、良いIDEから得たものを思い出してください。しかしブルックスは本質的複雑性が支配的であり、ツールの改善だけでは消えないと主張しました。

なぜ今でも意味があるか

現代のプラットフォームがあっても、チームは要求交渉、システム統合、例外処理、振る舞いの一貫性維持にエネルギーの多くを使います。表面は変わる（デバイスドライバの代わりにクラウドAPI）が、核心の課題は変わりません：人間の要求を正確で保守可能な振る舞いに翻訳することです。

この点がオースターハウトが突っ込む緊張点です：本質的複雑性を消せないなら、規律ある設計でどれだけ「どれだけがコードに漏れるか」を減らせるか？

「オースターハウト対ブルックス」議論（感情抜きで）

人々は時に「オースターハウト対ブルックス」を楽天主義と現実主義の対立のように表現しますが、経験ある二人のエンジニアが同じ問題の異なる側面を説明していると読む方が有益です。

オースターハウトの反論：設計は思ったより効果がある

ブルックスの“No Silver Bullet”は単一の魔法がハードな部分を消さないと主張しますが、オースターハウトはそれ自体に異議は唱えません。

彼の反論はより狭く実践的です：多くのチームは複雑性を避けられないものとして扱いますが、その多くは自己誘発的です。優れた設計は複雑性を意味のある程度で減らせます—ソフトウェアを「簡単」にするわけではなく、変更しにくさを減らすのです。混乱が日々の作業を遅くするのだから、それは大きな主張です。

ブルックスの警告：ある複雑性は組み込み済み

ブルックスは本質的困難に注目します。ソフトウェアは厄介な現実や変化する要求、コード外に存在するエッジケースをモデル化しなければなりません。優れたツールや賢い人々がいても、それらは消えません。管理するだけです。

実際にはどこで一致しているか

論争より両者の合意点は多いです：

• 世界が複雑なのである程度の複雑性は避けられない。
• 多くの苦痛は偶発的複雑性による。
• 真のコストは後で現れる：反復の遅さ、リスクの増大、「触るな」領域の発生。

チームへの実践的な問い

「どちらが正しいか？」と問う代わりに、こう問ってください：今四半期にコントロールできる複雑性はどれか？

チームは市場の変化やドメインの本質的難易度はコントロールできません。しかし、新機能が特殊ケースを増やすか、APIが呼び出し側に隠れたルールを覚えさせるか、モジュールが複雑さを漏らすかどうかはコントロールできます。

ここに実行可能な中間地帯があります：本質的複雑性を受け入れ、偶発的複雑性には容赦なく厳しくなること。

ディープモジュール：複雑性を正しく隠す方法

ディープモジュールは多くのことを行い、少ない理解しやすいインターフェースを公開します。「深さ」はモジュールが肩代わりする複雑性の大きさを表します：呼び出し側は厄介な詳細を知らなくてよく、インターフェースも強制しません。

浅いモジュールは逆です：小さなロジックをラップするだけで、パラメータや特殊フラグ、呼び出し順、あるいは「覚えておけ」のルールを通じて複雑性を外側に押し出します。

深いと浅いの実際的な比喩

レストランで考えてください。深いモジュールはキッチン：メニューから「パスタ」と頼めば仕入れや茹で時間、盛り付けを気にしなくて良い。

浅いモジュールは材料と12ステップの説明書を渡して自分の鍋を持ってこさせる「キッチン」です。仕事はまだ行われますが、顧客の肩に移っています。

層を増やすのが有効なときと有害なとき

新しい層は多くの決定を一つの明白な選択にまとめるなら有益です。

例：save(order) を公開し、内部でリトライ、シリアライズ、インデックスを処理するストレージ層は深いモジュールです。

層が嫌いなのは、名前を変えるかオプションを増やすだけのときです。もし新しい抽象が取り除くより多くの設定を導入するなら――例えば save(order, format, retries, timeout, mode, legacyMode)――それは浅い可能性が高い。コードは「整理されて見える」が、認知負荷はすべての呼び出し箇所に現れます。

浅いモジュールを見抜くチェックリスト

• APIに多くのパラメータ（特にuseCache, skipValidation, force, legacyのようなブール）がある。
• 呼び出し側が特定の順序を守らないと微妙なバグが出る（「AのあとにBを呼べ」）。
• モジュールが内部概念（ファイルパス、テーブル名、スレッドルール）をインターフェースに漏らしている。
• ほとんどの変更で多くの呼び出し-siteを触る必要がある。
• ドキュメントが警告ラベルのように読める（「XはYでない限り使うな」）。

ディープモジュールは単にコードをカプセル化するだけでなく、意思決定をカプセル化します。

認知負荷を下げるAPI設計

良いAPIとは多機能なだけではありません。人が作業中に頭の中に保持できるものです。

オースターハウトの設計レンズは、APIを思考量で評価することを促します：覚えるべきルールの数、予測すべき例外の数、間違ったことをしてしまう容易さ。

人間に優しいAPIの特徴

人間に優しいAPIは小さく、一貫していて、誤用しにくいことが多いです。

小さいことは乏しいことを意味しません—表面積が少数の組み合わせ可能な概念に集中していることを意味します。一貫性はシステム全体で同じパターン（パラメータ、エラーハンドリング、命名、戻り値）で動くことを意味します。誤用しにくいとは、安全な経路へ導くこと：境界での検証、早期に失敗する型や実行時チェックなど。

「オプションが増えるとコストが上がる」理由

追加されるフラグやモード、「念のため」の設定はすべてユーザーに対する税です。たとえ5%の呼び出し側だけが必要としても、100%の呼び出し側がそれの存在を学び、必要かどうか迷い、他のオプションとどう相互作用するかを考える必要があります。

APIが隠れた複雑性を蓄積するのは、単一の呼び出しではなくその組合せの指数性です。

デフォルト、慣習、命名の重要性

デフォルトは親切です：大多数の呼び出し側が意思決定を省略しても合理的な振る舞いを得られます。慣習（一つの明白なやり方）はユーザーの頭の中の分岐を減らします。命名も実作業を助けます：意図に合った動詞と名詞を選び、類似操作は類似命名にする。

もう一つの注意点：内部APIは公開APIと同じくらい重要です。製品の複雑性の大部分は裏側にあります—サービス境界、共有ライブラリ、ヘルパーモジュール。これらのインターフェースを製品として扱い、レビューとバージョニングの規律を適用してください（参照：/blog/deep-modules）。

複雑性が忍び込む場所：戦術的修正と特殊ケース

複雑性は一度にやってくることは稀です。締め切り圧力の下で正当なように見える小さなパッチが蓄積していきます。

典型的な罠

ひとつの罠は機能フラグの氾濫です。フラグはロールアウトに有用ですが残ると各フラグが可能な振る舞いの数を増やします。エンジニアは「システム」についてではなく「フラグAがオンでユーザーがセグメントBのとき以外のシステム」について考え始めます。

もうひとつは特殊ケースロジック："エンタープライズ顧客はXが必要"、"地域Yの場合は例外"、"アカウント作成から90日以上経過していると除外"。これらはコードベースに散らばり、数ヶ月後にはどれがまだ必要か誰も把握していないことが多い。

三つ目は漏れる抽象です。APIが呼び出し側に内部詳細（タイミング、ストレージ形式、キャッシュ規則）を理解させると複雑性は外側に広がります。1つのモジュールが負担する代わりに、すべての呼び出し側が扱うことになります。

戦術的と戦略的プログラミング（平易な表現）

戦術的プログラミングは今週を最優先します：迅速な修正、最小の変更、“出すこと”が目的。

戦略的プログラミングは来年を最優先します：同じ種類のバグを防ぎ将来の作業を減らす小さな再設計。

危険なのは「メンテナンス利息」です。迅速な回避策は今は安く感じますが、利息を支払う羽目になります：オンボーディングの遅れ、壊れやすいリリース、誰も触りたがらない古いコード。

実際に役立つガードレール

コードレビューに軽い問いを追加してください：「これ新しい特殊ケースを追加していないか？」「APIはこの詳細を隠せるか？」「ここに残す複雑性は何か？」
重要なトレードオフは短い決定記録に残す（数行で十分）。そして各スプリントに小さなリファクタ予算を確保して、戦略的修正が課外活動扱いにならないようにします。

複雑性はコードベースだけでなく製品を殺す理由

複雑性はエンジニアリングに閉じたものではありません。スケジュール、信頼性、顧客の体験に漏れ出します。

製品レベルのコスト：速度、安定性、オンボーディング

システムの理解が難しいとすべての変更に時間がかかります。リリースはより多くの調整、より多くの回帰テスト、「念のため」レビューを必要とし、タイム・トゥ・マーケットが遅れます。

信頼性も損なわれます。複雑なシステムは誰も完全に予測できない相互作用を生み、バグはエッジケースとして現れます：クーポン、保存済みカート、地域税ルールが特定の組み合わせになったときだけチェックアウトが失敗する、など。こうしたインシデントは再現が難しく修正も遅くなりがちです。

オンボーディングは目に見えない重荷になります。新メンバーは有益なメンタルモデルを構築できず、リスクのある領域には触れず、理解しないままパターンをコピーしてさらに複雑性を増やします。

顧客の混乱として現れる複雑性

顧客は振る舞いが「特殊ケース」由来かどうかを気にしません。彼らには一貫性のなさとして届きます：設定がすべてに適用されない、到達経路でフローが変わる、機能が「大抵動くがときどき動かない」。信頼が低下し、離脱が増え、採用が停滞します。

サポートと運用への税

サポートは長いチケットと往復により複雑性を支払い、運用はアラートやランブック、慎重なデプロイで支払います。すべての例外は監視・文書化・説明が必要になります。

実例：もう一つの機能追加 vs フローの単純化

「もう一つ通知ルールを追加してほしい」という要望を想像してください。追加は迅速に思えますが、振る舞いの分岐を増やし、UIコピー、テストケース、ユーザーの誤設定の可能性を増やします。

一方で既存の通知フローを単純化することは：ルールタイプを減らし、明確なデフォルトを設け、Webとモバイルで一貫した振る舞いにすること。ノブは少なくなりますが驚きが減り、製品は使いやすく、サポートしやすく、進化が速くなります。

複雑性を第一級の製品制約として管理する方法

複雑性を性能やセキュリティと同様に計画し、測り、保護してください。複雑性が出荷の遅延で初めて見えるなら、すでに利子を払っています。

ロードマップに「複雑性予算」を置く

機能スコープと並んで、リリースが導入できる新たな複雑性の量を定義します。予算は単純で良い：「新しい概念を追加するなら必ず一つ削る」や「新しい統合は古い経路を置き換えること」など。

計画時にトレードオフを明示してください：ある機能が3つの新しい設定モードと2つの例外を必要とするなら、既存概念に収まる機能よりも"コスト"を高く設定するべきです。

チームが実際に維持できる軽量メトリクスを使う

完璧な数値は不要です—方向性を示すシグナルがあれば良い：

• モジュール表面積：公開メソッド/エンドポイント、フラグ、設定フィールドの数。
• 概念数：ユーザー（または新しいエンジニア）が成功するために学ぶ必要があるアイデアの数。
• 変更失敗率：デプロイやリリースがロールバック、ホットフィックス、緊急対応を必要とした頻度。

これらをリリース毎に追い、決定に結び付けます：「公開オプションを2つ増やした；代わりに何を削除または簡素化したか？」

単に実現可能性を見るのではなく、単純さを試すためにプロトタイプする

プロトタイプを「作れるか？」だけで評価するのはやめてください。代わりに「使っていて単純に感じ、誤用しにくいか？」を答えさせてください。

機能に詳しくない人に現実的なタスクをプロトタイプで試してもらい、成功までの時間、尋ねた質問、誤った仮定を測ります。そこが複雑性のホットスポットです。

この点で現代のビルドワークフローは偶発的複雑性を減らすのに役立ちます—ただし繰り返しが短くミスを元に戻しやすいことが前提です。たとえばチームが Koder.ai のようなビブコーディングプラットフォームを使ってチャット経由で社内ツールや新しいフローをスケッチする場合、planning mode（意図を明確にする）や snapshots/rollback（危険な変更を素早く元に戻す）といった機能は初期の実験を安全に感じさせます。プロトタイプが本採用されるなら、ソースコードをエクスポートしてここで述べたディープモジュールやAPIの規律を適用できます。

複雑性クリーンアップをスケジュールし、成功基準を明確にする

「複雑性の掃除」を定期化（四半期ごと、またはメジャーリリースごと）し、「完了」の意味を定義します：

• オプションや特殊ケースを実際に削除する（単なるリファクタではなく）。
• オンボーディング手順や必須設定を減らす。
• 二つの重複するAPIを一つにまとめる。
• 対象領域の変更失敗率を低下させる。

目的は抽象的な「きれいなコード」ではなく、概念数の減少、例外の減少、安全に変更できることです。

チームが今四半期実行できる実践的な取り組み

Ousterhoutの「複雑性が敵である」という考えを週間単位の習慣に落とし込むためのいくつかの動きです。

5〜7の要点

• 複雑性をコストセンターとして扱う：ユーザーに価値をもたらさないなら予算承認が必要。
• 漏れやすい薄い層よりも少数で深いモジュールを優先する。
• 自明で説明不要なインターフェースを目指す：良い命名、小さな表面積、明確な不変条件。
• 「ただオプションを追加するな」：オプションは相互作用を増やし、特殊ケースは時間とともに蓄積する。
• 修正に呼び出し側の知識が必要なら、複雑性を外側に移した可能性が高い。
• 削除を成功指標にする：コードやケースを減らすことが最も効果の高い設計作業になることが多い。

1〜2週間の短いアクションプラン

混乱を引き起こしているサブシステムを一つ選んでください（オンボーディングの痛み、繰り返すバグ、「これはどう動く？」質問が多い箇所）。

1. インターフェースをマップする：公開関数/エンドポイント/設定フラグと呼び出し側が知るべきことを列挙する。
2. 契約を簡素化する：パラメータを統合し、「モード」フラグを減らし、モジュールが保証する2〜3の不変条件を書き下す。
3. 特殊ケースを削除する：ある顧客のためだけ、ある環境のためだけ、過去のバグのために追加された分岐を除去し、一般ルールで置き換える。
4. 軽いゲートを追加する：新しいフラグや例外は短い設計メモを要し、レビュー担当者が「特殊ケースを避けられないか？」と問えるようにする。

さらなる読書とフォローアップ

• John Ousterhout, "A Philosophy of Software Design"
• Fred Brooks, "No Silver Bullet"
• Fred Brooks, "The Mythical Man-Month"（特に概念的一貫性について）

内部フォローとしては、計画時の「複雑性レビュー」(/blog/complexity-review) やツール群が偶発的複雑性を減らしているかを素早くチェックする（/pricing）などが考えられます。

最後に一つ問いかけ：今週、もし一つだけ特殊ケースを削除できるとしたら、あなたは何を最初に削りますか？