橋本 麦∿Baku Hashimoto

目的に関知しない

外国語を学ぶ一番の醍醐味は母語では文節出来ない概念を知ることだ、という話がある。実際なけなしの頭で英語を勉強している身として、その通りだと思う。その点で、この数年で一番、良いなぁ、便利だなぁと思った形容詞が、agnostic だ。語源はagnosticism、不可知論。宗教的には、明確に神の存在を否定する無神論とは異なり、神は居るとも居ないとも断定できないとする立場のことだが、そこから転じて、大雑把に「分かりかねる」「知り得ない」のような意味になるらしい。ソフトウェア工学の世界では、プロトコルやインターフェースの詳細に関知しない状態で設計された、つまり「非依存の」に近い用法で使われることが多い。例えば、platform agnostic で「特定のプラットフォームに依存しない」という成句になる。似た言葉に cross-platform 「複数のプラットフォームで動作する」があるが、両者の語義的なニュアンスの違いはまだ上手く日本語に置き換えられていないように思える。

アグノスティック (情報工学) – Wikipedia (拙訳ですが…)

同じ汎用化でも、それぞれ特有の仕様に合わせて個別対応した結果、総体としてプラットフォームを跨いでサポートしてますよというのが cross-platform。に対して、「知り得ない」「関知しない」からこそ、個々の細かい仕様に依存しないよう、設計を抽象化して留め置くのが platform agnostic。これはあくまで第二言語学習者として語源から辿った印象なので、実際にはドミニク・チェンさんが教えて下さったイメージが適切そう。どちらの場合も結果的には同じようなコードを書きそうなものだけど、その根本の態度の違いはとても示唆的だ。

デザインツールについて考える時、この agnostic が帯びる意味合いというのはとても有用だ。多くのツールにとっての一つの目標が multi-purpose〈多目的〉にあるとすると、ぼく個人にとって理想的なツールの設計思想は、purpose-agnostic〈使用目的に関知しない〉という言葉がしっくりくる。果たしてそういう言い回しがあるのか、意味として通じるかはわからないけど。もっと良い表現があれば教えて欲しいところですが、さしあたりこの妙な造語で話を進めます。

見渡すところ、デザイナーにやりたい表現をヒアリングし、それに特殊化した機能をアドホックに追加していくアプローチの製品開発が多い。結果として出来上がるのは多機能化の末に膨れ上がったスイスアーミーナイフ、もしくは特殊化の果てに数ヶ月に一度しか使わないような白髪ねぎカッターだ。

それは、業界の標準的なワークフローの中で使う分には過不足無いのかもしれないし、世の中の9割方のデザイナーの需要をカバーするものでもある。一方で少しでも開発者の想定から外れた使い方をしようとした瞬間に、急にハックめいたことを強いられるという弱点にもなり得る。それは「想定の範囲が狭かった」ところに非があるというより、「想定し切る」こと自体に限界があるからだ。

iPhone以前のスマートフォンは、あらゆる用途を想定した上で、最小公倍数的にボタンを追加することで多機能性を達成しようとした。に対してiPhoneは、想定し切ることの限界を認めた上で、物理キーの押しやすさと引き換えに、タッチディスプレイ上でボタンの配置そのものを可変とすることで多機能化を実現した。実際のKeynoteではもっと違う意味で対比はなされていたのでこれは個人的な解釈になってしまうけれど。だた、これはとても purpose-agnostic なアプローチだと感じた。

これは殆どの人が忘れている感覚かもしれないが、そもそiPhoneをゲーム機として使うという発想は決して当たり前ではなかった。しかし、発売後になってマルチタッチデバイスに可能性を感じたハッカー達が、iPhoneをJailbreak(脱獄 = アンロック)し、当時許可されてなかったお手製アプリを無理矢理インストール出来るようにした。その中で、タッチスクリーンの操作感を生かしたゲームアプリも登場したりなんかして、あぁ、そんな使い方があったのか!と界隈がざわついた記憶がある。

その後どういう流れかApp Storeが登場して、ちゃっかり「ゲームも楽しめるiPod」としてtouchのCMが打たれたりなんかしたワケだけども、結局それはマルチタッチディスプレイという purpose-agnostic なインターフェースだからこそ為せた多機能化だったのだと思う。Appleがどこまで想定していたのかは分からないが。むしろ想定し切きれない所に、逆説的に道具としての応用の余地があった。

