MGReのシステム構成を公開 SaaS開発で大切な設計思想とは

ランチェスターが2020年6月にローンチした、アプリマーケティングプラットフォームの『MGRe(Make Good Relationship:メグリ)』。
アプリを通じたマーケティングを支援するMGReは、これまで提供していた『EAP』を大幅にアップデートする形で誕生しました。このアップデートに込めた思いと、技術面でのこだわりを、開発チームの5名が語ります。

「完全コンテナ化」が最大のポイントに

─ EAPからMGReに進化する上で、一番のポイントは何でしたか?

大久保 アーキテクチャをマルチテナント方式にしたのが最大の変更点です。

田代 EAPの時はシングルテナント方式で、クライアントのご要望に応じてカスタマイズを加えることで、拡張性を担保していました。

大久保 一方、MGReはコアな部分を共通化することで、モバイルアプリの開発〜運用に多くの人員を割けないクライアントでも、気軽に導入していただけるようになりました。例えば、スマートフォンOSのバージョンアップに合わせてアプリの状態も最適のものにアップデートできたり、MGRe側で追加・改善した機能もすぐにご利用いただけたりします。

田代 簡単に言えば、SaaSとしてよりモダンなアーキテクチャに刷新したということです。

─ 具体的なシステム構成を教えてください。

大久保 MGReのアーキテクチャは、この図のようになっています。

MGReのサーバサイド構成

大久保 まず、サーバサイドの構成をコンテナ系のものに全部差し替えて、サービス運用の柔軟性と拡張性を高めました。

山口 MGReへの移行で一番のポイントはここです。

大久保 具体的には、EAPではAWS Elastic Beanstalkを使っていたのを、MGReへの移行時に新しいマネージドコンテナサービスのAWS Fargateにしました。データベースにもAurora Serverlessを導入することで、テナントごとにスケールアップしやすいインフラに刷新しています。もう一つのポイントは、コアとなる機能とテナントごとにシステムが分かれていることです。

─ MGReには、【エントリー】【スタンダード】【エンタープライズ】と3つの料金プランがありますね。

大久保 その中で最も安価なエントリープランではコアとなる共通機能を提供する一方、スタンダードとエンタープライズプランでは個社別のご要望に応じた機能を拡張できるようにしています。こうすることで、APIを通じてクライアント企業のシステムと柔軟に連携しつつ、MGReそのもののアップデートも素早く進められるようになりました。

刷新を支えた「理想」

─ 稼働中のEAPをアップデートし、さらにアーキテクチャを変えるとなると、ゼロから新サービスを立ち上げるよりも大変な面が多かったのではないですか?

大久保 もちろん、細かな部分ではすごく苦労しました。でも、そこまで無謀な挑戦とも思っていなかったというか。

田代 サービスの設計思想としては、EAPを運用していた時から今のような形を理想像にしていたからだと思います。

大久保 それが大きいですね。

田代 SaaSとしての理想と言うか、1つのプラットフォーム上で異なるクライアントニーズに応えつつ、進化していきたいという思想が前からありました。

大久保 私はEAPの立ち上げ時から外部顧問として参画していたのですが、当時からSaaSとしてのベストプラクティスを模索する雰囲気があったように思います。

田代 加えて、EAPを運営する中で、各社共通のニーズと、個別に求められる拡張性の部分を各論で分けて考えられるようになったことも、MGReへの進化に役立ったと思っています。

─ SaaSとしてのベストプラクティスを模索する雰囲気とは、例えばどんなものですか?

田代 アプリサイドの開発が、参考になるかもしれません。iOS、Androidで別々のアーキテクチャを採用しつつ、EAPの時代からマルチテナント化を意識して進めていました。

二木 そうですね。特にiOSは、EAPの開発当初から内部的にソースコードを機能単位でモジュール分けする設計思想だったので、MGReのアーキテクチャに移行する時も、コア機能として定期的にアップデートしていく部分と、カスタマイズできる部分とを容易に分けることができたんです。そういったこともあり、あまり苦労しませんでした。

田代 Androidのほうは、MGReの開発にあたってどの辺を気をつけたの?

二木 EAPの開発をしていた時はエンジニア不足で、Androidではプロダクトをうまく育てられなかったという反省があったんですね。そこで、MGReではさらにKotlin化を進めたことに加えて、クラス単位でのリファクタリングも進め、可読性と安定性を向上させることに注力しました。こうした準備を進めたこともあって、将来的なエンハンスにも耐えられるように進化しています。ちなみに今ではソースコードの93%がKotlinになっています。

