FailCon Japanの午後のセッションに登場したのは、「Cyta.jp」を提供するコーチ・ユナイテッドの有安伸宏さん。「2週間で検証できることに6ヶ月かける失敗」と題されたセッションで失敗談が共有された。
たまたま隣にいた弟と気軽にサイトをつくってみた
200種類のレッスンが受けられるCyta.jpが目指すのは、「地域のサービスをスマホで買う」という未来だ。モノがAmazonで買えるだけでなく、オフラインの��ービスをオンラインで見つけて予約できる時代を描いている。
自らを「オフィスにこもって事業をつくるタイプの経営者」だと話す有安さん。スタートアップのプロダクトづくりには細かいイテレーションが必須で、そこには仮説検証が伴う。
「過去に検証が成功した最たる例は、Cyta.jpというサービスコンセプトを検証した時のことですね。Cyta.jpのアイディアを思いついて、プロのドラマーだった弟にコーチ第一号になってもらったんです。とりあえず簡単なホームページをつくって、思いついた価格で生徒を募集してみたら、SEOが効いて生徒が集まりました」
ユーザー獲得コストを一切かけることなく、1ヶ月ほどでスピーディにアイディアを検証することができた。
2週間で検証できることに6ヶ月かける失敗
一方、失敗してしまった検証の事例が、Cyta.jpに受講生同士のコミュニティを設けるというアイディアだった。
レッスンを受けるユーザー同士がつながって切磋琢磨すれば、ライフタイムバリューもおのずと上がるはずという仮説に基づいたものだった。
4ヶ月から6ヶ月をかけて最初から大きな仕組みを実装したところ、驚くほど使われなかったと言う。使われない原因を検証するためにユーザーに電話をしてみてわかったことは、自分たちが思っている以上に「社会人にとってレッスンを受けることは“パーソナル”である」ということだった。
「一番の問題は、この結果にたどり着くまでに6ヶ月という長い期間をかけてしまったことです。大きな機能だったので当然エンジニアの気合いも大きいですし、それまでに投資したサンクコストも膨大でした」
仮説検証のあるべき姿とは
ではどうすべきだったのか。有安さんは5つのポイントを挙げる。
- ユーザーと会って話す
- ペーパープロトタイピング
- コードを一行も書かない
- 最低限の実装で済ます
- ソースコードを後で捨てることをエンジニアと合意する
まず検証すべきは、ユーザーにとって価値があるか。それを知るためにはユーザーに会って話を聞くしかない。このユーザーヒヤリングに際しては特に意気込む必要はなく、それこそ画面を手書きで書いたペーパープロトタイプでいい。そうすれば、���発やデザインのリソースを使うこともない。
「コードを一行でも書いた時点でそれは負債だと認識しています。一度書いたものは、プログラマーも思い入れがあるのでお蔵入りするともなれば彼らのモチベーションにも響く。いかに最低限の実装で済ますか、仮説検証においてここは大事ですね」
こうしたプロセスを経てわかったことを基に、方向転換していけばいい。
現在も、毎週のように起業家の相談に乗る中で、「ユーザーに直接会って話す」ということをしているスタートアップは少ないと指摘する有安さん。もっとユーザーに会うべきだと強調した。
Members
BRIDGEの会員制度「Members」に登録いただくと無料で会員限定の記事が毎月10本までお読みいただけます。また、有料の「Members Plus」の方は記事が全て読めるほか、BRIDGE HOT 100などのコンテンツや会員限定のオンラインイベントにご参加いただけます。無料で登録する