個別案件を「反復単位」に変える：モジュール化・データ・資本戦略の関係

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

同じくFoundXの富田です。

今朝Fable 5.1が出てて、早速色々使ってます。

ああ、そうなんですね。どう違いますか、やっぱり。

いや、ちょっとまだわかんないですね。ちょっと安くなってるみたいですけど。

私も使ってみようと思います。

是非。なんかリセットもされてて、だったらもっと早く今週使っておけばよかったなと思いました。

え、あ、そうなんですか。リセットもされてるのは結構いいですね、それは。

はい。ということで、これを使いながらですね、また色々と調査していければと思います。

そんなAIを使ってIdeaCastをやっておりますが、FoundX Review Startup IdeaCastは海外のスタートアップをAIを使って分析しながら、今回はスタートアップの戦略とか事業の組み立て方というところを解説していく形になっております。これからアイデアや事業を考える人たちの参考になればと思います。

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

ということで、今日はプロジェクトの反復単位化ですね、モジュール化みたいな、そういうタイトルで、前回分析したものの1ページ、分析編の中の1ページのこの反復単位化というところを取り上げていきたいと思っています。

確かにモジュール化の話は結構これまで取り上げてきたなと思うので、それのまとめになるのかなと思うんですが、今回この戦略を取り上げる理由ってどういうところでしょうか?

そうですね。これまで私たちはハードウェアとか、そういう系のスタートアップを色々と紹介してきたんですが、こうしたスタートアップとか、建設とかエネルギーとかもそうですけれど、需要があってもその案件を実行できるようなオペレーション体制を組むのが難しかったりとか、資金が不足して成長は止まりやすいというところがあって、売上を増やすたびに人が必要になるような、あるいは一品物が続いていくようなものはなかなか規模の優位性につながりづらいので、このプロジェクトの反復単位化、モジュール化みたいなところをやっていかないとなかなかスケールしないんじゃないかと。で、スケールした時にもこのモジュール化ができているとファイナンスの利用可能性も変わってくるという、結構重要な考え方かなと思うので、ご紹介させていただこうかなと思っているところです。

では早速全体像のお話をさせていただきたいと思います。運用の制約から資本拡張への因果連鎖という形で、スライドが見えている方はスライドをご覧いただければと思いますが、結局、モジュール化とかをしていくといろんな形でオペレーションが楽になって、さらにそのオペレーションが楽になって可能になると、そこに対して低コストの資本が、うまくプロジェクトファイナンスとか証券化とか、そういうところを使ってファイナンスもしやすくなって、さらに成長していけるというようなことを説明しています。やはり簡単に作れるということだけではなく、その再現性を持っていけるということがファイナンス上非常に大事で、ここをやっぱり非常に重視していく必要があるのかなと思っています。

一方で、簡単にモジュール化すればいいというわけではなくて、顧客の要望をちゃんと聞いて、どういった条件とどういった成果であれば、どういったモジュールで成果を保証できるかというところをきちんと考えながら、それでオペレーションを回せるようにして、接続面と言いますか、インターフェース、案件間で変わらないようなインターフェースをちゃんと確立して反復可能にしていく。例えば配管の大きさであるとか電圧とか通信規格とか、そうしたものを案件間では変えないようなインターフェースをちゃんと用意して、そして分散を局所化した上で、手戻りもなくどんどんとモジュールを反復していけるようにする、そうしたことをやっていく。

で、これが実はデータの蓄積にもつながっていくと。異なる要件と言いますか、異なる案件で異なる状況でデータを集めてもなかなか比較できなかったりするので、なるべく同じ条件を揃えてデータもうまく蓄積して、それを学習とか、あるいは次のファイナンスにつなげつつ、ファイナンスをうまく使って大きくしていく。この流れを作っていくために、モジュールのような、反復可能にしていくということが非常に大事だというのが、このアプローチの全体像なのかなと思っています。

物理的な設備の小型化とかコンテナ化だけでは不十分で、この提供する工程全体の不確実性というものをうまく排除して初めて、このファイナンスまでたどり着けるというのがここのポイントではないかなと思います。

今、コンテナ化したり小型化したりするだけだと不十分ということだったんですけど、それはどうしてそれだけだと足りないということになるんでしょうか?

そうですね。仮に設備が同じであったとしても、現地調査とかがエネルギー系だと大事だったりしますし、基礎工事とか電源とか、系統への接続とか許認可とか保証とか、そうしたものが毎回異なると、見積もりとか工期の変動にかなり影響してきてしまうというところがあります。そこも含めてモジュール化していくと言いますか、反復可能にしていくというのがポイントだったりします。

