モノリシックな大規模アプリを運用する技術-サービスを“分割しない”メリットをSansanの実例に学ぶ

モノリシックにアーキテクチャを構築するメリットとは?近年、マイクロサービスアーキテクチャが注目を集めていますが、Sansanは大規模なアプリケーションに成長したいまも、モノリシックな構造を維持しています。ドメインコンテキストの共有のしやすさ、チームビルドのしやすさなど、モノリシックな構造だからこそ得られるメリットを聞きました。

モノリシックな大規模アプリを運用する技術-サービスを“分割しない”メリットをSansanの実例に学ぶ

近年、複数の小さなサービスをAPIによって連携させるマイクロサービスアーキテクチャが注目を集めています。分割されたシステムを各サービスチームが独立的に開発・デプロイできるこの手法は、組織のスケーラビリティーを高めてくれることに大きな特徴があります。

ですが、あらゆる課題を解決する銀の弾丸のようなアーキテクチャは存在しません。当然ながらマイクロサービスアーキテクチャにも向き・不向きはあり、対比的に語られることの多いモノリシックアーキテクチャは依然として有効な手法であり続けています。

モノリシックな体制の利点を生かして開発が続けられているのが、Sansan株式会社が提供する法人向けクラウド名刺管理サービス「Sansan」です。このアプリケーションはWebアプリケーションやバッチなどのプログラムが、ひとつのリポジトリで管理されています。また開発組織においても、各チーム同士が密に連携を取り合いながらプロジェクトを進行しているのです。

なぜ同社は、モノリシックな体制を貫き続けるのでしょうか。また、大規模な開発組織でプロジェクトを円滑に進めるための工夫とは。同社でアプリケーション基盤の改善に携わる加畑博也さんにお話を伺いました。

1
加畑博也さん(かばた・ひろや)
Sansan株式会社 Sansan事業部 プロダクト開発部。大学院卒業後、大手電機メーカの研究所に新卒入社。電力の使用状況を用いたオフィスワーカの行動予測に関する研究開発に従事。2014年11月、Sansan株式会社に入社。以来、法人向けサービスSansanの開発を担当し、主にアプリケーション基盤の改善に携わる。

モノリシックである利点 - ドメインコンテキストが共有しやすい

──法人向けクラウド名刺管理サービス「Sansan」の開発組織についてご説明ください。

加畑 現在、「Sansan」は社員や業務委託の方々などを含めて130名ほどの組織で開発を進めています(取材を行った2020年6月時点)。開発組織は「Webアプリ」「スマホアプリ」「QA」といった役割ごとにグループが分かれており、各グループはさらに3~6名程度のチームに分割されています。

チームごとに得意とする領域や機能が異なるため、強みを考慮した形でプロジェクトの割り振りがされるケースが多いです。しかし、各チームの役割はガチガチに固定されているわけではなく、比較的フレキシブルな形でプロジェクトがアサインされています。また、後で詳しくお話しますが、各チームが担っている業務内容は開発組織のメンバー全員に共有されており、誰でも開発組織内で進行あるいは計画されているプロジェクトの状況を把握できる状態です。

──「Sansan」はバッチやWebアプリケーションが単一のリポジトリで管理されていると伺いました。組織が一定以上の規模になるとリポジトリ分割やそれに伴う組織体制の変更を行う企業も多いですが、現体制をとる利点とは何だと思われますか?

加畑 いくつかありますが、ひとつはドメインコンテキストに依存しないことです。例えば、マイクロサービスアーキテクチャのようにドメインや機能ごとにチーム・サービスが分割されている体制ですと、市場環境やビジネス要求の変化によって、タスクが特定のチームに集中する、特定のシステムの改修ばかりが多くなるといった事態が発生しえます。または、分割の仕方そのものを後で変えたくなるケースもあるかもしれません。

