ウェブ時代に成果をあげるための心得

ウェブ時代において、質の高い仕事をし、大きな成果をあげようとする人のための心得：

• 面白いからといってやみくもに読むのはやめなさい。ウェブでは、あなたが読むよりも速く情報が増殖していく

• 人の目を介して編集された 質の高い文章を読むようにしなさい

• 人生は短い。多くの意見を聞くのではなく、少数の、物事を深く考えよく洗練された人と議論すること

（1996年にチューリング賞を受賞した、Amir Pnueliの言葉だそうです）

もしもピアノが弾けたなら

なんだかとても残念な話。

文化祭で、出し物の都合でピアノ奏者が必要に。ピアノ未経験の女子生徒が立候補。彼女をバックアップするためにクラス一丸となって準備に奔走する。

けれど、後に同窓会で、他にピアノが弾ける子がいたことがわかって、たいそうショックを受け卒倒しそうになりました、ということです。

この「弾けることを隠す」という気持ちは、なんとなくわかります。僕自身も高校時代、能ある鷹は爪を隠す、とまでは言わないけれど、同じ雰囲気を感じたためか、楽器が弾けることを大っぴらにはしていなかったように思います。現に、高校時代の友人の中には、僕が楽器を弾くことを今更ながらに知って驚いた人もいます。

それでも、上の話のような事態にならなかったのは、他にもピアノが上手な子がいて、その子は率先して人前に出るタイプだったので、特に困らなかったというだけ。

自分自身を鑑みて、元の話の彼が「弾ける」と言い出さなかった理由はいくつか思い付きます。

「自信がなかったから」 うん。これはありそう。まだプロじゃないだろうし。

「自分がいなかったらどうするんだろう？」という興味。学校のクラスはなにかとピアノ演奏をする子が必ず一人はいるようになっていて、どうしてそれが成り立つのかいつも不思議に思っていました。もし、誰もピアノが弾けなかったら、この状況をどうやって乗り切るのか、とても興味があります。別段、皆を困らせたいわけではないのだろうけど。

「ピアノが弾けるのだから」と言われることへの嫌悪感。ピアノが弾けるというだけで、弾く役になることが既に決まってしまっているというのは、その人の演奏能力を身に付けるための練習時間や努力にタダ乗りしているようなもので、フェアではないと強く感じます。あわよくばタダ乗りしようとしていたのを棚に上げて、皆で努力していた間、隠していたのは何事だ、というのではあんまりです。

一方、音楽ができることを隠していたために、悔しい思いをしたこともあります。野球部の地区予選の応援にクラス全員で行ったときのこと。相手高の吹奏楽の応援がまぁとにもかくにも下手なわけです。けれど、僕は野球を見ることそのものが好きだったので、下手な演奏なぞ気にも留めていませんでした。

すると、隣にいた例のピアノが上手な子が一言。

「（演奏の下手さに）気付かないのって幸せだよね」

と言うのです。このときばかりは、はらわたが煮えくりかえりました。その見下した態度はなんだ。音楽ができるのがそんなに偉いのか、と。（隠しているこっちもこっちなので、おあいこなのですが）

とまぁ要するに、最後の可能性として、そのピアノが弾ける子の

「性格が悪かった」

だけなのかもしれません。元も子もないですね。お後がよろしいようで。

「正直」である前に「真摯」であれ ～ 草彅君の謝罪会見で感じたこと

真摯（しんし）であることと、正直（しょうじき）であること。この二つは似ているようで、与える印象はかなり違うものです。先日の草彅君の謝罪会見のおかげで、「正直」と「真摯」の違いに関する例をいくつか思い出すことができたので、ここに挙げてみます。

以下は、温暖化ガスによる環境問題で、ガソリンの代わりに、バイオ燃料と言われるエタノールを使うことのデメリットを紹介したThe Economistの記事：（一応リンクは張ってありますが、原文はThe Economistの購読者しか読めないようです。すみません)

And when Henry Ford was experimenting with car engines a century ago, he tried ethanol out as a fuel. But he rejected it—and for good reason. The amount of heat you get from burning a litre of ethanol is a third less than that from a litre of petrol. What is more, it absorbs water from the atmosphere. Unless it is mixed with some other fuel, such as petrol, the result is corrosion that can wreck an engine's seals in a couple of years. (Henry Fordが一世紀ほど前に、エタノールを燃料として使ってみようとしたが、この案は却下されることになった。これにはちゃんとした理由があって、エタノールを燃やしたときの熱量はガソリンの3分の1以下にしかならず、さらに空気中から水分を吸収してしまうので、他の燃料、たとえばガソリンなどと混ぜない限りエンジンのコーティングを数年で腐食させてしまうからだ。) - Ethanol, schmethanol. The Economist, Sep 27th 2007.

この記事を読んで僕は、トウモロコシなどから取れるエタノールなどのバイオ燃料は、騒がれている割に実際はだめなのかと、しばらく思いこんでいたのですが、ブラジル出身の人から聞いた話だと、ブラジルではエタノール燃料の方がむしろ主流で、ほとんどの車がエタノール燃料で動いているし、エンジンの痛みも別にガソリンと変わらないとのこと。この話を聞いて、僕としてはなんだかThe Economistに騙された気分になったのですが、その後、同誌の読者からの意見のページ(Letters)で、以下のようなコメントを見つけました。

It would also do more to encourage the use of vehicles with flexible-fuel engines to provide American consumers with something they do not have: a real choice. In Brazil 80% of new vehicles run on ethanol, petrol or a mixture of both. There is no special tax rebate for these cars: we buy them because we want to. （（もしアメリカがエネルギー問題を真剣に考えているなら）アメリカの消費者が持っていない多燃料対応の車（これは実際の選択肢として存在する）を使わせるようにするべきだ。ブラジルでは80%の新車が、エタノール、ガソリン、またはその両方を混ぜたもので動くし、そういった車に対して税金の払い戻しなどもない。皆、必要だから買うのだ。）- From Letters, The Economist. Oct 11th 2007

これは明らかに記者の認識不足を指摘した意見なのですが、それにも関わらず、そのような記事をきちんと紹介している姿勢に、The Economist誌の「真摯」さを感じることができました。「間違いを指摘した意見は載せたくない」とか、「あの記事には間違いが含まれておりました。大変申し訳ありません」という対応が、「正直」な気持ちをそのまま表現したものだと思いますが、読者としては、そのような「正直」な姿を見たところで得るものは少ないです。

もう一つの例。大学のとある卒業審査のための発表会での話。

（先生）「その研究は、既存のツールを使いまわしただけじゃないのか？」

（学生）「（しばらく悩んで）…、はい。そうです。」

これも、「正直」の例。正直なのは結構だけれど、審査する先生方もおそらくその「正直さ」を求めているわけでありません。例えば、「使った技術は既存のものの組み合わせだけれど、それでもこの問題に取り組むことは大事なんだ」と言えるだけの、研究に対する「真摯」な姿勢。それを見せる方がきまって良い印象になります。

そして、草彅君の謝罪会見。「また楽しいお酒が飲めるようになりたい」と言うような「正直」さが好感を得ている、という報道もありましたが、それよりも、彼が慎重に言葉を選んでいる姿、自分の置かれている状況や、自分の行為、言葉が世間に与える影響などを真剣に考えている。そんな様子を容易に見てとることができたので、ただ正直に謝るではなく、真摯に向かうその姿勢こそが大事なんだということがよくわかりました。自分の犯した罪に真剣に向き合う。ただ愚直に発言を撤回するのとは質の違う「真摯さ」。

僕自身も「正直」である前に「真摯」でありたい。そう思います。

