ユメのチカラ

初めての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ページ)と記している。文庫のための長いあとがきで「日本の旧来型大企業の中ではこの状況に変化はないが、若者たちが主役の日本のネット産業は、ナードを大切にすることの意味に気づき始めている」と若干修正している。(ここでナードというのは、コンピュータプログラムに優れたちょっと変ったやつくらいの意味である)

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

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

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

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

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

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

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

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

と書いている。

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

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

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

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

読め。

ウィキノミクス

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

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

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

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

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

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

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

ソフトウェア企業に勤務している人々はソフトウェア企業がオープンソースと言う破壊的イノベーションに侵食されている事実に早く気がついたほうがいいと思う。

自分は関係ないというのは単なる願望で、事実はそうでない。

この潮流は誰にも止められない。

産業経済における知識の独占が急速に崩れつつあるときに企業はどのように行動すべきか。もちろん答はでていないし、完璧な回答というのも見出されていない。

社内に研究開発の組織を持つのではなく社外にそれを求める。そんなことがありうるのか。そんなことを実施できるのか。それによってビジネスを行なえるのか。多くの人は戸惑いいぶかしく思う。

資本主義が高度に発達した結果、地球規模のコラボレーションのインフラを我々は手に入れた。著作権をはじめとする財産権の概念も我々の幸福を追求するために様々な変容を迫られている。

社会的共有資本としてのオープンソースを位置つけたときそれを健全に発展させるにはどのような制度設計が必要なのだろうか。社会としてのコンセンサスをどのように醸造させるべきなのだろうか。

それは、ウィキノミクスという潮流に乗り遅れまいとビジネスパーソンをあおるのではなく、もう少し大所高所から、「カネ儲け」だけではない何物かを、議論すべきではないか。

公的基盤と私企業のバランス。それをどのようにすることが地球規模での幸せにつながるか。

インターネットは誰にも所有されていない。誰でも自由に使える。このアナーキーなメカニズムによって芳醇なコミュニケーションのメディアを我々は手に入れた。

地球規模のマスコラボレーションを当たり前のように空気のような存在として使いこなす人々が間違いなく増えている。

その人々は企業という枠組みをいとも簡単に乗り越える力を持つ。そのような世界ができつつあるのである。

書評 - ウィキノミクス/404 Blog Not Found
http://blog.livedoor.jp/dankogai/archives/50835758.html

イノベーションのジレンマ

先日、「オープンソースは資本主義の破壊的イノベーションである」などと書いたのであるが、イノベーションのジレンマをぱらぱらめくってみた。
http://blog.miraclelinux.com/yume/2007/08/post_7b5e.html

破壊的イノベーションによって破壊された企業に勤めていたという個人的な体験からか、この本に書かれている事例はインサイダーから見ても非常に興味深い。

あなたは、あなたの会社の基幹製品がいとも簡単に破壊的イノベーションにより破壊されていくさまを経験したことがあるだろうか。その貴重な経験からあなたは何を学ぶのだろうか。

収益が悪化し大幅な赤字を記録した企業の常としてコアビジネス以外を売却する。DECの場合は、教育ビジネスであったり、ストレージ部門であったり、DEC Rdbのようなソフトウェア部門であったりする。資産を売却するので一時的なバランスシートの数字は好転するが、もはや自立的な復活は望めないデススパイラルに陥ってしまっている。そしてこのスパイラルにはまった企業で復活した例はほとんどないとクリステンセンは指摘する。

そのプロセスの中で、希望退職プログラムなどを含め社員がどんどん辞めていく。破壊された企業から破壊する企業へと人材は流動する。

わたしはDECを94年に退職し、日本オラクルへ転職したわけだが、その典型例と言っていいかもしれない。その当時は全く意識していなかったのだが、Oracleのデータベースはクリステンセンの言う破壊的イノベーションそのものであった。

Rdbチームに身を置いていたものとして当時のOracleのRDBMSは冗談としかいいようがなかった。性能はプアだし、機能も貧弱だ。信頼性もサポートもお話にならなかった。しかし、仮にそうだとしてもOracleは破壊的なイノベーションであった。顧客はもっと簡単に利用できるRDBMSを求めていたし、様々なハードウェアやOSで走るOracleに魅力を感じていた。DECのRdbを購入すればVAX/VMSというマシンにロックインされてしまう。それはもはや価格競争力の低いハードウェアプラットフォームであった。

