Life is beautiful

理想のパワーナップ・チェアを求めて...

　ここの所、朝の４時半ぐらいから起きて朝ご飯前に２〜３時間集中してプログラミングをするのが日課のようになっているが、これを続けていると、昼過ぎぐらいから妙に眠くなって頭の回転が鈍くなる。それを解消するには、パワー・ナップが最高

　ちなみに、パワー・ナップとは「仕事中に堂々とする昼寝」のこと。ニューヨークの金融関係のエグゼクティブが、会議をしながら食べるランチをパワー・ランチと呼んでいるが、そこから「パワー（＝仕事をバリバリしている人の）」の部分を取ってきて「ナップ＝昼寝」とくっ付けただけだと私は理解している。

　寝すぎても寝足りなくても効果が薄いので、自分なりにベストの長さを探す必要がある。私の場合、３０分以上寝ると深い眠りに入りすぎて、逆に「寝疲れ」してしまうので、いろいろと実際に試した結果、たどり着いたのが１８分。これくらいだと、眠気だけが取れてすっきりとしてとても良い。

　家で仕事をしている時は、ソファーやベッドで寝てしまえば良いのだが、オフィスに出ている時が少々問題。駐車場の車の中で寝るというのを何度か試みたが、どうも寝心地が悪いので（新しい商品のアイデアですよ→自動車メーカーの人）、やはりオフィスに「パワー・ナップ・チェア」を置くしかないとググってみると出てきたのがこれ。

　いかにもニューヨークの投資銀行のエグゼプティブのオフィスに似合うデザインだ。私のオフィスには、こんな大げさなものを置く場所もないし、８０００ドル（８０万円）は出したくないので、もう少し探してみることにする。本当はビーチ・チェアでも十分なんだが、「それだけは絶対に変よ。やめて！」と妻に却下されてしまった。波の音でもパソコンのスピーカーから流しながら、アイマスクの代わりに麦わら帽子を顔にかぶせて、というのも悪くないと思うんだが...。

UIEジャパン、映像配信サービス「ひかりTV」において、GUIの“ユーザー・エクスペリエンス”を演出

　ここのところ個人的な趣味のiPhoneばかりに気を取られて、あまりUIEの話は書いていないが、久しぶりに良いニュースが舞い込んできたのでここで紹介。

　UIEジャパン、映像配信サービス「ひかりTV」において、GUIの“ユーザー・エクスペリエンス”を演出

　UIEngineというミドルウェアを持ち、思いっきりローレベルな組み込み機器のドライバーのレイヤーから、ウェブ・サービスまで幅広く開発をこなすUIEだが、最終的な目的は「すばらしい技術を作る」ことなんかではなくて「最高のおもてなしをユーザーに提供すること」。その意味では、これからの「ネットでテレビを見る」時代のリーダーシップをとることになるだろうNTTのIPTVサービスのおもてなしの設計を担当するということは、まさにUIEという会社の存在意義を証明するような話で、創設者の私としてはうれしい限り。

　ちなみに、しばらく採用を控えていたUIEジャパンも、今年度から再び積極的に優秀な人材を採用して行くとのことで、我こそはと思う方はぜひとも応募していただきたい（詳細）。

　エンジニアとしての技量はもちろんだが、なんと行っても大切なのは、こんなUIEのビジョンに熱くなれる人。以前このブログで、会社の方向性と自分のやりたいことのベクトルが会ったときに最大の力が出せる、という話を書いたが、まさに欲しいのは「会社の方向性とベクトルが最初からぴったりと一致している人」。特にApple TVを見て「俺ならこれよりずっと良いものを作ってみせるぜ」と豪語してしまうような人は大歓迎。

プラットフォームを選ぶということ

　この業界で仕事をしていると、しばしば迫られるのが「どのプラットフォームに向けて商品開発をして行くのか」という決断。会社としての経営判断の場合もあれば、個人のスキルアップやキャリアパスのための判断の場合もあるが、いずれにしろ限られたリソース・時間をいかに有効に使うか、という点ではとても大切。

