Diary

Ichiro Satoh

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

最新版
一覧

2010年3月31日

国際会議(PerCom)ですが、欧州開催で参加者数を心配したのですが、400人弱だったそうで、やれやれというところ。それと今回は通信など別分野の著名研究者も来ていたので、質的にもよかったのではないでしょうか。夜は7月に開催される別の国際会議の相談。その会議のジェネラルチェアは当方なので、会議関係者とテーブルを囲んで密談です。この出張のミッションの一つ。

ところでPerComと同様分野の国際会議にUbicompやPervasiveがあり、地味な研究を好むPerComと、派手好きなUbicompやPervasiveで棲み分けができています。3つの国際会議のプログラム委員を経験したのですが、PerComの場合、既発表の論文を発展させたものは積極評価するという方針なのですが、UbicompやPervasiveは新規ネタ重視。それぞれの考え方なのですがね。当方はすでにUbicompやPervasiveは関わらないようにしているので、今後、両国際会議どうされるのかを関知する立場ではないのですが、現状のように新規ネタばかり集めていると研究に深みがでないのですよね。特に米国大の方々はテニュア取得が関心事。米国大学でもファカルティに採用ぐらいならば、そこそこの採択率の国際会議の論文実績があれば研究に連続性などはなくてもいいですが、テニュア取得となると、例えば10年間、同じ研究を続けた場合に発展していることが求められるのです。結局、研究というのは積み重ねなのですよね。奇抜なアイデアは博士取得ぐらいまではよくとも、その後は深めることが求められます。その意味では新規ネタ重視の国際会議で論文実績を作っても、10年後に評価されるとは限らないのですよね。

特に米国ではリーマンショック以降は大学予算がへって、教員ポジションが減ったために、限勤務先でがんばってテニュア取得を狙うことが多く、テニュアの争奪戦状態。米国大ではテニュア取得率は20%を切っているとか。研究って当該分野の研究者同士の争いですが、人事に関していうと分野間の争いになるので、新規ネタ重視で連続性を重視しない研究分野は結局長続きしないのですよね。

2010年3月30日

国際会議(PerCom)の今日は基調講演と論文発表。基調講演はシュットツガルト大学の方ですが、旧知の研究者。PerComはコンピュータサイエンスで論文採択率が最難関になったりといまでこそ難関国際会議となりましたが、もともとモバイルエージェントの国際会議(Int.Conf.Mobile Agents)が2001年に採択率が20%を超えてしまったので終わらせることにして、かわりに新しい国際会議を作ろうということで、作ったのがPerCom。2001年の秋にバルセロナのレストランで深夜2時過ぎに話し合ったのでした。なお、今回のPerComで話になったのですが、またモバイルエージェントの国際会議を始めようかという声もあります。これは関係者ならばわかると思いますが、モバイルエージェントの研究を縛ってきた例の特許がそろそろ切れますから。

2010年3月29日

IEEE PerComに参加。今回は純粋に参加だけ。ただ、PerComは創立メンバーですし、プログラム委員なので。今年のPerComの採択率は12%。他の難関国際会議と比べても難しいということになりますが、PerComは過去に採択率は8%だったこともあり、今年は緩いという感じ。ちなみに採択率が8%のときのPublicity Chair(広報担当)は当方でした。ちょっとやりすぎました。

2010年3月28日

これからANA便で成田からフランクフルト。ビジネス席は満員、エコノミーはガラガラ。当然、後者の当方は快適。これもJALの影響なのでしょうかね。そのためANA様は結構強気ですね。機内の食べ物や飲み物は質量ともに目に見えて落ちてますね。

2010年3月27日

クラウドコンピューティングにおける電力制御の続きですが、巨大データセンターの性能・コストの支配要因は電力供給。性能が高いデータセンター系の設計・構築とは、電力効率がいいデータセンターの設計・構築と同じこと。究極的には情報や計算の流れとエネルギーの流れは一致することになるのでしょうね。

ところでソフトウェアまわりの研究者としては、データセンターではソフトウェアのレベルでも電力制御を意識しないといけないのかが気になるところです。少なくても課金は消費電力と連動することになるのでしょうから、消費電力をさげるための最適化などは今後重要な研究課題になるでしょうが、ソフトウェア内のアルゴリズムでも消費電力特性は相異します。その消費電力も平均値を重視するのか、ピーク電力を消費するのかは違ってきます。以前、Googleが自社のデータセンターの電力特性をまとめた論文を出してましたが、Web検索、Gmail、MapReduceでは電力特性が結構違います。電力特性が相異するアプリケーションを同時に運用することで平坦化しています。逆に言えばMapReduceだけを動かすようなデータセンターは電力的には不利ということ。

クラウドコンピューティングでは電力が最大のコスト要因ですから、そのクラウドコンピューティングがうまくいくかは、多様なアプリケーションを実行することで、電力特性を平坦化できるか否かにかかっているかもしれません。

2010年3月26日

クラウドコンピューティング向けのデータセンター系の論文をみていると、サーバ構成でもネットワークでもなく、電力に絞った論文が増えてきましたし、最近はコンピュータ系の国際会議でもコンピュータの話はなく、ひたすら電力について議論している論文もあります。いずれにしても巨大データセンターに関してはサーバやネットワークではなく、電力供給量で規模・性能が制限されます。今後はサーバやネットワークの工夫よりも電力側の工夫が重要になるのでしょう。この分野の研究は、コンピュータサイエンスはもちろんのこと、電気工学的な知識が必須になるのでしょう。そうなると人も入れ替わるかもしれませんね。当方は幸い、学部は電気工学科卒なので、データセンターやデバイスの電力まわり研究に関する論文を読んでもついていけますが、学科も大学院も情報系の研究者だと苦労するのではないでしょうか。時代は変わってきていますね。

あくまでも個人的な予想ですが、プロセッサだけでなく、すべての情報システムやコンピュータ、ネットワークが消費電力あたりの計算量や通信量にメトリックするが変わる可能性がありますし、その消費電力も平均を重視するのか、ピークを重視するのかで違ってきます。当たり前だけど平均は電気代に対応しますが、ピークは供給量制限に対応します。

ところでクラウドコンピューティングとスマートグリッドを対比したがる方々がおられます。ある種の集中システムであるクラウドコンピューティングと分散発電を前提にしたスマートグリッドでは根本がちがっていますが、クラウドコンピューティング向けのデータセンター内の電力制御にスマートグリッドの技術が使われる可能性は高いと思います。

2010年3月25日

昨日に引き続き、JavaScriptの話。最近、Google Chromeを初めてとして、JavaScriptにJITを導入して高速化することが増えています。遅いよりは速い方がいいのですが、システムの安定性を考えると単純ではありません。また、これまではWebブラウザの使い道はWebのコンテンツを眺めるぐらいでしたが、今後はWebブラウザのなかで動いているのは、ワープロや表計算を含む業務処理のGUI。そうなるとJavaScriptのスクリプトやプラグインが原因でWebブラウザが落ちましたというのは許されないのです。

そこで問題になるのはWebブラウザにおけるJavaScriptやプラグインの実行管理。これまでのWebブラウザまたは各ウィンドウをひとつのプロセスにして、JavaScriptやプラグインはスレッドとして割り当てる方式をとっていました。このためJavaScriptやプラグインが過負荷になるとWebブラウザを巻き添えにして落ちます。

しかし、JavaScriptがインタープリターのときはスクリプトが過負荷(例えば無限ループ)になっても救えましたが、JITでネイティブ実行になると、変換時にSoftware Fault Isolationにより検知コードを埋め込むにしても過負荷の検知は簡単ではない。同様にプラグインもシステム安定性という点では脅威になってきています。特にAdobe Flashは高機能なAPIが増えるにつれて処理が重くなっており、Flashが原因でWebブラウザが落ちることが多い。おそらく一般の方がWeb ブラウザを使う場合、Webブラウザの負荷の半分以上はAdobe Flashではないでしょうか。Adobeという会社はソフトウェアのメモリ管理がうまい会社でしたが(大昔、Directorでは少ないメモリでCD-ROMコンテンツを走らせるために、独自のメモリ管理技術を駆使していました)、最近はメモリを含む計算リソースを使いすぎですよね。

Appleは謹製製のWebブラウザであるSafariの現行バージョンからAdobe Flashを別プロセスで実行させるように変更しましたが、このためSafariによるWebブラウジングはプロセッサ的にもメモリ的にも重たくなったわけですがね。また、Chromeはタブにプロセスを割り当てることで、タブ単位ではJavaScriptの過負荷で落ちても、他のタブには影響しないようにしています。JavaScriptも同様に別プロセス化しないといけない状況はでてくるかもしれませんね。

いずれにしても既存のOSは、(マルチスレッドで実行するにしても)比較的大きなプログラムを少数実行することを前提に設計されているのですが、WebブラウザのなかではJavaScriptやプラグインなどの小さなプログラムが多数実行する世界。そのミスマッチがある限りは根本的な解決にならないのでしょうね。個人的にGoogleのChrome OSに期待することはWebブラウザの実行に最適化されたOSなのですが、Linuxをベースにしている限りは難しそう。

2010年3月24日

Twitterで「なぜJavaScriptはクラスではなく、プロトタイプベースにしたのだろうか?」と書いてみたところ、さっそく教えていただきました(参照)。JavaScriptの開発者がNetscapeに入社したときに、Webブラウザにプログラミング言語Schemeを入れようとしたら、Marc Andreessen氏からC言語風の文法を支持されたとか。当初がSchemeということであれば、クラスベースではなく、プロトタイプベースにするのは納得がいきます。長年、気になっていたことがすっきり解明です。皆様方、ありがとうございます。

オブジェクト指向プログラミングの源流を知らない方のために補足をすると、そもそもオブジェクト指向プログラミングでは、オブジェクト間の相互作用としてプログラミングします。ここまではいいのですが、問題はそのときにオブジェクトはどのように作るのか。原始的にはオブジェクトは一個一個についてプログラムで定義して、それをメモリ上に実体化すればいいのですが、同じオブジェクトを複数作るときは一個一個定義しているのは無駄。そこでオブジェクトをつくる鋳型というのが、いわゆるクラスなのですが、プロトタイプベースというのはオブジェクトをコピーして別のオブジェクトを作るという考え方。コピーするので、例えばオブジェクトの状態(インスタンス変数)を変更していたら、その変更も含めてコピーされることになります。クラスベースとプロトタイプベースに表現能力的な相異はないとされますが、GUIプログラミングのように類似したオブジェクトの複製を多数筒くるときは、いちいち状態を設定しないといけないクラスベースよりも簡単化されます。

ちなみにSchemeでオブジェクトやクラスを作ることはできますが、インヘリタンスはできません(メタ的な実装をしない限りは)。なぜかというとSchemeは構造化されたプログラミング言語なので、変数スコープを超えるようなアクセスはできないから。逆に言うとインヘリタンスというのは変数スコープを破っている機能といえることになります。そうそうオブジェクト指向プログラミングの本質を理解したければ、Schemeでオブジェクト指向の概念をいろいろ実装しているといいと思います。ただし、すごくマニアックですがね。

はなしをJavaSriptに戻しますが、JavaSriptの場合はクラスベースではなく、プロトタイプベースにして嬉しかったことはやっぱりないと思います。

2010年3月23日

このページはこのところ更新が止まっておりますが、年度末は報告書などなどいろいろありまして、忙殺されております。最近は質より量で勝負するような報告書は減りましたが、やたらとフォーマットにうるさい。MS-Wordなどのフォーマットファイルが送られていますが、型にはまることが苦手な当方には、簡単な報告書フォーマットでも逆らいたくなる衝動に駆られます。

2010年3月22日

高級コンパクトカメラの先駆けとされるローライ35が復活するそうですね。ちょうど一年ぐらい前に、ローライの代名詞である2眼カメラ(ローライフレックス)を作っていたメーカが倒産したりと、散々だったわけですがね。さて会社更生法が適応されて、メーカの元役員たちがつくった会社に継承されるそうですが、まさかローライ35を再生産するとはね。ローライ35は御存知の方はわかると思いますが、小さいボディにダイヤルなどがいっぱいで持ちにくいし、沈動式レンズなので撮影するときはレンズを引っ張り出さないといけないし、ファインダーはフォーカスと連動していないの目測でピントを合わせないといけないし、露出計は変なところについているので見にくいし、フィルム巻き上げレバーは独特で使いにくいし、巻き上げレバーをあげてからでないとレンズが沈まないし、フラッシュなどをつけるアクセサリシューは底面に付いているし、いまはなき水銀電池を想定しているので、いまどき電池では抑圧アダプターを使わないといけないし…などなど使い勝手は最悪のカメラでしたね。それでも好きな人は好きなので、需要はあるのでしょうね。ちなみに当方ですが、10年ぐらい前に、ローライ35はちょっと借りて使っただけで自分には向かないと悟りました。お手軽デジタル全盛時代にフィルムカメラで不便を楽しむというのは趣味としてはありだと思いますが、ローライ35は手強すぎます。ところでローライ35の露出計はCdsだったと思いますが、部材は手に入るのでしょうかね。

2010年3月21日

Twitterが流行っているらしいので、半年ほどまじめにTwitterをしてみたのですが(これまでセンサーのデータ置き場に使ったりはしていましたが)、今朝、1000フォローと1000ツイートを達成。フォローしていただいた皆様方りあがとうございます。実はTwitterを始めるにあたり、まわりのTwitterユーザからは最低でも1000ツイートと1000フォロー以上にならないとTwitterの意義や影響はわからないとわれており、個人的には1000ツイートでいちおう当初目標を達成です。それでわかったことは当方はやっぱりTwitterは向いていないということ。商売柄、深く考えることが仕事なのですが、Twitterは文字数が少ないので思考が深まらないのですよね。もちろん皆様方のフォローを読む分には短いのでいいのですがね。

2010年3月20日

ちょっと前に撮影した佃島の写真をwebにおきました。当方がまだ子供の頃は佃島には佃煮工場というか、佃煮に作っているところも見かけましたが、いまはお店が数軒あるだけですね。撮影はオールドレンズをデジタルカメラに付けるというミスマッチ。今回は1953年に製造されたレンズ(このレンズの発売は1930年頃だそうですから、設計という点では80年前)。コーティングがあるといっても最初期の時代で、フレア気味なのは困ったものですが、現代レンズのように高解像度&コントラスト重視ではないので、モダン建築の撮影には向きませんが、今回のようにちょっと古い建物にはいい感じ。

2010年3月19日

VTT(フィンランドの産総研のような組織)の関係者と打ち合わせ。東京にある国研ということがあるのでしょうか、大使館や外国の公的研究機関への対応は結構多い。当方は少ない方だと思いますが、それでも月に1,2回ある感じ。まぁ、これも仕事のうちなのですがね。先日、米NSFのプログラムディレクターと打ち合わせがあったのですが、米国の主要大学だったら予算獲得のためにファカルティメンバー全員が呼ばなくて参加してしまうような事態になるのですがね。ただ、研究者同士の打ち合わせと違って、研究機関のマネージメントスタッフとの会合では、先方の研究体制や研究テーマを説明いただくのですが、コメントが難しいのですよね。勤務先の位置づけもあって、下手をすると当方の思いつきのコメントが日本を代表するコメントにされてしまうことがあるので。

2010年3月18日

三鷹方面で打ち合わせ。帰りに道に途中下車してスイーツ調達。個人的にはスイーツに関しては東京は山手線の内側よりも外側(それも駅から徒歩10分以上離れた住宅地)の方がクオリティが高いですよね。結局、内側のお店は一見さん狙いですが、外側のお店はリピータ狙いなので、マーケティングよりもクオリティ重視になるのでしょうね。まぁ当たり前のことですが、今日はそれを実感することになりました。

2010年3月17日

