建築生産の歴史と展望(後日談)【その1】
この記事は「建築生産の歴史と展望」の論文を執筆した2人が、とりとめもない雑談をしつつ論文の内容を振り返るという対談です。
今回は、全3回のうちの第1回です。
前回の記事はこちら：日本におけるBIM活用について【その2】／あとがき
登場人物
押山玲央 / Reo OSHIYAMA
株式会社白矩 代表取締役、東洋大学非常勤講師
中村達也 / Tatsuya NAKAMURA
ゼネコン設計部
自分の興味の赴くままにやっている
中村：白矩では、ゼネコンの生産設計業務をコンピュテーショナルな手法で支援する、みたいな仕事が多かったと思うけど、最近はどんなことやってるの？
押山：最近は「複雑な建築を複雑なまま建築するために設計段階でどういう情報の整理をしたらより合理的な設計フローができるか」みたいなことに興味があって、そういうことを調べて設計支援ツールみたいなものを作ろうとしたりしているね。
中村：どういうツールなの？
押山：おもに意匠の範疇になる法規、構造設計、環境シミュレーションの三つだね。それぞれの基本設計段階でどういうことを決めているか、情報としてどういうふうに整理してデータ化しておくと合理的なのか、みたいなことを調べてる。最初は構造設計について調べて、構造設計をやってる実務者の人と一緒にワークショップみたいなこともやってみたんだけど、意匠設計と構造設計シームレスに繋げて自動化するとかは無理だと思った。
中村：一般的に構造設計は、意匠設計に比べると合理的に物事が決まっていくイメージがあって、実際に構造設計の過程を自動化しようとする試みも世の中にはあると思うんだけど、どう難しいの？
押山：まず構造設計のソフトって直観的な操作が出来ないしそもそも編集を前提としてソフトではないと思うのね。だから意匠の変更あって構造が変わるとき、仮に千本の線があったしたら、その千本は数珠繋ぎで一個一個見ていく必要があるんだよね。それをカチカチ設定しながら整理していくってものすごい手間のかかることなんだけど、意匠側は普段自分達が扱っているソフトはもっと直観的に操作ができるから、てっきり構造側でも意匠と同じように直観的にバンバン変更できると思っている。だから意匠と構造のタイムラグが発生していることが理解されずに、実施設計が完了する頃には意匠と構造が乖離しているという現象が起こるんだよね。で、これを解消するためにどうするかというと、基本設計段階で構造計画の大まかなストーリーを決めておくのが大切。かつ構造計算ソフトの入力はあくまで構造設計が落ち着いてから行う「清書」と位置づけて、構造計算ソフトに情報を入れる回数は極力減らす。すごい当たり前の事なんだけど（笑）。まあ詳しくは意匠と構造のストーリーを理解する その1を見てもらいたいね。
中村：なるほど。現場で白矩が解決する問題が、そもそもなんで起こってしまうのか・防ぐにはどうしたらいいのか、ということを、設計プロセスにまで遡って考えようとしてるっていう感じだね。
押山：そういうことだね。次に意匠に関する法規について調べていて、出来れば法規を調べる人たちが楽になるツールを作れないかなと考えている。色々な設計者の人に聞くと、防火・防煙区画とか排煙の規定って、プロジェクトが始まる時に必ずチェックする項目なんだけど、毎回同じことを調べるのにすごい労力がかかってるんだよね。
中村：そうだね。建物の用途ごとに基準があったりして複雑だし、建築基準法の条文だけだと判断できない場面も多くて、色々な実例集をひもといて法解釈をしなきゃいけない場面っていうのは多いね。
押山：そこで、建築基準法の条文同士がどういう風に結びついてるかをグラフデータベースで記述して、建物の変数を変えたらどの条文に影響するか、とかがわかるようにできないかなということを考えている。実際のユーザーインターフェースとしては、建物の用途や面積を入力して実行すると、「こういうところに防火区画が必要とされますよ」とか「●●m2ごとに排煙口が必要ですよ」とかの結果が出力されるようにしたいなと思っていて、まずはベータ版を作って実務の人に使ってみてもらいたいね。あとは、川島範久さんの環境シミュレーションの本を読んで、日照とか温熱環境とかがどういうフローでデザインされているのかも調べようとしている。環境はまだまだこれからだね。
中村：プロジェクト以外にも色々やってるんだね。それって設計事務所とかゼネコンから「こういうツールが欲しいです」みたいなニーズがあって開発してるの？
押山：いや、ほぼ自分の興味の赴くままにやってる（笑）。グラフデータベースを使ったのも、4年前に興味があって調べてたら、今回たまたま法規のことを考え出した時にあれ？これグラフで解けるんじゃね？と思ってやっているって感じ。（笑）
間違いや手戻りを許容するプロセス
中村：今まで白矩が主に携わってきた生産設計の範疇から、徐々に実施設計・基本設計の範疇にまで遡ってきてるって感じだね。興味に基づいてやってるっていうことだけど、どういうところに関心をもってるの？
押山：やっぱり、設計と生産設計の間、みたいなところに関心があるんだよね。設計段階でどういう風にデータを作っておいたら、生産設計とか施工段階で活用できる情報になるか、とか。だけど自由度は失いたくないっていうね。
中村：BIMとかをやってると永遠のテーマだね。基本設計、実施設計、生産設計、それぞれの段階で情報の確定度とか詳細度が変わってくると思うんだけど。
押山：そう。その確定度みたいなものを、データ的な表現として「許容差」と呼ぼうと思ってるんだよね。基本設計の時の許容差は1だけど、実施設計では0.1、生産設計では0.01、みたいに、それぞれの段階で許される間違いの範囲を指定することができると思う。基本設計の時は1の単位で不正合とか未確定事項があってもいいけど、実施設計のときはその十倍、生産設計のときはその百倍の確定度で設計しなきゃいけない…こういう仕組みが3Dモデルと連動してつくれれば、「この設計は実施設計なのに1ケタレベルの不整合があるから良くない設計だ」みたいな、設計情報の定量的な表現や判定ができるんじゃないかと考えている。
中村：なるほど。いわゆるLODの、より情報的な表現っていう感じだね。
押山：このコンセプトで重要なのが「手戻りを許容する」っていうことだと思ってる。設計段階でどれだけ問題を解決したと思っていても、現場が始まったら次から次に問題が生まれてくる。これはツールの発達では解決できないことだと思うんだよね。手戻りをなくすんじゃなくて、手戻りになった時にいかに素早く合理的に解決するか、デジタルツールはそこにフォーカスして活用すべきだと思う。
中村：今までの、いわゆるフロントローディング的な考え方だと、「川上である設計の初期段階で負荷をかけると川下の施工段階で生じるであろう問題を先行して解決できる」って考えるけど、そうじゃないってこと？
押山：そう。人間が設計している限り間違うし、予期せぬトラブルも絶対にある。現場である部分が納まっていないことがわかったときに「この部分を変更すると、あっちに影響が出て、あっちに影響が出ると問題の前提条件が変わって…」みたいなことって、よくあるよね。その時に、川下段階と川上段階のモデルデータの関係性とか優先度みたいなものが可視化されていれば、問題解決はよりスムーズになると思う。それと、それぞれの段階で構築すべきデータの精度や確度の指標が分かっていれば、「いま基本設計段階だからここまで入力しておけばいいんだな」とか「逆にこれ以上は今の段階でやる必要ないな」とかがわかるようになるんじゃないかな。
中村：たぶんそういうことは、ほとんどの設計事務所とかゼネコン設計部には「基本設計時のチェックリスト」とか「着工時の不具合予防項目リスト」みたいな書類がISOに基づいて整備されてると思う。
押山：やっぱりそういうものがあるんだ？
中村：そう。だけど、そういうチェックリストで検討した情報って、それぞれの段階での成果品である図面に表現した瞬間にかなりの部分が見えなくなってしまうんだよね。図面でもBIMモデルでも同じだと思うんだけど、成果品は色々検討した情報を「圧縮」して表現しているから、フェーズが変わって図面を見る人が変わると、そこに込められた意図や意志みたいな情報は容易に読み解くことができなくなる。よく「ISOは形骸化して書類を作ることが目的化している」と批判的に言われたりするけど、その実態は形骸化ということじゃなくてこういう「圧縮による情報の欠落」に起因するんだと思う。
押山：設計施工一貫が最初から根付いてる日本だと、基本設計・実施設計・生産設計で図面を見る主体が同一の会社(ゼネコン)っていう状況に慣れてるから、そういう情報の欠落は起きにくくはなっていると思うんだけど、海外だとフェーズが変わると図面を見る主体が変わるっていうのが普通だから、より深刻だろうね。そういう意味では、データの許容差を明示するっていうのは、設計者・施工者の役割や責任区分を明確にすることにもつながると思う。不具合があったときに「この部分の情報に不備があったから、これは実施設計をやった設計者の責任ですね」とか、責任の区分もわかりやすくなる。今は設計から施工までがなんとなく緩く繋がっちゃってるから、責任の区分も曖昧になっちゃってる。それはいい部分もあるけど困る場面も多い。そういうところにデジタルを使う切り口を見つけたいっていうことは、常に考えているね。
極端に言えば、設計者にはスケッチだけ描いてもらえばいい
中村：今日久しぶりに本屋に行って『建築技術』の設計図書特集を買ったんだけど、そこに内藤廣さんの論稿が載ってた。内藤さんはすごく精密な製図をすることで有名だった菊竹事務所の出身なんだけど、内藤さん自身の事務所が手書きからCADに移行した時の苦労を論じていた。
押山：内藤廣さんの事務所の図面は精度が非常に高いという話は聞いたことがある。有名なようだね。
中村：そう。その論稿の中で「CADの図面からは作図した人の意図や意思を見出しにくい」というようなことが書かれていた。これって「手書きの線には味わいがある」みたいな懐古趣味じゃなくて、実務の実感としてすごくリアルなものだと思うんだよね。実際に、手書きだと作図者が意図しない線は殆ど描かれないと思うんだけど、CADだと意図した線と意図しない線が等価に表現されてしまう。
押山：それはその通りだと思う。極端に言えば、設計者にはスケッチだけ描いてもらえば十分だと思っている。
中村：設計者が自分でBIMやCADを触らないってこと？
押山：そう。設計者はスケッチでプランや納まりを指示してくれればいい、それをうちの会社で3Dモデルに起こして不整合や不具合を発見した上で、作図まで完成できるから。その方が設計情報の伝達として間違いがないと思う。逆に、設計者が作ったデータは間違いが多すぎると思うことが多い。以前は設計者から設計のBIMデータをもらうこともあったんだけど、生産設計図や施工図を起こすためには精度がぜんぜん合わない。「設計者が思う納まり」だけをスケッチで示してもらう方が効率的だと思うよ。
中村：普通は「デジタルでの設計情報の表現力を上げるためには、設計者自身がCADや BIMのスキルを向上させなければいけない」と言われるけど、やり方によってはそうじゃない方法もあり得るってことだね。
押山：そうだと思う。「自分で考えて自分で描かないと納得できない」っていうタイプの人もいて、そういうやり方が合わない人もいるだろうから難しいけどね。最近はそうやって、設計者からスケッチをもらって白矩でモデルに起こして、不整合があったら質疑をあげて納まり指示してもらって…っていうやり方を、基本設計段階でも徹底するようにしてる。
中村：生産設計の段階でやるようなことを、白矩が参加することで基本設計で、かつデジタル的なやり方でやってるってことなんだな。
押山：そういうことだね。ゼネコンの生産設計のデジタル版みたいなものを考えていくと、うちみたいなやり方に収斂されていくんじゃないかな。
中村：それを設計事務所でもゼネコンでもなく、白矩というまた独立した会社がやってるっていうのが特徴的だよね。従来とは違う基本設計のやり方で、設計者からすると従来とは違う緊張感がありそうだけど。
押山：例えばどういう部分で？
中村：例えば、従来の基本設計だったら設計者が後工程を考慮して、スペックを過剰に見込んでおく、いわゆる「貯金」が可能だったよね。極端な例で言えば、ある部材の数量が実際は10個で足りるんだけど、特記仕様で「100個見込むこと」と書いておく。そうすると90個分の余分な費用が確保できるから、設計変更とか予定外の不具合が生じた時に保険金みたいな形で予算を捻出できる。でも白矩みたいに、設計者でも施工者でもない立場で設計情報を整理する主体がいると、それが出来にくくなるんじゃないかな。
押山：そうだね。その特記に気づいた時点で「数量が過剰ですよ」って質疑するだろうな。
中村：同じく『建築技術』に安田幸一さんも寄稿してるんだけど、最近はそういう貯金的な図面のスペックインがしにくくなってるということを指摘していたな。
押山：時代の流れ的にはどんどん難しくなるとおもう。そもそも「貯金」っていうのが建設業界に特有の習慣だと思う。多重下請構造の中で、数量やコストとの関係が曖昧になりやすい慣習ができて、それが今にもつながってきている。顧客と元請、元請と下請の関係のなかで、信頼関係を築いて仕事をするっていう点ではそういうやり方の良い面もあったけど、それによって施工者や専門工事業者が過剰なリスクを抱えてしまうという負の側面も非常に大きいと思う。
中村：実際その作業にどれくらいの手間がかかるか、っていうのが分からないと、適切なスケジュール管理もできないだろうしね。
押山：そうそう。これは余談なんだけど、以前に生産設計を支援したあるプロジェクトがあって、現場に行って打ち合わせをして「じゃあこの納まりでいきましょう。押山さんこれをモデルに反映させるのに何日かかりますか？」って聞かれる。それに対して「うーん、2時間くらいですかね？」って答えると驚かれるんだよね。「時間の単位が違う」って（笑）。
中村：それはすごい。コンピュータを使ってるからこそ出来る技だね。
押山：そのプロジェクトでは手動のモデリングじゃなくてバッチ処理でモデリングできるような仕組みにしておいたから、実際にそれくらいでできちゃうんだけど、その手間や過程は他の人から見えてない。だから実際には2時間でできる作業を、1週間とか2週間かかる想定で工程を書いてしまうことも起きうると思う。ちょっと話がそれたけど、作業の計画を立ててスケジュールを読むっていうのは、前例がないものに対してはすごく難しいから、そのスケジュールを前提に工程を立てたりするっていうのはそれ自体がすごくリスクを抱える行為なんだよね。
建築生産の歴史と展望
1.BIMを活用した設計・生産設計の協業体制の素案
第一部
1.建築生産の歴史と実情【その1】
2.建築生産の歴史と実情【その2】
3.生産設計とプロジェクトの透明性【その1】
第二部
1.日本におけるBIM活用について【その1】
2.日本におけるBIM活用について【その2】／あとがき
後日談
1.建築生産の歴史と展望(後日談)【その1】
2.建築生産の歴史と展望(後日談)【その2】
3.建築生産の歴史と展望(後日談)【その3】