技術の外側までをプロダクトとして設計する：許認可・資金・施工をどこまで引き受けるか

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

同じくFoundXの小田です。

今週は、FoundX並びにアントレプレナーラボの皆さんが暑気払いというイベントに集まっていただいて、色々コミュニケーションできて良かったですね。

良かったですね。結構たくさん集まっていただきましたよね。

そうですね。年に1回、ちょっと夏が暑すぎて9月になりましたけれど、結果として長雨の中になっちゃったっていう。

そうですね。雨も最近よく降っててね。残念ながら外ではできなかったですが、ああやって集まる機会はいいですね。

そうですね。本当に集まっていただいて、FoundXの卒業生の皆さんもたくさんいらっしゃったので、近況をお話できて良かったです。

はい。またこういう機会をFoundXでも作っていければと思ってます。ということで、ここからアイデアキャストのコーナーです。FoundX Review Startup IdeaCastでは、海外を中心としたスタートアップの事例を元に、スタートアップの戦略とか事業の組み立て方をAIを使って分析して紹介しています。これからアイデアを考える人たちの参考になればと思ってます。

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

ということで今日はですね、戦略編と言いますか分析編、50回記念でやったところの1つの傾向であった「技術の外側までがプロダクト」というような戦略に関してお話をしていきたいと思っています。技術の導入の非技術的なリスクというところまで引き受けて製品化していくという戦略になっています。

今回これを取り上げる背景というのはあるんでしょうか?

そうですね。これまでも結構、顧客の成果をとかいう分析もあったと思いますが、今回はどちらかというと供給側にフォーカスして、導入条件とか導入するための設計みたいなところが結構必要なプロダクトもあると。技術開発だけで留まっていてはなかなかうまくいかないビジネスも多いんじゃないかというような、そうしたことを紹介したいなと思っています。

実際に例えば、技術が使える段階にあったとしても、審査のプロセスとか設置のプロセスとか資金といったようなところで、お客様がつまずくと言いますか、障壁を感じて止まってしまうこともあったりとか、あるいは顧客の困り事というところを広く引き受けることによって、そうしたところを解決していくことができるかもしれませんが、とはいえ自分たちも負担が増えちゃうので、何を選んでいくのかとか、何を自分たちじゃなくて提携先に残していくのかみたいな、そうしたことを考えていただくための戦略として、この「技術の外側までがプロダクト」みたいな話をしたいなと思っています。

今回答えたい問いとしては、例えば優れた技術がなぜ導入されないのか、普及されないのかとか、スタートアップがいかにして許認可とか資金調達とか施工みたいな非技術的な導入リスクを反復可能なプロダクトにしていったのかみたいなところをご紹介できればなと思ってます。

では全体像です。この戦略の全体像となりますが、まずですね、例えば顧客の担当者と、購入を承認する担当者というのを分けて考えていくってのは大事かなというのが1つポイントとしてあるのかなと思っています。技術検証が完了してもですね、例えば技術担当者の検証が完了しても、導入をしていくためには購入みたいなところを調達部門とかと調整してやっていかなければいけないであるとか、あるいはその際にプロダクトの境界線を拡張して、評価とか契約とか資金調達とか施工といったような中間工程、カオスな中間工程みたいなところを、自分たちで制御可能かつ計測可能なプロダクトにしていくみたいなことをしていくのが今回のこの全体像というところなのかなと。実際にテクノロジーレディネスが上がった技術に対して、実際に購入して、お客様の中でオペレーションしていくまで、本当に長い、すごい大きな空白と言いますか、死の谷があるところをどう超えていくのかっていうようなところが、今回の「技術の外側までがプロダクト」みたいなところの整理になっているのかなと思います。

技術が良くても、それ以外の手続きだったりなんなりが大変だったりすると、やっぱり導入がされないっていうようなことなんでしょうか。

