ユメのチカラ

カジュアルなコミュニケーション

昨日はTLF (The Linux Foundation)のシンポジウムだったのだけど、仕事にはまっていて、キャンセルしてしまった（残念）。そしたら@itoh_bmarkからTwitterで体育館の裏までちょっと来いみたいな感じで呼びだされ、気がつくとTLFの懇親会会場にいた。セミナー本体にはいかないで、懇親会だけに居るというのも、どーよという感じがしなくもないが、重要な話は懇親会でされるという「宴会第二の法則」のとおり、その日も非常に示唆に富むお話が満載であった。

来年のLinux Kernel Summitをカーネル読書会がハイジャックするという件は、各所から非公式に打診されていて、がんばります。はい。

懇親会で、TLFのスポンサー企業の皆様とお話していて、よしおかさんたまにはブログ書いてくださいよとお願いされる。あれ、「はてな」の日記書いてますよ、と言うと、会社からは「はてな」ブロックされていて読めないので、面白い話は会社のブログで書いてほしいそうである。聞いてみると、はてなだけじゃなくて、mixi、ニコ動、YouTube、Twitter、Wassr、Skypeみんなだめ、全然だめだそうだ。あちゃ。そうですか。それは厳しい。

そー言えば今思いだしたのだけど、MID(Mobile Internet Device)のUI(User Interface)のデモをYouTubeにあげていて、それを見てくださいと、ある会社の人に言ったら、会社からは見れませんとか言われた件。たかが30秒くらいのデモを弊社ftpサイトにあげて、あーだこーだというのも大袈裟すぎてカジュアルなコミュニケーションできないよなあとその時に思った次第である。

Skypeで電話会議しましょう、なんてこともできないので、バカ高い電話会議システムを使わなくちゃいけなくて経費的にもいかがなものかと思ったこともある。

それはそうと、昨日は、会社でしこしことカーネルビルド(一応仕事もしています)なんかをしていたら、Twitterとかで呼びだされちゃうわけで、もはやメールですらない、カジュアルなコミュニケーションの輪という現実があって、会社ごとぶったぎられている大企業のコンプライアンスがちがちのインターネット環境からは想像もつかないものがあると思う。

北東アジアOSS推進フォーラムでid:koyhogeこと小山さんが声たからかに発表していた、日本各地で勃発しているカジュアルな勉強会ムーブメントにすっぽり大企業の従業員が抜けている驚愕すべき事実。もちろん大企業にも例外的にセンスのいい人はすくなからずいることはいるのであるが(例えば、わたしのこのブログを見ている人、あなただ)、そーゆー人は必ずしもマジョリティではない。

世界的な発明である「今夜飲み行けるよ！」ボタンとか、世界最先端のWebサービスの恩恵をまったく受けられないインターネットの孤島にいる人達。いらないおせっかいなんだけど、ちょっとヤバいなと思った次第である。

大企業の情報隔差というパラドクスは、ぜひNHKあたりに取材してほしいネタでもある。

http://hatena.ne.jp/
http://wassr.jp/
http://twitter.com/

日本は世界一のITコミュニティ天国

View SlideShare presentation or Upload your own. (tags: community)

日本は世界一コミュニティ活動が盛んな国？  http://itpro.nikkeibp.co.jp/article/OPINION/20081107/318749/

経済産業省商務情報政策局長感謝状

ひょんなことから経済産業省商務情報政策局長から感謝状を頂いた。わたしの年代だとお相撲の優勝者が航空会社の日本支社長(外国の方)から「ひょっうしょぅじょ〜ぅ」というのを懐しく思いだすのであるが、まあ、誰かから賞状を貰うのなんていうのは小学校以来と言っても過言ではない。

経済産業省として「ＩＴ産業の魅力の向上や将来のＩＴ産業の人材育成などについて、企業、教育機関の枠組みを超えて活躍している専門家の活動は、単に関係者間の自主的な取り組みにとどまらず、経済産業省の展開する政策にもご貢献されるものであると認識」し、ついては「この分野でご活躍いただいている専門家の皆様に商務情報政策局長より感謝状を贈呈したい」とのことである。

