約 100 のプロジェクトに見る、超初期のスタートアップの成功パターン、失敗パターン
この一年、100 個ぐらいの学生の技術系サイドプロジェクトを傍で見てきました。その中で見えてきたいくつかの成功と失敗のパターン、そして失敗パターンを極力踏んでもらわないようにするためにやってきた対策（とその失敗の歴史）を、ほんの一部ですがまとめておきたいと思います。
今回は「アイデア」と「行動」のパターンを紹介します。以下は各項目のリストです。
- 十分なサーベイをしているかどうか
- とにかく雑に作る
- 何回もプロジェクトをやっていると強くなる
- アイデアがないならインプットをしよう
- 行動量がすべて
- いま、会いにゆきます（顧客に）
- いま、会いにゆきます（チームに）
- メンタリングにちゃんと来て Ask する
- 規律とリズムが大事
- プロセスを信じてください
- このアイデアは勝てるかも感
- コミュニケーションの量と質は先行指標
- 役割分担はしないほうがいい
（追記：もっと減らすべきでした…。10, 11, 13 あたりは抜いてもいいかもしれません）
「アイデア」の成功と失敗のパターン
1. 十分なサーベイをしているかどうか
先日のインタビューでも言及しましたが、面白いアイデアを持ってくるグループは、きちんと過去の取り組みをサーベイしている傾向にあるように思います。
「これまでのものはこうだったけれど、今回の我々のプロジェクトはここが違います」という風に、過去の取り組みと自分たちが何が違うのかを説明できるグループや、「とにかくこれが不便で、探してもこれを解決する手段がないんです」といったグループがそれに当たります。Why This, Why You, Why Now に答えられるグループ、と言ってもいいかもしれません。
できればその上で「で、将来はこうなるだろうから、今回のこのプロジェクトです」と、自分たちの言葉で言えればさらに良い感じです。ただ、そうした将来洞察の言葉やビジョンはメディアの受け売りの人も多いので（私も他人のことは言えませんが）、自分の体験や考え、あるいはなんだかよく分からない強度のパッションやビジョンから来ているかどうかでも結構変わってくるように思います。
こうした新規性を探すサーベイは学術分野では当然のことですが、意外とプロダクトとなると忘れてしまいがちのようです。ただ地頭が良ければ、サーベイをするだけでもレッドオーシャン的な領域から抜け出ることができそうなことが何となく分かりました。もちろんレッドオーシャンを泳ぎきった後にある（であろう）ブルーオーシャンを狙うのも一つの戦略だと思いますが、学生でその領域を狙うのはあまりお勧めできないかなと…。
そうしたサーベイをお手伝いするために書いたのが Web サービスのサーベイ手法の記事です。これは各種スタートアップにも使えるのかなと思います。
その他、お茶の水女子大学の伊藤先生のサーベイに関するスライドや、筑波大学の落合陽一先生の論文サーベイフォーマットのようなものもお勧めしています。（まだスタートアップ用のフォーマットなどは作れてません…）
今現在は、サーベイがきちんとできているかどうか、そしてその上で自分たちの中で今回のプロジェクトが歴史の上でどのようなポジションにいるかを整理できているかどうかを確認するために、逆張りワークショップなどをしています。事前に「競合を調べておいてください」という宿題は出すのですが、当日どれだけ競合のポストイットを張り出せるかの量と、どういうマッピングになるかで、サーベイできてるかどうかは大体わかります。
数年前は学生が思いつきのアイデアでアプリを作り、それがウケたりしたことがありました。Raspberry Pi などを使ってちょっとだけ新しいことをするだけでも注目を浴びて、メディアアート展などに出せば、それが次の作品制作のモチベーションになることもあったそうです。今はそうした low hanging fruit があまりないので大変だとは思いますが、考えればまだまだ色々やれることはあるので、そのためにもサーベイが大事かなと言う結論になっています。
ただそうしたサーベイをした上で、いい感じにレールから一歩踏み出す良い手法はまだ分かっておらず、その一歩に関してはまだまだ課題です。
2. とにかく雑に作る
角さんの記事に全面的に同意するのですが、やはりプロトタイプ第一号をすぐに作るチームの進みは早いように思います。そして作っている中でアイデアも多少変わっていき、それが良いアイデアに繋がるように思います。
しかし多くのチームはすぐに手を動かしません。手を動かさないのは、
- 実装力があまりない（自信がない）
- 「とにかく雑に作る」ことへの心理的なハードルがある
- 素早く作るためのツールセットに心当たりがない
- プロトタイプは何個作ってもいいんだという感覚がない
といったあたりが原因かなと感じています。
実装力があるチームは一歩踏み出しやすいようです。実装力は筋トレのようなもので、これまでの日々にどれだけやってきたかで変わります。ただ一部のチームは実装力があるが故に考えすぎてしまうこともあります。ここの塩梅は難しいところです。
また国内で Design Thinking の手法を学びすぎている人は議論が多くなりすぎてしまう傾向にあるようで、議論でも Design Research でもなく、Design “Doing” に移ってもらう、一歩を踏み出すための何か、というのは悩んでいるところです。
3. 何回もプロジェクトをやってると強くなる
当然といえば当然なのですが、プロジェクトを何回も何回もやっている人がいるチームは、プロジェクトの進め方がうまい傾向にあります。分水嶺は 3 回ぐらいでしょうか。これは仮説どおりでした。
このため、プロジェクトは複数回やってもらうことを前提とした設計としています。最初に作るのは Web サービスなどがサイクルが短くていいなと感じています。ハードウェアは調達が絡むので、どうしてもサイクルが長くなりがちです。ただ Web サービスは大概やりつくされてしまっているのでなかなか難しい…という課題もあります。
何回もプロジェクトをやっている人はお金と時間の使い方がうまくなってくるように思います。特にお金を使って時間を短縮する方法といいますか。シリアルアントレプレナーが強いのはこのあたりかなと。
失敗してもいいから何度も挑戦すること、これを伝えるのはとても難しいのですが、これを繰り返してもらうことで確実に伸びていく手応えはあります。あとはこのサイクルをどう早くするかが課題です。
4. アイデアがないならインプットをしよう
多くの場合、アイデアがないのは圧倒的にインプットが足りないからです。そんなときには強制的にインプットする必要があるので、サーベイをするプログラムなども実施しています。
最終的には日々どれぐらいニュースや新製品を見ているか、というところに至ります。できれば欧米の技術ニュースや経済や社会系の情報もです。RethinkDB の人も言っていましたが、「The Economistを本気で読め。あなたをより早く成長させてくれるだろう」です（by RethinkDBはなぜ失敗したのか）。
ただ英語を読め、というのはハードルが高いので、Hacker News の日本語翻訳をやっています。雑な翻訳でも、英語タイトルよりはざっと見やすくなるのでは…という考えで作ったはいいものの、Make Something People Want できていないせいか、見てもらう習慣を作ってもらうところでは失敗しています…。
あとイケてる新製品のビデオを Youtube リストにまとめて、Fire TV Stick のアプリから 50 インチのディスプレイに流していたこともあります（ただ「ディスプレイは見てない/邪魔」と判断されて撤去されました…）。
以上がアイデアのパターンについてです。
「行動」の成功パターン、失敗パターン
5. 行動量がすべて
もちろんスマートにやることも重要なのですが、正しい方向さえ向いていれば、あとは行動量の勝負になりがちだなと感じています。そして行動量は意外と言及されない項目でもあるなとも思います。
明らかに疲れることや嫌なこと、自分の手を汚すことでも、さっとやってしまうチームの進みは本当に早いです。これは Paul Graham も書いているとおりでした。
6. いま、会いにゆきます（顧客に）
もうこれは何度も何度も言われていることですが、とにかく顧客のところに行くチームが強いです。「顧客に会いに行くことで開発のスピードが遅くなるんじゃ…」と思われるかもしれませんが、顧客に行っているところのほうが開発のスピードも早い傾向にあります。結局プロジェクトへのコミットの量の差、と言ってしまえばそれだけなのかもしれませんが、顧客と話すことでモチベーションアップするところもあるのかなと思います。
あとはその顧客に行くのが「今日か明日」といったスピード感かどうかが、成否の分かれ目にになっているように思います。
たとえば「明日インタビュー相手のアポを取れるみたいですが、どうしますか」と聞いたときに、「ぜひ！」と言って翌日に行くか、それとも「準備があるのでちょっと待って下さい」と一週間後にするかで、プロジェクトが出来上がるものも随分違うなという印象があります。
結局は小さな積み重ねがプロジェクトを進める、ということなのかもしれません。その積み重ねをどれだけのスピードでできるか、というのが初期のプロジェクトの成否には関わってくるのだなという実感がありました。
ただインタビュースキルがないと、自分の仮説を確証するような情報ばかりを集めてしまうので、ここは物凄く難しいなと思ってはいます。顧客インタビューのフレームワークとかを提示してもあまり効果がないケースも多く、課題として残っている部分です。
7. いま、会いにゆきます（チームに）
チームが一緒にいるかどうかはプロジェクトの成功を左右するほどに超重要です。本当に。これはもう間違いなく。
もちろんプロフェッショナル同士の人やタスクが既に分解できてる場合は、リモートでもいいかもしれません。ただ最初は方針が変わりやすければ、要件も変わりやすいので、一緒にいて、暇な人がいてもいので、いわゆるフロー効率性を重要視するのがいいというのは実感しました。
そのためにはチームが一緒の場所に居て、コミュニケーションすることが重要です。
ただ…もちろん授業やバイト、研究室などがあるので四六時中一緒にいることはできません。そこはもう、チームが一緒に入れるかどうかはリーダーの巻き込み力が問われるところです…。あとはみんなが来たがる場所にできていないのは私の力不足ですが、ここを解決するのはネットワーク効果なのかな…と思っています。
8. メンタリングにちゃんと来て Ask する
行動量があるかどうかに関わってきますが、メンタリングの回数が多いチームほどプロジェクトはうまく進んでいるように思います。もちろんメンタリングのたびに進捗を持ってきているので、メンタリングを勇んで受けられる、というところもあるのかもしれません。
誰かに何かを依頼する、というのは怖いことですが、その怖さを乗り越えてでもやりたいことがあるかどうかの反映なのかなと思います。と書いてると、自分にも言葉のブーメランが刺さって痛いです…。迷ったらすぐ相談！ですね。とにかく Airbnb の 3 人もメンタリングを受けまくっていたようです。
とはいえ強制的にメンタリングを受けてもらう、というのも重要な仕組みで、海外の某アクセラレータではそれを徹底するために、メンターの時間を調整して必ず来てもらうようにする人が雇われていたと聞いています（もちろんその他の業務もやってたみたいですが、主にメンターとの時間調整が仕事だったようです）。このあたりのオペレーションの徹底はまだできていないなと思います…。
9. 規律とリズムが大事
先日日経BPの中田さんのシリコンバレースライドがバズっていましたが、規律やリズムがあるかどうかはプロジェクトの進捗に大きく影響しているように思います。後述する「プロセスを信じる」という部分にも通じるかもしれません。
たとえば、「毎週月曜日のこの時間帯は全員集まる」とか「週末は Airbnb で一軒家を借りて開発合宿をする」といったチームは確実に進捗が出ています。
論文もそうなのですが、インスピレーションを待つよりも、定期的な予定を持つほうが圧倒的に生産性は良くなります。
とにかく定期的に作業して、定期的にプロダクトをアップデートしたりリリースしたりすること。それが結果的にモメンタムを生み出して、スタートアップ的なプロジェクトがうまくいくのでは、というのが気付きです。
スタートアップにこそ規律が必要、というのは反直観的なところかもしれません。そしてその規律やリズムを生み出す人がチームにいるかどうかが、チーム全体の実行力を上げるのかなと。
こうしたオペレーションは徹底するのが難しいのですが、そういうときにハスラーがいるチームは強いな…と思います。
10. プロセスを信じてください (Trust the Process)
『創造するちから』によれば、ピクサーの二つの原則のうちのひとつが「プロセスを信じよ」だそうです。これは本当にそうだなと感じています。
用意しているサイドプロジェクト支援のプロセスはこれまで書いてきたような失敗と反省の繰り返しから、極力うまくいくように支援するために色々趣向を凝らしています。
もちろんこのプロセスに乗らなくてもいいのですが、乗らないのなら乗らないなりの理由があってほしいな、というのが思いです。そこは参加者を説得できない私の力量不足でもあります。
もちろん、色々新しい挑戦をプロセスの中に仕込んでいるので、プロセスは常にどこか壊れていて、完璧ではありません。あるいはプロセス自体に透明性がないので信じてもらえないのかもしれません。そうしたところは改善していくべきポイントだなと感じています。
11. このアイデアは勝てるかも感
「このプロジェクト、イケてる、勝てる」という感覚をチームメンバーが全員持っていることは大事だなという話が上がりました。そういうチームは一気に物事を進めます。これは Peter Thiel の言う、ややマイルドなカルトなチーム、というところにつながってくるのかもしれません。
そのためにもアイデアの選定が重要だな…と思うのでした。
12. コミュニケーションの量と質は先行指標
端的に言えば、Slack のコミュニケーションの量でそのチームのプロジェクトの出来が分かったりします。実際、チームの間のコミュニケーション量や、コミュニケーションの質はプロジェクトの成否の先行指標になっている気がします。特に、
- ハスラーがいるかどうか
- ちゃんと場所に来るかどうか（一箇所で作業しているかどうか）
- Slack 上での会話量は十分か
あたりは重要なのかなと。そしてそのための仕掛けをきちんと用意しておく必要があるのだなと思います。
あとは、自分たちしか分からない言語を作っていたり、役割分担せずに全員で一緒の課題に取り組んでいたりすると、コミュニケーションの質という部分では良い傾向です。また、ちょっとした進捗でも「すげー！！」って驚いてくれる人がいたら、そのチームは雰囲気良くなります。感情表現豊かな人はハスラー向きです。
個人的にはハスラー、特に進捗のリズムを作るハスラーの重要性を感じたのが「行動」の部分での大きい気付きでした。
もちろん私のようなプログラム側の人間は、こうしたコミュニケーションを引き出すような設計をしなければならないのですし、アイスブレイクの手法なども試すべきだとは思いますが、そもそも「場所に来ない」という問題をどう解決すればいいか…というのは研究室と同じ悩みです…。
13. 役割分担はしないほうがいい
コミュニケーション量やフロー効率性のところと関わるのですが、役割分担は基本やらないほうがいい傾向にあります。
役割分担すると個別作業が多くなってコミュニケーションが少なくなります。また役割分担した瞬間に、とある人に一気に作業負荷がかかって、あとはその人のやる気が続くかどうかというところにプロジェクトの脆弱性が集中しがちで、フロー効率性が悪くなる印象です。
役割分担をしたほうがそれぞれの機能が早く開発できるように思いますが、大抵それは間違いのようです。すくなくともモメンタムが在るのは、役割分担をあまりしていないチームでした。もちろんプロであったり、要件が固まってれば分担したほうが早いことも多いと思うのですが。
実装力がある人でも初めての領域であれば「この技術を学んだことがないから…」と遠慮して役割分担してしまいがちです。でも「まあ勉強すれば技術なんてなんとかなるでしょ」という気構えで、全員で一緒に機能を開発したほうが良いのかなと思います。というかそういう学ぶ姿勢を持つ人を集めましょう、というチームの話になるのですが。
まとめと前提
以上が今回共有する気付きです。
なお、今回ベースとなったプロジェクトはスタートアップとは異なる点があります。それは以下のような点です。
- 超初期のプロジェクトであって、スタートアップではない
- フルタイムはほとんどなくて、サイドプロジェクト（しかも学生）
- 1プロジェクトの期間は短め
- 基本的に起業はお勧めしていない
ただ通常の『アクセラレータ』や『コワーキングスペース』とは異なる良い点としては、
- だいたい傍で見ている（傍でやってくれているプロジェクトは）
- 応募段階でアイデアはある程度スクリーニングしてある
- サイクルが早い
- ハードウェアとソフトウェアは半々ぐらい
というところでしょうか。
どちらかというと研究室に近いのですが、研究とは異なり、「人が欲しがるものを作る」というところは徹底しています。なので、メディアアートなどは基本今回のインサイトの対象に含まれていません。
また何かを認識するためには理論や枠組みが必要であることを考えると、私の認識は大いにリーンスタートアップや顧客開発、Paul Graham 的な視点が入ってしまっていると思います。その点はご了承ください。
なお、私が今回支援させていただいた技術プロジェクトのアイデアは「一見不合理に見えるけれど、最終的にはスタートアップに繋がるかもしれない」というものだけです。ただまだ成長途中の学生の皆さんのプロジェクトであり、期間もたかだか一年です。
成功と言っても、今のところうまく進んでいるものや、コンテストで入賞したプロジェクト、区切りがついたもの、といったような成功の程度です。学生の皆さんにとっては一つの大きな功績でも、社会人の皆さんにしてみれば「それは成功とは言えない」と思うかもしれません。
とはいえ、スタートアップや新規事業も最初は単なる『プロジェクト』です。こうしたプロジェクトの成功と失敗のパターンからは、スタートアップの最初の二ヶ月をどうやってうまく進めるか、といったところで、何らかのインサイトを提供できるかもしれないと考えています。特に「スタートアップの数が少ない」というボトルネックを解決する上で、超初期のプロジェクトの成功確率を上げる仕組みやインサイトには価値があると思っています。
こうしたリターンが出づらい取り組みは VC 等では行いづらく、公共に近い領域でしかしづらいと思っています。だから今の取り組みが続く間（＝大学への寄附金が続く間）、これらの成功確率を上げるための取り組みを引き続き行って、そこからのインサイトを社会に還元していければと思っていますので、どうぞ宜しくお願い致します。