情報処理学会の会誌に3月号に、2月号に引き続き当方の研究の解説記事。CO2絡みとはいえ今回は話が変わって、ICタグと排出量取引のこと。コンピュータサイエンスの研究者が排出量取引の研究をしなくてもいいのですが、要素技術的な解決よりも社会的基盤を作りたいのです。ITは情報システムだけでなく、社会そのものを変える力を持っていると信じているからです。これは大げさではなく、今後、社会的基盤を作るにしても、社会を変えるにしてもITの力なしでも不可能なはずです。世間ではコンピュータサイエンスに夢がないといいますが、当方は現在、社会的な一番影響がある科学技術はコンピュータサイエンスだと思っています。ただ、当のコンピュータサイエンスの研究者がコンピュータという狭い世界しかみようとしない。某学会が情報処理に夢がないというパネル討論を開いたそうですが、当方にいわせればコンピュータしか見えない人たちだから夢が語れないのでしょう。

さて今回の解説ですが、その要約をそのまま転載すると「排出量取引はCO2を含む温室効果ガス排出削減に対する経済的インセンティブを与える手段として期待されているが,既存の排出量取引は煩雑な電子取引を必要とし,一部の大企業以外は直接取引に参加することは事実上,困難であり,この結果,排出量取引は実経済活動から乖離して,金融商品化しているひとつの背景となっている.そこで本稿では,実経済活動の中心であるサプライチェーンの中に排出量取引を取り込み,実経済活動を通じた排出削減する手法を紹介していく.これは商品管理などに利用されるICタグを,あたかも排出権(または排出枠)に関する有価証券または貨幣のように扱えるようにすることで,排出量取引を簡単化するものである.例えばカーボンオフセット付き商品に貼付された排出権を商品の購入者に渡せるようにする.また排出量取引もICタグの受け渡しだけで行えるようになるため,排出量取引が大幅に簡単化する.また,今後,予定している実証実験についても概説する.」となります。

ただ、目的は(1)排出権を商品・サービス取引のインセンティブ(つまりオマケ)とすることで、市場原理により商品・サービスに添付された排出権量を増やさせることで、排出権の需要を増やすこと、つまり排出削減をすすめることにあります。また、(2)先進国が20-30%の削減目標を課した場合、排出権不足が想定され、市場で排出権の調達は費用がかかることになるでしょう。一方、排出権を作れる国々と、今後、製品輸出国となる国々は一致します。そこでこうした国々に排出権を輸出品のインセンティブとさせることで、先進国は製品輸入を通じて安価に排出権を調達することです。もちろんこれ以外にも目的があるのですが、さすがに書けることが書けないことがありますので。

2010年3月16日

当方は関数型プログラミング言語が嫌いと思われているみたいですが、嫌いなわけではないです(関数型言語とはいえませんが、Schemeの実装とかしたことあるし)。ただ、実際のソフトウェア開発に関数型言語が使えるかというとやや疑念をもっています。別に関数型言語では入手力処理が書きにくいとかというつもりは毛頭なく、むしろ心配している関数型言語を扱えるプログラマーの数とツール不足。当方のまわりには関数型言語好き、というかICFPに通している人ばかりなので専門の方が多いので怒られそうですが、苦言を少々。

個人または少人数の開発であれば関数型言語で開発できればいいのでしょうが、開発者というのは流動性が高い職種なので、5年後に関数型言語でプログラムした開発者が企業に残っていない可能性があります。もちろん、それでも関数型言語が扱える開発者がいればいいのですが、その確保に失敗すると書いたソフトウェアのメンテナンスはできません。そうなると関数型言語を使うと効率的に実装できる案件でも、関数型言語による開発にOKは出せませんから。関数型言語好きの方々は言語そのものやプログラミングには直目されますが、プログラミング前のモデリングやプログラミング後のメンテナンスにはあまり関心がないよう様子。

もうひとつの理由はツール不足。関数型言語を使いこなせる方はそれらなりにプログラミングスキルが高いのか、Eclipseなどの統合開発環境には頼らず、Emacsなどをがんがん書かれる方が多いです。本人はそれでいいのですが、プロダクトでソフトウェアを作る場合はプロジェクトの進行状態の把握が必要ですし、ソフトウエア設計時のモデリングとコードの対応もみえないといけない、またメンテナンスを考えるとコードスタイルも統一したいのです。その場合、最新の統合開発環境の方がツールが揃っているわけで、Emacsではダメとはいいませんが、ツールが揃うのは数年遅れになることが多いですから。

端から見ていると関数型言語の普及を狙うのであれば、プログラミング前のソフトウェア設計や、開発後のソフトウェアメンテナンスにフォーカスした方がいいと思ったり。

2010年3月15日

昨日の続きをすこしだけ。博士課程時代に欧州の研究所に転がり込んでいたときに、よくいわれたのは「コンセプトを考えるときはコンセプトだけを考えなさい。実現方法はコンセプトができてから考えるべきこと」。これは研究のテーマを議論していたときにいわれたものでした。ある意味で欧州らしい発想で、いわれたときは結構違和感をもったのですが、結局、当方はこれを研究者として基本思考あえて実践してきました。

なお、この指摘といっしょにいわれたのが、「コンセプトを考えるのは研究者の仕事。コンセプトを同実現するのかは技術者の仕事」と「研究者がどう実現するかを考えることは技術者の仕事を奪うこと」。これをいわれたときは、欧州は職業の分化が進んでいるということを改めて認識しましたが。それで当方はどうしたのかというと、研究者と技術者の二重人格化を目指しました。なのでコンセプトを考えるときは紙とペンだけを使って、コンピュータにはさわらない。逆に実装しているときはコンセプトをどう実装に落とし込むかということだけを考えて、コンセプトは変えないようにすること。このへんの使い分けは結構、重要だと思っています。コンピュータサイエンスの場合、ソフトウェアは形があってないようなものなので、気がつくと本来の目的とは違うものを実装してしまう可能性があるし、目的と実装がごちゃ混ぜになることが多いですからね。

2010年3月14日

わけあって10年ぶりぐらいにオーディオ製品のカタログを眺めることになったのですが、相変わらずですね。カタログの製品の説明は、スペック重視だし、ひたすら製品に使われている部材が高クオリティであることの説明だけ。製品の使うという観点はまったくない。まぁオーディオ製品はシャーシやケーブル、コンデンサなどなどの部材のクオリティが製品全体のクオリティに影響するのでわからなくもないのですが、ただ、ユーザの目的は製品を所有することではなく、その製品で音楽を聴くことなのですがね。

ただ、オーディオ製品のカタログというのは国内の産業の縮図みたいなものなのかもしれません。すぐれた要素技術を組み合わせたからといって、すぐれた製品ができるとは限らない。結局、要素技術を組み合わせてシステム化するところで負けてしまう。それからユーザが求めているのは製品のなかの部材のクオリティでも製品そのもののクオリティでもなく、その製品による「効果」なのですがね。

2010年3月13日

写真絡みの話題が続いてしまいますが、昨年、FinlandのTampereで撮った写真と、今年になってから築地で撮った写真をおきました。Tampereは普通にデジタル一眼とズームレンズの組み合わせ。築地の方は前回は古い単焦点レンズ、今回は比較的新しい単焦点レンズですが、比べるとわかるようにレンズの設計年代が違うと写真の雰囲気もかわりますね。

カメラといえばマイクロフォーサイズなどミラーレスのレンズ交換型カメラが増えてきましたね。光学ファインダーと比べると液晶ファインダーは見え方が悪いということになるのでしょうが、ミラー式の一眼レフは上記機種でもなければ視野率が100%にならないので、その意味では液晶ファインダーの方がいいのかも。一眼レフはミラーの駆動部分の設計が難しいとされカメラ専業メーカでないと難しいとされていましたが、ミラーレスならば新規メーカでも参入はしやすそう。

カメラの歴史に詳しい方ならば知られた話ですが、1950年代、カメラはLeitz(現Leica)やZeiss Contaxに代表されるレンジファインダーカメラが主流の時代。キヤノンもニコンもレンジファインダーカメラを作っておりました(当時のキヤノンはカメラもレンズもLeicaのもどき、ニコンはカメラもレンズもZeiss Contaxのもどき)。ところが当時、Leitzが発表したレンジファインダーカメラの新型機種(つまりLeica M3ですね) が、技術的にも圧倒的だったために、日本のカメラメーカはレンジファインダーカメラをあきらめて、一眼レフカメラにターゲットを移すことになりました。そしてご存知のように一眼レフカメラで大きな市場をとったという歴史があります。ミラー付きの一眼レフはニコン、キヤノン、ソニー(旧ミノルタ)などの従来のカメラメーカが圧倒的ですから、それ以外のメーカが新しいカテゴリに市場を求めるのは当然ですよね。そして往々にして、旧来メーカよりも新参メーカが成功をおさめます。というわけで個人的にはミラーレスカメラそのものよりも、メーカの淘汰の方が気になります。もちろんミラーレスカメラで一眼レフ移行時のカメラメーカ淘汰の歴史が繰り返すかはわかりませんが、時代の流れが変わるとプレーヤーも入れ替わるのが世の常。

なお、個人的にはレンジファインダーカメラをいまだに使っていたりします。上述の築地の写真は両方ともレンジファインダーカメラで撮った写真。

2010年3月12日

今週は取材が多かったですね。どの取材もプロのカメラマン(女性フォグラファーもおられましたが)が同伴。たくさん撮された一週間。最近は撮られ慣れしているといわれることがよくあるのですが、いいのか悪いのか。いちおう人生の目標は「研究者としてひっそり生きる」ことですから、写真を撮られる時点で目標から遠ざかっています。

この一年間ぐらい、取材などで撮っていただいたカメラマンさんのカメラはなぜかニコン製のD一桁型番の大型デジタル一眼ばかり。ニコンのカメラはシャッター音が個気味いいですね。古いレンズで遊びたい当方としてはマウント径の大きく&フランジバックが短いキヤノンの方がお好みですが(レンズ間ウンターをつければ他社製のレンズが使えるのです)。

2010年3月11日

午前中は半蔵門、午後は飯田橋方面で打合せ。時間がなかったので半蔵門から飯田橋方面の某A社までタクシーで移動しようと、流しのタクシーにのってみたものの、何を勘違いしたのか市ヶ谷の某B社に連れてかれてしまう。運転手さん「A社に着きました」、当方「ここB社ですが…」、運転手さん「いいえ、こちらがA社です」。運転手さんに御納得いただけるまで、しばらくコメディとしか思えない会話をしてしまいました。確かに某A社と某B社は同業のライバル会社なので間違いやすいかもしれませんが、行き先は企業名だけでなく、区と町の名前もいっしょに伝えたのに。タクシー代もただにしてもらいましたが、結局、地下鉄移動となりました。なお、N交通はタクシー会社ではまともな方だと思っていたのですが、結局、ドライバーさんによるのかもしれませんね。まぁいきなりカーナビに頼るタクシー運転手さんよりはいいのかもしれませんがね。普段、滅多にタクシーは乗らないのですが、たまに乗るとこんなことになります。

2010年3月10日

一昨日と昨日は休日をとることとなりましたが、今日から平常通りに業務。

プログラミン言語から電波までいくつかの標準化に関わっていますが、個人的には標準化に興味があるというよりも情報収集の場だったりします。アカデミアで仕事をしていると、企業の方々と会う機会を積極的に作らないと、いわゆる象牙の塔の状態になりますからね。

ただ、標準化というと日本では非営利な崇高な作業にみられがちですが、海外では標準化に関わる企業は自らが有利になるために標準化作業に技術と人をだしています。わかりやすい例としてHTML 5をあげると(当方はHTML 5は関わっていませんが)、GoogleもApple、そして最近はMicrosoftもHTML 5の標準化にご執心。HTML 5という高機能なWebコンテンツの通信・再生技術が標準化されれば、Googleは検索の対象が広がるわけですし、広告を出す余地が増えます。Appleにしてみれば自社の端末を売る機会が増えます。また、MicrosoftはAdobe Flashの影響を排除することができます。

それと標準化は技術を公開することですから、ただ標準化すると他社との差別化ができなくなります。だから、標準化は他社には見せない技術、つまりブラックボックス化した技術とは組み合わさってはじめて儲けにつながります。Google、Apple、Microsoftも標準化をすすめる同時に、GoogleはWeb検索を含むインフラ側を徹底的に隠していますし、Appleはコンテンツ販売の部分は徹底的に隠しています。日本の企業はこのあたりがお人好しというのか、前述のように標準化というと日本では非営利な崇高な作業と思っているのか、ブラックボックス化した技術をもたずに標準化をすすめるので、標準化がうまくいっても、儲かる部分がないということになります。

それと標準化の世界では企業のエゴ以外に、標準化ロビイストみたいな標準化で食べている連中が暗躍する世界(日本の国内委員会ではお見かけしません)。彼らは企業から標準化作業を依託をうけたエージェントなのですが、標準化の案件が多いほどお金になるので、いろいろ理由を付けては標準化案件を増やしたがります。実際の標準化の委員会というのは、こうした標準化ロビイストが企業・組織や国を代表して出席していて、自分たちの仕事を増やすために標準化作業を増やしたがります。言葉が悪いのですが、マッチポンプみたいな世界。

ここ数年、政府は標準化を国内企業が国際競争力をつける手段として、さまざまな支援をしていますが、基本的な支援は、企業内に標準化に対応できる人材を養成すること。それ自体は悪いことではないのですが、実際の標準化の場は、委員会や非公式な会合における標準化のプロといえる、標準化ロビイストたちが暗闘しています。企業内で片手間で標準化に関わる人材ではとても勝てません。プロにはプロで対抗するしかなく、標準化ロビイストを育てた方がいいと思います。経験と人脈がモノを言う世界なので、50才以上の(元)技術者さんを標準化エージェントにした方がいい。幸いにして国内企業は適任な技術者さんは結構残っているような気がします。

2010年3月9日

今日も私事のためにお休み。まぁ、このページは毎日、書いているわけではなく、通常は一週間分ぐらいのストックがあるので、それを貼ればいいのですが、今週はそのストックがない状態。

2010年3月8日

今日は私事のためにお休みさせていただきました。

2010年3月7日

クラウドコンピューティングのサービス開発向きの言語の続きですが、クラウド上のサービスは、サービスなのでソフトウエアを開発して納品・運用ではなく、日々改良となるでしょうから、初期開発よりもメンテナンス・改良の方が重要視されることになるでしょう。その場合、プログラミング言語への要求も変わってきそうですね。それとモデリング言語・表現も必要となるのでしょうが、既存のモデリング言語・表現は新規開発を想定しているので、こうした日々のメンテナンス・改良に向いているとはいえないですね。これは学術研究が解決すべき問題なのですが、まるで追いついていないという感じ。それとクラウド上のサービスは他のサービスを利用していることも多いはずで、他のサービスの改変の影響をうけますし、そのサービス自身の改変が他のサービスに影響を与えることがあります。このため外部の改変の影響による最小化する仕掛けや、外部の改変によるそれ自身の改変がやりやすくする必要があります。こうした話をすると昔流行ったAOP となるのでしょうが、改変対象は非機能的な部分だけではないので、AOPが使えるとも思えない。なんというか、ある程度使い捨て的なプログラミングも必要になってくるでしょうね。

2010年3月6日

昨日の続きを少々。クラウドコンピューティングでは関係データベース(RDB)と非関係データベース(最近はNoSQLと呼ぶそうですね)が対抗図式で議論されますが、データモデルの話なのにトランザクションの話にすりかわってしまっている感じ。そもそも関係データなどのデータモデルとトランザクション処理がごちゃまぜ。たしかに関係データモデルはトランザクション処理に向いていたといえますが、それは結果論であって関係データモデルとトランザクションはまったく独立。当然、関係データ以外でもトランザクション処理はできるし、関係データでもRDMSがサボればトランザクション処理はできないのですがね。クラウドコンピューティングとか大規模分散システムというと思考停止になるのでしょうかね。

2010年3月5日

クラウドコンピューティング、特にPaaS向けのプログラミング言語に関する議論。メモ代わりにここに書いておくと、クラウドコンピューティングと従来のシステムの違いはいくつかあるのですが、大きな違いは課金があること。この結果、PaaS向けの開発はプログラミング中に損益計算をするような状態になるというか、開発中のプログラムの実行による課金が考えながらプログラミングをすることになりそう。

