Life is beautiful

　先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。

　こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。

　「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあるが、それにも全く賛成できない。私はこの業界で多くのエンジニアも使ってきたが、優秀なエンジニアとそうでないエンジニアの生産性は（誇張抜きで）２０対１ぐらいである。そんな簡単な作業しか出来ないエンジニアとも呼べないようなエンジニアが沢山いてもマネージメントが大変なだけである。そもそも、就職した段階で詳細仕様書に従ってしかプログラムを書けないような人が、ソフトウェアエンジニアになっても幸せになれるとは思えない。

　そしてもっとも許せないのが、そういった上流→下流という階層構造でプログラムを作る工程そのものだ。

　これに関しては、自信を持って言えるのだが、「どんなに優秀なエンジニアでも、決してプログラムを自分自身で書かずに良い詳細仕様を作ることは出来ない」という絶対的な法則があるのだ。私の知っている優秀なエンジニアは、皆それを知っており自ら実行している。もちろん、彼らはプログラムを書き始める前に大まかな設計をするのだが、十分な経験を積んだエンジニアは、その段階でのものが「仮設計」でしかないことを良く知っている。だから、その段階で詳細設計書を書くような時間の無駄使いはせず、すぐにプログラム（もしくはプロトタイプ）の作成にかかるのである。

　実際にプログラムを書き始めて初めて見えてくること、思いつくことが沢山あるので、それを元に柔軟に設計を変更しながらプログラムを書き進めるのである。作っているプログラムが予定通りに動き始めてやっと、設計も完成に近づくのである。（ただし、そんな作り方で作ったプログラムはソースコードが汚くなってしまうケースが多いので、この段階から出来上がったプログラムを、読みやすさ・メンテナンスの高さを重視して大幅に書き直すことを強く薦める。エンジニアによっては、ここで一度作ったプログラムを全部捨ててしまってもう一度全部作り直す人もいるぐらい、この作業は重要だ。）

　世界を又にかけてソフトウェア・ビジネスをしている米国の会社は、MicrosoftにしてもGoogleにしても、この法則にのっとって、アーキテクト自らががプログラムを書いている。

　しかし、私が一度働いたことのあるNTTの研究所では、ほどんど自らソフトウェアの開発をしたことの無い人達が詳細資料書を書き、それを外注に発注してプログラムを書かせる、というソフトウェアの作り方をしていた。学生時代からプロとしてソフトウェアを作っていた私は、新入社員にも関わらず「こんなやりかたじゃ良いソフトは作れません」と上司たちにくってかかったのだが、誰一人として理解してくれなかった。

　私には、この「自分でプログラムを書かない上流のエンジニアが詳細設計書を作り、下流のエンジニアがコーディングをする」という工程そのものが、根本的に間違っているとしか思えないのだ。「下請け」という弱い立場にあり、経験も少ない下流のエンジニアが、「仕事を発注してくれる大切なお客様」である上流のエンジニアに対して、「この部分は、設計を少し変更をした方がプログラムがシンプルに書けるし実行効率もあがると思うんですが、変えちゃっていいでしょうか」などと言うことが出来るとは思えない。下流のソフトウェアハウスの経営者にとっても、そんな余計なことを言うエンジニアよりも、仕様書通りのプログラムを納期以内に黙って作るエンジニアの方が使いやすいのではないだろうか。

　日本のエンタープライズ系のソフトウェア業界は、そんな根本的に間違ったソフトウェアの作り方を長年してきたために、まるで建築業界のような下請け・孫請け構造が出来てしまい、下流のエンジニア達が十分な経験も得ることが出来ずに低賃金でこき使われ、業界全体として国際競争力をなくしてしまう、という状況に陥ってしまったのではないか、というのが今回の私の仮説である。

　もちろん、米国に住む私が得られる限られた情報だけから立てた仮説でしかないので、何か大きな勘違いをしているのかも知れないが、少なくとも今の日本を見ると、階層構造化されたエンタープライズ系のエンジニアたちよりは、オープンソース系の「設計からコーディングまで全部自分でやる」エンジニア達の方がずっと元気があるし幸せそうだ、ということだけははっきりと言える。

