【ITニュース解説】Our design tokens are a package, and the marketing site is deliberately not a consumer

Munchableというサービスは、ユーザーが直接使うアプリ、その製品を紹介するマーケティングサイト、そしてアプリのデモを見せるためのSNS動画という、三つの異なる媒体を持っている。これらすべてが、一貫したブランドイメージと機能を示す必要がある。たとえば、アプリで表示される色やフォント、さらには特定の状態を示すメッセージが、SNS動画やウェブサイトでも全く同じに見え、同じ意味を持つことが重要になる。しかし、これらを別々に開発していると、時間の経過とともにデザインや表現に「ずれ（drift）」が生じやすいという大きな課題があった。

以前のMunchableでは、アプリのデザイン情報である「デザイントークン」が、SNS動画を作成する際に手動でコピーされていた。デザイントークンとは、アプリやウェブサイトのデザインを構成する、色、フォントサイズ、間隔、角丸の半径といった、再利用可能な最小単位の情報群のことだ。この手動コピーという方法は、一見簡単に見えるが、実は非常に危険な行為だった。なぜなら、アプリ側で「Can't assess（評価できません）」という表現が「不明」に変わったとしても、手動でコピーされたSNS動画のデータは古い表現のまま残り、アプリとSNS動画の間で情報が矛盾してしまう事態が発生したからだ。デザインのずれは、単に見た目が少し違うだけではなく、ユーザーに誤った情報を伝えるという、製品として深刻なバグを引き起こす可能性があった。古い表現のSNS動画は、製品の信頼性を損なうことになりかねない。

この問題を根本的に解決するため、Munchableはデザイントークンの一部を「ワークスペースパッケージ」として共通化するアプローチを採用した。ワークスペースパッケージとは、複数のプロジェクトで共有・再利用できるように、特定の機能や情報をひとまとめにしたコードの集合体のことだ。このパッケージにデザインの共通要素を集約することで、各媒体が同じ「真実の源（source of truth）」を参照するようになる。つまり、どこか一つの場所でデザインの定義を変更すれば、それを参照している全ての媒体にその変更が自動的に反映される仕組みを構築したのだ。

この共通パッケージには、主に三つの情報が含まれている。一つは「ライトモード専用のカラーパレット」だ。Munchableはライトモードのみを提供しているため、ダークモード用の色定義は不要で、単一の明確な色体系を持つ。それぞれの色には、アクセシビリティ基準を満たすための「コントラスト比」も併記されており、視認性の高いデザインを保証する。二つ目は「スペーシング（要素間の間隔）」と「ラディウス（角丸の半径）」のスケール定義だ。これにより、ボタンの余白やカードの角丸が、どの媒体でも一貫した見た目になる。そして三つ目が、最も共有が重要とされた「評価の語彙（VERDICT_LABEL）」と「評価アイコン（VERDICT_ICON）」だ。これらは製品の評価結果を示すテキストやアイコンで、「Good fit（良い適合）」「Caution（注意）」「Avoid（回避）」「Can't assess（評価できません）」といった具体的な内容だ。これらの語彙が媒体間で異なると、ユーザーは混乱し、製品の信頼性が大きく損なわれるため、共有が不可欠だった。

一方で、このパッケージに意図的に含めなかった情報もある。それは「フォントファミリー」だ。フォントの読み込み方法は、プラットフォームによって大きく異なる。例えば、モバイルアプリ開発フレームワークであるExpoを使うアプリは特定のフォントファイルを読み込むが、ウェブブラウザはwoff2形式のウェブフォントを読み込む。このように、フォントのファイル形式や読み込みに関する技術は、各プラットフォームに固有の問題となるため、共通パッケージには含まれず、アプリやSNS動画といった各媒体（「コンシューマー」と呼ぶ）がそれぞれ自身の責任で管理することになった。これにより、共通パッケージはあくまで「プラットフォームに依存しない」汎用的なデザイン情報に特化し、各コンシューマーは、共通情報をインポートしつつ、自身のプラットフォーム特有の要件（例えば、React Native用のモーションカーブやCSSフォントスタックなど）を追加で定義するという、効率的な分業体制が確立された。

また、Munchableの「マーケティングサイト」は、この共通パッケージを全くインポートしないという、意図的な選択がなされた。これは、サイトのデザインがアプリとは明確に異なる部分を持つためだ。具体的には、マーケティングサイトでは、アプリよりも大きな要素（ヒーローセクションや大きなカード）が使われることが多いため、アプリの角丸（8、12、16ピクセル）よりも、より大きな角丸（12、18、28ピクセル）が採用されている。これはデザインの「ずれ」ではなく、ウェブサイトの性質に合わせた「意図的なデザインの違い」である。もしマーケティングサイトをパッケージのコンシューマーに加えてしまうと、アプリの角丸をサイトに強制するか、パッケージ内に二つの異なる角丸スケールを定義する必要が生じ、結果としてパッケージの持つ「単一性」という価値が損なわれてしまう。そのため、マーケティングサイトは独立したデザインを維持し、サイト内で表示される評価の語彙は手動で入力される。これは残されたリスクだが、デザイナーが最もよく確認する場所であるため、万が一のずれが生じた際にも、早期に発見できると見込まれている。

この新しいデザイン管理体制の最大の強みは、「型システム」、具体的にはTypeScriptの強力な機能にある。手動でのコピー＆ペーストは、変更を見落とすリスクがあったが、共通パッケージを利用し、それをTypeScriptで記述することで、そのようなリスクを大幅に軽減できる。例えば、パッケージ内で評価ラベルのテキスト名を変更した場合、そのパッケージをインポートしているアプリやSNS動画のコードは、自動的に「コンパイルエラー」になる。これにより、古いラベルを参照している箇所が強制的に修正されるため、デザインの「ずれ」が未然に防がれるのだ。これは、異なる媒体間でデザインが一致していることを確認する複雑なテストを記述するよりも、はるかに堅牢で効率的な方法だと言える。型システムが、コードレベルでデザインの一貫性を保証する「防護壁」として機能する。

このように、Munchableは、複数の媒体でデザインの一貫性を保ちつつ、各プラットフォームの特性も尊重するという洗練されたアプローチを採用した。デザイントークンを共通パッケージとして集約し、プラットフォーム固有の要素は各媒体が管理する。そして、型システムを活用することで、人間の手作業による「ずれ」のリスクを最小限に抑え、製品の信頼性とブランドの一貫性を高めている。ただし、古いJSONファイルに誤った情報が残っているといった正直な課題もまだ存在し、今後パッケージが唯一の真実の源となるよう、情報の整理が進められる予定だ。この事例は、現代のソフトウェア開発において、デザインと開発の連携、そしてコードの再利用性がどれほど重要かを示している。