そうですね。技術担当者と購入担当者の視点がやっぱり違っていたりすると思いますし、あるいは購入担当者の方が購入したいと思っても、必要な情報とかが集められずに失注する、というか購入に至らないとかいうところもあるかもしれませんし、あるいは顧客に追加の人材とか、手順を変えなきゃいけないみたいなコストが発生したら、技術が良くてもなかなか導入に至らないということがあるのかもしれないなという風に思います。

では、こうした問題系に関して少しお話をしたいと思います。まず、いろんな問題があってインセンティブが分断されてますっていうところが1つポイントかなと思います。顧客は顧客で、もちろん最後の最後は購入したいという意思を持つんですが、実際に購入して機能させるためには、例えばインストーラー、施工業者みたいなものが必要だったりとか、ファイナンシャー、いわゆる金融機関みたいな人たちが担保融資をつけて入れていかなきゃいけないとか、レギュレーター、規制当局みたいなのがいて、それを全て超えていかないと実際には導入されない。テクノロジーを実際に導入していく時の調整コストというものがあって、このコストがテクノロジーの便益というものを上回る時に、なかなか顧客では判断しづらいと言いますか、導入しづらいということになってしまいます。

その時に、こうしたアプローチでこの責任の分断、例えばメーカーは機器を売る、銀行は信用を論じる、そして施工業者は工事のみをするみたいな時に、この成立条件をうまく成立させていくために、分担された責任をうまくまとめていく。それも1つプロダクトとして必要ではないかであるとか、あとは資金と時間のずれというところもあったりして、例えば機器の仕入れというところで資金が先行する、キャペックスが必要になってくる時に、そのキャペックスをどのように補填するかっていうところにお客様側がつまずいてしまうと導入されないとか、あるいは技術的な性能というものに対して、銀行・保険会社側がまだそのリスクを取れないということになったら、仮に時間的に遅れてお金が入ってくるような状況であったとしても、そこにお金がつかない、遅れてもお金が入ってこないみたいな状況もあったりして、バンカビリティがある状況になってないというところだと、つまずいてしまうというのがあったりするのかなと。あとは本当に、それ以外の大きめじゃないところでもですね、施工日とか工期が読めないのであれば、なかなか顧客が導入しづらかったりとか、融資が使えなかったりとか、許認可がなかなか進まなかったりとか、そうした理由で契約が止まってしまうことがあるので、ここをトータルでまるっと問題として解決してあげるっていうことが必要になってくる可能性があるのかなと思ってます。

なるほど。その一社が全部引き受ければ、統合というか分断自体がなくなるっていうことなんでしょうか?そんな乱暴な話でもない気もするんですけれども。

そうですね。自社が全部引き受ける、その引き受けるっていうのを所有することということでもないのかなとは思いますね。所有すればその分コストとして自分たちが持つ範囲が広くなっていくので、これはこれで解決に一歩近づくかもしれませんが、どっちかって言うと責任範囲とかインセンティブをどうアラインメントさせていくのかみたいなところとか、時間的に、みんながオッケーを出すタイミングをいかに揃えていくのかとか、そうしたところが大事なのかなという風に思いますね。

例えば、今回あまり紹介しなかったスタートアップとして、パルメットっていうスタートアップがあったりしますが、ここの会社は住宅用の太陽光などの導入をしているところです。どういうことをやってるかって言うと、地域の販売とか施工会社を使う、自分たちは持たないと。ただ、自社の仕組みで複数の工程を繋いで、一気にそれが揃うようにしているみたいなスタートアップ。地域の施工能力と自社の進行管理を結んでうまく繋いでいく。そうすることによってこの分断されたインセンティブというものをうまくやっていく。パーミットフローみたいなものも、ある意味許認可みたいなところに関係していたりしますが、そうしたところをうまく揃えていくというようなことはあったりするのかなと思います。

