今さっきコンバーチブルノートについて具体的に説明していた素晴らしい記事を読んだ。
シリコンバレーで起業した日本人が語るスタートアップガイド2――シリコンバレー流の資金調達

で、そこで出て来た、自己資金で行くべきか、外部資金を調達すべきかどうかっていう話が面白いと思いました。シリコンバレーのスタートアップ流でいうと「自己資金で行くなんて甘っちょろい事いってると勝てるわけないだろ」っていうのが基本だと思う。

そんな時よく出てくるのが、37signalsの例。自己資金だし、リモートでみんな仕事してたりするし、シリコンバレー流のやり方とは完全に離れている。ポールグレアムも「チームは絶対一緒の場所にいないと成功しない。37Signalsは例外だ」と例外発言してたし。

そこで、なんか寝れないからネットをさまよっていると、リーンスタートアップ界のドンこと、スティーブブランクの2分そこらの動画があった。Small Business vs. Startup with Steve Blank

この動画では、「みんなスモールビジネスとスタートアップを混同してる。どちらも名前がスタートアップ（起業）だから誤解するんだ。シリコンバレーのスタートアップはスケーラブルスタートアップなんだよ。ちなみに、よくプログラマー達は37Signalsの例があるじゃないかって反論するけど、彼らも最初はスケールできるモデルで初めてなかったし、スモールビジネス的な思想を持っているよね。」と語っている。

おそらくここのポイントは、最初からスケーラブルな思想ややり方でやってないよっていう所で、今はスケーラブルだという事には疑問の余地がないんだろう。

面白いから、似たようなキーワードで検索したら、そのものズバリ、スティーブブランクが、37SignalsのスターでありRailsの作者DHHに「スモールビジネスとスケーラブルなスタートアップの解釈の違いで質問があるけど、37signalsは今のやり方でビリオンダラーカンパニーになれると思うのかい？」って聞いている動画を発見。David Hansson(37Signals) A Small Business Can Be a Highly Profitable Company

そこで、DHHは「もちろんできる。」と言っている。「37signalsは300万人以上のユーザがいるけど、チームは15人。僕の中でのスケーラブルという定義は、従業員を増やしてその分利益を増やすモデルではない。従業員を増やさなくても利益を増やすのがスケールというものだ。利益の増加と従業員の増加が相関しないのがスケールという意味だと思う。」と答えている。

