Diary

Ichiro Satoh

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

最新版
一覧

2010年12月31日

大晦日ですが、いつも通りに平常業務でございます。結局、時間切れの強制御用納め。でも明日は休もう。

2010年12月30日

今年は購入したカメラもレンズもなし。手持ちのカメラで十分。むしろ使ってないカメラをなんとかしたい気分。フィルムカメラとデジタルカメラを比べたら、フィルムカメラの方がいいと思うのですが、ラーニングコストがかかるのは辛く、フィルムカメラの稼働率が下がったのは事実。ということでNikon FM3A、Minolta CLE、Contax T3あたりがドナドナ候補。

ただ、皆さん同じことを考えるようで、中古フィルムカメラは暴落状態ですよね。最新のニコンF6も中古では10万円を切っているし、かつて中古でも50万円以上したHasselbradなどはPlaner 80mm F2.8をつけた500CMですら、いまは10万円ちょっとですからね。時代の移り変わりを感じます。

2010年12月29日

平常業務。御用納めをしたくても納められない状況。それにしても事務方を含めて来ている人が多いって、どういう職場なのか。

2010年12月28日

世間は御用納めのようですが、こちらは年内は平常業務予定。まだまだ新年早々だと思っていたのに、いつのまに年末になったのだろうか。というか個人的には年末だとは認めない。まだまだ新年早々だと断言したい。そもそもいつまでが新年で、いつから年末という定義もないわけですしね。

2010年12月27日

あいかわらず声がない状態を続けていますが、平常通りにお仕事です。

ところで一応、国立大学法人の大学教授ということもあり、博士課程の進学の相談を受けますが、博士は研究者としてのスタートラインに経つためのライセンス。そして博士課程はそのライセンスを取るための教習所。博士課程は研究者としての基本的なことは教えられますが、基本的には学生さん本人次第。ちなみに進学相談で困るのはパターンをいくつか列挙します。

博士を取ることを目的とされている方。前述のように博士取得してから重要なのですが、博士取得してから何をするのかを伺っても、明確な回答をいただけないと相談される側は困ってしまいます。なお、当方の場合は、博士をとることそのものが目的化されている方はお断りすることにしてます。重要なのは博士をとって、その後、何をしたいのかなのです。

一つ目と似ているのですが、自分探し系の方。博士課程で将来、何をやりたいのかを考えたいというもの。博士課程中は多かれ少なかれ成果が出ない時期があります。そうしたときに目的のない人は潰れる可能性が高いです。

最短経路を求める方。パターンとしては特定のテーマの研究をしたいから、それに必要な知識を教えて欲しい、とおっしゃっいます。レーシングライセンス教習でいうと、ドリフト走行だけを教えて欲しいというようなもの。むしろ知って欲しいのは研究者として基本的な考え方や研究方法。これらがわかっていれば研究テーマを変えても生きていけますから。

(ひかく的)専門分野の専門家になりたいという方。例えば経済学が専門ではない者からみると、マクロ経済はひとつ研究テーマになりえるとみえるわけですが、マクロ経済もさまざまな専門に分化しています。博士論文になりえない粒度の研究分野をひろく勉強したいといわれるとやっぱり困ります。これは情報系も同じで、例えばプログラミング言語といってもかなり細かく分かれており、プログラミング言語の研究をしたいといわれてもね。

また自信過剰の方も困るんですよね。研究者としてやっていくには自信が必要なのですが、大学院に入学する前から「研究者として大成する自信があります」と断言される方もおられます。もちろん研究に関わられてきた方が、その経験でうえでおっしゃっているのであれば結構なのですが。自信過剰の方に多いのですが、他人の研究には攻撃的といえるほどケチをつけるのですが、自分の研究のアラは見てみないふり。新しい研究テーマほど確立していませんから、アラはあるものです。問題はそのアラをふさいで、発展できるかなのですよね。

それから博士進学では研究テーマを伺うのですが、実際には研究テーマを変える学生さんも多く、進学時に伺う研究テーマは、テーマ設定能力を評価するためです。修士課程は問題解決能力を身につける場ですが、博士課程は問題発見能力を身につける場ですから、テーマ設定能力、つまり何が問題であるかを見いだして、それを解決するために方法が立てられるかをみます。問題発見能力をつけるのが博士課程なのですが、その発見センスががない人は博士課程にいっても身につかないから、研究テーマを通じて、問題発見センスだけは見ておいた方がいいということです。

2010年12月26日

このページの12月15日にシャープのGALAPAGOSの普及策として、(1)一般書店に取り揃えが少ないコンテンツ、(2)恥ずかしくて買いにくいコンテンツ、(3)家人を含めて人に持っていることを見せたくないコンテンツに焦点を絞るべき。そしてその代表が成人向けと書いたら、方々からコメントをいただく。日本の場合、本屋さんでブックカバーを付けてもらう人は、本を汚したくないこともありますが、何の本を読んでいるかを見られたくな人もいるわけで、そうした人に何の本を呼んでいるか知られたくない書籍がキラーコンテンツなのだと思います。なお、海外では書店がブックカバーをつける慣習はないのですが、ロマンスもののペーパーブックは表紙がシンプルで、一見する限りは何の本を読んでいるかわからないし、実際、Kindle向けの書籍もロマンスもの比率は高いといわれています。

まぁ成人向けというのは極端な例だったのですが、GALAPAGOSの場合はカラー液晶ですから、それを活かして、(1)から(3)の(いずれかに)該当する例が成人向けコンテンツということです。なお、AppleのiPadもカラー液晶ですが、Appleはコンテンツを制限をかけるので成人向けは排除する可能性があり、iPadでは無理だけど、GALAPAGOSならば流通しそうなコンテンツというとやっぱり成人向けになってしまいます。ただ、諸刃の剣のところがあって、電子書籍=成人向けというイメージができてしまうと電子書籍は普及しないので、たとえ売れなくても一般書も用意しないといけないでしょうね。

個人的には電子書籍のキラーコンテンツは、新聞・雑誌、著作権切れした文学書、成人向けの3つだと思っています。雑誌は書店よりも配達ベースの雑誌から電子書籍に移行しそう。ただ、新聞系は新聞社私大でしょうね。二つ目の著作権切れした文学書は安価に提供できるということもありますが、それ以外に交通機関が車内や機内サービスとして無料配信すると予測しています。

2010年12月25日

ちょっと早めに年賀状作成。こんなに早く年賀状を作ったのははじめというぐらいは個人的には早い。ただ、お約束ともいえるプリンターとの格闘は例年通り。クオリティ以前に、印刷したいときに印刷できるプリンターは世の中にないものでしょうか。それとレーザープリンターもインクジェットプリンターもトナーまたはインクはお値段が高いですよね。プリンター本体ではなく、トナーまたはインクで儲けるというビジネスモデルだからですが、毎年格安プリンターを買って、トナーまたはインクを取りかえずに、新しいプリンターを買うのが正解かもしれません。ちなみに某プリンターメーカに勤めている知人にいわせると「プリンターを買って、印刷しない客は泥棒同然だ」とか(本体では利益は出ず、インクで利益を出しているという意味)、それは極論にしてもプリンターメーカもエコを強調するならば、プリンターを長く方がメリットが出るビジネスモデルにすべきですよね。なんか昨日の話の続きになってしまいました。すみません。

2010年12月24日

引き続きダウン中。というか声が出ない。ということで休日出勤分を振り替えて代休にさせてもらったのですが、どうしてもオフィスではないとできない用務が発生して出勤。研究者稼業もなかなかつらい。それはともかく楽しいクリスマスをお過ごし下さい。帰りに年賀状を買ったのですが、今年もカーボンオフセット年賀状が売られているようですが、環境貢献を重要と思うならば日本郵便は発売せず、顧客も年賀状を出さなければいいのに。なんて思ってしまうのは、立場上いけない発想ですね。すみません。これと似ているのですが、エコをアピールした名刺やパンフレットをよくお見かけします。大手企業の多くが、名刺に再生紙だとか書いてあります。そんなにエコを気にするならば名刺もやめて、パンフレットも止めればいいのに思ってしまうのも、立場上いけない発想ですね。重ね重ねすみません。

2010年12月23日

さすがにダウンです。某Web系メディアから年明けの特集向けだとかで、国内携帯電話のガラパゴス化に関するメールでアンケート・取材。そもそもガラパゴス化が始まったのは、欧州の通信方式GSMと袂を分かれたこと始まるはず。当方の回答は記者さんの意図は違うようでしたが、さすがにiモードに主因を求めるのはちょっと違和感があります。

携帯電話に限らず、市場や社会が孤立化する理由は、内側から見ているだけでは不十分。外側から見ないとわからないことが多い。ガラパゴス化の議論をみていると、日本という内側からしか見ない議論ばかり。しかし、そうした内側みた議論こそが一番ガラパゴス化してことに議論している本人たちは気がつかない。

2010年12月22日

秋葉原方面で打合せ。連日の徹夜仕事が祟ったのか、喉を痛めてしまって、声が出ない。まぁしゃべらなければいいのですが、打合せともなると、ずっと黙っているわけにもいきませんね。

2010年12月21日

午前は新丸ビルで打合せ、そのあと新宿で打合せ、それから原稿書き。結局、オフィスで貫徹。朝方までに1万文字ほど書く。一昨日も書きましたが、所内業務の原稿書き。そのうえ内容は研究とまったく関係がないし、早く終わらせないと研究ができなくなるので、こうした雑用は早々に終わらせるのに限ります。

2010年12月20日

打合せの日。忙しすぎてまわっていません。

2010年12月19日

午後から休日出勤して原稿執筆。一万文字ほど書く。日々の用務もあり、毎日書けるわけではないのですが、ここ一週間ぐらいは一日時間がとれる日は一万文字ペース。人間、書こうと思えば書けるものだと認識。ただ、この原稿ですが、勤務先の職務上の執筆。そのうえ自分の研究とはまったくというぐらい関係ない内容。まぁ自分の研究と絡めて書こうと思えば書けるのでしょうが、正直言って絡めたくないのが本音。ここで自分の研究と絡めると、ただのお仕事として淡々執筆できなくなりますから。シンクタンクの研究員の気持ちがちょっとだけわかった気がした日々です。

2010年12月18日

さすがにぐったりです。プログラミングに現実逃避。今年になってからはScalaで書くことが多かったのですが、最近はJavaに回帰中。一週間ぐらい集中してプログラミングするのならばScalaの方が生産性が高いのでしょうが、一日の中で数分程度の細切れの時間を見つけてプログラミングしないといけない立場だとJavaの方が楽な気がしてきています。

2010年12月17日

某省の某研究所の外部評価を送付。5年間の中期計画の最終年度評価。研究ですから、うまくいくことも、そうでないことがあるのは当然。その両方をいかして、次つなげて欲しい。

以下は一般論ですが、そもそも大学や研究所の外部評価は組織や体制を変えるためにするもの。しかし、評価を受ける側が現状維持をするために外部評価をしようとすると、評価を受ける側も評価をする側も疲れるだけになります。実際、研究者が「研究計画通り研究が進んでいます」と主張される方も多いのですが、これは内部評価でいうべきことだし、むしろ外部評価は現状をかえて、よりよくするための手段ですから、計画通りに行かなかったところをいってくれれば評価委員はそれを改善するような指摘をします。教員や研究者が現状維持を指向するようになると、変えられるものも変えられない。おそらく外部評価の目的がわかっていない一部の方なのでしょうが、これが学科長やマネジャークラス以上だったりすると組織としても厳しい。結構、大学でいわれたから外部評価をやっているという学科の場合、学科全体がその状況だったりします。組織も研究者も、現状をよりよく変えるために外部評価をうまく使って欲しいと思います。

2010年12月16日

情報処理学会の関西支部で1時間の講演。会場は大阪駅の近くだったのですが、梅田の地下街では毎回に道に迷うのですが、今回も迷いました。何人かの方から、教えてもらっていたのですが、大阪駅で出た改札がよくなかったです。なお、この地下街は広いこともあるのですが、道が斜めに分岐していたりで、方向感覚がなくなるのです。さて講演はいかがだったでしょうか、個人的には当方の前と後の講演もおもしろかったです。

2010年12月15日

某所でGALAPAGOSを拝見。メーカ、それも当該部署に近い関係者もおられるので、ちょっと緊張してデモ機をさわらしてもらう。そのわりに関係者の前で「シャープのiPad」と呼んでしまって困った顔されてしまう。さて電子書籍端末としては出来がいいようですね。ただ実際に使うためにはサービスの整備が重要。残念ながらサービスがまだまだ未整備なようで、サービスについて伺うと歯切れのいい回答をいただけませんでした。

一般論として、電子書書籍端末というモノを作ることよりも、サービスをそろえる方がはるかに時間がかかります。サービスが整わない状態で端末だけ出荷すると、使えない端末というネガティブイメージが蔓延するリスクもあります。その意味ではライバルであるiPadでAppleは端末だけでなく、サービスも整えていたことは評価してもいいし、そのサービスも外部に開発者に広げています。GALAPAGOSですが、端末ができたのは始まりに過ぎず、サービスを含めると二周ぐらい周回遅れの状態。新年度が始まる4月までにサービスを整えられるかが、ビジネス的な成否を決めそうです。

ただ、個人的には秘策があると思っています。それは昔のVHSの戦略、つまり成人向け書籍に手を出すことです。成人向け書籍は書店に流通しにくいし、書店では買いにくい、さらに家の本棚に入っていることも恥ずかしい。電子書籍ならば人に見られずに買えるはずだし、自宅の本棚に書籍がはいるわけではないので、家族を含めて人に見られることははない。このため日本に関しては成人向けコンテンツに手を出せばAppleに勝てるかもしれません。その意味で東京都の書籍の表現規制は電子書籍の普及に大きな影響を与えると思っています。

