コンパウンドスタートアップについて起業家視点で考えた

コンパウンドスタートアップのおさらい

• スタートアップとしてマルチプロダクトからスタートする、というパターンが出ており、

• これまでの特定の顧客のペインを1つのプロダクトでPMFしなさいというセオリーとちがう

• メリットはいくつも商品が売れること

• USは買収、技術的インテグレーション、エンジニア組織が下敷きとなっている。しかしかなり難しい

• 日本においてはこれらを実現する資源がより貴重だろう

マルチプロダクトにも2パターンあるのではないか

• マルチと言っても2つあるのではないか
• 「1. 抽象化されたプラットフォームをベースに複数のアプリケーション(ここでいうプロダクト)がN個存在するパターン」と、
• 「2. 全く独立した別のプロダクトがN個存在するパターン」

• 1のプラットフォームをベースにする場合、メリットはプラットフォームによる共通基盤の恩恵を受けられること(セキュリティ、データ連携、抽象化された技術など)

• また当然既存の顧客資産にクロスセルをしていける

• デメリットはプラットフォームを創らないといけない。これが超絶困難。プロダクトの開発の他にプラットフォームの開発やマネジメントが必要になるため、それに応じた組織も必要になる。経営の難易度が飛躍的に上がる

• 多くの場合でデータモデルのアーキテクトが極めて難しい。また自社の技術資産をどの抽象水準で投資するのかも難しい。そしてプラットフォーム開発・設計経験者が必要で日本には極めて希少

• Stailerの場合は複数のプロダクトが1枚のデータモデルの上に創って1度目のPMFをしたが、内包される個別のプロダクトの独立した利用対するエンタープライズニーズも大きい。よって分割、独立したアーキテクトにしていくのが2度目のPMFに必要要件で、これが大きなチャレンジになっている。社運をかけてやっている

• パターン2のはじめから独立したプロダクトは、メリットは独立したチームで開発できる。依存もない。デメリットは抽象領域を検討しないため、再生産性が低い。使い回しができず、毎回起業するようなもの。顧客資産だけは使える。
• そして国内のほとんどのマルチプロダクトはこれだと思っている

• このパターンを考える上での好例はBill One。SansanやEightで構築している技術とOpsの基盤がそのまま使われている (OCR+人による目検) & 顧客資産にもクロスセルできている。多分だけどデータモデルは共通化されていない気がしているのでちょうどパターン1とパターン2の中間じゃないかと思う

市場の要因

• そもそも、これまでより「同時に多くの複雑な問題を解かないとスタートアップできない」問題がある

• これを1枚のデータモデルでPMF目指すか、はじめからモジュール分割されたプロダクトでいくのか、個別のプロダクトを独立してNこつくるのか、技術的意思決定がめっちゃ困難になっている

• 創業者は開発の速度を担保する前に、このアーキテクトに対して適切に意思決定をしていくスキルが必須になっていっていると思う

あわせて組織を考えないといけない

• 最終的には事業組織もプロダクトに合わせて分割しないと絶対に速度が出ない。逆コンウェイ。なぜなら適切なフィードバックの取り扱いができないから

• 要求が100を超えるとマネジメントは崩壊する。モジュールの中で独立して考えないといけない

• 技術的な意思決定と事業的な意思決定を一致させる能力が求められる