ユメのチカラ

2008年を振り返る

2008年は変化の年だった。自分にとって。1998年Netscapeのソースコード公開から10年。オープンソースにとっては10周年記念の年だった。この一年を12月でもあるので振り返ってみる。

自分にとっての今年の三大ニュースをあえて選んでみると、

(1) 取締役退任。生涯一プログラマ宣言。
(2) 経済産業省商務情報政策局長感謝状、楽天テクノロジーアワード2008金賞受賞
(3) 勉強会ブーム

取締役退任し、約半年。現場でAsianux Mobileの開発を行っている。ディストリビューションの開発というのは何かプログラムをスクラッチから書くということはなくて、ブートローダのバグを直したり、パッケージのビルトをしたり、ときにはパッケージの機能変更したりという非常に地味な仕事である。Webのサービスと違って、すぐ成果が世の中に出るという事はないので、製品開発といっても、イメージしにくい仕事かと思う。しかし、地味だけど、そのような仕事が好きなのである。

感謝状を受けたり、楽天テクノロジーアワード金賞をいただいたり、びっくりである。1999年に日本に戻ってきて、ひょんなことからカーネル読書会をはじめて気がつくと9年半。92回開催している。来年は10周年で、100回記念だ。こんなに長く、何回も開催できたのは、毎回話題を提供してくれる様々な講師の方と、毎回楽しみに参加してくれる人々があってのことだ。カーネル読書会のような自主的な勉強会は、発表者だけでも参加者だけでも成立しない。みんなが自主的に参加することによってなりたつ。それが商用のセミナーや研究会との違いだと思う。そのような活動を好きだから続けてきたことが、誰かの目にとまって、表彰されるというのは不思議な感覚である。好きなことをやってきただけなのにと思う。しかし、表彰されることで、多くの人の目にとまって、同じような事をする人が少しでも増えればそれはわたしとしてもとっても嬉しいことである。

勉強会大ブームというと語弊があるかもしれないが、IT勉強会カレンダーによって可視化された、自主的な勉強会のムーブメントは今年の明るい話題だ。勉強会開催の方法論も広く共有されるようになったし、ustream.tv等での動画中継のコモディティ化、ニコ動、Google Video等による動画配信など、勉強会開催の方法も高度化しつつある。それを人々が軽やかに運営している姿が素敵だ。

勉強会などのコミュニティ活動に意義を見出す人々が増えてきているのはうれしい事なのだが、一方で、本来なら参加してほしい技術者に、その良さが十分伝わっていないようなもどかしさも感じる。中々会社の上司の理解を得られない、同僚の理解を得られないというような声も聞く。課題として皆で考えたいと思う。

企業や組織の壁を乗り越えていろいろな人と繋りを持つことのメリットをもっともっと多くの人に伝えたいし共有したい。

来年はYLUG (横浜Linux Users Group)10周年であるし、カーネル読書会100回記念だ。100回記念にはぜひLinuxの父、Linus Torvaldsをカーネル読書会に呼びたいと思う。関係各位の協力をお願いした。

1月。

Netscapeのソースコード公開。あれから10年

今はなき米国Netscape社がその基幹製品であるNetscape Navigatorのソースコードを公開する事を発表したのが1998年1月である。

お知らせ。ITPro EXPOでアプレッソの小野さんと対談します。
Twitterはフォローが3桁を越えてからですよ、という小野さんの言葉を真にうけてフォローをどんどん増やしていったら、いつのまにかに700人以上フォローしていた。

2月。

技術は会社のものではない。みんなのものだ。社内セミナーをニコニコ動画(RC2)で公開するまで。
野村総合研究所での講演をニコニコ動画で公開した。講演をするときには可能な限り公開を条件とすることにした。

さよならNetscape、こんにちはWeb 2.0
10年前に書いた日記によって自分が癒される。そんな奇跡に出会った。

1000 Speakers Conference 素敵なカンファレンスだった。1000人のスピーカーに早く会いたいと思った。

4月

我々はOSを創っているのではないインターネット端末を創っているのだ
Mobile Internet Device (MID)端末は来年くらいにはブレークするだろうか。

5月

git入門

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

Linux World Expoのパネルディスカッションに参加します
パネルでは好き勝手なことをしゃべっていたようなのであるが、詳細なログがないので何をしゃべったのか覚えていない。残念。このパネルを見てましたよ〜という人に後日出会った。

6月

勉強会のことIT勉強会カレンダーや1000speakers conferenceを紹介した。

7月

取締役退任。生涯一プログラマ宣言。
大変多くの反響を呼んだブログである。多くの方に励まされた。

8月

セキュリティ＆プログラミングキャンプ2008
若いプログラマ志願者と過した5日間はかけがいのない経験であった。

9月

プログラミングはパッションだ U-20プログラミングコンテストでの審査などについて記した。
経済産業省商務情報政策局長感謝状
思いもかねない感謝状をいただいた。

11月

カジュアルなコミュニケーション
コミュニティ活動と仕事
勉強会のようなコミュニティ活動について、会社との関係について考えた。

楽天テクノロジーカンファレンスに行ってきた。
楽天テクノロジーアワード金賞を頂いた。

12月

セキュリティ＆プログラミングキャンプ・キャラバンで全国行脚全国の高校生、大学生、若い人たちと対話するのが楽しい。

コミュニティ活動と仕事

