2013年11月22日〜11月24日の3日間、Startup Weekend Tokyo(以下SWT)に参加してきました。
そこでの経験、思ったことなどをつらつらと振り返ります。
まずは、感謝
まずは、このSWT開催に尽力してくださった羽渕さん、松本をはじめとするOrganizerに感謝です。
3日間参加者が、サービスを開発することに集中できたのも、Organizerの方々の準備・当日の進行があったからです。
このような機会を通して、日本のStartup文化を育てていく姿勢はただただ、尊敬します。
私も是非機会あれば、次はOrganizerとしてお手伝いできればと思っています。
本当にありがとうございました。
目的
さて、私が当初このSWTに参加した目的は自分の技術力の客観的評価
でした。
自分がエンジニアとして何が優れていて、何が足りていないのか、他のエンジニアと開発を通して確認できればと思っていました。
結果
しかし、その考えて方は間違っていました。そもそもSWTをハッカソンの類みたいな感覚で認識していましたが、全然違っていたのです。
語弊があるかもしれませんが、一言で新規サービス立ち上げを皆でやる
会です。
SWT自体はサービス立ち上げの後押しをしてくれるイベントです。
当初の目的を達成するには、ガチなハッカソンを見つけてそちらでやる方がいいです。
STWの開発者に求められるもの、試せるスキルは総合的な開発力
と開発スピード
、ビジネススキル
でした。
SWTでは、大きくHustler(企画提案者)、Designer、Hackerで構成されます。
- Hustlerがピッチ(企画発表)する
- 良いと思ったところへDesigner、Hackerが参加してグループを構成
- 残り時間で企画を実サービスへと具現化する
総合的な開発力
私はフロントエンドエンジニアですので普段の業務ではサーバサイドの開発はしません。
サービス開発には企画内容にもよりますが、サーバ側の開発が必要になる場合があります。そのときは、
サーバ側はできないと一蹴するのではなく、必要最低限の部分だけでも実装してMVP(minimum viable product)へと形にする必要がSWTではでてきます。
私の場合は、勉強の為プライベートでheroku上にnodeアプリを開発している程度でしたが、これが功を奏しました。
当日はheroku上にフロントのsencha touchアプリと連携するチャットアプリをnodejs + express + socket.ioで構築しました。
このようにどのような開発者が一緒になるかもわからないので、できることは何でもやる必要があります。
サーバサイドのエンジニアやDBエンジニアもhtml,css,jsを書かなきゃいけなくなります。(また逆もしかり)
開発スピード
企画を揉んでからの開発になるので、3日間の上で開発に専念できるのは、20時間くらい(徹夜)かと思います。
その中で、MVPを作りあげるには、BestではなくBetterなものを早く作り上げる必要があります。
ビジネススキル
ハッカソンとは違い、サービス企画を一緒に練り上げる必要があります。
一人モクモクと開発に専念することもできますが、それはSWTの目的ではありません。
そのサービスにマーケットはどのくらい存在するのか、ターゲットユーザは誰なのか、
MVPとして作るものには何が必要なのか、積極的に議論に参加しないでいると
言われたモノだけ作って、結局、だれも使わないもの(ターゲットが欲してないもの)になりかねません。
思うこと
色々書いて来ましたが、サービスを作り上げる
ことは自分にとってとても面白いことだと再認識できました。
是非他の人にも参加してほしいと思うイベントなので、次参加する人へのアドバイスも下記にちょっと載せておきます。
ハッカソンでもアイディアソンでもない
上記の通り、ハッカソンではないので開発者は作るのみ
ではありません。またアイディアソンでもないので、面白そうなアイディアだけ
でもだめです。
実現可能でかつ社会の何かしらの問題を解決できるサービスで、収益化が見込めるものをチームで考えらる人、考えたい人が参加するといいと思います。
準備も必要
当日チームを組むので場当たり的なイメージもありますが、そんなことはありません。
Hustlerは企画を練っておけるし、Designerは早くデザインを上げるためにテンプレートみたいなものを作っておけるでしょう。
Hackerはサーバ構築を早く行うためにインフラ周りを調べておくこともできると思います。
今回私は、heroku使ってサーバ構築をすぐ終わらせることができました。コレも準備していたことです。
良ければ参考にしてください
また、SWT全体をとおして、リーン・スタートアップという考え方は重要になってきます。
知らないで参加すると、特にHustlerとのコミュニケーションやSWTの進め方のイメージがつかめなくなるので、是非読んでから参加することをお勧めします。
※ 例えば本記事内のMVP
や顧客開発
、ピボット
またリーンキャンパス
とか聞いた事ない人は必読で。
顧客開発はちょー重要
企画が決まると、顧客開発といって、ターゲットユーザに当たる人にインタビューしたり、アンケートしてもらったりして、企画の有効性を確認します。
google docs使ってのアンケートも有効ですが、できればちゃんと対面でインタビューした方がよさそうです。
文字ではわからないユーザの反応がいいFBになったようです。
※ 私はこのタイミングで開発していたのでちゃんと参加できなかったのが心のこりでした。。。。
ピボットを恐れない
顧客開発を進めていくと、やっぱり、もともと考えていたAという問題を顧客は抱えていないのではないか、だとするとこのサービスはそこまで使われないのではないか
という方向転換を迫られるようになります。
個人的には、顧客の意見を尊重して方向転換を実施してもいいと思っています。この方向転換をピボットといいます。
もともとの案に縛られすぎると、使う人が少ないサービスに一歩近づいてしまいますからね。
私達のチームも1度大きなピボットを行いました。
ランディングページはちゃんと作る
開発のスピードは重要と述べましたが、だからと言って、なんでもかんでもスピードを求めていいわけではありません。
SWTの序盤、企画が固まってきた段階で様々なチームが、launchrock.coやcomingsoonersのようなサービスを使って、ランディングページを作りました。
そのページには、サービス名
とキャッチコピー
、とメールアドレス登録フォーム
があるのみでした。
それらのサービス自体を否定するつもりは無いですが、少々お粗末な感じがしました。
本当に使ってほしいのであれば、
- サービス概要
- 機能詳細
- メッセージ
- 紹介ビデオ
等々、もっとちゃんと情報を載せるべきだと思います。それがあってはじめてユーザはサービスを理解し、共感してくれた結果、登録してくれるはずです。