ユメのチカラ

初めてのRuby

「初めてのRuby」は、他のプログラミング言語の経験があるプログラマ向けのRuby入門書である。プログラミングの入門書ではない。この明確なターゲット読者の設定がこの本の特長であり成功の要因である。

すくなくともわたしにとって、他言語(C言語)でのプログラミング経験があるものにとって、これほどまでにコンパクトかつ明解にRubyの真髄を語っている本書ほど、ありがたいものはない。

わたしはかねてからプログラミング言語の文法書は50ページ以内であるべきだと思っている。プログラミング言語の構文はシンプルであればあるほどいい。道具はシンプルな方が応用が効く。

それはともかく、プログラミング経験者にとって、第二、第三のプログラミング言語を学習するということは、計算機の入門、例えば計算機はどう動くかとか、メインメモリ、CPU、外部記憶の機能はどうだという事を学んだり、プログラミングの入門、アルゴリズムとか、計算量、データ構造、例えば、表、ハッシュ、N分木等々について学ぶのではなくて、そのプログラミング言語の文法や意味論を、そしてそのプログラミング言語の背景にあるプラグマティズムを学ぶことである。

つまり第二第三のプログラミング言語を学ぶということは、その言語が持つ哲学、思想、あるいは開発コミュニティのお作法までも含めた何がしかを学ぶことである。例えば、Perlという奇妙なプログラミング言語を学ぶということは、CPANというPerlハッカー達がよってたかって作ったライブラリのレポジトリについての何がしかを学ぶということで、そのような事を含めて理解してはじめてPerlという言語を学んだということになる。

なぜわざわざそのようなプラグマティズムを貴重な時間コストをかけてまでプログラマが学ぼうとするのか。そこにはそのコミュニティがはぐくんでいるベストプラクティスがあって、それは言語の壁をこえた普遍性があり、それを学ぶことの意義というのは強調されても強調されすぎることはないと考えている。

「初めてのRuby」はRubyを愛してやまないYuguiさんが、Ruby初学者に向けてRubyを学ぶ道標をあたえている。

他言語を使いこなすプログラマに向けて極めてコンパクトかつ明瞭にRubyのプラグマティズムを紹介している。言語の文法書にはでてこないRubyの考えかたを紹介している。

なぜRubyではforで繰り替えしを書かないのか。C言語族に属するわたしにとってYuguiさんの説明は明瞭でかつ説得力がある。なるほどなるほど。

先日、tokyo-emacsというemacs利用者(初心者からハッカーまで)の集りで、いろいろなelispのコードをながめたのだが、そのコードのスタイルが、なにかCを感じさせるものが多く、皆で「これってCだよなあ」というような事を言っていた。関数型と呼ばれる言語(elisp)ですらCの影響を受けたプログラマが書けばCの匂いのするプログラムになってしまうのである。

プログラミング言語がノイマン型コンピュータを抽象化し動作可能なものとしたのなら、そのプログラミングパラダイムはおおかれすくなかれ似たようなものになる。変数という概念があり、メモリはアドレスというもので識別され、そこには状態を保持するので、代入という概念を持つ。手続型としてくくれるものは、ほとんど似たようなものだと言える。このプログラミングパラダイムの中で様々な文法的な選択肢を絶妙なバランスで取捨選択したのがRubyであり、その取捨選択の思想をわかりやすく説明しているのが、本書である。

プログラミング経験者が第二、第三のプログラミング言語を学ぶ意義はなにか。プログラミング言語の瑣末な文法上の差異を学ぶことが重要なわけではない。プログラミング入門的な知識を得るために行なうのではなくて、言語設計の思想、ライブラリや、それを作りあげている開発者の思い、考え、ひいてはそのプログラミング哲学について学ぶというところにある。その言語コミュニティが持つ暗黙の哲学、価値観を学ぶプロセスにある。

しかしながら、そのような暗黙の哲学、価値観は究極にはそのプログラミングコミュニティに属し当事者にならないと容易には獲得できない。

本書は、そのコミュニティの入口まで初学者を連れてきてくれる。

Ruby初心者も中級者もばりばりのRubyハッカーも本書から得られるものは大きい。初心者にとっては、Ruby言語のみならずその思想にふれられるところ、中級者にとっては、そのRubyらしさという必ずしも明確になっていなかったものに対する指針がえられるところ、ばりばりのRubyハッカーにとっては、今まで空気のように感じていたRubyらしさというものを明示的に表現するというのはどのような事かということを整理、理解するつてとして本書の意義は大きい。

Rubyコミュニティの豊かな土壌からRubyKaigi(本当に素晴しい会議だ)があり、本書のような良書が生れ、多くのrubyistを拡大再生産している。持続可能なコミュニティはその文化を明示的に外に示し新人をリクルートする。素晴しいことである。

本書はRubyコミュニティの豊かさの象徴であると言っても過言ではないと思う。皆様にお勧めする。

-------------------------------
読んでいて気がついた誤殖など。
p53
誤：a >> 1  #=> 0b100
正：a >> 1  #=> 0b110
誤：a << -1 #=> 0b100
正：a << -1 #=> 0b110

p71
誤：p story[8, 7]     #=> "Grundy"
正：p story[8, 7]     #=> "Grundy,"
誤：p story[8...15]   #=> "Grundy"
正：p story[8...15]   #=> "Grundy,"

-------------------------------
索引について。

宇宙船演算子(p52)という見出しはあるが、"<=>"での見出しはない。ところがp36で<=>が初出するが何の解説もないので読者はp52を読むまで理解できない。索引で<=>の見出しがあれば、とりあえづそれを引いて疑問は解決する。

後方参照について

後に説明する項目については、多くの場合、明確にどこどこで説明すると明示してあるので安心して読みすすめる。下記は、いくつかの例外。

p112
def some_method(param = nil)
この構文(デフォルト値をあたえる)についていきなり解説なしで登場し、とまどった。

-------------------------------
p124
本章で扱っていないこと
イテレータとでているが、p119 6.3.6 イテレータを解説しているのではと思う。

p130
階乗の定義で、わたしなら再帰で書くなあと思った。
def fact(n); if n==0 then 1 else n*fact(n-1) end end

vi はじめに
File.chmodとFile#chmodの違いというのが結局どこらへんにあるのか良くわからなかった。

-------------------------------
本書を越える範囲のことについて

続編があるとしたら(勝手に期待するところであるが)、以下についてRuby風のお作法をぜひ読みたい。

テストの仕方
デバッグの仕方
性能のチューニング方法

-------------------------------
『初めてのRuby』サポートページ
http://yugui.jp/wiki/hiki.cgi?LearningRuby
『初めてのRuby』正誤表
http://yugui.jp/wiki/LearningRuby-Errata

Googleを支える技術

Googleという不思議なサービスを提供するそのコンピュータシステムの内側に公開された資料だけを利用して迫った良書である。

Internetの向う側のGoogleというシステムについて、われわれは日々利用しているにもかかわらず殆ど何も知らない。少なくともわたしは技術的な側面について殆ど何も知らない。神秘的な、都市伝説的なもの、例えば、20%ルールとか、そんなことぐらいしか寡聞にして知らない。