その場合、プログラミング言語に対する要件もちがってきます。まずは課金の見積ができる言語が求められ、逆に実行してみないとわからないような言語は避けられる可能性がありますね。この問題はIDEなどからサポートされるべき問題ですが、ただプログラム上の表記と実行フローが一致している方がよく、その意味ではどちらかという手続き型言語の方がいいのかもしれません。だからといって関数型言語がダメだとかはいうつもりはありませんが、宣言的な言語は表記と実行フローが一致しないので実行コスト、つまり実行時の課金負担が見えにくいのが問題かもしれません。ただ、もし関数型言語の並列実行を期待する場合は関数型言語の並列性の高さが逆に問題になるかもしれませんね。御存知のように関数型言語は副作用が少ないので並列処理がやりやすいのですが、過去に流行った並列Lispでは並列に実行できる関数をそのまま並列に実行しようとするとコンテキストスイッチが多発してかえって処理効率をさげることがあり、並列Lispでは並列度をあげることよりも、処理効率が下がらないように並列性を抑えることが重要となりました。クラウドコンピューティングの場合、スレッド単位で課金されることも多く、並列性をプログラム側で明示的に制御できることが求められるかもしれません。

プログラミング言語のメモリアクセスですが、クラウドコンピューティングではインスタンス(実行中のプログラム)は何らかの理由で停止することがあり、そのときインスタンスのデータ、つまりプログラム中の変数の中身は消えることになり、明示的に永続化領域に書き込む必要があります。既存のPaaS、例えばGoogle App EngineでもWindows Azureでも、プログラムから永続化領域のデータを読み書きするときは専用のAPIを呼び出すことになりますが、永続化領域のデータ操作方法とプログラム変数のギャップが問題になります。その意味では1980年代に流行った永続プログラミング言語(Persistent Programming Languages)の手法が参考になるかもしれせんね。永続プログラミング言語は関係データベース(RDB)の普及により、データモデルとプログラミング言語を独立する方向に時代が向かったために消えてしまったのですがね。

クラウドコンピューティングではRDBが使えるとか使えないとかが問題になりますが、そもそもRDB自体がプログラミン言語とは独立したデータモデルなので、プログラミング言語とデータベースである種のインピーダンスミスマッチはおきてしまい、例えばオブジェクト指向言語ならばORマッピングで苦労することになります。純粋にプログラミング的な見地に立てば、上述の永続化プログラミング言語のようにデータベースのデータ領域をストレートに変数として扱える方がいいのですよね。ただ、プログラミング言語に依存すると独立性がなくなるのでバランスが難しいところなのです。

2010年3月4日

早朝に確定申告。日本の電子行政のダメさ加減を実感するためにe-taxと勢い込んだのですが、ダメさ加減に負けました。結局、e-taxは断念して、国税庁のWebページで数字をいれて、印刷して持って行くという安直な手段に出てしまいました。まぁ郵送でもよかったのですが、これも税務署にいっても時間的なロスが少なかったから。

2010年3月3日

IBMが新しいサーバアーキテクチャを発表。要点はプロセッサとメモリーは別の筐体で、外部ケーブルを介して最大42.4GB/秒速度の高速バスで接続(MAX5)。メモリー用筐体には最大3Tバイトというメモリーが搭載できる。2台のサーバー間でハードウェア資源を柔軟に分配できる(FlexNode)。8個のSSDをパッケージ化したストレージで、HDDの800倍相当の入出力処理数を実現(eXFlash)。やはり注目はメモリが大容量であることですよね。IBMも報道発表で語っていたそうですが、プロセッサの処理能力は急速に向上したが、メモリ容量は増えていないため、この先、プロセッサが速くしても、メモリが足りずに処理が進まないという自体になるし、実際、メモリ不足からサーバーの使用率は上がりにくくなっているといわれます。また仮想マシンの数はプロセッサ性能ではなく、メモリ容量不足で縛られますからね。

このIBMの新アーキテクチャがどれぐらいに性能がでるかはわかりませんが、仮にうまくいくとしたら、次の課題はメモリのアクセス速度と帯域、消費電力。メモリは容量も増えていませんが、それ以上にアクセス速度はあがらず、メモリが性能のボトルネックになっています。これをさける方法のひとつはプロセッサのクロックは低めにするかわりにコア数を増やすことでしたが(メニーコア化)、これはメモリの帯域不足という問題にぶつかります。また、個人的には消費電力の方が気になります。御存知のように過去の動作周波数をあげることでプロセッサ性能をあげるアプローチは、消費電力という壁にぶつかったわけですが、メニーコアプロセッサはコア単位の可変周波数などの省電力技術を導入していますが、それでも早晩、消費電力の壁にぶつかる可能性は高いように思います。

それにしても、今回のIBMのアーキテクチャはメインフレームの世界ですね。その意味ではIBMならではといえますが、同時にPCサーバも行き着くところまで行くとメインフレームと変わらないということなのでしょう。

さて3TBのメモリがあったら何をしましょうかね。考えるだけでわくわくしますよね。10年後には3TBも少ないといっているかもしれませんがね。

2010年3月2日

総務省のセキュアクラウドの成果報告会でパネリスト。個人的にはかなり抑えめに話にしたつもりだったのですが、聞かれた方はびっくりされたようでしたが。それにしてもクラウドというと人が集まるのですね。参加募集は1日目で300人集めたそうですからね。ただ、逆にいうとクラウドコンピューティングって、クラウドコンピューティングが話題になっているうちは本物ではないのでしょうね。

2010年3月1日

ためてしまった論文査読を黙々と処理中。とくに問題なのはACMとIEEEの論文誌、つまりTrasactionsの査読。ある意味で査読者も力量が評価されるのですよね。ACMとIEEEのTrasactionsの査読では査読者一人につきA4で1ページぐらいのコメントは暗に要求されることもあり、リジェクトでも査読してもらうだけで論文のリバイズができたりします。コンピュータサイエンスの研究の場合、国際会議に論文を投稿・採録になってから、論文誌に投稿という流れになりますが、逆もありなのですよね。つまりトップ国際会議に論文を通すために論文誌に投稿してコメントをもらうという戦略。まわりにトップ国際会議に何度も通している人がいるならば、国際会議に投稿前にコメントをもらえるかもしれませんが、そうでなければ論文誌の査読コメントを利用して、論文をリバイズしていくというのもひとつの方法。でも以外に実践している人が少ないと思ったので、ちょっとだけ書いてみました。

2010年2月28日

一昨日、Erlangのことを書いたので、そのErlangのこと。Erlangを初めて知ったのは当方が学部か修士学生だった頃でした。普通のコンピュータサイエンスの学生であればErlangを知ることはなかったと思いますが、所属した研究室で某通信機器メーカとの産学共同研究に関わることになりそのテーマが交換機(それもC-TRON)の制御のためのオブジェクト指向言語だったのです。当時の交換機はChillなどの専用言語を使っていたわけですが、それをオブジェクト指向風に書きたいというものでした。そのため欧州の大手の通信機器メーカEricssonが作った通信用記述言語としてErlangをたまたま知ったというのが実状。

ちなみに昨日、ErlangにはCSP的なガード記述があると書きましたが、これはErlangの歴史を考えれば当然。詳しくは設計者の一人がErlangの歴史に関する論文を書いているので、そちらをご覧いただければいいのですが、せっかくなので当時の状況などを少々。

通信プロトコルの開発では、OSI的な世界では、まず仕様をきっちり決める。きっちり決めると言っても自然言語で仕様を書くと解釈にブレが出るので、数学的に裏付けられた方法で定義をする。そうした定義方法のひとつが形式仕様記述言語。簡単に言えば数学的に定義されている言語を使ってプロトコルを定義するという方法。その形式仕様記述言語にはいろいろあったのですが(過去形)、そのなかにCSPにデータ構造を導入したような形式仕様記述言語Estelleがあって、そのEstelleにより記述したプロトコル仕様を実装するためにEricssonはConcurrent Pascalを作っていた。ErlangはそのEricsson版のConcurrent Pascalの影響を受けたというか、それを拡張して実装したはず。なんでこんな事情を知っているかというとEstelleを含む通信仕様記述言語のISO委員だから(Estelleの拡張版の規格化では多少の貢献があったりします、ちょっと自慢してみたり)。まぁ、当方の話はどうでもいいのですが、ErlangがCSP的な記述ができるのは当然というか、Erlangの前身の言語がCSP的な記述の実装言語ということ。

あとElrangは交換機用言語として設計されたこともあり、実行単位の粒度の違いは気をつけた方がいいかもね。交換機の実行モデル(そんなものがあったとはもえないが)は実行単位が小さい、つまりスレッド粒度が小さいので、通常ではスレッドに割り当てなかったような小さい処理もスレッドに割り当てた方が実装しやすいし、スループットもあがるのですが、これをサーバ環境で動かした場合に実用になるかは別問題。そうそう元交換機技術者の方がErlangはうまく使いこなせるかもしれませんね。

ただ、Erlangという意味ではないですが、一般論として交換機用の言語は弱いところもあります。交換機の世界というのはエラーハンドリングを含めてハードウェア的に多くのことが解決される世界、TCP/IPのようになんでもソフトウェア的に解決しないと世界には向かないのです。Erlang好きの人に反論されるそうなので、ちょっと補足しておきますが、いまのErlangは交換機だけではないのでしょうが、癖がある言語である以上は記述対象がErlang向きか不向きかを見抜く眼力に必要だと思います。

まぁ、こんなわけでErlangというと20年前の古い言語という印象でしたから、最近になってErlangという名前を見聞きしても、当時のErlangとは違う言語としばらく思い込んでいたぐらい。なお、Erlangがこの時代になって流行る理由はいろいろあるのでしょうが、Erlangは交換機プログラムの記述として開発されたことを考えると、いまはTCP/IPなどの通信プリミティブが隠蔽されて、ある意味でいまのシステムは往年のチャネルベース通信プログラミングに近い世界になっているからかもしれません。実はErlangそのものよりも、Erlangがいま脚光を浴びる背景の方が断然興味深いです。

2010年2月27日

昨日の続きです。当時の並行オブジェクト指向で議論されていた話題に並行処理の定義方法があります。ちょっと歴史を説明しないといけないのですが、ひとつのプログラム内に並行処理をいれると効率的な処理ができる一方で、前述のように排他制御や同期処理をしないといけないのでプログラミングがたいへんになります。初期のUnixはそれを嫌って、各プロセスに割り当てるスレッドは高々一つと制限しました。そのうえ並行処理を行うときはプロセス自身を複製(fork)するという方法をとって、並行実行単位間の共有変数を排除。この結果としてはUnix向けプログラミングは簡単化させて、Unixの普及の要因の一つになったと思います。ここで興味深いのはUnixの前身のMulticsではプログラムの並行実行、つまりマルチスレッド実行を許していたので、Unixはプログラミングのシンプルさ・容易さのために、あえて低機能化させたといえます。

並行処理もif文やwhile文と同じ制御フローですから、これらの制御フローと同様に構文として記述すべきという考え方がありました。プログラムのブロック文に対して明示的に並行実行を制限する方法です。例えば二つのブロックは並行実行されるとかね。この場合はプログラマーがスレッドの起動を含めて定義することになり、きめ細かい制御はできますが、(モニターなどを導入するにしても)共有変数などのを管理するのは容易ではありません。

また、構文的な記述ですが、非明示的に並行処理を記述する方法もいくつか導入されました。例えばAdaなどはCSP的なガード付きコマンドという概念を導入して、スレッド実行可能な関数やサブルーチンに実行に必要な前提条件を定義しておいて、その前提条件が成立すると実行されるという方法をとりました。例えば通信データが届くと、所定のサブルーチンが呼び出されて実行するやり方。この方法ではスレッド起動そのものはシステム側に任せることになりますが、通信や制御のプログラムの場合はイベント駆動になることが多いのですが、この方法はイベント駆動的な処理では便利なので他の並行処理記述言語でも導入されました。最近でいうとGoもこれに近いプリミティブを導入しています。

ちょっと話題から外れますが、1990年前後に盛んに研究された並列Lispを含む並列関数型プログラミング言語では、関数単位にスレッドを割り当てました。これは関数の実行には副作用がすくないことを利用したわけですが、関数自体はどう呼び出されるかわからないので、並列度が上がりすぎるという問題を抱えていました。マルチコア時代は関数型言語の時代とかおっしゃる方は多いのですが、並列度を上げればいいというものでもなく、実際、スレッド数が多くなるとコンテキストスイッチのコストが大きくなります。それと歴史的に言えばプログラマーが並行実行を制御できない言語はベンチマークではよくても実システムでは向かないのですよね。だから最近話題になっている関数型言語による並列処理も同じ問題を抱えることになるでしょう。また、関数型言語だけではなく、手続き型の言語でも関数やサブルーチン呼び出し時に並行実行させるタイプもありました。もちろん、これら以外に並行処理の記述はいろんな方法がありますが、だんだんマニアックになっていくので、話を元に戻しましょう。

さて昨日は並行オブジェクト指向の話題だったので、話を並行オブジェクト指向に絞りますと、昨日書いたように当時の研究では複数オブジェクトは並行実行させるが、各オブジェクト内部は高々シングルスレッドとすることで、オブジェクト内部は逐次処理、オブジェクト間の相互作用として並行処理をさせる方法と、構文として並行処理を導入する方法が議論されていました。しかし、1995年頃に登場したJavaはスレッドそのものをオブジェクトとして扱う、つまりスレッド実行をオブジェクトとして導入して、そのオブジェクトに処理を渡すと並行処理されるという方法を導入しており、そのJavaの普及とともに並行処理の記述方法の議論は下火になってしまいました。昨日の話題にあげたScalaやErlangは結局、時計の針を戻すというか、Java登場以前にもどった感じなのですよね。

脱線しますが、Javaの並行記述は中途半端でしたね。スレッドそのものをオブジェクトとしたので、Java言語自体には並行記述と独立させることに成功したのに(ここまではよかった)、同期制御(synchronized)を言語側に導入してしまったので、並行実行はオブジェクトとして定義して、一方で並行実行の同期制御は言語として定義するということになっています。インターフェースに類似した方法で、クラス定義そのものとは別に同期制御を宣言できるようにしておくべきだったかもしれません。というのはクラス定義ではあくまでも機能要件を書くべきであり、同期などの非機能要件はクラス定義に埋め込まない方がいいので。

いずれにしても並行処理はプログラミングにおいては鬼門であり、多くのプログラミング言語は並行処理は避けていました。というのは並行処理というのはプログラミング言語では扱いにくいのです。つまり並行処理は実行に依存するのでプログラミング言語だけで定義できる世界ではなく、並行実行を表す計算モデルも考えないといけないのです。この並行計算モデルもたくさんあります(実は博士論文は並行計算モデルだったりします)。ScalaやErlangが流行るところをみると、CSPやActorモデルなどが再び脚光を浴びるのかもしれませんが、並行計算モデルとプログラミング言語の実装・実行とはギャップがあるので、並行計算モデルがあれば相互排除や同期の問題が解決するというものでもないのですよね。

2010年2月26日

コンピュータサイエンスの技術はある方向に振れると、しばらくすると逆の方向に振られることがあり、それを繰り返します。例えばいまはクラウドコンピューティングが流行っていますが、10年前はPeer-to-peerシステムが流行っていました。クラウドコンピューティングは多数のサーバで処理をさせるので分散システムの一種にもみえますが、サーバを一カ所に集めるという点では集中システムとしていいでしょう。すくなくてもPeer-to-peerシステムとくらべたら十分に集中システムですから。

最近、興味深いのはオブジェクト指向言語のScalaやErlangが話題を集めていることでしょうか。どちらもActor Modelをベースにしているそうですが、オブジェクト指向言語の歴史でいうと、Actor Modelなどの並行処理用オブジェクト指向言語の研究が盛んになったのは1985年からの6,7年ぐらいだと思います(Actor Model自身はもっと古いですが)。そして1990年後ぐらいから議論されてきた話題のひとつは、各オブジェクトは高々のひとつの実行スレッドとするシングルスレッド実行モデルと、一つのオブジェクトでも複数同時処理を許すマルチスレッド実行モデルのどちらがいいかというもの。

