アップルの経営手法を元幹部からの聞き込みを元に分析したインサイド・アップルを読んだ。

社員を特定の仕事に集中させる方式とか、いかに社内政治の発生を抑えるかなど、アップル独特のやり方を細かく分析していて最高に面白い。

でも、自分としてはリーンスタートアップと、アップルの製品開発のプロセスについていろいろ考えたりしてきたので、その部分に絞って書きたい。

主に、”顧客インタビューしない部分”と、”製品を秘密にする”という２つについて。

なぜ顧客インタビューしなくてもいいのか

ちなみにリーンスタートアップは、時間とコストをかけて顧客が望まないムダな製品を作らないようにする手法です。製品を開発する前からターゲット顧客にインタビューする。そして、自分が作ろうとするものに価値を見出す人がいるかの見込みを確認しながら小さく製品を作っていく。

この開発手法を去年の夏頃に勉強し始めた時は、これはいいやり方だなと感銘を受けたのたものであります。実際にいろいろと試して取り入れている部分が多いにあるし。

しかし、アップルは「顧客調査をやるとつまらないものが出来うんだよ！」といって調査を一切やらない。

「人々に欲しいものを聞いていたら速く走る馬を作ってたね」と、フォードが言ったか言ってないか分からない言葉がこの理屈を語る時によく引用される。アップルの開発プロセスは、リーンスタートアップの話を聞いた人が最初に思い浮かべる反証な訳です。

もちろん、UXとかリーンスタートアップを専門とするジャニスさんやらエリックさんやらは、「アップルだって社内で小さく試作品を試しているはずだ。」とか、「顧客に欲しいものを聞くのは間違いで、観察して顧客が欲しがるものを起業家はイメージするのが大切だ」と言っている。

正直、リーンスタートアップを世界中に広めている最中のエリック・リースは、「ウゼエな、アップルの話はすんなよ。」とでも思っていないだろうか。

しかし、リーンスタートアップの定番である「製品を作る前にターゲット顧客となりそうな人、10人以上はインタビューする」という事をアップルはしない。もちろんプロトタイプを作って改善していくというのは、社内で特別な扱いを受けているデザインチームがやっているけれど。

なんで試作品を作る前に顧客ニーズを確認しないでiphoneやらiPadが出来たかというと、ジョブズが欲しいものを作るという判断基準があったからだと思ってた。本を読むとまさにその通りの事が書いてる。

しかも、社内政治に気を散らされないで自分の業務に集中できるように、他の部署が何をやっているかはお互いにまったくわからないらしい。となると、Googleみたいにまず社内の人間が試作品を使って、社内規模で可能な限りフィードバックもらう事もしにくい。これはちょっと驚きだった。

ジョブズ指揮下のプロダクトは、ジョブズが気にいるかどうかが重要事項で、細部まで文句をつけられる。ちなみに、37signalsやEvernoteの社長も、自分が欲しいものを作るのが一番簡単なプロダクトの作り方だと言っている。

この”本人が本当に欲しいもの”というのがとても重要で、「俺もあったら欲しいと思うし、みんなも欲しがるだろう」っていう中途半端な欲求だと、なんかズレたものができるのだと思う。具体的には、代替手段もちゃんと試していて、既存製品のどこが問題かをはっきりと認識して、不満を持っているぐらいじゃないときつい。

まあ、普通自分が欲しい物基準で作るとBtoCになって、ビジネスモデルが難しく、あまり儲からないってのがつらいとこですが。そういう意味で、BtoB向け製品で、その分野の深い知識と問題点を理解してる人は有利だと思う。

ぶっちゃけ、自分が本当に深刻に思っている問題を解決する製品を作ろうとしているのなら、最初のインタビューはすっ飛ばしてもよいはずだ。RunningLeanでもそう書いてる。

下手にいろんな意見を聞いて、自分があまり欲しくはないなと思う機能を付け足してごちゃごちゃするよりも、最初は自分が本当に必要な最低限の機能のみ作るのがいい。Lisgoも最初は大多数の人が使えそうなUIを作って失敗してた。

アップルではジョブズがいろんな機能のアイデアにNOを言いまくって、製品がシンプルになっていくらしい。

ただ、自分が欲しいものを作っていて、ユーザの問題も、問題が解決したかも判断できるからといって、ユーザの意見を聞かないでもOKよってわけではないとは思う。

このへんアップルがどうだかわからないけど、僕の場合はユーザの要望やら意見を聞いてるだけで、「こういう視点があったか」とか、「この機能に気づかないのか」とか、「やっぱり自分と同じ考えの人がいたのね」と、素晴らしくタメになる。

ただ、最終的にどういう形に落とし込むかといった最終判断は、ワガママに自分が使うかどうかで決めている。自分が直接必要じゃなくても、明らかに大多数の人が必要だろうと思う機能のみつけたり。LisgoだったらBluetooth対応とか。

そういえば、Instapaperの作者もPodcastで言ってたけど、そういう作り方をしてるらしい。よいと思った新機能も、しばらく自分が使ってみて、使わないなと思ったら切り捨てるらしい。

製品が完成するまで秘密にする理由

アップルが市場調査をしないのは知っていたけど、製品が完成するまで秘密にする理由が面白かった。

まあ、考えても見て欲しいのです。リーンスタートアップの教えに従うと、出来る限り最初からユーザと対話して、どういう製品を作るかを顧客と接しながら改善を繰り返す。

となると、製品の詳細についてはオープンにならざるをえない。だって、顧客インタビューしたり、顧客にこちら側が考えた問題の解決手段がいいと思うか反応を聞いたりするわけだから。下手したら、製品出来上がる前にお金をもらう約束までする。

誰もお金を払いたがらない無駄な製品を作るリスクを減らすんだ！というのがリーンのテーマであり、「なるほど、こりゃいいね！」と僕も思っていたのですが、アップルはすごい秘密主義で正反対なんですよ。

なんでも、製品が秘密のベールに包まれていたほうが人々の期待が高まってよいと。まあ、これは分かる。でも、僕みたいな元々だれも注目してない状態なら関係ない事だ。

それより重要だったのは、「製品が出来る前に作るものを発表すると、ユーザの期待が勝手に高まり、それを上回るのが難しくなる。それよりも、素晴らしい物が出来てから一気に発表したほうがユーザに驚きと喜びを持って迎えられる。」という部分。

むむ。。これを今までの自分の製品開発プロセスに当てはめてみると、「こんな機能もつける。これにも対応する予定だ。ああ、その機能も付ける予定だよ。待っててね。」みたいな感じで話してた気がするぞ。やってしまったーーー。

そもそも、予定通りにスケジュールが進むわけないから、ユーザの期待値を無駄にあげてしまう愚かな行為だったかもしれない。ユーザの意見を聞く努力はサボらないようにするけど、要望があっても簡単に約束しない事にしよう。

このへんは、37Signalsのブログでも言ってた。「ユーザに約束するな」と。

ユーザから明らかに構想予定の機能を要求された時も、「ああ、その機能ね、もちろん付けるよ。すぐだよ！」みたいな返事は頭の中だけに閉まっておく。

「なるほど、検討しときますね。」といった感じに常に冷静に返事しつつ、機能が出来てから「ついにできました！」といきなり発表というツンデレ方式でいこうと思います。

というわけで、Lisgoの日本語対応は未定という事でお願いいたします。

参考図書 *アップルインサイド

Y-Combinatorが最新のDemo-Dayをやっているらしい。Techcrunchによると、39チームのうち15チームがモバイルアプリで、主流がどんどんモバイルファーストになってるみたいだ。

今回は初の日本人チームもいたりと、ピッチ見るだけでも勉強になると思うのだけど、僕が興味あるのはピッチよりiPhoneアプリを作っているチームのランディングページである。

Y-Combinatorといえば、スタートアップのノウハウが結集しているので、そこを卒業しようとしていて、iPhoneアプリを作っているチームがどんなふうにランディングページを作っているかは参考になるに違いない。

PathとかFlipboardみたいなお手本のような紹介ページも参考にはなるのだけど、あちらは潤沢な資金を使ってゴリゴリとイケてる動画を作れるからなかなか真似できない。

それよりも、お金も時間もないながら、ノウハウは最新のものを吸収して作っているチームのランディングページや、AppStoreページのほうが参考になるのですよ。

