Figmaから本番環境へ:2026年カタールにおけるデザインシステムの構築法

カタール国家ビジョン2030の推進、ルサイルにおけるフィンテック企業の相次ぐローンチ、そしてムシェイレブ・ダウンタウン・ドーハが掲げるスマートシティ構想——こうしたカタールのデジタル変革の波は、Figmaファイルの爆発的な増加を生み出しました。銀行はオープンバンキング対応のためにモバイルバンキングアプリを刷新し、通信事業者はセルフサービスポータルを再構築し、政府機関はHukoomiのような取り組みのもとで市民向けサービスの統合を進めています。しかし、プロジェクトを重ねるたびに私たちは同じ失敗パターンを目にします——美しく整理されたFigmaライブラリが、本番環境との接触に耐えられないのです。開発者はコンポーネントをゼロから作り直し、アラビア語版と英語版は少しずつずれていきます。半年後には、3つのチームがそれぞれ微妙に異なる「プライマリボタン」を持つことになります。この記事は、FOCUS POINTがこのギャップを埋めるために実践しているプレイブックです——トークン、ガバナンス、導入という順序で解説します。

本当の問題:あなたのFigmaファイルはデザインシステムではない

デザインシステムとは、共有ライブラリ内の見た目の良いコンポーネント集ではありません。ロードマップ、所有者、リリースノート、フィードバックループを備えた「プロダクト」です。ドーハのチームがFigmaをゴールと捉えてしまうと、ほぼ即座に3つの症状が現れます:微妙な不整合を抱えた重複コンポーネント(2pxずれたスペーシング、同じ「ブランドブルー」の4種類の色合い)、信頼できるハンドオフの仕組みが無いためにデザイナーが出すものと開発者が実際に作るものとの間に広がるギャップ、そしてカタール市場特有の問題として、正しくトークン化されなかったアラビア語タイポグラフィが挙げられます。その結果、開発者はプロジェクトごとにRTLレイアウト用のフォントサイズと行の高さをハードコーディングせざるを得なくなります。この解決は上流工程、すなわちトークンから始まります。

デザイントークン:あらゆるハンドオフを生き抜く真実の情報源

デザイントークンとは、カラー、スペーシング、角丸、タイポグラフィ、エレベーション、モーションの長さといった、ブランドとプロダクトの原子的な決定事項を、ハードコーディングされた値ではなく名前付き変数として表現したものです。適切に構造化されていれば(理想的にはW3C Design Tokens Community Groupの形式に従うことで)、トークンはプラットフォームに依存しなくなります——同じソースが、あなたのWebアプリ、iOSアプリ、Androidアプリ、さらにはウェストベイの銀行支店にあるFlutter製キオスク体験までも支えることになります。

• グローバルトークン:生の値(16進コード、ピクセルスケール、フォントファミリーなど)で、めったに変化しません。
• エイリアス/セマンティックトークン:「color.background.critical」や「spacing.card.padding」のような、用途に基づいた名前を持ち、グローバルトークンを参照します。
• コンポーネントトークン:最も細かい層で、「button.primary.background.hover」のように特定のコンポーネントに紐づきます。
• フレームを複製する代わりに、モード機能付きのFigma Variablesを使って、ライト/ダークとLTR/RTLを同時に管理しましょう。
• Tokens StudioやFigmaのネイティブAPI経由でトークンを書き出し、Style Dictionaryを使ってCSSカスタムプロパティ、Swift、Kotlin、Tailwind設定へと変換します。

ガバナンス:パーツの寄せ集めを生きたプロダクトへ変える

ガバナンスとは、本社のデザイナー、外部委託チームの開発者、キャンペーン用マイクロサイトを制作するマーケティングチームなど、数十人もの関係者がそれぞれ異なる方向に引っ張る中でも、デザインシステムの一貫性を保つための仕組みです。私たちが支援してきたカタールの組織——ドーハ拠点の銀行であれ、省庁のデジタル部門であれ——において最も機能するモデルはハイブリッド型です。少人数のコアチーム(2〜4名)がアーキテクチャ、トークン、リリースの頻度を管理し、各プロダクトチームは軽量なRFC(コメント依頼)プロセスを通じて新しいコンポーネントを提案します。提案されたコンポーネントはすべて、統合される前にドキュメント化されたユースケース、アクセシビリティレビュー、そしてアラビア語/英語のコンテンツ例を備えている必要があります。セマンティックバージョニング(メジャー.マイナー.パッチ)と公開された変更履歴があれば、「更新しても安全かどうか誰も分からない」という典型的な麻痺状態を防げます。

• 各トークンカテゴリとコンポーネントファミリーについて、誰が実行責任者(Responsible)、説明責任者(Accountable)、相談先(Consulted)、報告先(Informed)なのかを定めるRACIを作成しましょう。
• 貢献ガイドラインをアラビア語と英語の両方で公開してください——これだけでも、カタールの多文化チームにおける大きな導入障壁を取り除くことができます。
• 廃止ポリシーを設定しましょう:コンポーネントを削除する前に最低2リリースサイクル分の予告期間を設け、可能な限り自動化されたコードモッドを提供します。
• 各事業部門(リテールバンキング、法人、デジタルチャネルなど)の代表者が参加する月次のデザインシステム委員会を開催し、対立を調整しましょう。

カタールの組織における導入:義務から習慣へ

