こんにちは。モノタロウでECサイトの開発・運用を担当している平岡です。
モノタロウではECサイトのフロントエンド刷新に取り組んでおり、その内容をブログで共有したいと思います。よろしければ、関連記事もあわせてチェックしてみてください。
- Vue.js？React？フレームワーク選びの７つの選定基準、大規模ECサイトのフロント刷新プロジェクト
- モノタロウのフロントエンド刷新の取り組み①～大規模ECサイトのフロントエンドをドメイン単位で再設計した話
- モノタロウのフロントエンド刷新の取り組み②～工数34%削減を実現した刷新の効果
- モノタロウのフロントエンド刷新の取り組み④～BFF×GraphQL導入の狙いとスキーマ設計の試行錯誤
これまでの記事では、技術スタックのモダン化、ドメイン単位でのフロントエンド刷新を経て、開発生産性の向上を実現してきた経緯をご紹介しました。
現在のフロントエンドでは、Next.js（React）を用いており、Storybookでコンポーネント駆動開発を実践しています。この取り組みをさらに進め、複数のドメインにまたがるコンポーネントを共通UIライブラリとして切り出しました。
今回の記事では、約1年半にわたり取り組んできた共通UIライブラリの構築について、その背景、直面した課題と解決アプローチを紹介します。
なぜ共通化が必要だったのか
これまでのECサイトでは、デザイナー主導のスタイルガイドはあったものの、実装時にガイドから外れることが多く、サイト上に似たUIが複数存在していました。
この課題を象徴する例として、出荷目安アイコンの改修があります。このアイコンは多くのページで表示されているにもかかわらず、各ページ・各システムで実装が独立していたため、改修に9ヶ月もかかりました。
このような課題を解決するため、フロントエンド刷新に合わせて共通UIライブラリの構築に着手しました。
共通化への挑戦と課題
共通UIライブラリの構築にあたり、デザイナーとエンジニアで理想的なUIコンポーネントを一から設計しようとしたものの、すぐに2つの課題に直面しました。
1つ目は、バリエーションが多く、共通化の方針が定まらないことです。
「こんなUIもある」「あんなUIもある」と考慮すべきUIのパターンが増えていくだけでした。理想的なUIを一から定義するのか、既存のECサイトで使われているUIをベースに共通化するのか。結論が出ないまま、議論が繰り返されていました。
2つ目は、開発フローが確立されていないことです。
エンジニアはデザイナーのUI作成フローを把握しておらず、デザイナーも新しい技術スタックで何ができるかを理解していなかったため、双方が手探りの状態が続いていました。
当初は主要ページの刷新前に共通UIライブラリを完成させる予定でしたが、このままでは間に合わないと判断し、方針を大きく転換することにしました。
課題に対するアプローチ
1つ目の課題に対しては、全体を一度に設計するアプローチから切り替え、共通化の優先順位を決めることから始めました。
コードベースを理解しているエンジニアが、フロントエンド刷新対象のページで使われているUIを洗い出し、デザイナー合意の下でそれらのUIから優先的に整備していくこととしました。 このとき、共通化の基準を一律で定めるのではなく、スタイルガイドをベースにしつつ、既存コードのサイズ・アイコン・テキストなどのパターンを調べ、現実的な定義に落とし込むようにしました。
この進め方により、チーム間で「今何に取り組むべきか」という認識が揃い、優先度の高いコンポーネントから着実に進められるようになりました。
2つ目の課題に対しては、構造がシンプルなUIを題材に、共通化を小さく積み上げていくアプローチを取りました。
具体的には、エンジニアがStorybookでコンポーネントを実装し、デザイナーがデザインやアクセシビリティの観点でフィードバックを行い、それを受けてエンジニアが修正する、というサイクルを繰り返しました。 このサイクルを重ねることで、エンジニアとデザイナーそれぞれの役割が明確になり、開発フローが自然と定まっていきました。
デザイナーとの連携を支える仕組みづくり
役割分担を明確にし、共通化の基準も定まったことで開発は順調に進み始めました。しかし、共通UIライブラリを管理しているStorybookは、UIが更新されるたびにローカル環境で立ち上げる必要があり、デザイナーが気軽に確認できる状態ではありませんでした。
この課題を解決するにあたり参考にしたのが、社内のWebページ開発で活用されている、プルリクエスト（PR）ベースのPreview環境自動生成の仕組みです。
この仕組みをStorybookに応用し、GitHub ActionsとAWS S3を使ってPreview環境を構築しました。具体的には、PRにラベルをつけるとGitHub Actionsで自動ビルドされ、AWS S3にデプロイされます。デザイナーはPRに自動投稿されるプレビューURLにアクセスするだけで、ブラウザ上でStorybookを確認できるようになりました。
取り組みの成果
一連の取り組みにより、大きく2つの成果が得られました。
開発フローの改善
Preview環境の整備により、デザイナーが実装の早い段階からStorybookを確認してフィードバックを送り、エンジニアがすぐに修正を反映するという、デザイナーとエンジニアの双方向のやり取りが加速しました。その結果、実装からリリースまでのリードタイムが1週間から最短1日に短縮されています。また、Storybookのカタログはエンジニアとデザイナーの共通リファレンスとして定着し、コンポーネントの仕様に関する認識合わせもスムーズになりました。
UIの標準化と展開
ボタンやラベルなど、各ページで共通して利用されているUIをReactベースのコンポーネントとして標準化し、現在では約40個のコンポーネントをライブラリ化しています。刷新対象のページから順次導入しており、ライブラリを1箇所更新するだけで導入済みのページに一括反映できるようになりました。新規開発においても、コンポーネントを組み合わせることでスピーディに実装できるようになっています。
おわりに
この取り組みを通じて、共通UIライブラリの構築にはエンジニアとデザイナーのコミュニケーションを適切に設計することが重要だと実感しました。
もし同じようにUIが各ページに散在し、改修に時間がかかっているという課題を抱えているのであれば、まずは既存サイトで使われているUIを洗い出してみることをお勧めします。私たちも最初は理想的なUIを一から設計しようとして行き詰まりました。全てを一度に共通化しようとせず、アクセスの多いページから優先順位をつけて小さく着手してみてください。そうすれば、組織に合った役割分担やコミュニケーションの形が自然と見えてきます。
もし私たちの取り組みに興味をお持ちいただけましたら、カジュアル面談など気軽にお声掛けいただけるとうれしいです！