この記事にモバイルチームのリストが乗っている。このリンクリストが貴重なのだ。

ページに来たユーザとLivechatできるoLarkをつけてるチームが多い。

Lisgoのページでも付けてるけど、たまにチャットしてくる人がいて、その人達が競合アプリとか、代替手段として使っている方法とか教えてくれてすごくいいのでスゴイお勧め！設置も泣き出すぐらい簡単。

僕はiPhoneアプリ作ってるので参考になるのはPairのチームでしょうか。これはPathみたいにトップページにアプリの動作をフラッシュで見せている。やっぱこれが一番わかりやすいなあ。

動画はない。イケてる動画を作るのはコストがかかるから、ここらへんは難しい。しょぼい動画作ってもブランディング的にマイナスなるし。

ちなみに、Lisgoのページは僕のつたない英語で、アプリの動きを説明するという無謀な事をしている。でも、これはこれでいいんですよ。別に今の段階でたくさん人が来るわけでもないし、評判なんて気にしなくても無問題なので、とにかくパパッと作れるのを優先しているから！

というか、アップデートに忙しくて、紹介動画もページの写真もすごい古いバージョンであった。まあ、今の段階では適当でいいや。

ちなみに、Pairのランディングサイトのダウンロードアイコンをクリックしたら、そのままApp Storeのリンクに飛ぶ。Pathみたいに電話番号を入力するボックスが出てきて、携帯にダウンロードリンク飛ばす方法もあるけど、あれがベストなのかな。

PairのApp Storeの説明文は改行もなくて、最初の文が長いのでこれはよろしくないと思う。でも、スクリーンショットはシンプルに写真と文字を使ってていいと思う。Clearもこんな感じだった。Lisgoはスクリーンショットに文字詰め込みすぎてるから変えようか。

最近ようやく感覚として分かってきたけど、ほとんどのユーザはアプリを落とすまでにWebページなんか見てない。ここまで書いておいてなんだけど。

SNSかニュースサイトでアプリを知って、iPhone開いてAppStoreで検索して紹介分の最初の2行ぐらい読んで、その後スクリーンショットをちら見して、レビューをささっと見てダウンロードするか決めているのが大半だと思う。

なので、ほとんどのiPhoneアプリにとって時間を書けるべきなのは、ランディングページよりAppStoreの紹介文と、特にスクリーンショットだと思うんですよね。

できれば紹介文の最初の3行ぐらいを、短く簡潔に、一行か二行ぐらいの文章をスペース空けて書くのがよいと思う。

ランディングページ参考になるよという記事だったはずなのに、なぜか最後にランディングページなんかほとんど見られないだろうというオチになってしまった。

まあ、パソコンよりスマートフォンばっかり使う人がどんどん増えていくので、自然な流れと言えば当たり前かもしれない。Webのランディングページなんてモバイルで見ても小さくなって見づらいし。

そういう意味で、AppGroovesの方がやってるモバイルアプリの効果的なSEOってどんどん重要になるはずなんですよね。あのサービスはやろうと思ってたのに忘れてた。早めにやってツイッターかサイトで報告したい。

*Update
appSEO今使ってみたけど、これはヤバい！iPhoneアプリ作っている人みんなやったほうがいいと思う。登録も簡単だし、こうやってキーワードを入れるのかとか凄く勉強なる。

僕は「SEOなんかどうでもいいからいいプロダクトを作ればいいんだよ」っていう青臭い事を言うタイプなのですが、「こんなに簡単にSEOが向上するならやらないと損だよチミ」というようにこれからなると思う。

しかし、appSEOのランディングページも勉強なる。リンククリックしたら画面変わらずにスクロールしたり、紹介動画リンククリックしたらするっと下に出てきたり。

「グーグル　ネット覇者の真実」が面白い。中国で挫折した部分とか詳しくて最高なんだけど、スタートアップというのをブログ名にしてるのもあり、初期の頃にどのようにやってたかに注目して感想を書いてみます。

なんか初期の頃は、創業者の二人とも最初は自分の論文のためにGoogle作って、いい感じに研究結果書けたらいいなっていう雰囲気なんですよ。周りの友達が、「これはスゲエ、お前起業しとけよ！」とか薦めるんだけど、最初は乗り気じゃない二人。

まあ、スタンフォードの研究員という身分も結構満足できるものだし、アカデミアの道を志していたのもあるのであろう。

だからもあって、二人ともGoogleをヤフーとか周りのいろんな会社に売ろうとするんだけど、「みんなはした金だなあ、もっと高い値段で買ってくれよ」みたいな感じでいい買収が成功せずにトボトボと家路につく毎日。

とても面白いのが、最初らへんはGoogle創業者の二人は全然ThinkgBigじゃないのに段々とビッグマウスになっていくところ。途中からアクセス数が増えてくると、「おいおい、これは可能性あるんじゃないの、ちょっと起業しちゃいますか。世界変えちゃうぞ」みたいな感じで発言も調子に乗ってくる。

その後、どんどんGoogleが人気になってくると、ブリンとかは採用面接でいかにGoogleが世界を変えるかという壮大な構想を語りだす。うーむ、最初は適当な会社に売却して博士論文の執筆に戻ろうしていたのに。。

ほどなく、有名なベンチャーキャピタルに出資をしてもらうプレゼンで、ペイジが「将来は100億ドルの会社にするぜ。100億とは売り上げじゃなくて、利益のことだぞ。フハハ。」と盛り上がり始める。売り上げないけどアクセス数はうなぎ上りで自信ついてきたんだと思う。

そして、その頃に出資した側のVCの人が当時を振り返って、「笑っちゃうほど壮大な野望なんだけど、奴は大真面目の未来を計算尽くして、本当にそれを信じてたんだよ。。」みたいな感じで、初期の伝説が出来上がっていく。

そういや、ザッカーバーグもFacebookの初期の頃のインタビューがちょっと前に話題になってたけど、「いやあ、みんあ世界を変えるとか吹いてますけどね、僕はまず小さな大学という単位で価値あるものを作りたいのよね。別に世界変えるとかみんな気にし過ぎっすよね。。」という非常に謙虚な動画がアップされてた。

しかし、有名なエンジェル投資家であるロン・コンウェイが、スタートアップスクールでザッカーバーグと出会った頃の話を語っていたのはこんな感じだった。「彼は最初の頃から、凄く鮮明にソーシャルの行く末をイメージし、これから実現していく未来のビジョンが確固たるものとして自分の言葉で語ってたんだよ。。（スゲエよ奴は。。）」

ビルゲイツも自分用にゲームかなんかのプログラミング作ろうとしてただけだし、ジョブズも最初は企業にPC売って小銭稼げれば満足って感じだった。ジョブズでさえ、「もっとビッグに考えないといかんよチミ！」と初期の年上のメンターみたいな人に言われてるし。

最新のポールグレアムのエッセイでも、”壮大すぎるアイデア”みたいなタイトルで恐れを知らないビッグアイデアの数々を書いてるんだけど、引っ張っておいてオチが凄かった。

「でも、こんな感じで煽って書いてるけど、どう始めるかのベスト戦略は自分のために小さなアプリを作ることだよ。自分の小さな問題を解決すれ事から始めて、最初から壮大なビジョンを語って周りに過度な期待を持たせたり、敵を作ることはないぞよ。」といった感じで閉めてた。

「大きく考えても、小さく考えても費やす労力は変わらないから、どうせならでっかい事したほうがいいよ」というカッコいい事をVCの誰かが言ってたけど、歴史をひも解くと最初はみんなThinkSmallだったようだ。サービスに勢いが出てきて自信がついてきた後、VCや従業員の前でThinkBigになっていくというのが定番なのかも。

ユーザからのフィードバックをいかに全方位でくみ取るか、そのために便利なサービスの数々を書いてみる。今回はよてもよいエントリになりそうな予感がするので、アクセス数増えないかと無駄にタイトルにスタートアップとつけてみた。

ユーザの要求する意見を全部聞いてると、ウンコみたいなプロダクトができてしまいますが、自分の気づかなかった部分を知るためにもユーザの声を可能な限り聞くのは非常に重要であります。

リーンスタートアップでも顧客の声を聞けとある。「ずっと顧客の声を聞くためにビルから出ているわけにはいかないよね、そういう時は可能な限りユーザから自分にフィードバックを届けやすいチャネルを作るのが大事なんすよ」とRunning Leanのアッシュさんも言っております。

