佐藤一郎: Web日記 (2009年)

Diary

Ichiro Satoh

もともとは研究用ソフトウェアの開発履歴に関するページだったのですが、開発関連よりも雑談の方が多くなったので、2001年分から別のページを用意することにしました。リンクは勝手にしてください（でもリンクしたい人なんているのでしょうか）。
最新版
 一覧

2009年9月30日

わけあって電子広告の国際会議に参加・講演。商業ベースのシステムでほとんど広告としかおもえない論文発表と、いかにも学生さんが実装してみましたという論文発表のどちらかで閉口気味。当方は状況依存ベースの広告システムの発表したのですが、他の発表と比べて派手さのない発表となりました。聴衆は地元、フィンランドの方が多いのですが、フィンランドの方はあまり質問をしないのですが、発表後にスライドをほしいと7,8人ほどからいわれたので、好評だったのでしょう。フィンランドの方は直接話していても、あまり相槌も打たないし、感情を顔や声で表現しない。なので一対多の講演では終わってみないと好評だったのか否かがわからないのです。まぁ今回は一安心でしたが。

他の発表ですが、日本で話題になっている世界カメラのような研究が多かったですね。ただ、GPS付きの携帯電話とカメラによる情報をFacebookとかTwitterなどの関連づけようという話が多い。流行なのでしょうが、学術研究なのですから、そんな一過性のネタではなく、10年先に残るような研究をした方がいいように思ったり。それとWeb 2.0的な発想から脱却できない研究が多いですね。

ちなみに世界カメラのような空間にタグ付けするとか、空間にポストイットを貼って、それをAR的な手法でアクセスするというのは学術研究では古くからあり、実証実験はいくつかあったのですが、どれも実証実験以上に進まなかった。その理由はタグ付けされるような空間は一部に限定されて、逆にそうした空間にはタグがたくさんつきすぎて必要な情報を見つけられないのです。また、空間にタグづけする動機は人によって様々。例えばWebページであれば少なくても同じ情報を見ているのでタグの種別は収斂するのですが、空間の場合、人によってその空間にいる目的が違いすぎて、タグから必要な情報にたどるのが難しいのです。だから観光などコンテキストを限定しないとタグが発散してしまうことになります。不特定ユーザでタグをつけさせた場合、はじめはいいのですが、時間がたつともにタグが発散しますし、間違った情報が増えていきます。結局、最後はフィルタリングとノイズ除去が研究の中心になります。ちなみに世界カメラはiPhone限定なのが幸いする。つまりiPhoneのユーザというのは良くも悪くも独特なのでユーザ層を限定されることになり、当面はうまくいくのではないでしょうか。ただ、ユーザ数を広げると発散とノイズ化が進んでいきますがね。

2009年9月29日

ヘルシンキは気温は５℃と寒いです。午前中はノキアで打ち合わせ、それからタンペレに移動です。実はタンペレは初めて。フィンランド出張で困るのは食べるところがすくない。というのはフィンランド人は基本的に倹約指向なので外食はしない。北欧の他の国と違って王制ではなかったために食文化は発達しなかったこともありますが、フィンランド料理というものはない(トナカイ料理はラップランド料理であってフィンランド人は食べない)。それと食事のお味にはあまり拘らないようで、夏場はヨーグルト、冬場はスープで済ます人が多いように思います。それと昼休みも30分が一般的だそうで、ファーストフード的な食事が中心。もちろんヘルシンキだとそれなりにレストランがありますが、タンペレはレストランが少ない街ですね。

ところでフィンランド人との打ち合わせはすぐに本題にはいって、さらに脱線しない。ただ、気をつけないといけないのは質問にダイレクトに答えるということでしょうか。実は今日、タンペレのホテルにチェックインするときに「ホテルの近くに駅まで行くバスがありますか？」と聞いたのですが、日本を含めて多くの国だったらバス停の場所を教えてくれますが、ホテルの方に一言、「はい」と答えられてしまいました。フィンランド人には知りたいことをストレートに質問しないといけません。

ところで気温が5℃と書きましたが、フィンランドは外気温計がたくさんあるお国柄。一説によると一家に一個はあって、屋内にいながらにして外の温度がわかるとか。ちなみに昨日乗った空港と市内を結ぶバスも外気温計がついて車内で外気温を表示していました。

2009年9月28日

ヘルシンキに移動です。ということでフィンランドのことを少々。フィランドは国別生産性ランキングで常に上位にいますが、週休二日制というか、週休二日が義務。また勤務時間は8時から16時または9時から17時で、一日あたり7時間半(昼休みは30分が普通)。残業手当という概念がないので、残業はしない。そのうえ夏休みは一ヶ月ぐらいとるし、冬や秋にも一週間ぐらい休みます。それでいて生産性が高いのですが不思議なのですがね。なお、フィンランドはボーナスという概念はないようですね。日本は長期休暇はないに等しいのですが、失業率が上がるようならば従業員にボーナスか長期休暇のどちかを選べるようにしてみるといいかも。

また、当方の知る限りフィンランド人はリタイアするのが早い。これは福祉が発達しているので、働くよりもリタイヤした方がいいということが背景にあります。なお、ハイテク企業はこれが顕著で、例えばノキアだと50代以上のフィンランド人は少ない。というのはその年齢以上の従業員はストックオプション相当のボーナスをもらって、早期退職しているからだそうです。

ちなみにフィンランドの失業率は6～7%と欧州ではやや低めの水準ですが、従業員の解雇は他の欧州よりも簡単なようですね。フィンランドには新卒採用という枠はありません。このため新卒は就職活動がたいへんなようです。ちなみに日本の失業率の低さというは企業に新卒枠があるからだそうで、多くの国では経験のない新卒の学生さんの失業率は高いですからね。逆に言えば日本も長期雇用が崩れると新卒枠はなくなって、失業率があがることを意味します。

フィンランドは教育熱心といいますが、この雇用情勢が反映しているようです。フィンランドでは専門家を重視するお国柄ですが、その条件が専門教育を受けていること。逆に専門教育をうけていないと就職口がないことが背景にあるそうです。例えば俳優を目指すにしても、大学の演劇学科を卒業していないと仕事がない。それからフィンランドの小中学教育が充実しているといいますが、現地の方にいわせると、フィンランドは植民地をもっていなかったこと(歴史的にフィンランドは植民地にされていた立場ですからね)、フィンランド語が難しすぎることから、移民が少ない。その移民の子供が少ないので、結果的に下位レベルの子供が少ないからだそうです。実はこの状況は日本も同じなのですが、学力にも反映しているかは別問題。ただ、状況が似ているだけにフィンランド教育システムを参考にするのは理にかなっていますね。ただ、フィンランドの場合、教師は修士卒以上など教員の質は相当高いというのと、何事も自己責任というお国柄なので、学生さんが自主的に勉強するのでしょうね。

2009年9月27日

徹夜でお仕事。朝までに終わればいいのですがね。実は明日から海外出張なのですが、海外出張前は徹夜仕事というのは学生時代から同じで、進歩がないですね。たまにゆっくり休んでから海外出張をしてみたいですね。あり得ないとおもいますがね。

2009年9月26日

休日出勤になってしまいました。ところでIntelがIDFでAtomのSoCの詳細を発表したようですね(詳しくは例えばこの記事)。AtomのSoCは構想だけが発表された状態だったのですが、実体は特定用途向けの製品なので、厳密にはSoCではないようですが。ただ、今後はAtomを組み込んだスマートフォーン用チップ、省電力サーバ用チップ、家電用チップ、車載用チップなどいろいろ出てくるのでしょう。個人的に注目しているのはIntelが最初にどの分野を狙ってくるかだったりします。Intelのことですから、マイナーマーケットではなく、メジャーマーケットを狙ってきそう。

2009年9月25日

午前中は秋葉原で打ち合わせ、午後はオフィスにもどって原稿書き。ところで人から教えてもらったのですが、MITの電気＆コンピュータサイエンス学科のプログラミング授業というとSchemeということになっていましたが、いまはPythonをつかっているそうですね。Pythonは可読性が高いので、正しくはプログラムの整形が書き手に依存しにくいので、プログラミング教育では学生さんのプログラムを採点したり、手直ししたりするのは楽そうですね。Pythonといえば以前、Googleの方に、GoogleはなぜPython好きなのか、を聞いたことがあるのですが、その方はGoogle社内ではプログラミング言語の指定はないこと、そしてC++やJavaの方が多く、これらの言語は社内ライブラリも充実している。Pythonは簡易実装用途が中心という前置きだが使われている。Googleはコードレビューを重視しているので、社内開発者は他の人にコードレビューをしてもらうために可読性の高い言語を使うことが多い。このためPerl系の言語は書きやすいが、可読性に低く、コードレビューに向かないと返事をされていました。まぁ結構前の話なので現在も当てはまるかはわかりませんが。

2009年9月24日

ちょっと前ですが、経産省のJ-SaaSに関する相談を受けたのですが、いろいろ課題があるようですが、怖くてJ-SaaSのユーザ数は書けませんが(J-SaaSも電子政府の見直した対象にはいるのでしょうか)、書ける範囲で少々。

課題の１つ目はミスマッチ。J-SaaSで提供されているサービスは会計処理や給与処理が多いのですが、ユーザ企業は会計処理や給与処理は外部に出したくない。つまりユーザ企業の要求とサービスがあっていない。これはサービス内容の見直しが進んでいますが、ユーザ企業は予想以上に保守的だったということですね。

２つ目は提供されているサービスの機能不足。提供されているサービスは業務パッケージソフトウェアをもとにしているものが多いのですが、J-SaaS版は機能を削っていることがおおく、ユーザ企業が欲しい機能がない。パッケージソフトウェアが売れなくなっては困るということでしょうが、SaaSがパッケージソフトウェアのお試し版化する事態だけは避けて欲しいです。本来はパッケージソフトウェアがSaaSのお試し版になるべきです。

３つ目はカスタマイズ範囲が狭い。SaaS系のサービスをそのまま使えることは少なく、ユーザ企業はその業務などに合わせてサービスをカスタマイズすることになるのですが、そのカスタマイズできる範囲が少ないので、この企業の業務に合わない。こうしたカスタマイズに関してはSalesforce.comはうまいですよね。それと顧客はカスタマイズをするとそのサービスを使い続けることになるので、ユーザ囲い込みとしてカスタマイズ機能は重要です。さらにカスタマイズを生業にするサードパーティがあらわれるぐらいでないといけないのかもしれません。

４つ目はどのサービスを選れべばいいのかわからない。SaaS系のサービスは結局、使ってみないと本当に使えるかどうかがわからない。ライセンス料は休めに設定しているとはいえ、お試しサービスに企業が業務を任せられるわけでもない。ASPはもととなったアプリケーションがあることも多かったし、サービスの数も少なかったのですが、クラウドコンピューティング上のサービスは増えるので、結局、ユーザ企業は求めているサービスに、どのサービスなのかが見つけられないという事態になりそう。おそらく、ユーザにあったサービスを見つけるソムリエのようなサービスがでてくるでしょうし、個々のサービスもそれ自身のメタ記述が必要になりそう。

どの課題もSaaSを含むクラウドコンピューティングにおいて本質かつ深刻な課題です。クラウドコンピューティングで夢を語るのはいいのですが、J-SaaSの教訓は他人事にしないで活かして欲しいところです。なんかJ-SaaSは終わったみたいな書き方になってしまいまいしたが、まだ続くそうです。

2009年9月23日

今日も休日出勤。結局、連休は全日出勤となりました。国研は授業もなく楽そうに思われているそうですが(大学院があるので授業はあります。まぁコマ数は少ないですが)、研究成果だけで評価される世界なので、相当なワーカホリックになりきらないと生きていけません。

今日、正しくは米国太平洋時間の昨日ですが、GoogleのApp Engineはデータ管理システムをMegastoreに移行するためにサービスが一時止まるようですね。MegastoreはBigTable上のライブラリというか、トランザクションマネジャーのようなものなので、BigTableの制限がなくなるわけではないのですが、更新管理絡みのプログラミングは楽になるかもね。昨年、発表されたMegastore通りならばEntity Group内のデータに関してはACID特性とJoinもサポートされることになります。移行に関してはApp Engineの公式ブログの記事が詳しいのですが、それにしてもこの記事はいくつか気になることが書かれていますね。

そのひとつはPaxosの利用は断念したこと。Google I/OのApp Engine関連の講演でPaxosを利用するといっていたのですが、遅延が大きすぎて使わないそうです。ただ、これは不思議かも。実際に実装してみたら予想以上に遅かったという可能性は否定できませんが、分散アルゴリズムに多少知識がある方ならば、Paxosを含む３相トランザクションプロトコルは遅いことは常識。だから遅延が大きいことは当初から予想されたことだと思います(個人的には特許の問題のような気がします)。それにしても３相トランザクションプロトコルは学術研究ではたくさんの提案があったのですが、唯一といってもいい実用化事例がPaxosなのですよね。やっぱり３相トランザクションプロトコルは理論的にはよくても、実用は難しいのでしょうね。

この記事からGoogleはデータセンター間のMultihomingを重視していることもわかりますね。ただ、データセンター間、それも海を越えたMultihomingは複雑ですし、運用はたいへんになるのですが、Googleとしてはその複雑性を考えてもデータセンターの切り替えをしたいのでしょうね。ところでGoogleは以前、Datacenter as a ComputerまたはWarehouse-scale Computingというコンセプトでは巨大データセンターをひとつのコンピュータとして扱うことを狙っていましたが、いまは世界に散らばった巨大データセンターをひとつのコンピュータとして扱えるようにすることを目指しているようですね。まさに(Cloud Computingではなくて)Cloud Computerですよね。時代の流れは速いです。もっともこの記事からもわかるようにデータセンターの切り替えはGoogleにとっても一仕事のようですが。

それにしても日本国内には巨大データセンターを構築したい方が多いようですが、先行するGoogleは巨大データセンターの構築という段階の先、つまり、巨大データセンターを連携することで地球規模の超巨大コンピュータの構築という段階を入っています。巨大データセンターの構築が一周目だとしたら、Googleは二周目にはいっていることになりますが、日本は巨大データセンターの構築する計画もない。つまり、このレースにスタートすらしていない状況。いまからでも追いつけると思うのか、別のレースを始めた方がいいと思うかは人それぞれですが。ただ、仮にGoogleに追いつこうというのなら、巨大データセンターの構築だけではだめで、巨大データセンター間連携まで視野に入れないといけません。ただ、複数の巨大データセンターの連携では各巨大データセンターは地域的に離れている方がいいわけで、世界の各所に巨大データセンターを構築して、それらを連携することが求められます。いいかえれば日本国内にだけ巨大データセンターを作ればいいというものではありません。日本国内に巨大データセンターが必要と語られる方は、税金で作ることを念頭においている人が少なからずおられますが、クラウドコンピューティングのインフラは複数の国に設置しないといけない以上、国という枠に縛られる税金でインフラを作るのは難しく、国とらわれなくてもいい企業が作るものなのです。

それにしても、Googleを含むクラウドコンピューティングの先行企業にとっては、これまでのクラウドコンピューティング関連技術の中心だった巨大データセンターの構築は一区切りをついたということなのでしょうね。ここ数ヶ月でデータセンター関係者の退職が目立つそうですが、その背景としてデータセンター技術の成熟は無関係ではないように思います。もちろん、退職と背景には相次いでいる巨大データセンター構築の延期という要因が大きいのでしょうが、何しろ新しいことをやりたい人たちだから。そして、これから数年はGoogleのように巨大データセンター間連携に関する技術が盛り上がるのでしょう。例えばスケールアウト性もこれまでは個々の巨大データセンターの中で実現させようとしていましたが、今後は複数の巨大データセンターの連携によって実現する方向に変わっていくのでしょう。

2009年9月22日

予想通り、今日も休日出勤。国内的には休日でも、海外は休日ではないわけで、海外とのやりとりが多い身としては国内スケジュールで生きていられるわけもない。

省エネ絡みの話題をもうひとつ。2011年からCO2排出制限(キャップ制)が検討されています。欧州の排出量取引制度(EU-ETS)から遅れること6年となりますが(EU-ETSは2005年スタート、EU-ETSによる排出枠(EUA)の取引市場はすでに1超ドル規模)、クラウドコンピューティングが普及する理由も、CO2排出制限になるかもしれませんね。つまり国内に設置したサーバ上の処理を、クラウドコンピューティングインフラに移行することで、企業内で稼働させるサーバを減らすることで、企業自身のCO2排出量を少なくするということ。グリーンITでサーバなどの機器の運用上の省エネ化が進んでいますが、そもそも機器を購入・運用せずに済むならその方がいいわけで、極力、海外のデータセンターに任せるというのもひとつの考え方。

もちろんクラウドコンピューティングインフラのほとんどおかれている米国でもキャップ制は導入されますから、クラウドコンピューティングインフラの提供する企業にもキャップが課せられることになります。仮に消費電力からストレートに排出量を計算した場合は、クラウドコンピューティングインフラ事業者には相当な負担になります。この場合、計算コスト＝電気代になるという予測は崩れて、計算コスト＝電気代＋排出負担となるでしょう。ただ、キャップ制による負担はキャップの算定の仕方しだいの部分があります。仮にセクター的な算定をした場合、巨大データセンターと中小規模のデータセンターではエネルギー効率が違いますから、クラウドコンピューティングインフラ事業者、つまりGoogle、Microsoft、Amazonはエネルギー効率を極限にあげた巨大データセンターを使っていますから、こうしたクラウドコンピューティングインフラ事業者には余裕のあるキャップが課せられることになります。また企業別にベースライン的な算定をした場合、米国は国別排出削減量を2005年を基準年にしようとしていますから、米国内も2005年を基準年にする可能性がありますが、仮に2005年を基準年にすると、Googleのように早い段階で巨大データセンターを構築していたクラウドコンピューティングインフラ事業者にやや不利になりますが、それでもここ2,3年で電力効率が急速に上がっているので、クラウドコンピューティングインフラ事業者へのキャップは緩いものになることが予想されます。いずれにしてもクラウドコンピューティングの将来は技術要件よりも米国におけるキャップの算定の仕方次第で決まることは確かでしょう。

それはともかく前述のように欧州に続いて、日本と米国もキャップ制が導入されると世界規模でCO2排出源の押し付け合いがはじまることが予想されます。国内には、いまだに巨大データセンターを国内に作りたがっている人たちが多いのですが、CO2排出要因になるような施設をわざわざ背負い込むことないです。既存の国内データセンターにあるサーバを含めて、海外に任せてしまいましょう。百歩譲って、国産技術で巨大データセンターを作るにしても、海外において下さい。世界的に見ても巨大データセンターにこれほど執着するのは米国を除くと日本ぐらいなのですが、国内巨大データセンターを欲しがる方々は欧州を含む他の国がなぜ巨大データセンターに執着しないのかという理由を考えたことがあるのでしょうか。またGoogleなどのクラウドコンピューティング事業者がスマートグリッドになぜ関心をもつのかという理由を考えたことがあるのでしょうか。いまさら海外の既存巨大データセンターの後追いをしても仕方ないです。いい加減、米国の後追いと真似から卒業して、クラウドコンピューティングの先にある世界を目指そう、という発想をもってもらいたいです。

2009年9月21日

今日も休日出勤。ただし、3時頃からの出勤となりましたが。さて地球に優しい方ではないのですが(なにしろ飛行機たくさん乗ってますから)、省エネ型クーラーは地球温暖化を促進するという記事。代換フロンとして使っているガスがCO2の2000倍の温室効果があり、そして省エネ型クーラーほど代換フロンガスを大量に使っているために、例えば12年間クーラーを使って廃棄すると、クーラーによる温暖化効果の役半分は代換フロンガスによるものだそうです。世の中はCO2排出量に関心がいっているために、CO2の排出量を減らすこと自体が目的化して、なぜCO2の排出量を減らすのかという本来の目的がおざなりになっているようです。それから記事ではだ代替フロンガスの温室効果はCO2比で2000倍になっていますが、算出の仕方によりますが140～1.1万倍ということになっているかも。

これに限らずCO2排出削減スキームにはおかしなものが多いですよね。某自動車のエコ替えがその代表とされますが、いくら燃費の悪い車を燃費のいい車に買い換えても、エコ替えで下取りになった車が売却されて使われたら、トータルで排出量が減るわけではない。その燃費のいい車の生産には大量のCO2を含む温室効果ガスがでます。特にハイブリッドカーは部品数が多いので生産に関わる排出量が多い。メーカは環境負荷が少ないことを宣伝するならば、運用時の環境負荷だけでなく、生産に関わる環境負荷も示すべきですよね。個人的に現在のグリーンITがいまひとつピンとこないのも同じ理由で、グリーンIT対応機器を作るのにCO2が出ますから、多少、消費電力が多くても古い機材を使い続けた方が、生産を含む製品ライフサイクルにおける排出は減らせる可能性があります。逆にいえばグリーンITが現在のように運用時の省エネ効果だけを狙っていて、生産や廃棄で環境負荷が高いようだと、グリーンITはブームで終わってしまいそう。このままではもって2,3年でしょうか。

2009年9月20日

今日も朝から休日出勤。ただし、昼過ぎからは新国立劇場でVerdiのオペラ「オテロ」を鑑賞。新国立劇場の今シーズンの初日ということで、格安チケットの入手は半分諦めていたのですが、なんとか入手。オテロは久しぶり。たぶん5年前にパリオペラ座で見た以来でしょうか。

