Life is beautiful

　昨日のエントリーで、「人は一つの仕事を処理するときには、それを小さな仕事に分割して、順番に処理する」と書いたが、「パンを焼く」という仕事を例に取れば、こんな風になる。

１．イーストを３０℃のお湯と一つまみの砂糖とまぜて１５分間予備発酵させる
２．ボールに強力粉、予備発酵させたイースト、砂糖、塩を入れて良く混ぜる
３．こね板の上で生地をこねる
４．ボールにラップをして室温で１時間発酵させる（一次発酵）
５．適当な大きさに生地を分割し、丸めて形を作る
６．オーブンに入れ、３０分発酵させる（二次発酵）
７．オーブンの温度を２００度にして１８分焼く

　これは、ソフトウェアで言えば「手続き型のプログラム」であり、人間が一連の作業を把握するのに最も適した記述の仕方である（その証拠に、実際のどのレシピブックを見ても、レシピは必ず「手続き型」で書かれている）。

　興味深いのは、このレシピにおける、「１５分予備発酵させる」だとか「１８分焼く」などの待ち時間を含むステップだ。

　ブクブクとあわ立ってくる予備発酵中のイーストを１５分間じっと見続けていたり、パンが焼け上がるまでオーブンの前に座り込んでいるのは、初めての「パンを焼き」にチャレンジしている日曜日のお父さんぐらいで、いつもたくさんの仕事を同時に抱えた普通の主婦（もしくは主夫）は、そういった待ち時間を利用して、洗濯をしたり、夕ご飯のおかずを作ったり、韓国ドラマを見たり、子供を幼稚園に迎えにいったり、家計簿をつけたりしているものだ。

　そんな複数の仕事を同時にこなしている彼女たちにしてみると、自分がそれぞれの仕事のどのステップにいるか（つまりcontext）を常に完璧に把握しておくことは不可能に近い。手続き型のレシピのままで作業をしようとすると、それぞれの仕事において自分が何をしておくのかを把握しておくだけで頭がパンパンになってしまうし(memory overflow)、頭の切り替え（context switch）にやたらと時間がかかって作業効率が落ちてしまうからだ。

　そこで、パンの発酵中にはタイマーをしかけておき、タイマーが鳴ったところで「あ、キッチンでタイマーが鳴ってる。えっと、何のタイマーだっけ。そうだ、そうだ、パンの二次発酵中だったんだ。じゃ、次はオーブンの温度を上げてと…」というイベント・ドリブンな仕事の仕方をしているのだ。

　言い換えれば、彼女たちの頭の中では、上の「手続き型のレシピ」が、以下のような「イベントに応じた作業（event handler）」の集まりである「イベント・ドリブン型のレシピ」に変換されて実行されているのだ。

【スタート】
１．イーストを３０℃のお湯と一つまみの砂糖とまぜてタイマーを１５分間にセットする（予備発酵）
２．他の仕事に移る

【予備発酵終了のタイマーが鳴る】
１．ボールに強力粉、予備発酵させたイースト、砂糖、塩を入れて良く混ぜる
２．こね板の上で生地をこねる
３．ボールにラップをし、タイマーを１時間後にセットする（一次発酵）。
４．他の仕事に移る

【一次発酵終了のタイマーが鳴る】
１．適当な大きさに生地を分割し、丸めて形を作る
２．オーブンに入れ、タイマーを３０分後にセットする（二次発酵）
３．他の仕事に移る

【二次発酵のタイマーが鳴る】
１．オーブンの温度を２００度にしてタイマーを１８分後にセットする
２．他の作業に移る

【焼き上がりのタイマーが鳴る】
１．焼きあがったパンをオーブンから取り出す。（パン焼き終了）
２．他の作業に移る

　実際には、これに加えて、他のさまざまな仕事から派生した「イベントに応じた作業」が記述されたプログラムの断片が、彼女たちの頭の中にはぎっしりと詰まっているのだ。例えば以下のようなもの。