先日、大手企業にお勤めの若手技術者の方とお話する機会があったのだが、上司がコミュニティ活動をバカにしていて正直、説得するのに疲れてしまったというような事を伺った。上司が「所詮コミュニティ活動なんていうのはサークル活動だろ」と全くその価値を認めてくれない、というような話であった。

コミュニティ活動をしたところで、自社の直接的な売上に結びつくわけでもなく、経費節約に直接貢献するわけでもないので、上司殿にとっては単なる無駄なアクティビティにしかみえないのだろう。とは言うものの、時間外にやっているわけであるから、ほっといてくれと思わなくもないが、その手の上司は、ほっとくのではなく、白い目でみるというか、良い顔をしないというか、露骨にイヤな顔をするらしい。

仕事の延長で、どんどんコミュニティ活動を奨励する会社は、そうは多くはないと思うが、もちろんなくはない。しかし大手企業で、そのコミュニティ活動の可能性に気がついて、それをビジネスプロセスにリンクしているという事例はほとんど聞いたことがない。まあ、奨励しなくてもいいから、せめて邪魔はしないで欲しいとは思う。若手の勢いを削ぐような事はなるべくならばしてほしくないと思う。

そこで、考えた。頭の固い中間管理職にコミュニティ活動の意義をどのようにして理解してもらうか。それを仕事の文脈で価値のあるものだという風にどのように理解してもらうか。別に無理して理解してもらう必要もないという立場もあるし、そーゆー頭の固い上司しかいない会社はとっとと見切りをつけて転職した方がいいという声も聞こえなくもないが、できることなら、ちゃんと説明して、理解してもらった方が双方の精神衛生上、よろしいのではと思う。

いろいろな勉強会に出て思うのだけど、こーゆーダイナミックな学習の場、知識の流通の場に、なぜ大企業の従業員はほとんど来ないのだろう、大変もったいないではないか、いらないお世話ながら本当に思う。もちろん大企業の方もいらっしゃることはいらしゃるのだけど、会社には内緒で、こっそり来ていたりして、もっとどうどうと来れる環境になった方が、楽しいのではないかと。会社にとっても個人にとっても、そっちの方が絶対健全だと思う。

仕事と勉強会がリンクすれば、大手をふって参加できるし、ひょっとしたら講師の立場で仕事として発表できるかもしれないし、そうすれば、それが業績にもなるかもしれないし、などなど思うのだけど、やはり、いらないお節介かな。

もちろん、従来の学会発表というのは、研究職の皆様にとっては、仕事としてプロフェッショナルな知識交換の場としてあることはあるのだけど、もっと最先端な、一方でどろくさいバッドノウハウとか、そこに真実が落ちているような運用の話とかは、学会や研究会という旧来型のプラットフォームでは全く拾いきれていないという実感がある。(情報系学会の研究会はもはや勉強会に負けている可能性が高い/jj1bdx: life beyond Japan)

Internet Week 2008 IT Community Impact! 〜世界を変える新たな潮流〜で、そのようなコミュニティ活動を実践されている主宰者の皆様と議論したのだが、そこに参加の皆さんは、コミュニティ活動の意義を肌で感じ実践されていて、暗黙的にその価値を共有しているので、逆説的ではあるが、その意義を陽に言葉で表現できていないように感じた。すなわち、その価値観を共有していない人達に届く言葉をわれわれはまだ発見していないのではないかと思った。

勉強会に来る人は来るし、来ない人は絶対来ない。この絶対来ない人達にわれわれのメッセージを伝えるにはどうしたらいいのだろうか。

高橋さんが早速記事にしてくれたが、メディアの露出を増すというのも時間はかかるが一つの手である。しかし、そのようなメディアですら十分ではない。(「草の根勉強会が世界を変える」---Internet Week 2008でコミュニティの“熱さ”を語るトラック)

はやり一人一人が上司を説得するしかないのだが、その方法論をわれわれはまだ発見していないような気がする。

割箸の袋にメモをした、いくつか試してみたい今日からできる方法。

1) コミュニティ活動によって得た成果を会社内で宣伝する
2) 参加したコミュニティ活動を上司に報告する
3) 上司をコミュニティに呼ぶ

大企業の中間管理職から上の世代は、80年代のメインフレーム全盛の時代に育った人達だから、必要な情報は全部社内にあって、社外活動の経験がほとんどないし、その必要性を理解していない。いないのであれば、どうにかこうにか、なだめすかしても、コミュニティに参加してもらって、それの虜にするしかない。時間がかかっても、それをやるしかないと思う。(時間の無駄とか言う人がいるけど、まあ、邪魔はしないで欲しいと思う)

まっちゃだいふくさんに教えてもらったのだが、IT Skill Standard V3のレベル7には「また当該テーマに関して、学会、テクニカルコミュニティ、講演等で発表することができる」というのが求められていて、今回のパネリストは、レベル7の要件の一つを軽々クリアしているのね、などと思った。

IT Skill Standardsを作る人々というのは、社外のエキスパートと共同で開発しているわけだけど、それこそブートストラップというか、それをはからずも実践して経験した人達である。その人達がコミュニティ活動の実践的意義について熱く語る伝道師になってくれれば制度的な面からのフォローもあっていいかもしれない。

カジュアルなコミュニケーション/ユメのチカラ

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

経済産業省商務情報政策局長感謝状/ユメのチカラ

