10＋1 website｜テンプラスワン・ウェブサイト

3. 実務系

Q3.1　BIMのツールは建築デザインツールとして有用なのでしょうか。ツールとしては不十分だとしたら何が足りないのでしょうか。

石澤──建築デザインツールを「形をつくるツール」だとすると物足りないと思います。BIM系のソフトウェアは生産につなげることを重視しているので、ベジェ曲線やNURBSが扱えないとか、形態生成系の機能に物足りなさを感じることがありますが、それならほかのソフトウェアを使えばいいわけです☆29。なんでもできるものがひとつがあれば良いのではなく、やはりそれぞれ専門の使いやすい道具を揃えるというのが定石です。

もうひとつ言えるのは、デザインとは形をつくるだけではなく、情報を整えて可視化し、そこから閃きを得るというのも一側面です。そういう発想から見れば、データの構成を整えられるBIMはとても有用だと言えます☆30。

☆29──［堀川］異なるソフトウェアを使ったときに、データの連携部分で足踏みしているという声はよく聞く。特に汎用的なデータフォーマットだと（3Dでいえばstl、iges、stepとか、BIMだとifc？）、必要最低限の情報しか持っていけないため、受け渡し後に編集が必要という二度手間になることも多い。ソフトウェアのSDK（ソフトウェア開発キット）などを利用して自分でデータを書き出すだけのリテラシーがあれば、そういったしがらみから自由になれるが、そこまでのリテラシーを一般的に求めてもいいものかは気になる。

☆30──［角田］ソフト間の連携や、複数のソフトをまたぐことによって十分になるという理解をもっと一般化したほうが良さそう。

Q3.2　構造は、構造計算ソフトとのリンク程度しか行なわれておらず、2次部材や接合部等は計算ソフトには含まれず設計図書としてもあまり使用できないと思います。今後構造BIMはどうなると思いますか。

石澤──構造以外の人にとってはピンとこないかもしれませんが、構造計算ソフトでは、構造とそれ以外の部分の考え方がまったく違っています。2次部材や接合部が書き込まれていないから図面にならないし、あまり使えないというご意見ですね。

提坂──私は設計者ではありませんが、意匠・構造のBIMコーディネーションが専門です。確かに構造には解析モデルが存在するので、それを書き出せばBIMモデルにはなります。ただ、解析用につくられたモデルは、柱や小梁の接点位置で通しの大梁部材がぶつ切りになっています。そうした解析モデルを変換して図面用ソフトに持ってきたところで図面表現にはふさわしくありません。そこで導入できるのは、解析モデルのジオメトリをそのまま図面に使用するのではなく、解析ソフト内の情報をデータベース化する方法です。そうすればデータベース内で接点の統合などの処理をした上で、作図に携わる人が、作図に必要な情報だけをデータベースから取り出しモデルを再構成することができれば、解析モデルのジオメトリに頼らなくてもいいわけです☆31。

☆31──［豊田］BIMとはいえ、すべての情報を直接的に扱うのではなく、こうしたメタなレベルで扱った方ほうが良い場面の整理と、ノウハウや技術への落とし込みは、今後さまざまな領域やソフトウェアのあいだのやりとりが一般化していく際にすごく大事な領域になる。このあたり、実際にまったく汎用的な技術やノウハウが体系化されてないから、十分にひとつの建築情報学の研究領域になる。

Q3.3　BIMを実務で取り入れていますが、施工や設備会社が「Jw-cad」しか使っていないのが現状です。毎回変換のたびに時間だけがかかります。どのような対応をすべきでしょうか。

石澤──先ほどのツールの話にも関わりますが、やはりみなさん仕事をするうえで何かのツールを特化して使っているので、なんでも使えるという人はあまりいません。「ツールを変えてください」と言うのは筋ではないので、なるべくそれぞれの人の方法を尊重しながらも、私たちが持っているデータを提供することになりますが、変換の時間が結構バカにならない。だから事前になるべく良い方法を見つけて合意しておくことが大事です。例えば、ビューワーを入れてもらうとか、「私たちはここまで出しますから、あなたはそこから先を変換して使ってください」とか。そうした合意がないと、「君のほうが詳しいからやってよ」と言われてしまって負担が大きくなります。この事前仕分けに使えるのが「BIM実施計画書」や「BIM Execution Plan」と呼ばれるもので、納品日などのほかにやり取りうえの約束事を書いておくだけでも使えます。1件目のBIMプロジェクトで、完璧なBEP（BIM実施計画）を書くのは難しいですが、2件目以降はうまく書けると思います。トラブル防止にもなりますし、別のケースで展開もできると思います☆32。