─ EAPの頃は、シングルテナント方式だったため、個社別にカスタマイズ開発が求められるケースが多かったわけですよね?

田代 そうです。

─ その状況下で、SaaSとしてコアな部分を共通化していく作業を進めるには、ある意味で相反する抽象化思考が求められます。これを両立するのは、非常に大変だったのではないですか?

大久保 そう思います。でも、もとから理想像を描いて開発していたことが、MGReへの進化を支えたのは間違いありません。

山口 サーバサイドのアーキテクチャ変更でも、処理の内容自体はEAPからMGReへの移行で特に大きな変更はなかったんですね。ただ、今回のアップデートでマルチテナント化するにあたって、できる限りサーバの運用負荷を減らしたい、人的な運用負荷を減らしたいというのがあって。EAPの頃もそれなりのことはやっていましたが、今回はもっと抜本的に進めていこうということで、全てのプログラムをコンテナ化しました。 MGReへの移行プロジェクトを始めた頃、コンテナに対する知識がほとんどなかったので、ローカルで動いていたプログラムをFargateに乗せてみたら動かなくなるというケースも多々ありました。

─ 理論上はうまくいくはずでも、実際はAWS側でブラックボックスになっている部分が多かったということでしょうか。

山口 そうですね。Fargateを使って立ち上がったコンテナの中には入れないので、動かない原因を一つ見つけては問題を解消し、また一つ見つけたら解消する……という泥臭い作業を半年以上繰り返しました。

大久保 途中、何度か諦めかけましたよね(笑)。

山口 本当に数え切れないくらいでした(笑)。でも、動き始めてしまえば、後は何とかなるだろうと。EAPの頃から、クライアントはノーコード・ローコードの世界感で画面をポチポチやれば、必要なサービスが使えるようになるのが理想でした。なので、ここでサーバサイドをコンテナ化できれば、一歩、理想に近づくことができます。それに、コンテナ化には、新しいエンジニアがチームに加わった時も、開発環境をすぐローカルに構築できるというメリットもあります。だから、大変でもやる意義があると考えていました。

大久保 コンテナ化を完遂できれば、デプロイなどの自動化も進めやすくなります。「これでサービスが進化していくスピードが確実に上がるはず」と話しながら、苦しい作業をやり切ってもらいました。

GCPの採用に見る、自由な開発文化

─ お話を伺っていると、EAPからMGReへの移行は、開発チームのレベルアップにもつながっていると感じます。

大久保 当社の開発チームは、技術的に新しいチャレンジを嫌がらないというか、むしろ率先して提案してくれるメンバーが多いんです。これが、プロダクト開発にとても良い影響を与えていると思います。
先ほど話題に上がったコンテナ化の話以外にも、MGReの特徴の一つであるデータ分析機能の開発プロジェクトでは、担当している山口さんから、それまで使っていなかったGCP(Google Cloud Platform)を検討してみたらと提案されたんですね。ビッグデータの解析サービスとして、Google BigQueryが使いやすいということで。それによって、今後、Go言語に詳しいエンジニアも採用できればと考えています。

AWSからGCPへのデータロードシステム

 

猿渡 今作っているのは、「ランキングボード」と呼ばれる機能で、クライアントのアプリ内でどの画面、どのコンテンツがたくさん見られたかを可視化するものです。以前なら、これらのデータはGoogle アナリティクスを使えば無料で分析できましたが、有料版の登場でサービスの内容が変わってしまったので、MGRe上で分析できるようにしてしまおうと。それ以外にも、今後、分析機能を拡張していく上で、ボリュームのあるデータ分析では現状BigQueryが使いやすいということで、MGReが使っているAWSと共存する形でシステムを作りました。

大久保 当社はサーバサイドをRubyで動かしているので、Goを使うのはチャレンジングな面もあります。でも、猿渡さんが今回の検討をしてくれた時、Slackで「言語はどうします?」聞いたら「Goを使ってみたい」とのメンバーの声があり、では試してみましょうと即決しました。

猿渡 私自身は、Goに強いこだわりがあるわけではないんです。でも、当社は技術的なしがらみが少ないというか、「まず使ってみよう」というノリがあるので、試してみようと思ったんですね。

─ そういう新たなチャレンジができる開発環境は、とても素敵ですね。