新国立劇場のオテロの出来ですが、非常にいい。もう一回見にいってもいいと思ってぐらい。まず主役のOtello役はStephen Gould。初めて聴いた歌手でしたが、役にぴったりという歌手でしたし、声質も感情表現がすごくいい。ヒロインとなるDesdemona役は当初はNorma Fantiniだったのですが、降板となり、その代役のTamar Iveri。ただ、Tamar Iveriはスカラ座でDesdemona役をやるほどのお方だけ会って、相当な実力者でしたし、声質もいいし、感情表現もすごくいいです。実は代役の方がよかったというケースかもね。当然、カーテンコールは拍手喝采でした。そして悪役となるIago役はLucio Gallo。昨年、やはり新国立劇場でDon Giovanniのタイトルロールで聞いたことがある歌手で、Don Giovanni役がすごくよかったという印象があるのですが、今回もよかったです。オテロの出来不出来はIago役の演技力にかかっているといっても過言ではないのですが、Lucio Galloの演技はよかったですね。そして今回のオテロで何よりもよかったのは指揮者のRiccardo Frizza。昨年、VerdiのAidaで一度聴いている指揮者。そのときも好印象でしたが、今回もよかったですね。演奏は東京フィルで国内オーケストラとしては実力派ですが、今回は指揮者のおかげか、欧州のオペラハウスのオーケストラに引けを取らない演奏でしたね。4幕目の出だしがちょっと不安定なところがありましたが、それ以外は国内オケの演奏としても名演にいれもいいのではないでしょうか。さて舞台はベネチア風で、舞台に水を張って、その水をうまくつかっていました(新国立劇場はベネチア風舞台が好きですよね)。今月初めのオペラトークに行かれた方から花火も使うと聞いていましたが、こちらは前半にちょっとだけ使っていました。格安チケットなので席は上の方なのですが、舞台は奥行きがありますし、水を使っているためにステージに傾きがほとんどないので、むしろ高価なチケットでオーケストラストールに座った方々の方が舞台がよくわからなかったかも。演出は全体としては、奥行きのある舞台をいかすようにもう一工夫が欲しいところですが、メインの3人の演出はよいできでした。新国立劇場のオペラはここ数年、4,5本は見ていますが、今日のオテロはベストワンといってもいいですし、欧州の有力オペラ劇場の水準だったと思います。

ただ、残念なこともありました。新国立劇場は経費削減がいろこく出ている感じ。公演前にあらすじや配役の説明冊子を配っていたのですが、それが廃止。簡易版でもいいので配った方がいいと思います。また今シーズンはオテロを除くと新制作オペラはどれも舞台にお金がかからないものばかり。御存知のように新国立劇場はオペラ担当の芸術監督が亡くなられたり、演劇部門の芸術監督の人事でもめた、複数の演出家が新国立劇場との絶縁宣言をしたりといろいろあるのですが、ここ数年は客入りもいいので、お客さんに逃げられないようにしてほしいですね。まぁそれはともかく、個人的にも2009/2010年のオペラシーズンが始まったという感じ。今シーズンは何本のオペラを見ることになるのでしょうか。実は再来週にVerdiものを見る計画があったりします。

2009年9月19日

休日出勤。このところ外出や打合せが多く、休日でもないと落ち着いて仕事ができません。この連休はもしかすると全部出勤になるかも。実は忙しくなってしまっている原因のひとつは現政権がCO2排出量を1990年比25%削減を打ち出したことと関係があります。コンピュータサイエンスの研究者である当方とは関係なさそうなのですが、過去にこんなスキームを考えて、特許出願してしまったし、大きな予算を付けていただいたので本格稼働が始まっているのです。そして情勢の変化というのは恐ろしいもので、8月に入ってからともかく問い合わせが多い。おかげで打合せなどの席でのプレゼンを含めると、週に3～4回プレゼンしている状態。アカデミアの研究者としては企業などから声をかけていただくだけでもありがたいので、時間が許す限り対応させていただいております。さて、この研究ですが、問い合わせをしていたいただいたほとんどの方は事前に研究内容を理解していただいているようです。ただ、公開されている資料では研究意図は表面的なことしか書いていないので、長文になりますが、その背景を含めて説明しておきます。

さて研究内容は「サプライチェーン全体における排出権付き商品の実現」と「簡易かつ小口の排出権取引の実現」の二つの部分からなりますが、キーになるのはサプライチェーン全体の部分だったります。エコポイントは実際のCO2排出量とまったくの無関係という問題に加えて、対消費者向けに対象が限定されています。一方のこの研究は原材料から原材料・中間品の製造、最終製品の製造、流通、小売り、消費者のサプライチェーン全体段階を対象にしています。なぜサプライチェーン全体を対象とすることが重要かというと、今後の日本も導入されるだろう排出許容量(キャップ)と関係があります。ちょっと排出権の知識がある人ならばよくご存知のようにキャップ制度は、全企業にキャップを課す方法(川下型)が理想ですが、事業者数が多いのでマネージメントコストが膨大になるので現実的ではない。そこで電力会社や石油元売り会社だけにキャップを課す方法(川上型)は対象となる事業者数が少ないのでマネージメントコストが小さいですが、各事業者の環境貢献が不明確になるという問題を抱えます。この研究の狙いは、排出権をサプライチェーンの流れにそって川上から川下のに流せるようにすることで、川上型のキャップ制のもとで川上型に近い効果を出すことにあります。

二つ目の経済活動のリンクです。CO2削減策はいろいろ提案されていますが、結局、無理した削減活動は長続きしないし、負担が特定事業者に偏ります。ならば実経済活動に沿って、さらに経済活動規模に応じて、排出削減をさせるのが合理的なわけで、だったら実経済活動の代表であるサプライチェーン全体を対象として、さらに経済活動規模つまり商品の流量に応じてCO2削減負担(商品に添付される排出権)をさせるというものです。その意味では排出権ではなく、環境負荷の情報(例えばLCA)を商品に付けた方がいいという指摘を受けます。もちろん理想論としてはその通りだと思います。ただ、各企業が購入資材やサービスに関わる環境負荷と自社による環境負荷を正確に見積もることは難しいのではないでしょうか。だったら(外部調達を含めて)各企業のCO2削減努力の効果である排出権を扱った方が、細かい算定が一切不要なので、マネージメントが簡単になると予想しているからです。また、仮に環境情報を正確にトレースできたとしても、各企業にはその環境負荷に応じた税金を課した場合、国によっては税負担が違うと、より税負担の少ない国に工場を移転するなどの問題がありますし、その国のCO2排出量は削減できても世界全体としては減らせるわけではない。また税金は自国通貨で納税する以上、世界という基準で見ると為替レートの影響をうけます。一方、この研究が扱う排出権というのは世界共通な経済的価値、ですから税負担とは直接関係しないし、為替レートにも影響されません。また、実経済と排出権を近づけることで、排出権取引が金融ビジネス化することを抑えるというと意図もあります。

三つ目の狙いは日本国内の排出削減能力と関わります。日本の場合、国内の排出削減だけで1990年に対して25%どこころか、15%でも削減目標の達成は不可能といってもいいでしょう。そうなると当然、海外から排出権を調達しないといけないのですが、排出権の調達には莫大な費用が掛かります。今後は環境税(炭素税または地球温暖化対策税)で排出権購入費を賄うにしても、企業にとっても国にとっても負担が大きい。それで本研究の意図は海外から排出権を安く調達することです。日本の産業構造を製造業中心からサービス産業中心に変えないといけないのですが、その段階にいくまえに製造業、特に部品産業は国内では採算性が取れなくなり、輸入が増えるでしょう。さてこの研究は部品輸入を含むサプライチェーン全体で商品(原材料や部品)に排出枠を商品販売への経済的インセンティブとして付けさせることで、排出権をCDM事業や排出権市場以外から調達する方法を狙っています。実際、部品の製造国の多くは、CO2排出量が多い国と一致していますから、そうした国々から排出権を取ることは削減負担を世界全体で均等化させるのに役に立ちます。もうすこし平たくいうと、輸出向け製造業比率の高い国々、つまりCO2排出量が多い国々に対して、輸出品に「おまけ」として排出権を付けさせることによって、安くかつ大量の排出権を手に入れようというものです。

他にも研究意図はありますが、それは個別にお問い合わせ下さいませ。いずれにしてもスポーツにしても経済活動にしても、制度やルールを作った側が有利になります。CO2排出削減は世界規模の制度設計やルール作りです。だったら排出削減目標による経済影響を愚痴っているよりも、自国に有利な制度やルールを世界制度設計にいれる方がいいのではないでしょうか。こうした国策的なことはコンピュータサイエンスの研究者が考えることではないのですが、プログラミングや通信プロトコル設計と、政治や経済の制度設計とは類似点も多いのも事実だと思います。例えば法律の条文って、プログラムみたいなものですからね。

2009年9月18日

午前中は打ち合わせ、午後は教授会と来客。なんか目が回りそう。

2009年9月17日

今日も移動が多い。打ち合わせ、お台場、オフィス、青山。ところで夕方、オフィスのあるビルのまわりは騒然状態。実は隣のビル、某会館で麻薬で逮捕された某女性タレントの記者会見が開催されたため。というわけでテレビ局の中継車が列を作り、オフィスのまわりは報道陣でいっぱい。ところで某会館を会場に選んだということは、ホテルはどこも会場を貸してくれなかったのでしょうね。ただ、記者会見をする方もする方ですが、それに押し寄せる報道陣も報道陣。不思議な国ですね。ところでこられたことのある方は御存知だと思いますが、当方のオフィス周辺は場所が場所だけに警備は厳重な地域で、そんな地域にある某会館は大騒動になることが予測できる記者会見に会場を貸したということはよっぽど客入りが悪いのですかね。

MSKKからWindows 7の宣伝メールが来ていたのですが、それがラッキー七副神というキャラクターを使った宣伝。Windows 7の7と七副神の七をかけたのでしょうが、センスがあるとかないとかの以前の問題。海外のWindows 7の宣伝はセンスがいいのにね。MSKKは広告代理店を変えた方がいいのでは。

2009年9月16日

外出など忙しい一日となってしまいました。というわけで人間版のMapReduceってできないでしょうか。まずタスクを複数のサブタスクに分割。そして複数人にサブタスクを割り当てて、あとはサブタスクの結果を集める。MapReduce方式ならタスクを割り当てた複数人のうち、数人が止まっても逃げ出しても大丈夫ということになりますが、人間ですからね。やっぱり簡単ではないですね。

クラウド時代にSIerはどう変わるのだろう？というブログ記事を拝見したのですが、「クラウド案件では単価は2桁下がる」というショッキングな内容です。もちろんサンプルが二つだけなのであくまでも事例ということになりますがね。ただ、ここまで行かなくてもクラウド案件はある程度の価格低下は想定されるわけですが、個人的な心配は非クラウド案件の単価もクラウド案件の単価に引きずられて下がる事態です。正直言って、個人的にはクラウドコンピューティングがすぐに普及するとは思っておらず、当面は少数の一部の新規案件から徐々にクラウドコンピューティングに移行すると予想しています。ただ、相場感というのは少数の安い案件があればそれに引きずられます。つまり近々でクラウドコンピューティングの最大の影響は、非クラウドの単価を押し下げることになるでしょう。そして、その影響は相当大きくなると思っています。

さてクラウド案件は仮に二桁減となればビジネスにならないようにみえますが、クラウドの場合、世界市場にサービスを売る機会も出てきます。クラウドコンピューティングというと「規模の経済」という言葉がでてきます。「規模の経済」はクラウドインフラの調達および管理コストの削減という見地から語られることが多いのですが、個人的には「規模の経済」が効くのはインフラよりも、そのインフラ上でうごくサービスの方だと思っています。世界中にサービスを提供できれば薄利多売でも莫大な利益が出ます。例えば社員2,3人だけでも数百万人にサービスを提供して、何十億円という利益を出すような企業も出てくる可能性だってあります。それなのにクラウドコンピューティングでは国内巨大データセンターが必要とおっしゃる方がまだまだおられます。しかし、世界市場を狙ってサービスを提供する事業者にしてみれば、国内データセンターに閉じ込められるよりも、海外の巨大データセンターを通じて世界中にサービスを提供した方がいい。そろそろ国内巨大データセンター待望論から卒業してほしいです。国内巨大データセンターが必要というのは簡単ですが、国内の場合、土地代、建設費、電気代、人件費などを考えるとコスト的に高くついてしまって、そんな割高な国内データセンターを使いたがるユーザはいないでしょう。

2009年9月15日

ひたすら移動の日。築地、秋葉原、目黒、芝、そしてオフィス。こちらがプレゼンする立場、そしてプレゼンを聞く立場といろいろだったのですが、今日一日でガートナーの「ハイプサイクル」の図を何回も見る羽目に。それにしてもIT業界はガートナーが好きですよね。それだけガートナーに信じている人が多いということなのだと思いますが、ただプレゼンなどでガートナーのグラフや図を使う方というのは都合のいいものだけを選んで使っているだけなのですよね。それと最近、閉口するのが、クラウドコンピューティング関連でプレゼンでガートナーのクラウドコンピューティングの予測を引用して、クラウドコンピューティングは有用だと主張する人たち。そんなにクラウドコンピューティングは有用ならばまずは社内でもクラウドコンピューティングを利用しているはずなのですが、当方の知る限り自社による利用事例を話した企業はわずか。国内ベンダーでは皆無といってもいい状態。そして自社事例の代わりに決まって登場するのがガートナーの資料や予測。というわけでダメダメなクラウドコンピューティングシステムとそうでないシステムを見分けるのは簡単で、前者は必ずといっていいほどガートナーの資料を引用してくるのですごくわかりやすい。プレゼンなどでガートナーの資料が出てきたらすぐに席を立ちましょう。

2009年9月14日

それにしても忙しいです。人から教えてもらったのですが、MITの電気＆コンピュータサイエンス学科のプログラミング授業はPythonを使っていて、もうSchemeはつかっていないそうですね。もちろんSchemeはいいプログラミング言語だと思いますが(2回ほど簡易版Schemeを実装したことあるしね)、いいプログラミング言語がプログラミング教育に向いているかは別問題。特にプログラミング教育では学生さんのプログラムを採点したり、手直ししたりすることがあるのですが(最近はプログラミング教育の仕事から遠ざかっていますが)、Pythonは可読性が高いのでやりやすそうですが、逆に学生さんの書いたSchemeプログラムは読むのが辛そう。もちろんSchemeやLisp好きの方にはいろいろいいたいことがあるのでしょうが。でも所詮、プログラミング言語は道具なのですが、道具で何を作るかではなく、道具を使うことの方が目的になっている人をよく見かけますが、趣味のプログラミングならばそれでもいいのでしょうが、プロとしては？ですよね。

2009年9月13日

今日は休日出勤はなし。さて昨日、MacintoshのOSを最新版(Snow Leopard, 10.6)にアップグレードしたのですが、使っている限りは旧版(Leopard, 10.5)と違いがわからない。中身は相当変わったということになっていますが、ユーザとしてアップグレードする価値があるかはよくわからないです。アップグレードして後述するe-mobile以外は特に問題ないのですが、同時にアップグレードする理由もない。当面は他のMacintoshは旧版のままになりそう。それにしてもこれほど違いがわからないOSのメジャーバージョンアップもすくないですよね。もっともメジャーバージョンアップといっても費用はメディア代相当なのですがね。それからSnow Leopardにしたところe-mobileが使えなくなりました。これは想定内。e-mobileの対応は早くても11月だとか。ということで持ち運ぶマシンについてはアップグレードは少なくてもe-mobileの対応以降になります(もしかするとアップグレードはパスかも)。

さてSnow Leopardというと同時期にリリースされるWindows 7との比較されることがありますが、Appleはハードウェアのほとんど自社製品ということもあって、動作試験の範囲が少ないですが、Windowsはサードパーティが作った多数のハードウェアへの対応に相当なパワーを注がないといけません。なので開発の手間を考えると単純に両者を比較できないし、動作試験範囲が少なくても済むMacOSは雑多なハードウェアに対処しなければいけないWindowsよりも安定していて当然だし、互換性重視のWindowsにはできないような斬新な機能進化を望みたいところ。Microsoftの方はエコシステムという言葉がすきですが、Windowsは築き上げた強大なエコシステムが発展の足かせになっていますよね。ならばエコシステムの外側、つまりWindows以外に別系統の新OSを出せばいいのですが、それをしないのがMicrosoftの強みであり、弱みでもありますね。この問題はAppleにもおきていますよね。iPod/iPhoneはそろそろそのエコシステムが足かせになりそうな気配がありますね。

2009年9月12日

ちょっとだけ休日出勤。ところで、Appleにやられました。手持ちのMacintoshを一台、Snow Leopardにアップグレード。ここまではよかったのですが、選んだMacintoshがいけませんでした。MacBook(アルミニウム)にSnow Leopardを載せたのですが、MacBook(アルミニウム)は64bitモードは非対応。MacBook(アルミニウム)は64bit対応プロセッサを搭載していますし、機能的には問題ないはず。MacBook Proとの製品差別化を狙っているのでしょうか。まぁサーバマシンではないので64bitモードを使うことはないとはいえ、ちょっと納得がいかないです。

ところで64bitコンピュータは必要なのでしょうか。もちろんサーバは64bitに移行するでしょうが、デスクトップPCやノートPCも64bitに移行するのでしょうかね。長期的には64bit化するのでしょうが、現状ではメモリを多く使えるぐらいしかメリットがないし、そもそも既存のPC用アプリケーションはごく一部のビデオ編集や画像処理ソフトウェアが64bitに対応しているぐらいで、それ以外は32bit用なので、アプリケーションを使う限りは32bitと64bitで性能差を感じることはない。そう思うと32bitで十分で64bitはいらないということになりますが、16bitから32bitに移行するときもPCは16bitで十分という意見はあったそうなので、歴史は繰り返すというのでしょう。おそらく64bit化は進むとは思いますが、PCというカテゴリの成長限界と32bitの限界は結構一致するのではないかと思っています。つまり64bitになってもならなくても、PCでできることはあまり変わらないように予想しています。

2009年9月11日

なんか忙しいですよね。さて今日、4-6月のGDPが年率換算3.7％アップを2.3%アップに修正だそうです。当初の3.7%というのは速報値でしたから多少のズレは仕方ないのですが、1.1%の下方修正というのはいくらなんでも大きすぎ。年率換算3.7％アップという発表は選挙中でしたから、いろいろ憶測を呼ぶことにならないといいのですが。

2009年9月10日

豊洲方面で打ち合わせ。それから大手町で打ち合わせ。海外出張から帰国後、しばらくは多忙になるのですが、今週は外回りが多いですね。ただ、いろいろ見られるので、こちらに来ていただくより、こちらが伺う方が好きだったりします。問題は企業に伺う場合はスーツを着ないといけなくなること。同じ勤務先の方はよく御存知だと思いますが、内勤さらに来客がないときの服装は結構カジュアルですからね。なので急な来客で、スーツを着てこられると困るのですよね。

ところで先週のVLDBのアフターイベントの感想を書いていなかったのですが、ちょっとだけ。今回はデータベース系の研究者、それも相当上澄みの方々と濃密に議論させていただく機会を得たのですが、データベース、というかコンピュータサイエンス全体といってもいいかもしれませんが、研究トレンドが「需要指向に既存の要素技術を組み合わせる」という方向に進みそうということでしょうか。逆に言えば原理を解明してから、その原理を利用して実世界に応用するという従来の手法は通じなくなりつつあるあるようです。例えばクラウドコンピューティングを例に挙げると、巨大データセンターもMapReduceも需要があったから生まれた技術であって、巨大データセンターの一般構築論があったわけでもない。むしろ需要に応じて既存の手法を組み合わせたというべき。また、MapReduceも関数型計算モデルなどの原理を作ってから、MapReduce手法を開発したわけではない。原理の解明ではなく需要指向で研究となると、その需要の無いところでは研究開発は非常に難しくなっていきます。例えば最近、MapReduceクローンのHadoopを効率よく実行するための仕掛けに関する研究や、Hadoopそのものを改良する研究が流行っていますが、需要に応じて研究開発をするのですから、Hadoopを使わないといけない需要、つまり大規模データ処理をしないといけない立場とそれ以外では大きな差が開きそう。

実は今日の打ち合わせのひとつは某社の国産クラウドの技術説明というものでしたが、研究開発している方々は頑張っているのですが、そもそもこの某社自身が超大規模データセンターを使わないといけないという立場ではないので、某社が提案されているアーキテクチャは概念レベルではよさそうにみえても、なんでそのアーキテクチャが必要だったのかが明確ではないし、おそらくそのチューニング技術は持っていないでしょう。逆に言えばクラウドコンピューティングは自社でシステム構築から運用まで企業以外は必要な技術がわからないことなり、ITベンダーでも他者のシステムを構築したり、運用するビジネスそのものが立ちゆかなくなる可能性もあります。

また、行政サイドでは現在、クラウドコンピューティング関連技術への研究予算投下が検討されています。しかし、インフラを構築・運営の需要のないところにインフラ向け技術を開発しても意味ないです。また、研究開発助成のあり方も変えるべきかもしれません。上述のようにクラウドコンピューティングに必要な技術は需要指向で研究開発が進むのであれば、技術開発そのものに研究資金を投下するよりも、(例えば電子行政などの一環で)クラウドコンピューティングを使わなければならないような案件(エコポイントがいい例)を出していき、その案件に応じた技術開発を進めさせた方がいいかもしれません。つまり技術開発そのものに資金供給するという現在の研究開発助成は時代に会わなくなりつつあり、むしろ新しい需要を作る方が結果として技術が発展するのかもしれません。もちろん、当方を含めアカデミアの研究者はシーズベースで研究を進めるので、需要指向へ移行は厳しいものがありますが、ただ研究として新しい需要を提案するという生き方もあると思います。

2009年9月9日

