拡張する空間 建築家とITアーキテクトがつくるもの

著者 : 藤本壮介 鈴木雄介

• コム・ブレイン (2010年4月2日発売)

感想・レビュー・書評

[zerobaseさんの感想 · 2011年9月18日]

（※まとめは http://j.mp/rnObW5 ）

建築物より名前・主義主張・表現・ある価値観の枠組みが残るようになってきた。建築は「図書館はこうあるべきなんじゃないか、だとすると、こういうつくりかたになるんじゃないか、というところまで掘り下げる役割」かも。新しい提案の枠組みを作ることの魅力。枠を壊したい。こういうつくりかたとか、こういう考えかたで建築ってつくれるんだよ、と。ものをつくる方法自体を変換していく。考え方自体を変えていく。授業で早い時期にモダニズムの歴史とかをたたき込まれる。人がうごめている様子を考える。複数の人が動いている。関係性。コミュニケーション。模型にする。自分でもよくわかっていないものが形になってくる。モデル化。機能主義。それを超えようとするポストモダン建築。帰納的で無い要素の根拠は何か。コード。生成力。プラットフォーム。宣言（SOA、アジャイル、メタボリズム）。情報感覚と情報空間。アフォーダンス。機能主義は動線を短くする。距離を縮める。離れていることによって価値が出てくる状態とか、物理的に離れていなくても心理的に離れているような状態を建築はつくることができる。離れているけれど、声は聞こえるからコミュニケーションはとれるといった。いままでの建築は、距離をつくるときに、ぼんと壁を一枚立てて、こっちはこっちで、あっちはあっちというやり方。それは乱暴すぎる。距離感。

ツリー構造、オブジェクト指向、コンテナ、イベントというのは、それぞれ使い分けできるもので、どの部分に何を、どういうパターンで当てはめていくかによって、ソフトウェアの塊をどういう強さで管理してくのかを調整する（鈴木）。アレグザンダー、ポストモダニズム、関係性の概念。ソフトウェアの標準化、再利用性はしかし関係性の再利用をしなければならないので難しい。クレジットカードのオーソリゼーション(CAFIS)は世界中で関係性が安定しているから再利用性が高い。関係性を安定させられるかというのが問題。言葉にならなくても構造化されうる。言葉で説明したように構造化するというのは、それは言語の構造になっちゃっているような気がして、ちょっと物足りない（藤本）。論文みたいな建築。建築ならではの構造化のされ方みたいなものの新鮮さが欲しい。名付けえないものが立ち現れてくるような感覚。QWAN。アルゴリズム。非常にシンプルな基礎アイデアをかけあわせていくと、不思議なというか、より生っぽい、自然っぽいかたちになるというこの感じは、自然を意図的に解釈しようという意思から生まれているような。

ソフトウェアに対する理解不足。街を歩けば建築現場があり、むき出しの鉄骨や建機を見かけることで、建築の構造や構築方法を知ることができる。しかしインターネット上で工事中のソフトウェアに出会うことは無い。「建築は動かないがソフトウェアは動く」という指摘は本質的では無い。「動く」とは使われることで利用者の目の前に繰り広げられる現象である。（１）ソフトウェアは人が情報をデータにする／データから読み取るための媒介である。（２）ソフトウェアの構造とは、情報の”型”と”型の操作”の構成である。（３）ソフトウェアの構築方法とは”型”と”型の操作”の構成をプログラミング言語で組み立てることである。プロセスとして捉えるならば、我々がやっていることは、実現したいソフトウェアに対してその周辺にあるさまざまな情報の中から型や操作の構造を発見し、それをプログラミング言語で実現されたソフトウェアの構造として構築することである。その二重の構造を同期させることがわれわれの大きな目標（…）アーキテクチャは、この二重の構造そのものであり、ＩＴアーキテクトの仕事は二重の構造をつなぐデザインによって評価される。（鈴木）

