4回にわたって書いてきましたデータセンターとBIMシリーズ、今回でひとまず完結です。最終回はSSOTの概念と、Revitを利用したSSOTの実現について説明していこうと思います。
これまでのデータセンターとBIMシリーズはこちら
blog.vicc.jp
SSOT原則
Single Source of Truth（信頼できる唯一の情報源）という概念があります。ひとまずフリー百科事典で調べてみましょう。
この言葉はデータセンターの事業主サイドから発せられることがあります（「SSOTになってますか？」など）。
この概念を理解するためには逆の「信頼できない複数の情報源」を想像した方がいいかもしれません。
例えば、とある建物の階段について、1FL-2FLの段数が平面図では20段で図示があり、階段詳細図に描いてある段数が21段、法チェック図に書いてある表から蹴上寸法と階高を読み取って逆算すると22段だったとします。信頼できませんね。
これは極端な例ですが、どれが正なのかわからないという図面の不整合は大小さまざまあります。SSOTとは、このような不整合に踊らされず、意思決定をできるように「何かの情報を問われた際には表現する場所が変わっても同じ回答が出てくるようなデータの作り方をしよう」という行動原則です。
BIMというとすぐに3Dモデルが思い浮かべられがちですが、形状に限らず、例えば床仕上のような情報に関しても図面ごとに文字で書き込んでしまうと不整合が起こります。何らかの方法で、データベースから引き出した情報が各図面や仕上表に表示されるような形式であれば、不整合が起きにくくなります。
先ほどの階段の例では、3Dを切り出すという方法で平面図も階段詳細図も作図されていれば、整合が取れそうです。しかし、法チェック図で表に文字として書き込んでしまうと不整合リスクが残ります。可能であれば、何らかの形でパラメータを連動させてモデルと表が整合しているようにしたいものです。
Truth（信頼できる）とは？
Truth（信頼できる）の意味合いを誤解されることがあるので補足しておきます。
Truth=真実の意味合いとして「設計としてあるべき姿になっている」というニュアンスに誤解されることがありますがそういう意味ではありません。
引き続き階段を例とすると、ある建物の一つの階段の段数として正しい数値というのはどういう意味でしょうか？
SSOT原則が厳守されたときに信頼できるのは「そのデータの利用目的に合わせて設計者が判断した結果として、どのような値が設定されたか」までです。
建築基準法やバリアフリー法に適合した寸法になっているか、建築計画的に良いものと判断される寸法になっているか、あるいは美しい寸法体系になっているか…などはSSOTの議論の範囲外です。
原理主義者は現実に耐えられない
さて、SSOTは原則論で、BIM実務では作業者の能力や容量、動員計画と合わせて現実的な落としどころを探ります。
日本に限らず、ある建物の設計フェーズや施工フェーズに必要なすべての表現形式をRevitで作図するという人員を確保するのは簡単ではありません。
それゆえ、とくに整合性確認がネックにならないような図面はAutoCADを併用するという場合もあります。たとえばディテールシートなどが該当する図面です。（注：AutoCADで描きながらRevitが並走したり、2Dを見てあとからRevitを起こす後追いBIMとは別のものです）
このような場合に注意を要するのは矩計図や平面詳細図などです。一般図レベルの検討がRevitで3D要素を利用して行われ、部門間での納まり調整を経て、いわゆる「一般図確定」の後にRevitからDWGを書き出し、詳細図は（作業要員が確保しやすい）AutoCADで作図するというワークフローがあります。これは現実的で、うまくいけば賢いやり方ですが、罠もあります。詳細図を作図した結果、一般図では見えていなかった納まり上の問題が発見され、一般図に遡及するような変更が行われる可能性がある点です。描かずに納まるならその図面は要らないわけで、描けば何かしら出てきます。
この問題を解決するために「あらゆる要素を3Dモデル化するんだ！」と絶叫しても、無い袖は振れないので…次善の策としてDWGをRevitにリンクして一般図と詳細図の整合確認をするビューを設定するという手法があります。半分人力ですが、Revitの運用能力がある人がすべて作図するよりは現実的ですし、PDFかなにかに書き出してしまえばチェック作業をする人は格段に増えます（ACCの2Dビューで指摘事項を使う方が良いですが…これはこれで心理的ハードルがあるようです）。
また、人的資源が潤沢だったとしても、原理的にRevitで要素間の連動性を高めて完全な双方向での同期を取ることの限界が存在します。
例えば、ファイルサイズが大きくなると操作性が悪くなるのでモデルは分割する必要があり、分割したファイル間での整合を取る方法としてコピー/モニターのような機能が存在します。しかし、同期を取る対象となる相手の変更を無視するというオプションが存在するので、作業者が不整合を生む余地は残されます。
また、要素間の拘束を設定しすぎると動作が重くなり、動かかなくなってしまうこともあります。
しつこく階段を例とすると、構造モデルと意匠モデルで同じ階段モデルを使うと、それぞれ図面を描くときに不必要な要素が表示されて不都合があったりします。
そこで作業性を優先して意匠と構造を分けると、「構造モデルで配筋をモデリングした後で、設計変更されて段数が変わっていた！配筋が意匠の階段から飛び出している！」ということが起こりえます。この場合も基本的には一度作ったデータ同士を突き合わせて確認するというのが現実的な手法です。コンクリートの仕上面と鉄筋であれば干渉チェックで検出は可能です。
総じて、一度SSOTの原則は意識しつつ、作業性を配慮して一度データをつくり、整合性確認をする手法を考えるというのが落としどころになります。
冒頭でリンクを貼ったWikipediaを引用すると「上記のようなSSOTの『理想的な』実装は、ほとんどの企業でまず不可能である。」(2024/12/03最終アクセス)ということも心に刻んでおきましょう。
しかし、Revitでは整合を確保するために有用な機能がいくつかあります。
- コピー/モニター
- 共有パラメータ
- 集計キー
- キーノート
これらの機能を活用してSSOTの原則を意識してBIMマネジメントすることは、必ずプロジェクトの質を高めます。特にデータセンターのような複雑な通信設備を抱える建物では、容易に図面間の不整合が生まれ、生産性が低下します。こうした背景から、事業主側からもSSOTの厳守が明示的に求められることがあるわけです。
Revitを用いた反SSOT
ところで、BIMソフトあるいはRevitを利用すればSSOTとなるのでしょうか？
察しの良い読者諸賢はここまで書いたことからお気づきかもしれませんが、答えは否です。
Revitで完結していたとしても下記のような要素によって矛盾を生むことは簡単にできます。
- ラインワーク
- マスキング領域
- ビューで要素を非表示
- 文字による注釈（パラメータと矛盾する書き込み）
- 詳細線分
どれも場合によって必要な機能ではありますが、悪意はなくとも矛盾を生んでしまうのはAutoCADと変わりありません。極論すると、Revitですべての要素を2Dで作図しても、図書一式を作成することは可能です。もちろんこれではSSOTとなる可能性は極めて低いでしょう。
重要なことはファイルの拡張子ではなく、SSOTの原則を意識したデータ作成方法の選択とともに、作業性を担保しつつ整合性を確認するワークフローであり、BIMのプロセスです。
まとめ
今日まで4回にわたりデータセンターのBIMについて書いてきました。後半はデータセンターの仕事でよく話題になるBIM用語の話をした結果、BIMの一般論になった気もします。ある意味でデータセンターの設計とBIMの親和性の高さの証左ではないでしょうか。データセンターに限らず、体系化された規範が適用されやすい半導体工場、集合住宅、工業化構法などとBIMの親和性は高いですが、複雑性が高いデータセンターはBIMによる生産性向上の成果がわかりやすいため特にBIMがプロジェクトの必須要素になる傾向があります。
データセンターの設計に関わり、事業主側のEIRからはじまるBIMで不安を抱えていたり、攻めあぐねている設計者の皆さんからのお問い合わせ、お待ちしております。
