抽象化のジレンマ
https://scrapbox.io/files/63824598967bb3002292b4b3.png
よさをどこまで抽象化して実装すべきかという境界問題。 パラメトリック・デザインを突き詰めるほど、無数のパラメーターそれ自体の情報量は非パラメトリックにやるのと大差無くなっていく。
よさの探索空間において、パラメトリック・デザインという高速道路をどこまで稠密に配備すべきか。偶然にもその道路がよさの山のちょうど頂上を通過する場合はいいが、そうでない場合の方が多い。頂上へのラスト・ワンマイルを、一般道に降り、そして車からも飛び降りて、自分の脚で踏破する必要がある。
baku89.iconがHoudiniの便利さについて話した時、細金卓矢氏が パラメトリック・デザインを突き詰めると、万物を表現するのに足るあらゆるパラメーターを詰め込んだ、「もの（Thing）」ノード一つで済むのでは
というようなことを言ってたのを覚えてる。同様のことをホフスタッターも。
もしも、より高度の抽象化へと向かうことが、つねに望ましいことだとしたら、私たちは結局、状況などというものをけっして区別しないことになってしまうから。あらゆる状況の最良の記述が「なにかが起こった」ということになってしまう。「メアリー」というよりも「女」と、「女」というよりも「人間」と、そして「人間」というよりも「生きもの」、「生きもの」というよりも「物理的存在」というほうがよくて、最後にはたんに「もの」という言い方が勝利を収めることになってしまう。
[『メタマジック・ゲーム』p.570
例えば、パラメトリック・モデリングは便利なのだけど、いい具合の造形を作り込むためにパラメーターを無数に増やしてシッチャカメッチャカになるくらいなら、多少手戻りが効かなくともダイレクト・モデリングしたほうがいい。「キャラ」をMiiのように自動生成出来るとしても、そのバリエーションには限界がある。その表現力を豊かにしようとするほど、
問題となるのは最低限の抽象化をどこに設定するかである。
(…)
最低限のラインを大きくすると、それは基本的に、十二音の音階や、モジュラーシンセサイザーのメタファーなど、ある音楽様式が言語自体に埋め込まれてしまい、プログラマーの思考をその様式に固定してしまうだけでなく、基本的にプログラミング言語としての抽象化能力は高くないものが多いので、基本から外れた試みを行うためにその言語上で高度なライブラリを作ることも難しいといった問題が生じてしまう
一方で、最低限のラインを下げれば下げるほど、その言語自体の設計や実装に必要な知識は音楽ではなくコンピューターに関する知識そのものになっていく。
https://gyazo.com/6c4e53bb3465d9ddf45ab1bf696385f2.png
「怠惰さは美徳」というテーゼは、コンピュテーショナル・アーティストには当てはまらない。
「3度繰りかえすことは自動化せよ」という教訓が普通のプログラマーにとって有効なのは、自動化による恩恵はスケールするから。仮にその人個人にとって、その自動化のための労力が、3度愚直に繰り返す労力を上回ったとしても、自分以外の多くの人のムダを省いているのであれば結果的には得となる。そして、無数のユーザーに向けてWebサービスやソフトウェアを書いているプログラマーは、自動化を自己目的化したとしても、その倒錯は大概にして報われる。
しかし、コンピュテーショナル・アーティストにとっての自動化は、（みんなが使える汎用ライブラリをつくる場合をのぞいて）常に自分のためにあるし、特定の作品のためにある。スケールしない。
もう一つ厄介なのは、自動化によって試行錯誤が容易になることで追い込める「よさ」と、自動化する手間を惜しんで愚直に試行錯誤に励むことで高められる「よさ」とを常に天秤にかけなくてはいけないということ。その天秤にかけるという行為もまた、重たい常駐ソフトとして貴重な脳内リソースを圧迫しやがる。
いっそのこと「自動化は善」に振り切る方が良いという考え方もある。自動化にかける労力が増える分、ファインチューニング（※ 自動化装置のパラメータ調整ではなく、ジェネった結果をBakeし、更に加筆や調整を重ねる工程を指している）にかける労力は切り捨てる。プログラマーお得意の抽象化能力を用いて、自動生成の段階だけでギリギリまでよさを追い込めるようにし、その結果をよさがあるものとして一旦信頼する。多くのジェネラティブ・アーティストは、無意識的かこの戦略をとっている。 一方で、1から100までマニュアルで作ることでお決まりの手癖にハマることを防ぐためのサイコロとして、パラメトリック・デザインを取り入れるという考え方もある。モデラーのYuuki Morita氏がHoudiniを触っていたとき確かそんなことを言っていた。その場合、もはやパラメトリックである必要すらなく、完全なたらめでもいい。というか、でたらめとマニュアルのその間のグラデーションのどこを操作系として良しとするかという問題にもなってくる。良い文章をつくるのに、猿にタイプライターを叩かせるか、バロウズのように単語単位では形をとどめつつ、そのつながりをカットアップするか、ブルトンのように自動筆記という形で、でたらめさの中に頭の深層意識や統語感覚を辛うじて挟み込むことで、より文章としての体裁を保つ可能性を高めるか。でたらめと意識下のマニュアルとの間のどの中間地点が、作品としての体裁を保たせつつも、お決まりからの逸脱をもたらすのに最良なのかについて考えていく必要がある。
一方で、制作プロセスを、自動化至上主義とする段階と、ちまちま最高! な段階とに分ける戦略もある。つまり、自動化作業というのはプロプロダクションの時点であらかじめ済ませておいて、よさをファインチューングする実制作の段階ではチマチマやることを善とする。baku89.iconはこのタイプ。クリシェを避けるという意味では「カットアップ」戦略と同じ目的を持っているが、人の身体や意識を介さない外因的なでたらめを練り込むのではなく、何かをマニュアルで作り上げるそのプロセスにおける思考の傾向や手癖を変容させることで、出来上がるものが自ずとズレるよう仕向ける。
とにかく、「効率化がもたらす効用と、愚直にやる効用とを天秤にかける」という常駐アプリをいかに走らせずに制作に集中できるかが、プログラミングスキルを持ったアーティストに暗に求められている。