DX支援ではなく「事業者」になる:成果を直接提供するフルスタック型スタートアップの設計

皆さん、こんにちは。FoundXのです。

同じくFoundXの富田です。

雑談なんですが、最近このビルの中にまいばすけっとができまして便利ですね。

めちゃくちゃ便利ですね。もうなんか昼行ってお昼食べた後おやつ食べに行ってみたいな感じでめっちゃ使ってます。

そうですね。結構やっぱり近くにね、2分ぐらい先にセブンイレブンはあったけれど、ほぼ0分だとやっぱ違いますね。

いやあ、違いますね。今特に暑いので、外に出るのもっていう感じなのでありがたいですね。

はい。そんな感じでちょっとQOL、クオリティオブライフが、クオリティオブワークの方か、上がったかなと。[笑い]

いや、でもスーパーできるの本当ありがたいですね。

そうですね。私もついレトルトカレーを買っちゃいました。

あ、カレー召し上がってたんですね、さっき。

いや、さっきじゃなくて、いつでも食べれるように。

ああ、いつでも食べられるように。

はい。ということで、IdeaCastのコーナーに入りたいと思います。FoundX Review Startup IdeaCastは、海外を中心としたスタートアップの事例を元に、スタートアップの戦略とか事業の組み立て方をAIを使って分析して紹介する番組です。今日は再びですが、戦略の話をしています。

最初にディスクレーマーですけれども、AIを活用して情報整理しているので、一部情報が古かったり間違ってる場合があります。ファクトを重視される場合は必ずご自身で調べるようお願いいたします。ポッドキャストは個別の企業の評価とか投資判断を目的にするものではなく、また戦略とかをそのまま使っていただくというわけではなく、事例とかそうしたアプローチから参考情報とか考え方を引き出すことを目的としています。

ということで今日取り上げる戦略のアプローチは、成果を直接提供するフルスタック事業者モデルと言いますか、DX支援ではなく新しい事業者になっていくという、ツールベンダーではなく成果の提供者になっていく戦略というものがあるんじゃないかというような内容になっております。

今回これを取り上げる理由はどういったところでしょうか?

そうですね、SaaSとか色々と出てきていたと思いますが、AIとかによってよりバリューチェーンが伸ばせるようになって、場合によっては自分たち自身が新しい事業者になっていく可能性も出てきてるんじゃないかとか、あとやっぱりこのSaaSとか、あるいは機器販売全般ですけれども、顧客側にそれを自社に統合していく能力があることを暗黙の前提としているみたいなところがありますが、そうじゃない領域があったりすると、もう自分たちが成果の提供者になっていく、新しい事業者になっていく。DXの道具を提供するんじゃなくて、もう自分たちが全てをやりますみたいなことをすると、顧客の導入負担とかを減らせますし、大きくなっていく事業を作っていけるんじゃないかということで。その分スタートアップが品質とかリスクとか資金とか規制の責任を引き受けることにはなりますが、アップサイドを大きくしていく1つの手法としてあり得るんじゃないかなと思っていて、この手法を考えていきたいと思っているというところです。

では早速ですが、全体像をお話ししていきたいと思います。従来のSaaSモデルとかは、先ほども言った通り、スタートアップはある意味ツールとか機能を納品した時点で責任を終えていたみたいなところですが、この新しい事業者モデルというものは、もう少しバリューチェーンを伸ばして、完成した成果を提供していくというような内容になっています。従来のビジネスモデルと言いますか、ツール提供モデルですと、顧客が成果を出せるかどうかというものは、顧客の、既存企業の導入能力にかなり左右されてくるという点があったんですが、この新しい事業者モデル、自分たちが事業成果を提供していくというモデルは、もうそこまでやりますよと。テクノロジーを外部、つまりお客様に販売していくのではなくって、自社の内部の生産手段としてツールや技術というものを活用して、最終成果を直接顧客に提供していく、そうしたフルスタック型のアプローチというものがあるんじゃないかというのが、今回のアプローチの全体像になっています。

とはいえ、これが成り立つところは少なくなっているかなと思っていまして、例えば自分たちがやっていくってことになると、自分たちで導入期間を短縮できるかとか、品質を安定できるかとか、調整コストを削減できるかとか、失敗率をちゃんと低くできるかみたいな、そうしたものが大きくなってきますし、設備投資も大きくなってくる、あるいは回収も長期化するみたいな、そうしたデメリットもあって、ここをどうしていくのかというところがポイントかなと思ってます。

成果を提供するっていうだけであれば、成果に連動したようなビジネスモデル、料金体系にするだけでもあるのかなと思ったんですけど、それだけだと足りないっていうことなんでしょうか?

