ユメのチカラ

取締役退任。生涯一プログラマ宣言。

hyoshiok — 2008-07-01T13:30:00+09:00

6月30日臨時株主総会において、ミラクル・リナックス株式会社の新取締役として、児玉崇、伊東達雄を選任し、それに続く、取締役会議により、新しい代表取締役として児玉崇を選任した。佐藤武前代表取締役社長は、取締役会長へ、わたしは取締役を退任した。

ここにご報告する。

さて、ここからが本題(？)である。取締役を退任したからといってミラクル・リナックスを辞めるわけではない。今後は経営者という責任ある立場を退き一技術者としてミラクル・リナックスに貢献していく。

2000年6月にミラクル・リナックスを創業以来8年にわたって取締役CTOとしてミラクル・リナックスとともに歩んできたが、取締役というよりも、技術屋としてミラクル・リナックスのV1.0の開発、OSDL (Open Source Development Lab -- The Linux FOundationの前身)への参画、そしてAsianuxプロジェクトの立ち上げ、さらには未踏ソフトウェア創造事業や日本OSS推進フォーラムのサーバ部会での仕事などが思い出深い。取締役として経営に貢献したというよりも技術屋としての立場だったかと思う。正直言えば、経営者としては力不足であった。

8年前にはLinuxをエンタープライズ分野で利用するなどというのはほとんど冗談のように受けとられていた。誰が氏素姓のわからないフリーソフトウェアを企業の基幹システムに利用するのか。サポートはどうするのか。どのようにスケーラビリティを確保するのか等々。それぞれの課題について一つ一つ解決していったのがこの8年だったと思う。

オープンソースソフトウェアという未開の耕地にビジネスの種を植えた8年であった。

今後は一プログラマとして会社やコミュニティへ貢献していきたい。今年でわたしは50歳になる。いい年したおっさんである。とっとと技術屋なんかは引退してマネージメントの仕事でもしていろよという声も聞く。40代はミラクル・リナックスの取締役としての立場(？)もあったわけだが、それも退任したことだし、50代は、わがままを言って現役のプログラマに戻してもらった。はたしてプログラマとして使いものになるのか、ならないのか、不安がなくもない。この年で新しいことにチャレンジすることの難しさも知らないわけではない。

人生、綺麗事ばかりではない。いいこともあれば悪いこともある。上手くいくこともあれば上手くいかないこともある。成功もあれば失敗もある。家族には苦労をかけて申し分けないと思う。給料も役員報酬がなくなったので減ってしまった。子供の教育費も家のローンもある。

それでもと、思う。人生再チャレンジである。いくつになってもチャレンジである。

潔くない生き方かもしれない。ばたばた足掻いている。この歳でまだプログラマに拘るというのも相当見苦しい。でも、それがわたしなんだよなあと思う。

現在のプロジェクトはMID (Mobile Internet Device)向けのOS開発である。Intel Atomプロセッサ用のOS (Asianux Mobile Midinux)の開発を行なっている。20代の若手エンジニアの隣に座って日々ブートがどうだとかドライバが動くとか動かないとかをやっている。新人プログラマの一人として毎日勉強だ。grubのソースを読んだりsyslinuxのソースを読んで、SSD(Solid State Disk)が認識したとかしなかったとか一喜一憂している日々である。

カーネル読書会も続ける。このペースで開催していけば来年には100回になるだろう。第100回はゲストにLinusを呼びたいと思う。こんな事を言うと多くの人は笑う。だけど言葉にして言う。Linusを呼ぶことは簡単ではないけど不可能ではない。

次の10年自分はどのように生きたいのか。経営者ではなく一エンジニアとして生きいくのが自分の長年のユメであった。

ハッカーになりたい。ソフトウェアによって社会をよい方向へ変えたい。

こんなことを言うと頭がおかしいのじゃないかと言われる。暑苦しく、うざいと思われようとも、そのような人生をおくっていきたい。50代でプログラマを続けることは日本という地域では簡単ではない。そのくらいのことは理解している。道は遠く険しい。だけど、それも不可能ではないとも思う。職業としてのプログラマに誇りを持って生きていきたい。

日本に一人くらい、こんなへんなおやじのプログラマがいてもいいと思う。そういう我儘を許してくれるミラクル・リナックスそして家族には大変感謝している。