　パソコン用のソフトウェアであれば、「Windows向けに作るのかMac向けに作るのか」というOSレベルでの選択肢もあるし、「Windows Vista独自の機能を使って差別化を図るのか、それともWindows XPでもちゃんと動くように作ってまずは大きな市場をとりに行くのか」というOSのバージョンレベルでの選択肢もある。もちろん「そもそも特定のOS向けのアプリを作るべきか、それとも、すべてウェブ・アプリケーションとして作るか」というアーキテクチャ・レベルでの選択肢もある。

　「少なくともここ数ヶ月はiPhone向けのアプリケーションの開発に真剣に取り組む」と決めた私だが、そこには当然のごとく「Windows MobileでもGoogleのandroidでもJavaFXでもなく、iPhone OSを開発プラットフォームとして選び、そこにそれなりの投資をする」という意図的な「プラットフォームの選択」がある。

　そんな私を見て、「どうしてandroidではなくて、iPhone OSが選ぶべきプラットフォームだということが中島さんには分かるんですか」と、あたかも私が「iPhone OSが市場で大成功をおさめること」ことを確信でもしているような質問をしてくる人が何人かいたが、そこには大きな誤解がある。

　もちろん、私なりに市場規模、ビジネスモデル、技術そのもの、競争相手の状況などを総合的に見て「どのプラットフォームに投資をする価値があるか」という判断をある程度はするが、それはあくまで「予想」にすぎず、「確信」などというものからはほど遠い。Windows Mobileが着実にシェアを伸ばして行く可能性もあれば、Googleのandroidが携帯電話OSのデファクト・スタンダードになる可能性だって十分にある。iPhoneのマーケットシェアが、アップルの当初の目標の１％を超えて、数パーセント、十数パーセントになる保証など全くない。

　では、なぜその不確定さにも関わらず、私は（少なくとも個人として）iPhone OS上でのアプリケーションの開発に本気で取り組むことに決めたのか。簡単に言えば「iPhoneとiPhone OSに魅せられたから」であり、「iPhoneに成功して欲しい」と強く感じているからである。

　アラン・ケイが言ったように、未来を予測する最良の方法は未来を創りだすことだ（参照："The best way to predict the future is to invent it"）。「どのプラットフォームが勝つか」を予想してそれに基づいてビジネス判断をすることは「勝ち馬に乗ろうとする」行動でしかないが、こんな風に「このプラットフォームを勝たせたい」という思いで積極投資をすることは、自らが特定の馬を選んで「その馬を勝たせよう」とする行動であり、ある意味で「未来を創りだそう」とする行為だ。

　別の言いかたをすれば、「プラットフォームを選択する」という行動は、「どのプラットフォームが市場で成功するかを読む」という受け身の経営判断と（もっと消極的なものとして「勝者が明確になるまでは一切の投資はしない」という戦略もある）、「どのプラットフォームを勝たせたいか」という積極的な経営判断の組み合わせである。もちろん、後者には「自分がサポートすることによってプラットフォームが成功する可能性が高くなる」という、ずうずうしいまでの楽観主義と自己の過大評価が入っているが、結果から見ればそのくらい楽観的な人たちがこの業界を動かしてきたことを考えれば、そういう積極的な経営判断をしてこそ、この業界にいる醍醐味が味わえる、というのが私の信念である。

　ということで、iPhone向けのアプリケーションをApple Design Award向けに提出させていただいたわけだが、あとはWWDCでの結果発表を待つのみである。当面の目標はDesign Awardをもらうことだが、もちろんゴールは「iPhone App Store」でアプリケーションを配布して、できるだけたくさんのiPhoneユーザーに私が作ったアプリケーションを使ってもらうことにある。サーバー側を作っている相棒に「当初は何人ぐらいのユーザーが使うと予想する？」と聞かれて「３０万ユーザーぐらいが一度に来ても耐えられるように設計しておいて」と答えた私は、保守的な人たちから見れば「超」楽観的なのかも知れないが、そのくらいの意気込みを持っていなければ、眠る時間を削ってまでもの作りに集中するエネルギーは生まれてこない。

「少年よ大志を抱け！」よりも「若者よどん欲になれ！」の方が良くないか？

　月刊アスキー向けに「仕事を楽しんでしている人に共通するもの」というテーマでコラムを書いているのだが、そこで引用した「Boys, be ambitious（少年よ大志を抱け）！」に含まれたメッセージがどうも気に入らない。