あとはダンデライオン・エナジーとかに関しては、住宅地向けの地熱ヒートポンプをやってる、家庭用地熱みたいなところですけれども、ここに関しては小型の掘削の機械と、土の回収と輸送をしていかなければいけない、それを狭い住宅地でも工事できるみたいなことをやっていって、かつ許認可もしなきゃいけないと。そうしたところを一気に自分たちで揃えていくみたいなことを、建設会社側の施工業者ともうまく作業分担しながらやっているようなスタートアップだったりするみたいです。こうしたうまく揃えていくというようなものが、まさに自分たちで所有しなくてもできる方法なのかなと思いますね。

では続いて、このアプローチがどこで使えるのかに関してお話をしたいと思います。おそらくこのアプローチに関しては合ってるところ、合ってないところがあって、1つ合ってるところとしては、高額な初期投資、キャペックスが必要な時に融資の条件とかをどう引っ張ってくるのかみたいなところを合わせていく必要があるとか、許認可の壁が厚いであるとか、産業側がフラグメンテーション、細分化されてしまっていて、なかなかインセンティブのアラインメントと責任の同時的な条件を満足するような状況にならないとか、あるいはそれに加えて工程に反復性があるみたいなところが、比較的このアプローチが合っているのかなという風に思ってます。つまり、いわゆる許認可とかが合わないとかいうところを反復可能にしていくっていうようなアプローチがここなのかなと思います。一方で不向きな条件としては、技術自体がまだ未成熟だったりとか、案件ごとの個別性が高すぎたり、反復性がなかったりとか、スタートアップ側に資本とか資金の負担をする体力がないみたいな時には、ちょっと成立はしづらいのかなと思います。ある意味、採算不足とか技術の未成熟という問題が残っているようなところには、これはなかなか使えない。逆に技術が揃っていて、それが一気にタイミング的に合致しないっていう時には、このアプローチは比較的合うのかなという風に思います。

どこまでをやるかとか、全部をやるかとかも含めて、そういうのって最初に決めたところと途中で変えるっていうところもあると思うんですけど、そういう風にだんだん変えていくっていうプランもあるんでしょうか?

あると思いますね。例えば支払い者と費用構造を確かめた結果、自分たちの提供範囲を絞っていったりとか広めていったりしなきゃいけないみたいなことが出てくるかもしれないなと思います。例えば融資以外にも補助金とかを使う場合には、その補助金っていうものを新しい範囲として自分たちがやっていくみたいなこともあるかもしれませんし、場合によったらそこに関しては別の提携業者みたいなのが見つかれば、そこに任せていくみたいなこともあるのかなと思います。実際に、シールドっていうようなスタートアップがあったりしました。ここは住宅用の省エネとか施工会社向けのリベートの支援をしているところだったんですが、まず住宅所有者への直接提供というところをやっていたのに対して、自分たちの範囲を変えて、施工会社向けのリベート業務支援というところに転換していったというようなことがあったりしました。こういう風に自分たちの担当範囲というのを変えていくっていうのは事例としてあったのかなと思います。

ではこの戦略に関して、何をどこまで設計していくのかに関してお話をしたいと思います。自分たちがどこまでやっていくのかっていうところだと思っていて、そのために例えば低リスク・低コントロールなところとしては情報の獲得みたいなところがあったりしますが、徐々に高リスク・高コントロールが必要なのは、意思決定権を把握していくことだったりとか、あるいは契約の標準化をしていくってなると、それなりに高コストになっていくみたいなことがあったりするのかなと思います。自分たちがどこまで垂直統合してやっていくのか、製品の範囲を広げていくのかに関しては、割と考えるべき点なのかなと思います。ただ、意思決定の把握みたいな真ん中の辺りが1番いいのかって言うと、そんなことはなく、やはり事業内容とか事業環境に合わせて自分たちのリスクの範囲とか提供範囲というのを決めていかなければいけないのかなと。

