ワークはツリーではない

まずはツリーについて

どこかで聞いたようなタイトルを付けました。

この記事の前提としてWBS(Work Breakdown Structure)という概念があります。

タスク管理ツールasanaのページのリンクを貼っておきます。
(https://asana.com/ja/resources/work-breakdown-structure)

若干トートロジカルな言い方になりますが、WBSというのはリンク内の作業分解構成図で示されている構成のことです。

外装工事一式の下にガラス工事、金属工事…があり、ガラス工事の下には生産設計や製品調達、検品、ヤード管理があり…というように仕事の親子関係を整理したものだと考えてください。

そう、これは基本的にツリー構造で作業（たとえば建設工事）を把握するものです。

このような形で整理することで、作業間の依存関係が視覚的に把握でき、
会議体の形成（参加者の選定とか）、共有フォルダの構成などを決める際の土台となります。

WBSに表現されない関係

ものごとがすっきり区分けして縁を切れるときはWBSを明示してそれぞれに対処していけばいいわけですが、建築物は必ずしもコンポーネント化されたものの組み合わせだけではできていません。

仕上のパネルと支持部材は必ず何かしらの方法でファスニングされています。

このとき、パネルの構成と支持部材の構成が同じになっていればよいのですが、違ったらどうでしょうか？

例えば、既存躯体にたいしてファサードだけやりかえるような場合は躯体側から出ている支持部材の構成は各層ごとなのたいして、仕上パネルは外装デザイン上のエレメントごとにまとまっているというようなことがあります。

この場合、ややこしいのはパネル側のシステムとも関係あるし、躯体側のシステムにも関係あるものの管理です。

たとえば、パネルと躯体側ブラケットの間にマリオンがある場合を考えてみましょう。

マリオンは躯体に定着するための一次側のファスナとパネルを固定するための二次側のファスナの両方が取りついています。

樹形図で描くと下図のようになります。

（マリオンまで階ごとで整理すればよくなりそうですが誇張して書いています）

一度別れた枝同士が関係してしまうので、作業間のすり合わせが必要です。

すり合わせる相手を探そう

すり合わせの例としてマリオンの製作図を起こすために一次側二次側のファスナを探すことを考えます。

一次側のファスナにはスラブごとにアドレスが振られていて（2FL-F01,2FL-F01,2FL-F01…）
二次側のファスナにはパネルごとにアドレスが振られているとします（E01-F01,E01-F02,E02-F01…）

モデル上で物理的に接触しているものの対応関係は何らかの演算（干渉チェック的なやつ）によってすぐ把握できるんじゃないの？という声を耳にしますがよくある誤解です。

小さい範囲であれば力とパワーで干渉チェックの要領で対応関係を探すこともできますが、かなり早い段階で処理が重くなり、ソフトが落ちてしまいます。

ではどうするのかというと文字列の検索で対応関係をさがすのが賢いやり方とされています。

例えば、パネルの名前に対して枝番を付与することで２次ファスナ番号がきまっていれば、文字列のセパレータを使いつつファスナー側から対応するパネルの番号を抽出することができます。

Eg. ファスナE01-F01はパネルE01につく

こういう作業がしやすいようにBEPを作成する際に命名規則を検討しておくわけです。
対応関係が把握しやすい名前の付け方を考え、モデルに名前を付けるようになれば、第一歩です。

名前だけで解決しない問題

同じ発想でパネルではなくマリオンのファスナとの対応関係を把握するにはどうしたらよいでしょうか？

まず、ファスナと共通してマリオンもパネルと親子関係になっていれば話は簡単です。

Eg. マリオンE01-M01はパネルE01につくので対応するファスナはE01-F01,E01-F02…

ツリー構造が単純だと簡単ですね。

さて、上の図のようにマリオンが複数のパネルをまたいでいたらどうなるでしょう？

（複雑なファサードでは外装パネルが階をまたいで滑らかにつながることはよくあります）

名前で検索すると過不足があります。

この場合の解決策はモデルに対して名前以外に属性情報（RhinoであればUser textと呼ばれるもの）を書きこむことです。

たとえばパネルについている2次側のファスナに付ける属性情報はこんなものです。
Id = E01-F01
Mullion_id = 2FL-M01

このような対応関係を後付けで入れていくのは相当な手間がかかる一方で、モデリングの際に意識して一度仕込んでおけば後工程が圧倒的に楽になりますし、grasshopperを使うのであれば、作図するときに関係のあるジオメトリーの名前を取得して自動的に書きこむのは造作もないことです。

まとめ

「対応する部材名を属性情報に書きましょう」ってそんなことで何が変わるのか？と思われるかもしれません。

だまされたと思って書きこんでみるとプロジェクトの後半で詳細図を描いたり、数量拾いをするときに効果が実感できるはずです。

試してね。