2010年12月14日

朝4時半起きをして新幹線のぞみ1号。それから京阪奈にいってNICTの外部評価。外部評価の内容は書けませんが、10時から18時過ぎまでのハードなお仕事。個年度はNICTの中期計画(5年間)の最後の年なので、この外部評価の仕事もあと一回。NICTと当方の勤務先(NII)は同じ情報系を扱う研究機関。研究者としては評価される立場ですが、年に数回、評価する立場になるとみえることもあり、こちらもいろいろ勉強になりました。

NICTだけでなく、当方の勤務先(NII)もそうですが、政策コンテストや事業仕分けなどにより、これまでと同じではいかなくなっているわけですが、いち研究者としては、まずは自分の研究を遂行することなんですよね。あとは国民が研究機関とその研究者を必要を考えてくれるか。もちろん、そう考えて頂くように成果を出すのが我々の仕事。論文のための研究とかしている余裕はないんですよね。

2010年12月13日

打ち合わせの日です。どの打ち合わせも基本的にその道のプロの方にお任せするもの。こちらもプロを信じているし、それに応えてくれるはず。

2010年12月12日

先月ですが、日経BPのIT Proの記事に当方の発言「Googleは巨大化する機械学習マシン」が取り上げられています。当方の発言はともかく、この記事自体は鋭い現状分析があると同時に、非常に示唆的なところが含んでいます。例えば自然言語処理でも、Google的にひたすら情報、つまり大量データを集めることで高次処理を行う方法と、まず人間が情報の中にあるルールを見つけて、そのルールを使って処理する方法があります。現状はBig dataとか情報爆発という言葉が使われるように大量のデータを集めて、そのデータを使った処理に関心が移っているし、成果もいろいろ出てきています。ただ、アカデミアの研究者からみると、データ量勝負になったら、Googleなどに勝てない。だからGoogleと戦うためには、そろそろ逆方向に行く、つまり、ルールを発見・処理する方に研究をシフトさせて方がいい時期かなぁ、と思っています。われわれの生きている社会には情報が溢れているわけですが、個々の人間が貯められ、扱える情報量は限られていますが、それでも高次な知識処理をしているのですから、データ量に頼った方法がだけがすべてではないと思います。いずれにしても研究の世界では流行を追うと(当該分野の国際会議や論文誌が多くなるので)論文を出しやすいのですが、研究の先頭を狙うならば逆張りも重要。個人的にはBig Dataの研究が流行しそう、という話を聞けば聞くほど、逆の方向に行きたくなります。

2010年12月11日

いろいろあって休日出勤。

2010年12月10日

ビックサイトで某見本市。といってもほとんど人と会うのが目的となっておりました。ところで某見本市は土曜だという人が多くてびっくり。展示会場をうろうろしていたら、前首相まで登場。至近で拝見することとなりました。いろいろあったにしても前首相なのですから「さん」づけしてあげればいいのに、近くにいた人はみんな呼び捨て。

2010年12月10日

秋葉原方面の某社に伺って打ち合わせ。ショールームに隣接した会議スペースなのですが、ショールームが興味深いのです。社名を出さずに数多くの商品を扱っている会社なので、へぇ〜が連発する状態。

2010年12月9日

午前中は特許事務所で相談。午後は某社で相談。

いろいろ書きたいことがありますが、ひととまず一つだけ。1968年12月9日はDouglas EngelbartがSan FranciscoのBrooks Hallで、コンピュータの歴史に残るデモをした日。GUI、ウィンドウ、マウス、ビデオ会議、ハイパーリンク。すべてが42年前の今日、いまのパーソナルコンピュータの多くの概念・機能が明らかになった日です。それにしてもユーザインタフェース系の主だった発明が1960年代後半に集中しているのはなぜなんでしょうね。

2010年12月8日

Windows Azureの国内普及状況に関するインタビュー記事が出ていたのですが、大丈夫なのでしょうかね。Microsoft関係者がここを読んでいるのを承知で書いていますが、この記事を読んでますます心配になってきました。

商用提供が始まってから10ヶ月がたったそうですが、記事も具体的な事例は一件だけ。それも技術検証レベルで、対外的に実施された実証実験でもないようです。ちょっと寂しくないですか。記事では普及に向けたハンズオントレーニングを強調していますが、Micorosoft自身が自社の主力アプリをAzureに移行する方がよほどAzureへの啓蒙になるはず。そうしないと自社はリスクは犯さずに、サードパーティにリスクを取らせているように見えてしまいます。

それと心配なのはVM Roleの位置づけ。VM Roleを提供すること自体はいいと思いますが、本流のPaaSの方への関心が減ってしまって、PaaSとしても中途半間、IaaSとしても中途半間になる可能性もあります。Azureとは違う看板でVM Roleを出された方がよかったように思います。このままいくとAzureはクラウド以上に意味が不明・発散した言葉になりかねない。

また、PaaSではアプリケーションのアーキテクチャが大きく変わりますし、それに対応したアプリケーション開発が必要でしょう。でもいまは高尚なアーキテクチャ論を語っている状況ではなくて、実用的なアプリケーションをその新しいアーキテクチャで作って、そのソースを見せる時期だと思います。

正直いってAzureに残された時間は短いと思います。VM Roleである程度の実績は出せるでしょうが、それでMicrosoftの強みを活かせるとは限らないし、むしろPaaS型のAzureの殺すことになりかねない。いずれにしてもPaaSでAzureならではサービスが早々に登場しないと開発者に見限られる状況になってきていると思います。いまAzureの普及活動を一生懸命にされている方々が、来年の今頃、机の上の私物を段ボールにいれている状況は想像したくないです。

2010年12月7日

大急ぎで原稿作成。某新聞の12月27日か1月4日に記事になるとか。

2010年12月6日

先週に引き続き夜は急遽、某省に伺って打合せ(といっても今回の案件でも自分がもらう予算ではないのですがね)。想定外で、霞が関には似つかわしくない服装だったので、警備員さんに疑われ、担当者に受付まで向かいにきてもらう。

例年だったらこの時期は来年度予算はおおかたフィックスしていますが、政策コンテストの影響で財務省交渉が続いている御様子。さて書けないことも多いので議論を省きますが、個人的には産業政策という時代でもないと思いますが、産業政策が難しいのは、その政策の結果、うまくいった事例を探して伸ばすことよりも、うまくいっていない事例をきちんと淘汰させること。これを政策立案段階で淘汰させる仕組みを仕込んでおかないと、弱者対策で終わってしまいます。もっとも、この状況は科学技術政策も同じで、大型予算の研究助成の場合は、うまくいっているプロジェクトと、そうではないプロジェクトが出てしまいますから。

2010年12月5日

VAIOノートのOSをWindows VistaをWindows XPに戻す。正直いって素直に使いやすい。ただ、コンピュータサイエンスの研究者としては同時にOS発展について悩んでしまいます。

学術振興会のPDタイプの特別研究員の縮小・廃止の話があるようですね。個人的には博士就職後に国立大学助手(それも実質的には助教授扱い)で採用していただいたので、PDの経験はありません。ただ、博士課程の3年間は同じ特別研究員でもDC1を頂いていました。PDはアカデミア研究者のキャリアパスの一つなので残してほしいところですが、助教ポジションの新設、GCOE制度の開始の時点で、PDも制度の見直しが必要だったかもしれません。特任を含めて助教の人事は博士取得が前提ですが、助教ポジションができる前は、博士課程の学生さんを博士号をとるまえに助手に採用しておいて、博士取得というキャリアパスがあったのですが、現状の助教ポジションとPDは資格(博士号取得)の違いがなくなってきた。それと一部の大学はGCOE制度などでポスドク人件費をもっているので、GCOE予算で雇われる方も多い。もちろん趣旨も制度も違うわけですが、助教とGCOE制度を始めるときにPD制度の位置づけを見直しておけば、こんな事態は避けられたかもしれません。もちろん結果論になってしまいますがね。

前回の事業仕分けでは「(PDは)ポスドクの生活保護のようなシステム…」という過激なコメントがあったそうです。ただ、博士取得者やポスドクさんの就職難から、「予算措置をしなければ博士取得者が失業してしまう」という論法で、なりふり構わずポジション作りをしたことの反動がきてしまった部分があると思います。少なくても、その論法だと端から見ると生活保護的に見えてしまうかもしれません。ところで事業仕分けのコメントに関しては、その一部だけを切り取って感情的に非難される方が見受けられますが、当該評価コメントを読むとわかるように全体趣旨は若手支援制度における制度面の重複を問題視しています。

2010年12月4日

私事でひたすら片付け作業。さすがに疲れました。ところで一日遅れになりますが、NASAが発表したヒ素で生きる生物は興味深いですね。もしかすると人間を含む生物がリンを使うのも何らかの適応性の結果かもしれませんしね。噂された宇宙人発見ではありませんでしたが、わくわくさせる発表でしたね。

2010年12月3日

ひたすら打合せの日。話題が違うので頭の切り替えがたいへん。夜は某省に伺ったのですが、予算絡みで週末も徹夜だとか。例のパブコメも、パブコメを書く方はいいたいことを書けばいいわけですが、それをうけて財務省折衝する方々はたいへんですね。それにしてもパブコメ対応戦略で省によって明暗が分かれた感じ。当方が頂いている予算もパブコメに対応になったわけで、他人事ではないのですが、パブコメはプレゼンスを出すために、ある程度の数は必要でも、数が多ければいいというものでもないのも事実。すくなくても予算というのは予算に関わる関係者が多いからとか、受益者が多いからという理由で措置するものではないですからね。

ところで夕方の打合せでも話題になったのは、短期または長期において納税者の利益になるという観点からの「予算の必要性」と「予算の有効性」の違い。それと先の事業仕分けでも、例えば「科学技術予算は何に有効なのか」を問われているのに、「科学技術予算は必要」という立場で回答するからかみ合わないことになります。今回のパブコメでは研究者からのコメントも多かったそうですが、「科学技術予算は必要」という前提にしたコメントが大部分だったとか。科学技術予算については「有効性」まではコンセンサスはあっても、「必要性」というのは研究者以外にコンセンサスがあるかは疑問ではないでしょうか。少なくても今回のパブコメは対財務省向けなのですから、当該省庁が財務省への説得材料になるコメントに書くべきなのに、当該省庁への不満や非難を書いたら逆効果だし、事業仕分けの不満を書く場でもないはず。

2010年12月2日

午前中は人と会う用事もあり、横浜で開催されている組込系の見本市(ET)。この見本市はビックサイト時代から、ほぼ毎年いってるのですが、閑散としていた昨年よりは復調している感じ。それにしてもAndroidの展示が多いですね。ただ、展示している方に伺うと「Androidというと人が集まるから」だそうです。GoogleはAndroidをスマートフォン向けOSと捉えているのかもしれませんが、本来のターゲットははフューチャーフォンや組込系のはず。でもAndroid搭載のフューチャーフォンがあまりでてきませんね。

結局、日本のガラパゴス携帯電話がいい例なのですが、フューチャーフォンは雑多な入出力デバイスをいろいろつけています。新型の携帯電話でも、こうした入出力デバイス用の制御プログラムは過去に作られたものを使い回しをしており、Android向けに、搭載しているすべての入出力デバイス用の制御プログラムをAndroid向けに用意できるかというと現実的には難しい。逆にスマートフォンはタッチパネル主体で、入出力デバイス的には非常にシンプルなので、Android向けに制御プログラムをかいてもたかがしれています。

ところでAppleがiOSの外販をはじめたら、Androidはどうなるのでしょうね。使い勝手などを考えると、AndoridがiOSを上回る部分は多くなく、iOSを採用するスマートフォンメーカも出てきそう。まぁありえない状況なのですが、これが起きると本当に怖い。

2010年12月1日

ここに高らかに宣言しますが、今日は11月31日です。

はなしは変わって、先週の報道発表から一週間経ったのですが、メディア掲載数は16件。 まだしばらくは増えそうな雰囲気。

2010年11月30日

最近はJavaが凋落気味ということもあり、今後のどのプログラミング言語が流行るかの議論が盛んですね。なんか楽しそうなので、ちょっとだけ参戦。結論からいうと、プログラミング言語の善し悪しは、プログラマーにとって金なるか否か、だと思っております。例えばJavaが流行ったのも、Javaが使えるプログラマーには職があったことと、給料もそこそこ良かったからでは。こういってしまうと元も子もないので、いいかえると生産性。あるプログラミング言語の生産性が高ければその言語を開発に採用する企業も増えるので、その言語を使えるプログラマーの需要が増えます。生産性が高ければ給料を高めにしてもよい。

ただ、ここで重要なのは、いまはプログラミング言語がソフトウェア開発の生産性を決める時代ではなく、IDEやツールを含む開発環境全体であり、言語はその一部に過ぎません。つまりプログラミング言語そのものより、IDEやツールが完備されたプログラミング言語が重視される時代。例えばIDEと相性の悪い言語は敬遠されるし、テスティングの自動化がたいへんな言語も厳しい。

それとプログラミング言語は、英語などの自然言語と同じで、言語習得コストが大きいのですが、海外に住んだときに言語以上に、生活習慣や文化のギャップに戸惑うように、プログラミングする環境、つまりIDEへの依存性が高い。つまり言語の壁よりもIDEの壁の方が高い。だから複数のプログラミング言語を扱えるバイリンガル的なプログラマーでも、慣れたIDEから別のIDEにかえることはできない人が多い。その意味ではIDEやツールが言語を決める時代かもしれません。

また、Javaの総称型がいい例ですが、複雑な記法のために、手書きで欠ける人は少なく、多くの人はIDEに頼っていると想像されます。いいかえるとIDEが言語仕様に影響をあたえる時代だし、極端なことをいうとIDEが勝手にプログラムの見かけをかえることができるわけで、プログラミング言語の文法などはどうでもいい。