ソフトの互換性は年々良くなっているので、将来に期待もできますが、「Jw-cad」は国産なので独特なところがあって、その分、絶大な支持を得てもいるので悩ましいところですね。

☆32──［石澤］日本建築学会の「設計・生産の情報化小委員会」が発行している「BIM実行計画書」をベースにするのも良い。

Q3.4　BIMを使っていると、つねづね「情報体系」が必要だと感じる。カテゴリ、パラメータ、タイプ、管理番号などのコーディネーターが必要で、それを実務者が兼ねるのは負担が大きい。

石澤──例えば直方体をつくったときに、それが梁か柱か、家具なのかは、属性が示します。シンプルに考えるとBIMとはそういうものです。そこで、ある人が「梁」とつけて、別の人が「beam」とつけてしまうとうまく探せなくなるので、あらかじめ仕組みを考えてそれに従って情報を入れれば検索しやすいし、漏れもなくなります。そうしたシステムは「Uniformat」とか「OmniClass」と呼ばれているもので、通常は見積り表にも紐づいています。「B01」は基礎、などの決まりがあり、それに習ってやりましょうということです。日本の場合は、公共工事標準仕様（公共標仕）という国土交通省が使っているものがあり、それを使うと見積りとの互換性は良くなりますが、アメリカやイギリスを無視して、日本語フォーマットで入れたほうがいいのかというと悩ましい問題です。私も日本語のフォーマットシステムを整備するべきかどうかというのは一概に言えませんし、やはり国際的なルールを使うメリットは大きいと思いますが、例えば日本で一般的な工事だが海外仕様では区分けがないなどという欠点もあります。本来は誰かがそうしたシステムをつくったほうが良いのですが、現状では割に合わないけれども実務者が仕方なくその場でひねり出して情報を入れるというケースが多いです。だからこの質問への回答としては「その通りですよね」ということになります☆33。

☆33──［角田］これは永遠の課題。体系の整備はこれまでもずっと取り組まれているが、なかなかしっかりしたかたちににまとまらない。

Q3.5　建築実務のなかで面積は最も重要な要素だと思います。モデルと面積の取り方が一致しない場合、実情どのように対処しているか。また、どのように対処していくのがよいと考えているか。

石澤──今回いただいた質問のなかでじつは個人的に一番アツい質問でした☆34。例えば、今この部屋の面積を考えると、日本で一番よく使われている面積の取り方は壁の中心線（壁芯）によるものになりますが、じつは世界的にはそれはマイノリティです。例えばRevitでも、基本的には壁の内法での設定が扱いやすいです。日本の建築基準法の床面積は容積率にも関係していて、ローカルな計算のルールがありますが、BIMはオブジェクトによって管理します。つまり、ひとつの建物や部屋に対して、複数の面積があるのが実情で、それをどう管理するのかという問題ですが、これには決定的な答えがありません。国によってもルールが違い、ひとつ部屋に対してひとつの定義による面積だけでは足りない場合もあります。ダミーのオブジェクトを置くとか、部屋は分割線で部屋を分けるとか、やり方を工夫することは可能です☆35。一方で、マニアックにつくり込んでしまうとほかの人が理解できないものになりますし、どこまでやるかは難しく、この問題は地味に見えて厄介です。良い方法をシェアしながらやっていくのがベストなのではないでしょうか。

☆34──［石澤］ほかに個人的にアツいと感じているトピックは、例えば外壁における防火区画の回り込みや、法的に明示が求められる項目のうちモデルからは自明にならないものとして、平均地盤面の扱いや避難階の定義など。ニッチなトピックに聞こえるが、それには理由がある......。またどこかで議論の機会を設けられれば。
☆35──［堀川］このあたりの「ソフトウェアの本来の使われ方ではない使い方」は気になるし、好きな話。こうした迂回方法の数々を制限のなかから捻出している話自体が、そのソフトウェアの思想を浮き彫りにしているようでアツい。

Q3.6　BIMマネージャーとプロジェクトマネージャーは、どのような力関係でどのように協業するのがベストなのでしょうか。

