Life is beautiful

先週、アップルに提出した neu.Stereo （４５０円、iPhone/iPad/iPod touch用）が順調に審査に通りリリースされたので報告させていただく。このアプリは、本来の開発計画に入ってはいなかったのだが、どうしても私自身が欲しくて作ったもの。最初にステレオグラムを見たとき以来、自分で作ってみたいと思っていたのだ。

ちなみに、当初は他のユーザーの作品を見る事ができるギャラリーアプリを無料で配布し、オリジナルのステレオグラムを作れるプラス版を有料で、と考えていたのだが、ステレオグラムを見て楽しむだけならアプリは不要だし、iPadやiPhoneを持たないユーザーでの楽しめるように、ギャラリーは Facebookのファンページを活用して提供することにした。iOSアプリへの Facebookファンページの活用は初めての試みなので、どうなるかが楽しみである。

以下が iTunes ストアでの説明にサンプル画像（クリックすると拡大する）を追加したもの。

◇　◇　◇

皆さんはステレオグラムをご存知でしょうか。一見ランダムな模様が連続して並んでいるだけに見えるが、少し工夫をして見ると立体的な画像が浮かび上がって来る不思議な画像のことです。

neu.Stereoはそんなステレオグラムを自分でも作ってみたいという人のためのツールです。使い方はいたって簡単。

1. まずはランダムに並べる模様のベースになる「パターン画像」をライブラリー、もしくは、アルバムから選択します。

2. 次に 「パターン画像」をどのくらいかき混ぜてから使うかを選択します。もともと複雑な画像を 「パターン画像」として選んだ場合は、一番左のものでも大丈夫ですが、元が単純な画像の場合は右のものを選びます。

3. 次に「Depth Map」と呼ばれる白黒の画像を作ります。ペンを使って文字や絵を描く事も可能ですし、ライブラリーやネット上のものを適当に組み合わせて使うことも可能です。

4. 次に進めば自動的にステレオグラムが作られます。アクション・メニューを使って、作ったステレオグラムをメールで友達に送ったり、TwitterやFacebookに投稿することも可能です。Facebookにはneu.Stereoのファンページもあるので、そこに自分の作品を投稿したり、他のユーザーが作った作品を楽しむこともできます。

ではお楽しみください!

　AppStoreがオープンして２４時間が過ぎたが、PhotoShareのユーザーは順調に増えている。あまりに昼夜なしに直線的に伸びたので、最初は統計データの間違いかと思ったが、投稿される写真も順調に増えており、間違いではないようだ。ちょうど米国のユーザーが寝静まった頃に日本を含めて他の国でiPhone3Gの発売が始まったので、ちょうど補完するような形になったと考えられる。

　朝になってiTunesサーバーの調子が悪くなりiPhone 2Gのユーザーが新しいOSをダウンロードできない、という問題があったようだが、そこは新しく発売されたiPhone 3Gが補う形になったのか午前中もさらに直線での伸びを示す。午後になって加速度が付いてきたのは、新しいOSのダウンロードがようやく出来るようになったからのようだ。

　ちなみに、まだ「友達・家族を招待」という機能を使っている人はほとんどいないので、これは純粋に「App Storeのオープン初日にアプリを出すことができたから」という効果のおかげ。バイラルマーケティングの効果はまだ働いていない。

　当初の「イニシャルのユーザーを集める」という目的は十分に達成しているので（「誰もいないレストランには入りづらい」というフェーズは一気に抜けることができた、ということ）、とりあえずはどこまでこの勢いを保てるかを見守るだけだ。

　ちなみに、ブルーのラインがiPhoneユーザーの数。グリーンのラインは、ウェブからのユーザーを含めたトータルだ。一目盛りの数は...企業秘密ということでご勘弁ねがいたい。

　MacBlogzにPhotoShare by Big Canvasという解説ビデオが公開されていることを発見。PhotoShareの基本機能を分かりやすく解説しており、そこに関しては僕らが作ったプロモーション・ビデオよりも良く出来ているかも。

　いずれにせよ、こういうものを作ってもらえるのはとても喜ばしい。やはり、オープン当日に間に合わせたことには意味があったのか、と。

　iPhone OS 2.0のリリースに先駆けて、App Storeがついにオープンした。待ちに待ったBig Canvas最初のアプリ、PhotoShareの世界に向けたリリースだ。PhotoShareはその名前の通り「写真共有アプリ」。iPhoneで撮影した写真を友達や家族と共有することにより、「経験の共有」をしようというコミュニケーション・ツールだ。

　PhotoShareの特徴はとにかく使いやすいこと。Flickr、Facebook、MySpace などの既存のSNS向けの専用iPhoneアプリがたくさん出てくることは当然予想できた（そして実際出て来た）。それにも関わらず、PhotoShareを独自のウェブ・サービスとあわせて開発をしたのは、「iPhoneに最適化されたおもてなし」を提供するため。ユーザー登録が不要なところ、すべての通信が非同期で行われること、友達や家族の招待がとても簡単なところなど、私がいままで学んで来たユーザー・インターフェイスやおもてなしに関する知識やノウハウを総動員し、クライアント側だけでなく、ウェブサービスAPIまでも最適化して作った自信作なので、ぜひともお試しいただきたい（iTunesストアのPhotoShareへのリンク）。

