目的に関知しない
外国語を学ぶ面白さのひとつは、母語では文節出来ない概念を知ることだと聞いたことがある。
必死に英語を勉強している身としては、その通りだと思う。その意味で、この数年でもっとも「日本語に文節できないなぁ〜」と思わされた英単語が、agnosticだ。語源はagnosticism、つまり不可知論。神学的には、明確に神の存在を否定する無神論とは異なり、神は居るとも居ないとも断定できないとする立場のことだけど、そこから転じて、おおざっぱに「分かりかねる」「知り得ない」のような意味になるらしい。
agnosticは、ソフトウェアの世界では、プロトコルやインターフェースの詳細に関知しない状態で設計された、つまり「非依存の」に近い用法で使われることが多い。たとえば、platform agnosticで「特定のプラットフォームに依存しない」という意味。似た言葉にcross-platform＝「複数のプラットフォームで動作する」があるんだけど、両者のニュアンスの違いはまだ日本語に翻訳できていない気がする。
アグノスティック (情報工学) - Wikipedia同じ汎用化でも、それぞれ特有の仕様に合わせて個別対応した結果、総体としてプラットフォームを跨いでサポートしてますよというのが cross-platform。に対して、「知り得ない」「関知しない」からこそ、個々の細かい仕様に依存しないよう、設計を抽象化し、宙吊りにするのがplatform agnostic。これはあくまで第二言語学習者として語源から辿った印象なので、実際にはドミニク・チェンさんが教えて下さったイメージが適切そう。どちらの場合も結果的には同じようなコードを書きそうなものだけど、それぞれの言葉に現れる態度の違いはとても面白い。
デザインツールについて考える時、この agnosticが帯びる意味合いというのはとても有用だと思う。多くのツールにとっての一つの目標が multi-purpose〈多目的〉にあるとすると、ぼく個人にとって理想的なツールの設計思想は、purpose-agnostic＝使用目的に関知しないという言葉がしっくりくる。果たしてそういう言い回しがあるのか、意味として通じるかはわからないけど。もっと良い表現があれば教えて欲しいところですが、さしあたりこの妙な造語で話を進めます。
見渡すところ、デザイナーにやりたい表現をヒアリングし、それに特殊化した機能をad-hoc＝場当たり的に追加していくアプローチの製品開発が多い1。結果として出来上がるのは多機能化の末に膨れ上がった百徳ナイフ、もしくは特殊化の果てに数ヶ月に一度しか使わないような白髪ねぎカッターだ。
ある特定の業務を狙い撃ちした白髪ねぎカッター的なデザインツールは、その業務で使う分には圧倒的な省力化につながる。世の中の9割方のデザイナーの需要をカバーするものでもある。でもその特殊性は、少しでも開発者の想定から外れた使い方をしようとした瞬間、急にハックめいたことを強いられるという弱点に変わる。それは「想定の範囲が狭かった」ところに非があるというより、すべてのユースケースを「想定し切る」こと自体に限界があるからだ。
iPhone以前のPDAやスマートフォンは、あらゆる用途を想定した上で、最小公倍数的にボタンを一揃いさせることで、多機能性を達成しようとした。に対してiPhoneは、想定し切ることの限界を早々と認めた。で、物理キーの押しやすさと引き換えに、タッチディスプレイによってボタンの配置そのものを可変とすることで多機能化を実現した。これは、自分にはとてもpurpose agnosticな態度に思えた。
これはほとんどの人が忘れている感覚かもしれないけど、そもそも iPhone をゲーム機として使うという発想だって決して当たり前じゃなかった。ジョブズがキーノートで売り文句にしたのも「電話とiPodとWebブラウザがひとつのデバイスに」だったし。けど、発売後になってマルチタッチデバイスに可能性を感じたハッカー達が、iPhoneをJailbreak（脱獄 = アンロック）し、当時許可されてなかったお手製アプリを無理矢理インストール出来るようにした。その中で、タッチスクリーンの操作感を生かしたゲームアプリも登場したりなんかして、あぁ、そんな使い方があったのか！と界隈がざわついた記憶がある。
その後どういう流れかApp Storeが登場して、ちゃっかりiPod touchが「ゲームも楽しめるiPod」として宣伝されちゃったりしたワケだけども、それはマルチタッチディスプレイというpurpose agnosticなインターフェースだからこそ為せた多機能化だった。Appleがどこまで想定していたのかは分からないけど。いや、その想定し切きれなさこそが、ハッカーやサードパーティー開発者を奮い立たせて、逆説的に道具としての応用の余地に繋がったんじゃないかと思う。
iPhoneの登場と同じような転回が、GUIベースのデザインツールに起きてほしいと思う。
Adobe の今の開発の方向性に共感出来ないのも、ここ最近の UI/UX 系ツールが根本的な解決に感じないのも、その目指す重点が、特定の用途を想定した多機能化と特殊化にあるからだ。年々、旧スマートフォンのように、メニューもボタンも不用意に増えていく。たまに Illustratorのプロパティパネルのように、段階的開示によって表面上の見た目はスッキリさせてみるけど、内部的な機能構造はますます複雑化していく。XD や Figma、Framer は、一見モダンな設計に思えて、フラットデザイン以降のペタンとしたグラフィックに特殊化されている分、Illustrator に比べても表現力が乏しい。今更スキューモーフィズムをやろうとする人はいないにせよ、それがデザイナーの意思であるのと、ツールの機能上無意識に選択肢から除外されるのとでは決定的な違いがある。
話は戻って、百徳ナイフの喩えになぞらえると、じゃあお前が欲しいのはサバイバルナイフか、とか突っ込まれそうな気がする。だけども、purpose-agnostic であることは、何も「多機能さと引き換えに、使い手の高い習熟を要求する」とは限らない。デジタルツールにおいてそうした設計を達成するヒントは、むしろ数十年前のUNIX哲学や、プログラミング言語上の概念に既に隠されている——というか歴史上最もpurpose agnosticなプログラムは、オペレーティング・システムそのものかもしれない。
例えば「ひとつのことをうまくやる」小さなプログラムを組み合わせよ、という原則。これは素朴にGUIに置き換えるならばノードベースUIに相当する。Houdini やTouch Designerのあの高い柔軟性の鍵はそこにある。あるスタイルに具体的に設計された粒のデカい機能を与えられてしまうと、そのスタイル内のバリエーションを表現するに足るだけの限られたパラメータを弄くりまわすくらいしかやることは残されていない。あるいは裏ワザ的に変な組み合わせを試してみたり。だけど、それ単体としては単純な操作でしかない少数のフィルターを、自由な順序で組み合わることが出来たらなら、その表現の幅はずっと豊かなものになる。モジュラーシンセなんかはそんな感じなのかなぁと思ったり2。これはソフトウェア設計では Orthogonality＝直行性と呼ばれる考え方なのだけど、そうした余地をツールに残すということはとてもpurpose agnosticな態度だ。
オブジェクト指向言語における「カプセル化」の概念は、ここ最近の UI/UX ツールにおけるコンポーネント系機能や、AfterEffects の Essential Graphicsといった形で応用され始めている。これがもう少し進化すると、例えばグラフィックのまとまりをいくつかのハンドル、パラメータによってコントロールしたり複製出来るようになる。その結果、ドローイングアプリの中で、例えばフローチャート、Web ワイヤフレーム、あるいは間取りを描くツールと、デザイナー自らがその目的・スタイルに合わせた「白髪ねぎカッター」的な器具を自作することができる。もちろん、プラグインを作ればいいじゃんって話なんだけど、それだとユーザーに「開発者」としてのスキルを求めることになる。ツールをつかうことと、そのプラグインを開発することは地続きに溶け合っていてほしい。
こんな例をあげていると、一見業務効率の話に思えるかもしれない。けど、ぼくが言いたいのはもっと表現寄りの話でもある。つまり、グラフィック要素を自在にカプセル化して、より高次のパラメーターの調整や、レイアウトに集中できる環境は、グラフィックの様式そのものの試行錯誤をより自由なものにする。ちょっとイメージしづらいので、具体例をあげてみる。例えばビルトインの丸・矩形・多角形だとかをテクく組み合わせるのを強いられる今の状況は、開発者自身が「多分こんなのを描くにはせいぜいこの位の図形で事足りるっしょ」と想定した範囲の内側でもがいているようなものだ。 意識的にもがくうちはまだ良い。問題は、だんだんとその使い勝手を内面化して「角が緩和曲線を描いている角丸四角形を描きたいなぁ」というような発想自体が生まれなくなることだったりする。「○○ アプリで描いたっぽい感じ」というのは、そういうツールによる誘導の産物だ。だから、どんなスタイルのグラフィックが描かれるかに関知しないドローイングアプリを作ろうとすると、必然的にシェイプやコンポーネントをビルトインのそれらと同じレベルでユーザー定義可能である必要がある。
クリエイティブ・コーディングがやっぱり好きなのは、コードやコマンドを通して表現出来る操作が、GUIベースのデザイン以上に抽象化されていて豊かだからだ。コード上での「丸を書く」という命令は、単にディスプレイ上に描画する以外にも、モーションパスとしても、あるいは3Dプリンタのヘッドを動かす G コードとしても解釈できる。さらに openFrameworksならC++やofxAddons、p5.js ならnpmを介して、その言語によって過去作られた膨大なライブラリ資産と組み合わせることも可能だ。
クリエイティブ・コーディングのための環境は、そのどれもが「絵を描く」という目的にゆるやかに最適化されてはいる。でもそれは特定のスタイルに特殊化されているわけでも、いくつか用途を絞って個別対応することでmulti-purpose＝多目的を掲げているわけでもない。組版のためのInDesign、UIデザインのためのXDと違って、それがどういう使われ方をされ得るのか、そもそも何のためのツールなのかに関知し過ぎないことこそが最大の特徴ともいえる。そうしたpurpose agnosticな設計ゆえに、openFrameworksをつかってインフォグラフィックスをつくる人も、VJ、ゲーム、あるいはサイネージシステムをつくる人もいる。いろんな人の要求に応えることができる。
じゃあ大人しくコードだけ書いていいのでは、ってツッコまれそうだけど、そこには欠点もある。プログラミングによるビジュアル表現は、絵としての良さよりもコードとしての見通しの良さがどうしても気にかかる。結果として全部をわかりやすいルールで統制しようとして、それはそれで表現が似通ってしまったりする。「美しさ」のような漠然とした審美は、パラメトリックに記述しようとすると却って冗長にかつ中途半端になることが多い。だからこそ、限界までパラメトリックに作り込んだその先に、チマチマとした個別操作や、行き当たりばったりな破壊的編集を通した手数の積み上げが必要になってくる。これは根性論ではなくて、単にその方がある精度以上の「美しさ」を近似するには、単に効率的だからだ。
GUI ベースのデザインの利点はなんと言っても、その個別操作や破壊的編集がすばやく身体的にできるところにある。マウスやスタイラスを通したアナログ入力、WYSIWYGな操作感、裏側のレイヤー構造をさして気にせず目の前のアートワークだけに集中してイジくりまわせる環境は、コードに比べてうんとその「チマチマ」がやりやすい。インタラクションデザイナーが、ツメの段階で dat.gui や imguiなどでパラメーターを外部化しながらいじくり回す傾向にあるのは、このためだと思う。
いろんな所で言っているのが、制作行為はある種の多峰性最適化だということだ。いうなれば、いくつも峰がある山地を目隠して皆で登るイメージ。登山の目的は「良さ」という標高を突き詰めていくこと。標高が低すぎると、それは「良くない」ということなのでたまに死ぬ。この山登りモデルにおけるツールの役割というのは、山地を自在に歩き回るための登山道具のようなものだ。
繰り返しいった通り、現状多くのデザインツールは、素朴な多機能化、特殊化への方向に留まっている。これは、登山道具がドコドコの山専用に設計されているようなもので、そこで可能なのは、道具の作り手によって想定された山の中での局所最適化だ。「良さ」の集団山登りにおいては、デザイナーという小集団の役割はそうした局所最適化、つまり8合目より上の針の先ほどの山頂を目指してその繊細な足裏感覚で探り当てるように登っていく役割を担うことが多い。
一方で、こんな可能性だってある。その峰自体が果たして唯一の最高峰なのか。他にも未踏破の山が、既知の山の間、あるいは知らない次元の先に広がっているのではないか。そんな考え方をそっと提示するのが、メディア・アートやスペキュラティブ・デザインの役割の一つだと思う。山の登山口を見つけられたら万々歳で、こっちの方向に多分こういう山があるのかもしれないと予言めいたことをするだけでも十分。というか彼らはデザイナーと違い、根本的に「踏破」を求められてない。なぜなら、メディア・アートやスペキュラティブ・デザイン的な行動原理をもった小集団がいることは、集団全体が局所解に取り残され、緩やかな死を迎えないためのランダムさを体現することにあるからだ。
これはメディア・アートやスペキュラティブ・デザインそのものの定義を言い当ててるわけじゃない。この最適化ゲームにおいては、結果的にそういう役回りに回りがちだ、という傾向の話。そういう小集団は、べつに技術者や折り紙研究者だって構わない。特定の峰の局所解めがけてひた走る集団に対する、峰の配置自体を大域的に探し回るランダムウォーク集団。この2つの派閥はどうにも相性が悪そうだし、根っから制作観が違う分、現実世界でもいがみ合いがちだったりするのだけど、実はこの最適化アルゴリズムにおいては相補的な存在だ。
ぼくがとても中途半端なのは、デザイナーとしてはあまりに足裏感覚が雑過ぎる上に、メディア・アーティストほどラディカルに表現を相対化したいワケでもない所にあると思っている。映像というメディアの中で、更にMVやモーショングラフィックスという狭いカテゴリの中でさしあたりは満足している。だけど気移りもしやすいので、その枠の中であってもそれなりにいろんな山には登ってみたい。でもチマチマとしたチューニング作業も好きだから、なけなしの足裏感覚でもって5合目位までは登っておきたい。
「良さ」の峰を大域的に走査するための設計の抽象度。そしてこの峰と決めた時、高い精度で山頂を探り当てにいくのに必要不可欠な、道具としての直感性や体への馴染みのよさ。それぞれクリエイティブ・コーディングとGUIベースのデザインソフトウェアとが得意としてきたことだけど、この2つをうまい具合に兼ね備えたツールが無いのが、最近の一番の悩みだ。
Purpose agnosticなデザインツールを切に願うのは、そういうことなのだと思う。だって、そのツールが使われる山が予め想定されている時点で、その山はある程度クリエイターにとって観光地化されていて、製品化する程度に需要があるってことに他ならないから。いまさら自分ごときが登っても屁にもならないわけ。だからこそ、市場規模があるかどうか、ユーザーがそれを求めているかどうか、あるいはその道具がスタイルやジャンルに使われ得るかに「不可知」な態度のもと作られたツールが世の中にもっと充実していたら、素晴らしいなぁと思う。
追記
ちなみに、JavaScript の factory パターンのようなものをデザインツールで作りたかったのが、このデモ。 新千歳国際映画祭の ID 映像を作る時に開発した。ドローイングツールにおけるコンポーネントやプリミティブをユーザー定義できるのと同じように、それを一連のマウスインタラクションの中でどういう風に生成するかを定義できると最高だよねっていう実験でした。
あと、去年 Adobe Creative Residency に落ちちゃった時に提案していたのが、よりデザイン作業に向いた UI コンポーネントの開発と、それを使ったよりプログラマブルなドローイングアプリだった。インタビューの最中「で、Adobe 製品はどういう所に活かせるの? 」と痛い所を突かれ、アイコンとか作れます……とか応えてしまったのも落ちる一因だったと思う。（前からリスペクトしていた方が受かったので本当に良かったです）本当はもっと開発してから一般公開したかったけど、そんな事思っといて半年近く放置してしまっているので、所々動かないけど載っけておきます。積み残した制作終わったら再開します。
追記 Sep 14, 2026
この辺の考えは、論文や寄稿記事でようやくまとまった