2009年12月

お次は同じところからminiblog。今までとは全く逆の白いやつ

http://forthelose.org/themes/miniblog/miniblog-a-premium-wordpress-theme/

某所の短編小説の解説を書こうとか、そう言う話もありつつでもオランダの冬にやられてだるいので、気晴らしにテーマを変えてみた。
当面いろいろ変えてみて、気が向いたのにする予定。

今回のはJenxedというやつ。以下からダウンロード可能。

http://forthelose.org/ftl-themes

能力がないから日本が負けている訳じゃない。現実には日本はあふれんばかりの文化と才能を持った場所だ。

これはオランダに住んでいて、ヨーロッパを旅していて痛切に思う。東京・大阪という世界で文字通り１，２を争う大都市圏を擁し、勤勉な国民性と並外れたサービスを提供している。その上で日本食やマンガアニメカラオケといった、抜群のコンテンツを持った国である。覇権国家アメリカとてここまで魅力的な美辞麗句は持ち合わせていない。しかも、その覇権国家に一度は経済で勝ったというのだから並大抵ではない。落ちぶれたとはいえ、日本はその能力をまだかなり保っているのは、外から見れば非常によく分かる。外から見てよく分からないのは、一生懸命日本を終わらせたい人がいる、ということだ。民主党の話（だけ）ではない。日本はもう駄目だ！と叫んでいる人たちだ。彼らが叫び続ければ、自信を失った日本は本当に終わるだろう。そうさせないためにも、日本の中から良いものを選別して残し、改めて勝てる形に再編成しなければならない。そこでelm200さんのこの記事。

日本にシリコンバレーを作る方法
一方アメリカでは Google 一社で２万人の従業員がいる

といきなり素っ頓狂なところの引用から始めるが、Googleの有名な20%ルールを考えると、20000人の社員は、最低でも40*0.2で週８時間の自由なプロジェクト時間を持っていることになる。年間では20000*8*52=832万人・時間＝104万人日＝52000人月になる。5万人月とは圧倒的なR&D力である。L.starのいる会社は従業員1000人規模なので、どうあがいてもこれだけの工数は用意できない。人月単価100万円として520億円相当のR&D人件費、それをほぼわかりやすい投資無しで生み出していると言って良い。しかもこれはたかがGoogleの話（されどGoogleだが）であって、アメリカのソフトウェア業界全体の話ではない。

話を戻すとして、elm200さんは以下の点を問題としてあげている。これはL.starも同意する。
原因は、広い意味での社会資本にある。社会資本とは、簡単にいえば、面白いアイディアを持った個人を支援して、事業化し、収益を生んでいく環境である。

しかし、こういう社会資本が今までどこかに存在したはずなのである。でなければ日本が勝者になったはずはない。正解はもちろん、大企業の中、である。膨大なR&Dコストは従業員のやる気と情熱によって生み出され、それを世界に売って回収していくことで、日本は金持ちになった。翻ってIT業界はどうだろう。日本におけるソフトウェア業界の勃興は割と遅めで、老舗ですら60年代後半、ということもある。そして、大半が日本国内で閉じたビジネスをしていた。つまり、彼らは常に日本の大企業という上客と商売をしてきたことになる。はなからおいしい仕事を手にすることができたわけだ。そのツケは今やってきている。おいしい仕事をくれる大企業や官公庁無しに、SI企業が生き延びることはできない。必死にコスト圧縮により生き延びようとしているが、結局ソフトウェア業界の縮小を招くだけだろう。その縮小が続けば、今の大企業のようなビジネスモデルの大半は死滅する。
誰かが、こうしたクリエーティブなエンジニアたちを退屈な仕事から解放して、彼らにしかできない仕事に専念させてやらなければならない。それができるのは、優秀な起業家たちだけだ。冒険的な起業のほとんどは失敗してしまう。それでも生き残った一部の事業が大きな利益と雇用をもたらす。活発な起業を促す上で、日本に一番欠けているのは、資本市場的なダイナミズムだ。たとえば、誰かがスタートアップを始めたとしよう。シリコンバレーの人間だったら、まず出口(exit)から考える。株式公開するのか。大企業に売却するのか。3年後？5年後？そうやって、会社を売却することで創業者は大きな現金を得て、再び新しい起業が可能になる。

