はじめまして、フロントエンドエンジニアの神長です。 普段はフロントエンド組織とMyシリーズのフロントエンド技術のリードをしています。
現在TalentXではMyシリーズの開発にあたり、ボタンや入力ボックスなど様々なコンポーネントをtalentx-uiというUIライブラリとしてStorybookで管理しています。 なぜそのような運用に至ったのかをご紹介していきます。
なぜUIライブラリを自社で作る必要があった？
2023年2月に複数のプロダクトをMyシリーズとして共通PF化した直後、それぞれのプロダクトをあたかも同じプロダクトのようにシームレスに行き来できるUXにするためにどのプロダクトも同じようなUIにデザインを統一していく方向性になっていきました。
しかし、プロダクトや画面によって担当するエンジニア・デザイナーが別ということもあり、見た目や振る舞いに微々たる差が生まれてしまうことが課題になってきました。
Figmaも実装もプロダクト共通で使うUIの管理ができていなかったのです。
全プロダクト共通でコンポーネント管理するためには
全プロダクトに反映させたいベースとなるデザインはあったため、それをまずは実装で共通化する方向になりました。 そこで、別のリポジトリで管理されている各プロダクトからimportできるようにnpmパッケージとしてUIライブラリを開発することになりました。
コンポーネントの設計
全プロダクト共通のコンポーネントとして、atomicデザインでいうAtoms, Moleculesの粒度のもの（ボタン、入力ボックスなど）に加え、ヘッダー、サイドメニューもライブラリに格納しています。
その設計においてもっとも重要と考えていたのが責務を限定的にすることです。
ライブラリに格納されるコンポーネントは、前提として複数プロダクトで再利用できることを前提にしていますが、あまりにもなんでもできるようにする（色、余白、サイズの変更）とシステムが崩壊するので、できること・振る舞いを限定的にすることにより不自由になりますが、保守性が向上すると考えます。
振る舞いを追加・変更する場合も、デザイナーと相談して共通認識を持って進めています。
npmパッケージ化
UIライブラリをnpmで管理するにあたって、まずは組織のメンバー以外installできないようにしたかったのでGitHub Packagesを採用しました。
PAT認証することで、組織のメンバー以外はinstallできないようになっています。
Storybookの導入
デザイナーと共通認識をもつために、実装上どれがコンポーネント化されていてどのような振る舞いをするかを可視化する必要がありました。 そこで役に立つのがStorybookです。
このようにパターンを全て明記しておき、誰が見てもそのコンポーネントの責務がわかるようにUIのテストとしてもドキュメントとしても運用できています。
chromaticというStorybookとの親和性の高いホスティングサービスを利用し、デプロイしています。
運用してみて
talentx-uiを触るフロントエンドメンバー全員で運用をしているなかで、UIライブラリ化して以下のよかった点がありました。
- 共通コンポーネントに更新が入る際に、talentx-uiの更新と、各プロダクトでパッケージのバージョンを上げるだけで済むようになった
- 新規プロダクトの開発の際に、新規にコンポーネントを作る必要がなくなった
- 新規参入者もどんなコンポーネントをどのように使ったらいいかわかりやすくなった
- デザイナーとのコンポーネント追加更新のすり合わせをtalentx-uiベースで会話できるようになり、コミュニュケーションコストが減った
- 細かなトンマナの揺れがなくなった
また、課題として各プロダクトでプロジェクトが進行しながら共通コンポーネントに変更が入る場合、該当プロダクトとtalentx-uiを同時進行で進めないといけないのでスピード感が落ちてしまうので、チームメンバーと一緒に議論を重ねて改善していく予定です。
今後の展望
全プロダクトのコンポーネント共通化という目的のために作成したtalentx-uiですが、実は技術的障壁があり導入できていないプロダクトも存在しています。 全てのプロダクトにtalentx-uiを導入して、Myシリーズの世界観をより強固にしていきたいです。
最後に
長文にも関わらずここまで読んでいただきありがとうございました。TalentXでは一緒に働く仲間を募集しております。 カジュアル面談も行っていますので気になる方はぜひご応募いただければ幸いです！
