LoginSignup
27
11

More than 5 years have passed since last update.

Startup Weekendに3回参加して得られた失敗

Last updated at Posted at 2016-12-03

この雑な文章は、Startup Weekend Advent Calendar 2016 の3日目の記事です。
(ちょっとだけ遅れてしまいました... すみません。しかもあとでちょっと書き足したい!)

私と Startup Weekend について

私は今社会人2年目、いつもはWebエンジニアとして開発をしています。

Startup Weekend との出会いはかれこれ2年半前くらいで、初めて参加したときは大学3年の頃。
それから今年に入って2回参加し、つい先月オーガナイザーとしても関わり、色んな体験、経験をさせてもらいました。

私が参加したのは以下の回です。

  • Startup Weekend Tokyo UNI 2014/5/23-25 (1回目)
  • Startup Weekend Tokyo Women 2016/3/4-6 (2回目)
  • Startup Weekend Tokyo Healthcare 2016/9/16-18 (3回目)
  • Global Startup Weekend Tokyo 2016/11/18-20 (オーガナイザー1回目)

Startup Weekend を一言で言うと「金から日曜日の3日間、54時間で起業体験するイベント」...なのですが、
貴重な土日は丸々潰れてしまうし、次の日は仕事だし、しかも参加費はおよそ1万円、と初めて聞く方は参加を迷ってしまうかもしれません。

それでも私が Startup Weekend に3回も参加し、オーガナイザーにまでなってしまったのはなぜかと言うと、
とにかくこのイベント、参加者に「失敗体験」を残すことのできる、非常に良い場として設計されているからです。

私の周りにも、何人か Startup Weekend に興味を持ってくれている方がいらっしゃったので、今回は私が参加者として得られた「失敗」についてご紹介できたらなと思います。
こういう体験した人がいるんだなーという気持ちで読んでいただけたら幸いです。

(3日間の流れについては割愛しますので、詳しく雰囲気を知りたい方はこちらのブログ記事などを参考にしてください)

1回目の失敗: 作り込みすぎの MVP

ハッカーとして

始めて Startup Weekend に参加した頃の私は、ちょうど「自分でサービスを作りたい」と思い始めた頃で、何度か学生向けハッカソンに出ては中途半端なプロダクトを作っては捨てて、という大学生でした。
Startup Weekend は、ハッカソンの延長のような感覚で参加を決めました。

もちろん、当日はハッカーとして参加しました。

Startup Weekend には、ハッカー・ハスラー・デザイナーの3つの役割があります。
ハッカーとしての役割は、MVP(Minimum Viable Product: 必要最小限の製品)を作ること。目的は、そのアイディアに対して顧客がいるのかどうか、検証するため。

参加者はハスラーを選ぶ人が多く、相対的にハッカーは数が少ないため、3日間を通じて「サービスを形にできる人」としての期待を寄せられる役割です。
私もエンジニアとして力を発揮したい、その期待に応えたいという思いが強くありました。

そこで1日目の夜にチームが決まってからすぐ、Railsで実装することを決め、DB設計や画面設計、環境構築とただひたすらに手を動かしていました。

コーチからの一言

「MVPだから機能は制限する、でもMVPだからとはいえ、きちんと動くものを作りたい」

そう言って徹夜でMVPを作っていた私ですが、一方で仮説検証は、MVPの完成を待つ形になります。
さらに、2日徹夜したとしても、MVPを利用可能な状態まで持っていくのは厳しいということも段々と分かってきました。

そして、2日目のコーチングでズバリと言われました。「その検証ならブログでもできるよね?」と。

その瞬間、「今作っているものはMVPじゃない。検証のためなら、必ずしもWebアプリケーションまで作る必要はないんだ」とはっと気付きました。
極端を言ってしまえば、ブログでも、ランディングページでも、動画でも、モックアップでも、そのサービスの価値をユーザが体験できれば何でもいい。
ユーザにとっては「本物の機能があること」よりも「本物の体験ができること」の方が重要だから、と。

