他の創業者から寄せられる最も一般的な質問は、価格設定や市場参入に関するものではありません。それは静かで、少し疑わしいものです。 あなたくらいの規模のチームが、全体が崩壊することなく 150 個のモジュールを維持するにはどうすればよいでしょうか? 正直な答えは、150 個のモジュールを維持していないということです。私たちは 1 つのプラットフォームとその上の非常に薄いレイヤーを維持しています。重要なのは、その作品がどの層に属するかについての無慈悲さです。
人々を怖がらせる数学。
150 個のモジュールを、それぞれ独自のデータ モデル、独自の権限、独自の請求、独自の通知を持つ 150 個の小さなアプリケーションとして想像すると、22 人という人数は明らかに狂気です。これはエンジニア 1 人あたり 6 つのモジュールであり、それぞれが独立した製品になります。それを生き残るチームはありません。そのアーキテクチャに関しては、その懸念は正しいです。
しかし、それはアーキテクチャではありません。 CRM、請求ツール、ヘルプ デスクは、ユーザーにとって 3 つの異なる製品のように見えます。その下には、記録、関係、イベントのタイムライン、役割と権限、お金、ドキュメント、通知バスなど、同じ少数のプリミティブがあります。 違いは主に語彙とレイアウトであり、機械ではありません。
私たちは 150 個の優れた製品を開発しているわけではありません。私たちは、150 通りに構成された、少数の適切に構築されたプリミティブを構築しています。
コア/モジュールの分割。
ID、アクセス許可、リレーショナル データ レイヤー、支払い、ファイル ストレージ、検索、監査ログ、通知システム、エクスポート エンジンなど、あらゆるハードウェアがコア内に存在し、一度構築されます。これらは本当に難しく、真に共有される部分です。ここで修正されたバグは、150 個のモジュールすべてに対して一度に修正されます。ここで追加された機能 (電子署名など) は、それを必要とするすべてのモジュールで即座に利用できるようになります。
したがって、モジュールは意図的に薄くされています。それは、データ スキーマ、一連のビュー、1 つまたは 2 つのワークフロー、および 1 つのジョブの語彙です。 「CRM」は、次のような構成です。これらのレコード タイプはリードと取引であり、これはパイプライン ビューであり、これらはステージであり、これがコンバージョンの意味です。完全にコアに乗っています。新しいモジュールは主に宣言であり、コードではありません。
厳しいルール: 自分の独自性を獲得することです。
これを腐らせないための規律は、レビューによって強制される単一のルールです。 本当にそれを獲得した場合を除き、モジュールが特別であることは許されません。 モジュールが独自のオーダーメイドの権限モデル、独自の 1 回限りの通知形式、日付を保存する独自のプライベートな方法を必要とするたびに、デフォルトの答えは「ノー」です。それを一般的な機能としてコアに組み込むか、そうでないかのどちらかです。
これは現時点では厄介ですが、何年にもわたって決定的になります。 「ここに何かカスタムが必要です」というリクエストのほとんどは、実際には「一般的なケースについて十分に検討していない」というものです。一般的なケースを強制すると、コアがより豊富になり、すべてのモジュールが恩恵を受け、モジュール数が増加しても、維持する必要がある表面積はほぼ平坦なままになります。
私たちが諦めたもの。
このアプローチには実際のコストがかかるので、それに名前を付ける必要があります。 1 つのジョブに夢中になっているチームによって構築された最高のポイント ツールは、その 1 つのジョブに関して同等のモジュールを上回ります。最も奥深い電子メール プラットフォームには、私たちにはない自動化が備わっています。最も深いプロジェクト ツールには、私たちにはないビューがあります。私たちはそうではないふりをしているわけではありません。
その深さと引き換えに、一貫性、つまり 1 つのデータ モデル、1 つのログイン、1 つの請求書、1 つのエクスポート、および 1 つの通知レイヤーを共有するモジュールが得られます。 5 ～ 50 人のチームの場合、その一貫性は、単一のカテゴリの深さの最後の 20% よりも価値があります。ビジネス全体がその 1 つのカテゴリーであるチームの場合、そうではありません。私たちは自分たちの目的を正確に知っており、22 名で彼らにサービスを提供できるのはそのアーキテクチャのおかげです。