Life is beautiful

　ここのところブログの更新がさっぱりなのは、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アプリで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アプリの提出期限まであと約二週間。ブログなんて書いてる時間はないぞ、と。

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の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。つまり、週ごとのページビューのばらつきのうち、約３０%がエントリー数による影響によるもの、残りの７０％が他の影響によるばらつき、ということが分かる。

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

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

　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向けに何か本気で作ってみるのも悪くないな、と。

大まかな設計図をあたまに浮かべ、おもむろにコードを書き始める

　下回りの部品から順番に、丁寧に積み上げて行く

それでも必ず後から下回りの設計に気に食わない部分が出てくるので、

　苦しくてもそこは躊躇せずに壊しては作り直す

そうして行くうちに、だんだんと下の方から設計がしっかりしたものになってくる

　踏み固められた地面が固くなるように、少しづつ強固なプラットフォームが作られて行く

「今日はここまで実現しよう」と決めたら死にものぐるいでそこまで走る

　でも頭が回らなくなってきたら早く寝る

そうやって愛しい我が子を育てる様にコードを一行一行書いていく

　何百万人、何千万人もの人に使ってもらえる日を夢見ながら

プログラミングという楽しみがある時代に生まれて来ることができた幸せを噛み締めながら

Based on the findings of the study, AT&T is probably getting about $2 billion in incremental yearly service revenue due to the iPhone deal, and that figure will increase as more iPhones are sold.【Rubicon Consulting | Insight+ | Whitepapers | The Apple iPhone: Successes and Challenges for the Mobile Industryより引用】

　Rubicon Consultingは、AT&Tの約３００万人のiPhoneユーザーのうち「iPhoneのために他の携帯電話会社から乗り換えた」ユーザーが約１４１万人と仮定した上で、乗り換えユーザーによる売上げ増加が$1.64B、既存ユーザーによるデータ通信の増加による売上げ増加が$360M、トータルで$2B（日本円で約２０００億円）の売上げ増をiPhoneがAT&Tにもたらした、と試算している。

　いくつかの仮定に基づいた数字なので、具体的にこの数字がどのくらい正しいかはAT&Tしか知らないわけだが、数字の規模としてBillion Dollarであることは間違いないだろう。

　引用した論文にも書いてあるが、iPhoneは「若く、新しいものが好きで、裕福な」層に着実に受け入れられており、少なくとも初期段階で目指した「アーリーアダプターに受け入れてもらう」ことに関しては大成功である。Dan Farberの「iPhoneのユーザー層とBMWの所有者層は重なる」という指摘（参照）は正しい。

　そろそろドコモ・ソフトバンクとの交渉も佳境を迎えているはずだが、iPhoneに否定的だった夏野氏の退任（参照）はドコモがアップルと手を組む可能性を高めるが、逆にiPhoneの導入を強く主張する経営陣にいやけがさして夏野氏が辞めることにした、とも読めるところが興味深い。