あとは顧客側のインターフェースと言いますか、制約とか受注条件というのをちゃんと一定にしておくということもしておかないと、顧客との調整作業が残っちゃうとなかなかそこも時間がかかっちゃうとかなので、本当にいろんな意味の標準化、認証とかの標準もあるかもしれませんし、内部的な工程の標準化というもので、機器とか案件の選定とか接続面とか施工とか契約、検査まで含んで標準化をしていくというのが、実は設備をコンテナ化したり小型化するだけではない重要なポイントなのかなと思います。

で、ここで例えばですね、Redaptiveというスタートアップ、こちらはエネルギー・アズ・ア・サービスのスタートアップになるんですけれども、これは運用の標準化が実際に資金の調達方法を変えた例として、このRedaptiveというところは、企業施設の診断とか設備導入、資金提供とか保守とか、独自メーターによる効果計測で提供していくというところで、まさにこの顧客に対しては初期投資なしで導入して、エネルギー削減または発電成果にも結びついた性能契約というのを用いているというところです。彼らは診断から施工契約、継続契約というのを1つの反復工程にして、この資産群をクレジットファシリティに接続していくというところです。

いわゆるSunrunとかが住宅用の太陽光の展開を中心にするのに対して、このRedaptiveというところは大規模な企業施設のポートフォリオを対象としているというところで、成果を計測するような標準手段まで持つことによって、顧客への請求と金融機関への説明というのを同じデータで行っていく、ファイナンスまでつながっていく、そうしたものをやっているところがあったりはします。

似たようなところだとEnpalみたいな感じですね。Enpalはドイツのスタートアップですけども、住宅用太陽光とか蓄電、ヒートポンプをやっているところですが、住宅用設備でもですね、同じように運用実績から証券化まで進んでいく、リースとかローンとかまで用意していくみたいなことまで彼らがやって、複数の住宅のローンとかリース債権をまとめて資本市場に接続してファイナンスをやっていくというところもやっているスタートアップがあったりはします。

この辺、ミヘリベンジャーズというところがですね、Unlocking Project Finance for Climateみたいなことで、Funder's Guide to Bankability、いわゆるバンカビリティにたどり着くまでのクライメートテックのガイドみたいなところを用意していて、新技術の大規模導入においてはこの技術だけではなく、開発とか保険とか契約とか金融の関係者を組み合わせてリスクを低減していって、プロジェクトファイナンスまでたどり着くという、そうしたことを記事でまとめているところがあったりするので、こういうところもちょっと見ていただくといいのかなと思いました。

では、このモジュール化、あるいは反復化というところ、どんな問題構造に対して有効なのかというところのお話をしたいと思います。まずは悪循環のケースからお話しすると、個別要求に適用していく、いわゆる受託的に近いところにやっていくと、非反復的な設計とか調整費用がどんどんかかってきて、ここでコストが発生しますと。さらに毎回違う設計とかになると見積もりの誤差とか手戻りが発生しやすくなって、それによって金融機関は、毎回違うことをやっていたらそれって反復可能なビジネスになってないよねという形になって、金融機関からリスクを指摘されて審査が不利になって、ファイナンスもつきづらくなって、その結果さらに労働集約的な対応をせざるを得なくなって、また個別要求への対応をしていくという、そうした悪循環が起こりうるのが、いわゆる一般的な問題と言いますか、状況ですと。

つまり売上が増えてもですね、設計する人とかPMとか、あるいはそこに関わる人が比例的に増えてしまって、結局儲からない、生産性が停滞してしまう。いわゆる需要不足ではなくて、その案件ごとの複雑性による供給能力の限界と金融的制約がなかなか満たせないというところがスケールを阻むところがあります。

もちろん人員を増やして短期的に受注処理はできるんですが、それはファイナンスになかなか紐づかないということで、ここをなんとかしていかなければいけないというのが、まず問題の構造としてあるのかなと思います。

個別対応を減らしていくということにはなってくると思うんですけど、そうした時に顧客から見える価値というのは変わらないように設計していくということでしょうか?

そうですね。まさに外部の多様性と内部の対応性を分けていく必要があって、外部に関して顧客、お客様から見える選択肢というものはある程度残しつつ、自社内では共通モジュールとルールで処理する。多分、昔紹介したRobCoみたいなところで、ロボットのモジュールをうまくつなげて処理していくみたいなスタートアップがあったと思いますが、まさにお客様からは、選択肢を全て提供するわけではないんですが、このモジュールをうまく組み合わせて提供できる範囲の選択肢というのは残しつつ、中ではそれをうまく組み合わせるような仕組みを作っておく、ルールを作っておく、そうしたことが1つあるかなと思います。

そうした意味で、ある意味お客様の全ては解決できないけど大部分を解決できるような、反復可能な設計とかモジュールにしておくというのは非常に大事な設計の部分なのかなという風に思います。どこまで必要なのかというのを本当に見極めておくとか、とはいえお客様からいろんな要望があった時にどこまで対応するのかというのは、ここはSaaSと同じかもしれませんけれど、どこまで機能追加していくのかとか、あるいはハードウェア系でいけば基礎技術とか施工方法まで変える要望があった時には、場合によったら断るということも必要なのかなと思います。