Rdbチームが感じていたものは典型的な持続的イノベーション企業にいるものの典型的な反応である。自分たちのビジネスが破壊されつつあることにいかに鈍感であるか。

破壊的イノベーションというのは画期的な技術による破壊ではない。技術そのものはむしろ未熟で改良の余地が多いが、ローエンド市場ではそれでも十分であったり、まったく新しい市場では破壊的な力を持つ。

それにしても恐ろしい話である。

皆様にはじっくり読んで頂きたい教科書である。

オープンソースは資本主義の破壊的イノベーションである

というフレーズを通勤電車で思いついたのだが、そのときは結構いけていると思ったのだが、今考えてみると、それほどいけていない。夢を見ている最中はすげーなこれと思っていて、次の日、目が覚めてみると一体どこがすごいのかと思うようなものである。

破壊的イノベーションは持続的(改良的)イノベーションとことなって、まるっきり新しい市場を開拓し、既存の支配者を駆逐する。あるいはローエンド市場から参入し、既存の支配者を市場から追い出す。みたいな事が教科書には書いてある。

オープンソース的な世界では、著作権を私有するのではなく、共有することによって価値をたかめる。著作権という財産権を否定しちゃったら資本主義ではないではないか、とか思うのがフリーソフトウェアの思想を最初に聞いたときの素朴な感想であったりする人は少なくない。

財は共有すると減る。お菓子をあげれば自分の分が減る。お金をあげれば自分の分が減る。ところが情報は共有しても減らない。価値も減らない。だったら私有することにどれだけ意味があるのか。むしろソフトウェアのようなものはみんなで利用した方が得ではないか。

実際、趣味で作ったプログラムなんかを公開して勝手に使ってもらうというのは昔からおこなわれていたことで、ちょっとしたツールなんかも普通に無料で流通していた。

企業がちょっとしたツールを製造、販売なんかしようとした日には、値段が高くなってしまって全然売れないか、値段を安くすればもうからないので、そのような市場は、企業にとっては全然魅力的ではない。無料ないしは廉価なソフトウェアの独壇場という感じになる。利用してもらうには、無料ないし廉価というのが必須であったりする。

シェアウェアのような一人のプログラマが趣味(？)で作って、廉価で売りだすソフトウェアは企業のような様々なオーバヘッドがないので、数千円程度の価格でも十分ペイするコスト構造になっているし、需要もそこそこ存在する。

オープンソースソフトウェアも当初はローエンド市場や、インターネットという新市場にこっそりと参入し、企業が提供しない価値を無料で提供していった。企業にとっては、そのような市場は魅力的ではないので放置していた。

オープンソースソフトウェアでは、利用されることによって、新しい利用方法が生れ、バグが発見され修正される。導入コストが無料であることで利用は広がった。

Linuxも当初は趣味のOSであったし、企業が要求する機能をもたないOSであったのだが、無料という究極の価格によって、サポートを必要としない個人や、自らサポートできる技術者によってどんどん利用されるようになった。ローエンド市場の破壊的イノベーションであった。

Linuxの特徴的な事は、その開発がインターネットを媒体としたコミュニティという得体の知れないものが行なっている点である。一企業の戦略とか意志とかにはおかまいなく誰かが意思決定をしてそれを開発しているのではない点である。

ソフトウェア開発における破壊的イノベーションでもある。ソフトウェア工学ではウォータフォールモデルとかオブジェクト指向設計方法とかパターンとか数々のモデルが銀の弾丸として提案されたが、それらは全て持続的イノベーションであった。

ソフトウェア開発モデル的にも当初は数人程度の貢献者からなる小規模開発からはじまり、ソフトウェア開発におけるローエンド市場と言ってもいいかもしれない、いつのまにかに数千人の貢献者を持続的にひきつけるハイエンド市場まで席巻しているのである。

OS市場において、既存のプレイヤーは駆逐されつつある。

情報はフリーになりたがっている。おそらくこの流れは誰にも止められない。誰かが情報を独占しようとしても、他の誰かが同様なものをフリーで提供する。その結果、誰にも独占できないフリーな世界が構築される。

資本主義がフリーな情報流通というチャレンジを受けている。私有財産を認めることにより技術革新を促進するのが資本主義ならば、情報をフリーにすることにより技術確信を促進するのがオープンソースである。