そうですね。成果を左右する工程を外部に残したまま成果保証だけを行うと、制御できないリスクを負うことにもなったりしますというのが1つポイントとしてはあるのかなと思っているのと、成果連動型価格というものが有効なのは、測定可能性とか因果の帰属というのができる、これも前回少しお話ししましたが、そういう測定ができるところとか、主要工程を直接管理できる場合みたいなところがメインかなと思うので、ここがちょっと違うのかなという風に思います。あとは、料金設計ももちろん大事なんですが、どの工程を持てば成果の分散を減らせるのかっていうところも1つポイントとしては出てくるのかなとは思います。

はい。そうですね。この辺、面白い事例としてやっぱりHadrianとかがあるのかなと。彼らは製造業をフルスタックに近い形でやっていくというスタートアップですが、従来であればソフトウェアを工場に売っていくってことをやっていましたが、Hadrianなんかは製造能力そのものを提供していく。いわゆる製造会社として何かを納品するっていうことをHadrianがやっていて、工場内部の生産手段としてAIを使って、顧客には製造能力を提供するファクトリー・アズ・ア・サービスみたいなことをやっていたりもするみたいですね。

はい。ではこのアプローチがどういうところで効くのかというところを少し整理したいと思います。問題の構造がいくつかある時に、このアプローチは重要ではないかというのがポイントです。1つが、工程と責任主体の分断、いわゆる設計とか調達とか施工とかがそれぞれ別会社で、かつ全体最適をしていく責任者が不在な時には、こうした全体最適をすることによって早くかつ安く提供できるかもしれないっていうのが、問題の構造と解決策としてありますと。もう1個は導入能力の不足です。新しい技術とか新しいツールを購入しても、顧客側自身にその業務の変更とか現場の教育を完了する能力がなかったりする場合は、ツール提供だけだとなかなかうまくいかない。機器とかSaaSを提供してもなかなかうまくいかないというところがあったりするので、その導入能力の不足を補う時に、この成果を納品していくというのがあり得るかもしれないと。

3つ目がデータと学習の断絶ですと。これは実行を外部に任せるので、現場の例外処理とか失敗要因が製品開発に戻らないみたいなことがあるのかなと思っていて、失敗の原因が外注先に留まって、製品側には成功とか失敗の条件が戻らないみたいな場合は、もしかしたら問題として今回のアプローチが適切なのかもしれないと。最後にインセンティブのミスマッチですと。これは各社がそれぞれ担当していて、人月とか作業量とか販売で収益を得ると、そもそもの工程削減とか失敗の予防とかが、彼らにとって、いわゆる従来のベンダーにとっては売上減少につながって、その全体最適、あるいは最終成果への経済的な責任というものが弱いと。こうした問題構造がある時に、このフルスタックに近い形で成果を納品していくっていうのが、もしかしたら経済的にもペイするし、問題を解決できるかもしれないと。

成果を提供する側に立つと、それこそ遅延とか再作業とか品質不良とか、これが自社の損失になってくるわけで、改善への経済的な動機が強くなっていくこともあったりはします。なので、ある可能性があるというところがあって、そこをうまく使えれば、このフルスタック型のアプローチというものは、こういう問題構造に効いていくのではないかなということが言われているのかなと思います。

工程、バリューチェーンが工程ごとに切れているような産業っていうのはかなりあるかとは思うんですけど、それだけをもって統合すればいいという話ではなくて、他の条件も加わってくるということでしょうか?

そうですね。分かれているところの摩擦がどれぐらいあるのかっていうところが大きいのかなとまずは思います。標準的なインターフェースとかがあればそこの摩擦ってあまりないでしょうし、元請の企業とかが十分に調整できていれば、そこの摩擦が結構吸い取られていると言いますか、もうすでに解消されているので、参入余地は小さくなってしまうかもしれません。なので、もし入るところがあるとしたら、分断と言いますか、分かれていることによる損失が大きくて、顧客がその損失に支払う意思があり、スタートアップがそこを改善可能なところとして解決できるのであれば、もしかしたらあるのかもしれないなと思います。

今日は導入能力の不足っていうのも理由の1つに挙げられてたんですけど、導入支援サービスとかスタートアップでもよく見かけるんですけど、それで補えばいいじゃないっていう話でもないということなんでしょうか?

そうですね。そういうパターンもあると思います。例えば1回の業務変更とか、あるいはコンサルティングで済んで、その後は顧客が自前で運用できるのであれば、導入支援だけで十分なケースもあると思います。ただ、もし現場の条件とかが継続的に変わっていくとか、あるいは毎回の設計とか配置とか品質判断というものが成果を左右するのであれば、運用を継続的にやっていくっていうことの価値が高まってくるので、そこに対してはもしかしたら1回の導入支援じゃない形でやっていく方がいいかもしれないとか。あとはもしかしたら提供側、スタートアップ側もまずは導入支援として入って、反復して自社が介入しなければ成果が維持できないかどうかっていうのを確認して、そうであれば、継続的に成果を納品していくアプローチみたいなのを検討するのも1つのポイントとしてあるのかなと思います。

