月曜の朝、協力会社から「この梁の下端、干渉してませんか」とチャットが飛んできた。モデルを開いて確認すると確かに20mm干渉している。こういう小さな確認を週に何十回とやりながら、ふと「BIMの本当の価値って、こういう地味な突合の先にあるはずだよな」と思い直す。今週はそんな地味さと、その先にある未来を感じさせる記事がいくつか出ていたので、社内展開の参考になりそうなものを整理しておきます。
今週押さえておきたい3本
清水建設、BIMから地震損傷リスクを解析するモデルを自動生成
BIMで地震の損傷リスクを予測、清水建設が解析モデルを自動生成する技術開発。設計BIMから構造解析モデルを自動生成して、地震時の部材損傷リスクを可視化するというもの。うちの構造部門でも、意匠BIMから解析用モデルに落とし込む工程はいまだに手作業が多く、数日単位の工数がかかっている。ここが自動化されれば、初期段階でのBCP提案や免震・制震の比較検討が発注者との対話の中で回せるようになる。
歩行しながら空間をスキャンできるLiDAR「Raven」
歩行しながら空間をスキャンできるLiDAR 3Dスキャナー「Raven」。SLAM方式で、歩きながら半径50mまでの点群を取れる。改修案件や既存躯体の現況把握で、三脚を立て直しながらのスキャンに半日潰れるのは日常茶飯事なので、これはかなり気になる。精度がどこまで実用に耐えるかは触ってみないとわからないが、干渉チェックの前段階の「そもそも現況モデルがない」問題を薄くしてくれる可能性はある。
ハンドオーバー時のCOBieをどう仕込むか
The Thirty-Year Problem Nobody Plans For: Getting COBie Right at Handoverは、設計・施工の2〜3年に注力するあまり、竣工後30年の維持管理データ引き渡しが軽視されている、という主旨。日本ではCOBieそのものはまだ浸透していないけれど、発注者から「維持管理BIMで納品してくれ」と言われる案件は明らかに増えている。属性情報を後付けで整えるのは本当にしんどいので、着工前のBEP段階でどの属性を誰がいつ入れるかを決める、という当たり前の話に帰結する。
ゼネコンBIM担当としての独自考察
清水建設の解析モデル自動生成の話を読みながら、自社の標準テンプレートに立ち返って考えていました。自動生成が成立する前提は「設計BIMの属性・分類が揃っていること」で、これが揃っていないモデルからは何も生まれない。うちの社内でも、部材のTypeName命名規則すら物件ごとにバラついていて、施工段階で数量拾いに回すと積算部門から「これ何の部材ですか」と問い合わせが来る。自動化の話が出るたびに、結局は入り口の標準化に戻ってくる。
Ravenのような歩行型スキャナーは、協力会社に配れるかがカギだと思ってます。ゼネコン本体で1台持っていても、現場ごとに取り合いになるだけで、結局スキャンが必要な場面で使えない。躯体工事の要所要所で、職長さんが自分でスキャンしてクラウドに上げてくれる運用が組めれば、出来形管理と次工程の干渉チェックが同じ点群で回せる。ただし、点群データの管理容量とライセンス費用の問題があって、社内の情報システム部門を説得するのはたぶん一番の関門になる。
COBieの話は、うちだと「発注者から要求される前に、社内の維持管理系グループ会社と組んで先に標準を作る」のが現実解じゃないかと感じてます。発注者要件が出てから対応すると必ず後手に回るので、グループ内のFM部門が実際に使う属性リストを逆算して設計BIMに埋めておく。まだ試せていないが、この順序で回せれば発注者提案の武器にもなるはず。
まとめ
今週の記事を通して感じたのは、BIMの新技術が出るたびに求められるのは結局「入り口の標準化」と「協力会社まで含めた運用設計」だということ。清水建設の自動生成も、Ravenの点群も、COBieの引き渡しも、モデルの質と属性が揃っていて初めて効いてくる。派手な機能に飛びつく前に、来週は自社のTypeName命名規則の見直し会議を1本入れようと思ってます。地味だけど、たぶんこれが一番効く。