StartupWeekendFukuoka June振り返り

スタートアップウィークエンド とは…
ある 週末の54時間の あいだ、
あなたのいる町に現れる 幻のシリコンバレー。

構成

  1. Startup Weekendとは
  2. タイムスケジュール
  3. 2014-06-13 ミートアップ&チームビルディング
  4. 2014-06-14 ビジネスモデル開発&MVP作成
  5. 2014-06-15 ビジネスモデル開発&MVP作成&発表
  6. まとめ
  7. 参考リンク

Startup Weekendとは

スタートアップウィークエンド とは…
ある 週末の54時間の あいだ、
あなたのいる町に現れる 幻のシリコンバレー。

“あなたを起業家にする54時間。No Talk, All Action!”
http://startupweekend.jp/

タイムスケジュール

  • 2014-06-13 ミートアップ&チームビルディング
  • 2014-06-14 ビジネスモデル開発&MVP作成
  • 2014-06-15 ビジネスモデル開発&MVP作成&発表

2014-06-13 ミートアップ&チームビルディング

イテレーション#00

イベントの流れとしてはアイデアを持ってきた人が発表して一緒に作りたい人を募って3日で何か作って発表する。
参加者の役割はハッカー(形にしていく人)・ハスラー(企画者・プロジェクトリーダー)・デザイナー(絵や図で示していく人)の3つ。
今回はハッカーとして『IDカード情報を使って病院の待ち時間がわかるサービス』というアイデアに参加。
メンバー構成は技術1名(男性社会人)マーケティング3名(男性社会人・男性学生・女性社会人)デザイン1名(女性学生)という構成。
会場は22時で閉まるためそのあと近所のマクドナルドで簡単な打ち合わせをして初日は終了。

2014-06-14 ビジネスモデル開発&MVP作成

イテレーション#01

Build

プランAを文書化する

メンバーの1人が体調不良のため参加できなくなったので4名体制でスタートすることになった。
まず、『IDカード情報を使って病院の待ち時間がわかるサービス』というアイデアを実現するにあたってリーンキャンパスを作成して整理することにした。
顧客としては病院関係者、患者を想定。そこから以下のように整理した。

  • 顧客セグメント
    • 患者
  • 課題
    • 診察カードを病院ごとに複数持つのは管理が大変だ
    • 病院の受付で長時間待つのは苦痛だ
  • 価値提供
    • 病院の診療受付待ち時間をなくす
      • 診察情報の一元化
      • 待ち受け業務の効率化

Mesure

プランで最もリスクの高い部分をみつける

整理したリーンキャンパスの内容を元にリスクの優先順位をつけることにした。
まず確認したのが製品リスクである『本当に課題は存在するのか?』に対してビジネスモデルインタビューを実施した。
実施内容を以下の通り。

  • イベント参加者へのインタビュー
  • 近隣病院への電話インタビュー
  • 近隣病院への訪問インタビュー

Learn

プランを体系的にテストする

インタビューの結果以下の洞察を得ることができた。

  • 患者
    • 総じて診察カードを複数もつことは問題だと思っているようだ
    • 待ち時間に関しては忙しい社会人にとっては重要だが高齢者などにとってはそれほど重要な問題ではなさそうだ
  • 病院関係者
    • 高齢者が多いのでICカードやスマートフォンなどハイテクツールの利用は期待できない
    • 待ち時間に関してはそれほど業務負荷ではない

洞察を元に定性的検証を実施した結果以下の結論に達した。

  • 患者
    • 仮説設定した課題は存在していそうだ
  • 病院関係者
    • 患者サイドの課題がそのまま病院関係者側の課題と繋がっていないようだ
    • 今回の課題とはあまり接点のなかった高齢者に対する意識が総じて強いようだ

上記の洞察をもとに以下ののソリューションを決定した。

  • ICカードを使った診察券統合サービス
  • 近くの病院の診察待ち時間がわかるサービス

イテレーション#02

イテレーション#01で決定したソリューションを実施するにあたって対象となる顧客セグメントのピボットを実施する必要が発生した。
なぜなら病院関係者にインタビューした結果反応が非常に悪かったため病院関係者から収益を得るモデルを構築するのは難しいと判断したから。

Build

プランAを文書化する

顧客を患者にフォーカスしてリーンキャンバスを更新した。具体的な顧客セグメントととして患者のなかでも高齢者とその家族に焦点を当てることにした。
なぜならば病院関係者からインタビューした際に高齢者の患者というキーワードが頻繁に出たから。

  • 顧客セグメント
    • 高齢者の患者の家族
  • 課題
    • 高齢者の患者が病院に出かけて行って戻ってくるまでの間家族が心配する
  • 価値提供
    • 病院に診察に出かけて戻ってくるまで間家族が不安になる時間をなくす
      • 病院に入って病院から出るまでの時間をわかるようにする

Mesure

プランで最もリスクの高い部分をみつける

変更したリーンキャンパスを元に製品リスクとして『病院側の協力なしには課題の解決はできるか?』という問題が焦点となった。
なぜならば問題を解決するにあたって患者が病院を利用した情報を取得する必要があるのだがそれを実現するためには病院関係者サイドの協力が必要があるから。
つまり、『患者サイドの課題を解決する方法で病院サイドにメリットが提供できるか?』という課題を解決する必要がある。

Learn

プランを体系的にテストする

いくつかの検証の結果以下の結論に至った。

  • 病院側の協力なしには課題の解決はむずかしい。
  • 患者サイドの課題を解決する方法では病院サイドにメリットが提供できない。

