株式会社イタンジ（以下、イタンジ）は不動産賃貸取引を円滑にするためのサービスを提供しています。今回はアプリケーションを分割化するタイミングやメリット・デメリットについて、イタンジ執行役員の永嶋章弘氏にご寄稿いただきました。

アプリケーション分割、終わらない論争

競合が生まれやすいSaaS市場では、マーケットシェアを短期間で1社が独占しようとするよりも、1社あたりのACV（1社あたりの平均年間契約額）を改善し、LTV（顧客生涯価値）を最大化させていくのが、より現実的な経営戦略です。

そのため多くのSaaS企業は、アップセル・クロスセルを繰り返す必要があり、必然的にアプリケーション数が増加する傾向にあります。

少し前の話になりますが、GitHubの元CTOが下記のようなツイートをしていました。

出典：https://twitter.com/jasoncwarner/status/1592227285024636928

翻訳すると下記のような感じでしょうか。

私は、過去10年間のアーキテクチャ上の最大の間違いの1つは、完全なマイクロサービス化であると確信しています。

モノリスからマイクロサービスまでのスペクトラムで、私は次のように提案します。

モノリス > アプリ > サービス > マイクロサービス

それでは、いくつか考えてみましょう。

このツイートのスレッドには長い解説が続き、その内容は多くの反響を呼びました。

このように、ITシステムを構築する上でのアプリケーション分割、つまりどのようにシステムを分割していくかという話題は多くのITエンジニアの興味を抱くものだといえるでしょう。

本稿では、不動産業務のSaaS企業であるイタンジのアプリケーション分割に関する変遷を通じて、我々がどのようなタイミング、どのような単位でアプリケーション分割を行ってきたか、そしてその中で「やってよかった」と感じていることは何かをご紹介します。

1つのケーススタディとして、アプリケーション分割のご参考になれれば幸いです。

言葉の定義

今後の話をしやすくするために、ここでの言葉の定義をしておきます。

Monolith: 複数のアプリケーション（※ここでのアプリケーションは、1つの業務等の課題を解決する単位）が同じコードベース、デプロイ単位で管理されている状態
Apps: アプリケーションごとにコードベース、デプロイ単位が管理されている状態
Services: アプリケーションでなくて、アプリケーションを構成する機能単位でコードベース、デプロイ単位が管理されている状態（ECのサービスがあるとして、商品の検索、購入などというように大きめの単位で分かれている）
Microservices: Servicesをさらに細かく分けた状態（上記のECの例だと購入をさらにカートへの追加、与信問い合わせ、決済などに分けた状態）