iPhoneの登場と同じような転回が、GUIベースのデザインツールに起きてほしいと思う。

Adobeの今の開発の方向性に共感出来ないのも、ここ最近のUI/UX系ツールが根本的な解決に感じないのも、その目指す重点が、特定の用途を想定した多機能化と特殊化にあるからだ。年々、旧スマートフォンのように、メニューもボタンも不用意に増えていく。たまに Illustrator の 王rパティパネルのように表面上の見た目はスッキリさせてみるけど、内部的な機能構造はますます複雑化していく。XDやFigma、Framerは、一見モダンな設計に思えて、フラットデザイン以降のペタンとしたグラフィックに特殊化されている分、Illustratorに比べても表現力が乏しい。今更スキューモーフィズムをやろうとする人は居ないにしても、それがデザイナーの意思でもってそうするのと、ツールの機能上無意識に選択肢から除外されるのとは決定的な違いがある。

話は戻って、スイスアーミーナイフのアナロジーになぞらえると、じゃあお前が欲しいのはサバイバルナイフか、とか突っ込まれそうな気がする。だけども、purpose-agnostic であることは、何も「ソリッドでありながら、使い手の技量次第でいかにでも多機能化する」ということに限らない。デジタルツールにおいてそうした設計を達成するヒントは、むしろ数十年前のUNIX思想や、プログラミング言語上の概念に既に隠されている(というか歴史上最も purpose-agnostic なプログラムは、オペレーティング・システムそのものかもしれない)。

例えば「単機能の抽象化されたプログラムをパイプで繋げる」UNIX思想。これは素朴にGUIに置き換えるとノードベースUIになりそうだ。Houdiniや(少ししか触った事が無いけれど)Touch Designerの強みはそこにあると思っていて。あるスタイルの為に具体的に設計された粒の大きい機能を与えられてしまうと、そのスタイル内のバリエーションを表現するに足るだけの限られたパラメータを弄くりまわすくらいしかやることは残されていない。あるいは裏ワザ的に変な組み合わせを試してみたり。だけど、それ単体としては抽象的操作でしかない少数のフィルターを自由な順序で組み合わることが出来たら、その表現の幅はずっと豊かなものになる。モジュラーシンセなんかはそんな感じなのかなぁと思ったり。(違かった)これはソフトウェア設計では Orthogonality〈直行性〉と呼ばれる考え方なのだけど、そうした余地をツールに残すということはとても purpose-agnostic だ。

オブジェクト指向言語におけるカプセル化やインスタンス化は、ここ最近のUI/UXツールにおけるコンポーネント系機能や、AfterEffectsのEssential Graphicsといった形で応用され始めている。これがもう少し進化すると、例えばグラフィックのまとまりをいくつかのハンドル、パラメータによってコントロールしたり複製出来るようになる。その結果、ドローイングアプリの中で、例えばフローチャート、Webワイヤフレーム、あるいは間取りを描くツールと、デザイナー自らがその目的・スタイルに合わせた使い勝手のツールのサブセットを作り上げる事が出来る。開発者自身が関知せずとも、ユーザー自身が必要とする目的に合わせた機能性を生み出すことが可能となる。1 これはプラグインを通して可能なこともあるけれど、秘伝のタレ状態のSDKを解きほぐす必要も無しに、あくまで日常のデザイン行為の延長として可能になるべき。 あと、複製されたオブジェクトを一元的に編集できるだけの単純な「共通化」とカプセル化は違うのに注意。

これをAEでつくるのすごい。間取りコンポーネントがあれば…

というと業務上、効率上のメリットばかりになってしまうけれど、ぼくが言いたいのはもっと表現寄りの話。グラフィック要素を自在にカプセル化して、より高次のパラメーターや配置の工夫に集中できるというのは、グラフィックスタイルそのものの試行錯誤をより自由なものにする。ちょっとイメージし辛いので、具体例をあげてみる。例えばビルトインの丸・矩形・多角形だとかをテクく組み合わせるのを強いられる今の状況ってのは、開発者自身が「多分こんなのを描くにはせいぜいこの位の図形で事足りるっしょ」と想定した範囲の内側でもがいているようなものだと思う。 意識的にもがくうちはまだ良い。問題は、だんだんとその使い勝手を内面化して「カーブがトロコイド曲線になっている角丸四角形を描きたいなぁ」というような発想自体が生まれなくなることだったりする。こういう無意識的なアイディアの狭窄が積み重なることで「○○アプリで描いたっぽい感じ」は生まれる。だから、どんなスタイルのグラフィックが描かれるかに不可知なドローイングアプリを作ろうとすると、必然的にシェイプやコンポーネントをビルトインのそれらと同じレベルでユーザー定義できて、なおかつカプセル化できる設計になっている必要があると思う。