住宅の場合には、最初はブレーンストーミング、制約を気にせず、頭をやわらかくする。人が活動する場所としてどんなつくりかたがあるか、どんな楽しいものが作れるか。言葉やスケッチ。ラフな模型など。なるべく「建築」にならないように。壁・柱・天井・ドアなどに頼らず「閉じた空間」になるように。人間に対してちょっと優しくないやつを作りたい。最後までこの場所を理解できなくても、なんとなく使えてしまうような。建築を機能的に作っていくと至れり尽くせりになる。いろんな人がいて、いろんな使い方をするから、至れり尽くせりは嘘くさい。逆に可能性が制限されている。むしろどかんとハコをつくって、可能性を広げられるような。場所の抑揚。かすかに知覚できる何か。施主がどんな生活をしてるか聞き取り再解釈する（藤本）。アフォーダンス。図書館は複雑。検索性と偶然性。設計プロセスにおけるジャンプ。本の木。偶然性を重視しすぎ。エントランスまわりのプラン。図書館のことを自分たちが全然知らないと気づく。機能の相関図。結局どんな図書館をつくりたいんだろうということろに立ち返る。図書館らしい図書館。本の木が立っていて本だらけ。壁が全部本棚でぐるぐる。ボルヘス『バベルの図書館』。コールハースのフランス国立図書館コンペ。２０人に説明。謎が深まるプレゼン。建築の奇妙な美学。広い部屋ならなんでもできるがダサい。タイトなプランは冗長性が無く、要求の一部が変わると全体が破綻する。方法として破綻する。そういうタイトなところで、ここで起こることを鮮やかに秩序化したりできると、より美しいという美学。ポジティブな不自由さは、なんだか知らないけれど遺跡みたいに立ち上がっているというような感じが生まれてくる不自由さ。語り得ないもの。「人為を超えた」存在感。本棚のぐるぐるにルールは無い。作り手の方法論だけ暴走してはいけない。利用サイドの体験レベルの新しさとのバランス。アルゴリズミック・アーキテクチャ。理由が無いけれど秩序はあるという状態を建築は許容してくれる。関係性が無いのが重要だ。関係性が無いという関係。関係性の意図的設計と創発。QWAN。作り込まない遊びの部分を楽しむ。厳密に作られた建築の息苦しさ。フリーハンドのドローイングで決めた線。よくわからないけど、その場に行くと身体的に納得できる。人工物を作るプロセスと、自然のものが勝手にできるプロセスの間。おそらく建築家というのは、模型を見れば縮尺がすぐ分かるように訓練されている。その模型で作り込まれている状況を見れば、そこに身体がすっと入っていけるようになっている（藤本）。記号、圧縮（コーディング）、再現／再生（デコーディング／プレイ）、プログラム。大きなものは物語・ストーリーとして理解する。システムはディテール本位で、先に詳細から考えて、裏付け・説明として上段を後追いで書く。建築のプロセスと違う（鈴木）。模型の縮尺を行き来する。最終的に1分の1を作る。建築の場合は、最後が1分の1の実物を想像しているから、論理構造として下りていくという感覚はあまりない。細部を作り込んでいくという感覚はあるけど、最後はやっぱり実体験するものとして見ているので、それは大きな流れの中に入っているような気がする。ソフトウェアはひたすら1分の1をつくるための図面を引いている。設計はものづくりと同じ。1分の1の設計作業が終わったとき、図面が引けた瞬間には、もう実物が出来たのと同じ。建築でいい加減に線を引いているようないいかげんさは許されない。全体性に対する感覚はどこかにあるか。建築模型は神の視点で外から見られる。CGは視点が自由では無い。ソフトウェアにその意味の全体性はない。身体的リアリティはない。大きなソフトウェアはチーフ・アーキテクトも全体を把握せずに作っている。人工物の歴史の中で初めて全体がないエリアになりつつある恐ろしさ。人がインタラクションして初めて存在する。

インタフェースを考えることは、人間とはどういう生き物なのかを考えること。人間の本性をあぶり出す作業だろう（藤本）。

建築が即物的にコミュニケーションに傾向性を与えることが出来るように、ソフトウェアも即物的にコミュニケーションに傾向性を与えうる。しかも気配なく。最終的なインタフェースは身体。ホテルでカウンターの中だけで参照できるようにした。ホテルマンの豊かなコミュニケーションを向上（人間拡張）。一流の職人が使い込んだ道具に話しかけるように接するかのごとくソフトウェアを道具にするためには気配が必要。いまのソフトウェアは視覚的な表現に頼りすぎている（鈴木）。

[ichiro.marinersさんの感想 · 2018年10月23日]

ソフトウエアは、建築に例えられることが多い。しかし、このアナロジーを当然のこととして受け入れることは、私にはできない。その理由は、建築がその成果物を一望できることに対して、ソフトウエアを一望することは不可能であるからである。この違いにより、アーキテクチャーありきのトップダウン思想と、部分の集まりがアーキテクチャーを織り成すというボトムアップ思想の両端にそれぞれが位置する。　本書における、建築家とソフトウエア・エンジニアの対談に、読むべき点があるとすれば、このことに言及した鈴木雄介の発言。この思想的対立を見事に喝破しているその内容は、この人物がそれなりのソフトウエア・エンジニアであることを裏付けている（ソフトウエア・アーキテクトと名乗るやからには、怪しいやつが多いので）。　逆に言うと、この視点的違いを理解している人は、この本を読む必要は無いと思う。という意味において、私には読む必要のない本であった。

[bukubukubukuさんの感想 · 2011年10月11日]

なんとなく、ITがつかめるかんじかな。あと、建築家だけではないだろうけど、作る人は読んだ本に影響をすごくうけるんだなぁと、当たり前だけど建築家藤本氏の好きな本が書かれていておもしろかった。

[イトジュンさんの感想 · 2010年11月19日]

建築家とITアーキテクト。構造物を設計するという共通した職能を持つ2人による対談を記録した本。

建築家らしさ、ITアーキテクトらしさは良く出ており、それぞれに対する理解を深めるには役立つかも。ただ、建築とITが相互に作用することで生まれる「何か」については、期待に反して見出すことができなかった。

「コミュニケーションの離れ具合」「つくり込まない遊びの部分を楽しむ」などの論点を共有しながら対談が進んでいくのは興味深い。

[takahashimasさんの感想 · 2010年8月29日]

ITアーキテクトと建築家、面白くなりそうな組み合わせながら、議論がすれ違いがち。うーん、という感じだが、逆に「ちがい」がわかるという意味では有意義であったのかも？

[ひろさんの感想 · 2010年5月3日]

んー、微妙。

建築×ITという自分にとっての
大命題に近づけるかという思いから
即買い。

しかし微妙。
語り合う中からいまいちこれという
答えは見出せなかった気がする。

建築も情報技術を使うサービスも人間が使い、
ある種の場所をつくり、感覚で理解するものと言うのは、
今さら語るまでもないことであろう。

建築家として考えるべきこと
情報技術者として考えるべきこと
はそれぞれ役に立つ気がする。

したいことからどう作るかに落とし込むところとか、
とにかく作ってみようとか。

最後の鈴木氏の後書きにあったオークラの例が好きだ。
飛行機の遅延情報をあえてロビーに出さず、
カウンターの中だけに留めたという。

こういうデザインが
まさにアーキテクトの仕事だと私は思うのである。

使うのも行動を変えるのも
全て人間なのだから。