午前中は教授会。午後は打ち合わせで港区、また戻ってきて打ち合わせ。さて教授会ですが、ただ、東西線が止まったこともあって、当初は定足数に達せず会議が延びましたね。まぁ長引く会議なのですがね。今回の教授会は当方の学生さんの博士審査判定があったのですが、無事に合格が認められてやれやれですね。博士論文公聴会以降の仕組みは大学関係者でないと知らないと思うので少し書くと、博士審査の判定は、指導教員＋複数名の審査委員会を組織して、博士論文および公聴会の結果を受けて合否判断します。ここから先は本人の学生さんでなく、指導教員の仕事になります。さて公聴会の結果ははあくまでも審査委員会の判断。その判断を専攻レベルの教授会に報告して、その専攻教授会から博士審査合格を承認してもらう。その結果を大学レベル(または研究系レベル)の教授会で博士審査合格を承認してもらうという最終フェーズが必要です。今日は上述でいうと専攻レベルの教授会なので、もう一回、教授会に審議をかけることになります。専攻レベルの教授会は参加される先生方の専門と博士論文の専門は近いので、審議にかかる博士論文の中身は想像がつくことがおおいのですが、大学レベル(または研究系レベル)の教授会になると分野もまるで違うので、さっぱり訳がわからない研究への審査をすることになります。前の勤務先では研究系が理系も文系も一緒だったので、物理の博士論文から文学の博士論文まで審査することになりました。

2009年9月8日

おいでになった記者さんとPaxosアルゴリズムの話になったのですが、確かにクラウドコンピューティング関連でPaxosは最近注目の的ですよね。そして国内でも実装を試みる方も出てきていますね。さて分散アルゴリズムにちょっと知識のある人なら御存知のようにPaxosの最初の論文は、その提案内容よりも、その論文の発表経緯の方が有名ですよね(編集委員の机に埋もれていて、書いた本人はギリシャに・・・投稿から10年後に発表された)。ここまでは一般に知られていることですが、問題はここから。なんで10年間も論文が放置さえていていても先発明者が明らかだったのかというと、発明者の方(LaTeXを作った人。米国研究者には珍しくシャイな人ですよね) というか、その方の所属企業(DEC、いまとなっては懐かしい)は特許出願(US Patent 5261085)をしていたからです。なお、この特許は成立していませんが、20年間の特許権成立猶予期間ぎりぎりまで遅らせているだけとみるべきでしょう。このためDECを吸収したHP(正しくはDECを吸収したCOMPAQをHPが吸収した) と、HPとクロスライセンスを結んでいる企業でもなければ、Paxosアルゴリズムを使うとこの特許成立後に特許侵害で訴えられる可能性があります。なお、HPはこの特許に関わる研究開発の話はきいていませんが、この特許を材料にクラウドコンピューティングインフラのハードウェアビジネスに乗り出す可能性はありますよね。そしてHPのクロスライセンス先の一つであるMicrosoftはこの特許の発展版を最近、いくつか出願していますし、発明者はいまはMicrosoft所属だったりします(余談ですがDECの特許を有意義につかっているのはMicrosoftかもね)。

普段は特許侵害に気づいても個人的に指摘していて、このページを含む不特定多数が読むメディアには書かないし、公開の場では話さないのですが、Paxosは日本でも研究している人が多いのであえて書きます。企業が書いた論文で新規性の高い技術に関する論文があった場合、その技術は特許出願されていることがほとんど。上述のようにPaxosも例外ではありません。もちろんPaxosを研究している学生さんは特許について知らなくても仕方ないと思いますが、大学や企業のプロの研究者だと話は違います。今のご時世、論文だけでなく、特許についても調べるのがプロの研究者にとっては基本中の基本。仮に特許調査もしていないで研究をしているとしたら、プロの研究者として脇が甘いといわれても仕方ないです。特にPaxosはクラウドコンピューティングでもインフラのコアで使われる技術ですから、インフラ外からみても使っていることはわからないし、その実証は難しい。つまり黙っていたら侵害してもわからない可能性が高い技術です。しかし、(Paxosに限らず)他社が特許に出されている技術に関する技術について、権利者以外が内々に使っている、または将来使う予定になる場合、その技術についての研究開発を発表するのは特許侵害が発覚する可能性が高くなるだけだし、特許侵害裁判のときにその技術に関する研究発表などが法的証拠として採用されるだけ。

当方は、Paxosの研究をするな、というつもりはまったくないし、重要な技術だからPaxosは研究はした方がいいと思います。3相の分散プロトコルは研究は多いのですが、実用になっているのはPaxosぐらいですからね。ただ、研究には外に話していい研究と話さない方がいい研究があります。プロの研究者だったらもう少し上手くやって欲しいです。

2009年9月7日

やれやれ帰国です。会議中はずっと朝から晩までという状態でしたから、さすがにぐったり。往路のANAの成田発パリ行はボーイング777でしたが、復路のパリ発成田行はボーイング747、いわゆるジャンボジェット機でした。ANAは欧州線はB747からB777に切り替えが進んでいるので、もしかすると当方がANA欧州線B747にのるのは最後になるかもしれませんね。まぁエンジンが4つ(B747)と2つ(B777)だったら2つの方が経済的なのでしょうね。そうそうエコノミー席の毛布と枕が新しいタイプに変わっていました。毛布はちょっとだけ豪華に、枕は低反発クッション＆コンパクトになったようです。前の枕は柔らかすぎて枕には不適だし、そのわりに大きくて邪魔になるだけでしたから。こんなことでも当方のようなエコノミー座席の常用者にとっては大きな進化ですよね。それにしてもANAは成田発便と成田行便で食事のクオリティに差がありますね(これはJALも同じだけど)。成田行便の食事はもう少し何とかならないのでしょうかね。今回も復路は2回の食事ともにほとんど食べずじまいでした。そうそう機内で締め切りがせまっていた論文を書いていたのですが、到着後に締め切りが延びていました。

2009年9月6日

6回目のフランス訪問もいよいよ終わりです、といっても今年にはいってからの訪仏回数ですが。帰国にむけてパリCDG空港に移動です。今回は乗り継ぎだけなのですが、空港で5時間待ち。以前は、これだけ待ち時間があったら、荷物があろうとなかろうと一瞬市内に出て、パリの空気を吸ってみたりしていましたが、いくつか仕上げないといけない仕事もあるので、今日のところは空港でお仕事です。ところでパリCDG空港といえば、新しい第2ターミナルよりも古い第1ターミナルが好きだったりします。第1ターミナルは初めて降り立った海外空港ということもありますが(アンカレッジ経由の時代でした)、それよりも1970年代の未来社会を思わすような感じが好きだったりします。それにして第1ターミナルは1960年代末に作られたそうですが、当時は最先端だったのでしょうね。

2009年9月5日

午前中は主催者側と講演者で打ち合わせをしてから移動でした。それにしてもVLDBコミュニティというデータベース屋さんの集いによんでいただいて感謝ですよね。今後の流行るデータベース研究トレンドを知る機会がえられたのは、データベースの研究者ではない当方にとっても貴重な機会でした。データベース研究は、SIGMOD、VLDB、ICDEという少数の国際会議でトレンドが決まるし、そのコミュニティもどちらかというと閉じているし、国際会議で採録・発表された論文というのはすでに研究として終わっているわけでして、これらの国際会議の今後の研究トレンドは、こうした内輪のイベントに参加しないとわからないのかもしれませんね。今回は欧州の研究者の集まりでしたが、米国でも有力大学の研究者や博士課程の学生さんは他の有力大学の有力研究室に講演に行ったりして、研究トレンドの情報交換をしていて、一部の有名大学の一部の研究室だけがメジャー国際会議に採択されるという状況を作っています。もちろん、いいのか悪いのかわかりませんが。ただひとついえるのはインターネットがいくら普及しても、本当に重要な情報はネットには流れないということですね。3時過ぎからちょっと散策。

2009年9月4日

やれやれ講演終了です。5時間の英語講演は長いですね。もちろん日本語でも長いのですがね。スライド120枚+ビデオという構成でした。質疑も多かったので興味は持っていただいたのでしょう。ところで日本語よりも英語の方が喉にやさしいというのか、日本語で長時間でしゃべると喉がおかしくなることが多いのですが、英語の方が喉への負担が少ないような気がするのですが、気のせいでしょうか。

ちなみに講演の聴衆は学生さんをふくめて30人強なのですが、みなさんアクティブですよね。学生さんはポスドクポジションを得るために必死に売り込むし、ポスドクの研究者は次のポジションを狙って必死に売り込む。また売り込むにしても、自分の研究が当該分野や社会にいかに貢献があるかを強調するのですよね。これが日本の方の場合はというと、アクティブな研究者はいるのですが、残念ながら自己満足に研究される方が多いのですよね。一番困るのは、おもしろいことだけをやっていればいいと開き直られるタイプ。たしかに自分がおもしろいことを素直にやるとパフォーマンスが一番高いのでしょうが、テーマからして自己満足で設定しているので研究の貢献がなかったり、あっても自分で自分の研究の貢献がわからないのですよね。また、おもしろいと思うところだけをつまみ食い的に研究されるので、偏食というのか、バランスが悪いのですよね。例をあげると、プログラミングがおもしろいからといって、プログラミングばかりしていて、評価は手抜きというパターン。まぁ今回は海外でも上澄みだけ集まっているような状態なのでしょうがね。

2009年9月3日

4日目です。さすがに疲れてきますね。ところでGoogleのApp Engineの開発担当がリレーショナルデータベース(RDB)の採用予定はない、と表明したというインタビュー記事が出ていたそうですが(海外にいるので読めていませんが)、今回参加しているVLDBのアフターイベントのコミュニティの見解は微妙に違うようですね。長くなるので詳細にはかきませんが、問題はRDBはJoin操作などのコストが大きいこと自体が問題なのではなく、そのコストが予測できないことが問題だそうです。

確かにいわれてみればその通りで、例えばGoogle App EngineではRDBもどきのことはできても、Join操作がありません。ただ、Join自体は不可能なわけではないし、例えばVLDB'09の論文にあったようにパイプライン処理化すれば極めて高い並行状態でもJoinの処理コストは下げられます。ただ、データによって処理コストの大きさがわからないという状況は変わりません。逆にいえばコストが予測できるようにRDB操作を実行すればいいことになり、そう考えるといくつか工夫の余地は出てきますね。いずれにしてもコストの予測可能性(Predictability)は今後、重要になるかもしれませんね。つまり計算コストやメモリコストが予想できない可能性のある処理は排除されないまでも、経済的コストが高く付くという状況は想定しておいた方がいいかも。

2009年9月2日

3日目です。朝9時から夜11時まで続くのでさすがにくたびれてきました。今回は保養地なのだと思いますが、バスが一日に数本しかないような場所なので、当たり前ですが、会議に参加するしかありません。今日もセマンティックデータベースの話。それも演繹データベースの話が続いています。データベース屋ではないので、データベースの研究トレンドを熟知してるわけではないですが、演繹データベースの論文は最近はデータベースのメジャー国際会議では最近は見かけないのと思うのですがね。

ところで参加している研究者とMapReduceの話になったのですが、やっぱりMapReduceにのせられる処理はごく一部で、今後のトレンドはMapReduceにのせられない処理の方のようですね。というかデータ処理系の研究者でもMapReduceにあえてのせられない処理にフォーカスしているのは印象的ですね。VLDB関係者が多いこともあって、データセンター系、特にクラウドコンピューティング関連の話題になるのですが、意外にもトランザクションまわりの話が多いですね。

クラウドコンピューティングはトランザクションが苦手ということになっていますから、そのトランザクションを何とかしたいというのは研究者としてまっとうな発想。いくつかトレンドはお聞かせいただいたのですが、ひとつだけ紹介します(ここからはかなり技術的なのでお許しください)。ご存知のようにデータセンター内とデータセンター間でトランザクションアルゴリズムが違ってくるのですが、トレンドの一つは相異なトランザクションアルゴリズムの整合性だそうです。もちろんデータセンター内向けとデータセンター間向けでトランザクションアルゴリズムが出そろってからなので、先の研究トレンドになるのですが、確かに組み合わせ方によっては整合性はとれない可能性がありますね。以前流行ったマルチデータベースの一種と思う方が今回の参加者におられましたが、マルチデータベースではデータベース間トランザクションの研究はあまりやられていないので、新しいテーマになりますね。ほかにもいろいろ話題になったのですが、それはまたいずれ。

2009年9月1日

今日もVLDB'09のアフターイベントです。午前中はETHの方による昨日のデータストリームプロセッシングの講演の続き。当方がコメントするまでもなく、案の定、分散イベントやネットワークルーティングの技術とどこがちがうのかと吊し上げになっていました。ただ、5時間もチュートリアルするだけの知識がありながら、他分野のことはまるで知らない様子なのが端から見ていても哀れでした。ただ、この方はVLDBやSIGMODなどにデータストリームプロセッシング絡みで結構通している方だそうですから、状況は深刻かも。昨日も書きましたが、この方の問題ではなく、実際、SIGMODやVLDBなどのデータベース系のメジャー国際会議で発表された論文ですら、データベース系の論文しかリファレンスしてない傾向があるそうですから、データベース系の研究コミュニティの文化なのでしょうね。もちろん当方はその是非を評価する立場ではありませんがね。

午後はセマンティックデータベースの講演ですが、こちらは当方は関心がないというのか、セマンティック表現は一昔前の知識表現と同じで、どうしてもメタ記述のメタ記述になるので、技術ではなく哲学の問題になるのですよね。というわけで知識表現とオントロジーには手を出さないことにしています。それにこの講演では久しぶりに演繹データベースの話を聞きました。昔はいろいろなデータベースがありましたよね。演繹データベースとか関数型データベースとか、それにオブジェクト指向データベース。オブジェクト指向データベースぐらいもう少し生き残るかと思いましたが。例えば最近流行のオンメモリデータベースに限定してしまえばオブジェクト指向データベースの問題点が結構解決できると思ったりしますが、どうなのでしょう。

2009年8月31日

東京方面は台風だったそうですが、フランスは晴天です。さて国際会議の1日目です。午前はデータベース関連のEUの研究プロジェクトの説明、1時間×3本。午後はデータストリームプロセッシングの研究動向。午前の方は一人目はよかったのですが、あとの二人は博士課程学生のさんの研究を集めただけという感じ。ただ、全般にいまひとつ時代遅れなのと、講演した3人とも応用の説明がまったくないプレゼンでした。これではコメントのしようがない。

午後の方はETHでデータストリームプロセッシングを研究している方の講演、Brown大やMITのデータストリーム系プロジェクトを渡り歩いた方がだけあり、具体的に説明していただきましたが、個人的には新味のある話はなし。ただ、この講演は明日も続くの明日に期待しましょう。いつも思うのですが、データベース系のデータストリームプロセッシングの話はネットワークやデータフロー計算、分散イベントの研究の焼き直し的な話が多いですよね。ただ、知り合いのデータベース系研究者(複数)によると、データベース系の研究者は論文サーベイ対象がデータベースに関する国際会議や論文誌だけになる傾向があるそうで、それが他分野を知らない原因だとか。まぁその真偽は別にして、もちろんデータベースの論文だけで読んでいればいいというのは幸せかもしれませんが、他の分野の知見をうまく使えば回り道をしなくても済むと思ってみたり。

2009年8月30日

データベース系の国際会議VLDB'09のアフターイベントに招待されたので、プロバンスの端っこにあるToulonという街の郊外に移動。ご存知のようにVLDBはMapReduceなどの主戦場の国際会議なのですが、当方はアフターイベントだけ。だってデータベースを研究しているわけではないしね。アフターイベントは招待された研究者が7,8人が最新動向の講義をするのですが、当方の担当はユビキタスコンピューティング向けのミドルウェアとデータ管理に関する動向。ただ、各自5時間話さないといけないのがきつい。日本語でも5時間の講義はハードなのに、英語で5時間だから、ボロボロになりそう。

さてToulonへの移動ですが、当初は車に乗せてもらう予定だったのですが、結局、電車で移動。道中は想定された事態ですが、合流した研究者たちとずっとVLDBで発表された研究の議論。別件もあってVLDB'09で発表された論文のうち何本か読んでおいたのでなんとか話題についていけましたが。今年のVLDBは、MapReduceというか、Hadoop関連の論文に関する論文が多かったようですね。ところでMapReduceといえばOSの国際会議SOSP'09 の採択論文にもHadoopがらみの論文が何本かありました。MapReduce処理専用のデータセンターを構築する企業もあるようですが、高計算性能や低消費電力などの理由でMapReduceを含む特定のデータ処理に特化してクラスタを組むのであれば、OSも特定のデータ処理に特化させた方がいいことになります。しばらくはOSもデータベースも、そしてミドルウェアやネットワークも、特定アプリケーションのための専用機、というか専用クラスタまたは専用データセンターまわりの研究が流行りそうですね。

2009年8月29日

今日からフランス。ANAのパリ行きの飛行機の出発が遅れて、パリでエールフランス便への乗り換えで走る事態。ANAは乗れないことを考えて次のフライトも押さえておいてくれたのですがね。さてANAのパリ行きの飛行機はエコノミー席がいっぱいでビジネスクラスにアップグレードされちゃいました。機体はBoeing 777。これまでANAのパリ便はBoeing 747(いわゆるジャンボジェット機)だったのですが、Boeing 777になるそうです。さてビジネスクラスの席ですが、これがお世辞でもいいとはいえず。正しく説明すると、ANAのビジネスクラス席でも新しいタイプの方なのですが、フラットに近い状態になるので寝るのにはいいのでしょうが、イスとしての座り心地自体は決していいないのです。機内で仕事をしている当方は不向きです。というわけで今回は珍しく飛行機で寝ることになってしまいました。たしかにいつものエコノミー席とちがってビジネスクラスは寝るのにはいいですね。ANAの場合、イスとしての座り心地はプレミアムエコノミーの座席が一番いいかも。それとANAのキャンペーン「夏の大作戦」期間中だけに成田発欧州便のエコノミー席の機内食に冷やし中華があって、それが結構本格的な冷やし中華で、ちょっと楽しみだったのですが(実は先月は2回食べた)。それもビジネスクラスでは食べられませんでした。よせばいいのにCAさんにエコノミー席の食事が食べたいと頼んでみたのですが、ものすごく驚いた顔をされました。さて結果ですが、結局、やんわりと断られました。

2009年8月28日

早朝出勤、2時間講演、そしてオフィスに泊まって徹夜作業。講演はクラウドコンピューティング関連。今回は政府関連の非公開セミナーなどで話すときに使うスライドセットを使ったのですが(もちろん差し障りのあるスライドは抜いたのですが)、クラウドコンピューティングの技術説明よりも、クラウドコンピューティングが経済や社会にどのような影響を与えるかという内容。

多少紹介しておくと、クラウドコンピューティングの大きな特徴はユーザ企業がサービス提供者になれるというものがあります。つまり、自社用の処理を他社にも提供するということ。既存のシステムでは自社用の処理で手一杯だったのですが、クラウドコンピューティングはスケールアウト性がありますから、同じ処理をたくさんやることは簡単で、自社の処理が他社にも提供できるようになります。ベンダーはユーザ企業のサービス提供は商売敵になるので、あまり強調しませんが、クラウドコンピューティングの最重要な特徴のひとつだと思います。ただ、これは怖い一面を持っています。

例えば銀行がクラウドコンピューティングインフラを使って自社用の情報システムをサービスとして他行に提供した場合に何が起きるのでしょうか。自行向けの情報システムをサービスを他行に提供したとき、前者は他者の業務を監視できる、つまり実質的に前者は他者をコントロールできることを意味します。いまの銀行は預金高などで序列されていますが、今後のサービス提供能力で序列されるということ。二つ目はまた銀行が顧客に財務管理サービスを提供した場合はそのサービスの利用関係が序列関係につながります。

銀行同士のような同業者だけでなく、関連会社に提供する場合もあります。自動車会社に代表される系列産業において、例えばアセンブリメーカが、発注管理サービスや納品管理サービスを用意して、それを下請けの部品会社に提供した場合はどうでしょうか。先ほども行ったようにクラウドコンピューティングのスケールアウト性により、全下請けにサービスを提供することは容易です。さて下請けの会社にとっては発注管理や納品管理のための情報システムが不要になりますが、同時にメーカが提供する発注管理サービスや部材購入管理サービスを利用することは、発注状況や部材購入などすべてメーカに見えてしまうことを意味します。もちろん、下請け会社はそうした状況を嫌がるとは思いますが、こうしたサービスの利用を求められたときに断れるでしょうか。

クラウドコンピューティングというとインフラ事業者に情報を見られると、通信が傍受されるとか、そのレベルのセキュリティ問題で大騒ぎする人たちがたくさんいますが、本当に怖いのはクラウドコンピューティングという方法自体が社会や経済にあたえる影響の方。そのひとつは上述の自動車の例のように、ある団体や個人が何らかの優越的地位の濫用して、クラウドコンピューティング上のサービスを利用を他の団体や個人に強制された場合です。そのサービスの提供者はサービスの利用者を監視することができる。実質的に後者は前者にコントロールされる自体も考えられるでしょう。こうした問題はいままでの情報システムでは、それほど気にすることはなかったのですが、先述のようにクラウドコンピューティングはスケールアウト性があるので、広範囲にサービスの利用を強いる可能性があるのです。また、既存のシステムではサービスの提供者はサービス開発・提供の専業者だったのですが、同業者や取引相手などがサービスを提供するようになると話が一変します。なお、こうした問題は技術だけでは解決できないでしょう。なんらかの規制・監視組織を作る必要があるかもしれませんね。

2009年8月27日

今日はお引っ越しの準備。作業部屋が12階から13階に移ることになり(オフィスはいままでどおり19階です)、PCクラスタをバラすことになったので、ひとりでもくもくと40台ほどのPCからネットワークをはずしたり、機材をまとめたり、ダンボールの解体などなど大騒動。ひたすら肉体労働の日々になりました。ただ、またクラスタを組み直すかと思うとかなり気が重いというか、当面は少数台の構成で実験になりそう。それと明日は新版MacOS Xが発売されるからというわけではないのですが、PowerPC搭載Macintoshも一掃。

2009年8月26日

今日は当方の学生さんの博士論文公聴会(博士論文の審査会のこと)。無事に終わってやれやれです。あとは専攻会議で公聴会の審議結果を報告して、了承を得られれば晴れて博士となります。公聴会はもちろん本人もたいへんですが、指導教員もいろいろ気を遣います。まぁ無事に終わってので当方としては何もいうことはないのですがね。さて下記は一般論であって、その学生さんとは無関係です。