では続いて、どこでこのアプローチが使えるのかというところのお話をしたいと思います。このアプローチですが、成立しやすい条件、しにくい条件があるのかなと思っていて、まずしにくい条件から行きますと、要求がバラバラな市場に関しては基本的にはあまり適さないですと。あと現場の物理とか地質差というものが極めて激しく変わるようなところもなかなか難しかったりしますと。あとコア技術が頻繁にアップデートされるようなところに関しても、ちょっとなかなか難しいのかなと。あと案件ごとの特殊デザインとか意匠性が求められるところは、やっぱりこのモジュール系とか反復化のものは難しいです。

一方で成立しやすい条件としては、やはりこの高頻度で似たような問題が発生しやすい市場においてはうまくはまりやすいのかなと思います。あとは接続インターフェースが安定していたりとか標準化可能だったりするというところに関してもうまくいきやすい、接続面という感じですね。あと技術の成熟度に関しても、技術要素がある程度枯れていて、統合と実行が課題ですというところに関して、このモジュール系は割とはまりやすい。そして最後、価値の源泉というところですが、予測可能な成果、稼働率とかコストとか、そうしたところが予測可能であれば割とはまりやすいところなのかなと思います。重要なのは本当にこの同じ設計を何回使い回せるか、そこが適用できるかどうかというのが、割とこのアプローチの有効なところなのかなと思います。

同じ設計を何回使い回せるかというところで、高頻度で似たような問題が発生するということなんですけど、どうやって測るというか、どういうところに着目するとその構造って見えてくるんでしょうか?

例えば何件かの案件の中で標準的な条件を満たす割合がどれぐらいなのかとか、売上案件のうち標準的なBOM、ビル・オブ・マテリアルズで一定割合以上再利用できる件数がどれぐらいなのかとか、あとその例外とか設計変更の件数、あるいは同一地域で連続して施工できるような案件数とか、そうした、どれぐらいその案件の類似度が高いのかどうかというところを割と分解しながら見ていくというのが1つポイントなのかなと思います。

その要件の分布がある程度限定的かで、その要件というものの評価軸というものがある程度決まっているというところが1つ大事なところかなと思うんです。で、そうした技術要素がさらに成熟しているところに関しては、そこにプラスして標準化による可能性というところを割と出していけるというところがあるし、統合とか施工とか金融というところに課題を移していくことができるので、こうしたところもファイナンスしやすさというところにつながっていくのかもしれないなと思います。

そうですね。この辺りスタートアップとしては、例えばDandelion Energy、これは住宅用地熱ですけれども、地質差が大きければちょっと難しいかもしれませんが、Dandelion自体はこの住宅の近くに地熱を使う設備を作るという感じですが、設計とか掘削、施工、金融を1つにまとめて、顧客の調整負担を減らして、ヒートポンプ単体では販売せずに、地中のループ設計から施工の一体的な提供をしていくということをやっているスタートアップでした。

ここは割と反復可能な形にしていると。技術要素もそこまで深くは変わらないので、住宅の要件と地質の要件というのをどこまで標準化できるか、おそらくこのビジネスの成否というものを左右してくるのかもしれないなと。多分屋根置き太陽光とかよりは地質条件がちょっと違うので、標準化しづらいところではあるのかなという印象はあります。ただ一方で、顧客が1個1個調整していかなくても、Dandelion Energyに頼めばある程度工程統合して一括で受けてくれるので、そこは楽というところはあるかもしれないなと思います。

では何をどう設計するのかというところの説明をしたいと思います。ここはですね、いろんなビジネスによっても違うとは思いますけれども、まず顧客側の条件というのがありますと。既存アセットとかがあって、そこに対して接続条件を定義していく。例えば適合判定アルゴリズムとか自動見積もりとかを、AIとかうまく使って自動的にやって、それに対して自分たちの標準設計とかBOMとか施工手順、標準的な施工オペレーションのプロシージャーを当てはめていって、その上にデータ収集とか品質とか遠隔管理とか、そうしたことをやって、そこを自分たちでコントロールしながら、それを実現するためのハードウェアとかを自分たちで作る場合もあれば外注して作って、そしてそれを組み合わせて現地で統合していく、施工していくという、そんな感じになっていくのかなと。

標準的なハードウェア、汎用ハードウェアとか標準的なハードウェアまで至るための柔軟性と言いますか、1個1個の現場の違いをどこまで吸収できるのかというところを、ソフトウェアをうまく使って判定してやっていくというパターンが比較的多いのかなと思います。

