istyleにおける Atomic Design利用の現状と課題

下記イベントで登壇した資料です。
https://roppongi-designers.connpass.com/event/98120/

Transcript

1. istyleにおける Atomic Design 利用の現状と課題 2018/10/18@Designer X Engineer Development #01 Miho Takeuchi Kanami Hosoe Kohei Takata
2. 自己紹介 高田 孝平 エンジニア メディア開発統括部 細江 佳菜美 デザイナー デザイン部 竹内 美帆 フロントエンドエンジニア デザイン部
3. Atomic Design 導入までの経緯
4. • WEB開発はphpがメイン • HTML、CSS、JS、phpがくっついていて、密結合になってしまっている • 一部（ナビゲーション部分とか、ボタンとか）をコンポーネントとして切り出したものは あり istyleではどんな開発をしているの？
5. 役割について エンジニア Vue.jsのAPIつなぎ 複雑なscript サーバーの準備 デザイナー UI設計 ビジュアルデザイン フロントエンド Vue.jsのUIに関するtemplate style script • フロントエンドも「エンジニア」が付くが、エンジニアと区別するため以降は「エンジニア」を割愛 • 部署や人によって若干前後する場合はあるが、大方こんなかんじ
6. 今回の事例 新規の画面作成 完全新規の画面なので、 他に影響されるものが 無かった Nuxt.js(Vue.js) 新しい技術を使ってみよう という流れがあった 時間 新しい事にチャレンジ できる余裕があった デザイン デザインは先に ほぼ完成していた
7. • 今までの案件には「基準」が無かった • 作業を分担したこと、作業順の前後により、お互いが良い設計が共有できなかった →コミュニケーションが十分でなかった • 認識が合っていれば、エンジニア→フロントエンドだけではなく、フロントエンド→エ ンジニアもできるはず • 皆が設計の指針の認識を合わせられる手法として、Atomic Designを使用 Atomic Design導入までの経緯
8. Atomic Design とは？
9. 小さいUIコンポーネントを組みあわせて、 より大きなコンポーネントを作っていくための デザインフレームワーク ページ単位でデザインしていくのではなく コンポーネントを組み合わせてページを デザインする デザインフレームワーク
10. 簡単に例えると「部品」。 Atomic Designは、部品ごとに検品して、製品を組み合わせて完成させる家などと一緒 の考え方で作られている。 コンポーネントって？
11. Atoms （原子） これ以上分けられない最小単位 それ単体だと意味はない ボタン、アイコン、テキスト、 フォーム Molecules （分子） Atomsを組み合わせたもの ユーザーが何かアクションできる意味のあるもの 検索フォーム、削除ボタン Organisms （組織） Molecules、Atoms、他のOrganismsを組み合わせたもの 複雑なまとまりになる ヘッダー、フッター、パン屑、〇〇 アイテム、〇〇一覧 Templates （テンプレート） 画面のテンプレート 実際のデータは入っていない仮の状態 トップテンプレート Pages （ページ） Templatesに実際のデータが入ったページ 実際のデータが入った状態（APIにつなぐ） トップページ
12. デザインから見る Atomic Design
13. 04 03 02 ページデザイン作成 デザインからフロントエンドへ渡すまでの流れ 完成したデザインをコンポーネント単位で分解 ２を持ち寄り、デザイナー・フロントエンド・エンジニア全員で、 コンポーネントの単位の認識を合わせる コンポーネントの名前を決める 01
14. Pages 完成したデザインをコンポーネント単位で分解 Templates Organisms Molecules Atoms
15. • ボタンとボタン風リンク • ラベルをテキストにするか 意味をつけてラベルにするか • 数字をテキストにするか 意味をつけてカウントにするか Atomsを決めるときに難しかったこと BUTTON BUTTON <button> <a href=””> ラベル　メインテキスト ラベル　メインテキスト 1,234
16. • 担当によって、コンポーネントを切りたい箇所が違う ◦ デザイナー・フロントエンド：見た目や体験で揃えたい ◦ エンジニア：機能で揃えたい エンジニアと認識を合わせる 同じ要素のAとB 見た目が違うから ２つに分けたい デザイナー フロントエンド 中身が同じだから 1つにまとめたい エンジニア
17. 開発から見る Atomic Design
18. • atomsから上層に向かって開発する ◦ Atomic Designがコンポーネントから大きく考えていく手法だから、開発の流れもAtomsから開発・テストして積み上げ ていく形に • atomsは別開発環境で作り、すでにある共通で使っているコンポーネントなどからも 呼び出せるようにする ◦ また各サービスで独自コンポーネントはもつ ◦ もし共通で利用しそうだったら、別開発環境として外部化する 開発の進め方
19. • 他いろいろ記事を見ているが、サービス内でコンポーネントが完結しているものが多く、いろんなサービス共通でコン ポーネント開発してるパターンは少ないかもしれない。 • 逆に前例がなく、何がベストプラクティスなのかが悩みどころ。。。 今まで… サービス共通コンポーネント(Vue.js) 各サービス開発環境 アクションボタン 共通ナビゲーション Atomic Designを追加導入 サービス共通 コンポーネント(Vue.js) 各サービス開発環境 Atoms (Vue.js) 各Atoms
20. Vue.jsでは、コンポーネントをtemplate、script、styleを 1つのvue拡張子ファイルとして作る機能がある ＝単一ファイルコンポーネント フロントエンドとエンジニアが同じファイルを 触ることになるので、どっちがどこまでどういう流れで 実装を進めるか検討した 単一ファイルコンポーネントの 開発について <template> <div class="sampleComponent"> {{ sample }} </div> </template> <script> 　export default { 　props: { 　sample: { 　type: Boolean, 　default: false, 　}, 　}, 　} </script> <style lang="scss"> .sampleComponent { color: #f00; } </style>
21. 今までの開発の仕方 実際の案件であった手法 メリット・デメリット フロントエンドが静的テンプレート作って、エンジニア 側に引き渡して、HTMLをエンジニアがviewに埋め込 む。（主にPHPベースのみ） フロントエンドとエンジニアが同時並行で作業できる が、最後viewの部分をエンジニアが再度埋め込むこ とになり二度手間。 エンジニアがviewでロジックなりすべて埋め込んだ状 態で、この後フロントエンドはHTMLとCSSなどを当て ていった。 （Vue.js、PHPベース両方） フロントエンドが、エンジニアがロジックなどすべて埋 め込むのを待つ必要があり、同時に作業することが できない。もしリソース空いていたらもったいない。
22. vueファイル内での作業分担 フロントエンド エンジニア モック 主にtemplateとstyle、script部分 UIに関するパターン ロジック データ受け取り、APIつなぎ込みなどのscript。 表示の出しわけに関するtemplateでの条件など。 エンジニアは先にAPI作ることが多いので、その間に templateとstyle部分を作成し、templateまでつなぎ 込みを行う。 必要によっては、エンジニアが入ってから、調整す る。 モックコンポーネントのロジックを実装。 時間が掛かりそうなコンポーネントは、モックコンポー ネントをまたず先に作業する。設計あるので、どこで切 るか分かっているのでスムーズ。 最後PagesにAPIつなぎ込みを行う。
23. Atomic Designという 設計の共通認識で解決!
24. 解決! 実際の案件であった手法 メリット・デメリット フロントエンドが静的テンプレート作って、エンジニア 側に引き渡して、ＨＴＭＬをエンジニアがviewに埋め込 む。 （主にPHPベースのみ） フロントエンドとエンジニアが同時並行で作業できる が、最後viewの部分をエンジニアが再度埋め込むこ とになる。 vueファイル内でtemplateとstyle作るので、 エンジニアがHTMLを解読して表示パターンを埋め込む必要なし！
25. 解決! 実際の案件であった手法 メリット・デメリット 他のあるサービスは、エンジニアがviewでロジックな りすべて埋め込んだ状態で、この後フロントエンドは HTMLとCSSなどを当てていった。 （Vue.js、PHPベース両方） フロントエンドが、エンジニアがロジックなどすべて埋 め込むのを待つ必要があり、同時に作業することが できない。もしリソース空いていたらもったいない。 vueファイル自体は同じファイルだが、うまくコミュニケーションをとり、フロントエンド も開発を前倒しすることができる！
26. • Atomsは基本「要素を表示するだけ に徹する」 • 導入予定のサービスで利用する Atomsだけ作りました • また他のサービスで利用し、かつ共 通で使えそうなものはどんどん Atomsとして定義する予定 Atomsの開発
27. 作成したAtoms コンポーネント名 役割 要素 概要 AtcosmeButton ボタン button要素 汎用ボタンを表示、Google AnalyticsひゃpreventDefaultのため「@click」イベントも返す AtcosmeCount カウント数 （フォロー数やLike数など） span要素 カウントの数字を表示、3桁ごとにカンマが付く AtcosmeHeading ヘディング hx要素 タイトルを表示、levelを設定したらそのhx要素になる AtcosmeIcon アイコン span要素 >svg要素 アイコンを表示 アイスタイルでは、アイコンは基本SVG要素で実装、インラインでHTML上に書き出す形式のため、画像とは別コンポーネント AtcosmeImage 画像 img要素 画像を表示、リソースURLを受け取りsrcにセット AtcosmeLink リンク a要素 リンクを表示、Google AnalyticsひゃpreventDefaultのため「@click」イベントも返す AtcosmeLinkButton 見た目ボタンのリンク a要素 スタイルはボタンと同じのリンクを表示、Google AnalyticsひゃpreventDefaultのため「@click」イベントも返す AtcosmeText テキスト span要素 汎用テキストを表示 AtcosmeTextError エラーテキスト span要素 エラーテキストを表示 AtcosmeTextSub サブテキスト span要素 サブテキストを表示
28. Atomsの実装の認識 基本 Atomsは基本タグを表示するだけで、ロジックは持たない。 ただし、headingの出しわけやcountのカンマつけるとかscriptは仕方ない。 （表示するに必要なものは OK） スタイル • アイスタイル共通として決まっているスタイルを持つ • 各サービスや共通コンポーネントでMoleculesからの上書き前提でclass設定やscopedなし • scopedなしについては、名前が一意であること、 scoped後からつけるほうが影 響範囲少ない • Atomコンポーネント自身の役割を超えたスタイルは付与しない • スタイルに関してはどんな画面でも大丈夫な指定にする。 • 例えば、横幅など固定値はつけない
29. • Atomはただ表示するだけってところが最初ロジックまで埋め込みたくなった。どこま で実装したらいいのかという部分に悩んで時間かかった • コンポーネント設計で途中で変更した ◦ 最初labelコンポーネントもあったが、textとの違いがないため廃止したり、いろいろ変更があった ◦ 見た目ボタンなんだけど、aタグで遷移というものがあり途中で追加 ◦ textも今も必要かどうか、色がcssではbaseで設定されているため、悩んでいる 悩み・苦労した点
30. • デフォルトの色は何か悩んだ ◦ UIガイドラインをまとめているデザインメンバーの方も巻き込んで、今決まってないけど将来的にこ んな感じかなというのを検討した ◦ 開発面だけではなくて、うまく連携してUIUX（デザインの統一性とか）にも貢献できたらなぁと思った 悩み・苦労した点
31. • Molecules～Pagesの開発に関して話せたらと思います ◦ テストのやり方 ◦ ESLintの明確な定義 ◦ storybookの使い方の定義 ◦ TypeScriptを使いたい ◦ Vue.js以外を使う場合どうするか ◦ etc 次回は…
32. 総括
33. • コンポーネントの切り方や中身の実装について、共通の基準が生まれた • デザインが統一されるため、UIのブレを防げる • storybookの仕様書化による描画確認ができた • インプットする→業務で使う→社外にアウトプットするの流れが作れた やってみて良かったこと
34. • 実装者に依存していた共通の基準が生まれた ◦ 今後汎用的に使える • templateの切り方の考え方を共有できた ◦ 今まで感じていたコンポーネントの切り方の不満などはなくなるのでは • 開発効率に貢献 ◦ モックが簡単に作れる コンポーネントの切り方や中身の実装について、 共通の基準が生まれた
35. デザインが統一されるため、UIのブレが防げる • 基準にするものが視覚化できる ◦ 今まで実際のサイトを見ながらトーンを統一していたものが、全体を通してどこを統一しているのか がすぐに分かるようになる • コンポーネント化されているので、仕様書を読み漁らなくていい ◦ デザインだけでなく、仕様の統一もできる
36. storybookの仕様書化による描画確認ができた • 表示の確認漏れによる事故を防げる ◦ アイスタイルの開発では表示パターンが多いものがあり、時々確認漏れが発生していたが、その事 故を防げるようになる • 仕様書の更新漏れによる事故を防げる ◦ 仕様が変更になった際の更新がうまくいっていない事も、確認漏れにつながっていた。 ◦ 実装時にstorybookも修正する決まりにしておけば、その事故を防げるようになる
37. • 新しい技術をインプットする動きができた ◦ 今後も続けていく • 社内でやっていることを外部に伝える活動ができた ◦ 今まで社外にアウトプットする活動をあまりやっていなかった。今回、新しいものをインプットして、そ れを業務で使って、さらに社外に公開するという流れができた インプットする→業務で使う→社外にアウトプットするの 流れが作れた
38. • デザイナーとしてどう開発に取り入れていったらいいか悩み中 • 分子（molecules）の呼び方問題 • コンポーネントの説明を書かないと、どういうコンポーネントがあってどういう挙動す るのかとか他の人が把握できなくなる 課題・苦労したこと
39. • Atomic Designだけでなくコンポーネント新規開発、VueCLI、storybook、Nuxt.js、、、 などいろんなものが初めて尽くしで大変だった • storybookのwebpackの設定が、今までgulpだったので移行が大変だった。Nuxt.jsと storybookそれぞれ別なので共通で取り込めるようにした 課題・苦労したこと（Atomic Design 以外で）
40. まとめ
41. • いろんな組織・サービス・PJTがある中で、 どうするのがベストプラクティスなのかまだ見つけられていない Atomic Designを取り入れるPJTや組織によってカスタマイズすべし Atomic Designを取り入れたことによって、デザイン・フロントエンド・エンジニア間 の共通言語ができた • まだAtomsまでではあるが、効率的な開発ができるようになったはず • 少なくとも今まで課題となっていたものは解決した • これからはMoleculesより上の開発があるのでまだまだメリットが でてくるはず！
42. 「こういうときはこうしたよ！」っていう情報を 共有できるとみんな幸せになると思い、 今回アイスタイルでの状況を共有させていただきました。 みなさんのコンポーネント開発の 情報を共有していただけると みんな幸せになれるので ぜひ共有をお願いします＞＜
43. ご清聴ありがとうございました！