エンジニアがデザインシステム導入に取り組む際の落とし穴

2022/03/10(木) 開催
Frontend Talk 〜デザインシステム構築のリアルな裏側〜【hey｜note｜ANDPAD】
https://andpad.connpass.com/event/238368/
小泉 佑太郎 イベント登壇資料

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