現場の写真とか設備のデータとか測定とかをちゃんと自分たちでやって、標準にいかに落とし込んでいくのかというところが大事なのかなという風にも思います。

なるほど。結構施工の手前を自社でやるということなんですけど、施工を逆に外部化しても品質を保証することというのは可能なんでしょうか?

そうですね。ここも頑張れば可能かなとは思います。例えば施工の工法とか作業の順序というのを決めておくとか、検査とか写真とかセンサーデータみたいなところを標準化していれば可能性は高まります。一方で、もちろん施工会社のばらつきとかがあるので、例えば施工会社に関しては認証をするとか、教育をするとか、監査、あるいは再施工のルールとかみたいなものを契約で縛っておいて、ちゃんと自分たちの通りやってくださいというところをやっておく感じかもしれません。単純な外注ではなくて、管理にその辺りもしていくというところがポイントかもしれないなと思います。

場合によってはハードウェアとかも自分たちでやる場合はあるとは思いますけどね。汎用ハードウェアは安く外部調達できるし、工場投資を抑えられるというメリットもあるんですが、一方でそこは供給側の外部の品質とか供給停止リスクみたいなところが乗っかってくるので、特殊な部品とかがもし非常に大事であれば、そのハードウェア製造も自分たちが巻き取っていくというところもあると思います。その辺もやっぱりフルスタックに近くするのか、それともどうしていくのかというところは判断なのかなと思います。

いずれにせよ物理アセットとかを所有するか所有しないかではなく、どちらかというと顧客成果、アウトカムをどう保証していくのか、そのために自分たちが持っておくバリューチェーンというものはどこまでなのかというところを考えておくのが大事だろうと思いますし、場合によってはこの1番下の適合判定アルゴリズムみたいなところで、自分たちのものが合うかどうかで、合わないと思ったらそれに対してやっぱり断っていくという、そうした割り切りというのも大事、ある意味自分たちがコントロールできる範囲なので、ここも考えておくのが大事かなと思います。

例えばこの辺、先ほどRobCoみたいな話をしましたが、他にも例えばFormicという米国のスタートアップですが、彼らは既製のロボットを利用しながら、用途の選定から設計、設置、監視保守、SLA、そして資金提供をまとめてやってますと。汎用ハードウェアを使いながら、自分たちのお客様に対してその柔軟性をある程度このコントロールポイントとして自分たちが持って、汎用ハードウェアは扱い、そして成果を左右する、例えば運用とか契約とかデータに関しては自分たちがバリューチェーンとして持つという、そんな感じなのかなと思います。

RobCoが自分たちでモジュール型ロボットのハードウェアを製造していくのに対して、Formicはどちらかというと複数メーカーのロボットを柔軟に使っていくという違いがあると。技術の発明よりも顧客が使える状態にする工程的な障壁があるというところを見せるとFormicの方がいいかもしれませんし、いや、むしろハードウェアの方が実は重要なんだと言うのであればRobCoの方がいいかもしれないとか、この辺は割と攻め方が違ってくるのかなと思いますね。

この辺はもしかしたらAndreessen Horowitzのフルスタックスタートアップ系の記事、Full-Stack Startups for American Dynamismとか2023年にも出てましたけども、とか、フルスタックスタートアップの2015年の元々の記事とかを見ておくと、既存企業に技術を販売する代わりに、技術を組み込んだ最終成果、製品みたいなところを提供していくポイントが分かりやすくなっている文章なのかなと思います。

では、なぜこうした、フルスタックと言いますか、反復可能なものがモートにつながっていくのかというところのお話をしたいと思います。ここはですね、やっぱり標準化されたインターフェースとかモジュールとか、あるいは繰り返し可能な状態にしておくことによって、個別設計とか見積もりというところを劇的に改善することが可能ですというのが1つあります。これはソフトウェアとかもそうだとは思いますが、こういう機能でスケールしていきます、こういう機能しかありません、ただこういう機能であればはまるので使ってください、というところは1個あるのかなと思いますと。

で、さらに標準化されたインターフェースとか標準があると、歩留まりと学習曲線を辿っていけると言いますか。例えば最初の施工とか製造で手直しせずに基準を満たした割合を上げていくことができますと。ライトの法則、学習曲線ですけども、に関しては、累積生産量の増加と費用低下が経験的に関係していくということがあったりするので、このライトの法則というところをちゃんとやっていく。反復していくと失敗率が低下していく、労働コストも低下していくというのがポイントとしてあります。