経済産業省として「ＩＴ産業の魅力の向上や将来のＩＴ産業の人材育成などについて、企業、教育機関の枠組みを超えて活躍している専門家の活動は、単に関係者間の自主的な取り組みにとどまらず、経済産業省の展開する政策にもご貢献されるものであると認識」し、ついては「この分野でご活躍いただいている専門家の皆様に商務情報政策局長より感謝状を贈呈したい」とのことである。
今回、経済産業省として初めて「専門家コミュニティ活動」を表彰したらしい。昨日、経済産業省に出むき局長から直々に感謝状を頂いた。今回の対象者は独立行政法人情報処理推進機構からの推薦を受けた人々のようで、具体的にはITSS/UISS/ETSS等スキル標準の活動に貢献した方々、OSSの活動に貢献した人、そしてセキュリティ&プログラミングキャンプでの活動(わたしはこの分野)に貢献した人々からなる。

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

昨日は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を選んだからといって、米国本社で開発できる保証というのは全くなく、可能性はゼロではないとしても、開発できることすら未知であった。

しかし、自分は自分。自分に素直に向き合った。わたしは、開発をしたい。ソフトウェアを作りたい。その可能性は、今の会社に残るより転職した方が高い。そう考えた。

希望退職制度がその後押しをしてくれた。

その制度のおかげで、DECは人件費を削減でき、Oracleはソフトウェア国際化の専門家を雇用することができたし、わたしは転職することによって自分の専門性を死蔵することなく生かすことができた。

転職はもちろん奇麗事ではない。結果オーライだとしても、その時何かの保証があったわけではない。

しかし、チャレンジしなければ、わたしがOracle8にコードと言う足跡を残すことはなかったことだけは確かだ。

選ぶのはあなただ。チャレンジするのはあなただ。自分の人生を生きるのは会社ではなくあなただ。上司があなたの人生を保証してくれるわけではない。あなた以上に自分の人生を真摯に考える人は世界中いない。

30代後半、自分の足跡を残すために米国Oracleでひたすらコードを書いた。毎日コードを書き、テストをし、デバッグをした自分がいる。その当時の七転八倒は今はなき「シリコンバレー日記」に詳しい。

10年後わたしはここにいる。誰でも自分の行動を正当化する。過去は美化される。思い出は時として理想化され記憶は風化する。

何かをやってみる。そこには今まで見えなかった地平線が見えていた。

オープンソースと言うのに出会う前の30代のわたしの姿である。

こーゆーおっちょこちょいですっとこどっこいの新橋の呑み屋でくだを巻いているオヤジがわたしである。

20代のころ　－　未来のいつか/hyoshiokの日記
http://d.hatena.ne.jp/hyoshiok/20040909

シリコンバレー日記
http://web.archive.org/web/19981202003332/http://www.best.com/~yoshioka/diary.html
（文字エンコーディングをshift_jisにする）

1997年のこと　-　シリコンバレー日記
http://web.archive.org/web/19990423115009/www.best.com/~yoshioka/d/98/i980206.html
（文字エンコーディングをshift_jisにする）

若い人に人気のない産業は減衰する　－　ユメのチカラ
http://blog.miraclelinux.com/yume/2007/11/post_1ab2.html

自分が何をできるか

対案のない批判は単なる床屋談義であり、新橋の飲み屋でやってくれという空気を感じたので、自分のできる事を考えた。

実のところ、新橋の飲み屋で楽しく飲むのは大好きである。飲めば飲むほど饒舌になる。単なるヨッパライのおやじである。ブログなんていうのは所詮世界規模のヨタ話である。閑話休題

まあ、偉い人を批判するのは簡単である。大企業を批判するのも簡単である。あー、すっきりした、という感じである。じゃあ、おまえは、どれだけエライのか。そーゆー感じである。ご説ごもっとも、おっしゃるとおりである。

わたしはコンピュータが好きだ。プログラムを読んだり作ったりすることが好きだ。こーゆー事を書くと、おめー頭おかしいんじゃないか、と思われたりするのだが、昔はそれを口外するのがはばかられた雰囲気があったのかもしれないが、この年になると憶面もなく、そーゆー事を声を大にして言う。別にそーゆーことを声を大にして言っても、誰の迷惑になるわけでもないので、言ってもいいのである。人と違ってもいいのである。

ソースコードを読むのが趣味ですなんていう奴は世界広しと言えど、そうはいないと思っていたら、意外と同好の士は少なくなくて、インターネットのおかげで簡単に、そーゆー人と出逢う事ができてカーネル読書会などという変な会合も80回を数えることができている。

別に産業構造として日本のIT産業に国際競争力がなくてもいいという立場の人もいなくはないが、もちろんわたしはそのような立場をとらない。

なぜか。

日本から、そーゆー産業がなくなってしまうと、わたしの好きなプログラムをする人達がいなくなっちゃって(ここは極論だよ)、カーネル読書会みたいな変な会合が益々ニッチになってしまって、つまらないからだ。

もっと言えば、わたしはカーネル読書会で、OSの話だけではなくて、CPUプロセッサの話とか、キャッシュの話とか、IOバンド幅がどうだとか、RDBMSの上半分と下半分の実装がどうだとか、様々なある意味多くの人にとってどうでもいい、だけどそれを実装している人にとっては非常に重要な文字どおり命を削ってでも一生懸命作るなにものか、そしてそれを作ったその人達と語りあいたい。喜気として技術を技術として語りあいたい。

そのような場を日本という地域で持てれば幸せだと思っている。東京はおかげさまで人口密度も高いので、そーゆー変な人達がいっぱいいて、夜な夜ないろいろな勉強会だかヨタ話だかわからない会合が開催されている。楽しいではないか。