研究者とっては博士号はライセンスみたいなもので、博士号をプロの研究者になるための資格試験にすぎず、重要なのは博士をとってからの仕事なのですよね。特に大学や研究所などのアカデミアの道を選んだ人は博士をとってから3~5年ぐらいにオリジナルの仕事ができるか否かが重要。はっきりいってしまえば博士論文の出来不出来は関係なく、博士をとったあと研究者として伸びるか否か重要なのです(だから、つまらない博士論文テーマでも、その後の伸びにつながるようなテーマならばその方がいい)。逆に失敗するケースは博士論文の研究をそのままダラダラと続けてしまうケース。もちろん博士論文の研究テーマが今後も発展するテーマならば続けるべきですが、ちょっと離れて新しい仕事をしてみるのもいいと思います。新しい研究テーマを見つけられるというのも研究者にとって重要な能力ですからね。

それと大物といわれる指導教員をもった方々にとっても多い失敗ケースが、博士取得後もその指導教員がボスをしているプロジェクトに関わったり、論文も指導教員が共著に入った論文ばかり書かれるケース。そうした方は外部からは指導教員のサブセットにしか評価されないのですよね。特にその指導教員が目立つ人だったりすると、指導教員といっしょに研究をしている限りはその指導教員の影に隠れてしまうのですよね。研究の世界は一番とそれ以外。前者には居場所がありますが、かわいそうだけど後者には居場所がありません。自分の指導教員に、自分の研究テーマの一番をとられてしまう可能性があるのならばさっさとテーマを変えた方がいいかも。もちろん若い研究者は予算的にもたいへんなのですが、指導教員のすねをかじって、その先も２番以下の研究者として終わってしまうよりは、予算で苦労してでもいいので、指導教員から離れて新しい分野で一番になった方がいいです。きついことを書いてしまいましたが、親離れに失敗する研究者は多いのですよね。

ただ、親離れに失敗する人が多いことの背景には子離れができない指導教員が多いというのもあるように思います。最近の若い研究者にパワーがないとか愚痴をいうお偉い先生が結構多いのですが、そうした先生方の多くは博士取得後も学生さんを手元に置きたがります。しかし、人は環境をかわると伸びることが多いのですから、個人的にはそうした愚痴を聞く度に「あなたが手元に置こうとするから才能が開花しないんだよ」といいたくなります。指導教員も大きなプロジェクトを抱えていたりすると、気心の知れた自分の学生をまわりにおいて置きたいという心理はわからないでもないですが、それは学生さんのためにならないと思います。なので当方は学生さんは引き留めないというスタンスでおりますし、上述の学生さんも引き留めませんでした。

話はかわってAmazonが同社のクラウドコンピューティングインフラと企業側システムをつなぐサービス(Amazon Virtual Private Cloud (VPC))を発表。まぁAmazon内に格安でプライベートクラウドを作るようなサービスなので、既存のプライベートクラウドの位置づけは微妙になりそう。さてメーカ系のベンダーはプライベートクラウドがお好きなようですが、プライベートクラウドは仮想化技術を駆使するため、確かにハードウェアは有効利用できても、仮想化を含めてシステムが複雑すぎで管理がたいへんになってしまいます。個人的には大量のサーバをもつ大手企業ならばともかく、普通の企業がプライベートクラウドを導入しても、システムが複雑になるだけで何もいいことはないと思っています。ただ、プライベートクラウドをAmazon EC2などのパブリッククラウドや今回のVPCにつなぐというのならば話は違ってきます。普段はプライベートクラウドで運用して、必要に応じてパブリッククラウドを使うのならばつなぐのばら、プライベートクラウドもパブリッククラウドに近いアーキテクチャの方がいいことになり、プライベートクラウドという複雑なシステムを使うメリットで出てくるかもしれません。というかそれぐらいしかプライベートクラウドのメリットってないですよね。

AmazonのVPCは、プライベートクラウドが大好きなメーカ系ベンダーにとっては影響が大きいでしょうね。プライベートクラウドはAmazon VPCとの接続性が大前提になっていくでしょうから、Amazonのパブリッククラウドと相性の悪いプライベートクラウドや仮想マシンベースのホスティングサービスはユーザに敬遠されることが予想されます。

2009年8月25日

昨晩は徹夜でスライド作成。90枚を作るのはかなりたいへん。今日は予算関連の書類作成。もう何をやっているんだろうかというか感じです。

ところでWebにVisual Baisc 6 (VB6)がまだ使われているという記事がありました。当方の知る限りでも工場などの制御系システムではいまでもVBで書いたものを見かけることがありますし、企業によっては10年前に発注して作った業務システムを使い続けているところがありますが、こうした小さい業務システムだとVB6あたりで書かれていることが結構多いのですよね。ピュアにコンピュータサイエンスの研究をされている方にはVBは縁がないと思いますが、ICタグのリーダ・ライターやセンサーなどのデバイスではいまでもWin32API のランタイムを介さないと制御できないものがあり、こうしたデバイスも扱う場合は、下手にC++を持ち出すよりもVBで制御プログラムを書いた方が早い場合があります。

さて、個人的にはWindowsの「キラーアプリケーションはVBだった」と信じております。もちろん、いろいろ異論があるとは思いますがね。ただ、Windows 95登場前後に、中小企業が発注した業務向けシステムは多かったのは事実でしょうし、中小企業で業務システムを発注できるようになったことが、中小企業がPCを導入する大きな要因になったのではないでしょうか。日本は中小企業比率が高いので、中小企業がPCを買ってくれないと広まりません。また、米国の場合は個人営業的なコンサルタント兼プログラマーみたいな仕事をしている人が多く、そうした方々にVBは広く利用され、数多く業務システムが開発されました。実際、Visual BasicもどきRAD(Rapid Application Developmentのこと、いまとなっては懐かしい響きですね)がいくつか登場しました。

まぁ、好き嫌いをいったらVisual Basicは嫌いな言語なのですが、ただプログラミング言語の善し悪しは、決して設計思想や文法が美しいと、性能がいいとかではなく、プログラマーの立場からみて、稼がしてくれるか否か。つまり金が稼げるプログラミング言語がいいプログラミング言語になります。その意味では、Visual Basicは小規模の受注システムの開発では広く使われましたから、多くのプログラマーを稼がしたのでしょう。ちなみにプログラミング言語の設計思想や文法に執着するのは、当方を含めて研究者のようにプログラミングでそのもので稼ぐ立場でない方々が圧倒的に多いような気がします。ものを作る人にとっては道具そのものより、その道具で何が作れるかの方が重要ですからね。

なお、個人的なVBの関わりはVisual Basic ver.3 (VB3)からでして、VB3は日本未発売だったのですが、海外でRAD環境として話題になっていたので、個人輸入して使ってみたというのが最初でした。その意味では早かったと思います(日本でVBが知られるようになったのはVB4からでした)。ただ、当方はその当時、NeXTのInterface BuilderやAppleのHypercardの洗礼を受けた後だったので、VBには貧弱なプログラミング環境という印象しか持ちませんでした。ただ、当時のWindowsプログラミング環境は非常に貧弱でしたし、プログラマーには高いスキルを要求するものでしたが、VBだとマウスで画面を設計して、アクション単位に短いプログラムを作るというお手軽プログラミングスタイルは、Windows向けソフトウェアの開発効率を大幅にあげることに大きく貢献しました。ところで先の記事にもありましたが、MicrosoftがVBの呪縛から抜け出すには相当かかるのではないでしょうか。

2009年8月24日

早朝、区役所にいって期日前投票。投票所は会議室だったのですが、悪い癖でスタッフさんの数を数えてしまいました。受付が3人、小選挙区の投票用紙をわたす担当の方が2人、比例区と最高裁の投票用紙をわたす担当の方が3人、そして監督役が3人。ちなみに当方がいったとき期日前投票の会場にいたのは当方一人。職務の特性上、正規の職員さんたちだと思いますが、これだけの人数を2週間近くはり付けたら人件費はいくらなんだろう、なんて考えてはいけないのでしょうね。ちなみに同じ区内に何カ所か、期日前投票所があるはず。

2009年8月23日

Appleが巨大データセンターを作っているそうですね。Appleは自社のWebベースサービスでは、メールなどのサーバを「クラウド(サーバ)」と書いて、クラウドと呼んでいるぐらいですから、クラウドコンピューティングに御関心があるのでしょうね。おそらくiTunesなどのコンテンツ系のサービスを仕掛けてくるのだとは思いますが、データセンターという閉じた空間にコンテンツを置くようにすると、コンテンツ管理は簡単になりますし、再生回数に応じた課金もできるようになるはず。いまのAppleの強みは、ユーザインターフェースに優れたOSをもっていることでも、斬新なスマートフォーンをもっていることでも、製品デザインがすぐれていることでもなく、iTunes Store用に研究開発された課金技術とその特許ですからね。

2009年8月22日

今日は写真家アンリ・カルティエ＝ブレッソンが生まれた日だそうです。ブレッソンというと「決定的瞬間」という言葉を作ったことで有名ですが、画家志望だけあって写真のフレーミングはもちろん、被写体の構図にスキがないのですよね。日常の瞬間を撮っていながら、構図ができているというのはすごいですよね。もちろん、その完璧さが見る側の好き嫌いを分けることになるのですが。

ところで最近はフィルムの現像・プリント代が高いですよね。白黒フィルムを町中のDPE屋さんに現像・プリントに出したりしたら、一週間以上かかるし、お値段も高いしでいいことなしです。フィルム業界の方に伺うと、警察や消防署が証拠写真というのはフィルムの大口消費の一つだったそうなのですが、証拠写真もデジタル写真を使うようになりつつあり、フィルム需要が一段と減ったとか。確か裁判員裁判のときも裁判委員にはディスプレーで証拠写真を表示していたという話ですし。需要が減るので値上がりする、値上がりするのでさらに需要が減るというネガティブフィードバック。

2009年8月21日

新型インフルエンザが再び流行しているようですね。IT業界ではインフルエンザが流行すると必ず話題になるのが、企業のノートPC持ち出し規制。御存知のようにIT系企業でもノートPC持ち出し禁止にしているところが多い。ただ、インフルエンザ対策として一番有効な方法は、出歩かないことだそうですから、社員が在宅勤務できるようにしてあげればいいのにね。社員の安全確保よりも社内情報の安全確保ということなのでしょうか。仮にそうであっても、出社しないと業務できないようにしていると社内でインフルエンザ感染が広がるリスクは高くなり、感染拡大時に業務そのものが止まってしまいます。

これに限らず、国内企業はセキュリティを重視過ぎるというのか、過度のセキュリティ対策がコスト高の原因になっていますし、業務にも支障をきしていますよね。セキュリティ対策は重要なのですが、リスクの発生確率とその損害額に応じてセキュリティ対策を立てないといけないのですが、日本は伝統的にオペレーションリサーチが苦手ですよね。情報システムに限らず現代社会は開放系なのですが、リスクゼロなんて実現できません。むしろリスクを許容範囲まで減らすことの方が重要。

先日、IT企業の方々とGmailの安全性に関する議論になり、企業の方々は「大学ではGmailでメールを管理しているところがあるが、Gmailは危険性があり、弊社ではGmailによるメール管理などは考えられない。」と強くいわれました。でも、そもそもメールはインターネットというセキュリティ無法地帯を流れて届くわけですから、配送中にメールが盗聴されている可能性があります。だから、Gmailを使ったからといって安全だったものが危険なものになるのではない。Gmailを含めてWebベースのメールシステムによる盗聴を心配するのなら、メールそのものをやめた方がいいです。こうした見方しかできない方々は部分的なリスクにだけに目がいって、全体リスクが見えなくなっているのでしょうね。木を見て森を見ずという典型例でしょう。ちなみにここまで程度が低い方々に何をいっても無駄なので反論はしませんでした。いずれにしても不必要なセキュリティ管理は不要なコストだということを認識して欲しい、ある程度リスクは避けられないという前提にたってセキュリティ管理をして欲しいです。

2009年8月20日

このページを一般のBlogにしないのですか、と聞かれるのですが、RSS対応ならば勝手にRSSに対応していただいている方もおられるようですから。当方の自分のページを調べるときに利用させていただいています。RSSといえば今月に入ってからPubSubHubbub対応のBlogサービスが増えましたね。国内では昨日からLivedoor BlogがPubSubHubbub対応だそうです。RSSでもリアルタイムにBlogの更新情報が伝わるという感じでしたが、せっかちになったということでしょうか、RSSのリアルタイム性では満足しなくなったのですね。ただ、PubSubHubbubというとRSSをTwitterのようにリアルタイム化するという紹介をされることが多いのですが、それはその通りでしょうが、Web検索サービス(の事業者)の負荷を下げるものとみることもできます。PubSubHubbubを含めてWeb Hooks系の技術というのは、ページの更新があると、通知イベントを送る仕掛け。一方、Web検索サービスというのは定期的にクローリングする、つまりWebページを定期的にアクセスし、その内容をため込んでいます。この定期クローリングはWeb検索サービス事業者にとっては負担になっています。一方で、更新されるページはWeb全体のほんのわずかなので、Webページから更新を伝えてくれれば、無闇にクローリングする手間が省けるようになります。

ところでPubSubHubbubを使えばTwitterのようなサービスを簡単に作れるのですが、それ以外にWebベースのリアルタイム情報共有システムとしても有望かもしれません。またPubSubHubbubのハブ同士の接続関係をそのまま使ったSNSも作れるはずで、そうなるとSNSサービスそのものがハブネットワークの構造と一致することなり、インターネット上にある種のバーチャルなネットワークが構成されることになります。その場合はPubSubHubbubのハブのファンアウト数とカスケード数がコミュニティの近さを表すことになりそう(Small-Worldの仮定は信じていない方なのですが、PubSubHubbubのハブネットワークはSmall-Worldの仮定が当てはまるかも)。ところでPubSubHubbubを知ったときはクラウドコンピューティングのサービス向きだなと思ったのですが、オリジナルの実装からGoogle App Engine上で実現されていたようです。

個人的にはクラウドコンピューティング上のサービスのイメージとして、クラウドコンピューティングという集中システムを使いながら、オーバーレイ的に分散システムを形成するものと予想しています。いまのところPubSubHubbubのハブのネットワークは当方のイメージに一番近いかも。そのイメージを文章ベースで説明するのが難しいのですが、Twitter的サービスやSNS的サービスも、クラウドコンピューティング上で実行されるアプリケーションのPeer-to-Peer的なネットワーク構造として構成されることになるのではないでしょうか。つまりクラウドコンピューティング上で実行される個々のアプリケーションは独立ですが、Peer-to-Peer的に協調するためのプロトコルを使って、全体としてひとつのまとまったサービスを提供するように形態になるのではないでしょうか(もちろんPeer-to-Peer的な対称性が必要とはかぎらないし、むしろ非対称性の方が重要かも)。例えばTwitterもSNSも一括管理するサービス提供主体は消失してしまって、その代わり個々の小さいアプリケーションが半構造的な集合体としてTwitter的なサービスやSNS的なサービスを提供するという感じ。某アニメ映画にあったハブ電脳という概念に近いかもね。

2009年8月19日

なんか忙しいですよね。それはさておきWebニュースに、Sun MicrosystemsがSSDとHDDのハイブリッド型のストレージユニットを発表したという記事がありました。ものすごく情報が少ないので、この記事でだけで判断はできないのですが、消費電力重視としては正しい方法かもしれません。やはりOSやアプリケーションに細工が必要になると思いますが、そのあたりの情報もほしいところ。それと同じ記事にDRAMをフラッシュメモリでバックアップする不揮発性メモリが出ていますが、これは揮発性メモリ(つまりDRAM)とMRAMなどの高速不揮発性メモリのあいだを埋める技術としても有望ですし、特にインメモリデータベースと組み合わせると新しい展開が出てきそうですね。なんだかんだいってもSun Microsystemsは北米の金融・証券向けシステムのストレージでは大きなシェアをもっていますからね。今回の発表もそれなりに根拠があるのでしょうね。結局、エンタープライズ向けシステムはトランザクション処理は避けられません。また、処理履歴を残すことが求められます。今後、情報システムがクラウドコンピューティングに向かうとしたら、クラウドコンピューティングが苦手な部分に特化した補完するシステムやそれを支える技術が重要になります。SSDとHDDの融合やDRAMとフラッシュメモリの融合は、クラウドコンピューティングの補完技術としてもおもしろいのですよね。

2009年8月18日

科学技術政策研究所の方から教えていただいたのですが、同研究所でIEEEの定期刊行物(論文誌や機関誌のこと。なお、論文集などは含まれない)における国別の論文数などの調査を行ったそうです。その報告書は非常に興味深い結果ですし、今後の電気・情報系の研究動向や予算配分に影響を与えるでしょう。

さてその結果ですが、日本はというと数自体は純増ながらほぼ横ばい。しかし、IEEEの定期刊行物が増加しており、掲載された論文数が増加していることから国別シェアでは半減状態だそうです。他の先進国系はというとシェアは落としているものの、論文数もそれなりに増えており、大きくシェアをおとしている国は少ないようです。逆に中国、韓国、台湾が掲載論文数もシェアも大きく伸びています。日本は論文数で中国に抜かれていますが、このペースだと、2,3年の内に論文数で韓国、台湾、英国、カナダに抜かれるでしょう。IEEEの定期刊行物への掲載論文数だけで評価できるわけではないのですが、やはり電機・情報系でいい研究というのはIEEEの論文誌や機関誌に掲載される可能が高く、それが増えていない、シェアが下がっているというのは日本の研究が低迷していることになります。

ここ10年間ぐらい国内の電気・情報系の研究は、他分野に比較して予算的に優遇を受けてきたわけですが、それに報いるだけの結果を出していないと非難されても仕方ないでしょう。当方を含めて電気・情報系の研究者はこの惨憺たる状況は真摯に受け止めるべきでしょうし、どうしたら打開できるのかも考えるべきですよね。このシェアの落ち込みの原因の一つは国内企業からの論文が減ったということもありますが、企業だけに責任を押しつけるのも無理があります。アカデミアサイドがこうした議論では「実績が上がらないのは予算不足が原因、だから予算増要求」という結論に行きがちなのですが、これまで電気・情報系の研究は予算的優遇をうけていたわけですから、予算を増やせば解決できるというものでもないような気がします。ちなみに当方はIEEEの定期刊行物のうちで今回の調査で分析対象となったものに掲載された単著または筆頭著者論文は4本なので多少の貢献でしょうか。

何度も言いますが、電機・情報系におけるプロの研究者ならばIEEEの論文誌や機関誌に掲載された論文がゼロというのはありえないし(まぁ情報系ならばACMの論文誌などはありなのでしょうが)、IEEEの論文誌や機関誌に論文実績がゼロという方はニセ研究者とまではいないものの、少なくても研究者を自称していいのかということになるでしょう。これをいうと多くの方から怒られるのですが、海外で通じる論文実績がなければ、海外からみて研究者としてみられないというのは事実ではないでしょうか。また、学生さんでこれから研究室を選べれる方は研究室の先生の論文実績をよく調べた方がいいと思います。学生さんの世代が研究者になる頃には国内ではなく海外に通じる論文実績になるでしょう。ただ、現実問題として海外で通じる研究者になれるか否かは指導教員が海外に通じる実績のある研究者か否かに大きく依存します。やっぱり鳶が鷹を生むことは難しいですからね。

2009年8月17日

ACMのマガジンQueueの最新号にGoogle File System (GFS)に関するインタービュー記事が出ています。GFSを理解していないとさっぱりわからない内容なのですが、クラウドコンピューティングに関心がある人ならば読んでおいてもいいかもね。簡単に要約すると当初GFSは、MapReduceを利用したWebページのインデクッシング処理に特化していたが、それ以外の応用が増えたためにGFSにそれに対応することになった。管理方式はシングルマスターノードだったが、ファイル数の増加やマスターノード故障時のリカバーに時間がかかることから、マルチマスターノード方式に変更したこと。チャンクサイズを64MBから1MBに変更したこと。一貫性に関してはまだ課題があることなどが書かれています。

なのですが、Googleのような企業の内部システムに関する論文では、書かれていないことを読む方がはるかに重要。例えばアプリケーションの種類が増えたことは書いてありますが、相異なアプリケーションをひとつのファイルのシステムで対応しているのか、アプリケーションに応じてチューニングを変えたファイルのシステムを用意しているのかはこの論文からはわからない。マルチマスターノードにした場合、マルチマスターノード毎に担当するノードをわけるはずなのですが、その分け方の説明もない。おそらくWindows AzureのようにP2Pと何らかのハッシング技術を組み合わしているのだと予想しますが、どうなのでしょうね(といってもAzureのようにノードを対等にしていることはなさそうですが)。それからチャンクサイズを64MBから1MB に変更したのはインタビューではアプリケーションの都合とありますが、実はSSDの格納する都合があったからという可能性もあります(というかSSDへの対応と考えた方が自然でしょう)。また、先述の一貫性と関わりますが、GFSのオリジナルの論文を読むとわかるようにGFSは読み出し性能に特化していて、書き込みは遅いファイルシステム。その特性はそのままなのでしょうか、改良をしているのでしょうか、などなど書かれていないことがたくさんありますね。