で、かつ運用データの蓄積もしていけるというのがポイントで、やはり毎回違う状況の案件だと、データが集まったとしても比較可能ではないというところですが、一方でこのモジュール化、あるいは反復可能な状況にしておくと、データ同士を比較可能にして、活用可能にして、稼働率とか故障率とか残存価値とかが統計的に予測可能になったりとか、より学習が可能になっていく。その結果、最終的に予測可能になってくると資本コストの低下、バンカビリティが上がっていくということで、プロジェクトファイナンスとか証券化とか、そうしたファイナンスの仕組みというところもうまく使えるようになってくる。そうなると、どんどんとまたスケールの法則が効いて、ファイナンスが手に入ると、スケーリングの次の手を打てるようになって、さらにそのスケーリング、規模の経済が効いてくると、さらに学習曲線も下がってデータも蓄積してさらにバンカビリティが上がっていく。

この正のループみたいなところをちゃんと回していくことが非常に大事なのかなという風に思います。

運用データを蓄積してそれがバンカビリティにつながるということなんですけど、金融機関には具体的にはどういうことを説明するようなものなんでしょうか?

そうですね。まず建設費と完成時期の予測の誤差みたいなところが1つあるのかなと思いますと。あとは稼働率とか故障率とか修理時間、あるいは性能の劣化がどれぐらいなのかとか、あと顧客の契約期間とか解約率とか延滞率とか、支払い者の信用であるとか、あと保守費用とかですかね。そうした、悪い条件を想定した時のデットサービスカバレッジレシオみたいなところとかも含めて、金融機関が気になるところ、特に銀行が気になるところをちゃんと見せていくというのが大事かなと。あとプロジェクトファイナンスにおいては、資産とか契約とか保険とか口座とかキャッシュフローの辺りも見られる可能性が高いんじゃないかなと思います。

データと言ってますが、単なるデータ量があればいいというわけではなく、このデータによって競合よりも正確な適合性の判定とか見積もりとか保証判断ができているかとか、次の案件の粗利とか工期とか成功率が改善しているかどうかとか、そのデータの取得というものが自社の運用工程に組み込まれていて、競合がなかなか同じデータを得られないとか、そしてデータがソフトウェアとかに反映されて学習にうまく使われて、担当者が変わっても再利用できるとか。データが多ければ多いほどいいというわけではなく、このモートにつながっていくデータをちゃんと蓄積できている仕組みを整えられているかどうかというところが、おそらく最終的にモートにつながっていくところなのかなと思いますね。

この辺だと、例えば太陽光は割とバンカビリティが高いようなところだったりしますが、Terabase Energyという米国の大規模太陽光施工のスタートアップなんかは、発電所の設計、物流、そしてロボットの支援施工とか現場データ、そして運用ソフトを統合して、太陽光パネルの設置というものを現場ごとの人力の作業にはせずに、テラファブという移動型の施工システムとデジタル工程をうまく使って、本当に同じ施工単位で反復可能にして、設置速度とか品質とか作業人数を改善していくという、そうした構造を作ろうとしているスタートアップがあったりします。

先ほど少し紹介したSunrunなんかは住宅ごとの小口の設置であるのに対して、Terabaseはちょっと大規模なところなので、大量にロボットを使ってどんどん置いていくということができるかもしれないということをやっている、そうしたスタートアップがあったりはします。ここもですね、反復可能にすることによってファイナンスがつきやすくなるというメリットはあるのかなということがあったりはしますね。

この辺、Eclipseというところがですね、エンプティハウスインミシガンtoシリコンバレーみたいな、そうした記事を書いていて、ここでは物理産業の企業においては、ハードウェアとかソフトウェアとかインフラ、そして供給網、データなどを組み合わせる多面的な会社の構築が必要になるというような、そうした記事を書かれてたりします。複雑性というのは参入障壁になり得るものですが、それは正しく統合できるかどうかが前提であって、というようなところを説明しているので、この辺りも少し見てみるといいのかなと思いました。

では事例の検証ということで、成功例、失敗例を見ていければと思います。まずですね、失敗例から行くと、有名なのはおそらくKaterraですね。このKaterraというところは20億ドルぐらいを調達した後に2020年に破綻した、いわゆるフルスタックの建設系スタートアップだったりします。ここはですね、もう本当に建設から設計、供給、工場まで自分たちで広く統合して組織化していこうというところだったりしますが、残念ながら過剰に自分たちが保有してしまってなかなかうまくいかなかったとか、標準設計が凍結する前に工場設備に投資してしまったせいで、需要の同質性というものが不足してしまって、なかなかスケールしなかったというようなことがあったりはしました。

一方で成功例としては、最近だとFervoとかですかね。Fervoなんかは紹介でもしたかと思いますが、同じ採掘作業みたいなところにしていく。その掘削に関しても2024年に35%の掘削学習率みたいなところを発表していたりとか、掘削費用が半減したみたいな感じで、自分たちも50MW級のやつを何個か並べて、モジュールで並べていくことによって反復可能にしていくという、そうしたことをやっている地熱系のスタートアップだったりします。で、実際に初期の商用の井戸に比べてかなり掘削時間の削減とかもできているというのが1つだったりしましたと。

