新規事業開発のエンジニアリング
この10月から新規事業開発を支える「エンジニアリング」を最適化するというミッションを担うことになりました。
ヤッベー、マジこれ難しい！！とか、ウワ〜〜〜これマジで自分たちのありもののスキルセットとギャップありすぎやなぁあ〜〜等、毎日頭を抱えながら必死で生きています。
事業オーナーと一緒に新規事業開発をおこなっている状況はこっちをどうぞ。
今日はポエミーに、このエンジニアリング最適化の試みで何をしようとしているのかというのをご紹介したいと思います。なお、本記事はすべて個人の主観に基づく妄想であって、今朝見た夢の内容を書いたものとします。
もし誰かに怒られたら骨を拾ってください。
意義
新規事業開発、基本的には死屍累々になることを運命づけられています。
その過程で黒字化する比率は？
川本：全応募のうち、事業化検討フェーズまで進めるのが2%程度。さらにそのうち、検討を進めて黒字化に到達するのが15%程度ですね。
［議論］新規事業生む組織とは？ リクルート名物制度の秘密大企業の新規事業の成功率は5%程度と言われます。20回に1回しか成功しないわけです。
新規事業の成功確率は5%程度 突出した人材の失敗を許容できるか
また、成功したところで「再現性」がない領域です。同じことを繰り返したとしても再び成功するわけではない。
このため、だいたい
- それって事業によって違うよね！！
- その場その場で最適な判断を行うしかないよね！！！
- 要はバランスだよね！！！！！！
などという言説で乗り切れる領域でもあります。これらもある種真実だろうしな。
事業とエンジニアリングは一期一会。毎回ゼロから考えようって話ですね。
でも、それなりに大きめの企業で新規事業開発に力を入れるってなると、それじゃダメだと思うんですよ。新規事業開発、きっと何度も繰り返すと思うんですよね。そして、確率的にはきっとたくさん失敗する。
でも、失敗は次の糧にしないと、投資した意味がないですよね。失敗した事業も浮かばれないし。
特に、エンジニアリングって「不確実性を下げる行為」じゃないですか。
「曖昧さ」を減らし、「具体性・明確さ」を増やす行為が「エンジニアリングとは何か」という答えでもあるのです。
エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング
新規事業が絶対に成功するエンジニアリングというのはないにせよ、こうやったら失敗確率が減らせるよね、というエンジニアリングはあると思うんですよ、はい。だからこう、こうやったら良いよっていう指針のようなものを定義すべきなんじゃないかなと。それを使って、1%でも30%でも成功確率が高まったら良いじゃないですか。
事業オーナーはマジで必死で事業について考えてくれるので、そういうところに貢献できるエンジニアリングを定義できればと思っています。
私はアマゾンやフェイスブックのような「大成功するスタートアップ」を作ることはアートだと思っている。ただし、この本で示した基本的な型を身につければ「失敗しないスタートアップ」は高い確率で実現できる。これを私はサイエンスだと信じている。
起業の科学 スタートアップサイエンス
新規事業のフェーズ
偉そうなことを言いながら、僕自身は新規事業を起こしたことがない。
ただ、どうも新規事業開発においては一般的なステージというものがあるようです。
下記の記述は、以下の2つの本を参考にしています。
CPF (Customer Problem Fit)
顧客が「誰か」を定義した上で、その顧客が直面している課題を明らかにする。
将来的に事業として成立するためには、その顧客は「お金を払ってでも解決したい」と思う根深い課題を持っているはずであり、それを見つけ、本当に顧客がその課題を持っていることを検証する。
PSF (Problem Solution Fit)
実現できるかはわからないけれど、「確実にその課題を解決できる」というソリューションの仮説を提示する。
そして、定義した顧客を実際に見つけ、定義した課題を実際の現場から見える化し、定義したソリューション仮説によってたしかに課題が解消され、お金が支払われることを「実証」する計画を立てる。
MVPによる検証
みんな大好きMVPで、事業仮説を実証するとともに、事業計画として成立させる。
- 顧客が確かに存在することを証明し、
- 顧客の課題が提示したソリューションによって解決・お金が支払われることを実証し、
- 事業仮説が、投資可能であり将来的には儲かる構造をもったものだと証明する
Seed期
実際にサービスや製品を組み立て、新規事業として世の中にリリースし、商売を開始する。
その上でユニットエコノミクスを改善し、LTV > CACを達成する。
なおLTVとCACについては以下の通りで、LTV > CAC を達成し続ければ、理屈上ユーザを集めれば集めるほど無限に事業がスケールします。
- LTV (Life Time Value): 顧客が最初の接触時点から関係性が継続する限りの期間にもたらす利益の総額
- CAC (Customer Acquisition Cost): いち顧客を獲得するのに要した営業およびマーケティングのトータルコスト
PMF (Product Market Fit)
実際に LTV > CAC を達成できれば、PMF と言えるのではないでしょうか。
ここまで辿り着くと、資金を大きく投下して、顧客と売上・利益の拡大を実現していけます。もちろんその幸せは長く続かず、市場にいる顧客数には上限があるためCACが次第に悪化したり、人の数の増加に伴って組織が疲弊したりします。
新規事業開発を支えるエンジニアリングとは
新規事業開発のためのエンジニアリングって2つに分かれるんじゃないかと思うんですよね。上記の例だと、Seed期の前と後。
Seed期の前
Seed期の前って、とにかく仮説検証の繰り返しなんですよね。
それも、社内で事例とか分析とか上長との相談とかするのはとにかくバッドプラクティスであって、そんな暇あったらさっさと顧客に見てもらえ、という世界になります。
「仮説を顧客のところに持っていく」活動を、大体何回転させると新規事業案ができあがると思いますか？約2000回の新規事業開発の「相場観」から導かれたマジックナンバー。それが「300回」です。
下記の画像を含め、新規事業の実践論より引用。
上記書籍によると、300回の仮説検証を事業オーナーは繰り返さないといけない。もちろん何十年もかけられるわけではない。例えば期限が6ヶ月だとすると、1ヶ月あたり50回、1日あたり2.5回の仮説検証を繰り返せという話になります。
エンジニアリングは、このサイクルに耐えられないといけない。
ガッツリもの作る暇なんてねーぞ、というのが最初に抱いた感想でした。
限られた予算・限られた時間で、とにかくユーザに検証してもらうことを支えるエンジニアリング。
だから、以下のようなことがエンジニアリングとして必要なんだと思います。
- 如何にして「作らない」で高速に検証するか
- 「作る」としても如何にして既存のもの・仕組みを流用するか
- 「作ったもの」はどんどん変わるんだから、MVP以降に使い回すというような雑念を捨てる
必要とされるのは、スクラッチから全部構築していくぞ〜というエンジニアリングではなくて、できるだけ作らずに「検証できるようにする」というエンジニアリング。
検証のために物作りが必要になるにせよ、既存のもの（OSS、サービス等)を如何に流用し繋ぐかというエンジニアリングなのでしょう。自動化とか最適化とか二の次。
Seed期の後
事業アイディアが確立したら、あとはもう如何に早く安く、ユニットエコノミクスを改善し、ユーザを惹きつけるものを追加し、不要なものを切っていくかという話だと思っています。
そうすると如何にしてユーザを見ながら拡張できるかという話になり、ここでようやく、強く「保守性」のもたらすアジリティが要求されるようになるのかなと。
Seed期の前後でぜんぜん求める目的が違うんだ。だから、エンジニアリングのアプローチも変えないとダメなんだ、たぶん。
そして
というようなことを考えながら、理想的な姿はどこなんだろうなぁ、どうやって掘り下げていくと良いんだろうな〜〜〜というところで夢から覚めた。