May 15, 2026

ソフトウェアアーキテクトは都市計画家である — 入れ替わる主体のための計画論

建築メタファーが捉えそこねている「主体の入れ替わり」という現象に着目し、ソフトウェアアーキテクトの仕事を都市計画家のそれとして再定義する。継承可能性の設計という視点から、アーキテクトの本質的役割を整理する。

アーキテクチャ設計組織メタファー

はじめに

「ソフトウェア工学を建築に準えるのは適切ではない、プロジェクトには終わりがあるから」という言説がある。これは建築メタファーの弱点を 時間の長さ だけで捉えている。

しかし本当の弱点はそこではない。建築メタファーが捉えそこねているのは、主体の入れ替わり という現象である。

建築は、施主・設計者・施工者・利用者が、プロジェクト期間中ほぼ固定されている。完成して引き渡せば設計者の仕事は終わる。一方、都市は違う。市民は入れ替わる。行政官も入れ替わる。デベロッパーも入れ替わる。計画を立てた本人も、計画の完成を見ずに死ぬ。

ソフトウェアは後者だ。開発者は5年で半分入れ替わる。ユーザーは世代交代する。経営陣は方針を変える。書いた本人がそのコードを最後まで保守することは、ほぼない。

だからソフトウェアアーキテクトの仕事は、建築家のそれではなく、都市計画家のそれ に近い。「完成形を作る」ではなく「自分が居なくなった後にも、知らない誰かが運用し続けられる仕掛けを残す」ことが本質的な仕事になる。

なお、建築メタファーには「捉えそこねている」のとは別に「まだ拾われていない」部分もある。実際の建築は竣工して終わりではなく、用途変更 (adaptive reuse) やリノベーションが日常的に起きる。倉庫がオフィスになり、教会がレストランになり、工場が美術館になる。構造体を残したまま内部を作り替える営みは、レガシーシステムのリアーキテクチャと驚くほど似ている。しかしソフトウェア側の建築メタファーは「設計→施工→完成」という新築のプロセスばかりを拾ってきた。建築の本当に面白い部分 — 既存構造物との交渉、耐荷重の制約の中での改修、元の設計意図を読み解きながらの転用 — はまだほとんど参照されていない。これ自体が一つの記事になりうる主題だが、本記事では都市計画の側に軸足を置く。

この記事では、都市計画の視点でアーキテクトの役割を整理する。

1. 「完成」概念の放棄

建築家は完成図を描く。竣工日があり、引き渡しがあり、責任の主体が設計者から管理者に移る。

都市計画家には完成図がない。マスタープランは「2050年までにこの方向を目指す」という曖昧な指針であり、その間に何度も改定される。完成は目的ではなく、持続が目的 だ。

ソフトウェアでも同じことが言える。「v1.0リリース」「フェーズ1完了」「リアーキ完遂」といったマイルストーンは便宜的なもので、実際には次の改修・拡張・置き換えが既に始まっている。リリースは終わりではなく、運用フェーズへの遷移点に過ぎない。

DevOpsの本質は技術的な手法の話ではなく、この 時間軸の連続性 を受け入れるかどうかにある。「開発と運用を分けない」という標語の裏にあるのは、「完成して引き渡す」というモデル自体の否定だ。

アーキテクトが最初に放棄すべきものは「完成」という概念である。

2. 主体の入れ替わりを前提とする

都市計画の最大の制約は、計画を立てた人間が、計画の実行期間中に必ず居なくなる ことだ。30年計画を立てた都市計画家は、30年後その都市にいない可能性が高い。

この前提から、いくつかの設計原則が導かれる。

個人の暗黙知に依存しない。「あの人に聞かないとわからない」という状態は、計画の継承可能性を破壊する。コードベースで言えば、特定エンジニアの脳内にしか存在しない設計意図は、その人が辞めた瞬間に失われる。