ゼロベースの石橋さんも、「ユーザは熱心なファンからライトなファンまで幅広くいるので、それぞれの層の人達がストレスなくフィードバックをおくれる仕組み作りが大切」とこの前の相談室で教えてくれたのですが、本当にその通りだと思う。

そこで、現在進行型で僕がいろいろ試したり、他のスタートアップのやっている事を研究しているので、それを共有しようと思います。

基本はやっぱりメールアドレス

当たり前すぎて怒られそうなんですが、メールアドレスをサイトの分かりやすいところに書く。いっぱいメール来たら返信するの大変だしどうしよーと思っちゃいますが、普通はほとんどメールこないので大丈夫。誰も自分のサービスなんか気にかけてません。だからこそ、たまにわざわざメールくれる人は重要！

Lisgoも初期からの熱心なファンは直接メールでフィードバックがくれる場合が多い。

もし１人とかでやってて、全部に返信できないようになった時は、ちゃんと全部読んでるけど、全員に返信できないのは許してねとか後から書き足せばOK。Instapaperとかこのパターン。

Twitter

メールを送るより気軽なツイッター。ユーザが気軽にフィードバックをくれるようになるには、やっぱりその人がフォローしてくれないと可能性が低い。なので、ターゲットユーザが興味のあるような事を公式アカウントや個人アカウントでつぶやくのがベスト。

でも、実際はそんな時間がなかなかないので、まあ単純に個人アカウントが一番てっとりばやいのですね。このへん、話題のアプリClearとかは凄く上手くて、開発チームの面々をフォローするたびにアプリ内の色の新しいテーマが増えたりする。

Lisgoもツイッター経由で軽くフィードバックがくる事がよくある。とにかくメールより気軽にこれるから、ここがユーザとのメインのつながり拠点になってるスタートアップは最近多い。

電話番号

RunningLeanに電話番号書けって書いてたから、僕もわざわざ050Plusに契約して電話番号をサイトとかに載せてたけど、未だにかかってきたことはない。おそらく、Lisgoは海外のユーザがメインなので、日本までかけようと思わなかったり、そもそも電話なんて敷居が高すぎるのだろう。

でも、自分のサービスのターゲットユーザによってはとても有効だったり。取れない時は、留守番電話にして、メッセージくれたら書け直すか、メールにお願いとかのメッセージが流れるのがよくあるパターン。

電話で素晴らしいのは、実際にどういう所でユーザがつまづくか、どういう問題を抱えているか、そういうわざわざ自分がターゲットユーザを探してインタビューしにいかないといけないところを、あっちからわざわざかけてくれているのだ。

メールとかでは伝わりにくい細かいニュアンスとかもわかる。凄くユーザに聞いてみたい質問とかがあれば、相手の話を聞き終わった後に、一つだけ質問してもいいですかという感じで聞けばいい。（とはいっても、僕は実際にかかってきた事ないけど）

「パソコンで文字打つのもめんどくさいけど、電話で聞くなら楽だからかけてみっか」というユーザに最適なチャネル。「リーンスタートアップ勉強したからビルから出るぞ！」という意気込みのスタートアップの人達からすると、あっちからかけてくれるなんて最高だと思う。

公式サイトにライブチャットのoLark

初期のスタートアップはみんな設置するべきとHackerNewsでも話題のolark。サイト上に簡単にLivechat機能を設置できる。

YCombinator出身のスタートアップなんだけど、本当に設置も簡単で使いやすい。MacのiChatと自動連携してくれて、自分がオンラインの時は自動でライブチャットOK状態になって、オフラインの時は「今、オフラインだから代わりにメールしてね」に切り替わる。

フリーミアムモデルなので、それほど頻繁にチャットがこない段階では無料で使える。Lisgoの場合もたまにチャットがくる。でも、「音声エンジンは何使ってるの？」とか、アプリに興味を持った開発者の人が多いんだけどw　（でも、その人達もいろいろと話の流れでためになることを教えてくれる）

「メールの返信なんて待ってられん、今すぐ返答が欲しいんだよ！」というせっかちなユーザにぴったりです。

iPhoneアプリ内に匿名ご意見ボックス

iPhoneアプリだとここが最も重要だと思う。クックパッドの匿名ご意見ボックスみたいなもの。以前はメールでフィードバックを送りやすくするボタンを設置していたけど、匿名のほうが絶対にハードルは低いから意見を送りやすいはず。

クックパッドアプリとか、最近出たSnackrとかも実装してる。

メールを送るボタンは簡単に実装できるけど、匿名の意見ボックスはtestflightのフィードバック機能を使うのが一番簡単だと思う。これは、実はアップストアでリリースしたアプリからでも、普通にtestflightの自分のアカウントにメールが届く。（testflightはアップストアでの利用はノンサポートだよ言ってるが、この前普通に動いてたから今でもいけるはず。）