この辺りは例えば、Promise Roboticsというカナダの住宅建設自動化の会社があって、ここはお客がロボットを買っても運用できないという問題を解決するために、ロボットとかソフトウェアの販売に留まらずに、住宅メーカー向けに短期型の生産工場と自動化ライフサイクルを提供していくみたいなことをやっているみたいです。市販のロボットを使いながら、ロボットの計画とか工場運用とか工程設計を自社システムで統合していくっていうことをやっているみたいですね。Monumentalはどちらかというと、完成品、完成した壁というものを提供していたスタートアップとして紹介しましたけれども、Promise Roboticsは顧客の生産拠点っていうものを短期で、いわゆるキーを回せばすぐに稼働するような状態で立ち上げていくみたいなことをやっているスタートアップ。そして北米でファクトリー・アズ・ア・サービス型の展開を進めているスタートアップになっています。

あとはバイオ系とかでもありますかね。バイオ製造系だとCulture Biosciencesっていうところも、バイオリアクター機器を販売するんではなくて、クラウド接続されたラボで顧客のバイオ実験を実行して、リアルタイムでデータを提供していく。いわゆる設備とか実験運用、データ取得を自社でやって、顧客はプロトコルと目的を指定したら後は自動的にやってくれるみたいな、そんなところもあったりはします。

この辺ですね。レロベンチャーズが「ソフトウェアフイナリゲッTO」っていうような文章を出していて、これは2026年4月ですね。従来のSaaSは仕事を道具として支援してきたけれども、バーティカルAIは業務を実行すると、そして実行結果から継続的に学習するみたいなことを言っている。そうしたドキュメントもあったりするんで、この辺りも見ていただくといいのかなと思います。

では、どこでこのアプローチが使えるのかというところを少し整理しながら見ていきたいと思います。このアプローチは全てに使えるわけではなくって、おそらくここで使えるんじゃないかというようなパターンがあるのかなと思ってますと。まず顧客の要求ですと。技術ではなくて完成した成果に喜んで対価を払うところであれば、まずは1個目にいいんじゃないというところですね。逆にソフトウェアとか機器自体の機能とかカスタマイズ性を重視する場合は、ちょっと違うかもしれないなというのがありますと。あとは市場とか顧客側の能力という形で、顧客側にもし導入とか統合とか運用能力がないような業界とか顧客の場合は、成果自体を提供していく、あるいはフルスタックで自分たちがやっていくっていう方がいいんじゃないか。一方で成立しづらい条件としては、お客がそのシステム統合とか運用の能力がある場合は、ツールさえ手に入ればいいよという形になるので、そこは向いてないかもしれない。

そして価値の源泉という観点で考えると、成立する条件としては、外部パートナーの間の摩擦とか調整コストというものが課題な領域、事業の場合は合うかもしれませんと。一方で技術性能とか機器スペックの優位性だけで勝敗が決まるみたいなところに関しては、あんまりこのアプローチは向いてないかもしれません。あとプロセスの特性という形で、案件間の共通部分が大きくて、業務をこれから標準化、ソフトウェア化できるんであれば、もしかしたらいけるかもしれない。一方で案件ごとの個別性が極めて高い場合とか、知識の再利用が不可能な場合は成立しづらいかもしれない。そして最後に資本とか規制に関して、設備とか保険とか規制責任を自社から切り離す手段があったりとか、ある程度自分たちでうまくできるんであれば合うかもしれませんが、一方で巨額の固定資産とか法的な自己資本負担みたいなところを自社で全額抱える必要があるのであれば、ちょっと向いてないかもしれないっていうような、そうした整理ができるのかなと思います。

あとはいえ、条件が揃っていても価格がうまく設計できるかどうかっていうところも変わってくると思いますので、この辺りも見ておくべきかなと思いますね。

なるほど。条件いくつか挙げていただいたんですけれども、この中で特に重要なものとか、優先すべきものってあるんでしょうか?

顧客の要求ですかね。ちゃんと成果に対して喜んで対価を払ってくれるのかというところが1つと、あと自分たちでどこまでその主要な工程を制御できるかというところ、あとは反復可能性ですね。一品物にならないかどうかっていうところは特に重要なのかなと。資本とか規制の負担というものは考えるべきだと思いますが、その辺りは場合によっては資金調達とかでなんとか成立の余地があるかもしれないので、この辺りに関しては何かしら迂回手段があると思うんですが、顧客側の要求であるとか主要工程がどこまでマネジメントできるかというところは、おそらく結構大きな分かれ道なのかなと思います。

はい。成果って結構定義が難しいと思うんですけれども、どの段階でどこまで決めておくべきなんでしょうか?

