2018.10.18

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

“HONDA”がおいらの相棒　言う事聞かないオンボロ
どしゃぶり夜中に家まで　汗まみれ
--
イカスぜ おれの相棒　まわりの誰より早く走れ
お前とおれが組めば　すべて うまく行く
（奥田民生／ルート２）
 
ソフトウェアやヴィジュアルプログラミングの講習を受けて、実務で使う機会を逸してしまう
「ペーパードライバー」が多いのはある程度仕方がないかもしれないな、と思ったりします。
その人なりに思うところもあるだろうし、まったく新しいことをするのはハードルも高いだろ
うし、ソフトの操作と実務的な問題を切り分けながら使っていくのは容易ではないだろうし、
などと色々と想像を逞しくするうち、事情は理解できるなあといつのまにか腹落ちしてしまう
ためです。もちろんそのままではROI (return on investment)が上がらない訳で、決してそれ
が良いわけではありませんが。
 
しかし、「ちょっと使ってみたけどありゃ駄目だね」という声もときどき聞かれ、そちらのほ
うはちょっと気になる昨今です。鋭い意見のこともあれば、ただの野次馬（またはポジション
トーク）のこともあって、こちらとしても中身をきちんと知らないとその区別がつかないから
です。
 
デジタル界隈の勘の鋭い人は、ソフトウェアにできることには限界があることを最初から知っ
ていて、その「出来ないこと」のつくる領域からデザインに対するシステムの強度を推し量り、
うまく使おうとしたり、必要に応じて拡張しようとしたりします。
先日の建築情報学会キックオフ準備会議 第４回（大盛況でした、ご来場の皆様ありがとうご
ざいました）で杉原聡氏が言及された「(所属していたMorphosisの)Thom Mayneは、私が
作ったシステムの詳細は分からなくても、そのシステムに出来ないことを鋭く見抜き、そこを
開発するように要求してくる」という話がまさにそれで、これは欠かせない嗅覚です。気に
入った道具を使い倒すうえで、その限界を知ることは必須です。
 
自分の愛車はガス欠ランプが点いてからあと何km走れるのか、給油口が開かないときはどこを
めくればいいのか。「使い倒す」は、単なる「愛用する」とは異なります。たとえ壊しても直
す覚悟で、その道具の背景にある思想に触れ、道具にできる範囲を身体感覚と結びつけること
です。
 
付喪神（九十九神）とは、長年使い続けた道具には神が宿るとし、その道具に対して生じる霊
性に対して畏敬の念を示す概念です。
それが鉛筆には宿ってDynamoには宿らないということはないと私は思います。辛抱強く付き
合い、時間をかけて知ることで、どんなものにでも生じ得ます。
 
上記の会議で石津優子氏が指摘した「提供したツールが設計者の中のある点に到達して、他の
細部ができていなくてもあれこれ使い始める、そうなった時が開発をやめる時」という点は、
これに関係しているように思います。この場合、使い倒した結果そうなるというよりも、この
道具を使い倒そうと直感するポイントが「手離れ」のポイントだとなりますが、それを判断す
る何らかのクライテリアが使う側には備わっているということだと解釈できます。
 
このことは、見た目に使いやすいかどうかということとは甚だ無関係ではないかと私は考えて
います。
幼少期。夕食のハンバーグの横に人参のグラッセが乗っていて、私はそれが好きではありませ
ん。食べるのを躊躇している私に親が言います――甘くて美味しいから食べなさい。その頃の
私は甘く調理してある食事が苦手だったのです。美味しいかどうかは僕が決める！……とは言
わず、食事の最初に食べるなど工夫して食べてはいたわけですが、いずれにせよ、甘くて美味
しいと食べたいはこの場合無関係だったわけです。
 
使いやすさに対する配慮というものは必要です。使っていて痛みを感じるほど苦痛なシステム
というのも存在するからです。
しかし一方で、「可能性を感じる」という力が人間にはあります。「少ないインプットから(主
に意味のつながりを考慮して)全体をかなり高い精度でかつ高速に推量するという脳の処理」
によるもので、今日のAIが不得意とする領域の典型です。
この人間としての能力を活用するつもりである、ということが重要です。つまり「直感がそう
云う」を理由にするということです。そうして実際に使い続けることで、当初は思いもよらな
かった結果を得て、「手放せない道具」になっていく。これが「使い倒す」ということです。
使い倒してどうなるかということを事前に説明することは容易ではありません。そこに賭けて
使ってみたいという以上の動機は、ほかにちょっと思いつかないほどの力を持っています。
 
さらに私は個人的には、そこで使える道具のバリエーションは多いほうが良いとも思っていま
す。建築情報学会キックオフ準備会議の第３回、前回木内俊克氏が言及された伊藤亜紗氏の
「どもる体」の話で思いついたことです。
詳細は木内氏のコラムおよびこちらをご参照いただきたいのですが、人について「ノる」と
「乗っ取られる」というモードを考えます。身体が拡張されたように「ノッている」状態と、
主体性を奪われて雁字搦めになった「乗っ取られた」状態はときに表裏一体です。
この「ノる」という状態は、何千回ものフィードバックを経てではなく、たとえば同じ絵柄を
数回スケッチしただけのときにも起こっている感覚があります。そうすると往々にして、人は
自分の描いたものに「乗っ取られ」、その外に出ることが困難になります。そこで思い起こさ
れるのが、伊藤氏が言及された「つねにパターンを探索し、複数のパターンで更新を繰り返す」
ことです。
 
ある道具ではどうしても難しい領域があり得て、その道具の中ではそれを避けるという解決策
をとりがちです。しかし道具を変えればいとも簡単に解ける、少なくともその切迫感からは逃
れられるということはあり得ます。
機能の重複する道具を複数持っていても良いのです。それがないといけないと感じることは、
人のしぐさや方法論がいとも簡単にロックされてしまうことを知っていて、その回避の仕方を
知っている人だとも思われるのです。
 
そして、それがゆえに標準化が難しい。それは尤もなことです。
だからといって諦めるわけにもいきません。建設業で扱うデータはただでさえ粒度が整わない
のです。マニュアルをつくってしまいがちな思考回路はおそらく多くの人に共通ですが、機械
の操作などと建築設計プロセスの標準化が異なるのは、人の命を損なうような操作を回避する
ための標準化でなく、データをつくる効率やつくられるデータの価値を高めるための標準化で
あるということです。だから手続き的でなくてもいい、なんのためのデータであるか（その
データは何をするためのものか）が重要です。それを決めて合意し、その質を高めるよう作業
すればよいのではないかと考えられます。
 
ただ、そのデータの命は時々危機にさらされるのですが。共有サーバのファイルが移動してい
たりするとヒヤッとします。そうすると最低限のマニュアルはいるのかもしれない……。私は
マニュアルが嫌いなのでなるべくなしで済ませたい人間なのですけれど。
ええ、これが本音というやつです。

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