【洗濯終了のタイマーが鳴る】
１．洗濯機の中のものを乾燥機に移してタイマーをセットする
２．他の作業に移る

【赤ん坊が泣き始める】
１．おなかが空いている時間ならミルクをあげる。そうでないならば、オシメが濡れてないかチェックする。濡れていれば交換する。
２．他の作業に移る。

　イベント・ドリブン型の利点は、それぞれの「イベントに応じた作業」が規格化・単純化されてているため、仕事の量がどんどん増えて行ったとしても、仕事の量に応じて忙しくなるだけの話で、それ以外のオーバーヘッドがとても少ない点だ（=linear scalability）。それぞれの「イベントに応じた作業」さえキチンと書かれていれば、その集まりには順番も秩序も必要がないので、色々な仕事のための「イベントに応じた作業」がごちゃごちゃに頭の中で混ざり合っていても何とかなってしまう点（system stability）もこの方法の利点である。

　つまり、これがソフトウェアで言うところの、「手続き型のプログラミング」と「イベント・ドリブン型のプログラミング」の違いである。手続き型は一連の作業の流れを把握するという意味ではとても分かりやすい記述の仕方だが、同時にいつくもの仕事を抱えてこなして行く時には、イベント・ドリブン型で処理した方が効率が良かったり、システムとしての安定度が高まるケースがある、という点が注目すべき点である。

　ここのところ技術系ブロガーの間で話題になっている、「C10K問題（参照１、参照２）」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った（もしくは頼りすぎた）多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。

　この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた９０年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである（さすがに、メインフレーム時代の話は私は知らない）。

　十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、博士論文のテーマに最適だと思っている。この論争は、ある意味では、ミニコンから降りてきたmulti-threadを多用した多重処理を支持する一派と、１６ビットパソコンの時代のnon pre-emptiveなOSの上で別の進化をしてきたasynchronous I/Oを利用した多重処理のアーキテクチャを支持する一派とのぶつかり合い、ということも出来るぐらい根が深いものだ。

　「単純化しすぎ」と批判されることを承知で、便宜上、前者を「multi-thread派」、後者を「asynchronous I/O派」と呼ぶことにする。両派の主張は以下のようなものである。

multi-thread派の主張

　人間は、一つの仕事を処理するときには、それを小さな仕事に分割して、順番に処理する。それゆえ、プログラミングもそんな人間の頭の構造を反映して、呼びたいAPIを順番に羅列して行く「手続き型プログラミング」が適している。もちろん、APIによっては、ファイルIOやネットワークIOのように遅延を持つものもあるが、そこはプログラマーにはできるだけ意識させず、OS内部で自動的にcontext switchを行って、それによって多重処理を可能にすれば良い。せっかく、CPUやOSのレベルでmulti-thread、multi-processをサポートしているし、context-switchのコストは相対的にものすごく小さくなったのだから、それを最大限活用すべきである。

asynchronous I/O派の主張

　multi-threadを多用した「手続き型プログラミング」による多重処理は、一見とっつきやすく簡単に見えるが、実はシステムの安定性、保守性、スケーラビリティの面で色々と問題がある。複数のthread（もしくはprocess）で共有するリソースへのアクセスをシリアライズするためのクリティカル・セクションをアプリケーションレベルできちんと使いこなすことは容易ではないし、I/O待ちのthreadの数が莫大になった時にそれぞれのthreadのcontextを保つために必要なリソースが膨大になる。それに加え、APIによる遅延をプログラマーが意識しないというスタイルのプログラミングでは、そういったAPI呼び出しによる遅延をユーザーから隠してレスポンスの良いアプリケーションを作ることが難しくなる。それよりは、できるだけ少ない数のthreadで、遅延を持つI/Oはすべてasynchronous APIを使ったメッセージ・ドリブン（もしくはイベント・ドリブン）なプログラミングによる多重化の方が優れている。

