成長途中のサービスでモジュラモノリスを選択した2つの理由　人が増えてチームが分断されても生産性を維持するために

志賀氏の自己紹介

志賀誠氏（以下、志賀）：みなさん、こんにちは。

会場：こんにちは。

志賀：うれしい、返事がきた（笑）。オフラインで話すのが久々すぎて声が出るかちょっと心配だったんですが、なんとかなりそうなのでやっていきたいと思います。

今日お話しする内容ですが、「hacomono TECH BLOG」で事前に書いた内容と若干かぶるところがあるので、もし読んだ方がいたら、おさらい程度だと思って目をとおしてもらえると幸いです。

では、株式会社hacomonoから「Rails x モジュラモノリス」というテーマで発表します。最初に私の自己紹介を簡単にします。私は志賀といいます。インターネットでは“まこたす”という名前で活動しています。Twitter（現X）も@maco_tasuでやっています。

弊社では、今プラットフォーム部にエンジニアとして所属しています。昔から古くから動いているシステムのリプレイスに関わることが多くて、今もそういった仕事をしています。

プライベートはゲームが好きで、FPSをやったりバイクに乗ったり。あと犬が好きなので、犬とずっと遊んでいたりします。

私の経歴です。最初はソーシャルゲームの会社から始まり、ずっとバックエンドエンジニアとして活動していました。前職からSaaSビジネスに関わっていて、基盤チームで主に認証認可のリプレイスをやったりして、現職もSaaSの会社にいる感じです。今もプラットフォームチームに所属していて、最近はずっと基盤周りをやっています。

「hacomono」について

志賀：「hacomono」というサービスの認知度があまりないかもしれないので、本題に入る前に会社について簡単に説明させてください。

会員管理・予約・決済をすべてオンラインで実現できる、ウェルネス産業向けのオールインワンシステムを、「hacomono」という1つのサービスで提供しています。

いろいろな業態で使われていて、主にシミュレーションゴルフだったり24時間ジムだったり、パーソナルジムだったり。ああいうところに予約とジムの入退館とかあるんですが、あのサービスの裏側と、入退館のデバイスと言えばいいんですかね。QRをかざして入るような。ああいったデバイスも作ったりするようなかたちで、店舗DXをまるっとサポートするようなサービスを今運用しています。

今後ですが、「Whole Product戦略」というものを掲げていて、「hacomono」を使えば店舗DXがひととおり実現できるようなプロダクトを目指しています。まだぜんぜん足りないところもあるんですが、今、絶賛機能開発を進めているような段階です。

（スライドを示して）資料がちょっと古いんですが、多くの店舗に使ってもらっていて、今はだいたい4,100店舗に導入してもらっています。大きいところだと「chocoZAP」さんのバックエンド側の顧客管理・予約・決済基盤として使われていたりします。

ちょうど2023年4月に資金調達があったんですが、今のサービスの質を上げるところに絶賛投資をしているような段階で、今は安定稼働に注力して予算を使っています。今後も、新しい分野の投資を引き続きやっていくフェーズになっています。

hacomonoのフェーズは大きく5つあります。今はPhase 1の店舗DXを実現するために「hacomono」というサービスを運用しているんですが、Phase 5では社会のウェルネス産業のインフラを支える基盤として「hacomono」が要るような世界を叶えたいと思っていて、今はPhase 2に向けて開発を進めているような段階です。

直近、そのPhase 2のペイメント領域ですね。やはりジムの運営は、給料の支払いだったり店舗の運営で、なにかしらお金がかかると思います。そういったところのペイメント領域でなにかできることがないかということで、どんなものを作るかという検討と開発を進めようとしている段階です。

ちょっと長くなってしまいましたが、そんな感じでスマートウェルネス関係のSaaSを実現するために、hacomonoという企業で今がんばっているような感じです。次から本題に入ります。

プラットフォームチームについて

志賀：嘘でした。まだ僕のチームの紹介がありました（笑）。プラットフォームチームの紹介もします。

（スライドを示して）弊社の開発組織は、ざっくり上が機能開発をするようなチームで、下の点線で囲まれているところが基盤チームで、私はその中のプラットフォームチームに所属しています。

ざっくりなんですが、上のプロダクト開発以外のほとんどの開発をやるようなチームになっていて、その流れの一環で開発者の生産性を上げたい、維持したいというところで、今回モジュラモノリスの着手を進めていた背景があります。

本セッションで話すこと

志賀：今度こそ本題です。今日お話しする内容です。まず1個目が、弊社がモジュラモノリス導入に至った背景を説明したいと思います。あとはTECH BLOGの内容とだいぶかぶるんですが、導入に向けてどんな技術を使っているかを紹介します。

逆に今の導入の現状だったり、先ほどタイミー社さんからの話であったように、パッケージをどんな戦略で分けているとかのような、そんな深い話はできないので、そのあたりはもし時間があったら懇親会で聞いてもらえると助かります。

モジュラモノリス導入前はモノリスなアプリケーションで動いていた

志賀：それではモジュラモノリス導入に至るまでの背景について説明します。導入前の「hacomono」のサービスがどんなものだったかの説明からします。「hacomono」というサービスは、Rails、モノリスなアプリケーションで動いていました。

