アイロンビーズでルイージ作った

娘のためにアイロンビーズを買ってきたんですが、いつの間にか自分が夢中になってコレを作っていました。

ちょうどいい感じのチョコレートの空き瓶があったので並べて撮影。

（マリオじゃなくてルイージの理由は茶色のビーズが無かったためで深い意味はないです）

蓋然性のジレンマ

合理性のジレンマ、と云ってもいいかもしれない。
市場を調査し、顧客の意見に耳を傾け、自社の技術に磨きをかけ、リスクを抑えて、合理的に考えてもっとも成功する蓋然性が高い道を選ぶほどに、ヒット商品からは遠ざかっていく。
なーんか、そんな時代な気がするのよ。

微分不可能っていう感じかな。
「今」の傾向を分析するじゃん？「今、アレが来てるよね」っていうトレンドが見つかるじゃん？その微分値から将来の傾向を予測して「次はコレ！」って決めても、なーんか、当たらない気がするのよ。

微分から次を決めるっていうのは、つまりはニュートン法だよね。ニュートン法ってのは、目的関数が多峰性だったり解空間が離散的だったりすると使えないわけで、要するにそんな感じの時代。

目的関数が多峰性だと、普通にやったら簡単に局所解に陥っちゃう。じゃあどうするか。
遺伝的アルゴリズムなら突然変異率を上げる。SA法（シミュレーテッドアニーリング法）なら温度パラメータを上げる。
要するに、ランダム性を上げる。つまり「蓋然性」が低いところも探索しに行くってこと。無駄としか思えないところも探索しに行くってこと。そうやって初めて局所解から脱出できる。

「景気が悪いです、どうしますか？」
政治家も経営者もみんな、「無駄を省きます」ばかり言ってる気がするんだよ。そりゃいいんだけどさ・・・、どうもスイートスポットを外してる気がしてならないんだよ。
ムダ取りはトヨタ生産方式に代表される日本のお家芸ですしね。それが最も「蓋然性」が高いのは分かる。分かるんだけどね・・・。

そうやって蓋然性ばかりを追いかけていると、社会全体の突然変異率がさがるんじゃなかろうか。社会全体の温度パラメータが下がるんじゃなかろうか。社会全体が局所解へと急速に陥って身動きがとれなくなるんじゃなかろうか。

うん、モヤモヤと引っかかるのは、つまりこういうことだ。
何をもって「無駄」とするのか、その定義は存外に難しいんじゃなかろうかね、という疑問。
ものすごい高効率で製品を生産したところで、その製品が売れなければ意味が無い。逆に、いつも席を離れてどこに行っているのか分からない人が、散歩中にアイディアを閃いてヒット商品に繋げるかもしれない。
つまり、とある人の散歩が無駄かどうかを判断することは、果たして可能なのかどうなのか。

・・・てなことを、この本を読みながらつらつらと考えてる。

新しい市場のつくりかた

シャープやパナソニックの惨状をニュースで見聞するたびに、なんだか息苦しい気分になっている。
なぜだろう。
あれが日本の縮図だと感じるからかな。
あれが今のお前の姿だ、と鏡を突きつけられているように感じるからかな。

そんな息苦しさのなか、この本は、届くべき人にきちんと届くだろうか。

この本は「余談の多い」と銘打ってある。
というより、余談しかない。
でもその余談は「無駄」じゃないんだよね。
「余談」という形態でしか語れないものがあるじゃん。「余談」でしか伝えられない温度があるじゃん。
日本中の人がこういう「余談」を紡ぎ始めるときこそが、新しい市場の始まりだ。
・・・ってことだと思う、カッコつけて言うと。

そうそう、この本のタイトルは信じてはいけない。
皮肉なのかな。皮肉なんだろうな、きっと。
文字通り「新しい市場のつくりかた」の答えを求めて本書を手にとった、合理的で真面目でせっかちなビジネスマンは、さぞかしガッカリすることと思う。
でも、そういう人にこそ読んでほしい。

スゴイ本が出た！Computer Graphics Gems JP 2012

著者の一人である三谷さんより献本頂きました。ありがとうございます！

Computer Graphics Gems JP 2012 -コンピュータグラフィックス技術の最前線-

恐れ多くも三谷さんが書かれた第一章の原稿をチェックするという大役に与りました。お役に立てたのだろうかと不安に思うと同時に、このような素晴らしい書籍にほんの少しでも関わりが持てたことがとても嬉しく、大変名誉に思っています。