今回、経済産業省として初めて「専門家コミュニティ活動」を表彰したらしい。昨日、経済産業省に出むき局長から直々に感謝状を頂いた。今回の対象者は独立行政法人情報処理推進機構からの推薦を受けた人々のようで、具体的にはITSS/UISS/ETSS等スキル標準の活動に貢献した方々、OSSの活動に貢献した人、そしてセキュリティ&プログラミングキャンプでの活動(わたしはこの分野)に貢献した人々からなる。

感謝状の文言は以下のとおり。

感謝状
  吉岡弘隆殿

貴殿は経済産業省及び独立行政法人情報処理推進機構の人材育成政策に深い理解を示し我が国情報サービス産業の魅力向上や将来を担う人材育成のためその発展に寄与する活動に多大な貢献をされました
よってここに感謝の意を表します

平成二十年九月二十四日
経済産業省
商務情報政策局長       近藤賢二

授与式のあと、今回の受賞者の皆様と局長と歓談する機会があった。OSS分野で感謝状を受けた日立製作所の鈴木さんが口火をきって歓談がはじまった。スキルスタンダートを作成したアクセンチュアの杉山さんが、会社の枠を越えたプロフェッショナルコミュニティに参加できたという印象を語っておられたが、まさに同感である。また早期ＩＴ人材の発掘(セキュリティ&プログラミングキャンプやU-20プログラミングコンテストなど)についても、若い人にＩＴに興味をもってもらうことの重要性などをお話しした。例えばロボコンとか鳥人間コンテストなどに代表される技術に興味を持つ層を広げるイベントなどについてもいろいろアイデアを練っていく必要があると思う。

一方で、会社の枠を越えた知識の流通という意味で、標準化あるいは言語化が難しい暗黙知の流通は、人の流動化によってのみ達成できる。業界全体のレベルアップのためには人材の流動化が担保される必要がある。もちろんプロフェッショナルコミュニティを活性化することによって、知識の流通は加速されるであろうが、暗黙知は多くの場合、属人的なもので、それの流通には人の交流というのが欠かせない。すなわち、自主的に交流することは、どんどん勝手に民間がやればいいのであるが、人材流通に対する制度設計、政策立案などは、政府の力が必要となる。というような事を申し上げた。

今回の受賞者のほとんどは初対面の方だったので、さっそく名刺交換をさせていただき、これをきっかけに何らかの繋がりができれば望外の喜びである。

プログラマ35歳定年（停年）説

わたしに不用意にふってはいけないネタとして、プログラマ35歳定年（停年）説というのがある。飲み会かなにかの席でなにげなく、そのような話題を出し、延々聞きたくもない話を聞かされた被害者の方も少なくない。

血圧があがるネタである。

誰がいつごろからそんな事を言ったのだろう。

まあ、それはともかく、プログラマといってもいろいろあるわけで情報技術(IT)という分野も話している人によって全然違う話しをしているのに、双方とも気がついていなくて延々すれ違いの議論をするということも多い。

例えば、ITについても、(1)OSとかコンパイラとかRDBMSとかいわゆる基盤系技術、(2)エンタープライズ系(企業の情報システムとか)、(3)ミッションクリティカル系(勘定系、社会基盤系(電力送電網)とか)、(4)Webサービス系(Web2.0?)、(5)組込系(いろいろ)、などなど種々雑多ある。

またビジネス形態としても、(a)ソフトウェア製品開発、販売、(b)SI(受託開発)、(c)コンサルティング、(d)運用サービス、サポート、(e)Webサービス(Web2.0?)等々これまたいろいろある。

日本にはマイクロソフトとかOracleみたいな基盤系のソフトウェア製品開発販売の専業ベンダーというのはほとんどなくて、大手ハードウェアメーカがハードウェア販売のおまけ(？)みたいな感じで細々と商売をしていたりする。

そーするとだ、RDBMSを作りたいとかOSを作りたいと思った若者は、当該製品を作っている主に外資系に就職するくらいしか選択肢がなかったわけだ。大手ハードウェアメーカに就職しても商品としてのOSとかRDBMSの開発はほとんどやっていないので自分のやりたいことはできない。