あとはRobCoを先ほどから挙げてますが、その辺もやっぱりこの標準モジュールを用意して、お客様の現場に合わせてそのモジュールを組み合わせていく、共通ソフトウェアも提供しながら、モジュールの適合性というものを提供前に確認していくというようなことをやっていたりします。

あとはそうですね、Sunrunなんかは、先ほどから何度もお話ししますが、住宅太陽光を反復可能にしていくことによって証券化、金融とか契約の標準化をしていくことによってやっていったというところがあったりはしますと。初期は金融のみでしたが、今は施工能力を自分たちでも持つことになって、3.8万戸を超えるシステムを束ねた約5.8億ドルの証券化みたいなところをやって資本コストを圧縮したという、そうしたこともやって、さらに大きくしようとしているスタートアップだったりします。

成功と失敗で順番が結構鍵になってくるのかなと思うんですけれども、どういう順でやっていくといいんでしょうか?

そうですね。まずはやっぱりこの対象を狭く、再現可能なところに絞っていくというところが1つと、変えないインターフェース、接続面というのを定めていくこと。あと手作業を含めてもいいので複数回実行していって、そこの失敗とか学習を標準設計とか手順とかに戻していく。そして標準仕様が安定してから、自分たちで製造を持つのか、資産保有をやっていくのかという、いわゆるコンシェルジュ型に近いかもしれませんが、特定の用途から学習していって、その学習を回せるようなところから入っていくというのが1つポイントかなと思いますね。

ああ、そうですね。標準化できなかったことだけじゃなくて、結構市場環境とか外部の影響もあるかと思うんですけど、それはどれぐらい見積もるというか影響を見ればいいんでしょうか?

そうですね。もちろん金利とか資本市場とか、そうしたところも結構重要な要因ではあります。標準化が進んでいれば失敗しなかったということは言えないかなと。ただ一方で、設計とか費用とか工期の変動が大きいほど、外部環境の悪化に対して脆弱になるというところはあるのかなと思います。

例えば住宅系だとKaterra以外にもですね、Veevというところが割とうまくいかなかった失敗事例なのかなと思っていますが、こちらもですね、住宅設計からパネル製造、現場施工を統合して、住宅を反復可能な製品として提供しようとしていましたと。需要地の近くにファブを置いて、パネル化した住宅を設計、製造、施工しようとしていたんですけれども、ここもですね、Katerraよりも対象品を絞った形でやっていたんですが、必要な資金というものをなかなか継続的に確保できなくて、累計6億ドルぐらいを調達したんですが、2023年に次の資金調達が失敗して事業停止をしたという、そうしたこともあったりはしました。

一方で、BlocPowerなんかは、建設をやっているわけではないんですが、建物の電化をやっているところで、こちらは建物の電化の改修に金融とか施工管理、自治体との地域プログラムというのを組み合わせてやっていました。こちらは比較的うまくいってたのかなと思ったんですが、元々NPOから始まったスタートアップだったので、低所得者地域の建物に対して設備導入費とかを金融で分散して、複数の建物をまとめて回収しようとしていましたが、2026年8月にですね、一部の資産売却と再編というのを検討して、全ての債権者に返済できない可能性が報じられているという状況で、金融をうまく組み合わせてもですね、案件の反復性というものがなかなかうまくいかないと難しいという例なのかもしれないなと。Sunrunとかの住宅用太陽光とか蓄電よりは、建物の種別とか改修内容とか自治体プログラムが結構やっぱり多様で、なかなか一定の反復可能にはならなかったというような事例なのかもしれないなと思います。

では、こちらですね。最初に何をやっていけばいいのかというヒントです。このAIがまとめてくれたヒントなんですけれども、まずフェーズ1から行くと、既製品とか外部業者を使ってもいいので、まずは写真判定とか見積もりとか対象外条件のルール化、判定プロセスの標準化をしていきましょうというのが1つありますと。お客様が標準仕様とか成果に料金を払うかどうかをここで検証していくというのがフェーズ1と。

で、フェーズ2が、接続面、インターフェースの発見と手作業での反復ということで、創業者自らが数件とか数十件現場に出て、変わらない、ステイブルなインターフェースというのを見つけていく。そしてそこを変更せずに複数の案件が本当にこなせるかどうかというところをきちんと判断して記録しておくというのが大事ではないかなと。

フェーズ3が、設計をある程度フリーズ、凍結してパッケージ化していく、スタンダードなオペレーションのプロシージャーにしていくというところで、そこのフェーズ3に入って標準的なBOMであるとか施工マニュアルとかデジタルツインというのを構築していって、そしてそれを繰り返していくことによって本当に粗利の改善ができているのかとか、設置スピードの向上ができているのか、その再現性を確認できているのかというところを確認していく。こうした段階で進んでいくことによって、ある程度進んでいけるんじゃないかなという、そうした整理がなされているというところです。