さてシングルスレッド実行モデルとマルチスレッド実行モデルは何が違うかというと、前者は各オブジェクトは能動的に処理してもよい、つまり各オブジェクトに高々一つのスレッドを割り当てるが、オブジェクト内部的には逐次プログラムですから、オブジェクト内部で排他実行や同期をしなくてもいいので、オブジェクトのプログラミングは楽になります。一方、マルチスレッド実行モデルでは各オブジェクトは能動的に処理されますし、各オブジェクトにも複数のスレッドが割り当てられます。このため処理効率はあがりますが、オブジェクト内部で排他実行や同期する必要が出てきます。どちらもメリットとデメリットがあるのですが、シングルスレッド実行モデルの代表格というのが前述のActor Modelでした。

ScalaやErlangなどの並行処理の記述性を重視した言語が、シングルスレッドモデルというか、Actor Modelを採用したのは当然の帰結なのですが、正直言って、1990年後の議論がリバイバルを見るような感じですね。(Erlangは試しで使った程度ですが)Scalaは実装につかったりします。ただ、新しいプログラミング言語というよりも、昔のプログラミング言語で書いているという感覚はぬぐえないのですよね。ScalaやErlangに関しては、しばらくして実装事例が増えるとともに、記述の容易さよりも性能を重視して、マルチスレッド実行モデルがもてはやされるのでしょうね。歴史は繰り返されますから。もちろん当方の予測を裏切るような展開を期待しておりますが。

むかしの話ですが、4年生になって研究室に配属されて初めて研究室にいったときに、最初にあった人が、たまたま通っていた大学に転がり込んでいたCarl Hewitt(Actor Modelの創始者)さんでした。まぁ、このあたりから人生が狂ったような気もしますが、いま考えるとすごい環境でしたね。ちなみに4年生の時に初めて電話で話した外人研究者はL.Lamportさんでした。大学で講演する予定があり、その日程をきくために電話をかけてきたようでした。英語がさっぱりわからず別の人にかわってもらいましたが。

2010年2月25日

ここ数年、自分的には専門外とおもっているACM Multimediaという国際会議のプログラム委員をしており、フルペーパーの締め切りは来月初め。マルチメディア系の最難関国際会議らしいのですが、当方が普段投稿しているシステム系の研究分野の論文採択率からみると3倍以上、ゆるいような気もしますが。まぁそれはともかく、毎年査読をしていて感じるのは、マルチメディアやコンテンツの研究は最後は主観なので論文を書く方も、読む方もたいへんということ。この国際会議はACM主催であるようにコンピュータサイエンス分野の国際会議とはいえ、分野の特性上、マルチメディアのコンテンツを作ることを目的となった研究もでてきます。ただ、コンピュータサイエンスからみるとマルチメディアのコンテンツというのは出力に過ぎず、ここで求められているのはその出力を出すための方法。もちろんマルチメディア系コンテンツの性格上、出力自体の評価は難しい。そうなるとある程度、出力したいコンテンツの種類やクオリティを明確にしている研究の論文が採択されやすく、逆になんかやってみたら、たまたまいいコンテンツができたというのは、そのコンテンツのクオリティがよくても採録されないのですよね。SNSを含むコミュニケーションシステムやアーカイブシステムの研究。研究室で楽しく盛り上がっているのはわかるのですが、楽しく盛り上がっているのと研究的に価値があるのはまったく別なのですよね。その楽しいコミュニケ−ションやアーカイブを実現する技術を説明して欲しいところ。

2010年2月24日

トヨタの製品品質&リコール問題が話題になっています。このニュースを見る度に思い出すのが、1990年代にトヨタの役員の方(トヨタの主力工場の田原工場長だったはず)から伺った話。当時、日産が失速し始め、トヨタはシェアアップ戦略の真っ最中だったのですが、その方曰く、「シェアが50%を超えると社会的責任が大きくなる」という懸念を話されてました。その方の意図はシェアが50%を超えると、健常者向け以外の自動車も作らないといけないなど、儲かる自動車だけ作っているだけでは済まなくなるということだった記憶しています。さて、今回の騒動は、トヨタバッシングとかいろいろいわれていますが、世界で一番生産台数の多い自動車会社になると、製品品質を含めてそれだけの責任が出てくるということなのかもしれません。当方はこの問題に対してコメントする立場ではないですが、東洋の小国にある、いち自動車会社ではなく、世界で一番生産台数が多い自動車会社にふさわしい対応していただきたいです。

2010年2月23日

早大理工(高田馬場)で打ち合わせがあったので、オフィス(神保町・竹橋)にもどる前にNTTの武蔵野研究所で開かれたR&Dフォーラムにいってみる。時間があまりなかったので、クラウドコンピューティング(CBOC?)と(ややマイナー系の)通信関連を中心に拝見。いつものように素人と前置きをしてから、研究員さんの説明をありがたく拝聴させていただきました。ところで来場者は多かったのですが、さすが通信業界、それもNTTだけあって来場者はどなたもスーツ、スーツ。さて当方はというとグレーのジーンズ、グレーのモッズコート、中にはダークグレーのジレ、首には白黒チェック柄ストールを大巻にして、さらに白黒チェック柄のハンチング帽という、あの場では絶対にありえないファッションでした(普段はスーツ着ていることも多いのですよ、念のため)。知り合いのNTTの研究員の方にカジュアル大賞を進呈などと冷やかされておりました。確かに目立っていたかも。とはいえNTT様には懲りずにまた呼んでいただけるとうれしいです。来週のNTT関連のイベントには協力させていただいておりますから。

2010年2月22日

昼間は原稿書き、夜は論文書き。ところでSalesforce.comが日本国内にデータセンターを作ることを表明したことが、なぜか日経ビジネスに出ていました。実は雑誌版の方は読んでいたのですが、Salesforce.comはこれまでに何度も国内にデータセンターを作ると表明しているので、また言っているという程度の認識だったのですが、オンライン版の記事が出て話題を集めたようです。

Salesforceは海外では他社のデータセンターを借りているので、データセンターを作るといっても間借りするだけなのでしょう。わざわざ日本にデータセンターを置くメリットは少ないのですが、SaaSやクラウドではデータが国内にあるか否かに拘る人も多いので仕方ないのでしょうね。

Salesforce.comのサーバは1000台程度言われており、小規模性を利用してデータベースなどの問題を回避しているようですね。このページで何度も書いたように、個人的にはGoogleやMS、AmazonのデータセンターよりもSalesforce.comのシステムの方が興味があります。さてクラウドコンピューティングの話になると、十万台規模のデータセンターに注目が集まりがちですが、本来ならばサーバ数は少ないにこしたことがないです。サービス数の多さに注目するのはそろそろ卒業したいですね。だいたいサーバの性能の議論なしでサーバ数だけ比較するのはまったく意味がないのですよね。

それとクラウドのデータセンターではPUE値が話題を集めますが、PUE値は効率を表す指標のひとつに過ぎませんし、サーバを動かせば動かすほどPUE値はよくなりますから、省電力性をあらわす指標には必ずしもなりません。低消費電力を目指すならばサーバ数を減らした方がよっぽどいい。それとクラウドインフラ事業者にとって関心事はPUE値でも消費電力量でもなくて、電気代そのもの。つまり電気代が安くすることに関心があります。その意味では電気代が高い場所(例えば日本)でPUE値の小さいデータセンターを作っても意味がありません。でも霞が関方面の一部ではPUE値が小さいデータセンターを作ることが目的化しているような動きがあります。その委員会には関わっていないので、コメントする立場でもないですが、ここまでズレていると気の毒になってきます。

勘違いがないように付け加えておきますが、PUE値が指標として意味がないというつもりはありません。GoogleなどはPUE値の低さに拘るだけでなく、自社のデータセンターのPUE値を積極的に公開しています。クラウド向けの巨大データセンター競争は自動車で喩えるとF1レースのみたいなもの。PUE値は自動車でいうと燃費に相当するのですが、F1チームがレーシングカーの燃費はトップシークレット。そのPUE値をなぜ積極的に公開するのかという背景は考えておいた方がいいです。当方もその背景は推測の域を超えていませんが、一般の自動車の燃費規制と同じかもしれません。データセンターは消費電力が多く、米国内の産業別消費電力では上位にあります。PUE値が高い(つまり効率の悪い)データセンターには電力消費量に何らかの規制の動きがあるのかもしれません。もちろん現在は推測の域を超えていませんがね。

2010年2月21日

ひたすら原稿書きの一日。ところで昨日、カメラのことを書いたので、その続きを少々。個人的な好き嫌いをいわせてもらうとカメラはデジタルよりもフィルム。レンズはオートフォーカスよりもマニュアルフォーカス。シャッターは電子式よりも機械式。さすがに露出とシャッター速度の組み合わせは瞬時に設定できるほど慣れていないので、露出計または自動露出(AE)に頼りますが(ネガフィルムは粘りがあるのでなんとかできても、ポジフィルムはマニュアル露出の自信はありません)。ただ、フィルムカメラは現像やプリントにラーニングコストがかかります。特に最近はフィルムの需要が減ったために、フィルム代も現像代も年々上がっています。特に白黒フィルムは現像が高いし、時間がかかる。このためラーニングコストを考えると使うのはデジタルカメラばかりとなりました(それでもオフィスにフィルムカメラを3台も隠し持っていますが)。それでも古いマニュアルフォーカスをデジタルカメラに付けたりしています。便利さもいいですが、不便を楽しむという余裕はほしいです。

ただ、非コンピュータ的なものへ憧れは、商売柄、コンピュータは嫌というほど触れますから、その反動なのかもしれません。ただ、ここで書いていいのかはわかりませんが、本質的にコンピュータが嫌いなのだと思います。当方のまわりをみるとマイコン少年からそのまま情報系の研究者になったような人も多いのですが、当方はたまたま情報系の研究室に所属することになったからなので、コンピュータにまったくというほど思い入れがないのです。基本的に嫌いなコンピュータを直接使ったり、見なくても済むようにするためにコンピュータの研究をしています。

2010年2月20日

いろいろあって休日出勤。今月は4回目かなぁ。あまり思い出せない。というか気にしているのは法定休日数(4週間に4日間の休日)を守っているかだけ。だって守れないと勤務先が労働基準法違反になりますから。ところで当方のオフィスは19階ですが、20階で工事があったようで結構うるさい。それはまぁいいとして、ちょっと驚いたのはその工事業者。米国の超大手ビル管理会社の日本支社。まぁ日本でも六本木ヒルズなど都内でも管理業務をしているので、見かけること自体は不思議ではないのですが、40階建て以上のビルの仕事はしないと思っていました(勤務先のビルは22階建て)。ところで、このビル管理会社は米国では、いわゆるグリーンニューディール計画の主役的な存在なのですよね。こんな身近でも仕事をされているとはね。

帰り道に本屋に寄った道中で撮った写真をここにおいておきます。今回も35mmフィルム換算で50mm相当の単焦点レンズ一本。このレンズを手に入れたのは何年も昔なのですが、フィルムカメラではあまりいい印象が無く(コントラストが高すぎる)、実はあまり使っていなかったレンズ。でもデジタルカメラで使ってみると階調も立体感もなかなかいい感じ(サイズ縮小だけで画質的には何もいじっていません)。昨年末に同じ画角の別のレンズで撮った写真と比べるとまったく違う世界。それとデジタルカメラ全般にいえますが、シャドーの粘りが強いというか、フィルムだったら黒で潰れているような暗部も撮影されます。おかげで1/3か2/3EV程度アンダーで撮影する癖がついてしまっています。

2010年2月19日

午前中はいろいろたいへんでしたが、気を取り直して午後は多摩センターで講演。クローズドな集まりでの講演はいいですね。不特定多数の方がこられていると話せることと話せいないことの境界線が難しいですから。いずれにしても今日、当方の講演を聞いていただいた方にとって何かの参考になれば幸いです。そのあと勤務先からの事務方から某省絡みの連絡をうけて大急ぎでオフィスに戻る。それにしてもいろいろおきますね。おかげで午前中のいろいろたいへんだったことの一部がひっくり返りました。

2010年2月18日

最近、人力タクシーのすぐうしろに渋滞した自動車の列が続いているのを立て続けに目撃。人力タクシーは環境負荷が小さくても、それ以外の環境負荷を増やしていることになります。ただ、これは結構示唆に富んでいるかもしれませんね。人力タクシーによる渋滞は部分最適化が全体最適化につながらない一例なのですが、こうした現象は他にも多いように思います。そして、これからのITに求められる役割は、部分最適化が全体最適化につながるように調整することかもしれません。実際、いまのよなか部分的な最適化は結構進んでいると思うのですが、その部分最適化が組み合わさると衝突を起こすというのか、逆効果を生み出すことも多いのですよね。それをどう取り除くのか。もちろんケースごとに解決方法は違ってきますが、部分最適化から全体最適化に向かうのは世の中全体の流れだと思います。

2010年2月17日

しかし、それにしてもいろいろなことがありすぎです。体力的にも辛くなってきました。怒濤の年度末を乗り切れますでしょうか。

2010年2月16日

情報処理学会の機関誌(2月号)が届いたのですが、自分の研究の紹介記事を書かせていただきました。内容はコンパイラのコード最適化とかソフトウェア検証を物流トラックに適応するというもの。ちょっとだけ紹介すると、トラックの輸送経路をプログラムの実行フローと見てしまって、コード最適化で経路を効率化する話。少数のトラックを多数の荷主が共用する共同物流で、荷主の条件をソフトウェアの仕様と、トラック経路をソフトウェアの実装と見てしまって、荷主の条件にあったトラックを見つけるためにソフトウエア検証を使うという話。コンピュータサイエンスというと、言葉が悪いのですが、結局、コンピュータという狭い世界で、問題を見つけて、その問題をコンピュータを使って解いているだけともいえるわけでして、むしろコンピュータサイエンスの手法をコンピュータ以外の世界、つまり現実世界に応用しようという試みです。いまのところ同じ方向性を目指してくれる研究者が少なくて寂しいのですが、今回の記事で賛同者が増えると嬉しいですね。なお、来月号も当方の研究の紹介記事がでます。ただし、話はだいぶ違って排出量取引です。

2010年2月15日

こちらの記事によると機内で無料なのはお水とお茶だけだそうです。飛行機もだんだん世知辛くなってきましたね。まぁいろいろたいへんなのはわかりますが、国際線もエコノミー席は目に見えてサービスがわるくなっていますし。それでも出張させていただけるだけ恵まれているわけで文句はいえません。

もっとも個人的には国際線もシート電源さえあれば機内食や飲み物はなくてもいいかなぁ、と思ったりしています。機内食や飲み物は買って持ち込めばいいわけですから。欧米線だと飛行時間が長いので持ち込んだ食べ物が痛みそうですが、個人的には機内で配られる二回目の食事は食べないことが多いのです。それと機内のでは寝ないので(仕事を抱えたまま出張するので寝てる暇ないです)、シート電源さえあればエコノミー席で必要にして十分。ただ、なんど書きますが、シート電源だけは欲しい。実は飛行機に乗る度にシートテレビをつけるぐらいならばシート電源を付けてとおもったりしています。以上はどれも少数意見なのでしょうね。

2010年2月14日

Google App Engine (GAE)についていけません。GAEはよくいえば日々進化しているのですが、悪くいえば日々仕様変更があって、せっかく作った機能がGAE側でサポートされたり、作ったプログラムの挙動がかわったり。とくにデータベースまわりは仕様変更というか、こうした追加について行く覚悟がないと手を出せないです。似たような状況は1995-2000年のJavaまわりでも機能拡張が頻繁に行われたのですが、Javaの場合は後方互換性は保たれていたのですが、GAEの場合はどうなのでしょうかね。Javaは古いランタイムを持ち出せば対応できましたが、プラットフォームがクラウド側にあると、仕様変更に付いていくしかない。いずれにしても個人的にはGAEは手段の一つであって、GAEを使いこなすことは目的ではないので、そうそうつきあってられません。

