# エレガンス(システム設計) ## 定義 **エレガンス(elegance)**とは、システムがシンプルかつ効率的であることを指す、過小評価されがちな正当なシステム要件である。Larry Petersonは、Niklaus Wirthの「システムとはシンプルかつ効率的で『エレガント』であるべき」という絶対的な哲学、すなわち機能とオーバーヘッドの双方を削減することへの強硬な主張を出発点に、エレガンスを機能性や性能と並ぶ独立した設計要件として位置づける。エレガンスと**シンプルさ(simplicity)**は密接に関係するが同一ではない。シンプルさは達成に多大な努力を要し、その真価を理解するには教育を要する美徳であり(Edsger Dijkstraの言葉を引く)、エレガンスはそのシンプルさに加えて効率性・機能性の適切なバランスを含む、より包括的な設計上の質を指す。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] §4.3, §4.4) エレガンスの本質は、何を実現するかではなく**何を思い切って後回しにするか**の判断に宿る。インターネットの砂時計モデルにおけるIPの「細いくびれ」が好例で、IPの設計はグローバルなアドレッシングとルーティング方式の定義という一つの課題だけを解決し、信頼性のある配送・セキュリティ・モビリティ・QoSなど本来対処し得た多くの課題を思い切って後回しにした。これにより他者がイノベーションを起こしインターネットの未来における地位を確立するための広大な余地が残された。この設計原則は遅延バインディングの考え方に着想を得ており、まず最小限だが汎用の枠組みを作り、個々のユースケースのための詳細は誰もが要件をよく理解できるようになってから埋める、というアプローチを取る。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] §4.4) ## エレガンスとシンプルさの関係 エレガンスとシンプルさは相互に強化し合うが、両者ともに実現には多大な労力と優れた判断力の双方を要する。Dijkstraは「シンプルさは偉大な美徳だが、その達成には多大な努力を要し、その真価を理解するには教育を必要とする。さらに始末が悪いことに、複雑なものほどよく売れる」と述べた。この真理は個々のプログラムや数学の証明、あるいはエッセイと同様に、インターネットのような大規模システムにもそのまま当てはまる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] §4.4) 「シンプルさ」という考え方は理論上は過激なものではなく、KISS(Keep It Simple, Stupid)の原則やセカンドシステム症候群という格言はソフトウェア開発者に広く知られている。だが実践となると自制が効かなくなる。システム設計が順調に進み始めるとかえって「もっと難しくしてみよう」と口にしたがる傾向が、システム設計者には内在する。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] §4.3) 複雑さが単純に悪であり排除すべきものだ、というほど単純な話でもない。設計者は「複雑さの保存則」に直面する。複雑なシステムをより小さな構成要素に分解し、それに伴って細切れになった複雑さをあちこちに移動させることはできるが、複雑さそのものが消滅するわけではなく、扱いやすくなるだけである。したがってエレガンスが問うべきは複雑さの排除ではなく、複雑さをいかに管理するかであり、これがシステムズアプローチそのものだとされる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] §4.3) ## エレガンスを損なう複雑性の発生源 Larry Peterson は、システム設計にやたらに複雑さが忍び寄る発生源を次のように挙げる。(1) 巧妙さで評価されがちなアカデミックの研究者、(2) 最適化の機会に飛びつき定量化しにくいコストを考慮せずに定量化しやすい成果を出そうとする性分、(3) やたらに要件を詰め込み過剰な制約を課す政府や国際機関の野心的プロジェクト、(4) 売上のために既存のエレガントな製品に新機能を追加するという安易な道を取る製品開発チーム。John Mashey の言葉を借りれば「我々が遭遇した敵は、他ならぬ我々自身である」。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] §4.3) 失敗例として、プログラミング言語 PL/I(「FORTRAN、ALGOL、COBOLという異なる三つのプログラミング言語のパワーを結集させる」ことを目標に設計)と Ada(当時のDoDで使用されていた450以上のプログラミング言語すべてに取って代わるという要求を満たすために作られた)が挙げられる。両者はセカンドシステム症候群(シンプルでエレガントなシステムの後継が過剰設計で肥大化する現象)の典型例だが、要件の詰め込みすぎは「初代」のシステムでもよく起こるとされる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] §4.3) 成功例として ARPANET のルーティングメトリック設計が挙げられる。キュー長を負荷の尺度とする初期の方式は近視眼的な誘導を招き、帯域幅とレイテンシに基づく遅延を尺度とする第二弾は高負荷時に不安定な振動を招いた。第三弾のより複雑なアルゴリズムも現実のネットワークには複雑すぎることが判明し、結果として「動的メトリックは不安定すぎる」が定説となり、今日では静的メトリックが標準となっている。この事例は「システムは可能な限りシンプルであるべきだが、シンプルすぎてもいけない」(一般にアインシュタインの言葉として知られる)という原則を裏付けると同時に、適切なシンプルさの水準を見極めるには経験が必要であることを教える。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] §4.3) ## 横断的知見 (このconceptは第4章のみを起点として立ち上げたため、複数ソースの突き合わせによる横断的知見はまだない。本書後続章、および[[抽象化(ソフトウェア設計)]]・[[性能を意識した設計]]など既存conceptとの突き合わせは、それぞれの側のページで先行して記録した。今後の ingest でこのページ自体にも複数ソース間の知見を蓄積していく。) ## 未解決の問い - エレガンスは「シンプルさ+効率性+機能性のバランス」という複合的な質として語られるが、この3要素の間にトレードオフが生じた場合(例: シンプルさを保つために機能を削るか、機能を保つために複雑さを許容するか)、どちらを優先すべきかの一般的な判断基準は本章では与えられていない。[[トレードオフ意思決定]] の枠組みで定式化できるか。 - 「複雑さの保存則」(複雑さは移動できても消滅しない)は、[[抽象化(ソフトウェア設計)]] が論じる「偽の抽象(重要な細部を誤って隠す失敗)」とどう関係するか。抽象化による複雑さの隠蔽は複雑さの保存則に反しないのか、それとも隠蔽先(実装の内部)への複雑さの移動として整合するのか。 - ARPANETのルーティングメトリックの事例は「当時は動的メトリックが必要不可欠だという前提を覆す必要があった」と述べるが、こうした「前提を覆す」判断はどのようにして可能になったのか(単なる試行錯誤か、特定の分析的な洞察があったのか)は本章では詳述されていない。 - Wirthの「無慈悲なまでに」機能を削ぎ落とす姿勢と、ステークホルダーの多様な要求を天秤にかける[[トレードオフ意思決定]]的な判断は、実務上どう両立するのか。機能を求めるステークホルダーの要求を強硬に拒絶することと、要求を天秤にかけてバランスを取ることは緊張関係にあるように見える。 ## 関連 - 概念: [[システムズアプローチ]](複雑さの管理という観点での接続) / [[抽象化(ソフトウェア設計)]](省略・抽象化とエレガンスの関係) / [[性能を意識した設計]](オーバーヘッド削減という観点での接続) / [[トレードオフ意思決定]](ステークホルダー間のバランスという観点) / [[通常設計と急進的設計]](GENIの制約過剰な設計空間という事例の共有) / [[設計要件の確立]](GENIの要件・テンション明文化という事例の共有) / [[最終目標なき設計]](GENIの先送り判断と将来への代替案温存という接続) / [[設計の一貫性]](複雑性を下げる設計上の質としての並置。突き合わせは未検討) - 実体: [[Niklaus Wirth]] / [[Edsger W. Dijkstra]] / [[David D. Clark]] / [[Larry Peterson]] / [[Bruce Davie]] - ソース: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] - 書籍: [[ネットワークシステムについて語るときに我々の語ること]] ## 出典 - Larry Peterson・Bruce Davie 著, 進藤資訓 訳, 『ネットワークシステムについて語るときに我々の語ること』, ラムダノート, 2026, 第4章 §4.3「エレガンス:過小評価されているシステム要件」, §4.4「エレガンスとシンプルさについてのさらなる考察」.