意図を形式知化する。なぜこの道路をここに通したか、なぜこの用途地域をこう区切ったかは、条例や計画書として残される。ソフトウェアではADR (Architecture Decision Records)、ドキュメント、コメント、テストコードがその役割を担う。「動いているコード」だけでは意図が伝わらない。

新しい主体が読み解ける構造にする。10年後にこのコードベースに新人として加わる人間は、現在のチームメンバーよりずっと多くなる。最初の理解者が居なくなった後に来る無数の継承者のために書く。

「自分が辞めたらこのシステムはどうなるか」を真剣に考えたことがないアーキテクトは、まだアーキテクトではない。

3. 介入の不可逆性

道路は一度通すと付け替えが極めて難しい。沿線に建物が建ち、店ができ、生活動線が形成され、地価がそれを前提にする。「やっぱりこっちに通したかった」では済まなくなる。

ソフトウェアにも同じ性質を持つものがある。公開API、データベーススキーマ、ファイル形式、URLの構造、認証方式。一度公開して利用者が依存し始めると、変更は単なる技術的作業ではなく、利用者全員の移行コストを含む政治的プロジェクトになる。

Jeff Bezos はこれを “one-way door” と “two-way door” という比喩で表現した。戻れないドアと、戻れるドア。不可逆な決定 (one-way door) は組織の上位で慎重に判断すべきであり、可逆な決定 (two-way door) は現場に委譲して素早く下すべきだ、と。

アーキテクトの重要な仕事の一つは、どの決定がone-way doorで、どの決定がtwo-way doorか を見極めることだ。不可逆な決定は遅らせ、検討を尽くす。可逆な決定は早く下して進む。

これを間違えると二つの病になる。two-way doorの前で延々議論して進まない病と、one-way doorを軽率にくぐって取り返しがつかなくなる病。前者は遅延、後者は技術的負債の固定化を生む。

4. コモンズの管理

都市には「誰のものでもないが、全員が依存するもの」がある。道路、公園、上下水道、街灯。これらは コモンズ と呼ばれ、放置すると必ず劣化する。誰も自分の責任とは思わないからだ。

ソフトウェアのコモンズは、共有モジュール、共通ライブラリ、内部プラットフォーム、CI/CDパイプライン、データベース、認証基盤などだ。これらは全員が使うが、誰も「自分が責任を持っている」とは思っていない。結果として:

アーキテクトの仕事の一つは コモンズを誰の責任にするかを決める ことだ。プラットフォームチームを作る、SREに移す、ドメインチームに分散させる、いずれにせよ「無主物にしない」という意思決定が要る。

都市が公共事業として道路を維持するように、組織もコモンズを意識的に維持する仕組みが要る。

5. 時間軸の階層性

都市には複数の時間軸が共存している。日々のゴミ収集、季節ごとの祭事、数年単位の建物建替、数十年単位の区画整理、世紀単位の都市構造変化。どれも同時に進行している。

Stewart Brand は『How Buildings Learn』(1994) でこれを Pace Layers (速度層) という概念で定式化した。最も速く変わる Fashion/Art から、Commerce、Infrastructure、Governance、Culture、そして最も遅い Nature まで、異なる速度で変化するレイヤーが積み重なっており、速いレイヤーが革新を提案し、遅いレイヤーが安定を保証する。興味深いのは、Brand 自身が建築の内側からこの議論をしていたことだ。建物もまた「完成した静的な構造物」ではなく、内装・設備・構造体がそれぞれの速度で変化する動的なシステムである、と。

ソフトウェアにもPace Layersがある:

短い時間軸で働く人と長い時間軸で働く人は、見ている景色が違う。日次のデプロイをしているエンジニアにとって「10年後の保守性」は遠すぎる話だし、長期計画を立てるアーキテクトにとって「来週のリリース」は些末事に見える。

アーキテクトの役割は、これら異なる速度層の間を翻訳すること にある。長期の方針を、短期の実装判断にどう落とすか。短期の現実を、長期の計画にどうフィードバックするか。この翻訳をしない計画は形骸化し、この翻訳をしない実装は近視眼に陥る。