などといいつつ、実は正直申し上げまして、まだあまり読めていません（ごめんなさい）。パラパラとページをめくってざっと内容を確認した程度です。「もっとちゃんと読んでから感想をブログにアップしよう」と思っていたのですが、仕事やら育児（というか僕は子どもと遊んでいるだけですが）やら色々とバタバタして何時まで経っても時間が取れそうにないので、取り急ぎ紹介記事だけでもアップすることにしました。

（あと、恥ずかしながら私の素養が足りなすぎてざっと読んだだけではすんなりと理解できそうになかったという・・・orz）

ろくに読んでないのにこう書くのは失礼かもしれませんが、コレはすごい本だと思います。パラパラとページをめくっただけでも「これはすごい」という雰囲気が紙面からムンムンと伝わってきます。この手の内容が日本語で読める書籍はあまり無いんじゃないでしょうか。

著者の方々のお名前を拝見しますと、お会いしたことのある方、名前を聞いたことのある方がチラホラといて、これも僕にとっては楽しい体験でした。

この本の魅力の一つは、各章ごとに（書き手ごとに）文体がまるで違う、ということではないでしょうか。各章を担当された方たちがそれぞれのスタイルでそれぞれの熱意を込めている感じが伝わってきます。技術書でありながら、書いている方たちの個性や人間味が伝わってくるように僕には感じられました。文体を統一してしまうよりも、こういった個性を生かしたスタイルのほうが読んでいて楽しいですね。

2013も出版されるといいですねー！

株式会社カタッチを退職しました

私は9月からこうなります。（ごちゃごちゃと文章を書いても分かりにくいので図にしました。）

「好き」の反対は「嫌い」ではなく「無関心」だそうです。
同様に「幸せ」の反対も「不幸」ではないかもしれません。「幸せ」と「不幸」は案外近くて、案外似ているような気がします。
「幸せ」「不幸」の反対は、「退屈」ではないでしょうか。

自分が今、幸せなのか不幸なのかはよく分かりません。
しかし「退屈」していないことだけは確かです。

人間万事塞翁が馬ですからね！
遠い先のことまでは分かりませんが、とりあえず当面は楽しく生きていけそうな気がしています。

・・・というわけで、3Dなソフトウェア開発のお仕事があったら是非お声をお掛け下さい。自分で言うのも変ですが、今はお買い得ですよ！（たぶん・・・）。

読みやすいコードとは何か

Twitterでお題をもらったので、力不足を承知で書き綴ってみます。プレッシャーで変な汗が出そうですが、頑張ります。（今日は体調を崩してしまったので、自宅でのんびりしながら書いています）

まず「読みやすいコード」という言葉が僕はあまり好きではないのです。「読みやすい」というのは主観的な要素も強く、読みやすさの指標もハッキリとしません。読みやすさは読み手のスキルに依存してしまうという面もあります。そういった曖昧さを排除し、「読みやすさ」の正体をもう少し分解して捉えることは出来ないのでしょうか。

コードを読む、とはどういう行為か

脳内にある論理構造をコードに落とす行為がコーディングです。逆にコードから論理構造を脳内に再構築する行為が「コードを読む」ということです。言うなれば、コーディングはシリアライズで、コードリーディングはデシリアライズなわけです。つまりコードが「読みやすい」とは、コードから論理構造へデシリアライズしやすいこと、と捉えることができます。
一般にシリアライズよりもデシリアライズのほうが面倒で難しいです。ですからファイルフォーマットは大抵「読みやすい」ように設計されます。それと同様に、コーディングも「読みやすい」ように行われるべきでしょう。

読みやすさの3つのレイヤー

読みやすさには概ね3つの観点があるように思います。

1. 趣味や慣れのレベル
2. ヒトの認知・認識のレベル
3. 本質的な論理構造のレベル

インデントを揃えるとかどこにスペースを入れるとか、いわゆるコーディングスタイルは 1 のレイヤーに属します。ここでは議論しません。
2 は少し本質的です。ヒトの脳は一般にどのように対象を認識するか、という観点を指しています。各個人に依存した趣味や慣れの問題ではなく、人類の脳に共通な観点です。例えば「良い名前をつけるべき」というのは2のレイヤーに属します。人間なら誰だって、適切な名前が付けられている方が読みやすいでしょう。しかし名前は論理構造とは何の関係もなく、クラス名や変数名を変えたところで動作結果に差異は出ません。名前はコードを読み解く際の「ヒント」であって、もちろんそのヒントはとても重要なものですが、論理構造そのものとは関係がありません。
3 が最も本質的なもの、と僕は考えています。ここでは可能な限りこの観点で書いてみたいと思っていますが、うまく書けるかどうか・・・。

【余談】オブジェクト指向について

