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

by ANDPAD inc

Slide 1

Slide 1 text

エンジニアがデザインシステム導入に取り組む際の落とし穴株式会社アンドパッド開発本部 SWE 小泉佑太郎 Frontend Talk 〜デザインシステム構築のリアルな裏側〜 2022/03/10

Slide 2

Slide 2 text

フロントエンドエンジニア / 開発部SWE ykoizumi0903 小泉佑太郎 ● 2019/06入社 ● 担当プロダクトは引合・粗利管理（実行予算・発注など） ● 社内ではVue.js / Nuxt.js 専門 ● プライベートでは最近はNuxt 3推し自己紹介

Slide 3

Slide 3 text

建設・建築業に特化したクラウドサービス ANDPADとは

Slide 4

Slide 4 text

アジェンダ 1. ANDPADで「デザイン共通化プロジェクト」が必要になった理由 2. デザイン共通化プロジェクトの落とし穴 3. フロントエンドエンジニアとしてどうアプローチしているか 4. まとめ

Slide 5

Slide 5 text

ANDPADで「デザイン共通化プロジェクト」が必要になった理由

Slide 6

Slide 6 text

サービスによって細かいデザインが異なる現在のANDPADのデザイン

Slide 7

Slide 7 text

①新しいサービスを次々に展開していくビジネスモデル ②初期プロダクトと新規サービスの差異の積み重ねなぜデザインが共通化されていないのか？

Slide 8

Slide 8 text

ANDPADは建設業界特化のVertical SaaS 1つの機能を継続的に成長させていくだけでなく、チームごとにほとんど別のサービスを並行して開発・展開している意思決定・開発効率アップのため、サービスごとに開発メンバーやリポジトリ・技術スタックが分かれている ↓ 全社的なデザイン統一・変更のハードルが高い ①新しいサービスを次々に展開していくビジネスモデル

Slide 9

Slide 9 text

超少人数開発、デザイナーどころかフロントエンドエンジニアもほとんどいない中でのリリース ↓ 新サービスの開発に参画した FE・デザイナーは、よりよいものを目指して既存のデザインを改良してリリースする ↓ 「これが正」と言えるデザインがどこにもない ②初期プロダクトと新規サービスの差異の積み重ね ※2021年の上半期で◯人採用した開発組織が実践する採用手法より抜粋 ※2020年11月までのデータ

Slide 10

Slide 10 text

これらの問題を解決するため、デザインチーム主導で2020年の秋頃から本格的にスタート ❏ プロダクト間の差異をなくし、ANDPADのサービスを迷わず使えるようにする ❏ コンポーネント化することでデザイナー・エンジニア（フロント・アプリ）の工数を削減するデザイン共通化プロジェクト

Slide 11

Slide 11 text

これらの問題を解決するため、デザインチーム主導で2020年の秋頃から本格的にスタート ❏ プロダクト間の差異をなくし、ANDPADのサービスを迷わず使えるようにする ❏ コンポーネント化することでデザイナー・エンジニア（フロント・アプリ）の工数を削減するデザイン共通化プロジェクトそこから1年半経った現在も共通化はほとんど進まず

Slide 12

Slide 12 text

デザイン共通化プロジェクトの落とし穴

Slide 13

Slide 13 text

デザイナーチームでのデザインシステムの制作は比較的順調デザインルールやコンポーネント定義など、できた部分が進捗として見える状態 ↓ フロントエンドエンジニアに、実際のプロダクトにどう反映していくかを相談するMTGを設定デザイン共通化プロジェクトで起きたこと

Slide 14

Slide 14 text

フロントエンドチームへの共有MTGで、次にどこから手を付けて良いか、懸念点・課題が続出 ● サービスを跨ぐ共通APIの権限制御/データ設計は？ ● 共通コンポーネントはVueとReactで2種類作る？ ● 一部のサービスにだけ存在する機能は落として良いのか？ ● 各チームごとに実装の工数をどう確保するのか？ ● デザイン変更のユーザーへの説明は？　etc… デザイン共通化プロジェクトで起きたこと

Slide 15

Slide 15 text

デザイン共通化プロジェクトの落とし穴全ての問題を一気に解決しようとしてしまう

Slide 16

Slide 16 text

デザイン共通化プロジェクトの落とし穴様々な要素が含まれているのに、曖昧になったままスタート →実際に進めようとした段階で、どこから手を付けて良いかわからなくなるデザインツール共通化デザイン共通化フロント実装共通化サーバー実装共通化担当者設定・工数確保プロダクト仕様共通化スケジュール・顧客説明

Slide 17

Slide 17 text

