― 境界、依存、そして自律について
現代の複雑な課題を解決するには、システム思考が重要です。
- 個々の要素だけを見るのではなく、その間にある関係を見る
- 一方向の原因と結果だけでなく、フィードバックのループを見る
- 一時点だけでなく、時間の中で変化する構造を見る
- システム全体に良い影響を与えられるティッピングポイントを探す
AIの活用でもソフトウェア開発でも、システムを全体としてとらえるとともに、意図した波及効果をシステム全体にもたらすポイントを見極めることが重要です。生物も、組織も、人間関係も、社会も、国家も、そしてデジタル社会も、境界を持ちながら他者と関係しています。
そして、特定の規定された領域ではAIが圧倒的なパフォーマンスを発揮する時代となりました。わたしたち人間の役割は、次のような分野へと移行していきます。
広大な世界に境界を引いて、領域内のシステムに課題を設定する。そして、そのシステムと領域外のシステムとの関係性を定義する。
今回は「領域」と「境界」、「依存」と「自律」について考えいきましょう。
システムの領域は
以前、「生物多様性とシステム思考」という記事で、ニホンヤマネの保護活動を例として、絶滅が危惧される野生動物の生態から森林へ、森林から人間の活動へ、さらに産業や政策、地域社会とのつながりなど、システム思考のアプローチで部分最適と全体最適のバランスを考察しました。
森林が失われる理由を探しても、単純な解決策は見つかりません。林業の衰退、エネルギー政策、土地利用、地域経済、人口減少、野生生物の生態、人間の価値観。さまざまな要素が互いに影響し、ある変化が別の変化を引き起こし、その結果がまた最初の要素へ戻ってきます。
森を一つのシステムとして考えれば、個々の樹木があり、土壌があり、微生物がいて、昆虫や鳥や哺乳類がいます。ここまでなら生態系としてのシステムを設定しています。
しかし森林の状態には、人間の活動も大きく影響します。林業があり、道路があり、観光もあり、土地の所有者、法的規制、自治体の政策も関係してきます。太陽光発電施設があり、木材価格やエネルギー政策、国際貿易、人口動態まで関係してきます。
どこまでを「森林というシステム」に含めるか。境界をどこに置くかによって、同じ森林でも見えてくる問題はまったく違います。
例えば、
森林 → 樹木 → 野生動物だけを見るのと、
森林
├ 生態系
├ 林業
├ 観光
├ 土地所有
├ エネルギー
├ 地域経済
└ 行政まで含めて見るのとでは、解決策も変わります。
ここで重要なのは、現実の世界に「ここからここまでが一つのシステムです」という線が最初から引かれているわけではない、ということです。特に近年はこうした境界がダイナミックに変動しています。また、いろいろな意味で越境することが、新たな価値を生み出している世界です。
わたしたちは従来の枠組みを超えて、問題を理解するためにある範囲を切り出して「システム」を考えることになります。つまり、システムを考えることは、同時に境界を考えることでもあります。
ドメインを決める
世界は、ほとんど無限につながっていて、地域の森について考え始めても、世界規模での気候変動、土地利用、エネルギー政策、世界経済、国際的な資源価格までつながっています。金融、政治、人口動態、技術革新も関係してきます。
関係を追い続ければ、世界全体に行き着き、地球全体を考慮しないとシステムを定義出来なくなってしまいます。以前の記事で紹介したカナダの森林学者スザンヌ・シマードさんは、科学的な思考の限界を著書「マザーツリー」の中で次のように表現されています。
そしてまもなく私は、生態系全体の多様性とつながり合いについての論文を書くのがほぼ不可能であることを知ったのだ。対照群がないではないか！と、私の初期の論文の査読者は叫んだ。
〜中略〜
統計的有意性のある顕著な差だけを考慮する訓練などを通じ、ぐるりと一巡して先住民の人々が持っていた叡智に辿り着いたのだ
当然のことながら、地球というシステム全体に対照群を設けて実験することはできません。
システム思考においても、「今回はここまでを考える」と範囲を決める必要があります。そして、その範囲に過去の経験やデータを適用しながら、動的なフローを見て、制御するポイントを見ていくわけです。
課題設定について意味のある範囲を切り出したものを、「ドメイン」として表現します。ビジネスでは「製造業のドメイン」「金融のドメイン」のように、専門領域や業界という意味で使われることも増えてきました。
システムを考える上ではもう少し広く、
何をこの問題の内側として扱い、何を外側として扱うのかを定義した領域
と考えることができます。
例えば同じ森を見ても、林業者、生態学者、行政、観光事業者では、見ているものが違います。林業者なら、樹種、材積、林齢、伐採、搬出路を見るでしょう。生態学者なら、種、個体群、植生、生態系を見るかもしれません。
行政なら、土地利用、所有関係、防災、税、地域経済という視点で見るでしょう。同じ世界を見ていても、問題として切り取っている領域が全然異なっているのです。
つまり、ドメインを設定するとは、世界の切り取り方を決めることでもあります。
そしてドメインを決めると、その中で何を対象として扱うのか、どの関係を重要と考えるのか、どんな言葉を使うのかも決まってきます。
世界 → 境界 → ドメイン → 領域・対象・関係・文脈・ルール・意味何を自分たちのドメインとするのか。企業価値を決める上でも、競争戦略における核心をどこに定めるか。システムをどのように設計するか。
AIが大量の情報を扱えるようになった現在、この「領域を設定する」という能力は、むしろ重要性を増しています。情報が少なかった時代には、知識を増やすことそのものに価値がありました。
しかし情報がほぼ無限に得られる状況では、
- 何を知るべきか。
- 何がいまの問題に関係しているのか。
- どこまで考えれば十分なのか。
という問いの方が重要になります。
4つの法則
本質的な課題というのは、古来、多くの先人が深く思考して、法則を導き出してくれています。巨人の肩に乗ることも必要です。今回は4つの法則を紹介しながら、この命題についてわたしたちも深く考えてみましょう。
- ゲシュタルト原則
- デメテルの法則
- ガルの法則
- ルーカス批判
全体を見る
ゲシュタルト原則：The Gestalt Principle
ゲシュタルト心理学の有名な考え方です。「全体は部分の総和より大きい」と紹介されることがありますが、より正確には、全体は単なる部分の総和とは「別のもの」である、ということです。
システムも同じです。優れた部品を集めれば、優れたシステムになるとは限りません。
それでも、全体としてサービスが適切に機能する保証はありません。特に業務の文脈やユーザーの関心に最適化した画面構成や画面遷移が適切に設計されていなければ、使われないシステムになってしまうことも少なくありません。
2つの合成の誤謬
隠蔽パターン
ラストワンフィートにおける統合性、エンドユーザーとのタッチングポイントとしてのUI（ユーザー・インターフェース）は特に重要です。近年、個別の機能は高度化し、複雑化する一方で、その複雑性を適切に抽象化することなく、UIをただシンプルにしてしまっているUIも増えています。
画面がお洒落にデザインされているのは良いけれど、内部構造が隠蔽されていて、ユーザーがデータの構造や意味を体系的に理解する機会が失われていきます。そして、トラブル時にもユーザーは何が起きたのかも、対処の仕方も分からなくなってしまう傾向が高まっています。
混沌パターン
逆に、プログラム側の都合がそのまま露出してしまっていて、メニューがやたらに多くてどれを選んだら良いのかわからない「混沌」パターンも増えています。ユーザーの意図にマッチしていない深い場所に、良く使う機能が隠れてしまっていたり、提供側が売り込みたい機能（いまなら、AI機能等）が文脈と関係なく、しゃしゃり出てきて、ユーザーの認知を混乱させています。
こうしたUI/UXの問題については、過去の記事（デジタル社会のUI/UX論）でも警鐘を鳴らしてきました。
全体最適
個々の技術が特別に新しいものや優れたものでなくとも、適切な関係で組み合わせることで、優れた使いやすい道具になることもあります。つまりシステムには、個々の部品には存在しなかった性質が現れるのです。現在なら「創発」という言葉で説明することもできます。
要素 + 要素 + 関係 =システムとしての性質ここで重要なのが「統合」であり、システム・インテグレーターには全体を最適化して統合する重要な役割があります。そして、適切に「統合」できるかどうかは多様な「関係」によって決まります。システム思考では、個々の要素の関係を見ることが重視されています。
つながりを見る
デメテルの法則：Law of Demeter
システム思考では、要素間の関係を見て、最も効果的に良い循環を起こすポイントを見つけて介入することが重要です。関係性は複雑に折り重なっており、すべての関係性を制御することはできません。
人間関係に例えて考えてみましょう。ある人と話すために、その人の上司、家族、友人、取引先の事情まで知らなければならないとしたら、とても複雑になります。
組織文化に良くある構造として、一つの仕事を進めるために、
という状況が増えるほど、判断も制御方法も複雑になる一方です。ソフトウェアの世界では、この問題への対処として「デメテルの法則」という設計原則があります。
別名を「最小知識の原則」と言います。簡単に言えば、
直接関係する相手とだけ話しましょう。
という考え方です。
例えば、
A → B → C → Dという構造があるとき、AがBを通り越してCやDの内部事情まで知るようになると、CやDの変更がAにまで伝わります。
一つの変更が遠くまで波及するシステムになります。
逆に、
A ↔ B
B ↔ C
C ↔ Dのように、それぞれが直接関係する相手と適切な境界を持てば、変更の影響を局所化できます。「知らないこと」は、必ずしも欠点ではありません。
むしろ、必要以上のことを知らなくても済むように設計されていることが、システムの強さになる場合があります。ハードでもソフトでも、モジュール化、カプセル化、部品化によって、保守性、効率性、機能性が高まる効果を担ってきました。
これは、以前のブログ（AWSクラウドに学ぶビジネス設計）でAWSの設計原則の一つとして疎結合を紹介したときにも書いたことですが、日本のビジネス社会において、考慮するべき重要な法則でもあります。
デメテルの法則（最小知識の法則）は一般社会の文脈で評価しても興味深いものです。わたしたちは「知ること」を基本的には良いこととして考えています。
しかし、「知ることができる」と「知る必要がある」は違います。他人について知ることのできる情報を、すべて知る必要はありません。組織のすべての内部事情を、すべての社員が把握する必要もありません。
一つのサービスを使うために、サービス提供者がユーザーについてあらゆる情報を知る必要もありません。しかし、最近のデジタルサービスを見ていると、大量の情報を収集することが当然のようになっています。
しかし本来は逆の問いも必要です。
このサービスは、この情報を本当に知る必要があるのでしょうか。
最小知識の原則は、プライバシーの観点から見ても重要な原則です。
情報を集めた後で厳重に管理することも重要ですが、そもそも必要のない情報を知らなくても成立する構造にするという選択肢があります。機能性アウトドア・カジュアルアパレル企業として知られるワークマンは、顧客情報をあえてもたないことでも有名です。
話が少し逸れますが、近年のネットビジネスにおいて、従来は費用対効果の高かったキーワード広告、ターゲティング広告、SNS広告も競争が激化して、広告費用が高騰する一方です。顧客情報を収集して、広告をターゲティングする手法、キーワードに最適化した広告クリエイティブなどに時間と資金を投下し続ける一方で、本来取り組むべき、ものづくりや顧客サービスがなおざりになっているのではないか、とさえ思う企業も増えている気がします。
広告の費用対効果はどんどん落ちてきているのに、さらに出稿競争を煽るような思想も喧伝されています。LTV（Life Time Value）という、初期の認知獲得の広告費を数年かけて回収するといった考え方です。もはや、ユーザー情報を収集し続け、プライバシーへの配慮もなく、認知獲得を優先するビジネススタイルは、価格の正当性やモラルを問われかねないレベルに到達していると言わざるを得ません。
アテンション獲得のために、本来は知らなくても良い情報まで収集して、個人情報の管理と分析に莫大な時間とコストをかけ、さらに、広告でアテンションを獲得する、という手法で競争していては、健全なビジネスは育ちません。
あまりに行き過ぎたアテンション経済、広告でドライブされたビジネスは、そろそろ見直さなければなりません。本当にビジネスに必要なコアな情報は何なのか、最小知識の原則論から再考する意義は大きいはずです。
小さく始める
ガルの法則：Gall’s law
複雑性について考えるとき、もう一つ考えておきたいのが「ガルの法則」です。
大まかには、
正常に動作する複雑なシステムは、正常に動作する単純なシステムから発展したものである
という考え方です。
ここで重要なのは「単純なシステムの方が常に優れている」ということではありません。現実世界の問題は複雑です。
森林も、企業も、社会も、ソフトウェアも、長く運用すれば最終的には複雑になります。問題は、その複雑さを最初から設計しようとすることです。
- 実際に動く小さなシステムを作る。
- 現実からフィードバックを得る。
- 必要な複雑性だけを追加する。
この順序が重要です。
複雑さには、獲得される過程が必要なのかもしれません。これは自然界にも少し似ています。生態系は、誰かが完成図を書いてから作ったものではありません。膨大な時間の中で相互作用が積み重なり、現在の複雑な構造になっています。
進化するシステムと、最初から完成形を設計されたシステムは、見た目が同じように複雑でも、その成り立ちはまったく異なります。
動的に見る
「ルーカス批判」
さらに複雑なのは、システムを観察しているわたしたち自身も、しばしばシステムの一部であるということです。
- 政策を変えれば、人々の行動が変わる
- 制度を変えれば、制度を利用する側も適応する。
- セキュリティ対策を変えれば、攻撃者の行動も変わる
- サービスの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という二段階認証アプリが、2024年8月にMac版（デスクトップ版）の提供を終了するという事態になって、初めて気が付きました。
いままで、登録していた数十個の認証情報、エクスポートできなかったのです！
結局、数十件の認証情報を一つずつ登録し直すことになり、業務の影響が及ばないように少しずつ移行しているところです。
移行に際しては、シークレットを預けて大丈夫なベンダーか、突然、サービス終了しないか。エクスポートを禁止されてそのアプリにロックインされないか、などを気にしながら移行先を探してきました。
デジタル社会では「何につながっているか」だけでなく、どこに境界があり、何に依存しているのかを慎重に見極める必要が高まっています。
結局、わたしは自らTOTP Authenticator アプリを開発することにしました。その経緯と考え方、技術的な検討内容などは、zennに詳しい記事を書きましたので、ご興味のある方はご覧ください。
境界を設計する
世界をシステムとして見れば、そこには無数の関係性が見えてきます。だからこそ、わたしたちは境界を引く必要があります。境界を越えるところに関係が生まれ、その関係が依存を生みます。そして、どのような依存関係を選ぶかが、自律性を左右します。
この問いは仏教的に言えば縁起の世界、「そもそも何を存在として認識し、どの関係に意味を与えるのか」という、オントロジーや情報空間をどう構造化するかという問題にもつながっていきます。それはまた別の記事で考えてみたいと思います。
世界はつながっている。だからこそ、意味のある境界が必要になる。
自律とは、その境界を保ちながら他者と関係できることである。
システム思考とは、世界のつながりを認識しながら、どこに意味のある境界を置き、何をドメインとして切り出し、その境界を越えてどのような関係を結ぶのかを考えることだと言えます。
組織にとっても個人としても、この問いに応えるには哲学、思想が問われてきます。そして、その哲学を実装するには技術が必要になります。
哲学なき技術は、どこへ向かうかを決められません。技術なき哲学は、現実を変えることができません。本ブログで一貫して考えてきた「哲学と技術の統合」は、AI時代にあらためて重要性を増しているように思います。
関連情報
AWS CTOの講演
Werner Vogelsが語った「クラウドアーキテクトが知っておくべき6つの法則」
今回取り上げたガルの法則、デメテルの法則、ゲシュタルトの原則、ルーカス批判はAmazon.com CTOのWerner Vogelsが2015年のAWS re:Invent基調講演「クラウドアーキテクトが知っておくべき6つの法則」でも、紹介されていました。
Vogelsは6つの法則を単なる格言ではなく、当時のAWSのサービス設計やクラウドアーキテクチャと結びつけて説明していました。
- ルーカス批判（Lucas Critique）
- ガルの法則（Gall’s Law）
- デメテルの法則（Law of Demeter）
- オッカムの剃刀（Occam’s Razor）
- リードの法則（Reed’s Law）
- ゲシュタルトの原則（Gestalt Principle）
AWSクラウドでは内部に巨大な複雑性を抱えながら、利用者には比較的シンプルかつ適切な機能単位でサービスが提供されています。どこに境界を置くのか、どこまで内部を知る必要があるのか、複雑なシステムをどのように動的に成長させ続けるのか、といった問題はクラウドのアーキテクチャそのものでもあります。
今回の記事を書きながら、10年以上前に聞いたVogelsの講演を思い出しました。興味深いのは、これらの原則がクラウドだけに閉じた話ではないことです。
ソフトウェア、組織、社会、自然、生態系、そしてAI。対象が変わっても、「複雑なものをどう捉え、どこに境界を置き、どのような関係を許すのか」という問いは繰り返し現れてきます。
以前の記事でも取り上げたように、クラウドのとてつもない複雑性を扱っているAWSの設計思想には学ぶべきものが多くあります。Vogelsが2024年のre:Inventでも再び「複雑性」を正面から取り上げ、Simplexityという言葉を軸に、複雑性をどう管理するかを講演しています。彼の基調講演は「increasingly complex systemsを管理するための原則」を扱うものと説明されています。生成AIと巨大なデジタル依存関係が高まる現在、あらためてクラウドアーキテクチャの原則から学ぶべきことが多くありそうです。