(追記）

「草彅（なぎ）」君の漢字を、「草薙」と書き間違えていたので修正しました。まさか、こんな形で、このエントリに書かれていることを実践することになるとは。。。id:poccopenさんに感謝。

英語コンプレックスなんて些細なこと

「日本語が亡びるとき―英語の世紀の中で」が話題になっていますね。まだ手に入ってなくて悲しいのですが、内容についてはわからなくても、多くの人が英語に壁、いわば英語へのコンプレックス（漠然とした不安・恐怖）を感じていることが伺えました。

たとえば、弾さんの404 Blog Not Foundより：

梅田さんが、なぜ、それも日本ではなくシリコンバレーにおいて、「弾さんは英語が出来てうらやましい」と、ふと軽く、しかし底知れぬ諦念をもって嘆息したのかが。

と、シリコンバレーで長く暮らしている梅田さんでも、この壁は残っているようだし、その英語が堪能な弾さんですら、

まず、本書は英訳されねばならない。皮肉かもしれないが、それが著者の願いを成就させる最短距離である。そのために、私も出来ることをしたい。残念ながら私の英語力は本書を訳出するにはあまりに不十分であり、それ以前に日本語、そして文学の教養が足りなさ過ぎる。

と、文学的作品を書くレベルの英語力に至らないことを認めています。御二方とも、実用上の英語には困らないほどの力を持っていることは十分伺えますが。弾さんの場合は、日本語コンプレックスと言うべきものもあるようで。あれだけの日本語の読解力があり魅力的な文章を書ける人なのに、不思議。人の悩み・コンプレックスを推し量るのは難しいということですね。

他にも、アメリカにいて仕事をしているだけでは足りないという趣旨の話も見つけることができました：

日々の生活や仕事に必要なコミュニケーションはできるようになっても、そのことと英語でのソーシャライズ、つまり親密な交友ができるということの間には無限の開きがある

いやはや。英語経験が豊富な方々の間でも、英語コンプレックスは遍在しているようです。

英語へのもどかしさは常につきまとう 　僕自身も、英語で論文を長く書いていますが、満足のいく表現に行きつかないもどかしさと向き合わざるを得ないのが実情です。表現のストックが溜まるにつれ、書く速度は目に見えて向上していきますが、そうして書いた文章がネィティブの人にとって、意味は通じたとしても、いったいどのような印象を与えるのかについては、皆目見当がつかないのです。

例えば、「日本語が亡びるとき」というタイトルにしてもそう。日本語ネイティブなら、このタイトルを同様の意味で「日本語の危機」や「日本語が亡びる」などと言い換えたとき、それぞれの持つニュアンスの違いを敏感に感じ取れるでしょう。

この違いは辞書的なものではなく、文化的な要因が大きいと感じます。たとえば、過去にその漢字・言葉がどのように使われていたのか。「亡国」「金融危機」など、言葉が使われた状況が現在の意味に反映されていきます。また、「亡びる」「亡びるとき」という違いでも、「亡びるとき」とした方がじわじわと迫りつつある未来を指している印象を与えます。でも、この日本語を感じ取る能力をどうやって学んだのかは、僕自身にもわかりません。

英語で似たような例を挙げるなら、Impossible is nothingがいいと思います。お願いだから文法がどうこうとか叫ばないで。見慣れないフレーズが出てきたときに、どう感じるのか。その感覚が持てないことに、英語コンプレックスを抱くのです。

英語において、このどうやって学んだらいいのかもわからない言葉の機微を感じ取る能力が要求されるというのは、英語で普段不自由なく仕事をしていたとしても、甚だ恐ろしいものです。それなのに日本ではまだ多くの人が、英語で論文を書いたり、英語で仕事をする、ブログを書くという経験に乏しく、この危機感を共有すらできない。これもまた、日本語が生き残る上で、恐ろしいことだとは思います。

英語コンプレックスなんて些細なこと  今後日本語がどういう立場になるかなど、さらに深い洞察は「日本語が亡びるとき」に期待するとして、多くの人が英語コンプレックスを抱いているようです。それなら英語にコンプレックスがあっても、そこで悩む必要はないでしょう。むしろこの状況を逆手にとって、日本語を扱える人として英語を使う楽しみを見出していけばいいのでは、と思います。例えば、

• 映画を見るときに、T女史の意味不明な字幕と十分戦えるようになります。
  
• 邦訳を待たずして、原著で読めます。（翻訳の質や、日本の出版社が原題を捻じ曲げてでも売るためにつけるキャッチーなタイトルに騙されることなく、本を楽しめます）
• 試合中も一球ごとにデータが更新されるMLB（メジャーリーグ）の良さを楽しめます。いまの日本のプロ野球の既得権益にしがみついた体質では、同等のサービスは期待できません。
• 学問なら、アメリカの大学院で、しかも優秀な人は、英語以外が母国語の留学生で占められていることをご存じでした？ 
• やっぱり英語がうまく使えなくても、日本語で生きていける

ここまでリスクを取らずに英語を楽しめるって、実はすごいことだと思います。

英語を使うのを当たり前にする  ただ、僕も、坐しているだけでは何の向上も見込めないので、読む、書く、聞く、話すの能力のうち、「書く」について、また、ニュアンスを多分に含んだ日常の話題に慣れるため、英語でブログを書くことにしました。普段論文を書く方が多いので、ブログは三日坊主になるとは思うけれど。。。

ちなみに「読む」に関しては、僕自身研究者として英語の論文を読む機会が多いのですが、小難しくて気楽に読めないものばかりです。楽しんで読むために、情報系としては一般向けで内容がやや軽めのCommunications of ACMや、Economist（世界情勢と経済の知識が足りない僕には読むのが大変ですが）などの雑誌を電車の中で読んでいたりします。読むスピードのギアを上げないと特集記事などは読み切れないので、だんだん速読のコツが身に付いてくると思います。ただし、記事の内容に興味がないとただの苦行になるので気をつけて。

「聞く」はひたすら聞く。聞きながら重ねて口ずさむと（シャドーイングと言うらしい）「話す」力にも良い効果があります。Economistを英サイトで購読すると全記事の音読ファイルがiPodで聞けるので重宝しています。PodCastのCNET Buzz Out Loudなどは遠慮のないスピードで話してくれるので、英語の生の日常会話の資料として貴重なのですが、会話が事あるごとにMac, PS3, Nintendo～と、単調になってくるので、飽きてしまいました。これも興味のあるものを選ぶのがいいですね。

「話す」を鍛えるために、歩くときには英語で独り言をつぶやいています。ぶつぶつつぶやいていて危ない人ですが、なりふり構ってはいられません。もはや勉強法なんてものではなく、ただひたすら言葉のストックを貯める、表現してみる、の繰り返しです。でも、それだけで大してお金も使わずにかなり英語を使えるようにはなりました。

このあたりの能力って表裏一体になっています。「書く」を鍛えると、頭の中で文を組み立てながら「話す」にも活きてきます。「読む」は表現を真似て「書く」につながる。「聞く」は「読む」ためのリズムを教えてくれるし、状況に応じた会話を「聞く」ことで「話す」ときの言葉の引き出しを増やすのが簡単になります。実際に声に出して「話して」いると、「聞く」ための脳ができてくる実感もあります。

本の到着が待ち遠しい。けれど「日本語が亡びるとき」を読んだ後でも、きっとここで挙げた部分は変わらないと思えるので、先にブログにしました。

たった一つの準備で勉強会は変わる

この記事で伝えたいことは一つ。

建設的な議論を始めるには、準備が必要だ。

本について語るなら、まず本を読む。輪講なら、自分が発表者でなくても、ざっと本に目を通してわからない点をチェックしておくこと。

たったこれだけの準備で、グループでの議論は実りあるものになります。本に書かれている以上の話ができるからです。その段階までいかなくても、わからなかった点を周りの人に確認し、本の内容をより深く理解することができます。

準備をしてないとこうはいきません。まず、なぜこの本を読んでいるかわからない参加者が出ます。さらに、本の紹介者の話がわからなくなると、その段階で思考が停止する。あるいは明後日の方向の議論が始まってしまいます。輪講や勉強会のようにその場で内容を尋ねられるならまだ救いようがありますが、ブログのように対話的(interactive)な議論が難しいメディアでは、理解を深める術がありません。本を読んでないから教えて、というのが通用するのは、その人が教えるに値する場合だけだと考えてください。（知見のある先達であったり、内容に詳しくなくて当然の他分野の研究者など）

大学での研究生活を通して輪講をする機会は幾度となくありましたが、参加者が本を読まなかったときの不毛さには目も当てられませんでした。本の知識は読んできた人だけのもので、読まなかった人には見せかけの充実感だけが残ります。発表側には、自分で本を読み解く以上のものは得られず、プレゼンという参加者へのサービスの重荷が増えるだけです。ですから、今では、受け身の参加者しか集まらなさそうなときは輪講を開いていません。

このような話をしているのは、梅田望夫氏がTwitterでした以下の発言に対するネットでの炎上の様子があまりにも幼稚であるから。

はてな取締役であるという立場を離れて言う。はてぶのコメントには、バカなものが本当に多すぎる。本を紹介しているだけのエントリーに対して、どうして対象となっている本を読まずに、批判コメントや自分の意見を書く気が起きるのだろう。そこがまったく理解不明だ

梅田氏は「ウェブ進化論」などの著書で、ネットをとりまく急速な変化と、そのまっただなかに放り込まれてしまった現代の若者にエールを送り続けています。著書への感想をブログに書いてトラックバックを送信した人には、賛否両論含めてブックマークしているし、内容にも目を通しているそうです。この行動を見ていると、自分と異なる意見も含めて、彼が建設的な議論を欲しているのが伺えます。初対面の人と対談するときも、その人のブログなどをあらかじめ読んでいくから、昔からの知り合いのように話が弾むといいます。

準備をした上で議論することがいかに面白いか。その面白さを知ってしまうと、その準備をしてこない人への興味が途端に失せてしまうのでしょう。何も難しいことを要求しているわけではありません。準備はとても簡単。

同じ土俵で議論をするためには、何よりもまず、本を読むこと

本の内容をすべて理解することを要求しているわけではないし、言葉で書かれたものの解釈は、聞く人のバックグラウンドによって変わるのが普通です。むしろ、その違いが面白く、新しい発見につながることもあるのです。違う観点からの解釈で、内容の理解を深めることあります。

今回話題になっている本は、「日本語が亡びるとき」という書籍。Amazonで注文してからまだ届いていないので、議論に参加できないのが残念ですが、英語でしか本当の意味で活躍できる道が残されていない研究者として、思うところがふんだんにあります。本を読んだあと、またブログで感想を書きたいと思います。

（追記）このあと、「日本語が亡びるとき」についてはいくつか雑多な記事を書きましたが、以下のエントリが、一番僕の伝えたいことをまとめているかと思います。

論文を書く前に知ってほしい「言葉」の大切さ

優秀なプログラマは空気を読んで空気を描く

面白かったので参戦。

• プログラミングテクニックのまとめ 　（基本といいつつ議論の余地が多いエントリ）
  
• 中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント - 分裂勘違い君劇場 (そこに敢えて突っ込んでみた例)
  
• ちょっと囓っただけの素人が自分を過信して陥る三つの罠？ - カレーなる辛口Javaな転職日記（反論の反論に失敗してしまった例）
  
• そろそろ3つのポイントについて「弾言」しとくか（コードで何を作るかの方が重要と一刀両断）
  

まず、３つのポイントをおさらい。

1. 変数のスコープは小さく抑える
   
2. Do Not Repeat Yourself (DRYの原則) 同じコードは2度書くな
   
3. 言語を極めよ

この１と２は、まったく違うようで、とても似た問題を扱っていることにお気づきでしょうか。それは「依存関係」を減らすか増やすか。

矛盾を抱えるプログラマ　変数のスコープを短くすると、コードで必要なデータを近くにまとめて依存関係を減らすことができます。要するに、コードを

inputから、output(+副作用）を作る

というメソッドと同じparadigm(パラダイム: 枠組み）にまとめたいわけです。この形にすると、コードをメソッドの形に書き直して、再利用することが簡単になります。グローバル変数を多く使っているコードは、依存関係を即座に判断するのが難しく、メソッドに纏め上げるのが大変なので忌み嫌われています。

一方、DRYの原則に従ってメソッドやクラスとして一箇所にまとめられたロジックは、使うユーザーや使われる場所が増えるため、依存関係を増やします。使う場所が増えないなら、メソッドやクラスにまとめる理由は、コードにわかりやすい名前（alias)をつけるくらいの意味しかありません。例えば、あちこちで頻繁に使われる文字列型(string)の最初の文字のindexが0ではなく1に変更されたら、大惨事になるでしょう。

プログラマって、依存関係を減らそうと努力しているかと思えば、一方で依存関係を増やそうと一生懸命になる、とても不思議な生き物です。入力から出力を作る枠組みでしか物事を考えられない、可哀想な生き物でもあります。

変数のスコープを最小に抑えると、リソースを解放するタイミングを明確にできる利点がありますが、GC(garbage collection) を搭載した現代的な言語実装では、不要になったらメモリを即解放というわけにはいかないので、スコープが多少ずれていても、さほど深刻ではありません。

プログラマは空気を読む 学生向けにプログラミングの講義をしていたときに学んだのは、ソースコードを追う能力の乏しい段階の学生さんは、抽象化されたコードの「意味」ではなく、「動作」を追ってしまう、ということ。

例えば、SQLなどは高度に抽象化されたコードの典型例でしょう。（これを宣言型という人も多いですが、抽象化の度合いの違いにすぎません）。以下のSQL文、

SELECT * FROM t1, t2 WHERE t1.id = t2.id

を見て、「2つのテーブルt1とt2でidが同じ値の行を結合する」、と読み取れたなら、おめでとう！ もうあなたは立派に優秀なプログラマです。

例え内部で、lexer, parserからなるSQLコンパイラが動いていて、テーブルとクエリの静的型チェックをし、問い合わせスケジュールを組み立て、テーブルのデータ分布に基づいてスケジュールを最適化し、B+-treeとsequentialレコードを、ページロックを取得しながらserializabilityが保証されるようなプロトコルに従って検索して、必要ならライトウェイトロックで管理されたキャッシュにディスクページを保存しつつ、テーブルの結合にディスクを介したhash joinやexternal merge sortを実行していたとしても、そんなことは気にしてはいけません。SQLという入力から得られる結果の意味、つまり空気を読むことが大事です。

プログラミング言語は空気を描くもの どのプログラム言語を極めたらいいかって？ 空気を読みやすくて、自分の空気を描けるもの。できなければ拡張するか、作る。これが言語を極めるということでしょう。作るのは割に合わない？ 使いやすいプログラミング言語とその実装・ライブラリが出来上がるのを待つリスクが割に合うなら、のほほんと偶然の産物を待つのも一興でしょう。

(追記 10月29日)

考えることを減らせるように書く

長くなったのですが、同じラボにいた川中君がきれいにまとめてくれました。

「考えることを減らせる様に書く」

メソッド（関数）によるコードの整理や、オブジェクト指向による実装の隠蔽、プログラミング言語のなりたちなど、プログラミングのすべてはこの動機から始まります。すばらしい。

プログラマとして生きるということ

はてなを眺めるようになってから、「IT土方（どかた）」という言葉を知りました。IT土方とは、

システムエンジニア、プログラマーなどにおける過酷な労働条件を自嘲的に表現したもの。「土方」は差別用語及び放送禁止用語として扱われているため、使用の際には留意すること。

という意味だそうです。僕は研究者だけれど、プログラマでもあるので、プログラマが世間でこう呼ばれているのは非常に悲しいことです。プログラマというのは、本当はとても魅力的な仕事です。土方で甘んじているのは、きっと「プログラマ」として生きていないのだとも思います。（例えば、矢野勉さんのエントリにも挙げられているような状況の人達です）


プログラムをデザインする、ということ プログラムの場合、通常の土木工事と比べて顕著に違うのが、一度作ったコードを「一から作り直さないようにデザインできる」ということ。たとえば、コマンドライン引数を処理するプログラムを一度作ると、それをクラスの形に整理して（OptionParserクラスなどと名づけて）ライブラ リにしておきます。ライブラリを作る作業は、Windowsならdllを作る、JavaならJARファイルにまとめることに相当します。

書いたプログラムが自動的に再利用可能になるわけではなく、そうなるように「デザインできる」ということで、この間は結構違いがあります。二度目からは、ライブラリにリンクして使うので必要な仕事の量は格段に減りますし、使い道にあわせてライブラリの修正をしなくてはいけないことも多いですが、機能を改善し、使い勝手を向上できるというメリットがあります。修正に費やす時間は、今直すか、後で必要になってから取り掛かるか、という違い。Ruby on Railsのフレームワークも、Webアプリケーションで頻繁に書くようなコードをうまくライブラリ、モジュールにしていると思います。

プログラミングが肉体労働になりやすいのは、おそらく、このライブラリにまとめるという経験が不足している場合。Visual Studioでdllを作っておくだけで、ビルド時間や開発時間は短縮できるし、Javaならmavenを使えば、細かな修正を施したjarを頻繁にreleaseする作業が苦ではなくなります。PerlだったらCPAN用のモジュールを作るとか、RubyならRuby gems用モジュールを作るというところでしょうか。

他に考えられるのは、プログラマ自身が今書いているコードが二度目のコード（重複がある）と思っていない可能性。オブジェクト指向の考え方や、デザインパターン（クラスの組み方の過去の知見）を知らなくて、コードを再利用可能な形でまとめることに考えが及ばない、ということがありえます。Subversionやgitなどのソースコード管理ツールの存在を知らないと、再利用といっても、常にコピー＆ペーストするという最悪な方法を採っている人も多いかと思います。これでは単純労働となっても仕方がない。


ハッカーと画家 ここで紹介したいのが、「ハッカーと画家」という話です。ソースコードを書くのは、絵画を描くのと非常に似ています。僕自身もそうですが、新しいものを創ることだけでなく、良いコード、簡潔でわかりやすいコードをデザインすることに魅力を感じます。本文中には以下のように書かれています：

ハッカーと画家に共通することは、どちらもものを創る人間だということだ。作曲家や建築家や作家と同じように、ハッカーと画家がやろうとしているのは、良いものを創るということだ。良いものを創ろうとする過程で新しいテクニックを発見することがあり、それはそれで良いことだが、いわゆる研究活動とはちょっと違う。

コードをデザインする能力が、画家の画力と同じように、良いプログラマたる条件でしょう。良いデザインを考えることはかなり高度な知的活動になります。ただ、ビジネスモデルの中で、プログラマが良いデザインをすることと売れることが直接結びつくケースは少なく、プログラマが労働過多になるのは、以下のような事情によるものかと推察します：

Yahooに入ってみたら、彼らにとってハックするということはソフトウェアを実装するということで、デザインするということではないということがわかった。プログラマは、プロダクトマネージャのビジョンとかいったものをコードへと翻訳する技師とみなされていたのだ。

究極のプログラミング - コンパイラを作る-　コードをデザインする時間・許可が与えられない場合、たとえば、コンパイラを作る、なんてことは到底認められないでしょう。けれど、コードを書くというのは、人が考えていることを機械が実行できるようにすること。この意味から考えると、究極のプログラミングはコンパイラを作ることにあります（お絵かきソフトなど人の入力を画像データにするのも、ある意味コンパイラですね）。簡単な記述で、素敵な仕事をしてくれるのがコンパイラです。コンパイラを作る時間、そのために必要な技術を習得するコストが大きいので、通常は、他人が作った言語やフレームワークを使ってコードを書いているだけです。

Webアプリケーションのように、どのOS、どのブラウザでも動くコードを書くのは大変です（主にIEが他とケンカしてしまう悪い子なので…）。だから、その作業を軽減するために、Google Web ToolkitではJava言語からJavascriptコードを生成するコンパイラを作るという、とても良い仕事をしてくれました。けれど、コンパイラを作るのだって、そんなに大変なわけじゃないですよ？以下は、Joel on Softwareより引用：

Most people don't realize that writing a compiler like this is only about 2 months work for one talented person who read the Dragon book. Since the compiler only has one body of code to compile, it is much easier to write. It doesn't have to be a general-purpose compiler. It doesn't have a math library, for example.　（多くの人が、コンパイラを書くのはドラゴンブックを読んだ優秀な人が2ヶ月くらいでやる仕事だってことをわかってない。コンパイラには、コンパイルするコードしかないので書くのは簡単だし、一般的なコンパイラなんて書く必要はないんだ。数学ライブラリなんてものもいらない。）

ドラゴンブックはコンパイラの教科書としてとても有名ですが、隅から隅まで読む必要はなくて、字句解析、構文解析の概要を知って、Lex/Yacc/Bison, ANTLR、JavaCCなどどれか1つのツールの使い方を学べば、コンパイラはすぐにでも作り始めることができます。

開発するプログラムが同程度のものなら、フレームワークなり、コンパイラがあるだけで相当仕事が短縮されるはずです。ここで負荷が減らないなら、コンパイラで仕事が簡単になったから、あれこれ追加機能を実装しようと欲張るなど、開発すべき仕事が単純に増えているのでしょう。逆に、コンパイルコマンド１つで製品ができても、それを1分、1秒の時間単価や人月で見積もられてはいけないのだと思います。

プログラミング＋αの時代　 インターフェースのデザインなどは、上記の「ハッカーと画家」の例のような比較とは違って、本当に「画家」とか「デザイナー」の能力を要する分野に踏み込んでいるので、プログラマの仕事としては過負荷になっているのだと思います。

僕は、デザインすることは昔から好きだし、コミック、油絵とかも良く描いていたので、ウェブデザインをするのは時間はかかって大変なことだけれど、楽しい部分として受け入れることができます。まだまだ未熟だけれど、デザイン＋コーディングの両方できるというのは僕自身の専売特許だと思います。データベースが専門でシステムを作れるというのも、プログラマとして持っている僕の付加価値です。プログラマは、コードをデザインするだけでなく、＋α（アルファ）の部分で、自身のブランドを作れる存在だと僕は思っています。売れないブランドだって当然でてくるわけで、オープンソースのApacheブランドだって、よくよく見てみるといいコードばかりではありません。

プログラムをデザインする能力を習得した上で表現すべき「＋α」の部分が、まだまだ未開拓のように感じています。コンピュータ専攻の人だけでなく、もっといろいろな人にプログラムを学んで欲しいと思うのです。自分の魅力である「＋α」をアピールするためにプログラムを作ってみる、知識が足りなければプログラミングを学ぶ、この繰り返しをするのがレベルアップへの近道でしょう。

プログラムやコンパイラを作るというのは大変なことですが、「魅力的なものを創る」ためには欠かせないことです。コンピュータ、インターネット内だけの話ではなくて、コンピューターでデザインして、現実の作品を作るなんてこともできます。せっかくプログラミングという応用分野が広く、すばらしい技術を学んだのに、人に言われたものだけ黙々と作るというのでは、面白くないのは当然。

プログラマが「＋α」を作るという意味で、作ったものが売れないことがあるのも、飛ぶように売れる（有名になる）ことがあるのも、作家や画家と似たものを感じます。それはプログラマという職そのものの性質ではなくて、ビジネスとしてブランドの宣伝であったり、市場があるかどうかなど問題だと感じます。プログラマも、作りたいものだけを作る、と小説家や芸術家くらいわがままであってもいいと思います（これは偏見ですが）。わがままを通して「食える」ようになるというのは、プログラマに限らずまたどこか別の次元の話です。

プログラマとして生きるということ　プログラマとして生きていくというのは、ビジネスを含めて、自身のブランドとして独立する覚悟が必要ですし、そうしない道を選ぶなら、他で生活の糧を得る必要があります。これは、プログラマとして能力が劣ることを意味するわけでも、恥ずかしいことでもありません。Googleだって広告収入が安定しているからこそ、Google Web Toolkitなどの開発に注力できているのです。

開発をしていて労働過多で見合った収入が得られていないと感じたときに、「プログラマだから」と結びつけるのは、誤った思い込みであるように思います。「プログラマ」とはそんなひとくくりにできるような言葉ではありません。「プログラマ」は好きなものを思いのままに作れる夢のような職業である一方、製造・出版業のような既存のレールがない分、ものをつくる職業として確立できていない難しさもあるでしょう。

けれど、そんな時代の荒波を生きていくのが「プログラマ」です。数年で技術が変わり、新しいツールも次々に出てくる。そんな中、目指すものを創るために、自ら学ぶことを止めず、成長し続ける人が、真の「プログラマ」と呼ばれるべきです。3年前にも同様のことを書きましたが、プログラマやハッカーという言葉に対するこの思いは今でも変わっていません。

良い論文を書くために知っておくべき５つのこと

英語で科学技術論文を書くための書籍はいくつか出版されていますが、大抵、日本語と英語の表現やロジックの違いの説明が主で、「論文」というよりは「英語」の学習と質的に変わりません。ここでは、「論文」をいかに書くか、さらには「論文」を書くために「研究」をいかに進めるかという点に踏み込んだ内容を紹介していきます。

まず、コンピューター系の論文の書き方のHow toを示した書き物として、DB分野で有名なJennifer Widomの以下の記事が、良い指針となります:

• Tips for Writing Technical Papers (Jennifer Widom)

この中から、introduction (導入部）で説明すべきことについて引用しました。

• What is the problem? (解いている問題は何?）
  
• Why is it interesting and important? (なぜその問題が面白くて重要なの？)
• Why is it hard? (その問題のどこが難しいの？ 簡単な方法で解けないの？）
• Why hasn't it been solved before? (なぜ今まで解かれてなかったの？)
• What are the key components of your approach and results? (あなたの仕事のどこが重要なの？）

１. Abstract, Introductionが９割を語る

論文査読では、自分と同じ専門分野の人に巡り会えることは稀です。むしろ専門外の人に読まれるのが通常で、あうんの呼吸で問題が伝わる、なんて信じることに意味はありません。皆がコンピューターに触れるようになって、コンピューターサイエンスの分野も相当広がってきました。それに伴い、論文と同じ研究テーマに洞察の深い専門家に当たる確率も相当低くなっています。XMLの論文だからXMLに興味がある人向けに書く、ではなく、コンピューターサイエンスをかじった程度の人でも、abstractを読んで「XMLにはそういう性質があるのか、なるほど。面白そう！」と思えるように説明するのが大切です。上に挙げた５つの項目がintroductionで綺麗に説明されていない論文は、僕が査読した論文や、自分が過去に書いた論文も含めて、十中八九、いい論文（つまり読みやすい論文）にはなっていません。introduction以降の文章はろくに読まれないか、書いた本人の意図やアイデアがうまく伝わらず、見当違いの評価が返ってくるのが落ちでしょう。

2. コードを練るより先に、伝えるべきことがある

コンピューターサイエンスの分野においては、良いものを作るのはもちろん大事なのですが、そこから「良い論文を書く」までの間には相当な壁があります。日本では、この「良い論文を書ける」域に達している人が、欧米、さらにアジア圏内で見ても、圧倒的に不足しています。DB分野では既にシンガポールの方が論文を書く力は日本より優れているようです。技術的には、日本人でも、アルファギークと呼ばれるプログラマが多くいたり、未踏ソフトウェアでスーパープログラマと認定される優秀な人がいますが、必ずしも彼らが研究の世界でプレゼンス（存在感）を発揮しているわけではありません。(DBLPから氏名を検索すると活躍の度合いがわかると思います）

この壁の正体は何か？ コードを書ける人が陥りがちなのが、文書よりもコードを改善してしまうという罠です。作りあげたコードには、いろいろなノウハウや、論文に書ききれないくらいたくさんの最適化のための改良が施されていることでしょう。うまくいけば、決して他の人には作れないユニークなものが出来上がります。でも、ちょっと待って！論文は人に技術、アイデアを伝えるために書くもの。そんな人が真似できないものを作ってどうするの？

システムが複雑で、性能評価にいろんな要素が入ってくるほど、他の人が利用できない（つまり後続が現れない）研究になります。オープンソースの世界と同じで、研究の世界でも、人に面白い問題、アイデアを提起してあげると、あとは周りが勝手に問題を読み取って、後続研究が広がります。そんな動きを触発するには、コードを練るのと同じか、あるいはそれ以上に文章を練ることが大切です。アイデアを一番伝えられるのは、何よりもまず文章です。

３. 良い文章とは、悪い文章を書き直したものだ

最初から良い文章を書くことの難しさは、物書きなら誰もが直面する課題ではないでしょうか。良い文章がすらすらでてくる人が天才なら、そうでない自分は物書きには向いていない。そのような思考に陥りがちだった僕を十二分に救ってくれたのがこのフレーズです。

引用元のGood Writing by Marc H. Raibert には、文章を書くテクニックというよりは、書くために必要な心構えが記されています。kunishi先生のブログでも紹介されていますが、そもそもRaibertの文章そのものが、"Good writing is a bad writing that was rewritten (良い文章とは悪い文章を書き直したものだ)"の実例となっているのですね。

４. 書いた文に振り回されるくらいなら、思い切って捨てなさい

これも上のRaibertの記事から。文章を書いていると、とても良い文が書けたと思うことがあります。ただ、書き進めていくうちに、その文が周囲の文章と合わなくなったり、伝えたいことと内容が離れてしまうことがあります。でも、せっかく書いた名文は生かしたいというのが人情。

そんな文章の断片があちらこちらにでてくると、頭の中では文章という複雑なパズルのピースを組み合わせる作業が始まってしまいます。文章のニュアンスであり、既に説明した情報であり、いろんな要素を頭の中で組み合わせて文章を書くことになります。プログラムを組み立てるときも似たようなことが起こりますが、文の与える印象の方がより抽象的な部品なので、相当難しいパズルを解くことになります。

そういうトラップにはまったなと感じたら、その名文の部分を思い切って捨てます。さすがに、ただ消し去るというのでは忍びないので、PRIZE_WINNING_STUFF.txt （これは賞を獲れる！）というファイルに貼付けて保存して置きます。パズルのピースが減って、伝えたいことに絞って文章を書くだけでよくなるので、驚くほどの効果があります。必要なら、あとで「賞を獲れる名文」を戻してもいいでしょうが、僕自身の経験で、ここから復活したフレーズはありません…。　

PRIZE_WINNING_STUFF.txtは、最終的にほとんど役に立たないにも関わらず、論文を書くときにこれほど役に立つ道具はありません。

5. 良い研究でもシンプルなアイデアでできている

難しい研究に見えても、根本的にはシンプルなアイデアでできていることがほとんどです。論文の格を上げるために、式の定義を小難しく見せる必要はありません。問題解決のアプローチがシンプルであっても構いません。問題を解くことで分野の研究を一歩進める、そしてその成果をわかりやすく伝えることが何よりも大事です。

これを説明するのには教科書が良い例だと思います。教科書というのは、その分野をよく理解した人が、技術の内容を噛み砕いて、わかりやすく説明したものです。その最たる例として、DB分野には、現在のトランザクション管理には欠かせない技術であるARIES (WAL: Write-ahead logging)の論文があります。この論文は、分量も多くDBをよく知っている人でも読みこなすのは大変なのですが、教科書になると１ページで、アイデア自体もとても平易にまとめられる内容です。教科書というのは、元は論文であった知識を短く、かつ、技術を再現するのに十分な情報を持っている文章です。簡単だからといって、重要でないわけではありません。

では、噛み砕けばシンプルなアイデアをいかに論文として仕上げるか？ 重要なのは、シンプルなアイデアを素直に説明できる力にあると考えます。

先ほども述べましたが、日本ではプログラミング能力はあるけど、PhDをまだ取っていない（あるいは取る意思のない）若手が注目を集める一方、グーグルでは、PhDを取得した人を積極的に採用しています。プログラムの力量という意味ではPhD自体は意味を持ちませんが、PhDが示すのは、論文を読んで最新技術の詳細を理解でき、その上で、「新しいものを作り上げる力」を持っているという証です。過去を知らずして「新しいもの」は説明できないし、意図的に「新しいもの」の開発もできないでしょう。「新しい」は常に過去の技術との比較です。過去の論文で、問題がどのように定式化されているかを知っていることも、アイデアを簡単に伝えるためには必要です。

また、アイデアやアプローチがシンプルであっても、対象としている問題が重要で、解くこと、調べることに価値があれば、それは立派に「研究」として成立します。そして、この対象とする問題の重要性を考えることが、冒頭に挙げたintroductionに書くべきこと（問題設定、なぜ重要か、問題の難しさ、過去の研究との比較）に反映されていきますし、introductionを書いたときに、不足している実験が見えてくることもあります。このサイクルが研究の進める上で非常に大切です。

ACMのSIGに代表されるコンピュータ系のトップ会議に論文を通すためには、五十嵐先生の記事にあるように、もう少し努力や工夫が必要なようです。喜連川先生もインタビュー記事で語っていますが、そのようなトップの国際会議では３回くらいrejectされるのは当たり前で、落とされたからといって、がっかりしすぎてもいけないようです。さらに、いい研究ならば２番手の会議はスキップして、トップの会議に出すまで１年くらいsubmitを控える（！）なんてこともあるようです。

最後に、大前提として再びGood Writing by Marc H. Raibert から。

良い論文を書こうと思うこと、そして、書けると信じること

これがなくては、先に進めません。書く力は年をとっても伸び続けると聞きます。あきらめないことが肝心です。

結婚

友人の結婚式に参列しました。

自分以外の結婚式に参加するのは初めてでしたが、料理も美味しいし、それぞれの催しに新郎新婦の思いがこもっていて、本当にいい結婚式でした。

こちらがお祝いするのはもちろんなのだけど、それ以上に向こうから幸せをたくさんもらったように思います。結婚式って、こんなにいいものなんだと実感。妻を大事にする気持ちの大切さを再認識させられました。

前日まで、スピーチを考えて練習したり（本番は、インタビュー形式で、司会の人が助けてくれたので拍子抜けしましたが。。。）着ていくものを準備したり、子供がいるので、買い物に行く時間がなかなかとれなくて、かなりばたばたしていたけれど、間に合ってよかった。


披露宴では、スクエアの懐かしい曲！（Sweet Sorrow）に乗せて、新郎が自分で作成したという、写真のスライドショー。自分も一緒に移っているサークルのコンサートの時の写真を乗せてくれて昔を思い出せました。

彼自身もピアノを披露してくれました。いつの間に！と驚くとともに、何故か負けないぞ！という気分にもさせられたり。何を競ってるんだかわからないけれど(笑）環境が変わるにつれて、エレクトーンも昔のようには弾かなくなってしまっているので、再開するにはいい刺激になりました。

結婚式、自分ももう一度したいな！と思わされたけれど、一度だからこそ思いを注げるし、いいものになるんですよね。昔の友人にも再会して話も弾んだし、至福のひとときでした。

大学の若手研究者ができる４つのこと・実践編

情報関連の研究では、日本は欧米を中心としたコミュニティから取り残されています。このことは、ここ数年のTop Conference/Journalでの日本のpresence（存在感）をみるだけでもよくわかります。この状態を危惧して、tatemuraさんが「大学の若手研究者ができること」と題して以下の4つを提言しています。

（１）英語のレジュメを書いてみる（書かせてみる）
（２）日本語論文を書かない（書かせない）
（３）無駄な学会を退会する
（４）官僚との付き合いを減らす

「日本語論文を書かない」という点については、僕自身、既に6年実践しています。そもそも、東京大学 の情報科学科というところ（大学院ではComputer Scienceという名称）は、学部の卒業論文から英語で書かせる伝統があって、英語で論文を書くということは、研究をする上でのボトムラインという感覚が染み付いています。この意味では、「英語で書かせる」というのは、教育的にはいい方法だと思います。

東大生と言えど、皆が英語が流暢なわけでも、英文を書き慣れているわけでもないので、最初に出来上がってくる文章はひどいものですが、経験を積んでいくと、だんだんいい文章が書けるようになってくるようです。ここで苦労している時点で既に、英語圏で普通に研究をしている人たちに差をつけられているので、日本語で書く暇があったら、日頃から英語で書く練習をしないと、ますます差がついてしまいます。

tatemuraさんも言っていますが、日本人の頭脳や技術力が必ずしも劣っているとは、僕も思えません。（とある先生に同じ話をしたところ、向こうの研究者はもっと賢いんだよ、と言われましたが（汗））。それはともかく、新しい技術や、自ら開拓した研究分野を、「英語」で「わかりやすく」伝える技術を併せ持った人が、日本にどれだけいるのでしょうか？ という話です。SIGMOD, VLDBのようなデータベースのtop conferenceに通すためには、英語のnativeと言えども、数ヶ月を書けて論文を、個々のフレーズに至るまで吟味するそうです。ミーティングで文章を議論して、２時間でようやく1パラグラフ進んだという話も聞きます。僕としても、「日本語で書かない」を実践した、というよりはもっと単純な理由で、「日本語でまで論文を書く余裕がない」というのが本音です。

研究者として、一番面白くないことは、自分の仕事（論文）に対して何も反応がないことだと思っています。ブログを書く動機だったり、絵や音楽などの作品を作る情熱だって、何らかの反応を求めてるから生まれてくるものだと思います。ビジネスだったら、売れる、ということ。だから、たとえ論文が採録されたとしても、Reviewerの反応が素っ気なかったり、後続研究が出なかったら（つまり売れなかったら）がっかりするものです。（ブログに関しては、直接のコメント等がなくても、のちのち、いろいろなキーワードで検索されていることを知ると楽しいものですが）

日本語でわかりやすく研究を伝えるのも大事な仕事ですが、それはどう頑張っても日本の閉じたコミュニティでしか売れないことを覚悟しないといけません。読む側の立場から見ても、SIGMOD, VLDBの文献を追うだけでもかなりの労力を要するので、英語論文に決して引用できない日本語文献は、必然的に読まなくなっていきます。国際的に影響力のある人が、日本語で発表できているなら、世界の風が日本にも流れてきて良いのだと思いますが、現在のようにそのルートが閉ざされてくると、コミュニティは国内に閉じる一方なんだと思います。

ただ、研究者を目指す人にとって、日本における博士課程までの学生生活というのは必ずしも、経済的に恵まれたものではありません。比較的、財政的に豊かな東京大学ですら、博士課程の学生の授業料を全員免除するには至っていませんし、アルバイトをしながら、PhDや、職を得るために、通しやすい日本語で論文を書いている、という事情もあると思います。学生という理由だけで、保育園へ子供を入れる優先順位が他の人より下げられてしまうなど、社会全体として、世界最先端の研究者を育てる風潮がないのも確かだと思います。高校生までの教育問題は報道等で好き勝手に論じても、大学以降の、特に情報系の現在のようなpresenceの低い状態や、学生の待遇については、世間で議論されている様子はちっとも伺えません。

「無駄な学会を退会する」 は、まだ学会のPCを依頼されるような、一人前の研究者にはなっていないので、そういう身分になってから考えます。ただ、Fellowならまだしも、ただ の学会の会員というのには、どんな価値があるのかよくわからない、というのがあるので、メーリングリストを読む以上の会員にはなっていません。

「官僚との付き合いを減らす」というのも、まだ、どうコメントしていいかよくわからないところです。日本の劣勢を覆す土台となる学生の研究生活の改善のためには、社会的地位の低い学生として博士を取得する苦労を知っている人が、官僚となって働いている方が都合が良いと思うことが多々あるからです。むしろ、現状を鑑みる限り、もっと学者が参政しないといけないと感じています。

最後に、「英語のレジュメを書いてみる」という点。これが実践できていないことが、ここのところ心残りだったので、今日、自分のCurriculum Vitae (CV：履歴書)を書いてみました。海外の若手研究者と比べると寂しい限りですが（tatemuraさんの記事は、この寂しさを認識させたいという意図でしょう）、このCVを充実させ、常に世界に向けて情報を発信していくことを念頭に努力していきたいと思います。

上手なプレゼンテーションとは

今学期は、久々に大学の講義に参加してみています。

講義の形態は、学生が毎回発表するというもの。
修士1年の学生さんが多いせいか、覇気が足りない。。。

課題を与えられたら、与えられた文献しか読んでこない人とか、それすら読みこなせていないというのがちらほら。自分が発表したときは資料探しから始まって、何百ページもある資料にいくつも目を通して、基本を学んで、実験評価もして、と相当時間を費やして望んだのに、他の人からそれくらいの気概が感じられなくて、悲しい限り。（東大生なんだから1週間もあれば英語で100ページくらい読んできてよ！ というのが本音）

もちろん、プレゼンテーション技術が未熟なこともあるのだけれど、それ以前に、一つのトピックをわかりやすく紹介するには、そのトピックだけでなくて、トピックを含むもっと広い分野の知識が必要という認識がまだない様子。

それだから、プレゼンを聞いていると、この研究はなぜ重要なのか？ という視点を欠いたまま（発表している本人も理解していない様子で）発表を続けられてしまうので、聞いている方は、すぐ迷子になってしまいます。

問題は、発表する側の視野が局所的なこと。いくら研究の子細を丁寧に伝えたとしても、それだけでは、他にもっといい方法があるのでは？ と疑問に思ってしまうし、様々な研究の流れの中で、いま発表している内容はどういう位置づけにあるものなのか、ということもわからない。そのような大局的な視点がないプレゼンテーションは、同じ問題意識をもった人たち（例えば研究室の仲間とか）にしか価値がありません。

大局的な視点を身につけるには、たくさん学ぶこと。これに尽きます。よく書かれた論文や教科書は、そのような大局的な知識を効率よく与えてくれます。既に学んでいる人から、そのような知見を引き出せると、次のステップへ進む重要な足がかりとなのですが、どうも数ある授業の課題の１つとしか捉えていない発表者から、そのような知見を得ることは難しいようです。

自信を持って発表できないのは、やはり勉強が不足していることが一番の原因。すべてを完全に理解している必要はありませんが、少なくとも、何がわかっていて、何がわかっていないかを理解することは必要。そのレベルまで達している人とそうでない人とでは、自ずとプレゼンテーションの出来も変わってくるものです。

Windows Vistaはすごい

上記リンクの記事を読んでみて、Windows VistaってXPと比べて確実に進化してる～というのを感じました。スタンバイからの復帰が2秒というのは驚き。期待のMeiryoフォントはあまり文字を並べたときのバランスがよくないような気もしますが、MSゴシックよりは綺麗。

Windows Meeting Spaceって、NetMeetingの改良版かな？ 動作が綺麗になっているといいんだけど。
ファイルも共有できるようだから、pair programmingなんてのも簡単になりそう。

ファイルのヴァージョン管理もなされる模様。ファイルを上書きしても、以前の状態が復元できるという機能。まぁ、使用頻度は低いのだけれど、これがあるのとないのでは、作業するときの安心感が違います。

公式ページを覗いてみたら、USBメモリとかを増設メモリとして使えるんだって。今、フラッシュメモリは1GB、1万以下くらいの相場だから、これはありがたい話。フラッシュメモリは、HDDと比較すると、ヘッドを動かすシークタイムが無い上、データが連続に並んでいなくても読み込み速度は一定（だと思うのだけれど）だから、スワップ領域（Windowsでは仮想メモリ）へのデータ退避が相当高速になる。これはすごいことで、だって、メモリ容量ぎりぎりでアプリケーション開くと、動作が途端に重くなるとか、経験したことあるよね？ そういうのが、USBメモリを指すだけで回避できるようになるの。

すごいよ、Vista。（まぁ、それぞれの機能のできが良くなくてこける危険性はあるけど）。Web2.0といって、Webアプリケーション（Googleなど） V.S. デスクトップアプリケーション（MS)の構図を主張している人がいっぱいいるけど、ちっぽけなものです。やっぱりOS作れるところが俄然強い。

OSを作るというのはすごい仕事なのです。MacがIntel Core Duoを搭載したとかで喜んでいるのなんて、小さい小さい。一般の人がやれWindowsだ、これMacだとか評価するときって、十中八九見た目の話なの。Macの方が見た目がいい、Windowsはダサい、みたいな。それはそうなんだけど（笑）、OSとしてどっちができがいいかというと、どう考えてもWindowsに軍配があがる。画像描画の速さとか、安定性とかね(昔のWindowsはひどかったけど）。AppleのSteve JobsはMac用の魅力的なアプリケーションは紹介するけど、それってOSの機能じゃないの。iLifeとかiPodとか。

ここから先はOSを作るようなプログラマについての話。ちょっと難しめかも。

今週の週刊ダイヤモンドは、職業別給料比較でした。その中に、「プログラマは単純作業だから、30代までにシステムエンジニアに転機を計らないと先がない」みたいなことが書いてありました。僕はこれに断然反対。Webアプリケーション開発ならいざしらず、OSのように土台に近いシステムを作るとか、innovationになるようなソフトウェアを書くのって、単純作業なんかじゃないんだよ。ハードウェアの知識はいるし、OSの仕組みも知らないで、効率のよいプログラムなんて書けっこない。コーディングの上でオブジェクト指向（デザインパターンとか）やプログラミングスタイル、XP(eXtreme Programming)なんて宗教論争が盛んな方法論もあるけど、それらは所詮方法論。画家でいうなら、絵の具の使い方のようなもの。

本当のプログラマーっていうのは芸術家です。使ってみて初めて便利さがわかるようなプログラムを作る仕事。きっとこの記事を書いた人は、コンピュータにもうわかりきった仕事を反復してやらせるためのプログラムを書く仕事がプログラマーだ、という認識なんだろうな。 しかも去年もまったく同じ記述を見ました（涙）。週刊ダイヤモンドは記事の使い回しが多いようです。言われた通りの絵とか文章しかかかない芸術家なんて、付加価値を生むものは作れないでしょ。それだけのこと。

まぁ、世の中一般のプログラマの仕事というのはそういう単純なもの、ということを言っているだけなのかもしれない。確かに、技術的にみたら、Joelさんも話題にしていたけれど、コンパイラを作れるプログラマが世の中にどれだけいるかというと、僕は、東大でも、情報科学科のコースで学んだ人以外には思い浮かばないです。本1冊程度の知識でできることだけれど、わりと皆やろうとしない。コンパイラってC++とかJavaのとか、難しいものを想像するかもしれないけれど、要するに人間の入力を受け取って、プログラムにしたりデータにしたり、コンピュータがわかる形に変換するだけのもの。

コンパイラが自分で作れるようになると、楽しいですよ～。GoogleのWeb Toolkitなんてのもその例。SQLのように、データベースを操作する言語なんてのも自分で作れます。 standardがあるときに、そういう新しい言語を作るなんてことはしなくてもいいのですが、目的にあったものがないときに、新しいものを生み出す力があると、随分可能性が広がります。僕が自分で開発しているデータベースシステムだって新しい言語が必要だし、rubyなんてプログラミング言語も、プログラムを簡単に書きたいっていうニーズから生まれたもの。で、そう思った人にコンパイラを書く力があったという、その組み合わせが重要。


ここから先はデータベース屋さんとしてフラッシュメモリなどについて思うことなので、興味ない人は飛ばして。

フラッシュメモリがもっと大容量化すると、データベースでいうclustered indexが重要でなくなってくる。メモリに比べると速度が劣ることは変わらないから、ページ単位の読み書きという概念までは無くならないのだろうけれど。 でも、この変化は重要。 PostgreSQLみたいに、ヒープにデータを追記していって、データをディスク上でソートしてないようなへぼな構造でも（vacuumしないと性能がでないやつ）、性能には関係ないってことだから。 ディスク上（ここでいうのは、フラッシュメモリ上）でデータが分散して配置されていようと、連続して配置されていようと読み出し速度が変わらないということは、追記型のデータベースの利用価値も高まります。すごい。HDDに縛られていたデータベース界からのパラダイムシフトが間近。

[NHK知るを楽しむ] 予測できるはずの失敗

NHK「知るを楽しむ・失敗学」の第3回目です。今回のテーマは、「予測できるはずの失敗」

ベビーカーが電車のドアに挟まって引きずられてしまう。閉まろうとする防火シャッターの下をくぐろうとして挟まってしまう子供。プールの排水溝に吸い込まれてしまう。

人のように大きいものが挟まる場合は、当然、探知できるようになっています。でも、ベビーカーの前輪の軸の細い部分だけが挟まると、センサーが探知できずに引きずられる。 防火シャッターはゆっくり下がるので、手で止められると思いがちだけど、実は、シャッターはとても重く、一度下がりだしたら止める手段がないということ。プールの排水溝は、人がいないところで水を排出しなければいけないことを失念していたこと。それが、排水溝の蓋を管理しないという実態、事故につながったという事実。

どれも、知っているべきことを知らない、ということが招く事故。駆け込み乗車をしないとか、排水溝で遊ばないとか、ルールとしては知っているはず。でも、それがどうしてかという部分に、考えが回らない状況が生まれるようです。

僕が自動車免許を取るときに感じたことなのですが、交通ルールの持つ意味などは、小学生のうちからでも教えた方がいい。「止まれ」と書いてある道路や標識は何を意味しているか。死角から車が出てくる場所なんですよね。

あれをしちゃだめ、これをしちゃだめ、と頭ごなしに禁じることは簡単だけれど、本来なら「どうしてそういうルールがあるのか」という知識の共有をはからないと、ルールを定める目的、すなわち、個々を守るという機能が、十分に働かないことがあるといういい例。（直接的には関係ないけど、東京都教育委員会が君が代を強制したり、反抗したりというのは、知識の共有化が図られていないいい例でしょうね。靖国参拝の是非とかも。）


もうひとつ、驚きがあったのは、中越地震の時の上越新幹線の脱線事故について。メディアの報道では新幹線の安全神話が崩れたという見出しが多かったようですが、あれは事故というより、大惨事を事前の対策により防げた珍しい成功例だということ。死者・怪我人０人というのは、偶然や奇跡だけがもたらした結果ではなかったようです。そういう趣旨でネットを調べると、なんとも心あたたまるお話も見つかりました。


けれど、うまくやればこのように効果的なのに「予測できるはずの失敗」を防ぐというのは、なんと難しいことか、とも同時に思います。それは、人は怠惰で流されやすい生き物だから。日々の生活や、あのときああしておけば良かったという後悔なんて、往々にして予測できるものです。ただ、先のことについてあれこれ予測することは億劫なものです。それでも、失敗をしつつも、先を考えすぎずに生きていく楽観さ加減が、良い方向につながることもあります。

NHK知るを楽しむより： 失敗学

NHK知るを楽しむ NHK教育テレビ 月～木曜日 午後10:25～10:50を見ました。

六本木ヒルズの回転ドアで子供が挟まれて死ぬという事件以来、回転ドアは危険なものという認識を持っていたのですが、そもそもヨーロッパなどでは回転ドアは軽く作られていて、挟まれたとしても大事故に至らないという 「本質安全」性が満たされているそうです。

回転ドアは軽く作らないと危ない、という職人さんが持つ知識はあったようです。ただ、日本に輸入され、見た目をよくするために回転ドアに装飾を加えていくうちに、ドアは3倍以上の重量になっていたそうです。重くなるほど完全静止までの距離も長くなってしまうのを、センサーを増やすことで、安全性を確保しようという「制御安全」の方針がとられました。

結果として、センサーが探知できない部分があったり、人が挟まるのを探知してからドアが静止するまでの距離が設計者の想定以上のものとなり、事故につながりました。

この「失敗」を教訓に、「本質安全」を持った上で、多重に「制御安全」のセンサーを使った回転ドアが開発されているようです。「失敗学」というのも、失敗の経験をいかに活用するか、また、失敗を活かすためにはどのように失敗の知識を蓄積しなければならないかを追求する学問だとか。


試行錯誤という言葉があるように、日常の中でも膨大な数の失敗をしています。その失敗は経験として個人には蓄積されていきますが、それを他と共有すること、情報学の立場ならデータとして表現し人に伝えるという作業は、仕事の効率化や質を高めるという意味で、どの分野においても役に立つでしょう。 とりあえず失敗をとりかかりとしているけれども、この応用分野はもっと広いものだと思います。

野球選手なら、バッティングのときの体の感覚がそう。イチローがテレビで言っていたけれど、自分が良いと思うバッティングの感覚があるけれど、言葉にするのが難しいので、ここを守っていれば大丈夫、というポイントを探す努力をしているそうです。それでも、気づかないうちに理想とずれていくことがあるとか。失敗と正確に分類できない情報もありそうです。

データベース屋さんにとっては、これは永遠のテーマですね。人の知識をデータにする。その収集方法から情報のプレゼンテーションを自動化する方法まで、興味は尽きません。

World Cup

仕事をしたり、プログラミングをしながら横目で眺めていました。

それほどサッカー好きではないので、前回のWorld Cupの時に目立っていた宮本とか久保とか、欧州に行ってテレビによく出てくる選手しか知りません。

運よく先取点をとって、がんばっているなぁと関心していたところ、
後半目を離した隙に、あっという間に3点。
明日は日本中がイライラしているか落胆しているのだろうなぁ、と。

# mixiでは、早くも日記で怒りをぶつけている人がいて辟易してしまいましたが。ああいう場所で失態を演じると、即座に非国民扱い。恐ろしい

昔はサッカーをよくやっていたので、45分だけでも体力的に厳しいことは知っています。映像だけだとわからないけど、かなり炎天下だったとか。頑張りすぎてしまうと、熱中症にもなるでしょうし、精神的にも張り詰めていないととても45分＆45分は持ちません。

それを踏まえて、90分を戦い抜く体力の温存の仕方とか、相手に走らせる戦略を取っていることは十分伺えて、日本のプロのレベルの高さに関心していました。

ただ、ディフェンスでは、壁を厚くし、十分な人数がいるにもかかわらず、縦に突破されることが多かったのが気になっていました。中盤では敢えて仕掛けずに、厚いディフェンスでボールを拾う狙いだったのでしょうか。あまり、見たことがない陣形だったけど、少なくとも失点するまでは機能していたようだし、そういうものなのかなぁ、と。

実際、その厚いけれど強引な突破に弱いディフェンスを突かれて失敗したようですが、あの世界最高の舞台という環境、残り時間わずかのところで追いつかれたというショックは、如何ほどかと。最初に1点取られていた方がましだったのではないかと思えるほどの衝撃です。

以前にサッカーの試合をフルに見たのは、2002年のW杯だったりするので、そのときの日本の細かなパスワークでボールを進める戦術が印象的でした。今回は、安易にボールを相手に渡してしまうことが多いような気がしています。ゴールキックとか、相手に背が高い選手が多いのに、そんなに高いボール上げてどうするんだろう…、とか。素朴な疑問もたくさん。

1－0という状況では「耐えればいける！」、「勝てそうだ」という心境になるのだと思いますが、そういうときに、余裕を持ってボールは保持できているけど、決め手のパスで失敗が多いとか、ディフェンスが1枚抜かれると脆い、というように、うまく機能していない部分をプレーしながら修正できるかどうかって、難しいですね。

ys: 「 理想と現実の狭間の教育基本法 」

ys: 「　理想と現実の狭間の教育基本法　」 より引用。

「愛国心ではなく、日本を愛する心の涵養としたのは、そうすれば、日本人と日本国を作りあげてきた祖先の生き方も伝統も文化文明も、全て包含される からです。聖徳太子以来の日本、大化の改新で太子の理想を具現化した日本、古事記や日本書紀に記されている日本国の足跡、そこから窺える日本人の価値観全 てを愛する心という意味で『日本を愛する心』としました」

聖徳太子、大化の改新、奈良時代に編纂された古事記と日本書紀を縦軸として貫くのはまさに旧き良き日本の価値観である。そこには、神道も仏教も含め た宗教への畏敬、天皇を戴く皇室の尊重、皇室を支えてきた男系男子による皇統の継続、善き道徳心、上も下も睦（むつ）びて和の精神を尊重することなどが、 当然含まれる。

この件で、皇室の男子系等を尊重すべきとまでいくのは拡大解釈だと思いますが、それはそれとして、民主党の教育基本法の改正案と、その意図に関してまとめてあるこの記事には一見の価値があります。


このような教育基本法のあり方だと、歴史を学ぶことの意義も見えてきます。特に、国際交流の敷居が低くなった現代人にとって、自国の歴史や価値観がどう変遷したかを学ぶことは、他国籍の人とコミュニケーションを図る上でも重要なことがらだからです。 別に戦うわけではありませんが、孫子の兵法にもあるではありませんか。「彼を知り己を知らば百戦してあやうからず」、と。

# 外交で日本が完全に負けているのは、己も他も知らないからに尽きます。

現代の日本人の心に根付くものは、古来よりの宗教であったり、武士道であったりしますが、そのような日本人の価値観・美徳を、歴史の授業を通して学べなかったことが悔いに残ります。そもそも高校までの歴史の授業がそのようなものを学ぶ場ではないとしたら、これから学べばいいだけのことですが。

今の日本を「愛せ」ではいけません。その部分だけを取り出すと軍国主義という印象がぬぐえないのです。一方、日本を愛する心を「涵養」するというのは、素敵な目標だと感じます。国を愛せるようになるためには、国を愛すべき姿に変えていくという過程も大切ですから。人々の政治や経済への関心を高めたり、公職に就く人には税金を貪る姿勢を自戒させるような精神を養わないといけません。

GyaOの苦しみの理由

【レポート】GyaOの苦しみ - 独自コンテンツの死角と活路 (MYCOMジャーナル)

GyaOの上の記事は、経済批評にありがちな、実態を見ずに、数値や与えられたデータだけから判断している記事ですね。木を見て森を見ずの逆。独自コンテンツでテレビ局に対抗しようとしているのに力量不足だという内容なのですが、コンテンツの内容として、GyaOには新旧のアニメなどが豊富であるし、面白い映画も置いてあるのでとても魅力的だと思います。独自コンテンツがなくても、過去の映像のアーカイブはこんなにも魅力的なのかと思わされるくらいです。ビデオやDVDのレンタル店にいく気分ですね。

それと同時に、ポルノ的なコンテンツも多いから、うかつにGyaOは開けないという事情はさておき、視聴し始めてわかることは、強制的に広告を見させられる時間が長いということ。広告再生中に画面も非表示にできないし、大きさも自由には変えられない（ブラウザを強制的に全画面表示にする方式は特に最低です）

今は、HDDディスクレコーダーなどで、広告をスキップしてＴＶを見られる時代です。ロケーションフリーテレビを使えば、自宅に取りためた映像をネット越しに見られるところまで来ています。コンピュータを経由して映像を見るからには、テレビを越える快適さが大事です。まず、そもそも映像的にはパソコンのディスプレイ（液晶）は、表示速度、色の補完性能に関してブラウン管のテレビにはるかに劣ります。

その質の悪さだけでも辛いのに、広告を見なくては番組が視聴できないという不便が視聴者に課せられます。時代錯誤もいいところです。テレビと同じビジネスモデルがネットの世界で通用するはずがありません。広告を番組視聴中に見せる、番組と連動させて商品ページにつなげるなどの工夫が必要です。上の記事では、安い費用で番組を制作していることを非難していますが、ここは逆にメリットになるともいえます。中小企業でも、高い広告費や、制作費を使わずに、独自コンテンツを映像という形で情報発信できる場ができているということです。

広告なしで映像を配信する有料のサービスもあるのでしょう。けれど、そこまでの誘導の仕方もスムーズではありません。無料コンテンツを見るのも苦痛であるし、誘導の下手さ加減でかなりの顧客を逃していると考えられます。無料を売りにしているのに、有料サービスを前面に出せないという事情もあるのでしょう。そもそも完全無料という謳い文句は、顧客を集めるため、知名度をあげるために見栄を切っているだけとも考えられます。

GyaOは、新しいメディアを使っているのに、何一つ新しい機能や満足感を与えてくれません。一度使ったことがある人なら、誰もが感じていることでしょう。GyaOの収益が悪い理由は、視聴者にとって不便だからという一言につきます。今のままでは広告用のメディアとしても魅力的ではありません。木を見て森を見ずという以前に、木すらも見ずに記事を書くのはいかがなものかと。MYCOMはタイムリーな情報は提供してくれるけれど、記者の質が低いからか記事が面白くないのです。

[Open Source] もはやGPLはmustの存在ではない

自分の書いたソースコードについてどのライセンスを適用すればいいか、考えが整理されてきたので、オープンソースや、フリーソフトウェアについてまとめてみることにしよう。

GNU GPLはviral（伝染する）ライセンスであるから良くない、という主張は、オープンソース開発の本質を得ていない。Emacsの開発者でもあり、GPLの生みの親でもあるStallmanがこの方法を取ったのは、プログラムをproprietary（独占、転じてclosedの意）、つまり、特定の個人や企業の所有物とされたくないという考えが大本にあって、それを実現（強制）するための手段がGPLという形になっているだけだ。

他人の書いたコードに依存しないプログラムを書くことは、膨大な労力を要するものだ。開発者の知性や時間を、真に新しいプログラムを生み出す方向に向けるためには、過去に作られたプログラム、つまり知識や道具を誰もが利用できる形にし、それらをつなぎあわせることで不必要な作業を省き、創造する力を助長してあげなくてはならない。ソースコードが企業の利益のために隠されてしまって、創造が止まってしまうことを避けたいという信念がGPLの中にはある。

ここで、非公開でもうまくいく、とMicrosoftの例を挙げるのはかなり極端な話だ。確かに彼らは、Windows用のAPIを公開して内部実装を非公開にしているが、そのclosedな実装であっても、プログラマは利益を損なうどころか、APIの恩恵を享受して、プログラミングを快適にしてもらっている。でも、勘違いしてはいけない。彼らのビジネスモデルは、WindowsというOSを売ることであり、そのためには、Windowsの価値を向上させる必要がある。価値を向上するには、Windows上で動く品質の良いソフトウェアが多く誕生しなくてはならないのだ。そのために、他人任せではなく、熱心に次々とWindowsの機能を生かすためのコードを自社開発している。ただそれだけの話だ。

でも、コンピュータという創造力を無限に引き出すようなものの前では、Microsoft一社だけでその開発をすべてまかなえるほど、人間の新しいものを生み出す知性や創造力は限られてはいないということだ。確かにMicrosoftの貢献は大きい。Officeのように優秀で安定していて実用的なアプリケーションはとても便利だ。でも、品質のいい製品をマーケティングまで考えて開発するのは時間がかかるし、それもMicrosoftが超巨大企業になったからこそできることだ。でも、カレンダーのようなWebアプリケーションなど、今すぐ使いたいものを開発する小回りの良さでは、小さなグループで開発を進めるGoogleに完全に出し抜かれてしまっている。もし、Microsoftや他の企業がソースコードのすべてを独占し、オープンソースのコードやOSが存在しなかったらGoogleが台頭することなんてできなかっただろうし、我々がWebアプリケーションの便利さを知ることすらできなかったかもしれない。

この例だけでも、GPLが世に与えた影響は大きい。けれど、GPLを自分のコードに適用しようとすると頭の痛い問題を抱えることになる。著作権保持以外は商用利用もソースコード非公開でバイナリ配布など何でもありのBSDライセンスと同様に、ソースコードの利用に関して制限の緩いApache Software License (ASL) version 2.0が適用されたプログラムであっても、GPLライセンスのコードと組み合わせた場合、ともに配布することはできなくなってしまう。それはASLには、特許に関連する訴訟を起こした場合、ライセンスに書かれている権利を失効させる条項が含まれているからだ。ASLの権利を失うということは、ASLのソフトウェアを配布できないということを意味する。

GPLはソフトウェア開発を阻害するような特許訴訟を起こした人物にさえも判決が確定するまで、ソースコードを配布する自由を守ろうとしているし、ASLは、プログラマや企業の心の平穏を保つため、そのような特許訴訟に対しての対抗策を講じている。けれど、ここや、ここの話を見る限り、両者は対決をしているわけではないし、問題点は特許に関する条項のみであるから、歩み寄りの方向に向かうのであろう。GPLのページで、GPLと他のライセンスが適用されたコードを同時に配布できるか(compatibility)について、 こと細かに述べられているが、compatibilityの問題はさほど重要でもない。要するに、いろんな独自ライセンスのproliferation(増殖）のために、GPLの親であるFree Software Foundation(FSF)が、GPLの制約の維持に苦慮しているということだ。


でも、GPLを自分のコードに適用することを考えると、そのコードを書いたことに対する自分への金銭的な見返りが何もなくなってしまうことがとても恐ろしい。GPL製品を使う企業は、製品そのもののソースコードは公開しなくてはならないから、製品そのものを売ることはできないけれどその周辺（サポートビジネスなど）で対価を得ることはできる（バザール型）という。でも、そもそも個人プログラマがそんなビジネスを一からはじめるのは、とても大変だし、かなり長い道のりだ。かといって、ASLのように、非公開でコードがどんどん拡張されて利用されることが認められる場合には、自分のプログラムが何の断りもなしに金儲けに利用されてしまうのではないかと思ってしまう。ただ、GPLと違い、ASLの場合は、自分も非公開にしてお金を稼ぐことはできる。

たとえば、データの通信ライブラリを自分が作ったとして、それを他人が利用してWeb通販などのビジネスを始めたとする。Web通販部分は、自分の作ったものとは別個のものだから、そこにまで自分の権利が及ぶと考えるのは傲慢だと純粋に感じる。もし通販部分のソースコードを公開してしまえば、通販部分の開発費を他人のために投げ捨てる事態になってしまう。データ通信部分がGPLだと、まさにこの状況になる。差別化を計れる機能を実装しても、自分自身ですら商用に利用できなくなってしまう。まぁ、著作者ならGPL以外を適用すればいいのだが、GPL製品に囲まれてしまうと、すべての著作者やcontributorをたどってGPL以外の適用を認めるように依頼しなくてはならない。開発者の意思としては、BSDライセンスのように緩いものを適用するだけでよかったとしても、コミュニティの中で開発するためにGPLを選択した例も多いはずだが、その意思を確認することはほぼ不可能だ。

GPLはGPLのコミュニティ内で活動しているとき以外は、どうも自分の手足を縛るようなものの気がしてならない。創造性を助長するというよりは、窮屈さや将来への不安を感じてしまうものなのだ。ただ、変化するソースコードを公開したままにするcopyleftというのは決して悪いアイデアではない。

そうすると、Sun MicrosystemsがOpen Soralisに適用しているCDDL (Common Development and Distribution License)というライセンスがとても魅力的になる。mozilla.orgのFirefoxなどに適用されているMPLと同様に、ソースコードはファイル単位でライセンスが付与されるなど、ライセンスの適用対象が明確。それゆえ、違うライセンスが付与されたファイルとともに配布することができる(配布物全体に影響が及ぶGPLコードとともに配布することは無理だが）。ファイルを更改して配布した人には、ソースコードの公開義務（copyleft)を課すことができる。バイナリ形式で配布するときには、違うライセンスを付けてもいい、など。

Sun関連の人のblog(これとか、これとかこれ)を読むと、CDDLができた経緯や意図がわかって、さらに面白いかもしれない。

CDDLは、MPLがmozilla.org専用のものであるのに対し、commonと銘打たれていることからわかるように、MPLを汎用化したライセンスとなっている。GPLが他のライセンスとのcompatibilityで苦労した轍を再び踏まないようにしたいのであろう。プログラマが開発中に法律的な条項の解釈で悩むのは、やはり好ましくない。

CDDLを使いつつも、GPLコミュニティの中で自分のプログラムが生きていけるようにするには、mozilla.orgと同様に、GPLとCDDLのデュアルライセンスを検討するといい。GPL単独での利用で困難なのは、開発メンバーが多岐に亘った場合に、条件の緩いライセンスへの変更の意思を確認することである。最初から、開発者にGPLとCDDLの双方の条項に同意してもらえれば、Firefoxの成功例のように、企業、個人、非営利団体の垣根を越えて、オープンソースソフトウェアとして安心して開発を続けられるものになるはずだ。

ただし、デュアルライセンスという形態では、GPLプログラムとの共存が完全ではない。一度GPLプログラムを取り込むと、デュアルライセンスという形式はとれずGPLライセンスのプログラムとなる道しか選べないからだ。 LinuxのようなGPLで固められたOS用に移植することは可能だが、そうするとGPL専用、CDDL/GPL兼用の2つのbranchができてしまうことは想像に難くない。開発者は、GPL製品を利用することはできるが、それを利用してできたコードを、CDDL/GPLのデュアルライセンスの形に戻すことはできない。

面倒な問題は山積みだが、ライセンスを考える上でのポイントは、プログラマの心の平穏と、創造性を助けるもの、開発コミュニティの形成を促すライセンスであるかどうか、だ。CDDLはOpenSoralisで多数のプロジェクトが生まれているように、企業や個人を含めた開発コミュニティを作りやすくすることを目的としている。

GPLとのcompatibilityの問題のように、ライセンスにこの不具合があるからだめだとかという議論は、概して不毛であるし、いいものを作るというソフトウェアライセンスにこめられた本当の目的からは外れてしまう。LinuxのようにGPLによって得られた産物のインパクトの大きさから、GPLに反するライセンスを安易に卑下する意見が巷でよく見られるのだが、GPLの威力は、GPLのcopyleftの性質によるものなのか、それとも、GPLの適用範囲がそれを利用するものすべてに拡大していくことによるものなのか、を区別して判断しなくてはいけない。けれど、そのどちらについても、FirefoxやEclipse、Apache Software Foundation、PostgreSQLなどの成功例によって、copyleftが必ずしも必須ではないこと、ライセンスの適用範囲を広げなくても、いいものは出来上がることが示唆されている。もしかしたら、それらはGPLによってオープンソース開発の土台ができたことによって成功した例なのかもしれない。けれど、はっきりと言えることは、もはやGPLはmustの存在ではない、ということだ。

そうすると、一個人プログラマとしての僕にとって重要な指標は、自分が自分のソースコード（とそれを利用したアプリケーション）を自由に（商用・非公開を含めて）利用でき、改良が僕の知らないところで行われないという点だ。これらを満たす選択肢としては、CDDLが今のところ最良のものとなる。GPL非依存のライブラリも増えてきたこともあり、GPL製品に頼らなくても、コードを開発する土台がある今なら、GPLへ回帰する選択肢だけは残したまま、つまりCDDL/GPLというデュアルライセンスの形態をとり、GPL非依存のライブラリやツールを構築していくというのが、今の僕の結論だ。

歩きタバコと日本のモラル

こんなところに書いても何の足しにもならないだろうけれど、一言。

「歩きタバコは不快だからやめて」

世の中には嫌煙家とか愛煙家がいるようです。でも、「タバコは健康を害する」、「いやデータが怪しい」、という応酬を見ていると不毛だと感じます。職場などで四六時中副流煙にさらされ健康リスクを負っている人以外には、健康に悪いかどうかなんてどうでもいいことです。どちらの方向に証明されたとしても、「服に匂いがつく」、「嫌悪感を覚える匂い」は解決されていないのですから。

日本のタバコの税率は6割。これは、海外では8割のとこが多く、日本はかなり安い国なのだそうです。でも、この税金、歩きタバコ抑止という目的にほとんど使っていないことは明らか。目的税として徴収してはいないし、むしろ国や地方自治体にとって貴重な財源になっているはずです。

タバコ税は健康に悪いから増税してもいいなんて安易な論調を振りかざしているから、養老孟司のような愛煙家の意見の方に説得力が出てしまいます。タバコも文化で嗜好品であるのに、不当に抑圧されている、という主張のようです。この主張を変に間に受けて、税金を払ってやっているからタバコを吸ってもいい、なんて言う人もでてきます。

「タバコは健康に悪い」=> 「増税してもいい」
という論理は、本当に「タバコは健康に悪い」かどうかを疑わせるだけで簡単に崩れます。ヘビースモーカーでも元気なおじいちゃんだっているし…。

「増税すると喫煙者（特に未成年）への抑止力になる」
いままで6割（約2兆円）も徴収していて、効果的に抑止できていないし、他国で成功したことが、日本で当てはまるとは限りません。学校の職員室が禁煙でないところなんてざらにあるでしょう。「大人だから吸ってもいい」なんて論理は通用しません。それを使うと「大人でも他人の迷惑を考えられない」という論理を導けてしまいます。

マナーの悪い人に怒るのは当然。でも、高割合の税金を徴収していながら、啓蒙活動を十分に実施していない役所のほうがおかしい。

たばこの匂いへの反応を喫煙者と非喫煙者でわけると、おそらく喫煙者の方が嗅覚が鈍感になっていて嫌悪感も薄いこと。衣類への匂いの付着なんて、すでに実証されているはずです。

何か建前があると増税しやすいのですが、なぜか国民の目の代わりの監視役として重要なメディアは、増税されて得られたものがどのように使われているかまでは着目しない。

千代田区の歩きタバコ禁止条例も、区内の通りでは一応功を奏したようですが、千代田区の境を一歩出た橋の上で喫煙を始める人がとても多いそうです。

どうして歩きタバコを禁止にしたかわかっていない人ばかり。日本は他人の迷惑を考えられないというモラルの低い国なのです。会社の中ならば、これは社内のモラルです。こういうモラルの問題こそ、首相のようなリーダーの鶴の一声で変えられるようなものだと思うのですが。。。

改革、改革と威勢のいいことはいいますが、靖国や常任理事国などの外交にしろ、財政改革にしろ、一般受けすることを前面に出しても、真の政治意図は明確にしない（あるいは持っていない）というのが小泉さんなので無理でしょうが（苦笑）

元気のもと

早起きして、きちんとご飯を食べて、研究室に行って、仕事を開始。昼が近づくにつれ、日の光が心地よくなってきました。


幸せ。


こんなごく普通のことが、元気のもと。
仕事をしたりモチベーションを維持するのに、これ以上の準備はないかも。

先の不安を吹き飛ばして、冷静に一歩一歩今やれることをやる、という気持ちになります。



実は夜更かしして睡眠不足なので、けだるさはあるのですが、それでも心が落ち着きます。

食事を取って日の光を浴びることが、こんなに大切なことだと気付かされました。