　この二つのプログラミング・スタイルに関するディベートは、９０年代前半にOSの設計に関わっていたMicrosoft、IBM、Appleなどの企業内部でさかんに行われ、GUI OS上でのthreadの使い方に関しては一応の決着を見たようにみえたが、それが９０年代中ごろから、インターネットを介した数百msecという桁外れに大きなの遅延に向き合わなければならないWWWブラウザーやHTTPサーバーが出てきた時に、さらに別のディベートとさまざまな試行錯誤が行われながらも、今に至っても（業界のトップクラスのエンジニアたちの間ですら）まだ決着が付いていない、というのが実情である。

　たまたまnon-preemptive OS（Windows 3.1）、preemptive OS（Windows 95）、WWWブラウザー（Internet Explorer）、HTTPサーバー（IIS/Personal Web Server）の設計・開発のどれにも深く関わってきた私としては、さまざまな失敗と成功を通して、それなりのノウハウも蓄積してきたし、言いたいこともたくさんある。しかし、そういったことを全部書くと、一冊の本になりそうなぐらいの量になるし、思いっきりテクニカルになってしまってエンジニア以外の読者をこのブログから失ってしまいそうなので、ここで書き続けるべきか少し悩んでいる（ひょっとしたら、以前から試してみたかった自費出版向きのテーマかもしれない…１０００部ぐらいならこのブログを通して売れそうだし^^）。とりあえず今日のところは、渡辺千賀さんの本のタイトル風に「その１（かもしれない）」とお茶を濁しておく。

　私の住むシアトルは、めずらしい大雪と氷点下の日々が続き、交通機関（とはいっても車とバスだけだが）が麻痺状態。いろいろなところで車が立ち往生しているため、普段１５分かかるところが３時間かかったりと、大騒ぎだ。

　特に悲惨なのは、一度融けた雪が凍って出来た凍結道路。４輪駆動もアンチロック・ブレーキも、凍結した坂道では何の役にも立たない。

　ローカル局のKing5ニュースで、まさに凍結した道路で完全にコントロールを失っている車の様子が放映されていたのだが、ウェブサイトでも公開されているので、リンクを張っておく（音が出るので注意）。

　Seattle Snow Storm

　２２秒目ぐらいのところで、運転手の「Help!」という叫び声が入っているところが何とも言えない。ちなみに、このビデオは視聴者からネット経由で送られてきたものだそうだ。「こちら側」の代表選手みたいに言われるテレビ局も、こんな形で視聴者からのコンテンツを利用できれば、まだまだ捨てたものではない。

　先日の「スティーブ・ジョブズの面接試験、iPhone編」には、たくさんの方々にコメントをいただき、まさに双方向性のコミュニケーションの楽しさを満喫させていただいた。出題の際にも述べたが、この手の問題には特に決まった正解があるわけでもないので、出来るだけ多くの方から、さまざまな意見が出てくることそのものにとても価値がある。

　しかし、出題者の私が皆さんの意見を読んでいるだけでは双方向性が不十分なので、今日は私なりの解釈を書いてみる。

　結論から先に言えば、新生アップルの経営戦略が「パソコン上で走るiTunesをホーム・エンターテイメントにおけるメディア・ハブおよびメディア・ゲートウェイのデファクト・スタンダードにし、それにスポークとしてつながるさまざまなデバイスを開発し、同時にiTune Storeからそういったデバイス向けのさまざまなデジタル・コンテンツをiTunesを通して流通させる」というものであるから、というのが私の解釈である。

　現時点でのアップルにとってもっとも戦略的に重要な財産は、「iTunesを使って自分たちのメディアファイルを管理している何百万人ものユーザー」である。その大半がすでにiPodを持っているのは当然のことだが、同時にそのユーザーたちは、これからアップルが発売するiPhoneやAppleTVなどのさまざまなデバイスに真っ先に飛びつくであろう消費者でもある。

　もしあなたの知り合いに、iPod miniを使っているあまりパソコンに詳しくない人がいて、その人に「そろそろもう少し容量が多くて、ビデオを見ることも出来るデバイスに買い換えようと思うんだけど、何にしたら良いと思う？」と相談されたと想定してみよう。このとき、ほぼ同じ容量の新型iPodとマイクロフトのZuneが同じ値段で売っていたとしたら、あなたはどちらを薦めるだろう。