何が言いたいのかというと、プログラミング言語の善し悪しは生産性(金になるか)だし、そのプログラミング言語と、IDEやツールが不可分になっているし、言語よりもIDEが主になろうとしている時代。プログラミング言語だけ取り出して議論しても意味ないです。それとプログラミング言語を自由に選べるのはアカデミアの研究者か学生さんぐらいなのですよね。

2010年11月29日

先週の報道発表ですが、日経MJにも記事が掲載されたそうです。よって日経新聞の3紙全部(日本経済新聞、日経産業新聞、日経MJ)で記事にしていただいたことになります。3紙全部で記事なるのは少ないそうなので、注目していただいたということでしょう。もちろん研究はメディア掲載数よりも中身です。

昨日に続いてカメラの話。明日の11月30日は「カメラの日」だそうです。その理由はコンパクトオートフォーカスカメラが発売された日だからだそうですが、米国ではこうしたお手軽カメラをVacation Cameraと呼ぶそうで、それを日本に輸入したときにわかりやすいように「バカチョンカメラ」にしたとか。でも差別用語と勘違いされて、いまではNGワードですね。

2010年11月28日

今週末は珍しく休日出勤はナシ。というかれん久しぶりにカメラを引っ張り出す。普段はキヤノンのデジタルカメラを使っておりますが、もっぱら50mm F1.4レンズばかり、キヤノン純正(EF50mm F1.4 USM)、Zeiss (コシナ製造のPlanar T* 1.4/50 ZE)、ニコン(Ai Nikkor 50mm f/1.4S)の同じ50mm F1.4を付け替え(どれも6群7枚構成)。Zeissはコシナ製造の最新版。写りはキヤノン純正の50mm F1.4と似ているのですが、Zeissは常用しているレンズなのですが、Planarだけあって平坦性が高いというのか、中心部以外も解像しますし、前後共にボケは柔らかい。それに対してキヤノン純正は中心部の解像はいいのですが、周辺はやや落ちる傾向。ダブルガウスに近いレンズ構成だから仕方ないのでしょうが、普通の写真、つまり中心を焦点を合わせる限りは写りはいい。両者は結構似た写り。ニコンは同様にダブルガウスなのですが、レンズ設計が古いこともあり、ちょっとボケがうるさいのと周辺光落ちから、2段ぐらいに絞って使うべきかも。とウダウダと書いてみたものの、こうしたカメラマニア的なウンチクは苦手。だいたい撮った写真もレンズの違いは見比べないとわからないし、写真は写す対象できまりますから。

2010年11月27日

このページはAgentSpaceというモバイルエージェントの開発履歴のページだったのですが、一週間前にHadoop関連イベントに講演で呼ばれたときに、久しぶりぐらいにモバイルエージェントをデモすることになり、実はそのデモ用にAgentSpace用の例題を書き足したのでWebにおいておきます。なお、そのイベントではモバイルエージェントによるMapReduceの実装もデモしたのですが、そのMapReduceの実装もいれてあります。2時間弱で作った超手抜き実装ですが、この実装からMapReduceやHadoopの発展方向性を見いだすかは使われる方しだい。なお、デモ用ということもあり、MapReduceの動作そのものは見えやすく作ったつもりなので、MapReduceの動作を理解するにはいいかもしれません。スクラッチから作ったので、Hadoopなどのコードは使っていません。

まぁ、MapReduceモバイルエージェントをきちんと実装し直せば、修論ぐらいにはなるかもしれませんね。また国内論文誌ぐらいには通るでしょう。今回の実装では、ある程度、Mapperは処理に非依存、Reducerも大きく依存しないようにしたので、MapperとReducerがアプリケーション依存になりやすい、Hadoopよりも汎用性をあげられるはず。それとReducerもマイグレーションできますし、多段MapReduceも作れるでしょう。

また前にも書きましたが、MapReduceは処理そのものは簡単ですから、自前でMapReduceを実装するのもいいと思います。オープンソース全盛の時代となり、既存ソフトウェアのソースを読める時代になりました。でもソースの裏に隠された設計思想はソースを読むだけではわからないことも多く、むしろ自分で作ってみるとわかることも多いです。

2010年11月26日

一昨日の報道発表ですが、日刊紙では今日は電波新聞に記事が掲載されてました。業界紙系は週明けみたいですね。報道発表で中断していた仕事を再開・処理中。まずは論文査読を片付ける。査読にした論文はどれもおもしろいのですが、論文発表を急ぎすぎ。中堅国際会議ならばともかく、当該分野のトップ国際会議(今回はIEEE PerComのプログラム委員)だと中途半端な成果はネガティブ評価になりやすい。夜は自分の論文。こちらも報道発表で中断していたのですが、締め切りも延びたので間に合いそうな予感。

2010年11月25日

朝日新聞のニュースでイギリスとイタリアにおける教育予算削減に対する学生の抗議活動が記事になっていました。ギリシャ通貨危機をうけて欧州各国は大幅な政府予算削減。イギリスの抗議活動の発端は授業料の値上げ(大学の授業料の上限を3倍に引き上げ)への抗議でしたが、その背景にはイギリス政府予算で教育関連は17%近く削減になり、その結果、大学への助成金は40%近い削減になります。イタリアでも教育予算は19%削減。フランスでは年金改革と教育予算の削減のためにデモは高校生まで拡大している状況。米国も先の中間選挙で、小さな政府に動き始めており、実際、州政府レベルでは大幅に予算削減に動いており、多くの州立大学が授業料の値上げと州予算のカットが同時進行中。

欧米における予算削減状況と比べると日本はまだまだ恵まれているわけで、研究予算に対する事業仕分けに対する一部の学者による不満は、妥当な部分もありますが、世界情勢を考えると学者の世間知らずととられてもしかたない部分があります。

数年前、Thomas L. Friedmanの「フラットな世界」という書籍が話題になりました。グローバリゼーションにより、世界経済は一体化して、世界中が同等な条件で競争する時代が訪れることを予想しています。つまり農業製品も工業製品も世界規模のマーケットの中でひとつの価格に収斂していくことになります。これは先進国においてはデフレという現象があらわれます。企業は売上げも下がり、新興国を含む海外との競争により利益が上がらない。そして賃金は下がることになります。この結果、先進国に住む我々としては遠い国の問題と思っていた貧困問題も、グローバリゼーションとともに我々の身近にやってくることになります。少なくても先進国に住む我々の生活水準は、今後、下がることはあっても上がることはないのではないでしょうか。

昨日は排出量取引に関する報道発表をさせていただきまいた。幸いにしてWeb系ニュースメディアに加えて、日刊紙でも確認しているだけでも、日本経済新聞、日経産業新聞、日刊工業新聞、化学工業日報に記事を掲載していただきました。先述の政府予算の削減、そしてCO2を含む温室効果ガス排出削減により、我々の経済活動や生活は制約されていくと思います。そうした状況の中で、可能限り現状の豊かな生活を維持する方法として研究させて頂いており、環境問題に関心があるというわけではないです。排出量取引に着目した理由も、どうしても避けられない経済活動や生活の制約に対する補償メカニズムとして排出量取引の考え方が役に立つと考えているからです。

実際、情報技術は、政府予算の削減や温室効果ガス排出の削減のなかで、社会を効率化して、生活水準を維持するための有効な手段になると思っています。コンピュータサイエンスの研究者としては、世界で一番速いスパコンを作るより、社会基盤を作ることに注力していきたいと思っています。情報技術が社会に不可欠になった今、情報技術は社会を変えられます。速いコンピュータや速いネットワークを作るだけが、コンピュータサイエンスの研究者の仕事ではなく、社会をよりよくすることにも貢献できると思っています。そして昨日の報道発表させて頂いた研究はその一歩に過ぎません。

2010年11月24日

報道発表。ICタグを使った排出量取引の研究を総務省予算でさせていただいていることは、ここでも何度か書きましたが、このたびセブン&アイ・ホールディングス様の御協力をいただき、イトーヨーカドーの一部の店舗で実証実験をさせていただくことになりました。また、今日は報道発表に先立ち、その実験のための協議会の設立総会もあり、総会に総務省の技術政策課長様、凸版印刷の専務取締役と取締役、日本ユニシスの常務、セブン& アイ・ホールディングスの役員、ポッカコーポレーションの取締役にお越しいただきました。当方の小さなアイデアから始まった研究でしたが、多くの方の賛同・協力をいただいき、大きな実証実験になることは本当に感謝しております。実証実験は来年の2月でございますが、心を引き締めて研究をすすめていたきたいと思います。なお、報道発表内容はこちらのページをご覧下さい。

なお、同日中に掲載していただいたメディアはWeb系のニュースサイトで日経BPの記事マイコムの記事です。明日はいくつぐらいの日刊誌で取り上げてくれるでしょうか。

2010年11月23日

普段、携帯しているコンピュータをかえてみました。まえのマシンが不調になったため。最近のコンピュータは性能的な理由ではなく、故障したからなどの理由で機種更新することばかり。それにしてもコンピュータってデザインだけですよね。ハードウェアとOSが同じ会社のMacintoshはともかく、Windows PCはハードウェアのデザインとOSに親和性があるPCを見かけないのですよね。いっそのことMicrosoftがPCの筐体デザインして、それをライセンス化して、その生産と販売をPCメーカに任した方がいいように思います。PC業界の水平分業という考え方を崩すことになりますがね。

2010年11月22日

24日のイベントの準備に向けて打合せが続く日。夜は勤務先の事務方にいろいろ仕事をお願いしつつ、こちらも準備作業。夜遅くまでご苦労さまでした。世の中はiPhoneやiPad用のOSの新版を公開したことが話題になっていますが、iPhoneもiPadも持っていない当方には関係なく、うらやましくみているだけ。タイミングを逸しているわけですが、やっぱりほしいです。

2010年11月21日

平常通りに休日出勤です。仕事量に時間が追いつかない。いわゆるピンチな状態です。

2010年11月20日

休日出勤、明日も休日出勤ですね。昨日、ひさしぶりにモバイルエージェントのデモをしたわけですが、よくきかれるのが、モバイルエージェントでないとできないものはあるのか。モバイルエージェントは、あくまでも分散システムの実装技術ですから、モバイルエージェントでないとできないものは少ない。ただ、一つをあげるならばコンピュータというハードウェアよりも寿命の長いソフトウェア。どれだけ安定かつ頑丈なソフトウェアでも、それを実行しているコンピュータが壊れたら止まってしまいます。つまりコンピュータよりも寿命の長い、実行中ソフトウェアはありませんでした。ただ、モバイルエージェントのように実行中ソフトウェアが他のコンピュータに移動できると、コンピュータが壊れる前に他のコンピュータに逃げれば、ソフトウェアは実行し続けることになります。

こうした実行期間が長いソフトウェアは実現できなかったし、そもそも需要も少なかったといえますが、ソフトウェアをサービスとして提供するようになると、サービスの継続性、つまろソフトウェアの実行の継続性が求められるはずです。コンピュータの寿命よりも長時間実行し続けるソフトウェアというのは必要とされるのではないでしょうか。その実現方法はいまから考えておいた方がいいと思います。もちろんモバイルエージェントの技術を使うこともできますし、我々の体を構成している細胞のように常に入れ替わらせる方法もあるでしょう。いずれにしてサービスの寿命が、コンピュータの寿命よりも長くなってしまう時代は間違いなくやってきます。

ところで、映画のMatrixの二作目で、古いMatrixから生き続けるソフトウェアが登場したのを覚えているでしょうか。そうしたシステムの片隅で、コンピュータのリブートやリプレースを逃れて、生き続けるソフトウェアはありえるかもしれません。なお、映画のMatrixはモバイルエージェントでないと実装できないはず、と思っているのですが、この話はまたいずれ。

2010年11月19日

来週の報道発表準備。夜は皆様に作業をお任せして、Hadoop関連のイベントで1時間講演とパネル討論。プレゼンはともかく、デモは多くの方にそのメッセージが伝わらず大失敗。昨日も書いたモバイルエージェントでMapReduceを実装したのは、このイベントのためだった。いただいた質問は多かったのですが、モバイルエージェントとMapReduceの関係性に関する質問はゼロ。あとで講演中のTwitterも見てみたのですが、残念ながら、この関係性に関する指摘は皆無でした。当方のデモに問題があったのかもしれませんが、Hadoopのイベントで、掴みのためにだけに、わざわざモバイルエージェントのデモするわけなく、裏読みしてほしかったですね。

なぜモバイルエージェントでMapReduceを実装したのかという、MapReduceもHadoopも閉じたシステムだから。Googleは膨大なデータを集め、膨大なサーバでMapReduceを振り回しています。それ以外が対抗しようとしたら、データとサーバをシェアするしかないのです。しかし、MapReduceもHadoopも、クラスタ内で閉じたシステムとして構成することを前提にしており、他のクラスタのデータやサーバを共有する仕組みがない。GoogleのMapReduceについてはGoogle自身を閉じたシステムなので、それでもいいわけですが、HadoopについてはHadoopクラスタ同士で、データやサーバを共有する仕掛けを提供しない限り、MapReduceもどきからは抜け出せないし、少なくてもHadoopを使う側もGoogleに勝てない。それでは複数Hadoopクラスタ間でデータやサーバをシェアするにどうすればいいのかを考えると、モバイルエージェントそのものではなくても、近いアプローチになるはず。それが今日のメインメッセージのひとつでした。モバイルエージェントとMapReduceの組み合わせが一見、不自然なので、絶対に質問されると思っていたのですがね。

学会のデモでも同じですが、デモはコミュニティによって効果が違うんですよね。デモは実現したいことのほんの一部として、全体像を想像するコミュニティもあるし、木を見て森を見ずといいましょうか、デモそのものの細かい部分に関心をもつコミュニティもあります。もっとも最初にいただいた質問だったと思いますが、VMのLive Migrationの話を持ち出されたときは、さすがに途中で帰りたくなりましたがね。