結構フェーズ2までは手作業で反復するというところでかなり長いんだなと思ったんですけれども、受託のままにならないためには、どういうところに気をつけるというか、どういうことをするべきなんでしょうか?

まずはやっぱりこの目的をちゃんと決めることかなとは思いますね。手作業でやっていくことによって何を学びたいのかとか、どういうデータを取得したいのかとか、何をもってこの手作業を終えるのかというところを事前に定めておくこととか、あとは同じような判断を何回か行ったらテンプレート化する、ソフトウェアに移すといった、そうした判断をしていくというところ。なので、本当に共通パターンを抽出するために

その手作業をやってるんですよと。で、作業案件の売上で成果を評価するんじゃなくて、そのパターンが抽出できているかどうかで、きちんと判断していくってのは大事なのかなと思います。

その次に設計のフリーズをしていくってことだったんですけれども、ちょうどいいタイミングってどんなところなんですかね。結構判断難しいポイントだなと思いまして。

そうですね。複数の案件で、主要な顧客が求めてる成果とか、インターフェースが共通していき始めたりとか、標準的なコア技術とか、コアの部分を変えずに、構成の変化しやすい変数だけで案件を処理できるようになっていったりとか、あと主要な失敗原因がその技術ではなくて、施工とか運用の改善に移っているような段階であれば、フリーズしてもいいかもしれないなと思います。

あとは何でしょうね。1KOMMA5°、ドイツのスタートアップなんかは太陽光とかをやっているところですけども、彼らはまずは太陽光のソフトから入ったんですが、そこから各地の太陽光とかヒートポンプの施工会社を買収、または自分たちで作って、その上に共通ブランドとして、自分たちの1KOMMA5°っていうのを付けていった。つまり施工の能力は自分たちで最初から作るんじゃなくって、M&Aとかを通して取得するというような方法もあるのかもしれないなと思います。これは、Sunrunが金融とか契約中心の標準化をしていましたが、こちらはどちらかというと買収ですね、買収した地域の施工組織というものを共通のソフトウェアに載せていくみたいな、そうした形で広げていくっていう風なパターンもあるかもしれませんねと思いますね。

では、どうやって大きな事業にしていくのか、特に資本の構成の変化というところのお話をしたいと思います。これもフェーズ3つに分けると、フェーズ1はまず技術ですね。技術リスクと初期の学習っていうところ。ここはおそらくなかなかバンカビリティが高いとは言えないので、おそらくこれはエクイティ、VCとか、最も柔軟なVCエクイティとか、あるいは補助金とかで、やっていくのがいいのかなと。R&Dのフェーズは。

で、その後はフェーズ2でオペレーションを成熟していくところ。ここに関してもエクイティとか一部使いつつ運転資金のギャップをデットで埋めていくみたいなことが必要かもしれませんと。標準データが蓄積して、機器の稼働率とか、歩留まりの安定をさせていくっていう風なフェーズにおいては、そうした手も取れるかもしれませんと。

そしてフェーズ3は、複数の案件を束ねて、契約収入に基づくプロジェクトファイナンスとか証券化とか、そういうことをやっていく、そのキャッシュフローを元にです、予見可能なキャッシュフローを元に低コストのプロジェクトファイナンスとか、証券化みたいなところをやっていくっていう風なところが、スケールのために必要な転移と言いますか、資本構成の変化なのかなと思います。

プロジェクトファイナンスは、企業が大きくなったら利用できるのではなく、やっぱりこの案件単位のリスクとキャッシュフローがきちんと見えてくるかどうかっていうところがポイントではあるので、そこをちゃんと考えておく。そして、金融機関がプロジェクトファイナンスで入ってくるので、そのタイミングで、どういうところを金融機関が気にするのか、建設遅延なのか、性能なのか、保険なのか、解約なのかとか、そうしたところも審査されるはずなので、その辺りにもきちんと契約としているかどうかという風なところを見ておく必要があるのかもしれないなと思いますね。

その、どういう実績を持ってですね、エクイティからデットに移っていけるっていうような、そういう区切りになるんでしょう?

そうですね。いくつかあるのかなと思いますが、一般的にはやっぱ標準仕様があって、それで複数の案件が完成しているみたいな、そうした状況とか、建設費とか工期とか稼働率、あるいは保守費といったような、そうしたベースのKPIの予測誤差が小さい状況であったりとか、あとは長期契約ですね、長期の顧客契約があったり、その顧客の信用が確認できるような場合であったりとか、あと、技術が揃っていて、技術が新しいものにはなかなかバンクはつけてくれないので、技術保証がすでにある。稼働実績があるとか、保険とか許認可、供給契約が揃っているというような、割と1つの指標で考えるものではなくて、案件全体でリスク分担とかリスクが分散できてるかどうかというところが1つポイントではないかなと思います。

