偶然と出会う確率を上げる

おはようございます！
三井滉平です。

demmpaという会社で、個人のキュレーションメディア「knower（ノワー）」を運営しています。リンク＋コメントで簡単にあなただけのまとめを作ることができるサービスです。

▼サービス詳細はこちら
https://hello.knower.jp/

今日はあいにくの雨ですね。雨の日はちょっとだけテンション下がるので、雨の日ならではの楽しみを探したいと思う今日この頃です。

さて。
今日は【偶然と出会う確率を上げる】というタイトルで、スタートアップって未知の連続で、やっぱり正解がないんだなという想いと、じゃあどうやって行動していけばいいんだろう、みたいなことを書いていきます。

スタートアップの旅

僕自身、まだまだ1年ほどしかスタートアップをしておらず、成功もしてない立場なので、スタートアップを語ることはできませんが、体感として感じてきた事はあります。

「ああ、スタートアップって不確実すぎる旅なんだ」って事です。

僕よりも何十倍も経験や知識がある起業家の方や投資家の方にお話をお聞きしても、全く同じ事業で状況なのに、するアドバイスは180度違ったりします。正解がある世界であれば、こんな状況はありえないです。

例えば、受験の世界で、とある問題の答えを聞きに行ったとき、学校の先生と塾の先生が全く違う答えを言うことってないですよね。多少のプロセスの違いはあれど、答えは常に一つです。

勉強だったら自分より経験値の高い人に答えを聞けばやっていけたんですが、どうやらスタートアップの世界に画一的な正解はなさそうです。というか、正解があるんだったらみんな成功してるなと改めて思いました。

一応、リーンスタートアップなどの王道ルートはあれど、細かい時代背景や創業者が持つ影響力や資産など要因もあり、一概にこのルートを辿れば、、と言うものはなさそうです。そう考えると、特にC向けのサービスが成功するのは一定”偶然”だとも思います。

ただ、”偶然”なのであれば、誰がその事業を行っても成功確率は同じかというと、それは全然違います。連続起業家など経験がある人が行う事業の方が成功確率が高いのは事実あるはずです。

多分、スタートアップは「”偶然ハマる瞬間”までいかに早く辿り着けるか」なんだと思います。

“偶然”と表記すると当てずっぽうみたいですが、もちろんその裏には論理があり、仮説があります。ただ、最終的にはユーザーに使ってもらわないとわかりませんし、改善をしてみないとわからない領域があります。なので、いかに仮説の精度を上げ、いかにユーザーに早くあて、いかに1事象からの学びを深くし、”偶然ハマる”まで辿り着けるか、だと思うんです。

仮説検証しながら学習し、学習回数が大事な、知恵の輪みたいな。（本当にすごい人は見ただけで解けちゃうらしいのですが、普通の人は試行回数で学習していく気もするので、イメージとして。）

どうしたら”偶然”と早く出会えるか

スタートアップは「偶然ハマる瞬間までいかに早く辿り着けるか」だとすると、やるべきことは大きく3つで、その繰り返しかなと。

①仮説の精度を上げる
②素早くリリースする（ユーザーに早く当てる）
③学習効率を最大化する
→①に戻る

言葉にすると単純なんですが、これを実行するのがまあ難しいわけです。（そして、新しい発見をしたぞ！みたいなテンションで、この①~③を書いてますが、これは色々なところで書かれまくってる当たり前すぎることですよね、、。）

個人的に、一番大事なのは「①→②」だと思ってます。

と言うのも、①の仮説の精度を上げることや、③の学習効率を最大化することは、スキルや経験にも依存することがあり、結構難しいからです。加えて、①の仮説の精度なんて、そもそも経験がない世界の事業に飛び込んでいくことが多いので、最初のうちは当てずっぽうで進むしかありません。とにかく回転数が一番大事で、それによって①と③の能力も向上していくはずです。

なので、「①→②」が高速になれば、全体のサイクルも高速になっていきます。方向性は見えてきたので、もう少し動き方が明確になるようにステップを分けてみようと思います。

knowerとしての今後の動き方

大きく分けると上で書いた①~③ですが、もう少し自分たちの動きを考えながら実践的に書き換えてみようと思います。

1、仮説を立てる
2、デザインに落とし込む
3、実装する
4、リリースする
5、データを見る
→1に戻る

この1~5です。このサイクルを早くするには、僕の中で大事だと思ってることがあります。

✔️サイクルを早くすること（試行回数が多いこと）が一番大事だと共通認識が取れる
✔️ある程度の担当範囲を決め、信頼し合う（=議論からの脱却）
✔️全体戦略の共通認識がある（今何を改善しようとしていて、その先に何があるかがわかっている）
✔️死ぬ気で働く

この4つですね。

1つ目はわかりやすくて、4つ目も気合い作戦（物理的な時間量でサイクルを早めよう！）なので、置いといて、2つ目と3つ目をもう少し深ぼっていきます。

結局のところ、組織のスピードだけを考えるのであれば「独断で進めること（議論しない）」が一番良いです。独裁がスピード感的には一番ありますよね。ただ、独裁にしすぎると意図を汲み取った修正が効かなくなり、指示以上の結果が出なくなります。

なので、部分独裁で「担当者や責任範囲を決める事」と、「今向かう先と背景をそれぞれが知っている事」が重要だと思っており、その整備と共通認識、お互いへの信頼があれば回っていくと思ってます。

なので超直近で「サービスビジョンの言語化」「カスタマージャーニーの可視化」「グロースサイクルの可視化」「ダッシュボードの整備」などなどがしたいと言い出したわけですね。それを元に、今ここの改善のために頑張るよ！と決め、改善案を考え、それを実装し、再度データを見れば改善されているかわかるので課題がわかり、また仮説をたて、デザインして、みたいな感じです。

イメージは出来てるので、今までの3倍くらいのスピードでは改善がまわせるはず、、です！

多分、担当範囲を分けることによる摩擦は生じますが、そんなもんだと割り切って、とにかく数字を出すために進んでいきたい。そして、自分の担当範囲のアウトプットは他人の意見で曲げる必要はないけど、120%の説明責任はあると思ってるので、ちゃんと他のメンバーに言語化していくようにして進めていきたい。

***

そんな感じで、今までの学びとこれからの進め方の方向性について、書いてみました。

おわり。