# システムズアプローチ ## 定義 システムズアプローチ(systems approach)とは、計算機システムを設計・実装・記述するための方法論であり、単一の要素に執着する(不必要に最適化したり一つの要素だけであまりに多くの問題を解こうとしたりする)のではなく、システムの各構成要素が互いにどう作用し合って全体としての結果を生み出しているかという「全体像」を見ることを鍵とする。この考え方は、Larry PetersonとBruce Davieが1996年の教科書『Computer Networks: A Systems Approach』以来一貫して採用してきたネットワークの捉え方であり、実世界の実装にも強く焦点を当てる点を特徴とする。インターネットは、当初は研究室レベルの実験にすぎなかったものが今日では社会に不可欠なグローバルインフラストラクチャへと成長した、広くデプロイされた複雑なネットワークシステムの好例として位置づけられる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]] §1.1) ## 5ステップの方法論 システムズアプローチは具体的には次の一連のステップを反復することで計算機システムを進化させる。 1. 問題(あるいは新しいシステムの必要性)を定義する。これは(a)新しいユースケース/アプリケーションの特定、(b)新しい技術または技術水準の向上、という二つの組み合わせの形になることが多い。 2. 複数のステークホルダー(システムの利用者、運用者、費用負担者など)を考慮して要件を明確化する。 3. 代替の設計案をいくつか検討し、複数の選択肢から特定の実装を採用する理由を明確にする。 4. その設計の実現形についての有効性を(要件に照らして)実証的に評価する。 5. 得られた教訓を抽出する。つまり、ベストプラクティスや一般的設計原理として現場に展開する。 このステップの反復により計算機システムは反復的に進化する。タイムシェアリングのメインフレームからクライアント/サーバのLANベース分散システム、広域スケーラブルサービス、そして今日のクラウドサービスへの進化はその一例とされる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]] §1.1) ## 繰り返し現れる要件とシステムに依存しない原理原則 この方法論を実践すると、いくつかの要件が繰り返し現れる。代表例はスケーラビリティであり、ネットワークをサブネット・エリア・自律システムへ分割してルーティングシステムをスケールさせる設計や、SDNのスケーリング課題にHadoopのような分散システムの技法を取り入れる例が挙げられる。汎用性もまた共通する要件であり、インターネットが上位アプリケーションや接続デバイスの種類に依存しないように設計された点が電話網やケーブルテレビ網との決定的な違いとされる。 さらに、システムに完全には依存しない設計上の原理原則として次の6つが挙げられる。数学的な厳密さは持たない(電磁気学のマクスウェルの方程式や情報理論のシャノン=ハートレーの定理のようなものではない)が、多くのシステム設計者が従うベストプラクティスとみなされている。 - ポリシーとメカニズムの分離 - エンドツーエンド原理 - 階層的集約(情報隠蔽)によるスケーラビリティ - キャッシュによる最適化 - コントロールプレーンとデータプレーンの分離 - 抽象化の活用による複雑性の抑制 Butler Lampsonの論文 "Hints for Computer System Design" には、これら以外にもさまざまな原則が記されているとされる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]] §1.1) ## 教科書における実践と、レイヤリングとの緊張関係 『Computer Networks: A Systems Approach』の各章は、この方法論に従い問題の定義から始まる。例えば第1章では、多様なステークホルダーのニーズ・スケーリング目標・費用対効果のリソース管理を念頭に、グローバルなネットワークのための要件を導き出す。インターネットはすでに完成したシステムだが、同書はあえて現在の姿に至るまでのシステム設計の過程を読者と辿り直す構成を取り、そうした箇所の多くが「Bottom Line」という項目で強調される。 ネットワーキング教育で最も難しいテーマの一つに「レイヤリング(階層化)」の扱いがある。レイヤリングは抽象化の一形態としてシステムの設計原則に優れるが、システムを全体としてどう実装するのが最適かという思考を妨げることもある。近年、アプリケーション層のHTTPとトランスポート層のTCPの組み合わせがパフォーマンスの観点で必ずしも相性が良くないことが明らかになり、両者を「アプリケーションに信頼性・セキュリティ・性能をもたらすために必要なシステム」の一部と見ることで、トランスポート層にQUICという新しいプロトコルが登場した。この方法論はOSIの7階層モデルを絶対のものとして天下りに押し付けるのではなく、システム視点の思考が適用できる場面を判断するためのツールを読者に提供することを目指す。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]] §1.1) ## 判断としての設計プロセス(第4章) 第4章「システム設計における判断」は、5ステップの方法論そのものよりも、その各ステップの内側で働く**判断力**に焦点を当てる。システム設計は厳密な科学ではなく、アーキテクチャに関するどのような決定も正当化できてしまうが、正当化の根底には常に「何が重要で何が重要でないか」の判断がある。システムアーキテクチャを定義する作業とは、この観点からすれば異なるステークホルダーの要求を天秤にかける行為であり、これは5ステップのうち特に「(2) 複数のステークホルダーを考慮して要件を明確化する」「(3) 代替の設計案をいくつか検討し、特定の実装を採用する理由を明確にする」の内実を成す判断作業にあたる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] p.43) Larry PetersonがGENIプロジェクト(2000年代半ば、ネットワーキング研究コミュニティ向けの大規模実験基盤)で技術リードを務めた際の経験は、ステップ(2)「要件の明確化」が制約過剰な設計空間でどう行われるかを具体的に示す。計算機科学のほぼあらゆる方面から要求と制約が寄せられる状況で、報告書は11の要件・7つのテンション(要件間の衝突点)・6つのエンジニアリング原則を明文化した。重要なのは、テンション(対立)を解消する手段を報告書自体が指定するのではなく、対立の調整のための「ポリシー設定」だけを定義し、その具体的な扱いを将来の管理委員会に委ねて先送りした点である。これは、5ステップの「代替案の検討」が必ずしもその場で対立を解消する必要はなく、対立の存在を明示した上で解決を先送りするという判断もまた設計プロセスの正当な一部でありうることを示す。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] p.44、辛い試練) もう一つ、第4章が5ステップに与える層は「省略という設計行為」である。何を語り何を語らずに済ませるかという執筆上の判断(§4.2)は、システムを構築する際の要件と非要件の切り分けと直接的な関係があるとされ、これはステップ(2)の要件明確化の裏面、すなわち「何を要件から除外するか」を積極的に決める作業として位置づけられる。"Edge Cloud Operations: A Systems Approach"の執筆で著者らが即座に解決できない設計空間の難問(エッジクラウドのステークホルダー間の関係のモデル化)に直面した際、設計空間の概略を示すに留め、未解決であることを理由に他の作業を遅らせなかったという判断は、5ステップの反復性(問題定義から教訓抽出までを繰り返す)を支える実践的な態度として読める。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] §4.2) ## 境界条件としてのシステムズアプローチ(第11章) 第11章「ネットワーク管理は今やクールな仕事だ」は、システムズアプローチを設計時の判断(第4章)から運用時の判断へと拡張する。手がかりは、[[Amin Vahdat]] が ONF Connect 2018 で示したクラウドの優先順位図(マズローの欲求階層になぞらえたもの)である。この図は Google がクラウドインフラを構築する際、可用性 > 管理性 > 機能開発の迅速性 > ストランディング(効率性) > パフォーマンスという明確な序列で要件に優先順位を付けていることを示す。著者はこの図をシステムズアプローチのコンセプトを可視化するものと位置づける——「あらゆるシステムは一連の要件を満たす必要があるが、本当の課題はそれらの要件の間のトレードオフをどう図るかである」という主張を、抽象的な原則ではなく具体的な序列として提示している点が第4章の判断論との違いである。設計の一側面だけに固執すると、局所的な最適化に成功してもシステム全体としては無意味、あるいは逆効果になりかねないという教訓が、この序列から直接導かれる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.4) 第11章はさらに、要件間の「境界」をどう管理するかという運用側の問いを立てる。機能開発の迅速性と管理性という互いに競合しがちな要件の相互作用を、CDNスタートアップの事例(顧客要望の機能実装が難解な設定ファイルでオペレーターの手に負えなくなる)と、SDNの普及に伴う事例(データプレーンの新機能追加がコントロールプレーン・管理プレーンの更新を要求する)の二つで示し、いずれも明確に定義された管理APIの必要性という同じ課題に帰着すると論じる。ここで著者は「管理機能そのものが一つのプラットフォームとして機能し得る」と主張し、Istio のようなサービスメッシュをその実例に挙げる。第4章がシステム設計における判断(何を要件から除外するかを含む)を論じたのに対し、第11章は要件が確立された後にその境界線上で生じる摩擦をどう扱うか(制御と監視のための専用プラットフォームを構築する)という、システムズアプローチの運用フェーズへの適用を示す。(Source: ch.11 §11.4) ## 横断的知見 > [!contradiction] 「最新版の序文から定義を削除した」という記述と、第6版(2020年10月)Preface に現存する定義との食い違い > 『ネットワークシステムについて語るときに我々の語ること』第1章および book entity [[Computer Networks - A Systems Approach]] は、「著者らはSystems Approachという表現の定義を不要と考え、最新版の序文から削除してしまっていた。この欠落がHacker Newsでの誤解(Systems and Cyberneticsとの混同、『中身のない飾り文句』という評)を招いた」と記す(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]] §1.1)。しかし [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Preface]] として今回 ingest した第6版 Preface(2020年10月付、book.systemsapproach.org/preface.html)には、`## What is "A Systems Approach"?` という節が現に存在し、「big picture」視点・構成要素間の相互作用・輻輳制御を独立章として扱う判断などを含む定義がそのまま書かれている(Source: ch.0 Preface, What is "A Systems Approach"?)。したがって、少なくとも 2020年10月時点で公開された第6版 Preface の版には定義が残っていたことになる。考えられる説明はいくつかある——(a) LambdaNote 版が言う「最新版」とは 2020年10月版よりも後に web 上で改訂された Preface(本書は `book.systemsapproach.org` 上で継続的に更新される web 版であり、`.raw/` 原本注記によれば版表記は Version 6.2-dev)を指しており、Hacker News での議論(2021年3月時点、Bruce Davie のニュースレター記事の日付から推定)より後のどこかの時点で当該節が一時的に削除され、今回 ingest した原本はそれより前(2020年10月)または削除後に定義が復元された版のいずれかを捉えている、(b) LambdaNote 版の記述自体が事実関係を単純化・誤認している、のいずれかだが、**本 ingest の原本だけからはどちらか判定できない**。判定には book.systemsapproach.org の Preface ページの版履歴(GitHub リポジトリ https://github.com/SystemsApproach/book のコミット履歴)を separately に確認する必要がある。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Preface]], [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]] §1.1) - **第11章のクラウド優先順位図(可用性>管理性>機能開発の迅速性>ストランディング>パフォーマンス)は、第1章の5ステップ方法論とシステムズアプローチの未解決の問い「先送りの正当化条件」に、具体的な優先順位という形で部分的な回答を与える**: [[システムズアプローチ]] concept の既存の「未解決の問い」は、GENIの事例(第4章)が示す「対立の解消そのものを先送りする判断がいつ正当化されるか」という一般化の欠如を指摘していた。第11章のクラウド優先順位図は、この問いに一般則ではなく事例による回答を与える——可用性が確立されない限り管理性の改善は導入されず、管理性が確立されない限り機能開発の迅速性は追求されない、という明確な序列を示すことで、「どの要件間のトレードオフを先送りしてよいか」を序列の上位から下位への一方向の依存関係として構造化する。ただしこの序列はGoogleのクラウドインフラという特定の文脈に基づくものであり、第4章のGENIの事例のような「対立の解消を先送りする」判断とは異なる種類の解——序列自体を固定することで対立の発生源を事前に減らす解——である点には注意が要る。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]] §1.1, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] p.44, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.4) - **第4章が示す「省略という設計行為」(要件の除外)と、第11章が示す「境界の管理」(確立済み要件間の摩擦の扱い)は、システムズアプローチのステップ(2)「要件の明確化」を時間軸上の異なる局面に位置づける**: 第4章§4.2は、何を要件から除外するかを積極的に決める設計時の判断として省略を扱う(既出の横断的知見)。第11章はこれとは異なる局面——要件がいったん確立され優先順位が付けられた後に、要件間の境界(例えば管理性と機能開発の迅速性の境界)で生じる継続的な摩擦をどう運用管理するか——を扱う。前者は要件明確化の「入口」(何を要件に含めるか)における判断、後者は要件明確化の「運用」局面(含めた要件同士がどう相互作用し続けるか)における判断であり、両者を合わせるとステップ(2)が設計時の一度きりの決定ではなく、システムのライフサイクル全体を通じて継続する作業であることが見える。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] §4.2, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.4) - **第1章が投げかけた「セカンドシステム症候群は5ステップのどの段階の失敗か」という問いに、第4章は「特定の段階に固有の失敗ではない」という答えを与える**。第4章§4.3は、シンプルでエレガントなシステムの後継が過剰設計で肥大化する現象(セカンドシステム症候群)の例としてPL/IとAdaを挙げるが、同時に「要件の詰め込みすぎはセカンドシステム症候群の典型だが、実は『初代』のシステムでもよく起こる」と明言する。これは、要件の詰め込みすぎという失敗が5ステップの特定ステップ(たとえば「代替案の検討」)に固有の欠陥ではなく、システムが何世代目であるかを問わず、ステークホルダーの要求を天秤にかける判断力そのものが失敗しうる、という一般的な脆弱性であることを示す。第1章の5ステップ方法論は失敗を防ぐ手順を与えるが、各ステップをどれだけ誠実に、どれだけの経験を持って実行するかという判断の質までは保証しないことが、第4章によって明らかになる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]] §1.1, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] §4.3) - **第1章が挙げる「システムに依存しない6原理」のうち「抽象化の活用による複雑性の抑制」は、第4章では「省略」という執筆行為の言葉で具体化される**。第1章はこの原理を原則の一覧として提示するにとどまるが、第4章§4.2は「重要な概念と、省略しても問題ない詳細との境界線をどこに引くかを判断することは、うまい抽象化の定義と明らかに類似している」と述べ、抽象化を「何を書き何を書かないかの判断」という具体的な行為として再定式化する。両章を合わせると、抽象化の活用というシステムズアプローチの原理は、単なる技術的な階層化の技法ではなく、設計者が文書化や説明を通じて絶えず実践する判断のスキルであることが見える。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]] §1.1, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] §4.2) - **第6版第1章は、LambdaNote版第1章が抽象的に述べる5ステップ方法論のうちステップ(1)問題定義とステップ(2)要件明確化を、教科書自体の章構成として具体的に体現する**: LambdaNote版第1章は「問題を定義する→複数のステークホルダーを考慮して要件を明確化する→代替の設計案を検討する」という手順を方法論として抽象的に提示するが、英語版第6版 Chapter 1 Foundation は Problem: Building a Network 節で「地球規模まで成長しうるネットワークを構築する」という問題をまず立て(ステップ1)、続く §1.2 Requirements でアプリケーションプログラマ・ネットワークオペレータ・ネットワーク設計者という3ステークホルダーの視点から要件を列挙し(ステップ2)、その要件をもとに §1.3 Architecture でレイヤ化・プロトコルグラフ・砂時計モデルという設計原理へ進む(ステップ3の入口)という構成を実際に取る。両者を並べると、LambdaNote版が抽象化して述べた手順が、原著教科書の章立てそのものにどう写像されているかが確認できる。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 1 Foundation]] §1.2, §1.3, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]] §1.1) - **第6版第1章 §1.3.1・§1.3.5 は、レイヤリングを絶対視しないというLambdaNote版の指摘の教科書本文上の裏付けを与える**: LambdaNote版第1章は「レイヤリングは抽象化の一形態としてシステムの設計原則に優れるが、システムを全体としてどう実装するのが最適かという思考を妨げることもある」と論じ、HTTP/TCPの組み合わせがQUICという新しいレイヤ構成を生んだ例でこの緊張を説明する。第6版第1章はこれと同じ緊張を教科書の入門段階からすでに明示している——§1.3.1は「システムを線形なレイヤの並びと考えるのは単純化しすぎである」と述べ、同一レイヤに request/reply と message stream という異なる抽象が並存する例(図9)を示し、§1.3.5はインターネットアーキテクチャが「厳密なレイヤ化を強制しない」(アプリケーションがトランスポート層を飛び越えてIPを直接使ってよい)という特徴を持つと明記する。QUICのような設計判断を後に生む土壌が、教科書の第1章の時点ですでに用意されていたことが分かる。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 1 Foundation]] §1.3.1, §1.3.5, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]] §1.1) - **同じ Systems Approach シリーズの2冊が、書籍全体の編成軸として「層」と「スタック」という異なる選択をしている**: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Preface]] は Organization 節で、書籍全体を概念・基礎的な内容/中核となるプロトコルとアルゴリズム/発展的な内容という3層に分類し、この分類を章単位(第1章は基礎、第2・3・5・9章は中核、第4・6・7・8章は発展的)にも節単位にも当てはめる。この構成は個々の章の内部では「システムズアプローチ」を体現しつつ(例えば輻輳制御を独立章として扱いレイヤに押し込めない、本ページ既出の横断的知見を参照)、書籍全体のテーブル・オブ・コンテンツ自体は伝統的なプロトコルスタックの層をなぞる形で組まれている。これに対し [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Preface]] は、「プロトコルスタック(7層であれ3層であれ)がネットワークの考え方そのものを形作り制約してきた」「教科書もそれに沿って構成されてきた」と明示的に述べたうえで、SDN が提示する新しい**ソフトウェアスタック**に沿って書籍全体を構成するという方針を打ち出す。すなわち、CN 本は個別の話題ではレイヤを越境する判断を許容しながらも書籍のマクロな骨格としては層構造を採用するのに対し、SDN 本はマクロな骨格そのものをプロトコル層からソフトウェアスタックへ置き換える、という一段踏み込んだ選択をしている。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Preface]] ch.0 Preface, Organization, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Preface]]) - **本ページ既出の「教科書における実践と、レイヤリングとの緊張関係」節が抽象的に述べる緊張は、SDN 本の Preface によって書籍設計レベルでの具体的な解決策として先取りされている**: 既出の横断的知見は、LambdaNote 版第1章がレイヤリングを「抽象化の一形態としてシステムの設計原則に優れるが、システムを全体としてどう実装するのが最適かという思考を妨げることもある」と評し、その緊張の実例としてQUIC(HTTP/TCPの組み合わせの問題を機にトランスポート層を再設計)を挙げていた点を記録している。SDN 本の Preface はこの緊張を個々の技術判断としてではなく書籍の構成原理として扱い、「ソフトウェアスタックが実在し完全であることを読者自身が確かめる」ためのハンズオン演習を巻末に配置することで、レイヤ中心の教育がもたらしうる「魔法やプロプライエタリなコードでしか埋まらない空白」という不透明さそのものを解消しようとする。QUIC の例が個別技術のレベルでレイヤ越境の必要性を示したのに対し、SDN 本は書籍という媒体のレベルでレイヤ思考からの脱却を図る点が異なる。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]] §1.1, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Preface]]) ## 未解決の問い - 第6版第1章 §1.2.1 は3ステークホルダー(アプリケーションプログラマ・ネットワークオペレータ・ネットワーク設計者)を要件導出の起点とするが、LambdaNote版第4章が示す「判断としての設計プロセス」(ステークホルダー間の要求を天秤にかける)との対応——3者の要件がどう重み付けされ緊張が解消されるか——は英語版第1章の記述だけでは分からない。両版をさらに突き合わせる余地がある。 - 5ステップの反復方法論(問題定義→要件明確化→代替案検討→実証的評価→教訓抽出)は、Herbert Simonの[[設計の科学]]が示す設計手続き(満足化、生成器-検定サイクルなど)とどこまで対応するか。両者の概念装置をシステムズアプローチの語彙に対応付ける比較が必要。 - システムに依存しない6原理(ポリシーとメカニズムの分離、エンドツーエンド原理など)は、[[工学設計知識]]が示す「基本設計概念(fundamental design concepts)」というカテゴリや、[[技術的規則]]が示す「効力(efficacy)で正当化される命題」という規則の定義とどう位置づけられるか。 - 本書はシステムズアプローチを「教えられるもの」ではなく「時間が経つと自然と身についていく」ものだと述べる。この暗黙知的な性格は、[[通常設計と急進的設計]]が論じる通常設計(既知の枠組みの中での改良)と急進的設計(動作原理すら定まらない探索)のどちらの局面でより強く働くのか。 - Hacker Newsでの誤解は、システムズアプローチと「Systems and Cybernetics」([[サイバネティクス]])との混同として起きた。両者の実際の異同(方法論としての性格の違い)は本章では検討されておらず、後続の ingest で確認が必要。 - 第4章は「省略という設計行為」を要件明確化の裏面として提示するが、どこまで省略してよいか(重要な要件を誤って除外してしまう失敗)を防ぐ具体的な手続きは示していない。この境界判断は5ステップのどのステップに位置づけられるべきか、あるいは新たなステップとして明示すべきか。 - GENIの事例は、代替案の検討(ステップ3)において対立の解消そのものを先送りするという判断が正当化された例だが、こうした先送りが正当化される条件(いつ解決すべきで、いつ先送りしてよいか)は本書内でまだ一般化されていない。第11章のクラウド優先順位図はこれに部分的な回答(序列の固定による事前の対立回避)を与えるが、序列そのものをどう決定すべきかという一段上の問いは未解決のまま残る。 - 第11章が示す「管理機能そのものが一つのプラットフォームとして機能し得る」(サービスメッシュを実例とする)という発想は、システムズアプローチの5ステップのどこに位置づけられるべきか。新しい要件の発見(ステップ1)なのか、既存要件間の境界を管理する新たな設計対象の追加(ステップ3の派生)なのか、本書はこの分類を明示しない。 - 「最新版の序文から定義を削除した」(LambdaNote版)という記述と、2020年10月付の第6版 Preface に定義が現存するという事実(本ページ横断的知見の contradiction 参照)は、いつどの版で定義が削除・復元されたのかという版history上の問いを残す。book.systemsapproach.org の Preface ページないし GitHub リポジトリ SystemsApproach/book のコミット履歴を確認しないと解消できない。 - SDN 本の Preface は「ソフトウェアスタック」という語を書籍の編成原理として提示するが、その具体的な段(ハードウェア→スイッチOS→ネットワークOS→アプリケーションといった構成になるのか)は Preface 単体からは分からない。第1〜10章を ingest したのちに、CN 本の3層分類(基礎/中核/発展的)とSDN本のソフトウェアスタックの各段が、記述する対象として実質的にどこまで重なりどこまで異なるのか(単なる呼び方の違いか、扱う技術層そのものが異なるのか)を突き合わせる必要がある。 ## 関連 - 概念: [[設計の科学]](Herbert Simonによる設計方法論との比較対象) / [[工学設計知識]](工学者の設計知識の分類との比較対象) / [[通常設計と急進的設計]](通常設計/急進的設計の区分との関係) / [[技術的規則]](効力本位の規則という工学知識観との関係) / [[サイバネティクス]](Hacker Newsでの誤解の対象) / [[エレガンス(システム設計)]](複雑さの管理という観点での接続) / [[トレードオフ意思決定]](ステークホルダーの要求を天秤にかける判断という観点) / [[GitOps]](運用フェーズでの信頼できる唯一の情報源という具体化) / [[オブザーバビリティ]](管理性の一要素としての位置づけ) - 実体: [[Larry Peterson]] / [[Bruce Davie]] / [[Computer Networks - A Systems Approach]] / [[Software-Defined Networks - A Systems Approach]] / [[Amin Vahdat]] / [[Istio]] - ソース: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 1 イントロダクション]] / [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 4 システム設計における判断]] / [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] / [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Preface]] / [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 1 Foundation]] / [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Preface]] - 書籍: [[ネットワークシステムについて語るときに我々の語ること]] / [[Computer Networks - A Systems Approach]] / [[Software-Defined Networks - A Systems Approach]] ## 出典 - Larry Peterson・Bruce Davie 著, 進藤資訓 訳, 『ネットワークシステムについて語るときに我々の語ること』, ラムダノート, 2026, 第1章 §1.1「システムズアプローチの定義」, 第11章 §11.4「境界条件：システムズアプローチ」. - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Preface. https://sdn.systemsapproach.org/preface.html