そうですね。難しいなという風に思います。これも成果のところでお話ししましたけれども、やっぱ測定とかの難しさが1個あるっていうのと、契約の難しさというのがあるのかなと思ってます。なので、成果指標とか基準値とか測定期間とか、あと顧客側の協力とかですかね、を事前に定義して、本当にこの成果を納品できましたよねというのをちゃんと見えるようにしておく。で、完全な最終成果が測れない場合は、完成状態とか検収可能な中間成果みたいなところをきちんと決めておくっていうのが大事かなと。あと外部要因が大きいほど、固定料金とか成果連動みたいなところを組み合わせた方がまあまあ安全なのかなという風には思います。

この辺り、また医療系になりますが、Virta Healthっていうところに関しては、遠隔医療とか栄養指導とか継続モニタリングっていうのを統合して、雇用主とか保険者向けに患者ごとの成果に連動する100%リスク型価格というのを提供している、そういうスタートアップがあったりします。アプリ提供に留まらなくて、医師とかコーチとかモニタリングとか治療プロトコルを一体で提供して、顧客が求めているのはアプリ利用じゃなくって、血糖指標とか投薬の削減とか、そうした測定可能な成果だと考えて、これを進めていくというところで、シリーズEですかね、のところまで行っているスタートアップがあったりはします。

では、この戦略で何をどう設計していけばいいのかというところのお話をしたいと思います。まずはやはり自分たちで所有するところと外部化するところ、ここをちゃんと考えて分けていく必要があるのかなと思っています。全工程を所有するのではなくって、最終成果を左右するようなところをきちんと握っておくのがまずは大事だと。そのためには、例えば成果の契約、何をもって成功とするのか、何をもって完成とするのか、検収するのか、価格と保証をどうするのか、この辺りの価格決定権をちゃんと持っておくことっていうのが1つポイントだと思いますと。あとは業務設計とかデータをどうするのかっていうところで、見積もりとか設計とか判断のルールであるとか意思決定基準というものを自社のシステムでちゃんと集約していくみたいなことを1つしていくと。あとは実行制御という観点で、その成果を直接左右するような非常に大事な作業に関しては自社で実行する、あるいは自社が即座に指示・監視できる状態にしておく。こういうところを自分たちで持って、もしかしたら外部化するところとしては、資本とか規制能力とかに関しては一部外部の主体を利用したりするかもしれませんし、一般的な労務とかというところに関しては、学習の価値が低いとか、地域性の強いものに関しては提携先に委ねていくみたいなこともあるのかなと思ってますと。こうした自分たちで何を持つのか、何を外部化するのかっていうのを考えていくのが大事ですと。

で、境界はおそらく初期に自分たちが持っておくバリューチェーンの長さと、成長期のバリューチェーンの長さとでちょっと変わっていくのかなと思ってます。初期は学習のために広く自社で実行しておいて、標準化できた工程から外部に移転していくと言いますか、外部化していくとか、そうしたパターンもあると思います。で、外部化する前にその工程に関してはちゃんとデータを取得して、ここで学習しておくとかいうのは大事かなと思いますが、一旦長めに1回バリューチェーンを伸ばして、徐々に短くしていく、本当に利益の源泉となっていくようなところに短くしていくっていうのは、よくあるパターンなのかなとは思います。

バリューチェーンを長めにしてだんだん短くしていくっていうことだったんですけど、どういうところから短くしていく、つまり外部化していくっていう風にやっていくといいんでしょうか?

そうですね。先ほど少しお話しした内容ですけども、学習の価値が低いところとか、自分たちがやる必要はないとか、地域性が高いところとか、あとはいわゆる供給がいっぱいある、競争的な供給市場があるような領域とかは外部化していってもいいのかな。例えば一般的な搬送であるとか、汎用的な施工であるとか、あるいは汎用的な設備とか、あと金融資本みたいなところに関しては、自分たちで持たなくても外から調達できる可能性がありますし、場合によっては地域性が高いので自分たちがやっても学習がなかなか高まらないみたいなところに関しては、もう地域の方にお任せするみたいなところはあるのかなと。逆に持っておいた方がいいのは、顧客接点とか見積もりとか設計とか、あと品質判断とか、この辺りは割と自分たちが最後まで持ち続けるというのが1つパターンとしてあるのかなと思います。

この辺り、スタートアップで言うとエナジー・アズ・ア・サービス系で、Redaptiveというスタートアップがあって、ここは企業のエネルギー設備の改修について、調査から資金、施工の調整、測定、保守、これを1つのサービスとして提供しているスタートアップです。全比依存で設備を選んで、スマートメーターによる測定とか検証と、そして長期サービス契約というのを自社で管理しているところになってます。Jetsonみたいなところは住宅単位でヒートポンプ導入をしていましたが、Redaptiveのところは企業の複数拠点を長期契約で束ねて、そこで自分たちのサービスを長期的に売っていくということをやっているスタートアップです。