本書はGoogleの分散ストレージ(GFS/BigTable/Chubby)、分散データ処理(MapReduce/Sawzall)、運用コスト、開発体制などについて公開された論文などを引きながら解説している。

コンピュータシステムというのは極論すれば、いかに速くするか、いかに安くするかという2軸で発展してきたようなものだから、Googleという巨大システムをどのようにエンジニアリングするかという観点からもこの速くすること、安くすることの実務的な教訓というのは大変興味深い。

RDBMS(関係データベース管理システム)というソフトウェアは多量なデータをいかに格納し、検索するかという観点から開発発展してきたものだが、Googleは、それを地球規模の巨大システムに実装したものと言える。

わたしが本書で最も興味を引かれたものは、分散ストレージや分散データ処理の話ではなく、運用コストの章であった。そしてわたしはこの章が本書の最もユニークなところでしかも最も重要なところかと思う。

フツーのプログラマが計算コストと言うときアルゴリズムの計算量の事を指す場合がおおいと思うが、計算にいくらかかっているかという観点から議論するということは、あまりないと思う。

ムーアの法則のすごいところは、18ヶ月で半導体の集積度は倍になる、すなわちコストが半分になると言い切って、フツーのプログラマにそれを意識させたことである。コストが半分になるのだから、それを意識したプログラミング、すなわちメモリがどんどん増えていく、あるいはメモリがどんどん安くなることを前提としたプログラミングが正しいこととされた。そのようなパラダイムでソフトウェアサイエンスは進化していったようなものである。

コンピュータの高速化の流れも、ムーアの法則にのとって、クロックを高速化する事によって、命令セットアーキテクチャを変更する事なく、様々な実装上の工夫によって、高速化していった。ソフトウェアにとっては、ほとんど何もしないで高速化していったわけであるから楽な時代であったと言える。

ところがクロックをどんどん上げて行くことによって、電力消費量もそれに比例してどんどん増加していって、発熱の問題などが顕在化してきた。そこで、クロックを上げることによる高速化ではなく、マルチコア化等による高速化などが必要になってきた。同様に消費電力あたりの性能を上げるための様々な工夫が必要になってきた(←今ここ)

計算機の消費電力は電気代というお金になる。Googleが利用している計算機は、2000ドル〜3000ドル程度の普通のIAマシンのようであるが、その消費電力が増加の一途をたどり、年間運用コストがそれを上まわるかどうかという事である。

電気代だけではなくてデータセンターの建設費、効率的な電力消費設計などがコスト負担にどんどかかってくる。プログラマは昔はムーアの法則をメモリ空間の増大などと一次元的に考えていればよかったが、今後はメモリ空間はまあそこそこあるとして、消費電力をどう効率的に利用するか、省電力プログラミングが求められてきているような気がする。

消費電力を半分にできれば運用コスト(電気代)は半分になるし、ばかでかいデータセンターの建設も先送りにできる。サーバー機の重要なコストファクタが電気代というのが常識になってくるとプログラマのプログラミングパラダイムも随分変化してくる。

速くするだけではなく、電気代を節約する速さが求められるのである。

モバイル機器なんかは電池の持ちが商品価値そのものを決めたりするので、もっと重要である。バッテリーのサイズが半分になればデザインの自由度も随分増すだろうし、なにより軽くできるし、ハードウェアコストも安くできる。プログラムが物理的なデザインに影響を与えるのである。

プログラマがもっとコストなどの側面に意識を持つべきだと思うのだが、その意味で本書の第5章などは大変興味深くかつ意義深いと思う。

省電力プログラミングというパラダイムをそろそろ真面目に考えないといけない時期である。

Googleを支える技術 ……巨大システムの内側の世界
サポートページ
http://gihyo.jp/book/2008/978-4-7741-3432-1/support

Happy Hacking Diary(著者：西田圭介氏の日記)
http://d.hatena.ne.jp/nishidakeisuke/20080428

Papers Written by Googlers
http://research.google.com/pubs/papers.html

未来のいつか/hyoshiokの日記(電気代)
http://d.hatena.ne.jp/hyoshiok/searchdiary?word=%c5%c5%b5%a4%c2%e5

未来のいつか/hyoshiokの日記(省電力)
http://d.hatena.ne.jp/hyoshiok/searchdiary?word=%be%ca%c5%c5%ce%cf

勉強会のこと

ここのブログの読者の皆様にはご存知のこととは思うが、ほそぼそとカーネル読書会という名の宴会、もとい、勉強会みたいなものをやっている。

最近特に思うのだが、東京界隈ではそれこそ毎日のようにあちらこちらで勉強会など開催されている。定期的な開催もあれば不定期な開催もある。カーネル読書会のようなゆるゆるな運営もあれば、きちんとした運営のもと何百人もあつめるカンファレンス形式のものもある。

まあ、感覚的には結構頻繁にいろいろやっているよねと思っていたのだが、下記のIT勉強会カレンダーを見てほしい。

https://www.google.com/calendar/embed?src=fvijvohm91uifvd9hratehf65k%40group.calendar.google.com