　「少年よ大志を抱け！」という言葉には、「楽して金儲けしたい」、「風呂屋の番台に座ってみたい」、「美人の嫁さんが欲しい」、「一度で良いから女優とデートしたい」、「プール付きの家に住みたい」、「有名になって女子アナと結婚したい」、「一発当てて、後はハワイでのんびり暮らしたい」などの、下世話な欲求を否定するメッセージが含まれている。特に日本語訳の「大志」という言葉には、「志はもっと大きくなければいけない」「金儲けなど考えてはいけない」「私利私欲に走ってはいけない」というメッセージが強くこめられている。

　「最近の若者は覇気がない」などと批判する大人がたくさんいる。そんな人たちに限ってホリエモンのように「金儲けをしたい」ことを包み隠さずに正直に認め、それに基づいて行動する若者が現れると「拝金主義だ」と頭から批判するが、彼らはそこに含まれた矛盾に気がついていない。そんな大人たちから「金儲けみたいな下世話なことは考えずに、志を高く持て」なんて言われ、「そうか、俺もがんばろう」と若い人たちが考えて日本が元気を取り戻す、という金八先生のようなシナリオは、どうもしっくりこない。

　私の知り合い（アメリカ人）が、今年の夏からドバイの会社に転職することになった。理由は「あっちにはオイルマネーがあふれているから。そこで一角千金を当てて、早めに悠々自適の引退をしたい」からだそうだ。下世話である。どん欲である。でも、彼の目はきらきらと輝いている。

　そもそも資本主義というのは、「企業や個人が自己の利益を最大にするためにする経済活動が社会全体に利益をもたらす」ように設計されている。社会主義の国ならいざ知らず、日本が資本主義の国である限り、人々の「利益を追求する」強い欲求があってこそ経済活動がさかんになり、それが国力につながる。「資本主義社会の原動力」である人々の富への欲求を「拝金主義」という言葉を使って頭から否定することは、資本主義そのものを否定することと同じである。

　こんな理由で、私は「少年よ大志を抱け！」という言葉があまり好きではない。現実離れしていて心に響いてこない。もっとストレートな「若ものよ、どん欲になれ！」の方がずっと元気がでると思うんだがどうだろうか？

スティーブ・ジョブズが一度アップルを追い出されてNeXTを作ったからこそ存在するiPhone OS

　ここのところブログの更新がさっぱりなのは、iPhone向けのアプリの開発で大忙しだから。４月１５日にApple Desng Awardの件がアナウンスされてから二週間、ようやくAward向けのアプリも形になって来たので一息つける。締め切りの５月１２日まではまだ少し余裕があるが、締め切り寸前にプログラムを変更するのが大嫌いな性分の私はこのくらいの段階で「今日出そうと思えば出せる」ぐらいのクオリティに仕上げておかないと気が済まないのだ。後は徹底的なテストと、見た目の微調整。「ベータ版」としては十分のできだ。

　iPhone SDKもbeta4になり、ようやくチューニング用のinstrumentsも安定して動き始めたので、今日はメモリー・リークの徹底的なチェック。非同期通信だらけなのと、Objective-C覚えたての時に書いたコードが混ざっているため、予想通りリークだらけだったが、このツールのおかげて順調にリークを直すことができた。ガベージ・コレクションのないiPhone OSの場合、自分でリファレンスカウントの管理をちゃんとする必要があるが、非同期通信をきちんとサポートするためには、Model-View-Controllerのアーキテクチャ徹底した上で、それぞれのライフサイクルをきちんと考え抜いてノーティフィケーションのメカニズムを作らないと安定しては動いてくれない。このあたりのノウハウに関しては、一度ちゃんとまとめて書いてみたいが、少なくともiPhone SDKのNDAの呪縛が解けてからのことだ。

　ちなみに、３月からはじめたObjective-Cにもすっかり慣れたが、これはすばらしい言語である。スクリプト言語なみの自由度を持ちながら、必要なところはstrong-data-typeな部分を活用して「つまらない人的ミス」を減らすことができる。C++やJavaよりは明らかに開発効率が良く、JavaScriptやActionScriptよりも遥かに自由度と完成度が高い点が私としてはたまらなくうれしい。

