押山さんと考える、BIMと建築生産のこれから#1
登場人物
押山さんの仕事
蒔苗: 今回は株式会社白矩の押山さんをお呼びして、BIMや建築生産についていろいろとお話ししようと思います。まず初めに、なんでこういう仕事をやるに至ったのかを聞きたいなと。というのは、押山さんと僕や石原さんは学生の時からの知り合いなんですが、意外となぜこの仕事を始めたのか知らないな…と思ってｗ
押山: よろしくお願いしますw なんで始めたかっていうと、ちょっとドロップアウトしたみたいなところがありまして。東洋大学の藤村研究室を出て、就活するときにゼネコン、設計事務所、アトリエ、組織設計などいろいろ見たんですが、まずどこも肌に合わないと感じて、1年引きこもりみたいになってたんですよ。
蒔苗: そうなんだ、意外…
押山: それで自分にできることはなんだろうって考えたんですが、学生の頃からゲーリーやザハの、複雑な曲面を使った建築が好きで、そういうのを自分でも作れるようにRhinoceros(3DCADソフト:以下Rhino)を勉強していたので、卒業するときには割と使えるようになってたんですよね。それでRhinoの日本総代理店であるアプリクラフトに就職して、自動車、照明、建築など、一通りモデリングをしました。
蒔苗: それは代理店のサポートの一部としてってこと？
押山: そうですね。意外とお客さんに頼まれてモデリングする機会が多かったです。そのあと3年ほど勤めてから独立しました。建設業界を中心に仕事をしていて、もう少しでまる4年たちますね。
原体験：建築を作るプロセスへの疑問
押山: これはアプリクラフトの時、中規模くらいの建設プロジェクトに関わったときの話です。まずプロジェクトが始まったときに、入札後でトータルの金額が決まってるはずなのに、意匠・構造・設備を一から調整しなおしてたんですよ。
蒔苗: あー、建設業界だとよくあるやつだよね。
押山: そもそもそれって、入札でこのくらいの金額です、と見積もりを出した後なのに建物の全部を調整してるわけじゃないですか。それだと当然見積もりは変わるでしょ、っていう疑問があったんですよね。で、その時に施工者に聞いても設計者に聞いても、「そういうもんだから」と言われちゃったんです。これって変だよね？という疑問がそもそもありました。
蒔苗: なるほど。
押山: そして、それによって工期とか建物のクオリティにも影響が起きるはずですよね。見積もりを出して、それが通ってから大慌てで設計を全部変えてるわけですから。
蒔苗: そうだよね。見積もり前から設計が変わらなかったら？と考えると、そっちの方が確実に円滑な施工ができてるはずだよね。
押山: そういう入札前後の設計変更に付随して、「工程表の更新が行われずスケジュールが共有されない」とか「いろんな場面でのヒューマンエラーの多発」とか、「設計が終わっていなくても申請が通ってしまう」とか、いろんなことが起きてると思うんです。そしてそれを解決するのがBIMだったはずなのに、登場してから10年ほどたってもそんなことが起き続けている。BIM導入で何がよくなったのか結局わからない感じになっちゃってるなと。
渡辺: 確かに。建築のお施主さん、発注者にはこの辺は見えてない問題だよね。
蒔苗: 出すお金とスケジュールがわかって、そこから変わらなければいいですからね。
押山: こういう体験から、僕は「実現可能で値段がわかるレベルの設計が、入札の前にできるような発注の仕方を作れないか？」と考え始めました。
日刊建設工業新聞社の書籍たち
蒔苗: 「入札制度やコスト管理」とか「建設業界の構造改革」とかはほんとにそのままな感じだね。
押山: で、これが書かれたのって30年も前なんです。なのに触れてる問題が今まさに僕が感じている問題とほぼ同じことにショックを受けました。やっぱり「実現可能で値段がわかるレベルの設計が、入札の前にできるような発注の仕方を作れないか？」ってことを論じてるな、と。そして、ざっくりいうと「設計と施工の業務範囲があいまいで、責任の所在があやふやになっちゃってるのが原因」っていうことが書かれてます。
石原: なるほど…
押山: 実際、僕はこういうことをただ言うだけじゃなくって、どうやったらこういう仕組みができるのかを考えたいんですね。ただそのためには、今どうやって建築を作ってるのか、現代の建築を作るプロセスをちゃんと理解しないといけないなと。でも、そういう「建築を作るプロセス」についてあまり突っ込んだ議論がなくて、「こういうもんだから」っていうことで今まで来ちゃってると思うんです。それで生産性の低下とか、建設業に関わる人の高齢化とか、いろんな問題が起きている。
蒔苗: 確かにそういうところがあるよね。
押山: さらに言うと、「建築を作るプロセス」をちゃんと議論しなかったせいで、最近出てきた問題を「BIMやDXで何とかするぜ！」みたいな超ざっくりした話になっちゃったんじゃないかな？と思ってるんですよね。それで、こういう考え方を勝手に「デジタルウェポン軸」と呼んでます。ｗ
蒔苗: それはちょっと皮肉ってるわけ？BIMさえあればなんでも解決！みたいな考え方をｗ
押山: そうですｗ もちろん、僕ら含めBIMをやってる人たちって、そういう期待を持ってくれてる人がいるから予算がついて仕事をもらえてる側面があるんだと思うんですよ。ですけど、それだけにからめとられちゃうと、肝心の「建築を作るプロセス」がそのままになっちゃって、建設業界の問題もそのままになっちゃうと思うんです。
蒔苗: 例えばいろんな人が「こんなツールを開発しました！」とか「こういう自動化をしました！」って言うけど、そういうのって普段の業務の効率化にほんとにつながってるか疑問、みたいなこと？
押山: まさにそうですね、ニュースや広告のためのものになっちゃってる感じがします。実際、僕が設計効率化のツールづくりをお手伝いしたときに「これを開発しても僕ら自身使わないよな…」っていうコメントがあったんですよ！なんだか空虚な仕事の回り方になっちゃってるな、と。
蒔苗: それ言われると作ってる方としてはつらいね…
押山: ですよね。。ツールを作るにしても、建築を作るプロセスの中にちゃんと位置づけられてないとやっぱり使われないと思うんです。その意味でBIMのためにも、プロセスを改めてちゃんと考えるのが大事だなと考えてます。
建築生産プロセスとは？
押山: これは岩下秀男さんっていう研究者の方が言ってることですが、日本での建築生産プロセスの始まりは、大正期に鉄筋コンクリートが導入されたからという話があります。
石原: だいたいこういう話だと「日本のゼネコンには江戸時代の棟梁以来の伝統があるから…」みたいになりがちだけど、違うんだね。
押山: 鉄筋とか型枠とか、いろんな種類の工事を平行して進めなきゃいけなかったので、それらを束ねる人が必要だったためにゼネコンが生まれた、っていう説ですね。そして、現代日本における建築生産プロセスは以下のように定義されています。
一般的に建築主の業務であるところの企画からはじまり、設計者によって設計図書を完成させ、その設計図書に基づき施工者が部材・労務などの発注・調達を行い、長期間の現場施工を経て建築物が竣工し、建築主に引き渡されるという一連のプロセス
「建築生産」古阪秀三、2009
蒔苗: つまり、建築主＝発注者が建物を欲しいな！と思ってからできるまでの全部ってことなんだね。
押山: そうですね。そして「生産設計」は、「設計段階で作成された設計図(設計情報)を、円滑に施工できるように整理・詳細化して、実際に施工可能な図面(生産情報)を作成する業務」と言えると思います。設計してから実際に施工をするまでの間の仕事です。
石原: 中堅以上のゼネコンにはだいたい「生産設計」っていう名前の部署があるよね。
押山: その部署は図面自体の作成に加えて、そのための専門工事業者間の取りまとめもやってる、と僕は理解してます。
蒔苗: 施工図作成とはちょっと違う？
押山: 違いますね。施工図っていうと、ほんとに現場の職人さんが使うための、専門工事業者の中での図面を指すと思います。生産設計は施工図を描くために必要な図面を書いて、情報をそろえるところっていうイメージかと。日本独自の職能じゃないかと思うんですよね。
蒔苗: この辺は建築の規模や会社によって、細かく体制や呼び名が違ったりしそう。
渡辺: でもだいたい日本の大きめの建設プロジェクトだと、こんな流れで仕事が進んでいくんじゃないかな？
DrawingXとは何か？
押山: そして、生産設計の部署が作っているような「施工するために必要な情報」って、実は世界各国であり方が違うんですよ。例えばイギリスでは、そういう情報を設計者が設計図に盛り込んでいて、施工者は情報の作成とか付け足しをしないんです。そしてシンガポールでは、専門工事業者によってそういう情報が作られる。
蒔苗: なんとなく話には聞いていたけど、ほんとに仕事のしかたが違うんだね。
押山: 古阪秀三さん(以下古阪)という研究者は、こういう「施工するために必要な情報」＝「品質・コスト・工程管理の要となる情報」のことを「DrawingX」と呼んでいます。そして各国でのDrawingXのあり方の違いや、それまでの情報の流れの違いを図で示しています。
蒔苗: なるほど。そもそも国や体制ごとに情報の流れも違うし、どういう図面がDrawingXになっているかも全然違うね。
押山: 日本のやり方は、さっきの図の左上にありますね。総合図やコンクリート躯体図がDrawingXとされていて、ゼネコンが取りまとめの担当になってますよね。それに対して、シンガポールの場合は専門工事業者による製作図が、イギリスの場合は設計者による図面がDrawingXになっている。
壁谷: 海外ではゼネコンがDrawingXを描かないんですね。日本でゼネコンがこういうの描かなくなったらちょっとびっくりしますよね。
押山: 古坂さんも、「日本の建築生産プロセスにおいて、ゼネコンがDrawingXを行わない、ということ自体が極めて非現実的」と言ってます。あんまり描かないことを想定できないですよね。
壁谷: ゼネコンがDrawingXを描かないってことは、施工者側で種別の違う工事の担当者同士の調整が存在しないってことですよね？そんなことあり得るのかな？
石原: 工事の進め方が違ってて、異なる工事種別が同時に作業をしないから、そういう調整がいらないんじゃないかと思う。こないだ見学でドバイに行ったとき、コンクリートや鉄骨の躯体だけがのびてる建物がすごく多くて、会社のメンバーみんなと「どういうことだろ？」って話をしたんだよね。というのは、日本だと躯体が3階くらいまで上がったら、その下から外装工事を進めちゃうじゃない？
日本のDrawingXの描き方のよくないところ
押山: ただ古阪によると、日本でDrawingXがゼネコンによって描かれているのは、必ずしもいいことじゃないんです。
蒔苗: え、なんでダメなの？
押山: 設計と施工の業務範囲があいまいになるからです。例えばイギリスではDrawingXが設計者によって描かれていて、設計者と施工者の役割分担が明確です。対して日本では施工性の検討やそれに基づいた設計変更を施工者が主導している。古阪の指摘では、設計者がやるべき仕事を、施工者が肩代わりしているんです。
蒔苗: なるほど。
押山: そのため、施工に入った後に予算が大幅にぶれる、みたいなことが起きる。コストが検討できるレベルまでの図面を設計段階で描いてないですから、ある意味当たり前ですよね。業務範囲があいまいなせいで、施工側の業務が過大になりやすいことも問題です。
蒔苗: やっぱり役割分担が明らかじゃないと、誰かが尻拭いをさせられる構造になっちゃうってことなんだな…
押山: ちなみに、初めの方に出てきた日刊建設工業新聞社の本は、こういう問題を現場から描いたものだと言えます。ゼネコンの役割が肥大化しすぎたために、ゼネコンの現場監督や、彼らに指示される専門工事業者までもが疲弊していく場面が取材されてるんですよね。
今回はここまでです。次回は建築生産プロセス全体の問題を明らかにし、押山さんからそれを解決する仮説が提示されます。お楽しみに！