メッセージ。 - diary

http://www.absoluteweb.jp/ohno/?date=20051227#p01

姉と妹のお話。面白かった。長い文章が書けるってうらやましいな。まるで自由に空を飛んでいるような。そんな息遣いを感じました。

http://knn.typepad.com/knn/2006/01/post_3.html

 KandaNewsNetwork: ニュースの作られ方

 

 どの局も、取材時点の前で、報道したい演出を決め込んできている。そのキーワード以外は何を訴求してもムダだった。テレビはやはり、ビデオでなく、生出演でなければだめだと思った。

そうそうそうそう！ マスメディアに接するうえで、このへんを理解しておくのはすごく大事。テレビに限らず、新聞でも雑誌でも、マスメディアってワクが決まっちゃってることの弊害がけっこう大きい。

枠至上主義とでも言うのかなぁ。たとえば、新聞なんかを見ていても、文字が印刷されていないスペースはほとんどない（広告枠を除いて）。たとえその日が平和な一日で、ニュースにするような記事がなかったとしても、とにかく枠を埋めることが要求されるからだ。

だからメディアの人間は、自分の担当する枠に穴が空くことを一番恐怖する。とにかく何か、ネタネタネタ。埋められるものを探して自転車操業しているところも多い。だから神田さんが経験したようなことが起こる。

枠を埋めることを優先していると、ディレクターはまずストーリーを作って「あのネタはこれくらいの分量だな」、「ここにこのコンテンツを置いて盛り上げ、このへんを結論にしよう」とか考えざるを得なくなる。「調べてみたらこうでした。ネズミ一匹しか出ませんでした。時間余りました」みたいなのは許されない。少なからず予定調和がそこにある。

……ただね。まぁそれは仕方がないんだよ。メディアの制作現場でも、思いのほか少ない予算で作ってたりする。また、さまざまなしがらみや人間関係、組織の問題、個人の能力の問題などでうまく回らなかったりもする。すごい人もいればダメな人もいて、とにかくそれはスーパーな現場じゃない。ぼくらが日々苦労しているようなことが、メディアの現場でもたくさん起こってる。

そういう意味でね。「メディアなんてそんなもん」という感覚は持っておいたほうがいいと思うんだな。ネガティブな意味じゃなくてさ。彼らもスーパーマンじゃないってことで。こういう感覚を理解するうえで、神田さんの今回の記事はとても有意義なものだなぁと思った。

# 蛇足。よくメディアの報道を陰謀論なんかと絡めて考える人がいるけど、そういうのがないとは言わないけど、恣意性とか足並みそろえるのとか、そんなにうまくいかないような気がするですよ。

昨日の晩御飯のとき。マクドナルドでダブルチーズバーガーをほおばっていたら、椅子のかどからそおっと顔を覗かせて、クスクスクスクス笑っている子供を見つけた。金髪にオーバーオールの男の子だ。席を探すとき、外国人らしい夫妻を見かけたから、たぶんそこのお子さんなんだろう。退屈して、遊び相手を探してる様子がありありと見えた。

ぼくはハンバーガーにかぶりつきながら、ゆっくり視線を反対に向け、そしてさっと振り返る。椅子の向こうに金色をなびかせて、キャッキャキャッキャと声がする。そんなことを何度も何度も繰り返しながら、晩御飯の時間は過ぎていった。こういうとき英語が離せれば、何か話しかけられるのに。

……それにしても、いまどき珍しい光景だったよ。外国の子とはいえ、ああいう風に遊ぶ子供が、いまもいるんだねぇ。赤坂という土地と頑是ない子供の遊び。金髪の少年と30代オタク男子。休日の都会に淡く重なるようなコントラスト。それにしても、なーんでぼくなんだろうねぇなんて思うのは、いつもの自意識過剰かもしれないけど。

http://d.hatena.ne.jp/nipotan/20060128/1138445825

 にぽたん休憩所 - ライブドアの技術に限らない話

 

 ということで、

 今晩 22:58〜、NHK 総合で放送の「つながるテレビ＠ヒューマン」に出ます。

 私の部分は収録ですが、何も後ろめたくはないので、顔出し & 名前出しで出ます。

 ライブドア公認でライブドアの人間がメディアに出るのは、これが初になるんじゃないでしょうか。

 率直に今感じていることを言わせていただきました。

にゃー。番組終わりかけじゃん！ 見たかった。いま会社（泣）

ん？ なになに？
「MENSに質問！」？
「おひとりさまを見て好感を持ちますか？」？

つまり、一人でごはん食べたり、旅行に行ったり、
休日を楽しく過ごせる女性の人をどう思いますかって？

んなもん、萌え〜ですよ。決まっとろう。

男女問わず、よく一人でいて、「つまらない」とか、
「さみしい」とか言う人がいるけど、
自分一人を楽しくできない人が、誰かと一緒にいて
楽しく過ごせるんだろうかとぼくは思う。
楽しく過ごせるはずがない。

以前日記に書いた言葉リレーで、「つまらんぞ」と
言う人こそつまらないと言ったのも同じ。
つまるためには、その人自身につまるための
芽がなければならない。

誰かと一緒にいて楽しいと思うためには、
その人自身に楽しさを生み出す芽がなければいけない。
芽こそが価値であり、あなたのすべてだ。
芽を育てることが大事なんだ。