　対象ユーザーは、今まで写真を共有しようとすら思わなかったり、パソコンを通してアップロードするのが難しかったり面倒だと感じていた人たち。ブログやFlickrなどの通常のCGMのサービスでは、「作る側」に回る人は高々４％と言われるが、それを３０％とか５０％に引き上げることがPhotoShareの目標。だからこそ、リアルの世界で既に知っている家族や友人との写真の共有というシナリオを一番重視して作った。ディズニーランドで楽しむ孫の笑顔を離れたところにいるおじいちゃん・おばあちゃんがリアルタイムで楽しむ、そんな使い方をしてもらえるのが一番うれしい。

　ちなみに、今週になって作り始めたPhotoShareのプロモーションビデオもようやく完成したので、Youtubeにアップロードしておいた。ビデオの編集はすべて私。ナレーションは、MBAのクラスメートのAdam、編集ツールはiMovieという手作りのビデオなので、思いっきり素人っぽいのだがそこは大目にみていただきたい。

　４月に設立したばかりのBig Cavasのような小さな会社にとっては、新聞の記事に取り上げてもらう、というのが最も効果的なマーケティング。そのために色々と準備を進めて来たのだが、ようやくそれが功を奏してWall Street Journalに取り上げてもらえた。

One of the new wave of iPhone start-ups is Big Canvas Inc. of Bellevue, Wash., a firm creating a social-networking application for the iPhone that uses photos. Satoshi Nakajima, CEO of Big Canvas, said the development tools Apple offers for the iPhone, which are derived from technology underpinning Apple's time-tested Macintosh operating system, are the best he has seen for mobile software developers.

Mr. Nakajima, a former longtime Microsoft software engineer, also praised the App Store, Apple's channel for distributing software to iPhone users, which he believes will give greater visibility to unknown software developers than has been the case with other mobile phones.【IPhone Calls On Software Developersより引用】

　正確には私はCEOではなくてpresidentなんだが、その小さな間違いを除けば、Big Canvasのような会社にとっては、こんな記事は願ってもなかなか書いてもらえない完璧なマーケティング。

　実は、この記者（Nick）が１ヶ月ほど前にビルゲイツの引退に関する特集記事を書いている時に、私が関わっていたNetdocsというプロジェクトに関して調べものをしていて私にたどり着き、電話でのインタビューを申し込んで来たという背景がある。そこでNetdocsに関して色々と説明した後に、「ちなみに、僕はiPhone向けのアプリを作るためにBig Canvasっていう会社を設立したばかりなんだけど、今度iPhoneに関する記事を書く機会があったらコンタクトしてね」と頼んでおいたのだのだ。

　米国ではこれがBig Canvasという会社の旗揚げになるこのWSJの記事。App Storeのオープンともタイミングはピッタリだし、後はサーバーをしっかりと運営して、キチンとしたおもてなしを提供しつづけるだけだ。

　iPhoneアプリの開発もようやく終了し、後は一人でも多くの人が使ってくれることを祈るのみ。前にも述べたように、「直球ど真ん中」のSNSアプリなので、競争相手もたくさんいるといるはず。私なりにできるかぎりのおもてなしを提供しているつもりなのでそこでは誰にも負けないつもりだが、そもそも試してもらわなければ話にならない。

　そこで、Youtubeにアップロードするための宣伝用ビデオを作成中。それもエミュレーター上で動作するアプリをシェアウェアでQuicktimeムービーに変換したあと、iMovieで編集した上でナレーションを付けるという、ものすごく家内工業的なところがなんともベンチャー企業らしくて楽しい。

　しかし、今回のiPhone向けのapp storeのオープン。秘密保持契約があるためあまり表には出て来ないが、水面下はまるで西部開拓時代のゴールドラッシュを思わせる雰囲気ムンムン。オープンと同時に軽く千を超えるアプリが出てもおかしくない状況。私自身、この業界に入って３０年近くになるが、ここまで熱くなれたのは初めてかも知れない。

　週末の間、RC1(出荷候補No.1)をさまざまな環境でテストしてみたのだが、電波の弱いところではネットワークのスピードが極端に遅くなったり、とぎれとぎれになるため、妙に通信に時間がかかってしまい、通信を終了する前にiPhoneがスリープモードに入ってしまうという現象を発見。

　ちゃんとリトライの仕組みがあるので、データを失ったりはしないのだが、ユーザーから見ると、自分がした変更がリアルタイムに友達のiPhoneに反映されないというのはバグに等しい。