ちなみに、37signalsは”全部自己資金で儲かってるぜ！”シリーズというインタビュー記事集もやっている(笑）　有名どころとしては、Githubの記事がこちら。プロダクトの開発過程とか、いかに個々人が情熱を持って仕事を出来るかという考えを見るうえでもとても面白い記事。bootstrapped-profitable-proud-github

テクノロジ系スタートアップは１人のプログラマが大きな価値を生むので、元々スケーラブルだとは思うんだけど、外部資金をいれるかいなかって視点に立つとなかなか面白いと思った。どうでもいいけど、37signalsの例を出されてむかつくスティーブブランク師匠はスピードが足りないっていう視点で反論したほうがよいのではないだろうか。

まあ、最近メシ食った時に友達が、「法則とか定番化してみんなが当たり前だと信じてる事は全部疑うべきだ」と言ってたけど、これはその通りだなあと話してて思った。まあ、いろいろなノウハウを学ばないのもよくないけど、固定観念を持つのはよろしくないなと。

例えば、「初期段階はプログラマしかいらない」とか、「共同創業者を絶対見つける」とか、「出来るだけ外部資金入れるな」とか、「シンプルにしろ」とか、「早寝早起き」とか。

というどうでもよいことを考えてたら、また夜更かししてしまって早寝ができなかった。ツタヤで借りた漫画も延滞料金が発生する日なのに返せなかったし。ほんと、ツタヤの延滞料金はぼろい商売だと思う。

夏頃からiOS Meetup Tokyoという月一の勉強会に参加している。主に日本在住の外国人の開発者が集まる勉強会で、毎回15人程度が来て少人数のディスカッション形式。

昼に2時間近く勉強会して、その後行きたい人はご飯食べにいくので、少人数なのもあって仲良くなりやすい。

昨日、そこでTextToSpeechについてプレゼンしてきました。初めての英語のプレゼンで英語もなんか怪しいけど思ったよりウケた。よかった。たまたま、前列のピーターさんがiPhoneで途中から録画してくれてたのでアップ。

Lisgoで忙しく、ブログを書いてなかったのだけど、リーンスタートアップジャパンの夜会も開催されるとのことで、久々にブログを書いてみる。前回のブログ記事からかなり前進したので、その過程を思い出しながら書くとします。

※LisgoとはWeb記事を音声読み上げするiPhoneアプリで、ReadItLaterと連携させている。

目次
*ターゲットを絞って作り直して大正解
*コンセプトを絞ることによって熱心なユーザが見つかった

ターゲットを絞って作り直して大正解

以前のLisgoは大衆にアピールしようと、とりあえずブラウザを搭載して、そこから読み上げる記事を探してきてくれっていう仕様でした。しかし、これは最初の記事を取ってくるのが非常に使いづらい。

一ヶ月ほど前に、Zerobaseの石橋さんに相談して頂き、その時、自分が最初のユーザならまず自分をターゲットにして最小限の必要なものを作り、そこからアーリーアダプタのユーザへと降りて行けばよいと言われた。これが自分にとっては雷に打たれたかのように素晴らしいアドバイスでした。

というわけで、以前のコードを全部捨てて、自分がヘビーユーザであるReadItLaterという後で読むサービスのリストを取ってくるバージョンを最初から開発しなおした。もう、作る前からこういう仕様だったら圧倒的に使いやすくてシンプルなものになるのは明白だった。

しかし、この時悩んでいたのは、以前あったブラウザ機能を完全に捨てるなら別の名前のアプリとしてリリースしなおしたほうがいいのかってことでした。一応、Lisgoは英語学習者の人たちが最初に少ないながらも買ってくれていたので、この人たちはReadItLater連携アプリになったら使えなくならないかなあと夜も眠れない日々が続いたわけです。

まあ、とりあえずReadItLater連携作って、後からブラウザも付けたそうかなとか考えながら開発していき、結局リリース前にブラウザ機能はやはり完全に捨てることにした。なぜかというと、自分がまったくいらない機能だし、ReadItLater連携する人にもまったくいらない機能だからでした。

以前のユーザにはちょっと申し訳ないなあと思いつつReadItLater版をリリースしたものの、そもそもこの時点でLisgoを買ってくれた人は60人？ぐらいしかいなかったので、特にお怒りのメールはこなかった。おそらく使いにくいブラウザ機能で使い続けてくれていた人は数人ぐらいしかいなくて、その人たちはめんどくさくてメールもしないか、願わくばReadItLaterに登録して使ってくれたのかもしれない。

あまりユーザベースが少ないってのは方向転換がしやすいっていう利点はある。それでも、最初のブラウザ機能になれていて、ReadItlaterなんて知らんよっていうLisgoのファンを切り離す痛みは結構あって、悩んだ。その人たちがReadItLater使うと圧倒的に便利になるとは思うけど。

ちなみに、”TheLeanStartup”という話題の本をこの前読んだけど、マークザッカーバーグはFacebookが拡大するにつれ、初期の大学専用に使ってくれていたユーザの望むものから離れることはしょうがないけど心の痛みであると言ってたらしい。

さて、アプリとしては自分的に圧倒的に使いやすくなり、これは間違いなくイケルわと確信に満ちあふれながら毎日使い倒している毎日です。で、普通の企業が作っているならまだβテストの段階で、最小限の機能しかないのだけど、リリースする事が重要との事で、二週間ほど前にReadItLaterバージョンをリリースした。

次は、ターゲットを絞ったおかげで熱心に応援してくれるユーザが見つかったという話。

コンセプトを絞ることによって熱心なユーザが見つかった

さて、ReadItLaterと連携させることによってLisgoがシンプルで使いやすいものになったのですが、この訴状効果として、最初のターゲットも絞りやすくなった。

つまり、ReadItLaterユーザでTextToSpeech機能を使いたがっている人を探せばいいのである。とりあえずReadItLaterのサポートフォーラムでTextToSpeechで検索してみると、過去にこういうリクエストをしているトピックが6つぐらいあった。

しかし、ReadItLaterチームが「音声読み上げは間違いなく搭載するよ！」と返答しているものの、それは半年以上前の返信で未だに搭載される気配はない。というわけで、トピックに自ら返信してみると、とても興味を持ってくれて、TestFlightというiPhoneアプリのβテストができるサービスを介してテスターになってくれた。

というわけで、TestFlight経由でβテストをしてくれる人は14人ぐらいいるのだけど、毎日使ってくれる人はその中でも4人ぐらい。その人たちがとても有益な意見をくれたり、バグレポートをしてくれたり、どういう状況で使ってるかというのを教えてくれて死ぬほど開発の助けになってます。

特に、RunningLeanを先に読んでたのが大きい。この本には顧客には欲しい機能を聞いたり、製品を売り込むなと書いていて、ひたすら顧客の現在の問題や状況を詳しく聞いたり、アドバイスをもらうなど、ユーザへのインタビューの方法が先に学べたので、それがスカイプでボイスチャットする時や、メールでやりとりする時にとても役に立ってる。

中でも熱心にサポートしてくれる人は3、４人だけど、コンセプトを限定しているので、ちょっと自分のビジョンと違うなあというような提案はほぼ皆無。このブログポストと同じぐらい長いメールのやりとりを何度もやっておるわけです。ここまで時間を投資してくれてアドバイスや使用レポートをくれるというのは本当に素晴らしい。

Lisgoはまだ全然売れてないけど素晴らしい。やる気が出るという意味でモチベーションを高めまくってくださる。まあ、リリースしたけど普通ならまだβテストの段階であまり広まりすぎても困るので今はこのぐらいでちょうどよいかもしれない。

ちなみに、自分が最初のターゲットだから、一番重要なポイントや、どう開発していけばよいかはだいたい分かっているのだけど、それでも同じような趣向で使ってくれるユーザのくれる意見はとても参考になる。

自分だけでは気づかなかった問題とか、使い方。さらには、機能の提案も9割以上は自分の頭の中で考えた事があるものだけど、中には気づかないナイスアイデアをもらえたり、自分が重要だと思っていた機能はそれほど使われなさそうだというのが事前に分かったりする。

というわけで、細かいバグを潰したり、基本的なユーザビリティを高めたりとこつこつアップデートしてるんだけど、特に新しい機能を追加する時はよく意見をくれる人に聞いてみるというのも最近はやってみた。

RunningLeanのAsh師匠も機能追加する時は本当に慎重にしろっていってたし、誰も使わない機能を作らないように何度も考えたり、こういう機能を追加する予定だけどどうだろって聞くのは凄くいい。（どんな機能欲しいか聞くのはよろしくない）

ちなみに、顧客インタビューする時には、「これこれの機能が欲しい」と言われた時は、なんでその機能が欲しいかを出来る限り詳細に説明してもらって、本質的な欲求の部分を探るようにしている。

メールをする時によく書いているフレーズは、なんか機能の不満点や、改善の要求がある時は、出来る限り深くユーザーの事が知りたいから、その考えに至った状況を教えてくれって言っている。だいたい予想できるかもしれないけど、勘違いしたらまずいから詳しくなんでそうしてほしいのかを教えてくださいお願いといた感じで。そうすると、大抵の人は機能要求や、不満点と一緒に自分が陥っている状況を書いてくれるので聞き返す必要があまりない。

しかし、とっても重要なビジネスモデルが機能するかどうかを最初に顧客に聞くっていうのがまだ出来ていない。具体的にはヘビーに使う人のみ月額課金にするとかそういうものなんだけど、世の中のSaaSだとBtoBだからまあ課金モデルはありなんだけど、iPhoneアプリで一般ユーザ向けのもので月額課金なんて相当難易度高いし、ちょっと無理なんじゃないかとも思われるけど、とりあえず今度またスカイプでボイスチャットしてくれる人に聞いてみることにする。

先日、クックパッドの勉強会の抽選に受かったので行ってきた。スマートフォンのビジネスという内容であったけど、顧客開発的な手法がものすごく参考になって凄く勉強になった。

クックパッドは創業当初から顧客志向を体現してきた会社としていつも注目しております。また、ごちゃごちゃしないシンプルなデザインを突き詰めていたり、デザインにとても力を入れているのでずっと前から参考にしていたのだけど、今回はさらに深い内容が聞けて素晴らしかった。

定性的なインタビュー

サービス改善には定量的なデータだけでなく、定性的な顧客インタビューをとても重視してるらしい。サイトやアプリのデータマイニングから得られたデータを元に、現在の課題に近い属性のユーザを実際に社内に招いて、サイトやアプリを使ってもらうところを観察させてもらうとか。

いろいろと意見をくれるユーザもいるけれど、重要なのは、なぜその機能が欲しいかとか、なぜそこが不便なのかとか、お客が本当に求めているものを奥深くまで探ることだと教えてもらった。

特に、お客さんをよく理解して、優れた解決方法を実際に提案するのがプロの仕事だとその後の懇談会で教えてもらったのですが、ここはまさにリーンスタートアップの考え方と一致してるなあと思いました。顧客が問題を伝えるのは難しくないけど、解決方法を考えるのはサービス影響者だと。

あと、いろんなユーザの意見があったりすると、どれを最後に選択するかどう決めるんですかと聞いてみたら、やっぱり多数決より最後はリーダーが決めるのがよいらしい。このへんはいろいろな方法を試した現在の最善策だとか。

特に興味深かったのが、いろいろな意見がある時にどうしたらチームがぶれずにまとまるかっていう部分。ここは、共感というものが重要らしい。

たくさんの意見がある中で、Aさんという特定のユーザを取り出して、この人を喜ばせたいからオラに力を貸してくれ！みたいな感じでリーダーが引っ張るとまとまりやすいらしい。そうなると、チームのイメージも、このAさんならどう考えるだろうと思考が共有できるので、ぶれにくいとか。

ここらへんは、アップルの、「ジョブスならどうするか」っていう考えと似ていて面白かった。

ご意見ボックスとUIの改善

クックパッドのアプリには「ご意見ボックス」なるものがあるけど、これを実際にどうUI改善に使ってるかという話が面白かった。

ご意見ボックスは単純に、顧客の要望を集めるっていうイメージがつきそうだけど、ユーザの求めているものを実装していくとひどい製品が出来上がるのはよくある話。

これは定量データではなかなか把握できないユーザの行動データを分析するのにとても役立ってるみたいです。

例えば、アンドロイド版のUIでカテゴリ機能をつけたけど、ぱっと見ではその機能があるかどうか分かりにくかったと。カテゴリ機能があるのに、ご意見ボックスから「カテゴリ機能が欲しい」という要望が多かったとか。

そこで、UIの改善案を社内でいろいろ練って、いくつかの最終案を実際に試してみて、最終的にはご意見ボックスから「カテゴリ機能をつけて欲しい」という意見がこなくなったことでユーザがその機能を発見してくれていると数字でわかったと。

新しいUIを考える時のステップや、取捨選択も面白かった。テスト手法は、少人数→社内で実際にテスト→特定の顧客を社内に呼んで観察させてもらう→リリースみたいな、小さくちょっとづつ定性的にテストすると。

リーンスタートアップ本にも書いてあるけど、初期段階だと十分なユーザデータが取れないから、本当に絞ったユーザから定性的なインタビューをするのがベスト。その後、定量的なデータ分析は実際にリリースした後からじゃないとなかなかできない。

僕はiPhoneアプリを作ってるので、Appleの審査を通るまで実際にユーザに使ってもらうことができないなあと思ってたら、最近参加したIOS Meetup Tokyoで経験豊富な開発者の人にTestFlightといういいサービスがあるよと教えてもらった。

Appleの審査前にユーザのiPhoneにインストールしてテストしてもらえる優れものらしい。これはナイス。

リーンスタートアップ関係のビデオとか記事とか読んでると、自然とUXの話題も出てくる。いろいろ読んでると、リーンスタートアップの顧客開発の、特に初期段階のインタビュー手法部分はUXの手法とそっくり。UXと非常に共通点が多いとAdaptivePath社の社長さんが言ってる。

ここで、「リーンスタートアップなんてくだらん、UXのパクリじゃないか」とファンノイマンがナッシュ均衡を馬鹿にしたみたいにディスらずに、Lean UXとか無理矢理な造語を新しく作ってチャンスとばかりにアピールしているところが凄い。

まあ、なにがいいたいかと言うと、リーンスタートアップの手法の日本語記事はまだあまりないので、最初の顧客インタビュー部分とか、顧客観察部分のノウハウを知りたければAdaptivePathとか出してる「Subject to Change」を読めばいいと思う。僕も半分ぐらい読んだけど、これはかなりいい本だと思います。

ただ、テク系スタートアップにつきものの、プログラム部分の開発手法の細かい部分とかはアジャイル開発の、「アジャイルサムライ」って本とか読むとよいはず。ここはUXではカバーできないはず。

そう考えると、リーンスタートアップってのは、とにかくいろんな手法のいい所をパクリまくって改良を重ねているノウハウという感じでしょうか。

唯一ユニークな部分は、既存の大企業と違って収益方法が確率してない不確実な時期に、ビジネスモデルの実験を定性的にも定量的にも繰り返す部分かもしれない。まあ、これもそんなに新しくないかもしれないので、なんか既存の手法で参考になるものがあれば教えてくれると嬉しいです。

ちなみに、本日、大々的に宣伝されているEric Riesのリーンスタートアップの本が発売しますが、これもはやく読んで紹介したいと思う。Running LeanのAshさんによれば、inovative accountingの部分が新しくて面白いとか。しかし、なんにつけても新しい造語をつけて凄そうな理論にする姿勢は多いに学ばないといけない。

Lisgoも、イノベーティブリーディングとか、スピードラーニング的なキャッチーな宣伝文句を考えるとよいかも。

※参考文献
UX の第一法則は「ユーザの声聞くべからず」

LeanUX『実践的 User Experience ワークショップ』まとめ

さてさて、Eric Riesの LeanStartupも発売間近となり、いろいろなサイトで流行初めてきているリーンスタートアップのムーブメント。

現時点ではRunningLeanが最高の本に間違いないと思うのだけど、購入した人は著者のAshさんに30分のスカイプチャットできるという特典がある。この特典はいつ終わるかわからないので、早めに申し込もうと思う。

で、自分はなにを聞きたいかを今考え中だけど、特に思いつかないかもしれないので、こんなの聞いて欲しいという方がいれば募集します。

@umekun123のTwitter経由でもいいし、このブログのコメント欄でもいいです。
ちなみに、AshさんはSaaSが主に専門らしい。

Continue reading →

最初の顧客を探すのはとっても難しいのでみんな苦労すると思います。僕も大変苦労しております。RunningLeanによると、ランディングページを作ってブログを書き続けるのが一番効率よいと書いてる。

自分もランディングページ作ったけど、なかなかブログが進まない。ブログは書くのが時間かかってめんどくさい。で、ブログはユーザが検索して辿り着いてもらわないといけないから、効果が現れるのはロングテール的で、スピード感にかけるのは否めません。

そこで、とにかく仮説上のターゲット顧客に自分の製品を知ってもらいたい、でもFacebookとかGoogleの広告打つ金なんてないって時はTwitterでターゲット層にフォローするのが現時点でベストだと思う。

Continue reading →

先日、自分が最初のユーザである場合の製品開発の進め方のヒントを教えてもらったので、それを今回は書いていこうと思います。

（注）Web記事を音声読み上げするiPhoneアプリを作ってます

＠目次
「最初の動機は、自分が欲しいから作り始めたのであった」
「自分が欲しいモノなら最初の課題は認識している」
「最初のユーザ１人用に作るとシンプルな製品になる」

Continue reading →

さて、前回の記事からしばらくたってしまいましたが、アップルの審査が遅いか
らずっと漫画読んでたわけではありません。RunningLeanを読んだ後、何にで
も影響されやすい僕はひたすら最初のユーザを探していました。

少ないながらもヒアリングさせてくれる人に会ったり、Lisgoの本当の最初のユ
ーザにSkypeでビデオチャットしたり、新規事業を専門に仕事している方にアド
バイスもらったり、ZenStartupの朝会にいってナイスアイデアをもらったりと幸せな時を過ごしていたわです。

しかし、肝心のLisgoはリリース後一ヶ月で50ぐらいしかダウンロードされず、
これは革命的なアプリだよ！と吹いていた初期の勢いはなくなり、最近ではもう本当に謙虚なものです。まあ、この間に学習できたことは膨大であるのでよしとします。

いろいろな事がわかったので、リーンスタートアップっぽいことを実践してみた現在進行形のケーススタディを今回は書いていこうと思う。失敗体験のケーススタディです。

（注）LisgoはWeb記事を音声読み上げするiPhoneアプリ

＠目次
「ぶれぶれだった最初のターゲット」
「興味持ってくれる人の探し方」
「ヒアリング結果でわかったこと」
「最初のターゲットが段々と微調整されていく」

Continue reading →

ちょっと前にRunningLeanを読み終わりました。リーンスタートアップの基本は顧客の欲しいものを作りましょうで、特別な事はなにも言ってないのですが、ここまで徹底した姿勢は衝撃でした。

今まで一番影響を受けたのがポールグレアムのエッセイだとしたら、RunningLeanはその次ぐらいかもしれない。この本を読んでると、”まるでスタートアップを受託開発してるみたいだな”と思いました。

受託開発だと顧客は最初からいるしお金も発生する。でも、スタートアップが新製品を作る時はリリースするまで売れるかわからない。人々が欲しいものと維持可能なビジネスモデルを模索するのがスタートアップなので最初は実証前の仮説しかない。

リーンスタートアップではこのリスクを出来る限り減らすために、これでもかというぐらい顧客に意見を聞いて、顧客にお金を払う価値があるかを確認しながら作っていくので、スタートアップの受託開発みたいという感想が頭に出てきました。

ちなみに、著者のAshさんは、90％以上は失敗するスタートアップの成功確率を、1,2％でも上げるための本だよと書いてます。いろいろ勉強になったのですが、特に重要だと思った部分を今回は書いてみます。

＠目次
「顧客に欲しいものを聞いてはいけない」
「顧客の話を聞く順番と意味」
「自分が欲しいものなら顧客の意見は聞かなくてよいか」
「芸術作品やネットワーク効果が必要なものはどうするか」

Continue reading →