　私なら迷わず新型iPodを薦める。なぜなら、その人が今までiTunesを使って蓄積してきた音楽ライブラリやプレイリストなどのデータがそのまま使えるからだ。もちろん、マイクロソフトもその辺りは分かっていてiTunesからのデータのインポートをサポートしてはいるのだが、その手の移行には必ず何らかのリスクや制限が伴うし、ライブラリの移行後にiPod miniとZuneの両方を使い続けることにはかなり無理がある。

　つまり、一度iTunesを使い始めたユーザーにとってみれば、機能や値段でよほどの差がない限り、他社製品に乗り換えずにアップル製品を買い続けることがユーザーエクスペリエンスの面で最も正しい選択なのだ。アップルもその辺りはきちんと意識しており、単に音楽ライブラリやプレイリストだけでなく、ポッドキャスト、ビデオ、そしてiTune Storeと、使えば使うほどiTunesから（すなわちアップル製品から）離れにくくなる要素を着実に増やして来ている。

　別の言い方をすれば、アップルは、マイクロソフトが喉から手がでるほど欲しがっていた、ホーム・エンターテイメントにおけるメディア・ハブおよびメディア・ゲートウェイのデファクト・スタンダードの地位を、iTunesというソフトウェアを使って、あっさり奪いつつあるのである。これこそが、ビル・ゲイツがアップルのiTunes+iPodの成功をあれほどうらやましがっている理由だし、マイクロソフトが今までのOEM戦略を曲げて自らZuneというハードウェアを出さざるをえなくなった理由である。

　そう考えてみると、今回のMacWorldで発表されたiPhoneもApple TVも、ハブであるiTunesからみれば、iPodと同じ位置づけのスポークにあたるデバイスに過ぎず、そういったデバイスから直接iTune Storeにアクセスしてコンテンツを購入できるようにする（アップルおよび既存のiTunesユーザーにとっての）メリットはほとんどない。そこでiTunes抜きの中途半端なユーザー・エクスペリエンスを提供して、他社のデバイスと真っ向から戦うよりも、あくまでパソコン上で動くiTunesがあるからこそのトータルなユーザー・エクスペリエンスで勝負して、他社に真似出来ない戦い方をするのがアップルにとって正しい戦略である。

　今回のiPhoneとApple TVの発表で明らかになったのは、パソコン上で動くiTunesをハブに、エクササイズの時にはiPod Shuffle、車のダッシュボードにはiPod nano、持ち歩くのはiPhoneかビデオ iPod、そして家のテレビやAVシステムにはApple TVと、TPOに応じてさまざまなデバイスを使いこなすというライフスタイルにフォーカスして、iTunesに匹敵するソフトウェアを持たない他社には追従ずることが難しいユーザー・エクスペリエンスで勝負する、というアップルの戦略である。これこそが、Apple Computer Inc.からApple Inc.へと名前を変更し、本気でコンシューマー・エレクトロニクス市場に進出することを宣言した新生アップルのビジョンなのである。

　MacWorldでのiPhoneの発表に妙に興奮してしまい、すっかり書くことを忘れてしまっていたのだが、私がCEOを務めるUIEvolutionもCESに合わせてプレスリリースを出したので、今日はそれの紹介。

　プレスリリース本文（英文）はこれ、
　Partnership with AMS (austria micro systems)

　要約すると、「austriamicrosystems(AMS)が携帯型エンターテイメントデバイス向けに作ったAS3525、AS3527というチップ上にGUIを作るプラットフォームとしてUIEngineを選択」となる。

　消費者が手にとって見ることのできる具体的なデバイスのアナウンスメントではないので、あまりエキサイティングな話ではないが、パーベイシブ・アプリケーションの実現に向けて、こんなふうに一歩づつ前進して行くことは、うちの会社にとってはとても大切。CEOとしては、iPhoneのニュースに浮かれてばかりいずに、ちゃんと本業のこともこのブログで書かねば、と少し反省してのエントリー。