2010年11月18日

日経BPの記事で、Googleに関する当方がコメント「強大化している機械学習マシン」が引用されたのですが、端から見る限りGoogleの基本的なやり方は、元となるデータを集めるだけ集める、データ解析に凝った手法を使うよりもサーバ数で勝負。そしてそのデータ量もサーバ数も増加しているわけですが、ここまでくると増え続けるサーバ数のためにデータという餌を与え、その結果、サーバ数を増えているという感じでしょうか。Googleについては、この記事はたいへんよく書いてあるので、このページを読まれるより記事をご覧になった方がいいと思います。

ところで明日の1時間講演で、久しぶりモバイルエージェントのデモをするといってしまった手前、デモの仕込み。このところ別件で忙殺状態で、深夜になってから慌ててプログラミング。何をデモするかですが、Hadoop関連のイベントだったので、例題はHadoopのもとなったMapReduce。つまり「モバイルエージェントでMapReduce」。

MapReduceのコアのところに限れば小一時間で実装できると踏んだのですが、モバイルエージェントの実装は数年ぶりなので勘がなかなか戻らず、結局、1時間40分ほどかかって実装。とはいえモバイルエージェントは分散システムのオーバーレイネットワーク的なところがあり、分散処理を手っ取り早く作るときは楽です。なお、MapReduceの対象は、Hadoopに倣ってWord Countにしてみましたが、結局、Hadoopのソースは見なかったので、(モバイルエージェントのランタイムを使っているとはいえ)スクラッチから作ることとしました。MapReduceというと難しそうですが、コアの処理そのものはシンプルなので、そこに限定すれば難しくない。

MapReduce的な処理をするならばHadoopを使えばいいのでしょう。MapReduceに限らず、簡単でいいので、自分で実装してみると、ドキュメントやソースを読んでもわからないことがたくさん見えてきます。今回はMapReduce実装する前に、ざっとMapReduceの論文をもう一度読んでおいたので、実装する立場で見るといままで気がつかなかったことが見えてきました。Hadoopはよく実装されていると思いますし、Hadoopのソースを読むことは価値はあると思います。ただ、自分で実装してみないとわからないことも多い、つまりHadoopのソースを読んでいるだけではからないことがいっぱいあるはずです。実際、2時間弱の実装でしたが、論文になりそうなネタは3,4個は見つかりましたから。

2010年11月17日

流通系の業界団体で講演。ちょっと聴衆の関心事を講演内容にミスマッチがあったかも。反省です。ただ、当該内容の報道発表は来週なので、話せる部分と話せない部分もあるので難しいのです。

ところでFacebookが新しいサービス(Facebook Messages)に、HadoopのコンポーネントのひとつであるHbaseを採用するとか。自社開発のKey Value Store (KVS)であるCassandraは使われず。ただ、KVSは大規模データを扱うために、RDBMSのような強い一貫性ではなく、一貫性に制限があり、その制限はKVSによって違ってきます。つまり一貫性モデルがKVSによって違うのです。一方、KVSを使うアプリケーションは、数あるKVSの中から、そのアプリケーションの要求にあった一貫性モデルを提供するものを選ぶことになります。Facebookの今回のアプリケーションに最適だったのがHbaseが最適だったのでしょう。

ただ、Cassandraに関しては2点ほど疑問がありますね。1点目はCassandraの一貫性モデル。先述のようにKVS はその一貫性モデルで選ばれるので、一貫性モデルは変えるべきではないのですが、Cassandraはロードマップで別の一貫性モデルの実装をあげました。これはアプリケーションからみるとコアのところが変わることになりますから、Cassandraを採用しにくくしてしまった。その意味ではギリシャ神話のCassandraは、往生でありながら、予知能力が故に、トロイの不幸な将来を予知して、人々から敬遠されるわけですが、KVSのCassandraもロードマップ上の予知のために敬遠されている状態かもしれません。

2点目はこのページで前にもかきましたが、その新しい一貫性モデルがVector Clockベースであること。Vector Clockは論文こそたくさんありますが、ノード数が増えると性能が落ちるので、大規模データを扱うためにノード数が多くなるKVSには向かない技術。実際、KVSに限らず、Vector Clockを実システムに使っている事例は皆無のはず。

2010年11月16日

ScalaやErlangのおかげでActorが流行っていますね。正直いって20年間のデジャヴーを見ているよう(といっても正確には20年前は知らないけど)。最近の論調だと、Actorだと並行プログラムが書きやすいということになっていますが、Actorというのは並行オブジェクト(各オブジェクトが能動的に動く)の中でもシングルスレッドオブジェクトと呼ばれるタイプ。つまりオブジェクト内のスレッドが高々一つ。ちなみにオブジェクト内のスレッドが複数あるオブジェクトをマルチスレッドオブジェクトといいます。

シングルスレッドオブジェクトは並行処理の難しい部分、例えば同期処理をオブジェクトの外に出しているのに対し、マルチスレッドオブジェクトは外側に加えて、内側でも同期処理などをしないといけません。このためプログラムが複雑化しやすい。

また誰が同期などの並行処理を書くのかということ。マルチスレッドオブジェクトでは各オブジェクトの開発者が並行処理を書きますが、シングルスレッドでは各オブジェクトの開発者が並行処理を書くことはなく、並行処理はオブジェクト間の連携を設計する開発者に任せればいい。人数を考えると各オブジェクトを定義する開発者の数は多くなりますが、オブジェクト間連携を扱う開発者は少数。そもそも並行処理は誰でも書けるはずはなく、並行処理がかける開発者が少数で済む、シングルスレッドオブジェクトは有利になります。

20年前のシングルスレッドオブジェクト派の研究者とマルチスレッドオブジェクト派の研究者で散々議論がされたのですが、結果としてはマルチスレッドオブジェクトが優勢となりました。その理由のひとつは例外処理のしやすさ。シングルスレッドオブジェクトは綺麗にプログラムが書けるのですが、例外処理もシングルスレッドで処理しようとするとオブジェクト間連携が複雑になるのです。いまはマルチスレッドオブジェクトからシングルスレッドオブジェクトへの揺り戻しが起きていますが、歴史が繰り返すならば再びマルチスレッドオブジェクトにもどる可能性もあります。

2010年11月15日

目が回りそうな一日。あまり勤務先の内実は書かないようにしていましたが、今回の一件はすぐに世間の知るところになるのでちょっとだけ。研究系職員の共通FAXが突然撤去、そして番号変更。FAXとはいえ、事前予告なしで通信宛先変えてしまうというのが、情報系研究機関の情報リテラシィなのでしょうね。個人的には先週、名刺の印刷を頼んだばかりで、その対応。結局、事務方と相談の結果、名刺の方は新しい番号で再発注ということになりましたが、事前に通知してくれれば避けられた出費であり、もったいないですよね。企業だと部署の名称が変わるのは日常茶飯事なのでしょうが、メインのFAX番号を変えるのはそれなりの準備されますよね。

ところで、この時期になるとスパコンのランキング話題になります。でもこのランキングは自動車でいうと平坦な直線コースでの最高速度の競争みたいなもの。それも重要なのでしょうが、実際の道路はカーブがあったり、坂道があるわけで、単に最高速度が速いからといって、性能のいい自動車とはいえません。もちろん最高性能強も重要だとは思いますが、実際の効用で争って欲しいです。

そもそもランキングを狙ってスパコンを作っているわけではないはずだし、ラインキングが高かろうと、低かろうと、対象のスパコン自体の性能が変わるわけではないのですから、その性能のなかで精一杯、必要とされる計算をしてくれればいいのにね。なのに関係者がランキングに妙に拘るから、世間までミスリードしてしまっているように見えます。

昨年の事業仕分けで「一位でないと・・」という発言がありましたが、そもそも必要な処理をこなすのに必要な計算能力をもったスパコンと説明すればいいのに、上位にランキングされることを目標に置くので、例の発言が出てくることになる。さすがに懲りたのかなぁ、と思ったのですが、今回もスパコンのランキングが発表されると、関係者の皆様は何位だったかを話題にしたがる。だから世間もランキングしか見なくなる。

2010年11月14日

平常通りに休日出勤。ありえないほど仕事が多いわけですが、こちらが倒れるか、切り抜けられるかの競争状態。こういう状況では企業の方はうらやましいですよね。仕事を振り分けられるわけですが、研究機関だとそうもいかず、研究代表者=事務局実働部隊となります。

2010年11月13日

フランス出張断念。スケジュール的にはいけても、スト多発している状況で、仮に帰国が遅れると日本国内の用務先に迷惑がかかるんですよね。それでなくもてスケジュール的な理由で、9月にはいってから国際会議発表を2件断念、打合せ1件断念。忙しいとか文句をいいながらも、それでも海外出張に行ける人がうらやましい。

2010年11月12日

とある作業の過程で「MS-Wordは苦手」と開き直ったら、「得意な人なんていない」と逆襲されたのですが、確かにMS-Wordの達人という人はきかないですね。もしかするとMS-Wordは学習曲線はどこかで上げ止まりになっている可能性はあります。アプリケーションが道具であれば習熟度に応じてパフォーマンスが上がるように作るべきですが、そうした設計にはなっていないのかも。その意味ではAdobeはIllustratorやPhotoshopなどの熟練者がいますが、このあたりの設計思想が両社の違いになっているのかもしれません。世界的にもMS-Wordで作業している人は多いのですから、トヨタ流のストップウオッチ片手に調べる手法でもなんでもいいですから、MS-Wordの道具としての無駄は徹底的に減らして欲しい。

2010年11月11日

昨日は睡眠時間が2時間弱だったのですが、今日も徹夜確定状態。なんだかね。複数の仕事が同時進行状態で、時間ないのよね。それと研究者って、体力勝負ということを痛感する日々。でも本当の修羅場は来週と再来週。

2010年11月10日

今日も霞が関。今月にイベントと報道発表があり、その準備で奔走中。物理的にも奔走状態。毎日、二カ所以上に外出。その間、書類作成。なお、イベントも報道発表も自分の研究の実証実験絡み。皆様のおかげで学術研究の実証実験域をこえる大がかりなものになりそう。

2010年11月9日

早朝出勤、それから今月開催予定の報道発表のために、勤務先の広報担当者とともに某社に伺って打合せ。いったんオフィスに戻って霞が関、またオフィス。APEC対策で厳戒警備。昨日同様に霞が関は警官さんが多いのですが、密度に関してはオフィスの周囲の方が高い。勤務先のビルがあるブロックだけでも何人いるんだろう、という状況。それにしても移動が多い割に、オフィスも用務先も千代田区内という日々ですね(行動半径が狭すぎ)。

ところで先日、モバイルエージェントシステム(AgentSpace)を微修正したのですが、深夜、拡張をはじめてしまう(拡張というよりは別に作りたいミドルウェアの事前実験)。いまプログラミングをしている暇がないのはわかっているのですがね。

2010年11月8日

警戒厳重な霞が関でお仕事。結局、2回に霞が関に行くことに。ところで最近、研究者の評価基軸が話題になるのですが、定番の評価基軸の論文数も論文参照数の絶対ではない。当方の場合、分散システム絡みの研究をしていましたが、分散システムの研究だと参照数と実用性に相関がないというか、むしろ逆比例になることも多かったり。

例えばPaxosという分散合意アルゴリズムがあります。1990年ぐらいに提案されました。その提案した本人だけではなく、多くの人が論文ベースで改良・拡張を試みました。当然、論文参照数は増えます。しかし、Paxosを実システムで使っている事例は皆無といわれます。分散アルゴリズムの場合、コンピュータサイエンスでも理論系の研究と同じで、机上の議論。だから、実システムでは実用に耐えない提案でも机上研究だけは進んでしまいやすい。この例はPaxosに限らずVectorクロックなど事例がいっぱい。

それと学術研究では本質的な新規のアイデアはごく僅かで、残りの既存研究への改良・拡張。ただし既存研究に対する改良・拡張は既存研究に問題が多いほどやりやすい。だからアイデア的にはおもしろいけど、課題が多い研究ほど、関連論文が増えて、それに伴って参照数が増えることになります。だから実用化が難しい研究ほど盛んに研究される事態になってしまう。また、実用になっていない研究は必要な技術項目もわかっていないので、研究方向性が発散しやすく、やっぱり関連論文が増えて、それに伴って参照数が増えます。逆に実用になった研究は、その開発・発展の場が、学際から産業界に移りますから、論文数は伸びなくなることが多い。論文数や参照数も重要だとは思いますが、それだけで評価していたら、実用になる研究は評価されないことになりかねない。

この問題はコンピュータサイエンスに限らず、どの分野でもおきうる問題。ただ、コンピュータサイエンスの場合は新規のアイデアが提案されて、10年経って、関連論文がたくさんあるのに、なかなか普及しない技術は何らかの問題があるのだと思いますし、そのとき当該分野の論文数と論文参照数はむしろネガティブ指標とみることもできてしまう。こうしたことを書くと基礎研究軽視だとか、お偉い先生方から怒られるわけですが、論文数や参照論文数は研究的な価値の指標にはなりえると思いますが、研究の実用性と指標といえるかというと、それは単純ではないと思います。最後に当方も研究者としては論文数は参照論文数は重要だと思いますが、それらは評価基軸の一つに過ぎず、多面的な評価が必要なはずです。

2010年11月7日

