コンポーネント管理の失敗とこれからのやっていき💪

90f8b0a76f7dc881ae2e10aaf91c62d0?s=47 Kenya Hoshi
November 02, 2019

 コンポーネント管理の失敗とこれからのやっていき💪

デザインリテラシーヤバめな組織が理想のデザインプロセス、プロダクト開発プロセスを歩んでいくための第一歩です。果たしてPOLは「デザインに卓越した組織になれるのか?」にご期待ください

2019/11/02 FRONTEND CONFERENCE OSAKA 2019のLightning Talkで話した内容です。

90f8b0a76f7dc881ae2e10aaf91c62d0?s=128

Kenya Hoshi

November 02, 2019
Tweet

Transcript

  1. コンポーネント管理の失敗と これからのやっていき FRONTEND CONFERENCE OSAKA 2019 2. Nov. 2019 -

    Kenya Hoshimure (@yahooshiken)
  2. 自己紹介 株式会社POLというスタートアップで LabBaseというプロダクト開発を担当しています。 沼津高専 → 大阪大学 4年(休学中) 星牟禮 健也 @yahooshiken

  3. POLのプロダクト 産学連携を加速する 研究者データベース 研究を頑張る理系学生のための スカウト型就活・採用サービス

  4. デザインリテラシーが低い 自分たちの組織への 喝です エンジニアもデザイナーも協力して生きていこう、と思える きっかけになれば幸いです 今日お話すること

  5. UIコンポーネントとは? 突然ですが・・・

  6. UIコンポーネントとは? 同じパターンのUIを共通化して 再利用可能にしたもの。 デザインの統一と開発の効率化を図る

  7. 弊社の絶望的な現状

  8. 複数箇所で定義される 同一のコンポーネント

  9. 仕様の変更やメンバーへの周知に 耐えきれず、腐敗した Storybook

  10. デザイナーの意図通りに 使われないコンポーネント 同じデザインレビューを 複数回しないといけない 新機能追加の際に、 イチからデザインを作る必要 開発効率の低下 デザイナー工数の増大 放置されたテスト

  11. こんな光景、心当たりはありませんか? まさか弊社だけ?w

  12. 背景の共有 - LabBaseのこれまでの歩み

  13. これまで「リリースは大正義」で やってきたツケが回ってきた

  14. いち早くProduct Market Fitに達するべく スケーラブルなプロダクトを 提供するための組織と仕組みを考える というフェイズになってきた

  15. これからのやっていき宣言

  16. まずは、フロントエンドエンジニアもデザイナーも一緒になって考えました 1. 実際、どれくらいやばいのか? • 実際のプロダクションのアプリケーションをみんなで見てみる • コンポーネントの命名をデザイナー・エンジニア・個人間で合わせる 2. 実際、何をすればいいの? •

    Storybookの運用についてはSmartHRさんを参考に • デザイナーとエンジニアの関係についてはキッチハイクさんを参考に
  17. まずは、フロントエンドエンジニアもデザイナーも一緒になって考えました 1. 実際、どれくらいやばいのか? • 実際のプロダクションのアプリケーションをみんなで見てみる • コンポーネントの命名をデザイナー・エンジニア・個人間で合わせる 2. 実際、何をすればいいの? •

    Storybookの運用についてはSmartHRさんを参考に • デザイナーとエンジニアの関係についてはキッチハイクさんを参考に
  18. 課題意識の共有 実際にプロダクション環境で動いているアプリケーションのコンポーネントのス クリーンショットを見て、全員が現状のヤバさを知る

  19. 課題意識の共有 全員が同じコンポーネントを、同じ単語で認識しているか? • Button • Checkbox • Date picker •

    Radio button • Select • Slider • Switch • Breadcrumb • Drawer • Link • Menu • Tab • App Bar • Paper • Card • Expansion Panel • Progress • Dialog • Snackbar • Avatar • Badge • Chip • Divider • Icon • List • Table • Tooltip • Typography • Modal • Popover
  20. まずは、フロントエンドエンジニアもデザイナーも一緒になって考えました 1. 実際、どれくらいやばいのか? • 実際のプロダクションのアプリケーションをみんなで見てみる • コンポーネントの命名をデザイナー・エンジニア・個人間で合わせる 2. 実際、何をすればいいの? •

    Storybookの運用についてはSmartHRさんを参考に • デザイナーとエンジニアの関係についてはキッチハイクさんを参考に
  21. 理想状態の共有 SmartHRさんの取り組みが非常に参考になりました プロダクト間共通の React コンポーネントライブラリを運用する話 - SmartHR Tech Blog 目指すべき理想状態

    • Storybook + addon-docs • Unit Test • reg-suitでの画像回帰テスト • CIでビルド → ホスティング
  22. Storybook 5.2で使えるようになったaddon-docs MDX(markdown + JSX)の文法でドキュメントを記述できる

  23. (引用)reg-suitでの画像回帰テスト ピクセル単位でUIの差分が検出できる プロダクト間共通の React コンポーネントライブラリを運用する話 - SmartHR Tech Blog

  24. コンポーネント管理に対するチーム方針の決定 ✔Atomic Designは意識しない • 汎用的でない、繰り返されないコンポーネントは一旦無視 • 例えば、  は一個しか使われていない ✔運用可能なコンポーネント管理を • そもそもコンポーネントキットは腐りやすい

    • ワークフローを運用できなければ意味がないので、 できるだけエンジニア・デザイナーに負担がないように ✔対話を大切にする • 命名など、少しでも違和感を感じたらチームに共有する • 共通言語をつくる
  25. 実際は、まだ走り出したばかり。 果たしてデザインに強い チームになれるのか!? 乞うご期待!!!

  26. デザイナー・エンジニアの関係性に ついて考えるきっかけとなれば 嬉しいです ❤ 弊社もまだまだゴミカスなので、教えていただきたい・・・!

  27. Thanks!