00:00
[音楽]
はいこんにちはゼロトピックです ゼロトピックはTENXの代表である
ヤモトが経営や日々の気づきについて 話すポッドキャストです
今回はですね 別のポッドキャストで
オフトピックあるいはリピートライム っていうなんか自分が聞いている
ポッドキャストがあって その中で立て続けにコンパウンド
スタートアップっていう 複数のプロダクトを提供して
事業を立ち上げていくっていうような スタートアップについての話がされていて
これは結構個人的にタイムリーな テーマだったので
これについて自分がどう思っているか っていうのを少し考えを言語化して
まとめておきたいなと思っています
まずちょっと前提として どういう内容を話されていたかってところを
少し振り返ろうと思うんですが まずコンパウンドスタートアップの定義として
スタートアップとして 複数のプロダクトを顧客に提供する
ってところからスタートするっていう パターンをコンパウンドと
それぞれのポッドキャストでは 指されていたかなと思っています
これがこれまでのYコンビネーターに 始まる特定の顧客のすごく深い
ペインを一つのプロダクトで解決して まずはPMFをしっかり強く確認しなさい
っていうセオリーと違うじゃん みたいな
そんな今まで良しとされてきたものとの 結構アンチテーズみたいな部分があるので
少し議論が起きているのかな っていうふうに思っています
メリットは当然いくつも商品が売れること それはいろんな顧客
Aってプロダクトだったら それは違うって顧客に対しても
Bってプロダクトがササッと売れるってことが できるかもしれないし
Aを売れたお客様にBが売れるってことも できるっていう
そういう事業機会の拡大っていうのが メインのメリットだというふうにお話しされてました
他方で難しい
USでなぜこれが成立しているかというと まず買収ができたり技術的インテグレーションができるような
チームとか経験がUSの市場に資産として 溜まっていたり
あるいはエンジニアリング組織についても そういった複数のプロダクトを運営してきた
経験をする人間がいたり 組織があったりっていう
そういうセオリーが溜まってきているというところが 一つ挙げられていたものの
やはりかなり難しいというようなことが 話されていましたと
これについて自分がどう思うかみたいなところを 少し話したいなと思ってるんですが
そもそもマルチプロダクトというか コンパウンドといっても
パターンがでっかく言うと 2つあるんじゃないかなというふうに思っていますと
一つは事例でも話されていた Salesforceみたいに
プラットフォームっていうものをベースに その上に複数のアプリケーション
それがここで言うプロダクトですね
がN個結びついていく
最も重要な基盤とかデータとか 技術的な中小概念っていうのが
プラットフォームの方に 資産として溜まっているっていう状態
これをパターン一つ目として
もう一つのパターンは 全く独立したプロダクト
03:02
要はあらゆる連携ってものを または加味しない形で作られているパターンっていう
この2つなんかなというふうに思っています
全社のプラットフォームをベースにする場合
メリットっていうのはやっぱ プラットフォームっていう共通基盤とか
ある中小水準の恩恵を極めて
他のプロダクトがシームレスに 受けられるっていうポイントだと思うんですよね
例えばもう既にデータモデルがあって
その型通りに作っていくと プロダクトができるとか
あるいはセキュリティのレベルが かなり高い水準で一定にできるとか
データ連携がしやすい状況 インターフェースがちゃんと切れてるとか
そういった共通基盤のメリットを 受けられるっていうのが良くて
これは結果的に新しいアプリケーションを 出す時の開発速度につながったり
あるいは硬さ 要は品質の高さにつながっていくっていうのが
クリアなメリットだと思っています
当然ですけど既存の顧客に対して
複数のアプリケーションを クロスセールしていくってことは
当然できる これはどっちのパターンでもできると思うんですが
プラットフォームがある場合でも そこは問題ない
顧客資産の再生産性が すごい高いっていうところかなと思ってます
ただデメリットもあって デメリットは明確にプラットフォームを作んなきゃいけないっていう
なんかそれが超絶困難だと思っていますと
プロダクトの開発の他に 要はアプリケーションとして
機能の塊を作っていくっていうことの他に
要はその機能をどのように提供するかって
プラットフォームっていう中小水準の定義 開発 アーキテクト
そういったものが必要になっていって
それに応じた組織の構造っていうのも
ある種分割した形で必要になっていくし
プラットフォームとアプリケーションの間で 適切な建成関係も必要になっていく
あるいは事業のフィードバックって どこにどういった形でかかるのかっていう
当然両方プラットフォームにも アプリケーションチームにもかかるはずなんですけど
その社内構造の複雑さみたいなのを 受け入れていかないといけないっていうのが発生するので
非常に要はこのプラットフォームを作るっていうことが難しくて
そのデメリットみたいなものを そのまま引き受ける必要があるのが
プラットフォームをベースにしたパターンの 大きい難点かなっていうふうに思ってます
あとは日本で言うと
プラットフォームを経験した人材って そんな多くないと思うんですよね
そこがすごい難しいですね
アーキテクトとしてもそうかもしれないし
プロダクトマネージャーもそうかもしれないし
当然プラットフォームに特化したソフトエンジニアも
やっぱり市場の中では非常に貴重ってところが 難しさの一因であるかなというふうに思ってます
もう少しこっちのパターンを深掘りしてしまうと
多くの場合でデータモデルのアーキテクトって すごい難しいと思っていますと
あとは自社の技術水準をどの中小水準で 投資していくのかみたいなところも
すごく難しいのかなっていうふうに思ってます
ちょっと手前見せながら自分たちの話をすると
Stellaってフォールプロダクトを謳っていて
06:01
本当にStellaっていうワンプロダクトの中に
実は別のプロダクトとして切り出せるレベルの
でかい機能群がものすごいたくさん詰まってるんですよね
これが1枚のデータモデルを参照しながら作っていって
結果的に我々はPMFをしたんですよね
AとBとCとDとEというものの繋がりの中で
要は顧客がネットスーパーを早期に提供できるとか
極め高い品質のものを提供できるっていう
なんかそういう価値を提供したことによってPMFしたんですけど
個別の機能群だけが欲しいっていうニーズもやっぱ強くあって
なぜならエンタープライズってすでに
個別のシステムっていくつか持ってたりして
ただその中で埋めれない部分を
10Xが提供しているソフトウェアであれば
そこはすごく高い水準で満たせるから
この部分だけ欲しいっていうニーズが
かなり急遭してきますと
だけどそういったものに
さっきの1枚のデータモデルの上にあるプロダクトだと
なかなか提供が難しいっていうのが
我々が今面しているチャレンジだったりして
これを独立したアーキテクトに分割していくっていうのが
要は2度目のPMFにすごく必要なんですよね
1社2社3社に丸ごと入れるっていう意味でのPMFができたけど
これを分割して一部だけをインテグレーションして入れれるようにすることで
さらに事業機会を拡大すると
だけどそれにやるためにはプロダクト側のアーキテクトの変更
要はこの機能の品質とか機能の数みたいなものではなくて
プロダクトのアーキテクトの変更そのものが事業機会に直接結びつくっていう
結構自分的にも見たことがないような機会と面していて
これが大きなチャレンジになっていて
これをかなりトップダウンでリソースもかけながら
今チャレンジをしていこうと考えているところですと
ちょっと横道に反れちゃったんですけど
戻ってパターン2つ目の方ですね
初めから完全に独立したプロダクト
データモデルも全く共通化させず
技術的な資産も共通化させずっていうパターンは
これ完全に独立したチームで
全く横のことを考えないで開発できるのがすごいメリットだと思っていますと
例えば自分の経験だと
メルカリっていう会社がメルカリってプロダクトの他に
メルカリアッテっていうプロダクトを開始した時は
まさにこのパターンで完全に独立したものを作っていて
データモデルの共通化とかも一切ないです
B2Cなので
チーム向けのプロダクトってことで
顧客さんの使い回しみたいなものだけして
メルカリのユーザーに会って使ってねっていう通知をするだけみたいな
なんかそういう形でした
デメリットはこの中小領域っていうものを適切に検討しないんですよね
なので技術的な再生産性っていうのはすごい低いなっていうふうに思っています
使い回しはできなくて毎回新しく起用するようなもの
そこにいる人たちのノウハウだけが再利用できるものであって
技術的な資産とかデータモデルの明とか
09:00
あるいはインテグレーションするためのAPIとか
そういうものは全く用意されなくて
なかなか組織の再生産性はそんな高くない状態で進むかなって思ってます
で実はほとんどのマルチプロダクトって
この後者のパターンだなっていうふうに思ってるんですよね
それは結構大きい問題を仮にPMFした後抱えやすいっていうデメリットがあるなって思ってます
このケース考えた時に
33っていう会社のビル1っていうプロダクトって結構いい例だなと思っていて
なんか33はこのちょうど中間ぐらいだと思うんですよね
パターンAとパターンBの間ぐらいで
どういう意味かというと
8とか33で構築している技術とかオペレーションの基盤が
そのままビル1っていうプロダクトでおそらく使われてるんじゃないかと思ってます
その基盤っていうのはOCRでテキストを適切に読み取って
必要なメタ情報として分類する
最後それをプラス人で保管するっていう
なんか人で何を保管したらいいかってところが極限まで研ぎ澄まされていて
そのOCRっていうAIと人の目権っていう
その二つのオペレーションが技術とオペレーションの組み合わせによって
培われている基盤みたいなものがそのままビル1に使われてるんじゃないかなって思っています
かつ既存の顧客資産にもクロスセルができるっていうところ
ただなんか全くサービスの性質としては違うんで
おそらくデータモデルってのは共通化されてないんじゃないかなって思ってます
ちょうど中間にあるようなサンプルなんじゃないかなと思ってますし
おそらくですけどこの33特許の戦略とかも考えると
この進め方みたいな基盤の水準をどこに置くかっていうのは
かなり戦略的に考えられていたんじゃないかなってふうには思っています
この辺がちょっとその二つのパターンについて思ったことで
あとは市場の要因みたいなものもあるかなと思っていて
今新しく何か起業したりスタートアップやろうと思った時に
これまでより同時に多くの複雑な問題解かないと
スタートアップできない問題があるなっていうふうに思っています
要は簡単な問題というかソフトウェアで3回作れますみたいなものっていうのは
もうほとんどなくて結構その複雑で難しい
オペレーションも絡んだような問題を解かないと
なかなか本当に立ち上がるスタートアップしづらいなっていうふうに思ってます
この時の創業時というかプロダクトを作り始める時に
つまり大きい問いと向き合わなきゃいけなくて
それは何かというと1枚のデータモデルも何でもいいと
後に技術不細っていうのは後ろに追いやるので
まずは早く動くものを作ってPMFを目指すっていうのか
あるいはそこのPMFの不確実性は一定飲み込みつつ
要はキャッシュがバーンしてしまうとかそういうリスクを飲み込みつつも
一定の分割レベルを持った要は中小水準への投資を進めながら
モジュールが分割されたプラットフォームとプロダクトを作っていくのか
あるいは独立したプロダクトをもう何個も作っていく
12:03
そこに再生産性の低さっていうのは発生するけど
PMFはまだ何個もできるよねっていう前提でやるのかっていう
この技術的な意思決定っていうところだったり
設計に対する意思決定っていうのはすごい難易度が上がってるなっていうのが
市場の要因で起きてる気はしていますと
故に創業者とかあるいはCEO、CTO含めて
爆速で何か作っていくっていうことのために
アーキテクトのスキルっていうのはものすごい重要になってるなっていうふうに思ってます
僕自身とかアーキテクチャを考えるみたいなのは技術的にはやったことはないですけど
事業水準の中でどのようなアーキテクトであるべきかっていうところは
フィードバックをすごく持ってるというか欠けていて
そこを特にCTOである石川さんと直近はかなり議論する時間が長いなっていうふうに思ってます
最後もう一個組織的なのってもあるなと思っていて
最終的にはプロダクトとかプラットフォームとかそういったものの形に
事業組織もフィットさせないと絶対速度は出ないっていう
いわゆる逆コンベイみたいなものが発生するなと思ってます
この辺はおそらくVCの目線から全然見えないと思うんですけど
技術的な組織を運営していく上では必ず出る論点だと思ってます
いわゆる独立した組織で独立したガバナンスで
プロダクトと事業を一体で進められない限り
顧客の価値に届くものってなかなか早くデリバリーできないとか
顧客の価値は何かっていうその中小水準に下ろして
プラットフォームフィードバックみたいなものも
でかい1枚の組織例えば100人開発チームの組織がありますってところと
10人ずつ10個のチームがあるのだと全くスピードが違うと思うんですよね
なので適切なフィードバックができる環境を作るっていうことをするためには
技術組織とプロダクト組織っていうのは
ごめんなさい事業組織とプロダクト組織っていうのは
完全に一致させる必要があると思っていますと
これしないまままあこれはうちの反省なんですけど
例えば1枚のプロダクトの中で要求が100個1000個きましたってなったら
これ優先度絶対直列につけられないんですよ
わかんないですってなっちゃいます
なので適切な分割をしてその分割の中で優先度を決めて
リソースを配分するっていう経営の投資活動をしなきゃいけなくなるんですけど
この技術とプロダクトの組織と事業の組織が完全に分割していて
技術側は1枚です事業はNでありますっていう状態になっていくと
その要求の数点爆発して優先度をつけられない
結果経営のスピードが落ちるなっていうふうに思っていて
技術的な意思決定と組織的な意思決定と
あとはその上で事業的なトレードオフも必ずあって
プラットフォーム作るってなると
プラットフォーム作るための期間を潜んなきゃいけなかったり
仕様のロックインが必要だったりっていうのが必ず発生すると思うので
その間事業的なトレードオフをどのようにコントロールするかっていう問題も出てきて
やっぱこう難しいなと思ってます
15:03
ただこれらトータルでマネージできる会社だけが
やっぱり本当に最後まで成長する期間を長く取れるんじゃないかなっていうふうに思っているので
もう割とどこの会社も避けて通れないチャレンジなんじゃないかなっていうふうに思っています
今時一つのプロダクトでドーンみたいなのはやっぱり結構難しくて
過去で言うとやっぱり複数のプロダクトを束ねて
顧客の大きな問題を解けるってところにやっぱり価値があると思うので
その上で言うと遅かれ早かれこの問題っていうのは
全てのスタートアップの経営者が考えなきゃいけない問いなのかなっていうふうには思っています
はいということでちょっとバーっと自分の考えを喋ってみたんですが
もしコメントだったり質問あったりあればQ&Aのサービスでいただければと思います
はいそれでは
(♪ BGM)