ただ、この状況はクラウドコンピューティングの本質を示しているのでしょう。クラウドコンピューティングではアプリケーションというか、サービスは自己完結しているわけではなく、サービスが別のサービスを利用していることは当たり前。そうなるとプラットフォームの仕様変更だけでなく、利用しているサービスの変更をつねに影響を受けることになります。前にも書きましたが、クラウドコンピューティングのビジネスモデルはプラットフォームもサービスも、最新機能は無料で提供して、後方互換性は有料で提供することになると予想しており、最新版に付いていくのもたいへんだし、古いプラットフォームやサービスを使い続けるのもたいへんということになりそう。

このページで何度も書いたことですが、当方がクラウドコンピューティングのインフラそのものを研究対象にしないのは、クラウドコンピューティングは必要性があって作るものと思っているから。例えばGoogleならばMapReduce、Amazonならば自社のネット販売システムという確固たる目的があってクラウドコンピューティングインフラを作っています。逆にいえばクラウドコンピューティングを作ることを目的にしてシステムを実際に作っても、確固たる目的があってシステムを構築している連中には勝てません。そして当方に限れば自前のクラウドコンピューティングのインフラ技術には興味はあっても、インフラを作る理由の方ががないのです。その意味ではGAEはGoogle自身がアプリケーション実績があって、それを一般に公開したというわけではなさそう。これはMSのAzureも同じ。GAEがどうも筋が通っていないのも、GAEを作っているGoogle自身がGAEを使うアプリケーションがないというのが遠因にあると思います。逆に言えばGAEもAzureもGoogleやMSが自社開発サービスのプラットフォームとなることがブレークするかの試金石になりそう。

2010年2月13日

それにしても情報系の研究はデジャヴが多いのでしょうね。昔の手法が忘れられた頃に新規の発明として再登場。例えばWebサービスのシステム技術はCORBAなどで開発された技術のサブセットといってもいい状態。以前、他分野の方から情報系の研究はデジャヴが多い理由を聞かれたことがあります。その理由は複数あると思うのですが、そのひとつは情報系では論文誌よりも国際会議を重視するというのが背景にあるように思っています。

論文誌の査読は研究トレンドに左右されるわけではなく、純粋に投稿された論文が優れているか否かで評価するので、過去の研究に遡って新規性などが評価されます。一方、国際会議というのは基本的に一年おきに開かれることもあり、そのときの研究トレンドに左右されやすい。だから優秀な研究でもそのときの研究トレンドにあってないと不採録になります。

この結果、研究トレンドから外れると論文が通らなくなり、その結果、予算が取れなくって、研究が継続できなくなる。そして何年か経って再び研究トレンドになったころには過去の研究は完全に忘れ去られているので、過去の研究の焼き直しの研究が新規研究として再登場することになります。また、国際会議の場合、研究トレンドに合致した論文も研究トレンドの中で評価されるので、過去に類似研究があるかはそれほど重視されるわけでもない。

そうなると何が起きるかというと、研究トレンドの以前の研究と同様の研究が、その研究トレンドでは新規研究として扱われることが多くなります。車輪の再発明ではないですが、昔の研究が忘れた頃に新規の研究として再登場することになります。情報系の研究の進化が速かった頃は国際会議偏重でもよかったと思いますが、ここまでデジャヴ的研究が多い現状を考えると、他分野と同様に論文誌重視にした方がいいのかもしれません。少なくても研究トレンドから外れた研究でも継続的な発展に正当な評価をあたえる仕掛けは必要です。

2010年2月12日

いろいろ雑用の一日です。たまっていた事務仕事を片付けていくだけなのですが、なにぶん量が多すぎて片付かず。

2010年2月11日

つきあいもあって某省のイベントに顔を出して、関係者といろいろ相談。それにしても某省もたいへんそうですね。某省はそのイベントで某自動車メーカの自動車に省エネ大賞の大臣賞に選んだそうですが、その自動車のブレーキ問題から、受賞辞退の申し入れ。ちなみに大臣賞は一番上位の賞だったそうで、某省は面子丸つぶれ。ただし、某省の現大臣は某自動車メーカの労組出身ということもあって、文句も言えないそうです。ただ、某省も自動車担当部局の経験者が重用されていたところはあり、そろそろ考えた方がよいのでは。国内における自動車産業はすでに山をすぎているのではないでしょうか。これから坂道を下るだけの産業に肩入れするぐらいならば、これから坂道を上る産業をサポートしていただいた方がいいと思いますけど。もちろん今の時代、特定産業に的を絞った産業政策がいいとは思えませんがね。

2010年2月10日

来客対応と予算の継続申請のためにe-radと格闘。書類の方はバイク便で送られていきました。毎度のことながらギリギリですね。締め切りまで時間刻みで書類を作っていくわけですが、胃が痛くなるような緊張感がたまらない、と思わないとやっていけません(まわりにも迷惑をおかけますが)。

ところでe-radには手を焼きました。ちなみにe-radはe-Japan構想の電子政府構想の一環で作られた研究予算の電子管理システムで、政府系の競争的資金の応募に使います。ただ、このシステムは操作ともかく煩雑。今日、e-radを使ったのは予算の研究代表者をしている関係で研究分担者の情報を入力したのですが、操作が煩雑でともかく手間取りました。そもそも継続申請なので新規申請時に入力した情報を使えればいいのに、すべて再入力しなければいけないし、無駄が多いです。そのうえ紙ベースの膨大な予算書類はいままで通り必要ですし、紙ベースの予算書類とe-radへ登録はまったく独立。つまり電子登録の手間だけが増えている状態。

電子政府とか電子行政とかいうと聞こえはいいのですが、各省庁ともに電子行政システムを構築・運用することが求められているので、仕方なく構築・運用しているケースはあるようです。e-radの場合はどうかしりませんが。つまり、電子行政システムを使って省力化が目的ではなく、電子行政システムの実績を作ることが目的ですから、そんな電子行政システムに使い勝手を求める方が間違っています。結局、嬉しいのは政府系の情報システムを請け負う企業だけなのかもしれません。

2010年2月9日

最近はつくづく感じるのは潮目の変化でしょうか。情報系の研究は15年ぐらいは優遇されてきました。e-Japanを始め、IT関連の研究に投資することが経済活性化になるということになっていたし、科学技術予算のなかでも情報系だけが独立した枠がありました。例えば当方の勤務先は、情報系に特化した国研。創立は10年ちょっと前なので新しい研究所ですが、ここ10年間で他の分野で新しい国研ができたかというと少ない。逆説的ですが、それだけ情報系は優遇されてきたということでしょう。

それではここ15年ぐらいで国内IT業界は伸びたかというとかなり疑問。たしかにITゼネコンという言葉まで登場するようにIT業界の規模は他業種並みに大きくなりましたが、同時にここ15年は国内IT関連企業は海外競争力を失った時代でしたし、技術的にも海外技術の輸入ばかりとなり、日本から発信した技術は大きく減ったのではないでしょうか。

そうなると情報系の研究予算を特別扱いしてきたことも見直されることは必至。実際、来年度予算ではこれまでの情報系の予算枠という事実上、消失したような状態。もう少し正確に説明するとヘルスケアとか環境とかなどのターゲット指向になってきて、そのターゲットにむかう出発点は情報系だろうと、医学系だろうと関係ないということになりそう。

この状況は日本国内だけではありません。先日、NSFのディレクターとあったのですが、NSFも予算はターゲット指向になってきていて、例えばセンサーネットワークのNSF研究予算だったCyber-Physical Systems (CPS)も、NSF内部では環境モニタリングとして位置づけられていて、必ずしもセンサーネットワークという特定技術だけをねらった予算ではないと軌道修正をしたそうです。

情報系の予算枠があった時代は、情報系の研究者はその枠の中で評価をされました。つまり、情報系の研究者は、情報系の論文誌や国際会議に論文を書いていれば評価されたし、それで予算も獲得できました。しかし、その枠がなくなってしまったら、情報系の研究者は、情報系分野以外の研究と獲得合戦をすることになります。残念ながら、そうなったとき情報系の論文誌や国際会議における論文実績が評価されるとは限りません。全部とはいわないものの他分野でも通用する論文実績を多少は持っていないと生きていけなくなります。例えば国際会議や和文論文誌は他分野の評価基軸に合わず、英文論文誌に比重をおくことになりそう。情報系の難関国際会議に論文採択で一喜一憂していられた幸せな時代は終わったのかもしれません。また、先述のようにNSFが分野横断型に軌道修正しているので、今後は米国の研究者の研究評価基軸も変わってくるでしょう。

いずれにしても、これまでやり方では数年後にはジリ貧になるのは間違いないでしょう。研究者としてこれからどう生きていくかということになります。当然ですが、これは当方自身にもいえることです。すくなくても情報系以外からも成果が評価してもらえるような研究をしていかないと生きていけなくなりそうです。

2010年2月8日

今週は怒濤の一週間が確定状態なのですが、月曜日ですでにたいへんなことになってます。懸案は予算の書類の作成。その合間に某学会の機関誌の原稿と論文を書くという状況。一日一つでも間に合わない計算。さてさて乗り切れますでしょうか。

2010年2月7日

書類作成で、午後からオフィス。ところで今月に入ってからスマートハウス絡みの相談がたてつづけにあったのですが、正直いって、スマートハウスっていまさらという気がします。世の中ではスマートハウスは新しいと思っている人が多いようですが、大昔のホームオートメーション(HA)が流行った時代から繰り返されてきた議論。それとだいたい10年ぐらいのサイクルで流行しますね。1990年代前半のホームオートメーション、2000年前半の情報家電やホームネットワーク、そしていまのスマートハウス。違いを説明できる人はいないのではないでしょうか。

それとこのサイクルはネットワーク側の技術動向と連動しています。まずは1990年前後のホームオートメーションは1985年くらいのニューメディア構想とISDNによる家庭向けデータ通信が伏線となっています。そして2000年の情報家電やホームネットワークは1995年のインターネットの普及が伏線です。さて、スマートハウスは何が伏線になっているかが今度の動向を占う上で重要になります。その伏線ですが、Web 2.0のブームもあげられるかもしれませんが、個人的にはむしろ携帯電話向けサービスのビジネスモデルが伏線になっているように思います。というのはアプリケーションやサービスはスマートハウス内にダウンロードするか、Webブラウザを介して利用することを想定していますから。

なお、当方のところに相談に来られた方々は、そろってホームゲートウェイを想定したシナリオを描かれているようです。もちろんホームゲートウェイがよくないというつもりはないのですが、あくまでも一つの方法であり、他にもいろいろあるはず。例えばホームゲートウェイを介さずに携帯電話ネットワークを通してデバイスが直接外部と接続することも想定されるはず(例えばテレビ上でYouTubeを見る場合、ゲートウェイはないに等しい)。なのに、どうしてホームゲートウェイありき、という発想になってしまうのでしょうかね。ゲートウェイを前提の方法は2000年前後の携帯電話におけるゲートウェイ方式のサービスモデルであったWAP (Wireless Application Protocol)の壮大な失敗で通信業界は懲りているはずですが、ホームゲートウェイ好きの方はゲートウェイ絡みは死屍累々という過去を知らないみたいですが。

それとホームゲートウェイがお好きな方はOSGiを魔法の技術のように語られるのですが、OSGiは所詮はJavaベースのソフトウェア更新単位にすぎないわけで、OSGiを使うといままでできなかったことが突然できるようになるわけではありません。先日はOSGiって初耳という顔をしてお話を伺っておいたのですが、思いっきりOSGiをふくらませた話をお聞かせいただきました。いろいろツッコミをいれたかったのですが、ガマンです。

いずれにしてもスマートハウスは、過去のホームオートメーションや情報家電・ホームネットワークの失敗から何を学習していて、意義のある差異を出せるかにかかっていると思います。それができなれば過去の類似例のように忘れ去れて、また10年後に似たようなブームがやってくるだけでしょう。

2010年2月6日

昨日はまた違う研究予算関連書類を徹夜で作成中。しばらくは徹夜の日々が続きそう。予算をいただいたら書類を作るのはわかりますが、正直いって、いま書いている書類に何の意味があるのかがさっぱりわからない。研究に対するモチベーションが95%ぐらい下がりました。大きな研究予算をもらったあと、研究しなくなる研究者(つぶされたというべきかも)が少なからずおられますが、その気持ちがわかりますよね。この研究が終わったら、まぁ研究をやめないまでも、予算を必要としない研究分野にかえたいですね。

2010年2月5日

研究予算を頂いたら書類書きなどの事務仕事は仕方ないのでしょうが、ここ数年、事務仕事の量は異常ですよね。研究って、予算がないと研究できないのですが、予算があると研究ができないのも事実なのですよね。特に外郭団体に仕事を作るためとしか思えない書類が多くなりましたね。霞が関の外郭団体の方々は仕事熱心というか、暇というか。こちらの書いた文章の「てにおは」の間違いを細かくWordの修正機能を駆使して間違いをご指摘してくださいます。そんな丁寧な指摘する御時間がおありになるのであれば、文章をそのまま修正して頂ければと思っています。誰も読まないような報告書の文章細かい推敲をする時間はないし、そんな無駄なことはしたくない。本省の担当者と直接交渉で解決した方がよさそう。

2010年2月4日

日経新聞から単行本を書かせていただくことになっているのですが、当方の執筆が遅れており、担当編集者さんにはご迷惑をおかけしています。今日は編集者の方が来られたのですが、平謝りするしかありませんでした。でもそのことを数人にお話ししたら、皆さん口を揃えて、編集者さんがわざわざ様子を見に来てくれるというのは特別なことで、それだけ期待されていることといわれました。ありがたいことです。皆様のご期待に添えるように精進します。

2010年2月3日

一日オフィスだったとはいえ、空き時間もなく会議から会議。ロングランで会議にずっと出ている感じ。時間が欲しいです。最近は来客が多く、10時からではおさまらずに9時からや、夜19時や20時以降にお願いすることも多くなりました。というわけでご迷惑をおかけしております。ただ、もう本当に時間がないのです。

さて某自動車会社ネタが続いていますが、トラブル絡みの発表が続く会社もめずらしい。報道によりますと、昨日のリコール記者会見に引き続き、今日のトラブルは看板ハイブリッドカーのブレーキがきかなくなるというもの。ただ、これはちょっと不思議。というのはハイブリッドカーは回生ブレーキになっているはずで、通所の機械ブレーキだけでなく、モーターそのものをブレーキ(回生ブレーキまたは発電ブレーキ)として使っているはず。なにが問題なのでしょうかね。ところでその自動車会社の副社長による「(ブレーキ制御の)コンピューターを変えた。クレームがあれば販売店でも変えていると思う。変更は2時間もあればできる」だそうですが、自動車もPCや家電製品感覚になっているのですね。自動車は最後は制動系に頼るしかなく、その制動系のトラブルとなると事態は深刻だと思うのですが、どうなのでしょうか。

追記です。今日の日経朝刊に、ご丁寧に回生ブレーキの解説付きで記事がでていました。やはり通常ブレーキと回生ブレーキの協調に問題があったそうですね。どんな協調に問題があったのかなど詳細はわかりませんが、ブレーキペダルを踏んだとき、通常ブレーキと回生ブレーキの比重のかけ方(とタイミング)はバッテリ持ちに関わってきます。回生ブレーキは発電ブレーキと呼ばれることもあるなど、モータを発電機にして、その電力をバッテリに戻しています。なので通常ブレーキの割合を上げると燃費がわるくなるのです。今回のコンピュータ交換で燃費に影響がでている可能性はありますね。

2010年2月2日

今日は大学院入試。面接と判定会議。さて今朝の日経朝刊の一面トップに政府の温暖化ガス削減への行程表案が出ていましたが、1990年比で25%のうち国内の排出削減は15%で、残りの10%は海外からの排出権調達だそうですね。麻生政権では2005年比で国内の排出削減は15%ですから、単純には比較できませんが、2005年比を1990年比に直すと17〜18%の削減でしょうから、国内削減量が後退している気もしますが、気にしないでおきます。ところで、今日、ある大手自動車会社はリコール対象が450万台(費用は1000億円)の記者発表をされたそうですが、その記者会見は社長ではなく、副社長がなさったそうですね。大きな自動車会社にとってはたいした案件ではないといいたいのか、それとも製品不良よりも社長を守ることを優先したのか。いずれにしてもすごい会社ですね。

