BIMの夜明け
2023.01.26
パラメトリック・ボイス 芝浦工業大学 志手一哉
BIM演習の授業で開催した特別講義で招いた設計実務者の講師にしていただいた講義で強く印
象に残る言葉があった。その言葉は「BIMを使わないことのデメリット」である。日頃「BIM
を導入することのメリット」という言葉に違和感を持っていた私にとってかなり腑に落ちた表
現であった。「BIMを使わないことのデメリット」とはどういうことか。例えば、建具の情報
を管理する場合、BIMであれば図面で表現しても建具表で表現しても双方に違いは生じないの
で整合性をチェックする必要がない。BIMを使わない場合には、建具記号、巾や高さ、建具表
への記載忘れなど、図面と建具表の不整合をチェックしなくてはならない。建具の数が1,000
や2,000もあれば相当の時間を費やすし、レビューや概算の都度チェックを繰り返す。設計途
中なので建具の変更は当然のように生じるので、齟齬のない状態を確保するためにかなりの工
数を費やすのだが、その労力のほぼ全てがBIMを使っていればしなくてもよい無駄な作業であ
る。当然、オブジェクトのパラメータに入力した情報が正しければという前提だが、その前提
は図面に建具や建具符号および注釈を記述する場合でも同じである。情報の真正性はデータ
ベースでも直接記述でも変わらない。ドキュメント間の食い違いを何度もチェックするという
BIMを使っていればしなくてもよい作業は、仕上げ表や面積表など設計業務の随所に存在す
る。また、BIMを様々なビューで表現すれば、打ち合わせのためだけに色分け図や簡易なCG
などを準備しておく必要もない。若手の残業に無駄な作業が占める割合はいったいどれほど
になるだろうか。BIMを導入することのメリットという「今が正しいと考えてさらに何ができ
るか」を追い求めるよりも、BIMを使わないことのデメリットという「今の苦行を解消する」
考え方をする方が健全である。
似たようなロジックで「建設分類体系を使わないことのデメリット」を考えてみたい。BIMは
モデルベースの建築情報構築手法なので、配置したオブジェクトの数以上にデータが存在す
る。その膨大なデータに対して、並び替え、集約、抽出などの操作をしなければ、作業に必要
なデータを絞り込むことができない。BIMソフトウェアにおけるオブジェクトのカテゴリー
は、柱、梁、壁、床、階段など部位の名称がついているものの、実際は立体形状の生成方法の
カテゴリーである。そのため、柱コマンドで生成した手すり支柱、床コマンドで生成した坊水
層などカテゴリーの名称と設計者の意図が合致しないオブジェクトが混在する。そのため、オ
ブジェクトのカテゴリーだけではデータの操作を十分におこなえない。それを補っているのが
オブジェクトの名称である。人はオブジェクトの名称を見れば、そのオブジェクトが何を意図
しているかを判断できる。人が判断するならば、「RC柱」も「コンクリート柱」も「CON柱」
も同じ意味として理解できる。ただし、昇順/降順で並び替えても同じ概念（クラス）のオブ
ジェクトが集まるわけでもない。多様な表現の名称から「鉄筋コンクリートの柱」と同じ意味
のオブジェクトを抽出するために、辞書的なマッピングを用意することも考えられる。それが
上手くいったとしても、構造体 > 上部躯体 > フレーム > 柱のような階層的なクラスを定義
できないので、そのデータを何某かのソフトウェアやシステムで利用することに適さない。結
局、自分の作業や他のシステムに使うためのデータセットを手間ひまかけて整理する必要があ
る。オブジェクトのプロパティに建設分類体系の番号を入力しておけば、データの抽出、整
理、集約を容易におこなうことができる（例えば、拙著：BIMにおける分類体系の利用、鈴木
裕二：Uniclassが日本語になった）。建設分類体系を使わないデメリットは、BIMのデータを
利用するためのデータ整理という無駄な手間がかかることである。建設分類体系を入力してあ
れば、その手間を省くことができる。では、建設分類体系の番号は誰がオブジェクトに入力を
するのか。それはオブジェクトの設計意図を伝えたい人だろう。社内外／国内外のあらゆる人
やコンピュータに設計意図を伝えたいならば共通言語で意思表示する必要がある。「私の言葉
を察してください」では想いが行き違う。
分類の階層は、「type of」と「part of」の関係がある（詳しくは、安藤正雄：BIMと建築
分類標準をめぐる考察）。「type of」は、上位クラスに対する種類である。例えば、柱に対
する、RC柱、S柱、CFT柱などである。つまり、下位クラスは上位クラスを具体化する選択肢
である。「part of」は、上位クラスの構成である。例えば、RC柱に対する、鉄筋、コンク
リートなどである。この場合、下位クラスの各項目は上位クラスからツリー状に分岐するわけ
ではない。例えば、鉄筋とコンクリートの組み合わせは、現場打ちRC柱クラスにもPC柱クラ
スにも、RC床クラスにもRC基礎フーチングクラスにも所属しうる。そうすると、「part of」
の下位クラスをモジュール化しておくと便利である。そのモジュールは、上位クラスと
「type of」の関係、つまり上位クラスに対する選択肢となる。Uniclassで言えば、システム
（Systems：Ss）は、プロダクト（Products：Pr）の集合という概念である。このような分
類の性質を理解することは、システムやプロダクトに対する仕様の情報をどのように持たせる
べきかを検討することに役立つ。プロダクト分類のモジュール化は、設計図書で一般的におこ
なわれている、壁や建具などを記号化してその構成および各構成材（材料や部品）の仕様をリ
スト化することと概ね似た意味を持つ。プロダクト分類をモジュール化しないことのデメリッ
トについて筆者の想像が及んでいないが、モデルベースで資機材に係る情報をデジタルでやり
取りする際に検討されると考えている。
BIMを使っていなければ手間のかかることはかなり多いと思う。しかし、その実感を得ること
ができるのは、BIMソフトウェアを使って仕事をしている人だけである。モデラーに説明する
図面を描いてもらい、モデラーが作成したモデルをチェックし、モデラーに修正を依頼し、必
要以上に高いLODを要求することもあり、コーデネーションの結果をモデルと図面の両方に反
映するための指示を出し、思うように完備されていないデータを利用しようとする、というよ
うなやり方では、手間が増えて当前である。設計者や技術者が自分自身でBIMソフトウェアを
使うようになるまでは、日本のBIMは夜明け前である。
