コンパウンドスタートアップを支える技術戦略

HQ はこれまでリモートワーク環境整備プラットフォーム「リモートHQ」を運営してきましたが、この度より包括的な福利厚生サービス「カフェテリアHQ」の提供を開始しました:

この二つのプロダクトは部分的に非常に似た機能を共有しますが、福利厚生領域に存在する異なる課題をそれぞれ解決することを目的とした、完全に独立したプロダクトです。

HQ はリモート HQ で創業した当初から、将来的なカフェテリアプラン領域への参入を事業成長の方向性の一つとして掲げ、準備を進めてきました。 つまり HQ はコンパウンドスタートアップの一つです。

コンパウンドスタートアップとは

• 創業時から単一プロダクトではなく、複数プロダクトを意図的に提供
• 部署でサービスを区切るのではなく、データを中心にサービスを統合する
• プロダクト間の連携の良さそのものがプロダクトである
• 複数のプロダクトを管理、ローンチするケイパビリティを持つ

という特徴のスタートアップです。

コンパウンドスタートアップという LayerX の挑戦｜福島良典 | LayerX

コンパウンド戦略の成功は、展開するプロダクトの選択もさることながら、適切な技術選択とアーキテクチャ設計に大きく依存します。

この記事では、コンパウンド戦略を前に HQ がどのように技術課題を認識そして対応し、業界内での競争優位を築いていくか、その外観を紹介します。

アーキテクチャの概要

HQ の基本的な技術戦略は、明確に定義されたドメイン境界に基づいて設計されたモノリシックサーバーと、プロダクトの文脈に応じて適切なプレゼンテーションを提供するクライアントアプリケーションによるクライアント・サーバーモデルに支えられています。¹

ドメインの複雑さに立ち向かう

コアサーバーは HQ が扱う福利厚生領域を広くモデル化したコアドメインを中心とした、よくある四層からなるレイヤーアーキテクチャで構成されたモノリシックサーバーです。 コアドメインは特定のプロダクトだけのものではなく、全プロダクトで共通の概念を表現しており、プロダクト間のデータ共有や処理の再利用を可能にしています。 ドメインを設計する際は、極力特定のプロダクト固有の知識をハードコードしてしまわないよう心掛け、ドメインの本質的な概念を抽出して再利用可能な形で表現することを重視しています。

例えば、リモート HQ とカフェテリア HQ はそれぞれ異なるプロダクトですが

• 従業員は組織からポイントを付与される
• 組織が許可した福利厚生サービスを利用できる

という共通の構造を持っています。 このような共通の概念をコアドメインとして抽出することで、両プロダクト間でのデータや処理を共通化するだけでなく、新しいプロダクトを追加する際にも効率的に開発を進めることができます。

有向非巡回グラフで表現されたコンテキストマップの一部

一方で、全てを抽象化することが正しいわけではなく、プロダクト固有の要件やビジネスロジックを適切に表現することも重要です。 このようにドメインを適切に設計するには、高い技術力だけでなく何より深いドメインへの理解が求められます。

HQ 開発チームでは、ドメインマスターとの密なコミュニケーションを通じてドメインの理解を深めることを重視し、継続的な対話を通じてドメインの変化に柔軟に対応しています。

Go 言語と循環参照

システムアーキテクチャにしろドメインのコンテキストマップにしろ、循環参照は複雑さを増す要因の一つであり、可能な限り避けるべきとされます。 その点 Go はパッケージ間の循環参照を言語として許容しないため、 Go パッケージとして境界づけられたコンテキストを表現していくと、自ずから循環参照を持たない設計になります。

制約を回避するためには interface を介して依存方向を逆転させるなどの工夫が必要となり、面倒に感じる場合もあります。 しかし、適切に設計を進めていくと、すべてのドメインモデルがあるべき姿に落ち着くことが多く、逆に循環参照を欲する場面はドメイン理解が不足していることを示唆する重要なシグナルであると感じるようになりました。

当初は Google Cloud の SDK などを利用することを念頭に Go 言語を採用しましたが、循環参照を避ける設計がドメインの理解を深める助けになるという意外なメリットを感じています。

GraphQL

コンパウンド戦略は、コアサーバーとクライアントアプリケーションをつなぐ API 設計にも大きな影響を与えます。

HQ では API として GraphQL を採用しており、コアサーバーは単一の GraphQL エンドポイントを提供しています。 プロダクトを横断したデータの取得や更新を一つの GraphQL エンドポイントに集約することで実装を DRY に保つことが可能となる一方で、多様なユースケースをサポートするためにスキーマを設計する際に考慮するべきことも増えます。

Query はリソース指向

Query で取得する type は、前述のドメインモデルに基づいてリソース指向に設計されています。 プロダクトごとに type を分けず、同一の概念であれば共通の type として表現することで、プロダクト間のデータ共有を容易にしています。