これがわたしの生涯一プログラマ宣言である。

皆様のご指導ご鞭撻よろしくお願いいたします。

第88回カーネル読書会のおしらせ

hyoshiok — 2008-06-29T22:26:49+09:00

日時：07月04日、18時半開場、19時ころ開始
会場：ミラクル・リナックス、セミナールーム

お題: Googleの基盤クローンHadoopについて
発表者: 東京大学太田一樹さん
内容：
Googleでは１日に何Tものデータが処理され、検索・広告等のサービスに活か
されています。このような膨大なデータを処理する為の基盤技術としてGoogle
File SystemとMapReduce が使われている事が論文で発表されています。今回
はそのオープンソースクローンであるHadoopの概要と実装について発表します。

18:30頃、開場
19:00頃、お題開始
20:00頃、懇親会開始

場所はいつもの、ミラクル・リナックス社セミナー会場地図
http://www.miraclelinux.com/corp/about/maps_google.html

開場した後は、だらだらと自己紹介やら小ネタやらをやりますので、時間の許
す限り早めに来た方が面白いお話をきけるかもしれません。

会場で、ピザとビールの懇親会つき。（予定価格1200円(微妙に値上げ)）
懇親会参加希望の方は、懇親会参加と明記してください。

会場の都合で35名で締切ます。

なおセミナー内容につきましては、にこにこ動画などで配信予定です。
ustream.tvでのインターネット中継も可能であれば実施します。
チャンネル名は未定

登録はいつもの宴会君
http://utage.org/enkai/
宴会コード kernel080704

ＹＬＵＧ年表
http://www.ylug.jp/modules/pukiwiki/index.php?history

ＹＬＵＧ会合、読書会資料
http://www.ylug.jp/modules/pukiwiki/index.php?reading

Emacs勉強会 - tokyo-emacs

hyoshiok — 2008-06-29T10:49:26+09:00

Emacs勉強会に参加した。なんやかんやで30人を越える参加登録である。

自分は随分昔からEmacsを利用しているのだが、全然使いこなしている感じがしない。最近、Emacsを勉強しなおそうと思っていたので、早速参加することにした。

http://wiki.livedoor.jp/harg/d/FrontPage

Emacsの基本を勉強しなおそう市民連合(笑)の代表として一言挨拶をした。今回は同市民連合の決起集会(嘘)なので、大いにアジったのであるが、みんなでEmacsの基本を勉強しなおしたいと思った。

早水さんのEmacs Lisp講座は初心者に向けての優しい講座であった。

メモをはりつけておくが、これだけじゃあ、何が何だかわからないなあ。

Emacs Lispは怖くない
括弧は空気
EmacsのことはEmacsに聞け
ヘルプの使い方
Lispは単純
リストが全て
ドット対
関数名と変数名の名前空間は別

実践編
.emacsを眺める
(server-start)
ansi-term
入門書
もうひとつのScheme入門
独習Scheme三週間
プログラミングGauche
---------------------

files.el

K1LoW
moz.el
pabbrev.el
dabbrev.el

drill-instructor.el

yuki_neko_nyan
yasnippet

jj1bdx
face
color-theme

IMAKADO
anything
補完が凄い

Misho
Emacs for Latex

naoya_t

.emacs
IMAKADO

Emacsについて語り合う人が自分のまわりにいない人達にとってtokyo-emacsはとてもいいところだ。大変勉強になった。懇親会で、メモ用紙にマクロの解説をしている早水さんや、それを囲んでわいわいがやがや議論している。楽しかった。またやりたいと思った。

早水さん、参加の皆さんお疲れさまでした。ありがとうございました。

追記：資料を公開した。tokyo-emacs-080628.pdfをダウンロード

Googleを支える技術

hyoshiok — 2008-06-18T23:26:29+09:00

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

セキュリティ＆プログラミングキャンプ2008

hyoshiok — 2008-06-06T00:15:09+09:00

ソフトウェアは人が作る。人がすべてだ。

若い人が魅力を感じなければその産業は衰退する。若い人にとってソフトウェア産業が魅力的なものだということを我々はもっと伝えないといけない。ビジョンを示し、その魅力を伝える努力をしないといけない。

