マルチテナントアプリにおけるデザインコンポーネントの管理方法

こんにちは。マンガアプリチームでデザイナーをしている id:gano-k です。

GigaViewer for Apps(以下、GigaApps)は、マンガアプリに必要な「ビューワ」「作品詳細」「マイページ」などの基本機能を共通モジュール化し、複数のサービスで再利用できる仕組みを提供しています。 各サービスごとにカスタマイズされたUIを提供しつつも、裏側では共通の基盤が動いているのが特徴です。 このような構造の中でデザインを行う際には、「各サービスへの最適化」と「再利用性を担保する共通設計」の両立が求められます。

Inside GigaViewer for Apps連載10回目は、GigaAppsにおけるマルチテナント対応のデザインコンポーネント設計と、その実践的な工夫についてご紹介します。

デザイン時にマルチテナントで気をつけていること

まず重視しているのは、「横展開(他サービス展開)しやすい設計になっているかどうか」です。 たとえば、あるサービスで美しく見えるデザインでも、別のサービスに展開した際に見栄えや使い勝手が悪くなってしまうケースがあります。 そうした事態を避けるため、なるべくシンプルで拡張しやすいUI設計を心がけています。

また、共通コンポーネントを設計する際には、「少年ジャンプ+の読者」などサービス固有のユーザー像ではなく、“マンガアプリを使うユーザー”というより広い視点で体験を設計するようにしています。 これは、すべての共通部分で汎用性を持たせるための前提でもあります。 もちろん、各サービス側から「もっとこうしてほしい」といった要望が出ることもあります。 そのような場合には、エンジニアと相談し、無理に共通コンポーネントに押し込めず、必要に応じて個別対応用のコンポーネントに分離するなど、柔軟な運用を行っています。

Figmaを利用したコンポーネント管理

私たちのチームでは、デザイン作業に Figma を活用しています。 Figma は、デザイナー以外の職種の方やクライアントと共有する際に、専用ツールをインストールすることなく閲覧できるため非常に便利です。

では、実際にどのような点に気をつけてデザインを進めているのか。 GigaApps を導入している 2 つのサービスの作品詳細画面を比較しながらご紹介します。

GigaAppsで構築された2つのサービスの作品詳細画面
一見すると、どちらも似た構成になっています。 これは共通コンポーネントをベースにしているためですが、細かく見ていくとサービスごとの差異が見えてきます。

まず目に止まるのは、ブランドカラーです。左のコミックガルド+では青色。右の少年ジャンプ+では赤色を使っています。 両方とも同じFigmaコンポーネントを使っていますが、FigmaのLocal variables機能を活用することで、サービスごとに異なる色を自動的に適用できるようになっています。

次に注目したいのは機能や表記の違いです。 左のサービスでは「チケット」や「ポイント」が表示されていますが、右のサービスでは「初回無料」や「コインによる購入」が表示されています。 このように中身の要素が異なっていても、ベースとなるコンポーネントは共通化されており状態やサービスに応じてテキストやアイコンを動的に切り替える構造にしています。

複雑な条件を考慮した設計

色の切り替えについてはサービスごとのブランドカラーだけでなく、以下のような追加条件も考慮する必要があります:

  • iOS / Android などのプラットフォーム差分
  • ライトモード / ダークモードといったテーマの切り替え

このようなスタイル分岐に対応するため、Local variables機能を利用してAppearanceの切り替えで対応しています。

カラーTokenの設計

  • BrandToken:サービスごとのブランドカラー
  • PlatformToken:プラットフォーム(iOS / Android)ごとの色差分
  • Light / Dark:テーマ切り替え対応

PlatformToken
上図は、テキストやボーダーなどシステム系の色を管理している PlatformToken の設定画面です。 たとえば Figma 上でテキストの色を指定する場合、実装上は iOS では Primary、Android では OnSurface と異なる命名になることがあります。 プラットフォームで別々の Token を用意すると管理が煩雑になるため、Figma上では Main というFigmaTokenを作成し利用するようにしています。
PlatformToken例

また前述のようにBrandTokenは、プラットフォームごとの違いはありませんが、サービスによって色が変わります。そのような場合も同じようにLocal variablesを使って管理しています。

Brand Token例
このようにFigmaのLocal variables を使ってカラーTokenを管理することで、1つのコンポーネントを複数のサービス・プラットフォームに対応させることが可能になっています。

要素の切り替えを容易に行えるように

中身の要素についても、共通コンポーネントをベースにしつつ、各サービスに応じて柔軟に出し分けられる仕組みを設計しています。

ベースのコンポーネント
ベースコンポーネントでは、以下のような要素を切り替え可能な構造にしています:

  • 作品サムネイル
  • 各種ステータスアイコン(例:初回無料、完読済み)
  • テキストラベル(例:ポイント、コイン)

これらの要素を表示・非表示の切り替えで調整することで、1つのコンポーネントでさまざまなサービスの要件に対応できるようにしています。

サービス別のコンポーネントを並べた場合
上記画像は同じコンポーネントでサービスを切り替えた形のものを並べています。

  • 各サービスに沿った作品
  • 「初回無料」と「チケット無料」
  • 「閲覧数」と「お気に入り数」
  • コインやポイント

このような細かな部分でサービス毎に差があるのがわかると思います。 またカラーToken設計で話したように同じ箇所でもサービスによって色も変わっています。 このように、必要な要素だけをサービス毎で表示・非表示制御できる設計にしておくことで、似たようなコンポーネントの増加を防ぎ、デザイン運用の効率化と一貫性の維持を実現しています。

エンジニアとの協業で意識していること

私たちのチームでは、デザイナー・エンジニアがお互いにスムーズに連携できるよう、以下を意識してFigmaを運用しています。

1. 誰が見てもわかりやすいFigmaにする

Figmaはデザイナーとエンジニアだけでなく、プランナーやクライアントなどさまざまな職種が確認するツールです。 そのため、レイヤー構造や命名規則、変更履歴の管理まで丁寧に整備し、 「どこを見れば今の仕様がわかるか」が直感的に伝わる状態を目指しています。

また、同一画面で複数企画が進行する場合は、Figmaファイルを企画ごとに分けるなど、視認性と運用負荷のバランスを取りながら工夫しています。

2. Figma運用は“お互い楽になる”仕組みで

FigmaTokenなどのスタイル設計は、デザイナーにとっては管理効率が良くなる一方で、 エンジニア側にはToken名の把握や対応関係を理解する手間が発生します。

そのため、エンジニアに過度な負担がかからないよう、Figma上に比較表を設置したり、 実装時に迷わない仕組みを作ることで、双方の運用コストを最小限に抑える工夫をしています。

3. 設計段階での「すり合わせ」を大切に

UI設計の方向性が見えた段階で、なるべくエンジニアに確認・相談を行うようにしています。 なぜなら、デザイン上は実現可能に見えても、 技術的な制約やプラットフォームごとの差異によって実装が難しくなるケースがあるためです。

早期に相談することで、 「もしこういう意図なら、別のアプローチが現実的かも」といった実装面の提案をもらえることも多く、 結果として無理のない・質の高いアウトプットに繋がります。

おわりに

マルチテナントアプリの設計では、単に「共通化を目指す」だけでなく、将来的な拡張性やサービスごとのカスタマイズを視野に入れた、柔軟で現実的なデザイン判断が求められます。

GigaAppsでは、Figmaの機能を活用した変数管理や、エンジニアとの連携を通じて、運用性の高いコンポーネント設計を日々アップデートしています。

今後も、実践を通じて得た知見をこの場で共有していければと思います。