Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

8847086af047cbf895ab3277b59529fe?s=128

ANDPAD inc

March 10, 2022
Tweet

More Decks by ANDPAD inc

Other Decks in Technology

Transcript

  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. ご清聴ありがとうございました☕