2018.11.27

パラメトリック・ボイス　　　　　　　　　　 　　　　　竹中工務店　石澤　宰

人から時々、「石澤さんってメモ帳使うんですね」と言われることがあります。私は現在の所
属がコンピュテーショナルデザインチームであり、おおよそ毎日HP ZBookかMacBook Proの
どちらかとにらめっこをしており、またデジタル界隈の話題が好きでもあるので、アナログの
世界には住めない人、あるいはもう卒業してしまった人だと思っていた、ということのよう
です。
 
結局、手で書くと身体感覚が強く伴うのでよく覚えるし考えがまとまる、ただその後の編集や
配布にはあまり向いていない、だから好きな方を選べるようどちらも持ち歩きます。文房具の
話も大好きで、今持ち歩いているペン（CROSS Classic Century＋Frixion Ball 0.7mm）と
ノート(RHODIA Desk Webnotebooksドット罫)にたどり着いた理由を話し始めたら止まりま
せん。ルックアンドフィールは大事、道具を変えるとアウトプットも変わる。持ち歩く道具の
ラインナップで自分のできることも変わるので、そのチョイスは楽しいものです。
 
デジタルであれアナログであれ、私は人よりもメモやノートを取る量が多い自覚があります。
キーワードだけをメモする、あるいは記憶に定着させるためにメモをとらないという流儀の人
もたくさんいますが私は逆で、打ち合わせやレクチャーに手ぶらで行くと不安感を覚えます。
聞いたことを書き留めてあとで見返すという、自分の作業をアーカイビングする機会を逸した
ように感じるからです。
こうした性質のことを「メモ魔」と呼ばれることについて、私はまったく納得がいっておらず、
最初にそう呼ばれた人が誰かいたことはまあいいとして、なぜその言葉が人口に膾炙したのか
不思議で仕方がありません。人様に何の迷惑も及ばない、純粋に自分の思考回路のために行っ
ているそのことをなぜ魍魎の類と一緒にされなければならないのか。そのうえ横を見れば放火
魔や遅刻魔やキス魔がいて、なぜこんな迷惑な人達と一緒にされなければならないのかとやり
場のない怒りに憤る毎日です。嘘です。そこまで悩んではいません。
 
日本建築学会機関誌「建築雑誌」12月号に、建築のデジタルアーカイブについて寄稿をさせて
いただきました。データの更新、公開、知的財産権など、データを作って運用する「以外」の
部分について気になっていたことを書く良い機会をいただき、思いの丈を詰め込みました。ぜ
ひご一読いただければ幸いです。
とくにBIMという文脈について、データをどう保存するかということはまずもって「どのデー
タを最新として扱うか」という問題と深く関係しており、このコラムでも一度考えてみたこと
があります。では最終モデル・引き渡しモデル以外の情報はどうか。モデル以外にも議事録や
仕様書、製品マニュアルや検査記録など残すべきものは山程あって、モデルさえ持っていれば
建物のすべてがわかるとは残念ながらいきません。また、設計の過程で検討したが採用に至ら
なかった案、今後の建物の使い勝手を見越して行った設計変更の想定するバリエーションなど、
もしかしたら捨てずにとっておくべき別モデルもあるかもしれません。こうした情報はどのよ
うにとらえ、どのように選別しアーカイブとして運用すべきなのでしょうか。
 
とらえどころのない話のように思われたのですが、意外なところに切り口が見つかりました。
先日、Common Data Environmentとは何だろうかという議論をしていて、改めてその基本的
な定義となるBS1192:2007 (BS = British Standard)およびPAS1192-2:2013 (PAS =
Publicly Available Standard)を見返していたところ、用語の定義の中にこんなことが書いてあ
りました。
3.1 Archive
component of the common data environment (CDE)
たったこれだけです。しかしこれは、CDEの中にないものはアーカイブではない、ということ
もまた意味しています。
 
そもそもCDEとは、「ワークを共有するための協業的環境を提供する手段」であると定義され
ています。より平たく訳せば、仕事を分担して進めるためのコラボレーションに適した環境を
プロジェクトメンバー皆に与えること、およびその環境のことです。つまりアーカイブとは、
「コラボレーティヴな仕事をしていて、その人たちが原則的には全員アクセスできる場所にあ
るデータ」を指す、というわけです。
そう考えると、アーカイブとしてどこまで情報を置くか、つまり誰もがすべての情報にアクセ
スできるべきと考えるか、皆がアクセスできるのは確定的な情報に限定すべきと考えるかは、
定義の面ではどちらでもよく、それはプロジェクトや組織の主義・方針によるものであると考
えられます。
 
