Diary

もともとは研究用ソフトウェアの開発履歴に関するページだったのですが、開発関連よりも雑談の方が多くなったので、2001年分から別のページを用意することにしました(過去のページの一覧はこちら)。リンクは勝手にしてください（でもリンクしたい人なんているのでしょうか）。それから海外出張の写真一覧はこちらにのせてあります。筆者のプロフィールはこちらです。なお、このページはRSSに対応していませんが、外部のRSS化サービスを使うとRSS購読もできるそうです(当方は関知していません)。

2010年9月1日

AppleがApple TVやiPodなどの発表を行いましたが、個人的に一番印象的だったのは、新しいiTunesではアイコンから光ディスクの絵がなくなったことでした。光ディスクは過去の遺物ということをいいたかったのでしょう。それと音楽やビデオというコンテンツから物理的な実体が消失していることを意味しています。レコードからCDへの移行も大きな変化でしたが、物理的な実体の消失というのはさらに大きな変化だと思います。

それともう一つの注目点注目点はApple TVとビデオ配信サービスだと思います。しかし、日本ではApple TVの発売もビデオ配信サービスの提供先リストから外れています。日本は光ファイバー網などの通信インフラでは世界でも有数ということになっていますが、肝心のサービスでは取り残されていますね。いくらインフラが整備されていても、その上のサービスがなければ意味ない。

2010年8月31日

昨日の続きですが、当方の発想はシンプルで、どうせ研究するならば本質的なことを研究したいだけ。そして本質的な研究はいずれは評価されると信じています。昨日、モバイルエージェントのことは書いたので、今日は別のテーマ。ユビキタスコンピューティングの研究をしていました。ユビキタスコンピューティングはデバイス依存になりやすい研究分野。そのうえユビキタスコンピューティングは基本的に統合技術なので、多くの技術は他の分野からの借り物が多く、ユビキタスコンピューティングならではという技術が非常に少ない。だけど、ユビキタスコンピューティングの研究をするならば、そうしたコアな技術にフォーカスすべきだと思うのです。

さてユビキタスコンピューティングは現実世界とコンピュータの世界を結ぶ技術。もちろん両世界を結ぶ方法はいくつかありますが、人間が現実世界を理解するときは頭の中で現実世界のモデルを作っているように、コンピュータ側で構築される、現実世界のモデルがユビキタスコンピューティングならではのコアの技術だと考え、その現実世界のモデルとその周辺だけを狙うこととして、他は一切研究しないことに決めました。もちろん、他の研究がゴミだとはいいませんが、例えば特定のセンサーをターゲットにして人間行動を推定する研究をしても、そのセンサーが使われなくなったらその研究は顧みられるとは限らない。また前述のようにユビキタスコンピューティングは統合技術なので、コアの技術以外、つまり他の分野からの借り物の技術を研究したところで、その技術の大元の分野の既存研究を超えるのは難しい。

当方は他人の研究にとやかくいう立場ではないけど、学術研究ならば、一過性ではなく、長く残る研究をして欲しいですね。生物学などでも試薬や実験機材の日々進歩によって技術はどんどん入れ替わるそうですが、研究対象の生物そのものがかわるわけではない。一方、コンピュータサイエンスの場合、研究対象となるコンピュータは移り変わりが早い。特定のコンピュータをターゲットにして研究すれば成果は出せるかもしれませんが、そのコンピュータが消えたらその研究はゴミ同然なんですよね。例えば特定のスパコンやクラスタ、ミドルウェアだけをターゲットにした研究は、確かに性能向上するわけですが、そのスパコンやクラスタ、ミドルウェアがなくなったら、その研究も価値がなくなります。なお、そうした研究がよくないとはいうつもりもないし、誰かがやらないといけない研究なのでしょうが、一抹の儚さを感じるんですよね。

2010年8月30日

最近、やたらとモバイルエージェントについて訊かれることが多いです。確かに昔、モバイルエージェントの研究していたし、いちおう今もしているつもりですしね。モバイルエージェントって昔の技術というところがありますが、モバイルエージェントは本質的な技術だから、(その名前は変わっても)時を超えて生き続けるのではないでしょうか。

どうしてモバイルエージェントが本質的なのかを当方の当時の発想に遡って書いておきます。ご存知のように現代のコンピュータの理論的基礎はチューリングマシン。分散システムの計算モデルを博士論文とした当方としては、チューリングマシンがネットワーク対応になった場合、どのようなマシンになるのかというのは、(チューリングマシンそのもの研究をするかは別にして)究極の問でした。チューリングマシンをネットワークで結んで、他のチューリングマシンと通信できるようにするわけですが、コンピュータサイエンスを学んだ人ならご存知だと思いますが、チューリングマシンには万能チューリングマシンというのがあります。万能チューリングマシンとは、あるチューリングマシンをエンコーディングして、それを別のチューリングマシンで実行すると、あたかもエンコーディングしたチューリングマシンとして動作するという概念です。つまりコンピュータを仮想化して、仮想マシンで動かすイメージですね。さて万能チューリングマシンを考えると、チューリングマシンがネットワーク対応になった場合、通信でデータをやりとりするだけでなく、エンコーディングしたチューリングマシンもやりとりできないといけないと考えました。つまり、いまでいうと仮想マシンのLive Migrationですね。

ただ、当時は仮想マシンもありませんでしたし(メインフレームは別ですが)、ましてLive Migrationなんてない時代。そこで上記ができそうな技術として興味をもったのがモバイルエージェントだったのです。エージェントは(並行オブジェクト指向の)能動オブジェクトと同じで、データとコードを持つと同時に実行スレッドも持っていることになっています。つまりエージェントそのものがひとつの仮想的コンピュータとみることができます。そのエージェントがコンピュータ間で移動させる技術であるモバイルエージェントは、上述のネットワーク対応のチューリングマシンの実現例とみることができます。

その究極の答えが、モバイルエージェントでコンピュータのエミュレータを動かすという研究(の論文)でした(IEEE Wireless Communicationsの解説記事)。携帯端末は運ばれて、いろいろなネットワークに接続されますが、その携帯端末(つまりコンピュータ)のエミュレータをモバイルエージェントで作れば、携帯端末の移動(と移動先でのネットワーク接続)が再現するというものです。何がうれしいかというと端末の上で動くソフトウェアをテストするときに、端末を運ばずに、モバイルエージェントのエミュレータを運べばいいというものです。

もちろんモバイルエージェントを研究することになった理由は他にもありますが、(ネットワーク対応の)チューリングマシンのように本質的な技術というのは死なない。研究者をしていると論文実績を作ることも仕事で、そのためには効率的な方法は流行の研究をすること。というのは流行している研究分野は当該の国際会議も多くなるので、論文数も参照数も上げやすい。でも流行研究のすべてが長く残るわけではない。多くの研究分野は流行ってもすぐに消えていきます。特にコンピュータまわりの研究は研究対象のコンピュータの移り変わりが早いので、特定のコンピュータやデバイスにした研究は、そのコンピュータやデバイスが消えるとともに存在価値を失います。それと本質的な技術的コアのない研究分野は消えやすいし、消えた後には何も残らない。一方、本質的な技術をあつかう研究分野は仮にその分野はきえても、その技術は消えない。当方は研究者として一過性のテーマを追うのではなく、長く残るテーマを研究したいだけなのです。また、携帯端末エミュレータの研究がいい例ですが、本質的な研究というのは、仮に流行から外れていると国際会議は通りにくいかもしれませんが、難関海外論文誌にはちゃんと採録されるものです。

2010年8月29日

休日出勤。このぶんだと8月だというのに今月の休日は2日間だけでした。法定休日数(4週間に4日休む)をまもれず、また人事に怒られますね。8月は休みませんというと企業の方からは驚かれますが、研究者としては8月と年末年始は稼ぎ時なのです。というのは8月や年末年始は世の中が休みなので研究に集中できるのですよね。研究は毎日2時間みたいに細切れでするものではなく、短期集中の方がはかどりますからね。

一昨日書いたことの補足。Amzaon EC2をウォッチリストからはずしたのは、研究者としての関心とユーザとしての関心は違うということです。Amzaon EC2がよくないからではなく(当方も使っているし)、実ビジネスであって研究的な面白さがないから。Amzaonのことだから顧客のニーズをうまく汲んで新しいサービスを提供してくると思います。クラウドコンピューティングは結局、ユーザに近い方が強いですね。それと先行者に新しいアプリケーションが集まりますね。

2010年8月28日

Azureにネガティブなことを書きましたが、MS自身がAzureに本気になっていないことが透けて見えるんですよ。先日のTechEdなどのセミナーなどのAzureの啓蒙活動しても、現状はMS御謹製のサービスでAzureで提供されているものは皆無。MS自身が基幹アプリをAzureに移行するなど、MS自身がAzureに社運をかけていることをみせないと開発者はついてきません。せいぜい、大手の開発会社がどうでもいいプロジェクトをAzureで開発させてみて、Azureの開発実績を作りつつ、MS様の顔を立てるだけ。いまはそこでとどまっているわけで、MS様におかれてましては本当にクラウドコンピューティングに移行するならば本気度を見せて欲しいですね。例えばVisual StudioあたりをAzureに移行して、既存のスタンドアローン版を打ち切ってみれば開発者にも本気度がわかるのでは。業態変化には社内的なリストラが必要だし、既存の開発者を切れないのもわかるのですが、二股をかけていたら両方を失うことになります。MSはここ1,2年のAzureへの対応の仕方が10年後のMSを決めていると思います。

2010年8月27日

横浜方面ではMicrosoftのイベント(TechEd)が開催中のようですね。数人から行かないのですか、と聞かれたのですが、時間がなくて・・・と答えておきましたが、時間があっても行く気はなかったと思います(関係者の皆さん、すみません)。もちろん研究者は技術情報を追うことも仕事の一つですが、体も頭もひとつなので追える情報は限られています。だから何かにフォーカスしたら何かを捨てないといけません。今年のTechEdの話題の中心であるAzureに興味がないわけではないのですが、現状ではウォッチリストから外れています。意外と思われるかもしれませんが、Azureと同じクラウドコンピューティング関連ではAmazon EC2もウォッチリストから外してしまいました。それでは何に関心があるかというと、新しい技術や新しいアプリが出てくるか否か。Azureは開発は良くも悪くもWindowsの延長線なので、Azureの開発者の多くはWindowsの開発者となり、その結果、Windowsを超えることは難しいと予測しています。Azureならでは新しいアプリが作れるのは、Windowsの開発経験がない新しい開発者。しかし、MicrosoftはWindows開発者の優遇という道を選びました。これではWindowsの開発に不慣れな新しい開発者は不利なのでAzureの開発はしない。Amazon EC2はWindowsなりLinuxなどの既存OSを動かすわけで、それでは既存のサーバでは考えられなかったアプリは登場しにくいと判断しています。それとAmazon EC2ｈつまりクリステンセン風にいえばAzureもAmazon EC2も持続的なイノベーションなのです。もちろんAzureとAmazon EC2 はビジネス的にはこれからが旬なのだと思います。ただ研究者という立場からすると関心は減ったということです。新しい動きが出てきたらまた考えることにしましょう。もちろん何にフォーカスして、何を捨てるかは大きな賭けです。ただ選ぶ勘というか、センスは研究者にとって必要だし、研究者の運命がかかった賭けともいえます。

2010年8月26日

このところカメラの話題とが続いていますが、コシナのマイクロフォーサーズ用NOKTON 25mm F0.95の発表は衝撃でしたね。F値が0.95というレンズは35mm判用では少ないものの(以下は、該当するレンズを瞬時に2本以上あげられるような方むけです)、イメージサークルが35mm判よりもシネマレンズやレントゲン用ではF値が0.95はあったので、イメージサークルが小さければ作りやすいのでしょうか。個人的に驚いたのは最短撮影距離が17cmということ。フォーサーズなので35mm判換算では50mm。世にある50mmでF値が1.1以下のレンズでは、1m程度のものも多く、最短撮影距離が17cmというは最短のはず。このためだけにこのレンズを買うというか、このレンズでないと写せない世界がありあそう。ただ、NOKTON 25mm F0.95はフォーザイズ用レンズにしたら重いですよね。倍の35mm判用と大差ない重さ。周辺光落ちを嫌って、レンズを大口径にしたのでしょうが、もしかしてAPS-Cも狙っているのでしょうか。ちなみに当方はというと、フォーサーズのカメラはもっておらず、同じコシナの35mm判用のレンズ、NOKTON 50mm F1.1が欲しかったのですが、最短撮影距離が1mと知り、すっかり萎えたのでした。

それにしても(ミラー付きの)一眼レフカメラ全盛の時代になり、レンジファインダーカメラは古いもの、趣味のもの、という扱いになって久しいわけですが、ミラーレス一眼レフカメラが登場して、レンジファインダー方式の時代が再びやってきてしまったような感じですね。もちろんカメラとしてみれば、レンジファインダーではなく、一眼レフカメラとなるわけですが、レンズ的にはミラーが内分だけ、フランジバックの短いので、レンジファインダー用レンズそのもの。先日、Webにおいた夜のリスボンの写真と朝のリスボンの写真ですが、前者は全部がレンジファインダーカメラなのですが、後者は途中でカメラを変えており、前半がレンジファインダーで、途中から一眼レフ。どこで切り替えたのかがわかりますでしょうか。どの写真もWebに載せるためにサイズを変えただけで一切変更しておらず、撮りっぱなしです。

2010年8月25日

霞が関で用事。用務先の本省のオフィスと比べて、クーラーの効きがいいのがすばらしい。霞が関に行かれる方はご存知だと思いますが、エネルギーを所轄する某省と環境を所轄される某省が入っているビルは、空調は弱め、昼休みは電灯も消します。委員会が1PM始まりだったりすると最悪。ともかく暑い。地球温暖化とかいわれると妙に説得力がでてしまいます。それにしてもスタッフの方々は机にデスクランプをおいて昼休み中仕事をしていたり、机上の小型扇風機やうちわで暑さをしのいでいる姿をよくみます。また暑いオフィスにぎりぎりまで戻りたくないので、1PM近くまで周辺のコンビニで立ち読みをして時間を潰してる方も多い。こうした状況をみると省エネすべきところと、すべきではないところがあるように思えてきます。

2010年8月24日

ソニーの新しいデジタル一眼レフカメラのレフレックスミラーは透過ミラーだそうです。フィルムの一眼レフではキヤノンのEOS-RTやEOS-1RSなどがありましが、デジタル一眼レフでは透過ミラーは初めてかもね。透過ミラー式のメリットは、レリーズタイムラグの短い、撮影している瞬間の絵が見えることですが、実際に使ったことがある人はご存知だと思いますが、音が静かなのですよね。舞台や演奏会の撮影では重宝がられるかも。ただ個人的には好きではありませんでした。というのはレンズを絞るとファインダーが暗くなるので、通常のミラー式と大差ないと思ってしまいました。それにしてもミラーレス一眼レフから使い始めるユーザが増えると、ミラー付きの一眼レフはミラーレス一眼レフ＋αでないと売れない時代がくるのでしょうね。そして機構部分が多いミラー付きの一眼レフは一部のマニア向けのものになる運命なのかもしれませんね。可動式のミラー部分があるだけ、機構も複雑になるし、レンズと受光面の距離が長くなってレンズが大きくなるのですよね。

2010年8月23日

時差ボケになっている余裕もなく、2、3時間寝てそのまま貫徹仕事。いろいろなことがぎりぎりです。さてさて午前中は打合せ、午後はオフィスで残務処理。出張中にいただいたメールを順次返信させていただいておりますが、お待ちいただけると幸いです。

2010年8月22日

成田空港に無事に到着。ANAの新型エコノミークラスの座席ですが、なかなかよかったです。アッパークラスに乗れる立場ではありませんので、エコノミークラスの環境はたいへん重要なのです。そうそう成田空港は帰国客で満員状態でした。飛行機の方も予定時間よりも早く着いたと思ったら、成田空港上空で旋回して到着順待ちとなりました。

一昨日のこのページに書いたように国際会議からは知見が得られなかったのですが、一週間でも日常業務から切り離されると落ち着いて、研究構想を考えることができますね。研究者の仕事は広く浅くではなく、狭く深く考えることですから、出張先のカフェで思索する時間は研究者としては重要だったりします。

2010年8月21日

早朝の暗い時間にホテルを抜けでして、昼過ぎに空港に向かうまでの、6時間ほどリスボン市内を観光。そのときに撮った写真をWebにおいておきます。撮った順に並んでいるだけで、あまり整理はされていません。途中までは潔く50mm相当(35mm換算)の単焦点で一本で撮っていましたが、途中からズームレンズに日和りました(NDフィルターを持って行かなかったので、明るくなって絞るならば単焦点もズームレンズも大差ないから)。

さてTAPでリスボンからフランクフルト、ANAでフランクフルトから成田。ANAのフランクフルト便にはプレミアムエコノミー席がないので、当然、エコノミー席。それにしても満員のエコノミー席は辛いです。

2010年8月20日