この過激な思想が21世紀の技術革新の一旦を担っているという事が非常に興味深い。

オープンソースが資本主義の破壊的イノベーションである所以である。

どのように資本主義がオープンソース的なものとおりあいをつけるのか。疑問はつきない。

なぜウェブは資本主義を越えるのか
http://itpro.nikkeibp.co.jp/article/Interview/20070802/278983/

LL魂

夏の祭典。LL Spirit (LL魂)  に行ってきた。

個人的な感想など。

昨年のLLゴングのパイプ椅子は、おじさんには拷問に近いものがあったが、今年のホールの椅子は適度に座り心地もよく快適であった。実行委員会の皆様、ご苦労様でした(ぺこり)。

和田先生は、あいかわらづお元気そうでなによりだった。ステーブンレビーのハッカーズの話からはじまって(この本はハッカー倫理を知るうえで重要なテキストなのである)、ハッカーズ大辞典などを紹介しつつ、ハードウェアハック(微分機械(？)って何みたいな)のお話など、大変楽しい講演であった。帰宅してから先の2冊を本棚からとりだしパラパラめくったのは言うまでもない。

しかし、オレ様言語の作り方でパネルディスカッションができちゃうほど日本という地域にはオレ様言語をつくっている人がいっぱいいるのね。すげーな、本音できたよ。という感じである。

学校でコンパイラの作り方とかは習うけど、オレ様言語を作ってしまえというような危険思想をうえつけられるということはまあない。オトナの事情というやつで、研究職に進む人には、言語では論文とおらないよ(これが殺し文句)、企業に行く人には、言語では食えないよ(これも殺し文句)。大抵はそれであきらめるのが良い子の姿である。

それにもかかわらづ、わらわらとオレ様言語一派が勃興しているのは、やはりRubyのまつもとさんの影響に違いない。諸悪の根源はまつもとである。

オレ様言語どころかハリボテOSと称してオレ様OSまで作ってしまう輩もわらわら居て、日本という地域の将来を深く憂えるものである。(これはまた別の話)

人の話を聞いていると、なかなか楽しそうである。オレ様言語という自分が神の立場になって、すべてを決定する世界観こそプログラミングの醍醐味のような気がしなくもない。(いかんいかん、だんだん危険思想にそまりつつある)。しかし寝る間もおしんでそんなことをしたら、体に悪そうだ。睡眠不足におちいりそうだ。仕事にも影響があるかもしれない。と考えるのがフツーのオトナである。

自分の世界観をオレ様言語に投影するというのは、これはやってみたものだけしかわからない快感があるらしい(伝聞)。危険な世界だ。麻薬みたいなものである。(とは言っても麻薬をやったことがないので、よくわからないのだけど)

自分も高校生くらいのときに、なんの役にたつのかわからないただプログラミングが楽しいというだけのプログラムを作っていたわけだが、モノ作りの原点というか何かを作りたいという欲求に素直になればオレ様言語作りというのも究極の趣味のような気がしないでもない。プログラミングを目的にしちゃいかんと、一方のオトナのわたしが囁くのであるが、一方のチョイワルオヤジ(死語)のわたしが気持ちイイことして何が悪いと囁くのである。和田先生なんて、一生(？)好きなことをやっていて世間から後指をさされていないではないか、そんな生き方もあるではないか、などと思ってしまう。

しかし、ただでさえ時間がないのに、人生のプライオリティのなかで、こーゆー無限地獄の趣味を持ってしまっていいのだろうか(オトナの判断)。しかし、金はかからないし、ギャンブルにあけくれて家庭崩壊ということではないし、まあいいんではないだろうか(悪魔のササヤキ)。と揺れ動くオヤジ心なのである。

LL魂というのは人の魂をわし把みにしてぐわんぐわん揺振るイベントなのであった。

恐しいイベントである。

(通勤電車の中でニヤニヤしながらオレ様言語を妄想していたというのはナイショである。)

LL Spirit 感想。トラックバックリスト
http://karetta.jp/article/blog/ll-spirit/132858/trackbackList#trackbackList

The Practice of Programming (プログラミング作法)

先日、K&RのThe C Programming Language （プログラミング言語C）は初心者が読む教科書としてはいただけないと紹介した。では、お勧めは何か。

ずばり、The Practice of Programming (Addison-Wesley Professional Computing Series)を推薦したい。（日本語訳はプログラミング作法である）

