📕エンジニアとデザイナーで協力しながらStorybookを導入したよ

🎅はじめに

株式会社ビットキー Advent Calendar 2022・15日目の記事です！
担当はWorkspace&Experience事業部 プロダクトデザイナーの@Qtikimtnaです。
今日はエンジニアとデザイナーで協力しながらStorybookを導入したお話をします。

🎄背景と課題

📣コンポーネントの現状把握

まずお互いが感じている課題を出し合いました。

🌀デザイナーの気持ち

• Figmaで同じコンポーネントを使用してるのに、実装が微妙に違う
  • 上記ケースを指摘した際、その他の修正に比べクリティカルでない（機能は満たされてる）ので優先度は低く、修正が次回に持ちこされる場合がある
• Figmaにデザイン上のコンポーネントを作ってはいるが、実際に何がコンポーネント化されているか分からないので実装上の影響範囲がわからない

🌀エンジニアの気持ち

• そもそもコンポーネントを全部作るのが無理なので、都度各自で「補完」しながらコンポーネントを作っていた
  • 「補完」部分が各エンジニアに委ねられ、結果オリジナリティとなり、今コンポーネントが300くらいある。無尽蔵に存在してこれはやばい…！
• 実装時すでにコンポーネントとして存在するものなのかが分からない
  • 既存があるかわからないので、適宜判断してコンポーネント化している
  • 似てるものがあるけどこっちに寄せていいんだろうか？と迷う
  • 頻出コンポーネントをまとめた一覧のようなものが欲しいなぁ
• Figma上のコンポーネント名と、実装上のコンポーネント名が異なるため、パッと判断できない

🧙課題を解決するには？

〜課題を出し合った後〜
🙇‍♀️デザイナー「デザインコンポーネントの粒度をエンジニアと会話してなかったな…」
🙇‍♂️エンジニア「コンポーネントの粒度をどうする？の疑問もなかった…」
お互いの気持ちが見えたことにより、協力しながら解決していこう！となりました。

🌟やりたいこと

• デザイン上と実装上で、コンポーネントの命名を合わせることで、どんなコンポーネントを実装すればいいか？がパッとわかるようにしたい
• なるべくコンポーネントを使いまわして実装を効率化したい
• どんなコンポーネントがすでにあるのか？が可視化されていてほしい

🌟Storybookを導入する、で解決できそうか？？

• できそう！やってみよう

〜担当エンジニアが設計時に思いを馳せたポエム〜

フロントエンドにおけるコンポーネントの設計は未だにベストプラクティスがなく、QiitaやZennなどを見ても多種多様な実装例が出てくる。
「この構成にしておけば大丈夫」というようなものはなく、メンバーのフレームワークに対する理解や、UIデザイナーのパーソナリティを加味して変更している。1ページに対して1コンポーネントという”何もしていない設計”がベストになることも経験している。
観測できる限り“俺が考えた最強のアーキテクチャ”いわいる”俺俺設計”かUI Frameworkの機能だけで構成するかの両極端になりやすい。 チームでコンストラクトできる”我々設計”になるようアーキテクチャが進化していくものである。

🪄この導きにより今回のStorybookのルールを設定

🌟 同じような見た目の“見た目だけに責務を持つ”コンポーネントを作成しない
🌟 一つの機能要件に対してビジネスロジックを実装することと、UIの実装と機能分割できるようなチケットを作成できること

🎉実際にやったこと

🎨デザイナーがやったこと

• 現状整理
• Figma上にあるもの + 実装上にしかないものをエンジニアと一緒に洗い出す
• 他社事例調査
• 進め方、運用方法が現場目線で書いてある
• SmartHRの取り組み
• 更新体制の参考になりそう
• Storybook導入のメリット・デメリット
• どのコンポーネントを用意すべきか整理
• コンポーネントのラインナップと命名
• プロパティのラインナップと命名
• Figmaにコンポーネントを用意する
  

📝エンジニアがやったこと

• レベル分けの方針を決める
• コンポーネントのラインナップと命名
  • 感覚で作成してたコンポーネントを意味のあるコンポーネントに整理
• プロパティのラインナップと命名
• レベル分けする
• ファイルの移動と整理
• グルーピング
• presentation
  • ビジネスロジックが入っていないもの
  • ＝ 他の画面やサービスでも使いまわせるもの
  • 抽象化されたもの
• container
  • ビジネスロジックが入っているもの
  • ＝ 現サービスの特定の画面で表示する
  • 具体的なもの
• 実装上に用意する
• コンポーネント自体
• Storybookに表記

🎁導入してみてどう？ 現場の人に聞いてみた

🐰Kさん：課題を発起したエンジニア

• コンポーネントが共通してるので実装のスピードが上がった
• レビュー時に指摘あった場合、コンポーネントの見直しで済むので修正対応もスムーズになった
• 旧コンポーネントを新規コンポーネントに移行するのをどうしていくのか…（パワーかかりそう）
• メンバーでStorybookを触ったことがない人もいるので、このケースにはこれが作れますよ！的なオンボーディングがあってもいいかも

🦄Tさん：もりもりフロント対応してるエンジニア

• Storybookにある既存にコンポーネントに関して意思疎通のコストが減った
• 新規実装の場合、ビューの部分から着手しStorybook上でコミュニケーションを取ることで、デザインチェック⇄フィードバックのサイクルを迅速に行える
• コンポーネントから実装することで、どのような粒度にすると再利用性が高く柔軟なコンポーネントになるか、を意識するようになった(設計に対する意識レベルが向上した)
• Storybookの活用が浸透していないので、意識レベルではなく、開発のライフサイクル上に組み込んで推進する必要がある

🐱Yさん：Storybook担当エンジニア

• 今後きちんと使われてのか？フローが適しているのか…
• 無法地帯から秩序をもたせたところまでできた！が、目まぐるしく開発している環境で秩序を周知徹底していきたい！！今は育ててる最中です！

🐹Tさん：デザイナー

• デザインと実装が共通化してるので、確認がしやすくなりました！
• 導入の過程が見れたことで、デザイン側もコンポーネントの意識が強くなりました

🌈終わりに

🔔エンジニア側とデザイナー側で課題を出し合ったことにより、スタート時に目線が揃えられたことがとても良かったです。そしてチームを横断して協力しながら運用フローを整えていくことは、コミュニケーションが活発になり、相互理解が深まり、自分ごとに捉えられるようになる！とたくさんの学びが得られました。
👼前述にあったようにStorybookは育み中です！旧コンポーネントを新規コンポーネントに移行するのをどうしていくのか…開発のライフサイクルにどう組み込みか…などなど課題は残ってます。今後も自分ごとGo onできるように、協力しながら、試行錯誤していきたいと思います！

🎂🌟Special Thanks🌟🎂 @marikosato

〜〜明日16日の担当はWork & Experience Product所属の@hoshtさんです〜〜〜