平常通りに休日出勤。徹夜覚悟したものの夕方にはおわってやれやれです。ところでこのページは、1998年頃、AgentSpaceというモバイルエージェントの開発履歴を書いていたページでした。ただし、ここ10年間ぐらいは雑談ページと化しております。今日は久しぶり(5年ぶりぐらい)に当初目的の、AgentSpaceの開発履歴。現行版AgentSpaceはJava ver.6で動かない、と怒られていましたが、ちょっと手直し( メソッドを直しただけ)。あと変数名とJavaの新設キーワードとぶつかってコンパイルできない問題も修正。その修正版はここから辿れます。なお、正直いってメンテナンスしている余裕はないし、ここしばらくは研究的にもまったく違う方向にいっているのです。不具合は各自修正ということでお願いいたします。

こう書くとモバイルエージェントに興味がないと思われますが、いまでもモバイルエージェントは筋のいい技術だと思っていますし、ですし、卒論や修論で研究されるのはいいのではないでしょうか。ただ博士の場合は新規性を出すのはちょっと工夫が必要な気もしますけど。個人的にいうと、これまでいろいろな研究をしましたが、研究していて一番楽しかったのはモバイルエージェントでしたし、もう一度、研究する学術的な価値もあると思っています。

2010年11月6日

Twitterは流行っていますね。使わずにとやかく言うのはよろしくないので、1年ちょっとほどTwitterをしてみたのですが、一番印象としては共感ベースのコミュニケーション環境ということでしょうか。二番目は反対意見が汲みにくいメディアということでしょうか。心象的なことをいっても仕方ないので、そう思った背景を少々。

(1)140字という制限があるので、「みんな仲良く」とか、「街をきれいにしましょう」とか大義名分的で、誰も反対しにくいことを書き込まれる方が多い。また心情的な共感が形成できれば十分という書き込みが多い。

(2)匿名性があまりないということはあると思いますが、TwitterというよりもSNSにありがちな問題ですが、何かを書いたコメントに対するレスポンスがあっても、書いた本人が見るのはフォローしているユーザ、つまり書いた本人がセレクトしたユーザですから、比較的意見が近いユーザ層。だから反対意見に接する機会がすくない。いいかえれば、自分の意見が反対されないから、気持ちよく書き込みができることになります。

(3)議論が深まらない。文字数が少ないので、自分の意見をいっているだけで、議論になっていない。他人の意見をベースに持論を書き込むにしても、その他人とコンテキストを共有することが前提になってしまう。また文字数の制限から、せいぜい一人の書き込みにレスポンスできても、複数人の書き込みにレスポンスするのはむずかしい。Twitterは仕事(例えば研究上の議論) に使えるかと期待したのですが、その意味ではがっかりでしたね。

(4)業界ネタ的な書き込みが好まれる。当方も一部の専門家しかわからないことを書き込んでみると、お気に入りや公式RTされやすい。Twitterの場合、仕事に合間に書き込みをされる方が多いのか、その仕事を関わらないと知り得ない業界ネタ的な書き込みが多い。こうした書き込みをみていると、なんとなく、その業界の事情通になったような錯覚に陥りやすい。ネットで見えることなんてほんの一部なのですがね。

(5)同様に私事の書き込みが多い。これも生活の中で書き込んでいるから当然なのですが、ウケを期待するのか、フォロー数を期待するのか、プライベート情報をさらけ出している方を拝見すると痛い感じがしますね。

(6)過去の議論は顧みられない。議論は流れるだけだし、過去の議論はみるのには手間がかかる。だから「前に××いっただろう」みたいな議論にならないので、自分の前言に責任を取らなくてもいい、よく言えばお手軽、悪くいえば無責任なコミュニケーションといえます。

(7)フォロー数によってTwitterはその位置づけが変わりますね。当初はまわりのお勧めで始めたこともあり、内輪のコミュニケーション&情報収集ツールという位置づけだったのですが、フォロー数が1000を超えたあたりから、SNSよりも放送に近いという感覚になります。実は当初、フォロー数が1000を超えないとTwitterの真価はわからないといわれたのですが、これはその通りでしたね。

というわけで、いろいろ好き勝手を書きましたが、正直なところTwitterにちょっと飽きてきているのでした。文字数の制限や過去の書き込みの検索・参照の問題から、テクニカルが議論には不向きなのですよね。

2010年11月5日

打合せと書類作成の日々。さすがに睡眠不足がつらくなってきました。眠いといいながら、夜更けに、頼まれていた旧作ソフトウェアの不具合の修正を始めるものの、これがはまる。Javaものですが、直列化まわりの不具合はエラー情報から問題が特定できず、よくわからない。そのうえWindows XPでは動いても、Windows 7では動かないという謎の状況。

2010年11月4日

眠いなか書類作成。二晩連続徹夜仕事は厳しいので、3時間ほど眠って、朝まで貫徹仕事。ただし、深夜残業を続けると怒られるのでオフィスにはいかず、自宅でお仕事。ところで米国中間選挙は民主党の大敗となりましたが、米国大学は予算ドリブンの研究をする傾向が強く、国際会議などの研究トレンドに反映されやすい。情報系の場合、オバマ政権後はスマートグリッド系の研究が流行ったために、米国大関係者は自分の研究をスマートグリッドに絡めようと努力されていましたが、共和党が強くなると軍事系に絡める方が多くなりそう。

2010年11月3日

休日出勤、そのまま徹夜残業。それしか書くことがありません。また事務に怒られるんだろうな。まぁ休日出勤や深夜残業も数が増えるといろいろ問題が起きるわけで、申し訳ないのです。でもね、そうでしないと仕事が終わらないのですよね。

2010年11月2日

Amazonが送料無料化だそうですね。これまでも送料無料サービスをしていたので、実質的に変化はないですがね。それに送料無料化すればその分価格に上乗せされるだけなのですが、買いに行くよりは安くつくのかも。そうなると実店舗を含めて関連業界には痛いでしょうね(これの続きは後日ね)。いずれにしても無料といっても輸送コストがゼロになったわけではなく、どこかにいっているだけ。問題はそれがどこか。

個人的にはAmazon EC2/S3などのクラウドインフラ事業者としてのAmazonよりも、通信販売業者としてのAmazonの方が興味あります。通販って仕入れ、在庫、決済、発送などからなるシステムなのですが、Amazon並に巨大な通信販売業者というのはシステムも複雑だし、それを支えるITシステムも桁違い。Amazon EC2/S3も使いますし、その内部システムに興味がありますが、でも本当に知りたいのは通信販売の物理的およびIT的な処理の方です。

当方自身も専門はコンピュータサイエンスですし、IT業界にいると、目新しいITシステムに目がいってしまうけど、いまはITシステムが現実世界に不可分なぐらい普及しているし、現実世界もITシステムがなければまわらない。そうなるとITシステムだけを見ていてはだめで、システムを全体をみないとわからない。コンピュータサイエンスではお偉い先生方を含めて、世間はコンピュータを道具としてみていない、と嘆かれる方が多いのですが、時代は巡って、コンピュータはシステムのほんの一部に過ぎず、コンピュータを特別視している限りは見誤ることになります。その意味でもAmazon EC2/S3の仕組みをあれこれ想像するよりも、Amazonの通販システム全体の仕組みをあれこれ想像する方が重要なはず。

2010年11月1日

どうしましょう、11月になっちゃいました。今年もあと二ヶ月しか残っていない。ところで今月は後半に、来年早々に実施する実証実験に関する報道発表をすることになっています。そして、その準備が作業が始まりました。今回の報道発表は、単独ではなく、企業との共同発表となり、来られる記者もその分多くなりそう。勤務先の広報部門方など多くの方にお手伝いいただくわけですが、なかなかたいへんなのであります。この分だと今月は報道発表対策で忙殺されそう。いずれにしても研究者も、研究して論文を書いていればいいという時代でもなく、研究に関する説明責任を求められます。そのとき単に論文を書いていればいいというわけではなく、研究成果を社会にいかす方法を具体的に示さないといけないのです。

話は変わって、本日をもって日本繊維新聞が休刊そして、会社整理だそうですね。アパレル不況もここまできたかという感じですね。アパレル業界誌なのかでも、繊維新聞はファッション動向も大きく扱っており、その分、紙面にお金がかかっていたのかも。日刊のアパレル業界新聞は繊維ニュースと繊研新聞社だけでしょうか。アパレル業界って派手そうですが、内実はたいへんなようですね。

2010年10月31日

午後から休日出勤。産総研がロボット研究の現状をまとめたレポート。学術研究の本質的な問題をまとめているので、ロボット研究以外の研究者(当方を含めて)にとって考えさせられる内容です。分野を問わず、研究者の方には是非このレポートを読んで欲しいのですが、(ロボット研究に依存しない)要点を書くと以下の通り。論文数や参照数は実際的な貢献とは無関係、逆に(課題が多くて)実用化にほど遠い研究の方が論文数や参照数が多くなる。研究が盛んな分野だからといって世の中に求められている分野とはいえない(当該分野の研究者が多いから活発になっているだけ)、論文査読では研究の必要性の理由付けが虚像でも論文評価に影響しない、完成された研究ほど学術研究の余地が少ない(逆に言うと未完成の研究の方が論文が増える)、市場予測はあてにならない、などなど。

これらはロボット研究の問題ではないはず。例えば当方の専門である情報系の研究にもいえることです。所詮、論文数や参照数は研究者村のローカルな評価基軸にすぎず、村の外では通じない。もちろん、その研究者村に属する一人としては論文数と参照数を重視するのは当然だけど、村の外に対しても実際的な貢献をしていかないと、村そのものも孤立化します。勘違いされないように書いておきますが、それなりの論文数と参照数がなければ研究者失格であり、その論文数と参照数があったうえで、実際的な貢献が必要ということ。当方自身はそれができているとはいえませんが、このレポートをときどき読み返して、どうすればいいか、もがき苦しんでいる状態。

なお、ロボット研究という、当方の専門ではない研究を対象にした、このレポートの存在を知ったのは偶然でした。父親が、このレポートをまとめた当時の産総研の外部評価委員で機械・ロボット部門の担当だったのです。さらにレポート中にSCARA型ロボットを作った牧野先生も父親は知り合いだったこともあり、SCARA型ロボットや牧野先生の話は聞いていました。ちなみに牧野先生は山梨大を定年退官後は民間企業に移られたときいています。

2010年10月30日

オフィスによってから、新国立劇場でバレエ「火の鳥」「シンフォニーインG」「ペンギンカフェ」の3本立てを観劇(そのあとまたオフィスに戻りましたがね)。今シーズンの新国立劇場でバレエのオープニング演目なのですが、有名古典作品ではなく、ニッチな3本を持ってきたところは気合いというか、いっちゃってます。そのためチケットが大量に売れ残るという事態らしいですが、出演者を考えるとこんなお買い得な公演はない。日本でもトップバレエ、団の一つである新国立劇場バレエ団のプリンスパル級大量投入というですからね。

一番目のストラビンスキーの「火の鳥」はCDは持っていて何度も聞いているし、CDのノートを読んでストーリーは知っているのですが、ビデオを含めてバレエそのものをみたのははじめ(テレビでラストの方をちらっとみたぐらい)。実は音と踊りがシンクロしているし、冗長なところがなく、すごい作品だったのですね。無名のストラビンスキーをバレエ音楽の一躍トップ作曲家に押し上げただけのことはあります。演出はストラビンスキーの振り付けでは定番のフォーキン。パリオペラ座の初演から今年は100周年目だそうですが、いまも昔も同じ演出というのはある意味ですごいです。踊りの出来ですが、パリやロンドン、ニューヨークと比べたらダメですが、よかったと思います(個人的にはチケット安かったし)。ところでロシアもののバレエって、どうして王子様か王女様が出てくるのですかね。さらに王子様と王女様が山奥や森でばったりあう。昔のロシアでは王子様と王女様がそこら中に歩いたのでしょうか。

二番目の「シンフォニーインG」は知らない演目。ストーリーはなく、クラシックバレエの踊りにひたすら楽しむという作品だったのですが、日本のバレエ団とは思えない出来。オープニング演目なので気合いが入ってました。

三番目の「ペンギンカフェ」は、そうです、1980年代に一部で話題になったSimon Jeffesのペンギンカフェオーケストラのバレエ版です。個人的にはペンギンカフェオーケストラはCDを持っていたりと、嫌いではなかったり。このバレエ版ですが、もともと英国のロイヤルオペラバレエによるバレエ化なのですが(といってそもそもオリジナルは音楽だけでストーリーもないけど)、そのときに振り付けを担当した方が、今シーズンから新国立劇場のバレエ芸術監督になり、直々に演出・振り付けをしたそうで、完成度は高かったですね。新国立劇場でも人気&有力ダンサーに着ぐるみかぶせて踊らせていましたが、みなさん役に徹していましたね。次の演目(シンデレラ)の主役(さいとう美帆)をペンギン給仕役に使っている状況。ちなみに最終日はアボリジニの夫婦役が、「火の鳥」のイワン王子役と火の鳥役をそれぞれ兼務。それと着ぐるみきていると踊りにくいと思うのですが、そこはプロですね。出来もいいですし、素直に楽しめる作品ですね。それとタイミング的には名古屋開催のCOP10にあわせたのかも。

というわけで正統派のバレエファンには不評でしょうが、モダンダンス作品としてみればたいへんよかったと思います。もっともチケットが売れていなかったので、こちらは直前に安いチケットが手に入ったわけですが。二週間前はウィーンでオペラ「セビリアの理髪師」を観劇しているので、今月は二本目。

2010年10月29日

クラウドコンピューティングではGoogleは技術的には大きな影響力を持っています。しかし、Googleは内部システムの情報を出したがらない。たまに論文を発表しますが(Googleの方曰く、アカデミアにおける求人向け宣伝のひとつだとか)、論文で書かれるシステムはすでに使っていない古いシステムだそうで、結局、現状についてはわからない。これが個人的にはクラウドコンピューティングの研究をする気になれない最大の理由です。