技術を大事にする会社もあれば大事にしない会社もある。それはそれ、これはこれ。

人は食うために仕事をする。これも事実である。

自分がやりたい仕事例えば開発の仕事が、その会社でなければ、どうするか。選択肢は二つ。会社に残って別の仕事をする。もう一つは、その仕事がある会社を探して転職する。

大きな会社ほど、社内にいろいろな機会がある。これも事実である。

小さな会社は、あれもこれもできないから、あれ専門か、これ専門かである。

わたしは、大学を卒業して、米国のハードウェアベンダーの日本法人の研究開発部門に就職した。80年代の前半である。IBMに次ぐ世界第二位の規模の会社であったが今はその会社はない。（２0代のころ）

ソフトウェア製品を作るのは大変の事はもちろんいっぱいあるけど、それ以上に製品を作るという喜びがあった。ソフトウェアエンジニアリングのイロハを教えてもらった。

その後、いろいろあって日本オラクルに転職し、縁あって米国Oracleへの出向し気がついたら30代後半はせっせとコードを書いていた。

シリコンバレーのソフトウェア企業は間違いなく技術者を大切にする。そのような会社が競争力がある。もちろん、技術にあかるくない、とんがった頭のマネージャもいなくはないが、おたくはおたくとして心地良く生きられる空気がある。

ソフトウェアによって世界を変えてやろうという夢を持ったハッカーがいる。それで一山あててやろうという山師もいる。

で、自分にできることといえば、ソフトウェアの開発が面白い、楽しい、一生の仕事にたる価値のあることだと言うことを地道に伝える努力をすることだと思う。

エライ人に会う機会があったら直接言ってみる。若い人にあったら直接言ってみる。リアルでの機会を見つけて言ってみる。それを愚直に続けることぐらいしかわたしにはできないだろうけど、それをやる。

IPAのエライ人やNTTデータのエライ人に直接会う機会がある僥倖を利用して直接言ってみたいと思う。

IPAフォーラムって実はそーゆー機会を提供してくれたんだよね。実は午後からのセッションに参加して、午前中にそんなセッションがあったということを露知らず、エライ人に、コミュニティーがどうだとか個人を主体とした開発がどうだなんてなんて、ヨタ話を懇親会の場でかましていたのだ。そして、若い人に、あなた達の話をエライ人たちがメモを取りながら聞いていたよ、世の中変わるよ、君たちのコードでという話をしたいたりしたのだ。

エンジニアは文鎮に敬意を　－　Blog-side

業界の重鎮に対して、我々エンジニアは、敬意を示すべきなんじゃないか。

もちろん、おっしゃるとおりだと思う。そして、あなたの言うとおり、機会をみつけてお話をする努力もしている。

イメージを形にできない人は減衰する　－　404 Blog Not Found

ビジョンを語るのは文鎮の仕事じゃない。あなたの仕事である。

ありがとう。精進したいと思う。

 

若い人に人気のない産業は衰退する     http://blog.miraclelinux.com/yume/2007/11/post_1ab2.html

２0代のころ　－未来のいつか/hyoshiokの日記
http://d.hatena.ne.jp/hyoshiok/20040909

若い人に人気のない産業は減衰する

未来をイメージできない産業に人は集まらない。IT産業は人がすべてである。魅力のない産業は減衰する。

IPAフォーラム2007
【討論会】
「学生から見たＩＴ産業」と「ＩＴ産業から見た学生」
～ＩＴ産業は学生からの人気を回復できるか～
http://www.ipa.go.jp/event/ipaforum2007/program/discussion.html#tou-1

参加者がすごい。業界の重鎮。岡本晋氏（TIS株式会社　代表取締役社長）、浜口友一氏（社団法人情報サービス産業協会　会長、株式会社NTTデータ　取締役相談役）、藤原武平太氏（IPA　理事長）。

当日、このパネルディスカッションに参加していないので、下記の報道で様子を窺うしかないのであるが、「業界の重鎮もたじたじ」だったそうである。

IT業界不人気の理由は？ 現役学生が語るそのネガティブイメージ － ＠IT
http://www.atmarkit.co.jp/news/200710/31/ipa.html

この報道だけでは、なかなかその空気がわからない。IT産業の夢とかビジョンを雄弁に語られたのだろうか。

IT産業のイメージに対して、『岡本氏は「モノをつくっている会社は、イメージがモノで通じている。われわれの業界はモノを作るといってもソフトウェア、もしくはサービスを提供している。目に見えてイメージはわかないかもしれない。インターンなどで実態を見てからもう1度考えていただければいい」と学生を諭した。』と答えているようであるが、業界の重鎮が明確にビジョンを語れなくては困る。

コンピュータシステムによって世界をよりよくしていくのが使命なのではないか。ソフトウェアによって世の中を便利にしたり豊かにしているのではないか。

IT業界はどのような学生を求めているかに対し、『重鎮たちは「コミュニケーション能力に長けている人」（浜口氏）、「チャレンジングで好奇心旺盛な人」（岡本氏）』を挙げたそうであるが、営業だって、企画だって、コミュニケーション能力が必要であろう。IT技術者に専門性は必要ないのか。

業界の重鎮が学生に学生時代には専門を一生懸命勉強してきてくださいと言わなくてどうする。学校の成績がいい学生が実務で使い物にならないとしたら、教育機関にもっと実践的な教育を要求しなくてはいけない。例えば自動車のエンジンを設計する部署に文系の学生が採用されるか。ありえないと思う。機械科なりを卒業した学生が前提であると思う。