2010年2月1日

Java関連の調べごとでSun MicrosystemsのJavaのページをみたら、Sun MicrosystemsのロゴのかわりにOracleのロゴが大きく出ていました。一瞬、URLを間違えたかと思いました。合併完了はきいていましたが、実際的にはもう少し先だと思っておりましたので。ところで論文の関係で古い図版のデータを探してたら、なぜかAdobe FreeHand形式のファイル。どうしたものでしょうね。困りましたね。FreeHandは10年ぐらいは使っていなかったはずなのですが。なおAldusがAdobeに買われる前の頃はAldus系のソフトウェアをよく使っていましたが。それにしてもAldusの名残はAfter Effectぐらいでしょうか。PageMakerもFreeHandも見かけなくなりましたね。あまり知られていないようですが、VisioはAldusでPageMakerを開発していた連中が作った会社。その意味ではMicrosoft Office VisioはAldusの継承者ともいえなくないかも。

2010年1月31日

某学会の機関誌向けの原稿を一気に書く。おかげで書籍の原稿がなかなか進まない。それにしても疲れました。最近、これっばかりですね。

2010年1月30日

今月は仕事量が処理能力を超えてしまっています。どうしたものでしょうかね。来月になると仕事量はぱっと消えればありがたいのですが、年末に積み残した分を含めて、どんどん累積されていく感じ。それにしても疲れました。

2010年1月29日

わけあってオフィスに待避してあった私物CDプレーヤー(DCD-1500AE)を自宅に輸送。その間、コンピュータ上でiTunesとヘッドホーン(HD-580またはAKG-K701)という構成で音楽を聞いていましたが、格段に音が違いますね。いつも思うのですが、iTunesは他の再生ソフトウェアと比較すると、音に解像感に欠けるというのか。それと音の定位がひまひとつのように感じます。もちろん使い勝手はとってもいいので、iTunesを使うわけですが。

2010年1月28日

iPadが発表されましたね。でも当方はというとデバイスそのものには関心がなく、コンテンツ保護をいれてくるか否かだけに注目していました。でも昨日の発表ではその部分に関する具体的な情報はなかったようです。

なんでコンテンツ保護に拘るかというと、iPadではApple御謹製プロセッサ(名称はA4だそうですね)を使うという噂があり、だとするとプロセッサにコンテンツ保護向けの特殊機能をいれてくる可能性がありますし、そうでなければ自社製プロセッサを使わずに市販のプロセッサを使えば十分なはずですから。

ただ何しろ情報がないので、ここからは御謹製プロセッサにコンテンツ保護機能があったと仮定したときのこと。想定されるのはCellプロセッサのようなコンテンツ保護の特殊実行モード(Isolated Mode)の導入ではないでしょうか。具体的には特別なデータ保護領域をつくり、その領域にアクセスできるのは認証されたプログラムだけにするというもの。このコンテンツ保護機能を入れると、ソフトウェアによるコンテンツ保護と比べると、格段に保護を破られる可能性は低くなります。これはコンテンツで儲けたいけど、コンテンツ保護が破られて、コンテンツが不正に広まってしまうコンテンツプロバイダーに安心感につながり、iPadならばコンテンツを提供してもいいというコンテンツプロバイダーはたくさん出てきそうです。当たり前ですが、コンテンツプレーヤーならばコンテンツを揃えられることが市場を制する第一歩ですからね。

それにしてもAppleはプロセッサ、OS、アプリ、そしてネットワーク側のコンテンツ販売サービスまで全部自社製。往年のIBMもびっくりというほどの垂直統合モデルなのですが、コンテンツ保護という点では有利に働く可能性があります。特にコンテンツ販売サービスはその特許で他社に対してアドバンテージがありますし、建設中と噂されるクラウドインフラを使って、多様なコンテンツ販売や期間レンタルを仕掛けてくるでしょう。クラウドコンピューティングとハードウェアレベルのコンテンツ保護が組み合わさると、これまでの(ネットに限らず)コンテンツビジネスを一変させる可能性もあるでしょう。

ところでAppleは今回の自社製プロセッサ(A4)を外販する可能性は少ないと思いますが、外販されると脅威ですよね。特にAppleのコンテンツ販売サービスの利用権を付けてプロセッサの外販をすると、このプロセッサを入・利用する端末メーカはAppleのコンテンツ販売サービスを利用したビジネス展開ができますし、Appleの方はデバイスを売らなくても、コンテンツ販売の一番おいしいところを労せずにとれることになります。

ところで自社プロセッサ向けのソフトウェア開発の心配をされる方が多いようですが、Appleにとって純粋にコンテンツプレーヤーという位置づけなのではないでしょうか。どうしても必要ならばWebベースのアプリケーションで十分。だからAppleは自社製コンテンツビューアーや再生ソフトウェア、Webブラウザが動けばいいと割り切っているのではないでしょうか。サードパーティのローカルアプリケーションがないといけないと思っている人って、失礼ながらパソコンの発想から抜け出せていないようにみえます。

2010年1月27日

今日の夜、Appleが電子ブックを発表するといわれています。Kindleは買うのはAppleの電子ブックを見てからにしようと思っていたのですが、どうなることやら。ここを書いているときAppleの電子ブックはまだ発表されていませんが、いい機会なので当方の電子ブックへの懸念を書いておこうと思います。世間では電子ブックへの賛美が多いのですが、当方は電子ブックはすごくいいと思いつつも、その一方で懸念も持っています。別に電子インクはダメで紙がいいなどとノスタルジックなことをいうつもりはまったくありません。懸念しているは書籍の停滞です。

電子ブックでは絶版がなくなるといわれています。これは古い本でも手に入るということになり、便利ですが、全面的にいいといえるでしょうか。絶版というのは書籍の新陳代謝を促すメカニズムだったのではないでしょうか。書籍は出版社の都合などもあり、ある時期になると絶版になり、入手できなくなります。その書籍の内容に需要があれば、別の著者が似たような内容の本を(最近の話題をいれつつ)書くことになり、その内容の更新・改良が行えます(書籍が絶版になったあと、同じ著者が別の出版社で類似した本を書いても、絶版になった本の出版社は目くじらをたてないことが多く、同じ著者で改良した書籍を出せることになります)。

逆に電子ブックで絶版がなくなってしまったらどうなるでしょうか。出版年月日が古い書籍がいつまでも市場に残ることになります。電子ブックで出版コストが減るとはいえ、既存書籍の存在は新刊書籍にとっては脅威です。たとえ既存書籍はその内容が多少古くなっていても、その書籍と類似した内容の書籍を新たに書こうとする著者や出版社にとっては営業的なライバルになり、出版を躊躇するところも出てくるでしょう。つまり絶版がなくならないことになり、既存書籍の存在が新刊本の登場を抑えることになる恐れがあると言うことです。もちろん当方の懸念は文学書などには当てはまらないと思いますが、実用書や(あまり技術進歩のない分野の)技術書は影響をうけるのではないでしょうか。また、電子ブックの登場で章単位などの部分的な出版や改訂もでてくると思います。その場合、書籍のうち古くなった部分だけ更新することになります。それ自体は画期的なことです。ただ、その一方で同時に古い書籍がいつまでも市場に残ることには変わらず、新たに類似書を書こうとする著者や出版社には大きなライバルです。

古い書籍の強制的退出は進化の停滞を防ぐために必要ではないでしょうか。なんどもいいますが、当方も電子ブックはすごくいいと思います。ただ、どんな技術も負の部分があります。でも、電子ブックの負の部分をいう方がすくないので心配になって書きました。

2010年1月26日

日経コンピュータの2009年10月14日号に書いた当方が書いたクラウドコンピューティングの解説がWeb記事で引用していただいたので、その補足です。

プライベートクラウドの問題点は、管理者の確保。プライベートクラウドでは仮想化して、サーバの集約をするわけですが、その仮想化を扱える管理者は少ないし、そうではない管理者を仮想化が扱えるように教育する費用と時間はばかにならない。このため仮想化が扱える管理者がいる企業ではないいれられないでしょう。仮想化ベンダーの方にいわせると管理ツールを用意しているから大丈夫と反論されますが、その管理ツールを使えるように教育するコストが大きい。逆に言えば便利な管理ツールを提供していて、その管理ツールの教育コースも提供するベンダーがプライベートクラウドのビジネスで勝てるのではないでしょうか。

それと規模の問題。仮想化によってサーバ数は減らせるとはいえ、仮想化というレイヤーが入ることでシステムは複雑になります。その複雑性による管理コストの増加とサーバ数集約によるコストの削減を比べると、集約対象のサーバ数が相当多くないと、コスト削減効果は少ないことになります。もちろん仮想化そのものはサーバ台数は関係ないのですが、コスト削減効果を出すには台数は必要。日本で一番規模が大きい事例は三井物産の情報システムだと思います。1000台のサーバを仮想化で集約したそうですが、実はこれぐらいのスケールはほしいかもしれません。ちなみに関係者によると同社の案件は仮想化であって、プライベートクラウドではないそうですがね。

三井物産の事例はプライベートクラウドの難しさを物語っているかもしれません。その案件は三井物産の直系情報子会社が受けましたが、三井物産は大きなSI子会社があるので、前者の方に経緯を伺ったことがあるのですが、(大きなSI子会社に問題があったわけではなく)直系情報子会社はこれまで三井物産の情報システム全体を手がけていて、精通しているからこそできたそうです。その通りだとすると仮想化やプライベートクラウドは、ユーザ企業側の業務や情報システムに精通していることが条件になるかもしれません。この辺はプライベートクラウドの構築では一番重要なところだと思います。メディアの方は取材をしてみたらいかがでしょうか。なお、なんどもいいますが、大きいSI子会社に問題があったわけではないですよ。ここで言いたいのはユーザ企業の情報部門か運命共同体ともいえる直系情報子会社でないと、プライベートクラウドの構築は難しいということの例に挙げただけです。念のために。

ところでプライベートクラウドで過度な期待をされている方が多いのですが、コスト削減以外にはない。というのはプライベートクラウドの基盤技術である仮想化では、個別の物理サーバで動いていたOS、ミドルウェア、アプリケーションを仮想マシン上で動かすだけですから、OS、ミドルウェア、アプリケーションもかわりません。それは一見すばらしいのですが、逆に言えばプライベートクラウドにより、いままでの情報システムでは実現できなかったようなアプリケーションが実現できるようになるわけではない。個人的にプライベートクラウドに魅力を感じないのはこの部分だったりします。やはり新しい情報システムならばコスト削減だけでなく、新しいアプリケーションを動かして、新しいビジネスチャンスを生み出すべきですから。

他にもいろいろあるのですが、プライベートクラウドの問題はいくらでもあるので、今日はここまで。最後に一言だけいうと、プライベートクラウドはそのネーミングからして失敗していると思います。プライベートクラウドは仮想化と呼べば高く売れたのに、クラウドと名乗ってしまったので、低価格なパブリッククラウドと価格面で争うことになりました。これがプライベートクラウドの最大の失敗だと思います。

2010年1月25日

昨日、Webにおいた学会の招待講演のスライドですが、詳しい解説は情報処理学会の機関誌の2月号に記事になります。そちらもご覧下さい。内容はコンピュータサイエンスは、かつてコンピュータが高価かつ低性能だったので効率化・最適化する方法に関する研究はいっぱいあります。またシステム開発は難しいために不具合を事前に発見する手法が発展しました。こうしたコンピュータサイエンスの技術はコンピュータのために開発されましたが、その中にはコンピュータ以外、例えば現実世界にも応用できるはず、と信じております。そこで前回の講演では、現実世界として物流トラックを選んで、コンピュータサイエンスの手法をそのまま使って物流の効率化を狙っています。具体的にはトラックの経路をプログラムの実行の流れと見るという大胆なことをします。そこでまずトラック経路を表すためのプログラミング言語を作って、トラック経路をプログラムとして扱えるようにします。プログラムにしてしまえば後は簡単。例えばプログラムを効率化する方法に、コンパイラで利用されるコード最適化がありますが、そのコード最適化をトラック経路を表すプログラムに適用します。つまりトラック経路をコード最適化で効率化します。また、共同物流では複数のトラックが相違な経路、相違なダイヤで運行されます。ただし、荷主の条件にあったトラックを見つけるのが難しい。そこで荷主の条件をプログラムの仕様として見てしまいます。そしてプログラムの実装が仕様を満足するかを判定する手法である検証(Verification)のひとつであるモデル検査(Model-Checking)を持ち出します。そしてそれぞれのトラックの経路を表す実装プログラムが、荷主の条件を表す仕様を満足するかを検証して、条件を満足するトラックを発見します。

2010年1月24日

一昨日(1月22日)の電子情報通信学会 人工知能と知識処理研究会の招待講演で使ったスライドをWebにおきます。ただし、オフレコ的な話のスライドは抜いてあります。それは直接聞いていただいた方だけということでお願いいたします。

2010年1月23日

EUはOracleによるSun Microsystemsの買収が独占取引法違反にならないか調査をしていたわけですが、問題なしと判断したそうですね。これで買収の障害はほぼなくなったはずで、Oracleは早々に買収作業の完了をすすめることになるのでしょう。Sun Microsystemsが経営不振になった背景はひとつではなく、たくさんの要素が絡み合ったものだと思いますが、ソフトウェアの研究者としてはNFSの成功体験はあげておきたいと思います。Sun Microsystemsの絶頂期を含めて、同社の競争力の源泉はハードウェアではなくソフトウェアだったと思います。そのなかでもNFSは自社にとどまれず、他のUNIX系コンピュータでも採用が進みました。その意味では大成功だったのですが、それゆえに他のソフトウェアについてもNFSのビジネスモデルを踏襲してしまったように思います。

もういっぽうのOracleですが、Sun Mcirosystemsの買収によりハードウェアを扱うことが得策なのでしょうかね。というのはここ1,2年、複数の国内ITメーカの方々と話していて話題になるのは、DBMSがはいった案件(その多くはOracleのDBMS)で、Oracle自身のシステム提案に負けることが多くなっているそうです。国内ITメーカについてはそのライバルとしてIBMがあげられます。しかし、IBMはさっさとサービスの世界にいってしまいましたので、取り残された国内ITメーカにとってはOracleの方がライバルになっているということです。今後、Sun Microsystemsのハードウェア製品群をビジネスラインに加えると、日本に限れば国内ITメーカ対Oracleの争いというケースはこれからも多くなりそうです。

いずれにしてもSun Microsystemsのハードウェア部門はお荷物ですから、早々に手放すと予想しています。ところでEUの独占取引法調査ではMySQLの取り扱いも調査対象になっていようですが、OracleとしてはMySQLを手放したりせずに、飼い殺しにするのが一番いい戦略なはずですが、どうなることやらです。

2010年1月22日

電子情報通信学会のAI研究会で招待講演と某企業でプレゼン。研究会はテーマがグリーンAIだそうで、いちおうグリーン関連の話をさせていただきました。1時間講演だったところを、1時間30分ほど話してしまって反省ものでしたが、当方の研究に興味を持っていただければ幸いです。なお、招待講演で話した内容の一部は情報処理学会の機関誌の2月号に解説記事が出る予定なので、そちらもご覧ください。それにしても勉強会を含めるとプレゼンの多い一週間でした。ひっそりと生きたいです。

2010年1月21日

クラウドコンピューティングとスマートグリッドを対比するのが流行っているようですね。まぁお話ネタとしてはおもしろいとは思いますが、違和感もあります。ニコラス・カーではないのですが、クラウドコンピューティングと(古い)電力系統事業の対比は似ている部分もあるかもしれませんが、スマートグリッドに関しては再生エネルギーなどによる分散型発電を考慮したものですから、集中指向のクラウドコンピューティングとは真逆とみえなくもない。当方の頭が整理しきれないのかもしれませんが、現状ではクラウドコンピューティングとスマートグリッドの唯一の類似性は、どちらも話題先行で実態がついてきていないというところでしょうか。それにしてもスマートグリッドって、現場とは接点のない方々が想像だけで話を膨らませてしまっていますが、大丈夫なのでしょうか。