デザイン共通化は、他の横断的なPJよりもゴールやメリットがイメージしやすい - 全てのページのデザインが統一されていて - 簡単に新しいページやサービスを作ることができ - ユーザーも迷わず操作できる状態デザイン共通化プロジェクトの落とし穴 → 反対意見や疑問が出にくいので、　細部の仕様の言語化や、中間地点の設定をつい省略したくなる

Slide 18

Slide 18 text

フロントエンドエンジニアとしてどうアプローチしているか

Slide 19

Slide 19 text

①コンポーネント共通化ではなくCSS共通化に目標を変えた ②小さいチームで進められる範囲に絞って進めた ③新規プロダクトの実装時にセットで進めることにした実際に取ったアプローチ

Slide 20

Slide 20 text

フロントエンドエンジニア内でコンポーネント共通化の話をする際には、暗黙の了解として Bootstrapや Element UI 、SmartHR UI のような UIコンポーネントをイメージしていた ↓ コンポーネント共通化を目指す場合、コンポーネントごとの細かい挙動や共通仕様・バリエーションがある程度まとまっていないと進めにくい＋ Vue・Reactのフレームワーク両対応していくのかという問題（将来的なメンテナンスコストの不安） ①コンポーネント共通化ではなくCSS共通化

Slide 21

Slide 21 text

※自分がプライベートで Bulmaを使ってデザインしたサイトを、　HTML部分ほぼそのままで NuxtからNextに移植した経験があった　（Vue TemplateからJSXに直すのはちょっと大変だった） ①コンポーネント共通化ではなくCSS共通化デザイン共通化だけが目的であれば、 CSSフレームワークでも十分なのでは？

Slide 22

Slide 22 text

CSSフレームワークをターゲットに切り替えるメリット ❏ Vue、React、Svelteなどフレームワークを選ばずに使うことができる ❏ 挙動ではなくデザインのみの共通実装に絞ることで、やること・やらないことの線引きを明確化 ❏ 利用するプロダクト側で自由にオーバーライドできる（デメリットにもなるが、移行措置としては有用） ❏ 将来的にコンポーネント共通化を行う場合も使い回せる ①コンポーネント共通化ではなくCSS共通化

Slide 23

Slide 23 text

まずはフロントエンド＋デザイナーだけで裁量を持って動ける範囲に絞り、意見の集約が必要な部分は、後で調整 ❏ サーバー側APIやプロダクト仕様を共通化しなくても使えるように作る（CSS・slot・propsなどを使って、　カスタマイズの幅をかなり広めに取る） ❏ 全社的に適用するタイミングは一旦は決めない（共通デザインを導入する準備が整ってから、　適用タイミングを各チームのPM/PdMに判断してもらう） ②小さいチームで進められる範囲に絞って進めた

Slide 24

Slide 24 text

※そもそも「共通コンポーネントの作成」そのものにいきなりリソースを割くのは難しい ❏ 入ってきたばかりのメンバーはアサインしづらいが、キャリアの長いメンバーには製品開発をリードしてもらいたい ❏ フロントエンドエンジニアがチームごとに数名なので、デザインシステム専任に移動させると元のチームへの負担が大きい ③新規プロダクトの実装時にセットで進めることにした

Slide 25

Slide 25 text

新規ページの実装時に、デザインシステムに沿った実装を進めつつ、共通化予定のコンポーネントは別リポジトリに作って読み込むようにする ❏ 通常のプロダクト開発のスケジュールを遅らせずに済む ❏ 既存のユーザーへの影響が最小限になる ❏ あくまでプロダクト開発の一部なので、チーム内の調整のみでスタートできる ③新規プロダクトの実装時にセットで進めることにした

Slide 26

Slide 26 text

2021年末からWebフロントの実装がスタート、 2022年2月に共通CSSが導入された新規ページが本番公開同じサービス内の既存ページや、他のサービスへの展開についても検討中 ANDPADにおけるデザイン共通化の現在地ようやくスタートラインに立てた状態

Slide 27

Slide 27 text

まとめ

Slide 28

Slide 28 text

【フロントエンドエンジニアとしての学び】 ● 「デザイン共通化」というと最初から UIコンポーネントライブラリの作成を目指したくなるが、「コードを共通化しないデザイン統一」もユーザー視点では変わらないので、目標をどこに置くか決める ● 間を取って「CSSのみの共通化」という選択肢もあるまとめ【組織の一員としての学び】 ● 横断的なプロジェクトでは、多少遠回りであっても細かいタスクに分割して地道に進めていくことも必要 ● とりあえず動いてみないと見えない課題がたくさんある

Slide 29

Slide 29 text

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