昨今だとLinuxやMySQL/PostgreSQLなどオープンソースソフトウェアのおかげで別に大手ベンダーなり外資系ベンダーなりに就職しなくても、意欲さえあれば自分でがんがんコードを書くことは可能になった。

わたしのキャリアは1-aのパターンで、それ以外のところには正直土地勘がない。デスマーチの大規模エンタープライズ案件の修羅場とかはくぐったことがないので実状はどうなのかよくわからない。

最近はmixi、モバゲー、ニコ動などWebサービス系の開発現場のお話を聞く機会が多いのだが、その開発スタイルというのはウォーターフォールモデルとは全くことなる原理原則で開発されていて、それはそれで大変興味深い。

SIなんかは多重下請け構造みたいなのに組みこまれてしまうと単価勝負の世界になって人月いくらという話になるというのは理屈ではわかる。でもそれって経営者が、そーゆー判断したんじゃね？経営の問題じゃね？とか思う。

そーするとやはり案件ごとの受託開発よりも自社開発のソフトウェア製品開発とかWebサービス、あるいは運営サービス、サポートなんかの方が自社の強み特長をいかせておもしろいような気がする。

技術についても基盤系であればかなり蓄積が効くし、経験のつみかさねが強みになる。

そんでもって35歳停年説にもどるのだが、わたしがシリコンバレーに行ったのは36歳で、コードを書きまくったのが30代後半だった。未踏ソフトウェアは44歳、Cache Pollution Aware Patchは46歳、取締役退任。生涯一プログラマ宣言は49歳。そしてこの9月4日で50歳だ。

年齢は関係ない。限界を決めるのは自分だ。

Do not limit your self.

注記：定年の表記に関しては当初は停年と記していましたが、定年の方が一般的なようなので、そのようにしました。

未踏ソフトウェア奮闘記
http://itpro.nikkeibp.co.jp/members/NSW/ITARTICLE/20030619/1/
http://itpro.nikkeibp.co.jp/members/NSW/ITARTICLE/20030619/2/
http://itpro.nikkeibp.co.jp/members/NSW/ITARTICLE/20030709/1/
http://itpro.nikkeibp.co.jp/members/NSW/ITARTICLE/20030709/2/

Linux Kernel 2.6.18とCache Pollution Aware Patch/ユメのチカラ
http://blog.miraclelinux.com/yume/2006/09/linux_kernel_26_2c2c.html

エンジニアの未来サミット
http://gihyo.jp/news/report/01/engineer
http://gihyo.jp/event/2008/engineer
パネリストとして参加します。

創刊号巻頭座談会「エンジニアのマインドとは」～ボーナストラック
#3　座談会「エンジニアのマインドとは」
http://gihyo.jp/dev/serial/01/talks-bt/0003?page=2

プログラミングキャンプ

この夏、8月13日から17日まで、セキュリティ＆プログラミングキャンプ2008というの企画した。わたしも講師の一人として、プログラミングキャンプに参加する。

セキュリティ＆プログラミングキャンプ2008 http://www.jipdec.jp/camp/
セキュリティ＆プログラミングキャンプ2008/ユメのチカラ　http://blog.miraclelinux.com/yume/2008/06/2008-7e81.html

わたしのやりたい事。プログラムの楽しさを少しでも若い世代に伝え、仲間を少しでも増し、プログラマがプログラマとしての専門性をいかし生き生きと豊かにおくれる社会をつくること。

高度ICTリーダー論/shi3mの日記http://d.hatena.ne.jp/shi3z/20080807/1218068383

もっと若い相手、たとえば高校生や大学1,2年生などを対象に、もっと幅広い講師を呼んで講演会を開き、刺激を与えた方が「真のトップノッチ」育成には役立つのではないか。

まさにプログラミングキャンプはそのような明確な意図のもと合宿形式でトップノッチの発掘、養成をめざしている。

それにはどのようなカリキュラム(プログラム)がよいのか、今年は初めてなので文字通り試行錯誤の連続である。