とはいえ決めていかなければいけない時に重視したいのは、顧客の成果、アウトカムが何なのかというところを1つ決めていった方がいいのかなと。図面通りの部品が必要な日までに届くのであれば、もしかしたら工場を所有するっていう選択肢もあれば、供給者の選定とか品質の確認みたいなことをした上で、他社に作ってもらうってこともあるかもしれません。その成果というもの、お客様が本当に欲しい成果みたいなところを自分たちが確認して、それをどのように実現していくのかってのを考えていくのがいいのかなと。で、その中で、成果に大きく貢献するようなものをどこまで自分たちがやっていくのか、例えば取引先の再選定、仕様の変更、不良品の扱いとか、そうしたところまで自分たちがやるのかどうかっていうのを決めていくというのがあるのかなと。

あと契約の標準化みたいな話をしましたが、契約を共通化する時には、完成条件と例外時の対応みたいなところもちゃんと把握して、これは案件が増えてくると多分ある程度見えてくるところもあると思いますが、こうしたところをうまくやっていくというのが大事なのかなという風には思います。

成果をきちっと自社でコントロールできるようにしたいというお話だと思うんですけれども、そのためには、顧客との接点、窓口があるだけでは不十分だろうなというのはあるんですけど、どういう風にお客様との接点を作って、マネジメントしていくといいんでしょうか?

そうですね。そこはアウトカム次第なところはあるかなと思います。多分不具合を受け付けるだけ、カスタマーサポートだけをやるっていうようなところでは足りずに、例えばフィクティブみたいな感じで。フィクティブっていうのは部品調達とか製造支援のスタートアップなんですけれども、彼らは外部製造パートナーを監査・認定して、お客様の発注したものに対して、自分たちが品質管理とか、供給者の審査、そもそもの登録の審査と検査確認っていうようなところをやっていくみたいな感じですと。判断に必要な情報を自分たちで持って、それに対して責任を持っていくみたいな。そして場合によっては代替品の手配みたいなところまでやっていくっていうことも、やっていく必要があるかもしれないなと思います。そこも本当にお客様が何が欲しいかで、本当に早く欲しいだけで、自分たちで代替品を調達できるんであれば、別にそこまでやらなくてもいいとは思いますが、一方でもし本当にちゃんとしたものが欲しくて、短期的にすぐに欲しいというのであれば、多分代替品の手配というところまで、フィクティブみたいに自分たちが責任を持っていくっていうのは必要なのかなと思います。

では、これがなぜ成長につながるのかというところに関して、バンカビリティという観点で少しお話をしたいと思います。例えばですが、こうしたことをやっていくことによって、例えば導入プロセスを標準化して導入してあげることをやっていくと、非技術的なリスクを取り除くことができますと。毎回違う業者に発注してるとそこの学習がなかなか回らないので、なかなか進みませんが、自分たちがやることによって、この非技術的なリスクを取り除いていくことができますと。そうするとプロジェクト的に、金融機関から見てバンカブル、融資可能になっていくというようなメリットがあります。そうするとですね、次に資本がもしボトルネックであれば、銀行からその資本というものを引っ張ってきて、デプロイメントがよりできるようになっていくと。そうすると現実のオペレーションでデータが、失敗とか例外とかも含めて蓄積されていって、学習ができて、そしてさらにIRRが向上したりとか、顧客の獲得のコストが下がったりとか、次の契約の標準化が進んでいって、さらに一周戻ると言いますか、導入プロセスを標準化して非技術的リスクをさらに下げることができて、さらにバンカブルになっていくというような、このループを回すことができるようになっていくと。技術だけでももちろんできる場合もあるかもしれませんが、非技術的なリスクを自分たちが背負い込んで、反復可能にしていくことによってバンカブルになっていく。モジュールの回でもお話ししましたが、そうしたことをしていくことができるのが、この成長につながる1つの理由なのかなと思います。

これを現場にどんどん行っていくというか、数を増やしていく、最終的にはってところだと思うんですけど、それだけではなくて、そこからもっと改善だったり、非技術的リスクを取り除くところにつながらないといけないっていうところなんでしょうか。

