奥行きのある構図、っていうのは描くのが難しそう。
三次元を二次元にする、次元変換なり射影操作が入るから。
自分に絵心って奴はないので、その大変さの実感は全然ないのだけれど。
描こうとしているモノを、三次元的に解釈して、さらに二次元へ投影・射影しなければならない。
光に照らされている箇所や、逆に光の届かないところの影のつき方とかも、自然になるようにしなければならない。
それを実際に自分の手に取って観察したり参考にできればいいのだが、そういう訳にもいかない。
そういう、コンピュータなら簡単に計算してシミュレートできることを、人間が自分の頭で計算してシミュレートする。
こうなるはず、という頭の中で計算した結果の画像を、最終的には手でアウトプットする。
それが職人芸だったりテクニックという奴で、センスがある人ならあまり苦労なく出来るのかもしれないが、方法論はあるしスキルでもあるから、誰でも身に着けられはするのだろう(多分)。
こうなるはず、というものを形にする。
それはソフトウェアだったり、それらが集まったり、ハードウェアと合わさったものの集合体であるシステムも同じ。
ここで、完成形が見えている人と、見えていない人とでは、出してくるものは全然違う。
両方とも、アウトプットは仕様どおりではある。
しかし例えばそのソースコードが、読んでいてすんなり意図が分かるものと、なんでそう実装されているのかさっぱり分からないもの、という違いがある。
システム構成のレベルでも、そういう感じのことはある。
TDDは、ソフトウェアの完成形をそのまま形にするための手法、とも言えそうではある。
でも今言わんとしていることは、TDDで実現できることとはちょっと違う。
この世に存在しえないイデアの世界を、不完全なのは承知な上で、どれだけそのままこの世に写し取るか、という話のつもりだから。
TDDで最初にあるのはテストケースだが、そのテストケースがいびつなら、出来上がってくるものもいびつになる。
だから、TDDはリファクタリングがセットになっているわけだが。
テストケースを作るのは、ソフトウェアの完成形をイメージしている、不完全な人間の誰かなのだし。
誰かが作ったものを見たり読んだりしても分からないことはある。
それは、その世界を作った人の世界観が、他者に理解できないということ。
例えば、色々な仮定を置いてあるように見えるが、結局何の意味もなかったりする。
その業界で明確に定められた意味を持つ言葉が、別の意味で使われていたりする。
使い分けが分からない入り口や脇道がたくさんあったり、進み方が一直線になっていなかったりする。
相手と自分の考えを上手くマッピングできず、混乱する。
狂人にもその人なりの論理があるとは言われる。
その人の中では整合性が取れているのだと。
ああ、分かるよ、その理屈は一応ね。
でも、そういうのに付き合うのは、正直きついよねー。
一般的に使われているのとは全然違う公理から導かれた定理を一切の解説なしで理解しろ、という感じで。
なんで自分がそいつに歩み寄ってやらなきゃならんのだ、という感じで。
物語論とか、ヒットするためのストーリーの作り方、みたいなものを読んでいると、すんなり読めるものはいろいろ工夫がされているんだな、と思う。
それらの中で重要そうなのは、世間一般で広く認知されパターン化しているものをベースにしつつ、自分の必要に応じてちょっとだけアレンジせよ…とか、読者として想定する相手が慣れ親しんでいる言葉や概念をガンガン使え…とか、そういう類のこと。
これは結局のところ、相手の常識や知識に乗っかることで状況なり概念の伝達コストを省略しつつ、自分の伝えたいことを相手が低コストで理解できる形で表現せよ、ということなんだろうなと。
また、漫画やゲームのキャラクターの外見が、記号となるいろいろなもので埋め尽くされているのと同じことだ。
また、それらの記号について、時代の流れにより変わっていくもの(=いずれ誰もその意味が分からなくなっていくもの)と、変わっていかないものの違いは、明確にある。
ではこいつを、自分の専門領域であるシステム構築に適用するならどうなるのか。
誰にでも伝わる答えみたいなものはないのだけれど、モヤモヤしたものはある。
が、どうすれば表現できるものやら。
