いま私が考える誰よりもわかりやすいBIMの説明
2017.03.14
パラメトリック・ボイス 竹中工務店 石澤 宰
Twitterである日見ていた画像で、「フィルムケース」に註がついているのを見て、確かにそれ
はそうだと思うと同時に、自分の世代が確実に「いま」に押し上げられているのを感じました。
私自身、最後に写真用フィルムを手にとったのはトイカメラを使っていた12年くらい前で、い
わゆる35mmカラーネガフィルムを最後に使ったのは一体いつのことやら……。知らなくて当
たり前です。現像写真に親しみのない世代から「写真はなぜ1枚2枚と数えるのか」と質問を受
けた、というツイートも少し前にバズっていましたが、私自身も最後に写真を現像したのなん
て結婚式の型物写真くらいかもしれず、こうやって自分は徐々に歴史の証人サイドになってい
くのか、などと思った次第です。
BIMでの仕事のやり方は、CADでのそれに多分に影響を受けています。そしてCADの成り立ち
はそれ以前の方法論に基づいており、結果的に「手描き・手拾い・手計算」時代の方法論が現
在の仕事のやり方の土台を構築しています。そしてそれは常にベストであるとは限りません。
先日参加したBIMの日シンポジウムの安井建築設計事務所 飯島憲一氏のプレゼンで、こうした
事例をいくつも伺いました。例えば、開口部にXマークをするのはペンプロッタがハッチング
に不向きだったための方策であったこと、積算基準では簡略化のため0.5m2以下の開口はない
ものとするが、そのような例外処理はデジタル時代にあえて行う必然性は薄いことなど。
「手描き・手拾い・手計算」で実際に行われるワークフローは今日でも健在であり、そちらを
ある日突然廃止するわけにはいかないことも想像できます。ダブルスタンダードを認めながら
移行していくこと以外に答えはありません。とくに教育分野、新しく建築について教えるとい
う場面において、「旧来の方法が正で、かつ唯一」という状況は、これから急速に実務を学ん
でゆく世代にとって遠回りになりかねないからです(QWERTY配列のような事例もあるにせよ、
です*1)。
ところで、フィルムケースと同様にレガシーになりつつあるものに「電話帳」があります。壁
に掛けてあって、店屋物を取るときなどに五十音の頭文字からページを開いて電話をかける、
あれです。こちらもおそらく、Generation Z世代の多くが「あるのは知っている」か「あった
であろうことは理解できる」のどちらかに該当するアイテムでしょう(「信じられない」でな
いことを祈ります)。
BIMモデルがどうあるべきか、この電話帳になぞらえて説明するとわかりやすいことを最近発
見しました。ここを読まれる皆様には甚だ当たり前すぎる話ですが、何かのお役には立つかも
知れず、今回はそれを披露させていただきます。
私の電話帳にJimmyという人物がいます。彼はシンガポールでお世話になった不動産屋で、よ
く連絡をとったので登録してありますが、フルネームも入っておらず、携帯番号以外の情報は
何もありません。しかし、この電話番号を鍵としてWhatsAppに繋がっていて、そちらで好き
なだけ連絡が取れましたし、私の周りにJimmyは彼だけでしたので、それで十分機能していま
した。
これに限らず、私の今持ち合わせている「電話帳」は、連絡先アプリの持っている機能からみ
れば甚だ不完全で空欄の多いデータです。電話で連絡をとらない相手も多数います(私の個人
の携帯で最後に電話をかけたのは2ヶ月前です)。しかし私はここを起点に大変多くの連絡を
とることが出来ていて、新しい連絡先を継ぎ足す程度のメンテナンスしかしておらず、「紙の
アドレス帳あるいは住所録」にあたるものは持っていません。これが現在の私の「電子化され
た電話帳」です。
これによって私は、連絡先を検索したり、LINEやWeChatなどのSNSアプリと連携したりでき、
またその連絡先を人に送ったり、iPhoneを買い換えたらデータを引き継いだりできています。
そのどれも、紙の電話帳では相応の手間を伴う作業です。
この電話帳、私だけが使っている限り、私さえわかるようになっていればそれで構いません。
カネやんやモッさんやのっちがアダ名のまま書かれていてもよく、場合によっては本名の方を
忘れていたりしますが、私が使う検索キーはアダ名なので問題は生じません。頭文字を何文字
か打つなり、最近の連絡先から探すなり、「あ」から順番に捲っていくなりして見つけること
ができます。
しかしこの、私だけの電話帳を他人も使うとなると話は別です。のっちは曖昧さ回避のために
正式名称に変えておく必要があります(それがPerfumeの大本彩乃だと全員がわかっていれば
別です。いえ、私が知り合いだというわけではありませんが)。もしそれが最初から前提なら、
私は本名をまず登録し、アダ名は別の何かのフィールドに書くようにするでしょう。
人によってはグループ分けをまめに行っていることでしょう。例えば私にとって親友である
のっち(くどいようですが架空の人物です)は、他の人にとっては取引先であることもありま
す。同じデータであっても、どのように利活用するかは使い手によって変わります。たとえば
私のiPhone連絡先だけからプロジェクトの協力会社一覧データベースを作るのは無謀です。信
頼に足るものが必要なら、いくつかのデータを組み合わせ、不足は補わなければなりません。
逆に会社が電話帳データを渡すよ、と言って受ける立場になったら、全社員の電話やメールや
配属先がわかると有り難いと思うでしょう。受け手の心理として理解できます。しかし一度そ
うしたなら、異動に伴うデータの更新は誰がやるのか決めておく必要があります。大規模なら
ば専任の誰か総務部的な人が必要になるでしょう。
紙のアドレス帳は、勝手に埋まるということはありませんでした(データだって基本的にはそ
うですが)。今後連絡をとりそうな人を予測して手書きする必要がありました。そうなると何
となく、そこにある欄は埋めなければならないような気がして、全員の誕生日やら郵便番号や
らを甲斐甲斐しく調べて書き写したりしていたものです。
ところが今お使いの携帯電話の電話帳を今もそのように作っている方は少ないと思います。必
要があって掛けるか着信したかの際に名前だけ登録しておく、という形で作った人が多いこと
でしょう。このやり方が可能なら、連絡をとるかどうかわからない人物を端から用意しておく
のは徒労です。そして一度でもやったことのある方なら、全員の顔写真つき電話帳を作るのが
どれほど面倒か(そしてやったとして、いかに「ただそれだけ」のものか)、わかっていただ
けると思います。
当たり前のことをくどくどと書いたようにも思います。しかし、上記を情報システム的観点で
少し言い換えてみるとこのようになります。
データを電子化すると利便性が高まる。アクセス頻度からみて、形状や属性は必ずしも完全で
なくてもよく、使う人に必要な情報さえあればよい。フォーマットを保ち、差分を補完しなが
ら都度データ構築するのが効率的である。情報は名前など何かのクエリで探せる必要がある。
グルーピングやフィルタリングは受け手側が自由に行って良い。まめに更新作業をしないと利
便性が大きく低下する。名づけ方には合意が必要であり、データを共有する際は、正確に命名
するのが望ましい。その際も受益者負担で必要に応じてデータを作ってゆくのが効率がよい。
見栄え良いデータだからといって役立つとは限らない……。
携帯電話を使っている方は、これらのことを深く体得されています。
さて、BIMは。もう説明はいらないと思います。あえて言い切ります。あなたの携帯電話の電
話帳機能と同じです。使いこなす必要などありません。どうしてもダメな方は紙の電話帳と携
帯電話を併用していたりしますが、BIMモデルと紙図面を併用する我々などはまさにその方法
を地で行っています。それでも電話は鳴り、連絡はとれるのです。
これはあらゆることに通ずる情報リテラシーです。そして何より大事なこと、一度でも携帯電
話を水没させたことのある方なら、痛いほど理解されていることでしょう。データは消える可
能性があるゆえ、常にバックアップをとることです。
……今回はバシッと決まったと思ったのですが、iPhone7は防水でしたね。昔のiPhoneは防水
じゃなくて水没するとデータが飛んで、などということも、数年後にはきっとレガシーになっ
ていることでしょう。
*1 QWERTY配列が生まれた本当の理由