OSSのプロジェクトに参加することをわたしは強く勧めるが、学校で基礎を学ぶことは重要だと思う。

というようなことも考えていたのであるが、当日討論会に参加していた、学生さんの日記が下記にある。

IPAフォーラム2007で討論してきた - 東大MOT学生の奮闘記http://d.hatena.ne.jp/itoyosuke/20071101/1193932945

討論会の内容は報道されているよりも、さらに厳しい。

BtoBのビジネスをしている企業の業務が学生から見えにくいのは当然で、見えにくいなりに工夫をしないといけないと思う。でも、パネリストの口ぶりからは見えにくいのは当然のことで問題と感じていないというような雰囲気が伝わってきた。興味を持たなければ、インターンにも来ないだろうに。

ソフトウェアはモノではないからイメージしにくいというのは昔から使われていた言い訳である。先日NHKで放送された、「ポアンカレ予想」の番組は数学というもっと抽象的なものを見事に具体的イメージとして表現していた。プログラミングの楽しさ、面白さをもっと伝える努力がこの業界には圧倒的に足りないのである。問題と感じていないことが問題なのである。

ITを専攻している学生達からは、「就職時にITスキルが問われないのだとしたら、大学でやっていることには何の意味があるのか」という質問が出ていたのだけど、明確な回答はなかったと思う。その人たちは、ちょっとショックを受けていたような気がする。

大手SIベンダーの問題がここに垣間見られる。専門性を必要としない仕事なのか。それを言っちゃあおしまいよという事である。

その流れで、「入社時にITのスキルを問わないというのは、Googleのような企業の方針とは反対であるが、それですばらしいサービスを作ることができるのか」という質問が出たのだけど、「Googleの開発と日本のカスタムメイドなシステムを作るSIerの開発は違うもの。Googleはスモールチームで仕上げるが、日本は製造業的にラインを組んで仕上げるため、いろんな人材が必要になる。」とのこと。単に効率の悪いシステム開発をしているということではないかと思ったのだが、どうなのでしょう。使っている言語も違うだろうし、一概には比べられないかな。

大手SIベンダーからは銀行のオンラインシステムは作れるかもしれないがニコニコ動画とかmixiは絶対作れないということがよく分かる

この業界では、いつも「人材育成」がどうだということが語られるが、失礼ながら業界の重鎮がこの程度の認識だと、この程度の認識の人間しか集まらない。若い人たちに興味を持ってもらうためには、この業界の存在意義、ユメや志、ビジョンを熱く語る人が必要とされている。そして若い人たちがいっぱい就職したいと思う業界にこそ世界のトップノッチの人材が集まるのである。

誰もがまつもとゆきひろにはなれないが、教育と訓練と仕事の経験をつめれば、優れたプログラマにはなれるのである。ユメや志やビジョンを共有できなければモチベーションが続かない。それを語り続ける重鎮が必要なのである。

ブックマークのコメントも参考になる。

ブックマーク：IT業界不人気の理由は？ 現役学生が語るそのネガティブイメージ － ＠IT
http://b.hatena.ne.jp/entry/http://www.atmarkit.co.jp/news/200710/31/ipa.html

ブックマーク：IPAフォーラム2007で討論してきた - 東大MOT学生の奮闘記
http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/itoyosuke/20071101/1193932945

NHKスペシャル、「100年の難問はなぜ解けたのか～天才数学者　失踪の謎～」
http://www.nhk.or.jp/special/onair/071022.html

ソフトウェアの作り方を考える

「開発工程を別々に担当してはいけない」は思いのほか多数のブックマークを頂いた。コメントやブックマークを拝見しながらあれやこれや考えた。わたしの飛躍する思考というか雑な議論で辟易している方もいらっしゃるかとは思うがもう少しお付き合いいただければ幸いである。

わたしの経験は、このブログの読者の皆さんはご存知かもしれないが、ソフトウェア製品の開発経験に偏っている。米国系ハードウェアベンダーでコンパイラやRDBMS製品を開発していた。その後西海岸のソフトウェアベンダーに転職してそこでRDBMS製品の開発に従事した。そしてOSSの可能性を信じてミラクル・リナックスの設立に参加したのが約7年前である。顧客向けアプリケーション、例えば社内システム構築（人事、財務、購買などなど）の経験はない。

さて先の「開発工程を別々に担当してはいけない」ではいろいろな論点をごった煮風に突っ込んだものだから分かりにくくなったので、いくつか細かく分けて考えてみる。

人月のワナ。

多くの人が指摘しているようにソフトウェアの価値をかかった工数（人月）で評価するというのはまるっきりナンセンスである。熟練者が一ヶ月で作成できるものを初心者が6ヶ月かかったとすると、後者に6倍お金が払われるか、それだけの価値があるか。もちろんない。

この場合の正しくは、ある実装した価値、通常は機能で近似するかと思うのだけど、それに見合った価格が支払われるべきである。単位機能を実装する工数が少なければ少ないほど、利益があがるので、ソフトウェア開発における生産性向上のインセンティブが発生する。人がソフトウェアを作る以上、一人一人の専門性、技術を向上させることに高いインセンティブが発生する。企業にとっても、未経験者（安い人材）を雇用し、その利ざやで稼ぐのではなく、より専門性の高い人間を雇用し、その生産性の高さで利益をあげることに、そして教育やトレーニングに投資すること（生産性や品質の向上に繋がる）に合理性が発生する。