わたしは、デバッグの方法、コードリーディング、プログラミング入門をうけもつが、シラバスを作り、プレゼン資料、実習問題、デモの準備など、正直いってへろへろである。はたしてこのような問題設定でよいのか、はたしてこのような教材でいいのか、そもそも、このカリキュラムでいいのか、そのようなことを自問自答しながら七転八倒し教材を作成した。

まだ実際の講義をしていないので、何とも言えないのだが、講義という学生とのコラボレーションでわたしも多くのことを学ぶだろうし、多くのことを経験するだろう。そしてそのフィードバックは次に生かしていくつもりである。

単にプログラマとしてひいでているだけではなく、コミュニティのリーダとして人々に信頼され、尊敬されるような人材と巡り会いたい。養成とか育成とか、そのような上から目線ではなく、可能性を持つ人々を発掘し、生き生きとその才能を開花させるような環境を作りたい。

そのためにはその中間地点として、彼らがその才能を十二分に発揮できる環境を作るのがわれわれ大人の仕事で、それは具体的には、彼等を雇用できるようなビジネスを創出することが最ももとめられていることである。

Googleに多くの若い才能が結集しているのは、それは我々が十分彼らの才能を生かす仕事場を提供していないからである。日本のタレントを流出させているのは、我々がそのプレイグラウンドを提供していないからである。

その意味で、id:mkusunok の指摘は正しいと思うが、
geek虎の穴をつくろう/雑種路線でいこう http://d.hatena.ne.jp/mkusunok/20080807/ito

恐らく優秀なプログラマーなら日本にも少なからずいる訳で、私塾ではgeekに対してグローバルな視座や搾取されないだけのビジネススキルを獲得できる機会を提供し、geekだけでなく、彼らが活躍できる環境を整えることのできるようなサポーター、具体的には優れたビジネスマネージャやマーケティング、政策立案者も育てる必要がある。手をつけられそうなところから具体的なカタチにしていきたい。

育てるだけではなく、そのような社会環境を作るのが我々の仕事である。今まさに楠さんや清水さんにはそのような役割が求められているのである。

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

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

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

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

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

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

22歳以下の皆さん。

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

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

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

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

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

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

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

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

10年で200人。

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

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

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

勉強会のこと

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

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

まあ、感覚的には結構頻繁にいろいろやっているよねと思っていたのだが、下記の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のパネルディスカッションに参加します

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そしてWeb2.0の時代。

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

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

素敵だ。

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

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

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

1000 Speakers Conference

1000 Speakers Conference参加した。ミラクル・リナックスで開催した。

わたしの資料もアップしました。ylug_1000speakers.pdfをダウンロード

溝口さん（ドワンゴ）がニコニコ動画にアップしてくれた。ありがとうございます。

わたしは2-13の「カーネル読書会の作り方」でお話をさせていただいた。オフ会的勉強会の実践的開催方法論（おおげさ）について発表したのでぜひ参考にしてほしい。

各、発表はそれぞれ個性豊かで大変面白いものばかりだった。ustream.tvでの中継と、チャットがライブ感をかもし出していた。160人程度インターネット経由で中継を見ていたようである。

その後、懇親会を同会場でピザとビールで行なった後、新橋の居酒屋で二次会をした。

 

1000人スピーカカンファレンスという素敵なカンファレンスを開催してくれた、西尾さん、天野さん(amachang)、動画中継の溝口さん、発表者の皆さん、参加者の皆さん、どうもありがとう。そして、ニコニコ動画、はてな、ustream.tvなどインターネット上のプラットフォームを作ってくれた皆さんにも深く感謝したい。そのようなものがなければ、今回のカンファレンスはできなかったと思う。

若い人たちの元気のいい姿をみるのは心地よい。

第二回1000人スピーカカンファレンス／西尾泰和のはてなダイアリー
http://d.hatena.ne.jp/nishiohirokazu/20080223/1203780721

話したい人のためのカンファレンスを開催します。（追記あり)／IT戦記
http://d.hatena.ne.jp/amachang/20071211/1197350279

1000人スピーカーカンファレンス
http://ja.doukaku.org/wiki/index.php/1000speakers:2

技術セミナー「技術は会社のものではない。みんなのものだ」をYouTubeでも公開しました。

