問い：どうすればもっと早く多く失敗できたか？🤔 - meepa試行錯誤@dotDの振り返り
先日の投稿の通り、meepaは株式会社dotD内での活動を終了し、株式会社meepaとして心機一転して活動を継続することになりました。
meepaの挑戦自体はまだ継続中で成否を判断する段階にないですが、dotD内で約2年間に渡って試行錯誤を重ねた、保護者向けwebアプリ開発は残念ながら失敗に終わってしまいました。
dotDは『事業創造ファーム』です。転んでもただでは起きません。ちゃんと失敗から学びます。先日meepaも過去2年間の経験からの学びを全社勉強会でナレッジシェアしました。
折角の経験なのでdotD外部の方にもお裾分けということで、これから全4回に渡って記事にしてみたいと思います。
1. 問い：どうすればもっと早く多く失敗できたか？🤔 ←今回
2. 解①：不要な実験・開発をスキップする🏃♂️
3. 解②：開発を短期化する👩💻
4. 解③：実験を短期化する🧪
背景：dotDでの2年間
学びの内容をしみじみと受け止めてもらうためには背景の共有が大事。ということでまずは背景情報をお伝えします。といっても、前回記事の「これまでの2年間」セクションにちょうど良い文量でまとまっているので、まずは👇をご覧ください。
👆を読んで頂いた上で、改めて強調しておきたいのは以下の3点です。
1点目は、2年間で3回のピボット・4回の実験を行ったということ。それぞれどんな仮説に基づいてどんなMVPを用意してどんな結果になったのかについては以下をご覧ください。
2点目は、プロダクト開発を伴わない範囲での初期の仮説検証は順調だったこと。どんな実験をやってどんな結果が得られたかは以下をご覧ください。
3点目は、MVP開発を伴うβテストらしきことをし始めてからが、ずるずると長引いてしまったこと。3ヶ月1サイクル、maxでも1年半=6サイクルで色んな実験をしたいと思っていたのですが、結果的には半分程度のペースになってしまいました。
なお、meepaのコストの大半は開発費（≒人件費）で、内部人件費の計算の仕方にもよりますが、数千万円は投資してもらいました（後の問いの設定にもつながります）。
問いの設定
経験から適切に学ぶためには問いの設定は必須です。
結論から言うと、今回は「どうすればもっと早く多く失敗できたか？」にします。
なぜか。一言でいえば、一般的に大事だと言われているけれど、色々な障壁があって中々実践できないからです。
新規事業の成功確率には、1000件に3件（出所不明）、7%（出所：Paul Graham, Y CombinatorFounder, 注：成功の定義は企業価値>40億円）など色々な言説がありますが、間違いないのはほとんどの試みが失敗するということ。従って、挑戦の総数を増やすことが、ある個人または集団が成功を掴み取るための近道になります。同様に一つのプロジェクトにおいても、内部で色々な試行錯誤にトライすることが大事です。
起業家やVC社員と話していると、同じ新規事業でもBtoBは定石通りに仮説検証ステップを踏んでいけば大きな投資をする前にある程度成否が見えるのだが、一方のBtoCはどれだけ事前に適切なステップを踏んで自信満々でローンチしても結局『無風』に終わることが多いという話をよく耳にします。これが正しいとすると、BtoCの方がなおさら試行錯誤量が大事になりそうです。
とはいえ、上に書いたような内容を、僕は元々知っていました。何なら開始半年~1年の時点でそのことに反省して記事化👇していたくらいです。それでも上手くできなかった。気づいているだけ・知っているだけではできないというやつですね。これは振り返り甲斐があります。
一般的に大事だと言われているけれど、知っていても実践できない。そんな曲者をどう実現させるのか。『あなたの想いを、挑戦に変える』をミッションとするdotDではとりわけ大事な論点です。想いに挑戦する＝熱量が高い＝自分では簡単に止まれない（恋は盲目ってやつ）のだとすると、今後もdotDでは同様の失敗が頻発しかねないからです。
解決には大きな方向性として、プロセス・ツール・文化等を整備して「周りが止めてあげる」というのと、個人戦術的に「どうにか自分で止める」の2つがあると思います。いつか前者に関するdotDの取り組み事例を紹介するかもしれませんが、今回は個人戦術的に「どうにか自分で止める」を考察してみます。
次回予告
次回以降、「どうすればもっと早く多く失敗できたか？」の問いに対して、「どうにか自分で止める」の方向で、大きく3つに分けて解決策を考えていきます。お楽しみに。
この記事が気に入ったらサポートをしてみませんか？