ソフトウェアである機能を実装するために、設計、プログラミング、テストという工程があったとして、それを工程ごとに分離して、それぞれを単能化することによって生産性を向上するという、古典的な工場モデルがソフトウェア生産に適用可能なのか。ひたすらネジを取り付けるだけの自動車工場なんていうのがいまどきありうるのか。ソフトウェアの設計とプログラミングそしてテストというのがそもそも分離可能な工程なのか？

わたしは、そのような工程を単純に分離することは難しいし、分離することは専門性を高めることには繋がらないと思っている。分離することによって、生産性が向上するという証拠もほとんどみたことがない。ソフトウェアを実装する能力を高めるためには、渾然一体のプロセスである、設計、プログラミング、テストを等しく経験しなければならないと考えている。その経験を積むことによって一人一人の専門性すなわち生産性が向上していくと考えている。

テストとプログラミングをするものは分けるべきだと言う議論ももちろんあるが、ここでいうテストは実装の妥当性を評価するいわゆる内部テストに相当する部分で、仕様の妥当性を検証する統合テストあるいは受け入れテストのところではない。昨今ではテスト駆動型開発という手法で広く取り入れられている方式である。

ということで、工程分離することによって生産性が向上するという可能性が少ない、むしろ悪化すると考えている。一方で機能による分離では生産性向上がみこめると考えている。

ITゼネコンうんぬんかんぬんはまた別のお話なのでいつの日か別にお話することにしたい。

開発工程を別々に担当してはいけない

古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。

特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。

よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。

ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。

一度固定した文書は次のフェーズで変更するとなると、手戻り工数が莫大になってしまうので、通常は、前工程で決めたことは、後工程で変更はしない。後工程で変更しないという前提で文書を作るので、いろいろ長期間にわたって検討などをするのであるが、実装してみないとわからない事などもいっぱいあるので、なかなかそうは上手くいかない。

実装してみて、できたものは最終ユーザからみると使えないものでも、仕様書に明記されていたものをその通りつくっている限り実装者(製造)の責任ではない。

大量な文書を作るし、各フェーズのレビューの工数も重いので開発スピードは遅くなりがちで、当初予定していた利用環境やユーザの要求というのも時間とともに変化するので、実装が終了した時点では仕様そのものが陳腐化するという事もすくなくない。ひらたく言うと、一生懸命つくっていたのに使えないものができてしまったということである。

ユーザアプリ開発、SI(System Integration)の現場では、おおかれすくなかれ上記のようなパターンがあって、それに元請け、下請けという産業構図がはめこまれていて、元請けが大手ベンダー、下請け、孫請けが中小ベンダーという風になっていたりする。大手がゼネコンの立場になって、多くの下請け、孫請けを使って大規模システムを構築する場合、いろいろな意味あいを含めてITゼネコンといったりする。

工程を別々に担当することによって、数々の問題が発生する。

通常は上流の方が単価が高く、下流の方が単価が安いので、だれも下流をやりたがらない。下流工程は結果として単価の安い経験の浅いエンジニアをつけることになる。工程は通常、組織によってわぎりにされているので、下流工程の作業をやる人がノウハウをためて上流作業をになうという機会がない。元請けはいつまでたっても元請けだし、孫請けはいつまでたっても孫請けである。孫請けの経営者も経営者で、単価は安くても、とりあえず人の分だけ売上があがるので、大手にぶらさがっていれば食いっぱぐれない。そのため経営の緊張感はない。利益率は低いがどうにか食っていける。というような構造がある。

下流にいけばいくほど単価のたたきあいになるので経験豊富なベテランを配置することが難しくなり、若年層エンジニアを使いすてることにならざるをえない。いわゆる35歳停年説である。

業界全体としてエンジニアを使い捨てにすることには百害あって一利もない。にもかかわらず、抜本的な対策、方策がとられているようには見えない。

なぜなんだろう。

わたしには、この工程によって作業を分担するという方法が諸悪の根源であるように思えてならない。小さい会社が何十人もエンジニアを集められないので元請けになれないという事情があるというのは百歩譲ってあるとしよう。大規模な開発をするため何社かで共同作業が必要だったとしよう。その場合の分担を工程ごとに輪切りにするのではなく、機能ごとに縦に切る事を提案したい。

つまり、ある機能について、一社ないしは一人が仕様の決定から設計、実装、内部テストまで担当するのである。キモは設計者と実装者は同一人物とするのである。これを分離しない。

なんでこんなことを言うかというと、実装と設計は不可分で、実装をしてみて初めて気がつくこと、設計をしてみて初めて気がつくことなどがあり、実際の設計と実装というのはいきつもどりつのプロセスである。このいきつもどりつがない限り、いい実装などはできはしない。設計と実装を分断している限り、しょぼい設計としょぼい実装にしかならない。初めから完璧な設計などはないのである。完璧な設計でない以上、しょぼい実装しかうまれてこないのである。

工程を分離するのは悪なのである。

工程を分離するために専門性が蓄積されない。より高度な実装を作成するインセンティブも発生しない。

『「渡された仕様書を実装するサラリーマンプログラマ」の悲哀』にあるのは工程を分離されたプロジェクトの悲哀であって、サラリーマンかどうかは無関係である。