　しかし何と言ってもすごいのが、iPhone OSと開発環境の充実度。Interface Builderまでもがきちんと動くので、「組み込み系の開発環境」としてはブッチギリでNo.1だ。数年前からこの分野でプラットフォームを提供している、Sun Microsystems、Microsoft、Qualcomm、Symbianがここまであっさりと抜かれると誰が予想できただろう。まあ、それもこれも、スティーブ・ジョブズが一度アップルを追い出され、NeXTを作ったからこそiPhone OSが存在するというのは何と言うドラマだろう。

 

iPhoneアプリを作る際に注意すべき５つのポイント

　毎日のように「iPhoneアプリでApple Design Awardを取るぞ！」と騒いでいるので、知り合いに「それって（現実が分かっていない）大学生のノリですよ」と指摘されてしまった私だが、マイクロソフトを２０００年に退社してからは、ひたすらモバイル・組み込みの世界で仕事をしてきた私としては「俺が取らなくて誰が取る？」という気分。その超楽天的な態度が彼が言うところの「大学生のノリ」なのだろう。

　市場に受け入れられるアプリを作るためには、もちろん「誰にどんな価値を提供するのか」が一番大切。しかし、そこには残念ながら成功の一般方程式はないので、今日は比較的に一般化しやすい「どう作るか」という部分に関して、まとめることにした。

1. ユーザーの利用シーン・使用パターンを良く考えて作る

　パソコンやゲームコンソール向けのソフトと大きく違うのが、ユーザーの使用パターン。iPhoneに限らず、携帯電話用のアプリは基本的には「一回のセッションはわずかな時間、でも一日に何回も使う」もの。例えばゲームであれば、１時間ぶっ続けに遊ばないと楽しめないゲームではなく、ちょっと電車を待つ時間に２〜３分遊んだり、タマゴッチのように「基本的にはずっと遊んでいるが実際にアプリとやり取りをするのは時々」なゲームを作るべき。

2. １回に一つのアプリしか走らせられないことを強く意識して作る

　パソコンから来た人たちは、iPhone OSがアプリをバックグラウンドで走らせることを許さないことに不満なようだが、まさにここをキチンと理解して作り込むことが「良い携帯アプリ」を作るために大切。パソコンと違ってメモリの限られた携帯電話では、バックグラウンド・アプリを走らせる余裕などないし、そんなことを許してしまっては、Windowsパソコンのように「長く使っているとどんどんと遅くなるマシン」になってしまう（これって、自分に対する皮肉か？^^;）。途中で電話がかかって来ても、ユーザーがいきなりホームボタンを押してしまっても、ユーザーの大切なデータがなくなったり壊れたりしない、そんなアプリを作らねばならない。

3. ハードを強く意識して最適化する

　iPhoneの場合は、「CPUは非力だが強力なGPUを積んでいる」、「メインメモリは限られているが、フラッシュメモリは豊富にある」、「通信は遅いGPRSと早いWiFiの二種類がある」などの特徴があり、そのあたりを強く意識したアプリケーションの設計が必要となる。特に「どの処理をGPUが助けてくれるのか」を強く意識して設計すると、見栄えが良くて消費電力の少ない優秀なアプリが作れる。たとえば、viewを書き換えるのはCPUだが、viewそのものを変形したりアニメーションしたりするのはGPUの役目なので、そこを意識してviewの書き換えを極力減らしながら、フェードインなどの効果はGPUにさせる。

4. ネットワーク遅延によるストレスを極力減らす

　これはAJAXでも同じ話だが、特にネットワーク遅延の大きいモバイル・ネットワークを利用したアプリケーションを作る場合、通信による遅延をいかにユーザーから隠し、ストレスの少ないおもてなしを提供するかが鍵となる。軟弱なプログラマーはマルチスレッドにたよりがちだが、そこにある「排他制御のワナ」にハマらないように気をつけなければならない。私は基本的には「シングルスレッドで複数の非同期通信を同時に使いこなすことに命をかける」タイプだが、こちらはこちらで気をつけなければならないことが沢山ある（メモリーリークとか、プログラムの煩雑さ、だとか）。