テスト、デバッグ、移植性、性能、設計の選択、スタイルなどのテーマ（プログラミングの実践(Practice of Programming)）という計算機科学の授業でまともに取り上げられなかったものを取り扱っている。

移植性の解説で、国際性(Internationalization)の項目を発見したとき、ああやっとK&Rの呪縛から逃れられるかもしれないと思ったものである。

If one lives in the United States, it's easy to forget that English is not the only language. ASCII is not the only character set, $ is not the only currency symbol, dates can be written with the day first, times can be based on a 24-hour clock, and so on.

（米国に住んでいる人は、英語が唯一の言語ではなく、ASCIIだけが文字セットではなく、＄だけが通貨記号ではなく、日付は日から記述できるし、時刻は24時間でも表現できるということを忘れがちだ。）

一般的な入門書に国際化についての記述を発見し、ああ、国際化というのがプログラムが持たなければいけないいろいろな性質のうちの一つになったんだなあと感慨深く思ったものである。

まあ、それはともかく、デバッグ、テスト、性能、移植性などプログラミング言語の教科書ではなかなかお目にかかれない項目でありながらとっても重要な事柄について真正面から取り組んでいるこの本はお勧めである。

The C Programming Language

プログラミング言語Cの教科書の定番と言えば、カーニハンとリッチーによるものが有名だ。K&Rと呼ばれていて、今だにそれを推薦する人もあとをたたない。

わたしの本棚にも2nd editionがある。黄ばんだ表紙の奥付を見ると95/8/12とメモしてある。渡米してすぐリファレンスとして購入したものだ。

プログラミング言語の入門書で最初の例がなにがなんでもhello, worldというもの、K&Rからの悪しき慣習である。

プログラミングの初心者が、プログラムをどう書くかという事を習う教科書として使うにはいただけない。いただけない理由は多分いくつもあるかと思うのだけど、プロフェッショナルから見てもいただけない記述がいっぱいある。

例えば if (c >= '0' && c <= '9') ... とかいうイディオムとか、 c - '0' なんていうイディオムがいたるところ(？)にでてくるのであるが、この手の文字コード(ASCII)に依存したソースというのが、後にソフトウェアの国際化という観点から否定されていったという歴史を知るものにとって、諸悪の根源は、ここにあったのかという思いである。

最初に習ったソースコードにそのようなイディオムがあれば何の疑問もなくそれを繰り返す。それを後から泣きながら直していくというのが国際化の歴史だったような気がする。

プログラムから文字コードの仮定をとりのぞく。文字コードが7ビットであるという仮定をとりのぞく。文字コードが一バイトであるという仮定をとりのぞく。言語(英語)や文化にまつわる様々な仮定をとりのぞく。

プログラムから文字集合に関する情報をとりのぞくのが文字集合独立(Character Set Independent)なプログラムなわけであるが、そのような概念が成熟していなかった時代の歴史的な著書として歴史学者的な観点から読みとくのが正しい読み方かと思うのである。

下記はお薦めである。

昔の日記にも似たようなことを書いていた。（１０年以上前のお話）

96/02/20 シリコンバレー日記 ソースコードを読む程忙しい
http://web.archive.org/web/19991005060157/http://www.best.com/~yoshioka/d/96/02/i960220.html

(文字コードをshift JISにして読んでください)

人月の神話と大聖堂とバザール

人月の神話を先日読みかえしたので、今度は「大聖堂とバザール」を読みたくなる。「大聖堂」で自分のはてな日記を検索してみると

蕎麦屋
http://d.hatena.ne.jp/hyoshiok/20060808#p1

大聖堂とバザール
http://d.hatena.ne.jp/hyoshiok/20040622#p2

というのを発見する。前者はどうでもいいよた話であるが、後者はそのものズバリという感じのものである。

山形浩生のCathedralを伽藍と訳すのは、どう考えても誤訳に近いと思う。世間では「伽藍とバザール」でとおっているが、わたしはあくまで「大聖堂とバザール」というタイトルにこだわる。人月の神話での挿絵は伽藍ではなく大聖堂だと思う。「大聖堂とバザール」に対するわたしのコメントを書く前に紙面が尽きてしまった。（うそうそ）

なぜソースコードを読むのか？／ユメのチカラ
http://blog.miraclelinux.com/yume/2006/08/post_3771.html

人月の神話