そうですね。まさにその改善というものを、技術的な製品も含めた設計にどんどん反映させていく必要があるのかなと思います。経験が蓄積されただけだと、それはそれで一部の非技術的リスクは取り除けると言いますか、下げることはできますが、多分最終的にそのリスクを下げていくっていう時に、技術的な製品とか、あるいは自社の業務プロセスへの改善をかけていかないと、多分リスクって下がっていかないと思うので、そこをうまく回していく、そして製品自体も変えていくみたいなことが1つ必要なのかなと思います。

例えばラピッドロボティクスみたいなところ、製造現場にロボットを導入してるスタートアップですけれども、彼らは事前設定した作業と月額利用を組み合わせて、外部メーカーのロボットアームに自社の導入サービスとかを加えていったというようなことをやっていました。で、販売期間が想定より長くなってしまって、既存工場に作業スペースを置けないという問題から、人1人分の面積を意識した設計というものに変えて、より導入しやすくした。いわゆる製品を変えていったみたいなことをしたようです。こうした自分たちの製品自体を現場の経験から変えていくというようなことが、多分バンカブルになっていく1つのポイントなのかなと思います。

あとエレメンタル・インパクトという、気候変動系に投資しているところになります。ここは、ナイトリシティというスタートアップに対して200万ドルのDSFと言われている、ファースト・オブ・ア・カインドみたいなところの初期開発資本を提供している投資会社と言いますか、慈善団体にも近いところではあるんですけども、ここに関しては、プロジェクト資本をちゃんとナイトリシティがやってるので、追加資金、そうしたDSFって形で投資をして、それが他のプロジェクト資本を呼んでくるみたいなことがあった。うまく資本を使ってこのループを回していくっていうことができた例なのかなと思います。

では、他にもどういった事例があるのか見ていきたいと思います。いくつかの事例と言いますか、カテゴリーですかね、があったりします。まず1つ、バンタっていうようなセキュリティ系のスタートアップに関しては、元々ボトルネックは監査の属人化とか優先度の低下みたいなところがあったそうです。それに対してバンタというスタートアップは、SOC 2というコンプライアンス要件を自動化して製品を提供していったと。つまりお客様にとってのコンプライアンス要件を満たすっていうところに対して、自分たちが提供していったという1つの方法かなと思いますと。もう1つがパーミットフローというところです。何度か紹介しちゃうかもしれませんが、こちらに関しては、複雑な建築許可の手続きと手戻りというボトルネックがあったところに対して、主にソフトウェアですけれども、規制の要件調査をしたりとか、申請をやってあげたりとか、進捗の追跡のプロセス、そして場合によっては指摘の対応ということをしていって、最終的にお客様は最終判断とか設計内容の適合性を見ていくだけで良くなったみたいなところがあったりすると。こうしたもので最終的な行政判断というものにより辿り着きやすくなって、行政判断は第三者に残ることになりますけれども、そこまで辿り着けるようになったというようなところがあったりしましたと。

あとはその回で紹介したのはクルーバー。これはエネルギーの会社ですが、クルーバーに関しては、以前はボトルネックとして施工業者の資金繰りとか、あるいは販売プロセスが面倒と言いますか、なかなか繋がらなかったところに対して、自分たちが販売プロセスとか施工を行うことによって、見積もりから融資、そして調達までの統合をして、資本に関してはかなり重くなってしまったんですが、そこを円滑にして一気通貫でできるようにしたということがあったりしました。

あとはフォーミックっていうスタートアップですね。こちらはロボティクス系のスタートアップではありますが、第三者のメーカーのロボットを使ってるスタートアップですと。ここに関しては、以前はお客様にとってのボトルネックとして、工場の高額なキャペックスの負担とか専門知識の不足みたいなところで導入がされなかったところに対して、ロボット・アズ・ア・サービス型のモデルによって、自分たちが運用保守、性能保証をしていくみたいなことをして、継続サービスを提供していきますと。もちろんそれによって、自分たちがロボットを買わなければいけないという、自分たちのキャペックスが大きくなったものの、それによって導入はされやすくなったということがあったりはしました。もちろん自分たちとしては、そのロボットをどういうタイミングで更新していくのかとか、陳腐化していくものなので、そこをどうやっていくのかっていうところはかなり大きなリスクとしては残っていますが、こうしたところも含めてやっているというところがあったりしますね。