わたしはソフトウェア工場というコンセプトそのものを否定するつもりは毛頭ない。工学的なアプローチによってより品質の高い(バグ密度の低い)ソフトウェアをより少ない工数で生産するということは可能であると思う。QC活動のような方法論ですら有効な場面は少なくないと思う。

しかしXPで実践されているようなベストプラクティスの多くは工程の分離ではなく設計と実装の渾然一体となったプロセスである。

日本のソフトウェア開発の現場の国際競争力のなさというのがあるとしたら、ITゼネコンをよしとした、上流下流工程を是認したソフトウェア生産方法論にあるのではないか。そこに構造的な問題があるのではないかと思うのである。人月で工数をはかる事がやりだまにあがっているが、根本的な問題は、工程を分離して、下請けにだすというソフトウェア生産方法であると思う。

ちなみに、米国のソフトウェア製造業では(マイクロソフトもオラクルも)、設計する人がコードも書くのである。それが一般的な姿である。わたしの場合(DEC時代もオラクルの時)も、そうであった。

プログラマの仕事はプログラムを読むことである/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/10/post_9db7.html

フリーソフトウェアの価値観

80年代に消滅しかけたハッカー倫理を実現するコミュニティは、リチャード・ストールマンの孤軍奮闘ともいうべき活動によって細々とだが生き延びていた。

