hirax.net::Keywords::「道具」のブログ

■「ムーディー勝山のプライベートマイク」と「いつでもどこでも」　

　アメトークの「子供売れっ子芸人v.s.人気なし芸人」で、子供売れっ子芸人たちが（いつでもどこでも子供たちにギャグを要求された時のために）ギャグ道具を持ち歩いている、なんていうネタを話していた。藤崎マーケットはランニング・シャツをいつでも着ていて、小島よしおはいつでも海パンを履いていて、ムーディー勝山はマイ・マイクを持ち歩いていて、にしおかすみこはマイ・ムチを持ち歩いている、なんていうネタだった。

　「いつでもどこでもできる」というのは便利でもあるし、不便でもありそうだ。いつでもどこでも、本番状態だと、張り合いもあるだろうけれど、疲れてしまうこともあるだろう。そんなものを、そんなもののスイッチを楽しむことができるのが、コツなのだろうか。

■「自分で作った道具」で「自分が作るもの」と「クラス分け」　

　よく、「使う道具次第で、作る内容は違ってくる」と言われる。インターネット上の道具で言えば、ネット関連の日記ツールの「指向性」次第で、そのツールを使って書かれる内容は異なってくる、と言われる。もしも、繋がりを作るのが容易なツールであれば、繋がりを意識した内容になるだろうし、「意識して作業しなければ繋がりが作られないツール」を使うのであれば、あまり繋がりを意識した内容にはならない。コメントを重視した道具であればコメント主体になるし、コンテンツ志向の道具であれば、当然コンテンツが充実してくる。それは、自然なことだと思う。

　なぜそれが自然かと言うと、多くの場合、道具が指向する方向を、それを使う人は意識するからだろう。その道具が得意な方向に、つまり道具が導く流れの(一言で言ってしまえば楽に作業できる)方向に、人の努力は向かう。だから、「使う道具次第で、作る内容は違ってくる」のだと思っている。