一方で少しでも興味を持ってくれた人にソフトウェアを作ることの楽しさおもしろさ難しさを伝えることも必要だ。

人材育成だなんだと大げさにとらえるのではなく一緒にプログラミングの楽しさを経験したい。初心に戻ってプログラムを初めて作ったころの感動を体験したい。

22歳以下の皆さん。

あなたたちのために、そのような合宿を企画した。

セキュリティ＆プログラミングキャンプ2008 http://www.jipdec.jp/camp/

『若年層のセキュリティ意識の向上と優秀なセキュリティ人材の早期発掘・育成』という目的で2004年からやっているセキュリティキャンプがきっかけだ。合宿形式で行うセキュリティ人材育成のイベントのプログラミング版だ。

U-20プログラミングコンテストで若い人たち（中学、高校生）のプログラムを読む機会があるが、やはり回りに相談する人がいないのか、プログラムの基礎的なことなどの理解が足りていない。例えばif文を延々と重ねて処理をするとか、いたるところに数字（定数）が書かれていたりとか、そーゆー力ずくのコードを目の当たりにみて、コードを書くにしても基礎的なイロハの伝授が必要であるということを痛感していた。

コードの書き方だけではなく、デバッグの仕方とか、gitをはじめとする分散バージョン管理システムあるいはOSSを前提としたコラボレーションのちょっとしたコツとか、必ずしも明文化されていないがとっても重要なことについて学ぶきっかけを作りたかった。

もちろん、その先にあるプログラムを作ることの楽しさ、達成感、充実感なども共有したい。

わたしのミッションステートメントをここに記す。プログラミングキャンプ宣言だ。

* オープンソースソフトウェアを開発する元気のいい若手プログラマを輩出したい。
* 単にプログラミングテクニックが凄いというだけではなく、コミュニティのリーダとして、人々の話をよく聞き(コミュニケーション能力)、信頼されるようなプログラマを輩出したい。
* 彼等が今後の核になってさらに新しい人材を発見発掘するというエコシステムを作りたい。
* 彼等が新しい価値を創造し、世界から尊敬されるような人々になって、日本という地域が、そのような人々が集まるような場所にしたい。

10年で200人。

これが、わたしのユメだ。

そのような若者を雇用するビジネスを作るのが大人の役目である。

多くの若者の応募を待つ。

勉強会のこと

hyoshiok — 2008-06-04T10:10:34+09:00

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

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

まあ、感覚的には結構頻繁にいろいろやっているよねと思っていたのだが、下記の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に参加した時のレポートだ。発表がニコニコ動画にアップされているのも嬉しい。インターネットのおかげで時間も空間も超越できるようになった。

Linux World Expoのパネルディスカッションに参加します

hyoshiok — 2008-05-28T13:24:37+09:00

明日(5月29日)、Linux World Expoのパネルディスカッションに参加します。

http://www.idg.co.jp/expo/lw/lw2008/details/index.html#a27

日本SGIの高澤さんの司会で、キヤノン株式会社、志田惠昭さん、横河フィールドエンジニアリングサービス株式会社、丸茂晴晃さんらと人材育成をテーマに議論する予定です。

どんな話になるかは、その場のノリみたいな感じが強いのですが、お時間ありましたら、参加してください。

群衆の叡知(えいち)サミット2008 - (WOCS2008Spring)

hyoshiok — 2008-05-22T10:54:13+09:00

群衆の叡知サミット2008に参加した。http://techstyle.jp/wocs/2008spring/

パネリストはわたしも含めて下記の方々。
# 伊藤久美氏（IBMビジネスコンサルティングサービス株式会社）
# 伊藤直也氏（株式会社はてな）
# 伊藤佳美氏（日本ユニシス株式会社）
# 生越昌己氏（WASP株式会社）ブログ
# 楠正憲氏（国際大学グローバル・コミュニケーション・センター）
# 鈴木友峰氏（日立製作所）
# 田代秀一氏（独立行政法人情報処理推進機構）
# 谷川正剛氏（株式会社Prediction）
# 徳力基彦氏（アジャイルメディア・ネットワーク）
# 西田隆一氏（CNET Networks Japan）
# 福岡秀幸氏（日本電気株式会社）
# 山口浩氏（駒澤大学グローバル・メディア・スタディーズ学部）
# 吉岡弘隆（ミラクル・リナックス株式会社）
# チェア：岡田良太郎氏（株式会社テックスタイル）

