ユメのチカラ

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

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

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

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

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

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

群衆の叡知サミット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回カーネル読書会のおしらせ

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

今回は場所を日本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名で締切ます。

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

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

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

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

git入門

社内勉強会で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

勉強をしなおす

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

という事で日頃なにげなく使っている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を使っているけど全然使いこなしている感じがしない。ちゃんと基本にもどって勉強しなおしてみよう。きっと新しい地平線が見てくるに違いない。