Frederick Phillips Brooks Jr., "The Mythical man-manth: essays on software engineering", Anniversary edition. フレデリック・Ｐ・ブルックス Ｊｒ．「人月の神話」新装版、狼人間を撃つ銀の弾はない。滝沢徹他訳

わたしが紹介するまでもなくソフトウェア開発の古典中の古典である。先日の「情報システム学会(ISSJ)、情報システムのありかたを考える会」での発表のために、久し振りに読みかえしてみた。

原書は1975年に出て、長いこと読み継がれてきて、今だにその指摘は古びていない事に驚かされる。16章からは、初版以降に書かれた論文、評論になるが、やはりこの書の本質は、初版時点で書かれた1章から15章であろう。

第1章「タールの沼」。大規模システムプログラム開発がタールの沼にはまってもがき苦しむ、恐竜やマンモスみたいなものだと記している。今でも、そのようなプロジェクトは枚挙に暇がない。ソフトウェア開発の難しさを端的にあらわしている表現である。

「新聞を読んでいると、二人のプログラマが改装ガレージで、大開発チームが最大限の努力で作り上げたものを凌ぐ重要なプログラムをいかにして作成したか、という記事をたまたま見つけることがある。(中略)
それなら、どうしてソフトウェア産業の開発チームはそうしたひたむきなガレージ二人組にすべて取って代わられてしまわないのだろうか」(第1章、4頁)

ソフトウェア製品とプログラムの作成の本質的な違いは、前者にはマニュアル、教育、サポート、継続的なアップデートなどがついていて、後者は単なる実行可能なプログラムというところにあり、前者を製作するにはプログラムを作るより大変な工数がかかるということにある。

ソフトウェア工学の歴史は、大規模なソフトウェア製品をいかにしてタールの沼にはまらないようにして作るかという歴史に他ならない。

「ソフトウェア産業がガレージ二人組に取って代わられてしまわない」というBrooksの指摘はある面、正しかったが、一方でインターネットやオープンソースソフトウェア(OSS)の発展は、「ガレージ二人組に取って代わられた」事例のようにも見れる。

1975年の時点で、世界(地球)規模のソフトウェア開発環境は存在しなかったし、それを見通すということは、Brooksであっても不可能である。しかし21世紀になって、地球規模のコラボレーションが可能になり、コミュニティによる開発というのが、ソフトウェア産業を取って代わるほどの影響力を持ちはじめているという点は指摘してもいいと思う。

確かに単一の銀の弾丸はなかったかもしれない。しかし、インターネットというメディアとコミュニテーによる開発というのは、「ガレージ二人組」が世界にインパクトを与える可能性がある事を示した点で意義深いものである。

Brooksはプログラミングがなぜ楽しいかという事も記している。

• 物を作り上げる純粋な喜び
• 他の人々に役立つものを作ることの楽しさ
• 複雑なパズルのような組み立て部品を完成させ、それが巧妙に転回するのを眺めるおもしろさ
• つねに新しいことを学ぶという喜び
• 非常に扱いやすいメディア(媒体)で作業する喜び。その上、プログラムというのは、詩人の言葉と違って、現実に動いて働きだす

一方で、プログラミングの苦しさも記している。

• すべて完璧にこなさなくてはならない。呪文の一字一句たりとも正しくなければ、魔法は使えない。
• 壮大なコンセプトをデザインするのは楽しいものの、シラミの卵ほどの微細なバグを見つけ出すのはそれこそ単純労働だということである
• あれほど長い間苦労してきた製品が完成時(またはそれ以前)には時代遅れに見えてしまうことである

OSSにかかわる多くの人は、プログラミングに楽しさを見いだしている。一方でプログラミングの苦しさを上手に回避している。一人で膨大な単純作業をやるのは苦しいが、コミュニティで開発すれば、それも苦ではないという事かもしれない。喜びは参加者の分だけ倍増し、苦しみは参加者の分だけ割引かれる。

Brooksの「人月の神話」は読めば読むほど味がでてくる名著である。

まだ読んでいない若い技術者にはぜひ読んでほしいと思う。強くお勧めしたい。

JavaからRubyへ

角谷さんからの献本。ありがとうございます。

これは、文字どおりJavaからRubyへの移行するにあたっての実践的なガイドとなっている。技術的な側面よりもマネージャが知らねばならない様々な問題について議論している。