YouTubeでも公開しました。 実は先週中にアップされていたのですが、皆様への公開アナウンスが遅れてすいませんでした。

技術は会社のものではない。みんなのものだ。社内セミナーをニコニコ動画(RC2)で公開するまで。

先日、野村総合研究所向けに「技術は会社のものではない。みんなのものだ」というタイトルで社内セミナーをした。

オープンソースにまつわるソフトウェア開発方法論みたいな話である。まあ、中身は日頃わたしのブログをご覧の皆様にはおなじみなお話である。

野村総合研究所(NRI)の社員30人程度の皆様への社内セミナー(注)である。今回一つお願いをした。「講演を後に公開していただく事を前提にお請けします」。

セミナーを職業にしている講師にとってはありえない条件である。しかし、わたしは講演を公開することの経済的な損失というのはないし、むしろ自分の日頃の主張と行動に一貫性を持たせるという意味あいの方が強い。

講演内容を公開しろなどという講師は前代未聞である。大きな企業になればなるほど社内調整というやっかいなものが待っている。一度誰かが先例をつければ次の人はその道をフォローできるが、最初の一歩が困難にみえる。越えられない壁のように見えなくもない。

しかし、誰かが最初の一歩を踏み出して、何か新しいことをはじめたからこそ今の姿があるはづである。見えない壁を乗り越えるにはちょっとした勇気と行動力が必要である。社内力学の中で上手にたちまわる社内調整力、したたかなソーシャルハックが必要である。

エンジニアはどうもそのようなハックが苦手というか無頓着な人が多い気がするが、しなやかにそしてしたたか行動していきたい。

今回、公開をお願いしたとき、担当の野上さんは「よしおかさんからは何となくお願いされるような予感がしていましたよ」と後に語ってくれたが、何事もダメモトでお願いしてみるものである。わたしがお願いしなければ、公開はされなかったわけだが、野村総合研究所の多くの方の努力の結果、社内セミナーの公開を達成されたことは素晴しい事だと思う。

やればできるじゃん、などというと大変失礼にあたるが、何事もとりあえづやってみて、上手くいかなかったら上手くいくような工夫をする。そーゆースタイルでソーシャルハックを続けていく。

公開しないより公開した方がトクな状況を模索する。あるいは公開してもソンでない状況を発見する。企業の利益にそうような提案をする。

担当の野上さんには社内調整などご苦労をおかけした。感謝したい。ありがとうございました。

注：社内セミナー：ＮＲＩグループ内の社内ベンチャー制度の一つとして、ほぼ月1回、起業家などを呼んで講演会および交流会を実施している。啓発活動とケーススタディの場として提供。

講演会資料nri080122.pdfをダウンロード

セキュリティ・キャンプ・キャラバンwithプログラミング沖縄

若年層の情報セキュリティ意識の向上と優れたセキュリティ人材の発掘と育成を目的として、毎年開催しているセキュリティキャンプの成果とその蓄積されたノウハウを広く一般の方々にも公開すること、これからキャンプに参加していただきたい若い方々に正しい情報セキュリティの理解と意識の向上を図ってもらうこと、また、オープンソースソフトウェア(OSS)を中心としてプログラミングやアプリケーション開発について興味を持っていただくことを目的として、「セキュリティキャンプ・キャラバン with プログラミング　-沖縄-」を開催します。
http://www.jipdec.or.jp/camp/caravan/caravan_okinawa.html

ということで沖縄にきている。わたしは大阪、筑波、そして沖縄と三ヶ所キャラバンした。

来週は横浜で開催するので東京近郊の皆様はぜひ参加してほしい。
http://www.jipdec.or.jp/camp/caravan/caravan_yokohama.html

セキュリティキャンプ・キャラバンwith プログラミング　2007
集まれ“若い力”
http://www.jipdec.or.jp/camp/caravan/caravan.html

お知らせ。ITPro EXPOでアプレッソの小野さんと対談します。

来年1月31日に開催される ITPro EXPO で、アプレッソ代表取締役副社長CTOの小野さんと対談します。

【吉岡弘隆　×　小野和俊】Web 2.0時代のソフトウエア開発者の生き方　