ビル・ゲイツは1999年、TIME誌のインタビューにこう答えています。
「力の源泉は秘匿した情報ではなく、共有した情報だ。企業の価値観や報酬システムに、この
考え方を反映させる必要がある」。
「How Google Works」でエリック・シュミットらはこう主張します。
『経営の上層部が情報を集め、どれを誰に渡すか慎重に検討する。この世界では、情報は支配
の手段、権力の源泉として厳重に管理される。（中略）このようなケチケチした情報分配シス
テムも、従業員の仕事が「働くこと」だった時代には成功したかもしれないが、インターネッ
ト時代の従業員の仕事は「考えること」だ』。
これがそんなに素晴らしいなら、なぜどこも今すぐこうならないの？という疑問はもっともで
す。しかしながら大局的に言って、情報は少しずつすべてのメンバーにイーブンに配分される
ようになってきているようには感じます。私も基本的には同意で、人の主体的な思考と判断を
促すためには情報を限定することは意味が薄いと考えます。
 
ただ、建築に限って言うと、公開と言っても中身をちらっと見て目的のものを探すということ
がなかなか大変で、とにかく取っておけばいいとも言いきれません。紙図面ですら、山と積ま
れた図面から前回の打ち合わせスケッチを抜いてくることは楽ではないのに、これが適当に名
付けられた「ファサード打ち合わせ変更案B-修正指示済(2)」みたいなファイル名だと絶望的
です。
だからこそ命名法（Naming Convention）が大事！適切な名前のついていないファイルは無
価値！という立場が生まれます（あるいは、メタデータを使え！情報には属性を与えよ！とい
う立場もあります）。命名の徹底したフォルダは見ていて気分がよく、もちろんアクセシビリ
ティも最高です。
しかしそれは、徹底されるまで辛抱強く引っ張っていく人の存在なしには勝手に実現すること
のない世界でもあります。生物はエントロピーを減少させるとはいえ、情報エントロピーがこ
んなに減少することはありません。少なくとも私には無理です。
ルールを決めて皆がきちんと守るコミュニティの実現、という目標はもちろん正しいのですが、
なにしろプロジェクトは時間が限られていて、しかもみんなが徐々に忙しくなっていくので(フ
ロントローディングが実現したとしても、仕事のピークが去った頃には次のプロジェクトがも
う来ているものです)、なるべく覚えられるくらいのシンプルなルールを徹底するほうが私には
自然に思えます。
 
10月5日、日本建築事務所協会連合会総会のディスカッションにパネラーとしてお呼び頂いた
とき、「建築の情報活用という面でみんなが今すぐできるコツみたいなものはありませんか」
という質問をいただき、私は「絶対にそれが避けられないという状況に直面するまで、データ
はなるべく一つにしておくことです」とお答えしました。バックアップは別として、データは
なるべくまとめる、かためる、一つにする、分散させない。マネジメント効率が上がるから
です。
今もうひとつ、「情報は捨てない、整理に時間をかけない、ただあとで見そうなものだけはわ
かるようにしておく」ということも思いついたので追記します。データ管理というより整理整
頓のコツみたいな話ですが、よく効きます。

たとえば、最近私はプロジェクトごとのフォルダ構成を上記のようにしています。ここで、
さっと取り出す必要があるもの、あとで再利用する可能性のあるものは特別に0フォルダに入
れることにしています。こうしておけば他の人でも、まずどのフォルダを開くべきであるのか
すぐにわかると考えたからです。
 
引っ越しなどの際、中身のあるダンボールをついに開けることなくそのまま廃棄してしまった
経験のある方はいると思います。デジタルストレージは物理的空間を圧迫することこそないも
のの、中身の探せないアーカイブも虚しいものです。
誰にとっても完璧なアーカイブなど存在しません。想定外の用途に耐えうるアーカイビングは、
ある面において過剰投資です。シンプルなルールを守り、そのデータは「開架書庫」に置いて
おく。そのくらいであれば、何年かかければ実現できそうに思えるのです。
 
ところで、命名法などの議論を英語圏ですると、そのルールを守らせ違反を取り締まる人のこ
とをよく「police」と呼びます。私はポリスになるには向いていないかなと自己分析しますが、
でもそういえば「魔」はまだ取れていないのでした。
あと一ヵ月早ければハロウィンに引っ掛けて書けたのになと思っています。

 

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
•