ustream.tvでの中継(今回はじめての試み)、会場から携帯を利用した集計システムなどインタラクティブな仕掛、休憩時間にはアイスクリーム(美味)やドーナツの配布、ドリンクサービスなどいたれりつくせりのおもてなしでなかなか楽しいイベントであった。

http://www.ustream.tv/channel/wocs2008spring

セッションの内容についてはustream.tvで確認いただくとして、今回参加したなかでいろいろ感じたこと主張したことなどを雑駁ではあるが記してみたい。

オープンソースについて

群衆の叡知あるいは集合知の成功例としてオープンソースソフトウェアという認識のもといろいろ議論をさせていただいた。

オープンソースソフトウェア特にLinuxの成功については鈴木さんのプレゼンが上手にまとまっていると思った。のちに生越さん(おごちゃん)がオープンソースはお花畑かよ、というツッコミがあったが、それはそれとして、成功例の一つとしてLinuxがあることは間違いない。

群衆の叡知が成立する条件として、参加者の多様性、独立性、分散性、集約性などが担保されている必要がある。

Linuxの場合、gitという分散バージョン管理システムで、ソースコードを管理しているが、そのログによれば、2.6.12から最新版までに、約97000のパッチが約4000人の人達によって投稿されている。emailアドレスによる分析では250を越える所属(会社など)。

Top changeset contributors by employer        
(Unknown)        28613     (29.6%)
(None)            9034     (9.3%)
Red Hat           8029     (8.3%)
Novell            7518     (7.8%)
IBM               6683     (6.9%)
Intel             3201     (3.3%)
Linux Foundation  2800     (2.9%)
SGI               1824     (1.9%)
Oracle            1471     (1.5%)
SWsoft            1353     (1.4%)
Others           26300     (27.2%)
Processed 96826 csets from 4032 developers
257 employers found
A total of 14088649 lines added, 4699892 removed (delta 9388757)
as of 5/16/2008

この例からも分るとおりLinuxの開発は参加者の多様性、独立性、分散性、集約性などがある。

特筆すべきは、4割近い人々(所属がUnknownないしNone)が、業務としてパッチを投稿しているのではないという事である。昨今Linuxの開発は大企業によって推進されているという指摘もあるが、確かにその側面もあるにはあるが、Red Hat/Nobel/IBMという御三家それぞれ10%以下のシェアであり、今だに多くの貢献は、個人ないしは小企業に属する人々によってなされているという典型的なロングテールの開発であるという事である。

4000人の開発者はどのような思いで、そのパッチを作ったかは4000通りの回答があると思う。仕事であったり純粋に楽しみであったり人それぞれである。それを集約したのがLinux Kernelという事になるかと思う。

社内ブログと人材流動性

群衆の叡知が成立する条件として、参加者の多様性、独立性、分散性、集約性などが担保されている必要があると先にのべた。

企業内で、SNSや社内ブログで、叡知を結集するためには、上記の条件を意識してクリアしないといけない。そこが社内SNSなどの難しさの一旦である。またイノベーションが発生するためには、何らかの形でも新しい結合(出会い)が必要で、部門間を越えた結合を制度として設計し実装することが必要条件となる。NECの福岡さんの報告にあったようにNECの社内SNSはそれをファシリエータと呼ばれる人々によってドライブしているようである。

福岡さんは、社内SNSなどをEGM (Employee Generated Media)という概念で説明していた。さらに、会社の枠を飛び越えたEGMの可能性を指摘していたが、正直ビジネスの分野では非常に難しいと感じた。

そのような知恵は、会社に所属するのではなく個人個人に属するものだと思う。であるならば、その属人的な知恵は会社内あるいは会社間SNSで閉じ込めるのではなく広く公開したほうが社会にとっても有益である。しかし、暗黙知を形式知にするようなもので、それはそれで難しい。であるならば、人材流動性を前提として、その属人的な価値を、人材とともに流通するような仕組を考えた方が実現可能性が高い気がする。

日本の労働慣行は、長期間な雇用を前提としている。終身雇用と言わないが2年半で会社を変えるというスタイルではないので人とともに重要なノウハウが業界でゆるく共有されるということもない。