この手の本はパターン言語として、新しいパラダイムとか技術を導入する時に注意しなければならないガイドとして読める。

例えば、Linuxを導入するには、情報収集をして、限定的な展開をし、広範囲な展開をする。とか。

7章「普及」。要員の育成、社内でのスキル育成、短期間での立ち上げ、来るべき日に備える、などなどはJavaからRubyへの移行じゃなくても参考になる。かなり一般的なお話だと言えよう。

Rubyが言語としての熱狂を得ているのは、このような書籍が出版されていることからもうかがいしれるが、大手国産ハードウェアベンダのレーダにはまだ映っていないようだ。大丈夫なのかな。

いづれにせよ、新技術を導入したいと思っている技術者にとって、上司を説得するのに便利な一冊となっている。買いだ。

Matz日記
http://www.rubyist.net/~matz/20070420.html#p04

かくたにのWiki 『JavaからRubyへ』サポートページ
http://kakutani.com/wiki/articles/?FromJavaToRuby

オープンソースソフトウェアの本当の使い方

リナックスアカデミーの濱野賢一朗さんと日立の鈴木友峰さんの新書である。献本ありがとうございます。

鈴木さんとは、日本OSS推進フォーラムのワーキンググループなどでいつもお世話になっていて、IPAでやったOSSの評価プロジェクトなどではご一緒させてもらったりした。

本書も単なるOSSの解説だけではなく、IPAのOSS評価プロジェクトで得られた知見などをおりこみ類書にない特徴をだしている。(第4章など)

第5章で「OSSの課題」にふれているが、OSSミドルの発展はリナックスのようにはいかないだろうとしている。リナックスの開発の多くが最近はハードウェアベンダなどに勤務するOSの専門家によってなされているというのはよく知られているが、OSSミドルにはそのようなメカニズムがはたらきにくい。例えば、データベース管理システムの専門家はOracleのような専業ベンダーに多数いるが、彼らがOSSのデータベースの開発に貢献するというのは考えにくい。リナックスの場合、ハードウェアベンダーにとってはハードウェアを売るためにリナックスの開発に投資をするというのはありえても、OSSミドルの場合はミドルウェアベンダがOSSの開発へ投資するというのは考えにくいという事である。

わたしもある程度同意するのであるが、OSSミドルの大手ユーザが開発者を雇用して機能拡張をするというシナリオはありえる。PHP/Perl/Rubyなどの開発者がWeb 2.0系の企業に勤めていたりするからである。MySQLなどの大規模事例では、エンジンそのもののチューニングなどもユーザがおこないつつあるのである。

第7章では、OSSの活用はSIベンダーの競争優位性になりうるという指摘はまったくその通りだと思う。

OSSのメリットについて手軽(？)に理解する一冊になっている。

フューチャリスト宣言

梅田望夫、茂木健一郎の対談集。

ブログでおびただしいほどの書評、感想、コメントがこれから記されるだろう。それに何をつけくわえるべきか。

梅田望夫特別授業「もうひとつの地球」を読むだけでもこの本を手にとる価値がある。ここに、この本の真髄、あるいは梅田の真髄がある。

未来は明るい。そう信じる心が社会を動かす。未来に対する強い意志が自分を変え社会を変える。梅田も茂木も楽天的である。未来に肯定的である。そして未来を作る意志を持つ。未来はどうなるかと予測するのではなく、未来をどうしたいのかを語る。

これからの未来を創る自分の娘に読ませて感想を聞きたいと思った一冊である。

http://www.chikumashobo.co.jp/special/futurist/

「フューチャリスト宣言」連休明けに発売
http://d.hatena.ne.jp/umedamochio/20070427/p1

「フューチャリスト宣言」いよいよ発売です
http://d.hatena.ne.jp/umedamochio/20070507/p1

「フューチャリスト宣言」増刷のお知らせ
http://d.hatena.ne.jp/umedamochio/20070509/p1

書評　フューチャリスト宣言/404 Blog Not Found
http://blog.livedoor.jp/dankogai/archives/50825977.html

ハゲタカ

NHKドラマ「ハゲタカ」にはまってしまった。6話のドラマで3月24日に放送終了しているので、既に4週間ほどたっているのにいまだに「ハゲタカ」熱にうなされている。

ハゲタカとよばれる外資系ファンドマネージャの鷲津（大森南朋）が「腐ったこの国を、買い叩く。買い叩く。買い叩く」