やや余談になりますが、オブジェクト指向は 2 のレイヤー「ヒトの認知・認識のレベル」で語られ過ぎたように思っています。これはオブジェクト指向という言葉がプログラミングから分析・設計まで幅広く使われたことにも原因があると思われます。世界の万物をオブジェクトとしてモデル化するだとか、メッセージパッシングだとか、名前がないものは認識できないとか、名前で対象を切り取るとか、そういう哲学的な語られ方をすることが多かったように思います。こういった議論は、何かものすごく深遠な真実に触れたような気にさせられる割に、プログラミングにはさほど役に立ちませんでした。（分析や設計では役立つ面もあったかもしれませんが、私には分かりません）
オブジェクト指向プログラミングについては、それとは違う言葉でメリットが説明されるべきだと考えています。

長いコードは何故ダメか

下記のコードを例に考えてみましょう。

int hoge()
{
  int a = 1;
  int b = 2;
  int c = a + 3;
  int d = b + 4;
  return c + d;
}

この関数は5行あります。一般に、各行は潜在的にそれより前の行に依存している可能性があります。つまり潜在的な依存関係は下図のようになります。

つまり n 行の関数があったとすると、各行の間には n(n-1)/2 の依存関係が潜在的に存在しうることになります。
しかし上記のコードを実際に読み解いてみれば、下図のようなシンプルな依存関係で構成されていることが分かります。

このように、潜在的に存在しうる依存関係から実際の論理構造を抽出する行為が「コードを読む」ということだと僕は考えています。そして、潜在的な依存関係を出来るだけ小さく抑え、実際の論理構造に近い形に保たれているコードが「読みやすいコード」だと考えています。
上で見たように、潜在的依存関係は行数の二乗のオーダーで膨らんでいきます。これが長い関数は読みにくい原因です。

無名を好め

名前をつけるということは、他から参照され得るということです。つまり潜在的な依存関係を増やします。コードの読み手は「もしかするとこの名前は他の場所からも参照されているかもしれない」という可能性を念頭に置きながら読む必要が生じます。ですから、そもそも名前を付けずに済むのならば名無しで済ませたほうが良いはずです。
下記の2つのコードは等価なものですが、前者は関数の戻り値を受けた変数として a, b という名前を付けています。私は変数名を付けていない後者のコードのほうが優れていると考えています。

int a = foo();
int b = bar();
buzz( a, b );

buzz( foo(), bar() );

とはいえ、さすがに下記のコードはやり過ぎかもしれませんね。

func1(
  func2( func3(), func4( func5(), func6() ), func7() ),
  func8( func9(), func10() ) );

どこからが「やり過ぎ」と感じるかは個人差があります。これは人間の脳の能力とか個人の慣れとか好みの問題が絡むからです。おそらく訓練されたLispプログラマはこの程度ではびくともしないでしょう（たぶん）。

名前をつけるならスコープはできるだけ小さく

当然、名前を付けざるを得ないシチュエーションは存在します。クラス定義、メソッド定義、変数宣言、すべてが名前をつける行為です。これらすべての名前をつける行為は、名前空間の汚染につながることを理解するべきです。ここでいう名前空間の汚染とは、単に名前の衝突可能性のことを指しているのではありません。潜在的依存関係の増大を指しています。
あるスコープに名前が n 個定義されていると、それらの潜在的依存関係は n の二乗のオーダーになります。つまり名前を定義するということは、潜在的依存関係を増大させ、読みにくくする行為であるということです。
ですから、その影響範囲は出来る限り小さく抑えたほうが良いということになります。可能な限り小さなスコープに名前を閉じ込めるべきです。変数名、メソッド名、クラス名、全てにおいて名前を出来るだけ小さなスコープに閉じ込めることが読みやすさにつながります。

・・・息切れしてきた。
やばい、すごい大変な気がしてきた。全然説明しきれん。まだ静的な構造のことしか書けてなくて、動的な状態遷移の読みやすさについては一言も触れてないし。
しかも、当たり前のことしか書いてない気がする。書いてるうちに脳内で「そんなの当たり前じゃん」ていう声が聞こえてきてヤバイ。
何よりヤバイのは誰に向けて書いているのか分からなくなってきたこと。こういうのは初学者向けに書かなきゃいけないんだろうけど、もう俺の頭ン中は「上級者からのツッコミが怖い」という恐怖心でいっぱいだ。
なんだか書いてる意味があるのか分からなくなってきたよ、パトラッシュ。
尻切れトンボで申し訳ないけど、一旦ここで終わりにするよ。

あなたの心にあるガベージコレクション

初めてガベージコレクションを知った時、なんて酷いやつだと思った。