5. 機能の豊富さではなく、シンプルさと分かりやすさで勝負する

　機能が多すぎる携帯アプリを使っていて一番イライラするのは、UIが複雑すぎて一度何とかたどり着くことが出来た機能にもう一度たどり着くことができなくなってしまうこと（私の経験ではN900iがまさにそんな端末 ）。携帯アプリの場合、「どれだけ豊富な機能を提供するか」ではなく「（ユーザーに提供する価値を損なわずに）どこまで絞り込めるか」が勝負である。もちろん、絞り込みすぎたら役に立たないアプリになってしまうので、そのバランスが一番難しい。N900iは、撮影時の解像度は指定できるしマクロ撮影もでき、機能的にはとても充実していたが、肝心の撮影をしたい時に４つもクリックが必要、という最悪の作りであった（参照）。

　ということで、「どう作るか」に関しては良く理解しているつもりなので、後の問題は「何を作るか」。Apple Design Award 2008向けのiPhoneアプリの提出期限まであと約二週間。ブログなんて書いてる時間はないぞ、と。

Apple Design Award 2008

iPHONE DEVELOPER SHOWCASE - Highlights innovative and compelling new iPhone applications, built using the Beta iPhone SDK. Entries in this category must be pre-release, feature complete versions built with the Beta iPhone SDK which run within the iPhone Simulator or on a provisioned* iPhone or iPod touch.  Apple reserves the right to award more than one winning entry in this category. *You must have entered into the iPhone Developer Program License Agreement (“Program Agreement”) with Apple to provision an iPhone or iPod touch.【Apple Developer Connection - Worldwide Developers Conference 2008 - Apple Design Awards - Official Rulesより引用】

　Apple Design Award 2008がアナウンスされ、そこに"iPhone Developer Showcase"という私に最適なカテゴリーがあるのだが、なんと言ってもきついのは締め切りが５月１２日だということ。ベータ版のSDKがリリースされたのが３月６日。そこからわずか２ヶ月でfeature completeなアプリを出せというのは、かなり厳しい。

　しかし「スティーブ・ジョブズに（iPhone向けの良いプログラムを作ったことに関して）感謝される」という今年の目標のためには最短コースであることは疑いようもなく...。まあ、結局のところは「どう作るか」よりも「何を作るか」が大切なわけで、その意味では、発売当初からiPhoneを使い込んでいるヘビーユーザーである点を最大限に活用して、やるだけのことをやってみるか、と。

iPhone SDK, ついに実機でのテストが可能に

　ようやくiPhone SDKのDeveloer Certificateも入手し、実機でのテストが可能になった。さっそく、エミュレータ上で作ってあった「はてな人気エントリー・リーダー」を走らせようとしたのだが、XMLパーサーとして使っていたXMLParserが（OS-Xには標準装備だが）iPhoneOSには存在しないことに気がつき、libxmlで代用することに。これに結構手間がかかったのだが、なんとか解決してビルドに成功。

　WiFiに繋いだiPod touchにインストールすると、一発でちゃんと動く。非同期でブックマークの数を入手してくる仕組みもきちんと動いている。こうなったら、もう少し手を入れてからiTunes Storeで売ってみるのも悪くないかも知れない。これで会社は作れないだろうが、ブロガーの副収入としては十二分だろう（→はてなユーザーのみなさん：いくらぐらいなら買っても良いかのアンケートにブックマークコメントで答えていただけるとありがたい）。

　しかし、こうやってiPhone用のプログラムを書いていると、やはり私は「デバイス上のプログラミング」が好きなんだな、とつくづく思う。「今年こそはRuby on Railsをマスターするぞ」と予定していたにも関わらず、ここのところはiPhone/Objective-Cばかり書いているが、これが楽しくてしかたがないのだ。

　Safariというれっきとしたブラウザーが動くiPhoneでわざわざObjective-Cを使ってウェブ・サービスとのマッシュアップ・アプリを作るなんて酔狂なことをするエンジニアがそれほど沢山いるとは思えず、その意味では、その超ニッチな世界で誰よりも良い仕事をしてスティーブ・ジョブズから感謝をされる、というのを今年の目標にするのも悪くないかな、と思う今日この頃である（ちなみに、古川さんによると、私はジョブズに会ったことがあるどころが、自分が書いたソフト「Candy」を見せて悔しがらせたことがあるらしいのだが、さっぱり覚えていない...）。