　ちなみに、この話を書いていて思ったのだが、プログラムの仕様書は料理のレシピに似ている。ソフトウェアのアーキテクトが自らプログラムを書いたり、下っ端のエンジニアの書いたコードをレビューするのは、レストランのシェフが自ら料理をしたり、下っ端の料理人の作ったスープの味見をするとの同じである。もちろん、レストランに行く側の立場になってみれば、そんなレストランで食事をしたいのは当然である。シェフがレシピだけ書いてキッチンにも立たないレストランには行きたくないし、ましてや自分で料理したこともないシェフが書いたレシピを元に作った料理がおいしいわけがない。

　去年の６月に書いた「AJAXの本質」というエントリーには、相変わらず新しいリンクが張られたりして読者が絶えない。Google でAJAXをサーチしても２５位前後なので３ページ目になってしまうが、そこからの参照も相変わらす多い。

　そんな理由もあってか、ある出版社からAJAXに関する執筆を依頼された。実はずいぶん前（一月）に依頼を受けて、「了解です」と軽く返事をしておいたのだがすっかり忘れていたのだ^^;。今週になって編集者から連絡があり、来週の月曜までに仕上げて欲しいという。

　ブログで文章を書くのに慣れたとは言え、６０００字の原稿を一日二日で仕上げるのは辛い。そこで思いついたのが、一つの記事として書こうとするのではなく、一連のテーマを扱った複数のブログのエントリーのような気持ちで書くこと。

　私のブログエントリーは、平均して６００～７００字なので、８～９個ぐらいのエントリーと思えば良い。そこで、まず９つのミニテーマに絞り込む作業にかかったのだが、それに小一時間かかってしまった。

　そこからは一気に書き進むだけだ。最近は一つのエントリーを２０分ぐらいで書き、さらに１０～２０分かけて推敲する、というテンポで書いているので、その推敲の部分を後回しにすれば、３時間で９つ全部書けるはずだ。

　しかし、色々とインタラプトは入るし、ランチの約束はあるし、ミーティングはあるはで、結局丸一日かかってしまった。とりあえず推敲前のものを編集者に送付し、大体の方向性に関して確認を取り、明日と週末で推敲を終えて日本時間の月曜日（こちらの日曜日）には脱稿するという計画である。なんだかハラハラドキドキだが、これはこれでアドレナリンが上がって楽しい。

　書籍のタイトル、発売日などが決まり次第報告したいと思うので、stay tuned!

　【英語うんちく：この最後の言い回し"Stay tuned!" は、元々ラジオのアナウンサーが、コマーシャルの前に「まだまだ面白い番組が続くからコマーシャルの間に他のチャンネルに回さないでね」という意味で言う決まり文句だったが、それがメールやブログの最後に、「また少ししたら続報を書くから、楽しみにしていてね」という意味で言う決まり文句として使われるようになったもの。覚えておくと色々と重宝するフレーズである。】

　【追記】ちなみに、写真は妻が作ってくれたマグロのたたき。まわりだけを少し炒めたマグロに、海草サラダと大根おろしを乗せて、ビストロドレッシングをかけて食べると最高。刺身で食べるよりおいしいかも。

　昨日のエントリーで書いた「シアトル近郊の交通情報表示アプリ」、コメント欄で励まされたこともあり、全ソースを公開することにした。ただし、会社のサーバーで公式に遊ぶことになったので、発表の際にはまず英語で解説を書かねばならなくなってしまった。とりあえず、これが解説ページである。

　King Country Traffic Map

　たいしたことが書いてあるわけではないので、全部を日本語に訳すこともないとは思うが、肝となる How it works （どうやって動いているか）だけは日本語での解説が必要そうだ。そこだけ抜き出して意訳すると、