一方シリコンバレーのIT産業であれば、例えばRDBMSの実装について、人々の転職によって、業界全体で緩く共有されている。あるいは大規模トランザクション処理のTipsが緩く共有されている。さらに共有基盤としてOracleなどの商用ソフトだけではなくMySQLなどのOSSを利用した運用ノウハウがコミュニティの暗黙知として様々な形で流通している。

そして上記のような状況がシリコンバレーの地域的な競争力を高めているとするのなら、日本という地域でも意識して、人材を流動させることにより、その環境を作ることが可能なのではないか。

事実、大企業ではなくWeb2.0系の会社(はてな、mixi、ドワンゴ(ニコ動)、Gree、ライブドア、Yahoo等々)に所属する若手のエンジニア達は、いろいろな勉強会あるいは読書会などで、自分たちの問題を等身大で語り初めているではないか。隣に座ったPerlのエラい人達と対等に語りあっているではないか。ビジネスとしては競合する会社に勤めている人達が同じ場で自由に情報交換をしている。

そしてOSSの利用技術について暗黙知を形式知に転換したり、バッドノウハウとして情報交換している。

まさに、そこに集う人々は多様性、独立性、分散性、集約性などが担保されている状況が発生しつつある。

東京という地域では、結果として、そのような技術者のルツボがあり、新しい出会いがあり、イノベーションの萌芽が、見られる。

感想など

まだまだ語りたいことはてんこ盛りなのであるが、紙面がつきたので、このくらいにしておきたい。

最後になったが、素晴しい機会をあたえてくれた岡田さん、気持のいいおもてなしをしていただいたスタッフの皆さん、活発な議論をしていただいたパネリストの皆さん、ustream.tvでの参加者、そして会場に参加していただいた皆さん、大変ありがとうございました。皆さんのおかげで大変楽しい時間を過したと共に自分の考えをまとめるキッカケ、気付きのヒントを多数いただいた。お腹いっぱい、すっきりしました。

ありがとうございました(ぺこり)

付録：Linux Kernel Source Codeの分析について

下記にあるgitdmというpythonのスクリプトを利用した。pythonおよびpython-egenix-mxdatetimeなどのパッケージをインストールしておく必要がある。
http://www.kernel.org/pub/linux/kernel/people/gregkh/kernel_history/

Who wrote 2.6.20? 誰がlinux 2.6.20を書いたのか？／ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/who_wrote_2620__4b18.html

カーネル読書会／ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/post_da8e.html
GregKHがLinux開発者のプロフィールの分析を発表した。後のOttawa Linux Symposiumでの論文のモトネタとなる。

Greg KHの論文
http://ols.108.redhat.com/2007/Reprints/kroah-hartman-Reprint.pdf

追記：WOCS2008springに言及のあるブログ、日記など。

歌舞伎町で遇ったギークなタクシー運転手の編み出した、群衆の英知を活かした馬券購入法/雑種路線でいこう
http://d.hatena.ne.jp/mkusunok/20080521/wocs

群衆の叡智サミット2008Spring行って来た/public static void main
http://d.hatena.ne.jp/Kishi/20080522/1211419795

第87回カーネル読書会のおしらせ

hyoshiok — 2008-05-20T20:34:35+09:00

毎度おなじみ流浪の番組、カーネル読書会のご案内です。

今回は場所を日本SGIホールにしました。初めての方もそうでない方も奮ってご参加ください。

第87回カーネル読書会のおしらせ
日時：05月23日、18時半開場、19時ころ開始
会場：日本ＳＧＩホール、恵比寿ガーデンプレースタワーＢ１Ｆ
http://www.sgi.co.jp/company_info/map1.html
(場所は恵比寿ですのでお間違えのないよう)

お題：Linux Network Stack
　〜UDPメモリ管理の改善とNetwork Subsystemの現状と課題〜
発表者：大島　訓さん（日立製作所システム開発研究所Linux Technology Center)
概要：　
　2.6.25で採用された「UDPのメモリ使用量を計測し、上限を設定する機能」について、開発の動機、netdevでの議論の経過、実装、裏話についてご紹介します。また、Linuxのネットワーク
機能の現状を整理し、今後取り組むべき（と私達が考えている）課題をご紹介します。
　今回の内容は、3月にLinux Foundation Japan Symposiumで講演した内容がベースですが、YLUG向けに”濃い”話をします。