だって、どこからも参照されていないオブジェクトは問答無用で消してしまう。友達居ないやつを消して回っている。ぼっちは死ねということだ。非情なガベコレを前にして「僕はここにいるんだ！生きてるんだ！殺さないでくれ！」と泣き叫ぶ孤独なオブジェクトが眼に浮かぶようだ。

・・・なんてね。戯言（ざれごと）です、オブジェクトを擬人化した、ただの戯言。

でも、こうは思いませんか？

みんな誰でも、心のなかにガベージコレクションを飼っている。
みんなこう云う。「世界と繋がっていたい」。
たぶん、逆。世界との繋がりが切れてしまうのは怖い、と思っている。
そうして、自分に振られた参照カウントを数えながら、心に棲んでいるガベージコレクタに怯えている。

そうして、ツイッターでフォロワーを増やし、SNSで友だちを作り、ブログを書き、ぼっちがバレないように便所で飯を食い、ヒーローになりたくて課金アイテムを買う。

・・・なんてね。戯言です、ただの戯言。

でもこうは思いませんか。

ガベコレのルート集合はインターネットなんじゃないかって。インターネットから参照されていないものは存在しないのと同じだって。日常生活の繋がりなんて小さなコミュニティの循環参照に過ぎなくて、まるごとガベコレに消されてしまうような儚いものなんじゃないかって。

・・・なんてね。戯言です、ただの戯言。

検索エンジンの次に来るもの

ランキングエンジン、というのはどうだろう。

もちろんユーザーの投票によるランキングシステムは既に沢山ある。ここでいうランキングエンジンとは、多数決の投票による単純な順位付けではなく、もっと高度なものを想定している。その理由は、単純な投票システムでは問題が発生しているからだ。

今流行りの、ステマというやつだ。

業者によって月島もんじゃのランキングが不正に操作された件は記憶に新しい。こういうことが起こると当然みんな疑心暗鬼になる。あれもステマじゃないか、これもステマじゃないか、と疑うようになる。こうなってはもうランキングは機能しない。

「ステマに騙される奴は情弱」。そういう見方もあるだろう。確かに個のサバイバルという視点からは情報の真偽を見定めるリテラシーも重要かもしれない。しかしそれは、あまりワクワクする考え方ではない。個のリテラシーに頼った解決よりも、システムで解決する方法を考えるアプローチのほうが好きだ。より優れたランキングシステムを構築すること、つまりステマで簡単に操作されることがないロバストなランキングエンジンは作れないのか、と考える方が楽しい。

近いものを Amazon が既に作っている、ような気がする。

Amazon のレビューには『○人中、○人の方が、｢このレビューが参考になった｣と投票しています。』という表示が出ている。つまりレビューに対する信頼性をユーザーからの投票で評価している。そして「おすすめ度」の集計には、このレビューへの信頼性が勘案されているように見受けられる。つまり不正に評価を操作しようとしても、そのレビューがユーザーの信頼を得られなければ、「おすすめ度」の得点を思うように操作することは出来ないようになっているんだと思う。

こういう機能が食べログなどにも必要なのではないだろうか。

ただ、これだけではやや物足りないものを感じる。例えばあるレビューを見たユーザーが「これはステマだ」と評価したとする。果たしてその評価は信頼できるものなのだろうか。ただステマと言いたいだけの奴が滅多矢鱈に悪い評価を付けまくっている可能性はないだろうか。レビューの良し悪しの評価を単純な投票に頼ってしまっては、結局ノイズを取り除けないのではないだろうか。

つまり突き詰めて考えれば、評価の連鎖は無限、ということになる。あるモノへの評価があり、その評価への評価があり、評価の評価の評価もある。ランキングは、こういった評価の連鎖を積分したものであることが望ましい。

そういうランキングエンジンが、そのうち登場するんじゃないか、と思う。

それは待ち遠しくもあり、少し恐ろしい未来予想図だとも思う。ランキングエンジンはかなりの権威・権力を帯びる可能性があると思うからだ。それは過去に（そして今も）検索エンジンで起こったことの繰り返しだ。アクセス数は、検索エンジンの上位に表示されるかどうかに大きく左右される。そのためにSEOという言葉も生まれた。Google八分という問題も発生した。ランキングエンジンでは、この問題ががもっと露骨な形で再浮上するような気がする。

まあ、そもそもランキングというものはインターネット以前から権威の発生装置であったと言える。頼まれてもいないのにレストランに点数をつけたり。応募されたわけでもないのに文学賞を授与したり。するといつの間にか、そこに権威が発生する。権威はたぶん金になる。ランキングは常に何処かきな臭い。

そういうものかもしれない。