特定のプロダクトからのみ利用される field も中には存在します。 現在は特に問題になっていないため、そのまま残している状況ですが、今後のプロダクト開発が複雑化していった際には GraphQL ディレクティブを活用して、特定のプロダクトにのみ公開するようにすることも検討しています。

Mutation はユースケース指向

Mutation もまた原則としてリソース指向に設計されていますが、中には複数のリソースを単一のアクションで更新するようなユースケースも存在します。 また Query と比較してよりプロダクト固有のロジックを含むことも多いため、ユースケースごとに Mutation を分けることで、プロダクト固有のロジックを明確に表現しています。

例えばあるリソースを作成する際、プロダクトごとに必要な情報が異なる場合があります。 GraphQL では input の union が現状サポートされないため、一つの Mutation で全てのプロダクトに対応しようとすると例えばこのようなスキーマが必要となります:

input CreateResourceInput {
  name: String! # 共通
  foo: String # プロダクトAでのみ必要
  bar: Int # プロダクトBでのみ必要
}

type Mutation {
  createResource(input: CreateResourceInput!): Resource!
}

上記のスキーマは必要な field を入力し忘れたり、不要な field を入力してしまう可能性があります。 HQ 開発チームでは「スキーマから読み取れる情報を最大化する」という方針をとっており、その観点からもこのスキーマは望ましいものとは言えません。

代わりにこのような場面ではプロダクトごとに Mutation を分けます:

input CreateResourceForProductAInput {
  name: String!
  foo: String!
}

type ProductAMutation {
  createResource(input: CreateResourceForProductAInput!): Resource!
}

type Mutation {
  productA: ProductAMutation!
  productB: ProductBMutation!
}

こうすることでプロダクトごとに複雑化していく要件を個別に管理することができ、スキーマの保守性と拡張性を高めています。

セキュリティとデータ活用

カフェテリア HQ は技術進歩が停滞していた福利厚生領域に一石を投じるプロダクトです。 個のニーズの多様化と AI 技術の進歩に沿って進化するべく、データ活用が重要な要素となっています。

またプロダクトの連携そのもの価値にするコンパウンドスタートアップとしても、データ整備への投資は戦略上非常に重要です。

前のめりのセキュリティ

Google の DevOps Research and Assessment（DORA）は、2016 年の State of DevOps Report の中で、セキュリティを開発の初期段階から取り組むことが重要であると指摘しています。 設計段階で発見されたセキュリティ上の問題は、実装段階で発見されたものに比べて 100 倍以上のコスト削減が見込まれるとの試算もあり、セキュリティのシフトレフトの重要性が強調されています:

出典: 開発の早期段階における投資が後のコストを削減: セキュリティのシフトレフトで最終的な収益を強化 | Google Cloud 公式ブログ

スタートアップの最大の強みはスピードです。 その強みを活かすためにも、セキュリティを開発の初期段階から取り組むことが重要です。 一例として以下のような取り組みを行っています:

• 設計段階からセキュリティを意識した設計を行う
• Terraform でインフラのコード化と最小権限の原則の徹底
• Cloud Armor で WAF（Web Application Firewall）を導入し、アプリケーション層でのセキュリティ対策を強化
• OWASP のチェックなどについても早期から取り組む
• など

データフローの集約

プロダクトで発生するデータの流れが複雑化していくと、守るべきものも増えていき、その結果としてセキュリティ対策のコストが増大していきます。

HQ ではプロダクト上で発生するあらゆる情報を一元的に管理された専用の Google Cloud プロジェクトへと集約することで、データの流れを可視化し、セキュリティ対策を効率的に行っています。 Google Cloud 上でのデータ集約と権限管理についてはまた別の機会に詳しく紹介したいと思います。

データの活用と将来の展望

既存プレイヤーとの戦いにおいて、データ活用は重要な要素です。 今はまだ初歩的な段階ですが、データに駆動された高度な機能提供に向けた取り組みを開始しています。 将来的には、収集したデータを基に機械学習モデルを用いて更に精度の高いパーソナライズを実現することを目指しています。 このためには、データの質と量をさらに向上させ、より複雑な分析が可能なシステムの開発が求められます。

また、データ保護規制が厳しくなる中で、プライバシーを守りつつどのようにデータを活用するかが重要な課題です。 カフェテリア HQ では、個人情報保護法に準拠したデータ管理を徹底し、顧客に透明性を提供することで、その課題に対応しています。

まとめ

HQ のコンパウンド戦略は、連携したプロダクト群が一体となって複雑な課題に対応することで、企業の成長と市場での優位性を確保します。 今後も、革新的な技術と戦略的な思考で、持続可能なプロダクト開発を進めていきます。

Footnotes

1. 少し前の記事ですがシステムアーキテクチャ 2023 年 6 月版も合わせてご覧ください。 ↩