リチャード・ストールマンはソフトウェアは私有すべきではないという信念のもとFSF (Free Software Foundation)を立ち上げ、GNU (GNU's Not Unix)　というUnix互換のOSを作ろうとしていた。エディタ（emacs)、コンパイラ(gcc)、shell script (bash)、デバッガ(gdb) などなど様々なフリーソフトウェアを精力的に開発し、公開していった。

MITのAI研究所はLispマシンの商用化によって壊滅的な打撃をうけていた。優秀なハッカーたちは高給で商用Lispマシンベンダに雇用され、ソフトウェアの共有は、知的財産権の名の下に不可能になった。DECがPDP-10のサポート中止した結果、彼らのよりどころであるITSの未来も閉ざされた。

リチャード・ストールマンは占有ソフトウェアを書くくらいならウェイターにでもなったほうがましだ、だけどそれは自分の才能を浪費することになる、と後に語っている。

しかしながらリチャード・ストールマンの不屈の精神と努力によって80年代のGNUプロジェクトは着々と成果をあげていた。OSカーネルを除いては。

そして90年代Linuxが登場する。当時フリーのPC UnixといえばBSD Unixを移植した386BSDなどいくつかのライバルがいたことにはいたが、BSD陣営はAT&Tとの訴訟問題を抱えていたし、開発方式も、ごく少数のコアメンバーによる開発という従来型の方式で、爆発的に普及するまでにはいたらなかった。

Linuxはそれらのソフトウェアとまったく異なる手法で開発されている。Linuxの開発は、ごく初期の段階から、大勢のボランティアたちがインターネット上で共同作業する形で進められていった。誰かがすべてを監視するワンマン体制によって維持されていたわけでもない。Linuxカーネルのクオリティはリリースを毎週行い、数日中に寄せられてくる何百と言うフィードバックを素早く反映して次のリリースを行なうという無邪気なほどに単純なアップデートを頻繁に繰り返すことで維持されていったのである。このようにリリースを極めて頻繁に行なうことで、Linuxカーネルに次々と追加されたコードの善し悪しは、進化論的に淘汰されていった。そして、この開発方式が成功したことに驚かぬ者はいなかった。中略。真のプログラマたちが活動の場とするインターネットが社会の主流に躍り出たおかげで、彼らの文化そのものも表舞台でもてはやされるようになった。
（真のプログラマたちの国ーー概略史、オープンソースソフトウェア、倉骨彰訳）

リチャード・ストールマンのはじめたフリーソフトウェア運動はリーナス・トーバルズという若者ハッカーとインターネットの勃興によって新しい形で再出発したのである。彼は古きよき時代を知る最後のハッカーであったが、インターネット時代の最初のハッカーはリーナス・トーバルズと言ってもいいと思う。

ビル・ゲイツに代表される、ソフトウェアのコピーなんてとんでもない、独占的な所有権を持つことで、開発投資を回収し、利益を得て技術革新を促進するのだ、という考え方は、ビジネスモデルとしては非常に分かりやすく、結果として彼を世界一の金持ちにし、マイクロソフトを世界一のソフトウェア企業にした。

ソフトウェア商用化は結局のところハッカーにとっても大きな影響をあたえ、ソフトウェアの印税を貰って金持ちになるという誘惑に多くのハッカーたちは抗えなかった。80年代から90年代のソフトウェアベンチャーはビル・ゲイツモデルのコピーと言えるだろう。

しかしながらハッカー倫理に象徴的に語られている、情報公開が善で、コンピュータは世界を良く出来るという考え方は、人がなぜプログラムを作るのかという根源的な問いかけに、もちろん経済的な成功（金持ちになりたい）もあるにはあるけど、それ以外の動機もありうるのだということを示した点で興味深い。

Red Hatが株式公開をしたとき、梅田望夫は

レッドハットの勃興は、貪欲で力強い資本主義がオープンソースという怪物をもぐいっと飲み込んでしまった瞬間であった。「あどけない顔をした天才たち」は、あっと言う間に資本主義に飼いならされたのである。
資本主義に飼いならされたLinux。199ページ。シリコンバレー精神。梅田望夫

と記している。確かにフリーソフトウェアあるいはオープンソースが資本主義（ビル・ゲイツモデル）に飲み込まれたという空気もあった。

しかし、8年経ってみて、周りをみわたしてみると、情報公開は善で、コンピュータによって世界を変えてやるということを本気で思って実践している若きプログラマたちを沢山発見できる。

確かに彼らはリチャード・ストールマンほどフリーソフトウェアと声高には主張しないが、彼らは彼らが作ったプログラムによって世界になんらかのインパクトを与えることをモチベーションとしている。もちろん、経済的な動機が全くないといえばウソになるかもしれないが、それがトッププライオリティではない。

ビル・ゲイツに代表される知的財産権をたてにとったモデルと、フリーソフトウェア・オープンソースに代表されるハッカーモデルとで、どちらがより価値を継続的に生み出すのか。ハッカー的価値観を持った方法論というのが注目されている所以である。

先日開催されたITproチャレンジにはそのような若手ハッカーが集まっていたことを付記しておく。

ITpro Challengehttp://itpro.nikkeibp.co.jp/ev/challenge/index.html
http://itpro.nikkeibp.co.jp/article/Watcher/20070906/281310/

オープンソースソフトウェア　彼らはいかにしてビジネススタンダードになったのか
http://www.law.co.jp/okamura/OpenSource_Web_Version/Web_version991206.html
Web版は無償で公開されている。

第2章、真のプログラマたちの国―概略史、エリック・S・レイモンドを参照。

ハッカー倫理/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/09/post_972f.html

ビル・ゲイツの手紙/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/09/post_af17.html

ITpro Challenge/未来のいつか
http://d.hatena.ne.jp/hyoshiok/20070907#p2
ITpro Challengeその２/未来のいつか
http://d.hatena.ne.jp/hyoshiok/20070908#p2

ITPro Challenge無事終了/404 Blog Not Found
http://blog.livedoor.jp/dankogai/archives/50908309.html

ビル・ゲイツの手紙

古きよき時代のハッカー倫理はプログラムは自由に共有すべきものであった。当時プログラムに商業的価値はなかったし、コピーして利用することは理にかなっていた。

IBMがソフトウェアをアンバンドルしたことによって、ソフトウェアに商業的な価値が発生したのは60年代から70年代のころであろう。そしてこのソフトウェアのアンバンドルがまさにソフトウェア産業を発生させた。

これはメインフレームの世界であってホビースト達は自分たちでパソコンを組み立てプログラムを共有していた。

さて、当時のハッカー倫理ではプログラムをコピーすることは犯罪でもなんでもなかったが、パソコン向けのソフトウェアを書いたビル・ゲイツがそれに噛み付いた。彼はMITSという会社が作ったパソコン向けにBASICのインタプリタを書いたのだが、それをホビースト達が勝手にコピーしていると文句を言った。

それが、ビル・ゲイツの「ホビーストへの公開書簡」である。英語版のWikipediaにその写しがよめる。
http://en.wikipedia.org/wiki/Open_Letter_to_Hobbyists

彼はこんな主張をしている。

ホビーコンピュータのマーケットで最も重要な問題は良いソフトウェアや書籍がないことである。
我々はホビーマーケットが拡大すると予想しプログラマを雇用してAltair BASICを開発した。
ところがBASICを利用しているほとんどのユーザがBASICを購入していない。
皆さんは人のソフトウェアを盗んでいると認識するべきだ。ハードウェアにはカネを払うがソフトウェアは共有するものなのか？
これはフェアなのだろうか？
あなたたちがやっていることが良いソフトウェアが書かれることを妨げている。誰がカネにもならないことにプロフェッショナルな仕事をするのだろうか。あなたがたがやっていることは窃盗である。

彼の主張はもちろん賛否両論を巻き起こした。しかし時代はまちがいなくホビーコンピュータの牧歌的な時代からPC産業の勃興すなわち商業化の道へとたどっていった。そして歴史が示すとおりビル・ゲイツは世界一の金持ちになりマイクロソフトは世界一のソフトウェア企業となった。

ビル・ゲイツは1975年にマイクロソフトを創業し、ラリー・エリソンは1977年にオラクルを創業している。70年代後半はソフトウェア産業の出発点である。

ソフトウェアを書いて印税を得ることに魅力を感じる者たちが徐々にだが増えていった。かつてのハッカーたちが一夜にして億万長者になるということもあながち夢物語ではない。あまたのソフトウェアベンチャーは「ソフトウェアによって社会をよりよいものにする」という「ハッカー倫理」と共通の価値観を持つ一方で、「ソフトウェアを共有すること」を拒み占有することによって莫大な利益を得ようとしていたのである。

「ハッカー倫理」で紹介したように、ソフトウェアは皆で共有すべきだという人々は、リチャード・ストールマンを除いて商業化の名の下にほとんど消え去ったかのようにみえたのが80年代だった。

ソフトウェアを占有することにより利益を得る。

それを実証したのがビル・ゲイツの最大の功績である。

ソフトウェアを共有することによって社会をよりよくすると信じ頑なに孤軍奮闘していたのがリチャード・ストールマンである。彼の不屈の精神とビジョンが、90年代のオープンソースによって形を変えて蘇ったのである。

ビル・ゲイツの思想とリチャード・ストールマンの思想のどちらがより普遍的な価値を持続可能な形で生み続けるのか？21世紀の解くべき問題である。

ハッカー倫理／ユメのチカラ http://blog.miraclelinux.com/yume/2007/09/post_972f.html