となる。大して難しいことはしていないのだが、一番工夫をこらしたのは、画像をスライスするロジックに複数のスレッドが同時に入って来ないようにする仕組み。ファイルロックも含めて、色々なものを書いてみたのだが、結局のところ、最初にキャッシュされた画像が古いことに気がついたスレッドが間髪をおかずにキャッシュされた画像ファイルのタイムスタンプを新しいものにしてしまう、というものすごくシンプルなロジックが一番適していることに気がついた。こうしておくと、後から実行されたスレッドはキャッシュ画像が新しいものと解釈してスルーしてしまうので、ファイルロックを使った時のようなスレッド渋滞の起こる心配がない。唯一の問題は、後から来た方のリクエストを発行したほうのデバイスに少し古い画像が表示される可能性があることだが、サーバーへのアクセスが多いときは最大でも６分前の画像になるだけだし、サーバーへのアクセスが少ない時には、めったにこの状況にはならないので、これで十分なはずである。

　ちなみに、ソースコードへのリンクは英文のページにも張ってあるが、ここにも張っておく（ダウンロード）。ちなみに、このアプリをデバッグしたりビルドしたりするのに必要なSDKは、http://developer.uievolution.com/ からダウンロードできる。SDKは１．５とベータ版が出たばかりの２．０があるが、このサンプルに限って言えば、１．５の機能しか使っていないので、どちらのSDKでも走るはずだ。なお、デバッガー上のこのアプリを走らせる場合、RETAILモードのままで実行するとサーバーにアクセスしてくれないので、DEBUGモードで走らせる必要があるので要注意。

【追記】 DoCoMo版のUIEPlayerがPHPから返されたUJBCファイルをUJBCとして認識してくれないというバグを発見（大勢の人の時間を無駄にする前に、見つけてよかった^^;）。原因は判明したので、今は担当者の速やかな対応を待つのみ。早くしてくれ～。

　今年に入ってからレンタルサーバーを使って色々と遊んでいる私だが、そんな私を見て、社内からもそういった「遊び」の部分を会社として正式にサポートする仕組みを作るべきでは、という声が上がってきた。やっと分かってもらえたようだ。

　そこでさっそくサーバーを「ラボ」用に一台立ち上げてもらい、その上で前から作りたいと思っていたアプリを作ってみた。携帯電話用の「シアトル近郊の交通情報表示アプリ」である。シアトル近郊の交通情報は、ワシントン州の交通局のウェブサイトに無料で公開されているのだが、携帯電話から見られるようには作られていないのだ。

　そのサイトに表示されている画像をこちらのサーバー側で一度取り込み、細切れにスライスした上でディスク上にキャッシュし、それを携帯電話にダウンロードしたUIEngine上に表示してGoogle Mapのように自由にスクロールできるようにする、というアプリを前から作りたかったのだ。相手はウェブサービスとして提供しているつもりはないかも知れない点が若干微妙だが、もともと住民の税金で運営されているサービスだし、こちらも商用サービスを作るつもりも無いのだから大目に見てもらおう。

　ということで、覚えたてのPHPを駆使して、サーバー側にキャッシュ付きのイメージスライサーを作り、それにここでも公開したことのあるMap Viewerを組み合わせて完成。プログラムは結構簡単に作ることが出来たのだが、サーバー側に色々と不備があり、そこで苦労してしまった。

　しかし、これでいつでもどこでも交通情報がチェックできるようになった。シアトル近郊も人口が増えて来たので、ところどころで激しい渋滞が発生するので、これは便利である。まあ、米国のカーナビが日本のカーナビのように交通情報と連動してくれればこんなものは必要ないのだが、それにはまだ何年もかかりそうなので、しばらくは重宝しそうだ。

【追記】ちなみに、結構汎用性があるプログラムが出来たので、色々な所に応用できそうである。いっそのこと正式なサンプルとしてソースコードを公開し、たくさんの方々の知恵を借りながら色々と試していくのも良いかもしれないと思い始めている私である。

　日本では春一番が吹いた（正確には、気象庁が「春一番」と認定するに値する風の強い日があった―気象庁の「春一番」について参照）らしいが、シアトルにもこの時期には強い風が吹く。ただし、英語には「春一番」のような粋な言葉はなく、テレビの天気予報のでは単に「ストーム」と呼ぶだけである。

　この時期のシアトル地方の強い風は積乱雲によって起こされる風なので、相変わらず氷点下に近い気温と、積乱雲で作られる上昇気流の影響で雹（ひょう）が降ることが多い（雹は、湿った空気が冷やされて凝固した氷の粒が上昇気流でもまれているうちに成長してできる―詳しくはwikipedia参照）。