失われた10年。企業は出資者（株主）がすべての権力をもっているのだが、企業の価値は出資者だけではなく、経営者、従業員、取引先企業、顧客それぞれがあってこそ生み出される。

経営の効率が悪ければ、株主は経営者を入れ替えるようとする。昨今話題のTOBは、現経営陣に対し、もっと効率的な経営があるとして経営の変革を求める行動の一つだと理解すると分かりやすい。

１話は、老舗旅館「西乃屋」はバブル時にゴルフ場投資などをして、借金で首が回らない。ゴルフ場投資などしないで、ご贔屓のお客さん向けに手堅い商売を続けていればそんなことはなかったのだろうが、バブルの銀行は土地を担保にどんどん金を貸した（過剰融資である）。1998年銀行のバルクセールで西乃屋の債権を取得した鷲津は、旅館のオヤジ（宇崎竜童）の懇願も受け入れず、高値で売り飛ばす。

これに、旅館の跡取り息子の治（松田龍平）、東洋テレビの記者、三島由香（栗山千明）、債権を売った三葉銀行の担当者芝野（柴田恭兵）、三葉の役員飯島（中尾彬）らが絡む。

鷲津は若い頃、三葉の社員で芝野の部下だった。鷲津はその当時、小さな町工場への貸し渋り、貸し剥がしで経営者を自殺に追い込んだ過去を持つ。その町工場は三島の実家である。

２～３話は老舗玩具メーカー「サンデートイズ」。社長の大河内瑞恵（冨士眞奈美）を筆頭に、一族が会社を私物化する。公私混同で、会社の経費で放蕩三昧し経営悪化。いろいろあって鷲津は入札によりサンデー社を手中に収め、経営をよみがえらせる。

４～6話は、戦後カリスマ経営者大木昇三郎（菅原文太）によって創業された名門「大空電機」。企業再生家になった芝野。TOBで大空電機を手に入れようとする鷲津。これに、新興IT企業「ハイパークリエーション」社長となった西野治、由香、大空電機の創業部門であるレンズ事業部の熟練工、特級技術者加藤幸夫（田中泯）が様様な思いで絡んでいく。

「所詮カネなんだろう。ただの紙切れじゃないか」加藤は鷲津を挑発する。

1話目は、バブルに踊らされた、老舗の話。本業をまじめにやっていれば、無理な借金さえしなければ破綻しなかったパターンである。

2～3話は、創業者が会社を私物化し、経営を悪化させていくというパターンである。経営環境の変化に、創業一家がついていっていない。

４～６話は、カリスマ経営者が率いた名門電機メーカ。

企業はどうやって価値を生み出すのだろう。ハゲタカは買収した企業をより効率的な経営をする企業へ売り飛ばして、企業を蘇らせた。単なる利ざや稼ぎではなく企業再生としての役割を担っていたのである。

最終話で鷲津は加藤を中心にEBO（エンプロイーバイアウト）をしてレンズ部門を蘇させる。

鷲津を演じる大森がいい。狂気を秘めた治役の松田龍平もいい。シナリオが凄い。

企業とはなんだろうか。どう価値を生み出すのだろうか。そんなことをじっくり考えさせてくれる硬質のドラマだった。BShiで再放送されるそうだ。DVDも販売予定。

原作本とドラマの筋書きは異なるので別物として読んだほうがいいと思う。

渋谷で働くドラマディレクターの日記～土曜ドラマ「ハゲタカ」制作現場から～
http://www.nhk.or.jp/hagetaka-blog/

書評 - ハゲタカ　 ／404 Blog Not Found
http://blog.livedoor.jp/dankogai/archives/50792368.html

ハゲタカ～ROAD TO REBIRTH～ Part14
http://ex21.2ch.net/test/read.cgi/tvd/1176438579/l50

テストの参考書

ソフトウェアにおけるテストとは何か？端的に言えば、ソフトウェアの不具合を発見するための一連のプロセスである。
テストはソフトウェアの不具合を発見するプロセスなのだから、良いテストというのは効率よく不具合を発見するものであり、悪いテストというのは不具合を発見しないものである。
テストではプログラムのエラーを示すことはできるがバグがないことを証明することはできない。Myersの古典的名著「ソフトウェア・テストの技法 第2版」(最近第二版が発行された)では、成功したテストとはエラーを発見したテストであると定義している。なかなか強い立場である。

