Coral Capitalで投資を決めるときの基準の1つに、チームに優秀なエンジニアがいるかどうかということがあります。最近はシード投資に加えて、シリーズA・Bで出資することも増えましたが、その場合には開発チームや開発体制、技術スタックや設計方針などについて詳しくお聞きすることがあります。それはメンバーが優秀で事業ドメインやビジョンが優れていても、十分な開発スピードが保てなければ事業成長のボトルネックになり得ると考えているからです。逆に開発速度が圧倒的に速いことはmoatになると、個人的には考えています。
これは自明な考えのようですが、実はそうでもありません。「売上マルチプル」について語られることはあっても「開発速度プレミアム」のような概念は、あまり聞いたことがありません。しかし、実はきわめて重要なのではないかと思っています。
スタートアップのバリュエーションにおける売上マルチプル
企業の価値を算定するとき、事業モデルが確立している企業であればDCF法を使うのは合理性があります。将来にわたって生み出されるフリーキャッシュフローを基本としつつ、不確実性や事業環境の変化による陳腐化を織り込んだ資本コストで割り引いた現在価値の積分で算出するという計算方法は妥当に思えるからです。
一方、そもそも事業モデルが確立しておらず、長期の事業計画の蓋然性も低いシード・アーリーのスタートアップのバリュエーションはどうでしょうか。基本的に資金調達時の相対取引による相場感と、今後数年の伸びを織り込んだ「売上マルチプル」というより簡易的な考えを軸にすることが多いでしょう。特にメトリクスの標準化が進んだSaaS企業では、その傾向が強くなります。例えば、2022年秋の日本のスタートアップのシリーズA調達なら売上マルチプル5〜15倍がバリュエーションの1つの目線になります。
「シリーズAなら売上マルチプル5〜15倍が（最近の）バリュエーションの目安」と書いてしまうと、その数字が独り歩きしてしまう恐れがあります。しかし実際には市況によって大きく変動しますし、個別のディールでは多くのデータポイントを見て、それらを織り込むのが普通です。例えば月次成長率やチャーンレート、セールスサイクル、アップセルの蓋然性、顧客獲得単価、moatの強さ（競合参入の状況）などです。創業年が浅い場合には創業メンバーがブレイクするリスクもありますし、そのリスクもマルチプルに織り込まれると考えて良いでしょう。
開発速度もバリュエーションに加味すべき？
さて、投資家としてバリュエーションを考えるときに、そのチームの開発速度も織り込むべきではないか、ということを最近はより強く感じるようになりました。もっと言えば、一定以上の複雑なソフトウェアでビジネスを作る事業なら、アジャイル開発で使われる実装速度の目安である「ベロシティー」や、場合によってはコードベースに対する数カ月分のコミットログを見たほうが良いのではないか、ということです。
2010年代前半、すでにレッドオーシャンだったSNS市場で、後発のFacebook（現Meta）がものの数年で一人勝ちしました。その比較的大きな要因だったものに開発速度があると思います。今は覚えている人のほうが少ないかもしれませんが、Facebookはかつて「ウォール」と呼ばれる誰かの「壁」に、他の誰かが何かを書くというモデルでしたが、あるときTwitterを真似てタイムラインを実装しました。これは数億人が使うことを考えるとエンジニアリング的には、かなり大きな変更ですが、2010年代のFacebookは、こうした規模の変更をガンガン前のめりで行っていたものです（そして良くバグっていました）。その変化スピードを可能にしていたのは圧倒的なエンジニアリング力です。2010年代にはPHPをC言語に変換するコンパイラを自作して、それにWebサーバ機能まで単一バイナリとして実行形式に統合してデプロイするような独自の分散システムを築き上げていました。今でこそビジネス面ではユーザー数の増加ペースに陰りが見られたり、メタバースへのピボットの成否が心配されたりしてますが、フロントエンド開発のデファクトとなったReactや、APIのクエリ言語のGraphQLなどで知られているなど相変わらずFacebook（Meta）は技術面でエッジが効いています。
逆に、登場時に一大センセーションを起こしつつも消えていったGoogle Waveの失敗の理由として開発速度が遅かったからという指摘も一定程度は説得力を感じます。まさか、Googleのエンジニアの開発速度が遅いわけがないと思うかもしれませんが、実はGoogle Waveは全体をJavaで実装していてサクサクと大きな変更ができるコードベースではなかったという話があります。FintechのコアをJavaのように「硬い言語」で書くのは合理性があると思いますが、PMFを探る場面に向くのは「柔らかい言語」ではないかと思います。
最近の例だと、$20B（約2兆7000億円）でAdobeに買収されたFigmaもエンジニアリング力で勝った事例に思えます。スタートアップの教科書的には「FigmaはアプリUI/UXのプロトタイピング機能をブラウザで提供したから、クラウド化／SaaS化の世代交代の波に乗って成功した」と解釈するビジネスパーソンが多いかもしれません。それは間違いないですが、他の競合に比べてFigmaが圧倒的に受け入れられた背景には、Web開発コミュニティーの中から2015年頃に出てきて2017年に正式リリースされた「WebAssembly」を真っ先に使ってブラウザ上に高速な描画システムを構築したこともあると思います。
WebAssemblyはブラウザ上に仮想マシン（VM）と呼ばれる抽象的なCPUを実装して高速にプログラムを実行する標準規格です。JavaScriptのようにソースコードを読み込んで実行するモデルと異なり、Androidのネイティブアプリと同じように小さなバイナリファイル（ゼロイチの並び）の中に収められた命令をダイレクトに実行することから高速化が期待できます。2017年にFigmaは自社テックブログで「WebAssemblyで3倍速くなった」と書いていますが、Web関連技術の標準化団体W3Cで正式勧告となったのは2019年なので、Figmaはかなり前のめりでWebAssemblyを採用していたことが分かります。今も、Zoomなど一部をのぞいて一般的なSaaSでWebAssemblyを使っている話を聞くことはほとんどありません。
Figmaの例は利用者が感じる速さの話でもありますが、新技術を取り込んで、セキュリティーのリスクなどを検証しつつプロダクトとしてリリースできるスピード感は、やはり開発速度と言って良いと思います。
先行指標としての開発速度
利益・売上と、その成長速度こそが事業の価値を最もダイレクトに示す指標です。ただ、ソフトウェアでレバレッジする事業の場合、先行指標としてユーザー数の伸び、さらにその先行指標として開発速度があると思います。複数実装を試してMVP達成を目指す場合、同じランウェイで開発速度が2倍なら、2倍の数の実装を試すことができます。MVPのように規模が小さく1人や2人で一気に書ききるようなソフトウェアの実装速度は、エンジニアの能力やセンスによって10倍の差が出ておかしくないと思います。アップセルのための新機能開発も、特に初期であればエンジニアチームの開発速度に依存するでしょう。
一定規模の組織で開発するようになった段階であっても、技術的負債が蓄積したり、初期のアーキテクチャー設計がまずかったり、選択した技術スタックのエコシステムが停滞するなどすれば、機能拡張の速度はどんどん落ちて行くこともあるでしょう。どんなに瞬発的開発力があっても、土台がぐらつくと速度が落ちることがあるため、一定規模以上のチームになってくれば短期の「スプリント」と長期の「マラソン」に分けたアプローチも大切になってきます。優秀なエンジニア人材のチームビルディングができるマネージャーが不在で、ある時点から速度が落ちることもあるでしょう。早い段階から過度の理想形や技術トレンドの流行を追いすぎて、逆説的に開発速度が遅くなることもあるかもしれません。
資金調達にVC回りをしているスタートアップ創業者の方々と面談していると、プロダクトの実装詳細について投資家に聞かれることはほとんどないという声も聞きます。でも、上に書いたようなことは、本当のところシード・シリーズAなどではバリュエーションに影響を与えて良いことなのではないかと思っています。少なくともCoral Capitalでは投資の意思決定で重要な要素です。開発力や開発速度に自信があるのであれば、ぜひ投資家向けスライドや説明に、そのことを示すものを含めてみてはいかがでしょうか。
Partner @ Coral Capital
