tenjuu99(天重誠二)

蠱毒としての大学院... https://note.com/ryunosukesophist/n/nf1ecbe21846a

出荷制限や40%値上げのお知らせFAXが続々届いてる

LLMの登場以前からそうなのでは...？ https://linear.app/now/design-is-more-than-code

自分は結局コーディングエージェントをかなり探索的に使っていて、探索において問題の塗り替えや深化がおこなわれる。デザイン過程そのものがドリルダウン式になっているとおもうけど、これはLLMになってからも自分にとっては変わらなかった。それで、そうやっていないところは、まえからそうやっていない。

@shinpei0213 お疲れさまでした！

React がある対象に適合するかどうかという判断からは React のような体系的な観念が生まれなかったのは確かだとおもいますね。どんなところでも最適なシステムを目指しているわけではなく、ソフトウェアとはある思想をもった塊を切り出そうとするものであると言ったほうがいい。

UI = f(state) って React の有名な公式があるけど、あれに自分は意味を見出せないけど、それでも React 的世界観全体を駆動する表明にはあきらかになっている。純粋関数と状態の組み合わせがUIである、というような方向性に、React を書くプログラマーは駆動される。これは、その世界内での「良さ」の定義でもあるし、コードレビューで指摘されることもある(wayみたいなものとして)。

詩を書くようにソフトウェアデザインすればいいんじゃないでしょうか。詩に外部基準があるわけではないし、ソフトウェアも自律的な表現であることが目指されてもよい。

「絵画は鏡である」も「絵画は窓である」もどちらもメタファーだけど、これは「何かヴィジョンを映しだす平面」という類似性によって成り立っている。一方の鏡は、このヴィジョンはそれを見る私と関係づけられるもので、他方の窓はそれを通じて透かし見られる世界と関係する。[鏡, 私] と [絵画, 私]の関係が類比的であるときにメタファーとして成立するし、[窓, 外界] と [絵画, 外界] が類比的であればメタファーとして成立する。

ある詩を考えてみて、「絵画は鏡である」として、その絵画に映しだされるヴィジョンが私の何かを示唆するものであると読めるが、その同じ詩のなかでいきなり「その絵から透かし見られる風景は」みたいな話がでてくると混乱することになる(「あれ、こっちが映ってるんじゃないの？？」みたいな)。シュルレアリズム的な世界観を考えたらまあそれはいいのだけど、デザインにもってくるようなものではあまりない。メタファーが成立するには一貫性が必要だと言いたいだけなんだけど、それは世界観がちゃんと保持される必要があるということでもある。

ここで人間がメタファーを成立させるために働かせているのは詩的直観みたいなものだと思っていて、デザインの目的は美であると言ってしまうのは、たぶんこういうところにもある。詩のなかでメタファーが破綻していたらつまらないと感じるように、そもそも一貫性はメタファーが成立するための条件としてある。