GoogleのシステムにおいてGFSは最下位層になるので、頻繁に改良を行っているとは思いにくいのですが、それでも要求に応じて変えているのでしょうね。クラウドコンピューティングの技術はGoogleやMicrosoft、Amazonがもつ巨大データセンターに特化した技術が多く、そうした巨大データセンターを扱えない研究者や技術者には手が出せない世界になっています。ただ、それ以上にGoogle、Microsoft、Amazon以外の研究者に厳しいのは、多数ユーザにアプリケーションを提供する立場でないと、本当の技術要求はわからないという現実。例えば上述のインタビュー記事で、アプリケーションの種類が増えたのでファイルシステムへの変更が必要になったといわれても、Gmailがどのようにして各ユーザのメールを管理しているのかもわからないと、どんな技術要求がでてきて、どのように改良したのかがわからない。今後、アーキテクチャ設計上の最優先事項が、エネルギー効率というか、電気代削減になってしまうと、汎用なアーキテクチャではなく、特定のアプリケーションに特化して、そのアプリケーションを実行するうえでエネルギー効率が最善になるようになり、アーキテクチャーが専用化してくることが予想されます。そうなるとアプリケーションを持たない研究者や技術者は手を出せなくなります。もちろん、論文は書けても、実際的な研究開発は難しい。やはり論文の場合、実用性は別にして、根拠のあるアイデアで、それを実証する評価データがあればメジャーな国際会議や論文誌でも通りますからね。だからその研究に実用性があるかは別問題になります。なんか暗い話になってしまいましたが、でも現実なのですよね。

2009年8月16日

Twitterのシステム上のトラブルが問題になっていますが、Twitterは昔から信頼性がないというのか、昔の方が頻繁に落ちていたような気がしますがね(去年の冬あたりはボロボロだったような・・)。もちろん昔といっても2年弱前ですが。というわけで最近、話題になることが不思議だったり、まぁ話題になるというはユーザが多くなったということの裏返しかもしれませんが。ただ、Webサービスはシステム的に問題があるとユーザが離れるのですが、Twitterは強いですよね。ただ、今回のトラブルを報道しているニュース系メディアやブログ系メディアも、Twitterの信頼性問題を指摘するものはあっても、ユーザが離れない理由を議論するものは少ないし、その理由を議論しているものも、Twitterの独特のユルさが幸いしているみたいな思考停止的な結論になっています。まぁ確かにその通りかもしれませんが、もうすこしその理由は考えた方がいいかもしれません。

理由その一は、ネットサービスはある程度、ユーザ数をかかえるとユーザの移行はおきにくくなる。これはコミュニティ型ネットサービスの場合は顕著になりそう。実際、Twitterもどきはいくつかありましあが、信頼性向上をうたったTwitterもどきはあまり聞いたことがない。理由その二は、無償サービスだからという諦め。所詮は無償サービスですから、365日24時間稼働を求める方が間違っているということなのでしょうね。

理由その三は、Twitterはカジュアルなコミュニケーション用途なのでビジネス用途のせービスのような信頼要求がない。Twitterの英語的意味は鳥のさえずりとか、(人間の)おしゃべりの声なので、演奏中に音符を一つ外してもプロ以外は気がつかないのと同じで、全体として曲の流れがよければいいということかも。

理由その四は、ユーザ側がTwitterに対する信頼要求が明確になっていない。当方がTwitterを初めて使ったときの思ったのは現実世界には同等メディアがないなぁ、というものでした。例えばメールであれば現実世界の郵便の電子版という位置づけですし、ブログも既存メディアのエッセイや日記の電子版といえました。でもTwitterはそれに相当するものが現実世界にないのです。ユーザは、例えばメールならば郵便の信頼性を暗黙的に引きずるのですが、Twitterは現実世界に類似したメディアがないので、どんな信頼性を要求していいのかもわからないのかもしれません。

いずれも仮説ですが、誰か検証してください。研究ネタとしてはおもしろいのではないでしょうか。信頼性をあげるための技術は重要ですが、その一方で信頼性がなくて使われるサービスの研究もおもしろい課題です。

ちなみに当方がTwitterを使ってみたのは、コミュニケーションをしたいとか、独り言を書きたいとかではなく、センサーネットワークのデータ置き場に使おうとしたからでした。つまりセンサーのはき出すデータをひとまずTwitterにおいておいて、それをTwitterから監視しようということでした。Twitterは時系列毎におけるポストした時間が残るので。もちろんウケ狙いの研究としてはよかったのでしょうが、別にウケ狙いをする立場でもないし(あとでわかったのですが、他でやられていたようです)、その当時はTwitterは頻繁なポストに制限をしていたのか、連続したデータの書き込みに失敗することが多く、結局、Twitterを使いませんでした。まぁ、Twitterもこんな用途に使われたら過負荷になりますよね。それはともかくたまにはTwitterも使ってみますかね。

2009年8月15日

今日の日経朝刊の一面トップに自動車・電機のコスト削減計画がでていたのですが、調達コストや広告・販促費、物流費などの変動費のの削減レベルのメーカもありますが、これを機会に人員削減に踏み込むメーカもあります。近い将来、両者の差は広がるのでしょうね。

というのも、5,6年前に国内メーカの役員の方(その後は社長になられましたが)と話をすることがあり、そのときの会話を思い出しあのです。当時はIBMがオートノマスコンピューティングのビジョンを打ち出したのですが、数ヶ月遅れで、ほとんど国内メーカは、IBMのオートノマスコンピューティングとはそっくりビジョンを打ち出しました。まぁ、そのときの状況がいまのクラウドコンピューティングとそっくりというのもありますが、それはいずれに書くことにして、今日はその役員さんのお言葉。(その会社のオートノマスコンピューティングのビジョンがIBMの真似であることをカミングアウトした上で)「日本ではオートノマスコンピューティングは流行らない」と断言していました。その理由というのは、(IBM流のオートノマスコンピューティングは管理者を減らすこと目的だが)国内企業の経営者は、社員の数を減らすことよりも、雇用を維持することの方が優先するから、と言い切っていました。補足をすると日本では従業員解雇が難しいので、企業が新しいテクノロジーを導入して省力化しても従業員数を減らせるわけでもないし、省力化で余った人員のために新しい仕事を作るのも難しいということです。逆に言うと日本で流行るテクノロジーというのは要員数を減らすのではなく、新しい仕事を作るテクノロジーということになります。

結局、国内においてクラウドコンピューティングが普及するか否かは、クラウドコンピューティングによって需要がなくなった職種の方々に新しい仕事を作れるかにかかっているのかもしれません。クラウドコンピューティングの効果は情報システム費用を固定費から変動費に変えることなのですが、情報システムに関わる人件費が固定費のままでは効果はでませんね。現実問題として日本では解雇が難しい以上、既存システムの管理しかできない技術者に仕事を与えるために、既存システムを使い続けるというのは合理的な経営判断ともいえます。メインフレームを例にとると、日本は海外よりもメインフレームの需要が大きいといわれます。もちろんメインフレームの方が向いている処理はあるのですが、その一方でメインフレームしか扱えない管理者に仕事を作るためにメインフレームを使い続けているケースは少なくないように思います。経済成長中ならば新しい仕事は作れるでしょうが、その経済成長が止まっているとすると余った人員に仕事を用意するのはたいへんです。クラウドコンピューティングは要員を減らす以上に、新しい仕事が作れるかというちょっと疑問ですよね。

2009年8月14日

世間はお盆休みだそうですが、なんか忙しいですね。その割に仕事がはかどらないのですよね。ところで生産性本部の統計データ(2008年)では、日本の労働生産性は先進7カ国(G7)で最下位、OECD加盟30カ国中第20位。長いバカンスをとるラテン系のイタリアやスペインよりも低い、当然フランスより低い。要するに日本人は働いていないということです。贔屓目にいっても、個々には一生懸命に働いているつもりだけど、その働き方に無駄が多くて稼げていないか、そもそも稼ぎにつながらない仕事を一生懸命しているかのどちらかなのでしょう。先日も事務方から書類で記載漏れがあるので「○○○を書き加えてください」というお叱りをうけました(本当に３文字なのです)。記載漏れするのがいけないのはわかりますが、数文字の加筆内容まで決まっているのなら、それを電話で叱責するより、先方で修正した方が当方だけでなく先方にとっても効率的だと思います。これは極端な例なのですが、おそらく人件費を含めたトータルのコスト意識に欠如しているということが背景にあるのでしょうね。先の例でもそうですが、個々には自分が労働生産性が高いと思っているので、解決は難しそうです。

2009年8月13日

午前中はクラウドコンピューティングのヒアリング。最近はヒアリングや取材が多いですね。講演だと話せないこともヒアリングでは話せることもありますね。最近は使い分けることが多くなりましたね午後は大急ぎでACM系の国際会議のカメラレディ論文の仕上げ。先方から問い合わせがあるまで、投稿したことも、採択されたことも、締め切りもすっかり忘れておりました。

ところで慌てて論文を仕上げながら考えることではないのですが、国際会議とか論文誌とかいったいなんでしょうね。アカデミアで生きていくには、国際会議や論文誌での論文実績が必要となります。というのは大学や研究所が研究者を評価するときは論文(の数)が重視されるから。ただ、国際会議や論文誌で発表した論文というのは、専門性により細分化された小さなコミュニティで評価されるのですが、この結果、論文を通すためにコミュニティにウケる問題設定、ウケる表現方法になりやすくなります。それ自体が間違ったことではないかもしれませんが、本来は他のコミュニティにも有用な研究に関する論文でも、あるコミュニティにあった表現になってしまい、結果として他のコミュニティには理解されないということになります。行動経済学的にいうところのフレーム、つまり研究がコミュニティにあわせてフレーム化されてしまう危険性が伴います。

前述のように学会というコミュニティは専門性とともに細分化される傾向があり、例えば国内のコンピュータサイエンス系学会を例に取ると、かなり昔に電気学会から某通信会社の研究者が中心になって今の電子情報通信学会が作られ、その電子情報通信学会のなかの情報系の研究者が中心になって情報処理学会が作られ、その情報処理学会からは人工知能学会やヒューマンインターフェース学会などが作られました。さらにその各学会も専門性に応じて研究会という小さなコミュニティに分割されています。その結果、何が起きるのかというと、例えば、ある研究会で発表した論文を別の同じ学会の別の研究会で発表しても理解されない。複数の研究会で同じ研究テーマを扱っていてもそれに気づかないという自体になります。つまり、研究の表現方法や問題設定がいつのまにかコミュティ依存になってしまって、他のコミュニティには理解されないことになります。

個人的にはこうした状況をさけるために、なるべく違うコミュニティにも論文を書いたり、講演させていただくようにしています。今回の論文でもACM 系なので所詮はコンピュータサイエンスの国際会議なのですが、いつもとは違うコミュニティ向けに書いています。研究はバックグラウンドを共有していないと議論ができないのは事実なのですが、得られるコメントも想定範囲内になりますよね。

2009年8月12日

VMWareがSpringSourceを買収するそうですね。VMWareはともかく、SpringSourceはわかる人しかわからない会社かもしれませんが。サーバはVMWareの製品に代表されるように仮想マシン上で実行することが多くなりましたが、サーバの追加や置換ではクローリングを使うことが多く、このときミドルウェアの設定管理もクローリングを前提することになりつつあり、ミドルウェアも仮想化を想定して、設定などができるようにしておく必要があります。また、Webサービスにおけるサーバの負荷分散という見地から見ると、実際に負荷の原因はSpringSourceのSpringに代表されるWebアプリエーションフレームワークですから、そのWebアプリエーションフレームワークは仮想マシンと統一的に設定・管理するのは妥当いえます。

ただ、今回の買収が注目すべきなのは、ここ半年間ほどJava ベースのミドルウェアまわりの焦臭い動向がひとつにつながったということかも。Grailsは10月に公開予定のver.1.2でデフォルトのServletコンテナをJettyからApatch Tomcatに変更する予定なのですが、それで噂されたのが、SpringSourceはGrailsでも主導的な立場にあって、そしてTomcatも事実上SpringSourceが主導している状態なので、GrailsのJettyからTomcatへの変更はGrailsよりもSpringSourceの意図があるのではないかということでした。これはJ2EEの将来に関わるので、J2EE関係者にとっても今回の買収は関心事でしょうね。ただ、当方はJ2EEはよくわかっていません(昔、書籍の一章を書いたような気もしますが)。というかわかりたくない。EJB3で簡単になったとはいえ、それでも当方から見ると複雑怪奇。近づかないのに越したことはない。

この騒動と並行して起きたのが、Google App Engineは当初、Apatch Tomcatを使うという話でしたが、土壇場でJettyへの変更。当方もGoogle App Engineのベータ版が公開されたときにTomcatなのか、Jettyなのかを調べました。こちらはGoogle様のご意向次第とはいえ、急な変更だったこともあり、こちらも様々な憶測を呼びました。その憶測の一つは、Jettyはプラグインアーキテクチャなので、Google WaveはJettyを使っているとか、GoogleはHTML 5のWebSocketやBWTPのリファレンス実装もJettyだとかなどなど。もう本当か嘘かもさっぱりわからない状況。ただ、ここからは当方の邪推レベルの想像ですが、SpringSource はともかく、VMWareまでバックにいるとしたら、GoogleはTomcatを避けたというのは当然かもね。それに最近のVMWareはCiscoやEMCの陰もちらつくし。もちろん、かなりの邪推ですがね。

そんな想像レベルの議論はともかく、ここ数年、Java系ミドルウェアはいわゆるアプリケーションサーバの開発プロジェクトに取り込められるという動きが多くありましたが、今回の買収が新たな再編の火種になるかは興味があるところですね。ここで最近、ミドルウェアまわりで動きを見せないのはOracleとIBMですよね。Oracleは以前買収したBEAに加えて、Javaの大元であるSun Microsystemsまで買収したわけですし、IBMも同社のミドルウェアのラインナップはすごいものがあります。両者もミドルウェア再編に参戦してきますかね。

それと今回の買収が注目されるのはクラウドコンピューティング、特にPaaSへの影響でしょうか。PaaSでは、ユーザ側プログラムに提供されるのは、プログラムの実行機械またはインタープリターとミドルウェア。そのプログラムによって実現されるサービスの提供方法がWebベース。ならばSpringSourceのSpringをはじめとするWebアプリケーションフレームワークは主戦場になるのは当然です。PaaSを手がけるGoogle、Microsoft、Force.comのうち、Force.comとMicrosoftは独自路線ですが、Googleは、Amazon EC2上や(いわゆる)プライベートクラウド上でPaaSを提供する仕掛けを作っているサードパーティ勢との争いが激しくなりそうです。もちろん、現行Amazon EC2はVMWareではなく、Xenをつかっているわけですが、次世代Amazon EC2の動向を含めて興味あるところです。まぁ、この辺はまたいずれ。もちろん書けることと書けないことがありますが。

なお、個人的に今回の買収で驚いたのは、コアテクノロジーの移り変わりでしょうか。かつてJavaベースのミドルウェアの大手JBossはRedHatに買収されました。このときはOSとミドルウェアを融合がうたわれましたが、今回の買収は、もうOSが主導権をとる時代ではなく、仮想マシンがコアテクノロジーになっていることを示しているのかもしれません。ただ、PC用の仮想化技術もここ1,2年で、20年以上先行していたメインフレーム用仮想化技術の多くを吸収しきった状態。これからは独自に発展しないといけないのですが、メインフレーム用仮想化技術が管理機能を除くと、大きな進歩がなかったように、PC用の仮想化技術も次の一歩はたいへんでしょう。VMWareは今後、分散システムのエミュレーションに向かうでしょうが、単体コンピュータの仮想化についてはある種の引き詰まり感があるのかもしれませんね。

2009年8月11日

昨日の続きですが、Googleのデータセンターは既存データセンターと違いすぎて非常識という意見を聞きますが、PCクラスタの構築と運用の両方の経験があると結構、常識的にみえてきます。ちなみに昨日書いたノートPCでPCクラスタを組んだ当時、当方は現勤務先に移ったばかりの頃だったのですが、設立経緯からしてなかなか複雑な組織でして、マシンルームは空いているのに、新参者にはマシンルームにサーバをおかしてもらえないませんでした。仕方ないので自分のオフィスにPCクラスタを置くことにしたのですが、そのオフィスの電源供給はというと、同じフロアーの10室あわせても一般家庭の電源供給程度しかなく、普通のPCクラスタをおけなかったのです(もう時効だと思いますが、前勤務先で使っていた普通の10台構成のPCクラスタを持ち込んで動かしたら、フロアーのブレーカーを落としてしまったこともあったり・・・)。

そこで苦肉の策で思いついたのが、消費電力＆発熱が少ないノートPCでクラスタを組むことでした。実はそれでも供給電力が足りなくて、クランプ型電流計をつないでコンピュータにどんな動作をさせるとどのぐらい消費電力になるのかを徹底的に調べ上げたのですが、最後に行き着いたのではスリープとレジュームを駆使するという方法でした。つまり昼間はスリープさせておいて、人が少なくなる夜間だけで運用したのです。素人目からみるとスリープよりは電源を切った方がいいのにという話になりますまが、ブート＆シャットダウンの繰り返しはトラブルの原因になりますし、ブート時の消費電力の瞬間的増加がネックとなるのです。さて当方のクラスタはともかく、どんな技術にもいえることだと思いますが、一部の技術条件が制限された環境にいると逆に見えてくることもあります。Googleのデータセンターがスリープ＆レジュームさせているとは限りませんが、仮に10Aの電源供給で30台のPCクラスタを動かそうことを考えてみれば、Googleのデータセンターのアーキテクチャーの設計思想や意図が見えてくれるはずです。

逆にそうした経験がないと、クラウドコンピューティングのアーキテクチャーをみても常識的なことが非常識にみえるのかもしれません。その意味では研究者でも予算、電源、施設、人員に恵まれている方々にはクラウドコンピューティングのアーキテクチャーはわからないかもしれません。というのはGoogleのアーキテクチャーは電気代や運用費を含めてコストをぎりぎりにケチっていますからね。例えばグリッドコンピューティングを含むHPCはコスト度外視で瞬間的でもいいので最善性能を追い求める世界ですが、クラウドコンピューティングは、コスト重視で定常運用が要求さえる世界。実際、HPCの場合、チャンピオンデータ、例えばLinpackを何度も計算させて、一番速く計算が終えたときの計算時間だけを持ち出して、その計算時間で性能評価やランキング上位を求めることになります。両者はどちらも膨大なサーバから構築されているので似ているように見えますが、両者の運用方法やコストモデルはまったく違います。実際、クラウドコンピューティングが、グリッドコンピューティングを含むHPCとは別の流れから登場してきたわけですが、それは至極当然といえるでしょう。

いずれにしてもクラウドコンピューティングは、技術開発だけでなく、運用が重視される世界。各社のクラウドコンピューティングのアーキテクチャを評論家的に議論するのは簡単でしょうが、最後は経験がものをいうことになります。例えば、PCクラスタの構築と運用の両方の経験がないと、クラウドコンピューティングのアーキテクチャーを表面的には理解できても、本質的には理解できないでしょう。そこまで言い切ることはないのですが、それはあると思います。ただ、そうした経験も必要条件であって十分条件ではありません。小規模クラスタと巨大データセンターは別世界。クラウドコンピューティングの巨大データセンターを理解するには、やはり巨大データセンターの構築・運用経験が必須になるでしょう。実際、GoogleやMicrosoft、Amazonの巨大データセンターの構築では、一握りの技術者が、Google、Microsoft、Amazonを渡り歩いていますが、彼らは斬新な発想で新しいデータセンターを設計・構築すると別の会社に移るということを繰り返しています。逆に言えば彼らがいまどの企業にいるかをウオッチすれば動向がわかるという感じ。その意味ではクラウドコンピューティングの巨大データセンターについて語れるのは、そうした技術者だけかもしれません。

残念ながら国内にそうした技術者はいないでしょう。最近、クラウドコンピューティング向けに国産の巨大データセンターに構築の話が出ていますが、仮に巨大データセンターを構築するならば、GoogleやMicrosoft、Amazonを渡り歩いている技術者を引き抜いて、彼らに設計を頼む以外に、先端のデータセンターは構築できないのではないでしょう。何度も言いますが、クラウドコンピューティングは経験やノウハウが重視される世界。そうした経験やノウハウもなしに、巨大データセンターを構築したって、非効率でコストに見合わないデータセンターができるだけです。ただ、先行しているGoogleやMicrosoft、Amazonに追いつくのには何年もかかりますし、その間に彼らはもっと先にいっているでしょう。むしろ頭を切り換えて、巨大データセンターの上で動くサービスに特化した方がいいように思います。

2009年8月10日

このページを以前からお読みの方はご存知だとは思いますが、2001年頃にPC Cluster on Chair (PCCC)と勝手な名称をつけて、イスの上にノートPCを並べてクラスタを作っていました。なんでこんな古い話を持ち出すのかというと、実はGoogleのデータセンターはこのノートPCクラスタと近いのかもしれないのです。それも、偶然ではなく、ある制約を考えると類似したアーキテクチャになるはずなのです。

実は4月初旬にGoogleのサーバが公開されたときに、各サーバにバッテリが積んであるのをみて、最初に思ったのはバッテリはUPS用ではなく、スリープ用かもしれないということでした。スリープがいいのはサーバが暇になったら電源を落とさずに眠らせておけばいい(頻繁なリブートは故障のもと)。当方もこのノートPCクラスタは(自前の)管理ソフトウェアからスリープとレジュームを制御しておりました。当方の場合は後述するように事情から、夜、人が減ってからレジュームして、朝、出勤するとログを集めるとスリープさせていたからでした。もちろんGoogleがどんな運用しているかは知りませんが、電気代が夜間割引料金のときだけ運用して、昼間はスリープで止めている可能性はあります。

ただ、計算中のサーバをスリープさせて、レジュームしたときにその計算を再開するのは単独のサーバならば簡単でも、複数のサーバが絡むと至難の業です。というのもサーバ同士で通信やデータ共有していますし、さらにスリープやレジュームというのは結構不安定で失敗することも多いのです。このため、協調動作中の複数サーバをまとめてスリープとレジュームするには、スリープ前に複数サーバの計算処理過程のスナップショットを取っておくという前処理と、レジューム後にそのスナップショットを戻すという後処理が必要です。またレジュームとスリープが完了しているかを確認しながら進める必要があります。ということもあって。もう7年ぐらい前のことですが、当方はクラスタのスリープとレジュームのためのミドルウェアを作り始めたのですが、あまりにも複雑で途中でさじを投げてしまいました。もちろん今にしても見るともったいなかったと思うこともありますが、ただ、そのシステム要件が何かと難しい処理だという知見を得られたので価値のある経験でした。(理学的とちがって)工学的には、うまくいく方法を発見することも重要ですが、うまくいかない方法を知っていることの方も重要ですからね。