デットを早く使いすぎると、何か危険もあるっていうことですかね。なんかデットに頼るのが早すぎるデメリットってありますか?

そうですね。標準化前にデットとかを使うと、案件の損失が発生したと同時に返済義務が同時に発生するみたいなこともあるのかなと思ってます。特に、設置中の設備とか在庫とか保証とかを先に払うことになるので、成長していけばいくほど現金が減るのに返済しなきゃいけないみたいな状況になってしまうかもしれないので、そこに関しては、デットを使うよりはエクイティでやった方がいいフェーズもあるのかなと。もちろん、標準化とかデータ蓄積が完了する前に運転資金を拡大しちゃうと、資本構造が破綻しちゃうこともあるので、意図的にどういうファイナンスを組み合わせていくのかっていうところは、結構ここは大事な判断になるのかもしれないなと思います。

最近だとAIデータセンターとかがあったりしますが、Crusoe、結構有名なデータセンター系のスタートアップなんかは、電力、データセンター、計算設備、クラウドを垂直的に統合して、プレハブ部品とか、Sparkというモジュラー型のAIファクトリーとかを利用しているというようなところです。電力供給済みの外枠というところを提供して、モジュール型のAI計算設備を段階的に追加できるような構造を取っていて、ここは、1度に最終的な規模のところを建設するのではなく、需要に合わせて容量を追加する反復単位を作ろうとしているっていうような、いい例なのかなと思います。

大型のインフラであったとしてもですね、容量の増設っていうのを共通した単位に分けていって、いくつか紹介した電力、データセンター系のスタートアップでもいくつかあったと思いますが、そうした容量増設というものをモジュール単位にしていって、建設期間と需要リスクを段階的に処理できるようにしておくっていうのも1つポイントとしてはあるのかもしれないなと思います。

では、まとめのスライドに入りたいと思います。まず、今回の分割化していくみたいな、反復化していくっていう風なところのアプローチに関して大きくまとめると、原則が4つあるかなとまとめてくれましたと。

1つが、物理設備よりも先に案件の選び方、こちらを標準化していきましょうと。対象とする顧客であるとか現場の条件、インターフェースといったようなものをきちんと定義して、要求外とか、標準外の要求をちゃんと断っていくみたいなところが1つ。何を固定化するのかっていうところをきちんと考えておくというところかなと思いますと。

そして、その学習が行われてるかどうかっていうところを見るために、次の案件が安く早くなっているかっていうところを指標にしていく。単なる売り上げとか受注量ではなくって、学習曲線が働いてるかどうか、見積もり期間とか工期とかエラー率の低下が起こってるかどうかを確認していきましょうと。

そして3つ目が、全てのアセットを持つのではなくて、コントロールポイントを所有していく。全てを内製する必要はなくて、データとか適合判定とか契約とか保証、これらの要所となる部分を握って顧客のアウトカムを保証していくというところが大事だったりしますと。自分たちでハードウェアを作るかどうかっていう観点もですね。で、それが本当にアウトカムにどこまで大事なのか、そのアウトカムというものを、ソフトウェアだけで調整できるんであれば、別にソフトウェアだけでもいいかもしれないというとこですと。

最後に、カスタムの案件に対してノーとちゃんと言っていく。スケールできるシステムを守るために、非標準的な特注案件に関しては、短期的な売上を捨ててもいいというような規律を保っていく、こうしたところをやっていくというのが、1つポイントになってくる考え方ではないかなと思います。

フルスタックに近い場合もあるかもしれませんが、全てを内製するのではなくて、本当にそのコントロールポイント、制御点っていうところをきちんと持って、特定して、そこに対して資本と経営時間を使っていくというのが非常にポイントになってくるのかなと思うようなアプローチでした。はい。

ということで、以上、今回は分割じゃなくて反復化というところをご紹介しましたが、いかがだったでしょうか?

そうですね、設備を小さくするとかモジュール化するところだけに目が行きがちだったんですけども、そうではなくて何を標準化するといいのかっていうのを最初に定義すること、そのために実際に現場に出てみたりとか手を動かすっていうところで、きちっと、どこまでを標準化するかっていうのを自分たちで決めるっていうところが大事なんだなというのは思いました。

そうですね。そこの仮説を持って、やっぱり1個1個見ていくっていうのが大事なんだろうなと個人的にも思いますし、それが、仮説がうまくいった時にも、次の案件でコストとかリードタイムとかが改善してるかどうかっていうところが、まさにこの反復できてるかどうかっていうところの、1つの見定めるポイントになるんではないかなと思います。はい。それでは今日はこちらで終了です。

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