あとはサイバー保険のCoalitionなんかも、サイバー保険に対して継続的なリスク評価とかセキュリティツールとかインシデント対応を統合して提供しているスタートアップで、顧客に関しては、いろんなアプリとかツールを入れていくことによって、より保険を安くしていくことができるみたいな、そうしたところがあるのかなと。講義みたいな保険のフルスタックの方もあったと思いますが、あれはフルスタック型の保険会社だったのに対して、Coalitionなんかは既存のキャパシティとの提携というのを活用して育ってきたスタートアップだったりします。

はい。この辺り、いくつかVCのドキュメントも出てきて、NFXが2025年に出した「Stackable Business Models in the Age of AI」みたいなドキュメントでは、技術だけではなくって、価格とかサービスとか金融とか成果連動とか、そうした複数の事業モデルを束ねて、あるいは複合的に使って、価値の創出とか提供と獲得の位置を設計していく必要があるみたいなことを言っているドキュメントで、そのビジネスモデルをどう変えていくのかというところが、このAI時代に対して大事ではないかってことを言っているドキュメントだったりするので、これも面白ければ見ていただければと思います。

ではなぜこうしたアプローチが成果につながるのかに関してお話ししたいと思います。これに関しては、データを使った成功の因果ループみたいなところを使って作っていく必要があるのではないかというのを、AIがまとめた内容になっています。例えば成果の契約をする、顧客への一括提供によって市場の調整コストを排除して受注していく、成果を約束して契約しますというところですと。それによって運用データが手に入ります。実際の作業時間とか例外処理とかエラーの原因とか部材コストの実データなどを取得して、蓄積したデータを基に次の案件の見積もりとか設計とか配員とか自動化、あるいは工程の自動化というのを内部的な自分たちのソフトウェアでやっていく。そしてその結果、ばらつきの削減、現場の手戻りとか待機時間とか品質のばらつきが最小化されていって、ユニットエコノミクスが高まっていく。案件あたりの原価の低下が行われて、リードタイムの短縮も行われて、粗利が拡大していく。そうするとより競争優位が高い価格でオファーができるので、成果の契約ができるという、こうした学習ループをデータを使って回していくことによって、新しい案件ほど見積もり誤差とか作業時間、例外率とかが低下していって、より良いオファーがしていけるんじゃないかというのが1つポイントだという風に言えるのかなと思います。

その学習ループを回す上でデータが元になっていくっていうことだとは思うんですが、ただデータを集めるだけでいいという話でもないとは思うので、どういうデータを集めてどういう風に取り組んでいくべきかというとどうなんでしょうか?

おそらく、データが大量になっても別に自然には下がっていきませんと。なので、やるべきことはやっぱりデータを原因別に分類したりとか、次の見積もりとか標準作業に反映する組織とかシステムというものが必要で、例えば見積もり誤差とか手戻りとか例外っていうのをちゃんとレビューして、その標準的な仕様というものを固めていって、そこに対して変更をどうしていくのかっていうのを考えていかなければいけない。で、この改善がもし見られなければ、おそらく取っているデータが不適切か、もしくはもしかしたらそもそもこういうデータのサイクルと言いますか、学習サイクルが回らないような領域かもしれないというのを考えていくべきかもしれないなと思いますね。

この辺は例えばSaildroneっていうスタートアップ。これは海洋データとか海洋監視のスタートアップですけれども、彼らは機体を売らずに海上のミッションとかデータを提供する会社で、運用データが直接自分たちに蓄積されていって、それが次に繋がっていくというようなことをやっている、無人の水上艇を設計している、あるいは製造している、運航しているスタートアップだったりします。本当に自分たちで機械を作って、その機械を販売するんじゃなくって、海洋観測の結果とか測量とか監視データ、これをフルマネージドで提供していくのがこのSaildroneというスタートアップになっています。あとAPIとかで一体的に管理しているみたいなところかなと思います。

ではですね、どのように実装されているのかについて少しお話ししたいと思います。いくつかのパターンがあるという風にAIには整理してもらっています。1つが完成作業請負型ですね。これはこれまでお話ししてきた中だと、テラファーマとかMonumentalとかいうところが該当するかなと。ここは建設とか土木とかいうところで割と見られるところかなと思っています。こうした場合は、例えば現場のデータとか自社のオペレーターとかロボット機材を自分たちで持って、その結果を使って次をよりやりやすくしていくみたいなことをやっているパターンなのかなと思います。なのでここは完成した壁とか土木工事みたいなところを売っているっていうのが、このテラファーマ、Monumentalに代表される完成作業請負型というところですと。