その場合、チームやシステムの体制変更にかかるコストが非常に大きくなるという欠点があります。つまりマイクロサービス的な体制をとると、特定ドメインのなかではリソースが最適化されるものの、ドメインを跨いだり変更するコストが非常に増大するという側面があります。「Sansan」のようにひとつのコードベースで開発を進めていくことで、開発リソースを企業全体として最適化しやすいという利点があるわけです。

2

加えて、中長期的かつ組織的にサービスをメンテナンスしやすいという利点もあります。「Sansan」はtoBのサービスであるという性質上、特定の機能がユーザー企業のビジネスフローに深く入り込んでいることが多い。そのため、toCのサービスと比べると一度リリースした機能を廃止する判断がしづらく、メンテナンス性に対する要求が相対的に高いです。

もしもドメイン単位でサービスが分割されていれば、チームごとに採用技術が異なるといったケースが発生しうるため、あるチームのメンバーが別のチームの機能をメンテナンスしづらくなってしまうはずです。単一のリポジトリにしておくと採用技術も基本的には統一化されるため、すべての機能をどのチームのメンバーもメンテナンスしやすくなります。

また、マイクロサービス化を推進すると複数サービス間をAPIで連携する形になるため、ネットワーク障害やトランザクション境界に起因するトラブルをどう解決するかを考慮しなければなりません。モノリシックなつくりにしておくと、そうした課題を考慮する必要がほぼなくなります。

──開発・運用上の利点が大きいのですね。

加畑 かつ、当社が扱っている名刺管理という概念そのものが、事業ドメインとして比較的新しい概念だから、という理由もあります。この領域はまだ明確な答えといえるビジネスモデルが存在しておらず、今後も当社の事業内容は変化し続けていくと思います。にも関わらず、ある段階でビジネスコンテキストを切ってサービスを分割してしまうと、コンテキスト自体の変化が起きた場合に、対応コストが非常に大きくなってしまうはずです。

──なるほど。ドメイン分割やそれに伴うマイクロサービス体制は、むしろ「Sansan」というサービスの進展性を阻害してしまうわけですね。

加畑 とはいえ、私たちはけして「モノリスであること」を強く志向しているわけではありません。アプリケーションとしてのデータモデル設計などをふまえて、適切なアーキテクチャを検討した結果、いまの形に落ち着いているというのが正しいです。

例えば、名刺のデータ化や名寄せのロジックはSansanのデータ統括部門(DSOC:Data Strategy & Operation Center)が開発しているのですが、その部門と「Sansan」の開発組織とでは、開発体制もコードベースも完全に別のものになっています。「モノリスかマイクロサービスか」という二者択一ではなく、その組織やアプリケーションにとって最適な設計を常に考えておく姿勢が大切だと思いますね。

──現在の開発体制の利点が生きた事例はありますか?

加畑 私たちは「オンライン名刺交換」機能の提供を2020年6月16日より開始したのですが、この機能開発がスピーディーに行えたのも、現体制だからこそだと考えています。

3

Sansan上で発⾏するデジタルの名刺を保有できる機能。オンラインで⾏なう商談やイベントなどでの名刺交換が可能になる。

「オンライン名刺交換」のプロジェクトは新型コロナウイルスに起因する自粛要請の影響を受けて立ち上がったのですが、もともとは他のプロジェクトと同じような開発フローで進めていく想定でした。ですが、オンライン上で商談や会議を行うニーズが急激に高まったため、機能の優先度が非常に高くなったのです。

そこで、特例的なプロジェクトとして複数のチームからメンバーを招集し、「オンライン名刺交換」専門チームを立ち上げてプロジェクトを推進しました。ドメインコンテキストを横断するコストがないからこそ、この体制を実現できたと考えています。

結果的に、当初の予定よりも1か月ほど前倒しで機能をリリースできました。もし、マイクロサービス的な体制をとっていれば、メンバーのオンボーディングやドキュメントの解読といった作業に大きな学習コストがかかっていたはずです。そのコストがほぼ生じなかったため、スムーズに開発が進行しました。

