変幻する実行可能知識 08本物のアーキテクトにも少しだけ聞いてみよう今回は少し趣を変えて, 「本物のアーキテクト」, つまり建築に携わる人たちと我々がどのような接点を持っているのか, そこで彼我の間にどのような共通点と相違点があるのかを, 彼らの著作をざっくばらんに繙きながら探ってみようと思う. まずは1962年, 磯崎新の「プロセス・プランニング論」(鹿島出版会, 1997, 「空間へ」所収) より. 建築の計画概念には三つの段階があるという. 一つはクローズド・プランニング (閉ざされた建築), もう一つはオープン・プランニング (開かれた建築), 最後はプロセス・プランニング (プロセスの建築). クローズド・プランニングとは最初から完成した状態を予想して作られる計画 (設計) である. ソフトウェア開発で言えば, これは最初に最終成果物をきっちり設計し, それに向かって一目散に開発を進めるやり方だ. ウォータフォールでもインクリメンタルでもあり得る. 開発が終了したときがソフトウェアの完成したときだ. しかし私たち自身よく分かっているように, 実際にはクローズドなソフトウェアはない. 「保守は開発の倍のコストがかかる」というような口伝がそれを物語っている. それに対してオープン・プランニングとは最初から拡張可能であることをめざして作られる計画である. ソフトウェア開発で言えば, コンポーネントとかフレームワークとかオブジェクトとかを使い, ユーザに対してはプラグインなどのメカニズムを提供する. 現在の主流であるいわゆるモジュール化の技術である. プロダクト・ラインなんて言う考え方もそうかも知れない. 建築においては (この論文では図書館建築がテーマになっているのだが), できるだけ均質で同じ大きさ (グリッド) の空間を作ることによって増築や用途の変更がしやすいような建築物になる (ただしこの辺はソフトウェアとは多少事情が異なっているようだ). しかし磯崎新はオープン・プランニングに対して次のように批判する. オープン・プランニングには方向性がない, すべての用途の最大公約数に過ぎない, 「時間」が止まっている, というのである. もっともソフトウェアでは必ずしもそうとは言えないように思える. 例えばEclipseを考えてみればよい. そこには建築に較べてはるかにダイナミックなアーキテクチャがある. とは言え, アーキテクチャそのものがダイナミックに成長していくわけではない. いわばあらかじめ計画された範囲内での自由があるだけだ. プロセス・プランニングとは「時間的な推移の各断面が, つねにその次の段階に移行するプロセスあると考える方法」, つまり「成長する建築」である. ここで始めて「モノ」だけではない, (本当の意味での) 時間の概念が持ち込まれる. ソフトウェアで言えば, 時間とともにアーキテクチャそのものが進化していくようなソフトウェアである. 本当にそんなソフトウェアがあり得るのだろうか? 磯崎新は大分県立図書館での自分の経験をもとにこう言っている. 「その一つの操作としては, 図書館の空間体系を整理してみることであった. 今では図書館は複雑な機構をかかえこんでいる. しかし, その原初的な形態は<<人間が本をよむ空間>>だったのだ. (中略) タテのこのような空間の系列を整理すると私たちは一つのイメージをつかむことができる. それは<<空間を体系化>>することであり, これを可能にしていくのは<<機能の類型化>>ともよべる操作である」. これは私たちの言葉で言えばドメインのモデリングやアナリシス・パターンと言ってもよさそうだ. つまり少なくとも建築ではシステムの側よりはユーザの側に寄り添うことで, より時間を含んだ柔軟なシステムが得られる可能性があると言えるのかも知れない. しかしもっとダイナミックな「成長するアーキテクチャ」はあり得ないだろうか? 例えばアーキテクチャが明示的なモデルとして定義されていて, 実行しながらそのモデルが変更されていくような... 次の登場人物はクリストファー・アレグサンダー. 多分ソフトウェア業界でもっとも有名な建築家の一人であり, 言わずとしれたパターン言語の父である. 今回はアレグザンダーのパターン以外のアイデアについて見てみようと思う. (「クリストファー・アレグザンダー」, スティーブン・グラボー, 工作舎, 1989) アレグザンダーは, パターン・ランゲージを実際の建築のデザインに使ってみて多くの欠点があることに気付く. つまり「素晴らしく, 美しいパタンを多く身につけてはいても, 落ち着いた感じはなく, 満足のいくものではありませんでした」. これは私たちのソフトウェアについて同じような羽目に陥る場合が多い. 多くのパターンを知っていて, それをちりばめたソフトウェアを作っても必ずしも全体のアーキテクチャが美しくは見えないというようなことはないだろうか? アレグザンダーはそれに対して重要な二つの性質, 「一体性 (one-ness)」と「幾何学的特性」を見いだす. つまりアーキテクチャとは単に雑多なパターンをつなぎ合わせたものではない. よいアーキテクチャには例えばよいトルコ絨毯のテクスチャが持つような全体的構造があるはずだ, というのである (アレグザンダーはトルコ絨毯のコレクタでもあるのだそうだ!). いきなりトルコ絨毯と言われてもよく分からないが, アレグザンダーは12の幾何学的特性 (「まとまりのある空間的フィールドを創造するために相互に作用する特性群」) を提示している.
確かに建築は幾何学的な側面を持つ. しかしもっと抽象的なソフトウェアにとってこの「幾何学的特性」とは何を意味しているのだろうか? UMLモデルか? 確かにソフトウェアのアーキテクチャを何らかのダイアグラムに表したときの幾何学的特性が意味を持つかも知れない. ただしUML程度の抽象化の度合いではそこまでいけないようにも思える. 一方では例えばアーキテクチャを頭の中に思い浮かべるときには, 何かの「かたち」をイメージしていないだろうか? アレグザンダーはさらにこのような幾何学的特性を創出するためのプロセスも考えている. それが「センタリング・プロセス」と呼ばれているものだ. 例えばエクストリーム・プログラミングでは, メタファーとリファクタリングによってアド・ホックにセンタリング・プロセスを実現しているのかも知れない. しかしもう少し明確な「ソフトウェアのセンタリング・プロセス」は存在しないのだろうか? 今回の話は"?"だらけだった. 本当にこんな話がソフトウェア・アーキテクトに役に立つのかどうかすら分からない. けどあなたがある程度の経験を積んだアーキテクトならば, 再帰構造とか, 対称性とか, 汎用性にきっと快感を覚えるでしょう? それにはいったいどういう意味があるんだろうか? 次回からはまたソフトウェアの話に戻って, もう少し具体的なアーキテクチャとプロセスの関係を調べていこうと思う. |