シリコンバレーでは、そうやってエンジニアが大金を手にして再び新しい技術ベンチャーを作るため、非技術者が始めるのに比べて、成功確率は大きくなる。要するに、自腹である程度の規模の会社を始められる程度に、日本のエンジニアが金持ちにならなければならないのだ。極論を言えば、日本のトップエンジニア 1000人がそれぞれ10億円ずつ持っているようなイメージである。

私は、こういう革新的な起業文化をつくりたい。

L.starは、これを「リスクをどれだけ取ってチャレンジできるか」と言い換えるとよりシンプルじゃないかと思う。結局、だれかがリスクを取ることができさえすれば、この種の収益化はどんどん進行していくだろうと思う。しかし、日本のソフトウェア業界というか、日本自体が可能な限りリスクを取らない方向へものすごい勢いで動いている。ちょっとでも瑕疵があればすごい勢いで批判の対象になる、そんななかで、L.starは本当はチャレンジがしたくて仕方がないんだが、それはL.starはどうしようもない馬鹿だからである。常識的な人ならしない。昔「会社はリスクを取らずにつまらないことばかりしている」と愚痴ったら、そこにいたとある社長に「馬鹿だなぁ、会社とはいかにリスクを取らないかだ」と言われたのを覚えている。それが日本の実態なのである。

だから、金勘定のできる投資家「だけ」がいても、今の日本では駄目だろう。結局金とはリスク要因の一つに過ぎないため、他のものにつぶされる。大企業を好む風土しかり、新卒orDieの就職制度しかり、技術力よりコミュニケーション力ばかり求める会社しかり。そう言うのを乗り越えてエンジニアにチャレンジさせられる投資家がいて、始めて日本はシリコンバレーに匹敵する武器を手に入れられるのではないか。たぶん、Y Combinatorのような方向性を持った投資会社なんだろうな。まあL.starはポールグレアムが好きすぎるので、そういう影響を多大に受けていることは認める、としてもだ。

IPAの未踏ソフトウェア事業は、そう言う意味で方向性だけは悪くなかったと思う。ただし、あれは一定の成果を上げたものの、結局たいしたものをそれほど生み出したりはしなかった。GoogleやTwitterどころが、時価数十億円になる会社の一社も生み出さなかった。なぜだろう。そもそもそういうレベルを求めていなかったからだろうか。IPAの体質だろうか。ばらまく金がけちくさかったのだろうか。投資家とチャレンジャーではなく、教授と研究員の関係になってしまったということなのだろうか。

これを引用しているKoshianの以下のエントリも。

エンジニアが金持ちになって次の世代を作る未来
elm200さんが目指す「革新的な起業文化」を日本に芽吹かせるには、こういう非エンジニアにサービスを作らせてちゃダメなんだよ。それはカルチャーなんだから。エンジニアのカルチャーで作らないと。

この文章など、エンジニアの独りよがりに見えなくもない。そもそもエンジニアのカルチャーってなんなんだよ、と。しかし、活気のある新技術大好きエンジニアは往々にしてリスクテイカーであることを考えれば、ここも得心がいくであろう。内にこもるような官僚主義ではなく、もっと外に開いてリスクを取るようなカルチャーこそ、革新的な企業文化の中軸に据えられるべきものである。

リスクを取らない、と言う選択肢はもっとも安直だし、個人の選択として責められるものではない。しかし、全体としてリスクを取らない社会はそのまま沈み行くのみである。沈まないためにも、再び挑戦できる社会に回帰することが求められている、

オランダに住んでいるからこそ思う、外国人参政権論を考えてみた


もう民主党に売国されちゃいなよ、日本人！