　今年は先週の金曜日の夕方に雹がふった。風流な人ならば、「ガラス窓にあたる雹の音が私には春が窓を叩いているように聞こえる」と言いそうだが、私の頭に最初によぎったのは、「車は、地下駐車場だから大丈夫」である。

　一度だけ外にいるときに激しい雹に降られたことがあるが、その時はゴルフの最中だったので、傘をさしてプレーを続けた。ドライバーやアイアンショットにはそれほどの影響は無かったのだが、グリーン上の雹のお陰でパッティングがあまりにも難しくなってしまい、やむ終えず途中で中断したことを覚えている。

　土曜の朝になって庭をみるとビー球大の雹が溶けずに芝生の上に残っているので、すかさず携帯電話でパチリ。シアトルの春も近い。

　このブログの副題にもあるとおり、私は高校生の時から半田ごてを握ってパソコンをプリント基板から作ったり、アセンブラでプログラムを書いて雑誌に投稿していたりした、いわゆる「パソコン少年」の第一世代である。

　そんな私が最初に C という言語に出会った時は、「Cでプログラムを書くのは素人だけだ。本当のプログラマーはアセンブラだ。それも１６進のマシン語を直接書けなきゃだめだ」などと生意気なことを言っていたものである。しかし、大学に入ってから作った Candy をディスプレイドライバーを除いて全てCで書いたのも私である。

　C++ にも最初は抵抗があった。当初はコンパイラの性能も低かったので、とんでもないコードを生成していたし（コンパイラの吐き出したマシン語を読まずにはいられないたちであった）、「オブジェクト指向の本質は言語ではない、プログラミングスタイルだ」（どこかで聞いたことがある）と言いながらあえて C でVTalbleを作ってCOMのプログラミングをしていたものである（Windows95 には私がCで実装したCOMオブジェクトが複数ある）。

　C++ にやっと慣れたころに普及し始めた Java にはもっと抵抗があった。今となっては笑い話だが、「プログラマー自身がメモリの管理をしないで効率の良いプログラムが書けるわけがない」と真っ先に批判したのも私である。

　そんな私がやっと本気で Java でプログラムを書き始めたのは UIEvolution を設立した２０００年からであるが、今度はさらに Perl、PHP、Ruby といったスクリプト言語へのシフトが始まっているではないか。若いエンジニア達には負けられないとやっと勉強を始めたのが今年の１月。最初は不自由でしかたがなかったが、ようやく小規模なプログラムならなんとか書けるようになって来た。

　なんでこんなことを長々と書いているかと言うと、昨日、なかなか面白い経験をしたからである。

　UIEngine にクライアント側での非同期なデータバインディングをさせるためのサーバー側のモジュールにミニコンパイラ、というものがあるのだが、今まではC++版とJava版しか用意していなかったのだ。大企業を相手にしている分にはそれでも十分なのだが、今時のハッカー達からのフィードバックによると、「それではぜんぜんダメ」なのだそうである。

　そこでC版のソースコードを元に、PHP版を作ることに決めたのが先週。移植を始めたのが昨日なのだが、幾つか驚いたことがある。まず第一に、移植がものすごく簡単であったこと。結構複雑なプログラムなので、１週間ぐらいかかると見ていたのだが、一日で終わってしまった。次に、ソースコードがものすごくコンパクトになったこと。Cだと２０００行のプログラムがPHPだとわずか２００行である。最も効果的だったのが、テーブルデータを一つの array で表現できてしまう点で、そのおかげで API がものすごく簡素化できたのである。テーブルデータを持った array をコンストラクターに渡すだけで良いので、テーブル上のデータ一つ一つに関して addField() を呼ばなければならない C 版のAPIとは比べものにならないぐらい簡単だ。

