”便利でいいもの”を作り続けたい

MGRe（メグリ）は、アプリ開発とアプリマーケティングを同時に行うことができるBtoBtoCのSaaSプラットフォームだ。導入企業は安定性の高いモバイルアプリを簡単に始めることができる。洗練されたデザインのため、エンドユーザーは迷うことなくアプリを使うことができる。EAP（MGReの前身となった事業）をSaaS化し、2020年6月にMGReがリリースされた。
「便利でいいものを作りたい」と語るエンジニアチームのリーダーたちに、SaaS化プロジェクトと設計のポイントを聞いた。

左から、田邊（Androidリーダー）、二木（VPoE兼iOSリーダー）、篠田（プランナー）、蔵下（サーバーサイドリーダー）

※本記事は2023年12月にnoteで公開された記事の転載です。

01. 役割をコアとテナントに整理した設計

MGReの柔軟性を語る上で欠かせないのが、EAP→MGReに移行する当初からの設計方針だ。EAPではクライアント毎にフルスクラッチに近い形でカスタマイズ開発を行っていたが、SaaS化するにあたり、共通機能のコア部分と柔軟性のあるテナント領域に分けた。これがMGRe最大の特長だ。

サービスとして生き残っていくためには、複雑化していくニーズにすぐに応えられる即応性だけでなく、導入企業が保有している蓄積されたデータとMGReを繋ぐことのできる柔軟性の双方が必要不可欠だった。

［コアとテナントに分けたことによるメリット（一例）］
・定期的なアップデートがしやすい（コア）
・品質管理がしやすくなったため、アプリの安定性が上がった（コア）
・柔軟性が高く、個社ごとのニーズに応えることができる（テナント領域）
・基盤が整理されているため、予測が立てやすい
・大規模アップデート時の耐久性

次にアプリ（Android）とサーバサイドの設計を紹介する。この整理を行ったことが拡張性と柔軟性のポイントとなっている。

02. 簡易図解

【Android】

［課題と目的］
EAP時代のAndroidは全体として一つのモジュールで構成され、どのモジュールからも相互に参照することができた。SaaS化にあたり、コアとテナントに分離させるために機能ごとの依存を明らかにして、参照関係を整理する必要があった。

［実施したこと］
影響しあっている箇所を見極めて、ひとつひとつ解きほぐしていく作業を各機能ごとに行った。

［設計のポイント］
・各機能を、コアとテナントに分離
・インターフェースを定義し、必要に応じてテナント→コアを参照できるようにした

# コメント
メグリの仕事では、抽象化して取捨選択していくスキルが求められます。もちろん難しさはありますが、やりがいがありますし、エンジニアとして腕の見せ所だと思って取り組んでいます（Androidエンジニアリーダー田邊）

【サーバサイド】

［MGRe Auth：テナント側で、コアのような役割を担うライブラリ］
MGReと外部システムを繋ぐのがサーバサイドの主な役割だ。設計としては、一部のスタンダードな機能のみコアに。カスタマイズしたいところは抜き出して、テナントに整理した。テナント領域の中には、パターン化できる共通のプログラムを動かすことができるライブラリを作ることにした。これがテナント側にありながらもコアのような役割で動いてくれているMGRe Authだ。開発の大きな手助けとなっている。

［各機能ごとの設計の考え方（一例）］
店舗機能
コア側にある店舗機能を利用することもできるが、外部システムの店舗機能と同期したい場合はテナント側で処理できるように設計した。
*店舗機能：店舗の住所情報や在庫状況のデータ

会員証
EAP時代から、独自システムを利用している企業が多かったため、テナント側へ。ただし、個別に繋ぎ込みするのではなく、MGReAuthで処理できる設計にした。
*会員証：顧客情報や会員ポイントシステム

# コメント
サーバサイドのこの考え方は、新しく構想したわけではなく、前身サービスであるEAPの時から取り組んでいたことなんです。MGReに移行するにあたって約20社の情報を踏襲しながら設計しました。コアの機能と同じような動きができるテナント領域を目指しました（サーバサイドリーダー蔵下）

03. SDK組み込み・イベントタスクキュー

MGReはコアとテナント領域に整理されているため、テナント側で新しい画面や機能追加がしやすい設計になっている。ここではこの設計を活用した二つの事例を紹介したい。

【1.SDK組み込み】

近年、ニーズが増えているのがSDK組み込みだ。「SDKを組み込むとシステムに影響が出てしまうので避けたい」というのが一般的である。MGReも同様で、SDKによっては特有の仕様があり、SDK自体をコアに組み込んでしまうことで、そのSDKを利用しないアプリでも影響を受けてしまうことがある。しかし、テナント領域があることにより、SDK組み込みを必要なアプリだけに限定させることができる仕組みになっている。

# コメント
データとシステムを繋げるのがDXの本質。コアの部分にSDKを組み込むと重くなってしまうため、テナントに組み込めるようエンジニアチームが設計実装してくれました。SDK組み込みの対応がスムーズに進んだのも、綺麗な設計がベースにあるおかげです（プランナー篠田）

【2.イベントタスクキュー】

さまざまなニーズに応えることを可能としている仕組みの一つ、イベントタスクキュー。「アプリにログインした時に特定のページを表示したい」「店舗フォロー後にアニメーションを出したい」「クーポン使用後に外部のクーポンシステムと同期させたい」このような個別のニーズは、本来コアで実装しなければ実現できないため、仕組みを考える必要があった。
コアの機能内で、「Xというイベントが発生した際、Aという処理をしたい」ということを解決するために、コアで発生するイベントと処理（タスク）の概念を2つに分解し、イベント発生をコア機能に持たせ、タスクをテナントから注入できる仕組みを用意した。社内で会話がスムーズに進むよう、”イベントタスクキュー”と命名した。

# コメント
実は当初から構想には入っていたんです。エンタープライズはカスタマイズが多いので、きっといつか注入したくなるだろうなと。せっかくなら仕組み化してしまおうと思い、エンジニア側から提案しました。プランナーの篠田さんに伝えたら「夢のような仕組みだ！」と喜んでくれました（VPoE兼iOSリーダー二木）

カイゼンで、より良いサービスに育てていく

バージョンアップしやすい基盤があるため、コアの機能を作り込みすぎず、デリバリーしてニーズを吸収し、カイゼンを重ねて機能をブラッシュアップしていく。気軽に意見を出し合い、最適なジャッジをしていく。コアとテナント領域の特性を活かしながら、より良いサービスに育てていきたい。