次が導入一体型というところで、こちらはJetsonとかアフォーミックみたいなところ、Jetsonは私が紹介したところかなと思いますが、住宅の設備とか工場のロボットとかに関して、顧客の接点から見積もり、そして設計、導入の施工とか遠隔の監視とか、この辺りまで一体的に行っていく。そして機器導入に伴う許認可とか補助金とか施工の分断というのを一手に引き受けている、そこの摩擦を少なくしているというスタートアップではないかなと思いますと。

3つ目が規制事業者型っていうことで、講義とかファーボナジーとかが1つ挙げられていますけれども、この保険とかっていう領域において、UI、UXで顧客接点を取って、その後の引き受けの業務フローとか価格とか商品設計、あるいはデータというものを使って業務を統合していくみたいなところをやっているスタートアップなのかなと。規制ってどうしても色々と複雑だったりするので、この辺りをうまく統合してスムーズにしているというようなスタートアップではないかなと思います。

類型は別に排他的なものではなくって、同じ会社が市場とか成長段階によって組み合わせていくこともあると思いますし、ここ前回と違うのは、成果契約だけではなく、そして完成物だけに限定せずに、他のところにも色々とこのバリューチェーンを伸ばしていって垂直統合していくみたいなところは使えるかもしれないなという話として見ていくといいのかなと思いました。

スタートアップで入ると考えた時に、どれが1番スタートアップ向きかっていうのはありますか?

難しいですね。正直、資本をどこまで負担するのかっていうところと標準化の可能性みたいなところの組み合わせで決まってくるのかなと思ってます。初期にはその導入一体型みたいなところが比較的始めやすいのかなと思いますが、これは間違えるとコンサルティングになっちゃうというか、顧客ごとの個別対応に留まる危険性もあるというところですと。一方で完成作業請負型に関しては、データが直接得られるというメリットがある一方で、事故とか施工とか人員管理みたいなところをしていかなければいけないのでなかなか重いと。あと規制事業者型は価格決定力は高まり得るけれども、法的責任とか、保険だったら資本の構造と言いますか、自分たちである程度自前で持っておかなきゃいけないので、そこの設計とかは難しかったりする。というので、優劣があるわけではなくって、いろんな条件によって決まってくるものかなと思いますね。

宇宙でもこうしたところで言うと、顧客が衛星を持たずにミッション実行を買うみたいな例としてLoft Orbitalみたいなところがあったりします。標準衛星を調達して、顧客ペイロードの統合とか統合試験、あと打ち上げ、運用していって、宇宙ミッションをサービスとして提供していくみたいなスタートアップがあったりはします。これなんかも割とこの導入一体型に近いところかなとは思いますね。以前紹介したところで、この辺りは、Andreessen Horowitzが結構前ですか、2023年に出していた「Full-Stack Startups: American Dynamism」という記事の中で、政府関連とか物理とか産業とか企業、既存のそうした技術を販売しづらいような領域においては、スタートアップが完全なフルスタックで製品とかサービスを構築して市場に入っていく余地があるんじゃないかということを紹介していた記事があったりしました。

では、こうしたいくつか実装のパターンを見てきた中で、本当にこれをやっていくとしたらどうしていくのかというのをまとめたのがこちらになります。1つ目がやっぱり、成果だけではないとはいえ、成果連動型だとすると、その成果に対してお客様が本当に対価を払うかどうか、誰が払うのか、そして何をもって検収、成功とするのかみたいなところを、有料案件で確認していく。そのためにコンシェルジュMVPみたいな感じで手作業で成果を完成させていくみたいなことを考えていくのが1つかなと思ってますと。顧客が本当に成果に払うのはどこなのか、そしてそこのボトルネックは本当はどこになるのか。こうしたものを手作業で確認していくのがまずフェーズ1としてありますと。

そしてフェーズ2として、その成果を左右する工程、例えば見積もりなのか設計なのか分かりませんが、それを自分たちでシステム化をしていって、成果への影響が大きいところ、共通性の高いところをシステム化していって、それによって納期とか品質とかあるいは原価というものが実際に改善するかを確認していくのがフェーズ2で、その後は反復作業として、フェーズ3としてSOPとかルールとか教育、あるいはパートナー認定を整えて、中央で、より早く案件処理能力を増やしていくみたいなところで、そうした人を増加することによって案件処理能力を伸ばすみたいな、そうしたことをやって拡大していくというのが1つポイントとしてあるのかなと思います。

で、新しい案件と言いますか、新しいお客様ほど粗利が上がって、手戻りと人間の介入が下がるかどうかっていうのを1つのメトリクスにして見ていくと、このモデルがうまくいく領域なのかどうかっていうのが分かってくるかもしれないなと思います。で、もし改善しなかったら単なる受託会社とかになっちゃう可能性があるので、ここに関しては注意して見ておく必要があるかなと思います。