さて、仮にGoogleがサーバをノートPCのように運用している、つまりバッテリをスリープ用の電源供給につかっている場合を考えてみましょう(何度も書きますが、Googleの実際の運用は当方は知りません。あくまでも仮定のうえでの議論)。当方の経験でいうと、Googleといえども計算途中ではサーバをスリープはさせていないと思います。もちろん、かなり粗い粒度でスナップショットをとっている可能性はありますが、スナップショットの処理のオーバーヘッドを考えると、計算中のスリープはやらずに済むのならばやらない方がいい。それにGoogleがサーバがMapReduce 専用機ならば、稼働時間内にあわせてタスクをサーバに分割・割当できます。つまり、スリープさせる前にタスクの処理を終えて、結果を集めることができるはず。つまり計算途中ではなく、終了後にスリープするように運用できます。また、稼働時間に間に合うのであれば、個々のサーバの温度が上がったときに、そのサーバだけをスリープさせて、温度が下がってから再開することもできますし、スリープさせたサーバに割りあてたタスクを再分割して、計算が終わった複数台のサーバに振り分けることもできるでしょう。MapReduceのいいところが、タスクの分割とサーバへの割当をしてしまえば、タスクが終わって各サーバから結果を集めるまではサーバ同士は独立なので、一部のサーバを止めても支障がないところですからね。実際、MapReduceの主たるアプリケーションであるWeb検索用のインデクシングはリアルタイム性は要求されないので、更新の少ないWebページが対象ならば、インデクシング処理を夜間だけまわしても問題は起きないはず。

クラウドコンピューティングというとPUEに注目が集まります。どこどこのデータセンターが公開したPUE値の小数点以下の大小で大騒ぎ。でも当事者であるインフラ事業者にとってPUEなんてどうでもいいはず。彼らが関心があるのは電気代(ちなみに当方はこのページでも取材でもPUE値と電気代を使い分けて説明しているつもりです)。当たり前ですが、直接コストになるのは電気代です。PUE値がどんなに低くても、もとの電気代が高ければコストは高くつきます。逆にいえば電気代が安く済むのであればなんだってします。例えば気温があがる日中はデータセンターごと止めてもいいし、そこまでいかなくても電気代の夜間割引のあいだに氷を作って、昼間はその氷でコンピュータを冷却してもいい。そしていまのコンピュータは負荷が高くても低くても実は消費電力にほとんど影響しません。逆にいえば電気代を減らすにはスリープを含めてコンピュータを止めるしかない。ただ、こうしたことは経験なのですよね。だから、自分で経験してみないとわからないし、経験がない方にどんなに説明してもわかってもらえるとは限らない。正直いってクラウドコンピューティングは経験がないとわからないことが多いですね。

2009年8月9日

クラウドコンピューティングは計算資源のオフショアなのですが、クラウドコンピューティングで人のオフショアはどうなるのでしょうかね。どうも最近は取材や問い合わせドリブンで考えることが多く、これもその一つなのですが、このお題は考えてみるべきことかもしれませんね。クラウドコンピューティングはソフトウェアではなく、サービスの提供インフラです。そうなるとオフショアをするにしても、サービスを実現するソフトウェアの開発だけを外注に出して、サービスを提供は自社でするのか、サービスの提供も外注に出すかが考えられます。一方でソフトウェアは開発して納品という流れでしたが、サービスの場合、日々改良ということになるでしょう。そうなるとサービスの開発は現場に近くないといけないので、クラウドコンピューティングの時代はソフトウェア開発の外注ではなく、サービス提供の代行に主流になるかもしれません。そうなると２つの動きが出てくるでしょう。

一つ目の動きはユーザ開発の増加でしょう。日々の改良が重視されるのであれば、サービスの改良は現場に近い方が有利なわけで、クラウドコンピューティングになるとユーザ企業におけるソフトウェア開発・改良は現在よりも増えるでしょう。個人的には国内のSI企業にお勤めの方は、開発対象の顧客企業に移られる方が多いと予想しています。なお、社内でサービス運用を行うわけですが、サーバ類はクラウドコンピューティングのインフラに任せるでしょうから、純粋にサービスを開発・改良をする技術者には需要はあっても、インフラ運用の技術者に需要は少ないかもしれません。この場合、クラウドコンピューティングではインフラだけは豊富になりますから、便利なサービスは他者にも提供するだけの計算資源が確保できるようになり、自社用サービスが国内外に提供できる場合はありえますよね。というか社外提供するぐらいでないといけない時代になるかもしれませんね。

二つ目の動きはオフショアによってサービスの開発だけでなく、提供も外注する方法。クラウドコンピューティングではインフラは世界のどこにあってもいいので、外注先はインフラの設置場所ではなく、サービスの開発や運用をする技術者が多い場所になるでしょう。ソフトウェア開発では中国やインドに外注することが多いのですが、こうした国々に開発者が多いのであれば運用の委託もこうした国々に外注されることになるでしょう。もちろん、現状は中国やインドには開発者の供給はあっても、運用技術者の供給は少ないのですが、時間の問題ではないでしょうか。さてこの場合ですが、サービスの開発や改良する技術者はオフシェア先の海外の国々にいますし、運用も海外の技術者任せ。そうなるとせいぜいサービスの日本語化担当の技術者が必要なぐらいで、日本国内には技術者の需要はなくなるかもしれません。なかなか恐ろしい状況ですが、将来、可能性がないとはいえないと思います。

どちらの動きが主流になるかはサービスの汎用性の問題に帰着するのでしょう。ソフトウェアは、例えばMicrosoft Officeがいい例なのですが、言語依存部分を除くと世界統一仕様ですが、そのソフトウェアの運用によって企業の業務や各国の文化・習慣に合わせることができました。しかし、クラウドコンピューティングの提供対象であるサービスは業務そのものです。その結果、ソフトウェアと違ってサービスを企業や国のやり方に合わせるのは難しくなります。そうなると道は二つで、企業や国のやり方を世界的に標準化されたサービスに合わせるのか、サービスを企業や国のやり方に合わせるのかのどちらかです。前者の場合はグローバル化がいっそう進むでしょう。後者の場合はいわゆるガラパゴス化が進むでしょう。ただ、サービス化という点ではPC系よりも携帯電話の方が先に進んでいる部分があると思いますが、その携帯電話はユーザ行動や文化への依存性が高いために、世界的に広がった携帯電話用サービスは皆無な状態。これを考えるとクラウドコンピューティング上のサービスは意外にガラパゴス化するというのか、多様なサービスの中でユーザや企業がそれぞれにあったサービスを選んで使うという状況を予想しています。ただ、その一方で一番最悪の展開も考えておかないといけないのですが、それは日本は企業も個人も独自慣習に拘るあまりガラパゴス化が進んでしまい、一方は他の国々は標準的なサービスを駆使したグローバル化が進んでしまって、日本はいままで以上に孤立化する場合でしょうね。もちろん、10年先もいままで通りにやっていけると思っている方には当方は取り越し苦労と思われるのでしょうね。

ところで、前述のように立場上、クラウドコンピューティング関連の取材や問い合わせを受けることが多いのですが、いまだにクラウドコンピューティングのインフラに関心があるところと、インフラよりもそのインフラで動かすサービスに関心が移ったところがありますね。もちろん立ち位置というか、想定読者や広告主にもよると思いますが、メーカ系なのかユーザ企業が対象なのかによっても違ってくるのでしょうね。

2009年8月8日

某大学の大学院授業のレポート採点をして、成績表を送付。コンピュータサイエンスのなかでも理論的なことを扱う授業なのですが、履修者は情報系プロパーの学部を卒業された学生さんから、機械や生物などの非情報系の学部出身の学生さんまでいろいろ。トップレベルのレポートはさすがに情報系の学生さんのものですが、全体で見ると制御系や機械系の学生さんによるレポートの方がいいのですよね。実はこの傾向は毎年同じ。当方は大学院の授業の一コマをもっているだけなので、先方の情報系学科の教育に対して論評する立場ではないのですが、単年ではなく毎年の傾向となると部外者でも心配になりますね。

ところで成績表を送るために東京の中央郵便局に行こうとしたのですが、建て替えでなくなっていました。某省の前大臣ではないのですが、歴史的な建造物だったと思いますし、残してみてもよかったと思います。野村ビル(旧大和銀行ビル)など大手町は古いビルの外壁の一部だけ残して高層ビルに建て替えるのが流行っています。中央郵便局も外壁の一部を残すためでしょうか、壁一枚残っている感じでした。個人的には古いビルはなるべくそのままで残すか、思い切ってまったく新しく作り替えるかの方がいいように思ったりもしますがね。

2009年8月7日

今日は金沢にいるはずだったのですが、午前中は総務省。ただ、今回は概算要求が絡みではなく、内定している研究予算なので仕方ないです。ということで勤務先の事務の方ともども総務省にいくことになりました。午後は予定を入れていなかったのですが、たまっていた仕事などもあり、気がついてみると忙しい一日となってしまいまいた。それにしてどうしていろいろおきるのでしょうかね。

2009年8月6日

北陸先端科学技術大学院大学で暗号理論のワークショップで招待講演。ということで2年ぶりぐらいに石川県。暗号理論はまったくの素人ということをいいことに好き勝手をいったわけですが、暗号理論の研究の何か参加になれば幸いです。ワークショップでは研究発表もあったのですが、おもしろかったですね。当方はというと暗号理論はまったくの専門外なのですが、本当に参考になりました。お呼びいただいて感謝、感謝です。

ところで行動経済学や行動心理学に「フレーム」という概念があります。問題が表現される方法を、判断や選択にとっての「フレーム」と呼び、そのフレームが異なることによって異なる判断や選択が導かれることを「フレーミング効果」といいます。そして多くの画期的な研究や技術というのはフレームの中ではなく、フレーミング効果、つまり別のフレームに移行したときに生まれているといわれます。研究もひとつのフレームにとどまると、問題の捉え方がいつも同じになるので、既存研究に対する想定内の発展となってしまうし、当然、新しい応用も出てこない。どこかでフレーミング効果がひつようになります。もちろんフレーミング効果を偶然おきることがありますが、他分野の研究コミュニティで講演したり、先方の研究を聞いたりと、故意にフレーミング効果が起こす努力も必要ですね。

2009年8月5日

富士フィルムのコンパクトデジタルカメラにボケを生成してくれる製品があるそうです。普段、ボケを出すために明るい大口径レンズにして、絞り開放で撮ることをしているので、コンパクトデジタルカメラの小さくて暗いレンズでボケが出せるというのには興味津々。原理はフォーカスがあった写真の他に、フォーカスをわざとずらした写真を何枚か撮って、フォーカス以外の部分を見つけて、そこをデジタル的にボケさせるというもの。サンプル画像をみるかぎり、レンズによるボケと比べるとちょっと不自然なのですが、他社を含めて同様の機能は入ってくるでしょうし、そうなるとボケも自然になるでしょうし、特定のレンズのボケを再現するということもありそうですね。例えば球面Summilux-35mmやNoctilux-50mmのボケをエミュレートとかもあるかもしれませんね。楽器のシンセサイザーは往年のアナログシンセサイザーのエミュレーションするソフトウェアがある時代ですから、あり得なくはないかも。

2009年8月4日

今日もクラウドコンピューティング関連の取材でした。ということで続いていますが、クラウドコンピューティングのこと。Googleのデータセンターが話題になっています。運輸コンテナーに1000台単位のサーバをいれて、ひとつデータセンターだけでもそのコンテナーが何十台もあるようです。ただ、個人的にはちょっと？モード状態。というのは6月に「Datacenter as a Computer」という論文(というか本？)がでたので早速読んだのですが(5月の半ばに出たらしいのですが、ちょっと出遅れました)、常識を超えた考え方、そして巨大データセンターをひとつのコンピュータとして扱おうとしているGoogleの考え方がよくわかります。ただ、同時にGoogleのいうデータセンターと世間のデータセンターのあいだに大きなギャップがあることもわかる論文でした。

というのも当方も4月にGoogleのデータセンターに公式資料が出回ったときは素直に驚いたのですが、ただ、前述の論文を読むと確かにGoogleのデータセンターはひとつのコンピュータのように構成されていますが、サーバ構成も均質になっていますし、ネットワークの構成もMapReduceのように同じタスクをプロセッサに投げて、終わったら結果を集めるだけ、プロセッサが処理中に頻繁に通信することは少ないと考えているようです。その意味では巨大なSIMD型の並列計算機といった方がいいですし、それもMapReduceのための専用コンピュータとみるべきかもしれません。ここで疑問が出てくるのはPUE値との関係です。ご存知のようにGoogleのデータセンターのPUE値は常識では考えられないほど低いです。でも仮にMapReduce用の専用機として構成されているのであれば、PUE値は引くいのも納得ができるようになります。というのはコンピュータの歴史では消費電力という点では汎用コンピュータは専用コンピュータには勝てませんでした。なお、いくら仮想化技術を使うにしても、一般のクラウドコンピューティングにおいてユーザから依頼される処理には大小があるし、計算負荷もいろいろです。このため極限までコンピュータを使い回すことはできません。しかし、社内用途でタスクがわかっていればそれに応じて処理をプロセッサに割り当てればいいし、スケジューリングでもいろいろ工夫ができるので効率は上げられます。いずれにしてもクラウドコンピューティングが広がると、クラウドコンピューティング用のデータセンターでは様々な処理を実行しないといけませんが、その場合でもGoogleが同レベルのPUE値が維持できていればとてつもないことですが、そうでなければMapReduce用の専用機と思った方が良さそうです。いずれにしても巨大データセンターでも、特定処理に最適化されたデータセンターと、雑多な処理をする汎用データセンターはわけて考えるべきなのでしょう。

ただ、日本はというとそれ以前の状態。コンピュータメーカや霞ヶ関方面で、国産クラウドコンピューティング用データセンターの構想が検討されています。国産クラウドコンピューティングインフラだからといって、国内だけでなく、ひろく海外に提供されないといけないし、一国ごとに巨大データセンターを設置する必要性も義理もありません。どうしても国産クラウドコンピューティングインフラを作りたいのであれば、国内だけでなく、海外からの利用を考えるべきだし、価格と可用性の両面で、海外のインフラ、例えばGoogleやAmazon、Microsoftより有利でないといけません。それができないのならば海外データセンターを使えばいいわけで、むしろ海外のデータセンターを安価かつ都合良く使うために、例えば海外のデータセンター上のデータに関する法的保護を進めてくれた方がいいです。

個人的に国産クラウドコンピューティングで一番危惧しているのは、価格競争力のない国産巨大データセンターを構築してしまって、その構築費が無駄になることよりも(もちろんこれも深刻な問題ですが)、ユーザ企業の競争力を奪う事態です。つまり、データセンターの利用率を上げるために企業などに半ば強制的に高い料金のデータセンターを使わせることになった場合です。その企業は海外企業に比べてデータセンターの利用料がかさむわけですから、その企業の競争力が奪われます。というのも一連の国産クラウドコンピューティング構想の動きをみていると、どうしても過去の失敗、国産技術を国内企業(携帯電話のPDCなど)に強要したことが、国産技術だけでなく、国内企業の海外競争力を奪った歴史を思い出してしまうのです。国産クラウドコンピューティング構想が国内IT企業とそのユーザ企業の競争力を奪わないことを祈っています。

前述のGoogleの論文ですが、いろいろけなしましたが、情報系の仕事をしているのならば読まれるべきですし、少なくても第一章だけでも読んだ方が絶対にいいです。価値観が変われると思います。

2009年8月3日

最近はメディアからの問い合わせが多いのですが、今回はSI不況に関するもの。アカデミアサイドの当方が答えるべきことではないので、丁重にお断り。でもSI業者さんは人月制単価、派遣業化、多重下請け構造など問題が多すぎですよね。さて問い合わせとはまったく別にクラウドコンピューティングになるとSI業界の問題がどうなるかを考えてみました。以下はその個人的なメモです。

SaaSという言葉あるように、クラウドコンピューティングではソフトウェアは開発・納品されるものではなく、サービスとして提供される、つまりクラウドコンピューティング上でソフトウェアを実行することになります。これは大きな変化をもたらします。サービスを提供・運用することが目的であって、ソフトウェアそのものは納品物ではないのですから、ソフトウェアのコード量は意味をなしません。運用を含めた機能要求が価格基準になっていくでしょう。また、クラウドコンピューティング上のサービスはWeb上のサービスと同じ。運用しながら改良していくものになりますから、最初の開発費よりも、日々のサービスの改良＆提供で稼ぐビジネスに変わることになります。その結果、クラウドコンピューティングのサービスではソフトウェア開発を前提にした見積基準、つまり人月制単価は整合しなくなってくるでしょうね。

派遣業化ですが、これもクラウドコンピューティングになるとちょっと改善するかもしれませんね(というか改善すると祈りたい)。なぜかというとそもそもソフトウェア開発で派遣開発者さんを集めないといけないのは日本の雇用制度の関係で解雇が難しい。しかし、大規模なソフトウェア開発ではたくさんの開発者が必要なります。でも大規模な開発はそうそうあるわけでないし、ひとつの大規模開発中でも必要な人員数はかなり変動します。そうすると必要となる開発者数と社員開発者数のギャップを埋める手段として派遣開発者が必要でした(もちろんそれ以外の理由もあるわけですが)。ただ、クラウドコンピューティングになって、サービスの提供では先述のように日々改良ですから、ある程度の人員数が長期にわたって必要となります。長期に仕事があるならば社員開発者の数を増やすでしょうから、派遣開発者への依存度は減ると思います。

多重下請けの問題ですが、これもクラウドコンピューティングになると多少は改善するかも(そう祈りたいということかもしれませんが)。なぜかというと、サービスの改良というのはユーザにフィードバックを汲み上げることが重要です。そのためにはN次下請けの企業に改良を委託するよりは、ユーザに近い側の開発者が改良した方がいいことになります。実際、Web上のサービス提供会社は社内で改良していることが多く、外注がゼロではないにしても、一般のソフトウェア開発よりも外注比率が低いのではないでしょうか。

かなり無理して希望的に書いたところはありますが、クラウドコンピューティングはSI企業はともかく、開発者にとってはそうそう悪いことだけではないと思います。それと先述は別の取材に来られた記者さんに上記の一部を話したときにも指摘されたのですが、上記の３つからいえることは結局、SI業界の開発者の方々はSI会社にいるよりも、ユーザ企業に移った方がいいことになってしまいますね。実際、クラウドコンピューティングになるとユーザが開発することが増えるでしょうから、ユーザ企業に移る方は少なくないでしょう。

2009年8月2日

クラウドコンピューティングがイノベーションとなるならPaaSでしょう。ということ以前に書いたのですが、PaaSの場合、ハードウェアはもちろんのこと、OSやミドルウェアの準備もいりませんから、プログラムを書いて、アップロード＆実行すれば、サービスを開始できます。このため、(SaaSやIaaS/HaaSに対して) PaaSによるメリットとしてサービス開発・提供の速さがよく指摘されます。それはその通りだとは思いますが、それ以外にエンドユーザプログラミングに向いているのも大きなメリットのように思います。というのも職業プログラマーはすでに開発・実行環境を持っていることが多く、PaaSを使ったからといって生産性が上がるわけではない。逆に職業プログラマーにとってはなんでもないこともエンドユーザにとっては簡単ではありません。

エンドユーザにも、WebページにおけるJavaScriptやExcelのマクロなどちょっとしたプログラミングができる人は結構います。むしろ現場を知っているだけに強い。ただ、こうした方々がハードウェアやOS、ミドルウェアを用意して、さらにセキュリティパッチまで当てながら運用するのは負担が大きいのですが、PaaSになるとそうした負担が解消されるので、エンドユーザの中にはプログラミング・サービス提供する人が、決して多くはないものの出てくるでしょうし、クラウドコンピューティングではそうした方が開発したサービスは作成者だけではなく、他者が使うことができるようになります。

ただ、残念ながら既存のPaaSは職業プログラマー向けに作られてしまっています。Google App Engine上でJavaのプログラムを書こうとしたら、Eclipseという統合開発環境をインストールしておかないと辛いのですが、エンドユーザが、ちょっとしたプログラムを作るのにわざわざEclipseをインストールするかというとは大げさすぎますし、Eclipseは職業プログラマー向けです。その意味ではForce.comはオンラインベースの開発環境を用意していますが、ちょっとしたカスタマイズレベルが限度で、本格的にプログラムと思ったら、結局、Eclipseのプラグインをインストールする必要が出てきてしまいます。

そう考えるとPaaSがブレークするには、Webブラウザで動くエンドユーザ向けプログラム開発環境が必要なのかもしれません。Webブラウザ上の開発環境ではあれば、プログラミングのために何も用意する必要がないわけで、あとはどれだけ簡単にプログラミングができます。もちろんWebブラウザ上の開発環境はできることが限られるかもしれませんが(将来も職業プログラマーもWebブラウザ上の開発環境を使うことになると思いますが)、エンドユーザが本格的な業務アプリケーションを書くことはなく、むしろ多くの場合はちょっとしたWidgetのような小さいプログラムや、既存の複数サービスの連携させるプログラムでしょうから、そうしたプログラムならばWebブラウザで動くエンドユーザ向けプログラム開発環境でも対応できるでしょう。

