前置き

今回は、事業のビジネスアーキテクチャの面から、どのようにソフトウェアアーキテクチャの設計思想を使って、全体を設計構築していくのか？を見ていきます。

事業は、スタートアップの立ち上げ期であっても、業務の中で汎用的な業務部分を人による業務ではなくSaaSやBPaaSで代替させ、「コスト削減と品質のムラをなくしたい」という部分と、コアとなる部分を明確に設計され続ける必要があります。

その際に、自分たちで実装するコア業務と上記のSaaSやBPaaSの汎用部分との連携を考えなくてはならないので、結果的に事業全体のビジネスアーキテクチャは、マイクロサービスアーキテクチャの構造にならざるを得ないです。

意図的に「マイクロサービスアーキテクチャを設計しよう」と考えていなくても、SaaSやBPaaSを積極的に活用した結果として、企業全体のビジネス構造は事実上のマイクロサービスアーキテクチャになってしまうんです。

なぜそうなるのか？

これは、ビジネスの関心事を「自社で差別化すべきコア業務」と「他社と同じでよい汎用業務」に分離し、それぞれを独立した「サービス」として扱うアプローチだからです。

この構造は、以下の3つの要素で構成されます。

1. コアドメイン（自社実装） 🧠

役割

スタートアップの競争優位性の源泉 です。

他社にはない独自の価値を提供するビジネスロジックで、DDD（ドメイン駆動設計）でいうコアドメインに相当します。

事例

独自の推薦アルゴリズム、特殊な分析エンジン、革新的なUXを提供するアプリケーション。

2. 汎用サブドメイン（SaaS/BPaaS）🧩

役割

どの企業でも必要になるが、差別化要因にはならない汎用的な業務です。
DDDでいう汎用サブドメインや支援サブドメインに相当します。

事例

・決済：Stripe, PayPal

・顧客管理 (CRM)：Salesforce, HubSpot

・人事・労務：Workday, SmartHRなど

・コミュニケーションツール：Slack, Microsoft Teams

3. 連携（API / Webhook / イベント）🔗

役割

自社のコア業務と外部のSaaSを連携させる「接着剤」です。

この連携部分こそが、マイクロサービスアーキテクチャの「サービス間通信」に相当しています。

事例

自社アプリで商品が購入されたら、StripeのAPIを呼び出して決済を実行する。

Stripeで決済が完了したら、Webhook経由で自社アプリに通知が届き、注文ステータスを更新する。

マイクロサービスアーキテクチャとの類似点

この構造は、マイクロサービスアーキテクチャの重要な特性をすべて備えています。

サービス境界の明確化

自社が作るべき範囲と、SaaSなどの外部サービスに任せる範囲が明確に分離されています。

独立した運用とデプロイ

自社のコア業務は、StripeやSalesforceのリリースサイクルとは無関係に、いつでもデプロイできます。

APIによる連携

サービス間の通信は、明確に定義されたAPIを介して行われます。

スタートアップにとってのメリット 🚀

この「事実上のマイクロサービス」構造は、リソースの限られたスタートアップにとって極めて合理的です。

集中

最も価値を生むコア業務の開発に、人的・資金的リソースを集中投下できます。

スピード

差別化につながらない車輪の再発明（決済システムや人事システムの自社開発）を避け、迅速にビジネスを立ち上げられます。

品質

各分野の専門企業が提供する高機能で安定したSaaSを利用することで、全体的なサービスの品質を高く保てます。

ここのまとめ

結論として、現代のスタートアップがSaaS/BPaaSを活用して賢くビジネスを構築しようとすると、その結果として生まれるアーキテクチャは、必然的にマイクロサービスの思想を体現したものになります。

いきなりの非同期はやめる

しかしながら、スタートアップの導入期や、成長期初期ですと、いきなり自社のコア業務と外部のSaaSを連携させる通信の接合部を非同期にするということは実質難しいです。

この場合には、インフラ基盤はあえてモノリシックな構造にして、その上で動くソフトウェアやBPaaSのみ外部から利用するという戦法の方が妥当です。

いきなり非同期連携を前提とした分散アーキテクチャを目指すのは、多くの場合、時期尚早な最適化となります。

なぜ、その戦法が妥当なのか？

スタートアップの最優先事項は、完璧なアーキテクチャを構築することではなく、最小限のコストで迅速にプロダクトを市場に投入し、PMF（プロダクトマーケットフィット）を達成することだからです。

1. 複雑性のコントロール

非同期通信は、アウトボックスパターン、メッセージブローカーの運用、結果整合性の考慮、分散トレーシングによるデバッグなど、対処すべき複雑性が爆発的に増加します。

リソースが限られている初期段階では、この複雑性は開発スピードを著しく低下させます。

一方、

モノリシックな構造での同期通信は、シンプルで理解しやすいという絶大なメリットがあります。問題が発生した際も、原因の特定が比較的容易です。

2. 開発スピードの最大化

同期APIコールは、response = stripe.charge()のように、直線的なメンタルモデルで実装できます。
これにより、

開発チームはビジネスロジックそのものの実装に集中でき、迅速なイテレーションが可能

になります。

3. 運用のシンプルさ

インフラ基盤がモノリシックであれば、デプロイ、監視、ロギングの対象が一つにまとまります。これは、専門のSREチームが存在しない初期のスタートアップにとって、運用負荷を大幅に軽減 します。

これは「戦略的モノリス」である

重要なのは、このアプローチが

単なる場当たり的なモノリスではなく、将来の分割を見越した「戦略的モノリス」

