コーチ・ユナイテッドの有安さん

FailCon Japanの午後のセッションに登場したのは、「Cyta.jp」を提供するコーチ・ユナイテッドの有安伸宏さん。「2週間で検証できることに6ヶ月かける失敗」と題されたセッションで失敗談が共有された。

たまたま隣にいた弟と気軽にサイトをつくってみた

200種類のレッスンが受けられるCyta.jpが目指すのは、「地域のサービスをスマホで買う」という未来だ。モノがAmazonで買えるだけでなく、オフラインのサービスをオンラインで見つけて予約できる時代を描いている。

自らを「オフィスにこもって事業をつくるタイプの経営者」だと話す有安さん。スタートアップのプロダクトづくりには細かいイテレーションが必須で、そこには仮説検証が伴う。

「過去に検証が成功した最たる例は、Cyta.jpというサービスコンセプトを検証した時のことですね。Cyta.jpのアイディアを思いついて、プロのドラマーだった弟にコーチ第一号になってもらったんです。とりあえず簡単なホームページをつくって、思いついた価格で生徒を募集してみたら、SEOが効いて生徒が集まりました」

ユーザー獲得コストを一切かけることなく、1ヶ月ほどでスピーディにアイディアを検証することができた。

2週間で検証できることに6ヶ月かける失敗

一方、失敗してしまった検証の事例が、Cyta.jpに受講生同士のコミュニティを設けるというアイディアだった。

レッスンを受けるユーザー同士がつながって切磋琢磨すれば、ライフタイムバリューもおのずと上がるはずという仮説に基づいたものだった。

4ヶ月から6ヶ月をかけて最初から大きな仕組みを実装したところ、驚くほど使われなかったと言う。使われない原因を検証するためにユーザーに電話をしてみてわかったことは、自分たちが思っている以上に「社会人にとってレッスンを受けることは“パーソナル”である」ということだった。

「一番の問題は、この結果にたどり着くまでに6ヶ月という長い期間をかけてしまったことです。大きな機能だったので当然エンジニアの気合いも大きいですし、それまでに投資したサンクコストも膨大でした」

仮説検証のあるべき姿とは

ではどうすべきだったのか。有安さんは5つのポイントを挙げる。

• ユーザーと会って話す
• ペーパープロトタイピング
• コードを一行も書かない
• 最低限の実装で済ます
• ソースコードを後で捨てることをエンジニアと合意する

まず検証すべきは、ユーザーにとって価値があるか。それを知るためにはユーザーに会って話を聞くしかない。このユーザーヒヤリングに際しては特に意気込む必要はなく、それこそ画面を手書きで書いたペーパープロトタイプでいい。そうすれば、開発やデザインのリソースを使うこともない。

「コードを一行でも書いた時点でそれは負債だと認識しています。一度書いたものは、プログラマーも思い入れがあるのでお蔵入りするともなれば彼らのモチベーションにも響く。いかに最低限の実装で済ますか、仮説検証においてここは大事ですね」

こうしたプロセスを経てわかったことを基に、方向転換していけばいい。

現在も、毎週のように起業家の相談に乗る中で、「ユーザーに直接会って話す」ということをしているスタートアップは少ないと指摘する有安さん。もっとユーザーに会うべきだと強調した。