提坂──繰り返しになりますが、意匠設計のリーダーやプロジェクトマネージャー（PM）がプロジェクト全体を進行することは変わらないと思います。BIMマネージャーに期待されているのは、プロジェクト全体を見ているリーダーの下でチーム全体のプロダクション方法や進行状況を管理することです。そこをサポートすることができて初めて、プロジェクトマネージャーとBIMマネージャーはプロジェクトを効率的に進めることができます☆36。

☆36──［角田］データをコントロールしている側がマイルストーンを逆算して、データをつくっていないといけなくて、スケジュールを采配せざるを得ないシチュエーションも多くなってきている。そういう意味で、力関係ではないが、BIMマネージャーのほうが結果的にプロジェクトをコントロールしているものもありそう。

Q3.7　プロジェクト管理（設計〜建設）以外で、竣工後の維持管理ではどのように役立つのでしょうか。

石澤──BIMはお客さんのためにもなるということは以前から言われていますが、成功事例は少ないと思います。お客さんが必要としている情報のなかで、何がBIMモデルに入っていれば良くて、それがどの程度つくられているべきかというところで喧嘩になるからです。やはり、きちんとつくろうとするときりがないですし、プロジェクトの途中だと忙しくてなかなか自分の専門分野以外のデータの空きフィールドを埋めることに労力が割けません。人件費を割いてデータを入れるとしても、そのモデルに値段がついて買ってもらえるかは難しいところで、まだまだというのが実情だと思います。

また、お客さんにとっては当たり前のように思われても、設計者がケアしていない情報がたくさんあります。例えば新築の建物の電話番号は竣工後でないと決まりませんし、それらを誰がケアするのかという問題もあります。ある程度情報を絞るのが現実的なのですが、そうした話をプロジェクトの早い段階からできるケースは稀です。今後お客さんのBIMに対する認知が上がるに連れてノウハウが蓄積されていくとうまくいくようになると思います。

また、改修工事のときにお客さんが建物の図面や確認申請図を紛失してしまっていることもよくあるので、お客さん自身がデータというかたちでを建物情報を持ち続けてくれれば将来的にとても助かることになるし、さらにそれを使ってくれればすごくメリットがあると思います☆37。

☆37──［堀川］詳細な情報は難しいとしても、つくられたデータがお客さんや設計者に留まったままというのはもったいない。外形の3Dモデルだけでも全国共通のプラットフォーム（Google Earthでもなんでも）に公開して、詳細モデルが必要な場合はコンタクト先がわかるかたちになっているなど、情報が多目的に利用できる仕組みがほしい。［豊田］BIMデータの社会的・商業的な応用可能性は、じつはいますごく重要な領域。既存ストックのBIMデータをいかに社会ストックとしての汎用データとして提供できるかは、建築業界をあげて研究するべき。これからの都市計画や再開発は、そうした視点なしには成り立たない。［石澤］一方に、プロジェクトを通じて完成されたBIMモデルの価値がいかに評価されるか（簡単に言えば、データとしてどのくらいの値段がつくか）という議論があって、もう一方には、これまでBIMに限らずデータ化された建物をどう社会インフラにしていくかという議論がある。アメリカから留学生が来て仕事をすると、日本には敷地周辺の3D建物データベースで無料のものがないことに驚かれます。［角田］話としては切り分けたほうがいいと思っています。現段階は一石二鳥ではなく、どちらかを目的として進めていくことのほうが重要。これまではそれを混在させて、メリットを竣工後に見ていたがゆえに、本来のメリット探求がおろそかになっている印象。

Q3.8　先ほどBIMにおける面積の情報化の難しさについての話がありましたが、ほかに建築における空間など、情報化の難しさやもどかしさを感じるものはありますか。

石澤──ひとつ例を挙げれば、確認申請で求められる「避難距離」です。建物内のある場所から避難階段や避難設備にたどり着くまでの最長の距離のことですが、BIMには「避難する道」というようなオブジェクトはありません。図面では考えもしなかったようなことが意外と難しかったりします☆38。BIMはよく「建物のデジタルツイン」と言われ、しっかりつくると実際の建物の双子のようになるという考え方で、私は好きなのですが、避難距離のように現実に存在しないために扱いづらい情報もあります。そういったものに対してはなかなか良い方法はないのですが、プロジェクトのなかで便宜上解決することも多くあって、それもBIMのリアリティではないかと思います。

