「アーキテクチャ」という言葉の起源
ソフトウェア業界で日常的に使われる「アーキテクチャ」という言葉は、建築（Architecture）からの借用だ。単なる比喩ではない。両者の思考構造には、偶然では片づけられない共通性がある。
その接点を最も鮮明に示したのが、建築家クリストファー・アレグザンダーだった。1977年の主著『パタン・ランゲージ』は、建築と都市計画における253の「パターン」を体系化した書物だ。各パターンは「ある文脈で繰り返し発生する問題と、その解決策の核心」を記述する。
たとえば「光の降り注ぐ部屋（パターン159）」。人は自然光のある空間で心理的に安定する——だから主要な部屋には2方向以上の窓を設けよ。この「問題の文脈＋解決策」という組み合わせが、個々の建物を超えた 設計知の共有言語 になる。
1994年、エーリヒ・ガンマら4人のプログラマー（通称GoF）が『オブジェクト指向における再利用のためのデザインパターン』を出版した。アレグザンダーのパターン概念をソフトウェア設計に移植し、23の設計パターンを体系化したのだ。Observer、Singleton、Factory。これらの概念は建築家の思考から生まれた。
「柱」と「インターフェース」
柱は梁を支え、梁は床を支え、床は人の活動を支える。責務は明確だ。柱に配管の機能を持たせる建築家はいない。
ソフトウェアの単一責任の原則も同じ発想で、認証モジュールにDB接続管理を兼務させるのは、柱に配管を埋め込むようなものだ。動くかもしれない。だが配管を修理するたびに柱を壊す羽目になる。
ただし比喩には限界がある。建築の柱は一度建てたら動かせない。コードのモジュールは比較的簡単に分割できる。物理制約のない仮想空間には「あとから責務を分離する」という逃げ道がある。建築にはない「やり直しの自由」が、ソフトウェア設計者を甘やかしもする。
もう一つ。建築のジョイント（接合部）が面白い。鉄骨構造のジョイントは、部材同士をがっちり固定しない。熱膨張や振動で各部材が独立に動ける「遊び」を残す。ソフトウェアのインターフェースがまさにこれだ。密結合は短期的に速いが、変更に脆い。疎結合は初期コストがかかるが、システムの寿命を延ばす。
「ゾーニング」と「レイヤード・アーキテクチャ」
建築設計でゾーニングは基礎中の基礎だ。パブリックゾーン（リビング、ダイニング）、プライベートゾーン（寝室、書斎）、サービスゾーン（キッチン、浴室）。これらを分離し、動線を整理する。境界が曖昧な住宅は住みにくい。寝室を通らなければトイレに行けない。キッチンを通過しないとリビングに行けない。境界の失敗だ。
レイヤード・アーキテクチャは、このゾーニングをコードに翻訳したものだ。プレゼンテーション層、ビジネスロジック層、データアクセス層。各層は独自の責務を持ち、隣接する層とだけ通信する。ビジネスロジック層がデータベースの実装を直接触る設計は、寝室からキッチンの冷蔵庫が丸見えの間取りだ。動くには動く。だが関心事の分離が破綻している。
ロバート・C・マーティンの「クリーン・アーキテクチャ」は、この発想をさらに押し進めた。ビジネスルールという「最もプライベートな領域」を中心に据え、外側にインフラストラクチャ、フレームワーク、UIを同心円状に配置する。建築のプライバシー・グラデーション——公道から玄関、廊下、リビング、書斎、寝室へとプライバシーが段階的に深まる設計——そのものだ。
「リノベーション」と「リファクタリング」
リファクタリング。外から見た振る舞いを変えずに、内部構造を改善する作業だ。
建築ではこれを「リノベーション」と呼ぶ。築30年のオフィスビルをシェアオフィスに転用する。町家を店舗兼住居に仕立て直す。既存の骨格を活かしながら中身を入れ替える行為であり、最初に見極めるべきは「この躯体は健全か」という一点だけだ。
躯体が腐っていれば表面を塗り直しても意味がない。コードも建物も同じだ。スパゲッティコードに機能を足し続けるのは、シロアリに食われた柱の上にフロアを増築するのと変わらない。どこかで「建て替え（フルリライト）」の判断を下す勇気がいる。
フランク・ロイド・ライトは「建物は竣工した瞬間に時代遅れになる」と言ったとされる。コードも同じだ。リリースした瞬間から要件は変わり始める。設計者の仕事は「完璧な建物を建てる」ことではない。 変化を受け入れられる構造を仕込んでおく ことだ。
「住む人」と「使う人」
設計者と利用者は、同じものを見ていない。
建築家は図面と模型で空間を把握する。だが実際にそこで暮らす人は、身体で空間を体験する。図面上は美しい動線も、歩いてみると妙に遠回りだったりする。このずれを埋めるのがウォークスルーだ。完成前の建物を仮想的に「歩く」。VRでそれが着工前に可能になった。
ソフトウェアのユーザーテストも同じ問題を解こうとしている。が、ここで決定的な違いが顔を出す。建物は完成すれば利用者が自然と空間を「体験」する。ソフトウェアのUIは、体験する前に「理解」を要求する。ボタンの意味、画面遷移のロジック、エラーメッセージの意図。建築より一段、距離が遠い。
安藤忠雄は「住む人の人生を知らずして、家は設計できない」と言う。ソフトウェアではこれがさらに難しい。ユーザーは自分が何を不便に感じているか、うまく言語化できない。
問いかけ
- 自分の設計の「構造躯体」は何か？ 変えるべきでないものを変えようとしていないか。
- ジョイントは適切か？ 密結合になっている箇所、それは意図か、怠慢か。
- 利用者は「図面」ではなく「空間」で体験している。そのギャップを、最後に確認したのはいつだったか。