そして重要なのは、速いレイヤーの変更が遅いレイヤーを侵食しないようにすることだ。UIの変更がデータモデルを汚染し、機能追加が認証基盤に穴を開ける — これはPace Layersの境界が崩壊した状態であり、アーキテクチャの劣化そのものである。

6. 計画と現実の往復

都市計画はマスタープランを掲げるが、現実は必ず計画からずれる。人口予測は外れ、産業構造は変わり、災害が起きる。それでも計画なしでは都市は成立しない。

計画の機能は「その通りに進めること」ではなく、「ずれた時に何が問題かを判定する基準を提供すること」 にある。計画があるからこそ「この判断は計画と整合するか」「整合しないなら計画を改定すべきか、判断を見直すべきか」と問える。

アーキテクチャも同じだ。アーキテクチャ・ガイドラインが「絶対に守るべきルール」として運用されると組織は硬直する。一方で「あくまで目安」として軽視されると一貫性を失う。

健全な状態は、「逸脱には説明責任が伴う」 という運用だ。逸脱は禁止ではないが、なぜ逸脱したかを記録し、必要なら計画を改定する。これがADRの本来の使い方であり、都市計画における計画変更手続きと同じ機能を果たす。

7. Chesterton’s Fence — 既存物の存在理由

「目的のわからない柵を見つけたら、その理由がわかるまで撤去するな」という Chesterton’s Fence の原則がある。都市計画家がよく直面する問題だ。「なぜここに公園があるのか」「なぜこの道は一方通行なのか」「なぜこの地区だけ建物の高さ制限が厳しいのか」。

理由を知る人がいなくなり、現役世代から見て不合理に見えると、撤去・改変が議論される。そして撤去してから「実は重要な機能があった」と気づく。

ソフトウェアのコードベースは Chesterton’s Fence の博物館だ。「なぜこの抽象化があるのか」「なぜここで例外を握りつぶしているのか」「なぜこの処理だけ別経路なのか」。書いた本人がいなくなり、コメントもなく、テストもなく、ただコードだけが残る。新しい世代が「これは要らないのでは」と判断して消し、本番障害が起きる。

意図を残すことが、未来の自分たちを救う。これは個人の善意ではなく、アーキテクチャの責務 として組織に組み込むべきものだ。

8. ユーザーも入れ替わる

ここまで「主体の入れ替わり」を主に開発者の視点で論じてきたが、入れ替わるのは作る側だけではない。使う側もまた入れ替わる。

10年運用されているプロダクトの今日のユーザーは、10年前のユーザーとは全く違う層になっている。世代が変わり、デジタルリテラシーが変わり、競合プロダクトとの比較基準が変わり、UIの常識が変わっている。

「初期ユーザーが受け入れてくれた設計」が、現在のユーザーには通用しない、ということが頻繁に起きる。都市で言えば、自動車中心に作られた郊外都市が、車を持たない高齢者世代にとって機能不全になるようなものだ。

ここから導かれる原則は、ユーザーの同一性を仮定しないということだ。「我々のユーザーはこういう人たちだ」という像を固定した瞬間、そのシステムは現在のユーザーのための最適化に陥り、次の世代のユーザーを失う準備を始めている。都市が「現在の住民構成」に最適化した計画を立てると、人口動態の変化に対応できなくなるのと同じだ。

アーキテクチャレベルで言えば、「誰が使うか」の仮定が特定の層に深くハードコードされた設計は脆い。インターフェースと内部構造の分離、データのポータビリティ、アクセシビリティの確保 — これらは単なる技術的な良心ではなく、ユーザー層の世代交代に対する構造的な備え である。

9. 強制力なき計画 — 都市計画メタファーの限界