「ページビューを稼ぐにはやはりブクマだよね」を検証してみた

　昨日のエントリーに引き続き、今日もブログのページビューの統計解析。今日は、一週間あたりのブックマーク数とページビューの相関関係をプロットしてみた。

　これもしっかりと相関関係が出ている（一つだけ例外的に４８０近くもブックマークを集めたにも関わらずページビューが極端に低い週があるが、これは年末で例外的にトラフィックが低かった週のデータ）。

　最小二乗法で求めた直線の方程式は、Y＝53595+45X（Y:ページビュー、X:ブックマーク数）。Coefficient Determination（R^2）は３７％。相関関係はエントリー数よりも強い。"45X"の項目は、ブックマークが一つ増えるとページビューが４５増えることを示しており、ページビューを稼ぐためにはブックマーカーに受ける記事を書くことが一番の近道だ、ということを表す。

　◇　◇　◇

　さて、ここまで読んでいただいて、あなたはどう感じただろうか？「そうか、やはりページビューを稼ぐにはブックマーカーに受ける記事を書くに限る！」と頭から信じてしまった人は、少し気をつけた方が良いと思う。まさにこれが「統計のワナ」だからである。

　このデータが示すことは、単にブックマークの数とページビューに相関関係がある、ということを示すだけの話であり、どこにどういう因果関係があるかは教えてくれない。

　解釈としては、

1. ブックマークが増えると、その結果ページビューが増える
2. ページビューが多いと、その結果ブックマークの数も増える
3. ある条件が整うと（たとえば「多くの人にとって読む価値のあるエントリー」を書くと）ページビューも増えるしブックマークも増える

の三通りがあり、さらにその組み合わせ、という可能性すらあるのだ。ブロガーとしては、「それなりのエントリーを書くとページビューもブックマークも増え、その結果ブックマークや引用が増えると
その相乗効果としてさらにページビューが増える」というのが実感である。

　◇　◇　◇

　結局のところ、統計学を学べば学ぶほど明らかになって来るのは「この手の統計データを見た時には、一見どんなに説得力があろうと、基本的には頭から疑ってかかるべき」という話と、それと表裏の関係にある「実際にはあまり意味を持たないデータから、グラフなどを使って一見説得力のある資料を作ることは統計学の知識さえあれば結構簡単で、それで騙される人は結構多い」という話である。

「ブログのエントリーは多い方がページビューが稼げる」という説を統計学的に検証してみた

　ここのところ統計学を少しまじめに勉強しているのだが、そこで身につけたばかりのregression analysis（回帰分析）の手法を使って、「ブログのエントリーは多い方がページビューが稼げる」という説が本当かどうかを検証してみることにした。

　まずは、このブログの過去２４週間の週ごとのエントリーの数とページビューの数を調べ、エントリーの数をX軸に、ページビューの数をY軸においてプロットしてみる。それだけでもなんとなく傾向があることが分かるのだが、これを最小二乗法を使って、直線で近似してみるとこんな感じになる。

　直線の方程式は、Y = 44109 + 3405*X （Y:ページビュー、X:エントリー数）。つまり、このブログの場合、エントリーを書こうが書くまいが、週あたり約４４０００のページビューがあり、エントリーを一つ書くごとに約３４００ページビューづつ増えて行くということになる。

　もちろん、あくまで統計データでしかないので、１００パーセント信用できる話ではないのだが、傾きに対するstandard errorを計算すると１１２０。詳しい計算は省略するが、最小二乗法で求められた直線の傾き（３４０５）がstandard errorの３倍以上もあるということは、「エントリーを多く書いた方がページビューが稼げるという説は９９．８７％の確度で正しい」と言えることを意味する。

　ちなみに、週ごとのページビューは、エントリーの数以外の影響（たとえばブックマークされた数、他のブログから参照されている数など）でも上下するが、その「ばらつき」のうちどのくらいが「エントリー数」のみに影響されているかを示す数値がcoefficiet of determination（決定係数）。ExcelのCORREL関数を使って計算できるcorrelation coefficient（相関係数）を二乗した数値で、このケースだと0.295。つまり、週ごとのページビューのばらつきのうち、約３０%がエントリー数による影響によるもの、残りの７０％が他の影響によるばらつき、ということが分かる。