私たちはドーハにおいて、資金が潤沢に投じられたデザインシステムの取り組みが失敗する場面を数多く見てきました。それはコンポーネントの品質が悪かったからではなく、導入が継続的なプログラムではなく一度きりの発表として扱われたからです。経営層からの利用義務付けは初期的な遵守は生み出しますが、真の意味での導入には決してつながりません。効果的なのは、デザインシステムを「最も抵抗の少ない道」にすることです——ゼロから構築するより速く、古いSketchファイルよりも文書が整っており、目に見える形でメンテナンスされている状態です。

• 各スクワッド内に「デザインシステムチャンピオン」を任命しましょう——これは分散したチーム間でバイリンガルのベストプラクティスを広める最も速い方法であることが多いです。
• 毎週オフィスアワー(ドーハのオフィスでの対面、またはTeams経由)を設け、デザイナーや開発者が誰でも障害を持ち込めるようにしましょう。
• Figmaライブラリの分析データと、コード内のコンポーネント利用状況(ESLintルールやインポートスキャンなどを通じて)を追跡し、どのチームが導入済みでどこがまだかを把握しましょう。
• オンボーディングを新入社員研修に組み込みましょう——現地、地域、国際的な人材が混在し、それぞれ異なるデザインツールの習慣を持つカタールのような市場では特に重要です。

設計段階からのRTLとバイリンガル対応:カタールにおける絶対条件

カタールでローンチされるあらゆるデジタルプロダクト——銀行アプリ、通信事業者のセルフケアポータル、政府の電子サービス——は、ユーザーが同一セッション内で言語を切り替えることも多い中、アラビア語のRTLと英語のLTRを完璧に扱う必要があります。これをローンチ後に修正するのではなく、コンポーネントレベルで最初から組み込んでおくことこそ、デザインシステムが真価を発揮する部分です。CSSの論理プロパティ(margin-leftではなくmargin-inline-startなど)を使えば、別途RTL専用のコードベースを持たなくてもコンポーネントは自動的に反転します。方向性を伝えるアイコン(矢印、戻るボタン、シェブロンなど)には反転バリアント用のトークンが必要ですが、方向性を伝えないアイコン(検索の虫眼鏡やチェックマークなど)は絶対に反転してはいけません——これは今なお地域全体の本番アプリで見られるミスです。数字の扱いも見落とされがちなポイントです:製品が西アラビア数字(0-9)を使うのか、東アラビア・インド数字を使うのかを早い段階で決め、その選択をトークンとして符号化することで、すべての画面で一貫性を保てるようにしましょう。

Figmaからコードへ:実際に出荷されるパイプライン

私たちがクライアント向けに実装する技術的パイプラインは、概ね次のような流れになります。デザイナーはFigma Variablesとしてトークンを管理し、Tokens Studioのプラグインを通じてGitリポジトリと同期します。マージのたびにGitHub ActionsのワークフローがStyle Dictionaryを実行し、トークンをプラットフォームごとの出力へと変換します——Webアプリ向けのCSSカスタムプロパティ、Android向けのXML/Kotlin、iOS向けのSwiftなどです。コンポーネントはStorybook上で文書化され、視覚的にテストされます。これはデザイナーと開発者双方にとっての共有された真実の情報源となり、Figmaのコメントスレッドよりもはるかに信頼できます。Chromaticのようなビジュアルリグレッションテストツールが、意図しない変更をステージング環境に届く前に検出します。そして何より重要なのは、構築されたコンポーネントをFigmaの仕様と照らし合わせてデザイナーがレビューするデザインQAのステップが、ユーザーからの苦情が寄せられる前——つまり毎回のリリース前——に実施されることです。

本当に重要な指標を測る:ドーハの経営層向けKPI

• コンポーネント導入率:システムコンポーネントで構築された本番画面の割合 対 個別のカスタム対応の割合。
• リードタイム:デザインのハンドオフから本番リリースまでの平均時間(システム導入前後での比較)。
• アクセシビリティ準拠率:WCAG 2.2 AAに準拠するコンポーネントの割合。カタールの政府デジタルサービスにおいて特に重要です。
• デザインと開発の整合性スコア:Figmaの仕様と実際に出荷されたUIとの視覚的な差異率で、自動化されたスクリーンショット比較によって追跡します。
• バイリンガル(アラビア語/英語)版プロダクト間のUI不整合に関連するサポートチケットの削減。

ドーハのフィンテックシナリオ:成功の姿とは

ドーハのデジタルファーストな金融サービスチームが、オープンバンキング要件に紐づく厳しい規制スケジュールの中、新しい貯蓄商品をWeb、iOS、Androidの各プラットフォームでアラビア語と英語の両方でローンチする場面を想像してください。トークンが真実の情報源となっていれば、ブランドリフレッシュ(新しいプライマリカラーと更新されたタイプスケール)は、3つの個別の手作業による更新ではなく、単一のプルリクエストで3つのプラットフォームすべてに反映されます。ガバナンスが整っていれば、マーケティング主導のプロモーションバナーコンポーネントは、システムの外側でハードコーディングされて次のリデザインで壊れるのではなく、2日間のRFCプロセスを経て組み込まれます。導入が根付いていれば、新しく参加したメンバーは古い画面をリバースエンジニアリングするのではなく、システムのドキュメントを使ってオンボーディングできます。その結果得られるのは、単なるローンチの高速化だけではありません——組織が2030年に向けてデジタルへの野心を拡大していく中でも一貫性を保ち続けるプロダクトなのです。