カオナビデザインシステムのこれまでとこれから

Transcript

1. カオナビデザインシステム の これまでとこれから 株式会社カオナビ プロダクト本部 サービス開発部 別城慎治
2. 今日話すこと 1. これまでのカオナビデザインシステム 2. これからのカオナビデザインシステム ・カオナビデザインシステム構築経緯 ・構築〜運用までの話 ・これから取り組みたいこと ・カオナビデザインシステムが目指すもの ※ 以降カオナビデザインシステムは KDSと省略します
3. 自己紹介 ・フロントエンドエンジニア 別城 慎治(bekki shinji) @shinji_becky ページリニューアル案件やデザインシステム構築を経て現在は新 規機能開発などに携わっています ・趣味 アニメ、サッカー(最近は見る専門)、旅行 2019年11月入社
4. KDS構築の経緯は？ ?
5. KDS構築の経緯 KDS構築前(2~3年前)のコンポーネントの話 カオナビ本体のリポジトリに「共通コンポーネント」という形で存 在していた
6. AtomicDesign コンポーネントを 「Atoms」 「Molecules」 「Organisms」 「Pages」 の4つのディレクトリで構成
7. ・Atoms、Molecules、Organismsの分類判断 1. 運用の難しさ 存在していた課題 当時はまだ React を導入し始めたばかりで社内に React 開発のナレッジが蓄積されて おらず Atomic Design を取り入れるのは時期尚だった ・適切な設計
8. 2. UIの一貫性の欠如 存在していた課題 共通コンポーネントの実装フローにデザイナーチェックが存在し ていなかった テキストサイズが違うなどデザインと違うコンポーネントなどが存在していた
9. 3. 共通認識の持ちづらさ 存在していた課題 エンジニアだけではなくデザイナーにもAtomicDesignに準拠し てもらう必要があった
10. KDSの構築
11. KDSの構築 〜 デザイン・開発・リリースまでのフロー整備 〜
12. デザイン・開発・リリースまでのフロー整備 KDS専用のカンバンボードでチケット管理 デザイン変更やコンポーネント追加などはデザイナー主導で行うように整備 → エンジニア判断で変更を加えるとデザインとの整合性がとれなくなる
16. Figma カオナビではデザインツールにFigmaを採用 FigmaにKDSに必要な コンポーネントを洗い出してもらい、 スタイルガイドやUIパターンなどを定義 これを正としてエンジニアはコンポーネントを実装 していく
19. エンジニアレビュー デザイナーがFigma上で変更箇所の デザイン修正後、エンジニアにデザインをレビューす るフローを設けています ▪ 目的 エンジニアが実装する前に不明点はないか、デ ザインの一貫性が担保されているかなどをチェッ クするため
24. 実装後のStorybookレビュー 実装者はコンポーネントの修正(もしくは追加) 対応後、デザイナーにStorybook上で該当のコ ンポーネントレビューを依頼 ▪ 目的 ・Figmaのデザインと相違がないか ・パターンが網羅できているか をチェックする
26. KDSの新バージョンリリース バージョンアップの作業フローはざっくり３ Step
27. Step 1. リリースブランチをmasterマージ KDSの新バージョンリリース バージョンアップの作業フローはざっくり３ Step
28. Step 1. リリースブランチをmasterマージ Step 2. Tagの作成(リリースノート ) KDSの新バージョンリリース バージョンアップの作業フローはざっくり３ Step 作成したバージョニングガイドラインに準拠
29. Step 1. リリースブランチをmasterマージ Step 3. カオナビ本体のKDSバージョンアップ KDSの新バージョンリリース バージョンアップの作業フローはざっくり３ Step Step 2. Tagの作成(リリースノート ) 作成したバージョニングガイドラインに準拠
30. KDSの構築編 〜 技術スタックについて 〜
31. ・React + TypeScript ・styled-components ・Storybook ・Jest + React Testing Library ・REG SUIT ・Webpack ・GitLab 技術スタック
32. コンポーネントライブラリとしてのKDS ・GitLabのPackageRegistryを利用 KDS カオナビ本体 ・プライベートなnpmパッケージとして本体側で利用する
33. ディレクトリ構成
34. Storybook
35. REG SUIT
36. GitLab ブランチごとにStorybookを確認できるようにbuildジョブのアーティファクト からStorybook確認できるように整備
37. KDS構築の恩恵 ✅ 本体と切り離すことによる開発スピードの向上 ✅ デザイン・開発・リリースまでのフロー整備による作業効率化 ✅ 一貫性のあるUI/UX ✅ プロダクトブランディングの一部となる
38. KDSの運用
39. 構築に関してはチームで対応 運用体制 運用はチーム体制ではなく 自分 + テックリードを中心にフロントエンドメンバーで対応
40. 毎週火曜日に「KDSを考える会」を開催 課題の洗い出しや課題に対する対応をしています 運用体制
41. 運用改善例 - KDSの新バージョンリリース SlackのKDSチャンネルでリリースワークフローを作成 Step by Stepでリリース作業が行えるように仕組み化
42. 運用改善例 - リリースノートの自動投稿 以前はKDSのリリースを行った際にリリースしたことを Slackで共有するフローがあった PackgeRegistryのpublish後、リリースノートを自動投稿するように対応
43. KDSのこれから
44. これから取り組みたいこと ・アクセシビリティ対応 カオナビ 本体と共に考えなければなりませんが、 ガイドラインの策定・アクセシブルなコンポーネントを目指す ・エンジニアのデザイン体験 エンジニアがデザイナー目線を持ってKDSに向き合えるような取り組みをし ていきたい
45. KDSが目指すこと
46. 最後に
47. 最後に 技術的なことよりデザイナーとエンジニアがスムーズに作業を進めるための フローを作るところが難しい スムーズにいかないフローをどう仕組み化して円滑に回せるようにするかを 考えるのはとてもいい経験になっている
48. ご静聴ありがとうございました！