いや、結構その単なる受託会社になってしまう危険性があるっていうところで、最初からそのコンシェルジュ型MVPとか、特にその顧客に最適化することによってそれを繰り返すと、結局単なる受託会社になってしまう可能性もあると思うんですけど、どういう点に気をつけてMVP、フェーズ1、フェーズ2を進めていくといいんでしょうか?

そうですね。難しいなと思うんですけども、1つポイントがあるとしたら、顧客の要望を全て受けるというわけではなくって、自分たちが最終的にやっぱりこういう成果を出していく、これだったら多分可能になるんじゃないかっていう成果の仮説をちゃんと持って、それを定義して、顧客の中でこの部分をやりますっていう、狭く固定していくことっていうのが1つ大事かなと思います。個別要望じゃなくて、あくまで自分たちの仮説をベースに、ここの成果を取りたい、ここの成果をちゃんと自動化できるかどうかを確認したいので、ここだけをやりますというのをちゃんと固定し、狭く定義しておくことってのは大事かなと思いますと。で、お客の要望がもしあれば、有料オプションとか断るとかいうのもいくつかあったりすると思うんで、ここに関して、あるいは自分たちの標準に入れるのかどうかっていうところも含めて検討しつつ判断していく、単なる受託にならないように気をつけておくべきかなと思います。あとは、学習目的の手作業なのか、それとも個別の受託のための手作業なのかっていうところをちゃんと考えて引き受けるというのがポイントではないかなと思いますね。

この辺り、例えばMachina Labsっていうところ、米国の金属の製造をしてるスタートアップですが、作業とロボットの判断を工場に蓄積して製造事業者に移るというようなスタートアップです。これはRoboCraftsman技術っていうのを販売しているスタートアップでもあるんですが、自社で自ら知能化された工場というものを建設して運営して、デジタルの設計から金属の構造物の生産まで提供してるスタートアップです。成形から溶接、組み立てを1つの生産システムとして統合して、部品とか構造物を納品しているスタートアップで、こうしたところもあったりするので、最初は自分で手作業をやりつつ、徐々に知能化された工場っていうのをちゃんと作っていくというのが1つポイント、そうしたことをやってるところがあるのかなと。ここはシリーズCで1.24億ドルを調達しているスタートアップだったりしますね。

ではどうやってこれを大きな事業にしていくのかというところのお話をしたいと思います。まずですね、スケール時の事業構造と真のモートというものをきちんと把握しておかなければいけないかなと思ってます。自分たちが集約するべきものとして、例えば商品とか成果の定義とか標準の仕様みたいな、いわゆる顧客に何を納品するべきかとして、自分たちで考えておくことですと。あとは見積もりのモデルとか業務用のソフトウェアと言いますか、見積もりから設計、品質管理とかあの辺りを共通ルールにして、案件ごとの判断を記録して

おきながら自分たちのモデルを良くしていく。そして業務用のソフトウェアというのも自分たちで良くしていくというところが、1つポイントとしてはあるのかなと思います。

あと、一方ではその外部化していく、地域とかパートナーに任せていくというところが必要で、そこをどう区切るのかって感じですね。一般施工とか緊急対応とか、地域固有の許認可みたいなところに関してはおそらく共通化が難しいので、地域のパートナーとかに任せていくというところが必要になってくるのかなと思います。

で、もちろん外部化したとしても、写真とかセンサーデータとか手戻りの理由とかは自分たちが把握しておくってのもあるかもしれませんし、場合によったらそのパートナー企業に関して評価をしていく。例えば価格だけではなくって、本当にそのパートナー企業さんがちゃんと検品っていうか検収されたのかどうかとか、納期が遵守されたのかとか、そうしたところをきちんと考えておく、あるいは評価の基準を作っておくっていうのが1つあるのかなと。

で、この辺りやっぱりうまくやられないと、昔あったKaterraみたいなスタートアップがありまして、ここは建設系のスタートアップだったんですが、垂直統合して失敗したというところになります。かなりスコープを広く拡張していったというところだったので、固定費がかなり高くなっちゃって、組織の複雑性も上がって、学習速度がなかなか上がらなくて、その結果失敗したと。かなり調達をしたんですが、失敗したという風なスタートアップがあったりするので、やはりその自分たちはどこまで学習をできて、自分たちの学習成果をどこまで押さえるようにできるのかというところが、おそらく大きな事業にしていく時のポイントなのかなと思います。

いや、結構そのやっぱり境界を決めるのが難しいなとは改めて思って、どういうその項目ごとで決めるってよりは、もう少しそのこういう条件のものをこっちに寄せる、あっちに寄せるっていうような判断をするんだろうなと思うんですけれども、どういう点に着目して判断するといいんでしょうか?

