コンパウンドという言葉は見かけなくなったが、原則は残る

はじめに

「コンパウンドスタートアップ」という言葉は、ほとんど耳にしなくなりました。
けれど、その考え方自体は、複数プロダクトを持つビジネスモデルの中で決して古くなったものでありません。むしろ今では、当たり前の前提として受け入れられているように思います。

自分にとっては、会社の事業そのものをシステムとして捉えて設計していくと、ごく合理的なアプローチとしか思えません。

コンパウンドという言葉が示していた本質を振り返る

この言葉が話題になった当時、自分の中ではその核心はとてもシンプルでした。それは、“複数のプロダクトを独立に作るのではなく、共通の基盤を通じて相互に価値を高める” という考え方です。

重要なのは、各プロダクトが同じデータ・同じ世界観を共有していることでした。

そのために、ユーザー情報や認証、データモデル、外部データの扱い方といった共通レイヤーを会社として整え、その上に複数のプロダクトが乗るという構造をつくる。この共通レイヤーを構成する各コンポーネントが、いわゆる“ミドルウェア”と呼ばれていたものだと思います。

共通基盤が各プロダクトを支える構造は特別なことではない

プログラミングを学んだ頃、全部を main に書いていたものが、関数やオブジェクト思考を知るにつれて自然と共通化や抽象化されるようになりました。そして、業務を通して大規模なソフトウェア設計を学ぶ中で DDD を用いたマイクロサービスやSOAのようにサービス単位でもシステムを整理するようになりました。さらに、自社プロダクトを超えて使えそうという部分は、OSS として切り出すことで、グローバルで再利用可能にすることもありました。

コンパウンドスタートアップの文脈で語られる“ミドルウェア”も、結局はその延長線上にあるように思います。

システム設計の感覚が会社の事業全体にまで広がった、というだけで、エンジニアとしては特別に新しい発想ではありません。むしろ、これまで自分たちが当たり前にやってきたこと·やりたかったことが、経営サイドにも伝わりやすい形になった、というのが自分が感じた当時の感覚です。

設計のレイヤーを事業に広げる後押しだった

コンパウンドスタートアップという言葉が話題になったとき、自分が最初に感じたのは、「設計という考え方が、コードやデータベースに閉じず、事業構造の全体に広がっている」というところでした。

エンジニアにとって、正規化したり、抽象化したり、共通化したりしながら複雑さを整理することは当たり前ですし、システム設計が会社全体の事業構造やビジネスモデルに染み出していくのは、コンウェイの法則や DDD の文脈で語られるように、かなり自然なことのはずです。

そういう意味では、コンパウンドスタートアップ戦略は新しさというよりも、「エンジニアが普段やっている設計の感覚を、ビジネスでも積極的に取り入れていこう」という空気を作ってくれた後押しだったように感じています。

おわりに

コンパウンドという言葉はほとんど聞かなくなりましたが、エンジニアにとっては昔からやってきた設計の延長でしかなく、その発想が事業のレイヤーまで自然に広げがったものだと思います。

自分にとっては、エンジニアリングの感覚で会社の事業を考えることを当たり前にしてくれた言葉で、ひそかにうれしい変化でした。

「共通の基盤で複数プロダクトを支える」という考え方はむかしからあるものですし、これからも残り続けると思います。