なるほど。資本負担が結構低い方から始めるのがスタートアップとしては始めやすいなとは思うんですけれども、ただそこに着目するのではなくて、お客様の成果をちゃんと提供できるかっていうところから、資本負担はそれに従って変わっていくような形なんでしょうか。

そうですかね。多分フォーミックなんかも、ソフトウェアだけで、第三者のロボティクスを入れてもどこでも動けるようにしますよみたいな、そこだけ提供したとしても、多分結局お客様側で、たくさんあるロボットのうちどのロボットを購入するかとか、それをどこに置くかとか、どう運用するかみたいなのが残っちゃうので、だったらやめとこうかなみたいな感じになってしまうところに対して、フォーミックみたいなロボット・アズ・ア・サービスとして提供していくみたいなのが、お客様にとっては本当の成果になってる可能性もあるなと思います。もちろんお客様によっては、内製していると言いますか、技術者がいるので、別に他社のロボットでもソフトさえあればいいですよみたいな方もいらっしゃるかもしれませんが、おそらくはお客様によって求めてるものが違っていて、実行にどこまで関与して欲しいのかっていうところが変わってくるんじゃないかなと思いますね。

それでは次に、最初にどう試していくのかというようなところのヒントをAIがまとめてくれたので、これを紹介したいと思います。いくつかフェーズに分けてやっていくといいんじゃないかというようなことが整理されていますと。フェーズ1として、コンサルティングから始めたらどうかと。マニュアル的なこれを3ヶ月ぐらいでやると。コードを書く前とか何かをやる前に、少数の案件を手作業で最後まで伴走して、どの段階で実際に取引が詰まってしまうのかというようなボトルネックを特定していく。例えばバンタ、先ほどセキュリティのスタートアップを紹介しましたが、バンタなんかは当初スプレッドシートの手作業で分析していたということですと。じゃあそのボトルネックを解消できるか、そして解消した時にお客様が支払ってくれるのかっていうのを確認した上でフェーズ2に入っていくと。いわゆるプロセスの標準化ということで、同じ条件で案件が繰り返しできるか、例外処理を減らせるのかとか、あるいは見積もりとか責任分担とか検収条件みたいなことを標準パッケージとしてうまくまとめていくことができるのかっていうのを、次の4ヶ月から12ヶ月ぐらいで検証して進めていく。そして、お客様のコストとこちらの原価がうまく見合うのかっていうのを確認して、自動化できるかを確認していくと。直接的な原価というものがお客様の支払うような価格に対してちゃんとペイするかどうかっていうところを見た上で、フェーズ3として、ソフトウェアのオートメーションをしていくと。頻出するようなよくある判断のプロセスとかをソフトウェアで自動化したりとか、あるいは創業者以外でもそれを再現可能な事業単位として構築していくみたいな、こうしたことを繰り返していくことによって、どんどんと自動化・標準化というものができていくんじゃないかなっていうようなことが、今回AIがまとめてくれた内容になってます。

うん。この辺りは王道的だなと思うんですけれども、検証成功とみなすようなポイントって、受注数が増える以外にも、そこにも含まれるかもしれないですけど、どういったものがあるんでしょう?

