株式会社ラクスの技術ブログ

全982件

2026/11/10

はじめにプロダクト開発支援課フロントエンド推進チームの安彦です。プロダクト開発支援課は2026年10月に発足したばかりの組織です。私たちのチームが顧客としているのは、プロダクトの先にいるエンドユーザーだけではありません。社内でプロダクトを作っている開発者もまた、私たちが価値を届けるべき顧客として捉えています。現在、社内の複数のプロダクトで共通して使えるデザインシステム「 Libero（リベロ）」を構築しています。ラクスには、用途もブランドも異なる複数のプロダクトが存在します。開発者がそれぞれの現場で迷わず安全にLiberoを使えるようにするためには、最初に「 Liberoが何を持ち、何を持たないか」を決める必要がありました。この記事では、Liberoの設計において決めたことを、次の問いに沿ってお伝えします。はじめに複数プロダクト向けに、何を持たないか見た目と振る舞いを、何を根拠に決めたか画像だけでは表現しきれない領域 UI品質を担保する「5つの層」値を根拠から逆算し、CIで品質を担保するプロダクトからLiberoへ、何を渡せるかデザインガイドラインと接点の関係 AIが組んだUIの品質を、誰が担保するかおわりに ※Liberoのコードやドキュメントを社外公開する予定はありません。設計のケーススタディとしてこの記事がお役に立てば嬉しいです。複数プロダクト向けに、何を持たないか Liberoは、プロダクトのドメインやブランドを持ちません。ドメインの知識 *1 はプロダクトごとに異なり、変わり続けるので、Liberoが追従し続けることは困難です。また、ブランド *2 についても、複数ある中でのどれか1つの表現をLiberoの既定値にしてしまうと、他のプロダクトにとっては不要なスタイルを打ち消す余計な作業が発生してしまいます。「全社横断のデザインガイドラインを先に作らないのか？」と疑問を持たれるかもしれませんが、Liberoではそのアプローチをとりませんでした。各プロダクトでガイドラインの整備状況や目指す表現が異なるからです。そのためLiberoは、あとからどのガイドラインが注入されても受け入れられる基盤を先に作りました。APIにはドメインの言葉を持ち込まず、提供するコンポーネントの既定の見た目や振る舞いにも、特定のブランド表現を入れていません。このように持たないものを明確に決めた上で、デザイントークンを起点に、44のコンポーネントを提供しています。 Liberoのコンポーネントの既定の見た目。特定のプロダクトのブランド表現を持たない見た目と振る舞いを、何を根拠に決めたか既定にドメインもブランドも入れない分、見た目と振る舞いの値には別の根拠が必要です。Liberoでは、エンジニアが画面を組むときに毎回決めているものを整理することから始めました。画像だけでは表現しきれない領域画面を組むとき、画像という静的な形式だけでは、どうしても表現しきれない領域があります。状態: hover、押している途中、送信中、エラー、空データ、長い文字列、文字サイズの拡大操作: キーボードだけで操作できるか、スクリーンリーダーに何が読み上げられるか更新: 使っているライブラリを更新したあとの見た目これらが仕様として明記されない場合、実装するフロントエンドエンジニアの個人の判断に委ねられます。機能開発のスピードが優先される現場では、UIの細かな品質までを受け入れ基準に定める余裕がないことも少なくありません。個人の判断に委ねられ、気づかれなかった実装は、次に誰かがそのコードに触れるまで残り続けます。 UI品質を担保する「5つの層」そこでLiberoは、個人の判断に委ねられていたUI品質を、層に分けて整理しました。 UIは単一の面ではなく、土台から順に依存しながら積み上がる多層的な構造をしています。最下層にはブラウザやOS、支援技術といった変えられない実行環境があり、最上層にはプロダクト固有の判断が乗ります。 Liberoは、この両者の間に位置する5つの層を自身の責務と定めました。層ごとに何を満たせば品質が守られるかを定義し、すべてのコンポーネントに適用しています。セマンティックHTML: 用途に合ったHTML要素とroleで組み立てるアクセシビリティ: キーボードで操作でき、支援技術に名前・役割・状態を伝える状態表現: hover・focus・disabled・処理中などの状態を見た目で示すテーマ: 色や形をトークンとして持ち、値をまとめて差し替えられるフレームワーク対応: UIフレームワーク・CSSライブラリの更新に追従する最上層のプロダクト固有の判断（情報設計、画面の構成、文言、操作後の処理）は、引き続き各プロダクトが持ちます。Liberoが間にある5つの層を引き受けるのは、プロダクト側がこのドメイン固有の判断に集中できるようにするためです。値を根拠から逆算し、CIで品質を担保する Liberoが引き受ける層の品質は、感覚ではなく明確な根拠と自動化によって担保しています。具体的には、次の2つの観点を満たすように既定の振る舞いを決めています。 Web標準: ブラウザ標準の振る舞いを上書きせず、 Baseline のWidely availableに含まれる機能で作るアクセシビリティ: WCAG 2.2 AA の達成基準を満たすこの2つの観点はCIで検査しています。Web標準はWidely availableを外れる機能を使っていないかをlintで、アクセシビリティは違反がないかを axe-core で確かめます。見た目の値も同様に根拠から逆算します。色はコントラスト比から候補を絞り、角丸は要素の高さとの比から決定します。値そのものではなく導き方を決めているため、将来値を変える必要が出た際も、同じ導き方で安全に決め直すことができます。プロダクトからLiberoへ、何を渡せるか Liberoは既定値のままでも、UI基盤として品質が保たれ、そのまま問題なく機能するように作られています。しかし、実際のプロダクトに組み込む現場からは「プロダクト固有のブランドカラーやスタイルをコンポーネントに適用したい」といった需要が生まれます。そこでLiberoでは、影響範囲をコントロール可能な状態に保ちながら、各プロダクトのドメインやブランドを安全に受け入れる経路として、明示的に以下の3つのみを接点として開放しています。 props: コンポーネントに、variant・状態・表示する文言を値として渡す theme: 色や形の役割（primaryなど）に、ブランド表現の値を渡す events: ユーザー操作の発生をプロダクト側へ通知し、その後の処理を委ねるこの3つは、変えても影響範囲が予測できる経路です。開く範囲を絞っている最大の理由は、前節で述べた品質と振る舞いの一貫性を無秩序に壊さないためです。また、依存の向きをプロダクトからLiberoへの一方向に制限することで、ライブラリ更新時の予期せぬレイアウト崩れを防ぎ、保守の負担をLibero内で完結させる目的もあります。デザインガイドラインと接点の関係各プロダクトのブランド表現は、横断のデザインガイドラインとして先に定めてからコンポーネントに落とす流れが一般的ですが、冒頭で触れたとおり、Liberoはこの順で作っていません。すでにガイドラインが存在するプロダクトは、その固有の表現をthemeの値として差し替えます。例えばprimaryの役割に値を渡せば、ボタンやリンクなど同じ役割の要素が、まとめてブランドカラーに置き換わります。一方、ガイドラインが整備中のプロダクトは、まずLiberoの既定に乗り、固有の表現が増えてきたタイミングでガイドラインとして育てていくことができます。特定のブランド表現を持たないプレーンな基盤にしたのは、この両方の状況を単一の接点で受け止めるためです。プロダクトは値を渡し、どの部分にどの役割を当てるかはLiberoが固定するもし提供している接点の範囲で既定から外れる値を入れる場合や、接点だけでは表現できない要件が出た場合は、Web標準やアクセシビリティとの整合性が崩れるリスクが生じます。その際は、Liberoの利用を強制するのではなく、なぜこの制約になっているのかという根拠を共有し、トレードオフを一緒に評価した上でプロダクト側に判断を委ねる対話を重視しています。基準を下回る上書きをしたくなったときの判断の分岐 AIが組んだUIの品質を、誰が担保するかここまでは、フロントエンドエンジニアが画面を組む前提で書いてきました。しかし現在では、AIによってUIの生成が容易になり、フロントエンドエンジニア以外がコードに手を入れたり、プロトタイプを作ったりする場面が増えています。生成された画面は一見すると見た目が整っています。しかし、focusの制御が漏れていないか、選択状態が色だけで示されていないか、disabledのときに何が起きるかといった見えない層の品質まで、生成段階で担保できているケースは多くありません。ここで見過ごされたものは、直す工数として現れます。画面を作る費用が下がった分、コードを保守し続ける負担の比重は上がります。だからこそ、コードを書く人が増えるAI時代において接点を絞る意味がより大きくなります。 Liberoの提供する3つの接点（props・theme・events）だけを通って組まれた画面であれば、人が書いてもAIが書いても、その下にある5つの層は、同じ品質の水準が保たれます。非エンジニアがAIで作ったプロトタイプであっても、接点だけで組まれていれば、フロントエンドエンジニアは画面の構成や文言の確認に集中し、安心してそのまま実装に進めることができるのです。おわりにデザインシステムやガイドラインのような共通の基盤は、揃えるための強制力を持ちます。しかし一方で、その強制力がプロダクトの開発スピードを落としたり、何を自分たちで決めてよいのか迷わせてしまう場面もあります。私自身も、前身となるデザインシステムの実装と利用の両方に携わる中で、同じ難しさを感じていました。このもどかしい経験を振り返ってみると、問題は強制力そのものではなく、「なぜその形なのか」「どこまで変えてよいのか」が辿れず、現場の判断が止まってしまうことでした。Liberoの設計には、当時の自分たち自身の反省が活かされています。 UIは作って終わりではなく、技術の変遷に伴って求められる品質の水準も変わり続けます。Liberoが責務の境界を明確にし、根拠を開示しているのは、強制力を最小限に留めつつ、各プロダクトがこの変化へ追従しやすくするための基盤でもあるからです。判断をプロダクト側に残す分、各プロダクトとの対話は欠かせません。導入の検討段階から使い始めたあとまで、プロダクトで見つかる課題を持ち寄ってもらい、一緒に決めていきます。Liberoだけでは完成しないからこそ、プロダクトと育てていくシステムでありたいと思っています。複数のプロダクトに向けて基盤を作ろうとしている方はもちろん、日々の開発でエンジニアが毎回決めているものに名前を付け、その責務を捉え直すきっかけになれば嬉しいです。 *1 : 特有のデータ構造、業務フロー、文言など *2 : テーマカラーやタイポグラフィ

CSS, HTML, 人工知能, フロントエンド, アクセシビリティ, 設計, 組み込み

株式会社ラクス の技術ブログ

コンテンツ

株式会社ラクスの技術ブログ