実はちょっと前まで、レイアウトがカスタマイズできなかった。最近のアップデートで出来るようになったので、先日、1時間ぐらいでちゃちゃっといろいろな機能をつけたカスタムビューコントローラーを作った！絶対便利だと思うので、使ってみてください！ (Githubへのあげ方を勉強しようと思ったら、エラーが出てめんどさくなってzipでアップ）

ちなみに、アップストアへのReviewボタンをつけるのも有効。人によっては、ストアに直接Reviewを書くのが一番慣れてたりするからだ。

無料アプリでありがちな、ほとんど使ってないユーザがネガティブなコメントをつけられるのが怖いので、一定時間使ってくれてる人だけをフィルタリングしてポップアップでレビューを促すライブラリもある。

ただ、これは無視される可能性がまあ高いし、ネガティブレビューでもなんでもいいから、将来的にサービスをよくするために意見をいっぱいくみ取りたい！っていう人なら、分かりやすいところにレビューボタンがよいと思われます。（ポップアップも同時に組み合わせたり）

サポート掲示板をDesk.comで設置

Instagramなど、いろんなスタートアップが使ってて業界スタンダードとなってるようなDesk.com（AssistlyがSalesforceに買収された）。これは、FacebookとかTwitterとかメールとか、サポート掲示板とか、すべてのサポートをひとつのWebサービスで統合して管理できる優れもの。

フリーミアムなので、最初の１人は無料で使える！実はさっき使い始めたばかりなんだけどヤバい！設置もめちゃくちゃ簡単で、Twitterでは特定のキーワードを自動サーチに登録できたりする。こいつはやべえ。使い始めたばかりだけど、本当に十分すぎる機能が無料で使える。

これで、サイト内に掲示板のコミュニティを作って、機能提案とか、サポートのフォーラムを作る。メールするのめんどくさいし、Livechatもだるいなあっていう心理状況のユーザが、フォーラム型なら参加してくれるかもしれない。

余談ですが、Assitly時代、sixteenventures.comのインタビューでなんでフリーミアムに転向したか、その背景をいろいろ話してて素晴らしくSaaSビジネスの勉強になった。インタビュアが「ユーザを増やしてバイアウト狙いでフリーミアムに移行したの？」って直球の質問から始まるのだが、Assitly側の人は「いやいや、買収なんて考えもしてないよ」って返事してたけど普通にその後すぐにSalesforceに買収されていたw

ユーザとしてはよいサービスがフリーミアムで提供され続けられるので、ハッピーなパターンだったんですが、フリーミアムの裏も表も知っているsixteenventuresのリンコーンさん恐るべし。

GetSatisfactionなどのVote型フォーム

GetSatisfactionやUservoiceなどが有名。これは、oLarkと似ているけど、要望がVote型で投票できるフォーラムになっているのが特徴。自分も最初はこっち形式にしようかと思ってたんだけど、Vote型だと少数意見のユーザが声をあげにくいという心理状況になるという意見もあり、oLarkを先に設置した。

でも、LiveChatよりフォーラムに投稿型のほうが気楽だというユーザをカバーするために、今はDesk.comでフォーラムを設置しようと思ってる。まあ、今のところは自分は使う予定はないかもしれない。

まとめると、初期段階では、フィードバックくれるほどユーザがいないと思うので、とにかく全方位でチャネルを用意しておくとよいと思う。Facebookのコミュニティもまぜるといい感じだと思うけど、自分はあまりよく知らないので書かなかった。

自分の問題を解決するべく作ったサービスで、どこが改善点なのかよく理解しているつもりでも、ユーザの声は本当にためになる。自分の盲点だった部分を補強してくれたり、自分の考えが間違ってなかったと確信できたり、単純に応援してくれたり、いろいろとお得間満載です。

ご意見、ご感想、こういうのがあるよ！と教えてくれる親切な方は@umekun123まで。

先日、@zerobaseの石橋さんのご好意で、Web開発相談室に出演させて頂いた。素晴らしい夜でありました。無料動画と音声がアップされたので、死ぬほどお勧めです。凄く濃くて勉強になった。

Youtube動画はこちらから。通勤時間に聞けるPodcast版もあるよ。
(iPhoneのiTunesでzerobaseと検索すると楽に落とせるかも）

主なテーマはUIデザインとユーザフィードバックでした。特に、よいUIデザインをどう開発していくか。石橋さんは具体例を織り交ぜながら、最も重要な軸となる考え方も忘れないように話しくれるので、凄く分かりやすい。

なんというか、具体的な実践方法と、忘れてはいけない基本概念を抽象化しての説明を織り交ぜてくれる。本当にヤバい。こんなに濃密に深く学べる機会はなかなかない。

ちなみに、リーンスタートアップ的には最初に欲しい人がいるかを確認するのが重要なのですが、今回の話はどちらかと言えば、その後にどう製品をデザインしていくかといった話です。リーンスタートアップに興味ある人は、フィードバックループ構成したい時の、現実問題的なユーザの微妙な心理を話している後半の部分が必見だと思う。

ちなみに、ラリーキングっぽく肘をついて真剣に話を聞くというスタイルを意識したのだが、動画を見ると自分は相談側なのに非常に偉そうに写っている。すんません！

一応、僕が作っているLisgoを開発していく上での悩みを元に相談してるのだけど、サービス開発してる人なら誰でも役に立つ話ばかりだと思う。

Lisgoは自分が毎日使うユーザなので、どこが使いづらいか、どこに改善点があるかはかなり理解しやすい。でも、開発者だから機能の使い方が分かりやすいかどうかは分からない領域。自分は最初から使い方を知ってるからである。

つまり、周りの人に使ってもらって、横から観察するというユーザビリティテストが効果的になるけど、これも手軽に何回もできるわけじゃない。そういう、開発時間も必要なうえで、ユーザビリティもいかに洗練させるか。特に、いかに自分が気づかない部分に気づくか。

僕も頑張って本を読んで勉強したり実践で試行錯誤しているのだけど、実際には時間やコストのトレードオフがあり、なかなか教科書通りの事は全部できない。常に何を選択するかの日々がある。

石橋さんは、それも十分に踏まえて経験則から原理原則の応用の仕方を説明してくれるので、凄く負におちるというかなんというか。

詳しくは動画で見ると分かるのだけど、印象に残った部分を書いていきます。ちなみに、動画の最初は3分はLisgoの簡単な説明なのでスキップしても無問題。

ユーザビリティ・デザインの原理原則をインストールする (7分〜)

ユーザビリティ・テストはためになるが、そればかりやる時間もない。どう効率的に開発とのバランスを取るかというのが僕の相談だったのですが、結局はUIデザインの経験則としての知見を頭に入れるのが一番の近道と。

これだけ聞いたら当たり前じゃないかとみなさん思うかもしれないのですが、石橋さんが様々なよいUIデザインを作る具体例をぽんぽんと出してくれるので、「むむ。。こういう経験則をここまで深く知ったうえで他のUIを参考にしたり、自分のデザインを考えるのでは深みが違う。。」と圧倒される我輩が動画で観察できます。

もちろん原理原則を破る事も重要なのだけど、その場合も、自分のプロダクトはこういう理由でルールを破っているのでOKなんだ、という考えを持てるのと持てないのでは大きく違う。

そして、僕もアップルの純正アプリであるiPodやら、TweetBotやら、評判のよいUIデザインをいろいろ細かく参考にして勉強するのだけど、UIデザインの知見を知っているのと知らないのでは見える世界が違う。

ここで石橋さんは、「Defensive Design for the Web」など色々な本を紹介してくれた。アプリ開発でも原理は同じなのでもっと読まねばならぬ。ちなみにiPhoneだと「iPhneアプリ設計の極意」が凄くいい。ここでも、ルールとルールを破る時の解説がされていたのを思い出した。忘れるから何度も読もうと思った。

特に動画の該当部分を見ると重要な原則を例と一緒にいろいろレクチャーしてくれているので、とても濃密に学べると思う。

製品の問題をユーザは伝えられないから、観察が有効になる (32分〜）

上で書いたように、デザインの原理原則を頭に入れておくと、ユーザビリティテストするまでもない基本の事柄は先に潰しておける。ユーザビリティ・テストにもコストがかかるので。

でも、ルールを破るべきかどうか、ルール通りにしたものが果たしてよい結果に繋がるかはユーザを観察するしかない。いくら経験則を持っていても、自分の頭の中だけで考えると重いもよらない落とし穴に確実に落ちてしまう。

ユーザを観察するのがなぜ重要なのかという事を深い意味で語ってもらえたのだけど、自分にとって新鮮だったのは、「ユーザにどこが不便かを聞いても上手く伝えられる人は少ない」という部分。

「ユーザに欲しいものを聞いてもダメ」という事は分かっていたのだけど、「ユーザにどこが不便かを聞いても答えるのは難しい」についてはそこまで意識してなかった。

普段使っている様々な製品の使いにくい部分を的確に文句が言えるのは、結構訓練された人しかできない。なので、「どこが不便ですか？」は「どこが問題ですか？」よりましだし、「どうすればいいですか？」より遥かにましなんだけど、不便な部分を的確に教えてくれる人は少数派。これは肝に命じる事にしようと思う。

実際は不便なのに、使うのに慣れてくるとユーザは当たり前のように感じてきてしまい、本当の不便さに気づかなくなる。だからこそ、専門知識を持った人間の観察や意見が役に立つと言う事なのですね。

無意識にしていた反復に敏感になる（56分〜）

クライマックスに近づく部分で、衝撃の展開が訪れます。

自分がユーザで、自分が使いにくい部分をコツコツと修正していく作り方でLisgoは作っている。具体的な話になるけど、日本語と英語の記事をどちらも読むので、たびたびフォントの大きさを切り替えてたわけです。

それを切り替えるEditバーを手軽に出す機能をつけていたけど、この機能は大半のユーザにとっては優先度低いのではないかと思い、消すかどうか悩んでいると相談した時です。

すると、「フォントの切り替えは単純に自動化できるんじゃないの？」という単純な石橋さんのアンサー！

気づくと当たり前の事だったのですが、なぜか自分はまったく気づかなかったのです。なんと恥ずかしい。僕は、頻繁にフォントを切り替えるから、素早くフォントを切り替えられる便利な機能だぜ、オラオラこんなに早く切り替えられると得意げになってたのです。

でも、それは単純動作の繰り返しであり、何度も反復する動作は自動化するのがユーザビリティの原則だと言われました。恥ずかしいけど、なんというアハ体験！

思い起こしてみれば、何度も繰り返すうちに素早く操作ができるようになり、ルーチンワークとなり、無意識のうちに不便さを感じなくなってしまう落とし穴はたくさんの製品であると思うのですよ。反復が体に身に付けばつくほど人間はそれを意識しなくなると思う。

ちなみに、石橋さんは日本語と英語の記事を自動判別する技術的な考察もしっかりフォローしてくれた。（そういえば、これは面倒かなと思っていたのだった。）

また、何％の割合でルーチンワークとなり、どの割合で例外動作が発生するかを考え、ユーザがよくする一連の動作を自動化するかどうか、その時に応じて判断するためのフレームワークもホワイトボードで説明してくれるので、ここは必見。

興奮を隠して出来るだけ静かに聞こうと決めていたのですが、このへんではドーパミンが爆発している僕が動画では鑑賞できます。

この他にも、「熱心な人からライトなユーザまで、様々なレイヤーのユーザから、いかにユーザの負担を少なくしつつ、フィードバックを頂くか？」という難しいテーマについて。(40分〜）

また、ユーザに機能のOn,Offを選択させて設定項目を増やすのは出来る限り避けたいが、例外をもうけるかどうか悩んだ時の判断の仕方（1時間8分〜)など、サービス開発してる人なら絶対面白い話がたくさんあります。

一応記事にまとめるにあたって、印象に残った部分を3つだけまとめてみたんだけど、聞き直してみるとどこを聞いてもすごく勉強になるところばっかりなので、全部聞くのが絶対お勧めです。

この動画/音声はいろんな人に見てもらって、自分はこう思うとか、こうしてるとかコメントなどで教えて頂けたら嬉しい。石橋さん、このたびは本当にありがとうございました。

Web開発相談室に出演希望の方は@zerobaseまで。

ユーザの声を聞きながらプロダクトを開発する時、2段階のフィードバックがあると最近思うようになった。一つ目はユーザにとって何が一番重要かどうかのフィードバックで、二つ目がユーザビリティのフィードバック。

この二つは重なる部分もあるのだけど、最近は頭の中でしっかり分けて考えるようになってきた。製品を作っていると、無数に実装したい機能があって、どれを優先するかは常にぐるぐる頭の中で回っていると思う。

そして、ユーザのフィードバックを聞いたり、観察したりしていると、ユーザごとに最適な優先順位が違うので一見混乱しがちであります。たくさんある選択肢の中で、どの機能の実装を優先させるかのタイミングを何度も自問自答していると、頭の中で整理されてきたのでその事について書いてみる。

始めに、ユーザにとって一番重要な部分はどこかのフィードバック。これが最も大切で、使う人にとって重要な問題を解決してないと、いくらユーザビリティを高めて、初心者がつまずかない体験を頑張って洗練させても使われない。

例えば、僕はスワヒリ語を習おうと思ってないので、素晴らしいユーザビリティと、最初の導入が神懸かり的に分かりやすいスワヒリ語学習アプリがあっても使わないはずだ。逆に、電車の乗換を調べたりする必要性はよくあるので、UIがしょぼい乗換案内でも必要だからよく使う。もっといい乗換案内ができたら速攻で落とすと思う。

というわけで、初期段階は一番最初から興味を持ってくれて、多少の細かい部分は目をつぶって使い続けてくれるユーザを探して、その人を優先して作るのが間違いないと思われる。

というのも、細かいユーザビリティを高めるのも、バグを潰すのも、ユーザを拡大させるための拡張機能やマーケティング、どれも時間がかかる。今使い続けてくれる人にとって何が重要な部分かを何度も考えまくって、優先順位を考えるのが大事だと自分に言い聞かせるように毎日お経を唱えています。自分が最初のペルソナなのでかなり有利だけど。

Lisgoの場合だと、iPodのような基本的操作性であったり、テキストのハイライトやオートスクロールだったり、オフライン機能。また、イライラするバグとか、こういうもの。

逆に、ユーザの層を拡大させようとすると、読み上げ音声の質、記事をどう取ってくるか、多言語に対応するとか。現時点で絶賛して使ってくれている少数の方々以外は、こういう部分がクリアされないと使わないだろう。

500StartupsのDaveが言うように、一般ユーザに広める質に達してない段階でバイラルマーケとか、拡大を狙うなというのは理にかなっている。「お前の製品はまだクソなんだから、クソなのに気にかけてくれるユーザに集中しろ。クソな段階で広めるな。」と、こんな事を言っていた気がする。

クソな段階で拡大を狙い、初期ユーザにどうでもいい機能つけて使いにくくなり、一時的な獲得できた新規ユーザも使ってすぐ離れられるという悲惨な事態だけは避けたい。もちろん、ずっと特定のユーザにこだわる必要はないのだけど。

またまた具体的にLisgoの例で話すと、だいたい4段階に分かれている。1段階目が最初のユーザにとって重要な基本機能。2段階目が記事の取得方法。3段階目が多言語対応。4段階目が能動的に記事なんて読まない層でも開いてすぐ使えるような初期体験とか。(FlipboardやPulseの最初のカテゴリみたいな）。

その先は高難度の根本的な音質向上やテキスト表現向上など。全体に関わって重要だけど、難度が高いから後回しにしているもの。ちなみに、Lisgoは第一段階がだいぶ進んできたので、もうすぐ第二段階に進めそう。グーグルリーダー対応かTwitterのお気に入りした記事リンクを取り込むようにする予定。

ちょっと前に気づいた事は、バグ修正でも優先度をつけたほうがいいという事だった。これは自分でも、バグ修正は優先度高いんだという錯覚に陥ってた。なぜならバグだから。

でも、37Signalsの記事で、取るに足らないものだけど修正がすぐにできないバグなら後回しにしてもよいと書いていて、知らず知らずのうちに陥っていた常識に気づいた。実は無意識に致命的じゃないバグは後回しにしてたけど、バグだから早く治さないとなという意識は常にあったからだ。

ここまで書いててすっかり忘れていたけど、2つ目のユーザビリティのフィードバックについて書きたい。これについては、自分の製品のドンピシャのターゲットの人が使うのを観察させてもらうのが理想ではある。でも、そこまで厳密に絞らなくても、ユーザビリティに関しては周りの人に普通にさわってもらうだけでも学べる事がいっぱいある。

自分の場合は、友達に自分のアプリを触ってみてもらい、出来る限り説明をしないで横から観察させてもらう。そうすると、どこで詰まるか、自分の予想した導線を最初に進んでいるか、それぞれの機能に気づいてくれるかなどがよくわかる。

ちょっと前までは初めて使ってもらう人を横から見れる絶好のチャンスがあっても、わざわざ操作方法を説明してしまってた。なんというもったいない事をしていたのだろうか。一度でも説明してしまうと、初めてのユーザがどこで詰まるかという貴重な情報が分かるチャンスを逃してしまう。アホだった。

あと、なかなか難しいけれど、出来る限りユーザが操作している時に何を考えているかを話してもらえると参考になる。外国人で開発者の友達にやってもらった時なんかは、あちらも理解があって詳しく話してもらいながら観察させてもらったので、自分でもびっくりするほどの発見があった。

やはり、フィードバックを得るというのは、自分の無知に気づくための過程だと思う。ダニエル・カーネマンも、人間は自分の無知な部分にたいして無知であると言ってるし。

さて、この時に気をつけているのは、ユーザビリティ向上のアップグレードも優先度を常に考えるということ。つまり、先ほど話したステップの段階で、自分の製品のステージがどの段階にいるかを考えて、初心者に優しい仕掛け作りに費やす時間を考えている。

製品がまだアーリーアダプター向けに基本機能を洗練させている段階なら、多少の説明不足の部分は目をつぶって、一番重要な部分に時間をかけたほうが合理的だ。もちろん、どんな人が使っても使いにくいユーザビリティは常に気をつけないといけないけど、最初のユーザー体験で絶対につまずかないような細かい手順の説明とかは後回しでいい。

つまり、携帯電話がまだ珍しかった時代だったとしたら、その時点で高齢者でも使えるような携帯電話を目指して、最初のユーザーエキスペリエンス向上に時間をかけるのは得策ではないということであります。

その時々のターゲットユーザによって最適なユーザビリティも変化するというのは、ゼロベースの石橋さんに去年説明してもらった。これは自分にとって凄く大きなアドバイスだった。それまでは、とにかく誰にでも分かりやすいのが正義だと盲目的に思ってたからだ。

プロダクトを作ってると、ユーザビリティと機能のトレードオフは常に考えないといけない。機能としては絶対あったほうが使いやすいけど、初めてのユーザには分かりにくいというような時、捨てるか残すかはその時のターゲットユーザの範囲で決めるしかない。

iPhoneのReederというアプリは、非常に競争率が高いRSSリーダアプリの中で一番人気だと思うけど、初心者への配慮はほとんどないに等しい。自分も最初戸惑った。もうちょい使い方が分かりやすくなる仕掛けを入れた方がいいのではないかとも思う。

でも、使い方さえわかればこれほどいいアプリはない。RSSリーダ使うようなITリレラシ高い人達には、Flipboardのような万人向けのものより、機能面で尖らせたアプリのほうが向いている。

簡単にまとめると、その人にとって重要な価値をもたらすかと、使いやすいかの二つのフィードバック。この二つを常に整理していると軸がぶれないのではないかと思いました。顧客開発とユーザビリティのフィードバックとも言い換えられるけど、知らず知らずのうちにごっちゃになりやすいと思う。

※参考リンク
Paul Buchheit at Startup School 08
Janice Fraser CEO LUXr Advice to future entrepreneurs

最近、趣味でiPhoneアプリやプログラミングを始めたいという人からお勧めの勉強法を聞かれる事が多くなってきた。そこで、挫折しがちなプログラミングの覚え方を考えた。どう最初の壁を乗り越えるかについて書いてみます。

ちなみに、僕は超文系で、数学も死ぬほど苦手である。プログラミングを始めたのは28歳すぎで、歴はちょうど２年。PHPから初めて、2011年の3月にiPhoneでObjectie-Cを勉強し始めた。主にネットと本の独学。

小さい頃からプログラミングに慣れ親しんでいるわけでも、理系だったりもないので、当初の「絶対、俺には無理だ、この呪文の羅列は向いてない！」という気持ちも覚えています。文系出身だったり、プログラミングは専門外すぎて無理だと思っている人向けにこの記事は参考になるかもしれない。

ちなみに、プログラミング始める前までの経緯とか、少なくともhtmlとかできたんですかとかもよく聞かれるけど、そういうのは気にしなくてよいのである。それより、楽しくなるかどうかが重要で、楽しくさえなれば、勉強という意識がなくなり持続する。持続さえすれば勝手に上達する。

楽しくなければ続かないし、楽しくない事を続けても人生楽しくない。だから、自分が欲しいものをいきなり最初に作るのがよい。他人を笑わせれそうとか、情熱が続けばなんでもいい。ちなみに最初に作ったものはどうせ途中で辞めるので、あまり長い期間の間に情熱が続くものとか、スタートアップ的には考える必要ないと思う。

よく、まずhtmlから勉強してみたらいいのかなという事も聞かれる。そういう一般的な手順はどうでもよいのである。自分が作りたいものを先に決めて、それに必要なものだけ逆算すればいいと思います。

なので、最初にどんな言語から始めればいいかとかは考えずに、作りたいもの、欲しいもの、情熱が続きそうなものを決めて、それに必要な言語を調べればいい。その頃には選択肢がある程度絞れているから、選ぶのも楽だし。

まず基礎から始めるかと考えて、データベースとか、なになにの基礎とか、猿でも分かるなんたらなんたらの本から始めるかとか、これとこれを読んだら分かるだろうと勉強チックな感じで進めると挫折確率が高まる。別に技術者試験のテストを受けるわけでもないし、CSの学位を取るわけでもないので、楽しく、挫折せず、継続させるの3点だけに集中するのがよい。

例えば、自分が欲しいものがモバイルアプリだったら、iPhoneとかAndroidアプリを作ればいい。Webサービスでもいいし、ゲームが作りたければゲームでもよいし。

自分の場合、本当に初めての時、実はプログラミングの入門書を買って、こつこつ毎日進めていた。死ぬほど退屈で苦行で、レッスン4ぐらいに進んだ頃にはレッスン2の内容は忘れていた。実践で書いてないから高速で内容が頭から消えて行く。いつ使うかも想像できないメソッドとかを順番に覚えるのもやる気がでなかった。

これで、2回ぐらい挫折しました。でも、めんどくさいから作りたいものを決めて、それに必要なものだけその都度調べるというやり方に変えると、一気に面白くなり今に至ります。確か、ポールグレアムのエッセイに、最初からいきなり作り始めろと書いてたのがきっかけだったような。

さて、情熱が続きそうなものは技術が難しすぎてできないよと反論がきそうだ。うーむ、確かに。これは難しい問題である。自分も小さな頃からどこでもドアが欲しいけど、技術的に難しそうで、いきなりどこでもドアを目指したら挫折確率は限りなく高まる。

ここでは、とにかく簡単そうで、なおかつ自分に役立つものか、あるいは笑えるものを作るのはどうでしょうか。サービスと考えるよりも、特定の用途に絞るといいかもしれない。とにかく、小さな分野にまで切り詰めると、そこまで難しくないものに収まると思う。ジョークアプリとかいいかも。簡単で、モチベーションが湧きそうだったらなんでもいい。

さて、だいたい絞れてきたら、それに必要な言語も現実的には複数まで絞られると思う。例えば、Webサービス系だったらPHP、Ruby,Pythonとか。どれを選ぶかに迷ったら、身近に教えてくれそうな人が得意な言語にすればいい。

ところがどっこい、そんな人は普通まわりにいないのが現実。もし周りに教えてくれる人がいたら、とても幸せだと思う。僕の場合、プログラマの知り合いは皆無だったので、入門書籍が豊富な言語という基準で選びました。

ちなみに、たまたまプログラマの知り合いがいたとして、その人にお勧めの言語を聞くとします。十中八九、その人は自分の好きな言語に誘導します。別に自分が作りたいものに必要な言語であれば丁度いいのですが、下手すれば、モバイルアプリ作りたいのにWebサービスしか作れない言語から始めるといいよというアドバイスをもらうかもしれない。注意。

例えば、僕がPHPやってた時に相談を受けた時は、「PHPでWebサービスするのが最初はいいよ、htmlもcssも基本だし。」と誘導尋問してました。最近はiOSアプリ作っているので、「今ならiPhoneアプリだよ。Xcodeが凄く使いやすいし、アンドロイドみたいにいろんな機種に対応しなくてよいから楽だよ。」とか誘導します。

僕の場合、なんで誘導するかというと、単純に知り合いが興味を持ってるならプログラム仲間を増やすチャンスだと目をぎらつかせからです。まあ、熱心に教えてくれる人がいて、Web系でも作りたいもののアイデアがあるとか、どっちでもよい場合は臨機応変に判断すればOK。

とりあえず、言語（技術）から選んで、そこを出発点にすると挫折確率が高まるので注意。

ようやく、自分のやる気が出て、なおかつ簡単な作るモノのアイデアと、言語も決まったとします。ここで、次にぶち当たる壁は、こういう動作をさせたいけど、そもそもなにを勉強すればいいか検討もつかないというジレンマです。

ここは難しい。ここは詳しい人が近くにいると凄く助かる。検索ワードを教えてくれるだけでも仏様のように感謝したくなる。でも、そんなラッキーな境遇にはいないのが現実。こんな時に、技術書を複数買っていると役に立つ。

慣れてくるとネットで検索したほうが早いけど、初期段階では網羅的に方法論を書いている入門者はもの凄い力を発揮します。技術書は高いけど、似たような内容のものを何冊も買うと挫折確率が低くなる。もしお金がなくて、都内に住んでたら大型書店で立ち読みでもいい。

ここのポイントは、自分がこういう動作をさせたいという目的があるので、それについて書いている箇所を数冊の本から探し当てるのです。数冊買っても全部読む必要はなくて、必要な時に串刺し検索みたいにピンポイントで解説してるかを探し当てる。辞書的に使う。

さらに、同じ技術の解説でも、最初はいろいろな角度から解説してくれると一冊目で理解できなくても、三冊目ぐらいで分かる可能性が高いので数冊あると挫折確率がまた低くなる。せっかく実装させたい動作がはっきりして、学習意欲が高まったのにやり方がわからないのはもったいない。

どうしても分からなければ、出来る限り内容を詳しく書いて、誰かが答えてくれるかもという願いを込めて掲示板で質問するしかない。ところがどっこい、頑張って詳しく内容を書いても誰も答えてくれない確率が高いので、自分で検索したり、本を横断したほうが近道だったりします。

最後に、挫折確率を下げるやり方として、なんでも適当におおざっぱに進めていくのがよい。細かい部分は後から修正するという信念で、とにかく最小限の機能に絞って動くものを、デザインはひどくてもよいから早く作ると。

コードも汚くてよいから、動けばよいという哲学で進めると、ここでもまた挫折確率が低くなる。綺麗なコードに書き直すとか、そういうのは後々勉強すればよいので、はやくリリースさせるのを優先する。次は次はというテンポを作って、途中で止まっちゃわないように。

大抵の人の最初の壁となるのは、if構文とかループとか基礎的なプログラミング構文でさえもない。環境構築であったり、サーバへのアップ方法であったり。iPhoneアプリだったらXcodeの使い方であったり、Developer登録であったり、実機への転送方法であったりする。

こういう事は、実際にその都度、検索しながら覚えていくしかない。基礎をすっ飛ばして、こんなやり方で後から困らないの？と心配になるかもしれない。でも、技術的な事を心配する前に、その他の要素で挫折する可能性は限りなく高い。

そもそも、最初の段階で、これをまず覚えて、これも重要でと、あれこれ考えるとめんどくさくなって挫折すると思います。

基礎固めや発展的な知識は慣れてくるとそのうち興味が湧いてきて、自分からいろいろと知りたくなってくると思う。なので、最初はあまり心配せずに、ある程度興味を持ってきてから言語について学んだり、他人の書き方を参考にしたり、リファクタリングとかデザインパターンを学んだらいいと思う。

最後に、iPhoneアプリを始める人にお勧めの3冊を書いておきます。

「よくわかるiPhoneアプリ開発の教科書」
最初に読む本として最適。この本でとりあえず動くものが見れて、全体像が分かる。

「UIKit詳解リファレンス」
iPhoneの見た目の部分をどう実装するかの本。初心者の頃は手放せない。

「詳解Objective-C」
言語のリファレンスとして、辞書的に使う。

※番外
「iPhoneアプリ設計の極意」
UIデザイン、ユーザビリティを扱った海外で評判の本。翻訳も凄くいい。プログラミングは一切出てこないけど、UI設計の基礎知識をつけたり、知識の漏れを埋めるために凄くいい本。

サービスのアイデアを考える時、たくさんある中からどれにするかはみんな悩むと思う。悩んだ時は情熱を基準に選べばよいと考えるしだいであります。ビジネスモデルやマーケットもとても重要だけど、当人の情熱とは比較できない。

感情的な部分と、論理的な理由でなぜそう思うようになったか書いてみる。最初に感情的な理由から。

よいサービスを作るのには労力も時間もかかる。情熱がないと、強力な競合が出てきた時や、周りが理解してくれない時、なかなか収益源が見つからない時に、やる気をなくして違う事に移ると思うのである。

お金が儲からないと食っていけないけど、逆にお金がなくなって日銭稼ぎに他の仕事をしたとしても辞めたくないものとか、今の仕事を続けながら作った貴重な時間でやりたいぐらいの情熱を持つものがよいと思う。どうせ軌道に乗るまで時間かかるし。

また、お金よりも自分の情熱をモチベーションにしたほうがやる気も生産性も全然違う。もし途中で辞める事が物理的にできない状況でも、モチベーションがなくなると生産性は極端に下がるから、どうせいいものはできない。

自分はグルーポン系サービスのアラートサービスを2010年の12月から2011年の3月まで作ってました。もちろん、当時はやる気モリモリで毎日開発していたのだけど、思い描いていたような機能を搭載している類似サービスが出現した時にぴたりとやる気がなくなってしまった。

今思えば、自分が死ぬほど欲しいサービスというよりも、これが流行りそうだから誰かが作る前に早く作ろうという気持ちが強かった。

最初は、なんかWebサービス作りたいけどなにかよいアイデアないかな考えていました。マッシュアップアワードのAPIリストを眺めて、流行りそうなサービスを思いついたから作ったという経緯。それもYipitという海外のサービスのパクリが始まり。まあ、アイデアをパクる事は問題ないのだけど。

思い返すと日本でも絶対こういうサービスが出るから、早く作ろうという焦りみたいな気持ちが強かった。似たようなアイデアで、もっと上手に作ってくる競合が出た時点で簡単に諦めちゃうというオチでした。

この時、次に作るサービスは絶対に自分が死ぬほど欲しいサービスを作ろうと思った。毎日そればっかり考えて時間とエネルギーを注ぎ込むから、競合が出てきても逆に自分の選択肢が増えて嬉しいぐらいの分野がいい。

というわけで、2011年の3月に次になにを作ろうか考えていた時の話をしてみる。

その時は、いわゆるスケールしそうなアイデアとか、自分が面白いと思ってスタートアップ的なウケもよさそうなものもいろいろ選択肢としてはそれなりにあったのだ。でも、最終的にiPhoneアプリという一見こじんまりしちゃうけど、情熱度が高いLisgoを作ることに決めたのです。

他のアイデアは面白そうだなぐらいのレベルだったけど、Lisgoのアイデアは、何が問題で、どこが不満で、代替手段をあれこれ試しているけど、こんなのとても面倒だという具体的な部分まで分かっていた。

冷静に何度も考えて、どのサービスが実現したら自分の生活が大きく変わって、毎日使うかとなると、これ作るしかないわとなって、iPhoneアプリ開発のためにMacを買ったのです。

というのも、僕は読書もオーディオブックも好きで、AudibleもKindleも結構初期から前から試していた。でも、オーディオブックは便利だけど、読んでいる途中に気になる箇所を目で確認できない。

本は目が疲れたり、物理的に目や手を使いたくない時にオーディオブックみたいに耳で聞く事に移行できないのが多いに不満だ。Kindleの読み上げ機能は一番ビジョンに近かったけど、オーディオブック業界に圧力かけられて、ほとんど使えない有様だった。

しょうがないから、Web記事をPCの読み上げソフトでMp3化したり、本を裁断して100冊以上自作オーディオブックを作ってiPodで聞いてたりした。でも、死ぬほど面倒だし、本を目で読みたい時に、今はどのページだっけと目で確認しないといけない。

何を言いたいかというと、他のサービスのアイデアは「ああ、いいの思いついた、あったら便利かもしれない。実際にこんなのあるか調べてみるか。」みたいなものだったのにたいして、Lisgoのアイデアはすでに自力で代替手段を試しまくっていて、本当に困っていた。

ちょっと話が飛ぶけど、自分が欲しいサービスの場合は凄く有利だ。自分の問題を解決するサービスになるので、自分が最初の熱心なユーザになれる。ここでは、自分がユーザだと問題が圧倒的に理解しやすいという当たり前の話はおいておいて、サービスの焦点の話をしたい。

他の人にも喜ばれるかや、自分以外の視点で考えるために顧客インタビューをしないといけないけど、この時に自分が欲しいものという軸がないと、どの意見を優先するか悩みまくると思う。

実のところ、ある程度ターゲットを絞ってもユーザが10人いたら10通りのニーズがあるから、それぞれ微妙に違うことを言う。Aさんにとって一番重要なことは、Bさんにとってはどうでもよかったりする。ニーズを絞ったつもりでも、さらに細分化されていく。この時、自分が望むものの軸がないと、どのユーザを優先するかの基準が見つけにくい。

一番お金が儲かりそうなユーザに絞るというのはよさそうな指標だけど、どれが最終的にスケールしそうか予測するのは不可能だし、前述した通り情熱がなくなると途中で諦める。

リーンスタートアップが普及して、ユーザの行動やニーズを観察しながらピボットするという考えが主流になってきている。ユーザの反応を見ながらサービスを作っていくと、毎日が細かいピボットの連続であると思います。どういう時にピボットするべきで、どういう時に諦めずに方針を貫くべきかはみんな悩むし、よくある質問だ。

これは、誰にもわからない。最終的に正否は結果で判断される。どうせ、自分で考えないといけない。

だから、情熱が継続して、ビジョンがあるものを作ったほうがいい。競合相手がいても、自分が凄く欲しいものだったら、なんらかの部分に不満がでて、そこが突破口にもなるし。

結局、世の中は不確実な事が多くて、どれだけ頑張っても様々な理由で上手くいかないことが多いと思う。その時の流行りとか、周りの意見はそこそこにして、自分が困っている事を解決できるようなものを作ればよいと思います。

※参考リンク
Before product-market fit, find passion-market fit
アラートポン

先日、どうにも寝付けないのでeCornerというスタンフォード大学が提供しているアプリのポッドキャストを聞いていた。適当に検索したらRailsを作ったDHHの1時間ぐらいの話があったので聞いてみたら、これが最高に面白かった。

だいたい1時間ぐらいの長さだけど、前回書いた「スモールビジネス対スタートアップ」という記事で紹介した紹介動画の元ネタであった。リーンスタートアップのドンであるスティーブ・ブランクがスタンフォードでしているリーンランチパッドという授業にDHHが講演にきた時の話。

あの短い動画の中でも挑発的な事を言っていたのだけど、最初から全部聞いてみるとあの動画の調子のまんまであった。ひたすらスタートアップのエコシステムを全否定するような感じの事を喋っている。

37Signalsの本でも書いているように、DHHはアンチVCである。簡単に説明すると、「人のお金で新しいビジネス作ろうとしても他人のお金だから適当に使う。結果、新しい事業を創出する上で最も難しく、重要な利益の最大化という部分を後回しに考える。VCのお金を受けるという事は時限爆弾のようなもので、収益化のリスクを先延ばしにする。」と言う事を言っていた。

これは、リーンスタートアップ関連でRunningLeanという素晴らしい本を書いているAshさんの主張と部分的に似ている。あの人も、ユーザがお金を払うかどうかは最も重要でクリティカルな部分なので、一番最初にそのリスクが高い部分を検証するべきだと書いていた。

どちらも、ユーザ数が増えて後からビジネスモデルを探そうという姿勢は博打すぎるから無謀だという主張をしている。僕はこの意見にとても納得できるのだけど、どちらもSaaSが基本のビジネスが専門で、BtoC向けのビジネスではそう上手くいくかは難しいのではないだろうか。

TwitterとかFacebookとか、ネットワーク効果が必要で、BtoCで、課金モデルだと最初からユーザから集まる見込みがなくて、広告モデルしかしっくりくる収益源があまりない場合はどうなんだろう。

ちなみに、ここで言いたいのは収益化の話であって、サービスがウケるかどうかを検証するのはネットワーク効果必要なサービスでも、ある程度最初から検証可能だと思う。

そもそも、お金が余っていて、そのお金を投資にまわして、どれかの新規事業が成功して経済が回るシステムというのもそれなりに合理性があるはずから現在の形ができているはずだ。バブルが弾けるとは言われていても、VCと、それを必要としているスタートアップが存在するのも、どちらにとっても必要性があるだろうし。

というような考えが普通だとは思うのだけど、そういう常識的な考えを真っ向から否定して、教授をしているスティーブ・ブランクも「こいつは二度と呼ばないでおこう」みたいな感じになっているのが笑える。

ちなみに、生活していくお金がないから投資を受けるんだとかっていう意見にたいしてDHHは、それなら今ある仕事を辞めないで、少ない時間を使って少ない時間でできる事から初めてビジネスを作れと言っていた。自分のお金で、自分の貴重な時間を使うから、最小のコストで最大の結果が出るように真剣になるはずだと。

後、投資を受けるのは事業拡大のスピードを必要とするからだという意見の反論も語っている。ユーザー数を増やすスピードを意識して、数年後に事業化の目処が立たないリスクを先延ばしにする行為はスピード以前に時間の浪費だろという感じだった。

そういえばこの前、ショーン・パーカーのインタビューを読んだ。シリコンバレーの投資モデルは欠陥があるからそのうち崩壊すると言った内容だった。

ポイントとしては、投資家のお金をもらったファウンダはIPOよりも最近は事業が買収される可能性のほうが高い。そして、事業買収で投資家に利益が出るなら問題ないのだけど、最近の買収は事業よりも創業者達を大企業に雇う目的の人材買収の目的が高い。

そこで、単純に創業者達がストックオプションとかよい待遇とかで引き抜かれ、事業そのものは潰して終了。創業者は自分の名前も売れて、大企業によい待遇で引き抜かれるけど、投資家はあまり得をしないというケースが増えてきている。

この話を読んでいると、最近起こった金融崩壊の原因である、トレーダー達のモラルハザード問題を思い出した。基本的に人間は自分の利益を最大化するように行動するので、リスクとリターンのバランスが崩れて、リスク過剰に取った方が得になった場合はそうする。

さて、こういう問題が起こると投資する人達が早晩いなくなるんじゃないかと危惧する人もいるかと思うけど、TechCrunsh創業者のマイケル・アリントンがこのトピックについて最近書いていた。

ロン・コンウェイとか著名な投資家が言うには、そもそも、大企業にタレント獲得の目的で買収されるスタートアップは、競争に負けたスタートアップだからあまり気にならないというスタンスらしい。多くの失敗したスタートアップの中で、少数が大成功してIPOしたり、投資家に利益が還元される買収をされれば問題ないので、そこまで重要じゃないと。

なるほど、そういう考え方だから問題ないのかと一瞬思ったけど、絶対に問題だと思っている投資家も多いだろうし、ここらへんは弁護士の書類にまたなんらかの条項が増えるんだろうか。

なんにせよ、これからはますます、最初から収益化を模索するスタートアップが増えて行くのだと思う。

そういうわけで、Lisgoもここ数ヶ月、持続可能なビジネスモデルをなんとかテストしようと頑張っていた。具体的にいうと、毎日使ってくれるファンは最低でも10人以上いたので、無料版出すと同時に、全体の２％ぐらいからだけでも月額課金のモデルが上手くいくかためそうとしていたのである。

現時点でのダウンロード数とかはどうでもよくて、むしろ無制限バージョンになる現在のバージョンは誰も買わない100ドルとかに設定して、しこしこ改良しながらアップルの審査を待っていた。

しかし、残念なことにアップルの審査でリジェクトされた。機能へのサブスクリプションだからという理由らしいけど、WebベースだとOKだったりと、実際の審査の基準は非常に曖昧だ。残念。しょうがないから、他の持続可能な収益源を模索するしかない。

＠リンク
DHHのUnlearn Your MBA
http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2334

マイク・アリントンのタレントBuyで買収されるスタートアップに対する記事
http://uncrunched.com/2011/12/05/gowalla-founders-v-gowalla-investors/

ランニング・リーン
http://www.runningleanhq.com/

この前ブログを書いた時からしばらくたってしまった。ちょっと面白いアイデアを思いついたので今日は久々にブログを書いてみようと思う。面白いアイデアとは、ブログを書く時間に制約を与えるというものだ。

そもそも、なんでみんなブログを書かなくなるかというと、忙しいっていう以前にインセンティブの問題だと思う。例えば、マーケッターとかコンサルタントとかはそれなりにブログを書く理由があるわけです。宣伝になる。

でも、僕は今アプリをもくもく開発中なので、うーむ、ブログ書く時間あったら開発に時間さいたほうがいいんじゃないか。そもそも、Lisgoのユーザは現時点では英語圏の人達だから英語でブログを書かないといけないぞ。めんどくさないな、やめよう。となっていたわけです。

しかし、そういう日本語版を出す前になってから宣伝のためにブログを書き始めるかとか、就職に役立ちそうだから自分の技術力をアピールしつつ、開発チップをシェアするような記事を書こうかと考えていると、あまり無垢な気持ち筆が進まないのではと思い立った。

というのも、なんか思いついたのでそのまま書きなぐろうという感じの記事が結構面白い可能性があるのではと思ったのだ。あまり、ポールグレアムみたいに何回も回りの人に見てもらって、何回も書き直してっていうやり方はしんどくなって最初の一歩が出ないのではないかと思う。

それより、誤字脱字とかがあっても修正せずに、適当に書いたほうが楽である。そもそも、誰も自分のブログなんて真剣に読まないし、昔の記事になったらなおさら誰もさかのぼって読もうなんて人はいない。それなら、プロダクトのアップデートを繰り返すみたいに適当に書きまくって出荷、の繰り返しが実はいいのではないかともんもんと考えていた。

イメージとしては、ドワンゴの会長が書いているような、なんか頭の中を考えたそのまま文章にして、書き直すとかはあまりしてなさそうなのが面白いのではないでしょうか。

と、書いていたら、まったく制約を話からずれてしまったので、１５分の制約の話をしてみる。僕は37Singalsの本が好きで、「制約は力なり」という合い言葉も好きです。なので、毎日Lisgoの開発時間も起きた直後から6時間だけと決めていて、制限時間がきたら絶対に途中で辞めるというやり方で毎日やっている。

この効果は絶大で、まったくストレスを感じないし、モチベーションが落ちないし、むしろ次の日へのモチベーションが上がり、こつこつとなぜか毎日続く。なんか村上春樹もこんな感じで小説を一年以上書き続けるみたいだ。

というわけで、こういうスタンスで気の向いた時に思った事をブログに、15分以内に書きなぐってアップするということをしてみようと思う。ここまで、だいたい14分以内に書けた。なので、記事の質は落ちるけれでも、そもそも誰も自分のブログ記事なんて気にもしないので問題ないと思う。