何をいいたいのかというと、PaaSのメリットを最大限に享受できるのは、職業プログラマーよりもエンドユーザプログラマーかもしれないのに、既存のPaaS向けの開発環境は職業プログラマー向けなので、せっかくのPaaSのメリットがいかして切れないていないということです。PaaSというお手軽なプログラム実行環境＋Webベースのプログラム開発環境の組み合わせという視点は重要なように思います。ちなみに個人的には、仮にPaaSがイノベーションになるとしたら、そのイノベーションを起こすのは職業プログラマーではなく、エンドユーザプログラマーだと予想しています。しかし、それを実現するにはエンドユーザプログラマー向けの開発環境が整えられることが前提のひとつになるでしょう。その意味では既存のPaaSプラットフォーム、例えばWindows Azureは(職業プログラマーによる)既存ソフトウェア開発との親和性を重視しているのは決していい戦略とはいえなくなりますし、Google App Engineは、Pythonに引き続いてJavaをサポートしましたが、Javaはエンドユーザ向けの言語とはいえない。むしろエンドユーザ向け言語、例えばJavaScriptやPHPをサポートした方がよかったかも。でもこう書くとJavaで実装されたJavaScriprt実行系やPHP実行系をJava版Google App Engineで動かせばいいとかいってくる人がいるのですが、そうした実行系をインストールできない人にこそPaaSは需要があるのではないでしょうか。

2009年8月1日

昨日のことなのですが、某メディアからクラウドコンピューティングの問い合わせ。ひとつめの質問はクラウドコンピューティングではRDBがないことによる影響について。いちおうIaaS/HaaSでは既存RDBシステムが動くことや、PaaS系では擬似的なRDBはあるけど、Join操作がないし、トランザクションの考え方が違うので、データ管理には工夫が必要などの教科書的な回答をしておいたのですが、この質問はクラウドコンピューティングの講演をすると、ほぼ必ず聞かれる定番中の定番の質問。ただ、個人的にはRDBがないことが致命的とは思っていなかったりします。もちろんRDBがないのは困るのですが、RDBが必須のアプリケーションを無理してクラウドコンピューティングで動かすこともないです。というのもクラウドコンピューティングを活かしたアプリケーションというのは、従来にはなかったようなアプリケーションになるだろうと思っているから。ちなみにそのメディアの二つ目の質問は、国内でもクラウドコンピューティングへの対応を表明するIT企業が多くなったが、どこが進んでいるかというもの。ここでその回答を書くわけにはいきませんが、そうしたIT企業がいうようにクラウドコンピューティングがITインフラのコスト削減につながるのならば、IT企業自身がクラウドコンピューティングに切り替えているはずで、クラウドコンピューティングの華々しい効果を謳いながら、社内でクラウドコンピューティングの活用事例がないような企業はいったい？ということになりますよね。でも国内IT企業の場合、時代はクラウドコンピューティングなどと威勢いいことをおっしゃいますが、社内活用事例を説明されるところは少ないですよね。

2009年7月31日

海外出張後は出張中に発生した諸々の仕事で忙しいのですが、今週は報道発表が急遽することになったので、その準備作業で忙殺された感じ。それにしてもしばらくは、いろいろ起きそうな予感。ともっていたら某省から招集。日本海側に出張だったのですが、早々に切り上げることになります。

それはさておき先週の出張の写真を順次、Webにおいていきます。第一弾はGrazです。Kunsthausは写真でみてもヘンテコな美術館です。それとその出張は全く関係ないのですが、最近、Amarfiという映画が上映されているそうですから、Amarfiの写真をここにおきました。ただ、映画のポスターを見る限り、Amarfiではなく、Positanoという街のようですね。というわけで旧作ですが、Positanoの写真も併せてご鑑賞ください。

2009年7月30日

今日は報道発表でした。今回は論文というよりは特許ベースですすめていた研究の実証実験に関するもの。共同研究していただける企業の方々からみるとどうなのかはわかりませんが、当方の勤務先における報道発表としては出席された記者の方も多かったようです。もちろん記事にしていただくか否かは各メディアの都合によりますがね。それにしても研究はその研究をすること自体が重要なのは当然ですが、研究のプレゼンスをあげるというか、その研究成果を社会に還元しないといけません。ただ、社会に還元するにはその研究をしていることを社会に伝えないといけません。これまでは論文としてまとめる以外にプレゼンスを出す方法はなかったのですが、論文が書くことだけが目的となり、読まれることが少なくなってしまった現状では、論文以外の方法を模索しないといけません。

2009年7月29日

今日、MicrosoftがWindows関連のセキュリティ警告(MS09-035)を出しましたが、これはやばい。本当にやばいです。何がやばいかというと、特定のソフトウェアではなく、いろんなソフトウェアでセキュリティ的不備があることになり、その修正は個々のソフトウェアで対応しないといけないのです。まだ実際的な問題が起きていないようですが、仮に起きたとすると相当数のユーザが危険にさらされることになるので、大騒動になりますし、修正作業は個々のソフトウェアごとになるので、かなりめんどうです。

別に当方が解説する義理はないのですが、ちょっとだけ解説。原因はMicrosoftが提供されているライブラリ(汎用的な処理の集まり)の脆弱性なのですが、そのライブラリを使っているActiveXとよばれるタイプのソフトウェア部品は、その脆弱性をかかえてしまう。それはMicrosoftが開発したものに限らず、サードパーティが開発したものもそのライブラリを使っている限りは脆弱性をもつ可能性があります。そして残念ながら、そのタイプのソフトウェア部品は結構使われています(例えばAdobeのFlashとか)、さらにどのソフトウェア部品がそのライブラリを使っているのか、つまり脆弱性をもっているかはわからない。おそらく相当数のWindowsユーザに可能性があることになります。具体的には悪意のある仕掛けが施されたWeb ページにIEなどでアクセスすると、その問題のあるソフトウェアが呼び出されて、悪意のあるプログラムやウイルスなどが実行される恐れがあります。

ちなみにMicrosoftが今回、公開したパッチはライブラリそのものの問題を修正しますが、すでにそのライブラリを取り込んで使ってしまっているソフトウェア部品の脆弱性は解決されません。結局、ソフトウェア部品ごとにアップデートまたはパッチ当てをしないといけません。多くのユーザが今回のパッチで解決したと思い込んでいるような気がします。Microsoftはもっと正確に危険性を説明すべきです。さらに問題は個々のソフトウェアに修正ができるかです。今回問題になったライブラリそのものの開発は古く、ソフトウェア開発会社にとってでも、どのソフトウェアに問題があるかをきちんと把握するのは難しいでしょう。せめてMicrosoftは開発者向けに修正作業方法などを公開すべきです。と思ったら修正方法に関するビデオが公開されました。Microsoftの方々が登場して、明るく解説していますが、大丈夫なのかなぁ。

2009年7月28日

日立製作所が2009年第1四半期の連結決算を発表したのですが、IT関連は売上高が前年同期比21％減の4716億円。内訳は、ソフトウェアの売上高が同7％減の353億円、サービスの売上高が同13％減の2026億円、ハードウェアの売上高は同28％減の2337億円だそうです。まぁこの会社特有の問題もあるのでしょうが、メーカ系SIや金融系に強いSIは似たようなものではないでしょうか。

ところで話を日立に戻しますが、同日に日立製作所は、日立ソフトウェアエンジニアリング(日立ソフト)、日立情報システムズ(日立情報)、日立システムアンドサービス(日立システム)を含む、関連会社5社の完全子会社化を発表したのですが、どうなのでしょうか。日立システムはともかく、日立ソフトと日立情報は日立製作所との独立色が強いのを持ち味となっていた会社。両社は日立製作所とは競合する企業の仕事を結構とっていますから、今回の完全子会社化によって、一部の既存顧客を失うことになりかねない。また、この３社は日立製作所の情報部門と業務が重なっているだけではなく、３社同士でも重なっていますから、重複部門を中心にリストラがありそう。日立製作所の現社長兼会長は過去に日立ソフト会長をしていたこともあり、この辺の事情はよくわかっているはずで、承知の上での決断なのでしょうが、損得の両方がありそう。また、IT業界はスピードが命。意志決定が速いとはいえない日立製作所に取り込まれると、たいへんそうです。それと社内が混乱していなければいいのですがね。

2009年7月27日

出張後は毎回忙しいのですが、今回はいろいろ重なって本当に忙しいです。このペースだと倒れてしまいそう。話は大きく変わって、リコーがコンパクトデジタルカメラのGR Digital IIIを発表。GR Digital IIを愛用しているので気になるところなのですが、外見は瓜二つ、目新しい変化はレンズの明るさがF2.4からF1.9になったぐらい。なんかね。当方の場合、GR Digital IIを大事に使うことになりそう。フィルム時代と同様、GRといえば35mm換算で28mm相当の単焦点レンズがウリですから(フィルムは21mm版もありますが)、新機能を増やす余地は少なかったのでしょうね。個人的にはGR Digitalの筐体で、シグマのDPシリーズのように40mm相当レンズ搭載版を出した方がおもしろかったように思います。もちろんDPシリーズと違って、GRは撮像素子が小さいのでボケ味とかが出せるわけではないのですがね。

ここからはわかる人にしかわからないという話です。すみません。GRといえば、フィルム版もコンパクトカメラGR1ですが、最近は安くなりましたね。もちろん中古価格ですが、GR1は人気機種だけあって、GR1v(ブラック)あたりだと7万台だったのですが、いまでは状態のいい物が5万円を切る値段になっています。以前、GR1は迷ったあげく、コンタックT3を買ってしまったという過去があるので(だってプラボディよりもチタンボディの方が良さそうだったから)、GR1はちょっと欲しいかもと思ったりしますが、さすがにフィルムカメラは現像・プリントを考えるとデジタルカメラよりも高くつく時代ですから、いまさらフィルムカメラはね。でも、レンズ単体版のGR21mmは欲しかったりします(実はGR28mmレンズは持っていたりしますけどね)。

知り合いから中古DPEマシンを20万円で買わないか、というお話がありました。そうです、写真屋においてある大きな機械のこと。ほとんど自動でフィルムの現像・プリント・引き延ばしをしてくれる機械です。デジタルカメラの影響で店を閉じる写真屋さんが多いから、いい状態のDPEマシンあるからだそうです。確かにフィルム写真を撮ることはたまにありますが、わざわざ機械がほしいことはないし、そもそもあんなデカイ機械を置くスペースはありません。

2009年7月26日

GoogleのChrome OSのことは何回か書いたのですが、日経BPの「Google OSは別にある」という記事に触発されて、しつこくChrome OSのことを書きます。現記事はGoogle OSというのはGoogle App Engineであって、Google App Engineはスケラビリティが高い。ただMicrosoftと同様にOS供給者は圧倒的に強く、その意味でサードパーティがGoogle App EngineというOSを使う限りはGoogleに勝てないということ。記者さんの指摘通りだと思います。ただ、個人的には記事にあった「グーグルのモットーはスケールする」という指摘が気になってしまいました。というのはスケールという観点からいうと、ユーザにサーバ上のアプリケーションを使ってもらうためよりも、Googleが自社のサーバをスケールに運用するためにGoogle専用のクライアントOSが必要なのではないでしょうか。

いまさら説明するまでもないですが、Webブラウザはアプリケーション層の通信プロトコルであるHTTPはトランスポート層のTCPを使っています。そしてTCPはOSによって実装されています。しかし、HTTPはリクエスト・レスポンス型ですし、数多くの少量データを不連続に送るので、ストリーム通信向けのTCPには不向きです。こうした無駄や不整合はクライアント側だけでなく、サーバ側にとっても負荷が高くなる要因、つまりサーバがスケールできなくなる要因になります。しかし、Webブラウザ専用OSならばTCPをHTTP専用と割り切れます。例えばTCPのウィンドウ制御などをHTTPを前提にチューニングが行えますし、ウィンドウサイズを増加をサーバ側の負荷状況に応じて変更することもできるでしょう。またTCPは接続してしまえばクライアント側とサーバ側は対称なので、こうしたチューニングはクライアント側の負荷を下げるだけでなく、サーバ側の負荷もさげることになります。そして、自社のクラウドコンピューティングのインフラにチューニングされたOSは、他の汎用OSからクラウドコンピューティングを利用するときよりはインフラ側の負荷が小さいので、そのインフラ使用料を安く設定することもできますから、ユーザにとっても悪い話ではないし、Chrome OSをユーザに使わせる十分な経済的なインセンティブになるでしょう。

さらにTCPを使う必要もないのかもしれません。仮にGoogleが自社サーバの負荷を下げる、またはスケラビリティをあげるような独自通信プロトコルを開発していれば、その通信プロトコルをOSに採用すればいい。非標準的な通信プロトコルは広く使うことはできませんが、Googleのサーバがその独自プロトコルをサポートしていれば、Webブラウザ専用OSがGoogleのサーバに接続するときだけその独自プロトコルを使うのであれば問題はない(なお、トランスポート層より下の通信プロトコルはいじり難い。というのはレイヤ３スイッチが広く使われていますから)。

もちろん、これは極論です。ただ、クラウドコンピューティングが広まるとすると、Web専用OSだけでなく、今後のクライアント用OSの技術進化は、クライアント側の性能向上よりも、サーバ側、つまりクラウドコンピューティングのインフラの負荷をさげる、またはスケラビリティをあげることに方向性がかわるでしょう。クラウドコンピューティングはOSだけでなく、通信の技術進化の方向性にも大きな影響を与えます。クラウドコンピューティングの時代では、上述のようにデファクトスタンダードな通信プロトコルではなく、メインフレーム時代のように独自通信プロトコルが主役になるのかもしれません。

こうした独自通信プロトコルについてはIETF信者は激怒するでしょうし、メインフレーム時代に逆戻りするような技術進化がいいのか悪いのかはわかりません。しかし、記事のように「グーグルのモットーはスケールする」ならば、通信プロトコルを含めてスケールさせない要因をすべて排除するのもひとつの方法です。もしTCPというインターネットの基盤中の基盤が通信やサービスの発展の足かせになっているのであれば、それを捨てるのは悪いことではないし、IETFを含めて標準化作業が技術進化を遅らせている要因にならば、それを回避してもいいでしょう。

ここまでいろいろ書きましたが、おそらくGoogleはTCPに代わる独自プロトコルまでは考えていないでしょうし、手を出すこともないでしょう。というのは上述の記事にあるようにGoogle社是が「Don't be evil」だからです。つまり、GoogleはOSという悪魔の果実は手に入れられても、禁断の独自プロトコルという悪魔の世界に踏み込めないでしょう。GoogleがChrome OSを活かせるかは、Googleが悪魔になれるかにかかっています。それができないならばそれがGoogleの限界でしょうし、早晩、悪魔になりきれる企業に取って代わられるでしょう。もちろん、先のことはわかりませんが、将来Googleが衰退したときは、社是が足かせになったと評論されることだけは確かだと思います。

2009年7月25日

成田空港に到着。いろいろ疲れました。帰国早々、報道発表をすることになっていまい、その準備もしないといけないしで。というわけでプログラミングには思ったより時間がとれず。帰りの飛行機はちょっとでも進めておこうと、ずっとプログラミングをしていましたが、出遅れを取り戻せるわけもない。出張期間が長かったわりにはすすみませんでしたね。明日は事務仕事をするために休日出勤です。

2009年7月24日

長かった出張もそろそろ終わり。帰国の途につきます。さすがに一回の出張で4ヶ国に行くのは無謀でした。さて帰国ですが、まずはいったんフランスからスイスのバーゼルに入って、バーゼルの空港からフランクフルト空港を経由して帰国です。バーゼルの空港はジュネーブの空港と同様にフランスとスイスの国境沿いにあり、フランスからも入れるのですが、今回はスイス側からバーゼル空港に移動です。

総務省から報道発表されているようですが、下記の予算をいただくことになりました。当方のようなソフトウェア屋がなんでCO2削減の研究と思われる方が多いかと思いますが、ソフトウェアの研究は最適化や効率化の手法に関する研究が進んでおり、その手法の中にはCO2削減に役立つものもあります。コンピュータサイエンスも別に対象をコンピュータに限定する必要はなく、現実世界に応用できる研究も少なくないと思います。

2009年7月23日

国際会議の2日目。といっても国際会議は20日から始まっているので、4日目で、さらに最終日。昨日と比べて人が少ない。さすがにいい雰囲気の街ですから、国際会議よりも街探索の方がおもしろいのでしょうね。ところで場所がフランスですから、当然、フランスの研究者が多いのですが、フランスの研究者はたいへんなようですね。彼らは現大統領になってからといいますが、大学の予算が大幅に削減されていて、機材が買えないどころか、ポジションを失ったポスドクさんが多いようです。予算配分の選択と集中といっても、ポスドクを多く雇っている一部の大学に配分されるために、それ以外の大学はただ減らされるだけという状況のようですね。

さて開催地のColmarはアルザス地方の街。というわけでアルザス風の町並み、つまり黒い木骨組みの建物。ただし、ストラースブールが白壁に黒い木骨組みが多いのに対して、Colmarは壁の色がとりどり。壁は隣の色とは同じ色は使わないという規則があるそうで、赤、青、黄色から、ピンクや緑など多彩な色が使われています。また、ストラースブールは都会という感じですし、近代的な建物のと木骨組みの伝統的な建屋が混在しているのに対して、Colmarは伝統的な建物が多い。ちなみにColmarはワイン好きの人には有名だそうで、アルザスワインの中心地ですよね。

2009年7月22日

朝5時に列車でBaselを出発、そしてフランスのColmarという街に移動。Baselの滞在時間は実質、5時間ぐらいでしょうか。というのも今日は国際会議の9時からのセッションで発表があるのです。今回は日程の関係で致し方なし。それにしてもだからというわけではないのですが、発表の方は内容は伝わったとは思いますが、ちょっと散漫な発表になってしまったかも。移動したその日に発表というのはたいへんなのです。

ところでBaselの中央駅は、国境の町というだけであって、ひとつの駅舎にスイス国鉄(SBB)だけでなく、ドイツ国鉄(DB)とフランス国鉄の窓口やプラットフォームがあります。さすが国際都市という感じです。ちなみに普通の路線バスでも国境を越えますから、行きは運賃をスイスフランで払って、帰りはユーロで払うということになるので、両方の通貨をもっていないと戻れなくなったりします。

2009年7月21日

ワークショップの会場は大学なのですが、近くに風光明媚な湖があります。オーストリアという内陸地という印象がありますが、結構、きれいな湖が多いのですよね。ワークショップの昼食はボートで湖畔の街に行くことになりました。そしてワークショップ後は大急ぎで空港に行って、ウィーンを経由してスイスのバーゼルに移動です。ただし、飛行機が遅れて、バーゼルのホテルに着いたのは12時を過ぎておりました。今月、2回目のスイス訪問となりましたが、今回は訪問というよりも通過しただけという感じかも。

2009年7月20日

ワークショップの1日目。呼ばれて行ってみたものの専門外というか、参加者の分野が多岐にわたりすぎていて、議論がかみ合っていない感じ。それにしてもオーストリアという国は州によって違うし、住んでいる方々は州が中心で、オーストリアという国は意識していない。だから空港に降りると、「ようこそ、○○州へ」という看板がたっていますが、「ようこそ、オーストリアへ」とはならない。そしてインスブルクならばチロル人、ザルツブルクならザルツブルク人、グラーツならばシュタイヤーマルク人という意識のようですし、それをすごく重視します。その意味ではスペインのようなところがありますね。それとオーストリアの地方の方はウィーンのことをよく思っていない。フランスにおけるパリとそれ以外の関係に似ているのかもしれません。

2009年7月19日

日程の関係で一日オフです。ということで電車を乗り継いでGrazにいってみました。まずはヘンテコ美術館の代名詞となっているKunsthausにいってみました。2003年にピーター・クックとコリン・フルニエによる設計によって作られた美術館なのですが、写真以上にヘンテコでした。Grazの伝統的な町並みとのミスマッチが問題になっていましたが、目の当たりにするとミスマッチという段階ではないです。それと内部ですが、非常に使いにくそうですし、展示品をおけるスペースがすくない。外壁だけでなく、内壁も球形なので展示品がおきにくい、また明かり取りは天井のウツボのような小さなまどしかないので暗いですし、音がすごくこもるようです。ここまで問題が多いと、おそらく長続きしないではないでしょうか。また、形状が特殊ですし、外壁がガラスなので維持管理コストは相当かかるはず。というわけでいってみたい人は早めにいった方がいいかもね。閉館になるまえにね。ちなみにKunsthaus美術館はNeue Galarieという現代美術館の別館という扱い。Neue Galarieは宮殿だったお屋敷を改造した美術館で、内装を見るだけでも行く価値がありますし、展示作品もKunsthausよりもNeue Galarieの方が量・水準ともに高かったです。美術館側もよくわかっているのかもしれません。

2009年7月18日

今日は移動日です。飛行機を二回乗り継いで、さらに列車にのって、オーストリアの地方都市に移動です。インフォーマルなワークショップに呼ばれているのです。どのみちロンドンに行くことになっていたので、講演を引き受けましたが、欧州内とはいえ一日がかりの移動となりました。ロンドンを9時発フライトで、ホテルに着いたのは9時過ぎでした。

2009年7月17日

ロンドン3日目です。夜はロイヤルオペラでVerdi作の「仮面舞踏会」。5月にパリオペラ座で観たばっかりの演目の気がしますが。さておきロイヤルオペラの「仮面舞踏会」の出来ですが、主役のRiccardo役はRamon Vargas。旨い歌手で歌自体は文句なしなのですが、ちょっと声質がフィガロの役にあいそうな軽い声なので、Riccardo役には向いていませんでした。また、Renato役はDalibor Jenis。感情表現がいまひとつですが、歌はうまい。ヒロインのAmelia役はAngela Marambioも歌かったですね。ただ、体格がよすぎなのが問題でしたが。それからUlrica役はElena Manistina。歌自体いいのですが、迫力にかけていました。指揮はMaurizo Benini。可もなく不可もなしという出来。ただ、オーケストラはいいですね。弦楽器も管楽器も音に伸びがあります。演出は非常にオーソドックスなもの。さてパリオペラ座との比較ですが、個々の歌手のクオリティはロイヤルオペラの方が一段上ですが、演出や配役などはパリオペラ座の方がいいですね。一演目で比べるのはよくないのですが、ロイヤルオペラは歌手に頼りすぎているかなぁ、という感じがします。なお、オーケストラとコーラスはロイヤルオペラの方がいいです。実は同じVerdiの「Simon Boccanegra」もロイヤルオペラとパリオペラ座の両方でみており、このときは順番が逆でロイヤルオペラで観てから、パリオペラ座でも観たのですが、こちらの印象も同じで、歌と演奏を楽しむならばロイヤルオペラですが、オペラを楽しむのならば視覚性を重視するパリオペラ座の方がいいですね。