そうですね。受注が増えても一件あたりのコストが下がっていかなければ、多分検証は成功とは言えない。標準化ができてないっていうことなので、というところとか、場合によっては受注が増えても、カスタムのリクエストを受けた上での受注が多かったら追加作業とかが発生してしまうかもしれませんし、場合によっては受注したけど返金、リターンが多ければ、多分お客様の求める成果にはうまく合っていないということだと思うので、そこも多分まだ標準化できてない、一定の品質で成果を提供できてないということなのかなと思います。この辺り、例えば継続の条件というものを、完了率とか実作業時間とか手戻り費用とか回収の日数とかで事前に決めておいて、そこを満たしてるかどうかっていうのを見ていくと1ついいのかなと。例えばオーロラソーラーみたいなスタートアップ。こちらは太陽光のスタートアップで、見積もりとかをやっているスタートアップですが、例えば彼らは、提案とか契約の先にある、現場で実際に施工できたのかとか、工事管理の基本的な作業単位としては見積もりだったりしますが、見積もりだけではなくて、そこから現場の負担が増えていないかとか、ちゃんとその案件が完了されているか、つまり見積もりが本当に正しかったのかどうかというようなところをちゃんと見ていくとかいうことをやっていっているみたいですね。こうしたところまで見ておかないと、多分受注だけだと見えないところはあるのかなと思います。

では、これをどうやって大きな事業にしていくのかに関して考えたいと思います。スケーリングをしていくってのはスタートアップにとっては大事なので、事業はおそらく最初は単なるコンサルティングとか導入代行みたいなところから始まるかもしれませんが、それをいかに業界全体のインフラとかプラットフォームにしていくのかというのを考えていかなければいけないのかなと。多分このスタートアップの形式の場合、大きな競争優位というものは、ソフトウェアのUIとか機能の多さから生まれるわけではなくって、数多くの案件をこなす中で蓄積されてきた例外ケース、エッジケース、失敗データみたいなところをベースに自分たちのプロセスをよくしていくというところとか、地域ごとに規制が違ったりするので、そうした違いというものをちゃんと取り込んでうまくやっていくことができるみたいな、そうしたデータをうまく作っていく、あるいはそれを自分たちの製品に反映していくというのが、非常に大事なインフラへの進化のポイントなのかなと思います。案件から得た情報というものを次の案件とか次の判断に使っていって、顧客の成果をより良くしていく、あるいは採算をより良くしていく。これを改善していくことが、おそらく自分たちの事業を大きくインフラにしていくためのポイント。それでバンカビリティも上げていくみたいなことになっていくのかなと思います。なので、実施した案件だけではなくって、途中で止まった理由とか、見積もりと実績の差であるとか、保証対応の結果とか、そうしたものを貯めていく。いわゆる成功だけではなくって、損失が起きる条件というものをちゃんと学んでいくのが大事ですと。そのためには、じゃあどういった記録をして、次にその記録をどう活かしていくのかというのを最初にある程度きちんと考えておいて、そのデータを取っておくことが大事で、収益化はもしかしたらその後の方で取っていくっていう形でもいいのかなと思います。

そうですね、データを増やしていきつつ、そこから判断能力につなげていくお話だと思うんですけど、その時に何を見ていくべきというか、データを増やせばいいっていう話ではないと思うので、どういう風にポイントを見ていくべきなんでしょうか?

そうですね。1つが、結果まで追跡しておいて、次の案件のコストとか失敗が減るっていうことをちゃんと確認する。先のオーロラソーラーみたいに、見積もりだけではなくて、その先の完了した施工がどれぐらいあるのかみたいなものまで追跡しておくってのが1つ大事なのかなと思います。あとは自分たちの内部のプロセスですよね。こうしたいろんなことをやると内部プロセスが複雑になりがちなので、自社の中の入力情報とか業務手順っていうものがきちんと改善されてきている、コストが下がっているのかとか、規制とか契約にちゃんと対応できているのかとか、そうしたところまで見ていく必要があるのかなと思います。例えばラプターマップスっていうようなところ、こちらも太陽光設備に関する点検とか運用支援をやっているところですが、こうした発電所の点検みたいなところに関しても、集めた記録、データというものが次の業務にちゃんと繋がっているかどうか。例えば彼らは常設ドローンを遠隔で運用して、必要な時に設備状態を確認して記録していくみたいなことをやっていたんですが、竜巻後の点検を操業判断とか後続の対応につなげたみたいな事例があるみたいで、そうした異常事態と言いますか、突発的な事態を次につなげていくみたいなところまでやったことによって、いろんな製品の改良ができているというところがあったりすると聞いています。あとはサイトトラッカーですね。彼らは分散型インフラの建設とか設備管理のソフトウェアをやっているところですが、拠点が増えていくごとに同じ判断というものを毎回やり直さない仕組みになってるかどうかっていうところを見ているみたいですね。敷地の開発とか設備の共用とかテナント申請とか、こうしたもののテンプレート手順を提供して、国ごとのデータ保存要件に対応しながら共通の仕組みを使っていくみたいな、そうしたことをやってるみたいです。こうしたいろんなことをやっていきながら、自分たちのスケーリングを手伝っていくってのが、おそらく案件を増やしていったことの効果として出ているかどうかというところでポイントになってくるのかなと思います。