☆38──［堀川］このあたりにもBIMを開発している国の事情などが見え隠れして面白い。［木内］確かに、物質としては実在していないけれども、特定の社会に属している人間にとっては概念として存在しているようなものをどう扱うかというのは非常に面白いトピック。BIMが専門でない私の立場なりに想像してみると、必要に応じて質量ゼロのオブジェクトとして扱っていくのかなと思う。そのレンジをどこまで広げるかが判断の難しいところなのだろうか。そもそも線や面という情報も、人間が便宜的に使っている質量ゼロのグループ。これらなくして何かを思考することすら困難になるような重要なオブジェクト群だから、必ずモデルに入ってくるわけだが。

提坂──構造モデリングをやっていて、なぜこれがないのかと最初に思い当たるのが「接点」オブジェクトです。梁や柱の始点・終点のXYZ座標は取れるのですが、ある点のXYZを知りたい時に、そこに柱がない限り取れません。解析モデルのように、要素から独立した接点があって、Excelで数字を動かせば柱・梁などが追随してくれたら良いなと思います。なぜつくらないのか不思議に思っています。点からすべてのジオメトリを組み立てる「CATIA」にはありますね。

石澤──似たようなソフトウェアでも思想が違うものがありますね。

Q3.9　Rhinocerosのようなソフトウェアにプラグインを入れてBIMツールとして使う場合のメリット、デメリットを知りたいです。

提坂──それを力技と呼んでいます☆39。本来BIMに対応していないソフトウェアにBIM機能を付随させるためのプラグインを追加していくと、その人のPCでは使用できても、ほかの人の作業環境ではそのモデルが受け取れないことが多々あり、それがハンディキャップになります。例えば、私が情報を付加したRhinoモデルを石澤さんに渡しても、追加された情報を見ることを想定していない石澤さんの環境ではその情報は見られません。つまりBIMのプロセスで一番肝心な、チーム全体の作業環境を整える面でデメリットになってしまうのです☆40。

☆39──［豊田］ここで登壇者二人があっさり共有理解を持っていたのがこの日一番ウケた。［石澤］業界として定着しているかどうかは不明ですが、ドンピシャで通じていた。［角田］確かに力技だ。
☆40──［堀川］小さな事務所ならまだいいかもしれないが、大きな組織で環境を整える必要がある場合は確かにデメリットが大きそう。［木内］特にGrasshopper上では、専門的なソフトを一般のデザイナーでも使えるようにパッケージして差し込めるように、という思想の下つくられてるものが多いだけに、解析関係でも「あるある」ですね。今まで何度「私のほうで開くとエラー出ます」と言われたことか......。

石澤──Rhinocerosは私も好きですが、使えば使うほど思うのは、建築用ではなく車やプロダクトなどに適した汎用3Dソフトウェアだということです。だからこそ今まで建築でできなかったような面白い形をつくることが得意なのですが、例えば、フロアの設定がないとか、ちゃんとした建築の図面を描くのは大変です。やれないことはないという意味で「力技」です。「餅は餅屋」ですから、実務者にとっては賢く使い分けるという判断の方ほうが多いのではないでしょうか。

Q3.10　プレカットマシンとの連携がどこまで可能で、これからの見通しはどうでしょうか。あるいはその課題を教えてください。

石澤──あらかじめ工場で部材を必要な寸法に切ってから現場に持ってくることで、現場が楽になるし精度も確保しやすいというのがプレカットです。プレカットで大事なのは、工場の機械が寸法を理解できるということです。私が知っている限りではそれほどうまくいってなくて、特に鉄骨ではそれが顕著です。鉄骨屋さんは多くが十数年前に買った機械を使っているので、最新のTeklaのデータがそのまま入らず、実際はオペレーターさんが個別に寸法を打ち込んでいます☆41。将来的にはBIMのデータから直接機械を動かすことができるかもしれないのですが、まだあまりリアリティがないと私は理解しています。前半でお話したように、生産性を上げていくためにお互いにデータをやり取りする際の境界線やルールを探し出していくことが必要だと思います☆42。

☆41──［堀川］機械を入れ替えるタイミングや周期が気になる。それに応じて生産効率ががらっと変わっていくことにるのだろうか。

☆42──［石澤］その後Twitterで、これは木のプレカットの話ではないかというご指摘をいただいた。木材プレカットはかなり広く行なわれているし、ドイツのICDやスイスのETHZなどで研究対象にもなっている。ただ、切断は比較的大丈夫だが、穴あけのように反力を考慮しながら加工するようなものを汎用ロボットでやろうとするとかなり難しい。力技でズバッといけるもののほうが容易、と理解しています。