企業と顧客のよりよい関係を支えるMGReのアーキテクチャー（iOSアプリ編）

はじめに

こんにちは。iOSアプリエンジニアの二木です。
昨年MGReサービスがスタートし、これまで開発チームで様々な機能開発に取り組んできました。気が付くとあっという間に1年が経ち、直近ではMGReのアプリバージョンもv2.0へ進化しました。
よい機会なので、今回は、MGReアプリについてご紹介できればと思います。

MGReについて

MGRe（メグリ）は、モバイルアプリの開発から運用マーケティング活動までサポートするモバイルアプリプラットフォームですが、MGReの凄いところはアプリで必要な基本機能をアップデートできるサービスとして提供を可能にしつつ、企業で必要な異なる外部システムとの連携部分をテナント領域として組み込めるところにあります👏
（※ランチェスターでは、アプリで必要な基本機能をコア領域、企業ごとに外部システムとの連携部分などを自由に組み込める領域をテナント領域と呼んでいます。）

また、MGReアプリのステージ範囲は広く、基本機能のみで構成したスモールスタートでアプリをリリースし、事業に応じてECなどの外部連携でさらにアプリを進化させ、成長させることができるのも他のサービスにはない面白い部分です🙋

アプリ構成

このようなMGReのサービスの特徴を実現するために課題となったのは、前述したコアとテナント領域をうまく分離させたことでした。iOSアプリでどのようなアプリ構成で実現したかを次にご紹介したいと思います。

以下の図がアプリ構成になります。

XcodeのプロジェクトではFrameworkを内部に作成できる仕組みがあると思いますが、それを利用してコア領域とテナント領域を分けました。

構成図をみていただくと赤線で上下に分かれていていますが、下がアプリの基本機能があるコア領域になっており、ライブラリとして配信し、アップデートが可能になっています。
さらにコア領域においては、複数のモジュールで分かれており、各機能を疎結合にしてプログラム全体が複雑化することを避けています。なお、各モジュールは参照がルール化されており、うまく整理できるようになっています。

各モジュール

・ 機能モジュール（ニュース、お知らせ、アイテム、ブランド、会員証、店舗、クーポンなど）
・ アプリベース（アプリのベースを担う）
・ リソース類（文言、画像、カラーなど）
・ UI部品
・ データモデル
・ サービス（APIなど含めたサービス提供）
・ API（API通信）
・ MGReのプログラムコア（基本的なインタフェースなどを提供）

赤線より上のテナント領域では企業ごとに機能の変更や追加を行うことができるようになっており、その機能例をあげると以下のようなものがあります。

企業ごとの機能例

・ 新しいリソース（画像、文言、カラー）の差し替え、追加
・ 下タブの変更
・ 大枠のデザインパターン
・ サイドメニュー変更
・ 新しいAPI追加
・ 新しいDataModel追加
・ EC連携によるSSO
・ 会員証に差し込みたい画面
・ その他SDKなど（検証が必要です）

ちなみに、この構成については前プロダクトのEAP時代の構成から引き継いでおり、基本的な部分はあまり変わっていません。MGReになって多少フレームワークを整理しましたが、EAPの開発当初に開発チームメンバー内でしっかりルールを作って機能や役割ごとにフレームワーク化し疎結合な実装を行ったことで、MGReでもこの構成を活かすことができました。

余談ですが、EAP開発当時はアプリを実装する上でのルール決めやアーキテクチャの選定が重要だという想いがありましたが、実装開始までに時間がかかってしまい心苦しい時期もありました。ですが、あの時にしっかりと決めた構成やアーキテクチャがアプリの長い安定につながったと思うと、その重要性は大きいとわかります。（個人的には、当時エンジニアとして想いを貫いてよかったなぁと思っています😊）

MGReのアーキテクチャについて

さて、MGReのアーキテクチャについても少し触れたいと思います。EAPから引き続いて、MGReではMVCPを採用しています。
他にもClean ArchitectureやVIPERなどのアーキテクチャも検討に上がったのですが、最終的にMVCPを採用することにしました。決定する上で一番重視したことは「わかりやすさ」でした。

この「わかりやすさ」というのはMGReの特性上、非常に重要になってきます。
MGReのアプリは複数企業のアプリに適用できるように作られており、プロジェクトに参加するエンジニアも増えています。このような状況の中で学習コストが高いアーキテクチャを採用してしまうと、反って混乱やバグの原因になりかねません。
iOSアプリを開発しているエンジニアであれば、Appleが昔から推奨していたMVCの構成には馴染みがあると思います。かといって、MVCだとViewControllerが肥大化するリスクがあったため、MVCPを採用することでViewControllerをViewControllerとPresenterにわけ問題を解消するようにしました。

Presenterの追加のみであれば学習コストは抑えられるし、アプリの基本機能以外の実装で混乱することは少ないと考えたからです。

次のMGRe成長にむけて

MGReサービスは日々成長していますが、プロダクトの成長が重要になってくると思っています。MGReはプロダクト部で開発を行っていますが、今後はより積極的に動いて行きたいと思っています。

『アプリ表現の進化』

来年、画面を構成するレイアウト部分で大きなアップデート予定があり、アプリの世界観をさらに表現できる機能が増える予定です。そのタイミングでMGReアプリの仕組みも再設計予定となっています。（個人的には、かなり面白い画面レイアウト設計ができると思っているので、ワクワクしています💪）

新しい技術を積極的に使っていきたい

MGReの開発を行っているプロダクト部では、新しい技術については検証して、良いものは積極的に導入を考えています。

iOSアプリでは現状MVCPアーキテクチャを採用していますが、AppleがSwiftUIとCombineが発表したことで見直すよい時期がきていると感じています。
（先にSwiftUIを検証してみましたが、iOS13では動作に不安があったため、サポートOSがiOS14以上になったタイミングで導入を予定しています。)

またCombineはSwiftUIと一緒に活用することで、これまでの表示データとビューを別々に管理することから開放され、参照するデータと画面表示の整合性を担保することが容易になります。また、Combine自体もFoundation内にも採用されており、非同期の処理をまとめられ活用場面もいろいろとありそうです。

ぜひ楽しいディスカッションがしたいです！

ランチェスターでは、MGReのプロダクトをさらに成長するためにエンジニア同士で、たくさん楽しいディスカッションをしたいと思っています。
アプリチームではフラットに話せる環境があり、意見を尊重しながらも楽しくディスカッションしています。（楽しすぎて、よく時間が足りなくなっています…）
そんな環境ですので、ぜひ楽しく一緒にディスカッションできるエンジニア仲間が増えればいいなぁと思っています。とりあえず話を聞いてみたいなどでも大丈夫ですので、ぜひご連絡いただければと思います。