それにしてもGoogleはなぜ内部システムの情報を出さないのでしょうか。もちろんその理由は他社に真似されるのをに嫌がっているからでしょうが、真似されることによって他社が競争力をつけてしまうことよりも、真似している他社に社員が流出するのを避けないのではないか、と推測しています。

IT業界の場合は、他の業種と比較して、仕事に使う機械や道具は大差がないので、転職が容易とされます。その企業の独自システムを使っている社員の場合、他社に移ってもやっていけるかは限らない。少なくても社内の開発者向けシステムがよければ社員の流出は抑えられます。その社員の流出抑制効果は、フリーランチなどの福利厚生よりもはるかに大きい。

もちろん、IT業界ではこれまでにも、IBMやDECなど独自システムに固着する企業はありましたが、いずれもメーカ系なのでその独自システムを使うユーザ企業に転職するという道があったのですが、クラウドコンピューティングの場合はインフラの内側と外側の壁が高いし、そのインフラを外販しているわけでもない。そうなるとインフラの内側にいる技術者が外側で役に立つかという必ずしもいえないことになります。

逆に言えばオープンな技術でクラウドを組まない限り、クラウドにロックインされるのは顧客やサービス開発者だけでなく、インフラ内の技術者も含まれるということです。

2010年10月28日

某社訪問と打ち合わせ。それから霞が関。いろいろ動いたわけではないのですが、いろんな意味でハードな一日。ただ方向性は見えてきたのでよかったです。いずれにしても皆さん様にはいろいろお世話になりました。

話はかわって、勤務先の大学院の説明会を宣伝をせよ、ということなので大学院入試説明会のURLです。勤務先の国立情報学研究所は研究機関なのですが、総合研究大学院大学(総研大)という研究専門の大学との情報学専攻という大学院が設けられています。総研大の本部自体は逗子の方にありますが、情報学専攻は国立情報学研究所(千代田区)のなかにありますから、入学式などのイベント以外は逗子にいくことはないです。

というわけで情報学専攻に関してだけ説明をしておきますが、研究指向の情報系大学院なので、例えば4年生でも、研究をする上で基礎学力があって、現在、御所属の大学の研究室で研究下地を教わっている方や、企業で研究部門、または開発でも研究に近いことをなさっている方には非常にいいと思います。研究の世界でプロとして生きていくためには、当該分野の先端の研究成果をださないといけません。そこに至れる唯一の方法は、先端の研究をしている研究者といっしょに研究することです。先端は先端で、先端の研究者でないとわからない知見とかノウハウがあり、先端ではない環境から先端に行くのは不可能といってもいいです。その点では国立情報学研究所はプロの研究者の集団なので、非常にいい環境だと思います。

ただ国立情報学研究所は良くも悪くも研究機関であって教育機関ではありません。だから先端の研究者と一緒に研究するための準備ができてる人に向いています。逆にそうではない場合は一般の大学の大学院をお勧めします。一般の大学は教育機関なので研究にかかわる教育も充実しているからです。個人的な印象ですが、(情報系でなくてもいいですが)大学の研究室で、指導教員または先輩の学生さんが先端の研究をしているなど、先端の研究を身近に見る機会がなかったならば大学の大学院の方がいいように感じています。

なお、受験に興味を持たれる方から、学部時代や修士時代の専門が非情報系でも博士がとれるか、とよく聞かれます。その答えはケースによりますが、非情報系だと、情報系の基礎を勉強しなければいけない分、博士取得までに時間がかかりますが、博士取得は不可能ではないと思います。ただ、非情報系でもいいのですが、これまでの専門をしっかり勉強していることが前提になります。分野は違っても特定分野を体系的にしっかり勉強した経験のある方は、別の分野(つまり情報系)のしっかり身につきますが、中途半間にやられた方は以前の専門だけでなく、情報系も身につかないということが多いようです。

最後に大学院の説明会の宣伝といいながら矛盾していますが、一言だけ書いておくと、研究の世界でプロで食べていくのは簡単ではない。それと学部レベルの教育と違って、研究には予め正解が用意されているわけではない。365日不眠不休でコツコツ研究を続けても成果がでるとは限らない。かといって努力点はありませんから、結果がダメならばそれまで。だから精神的にも体力的にも強い方でないと、まちがいなく道半ばに破綻します。

2010年10月27日

午後は講演。内容はPersonal Carbon Trading (個人レベル排出量取引)。2時間の予定でしたが、質疑をいれると2時間半となってしまいました。Personal Carbon Tradingに関するセミナーは日本でも最初だったと思いますが、聴講された方はどのような感想を持たれたのでしょうか。排出量取引というと驚かれるかもしれませんが、ここ2年間ぐらい研究で排出量取引を扱っているし、排出量取引絡みの講演やパネルは結構が多い。なお排出量取引というのは、CO2に代表される温室効果ガスの排出を削減した人が、逆に排出が多かった人にその削減効果を売ること。

コンピュータサイエンスの研究者である当方がなぜ排出量取引を研究しているかというと、局所最適化から全体最適化に導くうえで有用だと信じているから。というわけで環境とか、気候変動とかに思い入れはまったくありません。

さて世の中をみていると局所最適化と全体最適化が相反している例は多い。電車に乗っていると運転間隔の調整という理由で電車の発車が遅らされることがあります。これはたいてい後続の電車が遅れたからなのですが、乗客にとっては後続の電車の遅れとは関係ないわけで、ダイヤ通りに発車して欲しいわけですが、鉄道会社からみれば遅れた電車は乗客数が多くなり、乗降時間がかかる。結果としてますます遅れるという事態になり、後続電車以降の電車に乗るお客さんも巻き込まれます。つまり全体最適化をすると、前に走っているお客さんの局所最適化、つまり乗っている電車はダイヤ通りの運行を望むということができなくなります。

もうひとつ電車の例をあげます。東京の朝は電車が混みますが、たいてい急行と各駅停車では急行の方が混みます。それは個々の乗客にとっては移動時間を短縮化することが最適化だからです。ただし、電車が混むと停車駅での乗り降りに時間がかかり、その電車も後続の電車も遅れることになります。つまり全体としては最適化されていない。つまり局所最適化が全体最適化になっていないことになります。だからといって急行ではなく各駅停車を乗りましょう、とキャンペーンを張っても乗り換えてくれる乗客は少ないでしょう。ではどうすればいいのかというと急行から各駅停車に乗り換えてくれた乗客に何らかの見返りをあげることです。

もちろん電車であれば有料の急行券を導入すればいいわけですが、世の中全体として、全体最適化につながらない局所最適化を緩める見返りとして、当方で注目しているのが排出権。息をしてい生きる我々が何らかの活動をすればCO2は排出されます。何らかの経済活動、例えば工場で物を作ったり、物を運んだりすればCO2がでます。だったらCO2をベースに、排出量を制限したり、インセンティブ(排出権)をあたえるのは、世の中を局所最適化から全体最適化に導く有用な方法と考えています。

コンピュータサイエンスの研究対象でコンピュータはさまざまなところで使われています。現代社会はコンピュータなしでは成立しないといっても過言ではないでしょう。逆に言えばコンピュータの使い方次第で現代社会はもっとよくなることもできるはずです。その意味ではコンピュータサイエンスの研究者というのはすてきな仕事です。というのは世界で一番速いコンピュータを作ることもできるかもしれませんが、コンピュータを通じて社会基盤も作れる可能性もあるから。実際、個人的にも速いコンピュータよりも社会基盤を作ることを狙いたいと思っていますし、排出権はコンピュータを通じて現実世界を変える重要な手段だと思っています。

2010年10月26日

ここ数日でやっていたのは講演のスライド作り。それもこのページではここ数日、MapReduceなど、Googleのデータセンターなどの話題を書いておきながら、作っていたのは個人レベル排出量取引のチュートリアル資料。クラウドコンピューティングと排出量取引は違うようにみえるかもしれませんが、本人的には違いがなかったり。

世の中にはRDBをクラウドで動かすとか、基幹系をクラウドで動かすとかおっしゃる方がおられます。別に止めはしないのですが、個人的には興味がない。既存システム用の技術やアプリケーションをクラウド上で無理して動かす方法を考えるよりも、クラウドコンピューティングならではの新しいアプリケーションを考えた方が百万倍は建設的。クラウドコンピューティングは新しいコンピューティングシステムなのですから、新しいアプリケーションの方がいい。実際、過去を振り返っても、新しいコンピューティングシステムは新しいアプリケーションを生み出すし、その新しいアプリケーションのために使われているはず。

ではクラウドコンピューティングが生み出す新しいアプリケーションをは何でしょうか。このへんは研究上の秘密なので書けませんが、ひとついえることはいままでの既存システムでは無理だと思われていたようなアプリケーション、考えもしなかったアプリケーション。思わせぶりなのはよくないので、ひとつだけ例を挙げておきます。

バングラデシュのグラミン銀行を御存知でしょうか。発展途上国向けのマイクロファイナンスをやっている銀行ですね。貨幣が情報である以上はその貨幣を扱う銀行は情報システム。しかし、既存の情報システムはコストが高く、少数の高額決済に向いていますが、マイクロファイナンスのような多数の少額決済には不向き。一方、クラウドコンピューティングというのは多数の中・低性能のサーバから構成されているので、多数の少額決済を実現できる可能性があります。

国連によると世界の人口は2050年には90億人に迫るといわれています。残念だけどその多くは豊かとはいえない。彼らの生産性をあげて、生活水準をあげることは人類、特に先進国に済む人間の義務だと思いますが、そのためにITが役に立っても、彼らがITに投資できる金額は年間50ドル以下。そのなかでITを利用するためには、規模の経済で価格がさがる余地のあるクラウドコンピューティングは重要になるはずです。その意味では日本を含む先進国だけをみているとクラウドコンピューティング向けの新しいアプリケーションは見えてこないかもしれません。

さて個人レベルの排出量取引にもどりましょう。既存の排出量取引は最小でも1000トン単位で取引されます。それは(国連認証の)排出権には1トンごとに識別子が振られているし、それぞれに有効期限があるなど、既存の有価証券と比べてもその取引がたいへん複雑だからです。また1トンの排出権が1500円前後である現状では、ボリュームの小さい取引は決済コストが相対的に上がってしまうのです。しかし、クラウドコンピューティングは厳密なトランザクションは不向きですが、大量の決済処理を低価格で実現する方策になりえると考えています。そして個人レベルの排出量取引が実現できるようになると世の中は大きく変わります(これはまたいずれ)。

当方は世の中を大きく変えられるような技術を研究したいのです。速いコンピュータを作るための研究も重要ですが、むしろ社会を変える研究をしたいということ。クラウドコンピューティングも排出量取引もその手段のひとつにすぎません。そうそう当方が考えた新しい個人ベース排出量取引についての大きな実証実験を予定しています。近々報道発表することになると思いますので、期待してください。

2010年10月25日

今日はオフィスにお泊まり残業。そうでもしないと仕事がおわらない。

さてGoogleのStreet Viewによる違法な情報収集が問題になっていますね。それにしてもGoogleはどこに向かっていくのでしょうか。以下は概念的な議論で恐縮なのですが、個人的にはGoogleを「巨大化している機械学習マシン」と理解しています。ちなみに機械学習はそもそもは人間が得られた情報から知識を獲得する過程をコンピュータ上に再現することです。簡単に言えば多くのデータを集めることで知的なことをする仕掛け。Googleはさまざまなデータを集めては、Web検索など高次なサービスを提供しています。ひとつの興味は膨大なデータを集めると、人間の脳をこえるような知性が身につくか。つまり、情報を集めれば集めるだけ知的になるのか、むしろ情報を集める過ぎると逆に働いてしまって人間の脳と同程度またはそれ以下になってしまうのか。

二つの興味は巨大化。Googleのことを「巨大化している機械学習マシン」と書きましたが、Googleはこれまでデータを集めるために巨大なデータセンターを作ってはさらに多くのデータを集めます。生物で喩えるならば、情報という餌を食べることで、Googleの体、つまりデータセンターは巨大化しています。ここで気になるのはGoogle自身が、巨大化をコントロールできているのか。端から見ているとGoogle自身が、Googleという情報を食べて巨大化する生物に食べられてしまい、情報収集と巨大化が自己目的化しているのではないかと思えるときがあります。

もちろん大量の餌を食べても排出物も多ければ巨大化しません。しかし、Googleは集める情報量に対して、出てくる情報量が少ない。つまり食べる一方で排出物はすくないために巨大化が止まらない状態に見えてしまいます。その先にあるのは、すべての餌、つまり情報を作り出す、我々も食べてしまうのか、それとも風船のように巨大化に限界があり、どこかはじけてしまう、つまり本当の意味での情報爆発かもしれません。避ける方法は2つ。ひとつは情報をはき出すか(もしくは忘れるか)、それとも細胞が単細胞から多細胞になったように、Googleを分割するか。

2010年10月24日

昨日は休みましたが、今日は休日出勤。ところで昨日の続きになりますが、思考問題として、もし自分がRay Ozzieの後任に選ばれたら、考えることを書いてみます。まぁ後任になるわけないでしょうから、あくまでも端から見たMicrosoft様のAzureビジネスへの印象です。皆さんが後任になったらどうしますか? 

Microsoftの方と(Azureに限らず)パブリッククラウドの採算性の話になると、パブリッククラウドは相当な規模がないと儲からないとおっしゃいます。確かにパブリッククラウドで儲けるためにはその通りでしょう。しかし、Microsoftの事情と、GoogleとAmazonの事情は大きく違います。例えばGoogleの場合、パブリッククラウドを提供しているといっても、自社製サービスの運用・提供用サーバの方が多いはず。