メタファーは任意に選択できるようななにかではなくて、世界Aが[a, b, c]みたいな関係であるとき、世界Bで[a', b',c']となっている場合にメタファーとして成立していて、「一貫している」と感じる、みたいなことだと思う。というか一貫性はメタファーとして成立するための条件というか。「ボタンを押す」ってボタンが単独でメタファーとして成立するんじゃなくて、[突起物, 押す] みたいな関係があり、これと類似した関係が構築される必要がある。[平板な色面, 押す]は、「押す」が類似するが、突起物ではないためメタファーにならない=一貫性がない。あるところでは突起物様のものが表現されているが押せず、あるところでは平面が押せるという状態には一貫性がない。

一貫したメタファーに貫かれていることが良いデザインの指針だとして、一貫していればなんでもいいわけでは当然なくて、ではどのようなメタファーが適しているのかをソフトウェアごとに考える必要があると思う
https://hollo.tenjuu.net/@tenjuu99/019d161a-ba5f-7e5d-998a-915280fb0f86 [参照]

@pokarim 誤解を避けるために留保を置いておきたいのですが、狭く概念とコード命名の一致を求める、というわけではないです。

以下、長くなったのですが、わかりにくいかもしれません。

まず、「恣意的関係」について言えば、たぶん二つのものがあって、それらが自由な関係にある場合に恣意的であるとおもいます。たとえば信号機に赤と青の色がそれぞれ停止と進行を意味しますが、赤=進行/青=停止と最初に定義されていれば関係は逆で、ここに必然性がない=恣意的である。 ただし、これがたとえば大阪では青=停止で赤=進行だが東京では逆だ、となるとかなり困難がある。それゆえ、まずこの恣意性はコントロールされる必要がある。

このコントロールの手段として有用であると考えられるのが、「二つのものごとの関係を類比として扱う」ということだとおもいます。これはメタファーだとおもいます。メタファーは、あるものごとの関係を別のものごとの関係と比較して、構造的な類似性を見出す行為だとおもいます。

コンピュータ上のUIの「ボタンを押す」ってメタファーですが、ボタンでもなんでもないし押しているかどうかもわからないわけですが、突起物とそれを押す(?)という関係に還元してしまえば、構造的な類似を見いだせる。コンピュータ上のあるUIを「ボタン」と呼ぶのは恣意的ですが、それが突起物と押下という行為の関係として見たときに「ボタン」という類比が成立する。フラットデザインがそうしたように、ボタンはボタンでなくてもよかった(恣意的である)のですが、実際には、デザインが機能するためには、恣意性が消滅しているかのように見えていないといけないんじゃないかと思います。

こういう関係を考えると、「ユーザー側の言語」と「プログラミング上のコード」は、単純な一対一対応なわけではなくて、むしろ重要なのは関係が類似することだと思います。コード中にメタファーが埋め込まれることは、プログラマーが類比関係を把握することに役立つ。ユーザーの言語とコードはまったく恣意的な関係にあるわけですが、この恣意性を克服することがデザインの課題であり、それに有用なのはメタファーである。詳しく述べるとこういう感じかと思います。

@pokarim 「ユーザーにとって何かがオブジェクト的である」というのがちょっとよくわからないです。「オブジェクト的」とOOPが同一の地平にないような気がします。自分が言いたいことは、どちらかといえばDDDの設計指針に近くて、ユビキタス言語(会話や実際の作業行為の領域で使われる言語)と、コードに表現される概念が一致する場合、「メタファーが一貫している」と思います。この場合、ユーザー領域にある言語とコード上にあらわれる言語(典型的にはクラスの命名とかですかね、クラスじゃなくても良いです)は、必然的関係は一切なくて恣意的な関係なんですが(つまりユーザーが想起する概念とコード上の命名が一致しなくてもユーザーは概念を想起できる)、この恣意的関係のコントロールを「メタファーの一貫性」と言っています。

自分が一貫性の重要性を述べるのは、デザインの目的とは美だからだといいかえてもいいです。用具を作ることはデザインの目的ではない。

なんか話が食い違っているけど、どこで食い違っているのかはよくわからない。 建材とコードを類比的に述べていなくて、アーキテクトと施工の分離というのが類比としてあり、これは疑うべくもないことだとおもう。表層と施工の分離というのはある意味一般的なパターンそのもので、作業の構造の分解から来ている。アーキテクト(建築家)という存在が独立してあるのは、他方にゼネコンみたいなものがあったりする。この作業行程の分離パターンはソフトウェア開発でもあきらかに踏襲されていて、アーキテクトは利用者のことを考えるUXデザイナーみたいなものだと考えればよく、ゼネコンはプログラマーにあたる。それを突き崩すのにDIYという作業パターンがある。

デザインはコードと外形のうち外形のほうにある、ということではなく、コードと外形を貫くなにかとしてデザイン行為を考える必要がある、とおもっている。コードと外形の分離が、実装とデザインの分離そのもので、デザインという領域を外形性のなかに閉じこめているけど、その言論が建築にもあるし、ソフトウェアではとくに強い。

OO的なUIにたいしてOOPで書くのが良いデザインだとは言ってないとおもいます 一貫したメタファーがあるべきだと言っていて、「OOっぽいUI」と「OOP」の関係はたんなる実装の話な気がする。

アレグザンダーが「ランゲージ」という言葉を使うのは、建築物の作成者が理解可能である基準を設けるためであるし、それは建築物の使用者と同じ理解可能性が求められる。というか、理想的にはDIYであって、作られるものの細部にいたるまですべてが、使用者=設計者に対して理解可能になっているのが、おそらく一つの理想になっている。

アレグザンダーは、アーキテクトと施工の分離をアンチパターンだと考えていた。一貫したデザインランゲージをいくつかの層に設けて、それらのランゲージによって、外形的表現と内部的表現が均衡を保つことが重要だとおもっていた。それは日本の施工習慣とはおおきくぶつかってしまったけど。

すくなくとも、この言論は一般的なソフトウェアデザインの方法論で聞いたことはないです(もちろんマルチパラダイムデザインもこのようなことは言っていません)。自分がこの議論で参照しているのはアレグザンダーです。

んー...。例えばいま念頭に置いているのはUMLのようなものではないし、OpenAPIもおなじ誤ちをおかしているとおもう。コードからデザインが一貫してみちびきだされるというようなことではなく、重要なのはパターンとデザインであり、それは星座をみつけだす行為である。

実装と外形的な表現に必然的な関係がアプリオリにある、といいたいわけではなく、そこに関係を作るのがパターンであり、デザインであると。これはある種の過剰な思想であることは認めるけど、外形的表現と内部表現が互いに自由であるというのは原則的にそうできるというだけのことで、それが良いデザイン指針であるとは思わないということです。

「実装は制約として機能してしまう」は、自分がそう主張したいわけではなく、「実装とデザインが切り離されると」という主張を敷衍するとそうなるということですね。ひとつには、このパターンは典型的には実装者とデザイナーの担当者の分離として現れる。この場合実装者にしか無い知識というのはデザイナーにとってはデザイン上の制約として現れる。

「そこに必然性がない」ところに関係性を構築する行為がデザインだと、ほぼそういう主張です。むしろそれこそがメタファーの機能。

もちろん実装者の都合とし一貫したメタファーに貫かれていることやパターンが入れ子状に現れるものは、実装とコードの関係性がわかりやすくイメージしやすいという意味で良い性質ではあり得ると思う
だけどそこに必然性はない

どこからどこまでが迷信とされているのかがわからなかった

パターンは星座みたいなもので、偶有的に見える関係のなかに形態を見出すことだと言ってもいいとおもう。

もうちょっと言うと、一貫したメタファーに貫かれていることは良いデザインの指針であるとアラン・ケイは考えてメッセージング/オブジェクトというパターンを考えたし、パターンが入れ子状に現れるものが良いデザインだとアレグザンダーは考えた。 ソフトウェアデザインの場合は、実装とデザインは切り離される(べきとする)言説が多くて、こういう分離のパターンはアレグザンダーなら避けたものだと思う。この場合、外形的なものの設計に対して、実装は制約として機能してしまう。 外形的な構造と内部の構造でパターンが入れ子状になっている場合、そのシステムを把握することは容易になるのはたしかだとおもう。

この思い込みのことがパターンですよね

内部のコードと外部の振る舞いを結びつけているのは実装者であるプログラマの先入観にすぎない