今から大変楽しみです。
あとここだけの話ですが、このセッションだけ特別に録画OKのお許しをいただいています。撮影隊のボランティアをやってもいいよという方はわたしまでメール(hyoshiok at miraclelinux.com)ください。

未踏オフ会

古川享PM(プログラム・マネージャ)の未踏ソフトウェア創造事業(長いな、以下未踏と称す)のオフ会に参加した。

古川さんの事は30年くらい前から、わたしは一方的に名前を存じあげていたのだけど、直接名刺交換をするのは初めてである。それはともかく、1970年代のマイコン世代の懐しいお話満載で、ASCII出版のころとか、マイクロソフト株式会社設立のころのエピソードなど興味がつきなかった。

最初にパワーポイントのちょっとしたTipsを延々話していたのは笑った。YouTubeのCTOは、パワーポイントも上手に使えないとか、どーでもいい(失礼)エピソードが面白い。

古川亨略歴ということで、ASCII時代の話から入った。

79年11月のASCIIにパーソナルコンピュータはメディアになるというコラムを書いてそれが自分のビジネス、生き方の指針になった。その後、ASCIIでInformixの日本語化、BSD Unixの日本語化、これはのちにSONY NewsとかUltrixで使われた。86年マイクロソフト日本法人設立。

当時Apple/Sun Micorsystems/Microsoftの三社から社長のオファーがあったが、マイクロソフトの社長になったのは皆さんご存知のとおり。人事権に関しては誰がなんと言おうとも、米国本社ではなく自分が持つというのを条件に社長になった。

人とぶつかった時に、相手の正しさを認めること、自分の非を認めること、それが重要で、Bill Gatesは人の話を聞く(リスニングスキル)がすばらしい。そしてそれを自分の力にする。

ソフトウェア事業は核となるところ、目標となるところを持っていないといけない。YouTubeは自分の母親にも使ってもらいたかった。そーゆーしっかりとした軸が必要。

天才プログラマを生かすプロダクションが必要。宣伝をして、マーケティングをして、営業をして、箱をつくって、権利関係を確認して、商標をとって、というような様々な事をやってくれる、アーティストに対するプロダクション事務所みたいなものが必要で、プログラマはその重要性を理解する必要がある。いいマネージャーに出逢う必要がある。

というようなお話をプレゼン資料2枚で延々1時間以上独演会をしている。古川節炸裂である。これはわたしの文章では伝えられない。ライブの醍醐味である。

その後、ユルユルの形でパネルディスカッションがはじまって、古川さんの熱気で竹内さんたじたじである。

いろいろ興味深いエピソードを聞きながら、結局のところ、日本という地域に圧倒的に足りないのは、やはり、ソフトウェア製品を作ってそれをビジネスにした経験者であり、その経験者を拡大再生産する土壌であると思った。古川さんのような「経験豊かなおじさん」が圧倒的に足りない。

足りないならば、もっともっと「古川さん」を利用させてもらおう。古川さん的な人達と交流を持ち、すこしずつ成功体験を拡大再生産していく。そのきっかけの一つとして未踏というプラットフォームを利用する。

優れたプログラマは沢山いる。彼ら彼女らの活躍するフィールドを作るために、ビジネスとして成立させるためのイロハを知っている古川さんのようなベテランをひっぱりだして、プログラマと同じ坩堝につっこんで、核融合を発生させる。

そんな期待感があった未踏オフ会であった。

古川 亨 ブログ
未踏ソフトウェア創造事業のオフ会に参加、その１
http://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!8461.entry

Exciting BEAT｢未踏ソフトウエア創造事業オフ会 & Venture BEAT Project」
http://v.japan.cnet.com/beatproject/blog/story/0,2000071498,000241c-0000021424o,00.htm

nobilog2
未踏ソフト第１回オフ会に行ってきました！
http://nobi.cocolog-nifty.com/nobilog2/2007/12/post_5ac0.html

Drift Diary12
未踏オフ会に参加してきました。
http://blog.drikin.com/article/73528036.html

nishimotzの日記
未踏オフ会
http://d.hatena.ne.jp/nishimotz/20071218

