これからSaaSを開発するなら知っておきたいカスタムオブジェクトという選択肢
こんにちは。製薬業界向けのSaaSを提供するシャペロンでCTOをしている浅野です。
シャペロンは製薬業界向けのVertical SaaSを提供しており、事業の初期から複数のプロダクト展開に取り組んでいます。今後はこれらのプロダクトをさらに拡充し、プラットフォームとしての形を目指す中で、拡張性が一層求められるようになってきました。拡張性を実現する方法はさまざまですが、この記事ではその一つ、「カスタムオブジェクト」という概念についてご紹介します。Salesforceでおなじみの機能なので、既にご存知の方も多いかもしれません。
なぜこのテーマを取り上げるかというと、ぼく自身がシャペロンでSaaSのゼロイチ開発に挑んだ最初の一周目では、その重要性に気づけなかったからです。もし次にSaaSを立ち上げる機会があるとすれば、たとえ初期コストがかかったとしても、開発初期にしっかり方針を決めて設計すると思います。
この記事は技術寄りのプロダクト戦略についての内容なので、特にSaaSのシード期に関わる開発者やプロダクトマネージャーの方にぜひ読んでいただきたいと思っています。
なぜ拡張性が必要なのか？
そもそも、初期のSaaSに拡張性が必要になるケースはほとんどありません。立ち上げ段階では、ドメインモデルをそのままデータスキーマとしてRDBなどで永続化するだけで、機能提供には十分だからです。
しかし、事業が成長し、プロダクトが複数に増えてくると、プロダクト群で共通して利用するデータ（ユーザーや顧客情報など）を定義し、それを整備・育成していく必要が出てきます。その過程で、共通データにはさまざまな要件が求められるようになります。
利用企業A「顧客オブジェクトに識別コードをつけて欲しい」
プロダクトBのPdM「顧客オブジェクトに新機能で使うための英語の氏名を入力できるようにして欲しい」
こうした要件が増えるたびに、RDBのマイグレーションを行い、アプリケーションコードを追加していく対応が本当に正しいのでしょうか？
Salesforceのアプローチ
Salesforceは、このような要件に対する圧倒的な拡張性を提供することで成功を収めた、世界最大のCRM SaaSです。
Salesforceでは、標準オブジェクト（取引先やリード、商談など）で表現できないビジネス特有のデータモデルを作成するために「カスタムオブジェクト」が提供されています。言い換えれば、カスタムオブジェクトとは、RDBにおけるテーブルやカラムが仮想化されたデータ基盤を指します。
Salesforceの経験がある人にとっては常識かもしれませんが、実際には業界内でも経験者は限られており、開発者コミュニティでもあまり取り上げられないテーマです。そこで、あえてここで紹介しておきます。
Hubspotのアプローチ
Hubspotは、Salesforceよりも新しい世代のマーケティングSaaSです。CRMとしても利用できますが、最初はメルマガ配信ツールとして導入する企業が多いかもしれません。
Hubspotは当初から「プロパティ」という機能を提供しています。これは標準オブジェクトに新しい属性を追加できる機能で、いわば「カスタムプロパティ」と言い換えることができます。
SalesforceがRDBのテーブルを仮想化しているとすれば、Hubspotはカラムを仮想化しているイメージです。仮想化のレベルではSalesforceに劣りますが、プロパティの拡張性に開発投資をしている点がHubspotの戦略といえます。
ここでは、カスタムプロパティに対応している標準オブジェクトについても「カスタムオブジェクト」と呼ぶことにします。
なぜ開発初期の意思決定が重要か？
記事の冒頭で、もし次に挑戦する機会があれば、開発初期に方針を検討したいとお話ししました。しかし、単にユーザーが新しいオブジェクトや属性を追加できるようにするだけがゴールであれば、あとから検討しても問題はありません。では、なぜ初期に検討する必要があるのでしょうか？
後からだと困るのは、たとえば次のような要望が出てきた場合です。
メルマガ配信では配信先の絞り込み条件に、標準プロパティの「ナーチャリングスコア」と、カスタムプロパティの「特定のイベントへの参加者」の両方を使いたい
このように、標準オブジェクトとカスタムオブジェクトを区別せずに使いたいという要件は、遅かれ早かれ出てくるものです。これを実現する最もシンプルな方法は、仮想化されたデータ基盤を構築し、その上で標準オブジェクトとカスタムオブジェクトの両方を定義することです。
データをどこまで仮想化するかにはさまざまなレベルがありますが、Salesforceは実装面でも極端な仮想化を徹底しており、EAVというSQLのアンチパターンとされる手法を戦略的に採用しています。詳しくは、以下の記事をご参照ください。
このようなデータ基盤を既存のSaaSに「あとから」導入する意思決定は、既存の実装に大きな影響を及ぼし、コストがかかります。これが、カスタムオブジェクトの導入には戦略的な意思決定が求められる理由です。
どう判断すればよいのか？
自分がシャペロンをローンチした当時を振り返ると、PMFの達成も不透明で、プロダクトビジョンもまだ曖昧な状況でした。そんな中でここまで考慮するのは、正直かなりハードだったと感じます。
一方で、この戦略を取って成功しているSaaS企業は少なくありません。SalesforceやHubspot以外では、個人的にウォッチしている製薬業界向けSaaS大手のVeevaや、「コンパウンド戦略」で有名なHR SaaSのRipplingもその例です。Veevaの創業者は元Salesforceのプロダクトマネージャーであり、Ripplingの創業者はHR SaaSのシリアル起業家です。こうした背景を持つ彼らだからこそ、こうした大胆な意思決定ができるのもうなずけます。
では、ぼくのようにエンタープライズ向けのSaaSを初めて開発する人間は、どうやって判断すればいいのでしょうか？正直、無理ゲーではないでしょうか？
明確な答えがあるわけではありませんが、ひとつ言えるのは、プロダクトビジョンがどれだけ明確かが判断の基準になるということです。ビジョンから逆算して、カスタムオブジェクトが必要かどうかの仮説を立て、その仮説の強さに基づいて判断するのが正攻法でしょう。
さらに、この検討には技術的な背景も考慮する必要があるため、エンジニアが実現性や提供価値について深く議論に参加することが重要です。アメリカであれば、Salesforceなどでの経験を持つエンジニアが転職市場にいるため、より解像度の高い意思決定ができるかもしれません。しかし、日本ではまだ事例が少ないため、不確実性を受け止めたうえで判断する必要があるでしょう。
最後に
シャペロンでは、このようなデータ基盤やカスタムオブジェクトの構築について、エンジニアが中心となってユースケースやアーキテクチャの議論を進めています。
また、エンジニアの採用も積極的に行っていますので、もし興味を持っていただけたら、ぜひチェックしてみてください！