Diary

Ichiro Satoh

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

最新版
一覧

2008年6月30日

慶大の大学院授業。さてGoogleがGoogle Media Serverというソフトウェアを発表・公開。テレビ局にとっては驚異になるでしょうね。これはYouTubeなどがTVで観られるようにする仕掛け。この仕掛けPC側で動いてYouTubeなどにアクセスするのですが、さらにUPnP AV対応のテレビを探して、動画を表示できるようにするもの。いよいよGoogleがリビングに進出してきましたね。さてGoogleも民放テレビ局は広告収入で収益をえているわけですが、PushベースのTVCMと検索というPopベースのGoogleの広告はこれまで棲み分けができていたわけですが、Googleがテレビの領域に入ってくるとなると状況は一変します。個人的にはYouTubeの強さというか、怖さはその膨大なビデオライブラリでも配信能力でもなく、むしろビデオコンテンツの検索を可能にしたことだと考えています。テレビ放送では各視聴者がみるテレビを観る時間は限られていますし、テレビ局数は多い。このため視聴者が観たコンテンツと観ていないコンテンツでは後者の方が圧倒的に多い。このためテレビ局は他のテレビ局や他のメディア(インターネットや新聞など)と視聴者の時間、つまり視聴者に広告をみさせるチャンスを奪い合っているのですが、同時にその視聴者が観ていなかったコンテンツもライバルになりえます。しかし、これまではテレビ放送を含めてビデオコンテンツは蓄積・整理がされていないので、視聴者が観たい番組があってもビデオコンテンツを探し出すのは難しかったのでライバルにはなりえなかった。しかし、GoogleはYouTubeというサービスをつかってビデオコンテンツを蓄積して、Web検索のようにユーザは観たいコンテンツに探し出せるようにしてしまった。そうなるとユーザは、いままで観ていなかった過去のコンテンツを観るようになってしまい、テレビ放送をリアルタイムに観なくなってしまいます。もちろん、YouTubeに蓄積されているコンテンツの多くは、良くも悪くもテレビ放送を録画しているものなので、視聴者はテレビ向けのコンテンツを観ていることに変わりないのですが、リアルタイムで観ないのであれば電波で放送する必要はなく、ネットワーク配信で十分。また、TVCMというのはリアルタイムで観ることを想定して作られているし、実際、放送時と視聴時のタイムラグが大きいと広告効果は下がることが多い。そうなればTVCMの価値が下がるわけで、広告料が下がってしまい、テレビ局は広告収入を減らすことになります。多くのYouTubeの視聴者は、テレビ放送では見ていないコンテンツを観ることがおおいのではないでしょうか。例えば仮にそのコンテンツに商品TVCMが含まれていても、Youtubeで視聴する頃にその商品が売られているとは限らない。いずれにしてもGoogle Media Serverはまだまだ実験的な段階だと思いますが、テレビ局が自ら作った過去のコンテンツとの戦いが始まったということで大きな分岐点になるでしょう。試したかったのですが、当方はUPnP AV対応のデバイスを持っていないので、断念。

2008年6月29日

某大手電機メーカの携帯電話の開発拠点の跡地にできたショッピングモールにいってみる。業界の方ならこの情報だけでどのメーカのどの事業所かがわかりますよね。ショッピングモールですが、バーゲンということもあってすごい人の数。別の大手電機メーカの携帯電話の開発拠点がまだすぐ近くにあるとはいえ、この周辺は人の流れが変わりましたよね。ちなみにショッピングモールのあった携帯電話の開発拠点は、携帯電話以前は人工衛星を作っていたところなのですがね(当時は国産衛星では最大シェアのはず)。ところで通信系の工場は、シンボル的に(変な)モックアップアンテナ兼宣伝棟を建てているところが多くなりましたが、最近は見かけないですね。昔はアンテナは最先端のシンボルだったので、目立った方がよかったのでしょうか。カラーテレビが始まった当時、カラー放送用のアンテナはカラフルに塗装されていたそうです。しかし、いまはアンテナは見えない方がいいとされる時代。携帯電話のアンテナもついている機種を持っている人が少なくなりました。通信関連の事業所でもアンテナ(もどき)はない方がいいのでしょう。

2008年6月28日

ぐったりです。ところでSlashdotに自分の研究のスレッドが立っているということを伺って、そのスレッド拝見。たいへんなことになっているかと思ったのですが、意外にも順当。この研究は最近発表したばかりだし、その論文も英語だしね。ただ、なかなか鋭い指摘もありましたがね。当方の関連でSlashdotにスレッドをたてられたのは当方が知る限りは2回目。もっとあるのかもしれませんが、普段はみないサイトなのでよくわかりません。いちおう「研究者としてひっそりと生きる」というのが研究者としての目標ですので、ひっそりと目立たずですね。

2008年6月27日

朝から書類作成。秘書さんや事務の皆様方まで巻き込んで、当方の日本語チェック。もうしわけないです。Googleの方が、コンピュータの省電力技術に関するコメントの記事があったのですが、「Googleのサーバは、ほとんど常に適度な量の作業をこなしており、動作がピークに達するフル回転状態や完全な休止状態はまれである」だそうです。ということでモバイルコンピュータ用のプロセッサの省電力技術をサーバに持ち込んでも意味がないということ。Googleは負荷分散がうまく機能しているからのコメントなのですが、学術研究では、忙しいときはプロセッサクロックをあげて、そうでないときはクロックをさげるという手法の論文がたくさんあるのですが、Googleのように負荷分散に成功しているシステムではクロック可変手法は無用ということかもしれません。いわゆるグリーンITには怪しいものが多いのですが、結局、情報システムを実運用したことがない方々が想像で研究開発しているのもその怪しさの原因のひとつかもしれません。当方は省電力関連の研究には手を出していないのですが、抜本的な方法は半導体技術に頼るしかないし、運用上の省電力化も、運用中の計算量や電力消費などの詳細データがないので評価ができないのです。もっとも想像で省電力方法を提案だけして、その評価をしなくていいのであれば別ですが、メーカでもないと基礎データがないので、どんな方法がどれくらい効果があるかがそもそもわからないのです。それにしてもコンピュータ関連の省電力に関する論文は、お題目だけのものは論外としても、提案だけで評価をしていない(できない)研究が多いですよね。

2008年6月26日

Eclipse ver.3.4をダウンロード＆インストール。非標準プラグイン類も動いているので、このまま使うことになりそう。最近は統合開発環境(IDE)なしでは開発できません。昔、エディタ(Emacs)を使ってプログラミングしていたなんていまでは想像もつきません。Emacs信者は、Emacsはエディターではなく、プログラマブルな環境だと反論されると思いますが、ソフトウェア開発の最新機能やツールはEclipseなどのメジャーIDEに搭載され、Emacsがそうした機能やツールをサポートするのは1年以上遅れることが多い。その時間差が問題なのです。ましてソフトウェアの研究をしている立場だと、常に最新の開発ツールを使い続けないと時代に取り残されます。ところでEclipse ver.3.4はMacOS Xの読み上げ機能を使ってソースコードを読み上げる機能がついたのですが、これって何に使うのでしょうね。これからコードレビューは読むのではなく、聞くのでしょうか。ちなみに入力時にアルファベットを一字一字読み上げるのでかなりうるさいです。もちろん読み上げ機能を止めればいいのですが、なんか楽しくてプログラミン中に読み上げさせています(すぐ飽きると思いますが)、ただし、この機能、電車でプログラミングする場合は使えません。

2008年6月25日

大阪出張です。大阪大学で講義、新横浜と新大阪は2時間15分だから一瞬ですね。毎年講義をしているとはいえ、学生さんバックグランドが掴めないので、技術キーワードをいろいろいってみて学生さんの反応を見ながら進めるのですが、クラウドコンピューティングでは全滅。遠慮して知らないふりをしている学生さんも多いとは思いますが。学生さんの多くがSI事業(最近はSIerというらしいが)に就職されるわけですが、国内SI業者はクラウドコンピューティングの影響を一番受けますよね。クラウドコンピューティングではサービスを実行するマシンはGoogleやMicrosoftのサーバなので、マシンやネットワークは彼らが用意してくれるので、ネットワークやサーバーの設計・設置で利益を得ているSI事業者は大きな収益源を失うことになります。当然、SI事業者で働いているネットワークエンジニアはいらなくなります。また、データベースなどのミドルウェアもGoogleやMicrosoft側で用意されるので、データベースのインストール・チューニングの必要はありません。これらの業務はSI事業者の収益源だったのですが、当然、SI事業者で働いているデータベース担当のエンジニアは多くいらなくなります。結局、SI事業者に必要な業務はサービスを開発すること、既存のサービスを組み合わせて大きなサービスを作るということが中心になってしまうかも。SI業者に勤めるにしても職種によってはたいへんですよね。もちろん、クラウドコンピューティングはすべて情報サービスには向くわけでなく、一年を通して一定して処理量がある情報システムは自前でサーバを持った方がいいのですが、逆に処理量が多いときと少ないときの差が大きいシステムは、処理量が大きいときに備えて大規模なシステムを購入・維持するよりは、クラウドコンピューティング上で実現して、処理量に応じて計算リソースを確保した方がお得です。いずれにしてもSI事業が不要になるわけではないのですが、サービス開発能力がある事業者以外はつらいかもしれません。

2008年6月24日

所内の委員会、特許事務所、特許庁、授業、来客。目が回りそうというか、目が回っていた一日。これ以外に明日の阪大授業用の資料、申請書類、論文査読をしないといけなかったのですが、すでにオーバーフロー例外でフリーズ状態。誰かリセットしてください。

2008年6月23日

慶大理工の大学院授業、それから早大理工。副都心線を使って西早稲田(早大理工)に移動しましたが、副都心線の渋谷駅はよくわかりませんね。さてUEFA EURO 2008はすごいことになっていますね。ファイルはドイツ対スペインのような気がしますが、ファイナルがトルコ対ロシアになったら、いろいろな意味で複雑かも。ところでiPhoneの国内価格が発表になりました。基本料は1万円弱と予想していたので、思ったよりも安かったというのが正直な感想です。でもiPhoneは国内ではどうなのでしょうか。iPhoneに否定的な見解をすると信者の方からおしかりをうけるのですが、iPhoneは発売時は相当話題になると思いますが、需要が一巡するとあまりうれないのではないでしょうか。ビジネスに使うPCと違って、携帯電話は日常で使うものなので国民性や文化に強く依存します。だから米国で受けたとしてもそれが他国で受け入れられるとは限りません。その意味では携帯電話向けサービスも同じでしょう。国内の携帯電話端末メーカはなくなっても、国内の携帯電話向けサービスは海外よりも進んでいるので、 国内サービス提供事業者が海外に進出すれば成功するという考え方があるようですが、端末以上にサービスは利用者の生活文化にあわせないといけないので、国内の携帯電話向けサービスは海外でサービスを提供しても、たまたま海外の需要とマッチして受けるサービスが少数はあるかもしれませんが、そのほとんどはうけいれられないのではないでしょうか。だいたい海外では3G携帯電話が遅れていると思っている方がおりますが、むしろ海外ではGSM(2G)で十分なので、3G携帯電話に需要がないだけですから。

2008年6月22日

このところGoogle App Engineで遊んでいます。Google App Engineですが、いろいろ制限はあるもののそれなりに使えますし、クラウドコンピューティングを先取りにするにはいいですね。実際、ちょっとしたWebサービスであればApp Engine上で簡単に実現できますし、そのままサービスを提供できます。わざわざサーバマシン、Apatch(Webサーバ)、アプリケーションサーバを用意して運用する時代ではないです。ただ、データベースまわりのAPIは何とかしてほしいです。まぁJOIN操作ができないなどの機能制限は計算リソースを維持するためにしかないのでしょうが、APIが独自なので、仮に他社のクラウドコンピューティングのインフラ提供サービスで、App Engine用のプログラムが動きません。今後はクラウドコンピューティング上の各種APIの標準化が必要になるのでしょうね。いずれにしても、いまお手軽にクラウドコンピューティング時代の先取りをしたいのであれば、GoogleのApp Engineしかないわけですし(Amazon EC2は有料だし、各種サーバの知識ないと無理)、少なくてもクラウドコンピューティングの可能性と限界を知るためには実際にプログラミングと運用してみるしかないです。

2008年6月21日

今日もぐったりです。以上。ところで携帯電話の機種更新を画策中。今回もデザイン性や機能よりも使い勝手優先で機種を選ぶことになりそうですが、使い勝手という点では機種は限定されますよね。携帯電話は手でもって使うものなので、薄ければいいというものでもないし、LEDがピカピカ光る必要もありません。

2008年6月20日

今日もEUの委員会。ややお疲れ。家に着いたのは0時過ぎでした。さて出遅れながらFirefoxをver.3に上げてみました。といってもver.3のβ版を使っていたので、特に変わったところもないのですがね。実は普段はApple純正Web BrowserであるSafariを使っているのですが、表示速度はだいぶ速くなりました。Safariと同程度でしょうか。ただ、Firefoxも結構使っていて、それはJavaScriptなどのデバッガー(Firebug)の出来がいいから。ただ、Webコンテンツ向けの開発ツールのユーザとなるWebデザイナーさんと話していると、いまでもCSSやJavaScriptを書き換えてはそのまま実行しているという過程を繰り返す方が多く、JavaScriptデバッガーやHTML/CSSインスペクターの存在すら知らない人が多い。その力業ともいえる開発には経緯をはらいますが、そんな非効率的なデザイナーさんには仕事を頼みたくないですよね。ソフトウェア工学の研究では、JavaやC++などを使った本格ソフトウェア向けの開発・試験手法やツールの研究は多いのですが、Webまわりはまだまだ弱い。逆に言えばまだまだ研究の余地はあるということになります。

2008年6月19日

EUの委員会に出席。23時過ぎにオフィスに行ってお仕事。終電でまたホテルに戻る。実は都内なのにホテルにとまることになっています(宿泊費などはEU持ちです)。会議に関してはあまり内容が書けないのですが、いわゆるFP7(さらにその次のFP8)の研究助成テーマを決める委員会。この先、5-7年間の欧州の情報系研究の流れを作ることになってしまいます。もちろんEUの研究助成は日本からは応募できないのですが、欧州の大学や研究所と組むことはできるわけです。昨日も書きましたが、情報系に限らず国内の研究予算がありますが、今後は減り続けるでしょうから、その対策は必要です。ちなみにオフィスに戻ったはのは某省の来年度予算絡み。ようやく概算要求の骨格が見えてきた感じ(ただ、当方はその予算をもらう立場ではない)。ただ、あいかわらず「安全・安心」がキーワード。もちろん「安全・安心」は必要です。でも絶対的に安全なシステムや、すべての人が安心できるシステムは不可能です。だから、「安全・安心」というお題目をつけるにしても、必要としている安全度、例えば許容できる事故率などを定量的に定めるべきですし、安心もその定義も明確にしないといけません。そうした定義なしに「安全・安心」というお題目をならべても、結局、感覚としての「安全・安心」だけになってします。また、新しい科学技術は枯れた技術と比べれば未知な部分もあり不安要素は相対的に多くなります。しかし、それを漠然とした「安全・安心」を求めると、保守化してしまって新しい技術は排除されてしまいます。もちろん霞ヶ関側の都合、つまり「安全・安心」が感覚的な言葉だからこそ、財務省や政治家を説得しやすいという事情もわかります。でも変化を求めるのであれば、リスクもとらないといけません。