2010年1月20日

経済学の研究者とクラウドコンピューティングの利用料金モデルについてのインフォーマルな勉強会。現状では良くも悪くもクラウドインフラ側の言い値の世界。言い値がまかり通っているのは自前の情報システムよりも圧倒的に安いので、いまはクラウドコンピューティングの利用料が高いと思う人がいないだけ。これも先はわからない。また、PaaS/IaaS型などではサービス提供者がクラウドインフラに利用料を払うメカニズムはあっても、そのサービスを利用するユーザが、サービス提供者に利用料を払うメカニズムさえない状況。サービス自体が課金できないと、いいサービスが生まれるわけもなく、そうなるとクラウドコンピューティングはバズワードに終わることになります。

さてクラウドコンピューティングには、クラウドインフラ事業者、サービス提供者、サービス利用者の3種類の当事者がいます。サービス提供者は対価を払ってクラウドインフラの計算リソースを借りて、サービスを実行する。そしてサービス利用者はそのサービスを対価を払って利用するという状況を想定しています。さてクラウドコンピューティングはユティリティコンピューティングを提供するインフラとして位置づけられているように、サービス利用者がサービスを利用するときに払う費用は従量課金制にすべきなのですが、問題はサービス提供者がクラウドインフラ事業者に支払う計算リソースの利用料と、サービス利用者が支払う利用料の徴収方法とサービス提供者とインフラ事業者間の配分のしかたです。

当方も現状ではいい案をもっているわけではないのですが、ひとまず電力取引のアプローチ、特に電力自由化後の電力取引のアプローチをベース、またはそれに近いアプローチを提案。クラウドコンピューティングはユティリティサービスと対比されますが、ユティリティには水道やガスもあり、それぞれの取引方法があるのですが、電力取引における同時同量の原則はクラウドコンピューティングに近い。そしてサービス提供者を発電事業者、クラウドインフラを電力取引における託送事業者とし、サービス利用者を電力購入者。電力取引では同時同量の原則がありますが、クラウドコンピューティングもサービスが必要なときに提供するという点では近い。問題は託送料金に相当するクラウドインフラの利用料ですが、託送料金の場合は送電系はともかく配電系の選択は難しいし、下手に下げると送電に支障がでるので固定的ですが、クラウドインフラに関しては競争を促進させてもよいように思っています。

経済系の研究者は卸売市場がお好みのようですですね。いい方法だとは思いますが、勉強会の時にも指摘したことですが、電力取引の例でいうと卸売市場の提案があったのですが、イギリスやカナダの電力自由化で実施したプール型電力卸売市場は失敗に終わりました。これは電力取引では供給不足は許されないので、供給者の方が優位であり、価格高騰と売り惜しみを招いたことと発電所の建設には時間を要するので供給者は他の供給者の動向を予想しやすく、自由競争がうまれにくかったことがあげられます。もちろん、電力取引とクラウドコンピューティングの卸売市場は違うわけですが、計算サービスを止めるわけには行かないので、供給側有利になる可能性は高いのではないでしょうか。もちろん先物やある種のデリバティブを使って供給側の優位性を下げることはできるかもしれませんが、電力と違って計算は需要を予測するのが難しい。

2010年1月19日

JALは会社更生法の適応を申請したそうですね。以前、アメリカン航空(American Airlines)の倒産(正しくは親会社のAMRの破産)のときに飛行機に乗り合わせたことがあります。CAさんが会社が倒産するけど、乗ってくれたことを感謝していると挨拶されたのを記憶しています。それと意外にこれまでの利用に感謝してということでしょうか、米国航空会社とは思えない丁寧な接客でした。さてさてJALはどうなることやら。最近はANAが多いとはいえ、JALも結構乗っているのですよね。復活を祈りたいと思います。といってもこうなるとやっぱり乗りたくないのも正直な心情。というわけで影ながら復活を祈っております。

さて今回のJALの会社更生法ですが、JALは日本における安定大企業の象徴的存在だったと思います。その意味では大企業は潰れないという神話も消えていくのでしょう。でも大学関係者の方に、昨秋の某就職希望ランキングの100位以内にJALが入っていたという話を伺いました。どうなっているのでしょうかね。

2010年1月18日

Googleが電力事業を始めるそうですね。報道されてからそのビジネスモデルを考えていたのですが、ちょっとわからないのですよね。世間では電力需要情報、つまり電力需要をユーザ別かつリアルタイムにモニタリングした情報を売る、またはその情報使った広告サービスを始めると予想される方が多いのですが、個人的にはピンと来ない。というのは以前、クランプ型の電流計を使って自分の電力消費を調べてみたことがあるのですが、電力消費からだけみて行動推定ができるかというと結構難しいという印象でした。すくなくても各家庭について、一日分でいいのでユーザ行動内容(せめてどの電化製品が動いていたか)とそのときの電力消費データがないと無理なのですが、前者のプライバシー情報そのものでそれを公開してくれるユーザは少ないでしょう。また家庭の場合は家庭によるので一般的な行動推定モデルを作るのは難しいと思われます。最近に、電力消費で行動推定という論文がいくつか出てきていますが、チャンピオンデータを想定しており、やはり実用に耐えるとは思えなかったりします。

再生エネルギーによる発電の逆潮流を防ぐために発電量コントロールすることも考えられるのですが、その場合は即応性を考えるとローカルに制御した方がよく、少なくてもGoogleにはうまみがあるとは思えない。また、Googleのインフラを使って家庭や事業者の消費電力削減に寄与して、その削減分の一部を手数料でもらうというビジネスも考えられますが、家庭の場合は10%も減らせるのが関の山でしょう。そうなるとGoogleにとって儲かるビジネスではない。

ということで消去法で考えていく、他社の何らかの電力削減に寄与するか、各所に設置された再生エネルギーによる分散型発電によるカーボンセット可能な環境付加価値(つまり排出権相当)を収集するかして、自社のデータセンターのカーボンセットすることを狙っているのではないでしょうか。つまり排出権(枠)を集めるためのビジネスとして電力会社を考えているのではないでしょうか。もちろん排出権(枠)を自社のカーボンセットにするのか、転売するのかはわかりませんが。

2010年1月17日

大学関係者はセンター試験の監督業務をされている方も多いかと思います。ご苦労様です。かくいう当方も前勤務先では毎年、監督業務がありました。現勤務先は大学院はあっても学部内のでセンター試験参加はなしとなっています。監督業務は肉体労働ではないのですが、試験問題を間違いなく集めて、解答用紙をまちがいなく集めるというのは心労があります(何しろ研究者は枚数を数えるとか地道なことが苦手)。回収した解答用紙が専用トランクにいれられてセンターに向かうトラックの乗せられるとほっとします。それと何よりも拘束時間が長いのですよね。ところで受験生の心情を考えると何事も受験生の都合優先というのはわからないでもないのですが、試験する方もたいへんなのですよね。それと試験が授業日程に跳ね返るので、まわりまわって学生さんにしわ寄せがいく場合もあります。

2010年1月15日

単行本の原稿の送付。といっても一章分未満なのですがね。複数の章を並行に書いているので進んでいるようで進まない。書籍といえば大昔に書いた分散システムの教科書の印税通知が来ていたのですが、今年はなぜか昨年の3倍以上(といっても微々たる額ですがね)。クラウドコンピューティングなどの影響で分散システムの基盤技術が注目されているのでしょうか。並列システムはプロセッサなどのハードウェアの進化に依存するので、20年前の技術は現代でも有効ではないのですが、分散システムは通信遅延という物理的な制約があるので、20年前の分散システムと最近の分散システムの差異はあまりないのですよね。逆に言えば最新の分散システムを必至に追うよりも、20年前の分散システムの勉強した方が早道かもしれません。少なくても最新トレンドの先回りをしたければ追い続けているだけではダメ。技術動向を予測してその先にいかないといけません。

2010年1月14日

Googleが中国政府に対して検閲撤廃を要求しました。Googleによる大規模かつ組織的なサイバー攻撃を受けたと主張しています。この主張が事実だとすると検閲撤廃というレベルの問題ではないような気もしてきます。Googleの主張を裏付ける事実関係が明らかになるかはわかりませんが、こうした声明が出たこと自体だけでも、インターネットの歴史に残る大きな事件ということだけは確かだと思います。ところでGoogleの中国法人の社員さんたちは微妙な立場に追い込まれることになりますが、そこまで手を打っているのでしょうか。

なお、Googleの声明によるとサイバー攻撃で一部の情報が盗まれたそうですが、こうした事件があると日本ではクラウドは危ないという議論になりますが、一般の企業のサーバでは大規模かつ組織的なサイバー攻撃に耐えられるわけもなく、今回の騒動は結果的にむしろクラウドへの移行を進めることになりそう。

2010年1月13日

かつてはヨドバシカメラ、ビックカメラとともに3カメと呼ばれたカメラのさくらやが精算だそうですね。個人的には「さくらや」で買った記憶がほとんどないので、当然、ポイントもありませんが、時代の移り変わりを感じさせる報道でした。ところでライバルのヨドバシカメラの企業研究ってないのでしょうかね。ヨドバシカメラはポイントカードを最初に始めた企業なのですが、ポイント制度は開始当時は会計処理的にはグレーゾーンだったはずで、国税庁や旧大蔵省をどうやって説得したのかは興味があるところです。また、当時、ヨドバシカメラのPOSシステムは全店の在庫状況を把握できるなどシステムにも先駆的でしたし、商品コードのJANコードの普及はヨドバシカメラなしでは語れない。というのはヨドバシカメラが納入業者に納入製品にJANコードを割り当てることを求めなければ電気製品にJANコードはいまのように普及しなかったのではないでしょうか。また、ヨドバシカメラがいすゞ自動車の川崎工場の跡地に作った物流センターはとてつもなく大きく、東京・神奈川エリアにまだ数点は大型店舗を作れるのではないでしょうか。神戸にも最近、大型の物流センターを作ったそうですが、関西でも梅田に続く大型店舗を狙っているのでしょうね。ヨドバシカメラは在庫管理やシステム部門など売り場以外のところにコアコンピタンスがありそうなのですが、ヨドバシカメラは情報がまったく出てこないのですよね。ところでヨドバシカメラの本社は大久保駅と東中野の真ん中あたりのマンションが立ち並ぶところにあるのですよね。

2010年1月12日

お恥ずかしながらTwitterに馴染めません。いちおう500ツイートぐらいはつぶやいてみたのですがね。研究職という仕事柄、少数の話題を深く考えるということが求められるのですが、Twitterはその正反対の世界。つまり断片化された多岐な話題がランダムに流れる世界。広く浅く情報収集するのには非常にいいのでしょうが。みなさん別の話題を書かれるので、一部のツイートだけを読むにしても、こちらの思考が発散してしまいます。狭く深くを求められる立場にはTwitteは不向きかもね。それにツイートを書くのも苦手。本質的なアイデアはTwitterの字数制限(140文字)で書けるのかもしれませんが、研究上のアイデアは、いろいろな技術的な背景を背っているし、短い言葉で断言できる結論だけではない。Twitterを使ったからといってロジカルな思考ができなくなることは決してないと思いますが、ただ、ロジカルな議論がしやすい環境とはいえない。

まぁもっと気楽にTwitterを使えばいいのですが、税金で研究させていただいている立場であり、その肩書きとともに情報を発信する以上は、何を書いてもいいというわけでもない。例えば「テレビのバラエティ番組おもしろかった」とか「ラーメンおいしかった」とか私事ばかり書いていられるわけでもなく、やはり研究に関わることを話題の中心におくことが求められます。また、前述のように税金で研究させていただいる以上は、研究に関する知見を(誰でもアクセスできる)メディアを通じて情報発信は求められます。そのメディアとしてTwitterがいいのであれば、Twitterを無視するわけにもいかない。というわけでもう少しTwtterを続けてみますがね。いつまで続くのでしょうか。

2010年1月10日

クラウドコンピューティング、特にPaaSの場合、サービスはクラウドインフラ上で実行されるので、クラウドインフラが変更になるとサービスにも影響が出ます。また、サービスは他のサービスを呼び出しているので、サービスの変更は他のサービスに影響します。そうなるとサービスの提供者は常にクラウドインフラや依存している他サービスの変更にあわせて改良しつづけないといけないことになります。もちろん、クラウドインフラにしてもサービスにしても機能向上や信頼性向上を狙って変更するわけですから、その変更に追随した方がいいわけですが、開発者がいないなど変更に追随できないサービスもでてくると思いますし、利用者も変更を嫌がる可能性があります。

そうなると過去のサービスを提供し続ける仕掛けが必要になります。実際、Salesforce.comの場合はインフラの仕様変更があっても所定期間は以前の仕様のインフラが提供されます。ただ、クラウドインフラやサービスにとって過去の仕様によるインフラやサービスの提供が負担になるわけですから、当然、その対価を利用者や利用するサービスからとるべきでしょう。ここでその価格には工夫が必要かもしれません。これまでソフトウェア販売では最新版は定価、旧バージョンは格安価格ということがありましたが、クラウドコンピューティングではその逆もありえるでしょう。つまり最新仕様のクラウドインフラやサービスよりも、旧仕様のクラウドインフラやサービスは高い利用料となるかもしれません。もっと極端に言うと、最新版クラウドインフラやサービスは無料にして、旧仕様のクラウドインフラやサービスで儲けるというビジネスモデルも想定できると思いますし、個人的にはこれが主流になるのではないかと予想しています。

逆に言えば環境(クラウドインフラや利用している他のサービス)の変化に応じて、生物進化のように自らも変化できるサービスは生き残れるという世界かもしれません。逆に古い仕様のクラウドインフラやサービスを使い続けるサービスというのは、ある種のガラパゴス化であり、その環境では生きていけても他の環境では生存力に欠けることになります。Windowsビジネスではエコシステムという言葉がよく使われましたが、クラウドコンピューティングにおけるエコシステムというのは、変化する環境であり、その変化がサービスを進化させるような環境になるのではないでしょうか。

2010年1月9日

昨日に引き続きOSネタです。WindowsでもMacOS Xでも後方互換性重視。つまり古いWindowsやMacOS X用に開発されたアプリケーションでも新しいWindowsや新しいMacOS Xでも動くように考慮されています。こうすることでユーザを古いOSを止めて、新しいOSそのものまたは新しいOSをインストールしてあるコンピュータを購入させるようにするのが、これまでのOSのビジネスモデルでした。

しかし、LinuxやBSDなどのオープンソース系のOSも増えましたし、Chrome OSのように無料配布を想定したOSも増えてきました。そうなると最新のOSの価格はただ同然になっていくことが予想されます。例えばMacOS Xの最新版であるSnow Leopardの価格は4千円以下となり、販売コスト程度になりました。こうなると最新OSを開発しても開発コストに見合う利益は得られないことになります。でも、発想を逆にしてしまえば収益は維持できそうです。どうするのかというと最新OSはただ同然で配布して、その代わり古いOSの販売・サポートで儲けるというビジネスモデル。Windowsでいえば、まず各Windowsで後方互換性はなくす、代わりにWindows 7は低価格で販売して、そのかわりWindows XPの販売価格・サポートは高く売るというのもの。

どうしてこのビジネスモデルが成立するかというと、まずOSの機能向上が停滞気味であり、最新OSをお金を出してまで使いたいとは思えなくなっています。つまりユーザは最新OSの新規機能ではなく、過去のアプリを動かすための後方互換性にお金を出しているのではないかということです。もうひとつはVMが普及すると古いOSは長く使われることもあげられます。いままではOSの寿命はハードウェアの寿命で制約されていました。PCはハードウェアの進化が早い代わりに古いOSでは新しいハードウェアでは動かないか、少なくても新しいハードウェアを使いこなせない。このためハードウェアの世代交代によりOSの世代交代が進みましたが、VMが前提の時代になると、ハードウェアの進化をVMが吸収してくれるので、古いOSが止める理由がなくなります。そうなると古いOSの販売・サポートは求められるし、むしろ古いOSの販売・サポートからOSベンダーが収益をあげられることは、OSベンダーだけでなく、継続的なサポートを得られるのでユーザにとっても悪い話ではない。

