一休.com/Yahoo!トラベル、マルチブランドにまた がるデザインシステム 2022/6/30 【一休 × 出前館】Frontend Meetup 株式会社一休 CTO室 山口将希@igayamaguchi

自己紹介 ・Twitter: @igayamaguchi ・一休 CTO室で フロントエンド寄りのエンジニア ・業務でVue.jsずっと触ってます ・漫画好き、最近はマガジンが熱い ・VTuberとか好き

今日話すこと ● 一休.com、Yahoo!トラベルで今起こっている問題 ● デザインシステムについて ● 一休ではどうやってデザインシステムを導入したか ● デザインシステムを導入してどうだったか

一休.comとYahoo!トラベル ● 一休.com、Yahoo!トラベル、２つの宿泊予約サイト を一休が運営 ● 2021年4月、Yahoo!トラベルを一休.comとシステ ム統合する開発プロジェクトが開始 ● 2021年10月、同プロジェクトがリリース ● 2つのサイトのフロントエンドが同じコードベースを 見るように ○ 環境変数や設定ファイルによって内部のロジック、 UIなどが変わるようにしている

リニューアル時（～2021/10） Tailwind CSSで一休.com、Yahoo!トラベルのスタ イルを透過的に扱えるように ● 色やスペース、タイポグラフィの定義 ● Tailwind CSSのテーマ機能で一休 .com、 Yahoo!トラベルのスタイルを切り替えられる ように ○ 同じクラス名を設定しても一休用のスタイル、 Yahoo!トラベル用のスタイルとなる 一休.com Yahoo!トラベル 環境変数で切り替え 同じHTML、クラス名でも別のスタイルとなる 例:class="bg-brand-gradient-p"を当てるとサイトごとの背景色に

リニューアル時（～2021/10） ● Tailwind CSSを駆使して同じコンポーネントと できるものは同一のコンポーネントに ● Tailwind CSSで対応できないものは別コン ポーネントに ○ レイアウトや表示ロジックが違うものはTailwind CSSのみでは難しい 例：施設カードはレイアウトなどが異なる Accommodation.ikyu.vue Accommodation.yahoo.vue

何が問題になっている？ ● トンマナの定義から外れるものが出てきた ● 車輪の再発明 ● 一休.com/Yahoo!トラベル間での二重実装、コピペ問題

車輪の再発明 ボタン、スライダー、施設カード等 小さい単位でコンポーネント化されたものとされていないものがあった コンポーネント化されていないものは両サイト間でも同一サイト内でも毎回同じような HTML、CSSを書いていた

二重実装、コピペ問題 一休/Yahoo!、PC/スマホで二重実装が行われている 例えば検索ページの周辺エリアコンポーネントの 337行のうち、差分は4行 このコンポーネントに仕様変更があった場合は両方編集 する必要がある 一休.com Yahoo!トラベル

どうしてこうなった？ ● スケジュールの問題 ○ 大規模プロジェクトでありながら半年という短いスケジュールでコピペが常態化 ● リリース後に改善をすべきだった ○ 一時的に作ったコードでもそのままにしておくと、そのコードを参考に実装されるものが出てきて増 殖していく ○ しっかり方針を決めて対応をすべきだった →改善だ！2021年11月にデザインシステムチームの発足

そんな問題にデザインシステム 標準の定義があるわけではないが ● デザインガイドライン ● デザインパターンライブラリ ● コンポーネントライブラリ（実装） からなるものが多い デザインシステムの手法を取り入れることでトンマ ナの統一、再利用性の向上を期待 Design Systems―デジタルプロダクトのためのデザインシステム実践ガイド https://www.borndigital.co.jp/book/11908.html

本当にデザインシステムが問題を解決してくれるのか デザインシステムがいいらしいという話は聞くことが多くなった しかし、それが僕らにとって適したものなのか 内部ではデザインシステムに明るいものはいなかった そのためデザインシステムについて詳しい外部の方にお願いをして、デザインシステムの理解度を上げた（今も お世話になっています）

本当にデザインシステムが問題を解決してくれるのか チームで議論 一休では以下をでデザインシステムとして作成することで、問題を解決できるだろうと判 断 ● デザインガイドライン（トンマナの洗い出し） ● デザインパターンライブラリ（コンポーネントの洗い出し） ● コンポーネントライブラリ（コンポーネントのコード化）

デザインシステムの構築

やったこと 初期構築 ● Figmaの導入 ● トンマナの洗い出し ● コンポーネントの洗い出し ● コンポーネントのコード化 初期構築後はデザインシステムの改善サイクルを回す

Figmaの導入 XDからFigmaへの移行 既存のデザインデータの移行は行わず一から作成 Figmaのメリット ● 各コンポーネントの情報が分かりやすい ○ スペース ○ タイポグラフィ ○ 色 ○ 関連コンポーネント ○ CSS ● Auto Layoutが使いやすい ● 共同編集がしやすい ● デザインシステムの事例が豊富

トンマナの洗い出し 色、タイポグラフィ、線、スペースを定義 どういうときに使うものなのかを言語化 このとき、一休/Yahoo!トラベルで違うものとな る場合はその対比を明示

コンポーネントの洗い出し UI上ひとまとまりとなる単位で洗い出し コンポーネントも一休/Yahoo!トラベルで差異があれば対比となるように

コンポーネントのコード化 Storybookでカタログ作成 TailwindCSSのテーマ機能を活用して 一休/Yahoo!トラベルの見た目の変化を 表現

初期構築後のワークフロー Figmaでページ作成 Nuxtのアプリケーションコードに組み 込み Figmaで実装したコンポーネントを Storybookに実装 ページ作成時は Figmaのコンポーネントを使用 該当するコンポーネントが存在しない場合はガイ ドラインの策定、コンポーネント作成から Figmaでコンポーネント作成

問題は解決したか 小さいコンポーネントは解決してきた ● ボタン、チェックボックス、チップス、スライダー、 etc… ● TailwindCSSで吸収できるものはうまくいった ● ガイドラインを参照することと、用意されたコンポーネントを使うことによって、トンマナの統一、車輪の再 発明は避けられるようになった

問題は解決したか 大きいコンポーネントはまだ課題あり ● 施設カード、検索UI、etc… ● レイアウトの違いや表示ロジックの違いはうまく吸収できていない ● デザインシステムより大きな単位で改善を行うフロントエンド改善チームを発足して対応開始

これから ● デザインシステムの適用範囲を広めていく ● 認知拡大 ● もっと大きなコンポーネントの改善

ご清聴ありがとうございました