では最後、まとめに入りたいと思います。このアプローチ、「技術の外側までがプロダクト」という話でしたが、大きく3つAIの方でまとめてくれていますと。1つ目が、プロダクトの境界線というものは、誰かに与えられるものとか、ソフトウェアだけでバッサリ分かれるんじゃなくって、自ら設計したり選択していくものですと。どこからどこまでをプロダクトにするのかっていうのは、本当に自社の事業の判断として自分たちで選んで設計していくものですというのが1つポイントであるのかなと。で、お客様がどういったところの成果を求めてるのかによって、ここをちゃんと考えていく必要があります。で、その時に、その成果を出す時のボトルネックが自分たちでコントロールできるかどうかというところが1つ

ポイントになってきます。場合によっては、そうじゃないところに関しては、パートナー企業とかに頼んでいく、委ねていくということができるかもしれません。

そして3つ目ですね、成長至上主義が戦略ではないということを、スライドでまとめています。いわゆるなんでしょうね、ユニットエコノミクスと基礎のファンダメンタルズのところをきちんと確認しながら、どこかでアクセルを踏めるように多分準備しておけっていうようなことなのかなと思いますね。

そうしたことで、起業家の皆さんには、顧客の導入を妨げているボトルネック、これがもしかしたらソフトウェアだけではない場合に関して、どこまで解消するのか、そして解消可能な単位に分解できているのかっていうところを確認するといいんじゃないかと。そしてそのボトルネックを解消することによってお客様がより多くの対価を確実に払ってくれるのかどうかっていうところをチェックする。そして、自社がその案件のボトルネックになってるところの情報とか権限を取得できるような契約構造になってるかどうかをチェックする。そして最後に、案件を重ねるごとに例外処理が減っていくとか、あるいは自分たちの工程プロセスが改善される見込みがあるのかどうか、ここをチェックしておくと、このアプローチがもしかしたら機能するかもしれないというようなことになっていくのかなと思いました。

ということで今回は技術の外側という話をしましたが、いかがだったでしょうか?

そうですね、やっぱりその成果に着目してそこを最大化するようにしようっていうところは前回と共通だったかと思うんですが、個人的には、そこからさらに構造までちゃんと分解して、それが技術以外にあるのであればそこまでやろうっていうお話だなと思ったので、やっぱり目の前のお客様のことだけではなくて、それが生まれる構造や背景にもきちっと分析して目を配って、どういう風にマネジメントするといい形に持っていけるかを考えるのが大事なんだなと思いました。

そうですね。さっきもまさに、プロダクトは技術だけじゃないみたいな話をTタイムにもやってたところだったので、まさにそういう話なのかなという風に個人的には思ってます。

技術ももちろん大事ではあるんですけれども、お客様が欲しいのは成果のはずなので、技術だけに、なんでしょうね、補助金とか助成金とかを出すと、そのビジネス全体を見なくなるよというような、そうした話をちょうどやっていたところだったんで、今回のこの話も少し繋がってくるところなのかなと思いました。

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

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