サーバは数を買えば、カスタイズ仕様にして無駄な機能を削って、コストを削減できるし、ボリューム効果(クラウドコンピューティング業界の用語でいえば「規模の経済」)に安く調達できます。このため両社にとってのパブリッククラウドというのは自社サービスの運用・提供用サーバの調達コストを下げるために手段なのです。大型のデータセンターは工場などの設備産業ですから、工場の合理化の究極の解のひとつが、サーバ台数を増やして調達・運用コストを下げることだったということ。だからサーバ台数を増やす方向にビジネス展開したということ(もちろん別の解もあって、例えばSalesforceとかね)。さらにGoogleとAmazonは両社ともに、儲けの部分は自社向けのサーバの用途、Googleならば広告代理店事業、Amazonならば小売事業で稼いでいますから、パブリッククラウド事業で稼がなくてもいい。だから、パブリッククラウドの利用料は安価でもよく、パブリッククラウドで稼がないといけない企業よりは有利な立場といえます。実際、Googleは実質、無料でWeb版のOfficeやメールを提供していますし、Amazonも来月からEC2の無料版を提供するそうです。いいかえればパブリッククラウド以外に収益源がなければ、パブリッククラウドで価格競争力はありません。

ここでちょっとだけ補足をすると、Amazonは自社サービスの運用・提供用インフラとパブリッククラウド向けインフラを共用していないそうですが、互いに共通化してあり、処理量が多い場合はパブリッククラウド側のリソースを借りて自社サービスを実行しているそうです(まぁAmazonがいつまでパブリッククラウドを続けるかは別途議論でしょうがね)。Googleは負荷(つまり消費電力)を平滑化するためにサーバに、プロセス単位で同社の複数サービスを混在させているようです。つまり、どちらも自社製サービスの運用・提供用サーバとパブリッククラウド向けサーバの仕様は共通と推測することができます。

さて話をMicrosoftに戻しましょう。Microsoftはゲーム機からサーバソフトウェアまで幅広く事業を展開していますが、GoogleやAmazonと違って、Microsoftのパブリッククラウド(つまりAzure)によるインフラ整備によって、自社向けサーバのインフラの調達コストが下がるとは限らない。もちろんMicrosoftはWeb検索と電子メールなどに自社サービス向けに大量のサーバを所有していますが、それらはPaaSであるAzureとは用途が違うので、Azure用のサーバと自社サービス向けのサーバが共通とは限らない。そうなるとAzureのインフラを拡充しても、Microsoftの自社サービスのインフラ調達コストを下げることへの寄与が少ないということになります。さらにMicrosoftの場合、Azureのインフラを使った自社サービスで利益で稼いでいるわけではなく、その収益で、パブリッククラウドとしてのAzureの利用料を下げるという戦略はとれない。例えばMicrosoftはAmazon EC2のようなIaaS系を提供しても、その利用料金は、小売業という収益源のあるAmazon EC2の利用料金と比べると、高めに設定するしかない。もちろんMicrosoftはWindows関連ビジネス(OS及びアプリケーション)で収益を上げているので、Windows絡みの収益をまわしてでも、Azureの利用料金を下げてくると思います。しかし、ここで問題なのは、AzureはMicrosoftの収益源のWindows関連ビジネスにマイナスに働いてしまうということ。

にもかかわらずMicrosoftはわざわざAzureのAPIをWindowsのAPIに近いものにしてしまいました。Windows APIの親和性はAzure上のサービスを手っ取り早く増やすという点では正しい戦略です。しかし、その一方でWindowsアプリケーションからAzureサービスへの移行が容易になり、非Windowsアプリケーションよりも、WindowsアプリケーションがAzureに呑み込まれやすいことになり、収益源であるWindows関連ビジネスの市場を小さくして、(Azureビジネスの原資となる)儲けが減ってしまう。本来ならば非Windowsアプリケーションの開発者をAzureに取り込むという戦略をとれたはずなのですが、Windowsというプラットフォーム戦略から抜け出せなくなっているのか、クラウドコンピューティングでは後発になったことで選択肢を狭めたのかもしれません。

もちろんAzureは始まったばかりだし、Microsoftの影響力を考えるとそれなりに普及するでしょうが、初期戦略としてはやはり疑問を感じます。この状況を打開する方法は、まずはAzureの普及によりMicrosoft自身が儲かるようにビジネスモデルをかえることでしょう。そのひとつはOfficeなどユーザ数が多いアプリケーションをAzureに移行して、その利用料で儲けが出せるようにすること。そしてパブリッククラウドとしてのAzureが普及すればするほど、自社提供のAzureサービス、例えばAzure版Officeの提供コストを下げて、利益を増やすことかもしれません。

AmazonはEC2事業は直接、自社の小売業に貢献しませんが、GoogleはOfficeサービスを無料でも提供しても、広告収入が増えればよく、無料サービスを展開してくるでしょう。このためMicrosoftはAzure版Officeを提供するにしても、利用料の低価格化がせまられることになります。そしてこのあたりがRay Ozzie氏の悩みのタネだったのではないでしょうか。実際、Ray Ozzie氏はCSA着任早々に広告収入モデルへの転換を発言しており、危惧していたのでしょうが、企業としては転換がはかれなかったかもしれません。それで次にどうするかですが、Googleを見習って広告収入モデルへの転換をするか。ただPCまわりは広告ビジネスはGoogleや他社に取られているので、携帯電話かテレビを狙うしかないでしょう。ただ、これも茨の道。またはGoogleが手を出していない分野、例えばPCやスマートフォーンなど、Azureを使うためのハードウェアをリースして、そのリース料で儲けるとか、いくつか考えられますね。いずれにしてもAzureが普及することで収益があがる構造にかえることが重要です。

それとテクニカルには非WindowsアプリケーションやサービスをAzureに引き込むことでしょう。前述のWindows APIの親和性が高いAPIをAzureに導入したことはWindows開発者に優位になりますが、これは逆の立場、つまり非Windows開発者からみると、新規参入が難しい市場とうつることになります。まずは非Windows開発者が参入しやすいように、非WindowsのAPIとの互換APIぐらいは導入した方がいいでしょう。昔からMicrosoftは開発者に優しい会社なので、既存Windows開発者を優遇ということになるのでしょうが、時には切り捨てるものは切り捨てて、新しい開発者をいれないと新しいアプリケーションやサービスは出てきません(この10年間でWindowsから革新的なアプリケーションが出てきたのでしょうか)。

最後にMicrosoftのソフトウェア戦略というのは、今後のIT業界に影響を与えるわけですから、IT業界に関わる方ならば、その戦略の今後を予測しておくのは重要ではないでしょうか。それからRay Ozzie辞職後の後任のChief Software Architectはいないとか、まじめに返す人が絶対に出てくるのですが、趣旨は今後のMicrosoftのクラウドコンピューティング戦略の予測です。

なお、Microsoft及びAzureに批判的なわけではありません。Azureは潜在能力は高いと思うのですが、ビジネス展開としては疑問を感じるというだけです。そもそも勤務先はAzureに関してMicrosoftと契約したそうで、是非とも普及していただきたいと、とっても思っております。

2010年10月23日

4日ほど前の話ですが、Bill Gates氏の後任としてMicrosoftのChief Software ArchitectになったRay Ozzie 氏が辞めるそうです。Ray Ozzie氏といえばLotus Notesの作った人であり、いまの同社PointShare(旧名Groovy)を作った人でもあります。正直言って、Ray Ozzie氏の今後よりも、Microsoftの今後の方が心配。おそらく数年経ったときに、今回の辞任はターニングポイントだったということになるかもしれませんね。

とおもっていたらMicrosoftは企業向けSaaS「Office 365」を発表。これは評判がいいとはいえないWeb版のOfficeのライセンスに加えて、通常のPCインストール型Officeの両方を含むライセンスだそうです。まぁ組み合わせたライセンス自体はひとつの方向だと思います。ただ、前にも書きましたが、Microsoft様におかれましては、Azureを啓蒙するならばまずはOfficeをAzureで実装してSaaSとして提供ください。開発者にはAzureを啓蒙しておきながら、自社の基幹アプリであるOfficeは従来通りのままでは、Azureに本気で切り替える開発者は少ないです。例えば使えるレベルのOfficeをAzureで実装して、同時にPCインストール型のOfficeの提供を止めて、Azure版の一本に絞るぐらいはして欲しいですね。一般論として自己矛盾したままビジネスを続ける企業は長く生き残れる確率は低いのですから。

ところでRay Ozzie氏はどこにいくのでしょうか。利口な方だからすぐにライバル企業に行くことはしないでしょうが、国内のIT企業もスカウトしたらどうでしょうか。その企業の株主は彼ならば高給でも納得すると思うし、それぐらいしないと国内IT企業は生き残れないかもしれません。

2010年10月22日

オラクルのExadataやNTTデータのLindacloudがいい例なのですが、大規模データ向けのアプライアンスの話題が多いですね。Lindacloudに関しては、Hadoopのインストール経験のある方ならばわかると思いますが、スタンドアローンにインストールのならともかく、本当に分散システム上にインストールしようとすると一人では辛い。そのインストールの手間が省けるだけでも需要があるのでしょうね。

いずれにしてもクラウドコンピューティングの技術を利用した製品は、プライベートクラウドを含めてアプライアンス化が進むのでしょうね。その背景はクラウドコンピューティングの要求事項のひとつであるスケールアウト性。チューニングとスケールアウトを比べると技術はまったくちがいます。チューニングに手慣れた技術者でもスケールアウトなシステムを構築ができるかというと無理でしょう。というのは、これまでのシステム構築では限られたシステムのなかで性能を出すことが求められましたが、スケールアウトの実現には処理量の増加時に(システムを拡充して)性能を維持することが求められますから、必要な知識も経験も違いますからね。

ただ、アプライアンス化がすすむと、ネットワークを含むシステムの構築・運用にかかわる技術者の需要が減ることになります。SI業者でも、本来のシステム統合ではなく、システムの構築や運用で稼いでいたところは、企業自身も技術者さんもたいへんでしょうね。ところで上述のHadoopのシステム構築については需要があるでしょうか。ここ2,3年はMapReduce/Hadoopに注目が集まって仕事は増えると思いますが、長期的にLindacloudのようにHadoopもアプライアンス化する、またはAmazonのMapReduceサービスのようにクラウド化するのであれば、Hadoopのシステム構築そのものの仕事は減ることになります。そしてBI系などビジネスデータに近い業者か、統計・データマイニング処理が開発できる業者ぐらいしか生き残れないかも。Hadoopが流行っているから参入するのは自由ですが、Hadoopが今後のよく考えてから参入してほしいですね。当方がSI業者の経営陣だったら、(Hadoopを含めて)システム構築系の技術者さんを減らす一方で、統計・データマイニングができる技術者さんを増やして、将来に備えます。

2010年10月21日

昨日、MapReduce/Hadoopの話題から脱線していったわけですが、分散システムを研究していた立場から、MapReduce/Hadoopをみると、手法そのものは並列Lispなどで使われていた方法なので、新しさはないです。ただ、分散システム向けのソフトウェアが難しくなる部分、例えば通信や同期処理とか、プログラムの多様化(例えばクライアント用とサーバ用プログラムがいる)などをうまく隠しているところは感心します。

以下は分散システムについてちょっと知識があれば常識的な話だけ。分散システム向けプログラミングという立場から見ると性能と例外処理はトレードオフの関係があります。HPC系がいい例なのです、ノード間の通信を含めて同期的に処理をすれば、失敗・故障がおきていればの場で見つけて、その場で例外処理ができます。このためプログラム自体はある意味でわかりやすい(少なくても後戻り的な処理は不要)。でもノードに処理速度または完了タイミングは違うので、同期的に処理しようとすると無駄(同期待ち)が発生して効率が下がります。逆に非同期処理だけでやれば、同期待ちによるロスは減るので効率はあがりますが、失敗・故障がおきてもすぐにはわかりませんが、後戻り的に例外処理をしないとけない。このためプログラムは複雑になりやすい。

さてMapReduce/Hadoopは面倒な同期処理をReduceの部分におけるファイル読み書きとして閉じ込めているので、処理本体には同期や通信処理を書かなくてもいい。というのは通信や同期のプログラミングは難しく、逐次処理しか知らない開発者には通信や同期は難易度が高い。それとMapReduce/Hadoopのもううまさは、一つのプログラムをコピーして、各分散ノードに割り当てて処理するので、クライアント用プログラムとか、サーバ用プログラムなどの多様なプログアムを書かなくてもいい。ひとつのプログラムを作るのでも精一杯の開発者の場合、二つ以上書けといわれても無理ですからね。

ただ、MapReduce/Hadoopは分散処理の中でも癖が強い。言い換えれば向き不向きがあるということ。だからその癖を理解して、癖にあるアプリでないと効果が下がります。特にReduce処理ではデータの入出力処理を裏のシステムに任せるので、無垢にプログラミングするとその入出力のために裏のシステム内で同期処理が多発してしまいがち。

その意味ではMicrosoftのDryadはMapReduceのReduce後にさらにデータ処理を多段で行う仕掛けになので、同期処理はさらに多くなります。複数の計算ノードから処理したデータをマージする場合、例えばノードの高々一つからデータがくれば先に進めるような処理(データフロー計算の用語でいうとXOR-merge/XOR-joinなど)ならばともかく、複数ノードで処理したデータが全部集めないと先に進めないような処理(AND-merge/AND-join)だと同期待ちが起きてしまって、性能がでないかもしれませんね。もっともXOR-mergeのような処理だったら、多段にしなくてもすむことも多い。もちろんMicrosoftはそんなことは百も承知のはずでしょうがね。

2010年10月20日

午前中は物流系会社の訪問、午後は打合せと勤務先内調整。オフィスで残業徹夜。日曜日に出張から帰ってきたわけですが、休まるときがないですね。

