株式会社イタンジ（以下、イタンジ）は不動産賃貸取引を円滑にするためのサービスを提供しています。今回はアプリケーションを分割化するタイミングやメリット・デメリットについて、イタンジ執行役員の永嶋章弘氏にご寄稿いただきました。
アプリケーション分割、終わらない論争
競合が生まれやすいSaaS市場では、マーケットシェアを短期間で1社が独占しようとするよりも、1社あたりのACV（1社あたりの平均年間契約額）を改善し、LTV（顧客生涯価値）を最大化させていくのが、より現実的な経営戦略です。
そのため多くのSaaS企業は、アップセル・クロスセルを繰り返す必要があり、必然的にアプリケーション数が増加する傾向にあります。
少し前の話になりますが、GitHubの元CTOが下記のようなツイートをしていました。
翻訳すると下記のような感じでしょうか。
私は、過去10年間のアーキテクチャ上の最大の間違いの1つは、完全なマイクロサービス化であると確信しています。
モノリスからマイクロサービスまでのスペクトラムで、私は次のように提案します。
モノリス > アプリ > サービス > マイクロサービス
それでは、いくつか考えてみましょう。
このツイートのスレッドには長い解説が続き、その内容は多くの反響を呼びました。
このように、ITシステムを構築する上でのアプリケーション分割、つまりどのようにシステムを分割していくかという話題は多くのITエンジニアの興味を抱くものだといえるでしょう。
本稿では、不動産業務のSaaS企業であるイタンジのアプリケーション分割に関する変遷を通じて、我々がどのようなタイミング、どのような単位でアプリケーション分割を行ってきたか、そしてその中で「やってよかった」と感じていることは何かをご紹介します。
1つのケーススタディとして、アプリケーション分割のご参考になれれば幸いです。
言葉の定義
今後の話をしやすくするために、ここでの言葉の定義をしておきます。
Monolith: 複数のアプリケーション（※ここでのアプリケーションは、1つの業務等の課題を解決する単位）が同じコードベース、デプロイ単位で管理されている状態
Apps: アプリケーションごとにコードベース、デプロイ単位が管理されている状態
Services: アプリケーションでなくて、アプリケーションを構成する機能単位でコードベース、デプロイ単位が管理されている状態（ECのサービスがあるとして、商品の検索、購入などというように大きめの単位で分かれている）
Microservices: Servicesをさらに細かく分けた状態（上記のECの例だと購入をさらにカートへの追加、与信問い合わせ、決済などに分けた状態）
イタンジ株式会社について
イタンジは不動産領域に特化したSaaS等を提供している設立10年目の企業です。
賃貸不動産を借りる一連の流れ（内見の予約、入居申込、賃貸借契約の締結）を電子化する賃貸管理会社・仲介会社向けSaaSサービス群「ITANDI BB+」や、リアルタイム不動産業者間サイト「ITANDI BB」などを提供しています。
リアルタイム不動産業者間サイト「ITANDI BB」は月間約560万PVほどのサイトに成長しており、主力事業である賃貸管理会社・仲介会社向けSaaSサービス「ITANDI BB+」は、ARR（※1）前年比＋70％と成長中。
「ITANDI BB+」の1アプリケーションで賃貸入居申込を電子化するサービス「申込受付くん」は入居申込サービス利用数 2年連続No.1のサービスで、年間約63万件の入居申込に利用（※2）されています。
（※1） ARR：Annual Recurring Revenue（年間経常収益）。各四半期末の⽉末MRRに12を乗じて算出。MRRには、月額利用料金、従量課金、付帯事業の収益を含む。ITANDI BB+の2021年10⽉時点と2022年10⽉時点でのARRを⽐較
（※2） 対象期間：2021年4月1日～2022年3月31日。No.1調査委託先：TPCマーケティングリサーチ株式会社（所在地：大阪府大阪市、代表取締役社長：松本 竜馬）
サービススタート、モノリス時代
「ITANDI BB+」のアプリケーション数は、現在10個ほどまで拡大しました。一番最初のアプリケーションは物件確認自動音声サービス「ぶっかくん」でした。「ぶっかくん」は、不動産業者間での物件確認電話に自動音声で応答することで業務効率化を図れるサービスです。
この時点では当然ですが、モノリスになります。
「ぶっかくん」の導入件数が増加し、次のサービスとしてリリースしたのは、賃貸不動産の内見予約をWebで完結できるようにした「内見予約くん」です。
「内見予約くん」の開発タイミングでもまだ、モノリスでした。
この時点ではサービスが大きく成長できるものなのか分からず、アーキテクチャ設計やインフラの管理コストなどアプリケーション分割にかける工数よりも開発スピードをとるという判断がなされたからです。
3つ目のサービスリリース、Appsへの分割
その後、「内見予約くん」の導入も拡大したため、3つ目のサービスとして現在の主力サービスである賃貸不動産の入居申込システム「申込受付くん」をリリースすることになりました。
この決定の背景としては「申込受付くん」は、これまでのサービスよりも複雑度が高くコードベースが大きくなりそうなこと、また、「申込受付くん」に連携するサービス領域の開発が予定されていた（賃貸借契約を電子化する「電子契約くん」など）ことなどが挙げられます。
ステージは重要です。5-50人規模の会社であれば、モノリス一択です。信じてください。
上記のようにGitHubの元CTOは開発メンバーの人数でフェーズを切っているようです。
冒頭でも触れましたが、SaaS企業はLTVを最大化するためアップセル・クロスセルを重ねる必要があり、ほとんどのケースでマルチアプリケーション化するため、いずれはAppsへの分割を検討すると思います。
ですので、SaaSにおいてはいわゆるPMF（サービスが市場に受け入れられる状態）を迎えるまではモノリスでいくのがよいと思います。そしてPMFが見えてきたらAppsへの移行を検討していきます。私たちにとってはこの「申込受付くん」がまさにそのタイミングでした。
ログイン機能とコア機能のService化も同時に実施
このように、PMFを迎えつつあるタイミングで Monolith > Apps への方針転換を行いましたが、同時に行ってよかったことをご紹介します。
それはログイン機能とコア機能のService化です。
今日のITサービスのほとんどではログイン機能をもっていると思いますが、アプリケーションを分割するにあたってログイン機能のApps化も同時に行いました。このアプリケーションはitandi-accountsと呼ばれており、現在では我々のサービスすべてにログイン機能を提供しています。
もう1つはコア機能、我々でいうと物件データベースのService化です。
SaaSにおいては、どのアプリケーションでも扱うコアデータに当たるものがあるはずです。我々でいうと、それは物件データであり、例えば薬剤師向けのサービスなら薬データになるでしょう。
Apps化に伴い上記の2つだけはService化を行ったことで、その後に増えていったアプリケーションは、そのアプリケーションの責務にフォーカスできるようになりました。
Apps化のメリットと課題
最後に我々が感じているApps化のメリットと課題をまとめます。
メリットは、1つのアプリケーションが小さくなるため影響範囲が分かりやすいことです。
チームを小さく保つことができるため、アプリケーションごとでの意思決定がしやすくなります。これはスピード感をもってプロダクト開発をする必要があるスタートアップ企業等には大きなアドバンテージとなるでしょう。
逆に課題としてまず挙げたいのは、分割の領域設定の難易度が高いことです。
我々はApps化に成功しましたが、間違った単位でアプリケーションを分割してしまうと、「アプリケーションとしては分かれているが実際に相互に密に依存してしまう」という状態になり、スピード感をもった開発を実現するという本来の目的が達せられなくなる可能性があります。
また、アプリケーションが増えるごとにインフラ環境をそれぞれ構築する必要があるため、それらの管理コストが高まることも課題です。
単純にサーバーの費用も嵩みますが、ライブラリやフレームワークを最新に保つ作業もアプリケーションごとに行う必要があり管理が煩雑になってしまいます。
今後の展望
現在イタンジでは、10近いサービスをApps化し運営してます。しかし、この方法がベストだとは思っていません。
前述の管理コストについての課題を改善するため、今後はモジュラーモノリスへの移行も検討したり、アプリケーションが増えるに従い、今までは見えてなかったコア機能が発生し、新たな共通サービスを開発する必要が出てきたりなど探求の未知は続きます。
SaaS企業様がアプリケーション分割について検討される際、当社のケーススタディが1つの参考になれば幸いです。
＜著者プロフィール＞
永嶋章弘
イタンジ株式会社
執行役員筑波大学大学院システム情報工学研究科修了。新卒でニフティに入社、SNSマーケティングツールの開発を担当。その後、創業期のイタンジに入社しさまざまな新規事業を立ち上げる。事業の区切りを迎えメルカリに転職し、アメリカ版アプリのヘルプセンターリニューアル、カスタマーサポートツール開発、メルカリNOW立ち上げなどに従事。2018年、イタンジの執行役員に就任。
- Original:https://techable.jp/archives/198848
- Source:Techable（テッカブル） -海外・国内のネットベンチャー系ニュースサイト
- Author:Techable編集部