　ちなみに、AMSは、本社がオーストリアの古いお城の中にあり、そのすぐとなりに最新の半導体工場を持つユニークな会社（お城の写真、入り口の写真）。歴史的建造物を保護するための苦肉の策として、政府がオフィスビルとして貸し出したそうだが、それがいかにもオーストリアらしい。

　待望のApple iPhoneの発表を記念して、今回はiPhoneにまつわる頭の体操。

　多くのブログでも指摘されているが、iPhoneはWiFi、GSM+EDGE、Bluetoothというネットワーク機能は持ちながら、iPhoneから直接iTune Music Storeにアクセスして音楽やビデオを購入することは出来ない（日本の「着うたサービス」に慣れている人の中には、「これじゃあ日本じゃ通用しないよ」と批判する人もいるぐらいだ）。

　ここで問題である、アップルはいったい全体、なんでiPhoneを使って直接iTune Music Storeから購入できるようにしなかったのだろうか？

　ジョブズは、自分が「これは絶対に必要」と思った機能を落とすようなことはしない。つまりこれは、「iPhoneからのコンテンツの直接購入」という機能を、ジョブズが（１）そもそも必要ない、と感じたか、（２）あった方が良い機能だがプライオリティは低い、と考えたという証拠である。

　ちなみに、このブログではこの手の頭の体操問題を「ビル・ゲイツの面接試験」シリーズと呼んでいるが今回はスティーブ・ジョブズに敬意を表して、「スティーブ・ジョブズの面接試験」と呼ぶことにした。例によって、正解が一つに定まっているわけでもないし、誰もが同じ答にたどり着かなければならない理由もない。大切なことは、「自分がスティーブ・ジョブズだったらどう考えるだろう」と、自分以外の人の立場になって考える習慣を身につけること。

　今年のNew Year Resolution（年初の誓い）は、「英語のブログにもっとエントリーを書くこと」。従業員とのコミュニケーションのためにも、楽して日本語ばかりで書いているわけにはいかない。

　その第一段がこれ。

iPhone, raising the bar of "total user experience"

　今回のMacWorldでiPhoneがアナウンスされることはとあるルートからの情報ですでに１００％確実と確信していたのだが、何と言っても驚かされたのが、進化がすっかり止まっていた「電話をかける」という携帯電話ならではの機能のユーザー・エクスペリエンスを向上させたこと。

　私も日本では最新の「3Gケイタイ」を使っているのだが、せっかくの高機能端末も、留守番電話のチェックをするときには、２０世紀からほとんど進歩していないプッシュボタン式のサービス（「このメッセージを消去したいときは９を、保存したいときは８を…」というやつ）を使わなければならないことに以前から疑問を持っていた。そんな誰もが持っているような疑問をストレートにCingular Wirelessに投げかけて、留守番電話、割り込み電話、電話会議、などの携帯電話本来の機能の使い勝手を格段に向上させた点がiPhoneのすごさである。日本で携帯電話を作っている人たちは、「そんなの技術的には簡単だよ。でも通信事業者がやらせてくれなかったんだ」と悔しがっているに違いないが、そんな「技術的にはそれほど難しくないが、色々な事情で一筋縄では出来ない」ことを出来るように持ってしまうのがスティーブ・ジョブズの力なのだ。

　全米最大のコンシューマー・エレクトロニクス・イベントCESが開かれているラスベガスからサンフランシスコに移動してMacWorldに参加。記者でもないのにこんな「CESとMacWorldのはしご」をしているのは私ぐらいかなと思いつつ早朝からスティーブ・ジョブズの基調講演に参加。そうは言っても、ブログの持つバイラル・マーケティング的な価値を考えれば、そろそろブロガーを記者と同じ扱いにしても良い時代が来ているのかも知れない（基調講演にブロガー用の招待席を用意するのってどうでしょう。そうしていただけたら来年も喜んで参加します^^→アップルの広報担当者の方）。