本当に毎日毎日いろいろな勉強会をやっている。このカレンダーは、はなずきんさん(http://d.hatena.ne.jp/hanazukin/)が個人で編集されているものなので、おそらくもれや抜けはすくなからずあるだろう。例えば、仲間うちでやっている読書会とか、広く募集していない勉強会などは当然載っていない。

これらの勉強会の特徴を一つだけあげるとしたら有志がボランティアでやっているものだ。商用のセミナーではない。IT系のカレンダーなので、業界の人達が集まるLinux World Expoとかの日程などももちろん掲載されているが、圧倒的多数はボランティアが自主的に開催している勉強会である。

個人が主催しているので、会費も無償か、あってもかかった経費を割り勘というのが多い。

内容も千差万別だが、それにしてもこれだけのコンテンツをほぼ無償でよりどりみどり勉強できる環境がこの地にはある。

勉強会によっては、勉強会のあと懇親会(宴会だよ宴会)がついてくる。これがまた楽しい。カーネル読書会は宴会があってのカーネル読書会のようなものである。

発表者に直に質問する絶好のチャンスである。宴会で隣に座った人が実は業界で知らぬ人はいない神様みたいな人だったりすることもある。あるいは一度も会ったことはなかったけど日記は良く読んでいたという、ああ、あの人かという人だったりすることもある。

確かに初めて勉強会に行くのはちょっとした勇気が必要だ。周りの人は皆初対面だったりするのはなかなか踏ん切りがつかない。行っても打ち解けないかもしれない。常連の人達は楽しそうにやっているかもしれないが部外者が行っても場違いではないか。などなど行かない理屈はいくらでもつけられる。

しかし、別にそんなに大袈裟に考えることはないと思う。ためしに行ってみて、だめだったら、自分にあわなかったら、別の勉強会に行けばいいだけの話だ。経済的なダメージがあるわけではないし、何がしかの知識が得られ、ひょっとしたらもっとすごい何かを得られるかもしれないチャンスなのである。

だめもとである。

いろいろな勉強会に参加してみて本当に思うのだが、このゆるい参加者の繋がりはとてつもない可能性を持っている。

カーネルの技術者もいれば、Web 2.0の開発者もいる。Perlのエラい人もいれば、Rubyの開発者もいる。ユーザーもいればばりばりのハッカーもいる。皆楽しそうにくっちゃべっている。わたしみたいにビールでヘロヘロになりながらキャッシュミスがどーだこーだなどと延々ヨタ話をかましている奴もいれば、大所高所から日本のIT産業の未来について、おまえはこの国の首相かみたいなツッコミを入れたくなるような論調でべきろんをぶっているやつもいる。

若い人もいれば年寄もいる。

オープンソースの技術論についてはとどまる事をしらない。MySQLやPostgreSQLのスケーラビリティについて、それこそ重箱の隅をつつきながら議論している。LAMPなどの定番のオープンソースについては共通の基盤として語彙がそろっている感じである。

そして単なる参加者だけではなくより積極的に発表者になろうというのが、1000人スピーカプロジェクトである。

http://ja.doukaku.org/wiki/index.php/1000speakers

自分を晒そう
恥ずかしがるための プライドなんて捨てちまえ！
それが自分のためにも 人のためにもなる

1000人スピーカ プロジェクトは、発表経験の少ない人に「自分の技術をさらけだす場」を提供することを目的としたプロジェクトです。

カンファレンスで自分のやったことについて発表することはとても重要です。しかし、参加者が100人を超えるようなカンファレンスで発表するのは敷居が高いです。また、そういうカンファレンスではどうしても参加者同士のつながりが薄くなりがちです。そこで、30人程度の規模のカンファレンスを繰り返し行うことで、敷居を低く、間口を広く、密度を濃くしていこうと考えています。

これだよこれ。こーゆープロジェクトがどんどん増えていって、勉強会の幹事もどんどん増えていって、参加者も発表者もどんどん増えていって、知が流通している。そんな実感がある。

日本にはGoogleはない。

だけど嘆くことはない。

われわれは勉強会、読書会という知のネットワークをここに持っている。

そしてプラットフォームとしてのインターネットを使いこなしている人々がいる。

巨大なバーチャルな学びの場をわれわれは持った。梅田望夫が「私塾のすすめ」で語っているような「私塾」があるような気がする。

参考：

カーネル読書会に必要なことは宴会で学んだ/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/08/post_5135.html
勉強会の幹事に向けて書いた。勉強会の運営のイロハである。

ちょっとした勇気と行動力(オフ会編)/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/12/post_fbd6.html
こちらは参加者へのメッセージだ。最低限、初対面の人と知り合いになろう。名刺交換をしようという、ちょっとしたコツを伝授(大袈裟だな)している。

勉強会でのエピソードなども早速ブログのネタにしちゃったりする。

Web2.0時代のソフトウェア開発のスピード/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/04/web20_5b1a.html
勉強会の後の懇親会で教えてもらったエピソードをネタにしちゃっている。金曜日の飲み会で企画会議をするという。

そしてこのエピソードはいろいろなところで使い回しをさせてもらった。
NDD (Nomikai Driven Development)/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/ndd_nomikai_dri.html

カーネル読書会のめざすもの/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/post_d222.html
なぜ、わたしはカーネル読書会なるものを始めたのかについて記した。

カーネル読書会とよしおかの野望/ユメのチカラ
http://blog.miraclelinux.com/yume/2006/07/post_69b1.html
ゆるい感じのカーネル読書会の実態を記している。

OSSの技術カンファレンス、縦串横串/ユメのチカラ
http://blog.miraclelinux.com/yume/2006/07/oss_f5f1.html

日本にはGoogleはないけど、OSの専門家やRDBMSの専門家やWebアプリケーションの専門家がバーチャルにコラボレートして世界にないものを創造していく、そーゆー緩い場ができると面白いなあなどど最近思っているのだ。それを東京と言う地域でやれないかなあと。

1000 Speakers Conference/ユメのチカラ
http://blog.miraclelinux.com/yume/2008/02/1000-speakers-1.html
先に紹介した1000 Speakers Conferenceに参加した時のレポートだ。発表がニコニコ動画にアップされているのも嬉しい。インターネットのおかげで時間も空間も超越できるようになった。

勉強をしなおす

いくつになっても勉強だ。昔とった杵柄。錆びたナイフを研ぐ。

という事で日頃なにげなく使っているEmacsのマニュアルを再読する事にした。会社の机の上にO'reillyの Learning GNU Emacs、Writing GNU Emacs Extensionsそして竹内監訳のGNU Emacsマニュアルがある。竹内監訳のGNU Emacsマニュアルの初版は1988年2月である。20年前である。いくら何でも日進月歩、秒進分歩のIT業界の時間感覚でなくても古すぎるだろうと思わなくもないが、機能がテンコ盛のEmacsにはversion 18ころの古典的な、基本機能をおさらいするには、サイズ的にも丁度いい感じである。

正直に告白すると、Emacsを日々使っているが自分で拡張を書いたりelispで手間仕事をちゃかちゃか片付けるという事はほとんどしていない。何かのきっかけでもないとマニュアルを読みかえすということもほとんどしない。ぐぐればどーにかなる。だけど、一見時間がかかると思えても基本にたちかえってみることは悪い事ではない。

今使っているEmacsは22.1.1だ。Ubuntu 8.04にデフォルトでついてくるやつである。10数年Emacsを使っているけど全然使いこなしている感じがしない。ちゃんと基本にもどって勉強しなおしてみよう。きっと新しい地平線が見てくるに違いない。

梅田望夫著「ウェブ時代 ５つの定理」

シリコンバレーという地域の競争力はどこにあるのだろう。あの底抜けの明るさはいったいなんなんだろう。と思う。

梅田望夫の［ウェブ時代　５つの定理」はシリコンバレーの空気をビジョナリーの言葉によって表現しようと試みている。

梅田にならって、「ウェブ時代 ５つの定理」でYahoo!ブログ検索、Googleブログ検索をしてみた。このブログを書いている時点でYahoo!で318件、Googleで約272件とでた。発売されてから1週間たつかたたないかで約300件ほどの記事が執筆されたということになる。それを梅田はすべて読むという。

毎日毎日自著の感想を何時間もかけてへとへとになりながら読む。読み続ける。それはなぜだろうと思う。

素人が書きなぐった感想をひたすら読みまくる。

リトマス試験紙として、「コンピュータによって社会を変える」という言葉を考えよう。あるいは「コンピュータによって社会を変えたい」という願望でもいい。あなたはこの言葉に共感を覚えるか、それともそうではないか。強くそう思う、そう思う、どちらでもない、そうは思わない、強くそうは思わない。

「コンピュータ」という言葉を「プログラム」という言葉に置き換えても、あるいは「技術」に置き換えてもいい。

技術者であるあなたはあなたの技術によって社会を変えたいと思っているのか。いつの日か自分の作った製品が世の中のどこかで使われて、何がしかの利便性を誰かに提供し何がしかの価値を発生させる。その様なイメージをあなたは持つのか。

ハッカーと呼ばれる人は、このプログラムによって何が変わるかをイメージできる人であり、プログラムによって社会を変えたいと思っている人のような気がする。

日本という地域で「コンピュータによって社会を変えたい」などというと、頭おかしいんじゃないの、宗教がかっていて気持ち悪いよと思われなくもない。

しかし、シリコンバレーの地には、そのような技術に対するオプティミズが蔓延しているような気がする。

それが彼の地の競争力の源泉なのだろうか？

もしそうだとしたら、それを日本という地域でコピーできないのだろうか？

ウェブという時代に一人一人が生き生きと幸せに生きるために。

高校時代マイクロプロセッサというものを知って、これで社会が変わると高校生ながら思った。就職してインターネットにふれて、これで社会が変わると新入社員ながら思った。オープンソースとであって、これで社会が変わると思った。

そしてWeb2.0の時代。

PCでもなく、携帯でもない。ワイヤレスブロードバンド時代。次の10年に何が来るのか。

東京の地で若い連中とくっちゃべりながら、この連中によって、いろいろ面白いことが始まっていることを確信する。LL (Lightweight Language)やらLAMPやら軽やかに使いこなす彼らが軽やかにWebサービスを立ち上げ緩やかな連携を会社の壁をいとも簡単に乗り越えて行なっている。

素敵だ。

それを目の当たりにすると、日本始まったな、と強く思うのである。

シリコンバレーの空気を日本語で発信し続け、若い人を励まし、彼がやらない限り世に起こらないことを梅田望夫はやる。

日本ならではの強さとシリコンバレーならではの強さの融合という最終定理に向けてわたしも微力ながら何がしか試行錯誤をしたいと思った次第である。

ウェブ時代をゆく

梅田望夫「ウェブ時代をゆく」を読んだ。

日本社会に足りないビタミンを補給してくれる書籍だ。

いまでこそ、シリコンバレー精神だなんだということが人々の話題にのぼるが、日本になんらかの違和感を持って90年代はじきだされたわたしとしてはかの地から日本を眺めていた時期もあったけど、結局のところやっぱし日本が好きだし日本でどうにかして何かを成し遂げたいと思っていて、その意味でこの「ウェブ時代をゆく」というのは梅田望夫が日本にいる若い世代に日本に足りない何かを必死になって伝えようとしている一冊である。

一時期、シリコンバレーに居たものにとって、梅田望夫のような楽天的な未来を信じる人々というのは、シリコンバレーには特異な人間ではないと言うことを知っている。それは、30代後半あるいは４0代になっても現役でバリバリコードを書いている人が珍しくないのと同じくらい珍しくない。

大きな組織にしか大きな仕事ができない社会と、小さな組織あるいは個人にもそのようなチャンスがあり、小さな組織が有機的にからみあって共同で大きな仕事をする社会。極論すれば後者のようななイメージをシリコンバレーという地域は持つ。

ソフトウェアによって社会を変える。ハッカーが持つ精神というのを、日本で言ったら間違いなく笑われる。会議室でそんなことを言ったら頭がおかしいのではないかと思われる。

日本ではそんなことを声高では言わない。Suicaは便利だ。不具合も取りざたされているけど便利だ。いちいち券売機で切符を買う必要がない。そのようなちょっとした便利を実装しているテクノロジーを開発した人は声高にその成果を誇らない。誇ってもいいとわたしは思うのだがそれが日本の社会である。

どちらがいいとか悪いとかの話ではない。

もう少し個人が自立して生きていく方が息苦しくなくていいと思うが、別に誰かにそれを強制するつもりは、わたしはない。

誰もがシリコンバレーに行けるわけではないし、行く必要もないし、日本の社会がそれを真似る必要もない。

しかし、評論家のように日本でできない理由をあげつらってもしょうがないと思う。日本はIT産業が３K職種だなんだなんて言ってもしょうがない。仮にそんな状況があるのなら、それを変えればいい。大げさな話ではなくて自分の周りのちょっとしたことをちょっと変える。

わたしは、おっちょこちょいなもんだから、面白いと思っていることを無邪気にやっていたら、今ここにいる。何かの戦略性があってここにいるわけではない。しかし、若干の自覚を持って、プログラムを作ると言うことに何がしかのこだわりを持って、いまの自分のポジションを作ってきたことも確かだ。

日本と言う地域で、もう少しプログラミングをすることが楽しくて誰かの役に立つという仕組みができればいいなあと思っている。少なくとも、そーゆー社会は実現可能だと思うし、自分でもできる範囲でこつこつとやっていきたいと思っている。

例えば、技術者としてその専門性を伸ばすために、会社の壁を超えて自由に技術的情報を交換できる場としての広い意味でのコミュニティ活動は、最近では大変活発になってきている。東京ではそれこそ毎日のようにいろいろなところで、勉強会だか読書会だか講演だかセミナーが開催されている。自立した技術者であれば、そのような場所に顔を出し、自らの専門性を磨くことに障壁はほとんどない。自覚を持ってそのような交流会に出て刺激をうけ誰かのスタイルを参考にして自分のスタイルにしていける。

かつては大きな組織と言うのが圧倒的に有利であった。今でもそのようなことはいっぱいある。しかし、一方でウェブやオープンソースの時代はその規模の経済性が相対的に低くなってきていることも事実だ。

大企業じゃなければOSの開発に携われないということはない。大企業じゃなければプログラミング言語を開発できないということではない。大企業じゃなければデータベース管理システムを開発できないわけではない。

大企業をシリコンバレーに置き換えてもいい。

シリコンバレーにいなければOSの開発に携われないということではないのだ。

ウェブやオープンソースのおかげで随分世の中は面白くなってきた。

世の中は自分の力で面白くもつまらなくもなるんだよ、それを作っているのは一人一人の個人なんだよという考え、働き方は、若者だけではなく、40代、50代のおじさんたちにも共感できるなにがしかのものをもっている。自分を犠牲にすることはない。いい意味で自分のために自覚を持って働くことが全体の幸福に繋がるようなそのような社会をみんなで作っていきたいなあなどと妄想は膨らむのである。

「ウェブ時代をゆく」いよいよ発売です。 －　My Life Between Silicon Valley and Japan
http://d.hatena.ne.jp/umedamochio/20071105/p1

ベストセラーは読まない

本の読み方はいろいろある。十人十色。

熟読、濫読、積読、黙読、音読、再読、回読、誤読、精読、速読、耽読、通読、復読、輪読、朗読、輪読、…

本の買い方もいろいろある。十人十色。

本屋でぶらぶら。新聞の書評を見て。アマゾンのリコメンデーション。ブログで紹介されていたから。

人それぞれのスタイルがあると思う。

人様の本の読み方や買い方に別にけちをつけるつもりは毛頭ないが長年培ってきたわたしのスタイル（というほど大げさなものではないが）を記してみたい。

若い頃は手当たり次第にともかく面白いと思ったものを読んでいた。自分の興味の赴くままという感じである。あたりもあればはずれもある。買う方法は本屋で立ち読みしてチェックして、というかそれ以外ほとんどなかった。（インターネット以前の本の買い方というのは本屋以外はなかったと言っても過言ではない）もちろん課題図書や輪講用文献など買わねばならないものは取り寄せで買うことはあったがそれは例外的な買い方で、圧倒的な多数は本屋で立ち読みして気に入ったら買う。好きな作家の新作ももちろんそのようにして買う。

技術系の文献については、暗黙の必読書みたいなものがあるので、それをカバーする。先輩などの推薦の類だ。会社の先輩に相談してみよう。本を読まない同僚や先輩に囲まれているなら、インターネットに聞いてみるのも手かもしれないが、自分の好みやスタイルが確立できるまではとりあえづ、濫読、積読でもいいと思う。

定番の教科書については熟読、精読、再読などをしたい。

昔は、本の耳を折ったり、マーカーで印をつけて、本を汚しながら読んだのであるが、最近はポストイットを貼るようにしている。後からチェックするとき耳を折るより目立つのと、本を汚さないので、ブックオフかなんかに、いらなくなったら売ってしまおうかという下心もあるからだ。

最近は新書版が流行でベストセラーの類もいっぱいあるが、ほとんど読まない。何年後かにも生き残っているかはなはだ疑問だし、賞味期限があまりにも短いので、最低でも発行してから一年くらいはなかったことにしておいてもいっこうに困らないのである。

まあ、営業職かなんかでお客さんとの共通の話題作りのためということであればしょうがないがプログラマにとって新書版のベストセラーを追っかけるというインセンティブは低い。ましてや、ベストセラーリストを定期的にチェックしてトップ10に入った新書を濫読するというようなことは、わたしにはできないし、したくもない。（そんなやつはいないと思うが、意外といたりして）

ただし例外があって、このミステリがすごいについては、もうほいほい買っちゃう。もちろん自分の好き嫌い合う合わないはあるがある一定以上の水準は確実にオーバーしているので買って損したという感じは全然しない。

わたしは、本は本屋で買いたい。どうもインターネットでクリックというのが便利ではあるのだが性にあわない。

なので、誰かのブログで紹介されていた本も手でメモって本屋で実物をチェックして買うという手間隙かかる方法をしている。せっかくアフィリエイトしていても紹介者にはメリットが全然ないので申し訳なく思わなくもないのだけど。

本代は惜しまない。ひたすら本を買って読みまくる。そんなスタイルである。

ハッカー倫理

実のところ60年代、70年代にMITにいたわけではないので直接見聞きしたわけではないのだが当時のMITの研究室にたむろっていてプログラマ達に暗黙のうちに了解されていた哲学、倫理、あるいは夢みたいなものがハッカー倫理とよばれるものだ。

スティーブン・レビー「 ハッカーズ」で次のように記している。

コンピュータへのアクセス、加えて、何であれ、世界の機能の仕方について教えてくれるものへのアクセスは無制限かつ全面的でなければならない。実地体験の要求を決っして拒んではならない。

すべての情報は自由に利用できなければならない。

権威を信用するな－－反中央集権を進めよう。

ハッカーは、学歴、年齢、人種、地位のような、まやかしの基準ではなく、そのハッキングによって判断されなければならない。

芸術や美をコンピュータで作り出すことは可能である。

コンピュータは人生をよいほうに変えうる。

フリーソフトウェアあるいはオープンソースのプログラマは上記のハッカー倫理を実践している人たちだ。世間一般からいえばコンピュータには詳しいがちょっと変わった風貌で何を考えているかよくわからないという風にみられていなくもない。

昔はIBMに代表される権威的なメインフレームの対極にDECのミニコンピュータ（PDPシリーズ）があって、それを操るのがハッカーだったわけだ。

プログラムは当然のごとく共有され自由にコピーされていた。コピーをさせないことは悪いことだと考えられていた。それに猛然と反旗を翻したのは若き日のビル・ゲイツである。彼はプログラムを勝手にコピーすることは窃盗行為であると言ったのであるが、このことについては別途記すことにする。

「ハッカーズ」のエピローグ「真正ハッカーの終焉」にリチャード・ストールマンが登場する。MITのAIラボの研究から生まれたリスプマシンの商用化をめぐってLMI社とシンボリックス社が商業化の名の下に情報を隠蔽し壁をめぐらし対立していくなかで、ハッカー倫理を貫こうとしたリチャード・ストールマンの悲劇を描いている。彼はソフトウェアを私有にすべきではないという信念を語っているが、商用化によって彼は孤立し、最後のハッカーとなった。

「会社がうまくいくやり方は、ひとつしかない。それは金儲けという動機で働く人間に会社をやらせることさ」（600ページ）

「会社のために働くことによって、最も純粋なハッカー社会のメンバーたちは、ハッカー倫理の中心となる要素、情報の自由な流れを、放棄してしまったのである。」（603ページ）

「ハッカーズ」は資本主義の世界ではハッカー倫理は貫けないというエピローグで終わっている。リチャード・ストールマンは世界中にただ一人である。そして彼の試みを紹介しつつも、そこにあるのはハッカーのユートピアではない未来を暗示している。

確かにインターネットが広く利用されるまでは彼の運動は孤立無援、孤軍奮闘であった。

ところがインターネットの時代になって一度はなくなったかに見えたハッカー倫理がオープンソースとともに蘇った。資本主義という経済制度の枠組みと対立するわけでもなく、むしろオープンソースはそれを資本主義とどうにか折り合いをつける形で共存している。

ちょっと反権威的で、すべての情報は公開されるべきだと考え、ハッキング能力によって評価され、コンピュータによって世界をよくしていくというようなことを考え実践しているプログラマたちがインターネットによって地球規模でコラボレーションをしている。

60年代、70年代のMITの研究所が地球規模で出現しちゃったという感じである。

「ハッカーズ」のエピローグはもの悲しいが、リチャード・ストールマンはその続編を自らの社会的なハックによって書き記したと言ってもいいだろう。

とんでもないハッカーである。

闘うプログラマ

わたしが紹介するまでもなく、「 闘うプログラマー〈上〉」、「 闘うプログラマー〈下〉」はビル・ゲイツの野望を実現すべく雇われた「伝説のプログラマ」デイブ・カトラーのＮＴ開発物語である。

わたしはデイブ・カトラーに会ったことはないがDEC時代にいろいろ伝説は聞いていた。一番、有名な都市伝説は、Windows NT (WNT)というのはVMS (DECのベストセラーマシンVAXのOS)を一文字づつずらした名前にしたというものである。誰かがデイブ・カトラーにその真偽を問うメールをしたところ、今ごろ気がついたのかよ、という返信が来たという。90年代初頭にそのようなメールがでまわっていたような記憶がある。

それはともかく鬼軍曹のような風貌のプロジェクトリーダ率いるＮＴ開発物語はザカリーの筆力もありぐいぐいと人を引きつける。

それは栄光と挫折の物語である。20世紀最後の商用ＯＳ開発物語と言ってもいい。このような大規模な商用ＯＳ開発はあとにも先にもマイクロソフトでの開発が最後になるであろう。専用ＯＳや小規模なそれの開発は今後も続くであろうが、商用でクローズな世界での大規模新規ＯＳ開発は今後は見られないであろう。

ＯＳＳ(オープンソースソフトウェア)がＯＳの作り方を大聖堂(伽藍型)からバザール型へ変えてしまった。マイクロソフトは今後も大聖堂型でソフトウェアを作り続けるだろうが、NT開発物語のような社運をかけたOSの新規からの開発はもやはないのではないだろうか。

90年代の初頭というのは、そのような時代であった。商用ソフトウェアベンダは自社の基幹ソフトウェアを社運を掛けて開発していたのである。一か八かで、掛金全部をその製品の開発に掛けた。

この本を読んだ当時わたしはDECからOracleに移ったばかりで、本物のプログラマ達がおりなす壮大な20世紀のドラマに心を踊らされたものである。

そしてそのような大規模ソフトウェア開発というのはマイクロソフトをはじめとする米国のソフトウェア企業にしかなかった。米国OracleからOracle 8の開発に参加しないかと声をかけられたのは正にそのころである。Oracle 8の開発というのは当時の米国Oracleにとっては一か八かの大勝負のプロジェクトであり、そこには間違いなく人を引きつける何かがあった。

わたしは一兵卒としてその開発に参加した。正直言って36歳での参加というのは若くないし、はたして使いものになるのか不安に大きかったが、このまま日本という地域で現場を見ないまま終るのか(？)、それともリスクも含めて一切合切腹をくくってチャレンジするのか、その選択でわたしは後者を選んだ。

朝から晩までコードを書いてテストをしてデバッグをする。それを延々日々繰り返す。プログラマとして充実した日々を過したように思う。

いつの日か「闘うプログラマ」の現場に立合いたいと思っていたのがOracleで実現した。自分なりにいつの日かにそれを総括してみたいと思っていたのだが、オープンソースに出会い、大規模ソフトウェアの開発は社内ではなく社外文字通り地球規模でおこなわれつつあるという予感を感じたのである。

21世紀はマイクロソフトやOracleに勤務しなくても大規模ソフトウェア開発に参加できる。素晴しい機会に満ちているではないか、そう思ったのである。オープンソースの奇跡と言ってもいい。

下記は1998年8月に記したシリコンバレー日記である。
----------------------------------
1998年8月5日(シリコンバレー日記より)
大聖堂とバザール
今年は本当にいろいろ日記を書いている．今日までに３０数本書いている．近年まれにみる快挙である．それだけネタに困らなかったのかもしれない．今年の頭に日記を復活した時，わたしの中には，１９９７年にわたしが何をしたかを忘れないうちに記そうという気持ちがあった．１９９７年のことでその予告をしたのだけれど昨今昔のネタはほとんどでてこない．それもこれもNetscapeの決断である．ソースコードの公開である．Mozillaで，http://www.mozilla.org/を紹介しつつ自分の期待を語った．

わたしは年頭になにを語りたかったのか？それを今から思い返してみるとこんなことだ．わたしはある大規模ソフトウェアプロジェクトに参加した．それも設計の初期の段階から，実装，テスト，リリースまでプロジェクトの一員として日々一喜一憂しながら関わった．そしてそのプロジェクトの成果は出荷された．それを自分なりに消化した形で総括したかった．

多くの人が関わるプロジェクトである．そこには人間のドラマがあるはづである．何かして，それはうまく行く場合もあるが失敗する場合もあるのだか，そこからなにがしかを学んでいく過程を記録に残しておきたかった．それは一つは自分のプログラマとしての成長の記録になるはづだし，内側からみたソフトウェアプロジェクトの貴重な資料にもなりえるのではないだろうかという思いがあった．

一人のプログラマがシリコンバレーに来て，そこでプログラマとして働くということはどういう事か？それを明らかにしたかったのである．それもできるだけ平易な形で．

ブルックスはＩＢＭのＯＳ３６０の開発の経験から「ソフトウェア開発の神話」という名著を記した．キダーはデータジェネラルのミニコン開発を「超マシン誕生―コンピュータ野郎たちの540日 (1982年)」で克明に記述した．ザカリーは「闘うプログラマー」でマイクロソフトのＮＴ開発部隊の生態を明らかにした．失敗と苦悩とそして栄光の物語である．

誰でも自分の行動を正当化する．過去は美化される．思い出は時として理想化され，記憶は風化する．

プログラマとしてのキャリアを続けていく以上，前のプロジェクトから何を学んだかを記すことは，記憶を風化する前にしなければいけない自分自身への宿題でもあったわけだ．

その作業が遅々として進まないうちにもっと自分にとって面白い事件が発生した．それが今回のモジラの解剖である．これは仕事ではない．単なる趣味の延長である．しかしながらその趣味は自分のプロフェッショナルな領域とほとんど重なる．プログラムの開発スタイルも開発されるものも全く異なるにもかかわらずプログラムを作るという個人的な作業の上では共通点も多い．すくなくとも自分の心の中でプロジェクトを楽しんでいるという意味では会社でのプロジェクトもモジラも同じスタンスにある．そして年頭に大規模開発の現場の話を誰かに伝えたいと思ったようにわたしは今起っているオープンソースの流れを誰かに伝えたくて伝えたくてしょうがなくなってきたのだ．

今年Ｎｅｔｓｃａｐｅがソースコードを公開するにあたっていくつかのエッセイを紹介していた．そのうちの一つがEric RaymondのThe Cathedral and the Bazaar(大聖堂とバザール）である．これは山形浩生によって日本語に翻訳されている． 伽藍とバザール を参照．

その論文には口上として「Ｎｅｔｓｃａｐｅがソースコード公開をするにいたって理論的な根拠となった論文」とか書かれていたのだけれど，わたしは，いくらなんでもそんなことはあるまいと思った．つまり，恥ずかしながら「わたしのあくまでの想像ですが，ネットスケープのお偉方が，件の論文を見て，おお，この論文いい事書いてあるから，いっちょこのモデルでやってみよー，そーだ，そーだ，とかいう事を取締会議かなんかでやったかというとたぶんそんなことはありえないんじゃないかなあ．そんな論文があろうがなかろうが，それと独立にネットスケープは決断したわけですね．その仮定が正しいとすると，理論的根拠というのはいいすぎなのではと思ったです．少なくとも謝辞の中にネットスケープの人の名前は一人もでていないし，直接的な関連はないのではないでしょうか？」などと能天気に記していたのである．ところがである．当該論文のエピローグにその後の話が載っていて，Ｎｅｔｓｃａｐｅの取締役がＥｒｉｃにメールを出し，２月４日の戦略会議に招待されたとかいうエピローグまで紹介されているのである．わたしはまるっきり間違っていた．赤っ恥をかいたのである．

Ｅｒｉｃは，従来型のソフトウェア開発の方法論を大聖堂（Cathedral）アプローチと呼んでいるのだが，大聖堂を組み立てるように注意深く管理されたアプローチと，バザールのような混沌としたスタイルを対比している．そして明らかなことにわたしは大聖堂のプログラマであった．自分自身はＧＮＵの事やＬｉｎｕｘに一定の理解を示しつつもバザールがすぐそこまで来ているということに全く気がついていなかったのだ．

大聖堂には大聖堂の掟やスタイルがある．その開発はなかなか面白い．ものを作ることは人間を根源的に満たすなにかがあるのかもしれない．そんなことを記したかったのかもしれない．

それがモジラの登場でいきなりバザールにぶっこまれて迷子になりそうになりながら，そのバザールの面白さダイナミックさに一気に虜になってしまったのである．そして，奇妙なことに自分の中では矛盾なく大聖堂もバザールも同時に楽しんでいるのである．

なかなか不思議な時代感覚である．
----------------------------------
http://web.archive.org/web/19990424133227/www.best.com/~yoshioka/d/98/i980805.html (文字コードをシフトJISにして読んでください)

ソースコードの読み方

ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。

ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか？

閑話休題。

ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようになった。これはいいことである。時代の進歩といっても差し支えない。

カーネル読書会ではその道の優れたプログラマにお話を聞くが、わたしは時々、どうやってデバッグをしているかとか、どうやってコードを読むかというような質問をする。暗黙知としてハッカーがもっているものを言語化してもらってどうにか形式知にしたいと思っている。

しかし、そうは言ってもまだまだ職人芸の世界で、なかなか優れたプログラマの技法というのが形式知化されているとは言いがたい。定石を集めたいところである。

ユメのチカラでは下記のエントリを記した。

コードを読むな、理解しろ
http://blog.miraclelinux.com/yume/2006/10/post_e3d6.html

これはoprofileを利用してrubyをハックした事例である。コードを読むのは端から端まで直列で読んでいたらいくら時間があっても読みきれない。コードを読むには、コードを読まないテクニックが必要でそれを紹介した。ブックマークやトラックバックもいっぱいいただいた。

トラブルシューティングの実際
http://blog.miraclelinux.com/yume/2006/10/post_5353.html
実際にあった問題を、ソースコードの観点から理解するという事例である。使っている道具立てはgrep/findなどなど標準的なものばかりだ。別段トリッキーなことをしているわけではない。包丁とフライパンだけで料理を作るようなものである。職人は道具を使いこなす。その技を見てほしい。

なぜソースコードを読むのか？
http://blog.miraclelinux.com/yume/2006/08/post_3771.html
そのものずばりの話題について記した1999年ころの記事である。大聖堂のプログラマであったわたしがオープンソースの潮流に触れその可能性にわくわくしていた感覚がある。「ソースコードを読む。その基礎的な技術がオープン・ソースの時代には最も必要とされているのである。」と断言しているが、その確信は今でもゆるぎない。

下記は大規模ソフトウェアの効率的な理解という観点で記した。ざっくり通しで読んでいただければ幸いである。

大規模ソフトウェアの効率的な理解
http://blog.miraclelinux.com/yume/2006/08/post_cae5.html
「OSSの時代こそ大規模ソフトウェアの実装の効率的な理解の方法論が求められている。企業が自分が作ったソフトウェアを自社のエンジニアに教育（OJT）するのと違って、OSSはそのような内部構造の教育コースがない。自分のすぐそばにコア開発者がいないので簡単に聞くことが難しい。
中略
その実践的な方法論についていろいろ議論していきたいと思う。」

大規模ソフトウェアの効率的な理解（その2）
http://blog.miraclelinux.com/yume/2006/08/2_2d39.html
ソフトウェアの規模を下記のように定義した。
    規模         行数
    小規模       10万行以内
    中規模       10万〜100万行程度
    大規模       100万行以上
ソフトウェアを構成する行数でおおざっぱにくくっている。あるいは開発に関与する人数によっても同様にくくれる。
    規模         人数
    小規模       10人以内
    中規模       10人〜100人程度
    大規模       100人以上

大規模ソフトウェアの効率的な理解（その3）
http://blog.miraclelinux.com/yume/2006/08/3_dc26.html
規模の把握。

大規模ソフトウェアの効率的な理解（その4）
http://blog.miraclelinux.com/yume/2006/08/4_4b7e.html
巨視的、微視的な理解という観点を提示している。

大規模ソフトウェアの効率的な理解（その5）
http://blog.miraclelinux.com/yume/2006/08/5_de60.html
「動的というのはソフトウェアを実行した時の挙動のことをさし、静的というのはソフトウェア(プログラム)の字面をさす。」
動的理解、静的理解という側面から解説した。

大規模ソフトウェアの効率的な理解（その6）、リグレッションテスト
http://blog.miraclelinux.com/yume/2006/08/6_570e.html
「OSSの実装も単にソースコードやドキュメントを整備するだけではなく、リグレッションテストをどれだけ充実するかという視点で議論、評価される時が来ているように感じる。よりOSSが大規模になり、修正が頻繁に求められるようになるとリグレッションテストが整備されているかいないかで、その変化に対する対応力が全然かわってくるのである。」

gdbの実践的使い方
http://blog.miraclelinux.com/yume/2006/09/post_fa59.html
gdbをデバッガとしてしか利用していないとしたらその威力の10%も利用していない。gdbはソースコードを読むためのツールである。「gdbはソースコードの理解を助ける偉大なツールなのである。」

gdb/xemacs/cscopeの使い方
http://blog.miraclelinux.com/yume/2006/09/gdbxemacscscope_e0da.html
「プログラムの状態は変数の値の変化によって変化していくわけだが、変数は、宣言され、値を代入され、参照されるなどして利用される。」

おまけ：
カーネル読書会とよしおかの野望
http://blog.miraclelinux.com/yume/2006/07/post_69b1.html
「ソースコードを読むことは楽しい。そういうと、多くの人は怪訝な顔をする。無理強いはしないしするつもりもないし、もちろんできないのであるが、ソースコードを読むことが楽しいということを少しでも多くの人に伝えたくて、あるいはそのような同好の士を発掘したく、ぼそぼそと続けている。」

本日のエントリーはソースコードの読み方という観点からまとめてみたが、テストの仕方、デバッグの仕方、性能問題の発見とチューニングなどなどについてもいつかは記していきたいと思う。コメント、トラックバックなどをお待ちする。

追記：
はてなブックマークを多数の方に付けていただいている。（これを書いている時点で100を越えている。）どうもありがとうございます。下記も参考になると思う。
大規模ソフトウェアをgdbを利用して微視的視点から理解をする
http://blog.miraclelinux.com/yume/2006/09/post_8096.html
gdbを利用して、どのようにソースコードを理解するか事例を紹介している。実際にあった事例なので、瑣末なめんどくさい事も含めて参考になると思う。現場はそのような瑣末なことがらにみちみちているのである。

シリコンバレーの思い出

今から約10年くらいまえにシリコンバレーにいた。米国Oracleのデータベースエンジンの開発部隊にいた。さらにそれを遡ること数年前、米国DECのデータベースの開発部隊、これは東海岸(New Hampshire州Nashua)にあった、で開発していた。

われわれはよく欧米とか言う。欧州の国々の文化と米国の文化を一緒くたに議論したりしがちである。しかし、米国と英国ですら文化的には随分違うし、ドイツ、スペイン、スウェーデンなどなども相当違うのではないかと想像する。

米国ですら、東海岸と西海岸も生活してみて、これが同じ国かというほど違う。東海岸といっぱひとからげに言うのも語弊があるかもしれないが、ニューハンプシャー州の住んでいたところと、西海岸のシリコンバレーでは気候も回りの人々も随分違う。

東海岸の米国DECは典型的な垂直統合型ビジネスモデルで、会社の文化も、西海岸の水平統合型の米国Oracleとは全くことなっていた。前者が破壊的イノベーションで破壊される側で後者が破壊する側であった。

会社での意志決定のスピードも前者と後者では随分違った。前者は慎重、後者はスピード重視というイメージである。これはたまたまそうであったのか、それともシリコンバレーという破壊者の巣窟であったからなのかはよくわからないが、わたしが想像するにやはりシリコンバレーという米国でも例を見ない特異点だからだと思う。

シリコンバレーの青い空と解放感。人々を引きつける何か。

シリコンバレーはIT産業に従事する者なら一度は働きたいというあこがれの地でもある。一方で80年代のボストン郊外にはDEC以外にもDG、Wang、Appolo等々(これらは全て今はない。全て破壊された)様々なハイテクベンチャーが勃興していて、ボストンにはMITやHarvardなど全米屈指の大学があって、こちらもあこがれの地であった。

それでも、やっぱり西海岸と東海岸では雰囲気が随分違った。西海岸はUnixで東海岸はLisp。西海岸はアバウトで実践的で、東海岸はフォーマルで理論的みたいな印象である。

西海岸の空の下でビールを飲みながら友人とよた話をするのが好きだった。

日本の社会と比べて、はるかに組織より個人を尊重している。大企業の看板よりも小さくても何をやっているかを重視するような空気がある。小さい会社でも専門性のある会社が大企業と対等にコラボレーションして、すざましいスピードで新しい価値を創造していく。そんなイメージである。

日本では小さい会社は大企業の下請け、孫請けというピラミッドに組み込まれていて、なかなか対等なコラボレーションというのは難しい。個人は組織に抹殺されている。

オープンソースの場合、その価値観は180度ひっくりかえる。組織ではなく個人。

梅田望夫はシリコンバレー精神 -グーグルを生むビジネス風土 (ちくま文庫)のなかで「なぜなら日本社会や日本企業は、ナードの価値を全く理解せず、ナードを大切にしてこなかったし、今も大切にしていないからである」(187ページ)と記している。文庫のための長いあとがきで「日本の旧来型大企業の中ではこの状況に変化はないが、若者たちが主役の日本のネット産業は、ナードを大切にすることの意味に気づき始めている」と若干修正している。(ここでナードというのは、コンピュータプログラムに優れたちょっと変ったやつくらいの意味である)

シリコンバレーがいまだに特異点である事は間違いないだろう。日本の旧来型大企業の姿もおそらくそうであろう。しかし、わたしは東京という地域でナードを大切にする企業というのが多くはないが生れつつあるという実感を持つし、旧来型大企業ですら、その内側には、ナードの価値を理解する人々が増えつつあると思う。

別にすべて変える必要もなければ変わらなければならないということもない。自分の近傍がナードの価値をみとめ、それを搾取せづ、ちゃんとビジネスとして回っていけば、それはそれで幸せである。

シリコンバレーをコピーするために、リスクマネーの導入やら、様々な制度改革をおこなって、日本でも、ベンチャービジネス振興だなんだと行なわれているが、それももちろん大事だと思うが、ハードウェアではなく人なんだよなあ。行動するエンジニアとか、経営者とか、中間管理職とか、そーゆー有象無象の人なんだよなあ。看板で仕事をするのではなく個人として行動する人なんだよなあ。そーゆー人がある程度増えてくれば、東京という街も楽しいことをおこせるよ。そんな事を思うのである。

梅田望夫はそーゆー事はシリコンバレーでしか発生しないと考えているが、わたしは東京でもミラクルは起せると考えている。それが彼がシリコンバレーにいる理由ならば、それがわたしが日本に戻ってきた理由でもある。

オープンソースがそれを可能にした。それに未来を見付けた。だからわたしはここにいるのである。

コインロッカー・ベイビーズ

「 海の向こうで戦争が始まる」のあとがきで村上龍は、

この作品を書きあげた夜、あるバーでリチャード・ブローディガンに会った。「二つ目の本になる小説を書いたよ」そう言うと、ブローディガンは「ふうん」と横を向いた。この野郎、おめでとうくらい言ったらどうだ、と思ったが、彼はその時機嫌が悪かったらしい。もう一度僕に向きなおるなり、「大事なのはね、三作目だ」と短かく言った。

と書いている。

「処女作なんて体験で書けるだろ？二作目は、一作目で取得した技術と想像力で書ける。体験と想像力を使い果たしたところから作家の戦いは始まるんだから」

コインロッカー・ベイビーズは彼の渾身の力を込めた初めての書下し長編である。プロの作家として一人立できるのかそれとも芥川賞作家としてだけで終るのか、その分水嶺になった作品である。

彼の近未来小説の中では、この作品が最も好きだ。 「愛と幻想のファシズム〈上〉」、「愛と幻想のファシズム〈下〉」 、 「希望の国のエクソダス 」、「半島を出よ」など強烈なドライブ感を持つ作品は少なくないが、やはりプロフェッショナルな作家としての一里塚をうちたてたこの作品が最も好きだ。

村上龍と言えばセックスとドラッグと暴力という古いイメージを持つ世代（いったい誰だよ）は、コインロッカー・ベイビーズとあわせて半島を出よを読みたい。

読め。

ウィキノミクス

マスコラボレーションはいかに世界を変えたか。

ピアプロダクションでは、財産権という概念が逆転する、なんていう話は俄かには理解しがたい現象ではないか。成果物を他者が勝手に利用しないように制限をかけるのではなく、無償で他人に利用させむしろそれを奨励するというようなことが理解できるだろうか。

インターネットによってコストゼロでマスコラボレーションが仮に可能になったとして、その事例を見せられたとして、自分のビジネスには関係ないどこか別の世界で起きていることではないかと思うのがほとんどなのではないだろうか。

自分のこととして理解してあらたな行動をこの本から起こすと言うのはほとんど考えられない。既にマスコラボレーションのことを十分理解しそこにビジネスチャンスがあると考えている人は、この本があろうがなかろうが行動しているだろうし、そうでない人は、この本があろうがなかろうが何もしないだろう。

オープンソースは既に市民権を得られたといっても過言ではないが、それでもいまだにそれを信頼していない人は少なくはない。

フリーソフトウェアから始まったソフトウェア開発の新しい潮流は、その華々しい成果にも関わらず、多くの人はそのメカニズムに注意を払おうとしていないし、払うつもりもない。

ソフトウェアがどのように作られるかと言うのは多くの人たちにとってどうでもいいことである。それは否定しないが、ソフ