未来のいつか/hyoshiokの日記
未踏オフ会
http://d.hatena.ne.jp/hyoshiok/20071218

30代のころ

日本のIT産業とかの憂鬱を書くとページビューとかブックマークがどどどどっとつくようではあるが、若干趣向を変えて昔話。

よっぱらいオヤジの昔話なんてまっぴらだと言う方はどうぞ次にいっちゃってください。スルーです。

わたしは新卒で世界第二位のコンピュータベンダーの日本法人に就職した。若い人は知らないかと思うが、当時DECという会社があったのである。今はその会社はない。

29歳で結婚して、31歳の時、米国本社へ一年間出向する機会があった。1989年10月のことである。身重の妻と一緒にBoston Logan Airportに降り立ったわたしは不安と期待で胸が一杯だった。出張で何度か来た事はあったが海外生活はもちろん初めてだし、本社で働くということに対する不安と期待が渦巻いていた。

ハロウィーンの季節だ。米国New Hampshire州の紅葉は、それは見事だった。自然が豊かなところである。

オフィスへの初出社。期待に胸を膨らませてSteve Hagan（当時のボス）のブースに行った。Steveが人事的なあれやこれやを説明してくれた後に、じゃあ、メンバーを紹介するよと言ってオフィスを案内してくれた。各ブースのパーティションの壁は日本のそれと違って背の高さほどあるので、いちいちブースに顔を出さないと中で何をしているかはわからない。

こっちのエンジニアはどんな格好をしながら仕事をしているのだろう。どんな風にブースを飾っているのだろう。やはりバリバリのプログラマはTシャツにジーンズで髭茫々という定番の格好だろうか。

そんなことを考えていた。

最初のエンジニアはスーパーマンの格好をしていた。次のエンジニアは魔法使いの老女だ。ともかく思い思いの変な（？）格好をしている。Steveが、わたしのことを紹介してくれるのだが、わたしは口をポカンとあけながら、ともかく、スーパーマンだか魔法使いだかと、Nice to Meet Youとか言いながら握手をした。

な、なんなんだ。ここはなんなんだ。

後にその日はハロウィーンと言って、それぞれが思い思いのコスチュームで楽しむ日だということを知ったのだが、海外赴任生活一日目のオフィス出勤者のわたしにとってはインパクトが強すぎる経験であった。

さすがに毎日スーパーマンではないということを知り、ほっとしたのであるが、それでも、ブースの中でポップコーンを作るやつはいるし、それぞれのブースにはそれぞれ趣向を凝らしたデコレーションがあったりした。

仕事はと言えば、我々が開発した日本語版のソフトウェア製品のコードを本社の製品にマージするという作業で、技術的なチャレンジはそれほどはなかった。当時の外資系のソフトウェア部門の仕事というのは、本社が作ったソフトウェア製品の日本語化というのが主であった。日本語の文字コードを扱えるようにしたり、日本語のメッセージを追加したり、日本語のマニュアルを作ったりという仕事である。

当時はユニバーサルな文字コード（Unicodeみたいなもの）というのがまだ一般的ではなかったので日本語のコードとしてDEC漢字コード（EUCみたいなエンコーディング）などをサポートするように本家のソフトウェアを変更していた。

本家のソフトウェアを変更するので、米国版ソフトウェアと日本語版ソフトウェアと別々にできてしまう。米国版ソフトウェアが完成してから日本語版を作成するので、１）開発コストがかかる、２）出荷の時期が遅くなる、３）出荷してからのメンテナンスが難しい、などなど問題点が多い。

そこで、日本語機能を本家にマージすれば問題は解決するのであるが、処々の事情でなかなか物事は簡単にすすまない。

わたしは入社以来、朝から晩まで日本語化なんて作業をやってきたわけで、それなりに第一人者である。コードを読まなくても現象から実装上の問題点などもだいたい見当がつくし、変更方法についても見通しを持っていた。本家の連中との議論も、そもそも論で言えば、国際化も考えていなくて何がソフトウェアだ、みたいなことを盾にずんずん説得していった。ラフなコンセンサスと動くコードみたいな世界である。

