初めまして、株式会社スマートラウンドCTOの小山（@doyaaaaaken）です。
昨年末Startup CTO of the year 2022というイベントに出場して優勝し、その際のピッチ内容について解説する連続記事をこれまで書いてきました。
今回の記事はその4本目の記事となります。
もうじき今年のStartup CTO of the yearが開催されようとしている中、このシリーズが3本で止まっていた事実を思い出し、 「今年中にしか出せないネタなので書かねば！」 という気持ちになり急遽駆け込みで書きました。
拙い部分があればご容赦ください。
なお優勝ピッチ解説シリーズの他の記事は以下リンク先で公開しています。👇
- 🔗【優勝ピッチ解説(1)】スマートラウンドの開発体制ではスクラムをどう改変したか？
- 🔗【優勝ピッチ解説(2)】スマートラウンドでISMS認証を取得した背景および得た知見
- 🔗【優勝ピッチ解説(3)】Server-Side Kotlin Meetupが日本最大のサーバサイドKotlin勉強会になるまで
また🔗ピッチ資料はこちらで公開しているので、そちらもよければ併せてご覧ください！
（ピッチで実際に話した内容の全文はログミーさんが書き起こし記事にしてくださっていますので、お時間ある方はぜひそちらもご覧ください！）
スマートラウンドとは
スマートラウンドは スタートアップと投資家の日々の実務を効率化するコミュニケーションプラットフォーム『smartround』 を開発・運営しているスタートアップです。
現在（2023年10月）時点で、4,500社ものスタートアップからご利用いただいております。
「スタートアップ・投資家の多対多の関係で生じる大きな非効率」を解消し、スタートアップ業界全体の生産性の底上げに貢献しようとしています！
コーポレート・セクレタリー と呼ばれる、株主総会運営、株主・取締役の変更手続き、株式管理、ストックオプション管理、IRなどコーポレートガバナンス全般に関わる業務領域を中心に、スタートアップを支援するサービス群をプラットフォーム上で提供しています。
ピッチ内でもこのスライドで、スマートラウンドが様々な業務効率化アプリケーションを包含したプラットフォームであることについて紹介しました
去年シリーズA資金調達を行い、現在絶賛組織も事業も拡大中のスタートアップです。
今回のテーマ：モジュラモノリス
それではここから本題です！
今回の記事のテーマは 「smartroundのシステムをモジュラモノリスにした背景・詳細内容」 についてです。
ピッチでは以下のスライドで紹介しました。
モジュラモノリスについては、その後もよく採用面談やイベントなどにおいて聞かれる機会が多かったので、イチ事例として参考になればと思い記事にしてみました。
モジュラモノリスにした背景
前述の通り、smartroundはスタートアップの資金調達・機関決定・株主管理などに関わる実務をサポートする多数のサービス群を1つのプラットフォーム上でまとめて提供しています。
そのため システム全体の規模は大きく、また新サービスをどんどんリリースしているため規模はどんどん大きくなります。
サービスページでは『創業からエグジットまで急成長を支える』と銘打ち、様々なサービスが利用できることを紹介しています（今後さらに増えていく予定）
リファクタリングを強く推奨する文化でありまた少数精鋭で開発していたこともあり、モノリスのままでも特に具体的なトラブルは起きていなかったのですが、4年近くもサービス運営していると以下のような課題意識が大きくなり始めました。
- 新メンバーのキャッチアップコストが高くなっている。そしてキャッチアップするまでのしばらくの期間は修正を安全に行えるか心配。
- 既存メンバーにとってシステム全体の仕様や実装の詳細をキャッチアップし続ける負荷が高まっている
そういったこともあり 『新規メンバーの学習コストを下げ、既存メンバーの認知コストを下げる』 という標語を立て、それを目標にモジュラモノリス化のプロジェクトを開始しました。
・聞かれそうな質問①：マイクロサービスになぜしなかったか？
1つ目の理由は マイクロサービスを綺麗に切り出すためのコンテキストの境界面がなかったから です。
「マイクロサービス化したけど、他サービスのデータが結局必要になり、サービス間で通信が数多く発生している（しかも相互参照で！）」といった他社のトラブルを、当時数多く聞いていました。
また私自身が過去に関わったプロダクトでもマイクロサービスを採用し、その結果としてマイクロサービスの難しさを体感したこともありました。
なお2020年にはオライリーから日本語版の「モノリスからマイクロサービスへ」という書籍が発売され、その中でも一足飛びにマイクロサービスを採用するのではなくモジュラモノリスを経由することを推奨されています。
2つ目の理由は マイクロサービス化によるオーバーヘッドに見合うメリットがなかったから です。
マイクロサービス化することにより当然別種の複雑さや管理の難しさが生まれます。
smartroundはスタートアップということもあり、当時少数精鋭のエンジニアで広範囲をカバーしており、それによりスピード間を持って開発していました。
マイクロサービス化はそのスピード感を損なうものであり、またそれに見合うメリットがないと判断したため、マイクロサービス化は行いませんでした。
・聞かれそうな質問②：いくつかの独立したアプリケーションに分割しなかったのはなぜ？
その案については実はかなり検討していましたが、やはり綺麗に切り出すためのコンテキストの境界面がなかったため見送りました。
どういう単位で分割したとしてもなんだかんだで共通機能は存在するということ、また サービスの仕様もまだまだドラスティックに変わりうるフェーズだったので変化に強いアーキテクチャにしたいこと からモジュラモノリスにしました。
モジュラモノリス構成の詳細
下図のようなバックエンドアーキテクチャを2023/10現在では採用しています。
図にない説明もいくつか補足しますと、
- システム全体にはサーバサイドKotlinを利用しており、Gradleのマルチプロジェクトという仕組みを利用し、複数モジュールに分割・管理している。
- Kotlinではclassやmethodに
internal句をつけると、モジュール外に非公開になる - それを利用し、Feature Module内の多くのclassにinternal句をつけ、フィーチャーモジュールとして公開したい機能のみをモジュール外に公開するようにしている
- Kotlinではclassやmethodに
- 各Feature Moduleはなるべく独立しており、もし将来単独のアプリケーションとして分割したくなった場合にできるぐらいの独立性を持つ
- Feature Module同士が連携するときはBypassと呼ばれるクラス（図にはないです）経由で連携する。それ以外の手段では連携しない（それによりモジュール間の依存がわかりやすくなる）。
- Bypassの呼び出しは、独立したサービスを呼び出すときのようなイメージ（外界に近い層で呼び出す）。
- チーム構成はきっぱりとモジュールごとにわかれているわけではないが、ある程度は担当する領域が各チーム決まっている
- 詳細は別イベントで語っているので以下のスライド参照
- 🔗『コンパウンドスタートアップの“疎結合すぎない”チーム設計』
なお、まるで自分が全て考えたかのように書いていますが、私が考案したわけではなくテックリードが考え、泥臭く手を動かし続けて今のアーキテクチャに変えてくれました（アーキテクチャ変更には結構時間がかかりました）。
おわりに
いかがだったでしょうか。面白く読んでいただけてれば幸いです！
最後に宣伝としてスマートラウンドの採用情報を貼っておきます。
昨年9月にシリーズA資金調達を行い、エンジニアもデザイナーもその他職種も、全ポジション積極採用中です！
「今は転職する気はないけど、ちょっと興味を持ったので話を聞いてみたい」という方も歓迎ですので、ご興味ある方お待ちしてます！
⏩ 採用ページ
⏩ カジュアル面談応募フォーム
⏩ 会社紹介スライド（※時間がない人向け）
⏩ エンジニア組織紹介スライド（※時間がない人向け）
Discussion