　ジョブズの講演とそこでアナウンスされたものに関しては、すでに色々なところで報道されているし、そのビデオも公開されているのでわざわざ書かないが、すなおな感想は「iPhoneの開発チームがうらやましい」である。技術的にどうだとか、ビジネスとしてどうだ、ということを硬いことは抜きにして、純粋にエンジニアとして考えると、iPhoneは「ぜひともチームの一員として開発に参加してみたい」商品。そんな商品の開発に関われるアップルのエンジニアは本当に幸せだろうし、それを可能にしているジョブズのリーダーシップにはひたすら脱帽である。

　Apple TVに関しても、iPhoneに関しても書きたいことはたくさんあるが、まずはせっかくCESとMacWorldの両方に参加したので、今日はその二つのカンファレンスの比較をしてみたい。

　まずは、基調講演だが、ビル・ゲイツの基調講演と、スティーブ・ジョブズの基調講演を比べると、圧倒的にスティーブ・ジョブズの勝ち。商品の魅力と言う意味でも、ビジョンに関しても、圧倒的な横綱相撲であった。

　次に二つのカンファレンスで目に付いた商品の中から、「これは欲しい！」と思えたベスト・スリーを並べるとこうなる。

１．Apple TV （MacWorld）
２．iPhone　（MacWorld）
３．SlingCatcher （CES）

　Apple TVは、シアトルに帰りしだいアップルストアで申しこむ予定だし、iPhoneも６月に発売しだい購入する。SlingCatcherに関しては、使い勝手をもう少し研究してから購入を決める。

　そんなわけで、CES対MacWorld、私が見る限りMacWorldの圧勝である。世界中の何百社ものコンシューマー・エレクトロクス企業がつどうCESと、アップルたった一社が仕切るMacWorld。やはり数ではなく質なんだと、そして技術ではなく「ユーザー・エクスペリエンス（おもてなし）」なんだ、とつくづく実感した。

　今週は、日曜日にシアトルを出て、ラスベガスのCESを見てから、月曜日の夕方にはサンフランシスコに移動して、火曜日の朝からMacWorldという強行軍。ミーティングの合間にビル・ゲイツによる基調講演（CES）と、スティーブ・ジョブズによる基調講演（MacWorld）の両方を楽しもうという贅沢な計画。

　とりあえずCESでの日程は予定通りに消化し、サンフランシスコ行きの飛行機を待っているところ。CESの今年のテーマは、HDTVとConnected Experience。Panasonicの縦長プラズマ・パネルを使ったライブ・セッションは、去年のNABでのセッションよりもさらに洗練されていていて見ているだけで楽しい。大画面テレビという意味ではSharpの１０８インチ液晶が目玉か。Sharpが発表したViiv対応テレビは、家電とパソコンの相互接続という意味では一つのブレークスルー。他の家電メーカーが追従するかどうかが見ものだ。

　ちなみに、Viivを「ヴィーブ」と発音する人と「ヴァイブ」と発音する人がいるので、どうしてそんなことになっているのか、と疑問に思っていたので、思い切ってインテルの人に尋ねてみた。すると、基本的には「ヴァイブ」が正しいのだが、「ヴァ」と「バ」の区別をしない日本で「ヴァ」を「バ」と発音してしまうと、少し問題のあるものの意味になってしまうので、日本でだけは「ヴィーブ」と読むことにしているそうだ。確かに…

　ビル・ゲイツの基調講演は、なぜか全体に盛り上がりに欠ける講演。Vista中心の講演であまり目新しいものがなかったこともあるが、全体の構成がそもそもいまいち。Fordと提携のアナウンスメントは、ほとんどすべての車と繋がるようになったiPodと比べてどこが良いのかいまいち伝わってこなかったし、せっかくのXBox360向けのHDTV配信の発表は少し時期尚早に思える。会場からの拍手があまりにも少なく、拍手を催促する場面まである始末。