　出荷寸前にはしたくないたぐいの規模の変更をほどこす必要があるため、しばらく躊躇していたが、「やるしかないんじゃない」という妻の言葉に励まされて、思い切って変更。この変更をほどこしたものをRC2として再度テストをしなければならないのだが、仕方がない。

　しかし、今回のアプリは、開発期間（３ヶ月弱）、コードの規模感（一万行弱）ともに、ちょうど９５年の終わりごろから年明けにかけてIE3.0を作っていた時にとても良く似ている。唯一の違いは、私自身がプログラムマネージャ、UIデザイナー、テスター、リリースマネージャのすべてをこなさなければならないこと。いくらアジャイルな開発が好きとは言え、この規模のアプリ＋サービスを増井君と私のたった二人というのは少々厳しかったかも。

　特に「細かなところまでキチンと目を光らせて、着実に仕事をする」ことがあまり得意でない私には、リリースマネージャの役目は少々辛い。せっかくアプリは完成したのに、iTuneストアにアップロードするときのちょっとした手違いでストアオープン初日のリリースを逃したりしたら目も当てられないぞ、と。

　しかし、かといって人を増やし始めると、それなりのオーバーヘッドが増え始めて、「２人で３ヶ月」で出来たことがいつの間にか「８人で９ヶ月」とかになってしまうから不思議だ。このあたりがまさに「ソフトウェア・ビジネス」の難しさ。

　デザイナーからもアイコンが届き、なんとかRC1（リリース・キャンディデート＃１、つまり出荷版候補のNo.1）を達成。木曜日に追加したユーザーインターフェイスの改良が突然悪さをし始め、冷や汗ものだったが、なんとか原因を解明して解決。やはりあまり出荷寸前に機能追加をするもではないと少し反省。後は最終テストを経て出荷するばかりだ。

　二年以上前に自分で書いた「ユーザー参加型コンテンツビジネスのまとめ」を久しぶりに読み直しりしながらリリースに備える。あとはユーザーにちゃんと価値を認めてもらうことを祈るばかりだが、これだけはリリースしてみないと分からない。私なりに出来る限りシンプルに分かりやすく作ったつもりだが、だからといってすべてのユーザーが理解してくれるとは限らない。本来ならβ版をリリースしてユーザーからのフィードバックを受けながら作るべきなのだが、そうも行かなかったので、ある意味でこれがβ版。今の時代、「β版＝未完成なもの」ではなく「β版＝ユーザーの声を聞きながら常に改良するつもりのもの」と解釈するのが良いのか、と。

　ちなみに、「Microsoft Office」に代表されるリッチ・クライアントから、ブラウザーで閲覧可能なウェブ・アプリケーションへのシフトが急速に起こっている中で、このiPhone SDKはとても面白い存在だ。今回私と増井君が作っている「専用クライアントを持ったウェブ・サービス」は、単なるリッチ・クライアントでもなく、純粋なウェブ・アプリケーションでもない、車で言えばハイブリッドのようなウェブ・アプリケーションだが、それも本格的な非同期通信と卓越した開発環境があるからこそ可能になったもの。

　AdobeがAIRで狙っているのもまさにこのあたりだが、そのカテゴリーを先に開拓するのは実はiPhoneではないか、と感じている今日この頃である。

　間近に迫ったapp storeのオープンに向けて全力でラストスパート中。SNSとしての機能はかなり前から一通りそろっているのだが、いざリリースするとなると「こうした方が使いやすい」「ここはこうした方が見栄えが良い」と細かなことが気になってくるのでいつまでたっても終わる気がしない。

　そうは言ってもアップルは待ってくれないので、ここは踏ん張りどころ。最後の最後に追加することになったアイコンのデザインが外注先からまだ上がって来ないのが気がかりだが、独立記念日の休日を返上して働いてくれているデザイナーさんたちを信頼して待つしかない。

　プロジェクトの途中で色々と機能追加をしたために「当初の見積もりよりも高く請求させてほしい」と言い出したデザイン会社に対し、「請求書は当初の見積もり通りにして欲しい。そちらが要求している差額分は、満足できる仕事をこちらが要求する期間内にしてくれた時にボーナスとして払う」と交渉しておいたのでそれほど不安はない。

　しかし、今回のiPhoneアプリだが、私の得意な非同期通信を思いっきり駆使しているので、そこは期待していただきたい。ユーザーを待たせないための工夫だけでなく、電波状況が不安定な環境でも安心して自由に追加・変更・消去が出来るところがミソ。途中で電波が切れてしまったり、電話がかかってきてアプリが強制終了されてしまうような環境でも、ユーザーの入力したデータは決して失わない。それがBig Canvasのおもてなし。

　などと色々と言ったところで、結局のところは技術のことに興味なんか全くない普通のユーザーに喜んで使ってもらわなければただの床屋の満足なので、そこが難しい。あと一踏ん張り、妥協せずに頑張るぞ、と。

　毎日のように「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アプリの提出期限まであと約二週間。ブログなんて書いてる時間はないぞ、と。