まあ、そんなこんなで、日本語版Rdbを一般化した国際化Rdbのソースコードを持って米国本社に乗り込んだのである。

New Hampshire州 Nashua という片田舎での生活は、まわりには日本人なんかほとんどいないし、それはのんびりしたものであった。冬はアパートの池がすっかり凍ってしまって、子供たちがそこでスケートをしている。会社まで歩いていける距離なので、通勤も楽だ。リスや鴨がうろちょろしている。

米国の生活もハロウィーンから始まって、七面鳥を焼いたり、年末年始のBoston、などなど楽しいものであった。妻は出産のために一足早く帰国したが、初めての米国生活は不慣れなことも多々あったが、結果オーライという感じであった。

その後、DECは業績が悪化し、Rdb部門は競合のOracle社へ部門ごと売却されてしまう。リストラで社内の空気は悪くなっていく一方であった。

日本に戻ったわたしは、日本で開発がどんどん縮小されていく現実とどう向き合うかを考えぬいた。ある意味、残るのも地獄、出るのも地獄の世界である。

日本DECの希望退職制度を利用して日本Oracleに転職したのが94年である。36歳の時である。転職としては、必ずしも若くはないが、かといって遅いと言うわけでもない。

退職時にお世話になった人たちにメールを書くという習慣があるが、わたしもいろいろな人たちにメールをした。その中の一人に初めての海外赴任でお世話になったSteveがいた。Oracleに転職するのだと言ったら大変喜んでくれた。

当時、DECのRdb部門がOracleに売却されたことによって、日本でも日本DECから日本OracleへRdb関連の引継ぎが発生していた。わたしもそのプロジェクトを日本Oracleで手伝うことになった。その引継ぎの会議でRdbについて最もよく知っているのがDEC社員ではなく日本Oracleの新入社員のわたしという奇妙なことになっていた。

まあ、それはともかく、日本Oracleに就職してアライアンスパートナーの支援をしていたところ、米国Oracleの開発チームからお声がかかってOracle8の開発に参加することになった。95年のころである。

会社の中で自分がやってきた仕事がなんらかの理由でなくなったとしよう。工場の移転でもいいし、部門の統廃合でもいい。なんらかの理由で転属ないし配置転換などが求められたとしよう。その時、われわれが取る選択肢は、配置転換を受け入れて会社に残るか転職か。個人的な事情で転勤を伴う配置転換が受け入れられない場合もあるが、ともかく会社に残るか去るかという選択肢である。

自分の専門性、例えばわたしの場合、ソフトウェアの日本語化、国際化などで10年飯を食ってきたわけで、それなりの自負はあったが、それを生かす仕事は今の会社にはないとしよう。その場合、どうするべきか。

もちろん正解はないし、人それぞれの人生である。

自分の専門に拘らず柔軟に対応して別の部門に転属になり、一から勉強しなおす。大きな会社であれば、雇用は確保されるだろうから、自分の得意不得意、好き嫌いはあるかもしれないが、贅沢は言わなければ食っていける。

一方、もう少し、自分の専門分野（ソフトウェアの開発）でやってみたいと考え、別の会社でそれができないか探し転職する。こちらは新しい環境に飛び込むわけだからリスクはあるが、自分のやりたいことに繋がる可能性は高い。

人それぞれ、正解はない。

わたしの場合は、悩みに悩んで結局後者を選んだ。

やはりソフトウェアに未練があった。DECはなんやかんや言ってハードウェアベンダーである。主力はVAXとかAlphaとかのハードウェアであり、Rdbをはじめとするソフトウェアは、おまけであった。典型的な垂直統合型ITベンダであった。

今だからはっきり見えているが80年代に時代は垂直統合型ITベンダ（IBMをその頂点とする）から水平分散型ITベンダ(Intel/Microsoft/Oracleなど）へ大きく舵を切っていたのである。

その当時、漠然としながらもOracleを選んだのは自分の直感であった。Oracleを選んだからといって、米国本社で開発できる保証というのは全くなく、可能性はゼロではないとしても、開発できることすら未知であった。

しかし、自分は自分。自分に素