でうんざりするほど書く羽目になったコメント（現在合計120弱で、半分近くがL.star）も落ち着いた。恐ろしいことにこれを読む人がL.star以外にもいると言うことだ。かの伝説のotsuneがこれまた5回もコメント欄からreblogしている。抜き方からしてどうやら全部読んだらしい。他にもトラックバックがなかったが「これコメント含めて全部理解すれば完璧！」みたいなことを言っているエントリもあった。世の中には馬鹿（ほめ言葉）もいるものだ。しかしコメントを書くことによってそれなりの知見を深めることができたと思うが、一方でこんな無駄もなかったと思っている。何が無駄かというと、このコメント欄でのやりとりを通じて誰かと何らかの同意に達することができたかというと、恐ろしく怪しいからだ。

L.starは多くの人たち（ほとんど民主党案反対派）の考えに不信感を抱いていたが、それを払拭するようなデータは結局見つからなかった。向こうは向こうで、コメントするのをやめたのは論破されたからではなく、揚げ足取られてむかついたから、とかそう言うレベルだろう。相手のほうが正しかったから、とはきっと思っていまい。そこにあったのは憎悪のぶつけ合い、足の引っ張り合いである。そこには日本再生の文脈はない。それどころが、残念な位置にいる人をいかに救済するか、という文脈もない。自分の位置に固執するための罵り合いに、いったい何の意味があるのか（いやおまえも参加したんだろう）こんなことをしていても、日本は何一つ良くならない。

残念じゃない日本ってどんなのか、考えたことがありますか？ -　みんな、自分に自信を持とう

こんなエントリも書いたが、我々の社会に必要なのは救済と再生である、という考えは未だにL.starの中心にある。そして、再生の言葉については心配していない。日本をどう変えるべきか、と言う議論は、今のWebでも頻繁になされている。愚にもつかないものからすごいものまでいろいろある。日本が再生できる、と言うのについては安心できる。来るべき再生の時には、しかるべき能力の日本人が現れ、新しい日本を作り上げるだろう。

問題は、しかし相変わらず救済の言葉が無いことなのだ。それが先になくして、再生の道筋をたどることができない。我々に必要なのは、子犬のようにキャンキャン叫ぶことをやめて実質的な再生に目を向けなけること、そんなのもはや誰でも心の奥底では知っている。しかしそれをやめる前に、それをやり続けていた自分と向き合わなければならない。例えば社畜を例に取ろう。社畜として生きることがいかにひどいことか知らないサラリーマンはめったにいない。しかし、社畜を否定することはすなわち自分の過去の全面否定である、と言う現実の前には、社畜以外の生活がどれほど素晴らしくても無意味である。それを変えるためには強い行動力が必要だし、それを支える言葉がいる。

例えば「騙された」と気づく人がいる。まっすぐ進んで行き詰まる人がいる。無理矢理外に放り出されて、後で気づく人がいる。これらのひとは社畜であることから逃げ出す力になるだろう。海外、というのもいいものである。自分が今まで信じてきた、あるいは信じざるを得なかったものを疑うきっかけになるからだ。それで人間は成長できるのだが、しかしそれをうまく導くことはできないのだろうかと思う。もちろん真っ正面から立ち向かっても駄目だ。多分寓話的なところから、回りくどくやらないといけない。

20世紀の日本には、それをできた人いた。昭和天皇の玉音放送だ。あの言葉をもって、第二次大戦的価値観はすべて終わりを告げた。逆に三島由紀夫は失敗したと言ってもいいかもしれない。彼の言葉は印象的であったが、しかし日本は止まらなかった。再生の言葉を語るブロガーがいるなら、その対となる救済の言葉を語る人も要る、それがL.starの思いである。そして、今回は見事に失敗したと認めざるを得ない出来だった。彼らに対して結局どんな言葉をかけることができたのだろうか。いやまあ、ブロガーごときに語れるものであれば、苦労はしないんだろうけど。

しかし、Wordpress2年目をやっていくにあたり「救済の言葉とは何か」というのは、一つのテーマにしたい、と考えている。

ベンチャー社長で技術者で: オブジェクト指向言語で処理したら保守性が悪い！.

というのを目にした。要するに「OO言語＋RDBな組み合わせ」において、O\Rマッピングに頼らずにちゃんとSQLとストアドを書いた方がいい、と言うことである。