猿渡 はい。

大久保 こういう多様性も、チームとして進化していく上で大切だと思うんですね。

「プロダクト志向」のチームが生まれた理由

─ 最後に、EAPからMGReへの移行で、開発チームをどう進化させていきたいのか、今後の展望があれば教えてください。

大久保 その前に現状を話すと、今回のMGReへのアップデートに合わせて、物理的にチーム編成を変えたんですね。以前はクライアントの状況に合わせて適宜、必要なエンジニアがサポートする案件別のチーム編成でしたが、2020年6月から全員がMGReというプロダクトに紐づく編成に移行しつつあります。現時点では、外部のパートナーさんを含めるとサーバサイドで約5名、アプリサイドも約5名で10人程度の規模になっています。

─ なぜプロダクトチームに移行しようと?

大久保 EAPからMGReへのアップデートプロジェクトが始まった頃に、エンジニアだけでミーティングを重ねて、どういった組織だとMGReがよくなるかを話し合ったんです。その結果、案件別ではなく、「全員がプロダクトエンジニア」という形に変えてみようとなりました。

山口 EAPで様々なクライアントとお付き合いをしていた頃から、個々の開発メンバーがPMF(プロダクトマーケットフィット)の観点で「もっとこうしたほうがいい」と感じていたことがたくさんありました。

大久保 そういった点を持ち寄って、ワンチームとしてMGReの開発を進めたほうが、よりモダンなシステムができるんじゃないかと考えました。以降は、コードへのアクセス権なども含めて、全員が情報を共有しながらボトムアップでチーム改革を進めています。

─ チーム編成を変えた結果、具体的に何が変わりましたか?

大久保 本格的に今のチーム編成になってから、まだ3カ月ぐらいなので、ちゃんとした振り返りはできていません。今はまだ移行期という感じです。でも、徐々にチームとしての相乗効果が生まれているとは感じています。

山口 私は、以前に比べてそこまで大きく変わったという印象がないんですね。これは悪い意味ではなく、EAPの時代から、サービス全体の発展を見据えて開発に取り組んでいたエンジニアが多かったということだと思っています。

─ もともと「プロダクト志向」の人が多かったと?

山口 はい。例えば、平日のオンタイムはクライアント対応をしていても、空き時間ができたらEAPのソースコードを自主的に綺麗にするような人もいましたし。

田代 二木さんがやっていたコードのモジュール化も、これに近い作業だよね。

二木 そうですね。「将来こうなってほしい」という理想みたいなものに向かって思考を巡らせて、設計・開発してきたという点は、ずっと変わらないです。

田代 目の前の業務だけに終始しないというのは、前からある開発文化かもしれません。どうせやるなら、時間を割いてちゃんとしたサービスを作ろうというエンジニアが多いと思います。

大久保 でも、今のチーム編成にしてから、GitHub上のプルリクエスト数は増えているんですね。これは、以前から皆が持っていた考えが、チーム全体として表れ出したという風にも言えると思います。

─ そのような開発文化が根付いている理由は、どこにあると思いますか?

田代 僕ががもともとエンジニアだったというのが、背景にあるのかもしれません。起業した理由が、「エンジニアにとって働きやすい会社を作る」というのと、「自分たちのサービスを持ちたかった」の2つだったので。
EAPの時代は、クライアントのご要望に応じてカスタマイズをしていった結果、サービス本体とかけ離れたコードが生まれてしまうというケースも確かにありました。自分たちのサービスを立ち上げて、収益を得るという面では正しいやり方だったと思っていますが、「エンジニアにとって働きやすい会社」という面では必ずしもベストなアプローチではなかったと思っています。その教訓を生かして、MGReではエンジニアが思う「プロダクトとしてこうあるべき」という理想を元に、サービスを進化させていきたいと思っています。

─ その思いが、開発チームの進化につながると?

田代 はい、その結果、MGReをご利用いただくクライアントのためにもなると信じています。例えばデータ分析系のサービスを進化させるには、機械学習に詳しいエンジニアがMGReのコンセプトに共感してジョインしてくれたらと思いますし、Appleが注力すると言われるAR機能を使った次世代サービスを産み出すのも、おそらく専門分野に長けたエンジニアです。技術を使ってクライアントに新しい価値観を提供していくために、お互いの強みを生かしながら成長していく開発チームを作っていけたらと思っています。

アプリ開発について相談してみる