>

Q.「おひとりさまを見て好感を持ちますか？」

→「好感を持つ」21%、「持たない」79%
<<

はぁ？

>

Q.「彼氏がいるのに、ひとりで行動することを理解できますか？」

→「理解できる」9%、「理解できない」91%

理解できない派の意見。
・何をやっているか心配。
・つきあっている意味がない。
・相手の行動がわかっていないと不安になる。
・彼女のひとり旅は許せるが、妻のひとり旅は許せない。     
<<

好きにしてくれ！
ただし、そういう人は男女問わずおれのまわりに近付かんとってほしい。
というか、このアンケート結果、ほんまなんか？ プンプン！

お正月休みに『Joel on Software』を読んだ。鋭い考察をした本で、なかなか興味深かったのだけど、とくに面白かったのが「漏れのある抽象化の法則」だった。ちょっと引用してみますね。

P.221

 漏れのある抽象化の法則が問題である理由の1つは、抽象化が、それが意図されているほどには私たちの生活を楽にはしてくれないことにある。誰かをC++プログラマとして鍛えていると、char*とかポインタ演算とかについて教えずに済めばいいのにと思う。すぐにSTLのstringに進むことができたらいいのに。しかしある日、彼らが"foo"+"bar"のようなコードを書いて、とても奇妙なことが起こり、私は立ち止まってchar*について教えざるを得なくなる。あるいは、彼らはあるとき「OUT LPTSTRを引数に取る」とドキュメントに書かれたWindows API関数を呼ぼうとするのだが、char*、ポインタ、Unicode、wchar_t、TCHARヘッダといった、漏れ出てくるものすべてについて学ぶまでは、その関数をどうやって呼べばいいのかさえ分からない。

 

 COMプログラミングについて教えるとき、Visual Studioのウィザードとコード生成機能の使い方について教えるだけで済めばいいのにと思う。しかし何かが上手くいかないとき、彼らには、何が起こっているのか、まったく見当が付かない。そうして私は、彼らにみんな教えなければならなくなる。IUnkownに、CLSIDに、ProgIDに……ああ、慈悲を！

 

 ASP.NETプログラミングを教えるとき、いろいろなものをダブルクリックして、それからユーザがそれをクリックしたときにサーバで走るコードを書けばいいのだと教えるだけで済めばいいのにと思う。確かにASP.NETは、ハイパーリンク（<a>）のクリックを処理するHTMLコードを書くことと、ボタンのクリックを書くことの違いを抽象化している。問題は、ASP.NETのデザイナが、HTMLにはハイパーリンクからサブミットする方法がないという事実を隠す必要があったことだ。彼らはそれができるようにするために、数行のJavaScriptを生成して、それをハイパーリンクのonClickハンドラに付けた。しかし抽象化は漏れて、エンドユーザーがJavaScriptを無効にしているとASP.NETは正しく動かない。ASP.NETが何を抽象化しているのか理解していなかったら、プログラマには何が悪いのか見当も付かない。

 

 （中略） 

 

 今日、CityDeskに取り組んでいて、私が知っていなければならないことは、Visual Basic、COM、ATL、C++、InnoSetup、Internet Explorerの内部構造、正規表現、DOM、HTML、CSS、XML—いずれも、古い『K&R』にあるものに比べて高レベルのツールであるが、しかし私は依然として『K&R』に載っていることを知っている必要があり、そうでなければトラブルに見舞われる。

 

 10年前、私たちは、将来は新しいプログラミングパラダイムによってプログラミングが簡単になっているだろうと想像していた。確かに、何年にもわたって私たちが築き上げてきた抽象化は、GUIプログラミングやネットワークプログラミングのような、10年、15年前には扱う必要がなかった、ソフトウェア開発の新しいレベルの複雑さを取り扱うことを可能にしてくれた。そして、現代的なオブジェクト指向のフォームベースの言語のような素晴しいツールは、たくさんの仕事を驚くほど早く成し遂げられるようにしてくれる。しかし、ある日突然、抽象化が漏れているところで問題を解明する必要が生じ、それには2週間もかかるのだ。そして、あなたがプログラマを雇うとき、仕事のほとんどがVBプログラミングであっても、VBプログラマを雇ったのでは十分ではない。VBの抽象化が漏れているところに出会うたび、彼らはタールにはまりこんで動けなくなってしまうからだ。

これはほんと、慧眼だよなぁ。ぼくも昔から「プログラミングができるようになるためには、コンピュータの気持ちを理解できるようにならなければいけない」と言っていたのだけど、これではうまく説明できていない。だけど漏れのある抽象化の法則は、これを本当にうまく説明してくれている。

ちょっと前、malaさんや増井さん、荻野さんと飲んだときも同じような話になった。「初心者にも、Ruby on Railsみたいなものを教えるべきだ」、「Ruby on Railsってどこがすごいんですか？ あんなの昔からありましたよ。便利なんですかねぇ？」、「簡単なことを簡単にできるようになっていて、かなりうまく抽象化してくれている」、「どの程度うまくやってくれるんでしょう？」、「……」という感じ。

漏れのある抽象化の法則は、まさしくこういった疑問に答を与えてくれる。プログラミングの本質に切り込む重要な理解だと思う。