時々不用意にディスってしまって申し訳無さを感じつつも、やっぱりcreative codingが好きなのは、コードやコマンドを通して表現出来る操作が、現状GUIベースのデザイン以上に抽象化されていて豊かだからだ。コード上での「丸を書く」という命令は、単にディスプレイ上に描画する以外にも、3Dプリンタのヘッドを動かすGコードとして解釈することも出来る。さらにopenFrameworksならC++、p5.jsならnpmを介して、その言語によって過去作られた膨大なライブラリと接続できる2npmというパッケージマネージャを挙げるなら、oFはConanになるのか。いやだけどofxAddonsのような気もするし。上手く対応するものが思い浮かばない…。。どれも大まかに「絵を描く」という目的に最適化されつつも、それは特定のメディアやスタイルにまで特殊化されているわけでも、コレとアレと…といくつか選りすぐって個別対応し “multi-purpose” を掲げているわけでもない。製本のためのInDesign、UIデザインのためのXDと違い、それがどういう使われ方をされ得るのか、そもそも何のためのものなのかに関知しないことによって、適度に実装が抽象化されていることが creative coding 系ライブラリのデザインツールとしての最良の点だ。その立ち位置の危うさがクリエイティヴなコーディングってなんなん…ってツッコまれポイントにもなっているような気はするけれど。そうした道具としての purpose-agnostic な設計こそが、これらのライブラリがお絵かきもゲーム制作にも、インスタレーションにも使われるようになっている所以だと思う。

じゃあ大人しくコードだけ書いてろよ、って言われそうだけど、そこには欠点もあって。プログラミングを通した表現は、どうしてもコードとしての見通しの良さが気にかかってしまう。結果として全部をパラメトリックに小綺麗に完結させようして、それはそれで表現が似通ってしまったりする。「良さ」のような漠然とした審美は、パラメトリックに記述しようとすると却って冗長にかつ中途半端になることが多い。だからこそ、限界までパラメトリックに作り込んだその先に、チマチマとしたチューニング行為や行き当たりばったりの破壊的編集を通した手数の積み上げが必要になってくる。これは根性論ではなくて、単にその方があるレベル以上の「良さ」にたどり着くには効率的だからだ。

GUIベースのデザインの利点はなんと言っても、素早くその「チューニング」や「破壊的編集」が出来るところにある。マウスやスタイラスを通したアナログ入力、WYSIWYGな操作感、裏側のレイヤー構造をさして気にせず目の前のアートワークだけに集中してイジイジ出来る環境は、コードに比べてうんとその一踏ん張りがやりやすい。3インタラクションデザイナーが、ツメの段階でdat.guiやimguiのようなライブラリを通してGUIからパラメーターをいじくり回せるようにするのはこのためだと思う。

いろんな所で言っているのが、制作行為ってある種の多峰性最適化だということだ。いうなれば、いくつも峰がある山地を目隠して皆で登るイメージ。登山の目的は「良さ」という標高を突き詰めていくことだ。標高が低すぎると、それは「良くない」ということなのでたまに死ぬ。もちろん万人にとって絶対的な「良さ」の基準なんて無いわけなので、そういうものがあったとしてと仮定の話。むしろその「良さ」の評価関数の多様さこそが、この集団山登りで全滅しないための肝だったりするのだけど。この山登りにおけるツールの役割というのは、山地上を自在にほっつき回るための登山道具のようなものだ。

繰り返し言う通り、現状多くのデザインツールは、素朴な多機能化、特殊化への方向に留まっている。これは、ツール = 登山道具がドコドコの山専用に設計されていることを意味していて、そこで出来るのは、ツール開発者によって想定された山の中での局所最適化だ。デザインとは?論はnoteで死ぬほど見たしあまり突っ込みたくない話題だけども、この「良さ」の集団山登りにおいては、デザイナーの役割はそうした局所最適化、つまり8合目より上の針の先ほどの山頂を目指してその繊細な足裏感覚で探り当てるように登っていく役割を担うことが多い。