　そうやって作った PHP のプログラムを見ながら思い出したのが、上に書いた「本当のプログラマーはマシン語が書けなきゃ」と強がっていた昔の自分である。一度否定したものを、いつの間にかちゃっかりと使ってしまっている私の身代わりの速さを、私自身は「柔軟性がある」と高く評価しているのだが、半周ぐらい遅れて走ってくる部下にとっては結構迷惑だ、というのが巷（ちまた）の評判である。やっと追い付いたと思った時には、「おまえどっちに走ってんの」と言われるのだから…。

【ある飲み屋での会話】

☆：　中島さん、ブログからの人材募集、成功したそうですね。
★：　うん、なかなか個性の強い人たちを集めることができたよ。
☆：　スクエニのジャマイカプロジェクトの人材募集にも協力してくださいよ。
★：　いいけど、ただ人材募集ページにリンクを張るだけじゃ誰も応募してこないんじゃない？
☆：　そうですね、何か募集したくなるようなことを書かなければいけませんね。
★：　そうだ、イイことを思いついた。ジャマイカのビジョンを説明する資料、作ったよね。
☆：　例のマンガですか…
★：　あれを、僕のブログで一部公開しちゃっていいかな？
☆：　大丈夫だと思いますけど。
★：　それを見せて、「読みたい！」と思わせて、応募してきた人にだけ読ませてあげるって言うのはどう。
☆：　面白いかも知れませんね。
★：　じゃあ、こんな感じでエントリー書くよ。題名は、「スクエニの未公開マンガ…

　ジャマイカプロジェクトの人材募集ページ

　ゲーム業界全体がイノベーションのジレンマに陥りつつある今、スクエニが今後それをどうやって打破しようとしているのか、どんなことをやろうとしているのかに興味のある人は、こういった人材募集ページから妄想を膨らませてみるのも悪くないかも知れない。（ここまで書けば、かなりの人がクリックするでしょう。応募して来る人数は保障しませんけど…。）

　「元MSエンジニア、ついにマックを買う」というエントリーを書いたのがわずか９ヶ月前だとは思えないぐらい、あっという間にアップル好きになってしまった私の一家には、今や iPod ３台と Mac ２台が大活躍をしている。私の期待していた通りの（参照）Front Row を搭載した新型Mac mini を発売してくれるアップルには、妙に購買意欲をそそられて困ってしまう。

　そんな私が少し前に書いた「スティーブジョブズに学ぶプレゼンのスキル」。それが、Mac People の編集者の目にとまったようで、特集記事への記事の投稿を頼まれた。

　このブログのおかげで文章を書くことにすっかり慣れてしまった私が、「あいよっ」と二つ返事で引き受けて書いたのがMac People ４月号の特集記事「ジョブズのプレゼンに学べ！」の冒頭のコラム。内容は先のエントリーを膨らましたものだが、編集部の人がその後３ページにわったって実際の基調講演の写真入りで解説を加えてくれたものだからとても説得力のある記事に仕上がっている。

　こんな形でブロガーのエントリーが編集者の目にとまって既存メディアにコラムを書くように依頼される、などということは今後もっともっと増えて行くはずだ。やはり雑誌やテレビという既存メディアにはそれなりの良さがあるので、こういう形でネットとのコラボレーションが起こっていくのが一番自然な流れなのだろう。

　ちなみに、この記事に添付された私の照会紹介文が、私の過去の経歴をずらずらと書くのではなく、そこはさらっと流した上で、「ブログ『life is beautiful』も開設 URL=http://satoshi.blogs.com/」と書かれていたのが妙に嬉しい。少しづつだが、私のアイデンティティが、「元Microsoftの中島」から「life is beautifulの中島」にシフトしているようだ。それが嬉しいのは、「いつまでも現在進行形の自分でありたい」私がいるからなのだろう。

　「Web2.0を活用する１０の方法」その９は、Reuse Other Services Aggressively―他の会社のサービスを積極的に活用しよう。筆者は、ソフトウェアの開発コストはスクリプト言語などで従来より格段に安くなったのに対して、情報やコンテンツを集めるのは相変わらずとても大変であると指摘した上で、Google Map や Craiglists が提供するウェブサービスを積極的に活用しようと薦めている。