国際会議(ECAI'2010)の最終日。会議は昼過ぎに終わり。それにしてもECAIといえば人工知能ではトップ国際会議のひとつのはずですが(採択率は20%)、内容的にいうと、当方がここ数年で参加・発表した国際会議では最低でした。もちろん当該分野の研究者は違うご意見なのかもしれませんが、専門外の当方としてはテクニカルに得られた知見は皆無でした。もちろん、こんなダメダメ国際会議で論文発表した当方も同罪ですがね。

まぁECAIの問題というよりも当該分野の研究コミュニティの問題なのでしょうが、研究分野を細分化して、テーマを作っているとしか思えない研究が多い。重箱の隅を突くという段階を越えて、隅のないところに小さい隅を作っている感じ。こうした傾向は他の分野でも見られるわけですが、細分化した研究成果を統合するという視点がまったくない。技術というのはそれぞれが直交しているわけではなく、複数の技術がコンフリクトすることがあります。

一生懸命、応用事例をあげているのですが、実際に応用して効果があったという発表は少ない、とっても少ない。応用事例をあげていても、その提案方法以外の方法でもうまくいきそうな事例ばかり。だから当該研究者には「いい例題」にみえても、それ以外からは「悪い例題」に見えてしまう。また応用指向の研究という位置づけでも、問題対象をものすごく単純化してしまっているので到底使えるとは思えないものばかり。例えば道路交通関係の研究でも、道路を閉ループがないと仮定していたり、車の走行速度を一定と仮定したり。閉ループを考えなくていいのならグラフ問題としては単純になりますが、現実は閉ループだらけ。そもそも一定速度でずっと走れるなら渋滞は起きません。素人目にもわかるぐらい非現実的な問題設定による研究でも、その部分には誰も質問しない。不思議なコミュニティですね。

それと時間が止まったような研究が多い。10年前といわれても気がつかないような研究発表が続いていました。セッションタイトルの半分以上は変わっていないのではないでしょうか。きっと細かく見ると進歩しているのでしょうが、前述のように細分化しているのでちょっとでも専門から外れると何が新しいのかもわからないし、それを説明する気もないようでした。それとシニアと思われるクラスの方の発表が多い。まぁ後者については有数会議だからそれ自体はいいと思いますが、研究者の入れ替えが怒らず、同じ顔ぶれが2年に一回集まっているのではないでしょうか。参加者の平均年齢が高いのですね。逆に言えば若い研究者はこの分野は避けているということになりますね。少なくても学生さんでも勘のいい方は避けるでしょう。

また発表で関連技術への比較や優位性を説明しない発表が多い(当方も発表では比較しなかったのでは、人のことはいえません)。ただ、世の中から取り残されたような研究が散見しますね。例えば情報から特定の情報を抽出する方法のセッションがあったのですが、わざわざ推論とかしなくても、Web検索の方がはるかに効率的に情報抽出ができているし、実際に使われているわけで、その研究分野以外からみると価値がないんですよね。世の中には違う技術でも同じ結果を導く技術はあるわけで、当該分野以外をふくめて優位性を説明して欲しいところ。

IEEE Intelligence Magazineだったと思いますが、人工知能の研究論文は人工知能以外の研究者から参照されないという指摘がありましたが、コミュニティ自体が閉じてしまっているのでしょうね。このコミュニティの人たちはこの先、どうするつもりなのでしょうね。今回はまさにそれを実感することとなりました。

2010年8月19日

国際会議(ECAI&PAIS'2010)の4日目。純粋人工知能系の国際会議は久しぶりだったのですが、多くの発表は自分のアルゴリズムを語り、簡単な性能評価をして終わるものが多く。だからそのアルゴリズムが何に役立つのかわからなし、仮に応用事例をあげている発表でも、その応用事例を見る限り、他のアルゴリズムでもできそうなものが多い。この分野は研究がモジュール化されていないというのか、例えば提案したアルゴリズムそれ自体は有用かもしれませんが、他のアルゴリズムと組み合わせたときに干渉してしまいそうな話が多い。各研究者は全体システムの一部を研究しているわけですが、おそらく自分自身の手法だけは評価しても、同時に使うべき他の手法との関係はいっさいみていない感じ。説明するのが難しいのですが、プログラムで言うと、特定の関数を(他の関数も参照する)グローバル変数をいじって最適化しているので、その関数だけ取り出してみれば最適化になりますが、全体としては動かないという感じでしょうか。

IntelがMcAfeeを買収するそうですが、Intelはこれまで米国の安全保障や国防上で重要な企業をいくつか買収してきています。純然な経済行為としての買収でしょうが、何らかの政府の意図もあったかもしれませんね。もちろん想像の域を超えないわけですがね。

2010年8月18日

国際会議(ECAI'2010)の3日目。今日は発表。ECAIといえば人工知能系では有名国際会議のひとつですが、質疑が低調というか、××について詳しく説明してください、という質問が多く、発表に内容にサジェスチョンを与えるような質問をしない。正直いって、昨日までのワークショップの方が質疑のレベルが高かったように思います。いちおう当該分野を代表する国際会議のひとつなので論文採択されることが目的化しているのかも。さて当方の発表ですが、人工知能の範疇にはいる研究でもなく、質問が少ないことをおそれて、質問しやすいように、穴をいくつかいれて講演していみたのですが、見事に穴をスルーされてしまう。まともな研究者ならば気づくであろう穴だったのにね。

それはともかく昨日と今日、リスボン市内を撮った写真をWebにおきます。当たり前ですが日中は国際会議にでているので、写真がとれるのは夜だけになりますがね。撮りっぱなしの写真が時系列に並んでいるだけですが、リスボンという街の雰囲気が伝われば幸いです。ちなみに5年前にプライベートでリスボンにいっており、名所旧跡はそのときの写真を見てください。

2010年8月17日

国際会議(ECAI&PAIS'2010)は昨日と今日はワークショップなのですが、ちょっと興味のある分野があり、お勉強中。ご存知のようにAI系の有名国際会議なわけですが、純粋AIの世界ということもあって、不慣れな分野。それにしても確率・統計を使った研究が多いですね。すでに応用数学の世界になっていて、コンピュータサイエンスの世界ではない感じ。ただ、例題指向の研究が多いのはあいかわらずですね。むかしもいまもAI的手法はうまくいく問題とうまくいかない問題があるわけですが、手法そのものの研究というよりも、いい例題をみつけることに注力している研究が多いのはあいかわらず。

2010年8月16日

昨日は飛行機の遅れもあって、24時間を超す長旅となったこともあり、ぐったりしながら国際会議へ。会場はリスボン大学の空港に近いキャンパス。このキャンパスにいくのは2回目なので慣れたもの。夕方、市内観光。リスボンは何度も来ているのですが、街に落書きがふえていますね。ここ数年、リスボンは治安が悪化して、観光客が減っているそうですが、たしかに以前より雰囲気悪いかも。幸い、9時ぐらいまで明るいので、暗くなってから街を歩くことはないと思いますが、ちょっと用心した方がいいですね。

ところで渡航先はLisbonですが、6月に移動のためにPortoに立ち寄ったときの写真をWebにおいておきました(短時間の滞在でしたが)。写真を見るとわかるようにワールドカップの真っ最中で、市役所前で街頭テレビをみながら一緒に応援しておりました。

2010年8月15日

ANAでフランクフルト空港、それからリスボン。ただしヨーロッパ中部の天候不順でリスボン行きは大幅遅れ。たしかにフランクフルト空港についたときは雨が激しかったです。ANAのフランクフルト便はプレミアムエコノミー席がなくなったのですが、CAさん曰く、フランクフルト便とニューヨーク便には新型機を投入したけど、プレミアムエコノミー用座席の調達遅れで、プレミアムエコノミーがなくなったそうです。小糸工業の座席の安全試験改ざん事件のあおりだそうです。スターアライアンスのゴールドメンバーで、エコノミー席からプレミアムエコノミー席へのアップグレードを期待している方はしばらくはフランクフルト便とニューヨーク便は避けた方がよろしいかと。さてエコノミーの新型座席ですが、好みが分かれるかも。

2010年8月14日

夜になってオフィスに出勤。海外出張前はいつもこのパターン。前回もオフィスから成田空港に直行でした。今日は乗った終電間際だったのですが、浴衣姿の人で多い。東京湾花火大会に行かれたのでしょうか。夏休み、それも深夜ということでオフィスはさすがに静か。

Oracleが、AndoridのJavaを巡ってGoogleを訴えたそうですね。メディアの方にも聞かれたのですが、正直いって話題にならないのではないでしょうか。少なくても昔のJavaを巡るSun MicrosystemsとMicrosoftの法廷闘争とは状況がだいぶ違うと思います。当時はMicrosoftは独自にJavaを作るというより、Javaを潰したかったのが本音でしょうが、Googleの場合はAndoridで(独自の)Javaをアプリケーション用の主要開発言語として使うことを狙っているわけですから。おそらくOracleが買収した旧Sun Microsystemsの関係者からGoogleに移る人が多くて、Oracleとしては何らかの対策が必要だったのではないでしょうか。本当にAndoridのJavaが問題ならばもっと早く裁判を仕掛けたと思いますから。それと旧Sun MicrosystemsからGoogleに移った人たちによる技術漏洩を心配していますが、Andoridまわりが裁判対象になるようですが、Sun MicrosystemsでもAndoridに近いJava MEまわりの人材は5年ぐらい間に流出しているはずで、Andoridへの情報漏洩としてもにわかには信じられません。Oracleにとっては、Andoridというのは単に裁判がしやすかったのでしょう。勝手にやっていただければよいかと思います。Javaに関しては、どうOpen JDKに移行させるかが重要でしょう。その意味では旧Sun MicrosystemsでいまもOracleにいて、さらにOpen JDKにも関わっている連中次第でしょう。彼らがOracleにいるうちに手を打ってもらいたいですね。そして、そのタイムリミットは短い。いずれにしても企業はビジネスよりも裁判を優先するようになると末期なので、Oracleの行く末の方が心配かも。

旧Sun Microsystemsの方々は本社があるSanta Claraに住んでいる人たちが多いし、家は相当高い地域で住宅ローンが残っているので、Santa Claraは動くすく人は少ないはず。その意味ではOracleの本社のあるRedwood cityはシリコンバレーの端っこですが(というかサンフランシスコ)、GoogleのあるMountain Viewは彼らにとって許容範囲のはずですがね。特に住宅バブル期にシリコンバレーで家を買った人は5千万円以上のローンが残っているはず。個人的にはシリコンバレーがいまもアクティブなのはシリコンバレーの住宅は高額で、そのローンを抱えた連中はシリコンバレーから離れないからだと思っています。人が動かないんだったら企業が集まることになります。ただ、住宅費が高い地域だから給与もたくさん払わないといけないけどね。

2010年8月13日

クラウドコンピューティングのセキュリティに関して。その前に米国のバス横転事故のニュースで、運転手はスピード違反でチケットを切られていたという記事がありました。クラウドコンピューティングやデータセンターのセキュリティとどうか関わるかというと、米国の場合、業務中以外を含めて素行や態度に問題がある人物を社員として雇ったり、社員に問題があった場合、雇った企業に損害請求が来るし、裁判になればたいてい負けます。このバス事故の場合、事故原因そのものは運転手の不注意であっても、問題のある社員に雇っていて、その社員が問題を起こしたのですから、バス会社は多額の賠償金を支払うことになるでしょう。これはクラウドコンピューティングも同じです。故意でないにしてもセキュリティ的な問題が起きて、他者に損害を与えた場合、そのセキュリティ担当部門に、セキュリティ的な問題行動を起こした社員がひとりでもいたら、損害を被った側はクラウドコンピューティングの事業者に対して損害賠償を請求してくるし、法廷に持ち込まれた場合、クラウドコンピューティングの事業者に損害賠償に勝ち目はない。海外の顧客が日本のデータセンターにデータをおかないのは、こうした問題発生時に損害賠償請求の範囲が狭いことに加えて、日本のデータセンター事業者の場合は社員を雇う際に素行調査まで行っているところは少ないので、海外からは日本のデータセンターは信用されません。こうした事情を抜きにして、国内データセンターに海外顧客を誘致策を議論するのはナンセンス。

ただ、日本の場合は企業だけでなく、社員も脇が甘い。通信会社やデータセンターで管理業務に携わる人でも、半ば誰かが特定できるような状態で、政治的な発言や誹謗中傷をのせたブログなどを掲載している方が見受けられます。米国だったら解雇か、少なくてもセキュリティが重視される部署からは外されます。というのはこうした社員を雇っていて、何かの事故などが起きて、損害賠償に関わる裁判になったら、そうした社員のブログの存在そのものが、社員の素行調査不足を裏付ける証拠になり、多額な損害賠償を受けることになるからです。なお、仮に国内の通信事業者やデータセンターが米国を含む海外から顧客からデータを預かるならば、こうした社員を辞めさせるか、重要部署から外すことが前提条件になります。ちなみに問題のあるブログや、問題のあるTwitterを発言をしてしまった社員さんですが、書いてしまった事実は消せません。お気の毒ですが、米国系のクラウドコンピューティング事業者やデータセンター事業者への就職は難しくなりますし、少なくても重要業務やセキュリティに関わるような部署には配属されることはないでしょう。ちょっと厳しいことを書きましたが、日本の常識と米国の常識は違うのです。

2010年8月12日

昨日に引き続きややメタな話で恐縮です。ご存知のように2011年度予算では社会保障などを除くと各省庁に１割削減される方向で進んでいます。どこで削るかは各省庁に任されておりますが、大学や国研は減額対象になるのは間違いないでしょう。国研の研究者(国立大の教員でもありますが)としては予算減額は我が身にかかわる深刻な問題なんですよね。国研の場合、予算の多くは文科省からの予算で、大学のように授業料収入はありません。大学関係者にいわせると授業料収入は教育関連への支出が実質的に義務づけられているので、大学は教育関連支出があるだけ国研より深刻だそうですが。それはともかくとして、１割削減が3年続いたとすると27％減になるわけで相当なしわよせがくると予想されます。

ただ、個人的に心配なのは学術研究に対する政策ビジョン。これが正直いってよくわからない。20年近く前に右肩上がりの経済拡大期は終わり、縮小期に入っているわけですから、削減はいたしかたない部分もありますが、それにしても学術研究に対するビジョンは定めて欲しいところ。

一方で世界的に見ると、研究予算は経費ではなく、投資として扱われる傾向が強まっています。つまり研究予算に対する経済的効果で評価されるということ。つまり100万円の研究予算をもらったら、100万円以上の経済効果をあげないと投資効果が低いと評価されることになります(つまるところ研究打ち切り)。日本ではまだその動きは少ないのですが、今後、その影響は大きくなっていくでしょう。あくまでも国民の皆様方に代わって、研究をさせていただいている立場ですから、世の中の流れに従うしかないわけですが、研究予算が経費ではなく、投資して位置づけられたときに、どうあるべきかはそろそろ考えておいた方が良さそうです。

2010年8月11日

最近、国際会議のプログラム委員を整理中。長年続けてきたものを含めて、いくつはお断りをしています。ちょっと補足をすると国際会議は基本的に分野ごと開催されます。例えばユビキタスコンピューティングとか、通信とか、ミドルウェアとかね。当該分野の研究者だけが集まって、当該分野の研究だけ発表したり、議論することになります。専門性というか、技術を深掘りをするには特定分野に特化して国際会議は正しいし、研究も特定分野に特化して、深掘りするのも正しい。ただ最近の傾向は、(世の中の)問題を技術を使ってどう解決するか、に移りつつあるように思います。そうなると研究者に求められているのは高度な専門性もありますが、それ以外に問題をきちんと理解して、それを解決に対する技術的提案が重要になってきています。その場合、専門性に特化した国際会議がいいとは限らない。もちろん研究者を続けるためには論文を書かないといけないので、国際会議での発表や論文誌への論文掲載は必要なのですがね。

2010年8月10日

夏休み中ですが、企業との打合せ。来年以降の仕込み。国研は企業と違うし、当然、国研の研究者としての責務があるし、国研の研究者だからお手伝いできることもありますから。それにしても世の中は休みなく動いていますね。8月に入ったばかりですが、この先数年の研究テーマを確立するという点では有意義な夏でしたね。

2010年8月9日

某国際会議と某海外論文誌の査読をしていたのですが、３本ともポリシー記述の論文ばかり(おかげで頭の切り替えをしなくていいので査読は楽ですが)。ポリシー記述はネットワーク管理、セキュリティ、コンテキスト依存などのいろいろ分野で流行っています(いまだにね)。ただ、いずれの分野のポリシー記述の研究にいえるのですが、ポリシーそのものが多様だから、いろいろなポリシーが記述できる言語を作って対応していきましょうという発想なのですが、問題は個々のポリシーも記述できるほど定まっていないことが多い。結局、記述言語を作ってみたものの記述対象がありませんでした、というオチになっている研究が多いんですよね。結局、言語設計や言語拡張といっても実際的な要求ではなく、脳内要求だけなんですよね。ちなみに今回、査読した論文２本はサービス指向系の話なのですが、ポリシー記述言語の汎用性とか表現性に拘っているのですが、普通なら不採録になるのですが、サービス指向系の研究はその手の研究ばかりだから不採録にするわけにもいかないところが複雑。

個人的にはサービス指向系の研究はピンと来ないんですよね。実はICSOCというサービス指向ではトップ国際会議ということになっている会議の第一回に論文を通したのですが、それがいい教訓になりました。その会議に行ってみてわかったことは、サービス指向という分野自体が研究として成立するほど成熟していないこと。実は他の参加者も同様の意見で、サービス指向の研究には手を出さない方がいいという立場の人と、もう少し様子を見るという立場の人に分かれていました(いろいろ国際会議に出ましたが、新しい分野なのに懐疑的な雰囲気でおわった会議も珍しかったです)。そして当方は前者をとりました。あれから数年たって、その会議の採録論文を拝見しても、あいかわらずなので、あのときの判断は賢明でした。何をいいたいかというと、今回のポリシー記述の査読論文も同じなのですが、サービス指向という研究対象そのものが不明確だし、研究のコアがない。どんな研究分野でもいえますが、コアがない研究分野って、あっという間に崩れるし、研究成果も残らない。そして米国だったら、研究者自身もテニュアとっていない限り、大学を追い出される。

一時脚光を集めたWebサービスに対して最近は否定的な話が多くなっていますが、WebサービスがWebという制約のために複雑化したこともありますが、それ以上に対象となるサービスが不明確だったために、それを支える技術が膨れあがってしまった部分は否定できません。いいかえるとサービスが明確になっていれば、それに必要な技術要件は自ずとわかるのですが、不明確なために必要な技術と不要な技術の線引きに失敗して、結果としてコミュニティ全体で脳内要求を膨らませてしまったのでしょう。これは他の分野でもよくあることですが、Webサービス系が不幸だったのは、その結果、標準化だけが膨れあがってしまって、それを支える技術が追いついていないこと。OSIの轍を踏んでしまいましたね。

2010年8月8日

休日出勤。夏休み中だけあってオフィスにいつもの週末とくらべて人が少ない。守衛さんによると1/3ぐらいだとか。まぁ普段の週末がおかしいという話もありますがね。

ところで日本では、5年遅れぐらいでコンテナ型データセンターが流行っていますね。先日、コンテナ型データセンターを提案している事業者の方と話していたのですが、日本でコンテナ型データセンターが普及しないのは法規上の問題で、特区ならば大丈夫と本気で思っているようで、ちょっと首をかしげたくなりました。確かにコンテナ型データセンターを野外に設置した場合は法規制に関わり認可なしでは設置できませんが、これが本当の理由なのでしょうか。というのは野外に設置した場合は、コンテナは動産ですし、水災や風災のリスクあるために保険が高くなりますし、リース調達した場合はリース料が高くなります。このため屋内に設置する方が安く上がるのです。ちなみに前述の事業者の方に保険の問題を指摘したら、驚かれてしまいました。収容するサーバ数やPUE値の話も大切でしょうが、企業に売るならば(保険を含む)資産管理込みで考えて欲しいです。ちなみに、その担当者は自社所有だから保険に入るかは関係ないとのおこたえでしたが、自社所有のコンテナでも盗難リスクや雨風をうける場所に設置した場合、資産価値が下がる可能性があるために株主が許してくれません。経営センスなさ過ぎ。

2010年8月7日

所用で自宅から2kmほど離れた大学へ。ところで先週に引き続き人物撮影をすることに。今日もレンズはPlanarの50mmにしてみました。先週、レンズのことを書いたら質問を受けたので補足しておきます。PlanarというのはZeissが設計したレンズ(構成)の名称。SonnarもやはりZeissが設計したレンズ(構成)。ご存知のようにレンズは凸レンズや凹レンズなどを複数枚組み合わせるのですが、その組み合わせ方(構成)によって、移りが違ってくるのです。他にはTessar型と(変形)Gauss型あたりが代表的でしょうか。もちろんレンズは絞ってしまえば差がなくなりますが、絞りを開放で撮ると焦点以外の部分がボケますが、そのボケ方はレンズ構成が結構影響してくるのです。写真からレンズ構成を見分けられるかですが、例えば同じPlanarでも製品によって違いがあるので、明確な差はないのですが、Sonnar的なボケ、Planar的なボケはあったりします。もっとも自己満足の世界です。なお、Hasselbradのような中判カメラを使えばきっとわかるのでしょうが、当方は中判を使う趣味はないので、その方面はよくわかりません。

2010年8月6日

アラブ首長国連邦(UAE)やサウジアラビア、インドで、BlackBerryの通信が検閲できないことから規制の動きが出ていますが、本当に傍受や検閲が難しいというのならば、iPhoneやAndoridよりもBlackBerryの方がセキュリティ的に良さそうにみえてしまいます。

2010年8月5日

某鉄道会社の本社で打合せ。子供の頃は電車の運転手になりたかったはずなのに、いまの仕事になってしまい、どこで人生を間違えたのやら。まぁ、仕事で、テレビ局に行ったり、東京タワーに登ったり、港にいったり、地下道をあるいたり、発電所にいったり、官邸にいったりと、いろいろいけることはメリットなのですがね。

2010年8月4日

昨日の続きですが、日本人ならば英語の論文で読むより、日本語で読む方が早いので、和訳されたり、日本語の類似文献を探される方もおられますが、正直いってお勧めしません。わかりやすい原論文が、和訳で意味不明になることもありますし、日本語の類似文献が正確とは限らない。一例を挙げると、以前、分散システムの経験則であるCAP定理のPが指す「Network Partition Tolerance」を「分散」と訳している人がおられたのですが、Network Partition Toleranceは文字通り、耐ネットワーク分断の意味であって、それを分散と訳したら、わかるものもわからなくなります。こと専門情報は(英語のWikipediaはまだいいのですが)日本語のWikipediaは不正確なものもが多いですね。実は授業のレポートを採点していて、同じ間違いをしているレポートが散見されたのですが、よくよく調べると日本語Wikipediaの説明に問題がありました。CAP定理もそうですが、誰かが誤訳したり、誤解した説明をするとそれを参照した説明が出てきてしまう。関連分野に知識があったり、原文にあたればわかるはずなのですがね。

2010年8月3日

先日、博士課程の学生さんから論文が難しくて読めないので、平易な解説はないかと相談を受けたのですが、ちょっと困ってしまいました。というか、その学生さんの専門に関わる論文か、それ以外で答え方が違ってしまうので。後者の場合は手っ取り早くは技術的な内容がわかればいいわけですから、平易な解説を読めばいいわけで、知っていれば紹介します。問題は前者の場合、つまその学生さんの専門の場合なのです。

論文は専門家向けに書いてあるので難しくて当然だし、論文は専門家向けに書いてあるので難しくて当然。難しいからといって論文を読まずに、平易な解説にたよっていたら、いつまでたっても論文が読めるようにはならないし、そもそも平易な解説というのは情報が少ないから、知識も浅学なままで終わってしまう。学生時代に論文を読むトレーニングができていないと将来、論文や技術書類を読まないといけなくなったときに、本当に困ることになりますから。

まずはトレーニングだと思って論文にも立ち向かって欲しいですね。そのときは自分なりの解釈でいいと思います。ここで「自分なりの解釈」というところが重要で、難解な哲学書と同じで、難解な文書を読みほぐす過程で、いろいろ考えたり、用語の意味を調べたりするわけですから。それと、自然科学の論文では実験結果の数値がすべてとなることがあり、論文内容は誰が読んでも同じ解釈になるかもしれませんが、コンピュータサイエンスの場合は、情報システムのアーキテクチャに正解がないように、人が介在する余地がすごく大きいのです。

だから論文を読んで、自分なりに解釈して欲しいのです。論文を印刷するだけではダメで、論文に書かれていることを自分で解釈して、自分の知識にしてほしいのです。それからこのとき論文を頭から読む必要はなく、つまみ食い的な読み方でいいので、自分にとって必要な情報をすばやく集める方がいい場合があります。米国のトップ大学の場合、博士課程の学生さんは一日に5,6本の論文を読んでいますから、彼らと研究で戦うには、こうしたショートパスも必要です(１日１本ペースでは絶対に勝てないです)。

それと論文の用語がわからないという質問をうけることもあります。実際には用語は研究者によって意味は微妙に違うから、用語の意味は正確にわからないかもしれないし、同じ用語でも分野によって違う意味で使われることがあります。ただ、同じ分野であれば用語の意味に多少のぶれがあっても、研究コミュニティとしてはある種のコンセンサスがあります。ただ、これはたくさんの論文を数を読んで、それぞれの論文がどのような意味で使ってるかを覚えるしかないと思います。

2010年8月2日

一昨日は長野新幹線でしたが、今日は東海道新幹線。夏休みで混んでいると思ったのですが、むしろ普段よりもすいています。ところで新幹線の運行はクラウド化できないのでしょうかね。つまり時刻表をなくして、忙閑にあわせて動的に運行ダイヤを変えてしまう。列車編成のやりくりや座席予約の問題がありますが、考えてみるとおもしろいネタですね。

2010年8月1日

休日ですが、ほぼ貫徹で論文執筆。なんとか完成・送付。さてちょっとマニアックな話題。わけあって人物の撮影。単焦点50mmレンズ(Planear 50mm)を引っ張り出して撮影したのですが、Planarは人物撮影いいですね。Zeissのレンズを評して「キレのSonnar、ボケのPlanar」といわれているだけあって、Planerのボケはいいですね。ふわっと溶ける感じ。さすがはZeiss。ちなみにSonnarはContax T3についている35mmぐらいしか持っていませんが、T3の解像感はすごいです。某カメラ雑誌の最新号にボケの特集がありましたが、レンズはボケ味に拘り出すと沼に堕ちます。お気を付け下さい。

2010年7月31日

昼頃に会議は終わり。いやいろんな意味で濃い会議でした。当方は帰り道に軽井沢のセゾン現代美術館。国内の現代美術系の美術館としては作品も充実していて、いい美術館なのですが、展示品が4,5年前とほとんど同じ。観光地だからリピータは期待していないのかもしれませんが。メルシャンの美術館にも行こうと思ったのですが、さすがに時間もなくなり、帰京。

2010年7月30日

午前中は立ち会いの仕事。それから大急ぎで長野新幹線で移動。クラウド関連の合宿。内容はかけませんが、12時過ぎても議論が続く、ハードな内容でした。出張直前に、出張に持参するPCのEclipseを前のバージョンを消して、ver.4にあげたのですが、これで結構はまる。まぁ会議中にプログラミング内職をしようと目論んだのですがね。

2010年7月29日

明日、廃棄備品の回収があるためその取りまとめ。かなり捨てることになりました(もちろん耐用年数よりも古いものばかりですが)。仕事上、コンピュータは研究の対象であり、研究の道具。このためコンピュータには思い入れは一切しないことにしています。というか特定のコンピュータへの思い入れをもっている限りはコンピュータの研究はできませんからね。それと過去に名機といわれようと、コンピュータに重要なのはいま現在の性能なのですよね。いくらいいコンピュータでも後生大事に持っていても意味はない。

2010年7月28日

メーカの方々とあうと夏休みも工場を稼働させるという話が多いですね。世の中、景気がよくなっているということなのでしょうが、9月以降は為替レート次第と総じて悲観的。

日本のヤフーとGoogleの提携が話題になっていますが、そもそも日本のヤフーと米Yahoo!は基本的に違う会社だし、日本のヤフーは技術を重視しているともいえませんから。米Microsoftは今回の提携に懸念を表明していますが、今回の提携で一番影響をうけるのは電通や博報堂を含む広告業界ではないでしょうか。ネット広告、そのなかでもWeb検索向け広告は大きな柱で、その根幹技術がGoogleになるということは、ネット広告においてGoogleの支配が強まるということ。

2010年7月27日

午前中はインターンシップでフランスの大学から来られている学生さんの進捗状況報告。実装力のある学生さんだったので、いささかむちゃふり的なテーマにしたのに、難なくこなされてしまう。いささか敗北感。まぁそれは冗談ですが、内容的にはそこそこの国際会議は通せるはずなので、いい論文を書いてもらわないとね。それにしてもインターンシップの学生さんのテーマ設定は難しい。ある程度、やればできるネタにしておかないと期間内に終わらないし、それだと研究的にはつまらない。午後は某社に行ってから、某省の紹介で某所にお出かけ。内容は書けませんが、今日もいろいろ勉強になりました。

2010年7月26日

午前中は早大理工に伺って、午後は霞が関同庁舎５号館の某省に伺う。いろいろ勉強になりました。関係者には感謝です。ここでその用務は書けないので、それ以外のことを少々。同庁舎５号館はクールビズ運動の本丸。というわけで皆さんはノーネクタイというか、ラフな格好な方も多いのですが、それ以前に空調の設定温度が高くて、スーツを着ていたこともあり、ロビーや廊下は蒸し風呂(会議室は空調が効いていました。念のため)。それと昼休み中は徹底的に節電するので、廊下や部屋の照明も消されるので、昼間だというのに皆さんデスクランプでお仕事。ただ、将来の省エネオフィスの実状を知る上でも、機会があれば真夏の同庁舎５号館は体験されておいた方がいいかもね。現状の我々の快適な生活環境を可能な限り維持しながら、省エネ化するための研究開発の必要性がわかります。

2010年7月25日

いやはら休日出勤でございます。まわりも休日する人が多いので、休日出勤という感じがしないところが怖いです。対霞が関用の資料作成。基本的には自分の研究の説明なのですが、その実施を想定すると、結構、込み入った案件もあるので気を遣います。文科省系の国立研究所に勤めている立場でいうのも変ですが、霞が関といってもいろいろな省庁があります。もちろんお互い相手の立場はわかっているし、最終的な目的は国民のためなど共通なのですが、そこに至る方法論には違いがあったりします。ただ、最近は横断的な要件が増えているので、複数省庁が関わることになります。ちなみに今回の案件は当方の研究の応用なのですが、三つの省(文科省を省く)が関わるので、事前説明だけでもいろいろあります。

2010年7月24日

いろいろたいへんなのであります。どうしましょう。

2010年7月23日

スイスの列車事故のたいへんなことになっていますね。実は列車事故のすぐ近くに一週間ほど滞在したことがあります。といっても10才頃なので、あまり覚えてはおりませんが、沿線に小さな村が点在する風光明媚なところでした(昨年は患者さんが搬送されている病院がある街Vispまでは行ったのですがね)。ちなみに斜面を登るためにループがあったりと鉄道好きにはたまらないのだと思います。

2010年7月22日

凸版印刷の110周年記念イベントに講師に呼ばれて講演。講演後に前勤務先時代の、当方の研究室及び他の研究室の元学生さんと会いました。皆さん、凸版印刷におつとめなわけですが、ご活躍をお祈りしております。

2010年7月21日

早朝に帰国、それから霞が関。オーバーナイトフライトは苦手です。特にシンガポールは時差が1時間なので、感覚としては国内出張で深夜バスで帰ってきた状態。

2010年7月20日

国際会議IE'2010の本会議2日目。基調講演は東大の坂村健先生にお願い。おもにTRONハウスの話。さて会場はMonash大学マレーシア校。御存知のようにMonash大学はオーストラリアの名門大学。特に工学部では有名な大学。マレーシア校のディレクターと話をしていたら、大学全体としても世界大学ランキングでも40番台だそうです。日本の大学よりもレベルが高いですね。さてマレーシア校ですが、場所柄もあってイスラム圏の国々からも優秀な学生を集めていますし、当然、マレー系や中国系も多いし、オーストラリアやニュージーランドからも結構来ているそうです。実際、大学ではいろいら人種や民族の方が多く、非常に多様性が高い。授業料を聞き忘れてしまったのですが、日本の大学よりもいいかもしれませんね。あたりまえだけど授業レベルも日本よりも高い。生活費は安く済みますし、大学のすぐ近くには巨大なショッピングモールがあって、日系スーパー（ジャスコ）の大型店舗まであります。そして多様性がない世界にいきた生物は、多様性の高い世界の生物に勝てません。これと同じで、日本人しかないない大学で勉強した学生さんと、多様な国籍や民族の学生さんといっしょにまなんだ学生さんでは勝負が見えています。

2010年7月19日

今日から国際会議IE'2010の本会議1日目。ジェネラルチェアとしては会議関係者への挨拶。さて基調講演はマレーシア政府、それも首相のIT補佐官にお願いしたのですが、あたりでした。貧困国に対してIT技術をどう普及させるのか、という話。経済性を考慮した話でしたが、よかったですね。これが日本だと、総花的なIT行政の話しかしないでしょうし、仮に海外展開といっても、、日本の(高価な)IT技術をアジアに一方的に押しつけるという話になりそう。

実は昨日、今日の講演の関係で、マレーシア政府の方と打ち合わせがあったのですが、1990年代にマレーシアは当時の首相が親日派ということもあって、日本からの通信技術支援を受けたそうですが、マレーシアにとって技術方向性も費用対効果も不向きだったそうです。このためマレーシアの情報通信は数年遅れてしまったとのこと。このあたりの内実は日本でも知られている話だと思いますが、問題なのは日本側の当事者だった方々はいまでもいいことをしたと思い込んでいること。情けないというか、ここまでくると悲しい状況。でも現実が見えない人には永遠にみえないし、同じ失敗を繰り返す。

2010年7月18日

国際会議IE'2010の併設のワークショップで基調講演。かなりウケがよかったです。今回はユビキタスコンピューティング系の実証実験の舞台裏的な話を中心にしましたが、リアルな場所、リアルなユーザ相手に実証実験をすると、研究の課題は技術ではなく、舞台裏的なことの方が重要。だけど舞台裏の課題は論文にはなりにくい。それとこの分野は、研究室内の簡易実験や数日間の実証実験が多いのですが、そんな実験をいくら繰り返しても無駄。実際の問題は実際の場所、本当のユーザ相手でないと絶対にわからないです。正直いって、そのレベルの実験で、わかったような気分になっているぐらいならばやらない方がいいです。無題というか害なんですよね。

2010年7月17日

早朝にオフィスで一仕事。大急ぎで成田空港。もうすこし時間があったら今日から開業の新型スカイライナーに乗ってみたかったのですが、そんな余裕もなし(だいたい日暮里にでるのがたいへん)。マレーシア航空で成田空港からクアラルンプールに移動。マレーシアで開催される国際会議(IE'2010)のために移動。当方はIE'2010のジェネラルチェアなのです。IEは欧州開催が多いのですが、今回はアジア開催。

あまり国際会議のマネージメントは好きではないのですが、日本から会議の役員になられる方が少ないので、日本のプレゼンスはほとんどない。多少、そのプレゼンスをあげるにはこうした仕事も重要なのです。もう少し正確に言うと、日本人主体の国際会議では役員になられる方は多いのですが、それでは海外へのプレゼンスはゼロ。やはり海外勢主体の国際会議でプレゼンスを維持しないといけないのです。ただ、こうしたことがわかってくれるのは同様に海外勢主体の国際会議などで役職になられる方々だけなのですがね。

2010年7月16日

オフィスに4月に納品された複合機(エプソン製LP-M5000)が壊れて修理。電源投入後のブート中に止まってしまうという状況。メーカからエンジニアさんがこられて修理作業なのですが、長くても1時間もあれば終わると思っていたのですが、4時間かかる難修理。こちらは作業をお願いするだけですが、なかなか落ちけず仕事に集中できませんね。ただ、エンジニアさんは本当にたいへんそうでした。ご苦労様です。なお、同型機種のプリンターは相当トラブルがあるようで、まわりで同一機種を使っている方々に故障事例集を配布して欲しいと頼まれました。レザープリンタの複合機は安くなりましたが、品質にしわ寄せが来ているのでしょうか。なお、別の部屋用に購入した同型機種はスキャナーでトラブルがあったようです。

2010年7月15日

EU(正しくはEuropean Commissionというべきか)の科学技術エージェンシーのひとつ(日本でいうとJSTみたいな組織)の委員をしており、FP7(そしてFP8)の情報系の研究テーマ作りの仕事もしております。それで当方の担当分野のひとつは、いわゆるユビキタスコンピューティング関連。ただ、FP7ではユビキタスコンピューティング関連に予算が大量投入でしたが、FP8では激減される見込み。一方で、EUの各国がユビキタスコンピューティング関連の予算を増やしています。ただ、ドイツはシティ規模のコンテキスト依存サービス、イギリスはe-Scienceとセンサーネットワークの融合、スペインとポルトガルはe-Healthなどなど。各国事情を反映したものなので、ある意味で健全なのですが、テーマが断片化することになります。ユビキタスコンピューティングは大元の米国研究者は抜けてきており、欧州と日本、韓国あたりが主体。ただ、欧州も特定の問題に特化する方向になってきてますから、ユビキタスコンピューティングの研究コミュニティは分断化されることになりそうです。ただ問題別に向かうのはユビキタスコンピューティングだけでなく、他の分野も同様。FP7が技術シーズベースだったのに対して、FP8は問題解決にシフトしそう。これまでのような研究分野にしがみついてしまって行き場を失う研究者が増えそうです。

2010年7月14日

一昨日にも書いたMicrosoftのAzureアプライアンスの絡みで電話取材。先方の期待とは違うコメントをしてしまったようです。ただ、立場上、特定の企業に肩入れすることはできないし、Azureの外販自体はAzureの発表時ですでにMicrosoftは否定をしていなかったわけで、想定範囲ですよね。それと今回のAzureアプライアンスはMicrosoftのパートナー企業(つまりDellやHP、富士通など)への配慮以上の意味を見いだせない。正直言って今回のMicrosoftのAzureアプライアンスを話を聞いたときの第一印象は、かつてのメインフレームビジネスとそっくりというもの。メインフレームのベンダーは、メインフレームをユーザ企業にウリながら、一方でユーザ企業がまかなえなくなった処理の代行サービスをしていました。クラウドは後者に相当しますが、Azureアプライアンスは前者もはじめるということ。どちらも対応するのはいいことかもしれませんが、同時にビジネス戦略が不明瞭になるというリスクもあります。

2010年7月13日

Windows XPのダウンロード権(つまりWindows VistaやWindows 7の購入者が無料でWindows XPにダウングレード)が2020年まで延長だそうです(2020年までのWindows 7の提供期間中はダウンロード権が有効となる)。つまりオフィシャルに2020年までWindows XPが入手できることになります。逆に言うと2001年発表のOSであるWindows XPで十分と思うユーザが少なくないことを、世界最大のOSベンダーであるMicrosoft自身が認めたことになります。先日も書きましたが、OSは技術進歩が止まって、コモディティ化しているということなのかもしれません。業界ダントツの研究開発費を投資している企業が、2001年発表のOSを2020年まで提供するということは尋常な事態ではないはず。

OSを研究されている方には怒られそうですが、急速に技術変化するIT業界においてOSだけ取り残されているのかもしれません。学術研究的にはOSは隔年で交互に開催される国際会議SOSPとOSDIが最先端の研究が発表される場ということになっていますが、Linuxなどの既存OSの機能拡張・追加的な話がほとんどで(昨年のSOSPに限ればOSまわりどころか、Hadoop絡みが多かったような気がしますが)、新規にOSを作ろうという研究は皆無(それどころか特定の研究グループの論文ばかり通る状況)。もちろん新規にOSを作ることはとっても難しいし、新規OSが学術的に貢献できるとも限らないのですが、どこかで大きく変えないと大きな進歩もできないはず。OSが専門というわけではないのですが、コンピュータサイエンスの研究者の一人としてWindows XPの延長を憂慮すべき深刻な事態と受け止めています。

2010年7月12日

Microsoftが同社のパートナー向けカンファレンスで、Azureを組み込んだハードウェアをベンダー(いまのところ名前が挙がっているのはHP、Dell、富士通)を通じて提供することを発表。昨晩のストリーミング中継の時間は、昨晩は貫徹だったので寝てましたけど。さてAzureインフラの提供自体は公知だったのですが、個人的な注目点は提供方法でした。例えば販売する、レンタル、特定のデータセンターに設置などいろいろ想定されますが、販売とレンタルになるようです。さてプライベートAzureはパブリックAzureの開発・初期運用環境なのか、その逆、つまりパブリックAzureはプライベートAzureの開発・初期運用環境なのか。ただサービスを作る側にとってはプライベートAzure用のサービスをそのままパブリックAzureに移行できるわけですからメリットは大きいですよね。また機能を制限した基本版サービスをパブリックAzureに無料または格安で提供して、フル機能のサービスをプライベートAzure用に提供してガッポリ儲けるというビジネスモデルもでてくるでしょう。それはともかく、こうした製品がでてくるとパブリッククラウドとプライベートクラウドをわけることが意味ないのかもしれません。

2010年7月11日

結局、オフィスにお泊まり残業です。決勝戦見たかったですが、そんな暇はありません。国研の研究者もたいへんなのです。

さてTwitterはCasandraを使わないそうですね。一昨日のこのページに書いたように分散システムは通信制約という物理的な制約があります。これを回避することはできませんが、アプリケーションに応じてその影響を小さくする方法はあるかもしれません。しかし、その方法があったとしても、アプリケーションの特性に応じて、技巧的に影響を小さくするわけですが、同じ方法が別のアプリケーションに使えるとは限らない。Facebook向けに開発されたCasandraがTwitterに向いているとは限りません。

ところでCasandraというとBerliozのオペラ「Les Troyens」しか思い出せない。2006年にパリオペラ座Bastille劇場で見ているのですが、Cassandraは(イタリアのあたる地域)王女ですが、まわりから気が狂っていると思われている役。トロイの木馬の入場を止めるのですが、群衆が例のトロイ木馬を引き入れてしまったあと、イタリア建国を夢見ながら自害することになります。というわけでCassandraというと不吉なイメージなんですよね。

2010年7月10日

先週の北米出張中に米大の連中と話題になったのが、Googleにいった学生さんの今後、というかコンピュータサイエンスの今後。ご存知のようにGoogleは博士課程の学生さんに大人気。コンピュータサイエンスのPhDをとって企業に行く人はいままでも多かったのですが、例えばIBMやMSは研究職雇用で論文も書いていました。だから企業をやめたあと大学で教員として採用されることも多かったのです。しかしGoogleに行かれた博士課程修了の学生は技術職採用で論文をあまり書かない。そうなると彼らがGoogleをやめられても、大学としては採用しにくいのです。問題なのはコンピュータサイエンスは、Googleに優秀な学生さんを取られている上に、その学生さんたちがコンピュータサイエンスのアカデミック研究に戻ってこないとなると、長期的にはコンピュータサイエンス全体としてジリ貧になりかねないということ。特にGoogleにいく学生さんが多い研究分野は深刻です。

2010年7月9日

某省訪問。同じ建物でも11階の部局はよくいっていましたし、その部局のレポートも書かせてもらっていましたが、今日は別フロアーの別の部局。いろいろお世話になりました。

ところで昨日の続きをすこし。分散アルゴリズムをみるときに注意した方がいいのは、効率的なアルゴリズムは必ずしも実用にならないということです。分散アルゴリズムというよりも通信プロトコルですが、TCPのハンドシェークを効率化する方法としてTransaction TCPというプロトコルが提案されましたが、使われているとはいいにくい(Googleはご執心という噂ですが)。アルゴリズム的には正しくても実用になるには無駄や冗長性が必要ということなのでしょう。その意味ではQuorumを使った分散アルゴリズムも、メッセージ数を減らすようにQuorumを小さくすると、実際のシステムにおけるトラブルの影響を受けやすくなりそう。また分散アルゴリズムではメッセージの到着順は不特定を前提にしますが、実システムではTCPを使えば到着順は保証できるし、いまどきのTCPの実装はいいので下手にUDPを使ってアルゴリズム通りに実装するより性能がよかったりします。ACM PODCあたりに発表される分散アルゴリズムの論文は重要ですが、実装とは大きなギャップがあるということです。

2010年7月8日

打合せの日。ところで分散システムの問い合わせをうけます。個人的にはその問い合わせ内容よりも、この時期に問い合わせてくることの方が興味深かったり。分散システムを特徴付けることをひとつあげよ、といわれれば通信遅延。というかこれがすべて。通信遅延があるので、分散システム内のコンピュータは他の現在の状態がわからない。わかるのは過去の状態だけ。その意味では星を見たときに、その光は大昔に発せられたと同じ。いまこの瞬間にはその星は爆発して存在しないかもしれないように、分散システムでも通信相手のコンピュータからメッセージが届いても、そのコンピュータにはこの瞬間には壊れているかもしれません。そして分散システムの根幹となる分散アルゴリズムは通信遅延の影響を避けながらその目的を達するための方法。例えば分散コンセンサスアルゴリズムでは各コンピュータで同じ状態をもつ方法を探りますし、分散相互排除アルゴリズムでは高々ひとつのコンピュータとそれ以外を明示的にわけます。また、リーダ選択アルゴリズムでは高々ひとつのリーダを選びます。どれも結局は通信遅延との戦い。

2010年7月7日

来客対応の日。ところでWindows 2000のサポート期間がいよいよ切れるそうですね。世間ではWindows 2000の現用機は結構残っているような気もしますが、10年前の製品ですから、致し方ないともいえます。ただ、気になるのはWindows 2000と現行のWindows 7に本質的な差があるのだろうかという点。もちろんGUIも違うし、Windows 2000では最新のアプリケーションは動かないかもしれません。そのアプリケーションについてもWindows 2000がWindows 7と比べて機能不足だから動かないと思えない。Microsoft Officeを例に考えると普通に使う分にはMicrosoft Office 2000とOffice 2010に差があるかという疑問です。PCというカテゴリーの成長限界だったのかもしれません。それにしても我々は10年間、何をやってきたのでしょうかね。

2010年7月6日

海外出張後は毎回同じですが忙しいですね。昨日の続きのような話になってしまいますが、Communication of ACMの3月号にジャーナルよりも国際会議を重視するのはコンピュータサイエンスだけという記事がありました。論文の発表先として国際会議とジャーナルはそれぞれ利点・欠点があり、どちらがいいとはいえないのですが、全般に難関とされる国際会議はそのときそのときで流行しているテーマがあり、逆に流行以外のテーマを扱った論文は採録されない傾向があります。特定のテーマに絞ることで発展を促せるかもしれませんが、本来、流行にとらわれずに研究すべきテーマは採択されないという状況がおきがちです。このため流行しているテーマがある程度発展すると、次に流行するテーマを探すという繰り返し。10年も立つと昔、流行したテーマを忘れており、同じテーマの研究を再度繰り返すことになります。これがコンピュータサイエンスでよくいわれる研究のデジャヴ—の原因になっているように思います。一方、ジャーナルの査読の場合は、いい研究か否かどうかで採否をきめるので、地道な研究も採録されます。コンピュータサイエンスは多少はジャーナル指向になった方がいいのかもしれません。

2010年7月5日

さて帰国です。国際会議の内容的には最後の一日に余計だった気がしますが、会議以外での情報交換は優位意義だったのでいいでしょう。最近、国際会議の内容と採択率が一致しないことが多くなってきているといわれます。今回の国際会議は約30%。Communication of ACMの6月号に調査した論文が出ていました(ACMの会員でないと読めないかも)。採択率と参照数の相関をまとめたものですが、採択率が15-25%あたりの国際会議の論文は参照数が増えますが、10-15%ぐらいだと下がるというもの。ただ、これは単純にいえませんね。参照数は著者数が多い方が高くなるといわれており、そうなるとHPC系のように各論文の著者数の多い分野は有利になりますが、HPC系は装置・設備がないと研究できないので、研究者数が限られるために採択率が極端にあがることはない。ただ、米国大学の関係者は採択された論文の国際会議を採択率で、予算獲得やポジション及びテニュア獲得に影響するので、採択率を引くしたい方々もおり、なかなか難しいです。

2010年7月4日

せっかくサンフランシスコ空港に楽に行けるようにサンフランシスコ市内に移動したのですが、独立記念日のためか、公共交通機関がまともに動いておらず、結局、タクシー移動。まぁ短時間とはいえ、市内にいられたのでよしとしますが、場所的にはつまらない出張となりました。まぁ国際会議もつまらなかったのですが、急遽参加することになった技術交換会やシリコンバレーの企業訪問などでは成果があった出張となりました。ただ、米国出張はしばらくいいかなぁ。

2010年7月3日

国際会議の三日目。内職がはかどります。いいのかわるいのか。会場の隣の部屋ではインド系の方々のイベント。怖いものみたさで乱入してみましたが、ステージが作られてインド映画さながらに歌って踊っておりました。それから隣の隣の部屋ではOracleのFinaical系の部門がなにやらセミナーを開いている様子。すごいのはそのセミナーに参加している方のiPhone、それも新型iPhoneの所有率。さすにがに三日目になると集中力が落ちてきました。比較的実務に近い問題である国際会議でおもしろみに欠けましたが、実際のシステム開発の現状を反映している点は価値があったのでしょう。

午後は空港の移動の都合からサンフランシスコ市内の空港行きの地下鉄駅の近くのホテルに移動。ホテルの斜め向かいにミュージカルのWICKEDがやっていたのですが、ホテルにチェックインするときに割安当日券があることを教えてもらって観劇(想定外でしたが、こうした土壇場の判断だけは得意)。オペラばっかりみているとおもわれているようですが、ミュージカルも結構見ております(ただ、今回のように格安当日券でないと、安い席はミュージカルの方が高い)。以前、WICKETですがニューヨークで見てみようと思ったことがあったのですが、チケットが高すぎて断念した演目。

さてWICKEDですが、ご存知のように「オズの魔法使い」のアナザストーリということで、「オズの魔法使い」では見方役の東の魔女と悪役の西の魔女のいきさつというか、西の魔女をフューチャーした作品。というわけでオズの魔法使いを見ていないとわからないし、特に衣装的にはジュディ・ガーランドが主演した古い映画「オズの魔法使い」を見てないとピンとこないかもね。ミュージカルの出来というよりも原作の問題なのかもしれませんが、「オズの魔法使い」と整合性をとろうとしていることがかえって、WICKEDのストーリーをわかりにくくしているかも。ミュージカルなのだから、苦労しました、でも成功しました、やったー、でいいと思うですけどね。それと思いのほか、楽曲的には平凡でした。いい楽曲でもオペラ座の怪人のように、同じ曲を繰り返し、何度も歌われるので閉口しますが、WICKEDはそれ以前に楽曲的な魅力はない。そう思うとマンマミーヤはストーリー的には平凡ですが、ABBAの数多くのヒット曲をちりばめているので飽きがきませんでした。辛口の感想を書いてしまいましたが、たぶんWICKEDはアメリカ人にはうけるのでしょう。東の魔女がいかにもアメリカ人的なポジティブ指向だけど、まわりに流されやすい性格という設定になっていて、感情移入がしやすいのかも。実際、東の魔女役のキャストの出来不出来や声質で作品イメージがかわりそうな作品でした。カーテンコールも東の魔女役と西の魔女役はそろって登場しており、あくまでも同列という扱いなのでしょう。ただ、ストーリー的にはメインである西の魔女の出来不出来にはどうでもいい作品です。それとWICKETですが、正義の味方は浮かばれないし、異端でおわるというのは、これまでのミュージカルにはないストーリーです。最後の最後で、死んだはずの主人公の西の魔女が実は生きていることにしたのはミュージカルらしい配慮でしょう。もしVerdiのオペラだったら不遇のまま死んでいますからね。さて日本でも劇団四季で上映されていたと思いますが、うけているのでしょうかね。

2010年7月2日

国際会議の二日目。今日ははIBMのVice Presidentの基調講演。内容はIBMが盛んにプロモートしているSmart Planet。重要なプロジェクトだとは思うのですが、IBMの方によるSmart Planetの講演は何度も聞いているのですが、毎回、同じビデオを流されるので、正直いって閉口状態。ただ、誰が話してもそっくりの内容となるという、IBMの統制能力の方に感心してしまいます。それと最近のIBMはテクノロジー予測に長けているので、過去のビジョン、例えばPervasive、Utility、そしてAutonomousにしても的を得ているし、キャッチフレーズの付け方も旨いのですが、結局、ビジョンだけを提示して、そのあとの発展を聞かないのは気のせいでしょうか。Smart Planetはビジョン提示以上の展開を期待したいところですが、どうなるでしょうか。

さて午後は発表。いまひとつもりあがらない聴衆なのですが、当方に限ると質問が多かったのでウケはよかったのでしょう。やりにくい国際会議です。会場が縦長の上に聴衆の座席がコの字型の配置になっているので、講演者から聴衆の様子がみえないのです。

2010年7月1日

国際会議の一日目。シリコンバレーの端っこですが、いかにもシリコンバレー的なところ、つまりビルが点在しているだけで何もないけど、太陽だけで燦々と照りつけています。さて国際会議のキーノートスピーカもGoogleのVice President。この辺ではGoogleのVice Presidentって普通なのかと思ってしまう(それは絶対に違うけど)。ただ、国際会議はつまらないので、内職(Springerのジャーナルで条件付き採録になった論文の修正)がはかどります。それなりのレベルの海外ジャーナルだし、数日かかると思っていた仕事ですが、一日で終了。いいのかわるいのか。

2010年6月30日

サンフランシスコ郊外にあるOracleの本社でインフォーマルワークショップ。ちなみにOracleの本社はヨットの浮かぶ池の周りに全面ガラス張りのビル群。なかなかお洒落。今回の出張目的は国際会議への参加・発表なのですが、シリコンバレーの関係者に訪米を話したら、ポジショントークのスロットを用意していただいたというのが実状。実はインフォーマルワークショップのつもりで、出張直前に参加をお願いしたのですが、30人弱ほどの参加者の中には、GoogleのVice Presidentや米国ABBの役員まできていて、議論は極めて濃かったです(参加者の半分は内容的にプレゼン資料すらありませんでした)。わけあってワークショップの中身は書けませんが、技術の流れはシリコンバレーのこうしたインフォーマルな会合で決まっていくのだということを垣間みられた半日でした。というわけで到着早々、出張目的の95％ぐらいは達成した感じ。そうそう参加者数名がテスラロードスターで来られていて、初めてテスラロードスターをみました。

2010年6月29日

溜まりに溜まっていた査読をかたづける。某超難関国際会議の採録論文をベースにした難関海外ジャーナル版から、どうしようもない和文論文誌の投稿論文からまでいろいろ。国内学会の和文論文誌の査読もしたのですが、情報系に和文論文誌って必要なのですかね。情報・通信系の場合、特定の国や文化に依存する技術というのは少ないわけで、それよりも世界に発信した方がいいのにね。ところで電子情報通信学会や情報処理学会では論文投稿数が落ちているそうですね。海外への投稿が増えているというわけではなく、国内の情報・通信分野の研究コミュニティが縮小してきているのが背景のようです。情報・通信分野の研究者の一人として、国内の研究コミュニティは結構、まずい状態になっているのかもしれませんね。ただ、国内学会という組織の維持にパワーを使うぐらいよりは、個々に海外に展開した方がいいと思います。国内学会はその構成員である国内研究者次第ですからね。

2010年6月28日

午前中は慶大大学院の授業。実は喉の調子が悪い中での授業でさすがに辛かったです。

MapReduce/Hadoopが流行っていますね。分散システムのアプリケーションとして有用だとは思いますが、それ以上にMapReduce/Hadoopはメニーコアプロセッサに向いています。マルチコアプロセッサもコアが50個近くなると、コア間通信のコストも大きくなりますから、並列システムというよりも分散システムとして捉えた方がよく、MapReduce/Hadoopはメニーコアを活かすという点で有用です。というかメニーコアプロセッサといってもコア数は同じではないので、利用可能なコア数を最大限利用するという観点からいうとMapReduce/Hadoopはメニーコアプロセッサのキラーアプリケーションになる可能性があると思っています。

個人的な関心事はMapReduce/Hadoopの技術要素のうち、メニーコアプロセッサ上で実行したときに必要となる技術(と不要となる技術)だったりします。例えばファイルシステムもHadoopシステム全体がメニーコアプロセッサによってスタンドアローン実行される場合はノード故障やネットワーク分断の前提は大きく変わります。また、Zookeeperのような分散管理システムについても分散システムを前提とした一貫性制御は大幅に簡略化されることになります。例えばHBaseとCassandraが比較されます。そもそも一貫性や可用性はアプリケーション次第なので両者を同列に比較することがナンセンスだと思いますが、分散データベースに限らず、Hadoopまわりは長期的にはメニーコア化に向いている技術が生き残る可能性はありそうです。

これまでは逐次処理用プログラムをいかに並列化や分散化に頭を悩みましたが、これからは分散システムをいかにメニーコアプロセッサという並列システム上に展開させるかが重要になるのかもしれません。

2010年6月27日

先日、クラウドコンピューティングのセキュリティ基準に関する委員会(今回はどちらかというと事前準備委員会)に呼ばれたのですが、ある意味で日本のセキュリティレベルを反映する委員会でした。セキュリティ基準といいつつも、消防署の丸適マーク(防火基準適合表示)と同じ発想(実際、クラウド版の丸適マークとおっしゃる方もおられましたし)。確かにクラウドインフラに丸適マークを交付すれば、利用者がクラウドインフラの選択時のヒントになるかもしれません。しかし、それはセキュリティ・安全基準の一面にしか過ぎません（ちなみに丸適マークが最低限の防火設備が整っていることを示すだけで、安全とかは何もいっていない）。

例えば欧米では製造物などに対する安全基準が数を多く定められています。これは製造物などの安全性を高めることに寄与しますが、それと同時に、その安全基準をクリアしていれば使用者責任にもなるという免責範囲を規定していることなのです。つまりクラウドコンピューティングのセキュリティ基準を定めるということは、ユーザにクラウドインフラ選択の参考情報を与える同時に、その基準をクリアしているクラウドインフラで仮にトラブルがあっても、そのトラブルは免責されるという範囲を定めることなのです。法的な根拠とならないようなセキュリティ・安全基準を作っても、スローガン以上の意味を持たないと思うのですがね。

さて欧米は製造物の安全基準と同様に、クラウドコンピューティングのセキュリティ基準を制定してくるでしょう。クラウドインフラのセキュリティは運用に負うところが多いわけですが、先日も書いたように欧米は運用者にセキュリティ関連の有資格者を当てることで、インフラ事業者は仮にトラブルが起きてもセキュリティ管理義務を怒ったとして損害賠償されるリスクを最小化する戦略ですが、日本のクラウドインフラ事業者さんはそうした対策を立てる様子もない。

2010年6月26日

いまごろ気づいているのですが、Swing Journal誌が今月発売号で休刊になっていたのですね。休刊だからといって回顧特集でもなく、平常通り。ということは急に決まったのでしょうかね。Swing Journal誌は良くも悪くもモダンジャズに偏っていたし、それもDavis、Evans、Hancock、Corea、Jarretあたりの特集が毎年、ちょっとずつ形を変えて編集されている感じ。そしてレコード評も広告を出してくれるレコード会社に偏っていましたからね。同じ出版元のADLIB も4月に休刊になっており、Jazz系雑誌メディアは厳しいですね。両誌ともに休刊理由は広告が集まらなかったことだそうですが、レコード業界が不況ということもありますが、50年代、60年代のレコードを評価して、新譜を評価しないと市場は小さくなります。Jazzは大人の趣味を強調しすぎて、読者層の平均年齢が上がってしまったのかもしれません。

2010年6月25日

旧型のMacBook Proのリチウム電池が大きく変形。中のセルが3センチ以上、ふくれあがりました。ただし、使用中や充電中ではなく、本体から外してあったバッテリが膨らんで変形。化学反応のすごさを実感。ところで保証期間もとっくにすぎていますし、お取り替えはなさそうですが、このバッテリの処分はどうすればいいのでしょうかね。

2010年6月24日

夕方から久しぶりにクラウドコンピューティングにおける経済モデルの勉強会。そこでも議論になったのですが、いまのクラウドコンピューティングは大型のデータセンターを誇示している御三家はいずれも本業以外で儲けている状況。つまり、広告代理店(Google)、通販業者(Amazon)、ソフトウェアベンダー(Microsoft)。このため経済モデルといっても、クラウドコンピューティングに閉じているわけではない。逆にクラウドコンピューティングを本業にしているところはSalesforceにしても3000台程度(待機系を除くと2000台弱)と数が少ない。経済モデルとしてクラウドコンピューティングだけを取り出すことに意義があるかは別にして、クラウドコンピューティングにおける経済的合理性のある規模はあまり大きくないということになるのかもしれません。また、データセンターを建屋ごともつ場合と、借りる場合で話が違ってきます。個々のサーバの稼働期間と価格、稼働率の問題ですが、データセンターの建屋、サーバなど。クラウドインフラ事業者といっても、どこまで所有するかは問題。さて当方はというと「エネルギーから情報への変換器としてクラウドコンピューティング」というタイトルで話をしたのですが、その内容はまたいずれ。

2010年6月23日

ちょっと調べることがあって、ここ数日、SOSP'09、HotCloud'09、SOCC'10あたりのクラウドコンピューティング関連の論文をひたすら読んでいます。これまでに読んだ論文も多いのですが、(調べたい案件に偏っているとはいえ)まとめて読むといろいろ傾向が見えてくれるのも事実。いろいろな研究がされていますが、研究されていないことも多い。その意味ではテーマを見つけ方次第のところはありますね。ただ、何が足りないかはクラウドコンピューティングだけをみているだけだとわからないのも事実。結局、現状では分散システムなり、データベースなり、バックグラウンドのある研究者が有利な世界であることはいえそうです。すくなくてもいまは別の分野の研究者が各自の専門をクラウドコンピューティングに持ち込んでいる状態なのですよね。クラウドコンピューティングはユビキタスコンピューティングと似て、コアの技術があるというよりも、既存技術の統合技術とみた方がいいのかもしれません(現状では)。

2010年6月22日

打合せが多い一日。インターンシップ学生さんのためのテーマ選び(研究期間3ヶ月)。クラウドコンピューティングが希望だそうですが、基本的に研究テーマを考えるのは好きなのですが、人のテーマは難しいです。

ところで雑誌アサヒカメラを立ち読みをしていると、ライカがフィルムカメラを撤退という記事(正しくは数年前から作ってなかったそうです)。ライカといえば現在主流の35mm判カメラを創始者。そのライカがフィルムカメラをやめるというのは、時代の変化を感じさせる出来事ですね。個人的にはレンジファインダーカメラが好きということもあり、ライカ製レンズは2本ほど持っていますが、ライカのフィルムカメラボディとは縁がありません。その値段もさることながら、シャッターの最高速度が1/1000と遅いのが苦手で(NDフィルターを使えとかいわれるわけですが)、ボディはサードパーティ製(Zeiss IkonとMinolta CLE)でした。フィルムといえば先月、ヨドバシカメラの秋葉原のお店にいったのですが、フィルム売り場が大幅に縮小されていました。フィルムメーカーも撤収したところが多いですし、残っている製品も一部サイズが廃止になったりしています。やはり時代の流れなのでしょう。ちなみに当方も今年なってからフィルムカメラで写真は撮りましたが、考えてみるとフィルムは買っていませんでした。

2010年6月21日

早朝出勤、9時にはオフィスを出て、慶大矢上で授業。さすがに疲れていて調子が出ませんね。大急ぎでオフィスにもどってお仕事の続き。ともかく忙しいです。

ところで先週の出張で行ったGuimaraesの旧市街の写真をおきます。結局、会議中外出できたのは最終日の18時から19時までの1時間弱だけ。その間に撮った写真をここにおきます。写真枚数が多いですが、実はすごく小さい街です。そうそうページの後半に出てきますが、旧市街の広場にはワールドカップ出場国の国旗が飾られていました。その広場では子供達がサッカーに興じていました。

2010年6月20日

成田行きのANA便は満員でした。3時ちょっと前に到着。ホテルから自宅まで25時間強の長い旅路となりましたが、無事帰還。ANA便ですが、サービスの質を落としていますよね。まぁこんなご時世ですから仕方ないとは思いますが、まずは食事前の飲み物サービスでは飲み物の種類が激減し、おつまみがなくなり、二回目の食事の前の飲み物サービスもなくなり、二回目の食事はコールドミール。往路に至ってはメインなしにされたし。なんか食べ物の話ばかりですが、目に見えてサービスを落としていますね。それからエコノミー席には新聞もなし(そもそも食事は期待していないので、これが一番困るかも)。JALがこけたとはいえ、ANAも収支的には決して万全の経営とはいえないので、事情はわかりますが、寂しいかぎりですね。今月はサンフランシスコ出張が残っています。

隣の方がiPadを使っていたので、その使い方を横目でじっくり観察。いろいろなアプリケーションを動かしたり止めたり、じっくり見るのには向いていないデバイスなのかもしれません。まぁ、当方の回りで発売早々買った人は最近は起動していないというので目新しい分、飽きやすいのかもしれません。買って使ってから論評すべきですがね。購入するかは未だ思案中。個人的にはSIMフリーの新型iPhoneが欲しかったり。

2010年6月19日

開催地のGuimaraesから電車で1時間20分ちょっとかかって、Portoの中央駅(Porto San Bento)に出て、それから地下鉄で10kmほど離れたPortoの空港にに移動。のはずだったのですが、始発電車が大幅遅れてPorto中央駅についたのは飛行機の出発時間の55分前。結局、タクシーで移動して、40分前に空港に到着。かなり危なかったです。TAPポルトガル航空でParis Orly空港に飛び、Paris Orly空港から陸路をCharles De Gaulle空港に移動。Orlyの到着時間が12時半で、Charles De Gaulleの成田便の出発時間は20時なので、7時間半の空きがあることになります。ひとまずパリ市内に移動して、定宿に頼んで荷物を預かってもらう(実はパリはだいたいなじみのプチホテルに泊まっています。ホテルの犬にまで顔(におい？）を覚えられています)。それからCharles De GaulleでANAの成田便です。

さてANAの成田便ではプレミアムエコノミーへのアップグレードもかなわず、エコノミー席のまま。座席クラスには無頓着な方なので、狭いのは我慢できるのですが、シート電源の確保に失敗したのは痛い。

2010年6月18日

国際会議の最終日、当方は午前中に論文発表。そしてその論文はベストペーパーを頂くことになりました。ありがたいことです。ただ、びっくりしたのは出版社のSpringerが副賞でくれた書籍。その本は当方が一章分を書かせていただいた書籍。確かにこの国際会議の分野と重なっているからわからないでもですが、まったく冗談としか思えない、あり得ない展開。そもそもSpringerは書籍はいっぱいあるのにね。結局、Springerの方が気を遣ってくれて、別の書籍と取り替えてくれました。いろいろお世話になりました。ところでAmbient Intelligenceの研究は足を洗うつもりだったのですが、7月に開催される国際会議と、9月に開催される国際会議で、それぞれ招待講演があり、まだ数ヶ月は足を洗えません。

それから国際会議が終わったのが6時近く、それから旧市街の観光です。今回は忙しかったですね。開催地のGuimaraesですが、初代ポルトガル国王の出身地だそうで、ポルトガルという国の発祥地ということになっているそうです。実際、初代ポルトガル国王が生まれたという城の城壁が残っており、その城壁には「ポルトガル、ここに始まる」という書かれています。

2010年6月17日

国際会議の座長。昨日と今日の論文発表をみていると、きっちり実装・評価している研究と、プロトタイプ実装だけの研究に二分されていますね(前者は少数で大部分は後者なわけですがね)。それと両者では研究対象も方法も違ってきていますね。実利用に関わる研究者は、実利用で生じる問題の解決に焦点を当てていますが、プロタイプ実装だけで実利用しない研究は原理やアーキテクチャとか、機能拡張にご執心。ここで問題なのは、両者のギャップが広がりすぎて、議論すらかみ合わなくなってきていること。

ところで国際会議ですが、ヘルスケア絡みの研究ばかり。EUはEUの研究予算と各国の研究予算の棲み分けが進んでいますが、ユビキタス系でもヘルスケア絡みは各国支援。というのは医療保険は各国負担ですから、その負担を軽減することをねらって、ユビキタス絡みに予算を投下している国があります。実際にコスト削減があるかは微妙ですが、各国ともに医療費削減の結果、医療環境が下がっているといわれ、それをITで補完するのがが狙いだそうです。そのため欧州はユビキタスコンピューティングの研究をするにしても、デバイスを売るためとかではなく、単純に社会コストを下げるためなので費用対効果をしっかりみています。これが日本だと使えないデバイスか、誰でも思いつきそうな提案ばかりで、コスト削減としての研究は見かけません。むしろコストを増やす研究ばかり。例えばスマートルームの研究が流行りましたが、センサーを設置すればユーザの位置は補足できますが、1平米あたり数十万かかるようではコストに見合ったサービスを提供できるわけがない。看護ロボットの研究も重要だとは思いますが、コスト的には人間に頼んだ方がいいことになります。もちろんコストがすべてではないですが、費用対効果がない技術は普及しません。

2010年6月16日

ポルトから列車で1時間半ほど離れた田舎町(Guimaraes)の駅前ホテルで、Ambient Intelligenceの国際会議。今回は欧州のAmbient Intelligenceの主要メンバーが集まるので、欧州側の動向を見ておくというのが目的なのですが、論文発表をしないと出張費がでないのが辛いところ。というわけで当方の論文発表は最終日。会場から1kmほど離れた旧市街は世界遺産に指定されているそうですが、行く暇もない(最終日の会議が終わってからになりそう)。論文集は久しぶりに製本された紙製。日本では紙製論文集に批判的な方が多いのですが、PDF配布などにすると参加者はPCの画面ばかりみて、会議を聞かない人が多かったりしますが、会議への集中という点では紙製論文集は捨てがたいです。

2010年6月15日

飛行機でパリからポルトに移動。昼過ぎには到着です。空港から市内に出て列車移動なのですが、ポルトの市役所前には野外大画面が設置されて、大勢の人が集まっています。そう今日はポルトガル対コートジボアール戦。ということでトランクを持ちながら、ポルト市民の方といっしょに観戦です。ただ、ポルトガルの方には今日の結果は不本意でしたし、ちょっとファールの応酬になってしまった感じがあります。というわけで、観戦後は皆さん、ちょっと沈みがち。ちなみに今日はポルトガル語圏であるブラジルの試合があるとかで、夜はブラジル応援だそうです。せっかくなのでポルト市内を観光して、夜に国際会議の開催地のポルト郊外の田舎町(Guimaraes)に移動です。

今回の往路移動は2日かけたのですが、GuimaraesからPortoから電車で2時間以上かかり(空港からPorto中央駅まで)、日本から同日にPortoにつく乗り継ぎフライトは、到着は23時過ぎ。そしてPorto中央駅からGuimaraesの最終電車は20時ちょっと過ぎ(ルフトハンザのフランクフルト便なら間に会う可能性があったのですが、A380の就航で早々に満員でしたし、Porto中央駅への移動がぎりぎり)。事務系には2日間かかったことで怒られ、詳細な理由書を求められたのですが、移動時間を足し会わせればわかるように同日に着かないものは着かないです。

2010年6月14日

ANA便でパリ。出発が遅れたので、到着もやや遅れました。さて無茶苦茶ラッキーなことにビジネスクラスにアップグレードしていただく。でもよかったのは、一回目の食事の前菜を食べたところで、メインディッシュが品切れでとかで(他のメインディッシュもない)、軽食を進められる。実は食事を注文するときは食事サービスが変わったとかで詳細に説明いただいたのですが(変わるも何もビジネス席のサービスを知らないので)、肝心のメインディッシュはなしとなりました。まぁアップグレードしてもらっているので文句はいいませんがね。機内サービス低下はエコノミー席だけだと思っていましたが、ビジネス席も機内サービスもすごいことになっていますね。

2010年6月13日

国際会議(ACM Multimedia 2010)の投稿論文12本の査読。今回は査読に手間取りました。マルチメディアは専門ではない当方が、当該分野のトップ国際会議のプログラム委員なのかは不思議なのですがね。ただ、トップ国際会議のプログラム委員は辛い。査読する側の研究者としての能力を試されるし、実際、下手な査読をしたらこの業界から干されます。

このところACM MultimediaはYouTubeに代表されるWeb系の動画を使った研究が増えましたね。過去にはテレビ放送が多かったわけですが、テレビと違って、Web系の動画はタグなどの属性情報がついていることが多く、画像認識で頑張らなくてもよくなっていますね。ただ豊富な動画をあつめるという点でWeb系動画は有用なのですが、去年ぐらいからYouTubeに特化した論文が多くなりました。YouTubeは有力な動画ソースであることは間違いないですが、YouTube以外には使えなさそうな研究には辛口な点をつけるしかないです。

それとユビキタスコンピューティング系の研究と似た傾向というべきか、センシングデバイスを組み合わせる研究が多い。例えばGPSとカメラを組みあせてコンテキスト認識などね。こうした研究はセンシングデバイスが増えれば情報は増えるわけですが、問題はセンシングデバイスが増えるとエラーやノイズも増えてしまうことが多いということ。学術研究ではチャンピオンデータで済むのかもしれませんが、実用になるかはむしろエラーやノイズで決まります。組み合わせればいいというものではないです。個人的にe-Scienceにやや懐疑的なのもこの問題が背景があります。実験機材にセンシングデバイスを張り巡らせば情報量は増えますが、エラーやノイズも増えます。もちろん個々のセンシングデバイスのエラーやノイズは隣接する別のセンシングデバイスで補正することはできますが、補正の計算コストは半端ではないです。e-Scienceの方向性そのものは正しいとは思いますが、センシングデバイスをつければいいというものではないです。

それとACM MultimediaはAR絡みの研究が増えたのですが、AR系の論文をよくよく読むと、画像認識技術と3D技術の発展に頼っただけの研究が多く、ARとして何が新しいのかはわからない研究が多いです。その定番は空間にタグ付けするというもの。そのほとんどは空間の撮影画像からその空間に付けされたタグを見つけるかの研究なのですが、これはARというよりも画像認識の問題。認識精度が上がったと主張されても、それは使っている画像認識技術とプロセッサ性能のおかげで、その研究そのものの貢献がまったくみえない。ACM MultimediaはARの国際会議ではないので仕方ないのですが、ARそのものの問題を扱った論文が少ないですね。例えば不特定多数のによる空間へのタグ付けでは、多く人が訪れる空間にタグがつきすぎてしまって、有用なタグが見つけられないという問題がありますが、現状はタグをつけるところで終わっています。それといつも思うのですが、ARは分野としては新しいのですが、ARのアプリケーションはAR聡明期と変わりませんね。さすがに物理世界に3Dアバターが浮かぶとか(日本から投稿に特に多いような気がします)は卒業して欲しい。もっとも新しいARアプリケーションならば研究よりもSF小説やSF映画の方がよっぽど進んでいますがね。

なお、上記は当方が直接査読した論文の傾向というわけではありません。当たり前ですが査読論文の内容には守秘義務がありますから。

2010年6月12日

Photoshop CS5をインストール。写真修正機能が増えましたが、宣伝通りにすごいです。特に職人技的な切り抜き処理が簡単できるようになっており、この技で食べていた人の職を奪うことになりそう。ただ、機能が強力すぎて使いこなしは難しいそうです。

2010年6月11日

いよいよ始まりました。しばらく仕事が手に付かなくなります。困りましたね。でも楽しみたいと思います。

2010年6月10日

ワールドカップは明日から開催ですが、なんか盛り上がりませんね。先日、某受業で学生さんに聞いたら、ワールドカップが今月開催を知らない方もちらほら。Jリーグ以前の状態に逆戻り。ちなみに勤務先のラテン系留学生さんたちは盛り上がっていましたがね。このページの昔からご覧の方は御存知かもしれませんが、試合を観に行ったり、決勝で負けたドイツ人サポートの集団に囲まれて欧州に行ったとか(機内でずっと泣き通し)、ドイツ大会では決勝戦のドイツに行ったりと、フランス大会では直後にフランスに行りとワールドカップ絡みはいろいろ。

2010年6月9日

これまで献本していただいても、このページでは書評は書いていなかったので、「クラウドセキュリティ＆プラバシー」(オライリー)というタイトルの非常に重要な書籍を送っていただいたので、紹介することにします。セキュリティの話になると技術論だけになりがちですが、この書籍は企業ガバナンスを含めてセキュリティの問題を解説しています。結局、企業の情報システムのセキュリティは技術だけの問題ではなく、企業の情報管理ポリシーに関わる問題なので、技術的な問題だけを議論しても仕方ないのですから。

この書籍でも紹介されていますが、企業の情報システムではISO 27001/27002という国際標準が重要な意味を持っています。少なくても企業として、このレベルのセキュリティ管理の認定を受けていないと話になりませんが、日本ではまだまだ認識が低い。それと海外ではこうした認定というのは、この認定を満足していれば、その認定がカバーできないセキュリティ問題に対する免責理由になる場合があり、企業のセキュリティレベルを示すとともに、法的問題が最小化するために重要です。しかし、こうした認定制度についてクラウドコンピューティングと絡めて説明している書籍は他にはなく、一読の価値があると思います。

ただ、残念だった部分もあります。それは企業に対する認定制度の説明は詳細にあるのですが、管理者のセキュリティ資格制度の説明がないことです。最後は技術や組織ではなく人なので。せっかくですから、ここで少し解説をしておきます。

海外には管理者向けの複数のセキュリティ絡みの資格制度がいくつかあり、大手データセンターの管理者や、企業や政府の情報セキュリティ担当者になるにはこうした資格を持っていることが前提になっており、実は海外クラウドコンピューティング事業者が日本にデータセンターを作らない理由でもあります。セキュリティに関する資格制度ですが、米国だったらCISSP (Certified Information Systems Security Professional、セキュリティシステムプロフェッショナル資格制度)が有名どころ。大手企業や米国政府やセキュリティ関連業務の社員・職員に資格取得を義務づけているところが増えています。この他に実務重視のGIAC(Global Information Assurance Certification、グローバル情報保証資格制度)などがあります。欧州だったらCEH(Certified Ethical Hacker、倫理的ハッカー資格制度)やCHFI(Computer Hacking Forensic Investigator、ハッキング犯罪科学資格制度)あたりでしょうか（ちなみにセキュリティホールを見つけてはそれを公表している方々は、高い倫理観要求されることから、例えばCEHやCHFIあたりの資格をもっていると信じたいですが、どうなのでしょうか）。

セキュリティの資格をもった者が管理すればセキュリティ問題が起きないということはないのですが、管理者のクオリティ維持には有効な方法です。実際、上述の資格の多くは有効期限も短いことから、管理者は日々勉強することになります。また、管理職にも資格取得を義務づけている会社もあります(噂ですが、HPのデータセンター管理者の解雇騒動では無資格管理者がターゲットになったとか、真偽は知りませんがね)。ちなみに資格の受験料は10万円近いものもあり、事業者が自らのセキュリティ要件を維持するために受験料を肩代わりすることが多いです。逆に言えばそうした人材を揃えないとデータセンターとしてやっていけないということ。

実はこうしたセキュリティ関連の資格が重要になるのは法的問題がおきたとき。というのは大型データセンターやクラウドコンピューティング事業者において、情報漏洩などの何らかのトラブルがあった場合、その賠償請求裁判では必要なセキュリティ管理を行っていたのかが焦点になります。そのときに、これらの資格をもっていない管理者にセキュリティに関わる情報管理をさせていたりしたら、その事業者はセキュリティ管理義務を怠ったとして、多額の損害金を請求されることがあるのです。それはデータセンターを利用するユーザ企業も同じです。無資格者によって管理されているデータセンターにデータを預けていていて、何らかのトラブルがあったときは、そのユーザ企業にも賠償請求がされることがあります。

さて日本には海外で認められるセキュリティ関連の資格を持っている人は非常に少ない。これは日本のデータセンターが海外企業から使われないことや、海外クラウドコンピューティング事業者が日本にデータセンターを作らないこととも深く関連しています。というのは仮に海外企業が日本のデータセンターを利用したとして、仮にそのデータセンターに関わる情報漏洩などのトラブルが起きた場合、そのデータセンターの管理者が無資格者だったりしたら、そのデータセンターだけでなく、利用者である、その海外企業もセキュリティ管理義務を怠ったとして、多額な損害賠償請求がまわってきてしまいます。また仮に海外クラウドコンピューティング事業者が日本にデータセンターを作ったとしても、セキュリティ資格をもった管理者を日本で集めるのは難しいでしょう。実際、海外クラウドコンピューティング事業者に関しては管理者は複数のセキュリティ資格をもっていることは当然として、身辺調査をしており、彼らの要求を満足する人材を多くないそうです(逆に言えば海外の大規模データセンターの管理者数が異常なほど少ないのは、コスト削減もありますが、その裏には条件にあった管理者の確保がたいへんなのです)。

最近、某省で国内データセンターの振興策が提案されおり、その報告書では国内に巨大データセンターが作られない理由して、電気代が高いとか、建築法の問題とかがあげられていました。むしろ海外クラウドインフラ事業者が日本にデータセンターを作りたがらないのは、前述のようにセキュリティ関連の資格をもっている管理者が少ないことも背景のひとつになっています。つまり海外企業が日本のデータセンターにデータをおいた場合、無資格者に大事なデータを任せることになり、法的なリスクが高いのです。

ちなみに、その報告書には海外セキュリティ資格に関する説明は一切ありません。こうした一番肝心な理由をスルーしている限り、データセンターの振興もクラウドコンピューティングの振興もできるわけない。そして、この状況で仮に大規模データセンターを日本に構築しても、それを利用するのは無資格者にデータを預けることを厭わない日本の企業だけです。また、国内では海外データセンターにデータを置くことを不安に感じる企業が多いわけですが、有資格者で管理される海外データセンターと、そうではない管理者によって管理されることがある国内データセンターのどちらが安全なのかを冷静に考えて下さい。

2010年6月8日

午前中は講演、これで講演ウィークはひとまず終了。午後はインターンシッププログラムでフランスからやってきた学生さんへの対応。

2010年6月7日

AppleがiPhone 4を発表しましたね。たしかにiPhoneというハードウェアとしては新味に欠けますが、周辺サービスを隙なく埋めてきた感じ。逆に言えばiPhoneというハードウェアをサードパーティに任せても、Apple及び開発者は儲けられるだけの仕掛けを用意しました、というのが今回のJobsの講演の趣旨だったように思います。だからといってAppleがすぐにiPhoneというハードウェアを他社にまかせることはないでしょうが、少なくてもハードウェアだけを見ていたらダメな時代になっていることは確かでしょう。

Appleまわりの次の関心事は建設中のデータセンターを使って、どんなサービスを展開してくるかだと思います。ただ、Appleがクラウドコンピューティングを使ったサービスを展開するのは正しい戦略だと思いますが、Apple自らデータセンターを建設・所有するメリットは正直いってはかりかねています。ありえるとするとGoogleとの仲たがいが今回のデータセンターの建設と関係しているのではないかと勝手に邪推しています。あと中途半端なままになっているApple TVが大化けする可能性もありますね。

2010年6月6日

講演で話題になったのですが、クラウドコンピューティングではSLAに示された可用性の大きさ、例えば99.9％だとか、99.95％だとかが話題になります。しかし、SLAの可用性を気にして意味があるのでしょうか。現状ではSLAの可用性は高い数字を言った者勝ち。何らかのトラベルでシステムが止まってしまっても、せいぜいトラブル期間中の利用料を返せばいいわけで、その程度のペナルティだったら、嘘でもいいのでSLAに高い可用性をあげて、ユーザを多く獲得した方が合理的な営業戦術となってしまいます。何を言いたいのかというと、SLAはあくまでも参考程度の情報と思うべきで、SLAの可用性を鵜呑みにしてはいけないし、SLAの可用性でインフラを選んでも仕方ないということ。

2010年6月5日

3日連続で大勢聴衆の前で1時間講演はありがたいのですが、連日で続くと辛いものがありました(昨日は講演はありませんでしたが、オープンハウスのポスター説明)。喉をすっかり痛めてしまいました。ただ、来週も一件残っています。

ところで週刊ダイヤモンドの今週号の「ゼネコン落城」という特集記事を読んでいたのですが、内容はもちろんゼネコン業界のことですが、その状況は国内IT業界そのもの。例えば少数の事業者を頂点とする多重下請け構造も同じですし、下請け叩きの構造も同じ、国内市場に特化しているのも同じ、人材不足も同じ、長時間労働も同じ、そして仕事がなくなると行政案件に群がるのも同じ。明日の国内IT業界を占うためにも興味深い特集でした。

2010年6月4日

勤務先の研究所オープンハウスの2日目。今日はポスター説明係。途中、1時間ほど変わってもらいましたが、それ以外はだいたい立っております。今日も大勢の方においでいただきました。まことにありがとうございます。

ところでオープンハウス中、RDBMSと非RDBMS(いわゆるNoSQL)について聞かれたのですが(ポスターとまったく関係ないのに)、個人的には比較すべき対象ではないと思っています。非RDBMS系に一貫性を導入するのも、RDBMSもどきの非RDBMSにJOINオペレーションなどの欠けた演算を導入するのは研究的にはチャレンジングですが、実需要には疑問を持っています。むしろRDBMSについてその内部処理を工夫して、大規模データを扱えるように改良した方がいいのではないでしょうか。そして非RDBMS系システムに無理に、一貫性制御やフルSQL演算を入れたとしても、スケールアウト性を含む性能的優位を失う結果になりかねません。むしろ、非RDBMSには、RDBMSが苦手な部分を伸ばしてくれた方が健全だし、非RDBMSのアプリケーションもその機能制限を許容できるもので使った方がいいです。

2010年6月3日

勤務先の研究所オープンハウスで基調講演。もうすこしコンパクトに話せばよかったと反省です。ちなみに講演スライドをWebにおいておきます。かなり大胆なことをいってしまいましたが、結構、本気だったり。スライドをご覧いただくとわかると思いますが、コンピュータサイエンスには興味がありますが、コンピュータとか、計算とかにはもう興味がなくなりました。そしてコンピュータという狭い世界にとどまっていてはいけないだと思っています。

2010年6月2日

霞が関でクラウドコンピューティング関連のセミナーで基調講演をさせていただきました。当方含めて4人が講演したのですが、他の3人方の講演は非常に興味深いし、本当に勉強になったセミナーでした。クラウドコンピューティングのセミナーはベンダーの宣伝か当たり前のことを話すだけのがっかり講演が多いのですが、今回はよかった。本当によかった。

ところで当方の講演内容は、クラウドコンピューティング向けのサービス開発だったのですが、同じソフトウェア開発でも既存システム向けとクラウド向けが決定的に違うのは、後者は納品するのはソフトウェアではなく、サービスであり、そのサービスは従量課金であるということ。既存システムでは仕様書通りにソフトウェアを作って納品することになりますが、その対価はソフトウェアの規模に比例するために大規模なシステムやソフトウェアの方が売り上げが伸びました。そのためコード量や人月計算による見積となりますが、クラウドでは提供されるのはソフトウェアではなく、(ソフトウェアを実行した結果である)サービス。だからソフトウェアの規模は無関係。そもそも仕様書もなくなるかもしれません。サービス提供者はユーザのニーズを汲み取ってサービスを開発・提供することがのぞまれます。だから仕様通りに作ることを求められてきた開発者にとっては、考え方が根底からかわるし、生き残れない人も多いでしょう。簡単に言うと、これまでのソフトウェア開発がプル型ビジネスモデルならば、クラウドの時代ではプッシュ型ビジネスモデルになるということです。

また、従量課金になると、ビジネスモデルもかわりますし、ソフトウェア開発も一変します。従量課金ではユーザは使った分だけお金を払うとともに、使えないサービスなら利用をいつでもやめればいい。そうなるとサービス提供者はユーザがサービスの利用をやめないように様々な対策を立てる必要があり、一番いい方法は常にサービスを改良し続けて、ユーザが逃げないようにしないといけません。そうなると何が起きるかというとサービスの開発というか、改良の期間は長期化するということです。その場合、長期間にわたって改良ができる体制・開発手法が必要となります。

クラウド向けのサービス開発というとアジャイルを候補にあげられる方がおられます。しかし、クラウド向けのサービス開発では短期開発だけでなく、持続可能な開発が必要なのです。たしかにアジャイルは仕様書の開発案件には向くかもしれませんが、人に依存した開発手法なので、改良期間が長期間にわたり、ある程度、人が入れ替わるような状況に向くとは思えません。アジャイルにしても開発手法の世界は、宗教というか、イデオロギー的なところがあり、少しでもネガティブな意見をいうとつるし上げられる怖い世界なので、これ以上の議論はやめておきます。しかし、個人的には持続的開発にはそれにあった開発手法や体制が必要になると思っています。

上記は今回の講演はごくごく一部。それ以外は参加していただいた方だけの情報ということにしておきます。

2010年6月1日

汐留方面でクラウドコンピューティング関連の講演。今日から8日間に4回の講演があります。全部内容が違うのがつらいところ。

さて本日をもってサン・マイクロシステムズは日本オラクルの子会社に吸収されたそうです。ひとつの時代の区切りですね。ただ、メディアで話題になっていないのですが、プレスリリースもなかったのでしょうか。ちょっと寂しさを感じます。通勤でサン・マイクロシステムズの本社があった最寄っていたので、朝などに社員さんによくあったりしていました。

2010年5月31日

朝方までお仕事、そのまま午前中は授業。あわててオフィスに移動してお仕事、お仕事。どうなるんでしょうか。そうそう6月3日と4日は文科省内の事業仕分けだそうです。勤務先的にはいろいろ影響があるようです。

2010年5月30日

今日も休日出勤。いよいよ法定休日数のクリアがまずくなってきました。さてさて6月3-4日は勤務先のオープンハウスだそうです。研究所創立10周年の記念イベントだそうです。例年と何違うのかはどうかはしりませんが、大所帯の研究所ですから、いろいろ見られるのではないかと思います。ということで以上、職務上の宣伝でした。職務は別にして、勤務先に関わらず、研究所のオープンハウスは専門でない方でも、未来を感じられる機会ではないかと思います。

2010年5月29日

休日出勤中。某社のお別れ会にでたのですが(社員さんではなく買収により某社がなくなるという意味)、iPadの自慢の集いと化しておりました。がまんしているのですから、そんなに自慢しないでください。それはさておきユーザが新しいジャンルの製品を買うのは、その製品が欲しいのではなく、製品による自分のライフスタイルや業務への変化が欲しくて製品を買います。その点でAppleはなんか変化させてくれるという期待感の与え方がうまいです。ただ期待以上の変化がおきないと急速に販売台数が下がることになりますが、すくなくても現状では自慢ネタ以上の用途がないようですね。というわけで今回は大人の対応とさせていただき、初期購入者の利用状況とiPadによる変化を見極めてから買いたいです。

2010年5月28日

某電子行政システムと格闘。某省や勤務先の事務まで巻き込んでしまったわけですが、どうもみても某電子行政システムの不具合。同じユーザが同時に二つ以上のWebブラウザでアクセスすると破綻する模様。こうした商売をしていると不具合のひとつをとっても、某電子行政システムの裏側にあるサーバというか、そのソフトウェアを作った方々の設計方針やスキルが透けて見えるのですよね。民間のサービスではありえない水準。電子行政について高尚な理念を語る人は多いわけですが、現状のシステムは理念に以前に技術水準が低いわけで、まずはそこからなんとかしないといけないのでしょうね。

2010年5月27日

明日はいよいよiPadの発売ですね。現状ではとっても欲しいけど、いまは無理かなぁ。それでひがんでいるわけではないですが、実はiPadそのものよりも、iPadが与える影響の方に興味があります。わかりやすい例はカテゴリが重なるタブレット型ネットブック市場を食うことになります。ただ、個人的に興味があるのはPCやサーバの端末としてiPadが使われたときの影響。例えばiPadでVNCやCitirixなどの仮想デスクトップを使って、オフィスや自宅のPC側の画面を表示・操作することできます。そうなるとPC側には画面や操作デバイスはいらなくなり、純粋にプロセッサやメモリ、ハードディスクが入った筐体だけがあればいい。AppleでいうとMac miniがようなPCかもしれません。またApple TVがiPadの母艦として復活する可能性もあるでしょう。いずれにしてもPCの前に座るというのはなくなるのでしょう(そもそもPCはユーザの従であるべきなのに、ユーザがPCの従になっているという異常な関係でしたから)。

ただ、そうなるとPCの画面表示・操作用デバイスである必然性はなく、クラウドコンピューティングに直接つなげばいいということになります。その意味ではiPadのような画面表示に特化した端末の登場は、長期的にはPCというカテゴリは無くしてしまうのでしょう。

もちろん、これまでにもシンクライアントの試みはたくさんありました。ただ、ダム端末というかシンクライアント以外は使えない端末でした。しかし、iPadの場合は(サーバ画面をみる仮想デスクトップともいえる)Webブラウザがあり、DRMなどの機能があると話は違ってきます。

2010年5月26日

実は知らなかったのですが、5月25日はJavaの15周年だったそうです。まぁなんだかんだいっても、この20年間で一番成功したプログラミング言語というのは否定できないと思います。開発者の数という点ではいまでも一番多いかもしれません。当方自身もJavaでいろいろプログラムを書かせていただきました。一日遅れだけど、15才のお誕生日におめでとう。

2010年5月25日

わけあってHadoopのなかでもZooKeeperのお勉強。ZooKeeperのアトミック(原子)ブロードキャスト機構を中心に調べることになりました。ZookeeperはPaxosの亜流を使っているということになっているようですが、それを含めて内部実装に関わる資料が少なくて、中身の仕組みも性能もいまひとつわからない。まぁソースを読めということなのでしょうが、ソースからは性能的な部分はよくわからないのですよね。

ところでちょっとだけ補足。分散システムにちょっと知識がある方にとっては常識中の常識ですが、Paxosのような同意プロトコルとアトミック(原子)ブロードキャストには深い関係があります。分散システムに詳しくない方向けに説明しておくと、同意プロトコルとは分散システム上の各ノードが同じ値を持つようにする仕掛けなのですが、この値の代わりに各ノードにおいて到着した複数メッセージのうち、特定のメッセージだけを受理するように読み替えると、各ノードが同じメッセージを受信するとみることができます。そして複数の到着メッセージに対してどのメッセージを受信するかの同意を次々行っていくと、それはまさにアトミックブロードキャストを実現しているのと同じになります。ちなみにPaxosも同意プロトコルですから、Paxosでアトミックブロードキャストが実現できるわけですが、さらにクラッシュ故障にも対応することができるようになり、Paxosによりすべてのノードがある一つのノードをリーダとして選べば、過半数以上のノードが正常に動いてれば、メッセージの受信順受は一意に定まるようになります。もちろん、Paxosのような3フェーズプロトコルが効率的なのかは別の問題ですがね。

2010年5月24日

午前中は慶大大学院の授業「計算モデル特論」。かれこれ10年近く担当。当初は清く正しくλ計算や型付きλ計算を中心に教えていましたが、検証ばかり教えた年や、最近はプロセス計算(Process Calculusが多いかも。ただ、計算モデルは哲学的な部分があって、答えがないというか、計算モデルを設計した人の関心事や性格が表れやすい。それはさておき計算モデルはつまるところは抽象化。システムの一部の様相をみるために、それ以外を捨てること。計算モデルを使うと、複雑に入れ組むシステムに埋もれている原理や様相を浮き上がらせてくれますが、それは複雑なことを簡単にしているのではなく、複雑なことを隠してわかりやすく見せてくれるだけ。クラウドコンピューティングの計算モデルが話題になっているようです。ただ、計算モデルがあると見通しはよくなると思いますが、一貫性制御などの難しい問題が解決するわけではないでしょう。それと計算モデルはシンプルが一番。計算モデルを複雑にすると複雑なシステムも記述できるようになるかもしれません。しかし、計算モデル自体が複雑になって、何を記述しているのかがわからなくなります。例をあげると1990年前後にマルチパラダイムという言葉のもとに、相違なパラダイムの計算モデル、例えば関数型の計算モデルや論理型の計算モデルの融合が流行りました。たしかに元となった二つの計算モデルでは扱えなかった様相を扱えるようになりましたが、融合した計算モデル自体が複雑になってしまい、1995年ぐらいにはすっかり聞かない言葉になりました。クラウドコンピューティングは複雑なだけに、何を表現したいのか、何を表現しないのかを整理してから計算モデルを設計しないと過去の失敗を繰り返すことになります。複雑にしたり難しくしたりすると、研究的には一見すごそうにみえますが、いい研究というのはシンプルだと思うし、わかりやすいはずです。

2010年5月23日

何人かから、このページにGoogle IOについて書いていませんね、といわれたのですが、正直いって、忙しすぎてそれどころではありませんでした。ただ、期待を裏切ってはいけないので少々。GoogleとVMwareの提携ですが、先日のSalesforce.comとVMwareの提携でも思ったのですが、Sun MicrosystemsにいたJava関連の技術者が、OracleによるSun Microsystemsの買収前後でSun Microsystemsにいた技術者が大量にやめていて、その連中が裏にはいるのだろうのでしょう。もちろん推測ですがね。いずれにしてもSun Microsystemsには優秀なエンジニアが多かったし、Javaも優秀なエンジニアを集めていました。その連中のいまどこにいるかというのは、技術動向、業界動向を予測する上ですごく重要なのですよね。

2010年5月22日

久しぶりに休日です。土曜日なので当然なのですが、裁量労働制にもかかわらず休日出勤が常態化しております。研究者といえども、効率的に仕事ができる人、時間の使い方がうまい人以外は生き残れない時代かもしれませんね。

2010年5月21日

本当に17日に公開されていましたが「クラウド時代のSIビジネス」という昨年10月に日経コンピュータに書いた解説のWebに公開されてました。さすがに半年前だと古い部分もあるにはありますが、おおかたはいまでも通用する内容ではないでしょうか。逆に言うとこの半年は本質的な変化はなかったのかもしれません。ブームといわれる技術は参加者も観客も増えるので、一見発展しているようにみえますが、実はブームになったころにはすでに停滞していることが多いのですよね。クラウドコンピューティングもその状態なのでしょう。

2010年5月20日

眠いままお仕事。秘書さんに手伝っても時代錯誤的な作業。それにしてもITとは何だったのかを考えさせられる一日となりました。

2010年5月19日

出張からそのままオフィスに戻って、徹夜残留仕事。この4日間の睡眠時間は5時間ぐらい。眠いとかいってられるわけもなく、お仕事。

話は突然かわって、CAP定理のこと。というのはここ1ヶ月ぐらいCAP定理について聞かれることが多いので。分散システムにおけるPartitionが話題になっていますね。CAP定理のPというのはPartitionのことですが、正しくはNetwork partitionのこと(もっと正しくはTolerance to network partition、つまり耐ネットワーク切断性)。文字通り通信切断なのでネットワークが分断された状態をさします。CAP定理のようにデータ多重化や一貫性制御の観点では、Network partitionというのはネットワークというコンピュータのグループが、通信故障などによって複数のサブグループに分かれてしまって、(1)個々のサブグループ内でデータ参照などができるか、(2)サブグループが再び一つのグループに戻ったときにデータの一貫性をどう保証するかのこと。ここで(1)はデータ多重化と配置の問題で、どのようにオリジナルデータと複製データを配置すればネットワーク分断に対応できるかという問題になります。(2)はネットワーク分断がおきると、分断されたネットワーク内でデータ参照・更新が行われるわけですが、それが再び統合されたときに、分断中は個々の分断ネットワークごとにデータ更新が行われているので、その更新をどのようにマスターデータに反映させるのか(または互いに反映させるのか)、つまりリカバリー処理をどのようにやるかが問題になります。

ネットワーク分断のリカバリーは難しいのですが、それが本当にたいへんになるのは２つ以上のネットワーク分断が起きた場合、つまりネットワークが３つ以上に分かれてしまった場合です。例をあげると、何らかの理由でネットワークで2つの分断が起きてしまって、3つのサブネットワークに分かれたとしましょう。そしてほぼ同時に二つの分断が回復したとします。そうするとリカバリー処理が二つ同時に動く可能性がでてきます。３つのうち一つは同時に二つのリカバリー処理の影響をうけることになります。しかし、リカバリー処理というのは例外的な処理なので、暗黙に排他的に実行される、つまる複数のリカバリー処理は同時に動かないことを暗に仮定している、または複数のリカバリー処理は同時に動く状況を想定せずに設計されていることがあります。しかし、複数のネットワーク分断がほぼ同時に回復するというのは例外的な状況ではなく、例えばネットワークスイッチの故障・回復では結構おきうる状況ということをお忘れなく。

2010年5月18日

出張で修善寺方面。日曜と月曜とほぼ貫徹二晩のあと、泊まり出張。意外に眠くならずに会議。情報を共有するにはこうしたイベントも重要ですね。

2010年5月17日

実は徹夜明けのまま慶大大学院の授業。授業というよりも業界動向などの雑談ばかり。ちょっと反省です。

ところで、最近、思うところがあって業界向けの勉強会に参加してみています。ここのシステムやソフトウェアを知るには論文を読むよりも勉強になりますね。すくなくても国内学会よりもアクティブだし、下手な研究会や全国大会よりも技術水準は高かったりします。個人的にはなぜ流行っているかに興味があったり。個人的な推測ですが、ソフトウェア分野に限るとオープンソースと関係があるのでしょうね。商業ソフトウェアの場合はソフトウェアベンダーが販促やサポートのために技術セミナーを開いていて、それに参加すれば勉強ができたわけですが、オープンソース系のソフトウェアの場合はそうしたセミナーはない。そうなると自主的に勉強するしかない、でも一人で勉強はたいへんなので、勉強会という流れでしょうか。それと商業ソフトウェアの技術セミナーに参加される方は、ある意味で職務命令として参加していたわけですが、勉強会の方は企業の枠を離れて自主参加。勉強しようと思う人はいろいろ勉強できる時代。でも逆に勤務先の指示で勉強していたような、受け身の方は確実に取り残される時代なのでしょう。また、商業ソフトウェアを作っている企業側も、自社の技術セミナーだけでなく、勉強会で積極的に説明できないと技術者にリーチできない時代になっていますね。

2010年5月16日

先週末に引き続き、土日と出勤。今月は連休があったというの法定休日数(4週間に4日の休日)を満たさないと人事部門から怒られます。国研の研究者は暇だと思われているらしいのですが、内実はいろいろお仕事があります。大学と違って霞が関方面の無茶振りもあるしね。

ところで出勤途中の地下鉄で往年のPentax 67(それもフル装備)を首からぶら下げたおじいさんを目撃。一度だけ持たせてもらったことがありますが、カメラ本体だけでも2kgぐらいあったはずですが、いったい何キロを首からぶら下げているのやら。Pentax 67はブローニー(120タイプ)のロールフィルムですが、富士フイルムはプレスト400のブローニー版を打ち切るとか。個人的には中判カメラは縁がないのですが、フィルムはいよいよ終焉になってきました。35mmだけど期限切れのプレスト400が2本ほど残っているので使わないとね。実はオフィスにフィルムカメラ3台隠し持っています。

2010年5月15日

先日、パロマ工業の不良製品問題の話を書いたら、なぜか大勢からお問い合わせをいただく。それも企業関係者と大学関係者で意見が正反対。前者は、パロマのケースは事故対応に問題があったケースだけど、今回の判決が今後の製品事故においてメーカの責任はひろくみられるのが怖いというご意見。後者はオープンソースは善意の公開だから、それを見た人の不利益は自己責任だというご意見。今回の仮説はというと、製品でオープンソースを使っていて、そのオープンソース側に製品改造に有用な情報が載っていて、その情報を使って不法改造されて、それによって事故が起きたという設定。オープンソースのライセンスで免責事項と書いてあるのは、不要な裁判を抑止するためであって、実際、裁判になったら、免責主張ができるとは限らない。今回、例に挙げたパロマのケースではそもそも不正改造は製品本来の利用とは離れているわけですから、メーカにとっては免責範囲のはず。しかし、裁判では社長が業務上過失致死傷で有罪となりました。仮に免責事項を振りかざして裁判を切り抜けられても、市場へのダメージは小さくはない。そして最後に問われるのは「メーカとして最善の努力をしたか否か」なのですよね。パロマのケースでは、不正改造を積極的に止めなかったことが判決理由になっているようです(長文なので全部を読めてません)。

2010年5月14日

外出が多い一日。朝から台東区、港区、江東区、千代田区と移動。オフィスに戻ってきたのは21時。国研の研究者といえども部屋にこもって思索にふけっていればいい時代でもないので、仕方ないのですよね。

一昨日の見本市では基調講演では、併設された見本市ではまったく同じ時間にSalesforce.comのBenioff氏の講演がありました。当方はぶっつけ本番で講演しましたが、Benioff氏は朝7時に会場入りして、リハーサルをしたそうです。ちなみに海外企業の役員は公演前の会場リハーサルは珍しくないし、周到に準備をしてくるのが当たり前。ただ、それを表に見せない(先月、Benioff氏の講演は間近で拝見したことがありますが、どちらかというとテクニックより熱血漢で行くタイプ)。例えばAppleのSteve Jobs氏はプレゼンのうまさで定評がありますが、おそらくスタッフとプレゼン内容を相当吟味して、何回もリハーサルしているのでしょう。ここで気になるのは日本の企業は役員さんたちはプレゼンするときにどれぐらい準備をしているのでしょうか。最近、某国内超大手コンピュータメーカの社長さんの講演を拝聴させていただきましたが、日本語の講演でも原稿を読み上げるだけでした。たぶんこのあたりから変えていかないと海外における国内企業のプレゼンスはあがりませんし、そもそもそんな社長さんには社員さんがついてきませんよね。

2010年5月13日

昨日の講演で話したのは、簡単に言うと「RFIDタグはモノに貼るのではなく、情報に貼るべき」ということ。いいかえると、RFIDタグは情報のように実体のないものを実体化するための技術。すでに実体のあるモノに貼っても意味がないとまではいいませんが、やっぱり効果は半減なのですよね。今回の講演はそれを発展させて、RFIDタグを情報としてだけでなく、経済価値として扱うための方法を説明しました。講演時の依頼が「グリーンテクノロジー」と絡めて欲しいということで、RFIDによる排出権の有価証券化にターゲットを絞りましたが、お話しした内容自体は販促ポイントでもクーポンでもいい。

それとRFIDタグは他の人と交換したり、ためることもできます。講演では明示的にはいいませんでしたが(スライドではありましたが)、これはRFIDタグが貨幣になるということ。貨幣は３つの基本要素、つまり経済価値、交換の媒体、蓄財の機能をもつことが求められますが、経済価値を表すRFIDタグというのは貨幣化する可能性があるということです。これを貨幣なんて簡単に作れるものではないとかいわれます。そうしたことを言い出す方は販促ポイントやクーポンの貨幣化などを想像されるようですが、視野が狭いですよね。確かに貨幣になりうる価値を新規に作るのはすごく難しいことかもしれませんが、上述の排出権のように経済価値をすでにもっていながら、貨幣としての機能が欠けていた経済価値は結構あります。そうした経済価値に貨幣としての機能を持たせるときにRFIDは有効な道具立てになります。それと必ずICカーではダメですか、と言い出す人がいます。もちろんICカードでもいいと思いますが、問題は交換媒体として使うときICカードはインフラが必要なのが問題。

いずれにしてもその先の話は講演に参加された方だけの特権ということですね。もっとも、よくよく考えると基調講演にしては話がぶっ飛びすぎていましたね。ちょっと反省です。

2010年5月12日

午前中はRFIDの見本市の基調講演をさせていただく。事務局によると基調講演の聴講者数は受付のカウントで800人をこえたそうです。講演中、演壇から眺めさせていただいていても大勢の人が来られているのがわかりました。実は夜はRFIDやバーコードの業界団体のパーティだったのですが、そこでも参加者数が話題になり、RFIDがブームだったときを含めても、RFIDの講演では最大の聴衆数だろうとのことでした。RFIDのブームが去ったなかでこれだけの人数が集まるというのは、RFIDもやっとビジネスとして成り立ってきたということでしょう。

見本市の方は時間がなくて15分ぐらいの滞在時間となりましたが、企業の展示ブースではいつものように「RFIDって、よくわからないんです」という枕詞いってから説明員さんから説明を求めたのですが、さすがに怪訝な顔をされてしまいました。さすがに基調講演をすると素人ぶり作戦は通じませんね。

2010年5月11日

今日は湯沸かし器などのガス器具製造業のパロマ工業も元経営者に対して、同社製品による業務上過失致死傷被告事件ついて有罪の判決がなされました。１７年間で１５件の死亡事故となっているし、ワンマン経営による企業統制の欠如が背景にあるようですが、判決そのものは妥当なものかもしれません。ただ、他のメーカにとっても重要な判決のような気がします。

もちろん、判決では(1)同社が修理業者による不正改造を間接的に助長していたとしており、(2)事故防止対策および被害拡大防止義務を怠ったとしており、特殊ケースであることは事実なのですが、(1)については他の企業でも該当するところがあるように思います。ソフトウェア業界も無関係といえるでしょうか。電子機器の不正改造はハードウェアによる改造だけではなく、ソフトウェアの改変によるものが増えています。そのときにメーカ側が改変のための情報を出していたりすると問題が出てきます。そのとき気になるのはオープンソースの絡み。GPLの場合、ソースコードを公開する義務があるのですが、そのときにソースコード側に改変に必要な情報(例えば出荷製品では無効化してある設定を有効にするとか)を含まれていて、その情報を使った誰かが改造した製品が事故が起きた場合はどうなるのでしょうか。逆に刑事責任や賠償請求をさけるために、改変可能性のある部分にはオープンソースを使うことを避けるということもありえるかもしれません。

ワンマン＆同族経営の暴走とみるのは簡単ですが、ソフトウェア開発者を含む多くの方にも影響する判決だと思っています。

2010年5月10日

午前中は慶大大学院の授業。さすがに疲れていて調子がいまひとつのままテンションだけで授業をした感じ。

意外なところからオープンIDについての問い合わせ。当方に聞かれてもね。それもいわゆる国民ID構想との絡みなのですが、連携以前にそもそもオープンIDに無理があるのではと回答。というのはオープンIDの理想はわかるけど、GoogleもYahoo!もFacebookもユーザIDはそれぞれのサービスへの囲い込み戦略の要。ライバルにわざわざそれを提示するとは思えないから。もちろん個人や中小のネットサービス業者がユーザ登録したいけど、そのシステムを作りたくない場合、特に個人情報を持ちたくない場合は有用かもしれないけど、それはユーザIDをもっていないところが、ユーザ管理を頼るという場合であって、IDをもっている企業同士が連携するというのはやっぱり考えにくい。さて国民ID構想絡みについてはここでは書けませんが、連携させることによりネットから行政サービス利用の時にオープンIDをつかうというのは確かに利便性はあると思うし、海外でも実施事例があります。なりすましの問題もあるし、あくまでも非対称な接続。それと法律的にオープンID側に情報提供を求めることが前提になるはず。

なんというか、日本人はお店のポイントカードのように範囲が限定された組織・目的に個人情報を出すことには無防備な方が多いのですが、それが名寄せ、つまり統合されるとなると強く拒否する傾向があるので、IDシステムの設計は利用範囲や利用目的が広くなるほど導入が難しくなるのではないでしょうか。本気で導入を狙うのならば、利便性もわかるけど、変なところでもめないようにした方がいいのでは。ということで誰ともなく、書いておきます。

2010年5月9日

土日と休日出勤となったのですが、その横でMacBookProの再インストール。システム設定が壊れたらしく、OSのアップデートができなくなってしまったのです。ログから止まった場所を調べればよかったのですが、大容量ハードディスクを購入されたこともあり、ひとまずシステムとアプリケーションをクリーンインストールしてから、ユーザ領域だけを古いハードディスクからコピー。手間が掛かるのはアプリケーションのインストールなのですが、インストーラからインストールしないといけないアプリケーションはATOKと、MS-Office、iWorks、Adobe関連ぐらいですからね。

2010年5月8日

iPad話の続き。当方が書くまでもなく、AppleはスマートフォンとPCを中間にあるマーケットを作ろうしているわけですが、裏を返していうとAppleはPCというジャンルから逃げ出したいのかもしれませんね。個人的にはiPadをみるまえにPCというジャンルの問題を考えたいですね。というのも例えばPCの代表的なアプリケーションであるMS-Officeは数年おきにバージョンアップを繰り返していますが、10年前のバージョンと現行バージョンを比べて、作られるドキュメントやスライド、スプレッドシートに本質的な差があるわけではない。PCの骨幹たるOSについても、Windows系はというと、Windows 7もそのまえのWindows Vistaも、さらにそのまえのWindows XPも大差ない、実際にWindows XPへのダウングレード対応機種が人気を集める始末。MacintoshのOSであるMacOS Xについても、Tiger(10.4)とLeopard(10.5)、Snow Leopard(10.6)にユーザから見本質的な差があるかというとWindowsの以上に差がない。どんな分野にもいえますが、発展のない世界は長期的には廃れるだけですから、AppleもPC、つまりMacintoshの固着していては先はないと思っているのかもしれません。それにしてもPCはどうして停滞してしまったのでしょうかね。商業ベースでもOpenDocとか、WinFSとかPCを変える技術は提案されていたのですが、どれも失敗してしまいました。

2010年5月7日

世の中はiPadで大騒ぎですね。数回さわらせていただいた経験でいうと、端末としてすごくいいできです。ただ、大きなiPhoneまたはiPod Touchという意味であって、電子書籍を期待するとがっかりかもね。それと家で使うもので、いろんな意味で持ち歩くのにいいとはおもえなかったり(見せびらかしたい人は別でしょうが)。さて欲しいかというととっても欲しいのですが、現状では利用できるネットワークサービスはiPhoneを想定したもので、iPadならではのサービスが出てくるまでは静観してもいいかもと思っております。それよりiPhoneが欲しいです。

ところで3G版のiPadですが、ネットワーク的には大丈夫なのでしょうかね。ソフトバンクはiPhoneによるデータ量増加で輻輳状態になっているに、iPadは画面が大きいだけに表示するコンテンツもリッチなものが増えるはず、そうなったときにソフトバンクのインフラは持つのだろうかと他人事ながら心配になります。インフラ的にはドコモの方が余裕があるのでしょうが、当方がドコモの役員ならば、先行して発売されている米国におけるiPadによる通信トラフィック増加を確かめるまでは、仮にiPad対応するにしても、経営的にその発表できないと思います。まぁ、 G3対応機種を売りながら、無線LANを使わせて、G3を使ってね、というビジネスになるのでしょうが。SIMフリー問題もインフラの問題が影を落としているのでしょうね。仮にソフトバンクのインフラに問題がなければ、ソフトバンクのSIMを買って、SIMフリーのiPadなりiPhoneにさして使うはず。しかし、SIMロックに拘るということは現状では他社に乗り換えられてしまうということなのでしょうね。

2010年5月6日

ギリシャ問題を端をなすユーロ市場の揺れが世界に広がっていますね。為替チャートを見る限りはパニック的に売りが殺到しているというよりもじりじり下げている感じで、逆に不気味ですね。ところでFXなどに手を出されている方は生きた心地がしないでしょう。ただ、これだけ影響が広がるとちょっとやばい感じになってきましたね。

2010年5月5日

このところ話題のJobsによるFlash批判ですが、iPhone/iPad向けに限らず、リッチコンテンツを発注するクライアント側がFlashの採用を躊躇するのには一定の効果があったはず。Jobsというか、Appleにしてみれば、Flashによるコンテンツが減れば、事実上、Flashの排除するしているのと同じですからね。その意味ではJobsには負けのない戦いのような気がします。

個人的にはむしろAdobeがFlashをどうするつもりなのかが興味があります。Flashの最大の問題と思っているのは、技術的な問題よりも、Flashの開発者というか、Flashクリエーターさんの給与水準のはず。携帯向けFlashで年俸400万円ぐらい、サーバ連携ができると年俸500万円ぐらいでしょうか。これも決して高いとはいえないのですが、ほとんどのFlashクリエーターさんは携帯向けにも参入できず、ましてサーバ連携は遠い世界。このため相変わらず、ほとんどのFlashクリエーターさんは昔ながらのWeb向けのビジュアルエフェクトにとどまっているのが現実。そしてFlashでもWeb向けだと年俸300万円ぐらいが相場。Web向けFlashはアウトソーシングが進むでしょうから、給与相場がさがる可能性が高い。

AdobeがすべきことはFlashクリエーターさんが食べていけるようにすることだと思うのですがね。もちろん、AdobeにしてみればFlashにサーバ連携機能をいれて、Flashクリエーターの給与の底上げを狙ったというところでしょうが、大部分のFlashクリエーターにはサーバ連携はついて行けない世界だし、むしろJavaあたりプログラマーがFlash開発に流れ込んだだけ。むしろAdobeは、iPhoneなどのApp StoreのようなFlashコンテンツ販売マーケットに力を入れるべきだったかもしれません。趣味でコンテンツを作っている人はいいですが、みなさん食べていくためにコンテンツを作っているわけで、食べていけないプラットフォームやツールは成立しません。

それとFlashの純正オーサリングツールは結構いいお値段(約9万円)しますが、零細Webデザイン会社だと、経費削減のためにFlash MX (2002年発売)とかFlash MX 2004 (2003年発売)あたりをいまだにつかっているところもあるようです。Adobeはソフトウェア会社ですから、ソフトウェアで儲けるのは当然だと思いますが、Flashの純正オーサリングツールの値段を下げてでも、ActionScript 3の開発者を増やす努力をしておいた方がいいと思ったりします。いずれにしても、このままではAppleがFlashに引導を渡さなくても、Flashクリエーターさんが食べていけなくなります。

最後にうんちく。Flashという名称ですが、もともとFlashはFuture Waveという会社が作ったFutureSplashという名称のソフトウェアで、それを買い取ったMacromedia(後にAdobeに買収される)がFutureSplashをFlashと改名したはず。

2010年5月4日

上海万博を記念して、4,5年前に国際会議の招待講演で上海にいったときの写真をWebにおいてみました。コンパクトデジカメ(GRデジタルと古いIXYデジタル)の撮影なので画質はよろしくないです。日本にいると中国は後進国というイメージがありますが、日本よりも遅れている部分もありますが、逆に進んでいる部分もあります。日本のメディアが伝える中国のイメージは前者ばかりなのですが、後者も知って、それを学ぶこともたいせつだと思うのですがね。ステレオタイプにはなりたくないですね。それから後日、上海の人は北京の人とちがって、道にものを捨てる人は少ないと伺いましたが、たしかに裏路地でも汚いという感じはなかったですね。あれだけ広いし、人口も多い国ですから、地域性が相当あるのでしょう。

2010年5月3日

今日、Hermesの前社長のJean-Louis Dumas氏が亡くなったそうですね。Dumas氏は写真好き(写真集まで出している)、特にLeica好きで知られており、それがこうじてHermesは倒産しかかったLeicaを買収することになりました。Dumas氏の死去はLeica にも影響するのでしょうか。氏の冥福を祈りつつ、レンジファインダーカメラ好きとしては老舗Leicaの今後はやはり気になるところだったりします(すでにHermesは資本を引き上げている？)。最近はドイツ系3大カメラメーカといえばライカ、カールツァイス、ローライなのですが、ローライは倒産(最近復活したようですが)。カールツァイスはレンズ専業メーカとなっていますし、上述のライカについてはパナソニックあたりが買収に動くでしょうかね。

2010年5月2日

NoSQLとRDBMSの話の続き。RDBMSは(関係代数理論にもとづいて正規化されていれば)問い合わせに対して該当するデータは必ず見つかるとか、(関係データモデルとは直接関係ありませんが)トランザクション処理により、データ一貫性が保証されていました。こうした漏れのないデータ列挙やトランザクション処理って人間が一番苦手な処理。だからRDBMSは人間が苦手な部分を補完してくれる技術として重宝されてきましたし、今後も重宝され続けると思います。

さてNoSQLですが、そのRDBMSを補完する技術という図式で考えると、NoSQLは人間的な知識処理と重なる部分がでてくるはずです。NoSQL絡みの技術の多くが、 FacebookなどのSNSから出てきているのは偶然ではないと思っています。人間関係というのは人間的な知識処理の対象のひとつだからです。ただ、既存のNoSQLは大規模データへの問い合わせという、やはり人間には苦手な処理を狙ってしまっています。個人的な関心事は、今後もNoSQLが大規模データへの問い合わせを追い求めるのか、人間的な知識処理の世界に足を踏み込むのか。

NoSQLは相変わらず大規模データ処理を狙う限りは、NoSQLはスケールアウトのための(言葉は悪いですが)妥協的な技術でおわってしまうでしょうね。逆に人間的な知識処理の世界に踏み込むとしたら本質的な技術になりえる可能性はあるでしょうし、それこそ攻殻機動隊的な世界の第一歩になるかもしれません(ウィリアム・ギブソンの世界観というべきか)。その意味ではいまのNoSQLはKVSをベースにしたキーワードマッチング的な処理となってしまっていますが、知識処理という点ではキーワードとその中身(値)という情報の組み合わせではなく、情報と情報の関係(relationship)が重要になりますが、膨大な情報の中で情報と情報の関係から問い合わせをする技術が次のブレークスルーかもしれません。なんというのか説明するのが難しいのですがね。

ところでいつも思うのですが、NoSQLという名称はミスリードさせますね。そもそもSQLとはまったく関係ないし、関係モデル(RDB)でも一部の関係代数の演算がないものはNoSQLとして扱われることがあります。誰が言い出したのかは知りませんが、NoSQLは名称で損していますよね。

2010年5月1日

コンピュータの歴史では「汎用機は専用機を駆逐する」という経験則があります。例えばLispマシン(Lispプログラムの実行に特化したコンピュータ)は汎用コンピュータであるワークステーションに駆逐されました。専用機がダメだった理由は、汎用機と比べると市場が小さいの開発投資がすくなく、性能向上が期待できなかったことや、専用機は使い道が限定されるので不良資産になりやすかったことなどがあげられます。ただ、クラウドコンピューティングでは意外に専用機に復活の道があるかもしれませんね。

例えばクラウドのような大規模システムの場合、RDBMSは向かないということになっていますが、Joinなどの処理速度がおそくなりがちな処理を、FPGAなどを駆使して専用ハードウェアで処理速度を稼ぐという手もあります。そしていままで決定的に違うのは、その専用ハードウェアは買って使うのはユーザ側ではなく、クラウドインフラ事業者の方であるということ。そのインフラ事業者が専用機を必要とするのであれば専用機に再び脚光を浴びることになります。それともうひとつは消費電力の問題。専用機は特定の処理に特化してできているので無駄がない。だから同じ処理をするならば汎用機よりも専用機の方が消費電力は少ない。この低消費電力性のために専用機を使うという可能性はあると思います。

専用機や専用ハードウェアは研究者としては悩ましいところ。専用機や専用ハードウェアは手っ取り早く性能は出せるので、論文になりやすいのも事実。でも変化も速いわけですから、数年先にはまったく違う手法の専用機や専用ハードウェアになっている可能性は高く、10年後に研究して評価されるとは限らない。ちなみに個人的には論文数を稼ぐことよりも、ロバストな研究をしていきたいと思っています。

2010年4月30日

国研の研究者といえども学術研究の旗のもと好き勝手できるわけはなく、企業と共同研究をさせていただくわけですが、企業からみると国研や大学は組みにくいでしょうね。当たり前ですが企業は研究開発にスピードを求めますが、国研や大学と組む場合、教員と共同研究の話がついても、産学契約部門、知財部門に話を通さないといけない。当方の勤務先は幸いにして両部署は同じなのですが、大きな大学だとたいへんでしょうね。国内の国研や大学が企業と組ましてもらうことを考えると、研究のスピードにくわえて手続きのスピードをどうあげればいいのか。文句をいっていても仕方ないので、先日はひんしゅく覚悟で知財手続きを先行させるということをしてみたのですが、意図をわかってくれた方とそうでない方がおられました。

それでなくても国内の国研や大学は企業から人気がないわけでして、例えば日本の大学は教員はそれぞれ違うテーマの研究すべきということになっています（中にいると互いに棲み分けに苦労します)。海外大学は同じテーマをする教員が複数いてもいいし、むしろ同じテーマを研究している教員同士が連携して研究しています。企業からみてどちらと組みたいかといえば海外大学となるのは仕方ないような気がします。これは明治時代以来の講座制による大学マネージメントの弊害なので短期では解決しそうもない。個人的には大学や国研を超えて横串的に研究コミュニティを作った方がいいのかなぁと思ったりしますが、旧国立大学を含めて大学や国研ごとに法人が違うので、これもまた難しい。

2010年4月29日

かなりまえ、某経済系メディアの取材。内容はクラウドコンピューティング関連。かなり勘違い系の取材だったのですが、日本企業でクラウドコンピューティングは普及するかときかれて、「日本の大企業は、中途採用よりも新卒を雇いたがるのですから、情報システムも自分の色に染められる新品が欲しがるでしょう」と答えてしまったのですが、その後はどうなったのでしょうかね。深い真意があったのに。新卒さんは何も知らないわけで、その企業独自の職務内容でもそれを当然だと思って順応してくれる可能性が高い。一方、中途採用で雇った人はこれまで経験をベースに働かれるわけですから、職務内容がある程度、他の企業と共通化されていないといけません(企業によって職務内容が違っていたら転職者に仕事を用意できない)。これはクラウドコンピューティングや仮想化にもいえています。クラウドコンピューティングにしても仮想化にしても、社内の情報システムの構成や運用を標準化にあわせることが前提。その意味では中途採用の方をうまく使いこなせる企業はクラウドコンピューティングの活用もうまいのではないでしょうか。というのは社内業務が標準化されているということですからね。

2010年4月28日

正直に申し上げますが、電子書籍に馴染めません。その理由は長時間読むのが辛いから。個人的にはがんばっても目が疲れてしまって3時間が限界。ちなみに当方の知人のKindleユーザ数人に聞いた限りでは1時間以上読んだことがないそうです。さて、これからは紙の書籍にかわって電子書籍の時代になる、と説かれる方々は電子書籍で連続何時間ぐらい読めるのでしょうか。

もちろん紙の書籍と電子書籍とそもそもまったく違うものだし、用途的にも棲み分けされると予想しております。だから電子書籍は紙の書籍を上回る必要性はないと思っています。ただ電子書籍のコンテンツは読める時間に制約されるように予測しています。例えば電子書籍では連続して読める時間が1時間程度ならば、電子書籍のコンテンツはその程度の時間で読めるコンテンツが普及することになるはず。そう考えると小説は今後も電子書籍よりも紙の書籍の方が売れると思われますが、逆に読書時間が短いマンガや雑誌あたりが電子書籍化するのかもしれません。それにどうせディスプレーで見るならば本よりも動画コンテンツをみたいです(その意味ではiPadの戦略は正しいと思います)。

ただ、電子書籍絡みの話で理解できないのは教科書を電子書籍(いわゆるデジタル教科書)という話。例えば内閣官房が最近発表した「新たな情報通信技術戦略」ではデジタル教科書の普及をあげておりましたが、デジタル教科書で長時間いろいろ読まされる生徒さんは目が疲れると思うのですが、大丈夫なのでしょうかね。まぁ最近のお子様は携帯電話やテレビゲームに鍛えているのでデジタル教科書でも何時間も読めるのかもしれませんが。デジタル教科書の推進団体によっては教育現場から遠く離れた方々のところもあるようですから、端から見ていても心配になってきます。

2010年4月27日

午後から2時間ほど講演。いかがだったでしょうか。ご満足いただければ幸い。なお、至極個人的には喉をいためました。マイクを使わしてもらったので、うまくセーブすればよかったわけで、当方の失敗ですね。

ところで話題になっていたSalesforce.comとVMwareによるvmforceが発表されました。実はSalesforce版のIaaSと予想していましたが、発表されたのはVMwareが買収したJava用WebフレームワークのSpringのクラウド版。情報もまだすくないので評価はこれだけですが、ひとついえるのはvmforceはJ2EEに引導を渡すことになりそう、ということ。それとGoogle App EngineもJavaをサポートしているとはいえ、手練れのJava開発者でもなかなか扱いが難しいことから、J2EEまわりの開発するJava開発者にとってGoogle App Engineは手におえるものではない。その意味では開発者の判断というよりも、彼らを雇っている企業がvmforceを使うか否かを判断するのでしょう。それと技術的な善し悪しは別にして、vmforceを使ってJ2EEの古いアプリをクラウドにのせれば売れると思い込む企業をあるでしょうね。ちなみに個人的にはSpringというか、Webフレームワークとはあまり縁がないので、いまのところvmforceへの需要はないです。

Salesforce.comらしく、なかなか上手いところをついてきますね。実は今日の講演でもSalesforce.comによるSaaSビジネスを取り上げたばかりでした。これは先日も書いたことですが、Salesforce.comのビジネスのうまさは、例えば主力商品のCRMのSaaSビジネスは、そもそもCRMというのは仕様を作るのが難しく、ユーザ企業が本気で仕様をまとめようとしたら社内の営業全員から要求を取りまとめないと無理。ほとんどのユーザ企業はCRMについて仕様どころか、要求すらまとめられない。ならば既存のCRMを使いましょうということになりやすい分野。また、Salesforce.comのシステムを使って、エコポイントの登録システムが3週間で作られた話にしても、短期案件で仕様を作っている余裕がなかったら、Salesforce.comが用意したサービスで満足するしかなかったはず。いいかえればSaaSだから短期開発できたのではなく、短期開発案件だったからSaaSでもうまくいったとみるべき。

クラウドコンピューティングというとAmazon EC2やGoogle App Engine、Windows Azureに関心が集まっていますが、実績という点ではSalesforce.comが圧倒的に多い。そしてそのSalesforce.comのビジネスはいろいろ参考になる部分が多いように思います。前にも書きましたが、ユーザからみれば必要なサービスが使えれば、それを実現するインフラのサーバが100万台なのか、1000台なのかは関係がありません。インフラばかり見ずにサービスという観点から見るべきと思いますが。

さて今回のvmforceですが、価格体系を含めてまだ全容が発表されていないので、なんともいえないのですが、Java開発者、特にJ2EEまわりの開発者を惹きつける仕掛けをいくつかうってくるでしょう。個人的に気になるのは、今回のvmforceはあくまでもSpringのクラウド版なのか、Salesforce.comのPaaSであるForce.comにJava開発者を呼び寄せる仕掛けにするつもりなのか。Force.comの開発言語はJavaに近いので壁は低いですし、当面はForce.comのAPIをvmforceのJava環境から使えるようにして、APIからJava開発者をForce.comに落とすつもりかもしれません。その意味では個人的にはvmforceに一番期待したいのは課金メカニズム。Salesforce側の課金システムを使って、vmforce上のサービスがその利用者から利用料がとれるのならば魅力的でしょう。もうひとつ気になるのは技術的な部分でJavaから仮想マシン環境を設定・制御できるか。というのはサーバで処理負荷の変動をわかっているのは、仮想マシンでもOSでもなく、サーバそのもののですからね。そのサーバから仮想マシンの設定を変えられるのはシステムの可用性をあげるうえで大きな意味を持つからです。

2010年4月26日

午前中は慶大授業。徹夜明けの授業はいろいろたいへん。某社の新型携帯電話のリーク騒動がおきていますね。某社関係者が置き忘れて、それをWebニュースメディアが取り上げたことになっています。たしかに当方の仕事上、内輪の会合などの席上で発売前の携帯電話を見せてもらうことはありますが、常識的にいって試作機を置き忘れるというのは考えにくい。素直ではない当方は、盗まれたのか、某社の宣伝のどちらを想像してしまいます。ただ警察が動いたそうですから、後者の線はなくなりましたね。世間的には落とした社員が解雇さえたそうなので、社員の身の上を心配される方が多いそうですが、ここで考えないといけないのは社員さんのことではなく、一部ニュースメディアが落としたものと知っていて報道したことの是非のような気がします。Webニュースメディアのジャーナリズムとしての品格が問われる事件になるかもしれません。

2010年4月25日

今朝の日経朝刊の一面トップはドコモ向けの携帯電話のソフトウェア統一の話。シャープ、パナソニック、富士通、NECの携帯端末メーカと、半導体メーカのルネサス、キャリアのドコモの6社で共同開発して、2011年度の端末から利用するそうです。共同開発そのものは御勝手にという感じなのですが、気になるのは「6社で開発した基幹ソフトは海外の携帯電話機メーカにも外販する」と書かれていること。いよいよ国内端末メーカの撤退への道筋を作るということでしょうかね。それと国内携帯端末メーカの延命ならば、上記の端末メーカ4社を生き残らせたら、共倒れになりますから、1,2社生き残れる力があるところを残した方がいいと思うのですが、どこまでもいっても護衛船団方式の発想から抜け出せないのですかね。国内端末メーカが海外展開できない最大の理由は護衛船団方式により携帯端末から撤退すべきメーカが残ってしまったことだと思うのですがね。もちろんいまさら護衛船団方式をやめても海外展開できるわけではないでしょうがね。同記事では次世代携帯電話のLTEについても言及していますが、LTEに需要はあるのでしょうかね。先日も書きましたが、2005年にヒューマンインタフェース学会誌から海外の携帯電話動向の解説を頼まれたときに、国内端末メーカのほとんどは数年以内に撤退・縮小を余儀なくされるという趣旨を書いて、携帯電話業界に出入り禁止状態にされた当方としてはいまさらという気がします。

2010年4月24日

休日出勤でございます。このところ毎週末ともに土曜か日曜はオフィスでお仕事。なんだかね。

2010年4月23日

一昨日の話の続きですが、国によってITにもとめる効果は違いますよね。それを痛感したのはフィンランドの科学技術庁(TEKES)に招聘されていったときの電子行政の議論。どうも先方と議論があわない。フィンランドの場合、人手が少ないからITを使って行政サービスを効率化して、その結果、生じる余力でサービスを拡充するが目的。一方、日本の場合は、人手は余っているわけで、ITを使うにしても人手を減らすことなく、サービスを拡充することが目的。もちろん国によって事情があるので、何がいいとはいえないわけですが、ただITを雇用を増やすために使おうとすると苦労することになります。

2010年4月22日

AdobeはiPhoneへのFlash搭載を諦めるようですね。個人的にはむしろ心配なのはAdobeがiPhoneに代わりFlash搭載に力を入れることになったAndoridの方だったり。不思議にも思われるかもしれませんがね。

FlashはWebアニメーションはもちろん、メディアアート作品も作れるぐらい強力かつ自由度の高い環境。これはリッチコンテンツを作るときには重要ですが、自由度が高いということはFlashコンテンツによってユーザエクスペリエンスがバラバラになりやすい、実際、Flashに統一したユーザエクスペリエンスは無い状態。御存知のようにAppleやMicrosoftにしてもユーザエクスペリエンス重視戦略(Microsoftの場合は中途半端なのですが)。そこにFlashを入れると、プラットフォームのユーザエクスペリエンスが乱れますし、Flashコンテンツのユーザエクスペリエンスもコンテンツによってバラバラになりやすい。しかし、統一したユーザエクスペリエンスがえられないとユーザは混乱することになり、長期的にはユーザが離れることになります。さてAndoridですが、AdobeによるFlashのAndoridサポートにより、短期的にはAndoridではFlashコンテンツがたくさん出てくるでしょうが、長期的にはユーザの混乱の原因になるのではないでしょうか。個人的にはAdobeがFlashのAndoridサポートを表明したことは、実はAndoridには不幸なような気がしてなりません。

昨年になりますが、Windows Mobileを搭載したスマートフォンに、いわゆるスキンでカスタマイズしてiPhone風のユーザインターフェースにできることを自慢していただいたことがあります。アプリケーションの選択・起動まではiPhone風、つまり擬似的にはiPhoneのユーザエクスペリエンスとなるかもしれませんが、いったんアプリケーションが起動してしまうと、まさにWindows Mobileのユーザエクスペリエンスの世界。本人が満足していればいいのかもしれませんが、個人的には相違なユーザエクスペリエンスが混在させてもうれしくないと思ったり。

それとiPhoneのFlash搭載騒動をみていると、Flashコンテンツを作ったことのない人が親Apple派と反Apple派に分かれて騒いでいるだけという感じがしないでもない。FlashについてはFlashのランタイムより、オーサリングツールの方は重要ではないでしょうか。

2010年4月21日

某省から、予算をいただいている研究による経済波及効果と雇用効果のお問い合わせ。予算をいただいる以上は対応するわけですが、なかなか難しいお題。というのはITそのなかでもコンピュータに関わる研究に関しては、経済波及効果はともかく、雇用効果は難しい。というのはコンピュータを利用することにより、なんらかのバリューを生み出したり、ビジネスチャンスを広げることもありますが、コンピュータの利用目的の多くは効率化。だから人員の数を減らすことはできても増やせるのは難しいし、そもそも人員を増やしてしまうIT活用はいいのか悪いのか。もちろん、ITでも通信絡みならば帯域を広げて、通信できるデータ量を増やせので、バリューを増やせるという効果があるかもしれませんが、コンピュータの場合はなかなかむずかしい。コンピュータの計算リソースにしても、コンピュータの応用先の現実世界にしても、効率化志向が身に染みているコンピュータサイエンスの研究者にいちばん難しいお題だったりします。

ところで、今の時代、税金による研究予算をいただいたその効果を問われるのは当たり前。たしかに経済効果の計算は面倒な仕事だし、それは研究者の仕事ではないと言い切られる方もおられます。ただ、その是非についてはわれわれ研究者はとやくかくいう立場ではなく、納税者が決めること。一方で、すごく残念に思うのは「サイエンスだから知見が得られれば、効果をいえなくていい」と開き直っている研究者がまだおられること。若い研究者でも同様の発言をしている人をみると呆れる以前に悲しくなります。少なくても納税者はサイエンスもエンジアリングもわけてみてはくれません。まぁ、そんな発言をできるということはその方はすごく幸せな立場におられるのでしょう。それとこの時期に多いのですが、科研費などの予算が採択されると「科研費とった」とおっしゃる研究者が多いのですが、これもそろそろ止めた方がいいとおもったり。すくなくても「科研費をいただいた」というべきかと。

2010年4月20日

打ち合わせの日。飯田橋、オフィス、赤坂、オフィスと移動が多い。話はかわって分散システムまわり。Eventual ConsistencyとかCAPとか流行っていますね。仕事がらその動向はこまかくウオッチしていますが、研究的に興味があるかというと積極的にはなかったり。もちろんEventual ConsistencyもCAPも、分散システム特有の制約を考えると、スケールアウト性とデータ一貫性における技術的な合理性をもった妥協点だと思います。ただ、研究者としては一貫性を保持しながらスケールアウトさせる方法を考えたいところ。分散システムに限らず、不可能と思われていることを可能に挑戦するのが研究者のお仕事ですからね。

2010年4月19日

慶大大学院の授業「計算モデル」。今年も履修者が多いようで教室を変更しない無理っぽい。来週もう一回様子をみますが。ちなみに昨年は3回教室変更となりました。それにしても理論系の授業はつらい。抽象機械を説明したくとも理論系の研究をするつもりでもなければ興味はわかないでしょうから、仮想化とは万能チューリングマシンであるというノリで授業展開してみたものの無理がありました。

2010年4月18日

先日、Salesforce.comのイベントに参加させてもらったのですが、Salesforce.comのビジネスをみていて感心するのは、ソフトウェアビジネスを上手く避けて商売をしていること。御存知のようにSalesforce.comの主力商品はCRM。企業の情報システムの中でもCRMは仕様化が一番難しいもののひとつのはず。というのはCRMというか顧客管理というのは、企業内の営業部署によってもちがってくるし、営業さん一人一人で顧客との関係は違います。だから、本気でCRMのシステム構築したら、営業部署はもちろん、営業さん一人一人から機能要件の聞き取りをしないといけません。あたりまえですが、そんなことをしていたらシステム仕様からして作れない。そのCRMを最初のターゲットにおいたSalesforce.comは賢いというか、Salesforce.com側でCRMシステムを用意して、「どうせ仕様が作れないならSalesforce.comのCRMシステムを使ってください」というやり方。いいかえればそもそも機能要求をわからなかった分野ですから、Salesforce.comのCRMが企業の要求にあわないということがない世界かも。

これはSalesforce.comがはじめたChatterという企業内FacebookやTwitterもどきの社内SNSサービスにもいえて、FacebookやTwitterが登場したときはその使い方がわかる人は少なかった分野。逆に言えば機能要件があって登場したサービスではなく、FacebookやTwitterが登場したからうまれたサービス。その意味では企業はSNSサービスの仕様を作ることができないから、仮にChatterのような既存サービスがあればそれを使ってみるということになります。

その意味では仕様を定める能力のあるユーザ企業や仕様が明確に定めやすい分野はSaaSに向かず、そうした企業には、仕様策定からして作りにくいサービスを売り込むのがSaaSビジネス成功の条件かも。一方、業務向けパッケージソフトウェア(例えば会計処理や給与管理など)をそのまま使っていても十分満足できる企業は既存のSaaSでも満足できる可能性は高い。

2010年4月17日

アイスランド火山噴火の影響で欧州は大変なことになっていますが、実は当初予定では今日はパリ発成田行きにのるはずだったのですが、諸般の事情により用務が延期となりました。でも予定通りだったならば帰れなくなるところでした。それにしても世の中はいろいろなことが起きるものです。なお、火山灰は数週間は大気中を漂うそうですから、混乱はしばらく続きそうです。事故が起きないことを祈りたいです。

2010年4月16日

懲りずに開発環境のクラウド化の続き。一昨日はプログラム解析などのメリットを書きましたが、今日はハードウェア互換性へのメリットについて。結論を先に書くと開発環境がクラウド化すると、プロセッサを含むハードウェアを変更しやすくなります。具体例としてiPhone/iPadで説明していきます。

いまのiPhone/iPadの開発では、ローカルで開発環境(Xcode)を動かして、ローカルでコンパイルして、実行ファイルをローカルからApp Storeに登録という流れになります(もちろんその間、テストなどはありますが)。これが開発環境がクラウド側に移行すると大きく変わります。ここで重要になるのがコンパイル。それもコンパイルを誰がいつ実行して、はきだすバイナリの種類は何か。

クラウド側の開発環境では開発者はクラウド側にアプリケーションのソースコードやイメージなどのリソースファイルを登録すると、コンパイルはクラウド側の開発環境にお任せ。例えばiPhoneはいまはARM系ですが、Appleがx86系プロセッサを搭載したiPhoneを発売したとしましょう。当然、いまの方法ではx86系アプリが揃うまでに時間がかかります。しかし、クラウドの開発環境では、クラウド側が登録済みソースコードを勝手にコンパイルして、x86系プロセッサ用のバイナリを作って、さらにApp Storeに自動登録したらでそうでしょうか。プロセッサを含むハードウェアが変わっても、そのハードウェアに対応したアプリケーションがいつでも揃っていることになります。なお、この場合は開発者はソースコードを作って登録するだけで、コンパイルはさせてもらえないのかもしれません。

この変化はすごく大きいはず。ソースコード配布を除くと、いままでのソフトウェア販売はプロセッサ種別に縛られていました。ハードウェアを変えたくてもソフトウェア互換性がネックになっていました。しかし、上ずつのようにコンパイルをクラウド側で自動化してしまうとその呪縛から逃れられます。これは端末メーカにとってはハードウェアの選択の幅を広げますが、逆にプロセッサメーカには脅威になり、過去との既存性だけではプロセッサは売れないことになります。

もちろん、いまはクラウド版の開発環境はVisual Forceなど数少ない。それもクラウド用のアプリをクラウド版開発環境で開発する世界。当然、現状はiPhoneはもちろん、携帯端末向けのクラウド版開発環境はないですけど。仮に開発環境のクラウド化してもプロセッサ選択自由を謳歌できるとしたらAppleのiPhone/iPadだけかもしれません。ただ上記はPCを含む他のコンピュータ全般にも当てはまるでしょうね(組込系は雑多なので無理でしょうけど)。

2010年4月15日

Salesforce.comのイベントにいってきまいた。皆様のおかげで参加となりました(それもプレス席)。ありがとうございました。ただ、内容は予想と違っていたかも。先日発表されたVMForceの話がないのは仕方ないとしても、Salesforce.comのSaaSは業務用アプリケーションとしては低価格性は知られているところですから、むしろ使い勝手とか、業務効率があがったなどをメッセージとして出すと予測していましたが、内容のほとんどは社内用のFacebookもどきのChatterに関するもの。おそらくはSalesforce.comもソーシャルネットワーク的なサービスもしていますよ、というメッセージを出したかったのだと思います。でも正直言って意図を図りかねました。それと当方に限ると実は開演前に個別に発表内容のChatterの説明＆デモを15分受けたのですが、その15分の方がイベントの講演よりも詳しかったですがね(ソーシャルネットワークって使ってみないとわからないことが多いので、講演で説明するよりも、デモで説明した方がいい)。Chatterのやり取りを人事査定に使うとか、報告書の代わりになるとか情報共有以外の効果はほしいところです。

今回のChatterのような業務狙いのFacebookもどきやTwitterもできのソーシャルネットワーク的なサービスが数多く提案されていますが、必ずしも肯定的に受け取られているわけではない。御存知のように業務向けソーシャルネットワークは社員間の情報共有には効果があっても本物のFacebookやTwitterですでに問題視されるように業務の中断などによる業務効率の低下が危惧されているわけですが、その問題をどう解決するのかを知りたかったですね。例えば日本でTwitter が流行っていますが、Twitterって時間がないと参加できないし、情報はまとまっていないのでみているだけでは時間を無駄にしがち。当方も少しやってみたりしますが、たいくつなイベントや委員会に出席しているときか、朝晩の一瞬だけ。そうしないと本務の効率がさがりますから。結局、ソーシャルネットワークであるかぎりは、業務効率をあげるか下げるかは使う人のリテラシーとか意識しだいになってしまいます。

2010年4月14日

メモリベースでクラウドコンピューティングインフラを作るという研究はありましたが、MRAMなどの不揮発性メモリで作ったらどうでしょうかね。DRAMなどの揮発性メモリの場合は当たり前だけど電源が切れたデータがなくなります。このためデータ多重化、つまりデータを複数のコンピュータに保存しないといけませんが、不揮発性メモリの場合はその心配はなく、例えば揮発性メモリを使う場合、4台に多重化していたのを2台にしても大丈夫な気がします。

クラウドコンピューティングでは多重化するのでデータをメモリに格納していてもいいという議論があります。確かにその通りかもしれませんが、データの安全性を考えると複数のサーバでデータ保存しないといけないし、停電や自然災害を考えるとデータセンター地域もかえるので、通信コストが大きい。そうなると消費電力的には決していい方法ではないのです。これを不揮発性メモリをかえると多重度を下げる、つまりデータを保存するサーバ数が減らせるし、停電時にデータが消えないので、相違な地域的なデータを格納は必ずしも必要なくなります。

問題は例えばサーバの電源が落ちたときに、不揮発性メモリの状態から再開することなのですが、これにはOSを一部作り替えないといけませんね。当方はOSの研究者でないと研究するつもりはないですが、クラウドコンピューティングのアーキテクチャを根本的に変える可能性もあり、SOSPあたりも通せるネタかもしれませんね。

2010年4月13日

休日出勤の振替休日のはずですが、やっぱり出勤です。基本的に大学や国研の研究者は個人商店みたいなもので、休めば自分の首を絞めるだけなのです。

ところで一昨日の続きですが、iPhone OSの新版で開発用のプログラミング言語を制限したことが話題になっていますね。常識的に考えればFlash対策でしょうがが、個人的にはクラウド上での開発環境と関わりがあると勝手に邪推しています。クラウドコンピューティング用のソフトウェアはクラウド側で開発した方がいいわけですが、今後はiPhoneのようなクライアント用のソフトウェアもクラウド側で、コーディングしてコンパイルする。このときプログラミング言語はクラウド上の開発環境に依存するので、(1)プログラミング言語の選択はクラウド上の開発環境に依存する、そのため将来、AppleによるiPhone用のクラウド上の開発環境でサポートする言語を明確化しておく必要があった。(2)iPhoneをセキュアなプログラムを実行するには、コンパイル済みソフトウェアのバイナリ解析よりもソースプログラム解析をした方がよく、そのためにはクラウド上の開発環境でソースプログラムを書かせて、コーティング時またはコンパイル時にソースれべるｄde 実行安全性に関わる部分をチャックしたいのかも。実際、最近のメモリチェックツールはよくなっていますからね。そう考えるとiPhone OSで開発用プログラミング言語を制限したというのは合理的な判断といえます。

2010年4月12日

おそれていた日がやってきました。今日から授業です。今年は月曜日に授業を集めたために午前中に慶大理工の大学院、午後は勤務先の大学院で、それぞれ授業。日吉ー神保町は電車で乗り換えなしとはいえ移動もあり、体力的もたいへんなのですが、それ以上にたいへんなのは頭の切り替え。慶大理工の方が理論系、勤務先の方はシステム系の内容。前者ではシステムを理解する前に基礎理論がたいせつと語り、後者では基礎理論は横に置いておいて実装の話をすることになります。両方の授業をうける学生さんがいないことを祈ります(大学間の単位互換があるので制度的には可能かも)。

2010年4月11日

iPhone/iPod Touchの新OSが話題になっていますが、マルチタスクは古い機種では対応しないようですが、マルチタスクはプロセッサ性能に依存しますが、メモリ容量がないと辛いことになります。

個人的に興味があるのは将来iPhone/iPod TouchがMRAMなどの不揮発性メモリを搭載してくるかだったりします。不揮発性メモリの場合、メモリにロードしたプログラムやデータは消えません。そうなるといまのようにFlashメモリ(やHDD)などの不揮発性メモリにいれておいたプログラムをロードするという必要はなく、出荷段階でなんらかの方法でプログラムを不揮発性メモリにロードしておいて、あとはそれにアクティブプロセス／スレッドを割り当てるだけでいい。そうなるとOSにプログラムのロード機能はいらなくなります。これはセキュリティ的には結構重要でOSからプログラムのロード機能を排除できるとウィルス的なプログラムの実行可能性をだいぶ排除できるようになります。

そうなると新しいプログラムを追加できるのかという問題になりますが、OSそのものを仮想マシン上で動かしておいて、仮に新しいプログラムを追加したい場合、現在の仮想マシンのイメージをどこかの専用サーバに送って、そのサーバで明示的に新しいプログラムをロードしてもらい、プログラムをロード済みの仮想マシンのイメージを送り返してもらい、それを仮想マシン上で実行すればいい。そのとき仮想マシンの全体イメージを送るとたいへんですが、差分を送るという方法もあるでしょう。

Appleは巨大データセンターを作っているそうですが、単に音楽や書籍などのデジタルコンテンツのストレージサービスなどつまらないです。上記のように(揮発メモリでもいいので)iPhone/iPod Touchに仮想マシンをいれて、仮想マシンイメージへのアプリケーション追加サービスぐらいはして欲しいですね。というかAppleはプロセッサを含むハードもOSも作り、アプリケーションの配信も自社で行っていますから、これができるはずです。

2010年4月10日

クラウドコンピューティングが流行っているためか、Eventual ConsistencyとかBASEとかが話題になるようです。ただ、昨今の議論、例えば、これからデータ管理はACID性からBASE性に変わるとか、Eventual Consistencyが主流なるかのようにいわれると違和感を覚えます。

Eventual Consistencyなどは一貫性条件をゆるくするとレスポンスやスケラビリティはよくなります。でも、ゆるくした分、アプリケーションは対処しないといけません。単一のアプリケーションであればEventual Consistencyによる不具合がおきなようできるでしょう。しかし、複数の違うアプリケーションが絡んでくると、すべてのアプリケーションがEventual Consistencyの問題、例えば一時的な一貫性の欠如をきちんと対処してくれるとはいえないし、特に開発事業者が異なる場合、他の開発者のアプリケーションがきちんと対応してくれるかを知るのは難しい。実際、Eventual ConsistencyやBASE的な手法を多用しているといわれるサービス、例えばFacebookやTwitterはあくまでも単一アプリケーション。ならばGoogle App Engineはどうなの、と聞かれそうですが、ものすごく荒く説明するとGoogle App Engineではサービス提供者が異なるサービス間のデータ共有は排除する設計。だから、同一開発事業者による複数アプリケーションになるので、問題があっても責任の所在は絞り込めます。

まとめると単純に単一アプリケーションで大規模データを扱いたいのであれば、Eventual ConsistencyやBASEは役に立ちます。ただし、相違な開発者による複数アプリケーションを使う場合はなかなか難しく、まだまだACID性をもつデータベースの方が便利になってしまいます。もちろん、ゆるい一貫性制御を吸収してくれるライブラリがあれば、それを複数アプリケーションが利用すればいいのでは、となりますが、問題はゆるい一貫性制御の解消はアプリケーション依存だからうまくいっている部分があり、仮に共通ライブラリを作っても性能が問題になるかもしれません。

また、クラウドコンピューティングに関していうと、大規模データを扱う単一アプリケーションが主流になるのか、そこそこの規模のデータを共有する複数アプリケーションに向かうのかによりますね。いまは前者ですが、将来的には後者に向かう可能性もあるでしょう。そのときはSalesforce.com的なアプローチの方が優位になる可能性もあります。

2010年4月9日

昨日の話と関わるのですが、コンピュータサイエンスにおけるトップ国際会議の論文を多少なりとも読んでいる人ならば実感していただけると思いますが、最近、トップ国際会議に採録される論文は、あまり知られてなかった問題を見つけて、それを解くという研究のもの。ここで問題なのはその解き方。実は解き方そのものに関しては新しい研究はほとんどない。逆に言うと知られていない問題を見つけることがすべてであって、解き方は従来手法の組み合わせや力業で十分ということです。もちろん問題をコンピュータの世界に落とし込むためモデリング(問題分割を含む)のところは重要ですがね。トップ国際会議の傾向がすべてではないのですが、時代変化の一面を映しているのは確かでしょう。

そうなるとコンピュータサイエンスの研究者に求められるのは、新しい解き方を見つける能力ではなく、問題を見つける能力となります。問題をみつけるためには現実世界に関するドメイン知識が必要になります。例えばソフトウェア工学の研究ならば、研究者本人が本格的な開発経験をもつ必要はかならずしないかもしれませんが、実際の開発現場における問題を教えてもらえる立場でないと今後は難しいでしょう。ソフトウェア工学に限られるかもしれませんが、海外の著名研究者は、大学教員の傍らコンサルタント的な仕事をしており、そこで得られた知識は重要なのでしょうね。いずれにしても多くの問題は知られているわけですから、特定ドメインについてある程度深く知る必要が出てきそうですし、今後はドメイン知識の有無がコンピュータサイエンスの研究者を選別することになるのでしょう。また、どのドメインを選ぶかによっても研究者の人生は左右されるかもしれません。

もちろんこうした変化を否定して、従来のコンピュータサイエンスを貫くのも研究者のひとつの生き方だと思いますし、当方もコンピュータサイエンスの研究者の一人としてはこうした時代の変化に戸惑うところもあるのですが、これも時代の流れだから仕方ないと割り切っています。それにコンピュータサイエンスと心中したくないですからね。

2010年4月8日

コンピュータサイエンスは問題を真正面から解く技術を求めますが、むしろ問題を分割する技術の方が重要なのかもしれません。12コアのプロセッサが発表されたり、MapReduce/Hadoopも使えるレベルになってきました。並列的な処理に関しては環境が揃ってきていますから、大規模な問題でもとりあえず力業で並列処理をすればなんとなる時代。逆に言えば並列処理のために問題を分割すれば難しい問題もなんとなるわけで、重要なのは問題の解き方そのものではなく、問題の分割の方なのかもしれません。ちょっと乱暴な意見ですけどね。

これと関わるのですが、これまでコンピュータサイエンスでは、その背景にある原理や基礎理論が重要と自信をもっていえたのですが、最近はいい辛くくなってきました。以前はコンピュータの性能がよくなかったので、いいアルゴリズムを設計しないと問題が解けませんでした。そして、いいアルゴリズムを設計するには計算の原理や基礎理論を理解することが必要。でもいまはコンピュータが高性能になっているので、小さい問題ならば力業というか、効率の悪いアルゴリズムでもそこそこの時間で解けてしまいます。大きな問題についても問題を分割すればあとはメニーコアやクラウドコンピューティング環境を使って力業でもなんとかなる時代です。なお、上述の問題分割に関しては、コンピュータサイエンスというよりも、統計学のようにデータを扱うための知識や経験が必要なのかもしれません。

2010年4月7日

日経コンピュータに仮想化の特集があり、たいへん参考になる記事だったのですが、それを読んでいて思ったのはむしろ仮想化によるネガティブな影響。結局、メインフレームにおける仮想化の問題を再燃させるかもしれません。そのひとつは古いOSの延命。いまはハードウェア(特にデバイス周り)の進化が速いので、ちょっと古いOSだと動作するためのハードウェアは入手不可能という事態になり、これがOSの寿命を決めていた部分があります。しかし、仮想化により古いハードウェア環境が提供されます。そうなると古いOSを使い続けられるようになります。その意味では仮想化ベンダーの自らのことをイネブラーと呼びます。独特な言い方ですが、なかなか的を得た呼び方かもしませんね。

もちろんそれ自体はいいことかもしれませんが、いろいろ弊害がでてきます。例えばIBMは仮想化により古いOSが延命されたために、古いOSのメンテナンスを続ける羽目になったのですが、MicrosoftもServer用OSはメンテナンスを打ち切れないという状況になるかもしれません。それはたいした問題ではなく、当方が懸念しているのは、古いOSというのは機能的にもセキュリティ的にも悪いわけで、そうした古いOSやアプリケーションが運用し続けるということは変化の重みになるわけで、長期的には情報システムの発展を止めてしまう可能性があります。

同時に仮想化はハードウェアの進化も止めてしまうかもしれません。結局、OSはハードウェアそのものではなく、仮想マシンが提供する仮想的なハードウェア環境を使うわけですから、最新ハードウェアの最新機能は使われるとはかぎりません。そうなるとハードウェアベンダーが積極的に新機能を投入するモチベーションは下がるかもしれません。それと現在のサーバ用高性能プロセッサの機能や性能を考えると仮想化をしないことがありえないという状況ですが、例えばすべてのサーバは仮想化を利用しているという状況になったら、仮想マシンが提供する環境やOSが仮定する動作環境は特定ハードウェアを想定する必要はなくなります。

確信犯的に仮想化のネガティブな部分だけを書いてしまったわけですが、どんな技術でもいいところがある反面、わるいところもあるわけで、その両方を見ていきたいですね。

2010年4月6日

クラウドコンピューティング話が続いてしまいますが、もうひとつ。それも(個人的には苦手な)プライベートクラウドのこと。プライベートクラウドは、いわゆる情報システム子会社を復権させるかもしれませんね。その結果はいいのか悪いのかは別問題ですがね。

メインフレームが全盛の時代では、コンピュータは高価であり、大手企業でも数台しかありませんでした。そのメインフレームの運用は全社的に共有することが前提になってしましたし、パッケージソフトウェアもない時代ですから、ソフトウェアは内製することも多く、運用や開発の中心となったのが情報システム子会社。しかし、時代はかわって、多くの大手企業は事業部制やカンパニー制を導入した結果、事業部制やカンパニー制などの部署単位で情報システムを購入・運用するところも増えましたし、パッケージソフトウェアも普及しました。その結果、情報システム子会社の不要論が出てきましたし、実際、縮小・売却されたところも多いの周知の事実。

さてプライベートクラウドの目的は、部署単位で購入・運用されている情報システムを統合すること。つまり全社または企業グループで情報システムを集約することであり、実はメインフレームを使っていた時代と同じように、全社または企業グループで共用するシステムを構築すること。そうなると往年のように情報システム子会社が重要がなりそうです。一方、情報システム子会社も、親企業の情報システムをプライベートクラウド化以外に生き残る道がないところも多そう。

実際、プライベートクラウドを扱うベンダーに伺うと、プライベートクラウドに関する引き合いのほとんどは、大手企業の情報システム子会社からだそうです。ただ、長期的にはプライベートクラウドはパブリッククラウドに吸収されるでしょうから、プライベートクラウドは情報システム子会社の一時の延命策にしかならないかもしれません。もちろんソフトウエアの開発力がある情報システム子会社は、パブリッククラウドを通じて、内製したサービスを親企業やグループ内だけでなく、他の企業にも提供できるという大きなチャンスがあります。しかし、多くの情報システム子会社は開発能力をすでに失っているのが現実だったりします。

2010年4月5日

昨日書いた某経済誌からクラウドコンピューティングに関する取材。結局、お断りしたのですが、そのなかで一番成功しているサービスは何かと問い合わせを受けたのですが、普通ならばAmazon EC2あたりを答えるところですが、国内が対象でしたし、SaaSを含めていうことだったので、TKC全国会をあげてしまいました。担当の記者さんも驚きましたが、IT業界の方も意外に思われるかもしれません。ただ、TKC全国会というか、TKC全国会のSaaSの提供方法は注目に値いすると思っています(なお、個人的にはTKC全国会とは何の関係もありません)。

さてTKC全国会は税理士の組織とおもわれがちですが、もともとは会計事務所向けの計算サービスをする組織でした。いまの業務もコンピュータを利用した会計・税理処理の請負業務が中心。なのですが、TKC全国会がうまいところは、税理士を前面に見せるて、コンピュータというかIT的な部分を極力見せません。その結果、顧客はITシステムではなく、税理士という人間に頼んでいるつもりなのです。もちろん、顧客がうけるサービスのほとんどはITによるものなのですがね。

このやり方はSaaSやクラウドコンピューティングにおいても参考にすべきだと思います。例えばSaaSによる会計・税務処理サービスではデータセキュリティが問題にされますが、TKCの場合は顧客はコンピュータではなく、人間に頼んでいるつもりのために不安がらないようです。それとサービスとユーザのインターフェースにおいて人間にまさるものはないです。人間による「おもてなし」を重視する日本の場合、SaaSやクラウドコンピューティングでは、人間を前面に出してITを徹底的に隠す方が成功する可能性が高いのではないでしょうか。

コンピュータサイエンスの研究者として、インターフェースとしての人間に期待するというのは逃げになりますが、同時にソフトウェアとサービスの大きな違いでもあると思っています。

2010年4月4日

出張前ですが、某経済誌からクラウドコンピューティングに関する問い合わせがありました。政府によるクラウドコンピューティングへの技術支援に関するものということで受けたのですが、どちらかというと官製クラウドコンピューティングインフラの必要性を訴えることを想定した内容だったので丁重にお断り(スポンサーの都合はわかりますがね)。GoogleにしてもAmazonにしても民間企業が勝手にクラウドインフラを開発・運用してきたわけで、官製クラウドコンピューティングインフラを作ったり、政府が技術開発を支援する必要はないです。

むしろ政府に期待したいのは関連の制度。例えばクラウドコンピューティングを終わらせるためのルール作り。ソフトウェアはベンダーがサポートを終了しても、そのソフトウェアを購入者の手元にあるので、そのソフトウェアを使い続けられます。しかし、クラウドコンピューティングでは提供されるのはソフトウェアではなくサービス。サービスは提供者が提供をやめたら、代替えサービスを見つける以外は対処ができません。だから、サービスを終了させるのがすごく難しい。無償サービスならば終了してもいいのでしょうが、有償サービスの場合、一度サービスを提供しはじめたら、おいそれとやめられず、下手をすると永遠にサービスを続けないと許されなくなりかねません(法的な義務はなくても、メディアやネットで叩かれます)。これでは怖くてサービス提供なんてできません。例えばサービス終了の一年前に終了を宣言すれば終了してもいい、などのルールを政府がつって、そのルールを満足していれば免責されるなどを法的取り扱いを補償していくれる方がいい。

残念ながら、クラウドコンピューティングのサービス終了方法の議論は聞いたことがないのですよね。まぁ業界も研究コミュニティも、目先のお金が欲しいので、官製インフラとか技術支援に予算措置とか言い出すわけですが、そろそろ政府がやるべき仕事、やらなくてもいい仕事は明確にしたいですね。

2010年4月3日

なんとか帰国です。やれやれですね。出張中に日本ではSIMロック解除への議論がいろいろあったようですね。SIMロックの弊害は7,8年前からわかっていたはずで、いまごろになってSIMロックの解除をいいだしても、手遅れもいいところではないでしょうか。

実は2005年にヒューマンインタフェース学会誌から海外の携帯電話動向の解説を頼まれたのですが、その解説で国内端末メーカのうち、海外メーカと合併したところ以外は数年以内に撤退・縮小を余儀なくされるという趣旨を含む解説を書いたことがあります。その当時は国内携帯電話は世界の先端にいると信じている人たちがたくさんおられ、猛反発を食らったのですが、多少タイミングが遅れていますが、確実にそれに向かっていますよね。当たり前ですが、SIMロックを外したら国内端末メーカは海外展開できるというものでもないです。海外はNokia、Samsung、LG、モトローラが熾烈な争いをしている状況。いまさら国内端末メーカの海外展開しても勝てる見込みはないし、国内向けの端末が海外で売れるわけもない。

むしろいま議論すべきことは、国内端末メーカの終焉をいかにソフトランディングさせるかのように思います。

2010年4月2日

午前中はワークショップに出席して、それから市内を少し探索してから空港です。といってもドイツは休日で街中も人気がない状態でしたが。国際会議後のワークショップは主要メンバーが帰ってしまっていることも多いのですが、今回は大物ぞろいでしたね。

ところで会場はマンハイムだったのですが、マンハイムは鉄道交通の要衝だけあって、空港から40分弱でマンハイム駅に到着。大学もホテルもマンハイムの駅から近く、移動はともかく楽でした。帰りの飛行機は満員でした。機内でメトロポリタンオペラ(METO)のビデオでサロメをやっていたので観たのですが、さすがはMETOで歌唱も演出もすばらしいのですが、やせ細っているはず予言者役がすごくふくよかなのはいただけない。

2010年4月1日

会議後、40分ほど電車に乗ってフランクフルトに移動。フランクフルト歌劇場でRichard Straussのオペラ「Daphne」を観劇。歌、演奏、演出、舞台ともにものすごくいい出来でした。Daphne役のソプラノ歌手Maria Bengtssonは出来がよかったですね。Daphneはギリシャ神話の神Apolloが一目惚れするぐらいの美人ということになっていますが、Maria Bengtssonはオペラ歌手にしては珍しくというか、顔とスタイルが抜群で、役所にまったく違和感が全くない。またDaphneの幼なじみのLeukippos役はテノール歌手Daniel Behle。演出の都合上、Leukipposはマニアックな役所でしたが、歌と演技ともによかったです。Apollo役はテノール歌手のLance Ryanですが、よかったですね。Daphneの父親役はバリトン歌手のMatthew Bestでしたが、バリトンで年寄り役という難し役所ですが、そつなくこなしていました。Gaea役はアルト歌手Tanja Ariane Baumgartner。この方はなかなか雰囲気があってよかったですね。演奏は指揮者がSebastian Weigleという方。Richard Straussのオペラは演奏の美しさがすべていえる部分がありますが、とってもよかったですね。細かい旋律まできれいな音をだしていました。演出＆舞台は、オリジナルの田舎ではなく、寂れたお屋敷の中という設定で、回転式の舞台をうまくつかって変化をだしていました。なお、演出はDaphneは花や木々好きというよりは、マニアックな花や木々への思い入れがある感じに演出され、Leukipposはやや異常者的な雰囲気になっていましたが、舞台とすごくあっていてよかったですね。ところでフランクフルト歌劇場はドイツでは3大歌劇場、ベルリン、バイエルン(ミュンヘン)、ドレスデンとくらべて一段下にみられます。全部を聞いたわけではないのですが、フランクフルト歌劇場は新しいだけあって音響もよく、いいと思うのですがね。

2010年3月31日

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

ところでPerComと同様分野の国際会議にUbicompやPervasiveがあり、地味な研究を好むPerComと、派手好きなUbicompやPervasiveで棲み分けができています。３つの国際会議のプログラム委員を経験したのですが、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は過去に採択率は８％だったこともあり、今年は緩いという感じ。ちなみに採択率が８％のときの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に関しては、しばらくして実装事例が増えるとともに、記述の容易さよりも性能を重視して、マルチスレッド実行モデルがもてはやされるのでしょうね。歴史は繰り返されますから。もちろん当方の予測を裏切るような展開を期待しておりますが。

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

2010年2月25日

ここ数年、自分的には専門外とおもっているACM Multimediaという国際会議のプログラム委員をしており、フルペーパーの締め切りは来月初め。マルチメディア系の最難関国際会議らしいのですが、当方が普段投稿しているシステム系の研究分野の論文採択率からみると３倍以上、ゆるいような気もしますが。まぁそれはともかく、毎年査読をしていて感じるのは、マルチメディアやコンテンツの研究は最後は主観なので論文を書く方も、読む方もたいへんということ。この国際会議は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時以降にお願いすることも多くなりました。というわけでご迷惑をおかけしております。ただ、もう本当に時間がないのです。

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

今年後半、分散システム、特に分散アルゴリズムを理解するには(論文以外で)何を勉強すればいいのか、と何人かから聞かれたのですが、なかなか難しい質問ですね。やっぱり論文を読んだ方がいいので。ただ分散アルゴリズムの基本中の基本を勉強するならば、最初の１冊目は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 らしく、あらのない演奏ですが、今年はパーカッションパートの方々が大活躍でしたね。

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

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

昔の日記へのリンク