そうですね。1番はやっぱりその成果にどこまで影響するのかみたいなところかなと思います。自分たちが成果を出す上で重要なポイントをちゃんと押さえておくのが大事で、あとは共通性があるか、案件間で共通的な部分なのかどうかとか、あとは自分たちが制御できるのかどうかとか、場合によってはその事故時、失敗時の損失がどれぐらいなのかどうかみたいなところ。成果への影響とか共通性が高いものはなるべく中央と自分たちに残しておく。そして自分たちで制御できるようにしておくというのが大事ではないかなと思います。

この辺、例えばBlocPowerみたいなところ、これは建物の電化をしていくスタートアップだったりしますが、彼らは建物の診断と、そして補助金など、建物を建て替えると言いますか、リノベするみたいな感じの時の資金調達とか、機器の選定、施工の管理、運用というのを1つに束ねて、お客が個別に事業者に調整せずに電化とか省エネの改修を進められるという風な形を作っていますが、まさに彼らはソフトウェアを自分たちで作って、それを改善しながら、プロジェクトのファイナンスまではいかないかもしれませんが、その補助金とかの資金調達とかを含むその改修っていうのの支援というものを全般的にやっていく。そこで学んで、それをどんどん展開していくというのをやっていったみたいなスタートアップだったりします。

では最後に、このアプローチから学べることということで学んでいきたいと思います。DXをするのではなくて、ツールを提供するのではなくって、自分たちが事業者になっていくというような、そうしたアプローチを紹介してきましたが、いくつか学べるところがあるのかなと思います。

所有するべき点、フルスタックにしていくと言っても、所有するべき点は全ての工程というわけではないということです。成果とかデータとか品質とか価格に強く影響するような工程というものをきちんと絞って、その制御点をちゃんと押さえておくこと。これが大事だと。で、それで学習できるデータ環境を作っておくとか、成果をちゃんと出せるようにしておくってのが大事ではないかなというのが1つのポイントです。

もう1つのポイントが、創業初期に関しては、完成形ではなくって学習手段として、いろんなものを手作業でやっていくというのが1つポイントではないかなと。「Do things that don't scale」ではないですけれども、手作業から共通判断とか例外を発見して、段階的にシステムに置き換えていくこと。その工程がAIによってより長くなってきているので、そこも含めてどこまで自分たちが伸ばしていくのかを考えながら、その学習をしていって、より長く提供していくのがいいんじゃないかというところが1つ。

で、3つ目が、売上の規模というのも大事なんですが、同時にやはりこの改善ができてるかどうかっていうところをきちんとメトリクスとして追っていくことです。案件数が増えたとしても、そこで同じ人手とか例外とかが発生しているのであれば、それはスケールしているわけではなくって、受託事業が肥大化しているということでしかないという風に考えると、やはり見るべきなのは、次の案件って言いますか、次のお客様で自分たちのソフトウェアとかロボットとかがよりうまく使えるようになっていて、より原価率が下がっている、粗利率が上がっているという風な状況をちゃんと作れているかどうか。これが作れていれば最大の堀になっていくであろうということが言えるのかなと思うんです。

あとはそうですね、最後、既存企業にツールを販売するだけでお客が望む成果を自力で達成できるかという問いに「No」というのがあれば、もしかしたらそこが事業機会として、販売というのは自分たちが乗り換え、置き換えていくことができるかもしれない。そうした観点でこのアプローチを見ておくといいのかなと思いました。では、こちらがいかがだったでしょうか?

そうですね。うん。なんかこう、垂直統合とか成果を提供するって言うと、全部自分でやるみたいな風にも一見聞こえがちなんですけど、そうじゃなくて、なんていうか、コントロールできて成果に直結する部分はちゃんと自分で持って、それ以外のところはパートナーも活用しつつっていうところの、その線引きというか境界を決めるところがすごく重要なんだろうなっていう風には思いました。なんかそうですね、学習を回しつつ、自分たちで握るところは握るっていうその設計がすごく難しいんだろうなというのは思いました。

そうですね。あえて期限にしておくとかも1つの方法かもしれないですね。仮説を持って、ここまでにこういう風なメトリクスじゃなければ、それじゃないと受託企業になっちゃう。それぞれ1つの生き方だとは思いますが、スタートアップとしてスケールしていくんだったら、連続的に何件案件を受けて、2年後までにここまで原価を下げておくみたいな、そういうハードルを自分たちで用意しておくっていうのも1つの方法かなと、今回まとめを見てて思ったところです。

はい。それでは今日はこちらで終了です。FoundX Review Startup IdeaCastでは、今後も皆さんのアイデアや事業作りの参考になるスタートアップの戦略アプローチっていうものを紹介していければと思います。ご興味のある方は是非チャンネル登録をお願いします。またFoundXの各種プログラムでも応募者を募集しております。周りに起業を考えている方いらっしゃれば、是非FoundXをご紹介ください。ではまた次回よろしくお願いします。ありがとうございました。

ありがとうございました。