1. はじめに
Web フロントエンド開発を中心に行っている寺島です。
この記事はアンドパッドで開発しているデザインシステム 『Tsukuri』 の Web 向け実装である『Tsukuri for Web』の構築について紹介する最後の記事です。
この記事では Tsukuri for Web の現状と今後について紹介します。
記事内容を通して、Web フロントエンド開発者やデザイナーの方にアンドパッドに興味をもってもらうことを目的としています。
2. Tsukuri for Web の現状について
2.1. UI コンポーネント
Tsukuri for Web に含まれる Web Component の UI コンポーネントライブラリのバージョンは、この記事を書いている時点で 0.1.0-rc.98 です。 開発を始めてから 8 ヶ月程度が経過しているので、だいたい週に 2-3 回程度の頻度で新しいバージョンをリリースしています。
現在 50 種類の UI コンポーネントが実装されています (組み合わせて使うコンポーネントもあるので、実現できる UI パーツの種類はこれよりも少ないです)。 ですが、アプリケーションの基本的な部分を実装するには、あと数種類のコンポーネントが必要であると考えています。 そこで、それらのデザイン・実装が完了するまでは RC (Release Candidate) バージョンとしてバージョニングを行う予定です。
現時点で実装されているコンポーネントは、いくつかのプロダクトで実験的に導入をしてもらっています。 開発者からのフィードバックを随時 Slack で受け取り、デザインシステム自体の改良や、コンポーネントライブラリの改良を行っています。
2.2. アイコンコンポーネント・デザイントークン
現在、以下が Tsukuri for Web から提供されています。
- 346 種類のアイコンを含むコンポーネントライブラリ
- 435 種類 (エイリアスも含む) のデザイントークンとして定義されたプロパティを含む CSS / SCSS ライブラリ
これらは、Figma に存在する定義から API 経由で情報を取得し、新しい実装を生成するまでは自動的に行えます。 そのため、変更の要求からリリースまでを数分で実施できます。
特に開発初期の段階では、反復的な変更を行う過程でデザイントークンの命名体系の変更などが比較的多く発生します。 そのような状態でも実装への反映が機械的に行えることが、やることが多い初期段階では特に有効に働いています。
しかしながら、デザイントークンライブラリ自体が迅速に変更ができても、それを利用しているコンポーネントライブラリや、プロダクトへの反映が行えなければ最新のデザインシステムに追従することができません。 また、デザイントークンの実装は CSS のカスタムプロパティや SCSS の変数なので、変更に対して脆弱です。
これを補助するための CLI ツールを実装し提供しています。 このツールは、入力にしたファイルの中で破壊的な変更が発生したカスタムプロパティや変数を検出し、新しいトークンの名前へと変更、または、削除されたことを示すメッセージを出力します。
これまでに大規模な名前の変更などがありましたが、このようなプログラムの存在によって、デザイントークンの再検討や変更を積極的に行うことができるようになり、デザインシステムをあるべき姿に改善し続けることができるようになっています。
3. Tsukuri for Web の今後について
開発が始まってまだ間もない Tsukuri for Web ですが、開発者として考えている今後についてを紹介して一連の記事を締めくくりたいと思います。
3.1. バージョン 1.0.0 に向けた開発
直近は Tsukuri for Web をバージョン 1.0.0 に到達させることに注力して開発を行います。 以下を満たした上で、予定された破壊的な変更を適用し、バージョンを 1.0.0 とする予定です。
- 主要なコンポーネントを一通り実装する
- 実装したコンポーネントすべてのデザイナーによるチェックを完了する
この過程で、さらななる機能拡張や新たなコンポーネントの実装を円滑に行うために、内部的な改善も行うつもりです。
これまでコンポーネントを実装するときは、あえてロジックの抽象化などを行ってきませんでした。 これは、開発の初期段階であるために、デザインシステムに必要なコンポーネントや、各コンポーネントの責任が変わる可能性が高いと考えたためです。 そのような状態の中で処理の共通化や抽象化を行うと、本来分かれているべきモジュールを一つにまとめてしまうなどの誤りが発生する可能性が高いと考え、積極的にコードの複製を選択してきました。 コンポーネントがそろってくるにつれて、各コンポーネントの責任が明確になりこのような誤りが起こりにくくなってきていると考えています。
ロジックの抽象化をするにあたって、 Zag.js のような実装をイメージしています。 UI コンポーネントに含まれる状態とそこから導かれる属性を定義し再利用可能な状態に実装します。 これによって、これらを組み合わせて複雑な UI コンポーネントを実装していける状態を目指します。
3.2. Tsukuri for Web 利用者サポート
Tsukuri for Web はデザインシステムで定義したデザインをプロダクトに浸透させることを目的としています。 以前の記事で記載したとおり、これの実現のためには、Tsukuri for Web 自体が開発者にとって使いやすいものでなければいけません。
一方で、Tsukuri for Web は Web Component を中心とした実装にするにあたって、インターフェースにいくつかの制限を課しています。 これは、保守性などを踏まえた適切なトレードオフだと考えていますが、開発者からすれば例えば以下のようなことを気にする必要が発生し、各 UI ライブラリネイティブなコンポーネントライブラリに比べて使い勝手が悪いと感じても仕方ありません。
- Attribute のうち有効ではない組み合わせが存在する
- 例えば、ネイティブな input タグなら、
type="text"と同時にcheckedを指定しても意味がありません- コンポーネントの仕様に沿ったマークアップを行う必要がある
- 例えば、List コンポーネントの子には必ず ListItem コンポーネントを配置する必要があります
- 例えば、ネイティブな input タグなら、
これらは以下などで解決できると考えています。
- コンポーネントの Props の型をより厳密にする
- ESLint ルールを実装する
まず、前者についてですが、例えば先ほどの input タグの例なら、以下の様なイメージです。
type Props = { type: "text" } | { type: "checkbox" | "radio"; checked?: boolean }
これを、Web Component のメタ情報やそれ以外の情報から生成する方法を検討して実装したいと考えています。
次に後者ですが、Vueテンプレートや TSXに対して、コンポーネントの親子関係をチェックするルールを実装することで、この問題が解決できると考えています。
また、このような実装面でのサポートに加えて、Slack ワークフローを用いた問い合わせフォームの実装など、Tsukuri for Web を利用している開発者が気兼ねなく問い合わせをしやすい環境を整えていこうと考えています。
3.3. デザインシステムでのカバー範囲を拡大
デザインシステムのカバーすべき範囲は色やUIコンポーネント以外にもあります。
例えば、プロダクト間で一貫した用語や表現を使うことで ANDPAD 全体の利用しやすさが大きく向上することが期待できます。 現在は主に UI コンポーネントの開発に注力していますが、いずれはライティングに関するルールを textlint で実装しようと考えています。
4. おわりに
これまで、四本の記事を通して、ANDPADのデザインシステム『Tsukuri』の Web 向け実装である『Tsukuri for Web』について紹介してきました。
これらの記事を通して記載してきたように、多くの要件を考慮に入れ最適な設計・最適な実装を目指して開発を行っています。 私は直接プロダクトを実装しお客様に届けるということは行っていませんが、プロダクトを開発するデザイナーや開発者を支援し、間接的にお客様の成功を支援できることを目指して引き続き開発を進めていこうと思っています。
これまでの記事を見ていただいた Web フロントエンド開発者やデザイナーの方がアンドパッドに興味を持っていただければ幸いです。
その他のポジションについては、下記サイトをご覧ください！
