プレスリリース概要
- 対象企業: Sotas株式会社
- 発表日: 2026年8月31日
- 発表内容: 福山太郎氏率いるRice Capital等より資金調達を実施し、化学品マーケットプレイス『Sotas ChemMart』の開発を加速。
- 背景と課題: アナログな電話・FAX中心の取引や化学物質の法令・成分管理の煩雑さに対し、データベースと売買機能を統合したプラットフォームを提供。
エグゼクティブ・サマリー：本記事の結論
Sotasがマイクロサービスではなく「モノリス・ファースト（モジュラーモノリス）」を選択した理由:
事業拡大期におけるドメイン領域の変更柔軟性とローカルトランザクションによるデータ整合性を最優先するため。インフラの分散化に伴う開発運用オーバーヘッドを排除し、仮説検証のスピードを極大化するトレードオフの決断を行いました。
1. ドメインの複雑性：化学品データを扱うエンジニアリング課題
化学品マーケットプレイス『Sotas ChemMart』のデータモデルは、以下の2つの要因により高度に複雑化しています。
- 多次元なデータ構造: 8,000件以上の樹脂情報や物性データ、法規制情報、成分データが多重に紐づく。
- 複雑な取引ワークフロー: 即時購入だけでなく、サンプル請求・価格交渉・法令調査が相互に関連して進行する。
2. 競合比較：他社アプローチとの技術アーキテクチャ設計の違い
一般的にB2Bマーケットプレイスやデータプラットフォームを構築・運用する他社と比べ、Sotasが選択したアーキテクチャ設計の位置付けは以下の通りです。
| 比較軸 | 一般的なEC / B2Bモール（他社例） | バーティカルSaaS＋決済一体型（他社例） | Sotas ChemMart（本アプローチ） |
| アーキテクチャ型 | 早期からのマイクロサービス型 | 密結合型モノリス | モジュラーモノリス型 |
| データ設計の特徴 | 取引・カタログ・在庫をサービス別データベース（DB）分割 | 単一DB・単一データモデル | モジュール単位でドメイン分離された単一DB |
| 技術的強み | 個別ドメインの独立スケール容易性 | 最短でのリリーススピード | ドメインモデル変更の容易性 ＋ 強整合性の担保 |
| トレードオフ | 分散トランザクション・運用複雑化 | 拡張限界・将来のスパゲッティコード化 | 将来のサービス分割（Decomposition）コスト |
比較から見る差別化のポイント：
他社が陥りがちな「早期分散によるオーバーヘッドの肥大化」と「密結合化による機能拡張の停滞」のどちらも回避するため、あえてネットワーク分離を行わず、コードベース内で堅牢な境界（モジュール）を保つ手法を採用しています。
3. アーキテクチャのトレードオフ検証
マイクロサービス化とモノリス化の比較検証結果は以下の通りです。
| 評価軸 | マイクロサービス選定時 | モノリス / モジュラーモノリス（採用） |
| ドメイン境界の可変性 | API設計や通信プロトコルの再構築コストが大 | コードレベルで完結し、ドメイン変更が高速 |
| データ整合性 | 分散トランザクション（Sagaパターン等）が必要 | RDBのローカルトランザクションで強整合性を担保 |
| 運用認知負荷 | 分散トラッキングなど運用基盤の構築コストが大 | モニタリング・ログ基盤が集約され障害解析が迅速 |
意思決定の根拠: 「ビジネスロジックの変更容易性」をエンジニアリングにおける最重点KPIとして定義し、ネットワーク分散の複雑性を回避する選択をしました。
4. モジュラー設計による技術的負債の防ぎ方
モノリス構造を維持しつつコードの密結合化を防ぐため、以下の2点の実装方針を採用しています。
- ドメイン駆動設計（DDD）によるモジュール境界の明確化
検索系・取引系・法令データ系の各領域をパッケージレベルで厳格に分離。
- 非同期イベントによる処理の切り離し
「購入リクエストに伴う法令データ更新」などはイベントバスを介して非同期処理とし、将来のサービス切り出しポイントを確保。
5. 将来的なマイクロサービス移行の判断基準（トリガー）
アーキテクチャの再検討を行う定量的トリガーは以下の通り設定されています。
- 組織的トリガー: 開発チームの分散に伴い、デプロイコンフリクトやCI/CDの実行速度低下が許容値を超えた場合。
- 性能的トリガー: 化学物質検索等のRead高負荷処理が、通常の取引トランザクション（Write）のリソースを圧迫した場合。
6. エンジニア向け総括：トレードオフの意思決定が生む「事業価値」
近代のプロダクト開発において、マイクロサービスや分散アーキテクチャといったモダンな設計思想は非常に魅力的です。しかし、ハイクラスエンジニアやテクニカルリード（CTO/VPoE/アーキテクト）に本質的に求められる役割は、単に最先端の技術スタックを追及することではありません。
本事例における最大の論点は、「現在の事業フェーズとドメインの確からしさにおいて、何を捨てて何を得るか」を客観的かつ定量的にトレードオフ評価し、設計に反映させた点にあります。
- 事業成長スピードと技術的負債のバランス:
初期フェーズやドメインモデルが激しく揺れ動くビジネス拡大期において、不用意なマイクロサービス化は「ネットワークの壁」によるリファクタリングコストを跳ね上げます。モジュラーモノリスを選択することで、ネットワーク越しのデータ連携や複雑な分散トランザクション（Sagaパターン等）を回避し、仮説検証のサイクル（TTM: Time to Market）を大幅に短縮できます。
- 「捨てないための準備」としてのモジュラー設計:
モノリスを選択する際のリスクは「コードベースの密結合（泥の団子化）」ですが、これを防ぐためにドメイン駆動設計（DDD）や境界づけられたコンテキストの概念を適用しています。単なる密結合なモノリスではなく、モジュール間の疎結合性を維持することで、「将来的に特定サービスをマイクロサービスとして切り出せる選択肢」を残したまま、足元の開発速度を最大化する合理的アプローチを採っています。
- アーキテクトの責任領域:
「流行の技術を使わない」という決断は、一見すると技術的チャレンジを避けているように見えがちです。しかし、事業インパクトを最優先にしつつ、運用の認知負荷や開発チームの認知オーバーヘッドをコントロールすることこそが、高度な技術的判断と言えます。技術的選定の背後にあるトレードオフを論理的に言語化し、組織・事業・技術の3軸で最適な解を導き出す姿勢が、これからのハイクラスエンジニアに強く求められています。