Backlogを一本化し、モノリシックなシステムを運用しやすく

──各メンバーは、他のチームの開発の動きをどのように把握しているのでしょうか?

加畑 私たちは「Sansan」の開発組織全体で、一本化したBacklogを用いてプロジェクトを管理しています。もともと「Sansan」の開発組織では、チームごとにプロジェクトの優先順位を判断・管理する体制をとっていました。今よりも人数が少なかった時代にはその体制で問題がなかったのですが、人数が増えてくると徐々に課題が見えてきました。

例えば、各チームが別々のBacklogでプロジェクトを管理しているため、あるチームは優先度の高い業務ばかりをやっているのに別のチームは優先度の低い業務ばかりをやっている。つまり開発リソースを最適化できていない状況が生まれていました。また、別のチームが取り組んでいる改修の内容がわからないため、ソースコード修正やプロジェクトのコンフリクトが頻発していましたね。

──その状況を改善するために、Backlogの一本化が行われたわけですね。

加畑 もちろんBacklog運用のスイッチングコストは大きかったですが、取り組むだけの価値があったと思います。一元管理されているBacklogをベースに仕事が割り振られるため、全チームが優先度の高いプロジェクトから順に取り組めるようになりました。また、各チームが担うプロジェクトが可視化されるため、作業のコンフリクトが起きにくくなっています。

──チケットの起票からプロジェクトのアサインまで、どのような流れで行われるのでしょうか?

加畑 まず、ビジネス的な要求やチームメンバーの意見などから、機能の新規追加や変更のアイデアが生まれます。その内容をベースに、プロダクトマネージャーがBacklogへのチケット起票を行った後、複数のプロダクトマネージャーやステークホルダーとの会議を設けて優先順位づけを行います。

議論の結果によってはチケットがボツになるケースもありますが、それは残念なことではなくむしろ良いことです。取り組むべきではないプロジェクトが、適切にふるい落とされたということですから。優先順位がつけられた後、各プロダクトマネージャーは該当する機能の開発が得意なチームと相談し合って、プロジェクトを進めていきます。

──開発体制という意味ではGitのブランチ戦略も重要ですが、どのような形式をとられていますか?

加畑 masterブランチをベースに、チーム単位のdevelopブランチを切る運用をしています。各チームは各々のdevelopブランチからfeatureブランチを作成し、機能を開発してPull Requestを発行し、承認されたらチームのdevelopブランチにマージします。

リリースする際には、masterブランチから切り出したreleaseブランチに、チームdevelopブランチの資材をマージします。リリースが正常に終了すれば、releaseブランチの資材をmasterにマージした後、各チームが変更を取り込む流れになっています。

──いわば、チーム単位で「git-flow」のワークフローをとっているわけですね。それ以外にも、採用技術などで大規模開発における品質向上やメンテナンス性の向上に寄与しているものはあるでしょうか?

加畑 当社では歴史的経緯から「Sansan」のサーバーサイドの言語としてC#を採用しているのですが、その特徴が品質向上に寄与していると思います。静的型付けの言語ですからコンパイルの段階で記述の誤りを検出できますし、(C#がマイクロソフト開発の言語であるため)マイクロソフト製のIDEであるVisual Studioの恩恵を受けやすい。大規模開発において適切にプログラミング言語を選択することは、開発効率や品質を向上させるうえで重要だと感じます。

また、システムの改修をなるべく容易にするため、.NETのNuGetというパッケージマネージャを用いて社内でサーバーを構築し、セキュリティやメッセージングの基盤といった一部のコア機能をパッケージとして提供・利用しています。リポジトリは同一であるものの、設計上の依存関係は比較的疎な状態を保っています。少しずつ機能を切り出しながら、パッケージ化を進めている段階です。

4

技術的負債の解消 ~事業フェーズに適した技術を選定する~

エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く