2009年7月16日

国際会議(ACM ICPS'09)で発表。今回は初日から参加できないので、発表日を後半にしておいてね、と頼んでいたら、本当に最後のセッションの最後の発表。ただ、昨日よりも参加者は多かったかも。発表は非常に好評だったので、方々で講演を頼まれました。それにしてもこの国際会議はなぜかモバイルエージェント関連の発表が多かったですね。当方がいうと怒られますが、いまさらモバイルエージェントでないような気もしますが、ただ、ロッキードなどの米国防系企業でモバイルエージェントに手を出すところが出てきているなどで、いろいろ動きはあるのですよね。

ところで会議のはじめはクラウドコンピューティングに関するパネルでした。聞いているだけでいいので気楽なのですが、パネル討論の内容がともかく古い。オルガナイザーはNSFのAutomonic Computingのディレクターだったので、ちょっと内容を期待したのですがね。クラウドコンピューティングはデータセンター系の人の話はおもしろいのですが、グリッドコンピューティングやP2P系、オートノミック系の研究者の話は我田引水的な話ばかりでつまらないのですよね。結局、クラウドコンピューティングというのは、データセンターをひとつのコンピュータとすることで、スケーラブルなコンピューティングを提供する技術ですから、グリッドやP2Pのように分散が先にありきということでもない。また、クラウドコンピューティングは故障を前提にした技術なので、オートノミックコンピューティングの適応性や自己組織化性が求められているわけでない。

2009年7月15日

国際会議(ACM ICPS'09)に出席。実は3日目から出席。二本論文を発表することになっていたのですが、一方は昨日、学生さんに発表してもらう。まぁ筆頭著者がは彼なのでいいでしょう。さて国際会議ですが、基調講演は思いっきりつまらない。発表されている論文もピンキリですね。最近は、難関国際会議を含めてピンキリというか、いい論文が多いか少ないかが会議のクオリティになっている感じ。

2009年7月14日

というわけでロンドンに移動。さて話は変わって、MicrosftはWeb版のOfficeの無償提供を決めたようですね。もちろん、ユーザとしては無償提供はありがたいのですが、個人的にはMicrosoftの失策ではないかと思っています。もちろん、Microsoftの立場から観るとすでにGoogleドキュメントにおいて無償サービスとして文書作成、表計算、プレゼンテーションが提供されていますから、Microsoftとしては無償提供以外に選択肢がなかったのでしょう。

しかし、Officeが提供する文書作成、表計算、プレゼンテーションはパソコンにおける代表的な処理だけにそれのオンライン版が無償提供になるというのは、他のソフトウェアにも大きく影響することになります。つまりOfficeに含まれる処理はもちろんのこと、画像処理などのOfficeには含まれたない他の処理についても、それらのWeb版は無償提供に追い込まれることになりかねない。当たり前ですが、無償提供になると開発費が出せなくなりますし、Web版として提供するためのインフラの購入・維持管理費もでないことになります。この結果、他社の同種のソフトウェアやサービスの開発意欲をなくす、またはベンチャーキャピタルが融資してくれなくなることが予想されます。そして開発投資が減れば技術進歩がとまってしまいます。この影響はオンライン版サービスの無償化だけでなく、オンライン版サービスと同様の機能を提供するソフトウェアに対しても、ライセンスのディスカウト要求に広がるでしょうから、ソフトウェア産業全体に影響しかねません。

さらにMicrosoftは同じ日にWindows Azureの価格体系を発表しています。クラウドコンピューティングを伸ばすには、そのクラウドコンピューティング上で動くサービスの開発をサードパーティ(企業や開発者など)に促すことです。企業や開発者は経済的なインセンティブがなければ、クラウドコンピューティング向けのサービスを開発してくれません。なのにMicrosoftはOfficeという超定番サービスを無償化してしまったので、サードパーティは有料サービスを提供しにくい状況を作ってしまいました。そもそも、MicrosoftはAzureをサードパーティがオンライン版サービスを提供するためのインフラとして期待していますが、そのAzureの使用料は有料なので、サードパーティは少なくてもサービスの利用料はクラウドインフラ以上の利用料をとらないと採算がありません。もちろん、Microsoftがクラウドコンピューティングを潰すという立場から観れば、Web版Officeの無料化とAzureの有料化は極めて強力な方法となります。

Microsoftという会社は、同社製品向けのデバイスやソフトウェア開発するパートナー企業にやさしいというのか、パートナー企業自身やその開発者が困らないように注意深く戦略をとってきたのですが、今回のWeb版Officeの無償化に関してはパートナー企業の儲け口を潰すことになるので、いい戦略だとは思えなかったりします。今後のクラウドコンピューティングやWebベースのサービスの発展を考えるのならば、MicrosoftはWeb版Officeを有償提供して、クラウドコンピューティング向けのサービス開発は儲かるというところを見せるべきだったと思います。

2009年7月13日

慶大の大学院授業。今期はこれは最後の授業。ところで欧州からかえってきたばかりですが、明日からまた欧州です。今回は４カ国をまわることになります。

2009年7月12日

都議会選挙の投票に行ってきたのですが、不思議におもったことを３つ。近所の投票所は近所小学校だったのですが、選挙管理委員会の方々が8人ほどおられました。おそらく席をはずしている人もいたでしょうから、さらに＋αの人数がいたのでしょう。区役所などの職員さんなのだと思いますが、ひとつの投票所にこんなに動員する必要があるのでしょうかね。工夫次第でかなり人員を減らせる気がしたのは気のせいでしょうかね。電子投票が検討されているそうですが、電子投票では開票作業自体は少人数化できても、システム要員が必要なるので投票所に貼り付ける人員の数はきっとふえるのでしょうね。

さらに不思議なのは即日開票へのこだわり。日本の場合、投票箱が盗まれるなどの騒動は起きにくいでしょうから、次の日にゆっくり開票してくれれば十分です。即日開票は夜を徹して行われますから、開票に携わる職員さんに深夜手当などが余分にかかってしまいます。

もうひとつ不思議なのは選挙開票速報番組。地方選挙なので選挙番組数はすくなかったのものの、当該番組はほとんど開票中継番組と化しています。スポーツ中継ならばリアルタイム応援することにきっと意味があるのだと思いますが、選挙ですから開票中に応援しても意味がないし、むしろ意味があったら困ります。なので開票が終わってから結果を教えてくれるだけで十分。まわりのテレビや新聞社の方々は選挙というだけで妙にテンションが上がられていますが、途中結果は報道していただかなくても結構です。これから国政選挙もあるのでしょうが、人件費が余分にかかる即日開票となり、そして投票日の夜は中継番組がいっぱい放映されるのでしょうね。もっとも一番不思議なのは議員数が多さなのですが、立場上、これに言及すると怒られそうなので、ここまでにしておきましょう。

2009年7月11日

帰国早々ですが、休日出勤です。いそがしいです。作業がおくれて方々に迷惑をかけていますが、週明けには解決します。というか解決しないといけないのですが。

2009年7月10日

OSをWebブラウザに特化したとするとOSはどうなるのでしょうかね。実はGoogleがChrome OSを表明してからいろいろ考えてみたのですが、いまのOSは多様なアプリケーション対応できるように機能豊富になっているので、Webブラウザ専用OSというのは基本的には、Webブラウザの実行に不要な機能を大胆に削っていけばよく、新しい機能を追加する必要はないでしょうね。

ただ、Webブラウザ専用と割り切るといろいろ思い切ったことができます。例えばスケジューリング、メモリ管理あたりはWebブラウザを前提にチューニングができるようになります。特にセキュリティ的にはだいぶ楽になりますよね。例えばWebブラウザ上の複数ウィンドウまたは複数タブで複数のWebページを開いていても、Webページ同士で通信をすることはないはず。だとするとWebページごとにプロセスを割り当てた場合、プロセス間通信は不要なわけで、各Webページがひとつの閉じた管理ドメイン内として開くことできるわけで、Webページによる影響をそのページだけに限定させることができます。

なお、Webブラウザ専用OSの登場で、個人的に気になるのはOSが提供すべき通信プロトコルのレイヤー。いまのOSはTCP/IPレベルのレイヤーを提供していますが、Webブラウザを前提にするのならばHTTPを中心としたアプリケーションレベルプロトコルだけでいいわけで、低レベルプロトコルをOS内にに隠蔽して、アプリケーションレベルプロトコルだけを提供するOSというのもあってもいいのかもしれません。ネットワーク屋さんの用語でいうとTCP/IPが通信プロトコルのウェストになっていますが、今後はHTTPがウェストになるわけで、なんでもHTTPで実現するという流れに拍車がかかりそうです。ただ、HTTPもOSで管理されるのであればセキュリティ的には工夫の余地がありますね。

2009年7月9日

Chrome OSのつづき。メディアはMicrosoft対Googleという対抗図式にしたがりますが、昨日も書いたようにMicrosoftにとってはChrome OSの登場は脅威でしょうが、独占禁止法の縛りを弱める効果があるので悪い部分だけではない。むしろChrome OSの影響が大きいのはMicrosoftのWindowsよりも、AppleとLinux陣営でしょう。また、PCメーカにとっても諸刃の剣になりそう。

まず、Appleですが、ご存知のようにAppleはハードウェアとソフトウェア一体化戦略をとることで、コンピュータ当たりのOS費用を下げることで他のPCメーカに対する価格優位性を提供していました。しかし、Chrome OSは他のPCメーカにとってもOS費用が下がり、Appleは価格優位性を失うことになります。また、AppleはGUIの操作性の良さは定評があるところですが、Andoridのように不出来なGUIを提供するようなGoogleでも、Webブラウザという特定アプリケーションに特化してしまえば、そこそこの操作性をもつGUIを作れるでしょう。MicrosoftにとってはChrome OSの登場は出血程度の怪我でしょうが、Appleにとっては致命傷になりかねない。次にLinuxですが、これまでのサーバーはともかく、クライアントに関してはLinuxは操作性も悪いし、アプリケーションも少なく、価格以外に競争力はありませんでしたが、Chrome OSは大元は同じLinuxとはいえ、多くのLinuxディストリビューターにとっては驚異になるでしょう。

そして、Chrome OSがPCメーカにとっても諸刃の剣になる理由ですが、Chrome OSを搭載すればPCメーカはWindowsのような高額なライセンス費を出さなくてよくなります。また、Windowsを使い続けるにしてもMicrosoftに対してライセンス費用の値下げの口実になります。しかし、PCメーカが製品としてChrome OS搭載マシンを出した場合、Chrome OSの品質保証をPCメーカも責任の一端を持たないといけません。従って、Googleがどの程度、Chrome OSの品質保証、つまり不具合などがあったときに対応してくれるかの役割分担が、Chrome OSが普及するかの鍵になるでしょう。ただ、Googleにとってはハードウェアを含んだ品質保証は初めての経験でしょうし、こうした個々のハードウェアにおける品質保証には膨大なテストが必要であり、大きなコストになってGoogleに跳ね返ってきます。おそらくGoogleは、Chrome OSの動作保証をGoogleが指定したハードウェアプラットフォームだけで行うことになるでしょう。そうなるとChrome OSを搭載したマシンはどれもほとんど同じとなり、PCメーカはハードウェア的な差別化は難しくなり、最終的には価格競争に追い込まれるでしょう。特にハードウェアによって製品差別化をしていた国内PCメーカにとってはダメージが大きいでしょう。

Chrome OSを搭載するPCが登場するのは来年以降のことであり、形も見えないOSにあれこれ論評しても仕方ないのですが、PCというジャンルにとってChrome OSの登場はいい面だけではないように思います。ただ、Chrome OSというパンドラの箱は空いてしまうのなら、もう後戻りはできないので、空いた時を想定していくしかない。個人的にというか、コンピュータサイエンスの研究者としては、サーバ側がクラウドコンピューティングにより自由度が奪われ、クライアント側はWebブラウザ専用マシンとなると、研究対象が減ることになります。もちろん、クラウドコンピューティング上で動くサービスが今後の研究対象になるのでしょうが、ソフトウェアと違って、サービスというのは設計よりも運用が重要となるので、学術研究としては扱いにくいのですよね。

さてChrome OSについては賞賛する声が多いようですが、個人的にはタイミングが遅さが気になります。すくなくてもPCメーカがWindows 7に向けて動き出しているときに、1年先の話をいいだすというのはタイミングがいくらなんでも遅すぎです。せめてWebブラウザのChromeを発表したときにChrome専用OSの計画を発表しておくべきでしたよね。もちろん結果論をいってみ仕方ないのですが、最近のGoogleは戦略に切れがないですよね。

2009年7月8日

まぁ、予想された通りとはいえ、GoogleがWebブラウザの利用に特化したOS (Chrome OS)を表明。確かにOSもWebブラウザ用に特化すれば、通信プロトコルスタックもシンプルになりますし、プロセス管理もセキュリティ対策もシンプルになるし、OS自体のアップデートも簡単化できます。ただ、考えておかないといけないのは、今後はWebブラウザがOS化する方向なのか、OSがWebブラウザ化する方向なのかです。前者ならばWebブラウザの機能は肥大化していくでしょうし、後者ならばOSとWebブラウザの境目は消えていくでしょう。いずれにしてもWebブラウザというソフトウェアのジャンルは消失していくように思います。また、Googleとしてはサーバからクライアントまで主導権を取りたいのでしょうが、Microsoftなり、Appleなりに、Webブラウザ専用OSを作らせるように仕向ければいいことであり、Google自体が動く必要があったのでしょうかね。もちろんMicrosoftもAppleも何らかの対抗策を打ってくるでしょうから、それを引き出すのが目的ということもありえるでしょう。

ところで、Chrome OSの話を聞いて最初に頭に浮かんだのは独占禁止法の絡み。日本や米国はともかく欧州ではOSとWebブラウザの抱き合わせ販売は独占禁止法に抵触する可能性があります。当然、Googleも避けられないはずですが、これを回避する口実がオープンソースなのかもしれません。最近は「オープンソース的」なことに対して議論が活発だそうですが、今後のオープンソースの意義のひとつとして独占禁止法回避があげられるかもしれません。

また、PCメーカ、特にネットブックPCのメーカにしてみるとChrome OSの存在はMicrosoftに対してWindowsライセンスの値下げ要求ができる材料ができたという点ではありがたい存在になるでしょうね。PCメーカの方に伺うとWindows 7は個人向け販売価格はVistaと比べてやや値下げになるといっても、メーカへのライセンス価格はほぼ同じでということのようですですからね。ただ、MicrosoftにとってもChrome OSの存在は悪い話ではないかもしれません。MicrosoftにしてみてもChrome OSがある程度、普及すると独占禁止法の縛りが弱くなって、同社の必勝パターンであるOSとWebブラウザの抱き合わせ販売がしやすくなるというメリットがあるかもしれません。

2009年7月7日

移動の関係でジュネーブのITUとWIPOのそれぞれの本部の前を通りました。今年はITUの4年に一度のイベントである見本市Telecomがありますが、ITUもTelecomも権威がないというのか、過去の遺物状態ですよね。

話は変わって今朝の日経新聞には「AneCan」の全面広告が出ていたのですが、「AneCan」の読者層と日経新聞の読者層は重なっているのでしょうかね。女性ファッション雑誌はよくわからないのですが、重なっているとは思えず、広告効果はあるのでしょうか。もちろん雑誌側が読者層を広げたいことはあるのでしょうが、こうした女性ファッション雑誌は読者年齢層や嗜好性で棲み分けをしているので、読者層を広げると自社の他雑誌の市場を食う可能性もあります。そうなると新聞社側の都合でしょうかね。

2009年7月6日

欧州では電気自動車をよく見かけます。町中にも電気自動車用の給電スタンドがあったりしますし、電気自動車専用の駐車スペースまであったりします。また、Zermattなどの一部の街では30年ぐらい昔から街内では内燃自動車の乗り入れを禁止していて、事実上、電気自動車だけになっている街もあります。

また、欧州で使われている電気自動車は驚くほど簡単な構造が多い。主要部品のモータ、バッテリ、タイヤ、ステアリングを組み合わせしているだけで、自作PCに近く、個人は無理にしても町工場でも作れそう。逆に考えると今の内燃自動車は複雑すぎますよね。車載用のソフトウェアの大規模化と複雑化が問題になっています。コンピュータ制御が必須ですし、コンピュータの数も一台で100個以上の場合もあり、当然、ソフトウェアも膨大な規模になり、一台5000万行を超えることもざら。最近はハイブリッドカーが人気ですが、内燃系＋電気自動車なので機械的にも電気的にも複雑なシステムとなっており、一部の自動車メーカに作れるかもしれませんが、複雑すぎるので価格的にも耐久性的にも長続きはしないような気がします。

こうした実運用されている電気自動車のおどろくほど簡易な構造を見せつけられると、自動車の内燃系から電気モーターへの移行は自動車産業の構造を大きく変えるでしょうし、すくなくてもすりあわせ的な組立産業はいらないし、まして大自動車メーカもいらないということになります。いずれにしても個人的には、CO2排出削減よりも、車載用ソフトウェア開発の規模や複雑さを嫌って、簡単な電気自動車に向かう可能性が高いように予測しています。いいかえれば大自動車メーカが寡占化した市場を打ち破るために電気自動車に移行するということ。

2009年7月5日

Amazon.comの日本支社が国税庁から追徴課税を受けたようです。こちらの記事によると、販売業務をしているアマゾンジャパンと発送業務をしているアマゾンジャパン・ロジスティクスがあるのですが、前者の収益は米国に納税しており、これを国税庁が日本に支払うべきと指摘したようです。この問題はクラウドコンピューティングが普及する顕在化する問題ですよね。国産クラウドコンピューティングインフラを作りたい人たちがおられるようですが、まずは海外にあるクラウドコンピューティングインフラにおける日本向けのデータやトランザクションの法的権利を明確化する方が先だと思います。

2009年7月4日

前回の海外出張の疲れが抜け切れていないのか、実は出発前からぐったりモード。まぁ欧州に行けばたいてい元気になるのですがね。まだ帰国までに数日あるのでその間に復活するでしょうかね。

2009年7月3日

所用でスイスのレマン湖におります。当たり前ですが、風光明媚なところですね。フランクフルト行きの飛行機ではプログラミングはせずに「ウェブはバカと暇人のもの」という新書を読みました。あまり書評というのはしないようにしていたのですが、ちょっとだけ。まぁタイトルの「バカ」とはおもいませんが、ヘビーユーザには「暇人」が多いのは事実かもね。それはともかく個人的にはWeb 2.0とか集合知とかはまるで信じておらず、研究的にも関わらないようにしてきましたので、やっぱりそうだよねという部分は結構ありましたがね。それとネットの世界の発展を考えると、少数の成功事例だけでなく、多数の失敗事例を知っておくべきでしょうね。特に当方を含めて研究者はチャンピオンデータでものを考える傾向がある、つまり成功事例だけしか見ない傾向がありますからね。

ただ、個人的なネットへの危惧は別のところにあって、ネットの世界がデータプロデューサーとデータコンシュマーに二分されているきて(この二つはきわめて個人的な分類です)。、後者が前者に比べて圧倒的に多いこと。ちなみに前者はコンテンツを作る側。つまりコンテンツを作る側(ちなみにこの本は前者のデータプロデューサー側の状況だけをまとめていて、後者への言及はほとんどない)後者はGoogleやYahoo!などのデータをひたすら集めて、提供し直す企業と、不特定多数のネットユーザのようにコンテンツをひたすら見る方々としましょう。個人的に危惧しているのは、後者は前者によってコンテンツが供給されないと活動できないのに、前者に対して後者が極端に多くなっていること。今後、前者のコンテンツ供給能力は増えているのでしょうか。もちろん、ブログなどにより供給者は増えているとはいえ、クオリティにはあがっているとはいいにくい。ブログの記事多くは記事や他のブログへの引用や批評であり、真のコンテンツやデータのプロデューサーの絶対数は、従来メディア、例えば新聞、雑誌、テレビなど比べても大きく増えているとはいえないように思っています。もちろんコピペによる記事やブログの引用も一つのコンテンツだし、ニコニコ動画のコメントもコンテンツなのでしょうが。ただ、このままではデータやコンテンツの消費速度に供給速度が追いつきません。コンテンツの供給不足を避けるために、データコンシュマーからデータプロデューサーに対して何らかのインセンティブを与える仕掛けが必要かもしれません。

2009年7月2日

ANAでフランクフルト空港に移動です。まぁ乗ったばかりなのですが、7月は「夏の大作戦」というイベントで、機内食に冷やし中華がありました。それもかなり本格的な冷やし中華。機内食も本格指向ですね。もちろんエコノミー席です。ところで先々週のパリは機内で健康質問票が配られたのですが、フランクフルトは一切なし。まぁ健康質問票を配ったからといって防げるわけでもないので、現実的と言えば現実的。日本も健康質問票の配布を止めたようですね。

2009年7月1日

先週の海外出張の後始末が終わらないうちに明日から海外です。どうなるでしょうか。

最新版
 一覧

Ichiro Satoh

Ph.D, Professor
National Institute of Informatics
2-1-2 Hitotsubashi, Chiyoda-ku, Tokyo 101-8430 Japan
Tel: +81-3-4212-2546
Fax: +81-3-3556-1916

　