L.staｒは元々Java屋でそれからSQLに移ったので、未だに自分が両方をバックグラウンドに持つ人間だと思っている。O/Rマッピングのイ ンピーダンスミスマッチを解決する簡単な方法が実は無い、と言うぐらいには両方を理解している。だからこそ言いたいが、この文章、特定のDBが中央に鎮座していて、それがすべての中心になるような業務システムにおいては完全に正しい。ただし、元々そう言うシステムを念頭に置いて書かれた文章であるので、その点はちゃんと考えるべきだ。O/Rマッピングに頼り切って、SQLをきっちり書かない、ということをすると性能が出ないというのはその通りである。

しかし、その主張に熱心になる余り、若干言い過ぎだろう、と言う部分も多々ある。

SQL-RDBMSというのは実に多様な側面を持った、というか明らかに持ちすぎたソフトウェアである。それらをちゃんと分離せずに論ずるのは危険だ。

要点がばらついているのでどこを引用すればいいか迷ったが、とりあえずここを。
オブジェクト指向言語で処理していればロジックが再利用し易いとか言いますけれど、ちゃんと設計していればストアドプロシージャの方がもっと再利 用し易い。例えば、他の言語でバッチ処理を書いても、エクセルマクロでアドホックな帳票を作るにしても、データがRDBMSにある限りロジックの再利用が 可能になります。

企業のシステムにとって、プログラムよりデータ（構造）の方が長生きなのですから、アクセス方法はRDBMSに入っている方が将来性がある。

「データ構造」のほうがプログラムより長生きだ、ということは多くのケースで間違いないのはその通りだ。が、果たしてストアドプロシージャは「データ構造」だろうか。いやもちろんプログラムである。だからここには「データストアとしてのSQL」と「プログラミングプラットフォームとしてのSQL」という2つの側面が登場する。データストアとしてのSQL、というかリレーショナルモデルを格納するシステムは安定している。実際に正しいテーブル構造を変えなければいけない、ということはまずない。しかし、これがプログラミングプラットフォームとしてはいささか怪しい。

SQLをごりごり書く、というのは意外にもアセンブラでのプログラミングに似ている部分があると言うことだ。SQLは前にも指摘したが、基本的に論理構造と物理構造を分離できない言語であるのに、物理構造を理解したチューニングが必須とされる。チューニング結果としてはき出されるSQLは、あらゆるものに依存しまくりの美しくないものである。これを果たして美しいというか。再利用性が高いというか。賭けてもいいが、自分が書いて自信があったものですら、1年後に見たら吐き気を催すような代物に化ける。他のプロジェクトに再利用できるか、というのはデータ特性とかにも依存してしまうし、また他のSQLデータベースに持って行けるかというと非常に怪しい。

そこで、DBを刷新しよう、と言うことになった時を考えて欲しい。ストアドのロジックは使える部分も多いが、互換性を考えるとある程度は捨てる羽目になる。チューニングはやり直しである。ましてや例えばOracleからPostgreSQLにダウンサイジングする案件などの場合、完全移植である。確かにデータ構造は長生きである。しかし、データ構造を格納するRDBMSとそのプログラムは、実際には長生きではない。

また、再利用性は、単語が違う意味に化けている。通常OO言語における再利用性とは類似のプロジェクト同一言語で議論されるものである。それに対して、ここでいうExcel等でも再利用できるという話は、他のインターフェースから利用可能だという話になる。これは再利用性ではなく、相互運用性の話である。そして、相互運用性の話をするなら、ここでOO言語が対抗して出してくるのはSOAとなる。SOAで使われる標準化されたXMLベースのプロトコルは、現実として標準実装すらないSQLより遙かに相互運用性が高いといえないだろうか。

このような欠点は、1つのDBが中核にあって、OO言語を周辺のUIとしてのみ利用できるような場合には全く無視できるものである。いわゆる企業の内部システムか、中規模のWebサイトだ。９０年代後半から2000年代前半にかけての中規模システムというのはだいたいこれでまかなえるレベルであり、その当時の経験から出た、といえよう。

では、逆に欠点が強く出るところはなんだろう。３つ考えられる。

