"持続可能な建築設計"の建築設計論 (1)
✴︎
1. 設計者の基本的ポリシー
◆ プロジェクトには、様々に特有の事情がある。「顧客の要求を満足する」という観点からみたとしても、顧客が様々な立場から要求を行う為、設計者はその要求の背景にある欲求や問題意識、目的を理解することが最低限必要になるのだが、顧客の性格は以下のように大別できる。
・顧客が建物の使用者である場合 (ここでいう使用者とは、滞在する張本人である)
・顧客=建物の管理者であり、主な使用者が管理者の制御下にある場合
・顧客=建物の管理者であり、主な使用者は管理者と平等な契約関係にある場合
・顧客=建物の管理者であり、主な使用者が不特定多数の人間にある場合
・顧客=建物の開発者であり、建設後は、その建物を別の第三者的な（＝ドメスティックではない）管理者に売却,貸与する場合
ここでは顧客とは出資者である。しかし同時に、「建物の仕様やデザインのテイスト、形態的な部分において最も緊密に設計者とともに意思決定を行う人間」である。このように、いわば、プロジェクトの行き先に責任を持っている人間のことを、ここでは顧客と定義する。
此の顧客がその価値基準において、「開発の立場の意見、管理運用の立場の意見、滞在し使用する立場の意見、それらが相互に対立が発生したときにどれを優先するのか、何を重要項目と位置づけるか」は、まさにプロジェクトにより異なる。（プロジェクトの固有性）
※今回設計論の対象とするのは、「継続的事業」としての建築プロジェクトである。いわば、時間的な広がりをもった建築事業に対する設計論である。
複数展開するシリーズものの設計、リノベーション、マスタープランを有する複数の計画、増築・改修が見込まれる建築物、将来像を有する構想としてプロジェクト、小さなアクションから徐々にスケールアップを見込んでいる事業、または、実験や検証を介して妥当性や方針を修正しながら進めようとしている一連の空間・環境の改善計画などがこれに該当する。
こういったプロジェクトは、要件の中に、設計されることそのものに対する持続可能性というものが含まれている。
言い換えれば、こう言ったプロジェクトでは、建築設計の中で意思決定が循環的に発生するか、または偶発的な対応としての意思決定が必要となる。
こういったプロジェクトにおける合意形成プロセスでは、共通の了解を積み立てることが必須だ。今回は、その知識の生産のプロセスと、そのノウハウに焦点を当てる。
◆ 顧客の目的が、個人の生活の福祉である場合と、法人の事業である場合とでは、プロジェクト理解に求められる知識の種類が大きく違う。
後者の場合、利益を生み出すためのロジックや、仕事の効率化、人々の行動様式への適応が建築計画に深く関わってくる。普遍的な空間を計画する場合でさえも、仮想のビジネスロジックが発生する。そして、そのロジックは、建築計画を適切なものにする為に学習し、これに適応する必要があるものである。これらの知識に関して、設計者は必ず、1人以上、その知識に詳しく、内的事情や何が課題であるかが頭の中に入っている専門家的人物を設計の協同者に加えなければならない（その人物が建築に関する知識を持っているかどうかは別として、その人物はプロジェクトのキーパーソンの1人である）。
◆ 設計者は、"設計上の概念モデル"を提示する。モデルは、設計サイドとして事業に関わる人たち(基本設計者、実施設計者、家具デザイナー、インテリアデザイナー、照明デザイナー、ランドスケープデザイナー……、施工管理者)全員が使用する言語の基盤である。このモデルは、建築物の詳細な設計・施工レベルと密接に結びついているが、しかしながら、協同者と「通訳せずに」コミュニケーションをとれるための言語基盤となることが要件となる。
設計上の概念モデルは、時に建築物そのもののモデルであったり、時に建築物に関連する情報のモデルであったりする。言い換えれば、そのモデルは知識であり、取り決めであり、コンセプトであり、建築物の運用プロセスを定義する体系である。このモデルをどれだけ深く追求し、簡素な・核心的なものとし、空間の配列から仕様までの様々な部分に反映できるかが重要だ。設計上の概念モデル（以下設計モデル）は、最終的にはツールでなければならず、実用上の厳密性と意味の豊かさを両立させなければならない。
※設計モデルは、協同者とともに改良を進めなければならない。検討の数と、コミュニケーションを通した空間要件への理解度に応じてモデルは成長する。根本的にはモデルの言語基盤にある用語をそのまま使って文章にまとめ、通訳を介せずに正しく理解し合えるようになることが、設計を改善する議論を最も活発化させる。
※設計者は往々にして、コンセプトが「どう機能するか」を語りたがり、しかし顧客はコンセプトが「私たちにとって何を意味しているのか」に関心がある。
協同者との会話においては、それぞれの役割に注力しなければならない。建築プロジェクトを説明する用語や事業構造に対して、協同者はそれが不適切な場合、あるいは重要な意味が欠如している場合、明確にそれに異議を唱える必要がある。そして設計者は、建築プロジェクトを説明する用語や構造に対して、それをかたちにする為に邪魔となる矛盾・不整合・曖昧さを質問し、明示的な理解を深め、（協同者とともに）信頼できる言語基盤を作らなければならない。
その言語基盤に求められる基準とは、「会話だろうが書面だろうが、いつでも・どこでも・簡単にコミュニケーションに使用できる」ことだ。もしその基準を満たさないならば、言語基盤の問題を協同者とともに、議論の俎上に取り上げる必要がある。まず、新しい言葉に変更しなければならない。そして、新しい言葉に応じた抽象的構造と、その体系を設計に活用するシナリオを会話の中で検討（エスキース）し、モデルを更新しなければいけない。
※時々、「建築家は抽象的すぎる」と顧客は思っている。そして、「クライアントは要求が抽象的すぎる」と設計者は思っている。しかしどちらが正しいかと言えば、それはクライアントである。事業を深く検討している事業者のほうが、このプロジェクトに関する豊富な知識を有すると考えるのが自然だ。認識の違いは、コミュニケーションのぎこちなさに起因している。そして、事業に対する理解は、設計者を通して事業者の中でも深まっていく。健全なコミュニケーションと共通の言語基盤の模索があれば、学習と発見は両者が共に経験する。本来、１つのチームはこの状態になることを目標としなければならない。
◆ 説明のための図は簡素でなければならない。必要なものはたったの数個の要素の問題の連なりである。余計なものがなければない程よい。包括的・網羅的であることを求めてはならない。図に文章を足し合わせて要素過剰な図を作るのではなく、文章は物事の注釈を行うものとして、図は図として選び抜かれたシンプルなものとして、並列させるのが良い。（説明図と文章の意識的分離）
文章によるコミュニケーションはあくまで設計の補完であり、あるいは会話の補完であり、それらの活動の役に立たなければならず、時系列的な保証と最新性を担保できる書式としなければならない。（不必要ドキュメントの削減）
※設計モデルは、（人々の集中を喚起し議論を触発するための）シンプルな説明用の図と別物であることを理解しなければならない。あくまでダイアグラムは後者である。（説明図と設計モデルの意識的分離）
・設計モデルとは、幾つかの物事の関連性であり、C.アレグザンダー流に言えば、いくつかの要素からなるサブセットの組み合わせである。
・設計モデルとは、空間のプログラムと経験を支える抽象的構造である。
・設計モデルは事業のある側面に関しては捨象し、その捨象した部分を「このモデルの境界の外にある」とみなして外部化する。外部化した事物は、モデルの言語基盤で説明できなくてもよい。事業者はこの外部化された部分も理解しているが、しかしながら本事業に関して問題となる部分ではないと現時点でみなされているため、モデルの取り扱う領域の外に置かれる。重要な概念を全て最初から取り扱う必要はない。重要な概念が、協議の中で見直され、追加されるたびに、設計モデルの境界はモデルと共に都度更新すれば良いのだ。
・設計モデルに関して、設計者はその整合性とフィジビリティを確保するよう議論を重ねる必要がある。
・技術的観点からみても、コミュニケーションの観点から見ても、設計モデルは、複数あってはならない。他のモデルが必要とされる場合、以下の二つの場合がある。
1 説明のための部分モデル : 親モデルの部分集合であり、特定の話題にフォーカスしたモデル。要素や連関の幾つかを間引き、分かりやすく文脈を示すためのモデル
2 複数のチームがあり、それらが責任と契約・建築の物理的範囲において明確に境界付けられている場合、それらのチームがそれぞれ構築するその他のモデルであり、モデルの適用範囲が相互に保護されているもの。
◆ 建物の運用に関する技術的なノウハウを設計者は有するべきである。ここでいう技術的ノウハウとは、「空間としてそれをどう実現するか」に関する知識である。
モデルが直接反映されて作られた建築は、建築作品である。このような建築作品は、空間の骨格が建築物の使用者に伝わる。単に行動を誘導するだけでなく、使用者にある種の知識を伝えることができる。このような空間は、持続可能な建築設計における次の仕事を大きく後押ししてくれる。
◆ 多段階にわたるプロジェクトでは、設計モデルを、「実施設計者」や「次のプロジェクトの設計者」に引き継ぎする必要がある。しかし、モデルに込められた意図や本質的部分を引き継ぐことは困難だ。
モデルの意図や本質的部分を引き継ぐ為に一番重要なのは、設計責任を構想部隊と実働部隊とで完全に分離しないことだ。なぜならば、責任が完全に分離してしまうと、構想側は実働の手本となる仕様的詳細部を提供できないからだ。また、詳細部の設計から得られる設計モデルの改善という基本的なフィードバックがなされないため、設計モデルがプロジェクト過程で急速に"過去のもの"になってしまい、レガシーとしてリスペクトされることはあれども、実用上不要なものとみなされてしまうからだ。
そうやって二つの関係が無関係になってしまった時、実施設計上の制約に対する感覚を設計モデルを構想する主体は失ってしまう。
これは教育的観点から見ても持続可能な建築設計ではない。知識とスキルが、ディテールに対する機微が設計者同士で伝達されないまま、仕様だけが一人歩きしてしまうからだ。
事業者（協同者）と共に建築の基本計画を立ち上げる構想側の立場にある設計者はだれでも、実施設計と現場に触れるため一定の時間を投資しなければならない。（逆にいえば、そういった設計の下流にある立場の実働設計者が設計上のモデルに関する議論にいずれかの段階で参加して、最も事業を理解している協同者と話をする機会を設けること、そういう機会を作れる体制を整えることが重要だ。）
✴︎
2. 設計技法
この設計モデルの議論をコミュニケーションに関する部分から真っ先に行ったのは、設計モデルの核心を先に説明したかったからだ。
この設計モデルについて私は、いわゆる "BIM(ビルディングインフォメーションモデリング)" とは距離をおいて説明している。BIMは学術的に信頼のおける用語ではなく、むしろ流行語に近い。BIMが指すものが本質的にプロセスなのか、それともデータなのか、データ駆動の建築生産姿勢のことなのか、或いはソフトウェアのことなのか、人と文脈によって言うことはバラバラだ。このような概念は議論を活発化させる為には必要だし、Web検索を行う人が自身の曖昧な関心に沿って情報を得る為にも必要だ。しかし、設計モデルはBIMに包含されるような対象ではない。設計モデルの核心は、前章で述べた点にある。
ただ、設計モデルにはBIMとしばしば酷似した用語や表現を用いることがある。例えば、設計の内容に関わる仕事には、実務的に2つの仕事がある。「決める作業」と「決まったものを実装する作業」だ。実装という言葉は、BIMを想起させるかもしれない。
重要な共通点は、両者がオブジェクト指向であることと、取り扱う時間スパンを従来の建築生産（建てて終わりの建築生産）よりも拡張している事だ。ゆえに、持続可能な建築設計が持つ顧客参加型デザインという方針は、本来ならBIM思想とは両立し得るものである。
ここからは重要な違い、すなわち以下の点について検討する必要がある。
BIMは、LODに基づき、設計上の詳細度合いを高めていく、手戻りを許さない設計プロセスとなる。また、BIMにおいてはモデルは実装そのものがコストである。フィードバックは少なければ少ないほど効率的であるし、無理に全てをモデル化する必要はない。一方で、持続可能な建築設計は開発がイテレーティブ（反復的）であることを指向する。修正することを前提としているというのは勿論のこと、ビジネスロジックに対する認識や「状況」が変化する際にも、過去のモデルを書き直すことを是とするのだ。
イテレーティブなデザインは、工期の見積もりを困難にさせ、手戻りや変更に伴う費用を増大させてしまう傾向がある。イテレーティブデザインにおいてもフロントローディングの仕事の進め方は可能だ。しかし、フロントローディングの思想により初期に行われた詳細の設計検討は質が高い一方で、変更に伴い終盤に行われる詳細の設計検討は吟味する時間があまりに短いことが問題だ。この際限のない仕様変更に直面してうんざりした仕事の経験がある人からすれば、その仕事を経験後にイテレーティブなデザインそのものを忌避する態度になるのは当然だ。
この点を理解していないと、設計モデルを運用することに挫折することになってしまう。
例えば、際限のない仕様変更をコントロールするために、「柔軟な変更ができるにも関わらず、いかに変更できない理由を作るか」「変更の提案をどのタイミングで持ち出し、何と相殺させるか」といった、設計コストを納める為の合意形成業務が、設計業務の多くを占めるようになってしまう。これは、顧客と設計者が対等な立場でない文化圏では設計者側によって暗黙的に行われている。これでは一体、何を目的として設計しているのか分からなくなってしまう。
それでは、反復的であると言うことの優位性とはなんだろうか？
まず指摘したいのは、LODをきちんと辿る設計プロセスにおいても、現場が始まってからも変更負担の大きい変更は発生するということである。これは顧客の要望そのものの変遷によるかもしれないが、その顧客を取り巻く激しい環境変化により発生する方針の変化であることもあり、誰かを説得すれば回避できるものでもない。そういったなかで、これまでの設計モデルを覆す根本的な設計変更が必要であると誰もが感じた時に、プロジェクトを納めるためにそれを抑圧するか、それを避けられないものとして受け止めるかといった２択に迫られる。持続的事業においては、変化への順応は遅れれば遅れるほど、厄介な問題ごとへと膨らんでいく。
"持続可能な建築設計"は、避け難い変更に備える為に最初からイテレーティブデザインの体制を作っておく、言い換えれば「初期対応に備える」姿勢であると言える。
ここでは、設計モデルをどのように建築にしてゆけば良いのか、いくつかの支援技法を動員する。
◆値, 属性, 特性
建築の構成要素には、ある種のまとまりをもって理解すべき要素と、さらにその要素を細分化したものがある。それらが多重に仕様を有している。たとえば、ガラスは個別の性能を有するが、ガラスと枠で構成される窓には窓としての性能がある。
オブジェクトには値を設けるだけでなく、オブジェクトの複数のまとまりに対する属性を設けること。そして、オブジェクトグループに対して〈構造としての〉特性を与えること。
BIMでは、非重複な要素で全てを並列に扱って包括しようとしないのが基本となる。複数のヒエラルキーにおいて、重なりを許容することが大事だ。
◆サービス
使用者にとって、空間の印象と意味とが重要であり、建築物のなかにある機能と構成要素が重要ではない。機能と意味とを接続するのがサービスである。
ここでは利用者のBEHAVIOR(ふるまい)を、適切に建築の空間操作に落とし込むプロセスが必要になる。こういったものは建築物の物質要素として概念化してしまうと、建築要件に"意味のない" 不自然な物質要素を追加することになってしまう。サービスは、建築物の構成要素である物質そのものの物性や形式からなるのではなく、どのように建築が活動を提供するのか（こう言った観点は環境面に限定した場合はアフォーダンスであり、運用面を含む場合はサービスと言える）に着目する。
◆モジュール
モジュールは、「分割による分担」と「まとまりによる凝集」の二面性を持つ概念である。
「分割による分担」とは、概念のもつれをほぐすようにモデルを変更する事である。
「まとまりによる凝集」とは、意味のある方法で要素をまとめられるようにモデルを変更する事である。
この二つを繰り返す事で、設計モデルは理解できない複雑なものから理解しやすいコミュニケーションツールへと改良できる。
言い換えれば、この二つの処理を通して、概念どうしの相互関係ができるだけ疎になるような分割を行う事こそが重要であり、それによって「全体の設計」という複雑で負荷の重いタスクを「モジュールの設計」という比較的頭で容易に扱える程度のタスクへと置き換えることができる。モジュールは最初は誤った設定になることが多く、フィードバックを繰り返してモジュールの設定を見直していく変更作業を行う必要がある。
◆生きた設計モデル
設計モデルでは、要素の生成と消滅が繰り返され維持すべき不変条件をある特定の要素に担わせるのは困難だ。軸となる要素・中心に据える要素を確定できない。何が作られ、何がなくなるのか分からないし、それがいつ起きるのかも分からない。そのせいで、間に合わせの設計作業を繰り返しては、それそのものが無意味な仕事になる(再利用されない)ことが多い。人件費の無駄遣いである。
最終的なモノ決めは発注時に確定するが、持続可能な建築設計においては確定させるまでのプロセスにおける対応に関心がある。図面の参照関係に対する運用方針や、仕様の変更時の波及範囲への一括変更を可能にするための設計図書の作成の仕方が問題であり、BIMの場合はどのようにワークセッションを行うのかが問題である。
そのために必要なのが、集約であり、不変条件が維持されるべき範囲をオブジェクトとして定義することである。特に、パラメトリックデザインを行う際には予め、集約の定義が必要になる。そして、この集約は同時に「窓口」としての役割を担ってもらう。すなわち、
・パラメーターの変更時には、各集約に対して変更の窓口を経由して制御すること
・内部のメンバーに対する変更のアクセスを厳しく管理し、保護すること。
が役割である。この取り決めにより、設計変更の際に不変条件をすべて不変のままにするこ
が可能となる。
既に発注してしまったものを変更することは基本的に要相談(原則不可能)であり、建築生産過程での決定済事項は不変条件であり、あらゆる設計上の知恵はその不変条件をむしろリソースとみなし、その活用を前提としなければならない。こういったときに、不変条件が維持される範囲は刻々と変化する。
すなわちこれは、可塑的な体をとる当の集約オブジェクトをできるかぎり可視的な形式とし、人間のコミュニケーションに活用できるものにする必要があることを意味する。
✴︎
3. 実践
実践に関しては、設計作業の中でデザインと言語とのあいだにどのような相互刺激が発生したかという点で評価できる。これについては、"持続可能な建築設計"の建築設計論 (2)にてまとめる。
✴︎
参考文献
Eric Evans 著 「エリック・エヴァンスのドメイン駆動設計」 今関 監訳 和知、牧野訳
※1章、2章についてはそのフレームワークが建築においても本質的に重要であるため、建築のコンテクストに置き換えてそのまま本記事に文章構造を採用した。3章以降についても考え方や疑問の作り方、仕事の中でのあるあるについては全面的に踏襲しつつ、語弊を避ける為にそもそも全く異なる用語を定義し直した上で、実質的に同じ意味の説明を行った(ex.モデル→設計モデル、ビジネスエキスパート→協同者、ユーザー→空間の利用者、ユビキタス言語→共通の言語基盤)
物の言い回しが原著と酷似していることは問題であるため、できる限り建築の文脈に置き換えて言い回しを若干変更したが、それでも残ってしまっている問題点についてはコメントに対して随時訂正を行う。