18:30頃、開場
19:00頃、お題開始
20:30頃、懇親会開始

場所は日本SGIホール、恵比寿ガーデンプレイスタワー B1F
http://www.sgi.co.jp/company_info/map1.html

開場した後は、だらだらと自己紹介やら小ネタやらをやりますので、時間の許す限り早めに来た方が面白いお話をきけるかもしれません。

懇親会はいつもの銀座ライオンが予約とれなかったので、旬鮮料理ＪＯＥ（じょう）其の壱。http://r.gnavi.co.jp/g169302/ 飲み放題コース(予定価格5000円) 、学生さんは1000円ポッキリ予定。(懇親会の会場が変更になっているので注意してください。)
懇親会参加希望の方は、懇親会参加(学割希望者はそれも)と明記してください。

会場の都合で90名で締切ます。

登録はいつもの宴会君
http://utage.org/enkai/
宴会コード kernel080523

ＹＬＵＧ年表
http://www.ylug.jp/modules/pukiwiki/index.php?history

ＹＬＵＧ会合、読書会資料
http://www.ylug.jp/modules/pukiwiki/index.php?reading

git入門

hyoshiok — 2008-05-17T17:50:48+09:00

社内勉強会でgit入門をやった。(参考資料をダウンロード )。

最近の開発でgitを使っているので、そのファーストインプレッションみたいなものである。マニュアルについては、日本語訳もあるので参考にしてほしい。

分散コード管理システムということで従来の集中コード管理システムとその使い勝手が相当違うように感じる。

基本的な使い方は、リモートにあるリポジトリをローカルにコピーして、そのコマンドをgit cloneというのだが、そのレポジトリに対してチェックアウト、チェックインを繰り返し最後にリモートのリポジトリにコミットするという感じである。

基本的には、集中型とそう違わないのであるが、精神的には随分違うという感じがする。

まず、変更はローカルのリポジトリにずんずん行なうという点。ローカルのレポジトリにずんずん行なうので、その時点でリモートにアクセスできなくてもいい。ノートパソコンにレポジトリを用意して、電車の中や街中でちょっとした変更をして、それをノートパソコンのローカルなレポジトリにずんずんコミットする、なんていう使い方ができる。

そこまでモバイルな使い方ではなくても、通常だったら、次のような感じかと思う。まづプロジェクト用リポジトリを準備して、各自は自分の開発マシンにリポジトリを置く。そして、個々の担当は自分のリポジトリにどんどんコミットする。テストが終った変更(コミット)に関しては自分のリポジトリからプロジェクトのリポジトリへpushする。

そんな感じである。

まだ、ありがたみが伝わらない？うーむ、説明が下手ですいません(ぺこり)

基本的には変更はブランチで行なう。ブランチが原則、前提。Linux Kernelの開発のように多数のプログラマによって独立に開発がおこなわれているというプロジェクトの場合、このブランチが原則というのは大変理にかなっているように思う。

また管理の対象もコミット単位(ファイル単位というよりも)というのも理にかなっている。

また各オブジェクトはSHA1のハッシュ値(16進40桁)で管理されているので、同じSHA1値であれば同じオブジェクトであるということがグローバルで担保されている。

ということは、例えばgitの開発ヒストリのログなんかも、本家をコピーしたリポジトリ全てで同一性が保証されている。Linusが最初にコミットしたオブジェクトは、世界中のどんなコピーでもe83c5163316f89bfbde7d9ab23ca2e25604af290という事が保証されている。通常は40桁のハッシュ値の最初の数桁を利用すれば参照できるので、例えば、

$ git-log e83c5163

とすればLinusが開発したgitの最初のコミットのログを見ることができる。すごいすごい。

$ git clone git://git.kernel.org/pub/scm/git/git.git

でソースも読めるのでいろいろ楽しめる。gitを利用したプロジェクトのヒストリの眺め方などという時間軸にそった楽しみ方もあるのではないかと妄想した次第である。

Rebase Early, Rebase Oftenという話をしたかったのであるが、紙面がつきたのでいつの日にか。

カーネルにおけるリグレッションの特定/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/10/post_d748.html

Git ユーザマニュアル (バージョン 1.5.3 以降用)
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html