最初に考えられるのは、超簡単なSQLしか使う必要のない、O/Rマッピングで十分な性能をあげられる場合だ。これは複雑なクエリを要求されるのことの多い業務システムでは滅多にないが、一方で単純な構成で性能を要求されるWebサイトのようなケースではままある。そもそも、昨今ではこれらの場合にRDBMSすら使わずKVSを多用する事が多いが、これらはその種のストアド機構など持たないため、自動的にたぶんOO言語で書くことになる。

次のは、複数種類のデータベースに対応しないといけないパッケージ商品だ。こういう商品でSQLをインターフェースにすると、ストアドでがちがちに固めた場合はともかく、通常のSQL文には過度のチューニングをさせられないことになる。ストアドにすると、言語側で記述すればそのまま対応できるロジック（再利用性は高い）が、今度は各DBごとにばらばらになり、個別実装にならざるを得なくなる。スピードが売りなら、それをするのもいいだろう。しかしビジネスロジックを例えばPostgreSQL,MSSQL,Oracleの3種類全部書くのは、果たして割に合うか。下手をするとバージョンごと、と言うことにもなりかねない。

最後はDBが1台で済まないケースだ。例えば1台で間に合わない性能を出さないといけないケースを考えよう。最近だとまず、memcachedを前段キャッシュに置くだろう。まずこれを置く場所に困る。SQLストアドの中に置けばいいだろうし、そう言うバインディングもある。しかし、O/Rマッピングのようなシンプルなクエリの場合、ちょうどSQLデータベースとの中間がきりのいい場所になる。このキャッシュ可能な場所の切り出しでは、全部のデータを一気に扱いたいSQLに部が悪い。

複数台無いとどうしようもない、いわゆる本当の大規模システムになった場合、SQL実装は分が悪い。例えば4ノードに拡大することを考えた場合、商用DBはどれも高価すぎる。オープンソースのものはいくつかあるが、多くは開発進行中であり、通常のSQLデータベースにはない制限、異なる性能特性に対応することを余儀なくされたりする。更新および検索の負荷分散機能も、SQLフロントエンドとして実装するのは大変である。このようなケースで相互運用性を求めるなら、中間層のサーバをもうけてXML-RPCベースなどのほうがまだいいだろう。

つらつらと書いてしまったが、RDBMSとそのフロントエンドでどう割り振るか、というのはシステムの根幹をなす部分であり、それだけに難しい。特に現在のデータベースはトランザクション処理系、データストア、プログラミング環境など、あらゆるシステムを網羅しているしろもので、それにいったいどれだけ依存するか、というのは一種の賭である。その賭を嫌ってSQLの機能を全く使わない、というむちゃくちゃな事をしているケースもたくさん見てきた。一方で、ストアド漬けになって、ベンダーロックインの状況から抜け出せない、あるいはバージョンアップの時に巨大プロジェクトになってしまって泣きを見ているケースも知っている（ただし、そう言うプロジェクトでは自分たちがベンダーロックインしていることが問題だと認識はしていないが）。

O/Rのインピーダンスミスマッチは古来からあちこちで摩擦を起こしている問題であり、我々はそう言う状況でもがき続けなければいけないのだ。そういう中で、確かに一般的ではあるが、あくまで一例にしかすぎないものをもって「これはこうすべきだ」と結論づけるのは、すくなくともL.starは拒否したい。ただ、もし強いて原則論を持ち出すとするなら、曖昧なものになってしまうが、以下のものをあげよう。

「データは転送するまでに可能な限り絞り込め」
異なるメモリ空間/マシン間でのデータ転送は非常にコストがかかる行為であり、できる限り避けた方が得である。その点、ある程度SELECT文の機能を活用する必要はあるだろう。

「SQLの特性に着目せよ」
OLAPとOLTPの話の例を出したが、SQLには特性の異なるものが多数含まれている。これらを一緒くたに議論をするとおかしな事になりかねない。

「アプリケーションが主なのか、DBが主なのか」
SQLはあくまでシステムの構成要素の一つであり、常に中心というわけではない。実際に中心はどれになるか、と言うのはちゃんと明確にしておく必要がある。

↑このページのトップヘ