ここでプロジェクトは一旦停滞する。

イテレーション#03

イテレーション#02で停滞したプロジェクト状況を打開すべく何人かの外部アドバイザーに意見をもらう。そして価値提案のピボットを実施することになる。
この時点で当初の『IDカード情報を使って病院の待ち時間がわかるサービス』から『お年寄りと子供の交流の場を作り心の健康をまもるサービス』へとコンセプトが大きく変わる。

Build

プランAを文書化する

ベースコンセプトが変わったため新たな顧客ターゲット(お年寄り・登校拒否の子供)を想定したリーンキャンパスに再構築することになった。

  • 顧客セグメント
    • 老人ホームに入居しているお年寄り
    • 一人暮らしのお年寄り
    • 登校拒否児童の保護者
  • 課題
    • 孤独なお年寄りは会話が無い
    • 一人暮らしのお年寄りは孤独だ
    • 不登校児童はコミュニケーションが無い
  • 価値提供
    • お年寄りと子供の心の健康
      • 孤独なお年寄りと登校拒否児童のマッチングの場を提供

Mesure

プランで最もリスクの高い部分をみつける

再構築したリーンキャンパスを元に顧客リスク『本当に一人暮らしのお年寄りは孤独か?』と市場リスク『どこから収益を得るのか?』を検証した。
検証にあたってはイベント参加者へインタビューを実施。

Learn

プランを体系的にテストする

インタビューの結果以下の洞察を得た。

  • 一概に一人暮らしの老人が孤独とはいえない
  • 登校拒否の子供はコミュニケーションに問題があるようだ
  • 収益を得る部分がない

顧客セグメントに関してはまだまだ追加検証の必要があるものの課題は存在しそうな事がわかった。むしろここで問題となったのは収益に関する部分である。
十分な収益を得るモデルが見つからないのである。この時点ではNPOとして老人ホーム・自治体などからの協賛・寄付による収益モデルしか見つからなかった。
プロジェクトは再び停滞し始めたところで2日目が終了、各自課題持ち帰りとして解散した。
なお、サービス告知用ランディングページは必要なので解散後に宿泊施設付近のモスバーガーで作成してクラウドサーバにアップロードまでは実施しておいた。

初めて訪れた福岡・中洲でやったことはプログラミング・・・

2014-06-15 ビジネスモデル開発&MVP作成&発表

イテレーション#04

イベント最終日、16時からアイデアを発表するのでリミットは8時間。ここで前日の収益問題を解決するためソリューションを構築するため再び価値提案のピボットと顧客セグメントのピボットを実施。
時間的にもこれ以上の変更を実施する余裕は無いのでソリューションをありきでビジネスモデルを再構築。
はたして発表に間に合うのか?

Build

プランAを文書化する

ターゲット顧客に関してはこれまでキーワードとなってきた高齢者にフォーカス。イテレーション#03で対象とした不登校児はスコープから完全に外す。
収益を得るためのソリューションとして孤独なお年寄りの話を聞いてあげて年表を作るアイデアをベースにリーンキャンパスを構築。

  • 顧客セグメント
    • 話相手のいないお年寄り
  • 課題
    • 話相手のいないお年寄りは自分の話を聞いていほしい
  • 価値提供
    • お年寄りの孤独をなくす

Mesure

プランで最もリスクの高い部分をみつける

残り時間があまりないこともありソリューションの鍵となる課題である顧客リスク『お年寄りは本当に話し相手を必要としているのか?』にフォーカスして検証を実施。
具体的な検証としては付近の老人ホームへ電話インタビュー実施した。

Learn

プランを体系的にテストする

電話インタビューの結果『話し相手を必要としているお年寄りはかなりいるようだ』という結論に達したのでソリューションとして『学生アルバイトがお年寄りとお話をして年表をつくるサービス』を構築することにした。

ソリューションを決めた時点で残り時間は5時間だったので前日に作成した予告サイトをベースに3時間でマーケティングサイトと測定プログラムを作成した。
マーケティングサイトで検証したい内容は以下の3つ

  • コンセプト
  • サービス内容・対象
  • サービス価格

マーケティングサイトのサーバアップロードと簡単なテスト実施後に各メンバーのFaceBook,Lineなどソーシャル・ネットワーク経由で検証依頼をしてもらった。
結果として2時間で100件近くのフィードバックを得ることができた。GoogleAnalysticsで測定していたのがピーク時で毎秒10アクセスあった。正直ソーシャルネットワークでここまでの数字が出ると思わなかったので少し感動した。

ちなみにソースコードはここ
システムはSinatraを採用、サーバーホスティングにはHerokuを利用。

そして、マーケティングサイトをそのままプレゼンに使用して結果発表。結果としては十分ではなかったかもしれないが8時間で何とか形に出来たので良しとしたい。しかし、マーケティングサイトの検証結果を元にあと2回ぐらい学習ループを回せていたら・・・と思うと少し残念である。

まとめ

優勝したチームと特別賞をもらったチームの特徴として

  • ベースとなるアイデアが初日からぶれていない
  • 実際に動くプロダクトをプレゼンしている

という2点があったので参考としたい。

結論としては『スタートアップウィークエンドは面白い!』である。
次回の福岡イベントは11月だそうだが是非参加したいと思う。

参考リンク

参考文献

Author: k2works
Link: https://k2works.github.io/2014/06/16/2014-06-16-startup-weekend-fukuoka/
Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.