一方で、こんな可能性もある。その峰自体が果たして唯一の最高峰なのか。他にも未踏破の山が、既知の山の間、あるいは知らない次元の先に広がっているのではないか。そんな考え方をそっと提示するのが、例えばだが、メディア・アーティストの役割だと思う。山の登山口を見つけられたら万々歳で、こっちの方向に多分こういう山があるのかもしれないと予言めいたことをするだけでも十分。というかデザイナーと違って根本的に「踏破」を求められてない。なぜなら、この多峰性最適化において、彼らの一番の存在意義は、集団全体が局所解に取り残され、緩やかな死を迎えないためのランダムさを体現することにあるから。これはメディア・アートそのものの定義や意義では決して無くて、結果的にこの適応ゲームの中でそういう役回りに回りがちという傾向でしかない。メディア・アートに限らずとも、技術者や折り紙研究者で構わない。特定の峰の局所解を目指してひた走る集団に対する、峰の配置自体を大域的に探し回るランダムウォーク集団。この2つの集団はどうにも相性が悪そうだし、根っからアティテュードが違う分現実世界でもいがみ合いがちだったりするのだけど、実はこの最適化アルゴリズムにおいては相補的な存在だ。ひょっとしたら、佐藤雅彦先生がいう「ジャンプ」というのは、ロジカルに考えると峰の勾配にそって登っていくしかない所を、偶発的に峰から峰へ飛び越えてしまう瞬間のことを言うのかも知れない。そして、そういう跳躍力を「良さ」の追求集団のなかに内包するほど、その集団全体の生命力はしぶといものになる。

ぼくがとても中途半端なのは、デザイナーとしてはあまりに足裏感覚が雑過ぎる上に、メディアアーティストほどラディカルにメディアにおける表現というものを相対化したいワケでもない所にあると思っている。映像というメディアの中で、更にMVやモーショングラフィックスという狭いカテゴリの中でさしあたりは満足している。だけど気移りもしやすいので、その枠の中であってもそれなりにいろんな山には登ってみたい。一方でチマチマとしたチューニング作業も好きだから、なけなしの足裏感覚でもって5合目位までは登っておきたいし、ついでに褒められてみたい。

「良さ」の峰を大域的に走査するための設計の抽象度。そしてこの峰と決めた時、高い精度で山頂を探り当てにいくのに必要不可欠な、道具としての直感性や体への馴染みの良さ。それぞれcreative coding、GUIベースのデザインソフトウェアが得意としてきたことだが、この2つをうまい具合に兼ね備えたツールが無いのが、最近の一番の悩みで、制作が終わらない原因なのかと思う。いや、制作が終わらないのは完全に自分の計画性の無さにあるけれど…道具のせいにした。ごめんなさい。

色々話は戻って、purpose-agnostic なデザインツールを切に願うのは、そういうことなのだと思う。だってそのツールが使われる山が予め想定されている時点で、その山はある程度クリエイターにとって観光地化されていて、製品化する程度に需要があるってことだ。別に今更自分ごときが登っても屁にもならないわけ。だからこそ、あまり需要は無いのかもしれないけれど、それがどういうスタイルやジャンルに使われ得るかに「不可知」な態度のもと作られたツールがもっと世の中に充実していたら素晴らしいよなぁ、と個人的に思った。


追記

ちなみに、JavaScriptの factoryパターンのようなものをデザインツールで作りたかったのが、このデモ。 新千歳国際映画祭のID映像を作る時に開発した。ドローイングツールにおけるコンポーネントやプリミティブをユーザー定義できるのと同じように、それを一連のマウスインタラクションの中でどういう風に生成するかを定義できると最高だよねっていう実験でした。

https://twitter.com/_baku89/status/1022709978182774784?s=20

あと、去年Adobe Creative Residencyに落ちちゃった時に提案していたのが、よりデザイン作業に向いたUIコンポーネントの開発と、それを使ったよりプログラマブルなドローイングアプリだった。インタビューの最中「で、Adobe製品はどういう所に活かせるの? 」と痛い所を突かれ、アイコンとか作れます…とか応えてしまったのも落ちる一因だったと思う。(前からリスペクトしていた方が受かったので本当に良かったです)本当はもっと開発してから一般公開したかったけど、そんな事思っといて半年近く放置してしまっているので、所々動かないけど載っけておきます。積み残した制作終わったら再開します。

http://ui.baku89.com/