― 複雑な世界の「境界」について
私たちは、何かを良くしようとするとき、つい「全体を理解してから設計しよう」と考えます。
会社なら組織を、プロダクトなら機能を、ソフトウェアならアーキテクチャを。できるだけ多くの要素を把握し、矛盾なく組み立てれば、よりよい結果に近づけるように思えます。
しかし、対象が複雑になるほど、この考え方はうまくいかなくなります。
人が増えれば組織は変わる。利用者が増えればプロダクトの使われ方も変わる。外部サービスに接続すれば、自分では制御できない事情が入り込んでくる。自然や社会を相手にすれば、なおさらです。
では、すべてを見通すことのできない世界で、私たちは何を設計できるのでしょうか。
わたしは最近、その答えのひとつが「境界」にあるのではないかと考えています。システム思考は、次のような視点でアプローチします。
- 個々の要素だけを見るのではなく、その間にある関係を見る
- 一方向の原因と結果だけでなく、フィードバックのループを見る
- 一時点だけでなく、時間の中で変化する構造を見る
- システム全体に良い影響を与えられるレバレッジ・ポイントを探す
生物も、組織も、人間関係も、社会も、国家も、そしてデジタル社会も、境界を持ちながら他者と関係しています。AIの活用でもソフトウェア開発でも、システムを全体としてとらえるとともに、意図した波及効果をシステム全体にもたらすレバレッジ・ポイントを見極めることが重要です。
AIが一定の領域で高い能力を発揮するようになった現在、人間の役割の重心は、領域そのものを定めることや、異なる領域をつなぐことへ移りつつあるように思います。
今回は「領域」と「境界」にフォーカスし、そこから表出する「依存」と「自律」について考えていきましょう。
システムの境界はどこにあるのか
以前、「生物多様性とシステム思考」という記事で、ニホンヤマネの保護活動を例として、絶滅が危惧される野生動物の生態から森林へ、森林から人間の活動へ、さらに産業や政策、地域社会とのつながりなど、システム思考のアプローチで部分最適と全体最適のバランスを考察しました。
森林が失われる理由を探しても、単純な解決策は見つかりません。林業の衰退、エネルギー政策、土地利用、地域経済、人口減少、野生生物の生態、人間の価値観。さまざまな要素が互いに影響し、ある変化が別の変化を引き起こし、その結果がまた最初の要素へ戻ってきます。
森を一つのシステムとして考えれば、個々の樹木があり、土壌があり、微生物がいて、昆虫や鳥や哺乳類がいます。ここまでなら生態系としてのシステムを設定しています。
しかし森林の状態には、人間の活動も大きく影響します。林業があり、道路があり、観光もあり、土地の所有者、法的規制、自治体の政策も関係してきます。太陽光発電施設があり、木材価格やエネルギー政策、国際貿易、人口動態まで関係してきます。
どこまでを「森林というシステム」に含めるか。境界をどこに置くかによって、同じ森林でも見えてくる問題はまったく違います。
例えば、
森林 → 樹木 → 野生動物だけを見るのと、
森林
├ 生態系
├ 林業
├ 観光
├ 土地所有
├ エネルギー
├ 地域経済
└ 行政まで含めて見るのとでは、解決策も変わります。
ここで重要なのは、現実の世界に「ここからここまでが一つのシステムです」という線が最初から引かれているわけではない、ということです。特に近年はこうした境界がダイナミックに変動しています。既存の枠組みにとらわれず、越境することが、イノベーションにつながっていきます。
従来の枠組みを超え、問題を理解するためにある範囲を切り出して「システム」を考えることが、重要です。つまり、システムを考えることは、同時に境界を考えることでもあります。
ドメインを決める
世界は、ほとんど無限につながっていて、地域の森について考え始めても、世界規模での気候変動、土地利用、エネルギー政策、世界経済、国際的な資源価格までつながっています。金融、政治、人口動態、技術革新も関係してきます。
関係を追い続ければ、世界全体に行き着き、地球全体を考慮しないとシステムを定義できなくなってしまいます。以前の記事で紹介したカナダの森林学者スザンヌ・シマードさんは、科学的な思考の限界を著書「マザーツリー」の中で次のように表現されています。
そしてまもなく私は、生態系全体の多様性とつながり合いについての論文を書くのがほぼ不可能であることを知ったのだ。対照群がないではないか！
〜中略〜
統計的有意性のある顕著な差だけを考慮する訓練などを通じ、ぐるりと一巡して先住民の人々が持っていた叡智に辿り着いたのだ
当然のことながら、地球というシステム全体に対照群を設けて実験することはできません。
システム思考においても、「今回はここまでを考える」と範囲を決め、その領域の外部との動的フローを見て、過去の経験やデータを適用しながら、介入する方法とレバレッジ・ポイントを考えていくわけです。
一般的にも、課題設定について意味のある範囲を切り出したものを、「ドメイン」として表現します。ビジネスでは「製造業のドメイン」「金融ドメインの知識」のように、専門領域や業界という意味で使われることも増えてきましたが、動的なフローとセットで語られることは少ないように思います。
システムを考える上では、その領域の外部との関係性が重要であり、
何をこの問題の内側として扱い、何を外側として扱うのかを定義した領域
です。
例えば同じ森を見ても、林業者、生態学者、行政、観光事業者では、見ているものが違います。林業者なら、樹種、材積、林齢、伐採、搬出路を見るでしょう。生態学者なら、種、個体群、植生、生態系を見るかもしれません。
行政なら、土地利用、所有関係、防災、税、地域経済という視点で見るでしょう。同じ世界を見ていても、問題として切り取っている領域が全然異なっているのです。
つまり、ドメインを設定するとは、世界の切り取り方を決めることでもあります。
そしてドメインを決めると、その中で何を対象として扱うのか、どの関係を重要と考えるのか、どんな言葉を使うのかも決まってきます。
世界 → 境界 → ドメイン → 対象・関係・ルール・意味何を自分たちのドメインとするのか。企業価値を決める上でも、競争戦略における核心をどこに定めるか。システムをどのように設計するか。こうした関係性の設計までつながっています。
AIが大量の情報を扱えるようになった現在、この「領域を設定する」という能力は、むしろ重要性を増しています。情報が少なかった時代には、知識を増やすことそのものに価値がありました。
しかし情報がほぼ無限に得られる状況では、
- 何を知るべきか。
- 何がいまの問題に関係しているのか。
- どこまで考えれば十分なのか。
という問いの方が重要になります。
4つの視点
本質的な課題というのは、古来、多くの先人が深く思考して、法則を導き出してくれています。巨人の肩に乗ることも必要です。今回は4つの考え方を紹介しながら、この命題についてわたしたちも深く考えてみましょう。
- ゲシュタルト原則
- デメテルの法則
- ゴールの法則
- ルーカス批判
今回取り上げるゲシュタルト原則、デメテルの法則、ゴールの法則、ルーカス批判はAmazon.com CTOのWerner Vogelsが2015年のAWS re:Invent基調講演の中で、「クラウドアーキテクトが知っておくべき法則」として紹介していたものです。当時、Wernerさんの講演を聞いて以来、わたしが構造を考えるときに常に意識している法則でもあります。これらは、AWSクラウドの巨大で複雑なアーキテクチャを設計する法則であると同時に、システム思考全般に活用できるものです。
全体を見る
ゲシュタルト原則：The Gestalt Principle
ゲシュタルト心理学の有名な考え方です。「全体は部分の総和より大きい」と紹介されることがありますが、より正確には、全体は単なる部分の総和とは「別のもの」である、ということです。
システムでも同じです。合成の誤謬という言葉もありますが、優れた部品を集めれば、優れたシステムになるとは限りません。
それでも、全体としてサービスが適切に機能する保証はありません。特に業務の文脈やユーザーの関心に最適化した画面構成や画面遷移が適切に設計されていなければ、使われないシステムになってしまうことも少なくありません。
小売で言えば「ラストワンフィート」、顧客が棚の前で手を伸ばし、商品を手に取るまでの最後の1フィート。どれだけ良い商品を作っても流通を整えても、ラストワンフィートで顧客の心に響かなければ購入してもらえません。システムも同じです。サーバーからネットワーク、アプリまでを設計する上で、最後に人の手と目に触れる区間で、UIの設計が破綻していれば、そのシステムは使われなくなってしまうのです。
こうしたUI/UXの問題については、過去の記事（デジタル社会のUI論）でも警鐘を鳴らしてきました。エンドユーザーのいる現場の最前線まで、全体を見て最適化することが重要です。
つながりを見る
デメテルの法則：Law of Demeter
システム思考では要素間の関係を見て、最も効果的に全体へ良い循環を波及させるレバレッジ・ポイントを見つけることを重視します。関係性は複雑に折り重なっており、すべての関係性を制御することはできないので、要点にフォーカスするのです。
人間関係に例えて考えてみましょう。ある人と話すために、その人の上司、家族、友人、取引先の事情まで知らなければならないとしたら、とても複雑になります。
組織文化によくある構造として、一つの仕事を進めるために、
という状況が増えるほど、判断も制御方法も複雑になる一方です。ソフトウェアの世界では、この問題への対処として「デメテルの法則」という設計原則があります。
別名を「最小知識の原則」と言います。簡単に言えば、直接関係する相手とだけ話しましょう。という考え方です。
AがBを通り越してCやDの内部事情まで知るようになると、CやDの変更がAにまで影響し伝わります。一つの変更が遠くまで波及するシステムになります。
逆に、それぞれが直接関係する相手と適切な境界を持てば、変更の影響を局所化できます。「知らないこと」は、必ずしも欠点ではありません。
むしろ、必要以上のことを知らなくても済むように設計されていることが、システムの強さになる場合があります。ハードでもソフトでも、モジュール化、カプセル化、部品化によって、保守性、効率性、機能性が高まる効果を担ってきました。
これは、以前のブログ（AWSクラウドに学ぶビジネス設計）でAWSの設計原則の一つとして 疎結合 を紹介したときにも書いたことですが、日本のビジネス社会において、考慮するべき重要な法則でもあります。
デメテルの法則（最小知識の原則）は一般社会の文脈で評価しても興味深いものです。わたしたちは「知ること」を基本的には良いこととして考えています。
しかし、「知ることができる」と「知る必要がある」は違います。他人について知ることのできる情報を、すべて知る必要はありません。組織のすべての内部事情を、すべての社員が把握する必要もありません。
一つのサービスを使うために、サービス提供者がユーザーについてあらゆる情報を知る必要もありません。しかし、最近のデジタルサービスを見ていると、大量の情報を収集することが当然のようになっています。
しかし本来は逆の問いも必要です。
このサービスは、この情報を本当に知る必要があるのでしょうか。
最小知識の原則は、プライバシーの観点から見ても重要な原則です。
情報を集めた後で厳重に管理することも重要ですが、そもそも必要のない情報を知らなくても成立する構造にするという選択肢があります。作業服チェーン店のワークマンは長らく「しない経営」を標榜し、会員カードを持たず、個人情報を過度に収集しない経営でも知られてきました。
標準店舗でアンケートを取ることで必要な精度を得ている、と言います。「情報を集めない」のではなく「必要十分な粒度を見極めている」わけです。まさに、最小知識の原則が有効に機能している事例と言えるでしょう。
一方で、最近のデジタルサービスは逆を向いています。広告のターゲティングのために顧客情報、顧客の行動履歴を収集し、その管理と分析に膨大なコストをかけています。本当にビジネスに必要なコアの情報は何なのか——最小知識の原則は、ここでも問いとして効いてきます。※この点は別の記事であらためて考えます。
小さく始める
ゴールの法則：Gall’s Law
複雑性について考えるとき、もう一つ考えておきたいのが「ゴールの法則」です。
大まかには、
正常に動作する複雑なシステムは、正常に動作する単純なシステムから発展したものである
という考え方です。
ここで重要なのは「単純なシステムの方が常に優れている」ということではありません。現実世界の問題は複雑です。
森林も、企業も、社会も、ソフトウェアも、長く運用すれば最終的には複雑になります。問題は、その複雑さを最初から設計しようとすることです。
- 実際に動く小さなシステムを作る。
- 現実からフィードバックを得る。
- 必要な複雑性だけを追加する。
この順序が重要です。
複雑さには、獲得される過程が必要なのかもしれません。これは自然界にも少し似ています。生態系は、誰かが完成図を書いてから作ったものではありません。膨大な時間の中で相互作用が積み重なり、現在の複雑な構造になっています。
進化するシステムと、最初から完成形を設計されたシステムは、見た目が同じように複雑でも、その成り立ちはまったく異なります。
動的に見る
ルーカス批判：Lucas Critique
さらに複雑なのは、システムを観察しているわたしたち自身も、しばしばシステムの一部であるということです。
- 政策を変えれば、人々の行動が変わる
- 制度を変えれば、制度を利用する側も適応する
- セキュリティ対策を変えれば、攻撃者の行動も変わる
- サービスのUIを変更すれば、ユーザーの行動も変わる
経済学には「ルーカス批判」という議論があります。これは本来マクロ経済政策についての議論ですが、過去に観測された関係をそのまま未来へ延長して政策効果を予測することには限界がある、という問題を指摘しています。政策そのものが変われば、人々の期待や行動も変わるからです。
一般論としても、システムへ介入するときには、一時的な介入が新たな依存や既得権を生み、問題そのものを変えてしまう可能性についても以前の記事で考察してきました。
これをそのままソフトウェアの法則として扱うことはできませんが、複雑なシステムを考える上では示唆的です。
観察する → モデル化する → 介入する → システムが変わる → 元のモデルも変わるつまり、未来は単純に過去の延長線上にはありません。だからこそ、完成された未来を最初から設計しようとすることには限界があります。
複雑な世界をどう設計するか
ここまでの4つの視点を重ねてみると、一つの方向が見えてきます。
では、予測できない複雑な世界に対して、わたしたちはどう向き合えば良いのでしょうか。
わたしは最近、完成形ではなく、境界を設計することなのではないかと考えるようになりました。
- 未来に変更が起きても、その影響が無制限に全体へ伝わらないようにする。
- 内部の複雑性を、そのまま外部へ漏らさない。
- 外部の複雑性も、そのまま内部へ持ち込まない。
しかし、完全に閉じてしまうわけではありません。
必要なものは交換できるようにする。前半で、ドメインを「何をこの問題の内側として扱うかを決める領域」と捉えました。
この意味では、
ドメインが「何を考えるか」を決める境界なら、アーキテクチャの境界は「どのように関係するか」を決めるもの
と考えることができます。
世界 → 境界 → ドメイン → 対象・関係・ルール・意味そして、ドメインの外側にある別のシステムと関係するとき、そこには新たな境界が現れます。
Domain A —— Interface —— Domain B設計とは、すべてを一つにまとめることではなく、異なるものが異なるまま関係できるように、その接点を考えることと言えます。
縁側や土間を考える
自然界にも境界があります。細胞膜は細胞の内と外を分けますが、完全に遮断しているわけではありません。必要なものを取り込み、不要なものを排出し、外部との関係を保っています。人間の身体にも皮膚があります。家にも内と外があります。
日本の家屋には、その中間に「縁側」や「土間」という興味深い空間があります。縁側や土間は完全な内部でも、完全な外部でもありません。
内と外を分けながら、同時に両者が関係できる場所でもあります。ソフトウェアのインターフェイスやAPIも、それに少し似ています。異なるシステムを一つにしてしまうのではなく、
異なるまま関係できる場所を作る。
そう考えると、「縁」という日本語は興味深い言葉です。「ふち」という境界であると同時に、人と人との「えん」という関係も表します。
A ── 縁 ── B以前から疎結合という概念を紹介してきましたが、これは単に「結びつきを弱くする」という意味ではありません。疎結合とは、互いの境界を失わずに相手を尊重した関係を構築することと言えます。
それぞれが自らの内部を保ちながら、必要なところだけでつながることです。境界とは、関係を断つための壁ではなく、関係の仕方を決める場所になります。
依存と自律のバランス
境界を越えて関係すれば、そこには依存が生まれます。ソフトウェアはOSに依存します。OSはハードウェアに依存します。ネットワークを利用すれば通信インフラに依存します。暗号アルゴリズムや標準規格にも依存します。
人間も同じです。食料を生産する人がいて、電気を供給する人がいて、道路や通信を維持する人がいます。社会そのものが巨大な相互依存システムです。
したがって問題は、依存するか、依存しないかではなく、どのような依存関係を結ぶのかです。
その依存は交換できるでしょうか。一方的なものではないでしょうか。何に依存しているのか、わたしたちは理解しているでしょうか。
そして必要になったとき、その関係を変更したり、退出したりできるでしょうか。このように考えると、「自律」という言葉の意味も少し変わって見えます。自律とは、誰にも頼らないことではありません。
すべてを自分で作ることでもありません。むしろ、
誰と、どのような関係を結ぶかを自分で選べること。
そして必要なら、
その関係を変更したり、退出したりできること。
です。
孤立していることと、自律していることは違います。良いシステムは完全に閉じているわけではありません。外部と豊かな関係を持ちながら、自らの境界を失わない。
わたしには、それが自律したシステムの一つの姿に思えます。
システム開発の現場から
最近、わたしはAuthenticatorアプリを開発しました。二段階認証で使うワンタイムパスワードを生成するためのアプリです。ここまで見てきたような法則をアプリ開発の現場で、どのように考えて適用したかを紹介いたします。
TOTP（Time-Based One-Time Password）という仕組みそのものは比較的単純です。
Secret + Time + Algorithm = OTPしかし、実際にプロダクトとして設計すると、同期、バックアップ、外部サービス、ライブラリ、課金など、多くの依存関係が入り込んできます。
そこで何度も問い直したのが、
Authenticatorは、本当は何を知る必要があるのでしょう。
ということでした。
一つ機能を追加するたびに、アプリが知るべき外部世界が増えます。一つサービスを追加するたびに、システムの境界の向こうに新しい依存先が増えます。依存をゼロにすることはできません。OSにも、端末にも、同期の仕組みにも依存します。
しかし、
- どこまでを自分たちのドメインとするのか。
- どの依存を受け入れるのか。
- どこに境界を置くのか。
は設計できます。
依存をなくすのではなく、依存を選ぶ。この考え方は、Authenticatorというシステムだけの問題ではありません。
境界の曖昧な世界で、境界を見る
現代のデジタルサービスは、とても便利になりました。ログインも、同期も、決済も、ほとんど意識せずに利用できます。「シームレス」であることは、優れたUXの条件とされています。
しかし、少し違う見方もできます。
シームレスで、本当に境界がなくなっているのでしょうか。
実際には、境界が消えたのではなく、見えなくなっただけかもしれません。ユーザーからは一つのサービスに見えていても、その背後には複数のクラウドサービス、ID基盤、決済、分析、インフラが存在することがあります。
境界が見えなくなると、依存も見えにくくなります。ここには危うい構造があります。
- 普段は意識しなくても、サービスが終了したとき
- 料金体系が変わったとき。アカウントが停止されたとき。APIが廃止されたとき
- データを移行したくなったとき
初めて、その依存の存在に気づくことがあります。わたしも愛用していたAuthyという二段階認証アプリが、Mac版（デスクトップ版）の提供を終了するという事態になって、初めて気が付きました。
いままで、登録していた数十件の認証情報が、エクスポートできなかったのです！
しかも、Authy Desktopは当初2024年8月に終了すると告知されていましたが、その後予定が前倒しされ、2024年3月19日にEOL（End of Life, サポート終了）となりました。
結局、わたしは業務に影響が及ばないように、時期を見ながら認証情報を1件ずつ登録し直すことになりました・・・。——再登録の作業をしながら、「依存とは何か」をかみしめました(>_<)。
移行に際しては、シークレットを預けて大丈夫なベンダーか、突然、サービス終了しないか。エクスポートを禁止されてそのアプリにロックインされないか、などを気にしながら移行先を探してきました。
デジタル社会では「何につながっているか」だけでなく、どこに境界があり、何に依存しているのかを慎重に見極める必要が高まっています。
——というわけで、冒頭に書いたTOTP Authenticator アプリは、こうした経緯で生まれました。その経緯と、実際にどのように依存と境界を設計したかについては、Zennの記事「依存を選ぶ ― 2FAアプリ開発で考えた『選ぶ・持ち出す・続ける』自由」にまとめました。
境界を設計する
世界をシステムとして見れば、そこには無数の関係性が見えてきます。だからこそ、わたしたちは境界を引く必要があります。境界を越えるところに関係が生まれ、その関係が依存を生みます。そして、どのような依存関係を選ぶかが、自律性を左右します。
ここまでの道筋を一枚の絵にすると、次のようになります
この問いは仏教的に言えば縁起の世界であり、「そもそも何を存在として認識し、どの関係に意味を与えるのか」という、オントロジーや情報空間をどう構造化するかという問題にもつながっていきます。それはまた別の記事で考えてみたいと思います。
世界はつながっている。だからこそ、意味のある境界が必要になる。
自律とは、その境界を保ちながら他者と関係できることである。
システム思考とは、世界のつながりを認識しながら、どこに意味のある境界を置き、何をドメインとして切り出し、その境界を越えてどのような関係を結ぶのかを考えることだと言えます。
組織にとっても、個人にとっても、この問いに応えるには哲学、思想が問われてきます。そして、その哲学を実装するには技術が必要になります。
哲学なき技術は、どこへ向かうかを決められません。技術なき哲学は、現実を変えることができません。本ブログで一貫して考えてきた「哲学と技術の統合」は、AI時代にあらためて重要性を増しているように思います。
関連情報
AWS CTOの講演
Werner Vogelsが語った「クラウドアーキテクトが知っておくべき法則」
Vogelsは以下の6つの法則を単なる格言ではなく、当時のAWSのサービス設計やクラウドアーキテクチャと結びつけて説明していました。
- ルーカス批判（Lucas Critique）
- ゴールの法則（Gall’s Law）
- デメテルの法則（Law of Demeter）
- オッカムの剃刀（Occam’s Razor）
- リードの法則（Reed’s Law）
- ゲシュタルト原則（Gestalt Principle）
AWSクラウドでは内部に巨大な複雑性を抱えながら、利用者には比較的シンプルかつ適切な機能単位でサービスが提供されています。どこに境界を置くのか、どこまで内部を知る必要があるのか、複雑なシステムをどのように動的に成長させ続けるのか、といった問題はクラウドのアーキテクチャそのものでもあります。
ソフトウェア、組織、社会、自然、生態系、そしてAI。対象が変わっても、「複雑なものをどう捉え、どこに境界を置き、どのような関係を許すのか」という問いは繰り返し現れてきます。
以前の記事でも取り上げたように、クラウドのとてつもない複雑性を扱っているAWSの設計思想には学ぶべきものが多くあります。Vogelsが2024年のre:Inventでも再び「複雑性」を正面から取り上げ、Simplexityという言葉を軸に、複雑性をどう管理するかを講演しています。彼の基調講演は「increasingly complex systemsを管理するための原則」を扱うものと説明されています。生成AIと巨大なデジタル依存関係が高まる現在、あらためてクラウドアーキテクチャの原則から学ぶべきことが多くありそうです。