　プレゼンはさておき、発表されたものの中ではDellのホーム・サーバーに個人的には一番注目している。XBox386をメディア・エクステンダーとして使ってホーム・サーバーに蓄積した音楽や映像を楽しませる、というのは、アップルのiTVとも真っ向からぶつかる戦略。ユーザーとしては、家庭内のメディア・ネットワークを、マイクロソフトのテクノロジーで繋ぐか、アップルのテクノロジーで繋ぐかの選択を迫られることになりそうだ。

　アップルの強みは(メディア・サーバーの役割も果たせる)iTunesがWindowsマシンでも動いてしまうこと。この強みとiPodの成功を生かしてiTVを普及させることができればアップルにも十分勝ち目はある。明日のジョブズによる基調講演が楽しみだ。

　Slingboxを導入して日本のテレビを見始めて１０日ほどになるが、Sharpのガリレオと違って録画しておいたテレビ番組を（ダウンロードせずに）ストリーミングで見れるという点は圧倒的に便利である（ガリレオにもストリーミングの機能があるにはあるが、1-2Mbpsぐらいではまともに動作しない）。おかげで、年末年始の特別番組はたっぷりと楽しませてもらった。

　それに加えて現在放送中の番組を生で見ることができるという点が、思っていたよりもインパクトが大きい。何か他のことをしながら日本のテレビをつけっぱなしにしておくというだらしない楽しみ方をすると、「ここは本当にシアトルか？」と不思議な気持ちになる。

　動画のクオリティは、「VHSの三倍モードぐらい」と評価した最初のころよりも少し良くなった。４２インチのプラズマに表示しても、少し離れて見れば全く気にならない－VHSの通常モードぐらいか。理由を調べてみると、当初は700～800Kbpsしか使っていなかった帯域を、今は1.3～1.4Mbpsをコンスタントに使っている。どういうアルゴリズムを使っているとこういうことになるのかは不明だが、「このネットワーク環境ならこのくらいの帯域まで使っても大丈夫」と自動的に判断しているようだ。ちなみに、我が家のネットワーク環境は、上り側の日本はUSENの光（100Mbps）、下り側のシアトルがVerizonのADSL（1.5Mbps）という構成。つまり、下りのADSLで制限される帯域をほぼ目一杯使って最適な動画をストリーミングしてくれるのだ。

　Slingboxのストリーミングには、自動的に最適化してくれるSlingStreamモードと、自分でビットレートや解像度を個別に指定するManualモードがあるのだが、Manualモードで最高の設定（640x480、full rate）にすると、画像の質は上がるのだが、時々フレーム落ちで動画の動きがギクシャクする。それと比べるとSlingStreamモードは、解像度は若干落ちるものの、動画の再生はいたってスムーズ。実際の視聴にはSlingStreamモードが適しているようだ。

　Slingboxの先に繋がっているハードディスク・レコーダ（Toshiba Varadia RD-XD92D）の操作は、リモコンのボタンに若干不足があるのと（この問題はカスタムボタンを設定することで解決可能らしい）、ネット越しのリモコン操作特有の遅延に少しいらいらさせられるのを除けば、今のところなんとか使いこなせている（とは言え、誤操作で録画した番組を全部消してしまったりしているが、これはSlingboxのせいではない^^;）。

　ちなみに、先日のエントリーでも述べたが、「日本のテレビ番組を見終わるたびにいちいちストリーミングを止め、次に見るとき再開する」、という使い方はあまりにも不便である。そのため、どうしても「単にテレビの入力切替だけで、日米のテレビ番組を自在に切り替えて見る」という贅沢な使い方になってしまう。そんな使い方をしても誰かに直接迷惑をかけるわけではないとは言え、見てもいない動画を1.4Mbpsでストリーミングしっぱなしとは、あまりにもインフラの無駄使いないので、なんとか解決方法を見つけなければならない。本格的にIPTVの時代がやってきたときに、この「ストリーミングしっぱなしによるインフラの無駄使い」は結構問題になるのではないだろうか。