中村 では「アーキコモンズ」の成り立ち、特に「資源としてのデザイン」という考え方について聞かせていただけますか。
連 「アーキコモンズ」を思いついたきっかけは、大学時代に出会った「コモンズ論」という考え方です。1960年代に、地球上の資源が有限であるということが世界的な関心になりました。そうした中、生まれた理論の一つがアメリカの生物学者、ギャレット・ハーディンによる「コモンズの悲劇」2です。これに対し、同じくアメリカの経済学者、エリノア・オストロムは、地道なフィールドワークをもとに、コミュニティの構成員による不断の改善の積み重ねで上手に自然資源が長期的・持続的に管理されている事例をたくさん集めてきました。資源をどのように共有するのかという問いは、情報化技術が進む現代においてますます重要な問いになってきています。
2.多数者が利用できる共有資源が乱獲されることによって資源の枯渇を招いてしまうという経済学における法則。 共有地の悲劇ともいう。
さて、もうおわかりの通り、「アーキコモンズ」は「アーキテクチャ+コモンズ」で作った造語です。コモンズ論の考え方を、建築領域へ移築したいと考えつくりました。建築プロジェクトに関わる人が、設計プロセスを形作っていくための体系だった方法論を作り出せないか、そういうような問題意識でした。多様な主体が、共有構造を作っていく知性や技術を開発すること。
「アーキコモンズ」という発想は、学部三年生のときに思いついたものです。そのため、卒業制作も「アーキコモンズ」をテーマにしたいと考えました。しかし理論的な提案は、実際に検証されなければ説得力を持たないと思い、企画書を片手に実施プロジェクトをやらせてくださいと、いろいろな企業に営業してまわっていたところ、多くの出会いがあり、木造物件の改修を手掛けることになりました。そこで大学の内外から学生を募って「木造賃貸アパート再生ワークショップ」というプロジェクトを立ち上げました。当時はWikiを作って、プロジェクト中のやりとりをすべて記録し、制作のアーカイブを作るという方法を試したりしました。
中村 それが現在のモクチン企画のルーツですね。
連 そうです。そのあとの修士研究も、引き続き「アーキコモンズ」をテーマにしました。卒制を通して、「アーキコモンズ」の在り方としてはWikiなどのナレッジベース3で管理された共有知のようなものを暫定的を想定していましたが、まだ方法論と呼べるレベルにはありませんでした。そこで「コモンズ論を下敷きにした建築方法論」という原点に立ち返って、あらためて「アーキコモンズ」を考え直したんです。関連書籍を深く掘っていくうちに、コモンズ論における「資源」の対応物として、改修時の思考や経験をアイデアの単位で外部化するという方法を思いつきました。アイデアをあるフォーマットに記述することで、それ自体が共有可能な資源になると面白いと考えたのです。当然、パタンランゲージにも強い影響を受けています。そうして修士二年の頃に「モクチンレシピ」が出来上がります。
3.ナレッジマネジメントのための特殊なデータベース。知識の検索を可能とし、知識を組織化し、知識をコンピュータ上に集合させたものである。
中村 資源を管理する方法を取り扱うコモンズ論に合わせて、建築的なアイデアを管理可能にするために生み出されたのが、デザインをフォーマットに記述するという方法、すなわち「モクチンレシピ」だったと。
連 そういう意味では、「モクチンレシピ」は実践から生み出されたプラクティカルな「ツール」というよりは「理論の所産」です。今振り返ってみると、この時考えていたアイデアの資源化というテーマは、ある程度実現してきたように思います。
中村 では冒頭の問いを別の形で聞いてみたいと思います。「モクチンレシピ」を通した、在来工法による生産の“ハッキング”についてです。この試みは本当に達成し得るのでしょうか。ここ数年にわたる理論の実践を通して、連さんが得た気付きはありますか?
連 「モクチンレシピ」を公開するだけでは十分ではない。そのままでは使われない、とういことですね。中村も、その問題を解決するためにいろいろやってきたと思います。これは結構大きい問題で、『10+1』4に寄せた論考でも少し触れました。そこでは「生成力」という話をしています。
「生成力を設計せよ──1968年のC・アレグザンダーへ」(http://10plus1.jp/monthly/2015/03/issue-03.php)
ちょうどこの連載の第2回でも触れられていた建築家・デザイン理論家のクリストファー・アレグザンダーは、初期の頃には「合成」という言葉でシステマティックにデザインを論じる人だったのが、無数のワークショップや実作での挑戦を経た後期ではもっとウェットに「生成力」と言い始める。彼のニュアンスはちょっと違うかもしれないけど、デザインが生み出される状況を作るには、その周辺の「社会環境」まで含めて考えないといけないということだと思います。「ビルダーズ・ヤード」や「セルフ・ビルド」といった彼の後期のキーワードは、そうした問題を巡っている。理論としてみれば、定性的な側面が増えたことで後退しているように見えるけれど、僕からみればそこまで責任を持つ、ということ。どうしたら資源がちゃんと使われるようになるのか、管理・運用も含めて建築家が面倒を見切れるのかが問われています。今後、経済活動でいえば「サービス」のような言葉が当てはまる仕事に、建築家はどう向き合っていくのか興味があります。
中村 モクチン企画として「モクチンレシピ」を運用するときに、誰も使ってくれないという問題。前期のアレグザンダーが結果的に使われなかったこととパラレルにみえるし、その失敗はむしろ現代的な問題を突きつけていると。
連 そうです。建築のオープンなシステムに興味を持ってやってきたらこうなったね。
Copyright © ITmedia, Inc. All Rights Reserved.