2008年6月18日

EUの情報系研究予算(FP7)の研究助成のテーマを決める委員会に出席。なぜか日本で開催されているところが謎なのですがね。それはともかく日本の財政状況などを考えると、日本の研究助成予算は今後減っていくの確実です。そうなると我々研究者には、少ない国内予算を細々とやっていくか、海外の予算を取りに行くか、海外に拠点を移すかの３つの選択しか残されていません。その状況にいつ追い込まれるのかはわかりませんが、10年先を考えると国内研究助成は減り続け、いまの半減以下になっていることは十分想定できます。ただ、一つ目の選択肢は避けたいところなので、当方なりに対策をたてているしだいです。一般論として、どんな世界でも状況(例えば経済状況)が下り坂になると、逃げ切れる世代は現状を維持しようとしますが、逃げ切れない世代は現状を打破して上り坂にするか、別の世界に逃げ出すしかありません。これは研究の世界も同じではないでしょうか。いずれにしても逃げ切れない世代には選択肢が少ないです。

2008年6月17日

今日も取材です。当方の研究に関心をいただき取材していただくのはたいへんありがたいです。実は取材が続いており、今月になってから何回取材をうけたかもわからない状況になっております。記事の掲載が新たな取材・記事掲載につながっており、いつまで続くのでしょうか。さて突然ですが、東急東横線と東京メトロ副都心線の相互乗り入れに反対！とさけびたいです。副都心線は大幅遅れが続いているようですね。さらに東急東横線まで乗り入れたら収集がつかないのではないでしょうか。現状では東武東上線と西武池袋線×東京メトロ有楽町線と副都心線が相互乗り入れするので、東武東上線ー東京メトロ有楽町線、東武東上線ー東京メトロ副都心線西武池袋線ー東京メトロ有楽町線、西武池袋線ー東京メトロ副都心線の４つの乗り入れパターンがあって複雑なのに、さらに副都心線と東横線をつないだら、５線が絡むことになります。ご存知のように東横線は毎朝、上り電車は渋谷駅付近では止まってばかり。信頼性のあるシステムを作るためにはトラブルが起きても、そのトラブルを広げないことです。4年後にはさらに東急東横線がつながるそうです。東横線と副都心線をつないだら、横浜で起きた遅れが、埼玉に広がりますし、逆も起きます。ちなみに鉄道マニアに伺ったところでは、有楽町の和光ー小竹向原の区間は副都心線として計画された区間であって有楽町線の区間でなかったのですが、副都心線できる以前、和光ー小竹向原区間だけが先行して開業したので有楽町線とつないだそうです。このため有楽町線の和光ー小竹向原区間を副都心線区間にするのが筋なのですが、東武東上線から有楽町線で都内に向かう利用者も多く、いまさら同区間を有楽町線から切り離せないのだそうです。なお、東横線と副都心線の接続にともなって東横線のホームも明治通り側に移動。ということはJRへの乗り換えは手間がかかることになりますし、まして京王井の頭線の渋谷駅は相当離れますね。

2008年6月16日

午前中は慶大の大学院授業。AMDがGPGPUを発表しましたが、単精度とはいえ、1TFLOPSだそうです。一昔前はスパコンでもありえない性能ですからね。もっとも消費電力はかなり大きそう。当方は浮動小数点演算を使うソフトウェアを滅多に書かないので需要がないのですがね。

2008年6月15日

昨日の続きです。勤務先の場合、年二回博士課程入試があるので、問い合わせが集中する時期が年二回にあります。問い合わせで多いのが博士論文のテーマ。いろいろテーマを提案をいただくのですが、困るのは社会を変えるような重いテーマを熱く語られる場合。せめて2,3年で終わるテーマでないと博士はとれないことになります。もちろん研究したいテーマにするのがいいのでしょうが、博士をとってからも博士論文のテーマを続けるとは限らないし、活躍している研究者には博士取得後にテーマを変えていることが多い（もちろん、研究は地道に続けている方もおられますが、単にテーマを変えられない研究者も少なくない）。それはともかく博士論文は博士課程という研究者養成コースの実習課題のようなものですから、博士取得後に研究者としてやっていける知識や思考トレーニングができるテーマに割り切るのもいいかもしれません。いずれにしても突き詰めて考えるようなテーマがいいですよね。次に困るのは逆に思いつき程度のテーマを語られる方。よく考えずに浅いテーマを選ばれてそれで博士号をとれても後で苦労するというか、博士取得後にのびないことが多いように感じます。よくある失敗は、○○技術と△△技術、××技術などの複数技術の組み合わせてシステムを作りますというような研究。どれか一つの技術でも極めてくれればいいのですが、下手をするとどれも中途半間に終わります。研究の世界は一番とそれ以外なので、狭い分野でもいいので一番になれる分野を狙った方がいいのですがね。同様に困るのは、既存○○技術に何かを足したというテーマを持ち込まれる方。例えばネットワーク制御にエージェント機能を拡張してみたというような研究。もちろん、その拡張やブレンドが本質的な場合はきわめていい研究になるのですが、そうではないと難しい問題をさらに難しくしているだけになってしまいます。ただ、こうした研究は一見すると既存研究よりもさらに難しい問題を解いているように見えるので、国内学会だとジャーナル論文も通ってしまうことがあります（当たり前だけどメジャー国際会議では通用しない）。でもマッチポンプのような研究はいつまでも続けられるわけでもない。そして一番多いのはテーマに新規性がないという場合。ちょっと調べれば過去に同様の研究があることがわかる場合は論外なのですが、筋がよければ新規性は出せることもあります。ただ、これは指導教員がどのように研究方向性を誘導するかにもよるので、学生さんではなく指導教員にもよるかも。また、同様に困るのはアプリケーションをテーマにされる方。博士課程の場合は技術的な新規性や貢献が求められるので、便利なアプリケーションやサービスを作りましたというテーマは博士論文にしにくい。技術的な部分に絞ってテーマを考えられた方がいいと思います。いずれにしても適切な博士論文のテーマが設定できれば、その時点で博士論文は半分とはいわないものの1/3ぐらいは終わっているようなものだったりしますがね。

2008年6月14日

博士の進学について問い合わせをうけることが多いのですが、当方なりの考え方を書いておきます(当方は大きなことをいえる立場ではないです)。当方の勤務先の博士課程の場合は、あくまでも研究所付属博士課程という位置づけ。基礎から勉強したい人は大学の博士課程に行かれた方がいいと思います。これを書くと当方は怒られるのですが(勤務先博士課程の広報担当の委員になっているらしい)、大学の場合、学部や修士の授業が潜り込めるのでいろいろ勉強できるというメリットは大きいです。一方、当方の勤務先のように研究所付属博士課程のメリットは、プロの研究者の研究を身近でみるチャンスが多いということでしょうか。たまに修士・博士課程に入ると指導教員が学生さんに「研究の指導」をしてくれると思っている方がおられますが、研究するのは学生さんなので、指導教員が「指導」できるのはせいぜい論文の書き方とか、研究方向性に関する助言や議論であって、研究そのものを指導できるわけではありません。結局、研究の仕方はプロの研究者から盗むしかないです。その意味では当方の勤務先のように研究所付属博士課程の方がプロの研究者が多いので、プロの研究者の研究の仕方を盗むチャンスは大きいかもしれませんね。仮に大学の博士課程に行くことになっても、指導教員が自分自身で研究しているような方のところを選んで研究の仕方を学んだ方がいいと思います。また博士課程にいれば受動的に「研究の指導」が受けられると勘違いしている方がおれますが、そうした方は博士課程にいっても落胆されるだけかも。このほか進学に関するお問い合わせで一番困るのは博士をとることを目的化されている方からの問い合わせ。博士号(学位)なんて研究者としての資格の一つにすぎないわけで、重要なのは博士取得後にいい研究ができるようになっていることなのにね。博士課程におられる間に(まわりの研究者の研究の仕方などをみて)自分なりに研究の仕方を身につけてもらうことが目的であって、博士論文の研究はその実習課題にすぎないし、まして博士号はそのオマケみたいなもの。なので「(私は)博士号をとれますか」などとか聞かれると、この人はオマケが目的なの？ということになります。博士取得後の方が重要なのですがね。博士課程にいくにしてもトップ研究者を狙うのかそうではないかで違ってきます。例えば指導教員を選ぶにしても、指導教員も世界の一番の研究を狙っている方もおられますし、そうではない方もおられます。その選択を間違えると確実に不幸になります。なおトップ研究者はトップ研究者なりの研究の仕方やノウハウがあるようで、トップ研究者の指導教員はやはりトップ研究者だったということがほとんど。トップ研究者を狙われる方は、(大学を変わることになっても)トップ研究者のところで指導を受けられた方がいいと思います。ただ、そうした研究者は学生さんの研究指導に関心がないことが多いですがね。

2008年6月13日

国際会議の3日目。ただし他の仕事もあったので途中参加。国際会議ではこのコミュニティ(形式仕様記述や試験)はどこにいくべきかというパネルがあったのですが、パネラーでも企業の研究者は現実がわかっているようでしたが、大学関係者のパネラーは形式化が御専門の方々。20年前のような話をされる方もおられますし、取り上げている例題も別に形式仕様記述を使わなくてもいいところに、わざわざ形式仕様記述を使おうとしているとしか思えないものばかり。最後のパネラーの一人が「Internet really needs formal methods」というメッセージで最後をまとめられていましたが、インターネットは本当に形式仕様記述を必要としているのでしょうかね。インターネットを形式的仕様記述で書けるのでしょうかね。そこまでいうなら、インターネットで実際に使われているプロトコルを形式的仕様記述で書いてほしいし、その記述で実装ではわからなかった問題などを見つけてみてほしい。

2008年6月12日

国際会議で発表です。さてこの国際会議は形式的仕様記述に関するものです。28回目ということで歴史のある国際会議なのですが、その歴史の長さが災いしているかもしれませんね。出席するのははじめてなのですが、まず最初に驚いたことは、内容以前に採録されている論文を眺めてみると、論文の参考文献は20世紀のものを結構多いこと。通信の世界は移り変わりが速く、3年前でも大昔なのにね。また扱っている内容も世の中からズレているというか、通信が電話を含めてインターネット(TCP/IP)に修練しているというのに、いまだにOSI を想定しているとしか思えないような論文もある始末。ただ、この問題は通信の形式的仕様記述という研究分野の特有の問題なのでしょうね。世の中はTCP/IPになっているのに、形式的仕様記述言語でTCP/IPに対応したものがない。もう少し正確に言うと、既存の形式的仕様記述言語はデータリンク層などの記述に向いているかもしれませんが、形式的仕様記述言語とTCP/IPはミスマッチが致命的なほどに大きい。このため形式的仕様記述言語を使ってTCP/IPによる通信を記述しようとするとすごく複雑になるし、そもそも正確に記述できないのです。つまり、まるで使えないということ。過去にはMITのTCP/IP処理の記述言語などのいくつかのプロジェクトがあったのですが、TCP/IPのbindやacceptなどの基本動作すら、C言語と比べて本質的に簡単に書けるわけでもないし、通信ではパケットロスなど通信失敗がつきものなのに、理論的にきれいに言語をつくればつくるほど例外処理が書けなくなります。またTCP/IPに適した形式的モデルの構築への試みもたくさんあったのですが、ことごとく失敗。このコミュニティは、形式的記述をTCP/IPに対応ができないのであれば、できないことはできないと総括した上で、TCP/IPのうえで動いているアプリケーションで形式的仕様記述が向いているものをさがすか、通信以外の分野に行くしかないと思いますが(π-calculusな方々で機転が利く連中ははBPELや分子生物学に脱出済み)。ということもあって当方は通信以外の分野(物流)への形式仕様記述への応用に関する論文を書いた次第。ただ、通信関連の研究者はネットワーク層などの通信階層で棲み分けをして、その境界を犯すことはタブーという研究コミュニティなので、当方のような通信とはまったく関係ない発表するのは驚いたでしょうし、通信とはまったく違う世界の話なので理解されたかも大いに疑問ですがね。実は当初は通信屋さんにわかるようにプレゼンをしようと思ったのですが、当方の研究にとってこのコミュニティはお客さんではないので、そもそも理解していただいてもメリットはないのです。このため通信屋さん向けの説明は抜いてしまいました。

2008年6月11日

