2022/03/10(木) 開催 Frontend Talk 〜デザインシステム構築のリアルな裏側〜【hey｜note｜ANDPAD】 https://andpad.connpass.com/event/238368/ 小泉 佑太郎 イベント登壇資料
エンジニアがデザインシステム導入に取り組む際の落とし穴株式会社 アンドパッド開発本部 SWE 小泉佑太郎Frontend Talk 〜デザインシステム構築のリアルな裏側〜2022/03/10
View Slide
フロントエンドエンジニア / 開発部SWEykoizumi0903小泉佑太郎● 2019/06入社● 担当プロダクトは引合・粗利管理（実行予算・発注など）● 社内ではVue.js / Nuxt.js 専門● プライベートでは最近はNuxt 3推し自己紹介
建設・建築業に特化したクラウドサービスANDPADとは
アジェンダ1. ANDPADで「デザイン共通化プロジェクト」が必要になった理由2. デザイン共通化プロジェクトの落とし穴3. フロントエンドエンジニアとしてどうアプローチしているか4. まとめ
ANDPADで「デザイン共通化プロジェクト」が必要になった理由
サービスによって細かいデザインが異なる現在のANDPADのデザイン
①新しいサービスを次々に展開していくビジネスモデル②初期プロダクトと新規サービスの差異の積み重ねなぜデザインが共通化されていないのか？
ANDPADは建設業界特化のVertical SaaS1つの機能を継続的に成長させていくだけでなく、チームごとにほとんど別のサービスを並行して開発・展開している意思決定・開発効率アップのため、サービスごとに開発メンバーやリポジトリ・技術スタックが分かれている↓全社的なデザイン統一・変更のハードルが高い①新しいサービスを次々に展開していくビジネスモデル
超少人数開発、デザイナーどころかフロントエンドエンジニアもほとんどいない中でのリリース↓新サービスの開発に参画した FE・デザイナーは、よりよいものを目指して 既存のデザインを改良 してリリースする↓「これが正」と言えるデザインがどこにもない②初期プロダクトと新規サービスの差異の積み重ね※2021年の上半期で◯人採用した開発組織が実践する採用手法 より抜粋※2020年11月までのデータ
これらの問題を解決するため、デザインチーム主導で2020年の秋頃から本格的にスタート❏ プロダクト間の差異をなくし、ANDPADのサービスを迷わず使えるようにする❏ コンポーネント 化 することでデザイナー・エンジニア（フロント・アプリ）の工数を削減するデザイン共通化プロジェクト
これらの問題を解決するため、デザインチーム主導で2020年の秋頃から本格的にスタート❏ プロダクト間の差異をなくし、ANDPADのサービスを迷わず使えるようにする❏ コンポーネント 化 することでデザイナー・エンジニア（フロント・アプリ）の工数を削減するデザイン共通化プロジェクトそこから1年半経った現在も共通化はほとんど進まず
デザイン共通化プロジェクトの落とし穴
デザイナーチームでのデザインシステムの制作は比較的順調デザインルールやコンポーネント定義など、できた部分が進捗として見える状態↓フロントエンドエンジニアに、実際のプロダクトにどう反映していくかを相談するMTGを設定デザイン共通化プロジェクトで起きたこと
フロントエンドチームへの共有MTGで、次にどこから手を付けて良いか、懸念点・課題が続出● サービスを跨ぐ共通APIの権限制御/データ設計は？● 共通コンポーネントはVueとReactで2種類作る？● 一部のサービスにだけ存在する機能は落として良いのか？● 各チームごとに実装の工数をどう確保するのか？● デザイン変更のユーザーへの説明は？ etc…デザイン共通化プロジェクトで起きたこと
デザイン共通化プロジェクトの落とし穴全ての問題を一気に解決しようとしてしまう
デザイン共通化プロジェクトの落とし穴様々な要素が含まれているのに、曖昧になったままスタート→実際に進めようとした段階で、どこから手を付けて良いかわからなくなるデザインツール共通化デザイン共通化フロント実装共通化サーバー実装共通化担当者設定・工数確保プロダクト仕様共通化スケジュール・顧客説明
デザイン共通化は、他の横断的なPJよりもゴールやメリットがイメージしやすい- 全てのページのデザインが統一されていて- 簡単に新しいページやサービスを作ることができ- ユーザーも迷わず操作できる状態デザイン共通化プロジェクトの落とし穴→ 反対意見や疑問が出にくいので、 細部の仕様の言語化や、中間地点の設定をつい省略したくなる
フロントエンドエンジニアとしてどうアプローチしているか
①コンポーネント共通化ではなくCSS共通化に目標を変えた②小さいチームで進められる範囲に絞って進めた③新規プロダクトの実装時にセットで進めることにした実際に取ったアプローチ
フロントエンドエンジニア内でコンポーネント共通化の話をする際には、暗黙の了解として Bootstrapや Element UI 、SmartHR UI のようなUIコンポーネントをイメージしていた↓コンポーネント共通化を目指す場合、コンポーネントごとの細かい挙動や共通仕様・バリエーションがある程度まとまっていないと進めにくい＋ Vue・Reactのフレームワーク両対応していくのかという問題（将来的なメンテナンスコストの不安）①コンポーネント共通化ではなくCSS共通化
※自分がプライベートで Bulmaを使ってデザインしたサイトを、 HTML部分ほぼそのままで NuxtからNextに移植した経験があった （Vue TemplateからJSXに直すのはちょっと大変だった）①コンポーネント共通化ではなくCSS共通化デザイン共通化だけが目的であれば、CSSフレームワークでも十分なのでは？
CSSフレームワークをターゲットに切り替えるメリット❏ Vue、React、Svelteなどフレームワークを選ばずに使うことができる❏ 挙動ではなくデザインのみの共通実装に絞ることで、やること・やらないことの線引きを明確化❏ 利用するプロダクト側で自由にオーバーライドできる（デメリットにもなるが、移行措置としては有用）❏ 将来的にコンポーネント共通化を行う場合も使い回せる①コンポーネント共通化ではなくCSS共通化
まずはフロントエンド＋デザイナーだけで裁量を持って動ける範囲に絞り、意見の集約が必要な部分は、後で調整❏ サーバー側APIやプロダクト仕様を共通化しなくても使えるように作る（CSS・slot・propsなどを使って、 カスタマイズの幅をかなり広めに取る）❏ 全社的に適用するタイミングは一旦は決めない（共通デザインを導入する準備が整ってから、 適用タイミングを各チームのPM/PdMに判断してもらう）②小さいチームで進められる範囲に絞って進めた
※そもそも「共通コンポーネントの作成」そのものにいきなりリソースを割くのは難しい❏ 入ってきたばかりのメンバーはアサインしづらいが、キャリアの長いメンバーには製品開発をリードしてもらいたい❏ フロントエンドエンジニアがチームごとに数名なので、デザインシステム専任に移動させると元のチームへの負担が大きい③新規プロダクトの実装時にセットで進めることにした
新規ページの実装時に、デザインシステムに沿った実装を進めつつ、共通化予定のコンポーネントは別リポジトリに作って読み込むようにする❏ 通常のプロダクト開発のスケジュールを遅らせずに済む❏ 既存のユーザーへの影響が最小限になる❏ あくまでプロダクト開発の一部なので、チーム内の調整のみでスタートできる③新規プロダクトの実装時にセットで進めることにした
2021年末からWebフロントの実装がスタート、2022年2月に共通CSSが導入された新規ページが本番公開同じサービス内の既存ページや、他のサービスへの展開についても検討中ANDPADにおけるデザイン共通化の現在地ようやくスタートラインに立てた状態
まとめ
【フロントエンドエンジニアとしての学び】● 「デザイン共通化」というと最初からUIコンポーネントライブラリの作成を目指したくなるが、「コードを共通化しないデザイン統一」もユーザー視点では変わらないので、目標をどこに置くか決める● 間を取って「CSSのみの共通化」という選択肢もあるまとめ【組織の一員としての学び】● 横断的なプロジェクトでは、多少遠回りであっても細かいタスクに分割して地道に進めていくことも必要● とりあえず動いてみないと見えない課題がたくさんある
ご清聴ありがとうございました☕
andpad
mamohacy
ahana
miyatakoji
sakaik
harukasakihara
nenonaninu
megabitsenmzq
oogfranz
chiroruxx
oracle4engineer
k1low
eliasnogueira
bkeepers
scottboms
mza
bluesmoon
aki_iinuma
holman
sugarenia
jponch
mongodb
michaelherold
roundedbygravity
hatefulcrawdad