ここまで都市計画とソフトウェアアーキテクチャの類似を論じてきたが、決定的な非対称性が一つある。都市計画家には法的強制力があるが、ソフトウェアアーキテクトにはない。

用途地域、建蔽率、容積率、道路斜線制限 — 都市計画家が定めたルールは条例として法的拘束力を持ち、違反すれば建築許可が下りない。自動的に強制される。一方、ソフトウェアのアーキテクチャガイドラインは本質的に「お願い」である。忙しければ無視され、知らなければ違反され、レビューで指摘されても「次のスプリントで直す」と先送りされる。

つまりソフトウェアアーキテクトは、条例なしで都市計画をしている ようなものだ。ガイドラインを書くだけでは遵守されない。「正しいことを書いたのに誰も従わない」という嘆きは、強制メカニズムを欠いた計画の必然的な帰結である。

ではどうするか。人間の意志力に頼らず、構造的に計画を実効化する仕組みが要る。

Fitness Functions の自動化。Neal Ford らが『Building Evolutionary Architectures』で提唱した概念で、アーキテクチャ上の制約をテストとして表現し、CIで自動実行する。「循環依存を禁止する」「このモジュールからあのモジュールへの依存を禁止する」「レスポンスタイムが閾値を超えたらビルドを落とす」。条例の自動執行に相当する。ArchUnitやdeptryのようなツールがこれを支援する。

Paved Road (舗装された道)。Netflixが提唱したアプローチで、「正しいやり方を、最も簡単なやり方にする」という発想だ。テンプレートリポジトリ、内部CLI、プラットフォームAPIを整備して、ガイドラインに沿った開発が最も手間が少ない状態を作る。禁止するのではなく、従った方が楽になる構造 を作る。都市計画で言えば、条例で規制するのではなく、インフラを整備して自然と計画通りの開発が行われるように誘導するアプローチに近い。

APIレビューゲート。公開APIやスキーマ変更など不可逆性の高い決定に対して、マージ前にアーキテクトのレビューを必須にする。すべての変更をレビューするのではなく、one-way doorだけを対象にすることで、ボトルネック化を避けつつ重要な決定の品質を保つ。

これらは条例の代替であり、アーキテクトの意思を人間の記憶や善意ではなく、システムとプロセスに埋め込む 試みだ。強制力のない計画は計画ではない。仕組みにすることで、アーキテクトが居なくなった後も計画が生き続ける。

10. アーキテクトの本質的役割

ここまでの議論を集約すると、アーキテクトの仕事は次のように整理できる。

建築家の仕事: 施主の要件を満たす完成形を設計する。完成して引き渡せば仕事は終わる。

都市計画家の仕事: 自分が居なくなった後も、知らない誰かが運用と更新を続けられる枠組みを設計する。完成形を作るのではなく、変化を受け入れる構造を作る。

ソフトウェアアーキテクトの仕事: 後者。具体的には:

この視点に立つと、「綺麗なコードを書く」「最新の技術を使う」「速いシステムを作る」といった話は、アーキテクトの仕事の中心ではなくなる。それらは手段であり、目的は 「自分が居なくなった後も持続する組織とシステムを残すこと」 にある。

まとめ

建築メタファーが捉えられないのは、ソフトウェア開発の「終わりのなさ」だけではない。本質的な問題は、主体が入れ替わり続ける という事実だ。

開発者は辞める。ユーザーは世代交代する。経営者は方針を変える。そしてアーキテクト自身もいなくなる。

この前提を真正面から受け止めると、アーキテクトの仕事は完成形の設計ではなく、継承可能性の設計 になる。誰が来ても、誰が去っても、組織とシステムが機能し続ける枠組みを作ること。

都市計画家は、自分が見ることのない100年後の都市のために計画を立てる。同じように、ソフトウェアアーキテクトは、自分が関わらない10年後のコードベースのために設計する。

この時間感覚を持てるかどうかが、実装者とアーキテクトを分ける一線 だと思う。

← Back to all posts