若い人の中にはを読んだことがない人がいるかと思うので、参考書として推薦しておく。
今度プロジェクトでご一緒する若手のエンジニアにはとりあえづMUSTで読めと言っておいた。

シリコンバレー精神

「ウェブ進化論」でおなじみの梅田望夫による「シリコンバレーは私をどう変えたか」の改題、文庫化したのが本書である。「シリコンバレー精神」が96年から2001年ごろの5年間、「ウェブ進化論」はその後という感じである。梅田望夫の原点がこの本にある。うれしいことに著者自らによる文庫本新規書き下ろしのあとがきが本書のインサイドストーリを解説している。

自らが書いたものを自らが解説すると言うのは究極の解説である。文庫本の解説と言うの無駄極まりない盲腸のような存在であって無駄がゆえにヨタ話としては非常に面白かったりするが、おめーはそれを見たのかよというような突込みを入れたくなるようなアバウトな解説もあったりして玉石混合である。

しかし、「シリコンバレー精神で本書を書いた」なんていうのは本人以外わかりようがないし、その後のエピソードなんていうのも本人だからこそ書けることである。新規書下ろし60枚のあとがきは間違いなくお勧めであり梅田望夫ファンには「ウェブ進化論」を解題する上で格好なテキストとなっている。

それはともかくシリコンバレーをシリコンバレーとして特徴付けていることを一つだけあげるとしたらそれは何か？5年前に本書を読んで、わたし自身も90年代当事者として生活した経験を持つものとして感じることは、梅田の言う「シリコンバレーの凄いところは、ナードを搾取しなかったことにある」につきる。

失われた10年を取り戻すために日本は様々な制度改革を行い仕組みとしての直接金融だなんだというのを整備し会社法を引き合いに出すまでもなく器としての起業支援というのが整ったようにみえる。産業活性化のためにベンチャー支援だ～というお題目が聞こえてくる。まあ、ありがたいことである。

頭のいい人たちはシリコンバレーの仕組みのコピーにうつつを抜かしているのだが成功したと言う話は聞かない。もちろんそれは半分は成功した。仕組みとしての直接金融とかベンチャーキャピタルとか株式上場とかの環境は整備されている。その意味で半分は成功した。もう半分のシリコンバレーを支配する精神について日本と言う地域で再現可能なのだろうか？

それを考えたい。

日本では文系理系という枠組みがあって政府の仕組みやら政治経済の多くはいわゆる文系が支配している構造になっている。ごく例外的に理系的な人々が重宝がられる分野があるが通常は文系のほうが（生涯）賃金も高いことが知られている。最近でこそ特許料にまつわる裁判などで理系が生み出した価値について再評価が行なわれているがまだまだ例外的である。

価値を生み出すのは人間である。コンピュータや機械が自動的に価値を生み出すわけではない。文系とか理系とか関係なく人間が価値を生み出す。ソフトウェアという得体の知れないものをあやつってそれに本能的とも思えるほどの才能を発揮するものを梅田は「ナード」と呼んでいるが、シリコンバレーの凄みはそのナードを搾取しなかったことにある。そして徹底的に彼らが価値を創造する環境を整えた。

プロフェッショナルとして成長していくためのコミュニティ、大学を始めとする智の実験場、人材の流動性、人材評価システム。そこぬけの楽観性。

梅田はオープンソースの未解決な問題を7つあげた後、次のように書く。

「これらに共通する本質的課題は、ナード世界とビジネス世界の新しい関係の構築にある。そしてそのためには『ナードたちはなぜプログラムを書くのか』という哲学的問いに答える努力をしていかなければならないのだ。
　しかしその問いに対する答えを、日本で考えることはできない。なぜなら日本社会や日本企業は、ナードの価値を全く理解せず、ナードを大切にしてこなかったし、今も大切にしていないからである」（ナードの価値、186ページ）

99年に日本に戻ってきてひょんなことからミラクル・リナックスの創業に関わった。そしてその時来わたし自身への宿題は、日本という地域でシリコンバレー的な精神を再現することは可能なのだろうかという問いかけである。まだ結論は出ていない。しかしインターネットとオープンソースという潮流はそれを可能にするとわたしは考えている。もちろん一社だけでできることは限られているが少しずつ仲間を増やしナードの価値を理解し大切にする社会を作りたいと考えている。