ところで当方が翔泳社の雑誌に描いた図版は使われたとかで日経HR(日経新聞系の就職関連出版社らしい)の書籍を翔泳社から送っていただく。その書籍は日経キーワード重要500という書籍なのですが、これが結構おもしろい。多方面に扱っていて簡潔に説明してありますし、普通のキーワード集とちがって、今年の7月ぐらいまで時事ニュースまで解説されています。就職面接などできかれることをまとめたのだと思いますが、いろいろ勉強になりますね。おそらく同種のキーワード本であればどうようにまとまっているのではないでしょうか。一読の価値はあります。それにしても今の学生さんはある意味、恵まれていますよね。ただ、こうしたキーワード本の内容程度の知識が身についていれば、どこでも就職できるでしょうが、それがなかなかできないのが悩ましいところなのでしょうがね。

2010年10月19日

来月の報道発表に向けて、関係者の広報担当者が集まって打合せ。ただ当方は報道発表資料を作るのはむいていません。

なお、報道発表が研究に直接貢献するわけではありませんが、いまは研究者として論文だけを書いていればいいという幸せな時代ではない。研究内容を広く知っていただくという説明責任が求められる時代。また、最近は研究予算によっては報道発表件数という定量的オブリゲーションが課せられることも普通になってきています。本当に時代が変わりました。その意味でもプロの広報担当者といっしょに報道発表ができるならば、報道発表しておいた方がいいと思います。というのは報道発表はノウハウが必要で、それは経験でしか得られないものですから。

それから上記の報道発表ですが、11月は予告編、本編は2月。後者は大きな発表になる予定です。期待してください。

2010年10月18日

最近、MapReduceやHadoopが企業で注目されているのをみると、これまでいわれていた大規模データ処理のネックとは何だたのかを考えさせられます。特に国内のコンピュータサイエンス系の研究コミュニティでは、コンピュータの処理能力が上がったけど、問い合わせ処理を含むデータベースがデータ量に追いついていない、というアジェンダのもとに研究が進んでいました。しかし、本当にデータベースがデータ量の増加に追いついていないからでしょうか。むしろコンピュータの処理能力がデータ量に追いついていないからではないでしょうか。

例えば流通系では販売データを13ヶ月しかもっていない業者が多いとされます。なぜもっと数年分とか長い期間のデータを保持しないのかというと、長期間分データを扱うとデータ解析のバッチ処理を夜かけても終わるのは朝方に終わらないから。つまり過去のデータをたくさんもっていても処理しきれないから、過去のデータを泣く泣く捨てています。つまり制限しているのはデータベースではなく処理能力の方。また、前述のMapReduceやHadoopが流行るのも、MapReduceやHadoopは並列度をあげることで処理時間を短縮するためであって、データベース側の性能制約をゆるめるためではないはず。本当にデータベースの性能が本質的な問題だったのかは再考した方がいいかもしれません(もちろんデータベースの性能はお金しだいなわけですがね)。

間違ったアジェンダでいくら研究しても、その研究成果が使われることはありません。Webなどで新しい大量データが出てきているし、センサーでデータを収集すればもっと大量データが生まれるでしょう。もちろん、そうした大規模データに対処する技術は重要でしょうが、でもその前に計算能力不足で泣く泣く捨てているデータを救ってあげる研究も必要なはず。

2010年10月17日

ANAのミュンヘン発成田行きに搭乗。満員のエコノミー席で12時間。堪え忍んで帰国です。というか長時間のエコノミー席に耐えられるというのは、海外出張が多い、研究者稼業には必須の能力だったりします。ところで機内食(あんかけ焼きそば) を半分凍っている状態で出される。あんかけがシャーベット状態。結局、溶けているところをちょっと食べただけ。ちなみに隣の方は凍っている状態のまま食べていました。こんなときにクレームをつけると疲れるだけなので、あきらめた方が精神衛生的にはいい。どこの航空会社もビジネスクラスが収益源で、エコノミークラスはどうでもいい存在なのですからね。ところでオーストリア滞在中は暖かい日でも最高気温が14度ぐらいだったので、東京は暑く感じます。

2010年10月16日

さて朝、少しだけウィーン市内を徘徊した後、空港へ。今回の出張ではウィーンの滞在時間はのべ一日程度なのでたいした写真を撮ったわけではないので、今回の出張ではなく、5年前にプライベートでオーストリアに行ったときのViennaMelkDurnsteinKlagenfurtの写真をWebにおいておきます。

2010年10月15日

国際会議の最終日。発表も最終日。

会議後にバスでウィーンに移動。一泊するということでウィーンオペラ座で「Il Barbiere di Siviglia(セビリアの理髪師)」を観劇。主な配役はFigaro役はMarco Caria、Rosina役はCatilin Hulcup、Almaviva伯爵役はテノールのBenjamin Bruns、Bartolo役はバスのAlfred Sramek、Basilio役はバリトンのJanusz Monarcha、Fiorello(伯爵の召使い)はClemensha Unterreiner、指揮はYves Abel。舞台はセビリアの理髪師の典型的なセット、演出はコメディ的な要素を強調していて、Rossiniの意図通りに娯楽作品に仕上がっていました。さて出来ですが、ものすごくいいという訳でもないのですが、ウィーンオペラ座としては普通なのかもしれませんが、あらが全くないし、全体としては水準はきわめて高い。ちょっと残念なのはラストのドタバタが淡泊な演出だったことでしょうか。歌手の出来ですが、Marco Cariaが声質も演技もFigaro役になりきっていましたし、歌もすごくいい。Catilin Hulcupもアリアは完璧にこなしていましたし、合唱部分もうまかったですね。伯爵役はBenjamin Brunsは出だしは声がはっきりしませんでしたが、それ以外はいいでき。そしてBartolo役のAlfred Sramekは歌もよかったですし、演目らしくコメディ的な演技がよかったです。それにしてもストーリー的な楽しさ、そして有名アリアが詰まったオペラで音楽的にも悪いはずがない作品。Janusz MonarchaやClemensha Unterreinerも好演。指揮のYves Abelは前奏曲で音が今ひとつのところがありましたが、それ以外はそつなくこなしてました。それにしてもウィーンオペラ座は水準が高い。

セビリアの理髪師では伯爵はRosinaと結婚しますが、原作的にはその続編(フィガロの結婚)では女中と浮気をしようとして、痛い目に遭うことになります。個人的にはどうもフィガロの結婚のイメージがあって、伯爵はどうも信用できないのですよね。

2010年10月14日

国際会議(SEUS'2010)の二日目。招待貢献は車載系の話。このプロジェクトの話を聞くのは二回目ですが、いつも一般論でおわる。外で話せないほどすごいのか、まったく進んでいないのか(前者ならば招待講演はうけなませんね)。さて国際会議ですが、ややクローズな会議なのですが、どの発表も(実態は別にして)うまくいきましたという話。というわけで何が問題だったのかがわからない。内容的には工学よりの会議なのですが、うまくいった事例よりも、うまくいかなかった事例の方が学ぶところが多いはず。というわけで学ぶべきことがすくない会議になってしまっています。

夜はバンケット。でも山腹の農家兼食堂に連れて行かれたものの、出されたのは洋なしから作ったビールと、(ホテルの朝食に並ぶような)ハムなどのコールドフーズだけ。実はオードブルだと思い込んで、その後の食事に期待していたのですが、オードブルだけで終わってしまったという状態。まぁ期待する方がいけないのかもしれませんが、朝食よりもさびしいバンケットは悲しすぎます。

2010年10月13日

国際会議(SEUS'2010)の1日目。招待講演はウィーン工科大の方ですが、この方の講演は10年ぶりぐらいですが、内容が変わっていないような気がします。同じことをやり続けることに意義があるのか、進んでいないのか。学会会場は旧市街とは川をはさんだ場所。すでにオーストリアは紅葉がすすんでいて、景色だけはいいです。

2010年10月12日

オーストリアのWaidhofenという場所に移動。

2010年10月11日

オーストリアのWaidhofenという場所(ViennaとLinzのあいだあたりの田舎)で開催される国際会議にいくために、まずはViennaに移動です。Viennaは東京の真冬の気温。寒いです。エコノミー席で12時間。今思うとANAでもフランク便などの新造機の新型エコノミー席は快適でしたね。

2010年10月10日

ちょっとだけオフィス。明日から海外出張なので出張中の事務仕事をしておく。

2010年10月9日

シンポジウム出席ごとにすこしだけ休日出勤。明後日から海外出張なので、いろいろ仕事が多い。先日、Salesforceのイベントにいったのですが、正直いって話題性のないイベントでした。わざわざ行く意味なかったですね。目玉にするかなぁ、と思っていたファーストリテーリングの話題はほんの少しで、肩すかし。Oracle対Salesforceで繰り広げられる、クラウドの定義論争にしても業界を盛り上げるための宣伝活動。知っていて乗っている方はいいとしても、まともにつきあうものではないです。そもそもOracleからみればSalesforceは最大顧客の一つでして、本気で喧嘩するわけがない。

ただ、目玉はなかったと書きましたが、明にはいっていないものの、Salesforceの導入理由が一変しているのは興味深かったですね。前述のファーストリテーリングなどがSalesforceを利用する理由は、海外展開をする企業にとってSalesforceを利用する理由は、(オフショア先を含む)世界中でどこでも使えることと多言語対応のはず。SaaSだからとかはどうでもいい話。SalesforceのSaaSはクラウドなのか否かみたいな議論は卒業して欲しいですね。スケールアウト性の欠如についても所詮は技術的な問題だし、少なくてもユーザから見て必要なリソースが確保できれば、スケールアウト性の有無はどうでもないいし、そもそもクラウドか否かという議論そのものが本質的な問題ではないはず。

去年の今頃に日経コンピュータの解説記事にも書きましたが、クラウドは技術的な影響よりも、システム単価を引き下げる影響の方が遙かに大きい。だからクラウドか否かよりも、クラウドというバズワードによって、ユーザがSI業者から価格主導権を奪ったことの方がはるかに大きな意味を持ちます。その意味ではクラウドがバズワードで終わろうと本物になろうと関係がないはず。

2010年10月8日

CEATECにいってみる。初日のパーティには出られず、4日目にふらふらと行く始末。ただ開場前についたものの長蛇の列。主催者のひとつのオブザバーという立場を使わしていただき、事務局ルートで開場前に入らしていただく。おかげで人気展示ブースでも並ばずに拝見。今年のCEATECはスマートホーンや電子書籍などが話題のようですが、製品として発売されるものは家電量販店でみれば十分なので、試作品だけをみてまわる。今年の話題の中心となった東芝のメガネなし3Dテレビの試作品ですが、なかなかできですね。個人的には3Dテレビには懐疑的ですが、少なくても今流行のメガネ付き3Dテレビは、メガネなし3Dテレビの登場とともに短期間で消える商品ジャンルということだけはわかりました。それから大急ぎで四ッ谷と本郷の用事。

2010年10月7日

ノーベル賞受賞は発表になりました。さて受賞された方が日本人の若手研究者が海外大学の訪問が減ったということを根拠に「若手研究者の内向き」を懸念されてました。でも、どうなのでしょうかね。若手の研究者は大学では以前のように常勤で採用されることはなく、任期付き助教かポスドクで採用されるので、海外にいくチャンスがないのです。特にポスドクの場合は海外大学で研究している期間は給与がでない。制度が内向きにしているのであって、好きこのんで内向きになっているとは限らない。もちろん内向き研究者も多いのも事実ですがね。国内学会の役員とかパネルや招待講演はシニアな先生方にまかせて、国際会議で活躍した方がいいと思います。

2010年10月6日

打ち合わせが4件。幸い3件目までは場所が所内。4件目は大手町方面。頭の切り替えがたいへんです。4件目は体力的にも内容的にもヘビーでした。

2010年10月5日

ビックサイトで8日まで開催されている見本市「東京パック」の凸版印刷(株)のブースで、当方の研究を紹介するパネルが展示されています。行かれる方は見に行ってください。業界的にはCEATECに行かれる方が多いと思いますがね。

2010年10月3日

最近、Googleは大丈夫でしょうかね。というのは最近発表したサービスはいまひとつぱっとしないような気がするのは当方だけでしょうか。それとGoogleはSNS系はうまくいきませんね。もちろん、Googleはビジネスモデル的にいえば広告代理店そのものであり、その広告があつまればいいのかもしれませんが、サービスが人気を集めなければ広告収入にもかげりが出てきます。どんな組織でもそうですが、秀才ばかり集めるとうまくいかないんですよね。普通の人も変な人もいれないと、多様性が失われていきます。それとGoogleをみていると自社のデータセンターありきなのですよね。その意味では製造業で製品よりも工場を重視して待っているのと似ているのかも。もうすこしネットで遊べばいいのにと思ったり。もちろんゲームという意味ではなく、自社のデータセンターの能力に頼らずに、ネット可能性を楽しめばいいのになぁ、と端から思えるのです。

2010年10月2日

オフィスにはいかなかったものの徹夜仕事。この先を考えるとやれるときにやっておかないと終わってしまうので。

2010年10月1日

神戸のスパコンの初出荷の記事がでているのですが、驚くべきことに記事の1/3ぐらいはミルクランという物流の話で、スパコンそのものとは関係がない。実際の記者会見でスパコンと物流の話の比率はわかりませんが、少なくてもメディアとして見た場合、スパコンってその程度の扱いということなのかもしれません。

ただ、世の中的にはスパコンよりもミルクランの方が遙かに重要。あえてスパコンの記者発表にミルクランの話題を持ち出したメーカの方々は、どちらが重要なのかよくわかっていますね。もっともこの記事を読まれる読者で、その意味が理解できる人は少ないかもしれません。ちなみに当方はというとやはり関心事はスパコンではなくミルクランの方ですし、実はミルクラン絡みの物流方式で特許まで取っています(国内特許は成立、いま海外に申請準備中)。

最新版
一覧

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