これに一番近い例はメインフレームですよね。言葉は悪いのですが、メインフレームは過去のソフトウェアを動かすために存在しているような部分は否定できないわけですが、ユーザは既存ソフトを新しいコンピュータ向けに更新ができないという事情を抱えていますから、言い値で売れるわけで、実際、メインフレームの利益率は高いようですね。

2010年1月8日

Nexus One向けSDKリリースの遅れが話題になっているようですね。まぁマーケティング的な理由からCESの直前にNexus Oneを発表したかったけど、SDKまで手が回らなかったというのが実態なのでしょうがね。しかし、もしGoogleが確信犯で開発へのSDK先行配布をしなかったとしたら考えさせられる事態。というのはMSもAppleも新OSのリリースでは開発者にSDKの先行配布が業界の慣例。Googleはその慣例を破ったわけですが、一方でGoogleが慣れ親しんだWeb APIの場合は突然、仕様が変更になる世界。そしてAPIを使う側が対処療法的に変更に対応するという事後対処的なアプローチが常識。そもそもGoogleにはSDK先行配布の概念もないし、むしろそうした世界観にアプリ開発者も慣れろという御神託かもしれません。というのはSDKの先行配布はアプリ開発者にとってはありがたいのですが、その一方でその先行期間の分だけ進化が遅くなります。Googleは変化を早めたいと思っているのであれば、業界慣例をあえて破るのは合理的ともいえます。

実際、クラウドコンピューティングでは、サービスが別のサービスを呼び出すことになりますから、どこかのサービスの仕様変更が他のサービスに影響を与えるというのは、至るところで常に起きるでしょうし、その影響への対応に追われることになるのでしょう。これは一見不合理に見えますが、生物は日々起きえる環境変化に適応して生き抜いてきたわけで、進化をもとめるのならば避けては通れないことのように思います。そして新しい実行環境やサービスよりも、古いバージョンの実行環境やサービスを残す方がもうけになるのでしょう。つまり新しいサービスはただ同然にして、古いサービスは高い利用料でふっかける。変化への対応ができない利用者からは言い値でお金を取れますからね。つまり、変化に対応できるとお金がかかりませんが、変化に対応できないとコストがどんどんかかる時代でしょうか。

2010年1月7日

安全・安心というキーワードが流行ったせいか、デペンダブルコンピューティングの研究者は多いのですが、そうした研究者と話していて不思議なのは、意外にミッションクリティカルなシステムを知らないのですよね。数年前になりますが、ある研究者の方と話をしていて、ミッションクリティカルな制御系システムを対象としたプログラム解析の研究をされているというので、当方は「解析対象のプログラミング言語はAdaですか?」と聞いたら、Adaは大昔に廃れた言語と強く一蹴。でもミッションクリティカルなシステムの代名詞である航空機の制御系はAdaで開発している事例は多いはず。例えばBoeingの旅客機もAirbusの旅客機も制御系はAda言語で書かれている部分が多いし、それは最新の787もA380でも変わらない。なんでこの話題をいまになって書いたかというと最近、デペンダブルコンピューティングまわりでもAdaを知らない研究者がおられたので。個人的にはAdaに思い入れはまったくないのですが、デペンダブルコンピューティングを研究するというのならば、現実のシステムの状況ぐらいは知っていて欲しい。他人の研究にとやかくいう趣味はないのですが、さすがにあきれたのでちょっとだけ書きました。

2010年1月6日

噂されていたNexus Oneが発表されましたね。携帯電話業界にとって、iPhoneに続く、黒船出現ですね。GoogleはNexus Oneの利用料金を新たな収益源と思っているのならば同じ土俵で競争できますが、Googleが広告用スペース、つまりカンバンだと割り切っていると怖い存在。つまり、Googleは広告収入をえるためにカンバンの数を増やすことを狙います。そうなるとカンバン、つまりNexus Oneの利用料金はどこまでも値下げしてくるでしょう。利用料金は無料になることも想定した方がいいかもしれません。ところで、たまにGoogleをIT企業と勘違いする人がおられます、収益モデルからみると広告代理店に近い業態の企業です。実際、Googleの収益のほとんどすべては広告料のはず。

Googleは広告収入でも利用料金でもないもうひとつの収益モデルがあります。それはソフトウェアやコンテンツデータの販売で収益をあげるというもの。ただ、ここで問題はAppleの特許。AppleはiTunesストアのまわりで基本特許を固めており、Googleといえども特許をさけてソフトウェア・コンテンツ販売ビジネスができるかは見物ですね。Appleの強さは、Jobsのカリスマ性でも、デザインの良さでも、iTunesストアの販売実績でもなく、B2Cの電子商取引の特許にあります。

あくまでも個人的な予想ですが、これから10年はIT分野は特許を含む知財の争いになっていくと思います。これはアカデミアの研究者にとってはやりにくい時代なのですが、それが時代の流れならば生き抜くしかないのですよね。

2010年1月5日

そういえばそろそろCESの時期ですよね。CESの直前はいろいろ製品発表があるのですが、今年は静かですね(逆に言えばCESが始まった頃には主要な新製品発表は終わっていた)。CESが地盤沈下しているのか、メーカが新製品開発を手控えているのか、きっとその両方なのでしょうけど。家電製品もハードウェアそのものではなく、ハードウェアからアクセスするネットワーク側で勝負する時代。そして収益源はハードウェアメーカからネットワーク側に移行しています。もちろん家電製品などのハードウェアがなくなることはありませんが、収益はどんどんネットワーク側に吸い取られていくのでしょう。

もっとも日本ではいまだに「組込コンピュータ」とか「ものづくり」とかのキーワードがもてはやされています。組込コンピュータそのものは高度化されても収益源がネットワーク側にとられているわけで、人件費の高いに日本で組込コンピュータに入れ込んでどうするつもりなのでしょうか。「ものづくり」というキーワードが大好きな方が多いのですが、ネットワーク側のサービスで商品差別化する時代。「もの」よりも「サービス」に注力すべきなのにね。クラウドコンピューティングにしても、クラウドコンピューティングはエンタープライズシステムの文脈で語られることが多いのですが、家電製品や組込コンピュータの方がクラウドコンピューティングの影響は大きいように思います。

2010年1月4日

仕事柄、メディアの取材を受けることが多いのですが、記事になっていても本人は気づいていないことも多く、今回も出先で記事を教えてもらう始末。日経流通新聞(MJ)の1日号のクラウドコンピューティング特集に当方のインタビュー。といっても数行でしたね。ただ、なぜかTwitterに関する囲み記事の中。実は今日になって掲載をしった記事はもうひとつあって、流通新聞という業界紙。こちらは半ページ分で研究の紹介記事を掲載していただけました。

話は変わって、クラウドコンピューティングにおける開発言語のこと。個人的にはGoogle App Engine(PaaS型のクラウドコンピューティングのひとつ)の開発ではPythonもJavaも両方使うのですが、従量課金制を考えるとPythonのような動的言語やLight-weight Languages (LL)はクラウドコンピューティングの開発には向かないかもしれません。こうした言語は実行してみないとエラーを含めてもわからないことが多い。自前のコンピュータでプログラムを動かしているのならば、例えば無限ループに堕ち込んでもコンピュータの負荷が増えるだけですが、クラウドコンピューティングでは従量課金により経済的な損出になります。こうしたプログラムの不具合による経済的損出をさけるためには静的言語の方がいいと考えることもできます。

もちろんクラウドコンピューティングの従量課金制において、不用意な負荷をさけるためには言語ではなく、開発環境でプログラム上の不具合をみつける方法もあると思いますが、動的言語はその動的な特性から統合開発環境との相性が悪いという問題になり、やっぱり静的言語の方がいいという結論に向かってしまいます。いずれにしても従量課金制がクラウドコンピューティング向けソフトウェア開発において重要な要素になりそうです。特に課金対策、例えば実行による課金額の見積や課金料をさげるための最適化が必要になりそう。

2010年1月3日

MicrosoftのクラウドコンピューティンサービスであるAzureは1月1日から始まったのですが、正直言って個人的にはAzureにはいまひとつ惹かれないのですよね。あえてクリステンゼン風な言い方をすると、クラウドコンピューティングは破壊的イノベーションだと思うのですが、Azureは既存Windows開発者が開発しやすいようにするために持続的イノベーションを狙っています。残念ながら破壊的イノベーションと持続的イノベーションが両立するとは思えないのです。

Microsoftは既存Windows開発者に優しいというか、彼らを見捨てることなく、ここまで上手く引っ張ってきたのですが、その結果がWindowsアプリケーションの停滞につながったように思います。Microsoft謹製のアプリケーションでいうと、例えばOffice 2000で別に困らない。普通のユーザがOffice 2007(そして来年発売されるOffice 2010も含めて)を使って行う作業のほとんどすべてはOffice 2000でもできるはず。でもOffice 2000は10年前のソフトウェアなのですよね。移り変わりの激しいIT業界で、10年前のソフトウェアでも困らないというのは本来あってはいけないこと。

Windows開発者の皆様方にはたいへん失礼な物言いなのですが、Windows向けアプリケーション開発は時間が止まったような世界。そんな世界に浸った開発者がクラウドコンピューティング向けの新しいサービスを作れるかというと疑問なのですよね。あるプラットフォームが既存の開発者が有利という印象を与えたら、新規開発者はそのプラットフォームは避けるものです。Azureをイノベーティブになるには、既存のWindows開発者を切り捨ててでも、新規の開発者をAzureに引き込む必要があったのではないでしょうか。

それと過去の歴史を考えると新旧プラットフォームでアプリケーションの重複はない。例えばメインフレートとミニコンでは、メインフレームからミニコンに移行したアプリケーションよりも、ミニコン向けに新たに開発されたアプリケーションの方が多い。Azureのことに話題を戻すと、現在のWindowsのアプリケーションはWindowsで動かせばよく、Azureで動くアプリケーションは今までにないものになるということです。このため既存Windows開発者をAzureに連れて行ったために、Azureというせっかく新しいプラットフォームなのに古いアプリケーションを動かし続けることになりかねません。

ならばどうすればいいのかですが、他のプラットフォームの開発者を引き入れることも重要ですが、やはりエンドユーザによる開発ができるようにすることが求められるように思います。実際、Force.comはWebブラウザで開発できるので、開発ツールや統合環境のインストールは不要なのですが、こうしたインストール有無だけでもエンドユーザ開発の障壁になっていましたから、Visual Studioのインストールが必要なAzureって時代錯誤なのですよね。

2010年1月2日

今年後半、分散システム、特に分散アルゴリズムを理解するには(論文以外で)何を勉強すればいいのか、と何人かから聞かれたのですが、なかなか難しい質問ですね。やっぱり論文を読んだ方がいいので。ただ分散アルゴリズムの基本中の基本を勉強するならば、最初の1冊目はA.S.Tanenbaumの分散システムの教科書でしょうか。これは定番な教科書なので説明する必要はないでしょう。類書ではG.CoulourisとT.Kindbergの教科書もすごくいいと思いますが、A.S.Tanenbaumの方が原理的な話題はやや詳しい。分散システムでも一貫性や耐故障性であればK.Birmanの教科書を読むのが基本でしょう。さすがにこの分野の大御所だけあって内容が詳しい、というかこのレベルの知識はないと話にならない。また、似た内容ですがR.Guerraouiの教科書もおすすめです。彼はオブジェクト指向言語まわりの研究をしていたこともあり、プログラミングという立場からはK.Birmanの教科書よりはいいかも。G.Telの分散アルゴリズムの教科書は悪くはないのですが、実際の分散システムに必要なアルゴリズムとはずれているかも。それとN.Lynchおばさんの御一派が書かれた分散アルゴリズムの教科書はあまりすすめないかも。記述方法(IO-Automata)が独特すぎて、これが読める人は少ないでしょう。あと分散ではなく、並列計算系の一貫性制御ならばいまはM.Herlihyの並列計算の教科書もいいです。同期制御とスケジューラについては詳しくなれます。これらの本をよめば1995 年以前ぐらいの分散アルゴリズムの基本的な流れは理解できると思います。分散アルゴリズムに関しては1990年以降は画期的なアルゴリズムの登場は急激に減っていますが、P2P関連で登場した分散ハッシュなどは新しいアルゴリズムは見ておいた方がいいでしょう。またCyber-Physical Systemsやセンサーネットワーク(といってもネットワーク側ではなくてね)に関心があるのならば、G.Muhl、L.Fiege、P.Pietzuchの分散イベントの教科書もいいかも。これは分野が特殊ですが、良書だと思います。分散システムはデジャヴが多いのですが、WebサービスなどはCORBAなどの分散オブジェクトの歴史をたどっている状態で、このためWebサービスまわりのシステムを関わるのならば分散オブジェクトの知識は必須で、分散オブジェクトならば一見軽そうな書籍ですが、おすすめです。

また、トランザクションについてはG.Grayの分厚い教科書を読むのが正解なのですが、さすがに分厚すぎるのでG.WeikumとG.Vossenの教科書がいいかも。ただし、この教科書はP.Bernsteinの教科書をべーすにしていてP.Bernsteinの教科書は絶版になった後、PDF版が無料で公開されているので、こちらを読めば十分です。トランザクションについては1990年ぐらいまでには技術が確立しているので、実は多少古くても困ることは少ない。ただ用語はちょっと古くて、ACIDなどの略語は登場していなかったはず。P.Bernsteinで用語などの新しさを求めるならば別の教科書でもいいかもしれません。ただ、トランザクションを使う立場で書いてあるので内容がやや軽い。トランザクションを作る立場ならばP.Bernsteinの古い方の教科書(またはG.WeikumとG.Vossenの教科書)とJ.Grayの教科書は必読です。

なお、これらはどれも教科書、つまり入門レベルです。これらは分散システムの研究や開発するならば知っていて当然。逆に言えばこのレベルの知識がないと話にならないし、これらの教科書に書かれている程度の基本的な知識なしでは分散システムの研究・開発しても無駄なところで回り道をするだけ(もちろん無知なために苦労したい方を止めたりはしませんけど)。かつてマルチコアが出てきたときに並列プロセッサにおける同期制御が、システムレベルの開発者にとって必須の知識になったように、クラウドコンピューティングでは分散アルゴリズムの知識は必須になると思います。残念ながら今のクラウドコンピューティングのインフラは分散アルゴリズムの難しいところを隠蔽してくれないので、アプリケーション側で解決しないといけない問題がまだまだ多いですから。

2010年1月1日

今年もVienna Philharmonicのニューイヤーコンサートをテレビでみる(毎年、チケット争奪にやぶれており、今年は参戦せず)。2008年に引き続いて指揮はGeorges Pretre。オペラ指揮では有名な指揮者。2008年のときもGeorges Pretreはニューイヤーコンサートの指揮では過去最高年齢だったこともあり、体力的な心配をする方が多かったのですが、無事に終わりました。さすがにアグレッシブな演奏はなくなりましたが、ゆっくりとした指揮ながらVienna Philharmonicの特性を上手に使った演奏で、とってもよかったです。また、随所に嗜好を凝らせていまして、楽しめるニューイヤーコンサートになっていました。演奏はVienna Philharmonic らしく、あらのない演奏ですが、今年はパーカッションパートの方々が大活躍でしたね。

選曲はオッフェンバックの曲の有名曲をもってきたことと、フランス人指揮者だけあって、フランスに関わる曲を選んだところはおもしろかったですね。それと1曲目にオペレッタ「こうもり」の序曲を持ってくるあたりはオペラの指揮者という感じですが、Vienna Philharmonicは本業のウィーン国立歌劇場で「こうもり」は散々やっている定番曲(そのうえ「こうもり」の上演は年末年始が多い)ですし、指揮者の方もオペラの序曲らしく、2曲目以降が盛り上がるように指揮していましたね。さすが老練な指揮者だけのことはあります。

来年はFranz Welser-Mostが指揮だそうです。Welser-Mostの指揮はチューリッヒ歌劇場でオペラ「フィガロの結婚」で聞いていますが、そのときは非常にいい出来でした。ということで来年のVienna Philharmonicのニューイヤーコンサートも期待しておきます。

最新版
一覧

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