　少し前に、サーバアプリを(静的HTML+hns(hyper nikki system)から自作ツールに変えた時、つまりWEBサーバ側のコンテンツ作成ツールを開発しようとした際には、WEBサーバに「どんな内容のことを書き連ね・どんなものを溜めている(溜めたい)のだろうか」ということを考えた。「使う道具次第で、作る内容は違ってくる」のが真実だとしたら、どんな「道具を作るべきなのか＝どんなことを(その道具を使って)作りたいのか」を考え直す作業をした。

　「自分が何かを書くために、そのためのツールを作る」というのはとても新鮮な作業だった。なぜなら、結局のところ、それは「自分が何をしたいのか」ということを考える作業でもあったからだ。

　サーバアプリはRailsを使って適当に作った。その構造を大雑把に言えば、画像アップロード・他サイトリンク(リンク先サムネイル作成/全文キャッシュ)などの機能を備えたContentクラスを作り、Contentクラスを継承して、Articleクラス(できるかな?)とMemoクラス(inside out)とBookmarkクラス(現状Tech-logs)があり、それら全てのContentを継承したクラス間をKeywordクラスが(Keywordクラス自身も含め)繋いでいる、という具合である。そういったクラス継承に頼った道具の造り・構造は、Ruby on Railsという道具をさらに使ったためである。（また、デザイン/CSSはtDiary系互換にし、自分でそういった作業をすることは止めた。）

　Article(できるかな?)とMemo(inside out)とBookmark(現状Tech-logs) という各クラス分けされた道具に影響され、それまでとは書く位置づけ・方向性はやはり異なってきたように思う。inside outからは、コメント程度のBookmark的要素(現状Tech-logs)が消え、その分、Articleクラス(できるかな?)に近づき、Articleクラスからは、Memoクラス(inside out)的に書いた小品は消える、という具合だ。

　とりあえず、自分のために作ったツールだから、自分が使うためには一番いい。けれど、クラス分けし過ぎたような気にもなる。本来、曖昧な境界線しかないものを、別なものとしてクラス分けしたことの弊害が、きっとどこかに出てくるに違いない。キーワードでその分離を補うことを狙ったのだけれど、キーワード連携ではどうやら力不足のようだ。

■「夜のコンビニ・デッサン」と「色々な世界を描くための秘密道具」　

　石膏のベートーヴェンや、皿の上の果物や、あるいは身近なモノをデッサンをしたことがある（あるいは、課題として与えられたことがある）人は多いと思う。芯が柔らかな4Bくらいの鉛筆や、パレットに載せた数色の絵具で、目の前に見えるものを描こうとした経験を持つ人は多いと思う。石膏のベートーヴェンを描くならともかく、色のついたモノを描かねばならない時には、いきなり悩んだりはしなかっただろうか。目の前に見えているモノを、手にした道具でどのように表現するか悩んだりはしなかっただろうか。

　ケント紙のスケッチブックと4Bの鉛筆を手に持って、「目の前の赤いリンゴと、黄色いバナナはどちらが白いのだろう？どちらが黒いのだろう？」と悩んだりした経験はないだろうか？ 色々な色をどんな風に限られたもので置き換えれば良いのか、全然わからないままに、適当に鉛筆を走らせた人もいるのではないだろうか？ 夜のコンビニを、ケント紙に鉛筆で描いた「コンビニ＃３」を眺めたとき、ふとそんな経験を思い出した。

　描かれているのは、人通りの少なそうな道沿いに立つコンビニエンスストアで、青や赤といった色を白と黒の世界に置き換え描かれた世界は静謐で、まるで異次元の世界のようで、それでいて、とても「私たちの現実の世界」を忠実に描写しているように見える。

　いつだったか、絵画の解説書を眺めていた時に、面白い描写と記述を見た。「面白い描写」というのは、絵の中に不思議な機械が描かれていたことで、「面白い記述」というのは、その道具が「目の前の景色をどのような色や明暗で表現すれば良いかを判断するために作られた光学機器である」という説明だった。その「連続色→離散色・明暗変換」の道具は、時代を考えればおそらく単純な色分解フィルタなのだろう。…ただ、残念なことに、その不思議道具(色分解フィルタ・ツール)が描かれていた絵が誰のどの絵だったかを忘れてしまった。時代背景を考えれば、17世紀後半から19世紀中盤くらいの絵だろうと思うのだけれど、誰のどの絵だったのかを全く思い出せないことが残念至極である。

　人間の比視感度を考えると、（赤：緑：青=3:6:1くらいで）緑色の感度が高い人が多い。だから、少し赤味がかった緑色をしたサングラスでもかけながら景色を見れば、色の着いたリンゴやバナナや下履を簡単に黒鉛筆で「濃淡画像」として描くことができるのだろうか。

　夜道、ふと横を見ると、「夜のコンビニを、ケント紙に鉛筆で描いた"コンビニ＃３"」に瓜二つな景色が見えたので、ケータイでその景色を写してみた。そこには人も車も写っていて、そのまま私たちの現実の世界だ。けれど、それだけだ。"コンビニ＃３"にある妙な存在感(あるいは不存在感)がそこにはない。それが、良いことか・悪いことかはわからないけれども。

■光スペクトル操作用のMathematicaライブラリ　

以前、Mathematicaの演習用に作った「スペクトル操作用Mathematicaライブラリ」を少し直したので、ここ（”ColorLib_amature.nb”に置いておきます。以前作ったものと同じく、スペクトル・データをリストのような離散データではなくて、関数として（純関数＝無名関数として、あるいは、明示的な関数として）取り扱うという点が特徴だと思います。「（せっかくMathematicaで解くのですから）解析的に解く」「使用者には離散化・数値計算など、面倒くさい汚い部分は見せない・見たくない」という方針で作ったものです。

以前のものからの変更点としては、"spectorPlot"や"labPlot""labColorPlot"など、関数名のMathematicaの命名規則に合わせた変更、加法混色・減法混色用関数の追加・グラフ表示関数の追加・バグ修正といったところです。

　最初のラフスケッチが、絵画の原理を自分なりにおさらいするためのものだったので、濃度変調・面積変調などを扱おうとする場合には、比較的簡単に・気持ち良く作業ができると思います。たとえば、下記のようなコードを書けば、D65光源のもとで、赤紫色の絵具を重ね塗りしていったときの色の具合を CIE Lab 空間で眺めたりすることができます。

labPlot[
　Map[lab,
　　Table[transmissionSpector[D65,
magentaFilter, d],{d,0,10.0,0.1}]
]
];

　また、白色光照射時に黄色い絵具を塗り拡げる面積を増やしていった場合の反射光スペクトル変化をアニメーションとして作成・グラフ表示するコードはこんな感じです。"addtiveMixtureSpector"は加法混色用の関数で、"transmissionSpector"は減法混色用の関数です。お遊びソフトですが、色々遊ぶこともできるかもしれません。

Map[spectorPlot,
Table[
addtiveMixtureSpector[
{whiteLight,
transmissionSpector[whiteLight, yellowFilter, 1]},
{1-r, r} ],{r,0,1,0.1}]];

　コードを書く際に、Mahematicaで数式と文字列をシームレスに取り扱うことができたなら、もっと簡単に関数が書けるのにとも感じました。しかし、そういった感覚になるときは、たいていの場合「その道具の使い方・その道具を扱うプログラミングスタイルが間違っている」ことが多いものです。というわけで、Mathematicaプログラミングをまた勉強しなおしてみよう、と思ったのです。

■「メディアの特性」と「制御工学の安定性」　

　渋谷で飲んだ帰り、道玄坂の坂を駅に向かって下っていくと、隣を歩く人が「あんな風に名づけ、メディアが取り上げるから、そんなものが増えてしまうんですよね」と言った。メディアに関わるその人が、そんなことを言った。その人の視線の先を眺めると、渋谷駅前のビルの上に「モンスターペアレント」という広告が大きく光っていた。

　光る広告を見た後に、「1,2ヵ月前のログに、検索語として、漂白剤や洗浄剤の商品名が多かったこと」をなぜか連想した。その検索語を示す何桁にもおよぶ検索ログを見て、「メディアが名づけ・報道すること」や「検索サービスがユーザに与えるもの」について、考えさせられたことを思い出した。

　その言葉を聞き道玄坂を下りつつ、「制御工学のフィードバック」を考えた。「出力（結果）を入力（原因）側に戻す」ことを意味するフィードバックにおいて、「出力の増加が入力の増加をさらに生む」ような「戻し方」を正のフィードバックという。

　正のフィードバックが働いている場合、（特に系のループ利得が1を越える場合）何らかの破綻が起こるまで出力が増大しつづける。また、この領域では初期値の違いが時間の経過にしたがって無限に引き伸ばされるため、僅かな初期値の違いがシステムの挙動を大きく変える（カオスな振る舞いとなる）場合がある。これは複雑性や多様性を生み出す原動力となりうる。

　そして、その逆に「出力の増加分を入力を減らす」ように働く、出力（結果）の入力（原因）側への戻し方を「負のフィードバック」と呼ぶ。

　負のフィードバックが働く場合は、フィードバック系の増幅率は裸の増幅率より小さな値となる。この増幅率の余裕分の範囲で、出力の増加は増幅率を引き下げるように働き、出力の低下は増幅率を引き上げるように働くので、出力の変動を抑えることができる。（不安定性を消し、安定にすることができる）

　電子機器・メカ機器で多く使われるフィードバックシステムは、「負のフィードバック」だ。なぜなら、それにより「システムの安定化」を実現化することができるからである。逆に言えば、そういう風にシステムを作らなければ、安定して機器を動かすことはできない。

　その一方、ユーザーインターフェースをつかさどる機器は、「正のフィードバック」として動くものも多い。たとえば、車のハンドルを動かすパワーステアリングなどは、入力の増幅が出力の増幅を生み出す「正のフィードバック」システムだ。少ない力で人の手助けをするシステムを作ろうとするならば、「正のフィードバック」を使うのが自然で人に優しい、というわけである。そういった、ユーザの反応を増幅拡大して見せるポジティブ・フィードバック系が多い。

　ユーザの操作・反応がとても重要であり、同時にマスメディアでもあるようなツールを作ろうとするときには、この「フィードバック」特性を意識することは、きっと何かの知見を与える、と思う。「正のフィードバック」と「負のフィードバック」、そして、それらのフィードバック・システムが生み出すシステム、そういったものの挙動をシステムに関わる人々が想像してみることは、きっと何かの役に立つのではないだろうか、と思う。

　どちらが良いとか悪いといった単純な二元的な話ではなくて、複雑なシステムの挙動に対して道具が与える影響を考えてみることはきっと無駄にはならないだろう、と思う。