　他の会社のサービスを再利用するべきかどうかは、「どこで勝負するか」を考えればおのずと明らかになってくると思う。ネットで書籍の流通システムまで作ろうとしている会社がアマゾンのウェブサービスを使うのは明らかに間違っているが、自社なりのユニークな書評やランキングを備えたバーチャル書店を作るのであれば、アマゾンのウェブサービスを使うのは理にかなっている。

　逆の立ち場から見れば、「この部分だけはこの会社に任せてしまった方が良いかな」と思わせるぐらい圧倒的な情報量を誇るサービスをどこよりも先に作ってしまえば勝ち、ということである。この点にいち早く気づいて先手を打ったのがGoogle、そこにやっと気がついたのがMicrosoftである。

　ソフトウェアは戦いに必要な武器だが、最終的に勝敗を決めるのはサービスが提供する情報やコンテンツだ、というところが面白いところでもあり、難しいところでもある。

　UIE Japanの正式な活動が３月１日にスタートした。まずは、正社員三人、インターン二人が３月１日付けで参加。今の仕事の引継ぎが終わりしだい入社してもらえる人が三人。外部からコンサルタントなどの形で参加していただける人も含めると１０人超の会社が、去年の１１月末にこのブログで人材募集を始めてから（参照）わずか３ヶ月でここまで出来できてしまったことになる。これもすべて関係者の寛大なる理解と甚大なる努力のおかげである（感謝、感謝）。しかし、何と言っても、ネットの力を効率良く利用すると、これだけのことがこんなスピードで出来てしまうものかと、われながら関心してしまう。

　木曜日と金曜日は、主に UIE Japan で作るサービスの企画に関するブレスト。面白そうなアイデアがホワイトボード一杯にかかれる。どのサービスもとても楽しそうだ。しかし、全部はとうていできないので、投票でまず４つ～５つに絞り込むことにした。

　各人に１０点づつのポイントを与え、自分が作りたい、もしくは会社として作るべきと思うサービスにそのポイントを振り分けて投票するというシステム。ただし、「作りたい人に作ってもらいたい」という意味も含めて、投票で選ばれたプロジェクトに関しては、一番多く投票した人が仮のオーナーとして選ばれる、とう条件を付けた。つまり、自分でどうしてもやりたい、というプロジェクトがあれば１０点全てをそれに投じれば良いのである。

　そんなプロセスを経て選ばれた５つのプロジェクト。どれもとても魅力的なサービスだ。それぞれのオーナーが次の週の水曜日までに概略プランを作ってくることにして、とりあえず解散。社員全員がやる気にあふれている上に、具体的なプロジェクトの話になると目がキラキラしてくるのがすばらしい。会社設立の第一週目としてはなかなかの滑り出しである。

　ちなみに、UIEvolution本社を作る過程では失敗したことも学んだことも沢山あるが、会社の成功の鍵を握るのが社員のモチベーションだ、ということだけは身にしみて理解したつもりだ。しかし、モチベーションというものはそれぞれの人の内部から湧き上がってくるものでなければならず、後付けではなかなか難しい。「朝礼」とか「運動会」があまり役に立たないのはそれが原因だ。結局のところ、会社が作りたいと考えているようなものを作りたいと思っている人たちを集めて、彼らに思い存分作りたいものを作ってもらうのが一番良いのではないかと考えている私である。

　私の大好きなラーメン屋に例えれば、「本当はフランス料理が作りたい」という料理人よりは、「俺はラーメンを作るために生まれてきた」と自らを語るラーメン職人を雇った方がモチベーションは上げやすい、というごく単純な話である。もちろん、一度雇ってしまった人が中華丼を作りたいと言い出したのであればそれを作ってもらうのもありである。その中華丼が売りつ続ける価値のある商品かどうかは、シェフやオーナーが決めるのではなく、客に決めてもらえば良いのである（もちろん、中途半端な商品を提供して客を怒らせてはいけないので、そこが難しいが…）。

　そんなことを考えながら集めたラーメン職人達の集まるUIE Japan。どんなラーメン屋ができるのか、どんなおいしいラーメンを食べさせてくれるのか、それとも誰もラーメン屋に期待していないような料理を出して驚かしてくれるのか、これからがお楽しみだ。