ただ、いわゆるよくあるRailsのMVCという感じじゃなくて、内部的にはクリーンアーキテクチャで、ある程度一定にルール化されていて、入社した当時は「きれいなサービスだな」と思ったのが印象的で、よく覚えています。

ただ、レイヤー同士はわりと横で好きに呼べるような状態で、「人が増えてきた段階で結合度が徐々に高くなっているような状態にあるのかな」と入社当時に思っていました。この「hacomono app」という1つのRailsサービスを、エンジニア組織全体でワンチームで見ていたのが今までの現状でした。

開発組織が大きくなり、チーム間のコンフリクトが発生しそうに

志賀：その状況が2022年4月からちょっと変わりました。「負うべき開発ごとにチームをもっと分けましょう」みたいなイベントがありました。ざっくり3チームと書いているんですが、機能ごとに負うチームが分かれて、そのチーム全体で、同じく1つのコードベースのRailsアプリケーションを見るような変遷がありました。

チームが分かれて以降、開発組織もだいぶ大きくなってきて、2倍ぐらいに増員しました。それに伴って追加される機能も「あっ、こんな機能がリリースされたの？」みたいなことがやはり起こるようになってきて、自分の知らないコードが徐々に増えてきたなと思っています。

そうした場合に、よくある話かもしれないんですが、やはりチーム間のコンフリクトというのが起こってくるなというのがあります。てすごく困っていたという状況ではありませんが、「起こり始めそうだな」みたいな予兆を感じていました。

例えば「今からいじろうとしているコードって、触っていいんだっけ？」「触った場合、どういう仕様が正しいんだっけ？」みたいなものを正確に把握できる人がいなくなったりとか、「自分のチームの領域だけど、もしかしたらほかのチームが手を入れてしまう」みたいな。そういった、同じコードベースを触っているがゆえに起こり得る問題もあるだろうなと思っています。

あとはドメインの成長というところで、「hacomono」は2019年にリリースしたばかりで、どういうサービスのかたちで提供していくかを探り探りやっているところがあります。今後、「ドメインが実際に成長して、1つのチームを持ったほうがいいよね」みたいなことも起こり得るだろうと考えていました。

あと、ほかに起こることとしては、新サービスの誕生とかですかね。「hacomono」で使っている共通の、サービスに依存しない機能というか、メール配信だったり課金だったりを使いたいとか。

あとは、実は「hacomono」のサービスを外から使ってみたいとか。そういった別のサービスからの利用みたいなものも今後起こり得るだろうなというのが、この時に考えていた問題です。

ということがあって、人が増えてわりとコードが自分で把握できなくなってくるという問題が、やはり生産性が下がる1つの要因だと思うので、「極端な話、人が増えても今までのモノリス同様の生産性を維持したいですね」というのが今回やりたかったことになります。

それを実現するためには、それぞれの領域で、知識と実装面で分離できる仕組みを作っていかなきゃなと思ったのが背景としてあります。

（スライドを示して）図にするとこんな感じですね。チームごとに担当する機能が分かれていて、機能間の呼び出しはAPIを通してやるみたいな。自分の領域は安心して触れる状態にしたかったというのが背景にありました。

モジュラモノリスを選択した2つの理由

志賀：そこで採ろうと思った戦略で、いきなりちょっと極端ですが。「モジュラモノリスとマイクロサービス、どちらがいいかな？」みたいな検討がありました。すごくざっくり話すと、左がモジュラモノリスで、1つのRailsとアプリケーションで中身が分割されているみたいなイメージですね。右側がマイクロサービスの一例ですね。物理的に分離されているよと言いたかった感じです。言語ベースが変わっていることもあります。

結果的にここに登壇しているので、もう答えになってしまっているんですが、モジュラモノリスを選択しています。TECH BLOGで僕は、いろいろな軸みたいなものを書いて○×みたいなかたちで評価していたんですが、ちょっと難しく考えすぎたなと思っていて。結局会社の状況に合わせてその時に何を優先するかで、どちらのアーキテクチャを採るかは変わるんじゃないかなと思っています。

hacomonoとしては、大きくこの2つのポイントを重視してモジュラモノリスを選択しています。1個目は「成長に合わせてモジュールとモデルの見直しが発生しそう」ということが懸念としてありました。

先ほどタイミー社さんからも「モジュールの分割の方法とか正しい指針って、なかなか決めるのが難しいよね」というお話があったと思うんですが、僕もまったくそのとおりだと思っています。

モジュールとモデルのかたちって、成長途中の段階のサービスで完璧に決められる人はいないと思うんですね。なので、後々そこの見直しが発生した時に、比較的簡単にモデルとモジュールを作り直したいというのがありました。そうした場合に、マイクロサービスだと物理的に切り出したらなかなか難しいから、モジュラモノリスにしたいなと思ったのがあります。

あとはもう会社の状況にもよると思いますが、hacomonoは今成長段階なので、なるべく早く顧客に価値を届けたいというのが背景としてありました。

もうちょっと具体的に言うと、やはり物理的にサービスを分けちゃうとCI/CDをイチから作らないといけなくて。hacomonoではマイクロサービスの運用実績がないんですね。なので、「そこにリソースを割いてマイクロサービスを運用して、そこのコストをずっと払い続けるのはあまり現実的じゃないよね」という話がありました。1つのコードベースで動くならそれに越したことはないというのがあり、モジュラモノリスを選択したという背景があります。

（次回に続く）