国際会議(FORTE'08)に出席。といっても開催場所は田町。ということで感じが出ません。発表は明日なのですが、日本開催なのに日本からの採録されたのは当方だけというお寒い状況。そのうえ当方にとってこの会議は専門というわけでもないです。

2008年6月10日

パシフィコ横浜で開催されたGoogleのデベロッパーカンファレンスに行ってきました。先月末に開かれていたGoogle I/Oの発表のままなので新味の情報はまったくというほどなし。ということで当方は講演などはそこそこに、米国側のGoogle関係者といろいろディスカッション。当然、肝心なことはしゃべらないのですが、Googleの強さと弱さの両方をたくさん垣間見ることができました。その一部を書くと、例えばApp Engineもよくできていますが、Googleは自らのサービスではなく、広告収入という間接ビジネスで利益を得ているので、サービスそのもので直接的に利益を得るという発想も希薄だし、App Engineで稼働するサードパーティ製サービスへの課金については逆に相談される始末。Googleはクラウドコンピューティングでは数少ない有力会社ですが、サービスそのもので儲けるつもりの会社にとって、Googleのクラウドコンピューティングのインフラ提供サービスは使い勝手はよくないかもしれませんね。その意味ではソフトウェアや商品などの販売という直接ビジネス主体のMicrosoftやAmazonの方が向いているかもしれません。ところで以前、Googleはサービスの数を増やしすぎではないかという疑問を抱いていたのですが、関係者にいわせるとサービスでも簡単に始められるという魅力がGoogleの就職希望者が多い理由なので、社員のモチベーションを維持するために完成度の低いサービスでも始めさせてないと、社員の不満がたまることになるそうです。ご存知のようにGoogleは優秀な社員をたくさん抱えていますし、有名な20%ルールもいいですが、社員の優秀さ、というか優秀な社員たちを満足させるために、Googleが自滅しないことを祈りたいです。

2008年6月9日

慶大の大学院授業、それからオフィスに戻って仕事です。徹夜に近い状態だったので眠い、眠い。実は授業中も眠くて意識がところどころなかったような。さてAppleのiPhone 3Gがいよいよ発表。個人的にはiPhoneにはあまり関心がなかったのですが、199ドルというお値段にはびっくり。国内で2万円を切れば惹かれるものがありますね。その分、通信費は高そうですが。いずれにしても国内でも発売直後は潜在的ユーザが飛びつくでしょうが、問題はそのあとですよね。米国ではiPhoneを買いそうなユーザはすでに2G対応をiPhoneを持っていますし、2Gの携帯電話でも困らない。国内ではiPhoneよりもiPod Touchが先に発売になったため、iPhone 3Gを買いそうなユーザはiPod Touchをすでにもっているでしょうから、さらにiPhone 3Gを買うかはやはり疑問ではないでしょうか。というわけで話題のわりに売れないと予想しています。ただ、携帯電話ビジネスにおけるiPhoneの影響力というか、破壊力は大きいです。それと開発プラットフォームとしては気になりますよね。いくつかの携帯電話向けのプラットフォームがありますが、携帯電話とPCが一番近いのはiPhoneの開発プラットフォームなので、PC側のアプリケーションを取り込むという点でも影響力が大きいです。

2008年6月8日

新国立劇場でオペラ「椿姫」を観劇。いい出来でした。「椿姫」はヴィオレッタ役がすべてといってもいい演目なのですが、そのヴィオレッタ役を演じたソプラノ歌手Elena Mosucが歌唱力、声量だけでなく、感情表現までいい出来でした。ちなみにElena Mosucですが、昨年の3月にチューリッヒ歌劇場で「魔笛」の夜の女王様役で聞いてみるのですが、そのときも好印象だったのですが、今回もよかったですね。ドイツ語圏でもハイレベルなチューリッヒ歌劇場でドイツ語オペラの代表作である「魔笛」、その夜の女王様役を演じるぐらいですから、実力は相当あるのでしょうが、椿姫のヴィオレッタ役にはいいですね。新国立劇場の「椿姫」は数年前にも観ており二回目のはず。正直いって前回はあまりいい印象がなかったのですが、今回は明らかに水準があがっていますね。さて2007-2008オペラシーズンも終わりに近づいていますが、今シーズンは今回の椿姫を含めて12オペラをみたのですが、演目を含めてトータルでは今回の「椿姫」が一番よかったかもしれません。今年は観たオペラはマイナー演目が多かったのですが、定番演目にはやはりオペラとしての良さがありますね。特に椿姫は有名アリアがいっぱいですし。今日のカーテンコールでは、ブラボーという声に混じって、日本語で「ありがとう」と叫んでいる人が結構いたのですが、すばらしいオペラに「ありがとう」でした。

2008年6月7日

ぐったりしています。休日出勤したかったのですが、さすがにぐったり。ということで家でおとなしく論文査読。今日はACM Multimedia 2008の投稿論文。マルチメディアのような派手系な分野は専門でないのですが、 ACM Multimediaはプログラム委員になっております。そのうえ今週と来週は理論系の研究者になっていないといけないので、頭の切り替えがつらいですね。ところでNHKで環境問題の特集がやっていました。ところどころ観ていたのですが、当該分野の学者は将来予測などにきわめて慎重な言い回しに徹していましたが、司会者などがそれを断言に変えてしまっていて、いろいろな意味で考えさせられる番組でしたね。最近はなぜか環境問題絡みに関わることになっていますが、当方は二酸化炭素が増えているようなので、それを減らした方がいいとは思います。ただ、その二酸化炭素が増えたことによる影響については専門家ではないのでなんともいえませんし、その影響を予測する立場ではありません。

2008年6月6日

今日もオープンハウスですが、取材や来客への対応でオープンハウスどころではなかったというのが実情でした。勤務先のオープンハウスは招待ベースではないので、一般の方もおいでになりますし、説明のターゲットが絞り込めずなかなか難しいですね。というわけで日中はオープンハウスなので、オープンハウスが終わった後と行き帰りの電車で、国際会議のカメラレディ論文を書き上げ。それにしても時間を見つけるのがたいへん。

2008年6月5日

今日からオープンハウスですが、午前中は特許事務所で相談。午後は取材への対応。さて今回のオープンハウスではちょっと変わったテーマの研究を出すことにしました(といってもWebには情報がありません。まぁ2週間前の報道発表ネタですが)。コンピュータサイエンスがある程度成熟した現在、コンピュータサイエンスの探求を続けても大きな成果は期待でないのではないでしょうか。今後はコンピュータサイエンスの技術を、コンピュータサイエンス以外の分野に応用するかが焦点になるはずです。ただ、研究成果を他分野に応用するといってもすぐに応用できるわけではありません。当方の場合、ここ数年はユビキタスコンピューティングの研究をしてきましたが、別にユビキタスコンピューティングそのものに興味があったわけではありません。ユビキタスコンピューティングは現実世界とリンクしているので、コンピュータサイエンスの現実世界への応用を探せるからでした。実際、応用先とのコネクションはそれなりにできたように思います(もちろんまだまだですが)。ところで最近、コンピュータサイエンス系の学部の卒業生が、情報系企業以外に就職先がないことが問題になっています。コンピュータサイエンスはセカンドメジャーとして学ぶべき学問なのに、そのコンピュータサイエンスしか勉強しなかったとしたら、情報系から逃げれなくなるのは当然です。かわいそうだけどあきらめてもらうしかないです。ただ、この問題は研究者にも当てはまるかもしれません。コンピュータサイエンス以外の分野への応用にコンピュータサイエンス研究の主眼が移ると、実際的な応用先が見つけられる研究者とそうではない研究者で運命を分けることになりそうです。

2008年6月4日

物流の業界団体で講演。コンピュータサイエンスの数学のように真理を追究するような学問ではない。このためコンピュータサイエンスの研究は何らかの役に立たないと存在価値がありません。ということで研究成果を使っていただけるところにいって研究を説明するしかないです。具体的な応用を想定した研究をするにしても、現場の方のコメントをもらわないと独りよがりの研究になってしまいます。というわけでも応用分野から声をかけていただいたときは、手弁当で講演させていただいております。また、取材に関しても他分野のメディアから取材要請はお断りしないことにしています。ところで明日からオープンハウスなのですが、それどころではないかも。

2008年6月3日

それにしても忙しいです。昨夜は徹夜仕事だったので眠いのですが、今日は勤務先の大学院の授業。担当は今月と来月だけだけなのでいいのですがね。すでにオーバーフロー例外が発生していますが、それでも処理を続けています。

2008年6月2日

午前中は慶大授業、午後はオフィスで仕事です。すでに仕事がスタックオーバーフロー状態です。どうせならばゼロ除算例外でハングしたいです。

2008年6月1日

Googleの開発者向けカンファレンスが開催されているため、Googleまわりが騒がしいのですが、App Engineの一般公開やAndroidの技術情報が公開されたようですね。さてAndroidですが、ベースがLinuxというのは知られていましたが、今回公開された資料をみると相当カスタマイズされていますね。携帯電話の場合、電力管理が重要なのですが、商品化されているLinuxベースの携帯電話の省電力チューニングと比較するとまだまだ甘いのですが、海外携帯電話の場合、端末の厚さなどは気にしないので、大容量バッテリをつめるという算段なのかもしれません。それとAndroidのJavaは、仮想マシンがスタックマシンベースではなく、レジスタマシンベースだそうです。これは比較的知られたアイデアなのですが、ただプロセッサのレジスタを直接使えるのでプログラムの実行は速くなりますが、多様なプロセッサに対応するには、プロセッサに対する抽象度をあげないといけない。そうなるとプロセッサのレジスタをフルに使えるわけではないので、そのトレードオフが難しくなります。また、当然、Javaのバイトコードとの互換性はなくなります。こうした高速化は有効なのですが、現状での携帯電話向けのプロセッサでは、ハードウェアレベルでJavaのバイトコードを向けのアクセレター機能をもっているので、あえて仮想マシンのレジスタマシン化をしなくてもいいはず。Googleの意図としては特定ハードウェア機能に依存しないプラットフォームにしたかったのでしょうが。いずれにしてもどちらがいいかは消費電力しだいかもしれません。

2008年5月31日

休日出勤です。それにしても忙しいですよね。そうそうオフィスのメインマシンをMacProに以降。正しくはMacProからMacProへの移行なのですが、やはり8コアマシンは速いです。というか事務仕事で8コアを使い切れません。

2008年5月30日

今週は日経産業新聞(27日)と日刊工業新聞(29日)や、複数のIT系のWebニューサイト(ITmediaなど)に当方の研究に関する記事が掲載されたことから、その問い合わせや取材申し込みへの対応に追われる一週間になってしまいました。来月は「研究者としてひっそりと生きる」を実践したいですが、来週も取材が3件あるし、すでに無理そうですがね。そういえば来週の木・金曜日は勤務先のオープンハウスらしいですが、期間中は取材対応や霞ヶ関対応(来年度概算要求)で手一杯が確定。毎年、この時期になると霞ヶ関から、来年度の概算要求の相談を受けるのですが、省庁もネタ切れですよね。二つの省の方からほぼ同じネタで相談を受ける始末。アイデア出しやコメントなどは協力しますが、7月後半あたりから各省庁から頼まれる政党の部会向けや財務省向けの説明資料作りへの協力は遠慮させていただいております。

2008年5月29日

午前中はISOのRFIDタグ/バーコード委員会の総会。それにしてもRFIDタグはどうなるのでしょうか。RFIDタグに熱心だった企業でも撤退するところが続出しているのが実情。工場内の生産管理や書類や図書管理などの閉じた事例はいいとしても、小売り系は全滅に近いですよね。結局、誰がタグの貼るのかという基本的なところで同床異夢ですからね。さて話は変わってMiscrosoftのソフトウェア系の開発者会議のPDC2008のプログラムの公開されました。そのセッションを見るとMicrosoftは一気にCloud Computingに舵をきりましたね。一方のAppleの開発者会議のWWDC2008はiPhoneやMacintoshの開発ばかり。つまりMicrosoftはCloud Computingのインフラで動くサービス開発にフォーカスしていますが、Appleはパソコンやスマートフォン上で動くソフトウェア開発にフォーカスしています。このままだとApple系のソフトウェア開発者は時代に取り残されますね。Appleはいまは全盛かもしれませんが、いつの時代も優秀なプログラマーは先端のソフトウェア実行環境に集まりますから、Appleまわりでは開発者の流出が進みそうですね。

2008年5月28日

安藤忠雄氏の講演を早大で聞く。実は当方のところので博士課程学生ですが、博士論文の中間発表を早大でもすることになり、早大に出かけたついでに講演をきいてみました。4月に東大入学式での安藤氏の(過激な)講演が話題になっていましたが、確かに入学式や入社式での講演としては彼はもってこいですね。建築家としてはユニークな経歴に注目が集まっていますが、相当基礎訓練をしているようですね。また、司会の早大の建築学科の先生が講演前に「彼は努力を見せない天才なので、自分も真似できると思うな」と釘を刺していたのが印象的でした。さて話は変わって、IT業界のこと。IPAはまたやってくれました。昨年、IT業界の重鎮と理系学生による討論会を企画したのですが、その重鎮のひとりが、IT業界の3K(きつい、帰れない、給料が安い)に対して、「3Kの帰れないは、帰りたくない人が帰れないだけ。」と発言して物議を起こしたのですが、今年もIPAは討論会を開催。今回は主催したIPAの理事長(NECの元社長)が「入社して最初の10年は泥のように働いてもらう」と発言したそうです。終身雇用制が崩壊しているなか、まだこんな発想をしている人がいるのですね。さらに「仕事をするときには時間軸を考えてほしい。プログラマからエンジニア、プロジェクトマネージャになっていく中で、仕事というのは少しずつ見えてくるものだ」という発言もあるのですが、この方の頭の中では、プログラマはエンジニアよりも下の存在で、そのエンジニアはプロジェクトマネージャより下の存在という意識なのでしょうね。個人的には職種に序列をつける発想は違和感を感じますがね。ちなみに今年の討論会の 案内には「業界トップの方がITプロフェショナル技術者のあり方として、如何に高度で重要な技術者であるかを明示することが、学生のIT業界の認識および就職人気の向上につなげることを目的としています。」と書かれています。たしかに学生さんにIT業界がどのような体質なのかを認識させるのには成功したのではないでしょうか。もっとも就職人気の向上に寄与したかは疑問ですが。

2008年5月27日

今日は早朝出勤です。いろいろ業務があり、それにとられる時間を考えると早朝ぐらいでないと時間が捻出できません。さて昨日の続きですが、GoogleはCloud Computingという観点から見ると、Googleは分割を求められるかもしれませんね。GoogleはCloud Computingのサービス提供インフラを保有しつつ、gmailをはじめとしてサービスそのものも開発・提供しており、そして収入源は広告収入に依存しています。これは日本の民放TV局に似ています。日本の民放TV局は、TVCMという広告から収入を得て、サービスに相当する番組を制作しつつ(下請けに投げるだけですが)、放送というインフラをつかって、その番組(サービス)を提供しています。一方、海外のTV局は、TVCMで収入を得ていますが、番組制作は最小限にとどめて、その代わり番組制作会社から番組を買って、それを放送しています。つまり、海外TV局は番組(サービス)と放送(インフラ)は分離されているのですが、日本の民放TV局やGoogleは、サービス(番組)を自ら制作するとともにそのサービス提供インフラ(放送)も保持しています。日本の民放TV局の放送と番組制作が分離されていないことが、コンテンツの再利用を阻害していますが、これと同じ問題が起きるでしょうし、さらに独占禁止法などの縛りをうけて、Googleは現状のようにサービス開発とサービス提供インフラのどちらか一方を捨てるまたは分割させられ、Googleは後者のサービス提供インフラをとるのではないでしょうか。いずれにしてもCloud Computingを立ち上げるには、サードパーティのサービス開発会社の協力は不可欠なのですが、今の状況は放送局(Cloud Computingインフラ提供会社)が自ら番組を制作・提供しながら、その空き時間でサードパーティの番組制作会社(サービス開発会社)が作った番組(サービス)を放送しているような状態。これではサードパーティのサービス提供会社の協力は得られません。そして両方を維持した場合ですが、MicrosoftのOSとアプリケーションの独占問題と同様に、GoogleがCloud Computingインフラで一人勝ち状態になると、サービス提供インフラとサービス開発の両方を提供していることが独占禁止法上の問題になるかもしれません。

2008年5月26日

慶大の大学院授業です。今日はビデオを流したりと楽させていただきました。ところでgmailを使っていますが、最近はgmailのページを開いたときに、サーバの問題(過負荷?)で待たされることが多くないでしょうか。サービスの拡大にサーバの処理能力が追いついていないのでしょうか。それにしてもGoogleはちょっと手を広げすぎではないでしょうか。Googleはお金もインフラもあるので、思いつきレベルのアイデアでも始められるのでしょうが、最近のGoogleは思いついたままでリリースしている感じで、社内選別メカニズムは機能しているのでしょうか。また、その始めてしまったサービスも発展しないものも多いところをみると、市場調査不足に加えてマネージメントにも問題があるのかもしれません。この問題ですが、お金とインフラがありすぎるというGoogle特有の事情があると思いますが、広告収入モデルの問題にも見えます。サービスの開発・運営費を広告収入で賄うのは、サービスに対する直接の対価ではなく、あくまでも間接的に得られる収益です。このためGoogle全体としての広告収入が得られれば、個々のサービスの収益性の評価は甘くなりがちです。また、広告収入モデルの難しさは、サービスのクオリティと広告収益が一致しないことにあります。つまりサービスのクオリティが高いからといって、集客性があるとは限らない。例えば年に一回しか使わないような機能は、たとえ重要でも広告収入は稼げません。そうなるとサービスのクオリティがあげるというベクトルは働かないので、だらだらとサービスを続けることになりそうです。

2008年5月25日

Springerから論文のソースを送ってほしいというメールが来たのですが、不思議に思って聞くと、以前投稿していたSpringerのジャーナルが採録になっていて、掲載用に原稿がほしいらしい。でも採択通知がまだなのですがね。Springerの問題ではなく、そのジャーナルの編集委員会の問題でしょうが。Springerもそうですが、ACMやIEEEもジャーナルが増えていて、ジャーナルによっては編集委員会がしっかりしていないところが多いですね。ACMに投稿中の論文は1年以上、店ざらし状態にされています。ジャーナルといえば隣国でSpringerのLecture Notes in Computer Scienceをジャーナル(論文誌)扱いにしなくなってから(当たり前です)、査読期間が短いことをウリにしているジャーナルがいろいろできでいるようです。当方は幸い、こうしたジャーナルのお世話になることはないのですが、こうしたジャーナルの中には査読がひどいものがあると聞きます。すごい例ではIJCSNS(International Journal of Computer Science and Network Security)というジャーナルがあるそうですが、このジャーナルにいたっては採録から投稿締め切りから出版日までの10日間かからないそうです(5月25日が投稿締め切りで5月30日に発刊ということは5日間！)。いったいどんな査読をするのでしょうかね。学生さんが博士論文の論文数などで焦って、こうしたジャーナルにすがりそうですが(個人的にはおすすめはできません)、こうしたジャーナルを博士論文基準にカウントするかは大学の見識になりそう。さらにプロの研究者でもこうした雑誌に出している人は多いそうです(確かにWeb検索するとたくさんの日本人研究者がジャーナル論文実績にされているようですね)。もちろん、こうしたジャーナルに投稿するか否かは研究者本人の判断ですし、採録までの期間が短いからといって査読がひどいとはいえませんから、当方はこれ以上はコメントする立場ではありません。ただ、こうしたジャーナルは一つ違うと怪しい博士授与大学からの博士号と大差ないことになりかねないわけでリスクはありますよね。いずれにしてもジャーナル論文も安くなったものです。

2008年5月24日

今月、Princeton大学にいったときの写真をWebにおいておきます。アメリカでは4番目に古い大学。用務は近くのRutgers大学(ニュージャージ州立大学、こちらはアメリカでは8番目に古い大学)だったのですが、先方の大学の方に連れて行ってもらったのでした。確かに歴史ある大学で、古い建物もありましたが、ただ新しい建物も古い建物とテイストをあわせて作ってあるので、どこまで古くて、どこからが新しいのかがよくわからないという状態。学生さんが芝生で談笑しながら、勉強している様子はまさにアメリカの大学のイメージそのものですね。Ivyリーグの一つだけ会って、授業料は高そうですね。学生さんが金持ちそう。用務先の州立大学とは別世界です。Webにおいた最後から2枚目の写真はかつてアインシュタインのオフィスがあった建物です。

2008年5月23日

今日も半ば徹夜。さらに始発電車で出勤してお仕事。さて昨日は特許出願。といっても弁理士さんに出願処理をしてもらったわけですが、そして今日は報道機関の方に来ていただいて報道発表。なんか怒濤の一週間でした。でもカメラレディ論文×２本の仕上げとインタービュー記事のチェックが残っていますが。さて報道発表(発表資料はこちら)は、タイトルや研究目的だけ見るとかなりトンデモ系に見えますが(ちなみにタイトルは事務局からいただきました)、適応可能事例を調査して、実現上問題になりそうなところはかいけつしてありますから。この研究ですが、5,6年前にやっていたネットワークの経路制御に関する研究で、アクティブネットワークと呼ばれる方式向けのプログラミング言語を作ったのですが、それの物流に応用しようという話。ネットワーキングと物流は大きく違っているように思われるかもしれませんが、そもそもインターネットの経路制御は物流の配送システムを真似てつくられたので、逆に経路制御用に開発された技術を物流に応用できるはずですよね。このため実はネットワーキングの研究といいながら、変な言語を作っていたのは研究当時から物流狙いだったのです。元になったネットワーキングの研究では研究予算獲得(JSTさきがけ研究21)をいただいたり、ネットワーク管理は最高峰の海外論文誌(JNMS)に通してあるのですが、研究助成も学会も非常に保守的ですから、過去に例のあるような研究でない予算は出してくれないし、論文も通してくれません。なので本当の狙いは隠して研究をしてきたの実状だったりします。なかなかつらいところです。研究助成機関や学会はともかく、世の中の方はすでに変わってきているので、今回はまずは報道発表で世の中の方で先に出してみたのです。よく論文が国際会議や論文誌に通らないと嘆いている研究者が学生さんがおられますが、その研究がダメなのか、その研究が先に行きすぎているかのどちらかです。前者ならダメダメなのですが、後者は投稿するタイミングを考えるか、別分野でその研究を論文にした方がいいと思います。スジがいい技術というのは特定の分野とは限らず、いろいろな分野で使えるのではないでしょうか。個人的には、ネットワーキングと物流を区別していないのと同様に、物理世界と仮想世界の区別をつけないようにしています。いい技術はどちらでも使えるはずです。

2008年5月22日

今日は3時間睡眠。さすがに眠い。ところで東急田園都市線＆東京メトロ半蔵門線(相互乗り入れ)を使っているのですが、毎朝遅れます。でも遅れる理由は明らかなように思います。まずは田園都市線＆半蔵門線＆東武伊勢崎線が相互乗り入れ、つまりひとつの電車が神奈川県の真ん中から栃木県近くまでいくことになります(98kmらしい)。そんな長い距離を走ったら、遅れる可能性は大きくなります。せめて相互乗り入れは田園都市線＆半蔵門線または半蔵門線＆東武伊勢崎線にしてほしい。また上下線の一方でおきた遅れが、すぐに上下線に広がります。この原因は半蔵門駅にあります。朝などは田園都市線の中央林間(または長津田)発半蔵門線止まりの電車が何本かあるのですが、この電車は半蔵門線の折り返し線にはいったあと、中央林間方面電車になります。しかし、中央林間本面が遅れると、折り返し線に前の半蔵門線止まり電車が折り返し線にはすでにいっているので、半蔵門線止まりの電車は折り返し線に入れず、ホームで立ち往生。そうなると後続の押上本面の電車まで遅れます。結局、上下線ともに遅れが広がり、それが半蔵門駅ますます増幅されます。また、押上駅では線路が４本あることもあり、東武線または半蔵門線で遅れが出た場合、押上駅で乗り入れを中止するそうですが、渋谷駅では２本しかないので、田園都市線または半蔵門線で遅れが出ると、そのまま田園都市線と半蔵門線に広がるらしい。渋谷駅の拡張は考えないのでしょうか。いずれにしても半蔵門線はシステム設計を間違えていると思うのでした。

2008年5月21日

完全に徹夜状態で資料作成。ところで雑誌「広告批評」が休刊するのですね。学生時代から毎月ではないにしても年に数回は買っていた雑誌なので残念ですね。編集長のインタビュー記事がWebに出ているのですが、さすがに広告業界の重鎮ですよね。なかなか興味深い内容。一読に値します。そのインタービューで「ウェブ広告はインフォメーションですよね。表現性は全然問題にならないレベル」という発言があるのですが、確かにその通りですよね。またWebが広がるとともにTVCMなどのマスメディア広告は「あいさつ機能」化というのも確かにその通りなのかもしれません。ただ個人的にはまだまだマス広告は強いように思っています。このインタビュー記事にはふれられていませんが、携帯電話のワンセグがマス広告とWeb広告の架け橋になるかもしれませんね。通勤中などにワンセグ放送を見ている人が増えていますが、そうすればテレビの視聴時間は伸びることになりますし、それに加えてワンセグの場合、Web広告へのリンクが貼れますから、ワンセグ放送上のマス広告とWeb広告の融合もありえるかもしれません。個人的には携帯電話のフルセグ化、つまりHDTV化は必要性を感じないのですが、フルセグ化することでTVCM広告効果があがる、またはWeb広告への誘導が促進されるのであれば、携帯電話のフルセグ化は意外に早くすすむように思います。いずれにしても携帯電話向けフルセグ受信機は小型化、低消費電力化、安価化がすすみますから、カラー液晶を積んだ機材ならばおまけとしてフルセグ、つまりHDTVがついていることもありえると思います。話はもどりますが、コンピューティングも将来はTVと同様に広告収入モデルが大きな比重をしめることになるわけで、広告業界の動向を知っておくことは、次世代コンピューティングを予想する上では重要です。

2008年5月20日

なかば徹夜状態で資料作成。いろいろたいへんです。もうぐったり。疲れました。でも今週は寝ている暇がないのがつらいところです。

2008年5月19日

慶大理工の大学院授業。それからオフィスに一瞬だけよって、早大理工。今週は某イベントの準備、特許出願、プログラム委員長になっている国際会議の論文採択、カメラレディ論文３本の仕上げ・・・、と大忙しです。ということで今週は怒濤の一週間になりそうです。

2008年5月18日

ネット規制や携帯電話の規制が話題になっています。例えば小中学生が学校裏サイトにアクセスすることが問題だからといって、そうしたサイトを安易に規制すると表現の自由の侵害になりかねない。個人的には対抗策はスパムにはスパム。ゴミ情報にはゴミ情報なのだと思っております。裏サイトを法律的に規制するより、そうしたサイトには大量のスパム書き込みをする。そうすれば悪意をもった書き込みを見つけるのもたいへんになりますし、そもそもスパムであふれたサイトを読む人は減りますから。もちろん技術的にも社会的にも解決すべき問題がいくつかありますが、いずれにしても一度発せられた情報を消すことは難しいのですが、その情報をノイズでかき消すことは容易です。ネット規制に関しては、優秀な技術者や研究者がネット規制反対の立場でブログなどを通して活発に意見表明や議論をされています。もちろん意見表明や議論も大切ですが、やっぱり技術屋ならば、(反対されているネット規制以外の方法で)有害サイトを無効化する方法を考えた方が建設的ではないでしょうか。

2008年5月17日

政府の教育再生懇談会は「小中学生に携帯電話を持たせない」という提言を出しているそうです。理由は有害サイトにアクセスする危険があるからだそうです。つまり、ある道具を使うと事故がおきるかもしれないので、その道具を禁止しましょうという発想。つまりハサミやカッターは使い方によっては怪我をするかもしれないので、ハサミやカッターの使用禁止しましょう、ということですよね。教育再生懇談会は教育再生会議の後継委員会のようですが、この程度の発想しかできないのですかね。そんなに有害サイトが心配ならば、まずは有害サイトの方を取り締まればいいことであって、道具である携帯電話を制限するのはなんか違和感を感じます。もちろん現状は有害サイトが小中学生に急速に広がって収集がつかないという側面があるので、一時的に携帯電話側を規制するというのは一つの方法かもしれません。でも結局は有害情報が携帯電話以外のメディアに逃げるだけなので根本的な解決にはならないのではないでしょうか。個人的には、むしろ小中高校生のメールの使いすぎというか、友人間でメールへの即答がなかば義務化している状況を改善してあげたい。ほとんどメール中毒といっていい状態ですよね。彼らのメールの返信に追われるような人生をみると、いまの中高校生でなくて本当によかったと思います。

2008年5月16日

いろいろ忙しいです。仕事量が処理能力を超えている感じ。ところで先週の出張(Rutgers大学)の写真をWebにおいたのを忘れてました。最後のStarbucksの容器は期間限定でオリジナルマークの復活だそうです。厳密には人魚の髪の長さが違うそうですが。

2008年5月15日

RFID関連の見本市にいったのですが、所詮狭い世界なので(売れていないので、市場が狭い、だから顔ぶれが変わっていない)、数分おきに知り合いにあう始末。同じ会場でソフトウェア開発環境と組込コンピュータの見本市もやっているのでよってみる。前者は人が多かったのですが、後者は盛り上がりがいまひつですね。後者は会場も広いので人数的には同じようなものかもしれませんが。さて組込コンピュータですが、こうした見本市ではTRON関連の展示が多かったのですが、少なくなりましたよね。それとLinuxも展示しているところは少なくなりました。こちらは当たり前になったのかもしれませんが、この見本市に関していうと大手の組込Linuxのディストリビュータで展示していたのはMontaVistaぐらいで、そもそもこの見本市が魅力がないのかも。

2008年5月14日

Windows Vistaは発売から一年以上たっていますが、新しい物好きのまわりの研究者を見ても使っている人は少ない。VistaはマイクロカーネルOSと同じ失敗をしたのかもしれませんね。マイクロカーネルOSと同じ失敗をしたのかもしれませんね。マイクロカーネルOSはカーネルが提供する機能を必要最小限にして、それ以外のOSが提供すべき機能はアプリケーション(ユーザレベル)で実現することにより、機能の変更や拡張可能にしました。しかし、通常のOSではカーネルで提供される機能も、カーネル内とカーネル外で切り替えながら実現するので、実行コストが大きくなってしまいました。しかし、ユーザは機能拡張や変更をするわけではないので、モノシリックOSに対して機能的な違いは見いだせない。ユーザはパフォーマンスが速いOSを求めますからから、どれだけアーキテクチャが優れていても普及しませんでした。さてVistaですが、リソース食いとパフォーマンスの悪さの原因は.Net Frameworkをベースにした高水準APIにありますが、高水準APIは開発者から見ると低水準API(WIN32)と比較してアーキテクチャ的に優れたものであったとしても、高水準APIは低水準APIを組み合わせたものに過ぎないわけで、低水準APIで実現できないような新しい機能をユーザに提供するわけではない。その一方で高水準APIは低水準APIと比べるとパフォーマンスは悪くなります。そうなるとユーザから見ると、高水準APIを導入したVistaは機能は低水準APIしかないXP以前と同じなのに、遅いだけのOSにみえてしまいます。もちろんVistaのGUIは？マークがたくさんですが、Microsoftの立場から見ると、Vistaは開発者から見たインターフェース、つまり低水準APIから高水準APIに変わっても、OSとしての機能そのものには進歩がないので、ユーザ側からみたインターフェース、GUIで進歩性を出そうとしたのかもしれませんね。だって、VistaのGUIがWindows XPのGUIと大差なかったら、機能は同じで見た目も同じで、ただ遅いだけのOSになってしまいますからね。ただ、Vistaはユーザに評判が悪いために、開発者たちも売れないOS、つまりVistaにあわせたソフトウェア開発、つまり高水準APIを駆使したソフトウェアを開発しようとしないのは皮肉な結果ですが。ただ、個人的には、高水準APIへの切り替えは避けては通れないステップなので、Vistaの不評は仕方ない事態だと思います。また、Vistaはリリースが遅れたわけですが、高水準APIでもそこそこの性能のPCが登場するのを待っていたとすると、リリースが遅れたのは合理的な判断とみることもできますね。

2008年5月13日

今日は博士課程の学生さんの中間発表。発表する学生さんもたいへんなのですが、こちらの方も気苦労が多いです。それにしても出張後は仕事がいろいろたくさんです。勤務先のネットワークは、Macintoshはつながるけど、Windowsはつながらないという事態に。DHCPでトラブルが起きているみたいなのですが、謎ですね。それも同じフロアーだけの問題みたい。ただ、同じフロアーの方々はMacintoshユーザが多いのでトラブルに気づいてもいない始末。もっとも当方もMacintoshなのですが、秘書さんのコンピュータはWindowsなので気づいたのでした。

2008年5月12日

ニューヨーク発便なので14時間の長旅。プレミアムエコノミーにアップグレーとしていただいたので電源確保。機内では2時間ほど寝たものの、それ以外はお仕事。論文執筆と、その論文用の性能評価プログラムの作成。もっともネットワークが絡む性能評価が必要なので、機内でベンチマークまではとれませんでしたがね。

2008年5月11日

いよいよ帰国の途に。ANAのニューヨーク発成田行きに搭乗。それにしてもアメリカ出張はつらいですね。さて今回の出張では、2000行程度のプログラミングと論文一本を書き上げる予定でしたが、どちらも中途半端。前者は設計を間違えて無駄なコードを乱造、後者は半分ほど書いたところ。あとは復路の飛行機ですね。それからもうひとつ今回の出張ではPythonを覚える(正しくいうと思い出す)というのが目標なのですが、こちらはだいぶ思い出してきました。頭の体操も兼ねて、毎年、一つ以上のプログラミング言語は覚えるようにしていますが、なんか最近は前に覚えて言語の復習ばかりで、言語の数が増えていません。

2008年5月10日

Rutger大学は全米では8番目に古い大学だそうですが、たしかにキャンパスによっては1800年代の建造物がいっぱいです。今日のように土曜日は大学ラグビーの試合があって、今回訪問したキャンパスの試合がある土曜日は車でいっぱいになるそうです。今回はスタジアムが工事中のようでしたがね。帰国の準備のためにニューヨークに移動。ニューヨークのメトロポリタンオペラで、オペラ「The First Emperor(始皇帝)」を観劇。始皇帝役はあの３大テノール歌手の一人、ドミンゴ(Domingo)。ストーリや曲に関しては？マークがかなりつく作品でしたが、ドミンゴがひとりでオペラとして維持している感じでした。お姫様役(Sarah Coburn)なかなかよかったですね(また昨年とは違う方だそうですが、あとのメンバーは去年とあまりかわりないようです)。指揮は作曲者自身のようでしたが、オーケストラ演奏自体はいいのですが、問題は曲がいまひとつなので、盛り上がりにはかけました。舞台や演出はさらに？マークが連発なのですが、唯一Wada Emiがデザインした衣装は東洋性と美術性のバランスをとったものですごくよかったです。おそらくアメリカ人からはオペラ作品という以前に、東洋的な雰囲気で楽しめるのでしょうが、ストーリーは稚拙というか、かなり無理があるし、楽曲的には善し悪し以前、歌は中国語ではなく英語で、さらに舞台もモダン風なので中国的な雰囲気は少ない。ということでドミンゴと衣装だけでもっていたような作品でした。去年、初上演されたときも評価がわかれたようですが、たしかに評価の難しい作品ですね。ただ、純粋にドミンゴの歌を楽しむのであればいい作品かもしれません。ドミンゴは声量もありますが、声質と(歌的な)演技力はオペラ歌手の中でも抜きん出ています。やはりドミンゴは3大テノールといわれただけはありますね(いまは2大テノール?)。それにしてもこの半年間で2回もドミンゴの歌を聴けるとは思いませんでした。贅沢ですね。メトロポリタンオペラも半年間で3回目。これもあり得ない数です。

2008年5月9日

今日もRutgers大学でワークショップです。さすがに質問をするのにも疲れてきました。それにしても無線LAN、それもRSSIをつかった位置推定や省電力制御の話題が多いワークショップです。ただ、今日の発表にRSSIはいかに不安定で使えないパラメータであるかという研究があり、この発表を先にやっておいてくれたら、一昨日や昨日他のRSSI絡みの発表はすべて無意味な研究ということになったのですがね。それにしても無線LANの研究は難しいですね。数年前までは無線LANはコンピュータ向け専用通信技術という位置づけでしたが、コンピュータ系の研究室でも手を出せましたが、携帯電話などの無線技術の主戦場と電波伝送的にも近くなっているので、コンピュータ系の研究室が無線LANでもRSSIのような物理層に近いレイヤーの話題に手を出しても、高価な測定機器やや電波暗室を持っている無線専門の研究室には絶対に勝てません。実際、今回のワークショップでも、大学、それもコンピュータ系の研究者による無線LAN関連の研究はレベルが低すぎ。おそらく無線系の会議だったら卒論発表としてもみても失笑レベルだったのではないでしょうか。もちろん、コンピュータ通信関連のトップ会議に採択される無線関連の論文でも、やはり無線を専門にしている研究者から見ると失笑レベルのものが多いそうですから、仕方ないといえば仕方ないのですがね。ところでRutger大学は学食の調理が本格的でおいしいですね。やはり研究のアクティビティにとって、食事のクオリティは重要かも。ところで米国に行くとiPhoneを使っている人が多いですね。それとiPod Tocuhを使っている立場からいうと、多くの人がイヤホーンをせずに使っていることがある意味、新鮮。つまりiPhoneを電話やPDAとして使っているということなのですが、やっぱり新鮮。ただ、個人的にはiPhoneはちょっとパスかも。むしろiPhoneはAPIの公開に踏み出したということの方が重要かも。iPhoneにしてもAndroidにしてもほとんど全部のAPIを公開したのですが、これまでの携帯電話はJavaやFlashのアプリケーションは独自開発はできるにしても、公開されているAPIはごく一部なのでゲームがせいぜい。その状況を打ち破ったのは大きな意味を持ちますね。さて問題なのはAndroidの方。JavaベースのAndroidはネイティブベースのAPIよりは遅いのですが、携帯電話はレスポンスが要求されますから、どの程度受け入れられるでしょうか。

2008年5月8日

今日もワークショップです。そして60分の講演。オーディエンスの背景知識がわからないので、すごく話しにくい。さてワークショップは質問をするのが仕事のような状態になっていますが、他の講演の多くは無線関連で、質問をするのもなかなかたいへん。誰も質問をしないので、手を挙げてから質問を考える始末。それにしてもフィンランド人の研究者は日本人研究者並におとなしいですね。ほとんど質問をしないです。もちろん、むやみに質問をされるのも困りますが、無反応なのも困りものです。

2008年5月7日

Rutgers大学(ニュージャージー州立大学)でワークショップ。Rutgers大学関係者とHelsinki大学、Helsinki工科大学の関係者がメイン。6時過ぎにPrinceton大学訪問。メインのキャンパスやアインシュタインのオフィスがあったキャンパスなどを訪問。イギリスの古い大学のような雰囲気。ただし、古いといってもアメリカの基準で古いということになりますが。いまいるのはニュージャージーですが、サンフランシスではJavaOneを開催中。Java自体はJavaFXぐらいしか話題がないのですが、もりあがっているのでしょうかね。そのJavaOneでSun MicrosystemsのCOEの講演の記事が出ていましたが、COE曰く「ソフト価格で許されるのは無料だけ」だそうです。つまりソフトウェアはサービスやハードウェアを売るためのオマケ。でもそのオマケがないとサービスやハードウェアは売れないそうです。いちおうそのソフトウェアの研究を仕事にしている立場からいうと、いろいろ複雑。ある意味、当たっているところはありますが、逆に言うとソフトウェア専業メーカはやっていないということですよね。Sun Microsystemsのようにデータセンター向けのハードウェアやサポートで収益があげられる企業はいいの、ですが、ソフトウェア専業メーカーはソフトウェアを作って売ることしかできないわけで、そのソフトウェアが無償になったら儲かりません。ハードウェアやサポートを売るためのインセンティブになっても、ソフトウェアに対してハードウェアやサポートによる収益を超えるような研究開発には及び腰になるでしょうから、今後はソフトウェアの研究開発は長期的には停滞していきますよね。

2008年5月6日

ひたすら移動です。長い一日になりそうです。ところでSun Microsystemsに続いて、Microsoftもデータ・計算センターの設備をラックから(貨物用)コンテナに移行しているようですね。従来はコンピュータを何枚もさしたラックを管理単位にしていたのですが、コンピュータの数が多くなるとラックでは管理も煩雑だし、場所も食いますからね。多数のサーバ類は製造段階でコンテナに格納し，コンテナごとデータ・計算センターに搬入して，コンテナ単位で冷却を行うそうです。Cloud Computingが普及すると家庭やオフィスの計算やデータ管理はCloud Computingのインフラに任せてしまうので、サーバを個人や一般企業が購入・運用することは皆無になってしまうかもしれません。そうなるとサーバというハードウェアのマーケットはCloud Computingインフラ向けだけとなってしまう。つまりコンテナが主体になってしまって、いまのようなサーバ用コンピュータ単体やラックは見なくなるかもしれませんね。ちなみにCloud Computingのインフラというのは広い敷地にコンテナが整然と並んでいるような風景なのでしょうか。そしてコンテナの中にあるサーバが調子悪くなったら、コンテナごとフォークリフトでトラックに乗せて、メーカのサービスセンターに送るのかもしれません。こうかくと冗談っぽく聞こえますが、かなり現実味を帯びているから怖いですね。

2008年5月5日

午前中はオフィス、午後は新国立劇場でオペラ「軍人たち」をみる。欧州のオペラハウスの演出を引き継いだようですが、まさに最近の欧州オペラではよく見られる前衛的演出、舞台、衣装。歌手も非常にいい出来でヒロイン役(マリー役)のVictoria Loukianetz、男爵役のPeter Hoareは退廃的な役所なのですが、うまく歌いきっていました。また演奏は新日本フィルハーモニー交響楽団ですが、現代音楽調の難曲を見事に演奏して非常によかったです。この水準のオペラを国内で見られるとは思いませんでした。藤原歌劇団や二期会はいいオペラ団だとはおもいですが、収益性が求められるので、こうした前衛的な作品は取り上げない。欧米オペラ座は自国では前衛作品を取り上げますが、来日公演ではこうした演目はさけるのが常。やはり日本では新国立劇場ではないと上演できない演目だったのではないでしょうか。ただ、このオペラは良くも悪くも通好みなので、オペラらしい作品を見れると思った方は唖然だったと思います。

2008年5月4日

速報という形で報道されていますが、MicrosoftはYahoo!買収を撤回したようですね。これでYahoo!株は大幅に下がるでしょうから、Yahoo!株主は大損害なわけで、Yahoo!経営陣の解任動議に動くはず。そうなるとYahoo!は経営陣と株主のあいだで内紛状態になります。Microsoftにしてみれば、Yahoo!内紛で株価が下がったところで、値切ったうえで再度買収を提案してもいいわけで、買収するにしてもここ撤回発表するのが正解ですね。買収発表があったときのこのページでも書きましたが、Yahoo!経営陣は断る理由などないはずなのですがね。Yahoo!経営陣はいったい何を考えているのでしょうかね。仮に将来にわたってMiscorosftが買収してくれない場合ですが、今回以外の買収騒動とリストラ騒動で嫌気をさしてYahoo!を辞めた社員は少なくないはず。そうなるとYahoo!は技術的にも営業的にも力が落ちているはずで、起死回生の策でもない限りはジリ貧になっていくのではないでしょうか。さて日本のヤフーはYahoo!とは独立しており、今回の買収騒動では蚊帳の外ですが、Yahoo!が内紛に陥って陰りがみえてくると、国内のヤフーのブランド力も下がりかねないので、今回のMicrosoftの買収撤回はグッドニュースではなくバッドニュースでしょうね。

2008年5月3日

Cloud Computingに将来性があるかについて問い合わせをうけたのですが、個人的にはCloud Computingの特徴はスケラビリティーなどいろいろあるとは思いますが、個人的に一番重要だと思っているCloud Computingがフォンノイマン型アーキテクチャに近いこと。Cloud Computingの場合、超巨大なインフラに、データも手続き(プログラム)の両方をおいて、その手続きでデータをアクセすることになります。一方、フォンノイマン型アーキテクチャはデータと手続き(プログラム)を一つのメモリに入れますから、Cloud Computingのインフラを一つのコンピュータと考えれば、Cloud Computingはフォンノイマン型アーキテクチャに極めて近いことになります。いままでもWebサービスなどの類似した試みはいっぱいあったのです、データと手続きは別のサーバに置かれることが多い。ご存じのように非フォンノイマン型アーキテクチャはいままで数多く提案・試作してきましたが、性能的にも価格的にもうまくいった試しがない。もちろん単体のコンピュータと、Cloud Computingのようなネットワーク上のサービスインフラは違うのですが、やはりサービスを定義するプログラムがデータと手続きから構成される限りは、フォンノイマン型アーキテクチャの呪縛からは抜け出せないのではないでしょうか。

2008年5月2日

今日は会議の日です。ところでRuby関連の研究の相談を受けたのですが、こちらとしてはコメントする立場ではないし、こちらがコメントしてもそれを聞くわけでもないでしょうから黙っていましたが、いまさらRuby はどうなのでしょうか。2年ぐらい前、Ruby on Railsが登場したときはエキサイティングな言語という感じがありましたし、実際、Twitterなどの旬なサービスがRuby on Railsを使っていましたからね。ただ、Rubyという言語の今後の発展にとって、Ruby on Railsがいいアプリケーションだったかは今となっては疑問だったりしますが。それはともかく個人的には記述の簡便さよりも可読性を重視するので、Rubyはプログラムを書く気にはなっても、読む気にはなれないのですよね。やはり可読性と記述性は相反しますからね。もちろんスクリプティング言語はお手軽・簡単プログラミングが目的になるので可読性よりも記述性を重視されて設計されることが多いのですが、プログラムレビューが重視されるようになっている現状では、記述の簡便さだけでなく、可読性の方も重要になってくるのではないでしょうか。また、Cloud Computingでサービスを記述する場合、スクリプティング言語でサービス定義に使うことが多くなると、スクリプティング言語はその目的からしてかわってくるのではないでしょうか。

2008年5月1日

月がかわって5月ですね。毎月1日は情報関連メーカが値下げ発表をします。各社の発表、例えばバッファローやIOデータがあります(わかりやすいように希望小売価格があるメーカを上げています)。なぜ毎月1日に集中する理由は意外に知られていないようですが、ヨドバシカメラなどの量販店は毎月1日にメーカにその月の卸価格を出させるのです。このためメーカは毎月1日に価格改定が発表することになります。これは製品価格をオープンプライスをメーカも毎月1日に通知します。さてIT業界はダウンサイジングですから基本的に値下げ発表となります。特にハードディスクやメモリ関連は顕著です。このため、ヨドバシカメラなどの量販店で売っているような機材や部品を購入するときは、月末ぎりぎりの場合は次月の1日に行われる価格改定をまってから、見積＆発注すると安く購入できることが多い。ただ、ここで注意しないといけないのは購入先が小売りなどをしている場合です。店頭在庫などを持っていると、その在庫の卸価格をもとに見積もりを出してくることがあります。いずれにしても機材の見積&発注では予算を有効利用したいですね。

2008年4月30日

MacOS 10.5用のJava SE6が正式リリース。まぁデバロッパー版が前からリリースされていたとはいえ遅い、遅すぎですよね。そのうえ64bitマシンだけ(実はMacOS 10.4用にはJava SE6の評価版がリリースされているので、32bit版も動きますがね)。AppleはMacintoshもiPhoneもCocoaベースのネイティブAPIに主軸をおいているので、仮想機械ベースのAPIには関心がないのでしょう。確かにネイティブAPIは実行コストが小さく、iPhoneのような組込コンピュータでも動くというメリットがあります。一方、JavaやMicrosoft .Net Frameworkのような仮想機械によるAPIはマシン非依存のアプリケーションが作れますが、実行コストが大きい。ただCloud Computingに代表されるように、ソフトウェアの実行場所がサーバー側に移行すると、ネイティブAPIに活躍場はないし、そのネイティブAPIに固着したAppleは先がない。おそらくAppleの戦略は。AppleはPDA以上、PC未満の端末と組込コンピュータに注力するつもりかもしれませんね。逆に言えば、ここはMicrosoftが一番手薄な市場ですから、ビジネス的にはねらいところではあります。つまりWindows Vistaは非力マシンのOSとしては重すぎますし、Windows CEは使い勝手に難があります。もちろんLinuxベースの簡易端末もありえますが、使い勝手を考えるとMacOS Xの方がいい。仮にAppleが軽量版MacOS X＋Safariを用意して簡易端末を売られると他社は対抗ができませんからね。ただ、OSとWebブラウザだけの端末は価格競争になるでしょうから、iPodやiPhoneなみに市場に関連商品エコロジーでも作って大きなシェアをとらないと採算性はとれないはず。

2008年4月29日

いまフィルムカメラを使っている方はどれぐらいおられるのでしょうかね。カメラの業界団体(カメラ映像機器工業会, CIPA)は、フィルムカメラ(銀塩カメラ)の生産・出荷台数の統計の発表をやめたそうです。1月の統計はフィルムカメラの生産が1580台(約4600万円相当)、出荷は1万1573台(約1億7200万円相当)と微々たるもの(使い捨てカメラは含まれていませんが)、そしてついに2月の統計ではフィルムカメラはなくなっています。CIPAの規定上、統計発表の対象から外れるのが理由だそうです。それにしてもカメラの国内最大業界団体自らフィルムカメラを統計対象から外したのは一つの時代の終わりをしめす象徴かもしれません。実は当方はいまだにフィルムカメラを使っており、心境的にはやや複雑だったりします。たしかにカメラ量販店でもフィルムカメラは片隅にあるかないか、フィルム売り場もどんどん小さくなっていますね。この分だとフィルムカメラへの需要は減って、フィルムもその現像＆プリント代も高くなりそうです。ちなみに手持ちのフィルムカメラはContax T3、Minolta CLE、Nikon FM3Aなのですが、さてこれらのカメラをわかる人はどれぐらいいるのでしょうかね。

2008年4月28日

午前中は慶大の大学院授業。今年は履修者27人だそうです。大学院の授業としては多いですよね。さてここ数日はMicrosoftのMeshの研究。だんだんGrooveに似てきていますよね。Grooveを率いていたRay OzzieがMicrosoftを率いているわけですから、当然といえば当然ですが。Meshはまだまだこなれているとはいえませんが、GoogleのApp Engineと同様に今後のコンピューティングにつながる道にはなるでしょうね。その意味ではAppleは先がないですよね。ハードウェアとソフトウェアの一体化と独自APIに拘るたために、サービスという概念にすら行き着いていませんからね。Appleはいまはいいですが、PC時代の終焉とともに終わりそう。ところでGoogleのApp Engineなどは(いまのところ)Pythonだけをサポートしていますし、MeshもプロタイプはPythonを使っているそうです。これを書くとRuby愛好家の方は怒るわけですが。ただ、すくなくても現状ではクラウドコンピューティング系の最新技術を使うにはPythonを使うしかないのも事実。ちなみにRubyに関してはスクラッチにちょっと処理を書くときはいいと思いますが、サービスコンポジションを書く限りはオブジェクト指向ではなくてもよく、Rubyのように開発者にオブジェクト指向を要求する言語は使いやすいとは限らないのですよね。ところでMicrosoftの作るMeshのアプリケーションは個人向けのものばかりなのでしょうかね。Meshというか、Grooveの特性を考えると個人向けよりも業務向けの方が向いているし、需要も大きいと思うのですがね。

2008年4月27日

最近、Webに出回っていますが、Ray Oggieのメモ。今後の技術トレンドを考える上で、2005年のメモととともに重要なドキュメントになりそうですね。技術ポイントは大きく分けて3つなのですが、その3つめに関するプログラミングを解説したビデオも公開されていますが、これもなかなかおもしろい。ユビキタスコンピューティングとかを語る前に見ておきたいですね。それにしてもいまは1995〜97年ぐらいのWeb聡明期と同じぐらいIT技術が大きく変わっていますし、エキサイティングですよね。

2008年4月26日

オフィス前では撮影中。ドラマのようですが、最近は多いですね。さて昨日の続き。研究者にとって論文発表は必須なのですが、IT系に限ると論文のライフサイクルは技術のライフサイクルについていけてない。例えばソフトウェア系を例にとると、当該分野で代表的な論文誌であるIEEE Transaction on Software Engineeringという論文誌がありますが、採録から掲載までに2年以上かかることも珍しくない(当方の場合は1年程度でしたが)。いくらいい研究でも2年もたったらその研究は陳腐化しています。国際会議は研究者同士の情報交換として生き残るでしょうが、論文誌は研究発表の場にならなくなっています。こうした問題への試みとしては、韓国の情報処理学会に相当する学会が、投稿から掲載まで半年をウリにする英文論文誌を始めましたが、同様にスピードをウリにする論文誌がでてきそうですね。自然科学の学術誌Natureの試みですが、Nature Precedingsという雑誌では投稿された論文は、査読なしでネット上で掲載して、読者からの評価をうけるというスタイルを試みています。この場合、読者評価というのはある種の人気投票になってしまうので、研究としての価値と人気度は一致しないという問題もありますが、少なくても早い段階で研究成果を公開できるというメリットはありますよね。いずれにしてもベストの論文採択方法がない以上は、これも論文評価方法のひとつにはなるかもしれません。

2008年4月25日

昨日の論文誌の続きですが、和文論文誌ってどうなんですかね。和文論文誌は理学系学会では廃止方向ですが、情報系はむしろ増えている感じ。日本語の論文はいくら書いても海外で読まれることは皆無だし、海外からみると研究成果として認められるわけではない。萌芽的な研究を扱う研究会などは日本語でも仕方ないでしょうが、完成された研究を発表する論文誌は英語論文だけにしてもいいと思うのですがね。国内指向を続けていても海外から取り残されるだけなのにね。同様に研究者の実績でも、日本語の論文誌は何本あっても、海外からみるとゼロ本と同じ。もちろん情報系研究者の場合、研究実績が和論文が中心の方が多く、そうした方は研究実績が大きく目減りすることになるので強い抵抗があると思いますが、いつまでも国内情報系だけで独自基準が通用するわけではないの事実ですよね。

2008年4月24日

数日前ですが某国内学会から、学生さんの書いた論文(当方は共著)の別刷りが、その請求書とともに到着。国内学会の場合、別刷りを著者に強制的に買わせないと財務的に論文誌の刊行ができないのはわかりますがね。ちなみに海外の出版社の多くは、校正や整形作業はインドに外注するようになっています。この結果、コストも下がったそうですし、時間も大幅に短縮できたそうです。情報系の国内大手情報系学会の場合は、なぜか同じ印刷会社に整形から校正、印刷まで委託しているようですが、せめて英文論文誌は海外に外注に出してもいいような気がします。もちろん左右ページの行揃えなど日本特有の印刷品質は維持できなくなりますが、そもそも紙媒体にするにしても、オンライン化された論文PDFファイルをダウンロードして、プリンターで印刷する限りは無駄な品質ですよね。学会事務もオフショアの時代だと思うのですがね。

2008年4月23日

国際会議の査読論文が15本ほどためてしまって、ひたすら査読です。そんななかちょっとわけがあって、深夜Javaでマルチスレッド絡みのプログラミング(現実逃避ともいいます)。実は久しぶりにWindowsで開発＆実行しましたが、マルチスレッド絡む処理の場合(それも頻繁にスレッドの生成と消滅を繰り返す)、Windowsは速いですね。まぁJava VMがWindowsに最適化してあるというのもありますが、同じプロセッサ(Core 2 Duo)で、クロックはWindows Vista マシンは1.2GHz、一方のMacintoshは1.8GHzなのにWindowsの方がやや速い。もちろん、かなり特殊な事例で、1コアに割り当てる逐次処理ではMacintoshがいくぶん速いのですが、それでもクロック差はない。MacOS XはWindowsと比較してスレッド生成コストが大きいですよね(MacOS XはLinuxとスレッド生成コストと大差ないしね)。もうすこし解析したいのですが、いまはそれどころではないのでパス。

2008年4月22日

さすがにあきたのでCloud Computingの話はひとまずお休み。WebニュースにHDDとSSDのセミナーに関する記事が出ているのですが、なかなかおもしろいですね。SSDはHDDに対して消費電力はアクセス時に3分の1、アイドル時に6分の1、重量は3分の1、耐衝撃性は3倍だそうです。速度比較はありましたが、消費電力の比較ははじめてみました。また2010年には、GB単価の違いが2倍程度と予測されるそうです。また、人間社会の情報量と記憶媒体の総容量に関する議論がありますが、なかなかおもしろい。

2008年4月21日

午前中は先週から始まった慶大の大学院の授業の二回目。まじめに理論計算機科学の話。90分話すとのどがかれますね。ところでそろそろ自分でも飽きてきたのですがCloud Computingのこと。立場上、制度設計的なことを考えないといけないのですが、Cloud Computingになると日本は税収が大きく下がるかもしれませんね。理由は２つありますが、一つ目は直接的な税収減です。Cloud Computingでは利用者側、つまりユーザや企業はコンピューティングやデータストレージはCloud Computingに任せることになるので、ユーザや企業の情報システムのリソースは少なくてもいい。そうなると情報システムへの投資は大幅に減ります。この結果、情報システムの販売・維持に関わる市場は小さくなり、それにともなう消費税収が減ります。当然、システムを販売・維持をする事業者側の売り上げ減になると法人税収も減ります。サービスを実現するソフトウェアはCloud Computingになっても必要なのですが、問題はSI事業者。SI事業ではソフトウェア開発だけでなく、システムやネットワーク構築で稼いでいるのですが、システムやネットワーク構築はCloud Computingのインフラを使えばいいので、業務は激減することになります。いまはSI事業は人気のようですが、長期的には先行きは不透明ですよね(SI会社は学生さんの就職先と有力なのですが、もしCloud Computingが普及すると、ネットワークやデータベースなどのシステム管理スキルへの需要は減るので、いまから就職しても一人前になった頃はいらない人材になっているかも)。いずれにしても一般ユーザや企業の情報システムへの投資は減少することになります。でもCloud Computingのインフラの設備投資が増えれば相殺されるかもしれませんが、日本に限ると国内でそのインフラを維持・運用することはすくないのではないでしょうか。ということで国内ではIT関連の税収は落ち込むことが予想されます。さて理由の2番目ですが、これはCloud Computingインフラがおかれる国と利用者側の国が違った場合におきます。現状の(企業間を含めて)電子商取引では、売る側および買う側も商取引を行う人またはコンピュータはそれぞれの国にあるわけで、商取引に伴う税金は売る側および買う側の国に支払うことになりますが、Cloud Computingの場合は、売り手の商取引サービスも買い手の商取サービスもCloud Computingインフラ上で動いていますから、商取引を発生する国はどこなのかという議論が出てきますし、Cloud Computingインフラが売る側および買う側の国と相違する場合、売る側および買う側の国はCloud Computingインフラ上の商取引を補足するのは難しくなります。もちろん商取引サービスが売り手または買い手が占有的に利用するものであれば単純なのですが、プログラムではなくサービスなので、他の売り手や買い手の商取引を代行しているはずで、特定業者に関わる商取引だけを把握するのは事実上困難でしょう。逆にCloud Computingインフラを保持している国は商取引に関わる税金をかけやすくなりますから、Cloud Computingインフラを持つというとは、貿易都市や商業都市を造ることと同じになります。ロンドンなどの金融都市を作るより、Cloud Computingインフラを誘致した方が手っ取り早いし、税収も多いのではないでしょうか。もちろんそのためにはCloud Computingインフラ設備に電力を安価かつ安定して提供するインフラ整備が必要なのですが、日本は仮に電力供給ができてもダメですよね。理由は地震がありますから。地震のリスクを考えると、日本はCloud Computingインフラの整備・運用に向きません。

2008年4月20日

同じ話題が続いていますが、Cloud Computingのこと。システム的なことはある程度、予測できてしまうので、いまの関心は利用料金。まずインフラの使用料とサービスの使用料は分けて考えますが、前者のCloud Computingのインフラの使用料は利用した計算量、利用時間、ストレージ量、通信量などが重要なファクターになるはず。Cloud Computingはスケラビリティ確保が最大原則になりますから、そのスケラビリティを確保するために使った分だけ払うという料金モデルを導入して、いまのインターネットのようにリソースを使った者勝ち的な状況はさけないといけません。その意味ではCloud Computingインフラの使用料は電気代や水道代に近い存在になるはず。上記の料金ファクターで電気代や水道代に相当するのは、計算量なのですが、コンピューティングの場合、ところでリアルタイム性も要求されるので流量に近い概念かもしれませんね。Cloud Computingインフラ事業は、コンピューティング・データストレージというリソースの提供サービスなので、先物取引的なリソース確保はあると思いますし、卸売り的なビジネスも可能でしょう。つまり前者はリソース予約そのものなのですが、問題は事前予約したリソース使用権の売買が可能になるかですよね。次にサービスの使用料ですが、これはサービスによりますよね。例えば従量課金が向いているサービスもありますが、利用度は少なくても重要なサービスは従量課金に向かない。また、利用者の多いサービスでも従量課金にするのとサービス提供者は売り上げが変動するのをいやがって、月単位などで契約する形態になるかもしれません。料金の徴収はCloud Computingのインフラ事業者が支払い代行をするでしょうが、実はこれまで1セントや1円以下の支払いを扱うマイクロペイメントはうまく行った事例がほとんどないのです。理由は料金支払いシステムのコストが支払額よりも高くつくことも多く、経済学者のいうようにマイクロペイメントはうまくいかない。

2008年4月19日

ここ数日はCloud Computingのことを書いたのですが、問い合わせを受けたのでここで返答しておきます。いくつかあるのですが、一番多いのはいつぐらいにCloud Computingに移行するかです。当方の意見を書くと、良くも悪くも急激にCloud Computingに移行することはないと思っています。やはりCloud Computing向きのサービスとそうでないサービスがあるので、まずは移行しやすいものから徐々に移行すると思いますし、現行手法とCloud Computingのハイブリットな状態は10年以上は続くと想定しています。ただ、大きな流れとしてはデータも計算も、ネットワーク上のインフラに移行してくのだと思います。Cloud Computingに移行する理由がわからないと質問されたのですが、これは単純で、自前でコンピュータを持つよりもCloud Computingインフラを利用したときの方が安くあがるということになれば、企業も個人も経済的合理性にもとづいてCloud Computingへの移行が進むと思います。ただ、最後にダメ押しするのは意外にも環境問題かもしれないと思っています。なんらかの二酸化炭素排出に関わる課税措置などの経済的なペナルティが導入されて、自前でコンピュータを維持するより、Cloud Computingインフラを利用したときの方が二酸化炭素排出が少なってことになれば(ペナルティが減ることになれば)、Cloud Computingインフラに移行するかもしれませんね。一方のクライアント側ですが、計算能力もストレージも少なくて済みますから、性能的にダウングレードするでしょうし、結局、価格勝負の世界になって、100ドルぐらいになるかもしれません。これを考えるとIntelが、稼ぎ頭の高機能x86プロセッサ市場を脅かすかもしれない低価格x86プロセッサ(Atom)に力を入れるのも合理性がありますね。

2008年4月18日

今日も貫徹明けです。6時半頃に出勤。中一日で貫徹だと辛い。さてこのところCloud Computingの話題が続いてしまっていますが、今日もその続き。日本の場合、年金や税金などの管理に巨大情報システムを作っていますが、まぁそのクオリティの問題は別にしても、行政機関のシステムは、年度末などの特定の時期には負荷があがるという傾向がありますが、それ以外は負荷が小さい。しかし、最過負荷時を想定してシステムを作っているので、通常時は無駄にシステム規模が大きく、導入コストも維持管理コストも無駄このため行政機関の情報システムはCloud Computingに向いているといえます。もちろん、日本の場合は行政機関の大規模情報システムは、国内IT 産業というか、ITゼネコンの維持が目的だったりすることもあるので難しいのですがね。仮に行政機関の情報システムがCloud Computingに移行した場合ですが、特に中央官庁の仕事の多くは事務仕事なので、相当数の仕事はCloud Computingインフラ上でデータベースを維持して、そのインフラ上でアプリケーションを動かすことになります。問題はこの先でして、行政機関の情報システムがCloud Computingインフラで維持・運用するようになったとき、行政機関によって違うCloud Computingインフラ提供業者を使っていると、インフラ間の情報交換に費用がかかるので、Cloud Computingインフラ提供業者は集約されていき、特定の御者に国のデータベースと事務処理を任せることが想定されます。こうなると行政情報も情報処理もCloud Computingインフラ提供業者の手の中にあることになります。つまり税金も年金、行政情報もすべてCloud Computingインフラのデータベース上で管理され、サービスもCloud Computingインフラ上で動くになります。例えば税金を考えると、納税も個人や事業者の税金管理サービスが、Cloud Computingインフラ上で動く国税庁や地方自治体の徴税システムに支払うことになり、税金も国家予算もCloud Computingインフラ上で維持・管理実現されることになります。さらに身分証明などもCloud Computingインフラ上で実行されるサービスが発行することになるでしょうし、そうでなくても国が発行した証明書より、Cloud Computingインフラ上で発行された身分証明の方が信頼されるかもしれません。いずれにしても徐々に行政そのものもCloud Computingインフラ提供業者に依存することになっていくでしょう。そうなったら、国そのものがCloud Computingインフラ提供業者に実質コントロールされているような事態も想定されますし、そもそも国家がいまのように維持できるのでしょうか。だからといって国家が行政向けCloud Computingインフラを提供すべきとは思いませんが、Cloud Computingインフラに国が依存した場合に発生する問題の整理、複数の民間Cloud Computingインフラを利用しながら、リスク分散をする方法などは今のうちに検討しておいた方がいいと思います。

2008年4月17日

Cloud Computingの話題が続いてしまっていますが、またCloud Computingの話。さてCloud Computingのサービス記述言語はどのようなものなのですかね。Google App Engineはいまのところ記述言語はPythonだけですが、AmazonのElastic Computing CloudはXenを使っているようでいろいろ対応できるはず。いずれにしてもCloud Computingのインフラ側のコンピュータで動くわけですが、サービス提供事業者などのインフラ提供事業者以外がが開発したコードも実行することになるので、そうしたコードが悪さをしてもインフラ全体への影響を最小限にするために仮想機械やインタープリター内でコード実行して、他への影響をブロックすることになります。このため仮想機械やインタープリター向けの言語が使われることになります。そうなるとネイティブコードの実行を想定し、さらに低水準アクセスができるCやC++のようなプログラミング言語は排除されてしまうでしょう。もちろん、いまのアプリケーションやサービスはCやC++で書かれていることが多いのですが、アプリケーションやサービスだけでなく、開発者も一変してしまうかもしれません。さて話題を戻しますが、どの言語が本命になるかですが、スクリプティング言語、そしてJavaやMiscroft CLR上の言語あたりが本命になりそうですね。ただCloud Computingがまだまだ実験的な段階ですから、Cloud Computing向けサービス記述言語の機能要件がまだよくわからないので、言語を設計したくても誰もできないというが現状ではないでしょうから。もっとも言語レベルで統一化が進むのか、言語を実装する仮想機械レベルで統一化が進むのかがわからないです。特にCloud Computing上のサービスは開発速度が優先されるので、ドメインごとに言語が作られる可能性もありますからね。その場合はばらばらの言語を使いますが、個々の言語に対してセキュア実行機構を作るのはたいへんなので、その場合は言語向けの仮想機械レベルで統一化される可能性が高いですね。

2008年4月16日

昨夜は貫徹状態。午前中の用事は10時からの会議だけでしたが、早朝6時に出勤。さて続いてしまっていますが、Cloud Computingの続きです。Cloud Computingが普及した場合、要求される人材もかわってきますよね。例えばOSですが、Cloud Computingのインフラ側はスケラビリティを重視したOSが使われるでしょうが、クライアント側、つまりユーザはダム端末のようなコンピュータを使うわけですから、ネットワークにつながって、Webブラウザが動けばいいので、たいしたOSはいらなくなります。そうなるとユーザやプログラマーはOSの知識は不要になるでしょう。また、ネットワークに関する知識についても、Webブラウザをつなぐだけですから(Cloud Computingインフラ側の管理者を除くと)いまほどネットワークに関するスキルはいらないでしょう。また、各種サーバやデータベースもCloud Computingインフラに任せてしまうのですから、サーバやデータベースの維持や管理などのミドルウェアのスキルは一切いらなくなります。つまり技術者や開発者に必要とされるプロフェッショナルスキルは一変してしまいますね。逆にプログラマーやSEに必要な知識は、Cloud Computingインフラ上のAPIやサービスに関する知識。そしてそられを組み合わせて所望のサービスを作ることなります。そうなるとアルゴリズム的なプログラミング能力よりも、使い勝手がよくて、利用料が安いAPIやサービスをたくさん知っているか否かが重要になりそうです。ただ、先日も書いたようにCloud Computingの世界は、サービス開始までの速さが命の世界ですから、手っ取り早く開発できるプログラマーが重宝される時代になりそうです。また、SEさんに関しても設計の自由度はCloud Computingのインフラで相当制約されますし、サービスの提供インフラはすべてCloud Computingのインフラに任せればいいので、仕事は相当経るのではないでしょうか。一方、Cloud Computingのインフラ企業側の管理や開発は、現在のIT技術者に近いでしょうが、かなり特殊なスキルになると思いますし、昨日書いたようにCloudComputingインフラの提供会社が数社の巨大企業に集約されていくと、ごく少数のIT技術者だけの世界になってしまうでしょうね。おそらく自前で、コンピュータにWebサーバを立ち上げたり、データベースをインストールするというのは、今の時代に自動車や家を自分で作って住むのと同じぐらい、危なっかしいし、コスト的にも見合わない行為になるのではないでしょうか。

2008年4月15日

またまたCloud Computingの話題ですが、なんで拘るかというと個人的にはGoogle App EngineやAmazonのElastic Computing Cloudなどが先兵をつけたCloud Computingは、情報サービスやそしてコンピューティングを根本的に変えてしまう大きな変化だと思っているからです。Cloud Computingが普及してしまうと、いまのPCで使われているビジネスアプリケーションやコンシューマーが使うアプリケーションに必要な処理やデータは、Cloud Computing上にある各種サービスを使えばよくなってしまうのではないでしょうか。PCは常時接続とWebブラウザが使えるだけのコンピューティングがあれば十分という時代になって、昔のダム端末に近い存在かもしれません。また各種のネットサービスを提供する企業もCloud Computingによって提供されたインフラを使えばよく、自前でサーバを立ち上げたり、データベースを構築することはなくなるでしょう。むしろCloud Computingインフラの利用者側の企業間でデータベースを共有する、つまりビジネス上の最重要情報を共有することが前提とするビジネスモデルも出てくるでしょう。さてCloud Computingのインフラ提供企業ですが、当初は小中規模のインフラ提供企業もあるでしょうが、ある程度の規模が必要なことを考えると、長期的におそらく現在のネットビジネスの列強、Google、Amazon、Microsoft (+Yahoo)、eBay, Salesforcesあたりが核になって、吸収・合併を繰り返して、最終的には少数だけになるのではないでしょうか(おそらく3つぐらい)。もちろん、10年以上の時間がかかるでしょうが、現在PC上でのほとんどの処理はCloud Computingに飲み込まれていくことになるでしょうし、またそのときにはコンピュータは少数の巨大インフラ提供企業のなかだけで使われる特殊な機械という存在になってしまうかもしれません(もちろん組込系コンピュータはたくさん使われるとは思います)。IBMの初代経営者であるThomas J. Watsonは1940年代後半に「コンピュータにはせいぜい5台分の市場しかない」という発言をしているのですが(この発言は捏造らしいですが)、これは実は正しかったといえる時代がくるかもしれません。

2008年4月14日

昨日の続きです。商業Cloud Computingサービスは、コンピュータサイエンスの研究にどのような影響を与えるのでしょうかね。個人的にはCloud Computing以前、つまりWebサービスはアカデミア研究になりえないという認識でおります。アカデミアでもWebサービスの研究をされている方はたくさんおられるので、袋たたき似合いそうですがね。その理由ですが、例えば研究として新しいWebサービスを思いついたとしても、それを論文に書いて公知になるまでには時間(国際会議なら半年、論文誌だと1年)がかかります。一方、Webサービスの場合は小規模のものであれば比較的短時間で実装ができますし、それを公開して、実ユーザに使ってもらうということもできてしまいます。そうなったら論文を書いているよりは、提案したサービスを公開して、実ユーザに使ってもらった方がいい。サービスを使って好評か否かを調べた方が確実に研究の善し悪しを評価できますし、その方が時間的にも早い。さてCloud Computingサービスは、Webサービスでは必須だったサーバを自前で用意するというステップを省きますから、サービス開始までの時間は短くて済みますし、機材もお金もなくてもサービスを開始できることになるので、研究予算がないのでサーバを買えなとかといういいわけはもう使えない。その意味では個人レベルでも大企業と並ぶようなサービスを提供するケースが出てくるでしょうし、腕のいいプログラマーさえいれば、アイデアを思いついてから、サービス提供まで1ヶ月もかからずに実運用までもっていけるはず。いずれにしても論文という評価基準を規範とするアカデミア研究は、Webサービス以上にCloud Computingの時間の速さについていけないことになります。さらに商用Cloud Computingサービスが普及すると、サービスを実現する基盤システム、つまり研究のコアになる部分は、GoogleやAmazonなどのCloud Computingサービスの提供企業に握られることになりますから、何を研究すればいいの？という自体になってしまうかも。

2008年4月13日

Google App Engineのベータ版ですが、先着アカウント取得に失敗したのですが、近日中に追加アカウントがあるようですね。App Engine SDKでスタンドアローンで遊び始めているのですが、開発用のプログラミン言語のPythonはすっかり忘れている始末。まずはPythonのお勉強のし直しが必要だったりします。それにしてもスクリプティング言語は、お手軽な反面、すぐ忘れますよね。Google App Engineですが、キーテクノロジーはデータベースだと思いますが、Webのように通信コストが大きい状況では関係データベースはいいとはいえず、新しいデータモデルが必要となるかもしれませんね。ところでGoogle App Engineはお値段的にはどうなるのでしょうね。ちなみに同じCloud ComputingサービスであるAmazonのElastic Computing Cloud (EC2)は、最小構成ではメモリ1.7GB、ディスク160GBの場合、時間あたり$0.10、データ転送は1GBあたり$0.10だったりします。個人的には破格にやすいと思うのですがね。それにしてもこうした安価なデータ＆アプリケーション実行サービスのインフラが出てくると、便利になった反面、研究としてはやりにくくなるのも事実。クライアントまわりだでなく、サーバまわりも研究テーマもなかなか難しくなってきます。それでもクライアントまわりよりは研究テーマが残っているでしょうが。いずれにしても、これからのコンピュータサイエンスはは、純粋にコンピュータサイエンスを突き詰めるのではなく、自然科学や実社会の特定分野にコンピュータサイエンスの手法を使って、効率化したり、付加価値をあげることになるのかもしれません。

2008年4月12日

Windows Vistaはサービスパック1(SP1)のリリースにあわせて、大幅値下げだそうですね。MicrosoftによるとVistaは売れているということになっていますが、やはりいろいろ問題があるのでしょうね。個人的にはVistaのGUIには馴染めないのですが、そのGUIは別にすると.Net Frameworkベースの高水準APIなどみるべき点は多いと思いますが(使いたいかとは別ですけど)、もちろんそうした高水準APIが性能を悪化させている元凶ではありますが、コンピュータサイエンスの研究者としては何が性能を下げているかを知るのも仕事なので、構造を知ると同時に、実際にいろいろ試してみることは大切だと思います。いずれにしてもコンピュータサイエンスの研究者としては、いい悪いとか、好き嫌いとかは常に最新のOSを使っていないといけないので、Vistaも使うことになります。コンピュータサイエンスの研究者にとってはコンピュータは研究の対象なので、古いハードウェアや古いOSを使っているようでは時代にあった研究ができるわけがないのです。また、特定のOSやハードウェアに依存しないことも大切なのですが、Windowsしか使わないとか、Macintoshしか使わないとかだと、そのOSの世界しかしらないわけで、OS共通の機能とOS独自の機能が区別できないのです。コンピュータサイエンスの研究している以上は、複数の最新OSを使い続けないのですよね。人間ですから、慣れたOSの方がいいので、複数を使うのは結構たいへん。でも仕事ですからね。

2008年4月11日

科研費萌芽の採択結果の通知。以下は大学業界でないとわからない内容です。すみません。当方の勤務先は科研費の全国採択率ベスト５内を毎年度キープしているそうで、不採択はランキングに悪影響を与えるのでなかなか許されない雰囲気だったりするので、ほっとしますよね。ただ、予算はいただいてからがたいへんなのですよね。当たり前ですが予算に見合った、またはそれ以上のアウトプットを出さないといけませんから。この萌芽以外に基盤(B)もあるので(どちらも研究代表者)、二つを同時に研究するには相当心してのぞまないといけません。ところで、毎年この時期に閉口するのは、予算額や件数を自慢するメールを送ってこられる方々。早速、そうしたメールをいただいたのですが、まぁ御本人は悪気がないのでしょうが、片手では数えられないほどの科研費(分担者を含む)をとって全部きっちり研究できるのでしょうかね。他人事ながら心配になったり。ただ、研究ではなく研究予算を獲得することが目的化しているとしか思えない方もおられますがね。いずれにしても研究者ならば予算額を自慢するのではなく、自慢でできるような研究成果を出さないといけないですね。ところで「萌芽」って、一般ではあまり使わない用語だと思いますが、意味はわかるようでわからないですよね。まさか昨今流行った「萌え」と関係があるわけはないですよね。

2008年4月10日

新国立劇場でWeberのオペラ「魔弾の射手(Der Freischutz)」を鑑賞。先月、同じ新国立劇場で出来がすごくよかった「アイーダ」を観たばかりなので(それも2回も)、アイーダと比較してしまうとちょっとがっかりなのですが、国内オペラとしてはよい出来ではないでしょうか。特にヒロイン役(Agate)は若い歌手(Edith Haller)だったのですが、これがすごくいい出来。主役(Max) のAlfons Eberzはいい歌手のようですが、初日ということもあってまだ調子がでていないのか。隠者役の歌手(妻屋秀和)はよかったですね。舞台装置や衣装、演出もいろいろ新しい挑戦をしているのは好感なのですが、なんか消化して切れていない感じ。演奏は冒頭のホルン重奏がウリなのですが、音があっていないなど演奏は？でした。ただ、やはり「魔弾の射手」という演目そのものに、観客を引き込む迫力がないのです。同じドイツオペラでもワグナーのつもりで観に行くとがっかりするかも。さて今晩で今シーズン(2007-2008)でみたオペラは9つ。今シーズンも10本は見られますでしょうか。

2008年4月9日

次期Windowsの噂がちらほら聞こえはじめしたが、カーネルよりもWinFSを乗せてほしいですよね。ご存じのようにWinFSはWindows Vistaに搭載予定だったけど、結局、搭載されなかった機能。たまたまWinFSのデモビデオをみつけたのですが、確かにこのデモビデオのことができれば、Windows Vistaは時代を変えたOSとして名を残したかもしれません。OSの最も基本機能の一つであるファイルシステムは、データの保存やアプリケーション間でのデータの共有です。こうした機能に立ち返ってほしいところです。WinFSは関係データベースをもとにしていますが、XMLベースのデータが増えている状況では、ファイルシステムの代わりにXMLデータベースにしてしまってもいいかも。それはそれで問題山積なのですが、PCが閉塞状態になっている以上は、次期Windowsには互換性よりも斬新な機能を期待したいところです。

2008年4月8日

PCはダウングレードの時代ですよね。IntelのAtomプロセッサ搭載のPC(NettopやNetBook)の価格レンジはディスプレー込み4万円以下。Atomは非力とはいえ、x86プロセッサ。Windows XPが発売された頃のスペックと考えれば、メールやWeb ブラウジング、簡単な文書作成や表計算であれば十分につかえるはずで、現在のPCのような高性能マシンを一般コンシューマーがわざわざ使う必要はなく、安価PCで済ますことが多くなるでしょうし、それにともなって光ディスクも大容量ハードディスクもいらないということになりそう。そうなると高価格PCで利益を稼いでいる国内PCメーカはつらいことになるのですが、ただ日本の場合、すでにPCの普及率が高いことですから、セカンドマシンとしてAtomプロセッサ搭載のPCの需要がそれなりにあると思いますが。いずれにしてもPCは性能ではなく価格重視になるでしょうし、その性能も初期のWindows XPマシン程度で落ち着いてしまうかもしれません。研究者としてはPCの性能はあがることを前提に、研究している時点のPCでは遅いアルゴリズムも過負荷なシステムも、将来のPCはサクサク動くというと仮定して研究してきたわけですが、これから現時点で遅いアルゴリズムや過負荷なシステムは、将来も遅く、過負荷のままかかもしれません。いずれにしてもPC用のプロセッサは価格が重視されるでしょうし、サーバ用のプロセッサは電力あたりの計算性能が重視されることになるのでしょう。

2008年4月7日

Sun MicrosystemsがJava SE for Businessというサービスを始めるようですね。まだざっと概要をみただけですが、通常のJava SEはサポート期間は3年間ですが、それを最長15年間までのサポートを約束するものだそうです。いまだにJava SE ver.1.4を使っているシステムは多いですから、結構、需要があるかもしれませんね。料金は従業員数で換算するそうですが、グレードによりますが、従業員一人あたり年10〜12.5ドル。古いバージョンを使っている企業は小規模なところがおおいですから、結構リーズナブルかもしれませんね。Javaは"Write once, run anywhere"という理念を掲げていますが、現実にはバージョンに依存している部分も多い。その一方でJavaで書かれたソフトウェア資産が増えてしまった状況では、これからは下位互換性を重視しないといけないということなのでしょうね。

2008年4月6日

IntelのAtomの続きです。4月3日のこのページでMicrosoftのAtomへのサポートがないに等しい、と書いたのですが、その日にMicrosoftはAtomなどを搭載した小型PCを想定してWindows XP Homeの販売延長を発表していたのですね。4月3日にも書きましたが、Atomへのサポートを怠ると、Atom搭載マシンはLinuxばかりになってしまいそうですから、Microsoftとしても静観できなかったのでしょうね。Windows Mobileを除くと、Microsoftにしてみるとマシンスペックが下がるというのは初めて経験だったのではないでしょうか。誤解している人が多いのですが、Microsoftにとってもお客さんは、エンドユーザではなく、WindowsのプレインストールしてPCを製造・販売するPCメーカ。そのお客さんであるPCメーカに儲けさせるためには、PCへの要求マシンスペックが常に高くして、PCの価格が下がることを防ぐことです。その意味ではWindows Vistaのような高スペックを要求するOSはお客さんの想いのすぐれたOSといえます。今回のWindows XP Homeの販売延長は、Windows XPとWindows Vistaという二つのOSの併売ということ以上に、Windowsのビジネスモデルの大きな転換になりますし、PCメーカにとってもPC価格の低下という事態になりかねない大きな変化ですね。次期Windowsでは、低スペックマシンから高スペックマシンまで対応できるようなOSを作らない限りは、Windows XPをまだまだ販売を続けることになってしまいます。この場合、Windows XPが長期にわたって標準的なOSとなって、結果としてOSの進化は遅くなりそう。逆にMicrosoftが低スペックマシンから高スペックマシンまで対応できるOSが提供できたとしても、OSがGUIと一体化された現状では、エンドユーザが低スペックマシン用の使い方になれてしまうと、高スペックマシンの高度なGUIはユーザから求められることが少なくなり、結果として高スペックマシンでも低スペックマシン用GUIを提供することになりかねません。もちろん、ユーザがそれでいいと考えるのならば仕方ないのですが、今後コンピュータの技術トレンドは保守的なものになっていくのでしょうね。IntelのAtomは、通常x86プロセッサの売り上げに影響するでしょうから、Intelにとっては諸刃の剣になるでしょうし、MicrosoftにとってはOSの機能的な進化が難しくなり、Windows XPまたは相当のOSを長く売り続けることになり、(新規開発が減るので)利益は上がるかもしれませんが、売り上げは減少をもたらしかねない。そしてコンピュータ技術にとっては低スペックのコンピュータが市場にあふれることになって、長い停滞の時代を作ってしまうかもしれません。

2008年4月5日

三菱東京UFJ銀行は旧東京三菱銀行と旧UFJ銀行の統合作業のため、4月の週末からシステムを止めるそうですが、おおがかりですよね。実際、システム統合に伴う費用は3300億円だそうですが、みずほ銀行のような事態をさけるために慎重にやるつもりなのでしょうが、この費用は尋常ではないです。両銀行のシステムは大きく違っていますし、旧東京三菱はIBM製、一方、旧UFJは日立製。特に旧UFJ は基幹システム系はメインフレームですが、それ以外はLinuxを多用する斬新なシステムだったのですが、旧東京三菱のシステムを拡張することで統合することになったようですね。今の時代、銀行はシステム産業ですから、システムの出来不出来が銀行の善し悪しを決めることになりますし、行員の人事評価もシステムが使いこなせるか否かは大きな要素になりますから、銀行統合ではシステム的に主導権をとれなかった銀行(つまり吸収された銀行)の行員は、(不慣れな)吸収した側のシステムを使うことになり、システムが使いこなせない＝能力不足のレッテルを貼られて早々に辞めていくことになります(というか辞めさせられていくというのが正しい表現かもしれませんが)。実際、過去の銀行統合では、吸収さえた銀行の行員さんは統合後5年もたつと1割以下になっているそうですね。もちろん例外はあって、三菱銀行と東京銀行の統合の時は勘定系システムは三菱銀行をベースになりましたが、情報系システムや外為系システムは東京銀行のシステムをベースにしたようで、どっちが吸収したのかわからないような感じでしたがね。ただ、三菱東京UFJ銀行では今回の統合で、旧UFJ銀行のシステムは一掃されることになりますから、今後は旧UFJ銀行出身者はたいへんだと思います。こうかくと冷たい表現と思われますが、これが企業吸収合併の現実ですからね。さて今回のシステム統合を仕切るのはIBMですが、IBMとしては三菱東京UFJ銀行のシステムをとれるのは大きいですが、今回の統合作業は必要な人員が多いですから、人員的にはたいへんではないでしょうかね。ちなみに旧UFJ銀行のシステム(日立)ですが、ゆうちょ銀行が引き継ぐことになりました。正しくいうとゆうちょ銀行のシステムを請け負ったNTTデータが日立からUFJ用開発したシステムを流用することになりました。開発費を押さえるという点では正しい判断のですが、すでにシステムの設計は新しいとはいえず、今後の金融商品の拡大に対応できそうもありませんね。

2008年4月4日

AppleのiTunes Storeは今年の1月と2月に楽曲販売数でWal-Martの販売数を抜いたそうですね。ということは全米では音楽販売でトップになったということになります。Appleはコンピュータメーカとしてではなく、コンテンツ販売業者として扱わないといけないのでしょうね。当面、音楽小売ビジネスはAppleを中心にまわっていくことになりそうです。

2008年4月3日

IntelがAtomを発表しましたね。問題はMicrosoftがWindows Vista系もWindows Mobile(Windows CE)系でも低消費電力用パッケージを用意するつもりがないようです。x86系プロセッサ向けOSのノウハウを一番持っているのはMicrosoftでしょうから、Microsoftにとって大きなビジネスチャンスだと思うのですが、いったいどうしたのでしょうかね。特にWindows Mobile系はここ数年は進化がとまっていますよね(もちろん組み込み系市場は保守的なのはわかりますがね)。そうなるとIntelとしてはLinuxをベースにしたAtom用のOSをIntel自身がサポートしないといけないことになりますね。もしかしてMicorsoftはLinuxを側面しているのではないかとまで思ってしまいます。ところで近々Appleが次期iPhoneの発表するという噂ですが、次期iPhoneにIntelの新型x86系小型プロセッサのAtomを搭載してくるでしょうかね。現行iPhoneのプロセッサはARM11のバリエーションの一つだそうですが(ちなみにクロックは620MHzらしい)、問題は消費電力ですよね。AtomはARM11に対して同クロックならば2倍程度ありますが、商品電力はARM11系の場合、製品によりますが、0.50mW/MHz以下。Atomの場合は800MHzの製品の場合でTDPが650mWだそうですから、消費電力は悪くなる可能性が高いので、Atomを搭載する場合はアプリケーションに応じてクロックをきめ細かく制御することが前提になりそう。その意味ではハードウェアもOSも作れるAppleならばAtomを使いこなせる可能性がありますが、消費電力制御はそのノウハウやパラメータを蓄積するのには時間がかかります。仮にIntelが事前に情報を出しているにしても、すぐにAtom版を出荷するのは難しいのではないでしょうかね。もちろんバッテリ持ちよりもプロセッサ性能を重視するのであれば話は別ですがね。それからARM11で思い出したのですが、ご存知のようにiPhoneはJavaを搭載していないのですが、ARM11系プロセッサならばJava用アクセレーターであるJazelleを搭載している可能性は高く、プロセッサ的にはそれなりの速度で動かせるはずなのです。Jobsのいうようにメモリ量的につらいというのはただしい見解でしょう。もちろんビジネス戦略的にJavaをサポートしたくないというのはあり得ますがね。

2008年4月2日

33種のメモリカードに対応したUSBカードリーダだそうです。この製品のメーカの仕様をみると無理してメモリカードの種類を増やしている部分もありますが、それにしても種類が多いですよね。

2008年4月1日

今日から新年度。その前に前年度の宿題を終わらせないと。

最新版
一覧

Ichiro Satoh

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