　つまり、エントリーをこまめに書くことも大切だが、より多くの人たちにブックマークされたり引用されたりする良いエントリーを書くこと・サーチエンジンにより発見されやすいエントリーを書きためておくこともまた大切だ、ということ。それなりのページビューを稼いでいるブロガーにとってはあたりまえのことだが、こうやって数字にするとより説得力が増す。

　ちなみに、統計学に関しての書物で、私として一番のおすすめはブルーバックスの「統計でウソをつく法」。これを読むと、ちまたで言われている「統計学的に解析すると...」という発言に、いかに「ウソ」や「こじつけ」が多いかが理解できる。この本に書いてある例で一番印象に残ったのが、「大学生のタバコと成績の相関関係」の話。実際、とても強い相関関係が出るのだが、それは「タバコを吸うから頭が悪くなるのか」、それとも「頭が悪いからタバコを吸うのか」、それともまったく別の理由か？この話一つでも結構勉強になるので、一読の価値あり、である。

にわかに騒がしくなって来たMicrosoftによるYahooの買収話

　Wall Street Journalのニュース速報サービスに加入している私だが、今日の午後になってにわかにYahoo!関連の速報が入り始めた。時間軸にそって並べるとこんな感じ。

12:14「YahooがGoogleのサーチサービスを再び使う可能性についてGoogleと交渉している」という情報が流れる。Googleとがっちり提携してしまえば、Googleとは死んでも組みたくないMicrosoftにとってYahoo!を買収することが難しくなるからだろう、との憶測付き。

17:48「Yahoo!がAOLとインターネットビジネスを統合する交渉を進めている」という情報が流れる。Microsoftからのプレミアム付きの買収を蹴った経営陣としては、それよりも株主にとって魅力的な戦略を打ち出さない限り、株主から訴えられる可能性もある。AOLとの統合はその答えの一つだ、というもの。

19:01「MicrosoftとNews Corp（Fox、MySpaceの持ち株会社）がYahoo!を共同で買収するアイデアについて話し合っている」との情報が流れる。

　すんなりと行くとは最初から思えなかったこの買収劇。最終的にどう決着するのかはまだまだ読めないが、「MicrosoftがYahoo!の買収に成功する」という可能性はまだ残っているものの、それがビジネスとして成功して「Microsoftの株主に利益をもたらす」とはどうしても思えないんだが...。

「シリコンバレーのお約束」をことごとく破るアップル

Google's famous catchphrase, "Don't be evil," has become a shorthand mission statement for Silicon Valley, encompassing a variety of ideals that proponents say are good for business and good for the world: Embrace open platforms. Trust decisions to the wisdom of crowds. Treat your employees like gods. It's ironic, then, that one of the Valley's most successful companies ignored all these tenets. 【Breaking the Rules: Apple Succeeds By Defying 5 Core Valley Principles】

　シリコンバレーを代表する会社の一つであるアップルが、オープン・ソース、オープン・プラットフォームなどに代表される「独り占めしない」という「シリコンバレーのお約束」をことごとく破っているというWiredの記事だ。

　WebKit関連での動きなどを見ると必ずしもそうではないのだが、iPod+iTunes+iTunes storeというラインでの「囲い込み戦略」はアップルの戦略の要（かなめ）でもあるわけで、当然と言えば当然。それよりも興味深いのが、Mac／iPhoneにおける徹底的な「独自OS戦略」。

　特に後発のiPhoneに関しては、NokiaがしているようにJava+Flashあたりで攻めるのが通常の戦略だが、独自のハードウェアに最適化した独自のOSで真っ向から攻めてくるところが、何ともアップルらしいと言うか。

　しかし、Mac向けのOS Xまでは静観していた私もなぜかiPhone SDKには妙に熱くなってしまっているところがアップルの戦略にハマってしまったというか何と言うか。まあせっかくの縁だからこうなったらiPhone向けに何か本気で作ってみるのも悪くないな、と。