であるという点です。

明確な境界

外部SaaSとの連携部分は、明確なAPIコールとしてコード上に存在します。

これは、将来非同期化するための 最初の「継ぎ目（Seam）」 となります。

進化のタイミング

ビジネスが成長し、

・特定の同期APIコールがパフォーマンスのボトルネックになったり（例：時間のかかるレポート生成SaaSの呼び出しがユーザーの操作をブロックする）

・より高い回復力が求められたりした

その時点で初めて、その部分だけを部分的に非同期化すればいいんです。

YAGNIの原則

これはまさに「YAGNI (You Ain't Gonna Need It)」の原則の実践です。
必要になるまで、非同期化という複雑な仕組みは導入しません。

ここのまとめ

結論として、インフラをモノリスに保ち、外部SaaSと同期的に連携する戦略は、スタートアップが最も重要なビジネス課題に集中するための、極めて成熟した戦略と言えます。

成長期フェーズでのインフラ管理

成長期に入り、企業の提供するビジネスやソフトウェアの需要が上がっていったら、徐々に自社の自前で実装していた業務やソフトウェアも分割する必要性にかられます。この時が一番、モノリシックなインフラ構造であることが企業にとってストレスになり得ると思うので、サーバーレスアーキテクチャを採用し、インフラ基盤を自分たちで運用する手間とコストを削減するのはベターかなと思います。　成長期フェーズでもインフラ基盤を分離するようなケースってあるの？

なぜサーバーレスが基本戦略なのか

運用負荷の削減

サーバーのプロビジョニング、パッチ適用、スケーリングといった運用業務をクラウドプロバイダーに任せられるため、少人数のチームでもプロダクト開発に集中できます。

コスト効率

リクエストがない時は課金されないため、トラフィックの増減が激しい成長期のスタートアップにとって、コストを最適化しやすいです。

スケーラビリティ

需要の急増に合わせて自動的にスケールするため、急な成功（Success Disaster）にも対応できます。

成長期でもインフラ基盤をあえて分離・自社管理するケース

サーバーレスが万能ではない領域も存在します。

ビジネスの特定の要求を満たすために、あえてECS/EKS (Kubernetes) やEC2のような、よりコントロール性の高いインフラをサーバーレスと併用するのです。

1. 高度なパフォーマンスと低レイテンシの要求 ⏱️

課題

サーバーレス（特にLambdaなど）には「コールドスタート」という初回起動時の遅延があります。

ミリ秒単位の応答速度が求められるサービスでは、これが致命的になる場合があります。

ケース

・リアルタイムの広告入札（Ad-Tech）

・オンラインゲームのバックエンド

・高頻度取引（FinTech）

解決策

常に起動状態を保てるコンテナ（ECS/EKS）や仮想マシン（EC2）を、低レイテンシが求められる部分に限定して採用します。

2. 長時間実行される、あるいはステートフルな処理 💾

課題

サーバーレス関数は、実行時間に制限があり（例: Lambdaは最大15分）、ステートレス（状態を持たない）であることが前提です。

ケース

・大規模なデータ分析や機械学習のバッチ処理

・リアルタイムの双方向通信（WebSocketサーバーなど）

・インメモリで大量のキャッシュを保持する必要があるサービス

解決策

これらの長時間・ステートフルなワークロードには、コンテナや仮想マシンが適しています。

3. コストの予測可能性と大規模トラフィック 💸

課題

サーバーレスはリクエスト単位の課金のため、トラフィックが非常に多く、かつ安定してくると、常に起動している仮想マシンを定額で利用するよりもコストが高くなる「コスト逆転現象」が起こり得ます。

ケース

・常に高いトラフィックがある主要なAPIエンドポイント

・大規模なSaaSのバックエンド

解決策

ベースとなる一定のトラフィックを、
コスト効率の良いリザーブドインスタンスなどで捌き、
急なスパイク分だけをサーバーレスで吸収する、といったハイブリッド構成を取ります。

4. プラットフォームエンジニアリングへの投資 🛠️

課題

組織が拡大し、複数の開発チームが共通のインフラ基盤を必要とするようになると、全社的なガードレールや標準化された開発体験を提供する必要が出てきます。

ケース

社内開発者向けに標準化されたCI/CD、監視、セキュリティの仕組みを「プラットフォーム」として提供したい場合。

解決策

Kubernetes (EKS/GKE) を採用し、その上に社内プラットフォームを構築します。

これにより、開発者はインフラの詳細を意識することなく、迅速かつ安全にアプリケーションをデプロイできるようになります。

結論：ハイブリッドアプローチが現実解

成長期のスタートアップにとって、「全てをサーバーレスにする」か「全てを自社管理するか」という二者択一ではありません。

ほとんどのスタートアップは、ハイブリッドアプローチを採用します。

基本はサーバーレス

通常のAPI、バッチ処理、イベント駆動のロジックなど、ビジネスロジックの**80%**はサーバーレスで実装し、速度と効率を最大化します。

例外は分離・自社管理

パフォーマンス、コスト、特殊な要件といった特定の課題を持つ 20% のワークロードだけを、コンテナや仮想マシンで運用します。

アナロジー

これは、運送会社が普段の配達には燃費の良い標準的なトラック（サーバーレス）を使い、
冷凍品や巨大な荷物といった特別な輸送には専用の冷凍車や大型トレーラー（分離されたインフラ）を用意するのに似ています。
適切なツールを適切な場所に使うことが、最も賢明な戦略なのです。