以降はWordPressで、簡単なサンプルページを作る方向性に転換しました。
一からRailsで実装するよりもずっと早く完成して、その分、検証に必要なコンテンツを揃えることに力を入れることができました。

技術はあくまでも目的に対する手段

ただ自分の作りたい思いを優先して、作り込むことにばかり注力し、顧客検証という本来の目的を見失ったこと。その結果、時間という貴重なリソースを多く失ったこと。
技術はあくまでも目的に対する手段であることを、改めて痛感した3日間でした。

2回目の失敗: 顧客を見つけられない

解決したい課題がブレていく

2回目の参加をしたのはそれから2年後、社会人になって1年経った頃でした。
Webエンジニアとしての何でもいいから一歩進みたい、その糸口にしたいと、再び参加しました。

死ぬほど緊張しながらアイディアピッチに挑戦して、コミュ障を発揮しつつも何とかメンバを集めて、チームを作ります。
始めのアイディアはとても小さいものですが、チームで話していくうちに少しずつ形になっていきます。

でもある程度話すと分岐点や行き詰まりや新たな展開が起きます。
「それはこういうものにも使えそうじゃない?」「それはこういう人にもいいんじゃない?」

話がどんどん拡散されていって、気づけば「顧客って誰なんだっけ?」「課題ってなんだっけ?」ということになります。
そういうとき、一番重要となるのは、そのアイディアを考えた時の自分の気持ちではないかと思います。

自分の欲しいものが一番ブレない

アイディアは自分自身の中からしか生まれないもので、発端のすべては自分です。
だからこそ、「自分ならこのサービスを使いたい」と思い続けられること、自分自身が最初のユーザとなってサービスを作り上げることが、始めは一番良いと思っています。

「私をユーザにしてください。私が欲しいものを作ってください」

チームの方向性を定めるためにも、私は自分が指針となる、自分が最初のユーザになることを決めました。
それを宣言するのは少しだけ勇気がいりましたが、チームの皆も私を信じてくれました。

顧客を探し出す

でも自分だけが喜ぶサービスでは意味がなく、それが欲しいと言ってくれる人を見つけなければいけません。

私たちのチームはその課題を持っているかどうかのアンケートを作り、Facebook経由で知人に声掛けをして、回答してもらうことにしました。
チームの努力で数十名のアンケートが集まり、それを発表資料としてまとめ、練習を重ね、発表まで何とか持っていきました。

懸念点は残っているけれど、できる限りことはした。
そう思っていましたが、あるチームが発表したとき、衝撃を受けました。

「私たちは、このアイディアをターゲットとなる店舗に見せにいきました。その結果、3店舗が喜んで導入すると言ってくれました」

そのチームは、私たちよりも圧倒的に行動していました。
建物の外に出て、自分たちのアイディアを直に顧客に見せ、そしてお金を払ってくれる顧客を見つけ出す。同じ3日間なのに、本当に起業しそうだと思えるような勢いがありました。

同時に、検証の大切さは身に沁みて感じていたはずなのに、という強い敗北感を感じました。

さいごに

Startup Weekend には、とても良い「失敗体験」を心に残す場であると、私は思っています。
例えばそれは、アイディアピッチであったり、チームビルディングであったり、コーチからの鋭い指摘であったり、ユーザからの思いがけないフィードバックであったり、他チームの発表であったり、審査員からの評価であったりします。

私は3日間の最後に悔しい思いをしなかったことがありません。

でも悔しい思いをするのは、この3日間に本気になれた人たちだけです。
本気になって、それでも届かずに悔しい思いをすればするほど、「次はやってやるぞ」という気持ちになる。
そして次は本当にやってしまう。それでもまだ届かないものがあって悔しくなる。
そういうものだと思うのです。

次の Startup Weekend Advent Calendar 2016 の4日目は、Yuji Imagawa さんです。
よろしくお願いします!

27
11
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
27
11