😽

Chromaticを実務で運用してみた

2023/05/23に公開

TL;DR

Chromaticを実務運用してみて約半年が経ちました。
そろそろ知見も溜まってきたので備忘録がてら記事にしたいと思います。

簡単に説明すると、Chromaticいいよって話です。

なぜ導入したか

Chromatic導入以前はreg-suitを使用していました。

reg-suitがだめというわけではありません。
むしろreg-suitはVisual Regression Test(以降VRT)ツールとして、無料とは思えないほどのクオリティがあり、とても素晴らしいツールだと思います。
私も大変お世話になりました。

reg-suitをやめて、Chromaticを実務で運用したかった理由は以下の2点です。

  • ツール上でレビューを行いたかった
  • デザイン確認のフローをGitHubのCI Checksに密に組み込みたかった

reg-suitはなんらかのStorageにStorybookのスナップショットをあげ、それを確認します。
確認後はGitHubをApproveすることでreg-suitのCI Checksがグリーンになります。
指摘事項がある場合はGitHubのコメントで行うか、別途Slack等のコミュニケーションツールでやりとりをする必要があります。

Chromaticはツール上で、しかもUIに対して直接コメントできる点で、私が欲している要件を満たしていました。
commented-chromatic

これにより、デザイナーとの連携がより円滑で的確になりました。

また、デザイン確認のフローをより明確にワークフローに組み込みたい意図もありました。

CI TestsとCI ReviewがChromaticが提供するCIです。
Chromatic上でそれぞれApproveすると、CI Checksがグリーンになります。

それに加えてGitHubの Require branches to be up to date before merging にCI TestsとCI Reviewを設定することによって、PRにデザインレビューが必須になります。

reg-suitだと、エンジニアがPRをApproveすることでCI Checksがグリーンになってしまうので、デザイン確認を強制することはできませんでしたが、Chromaticを導入することによってデザイン確認のフローがより確実に行われるようになりました。
※Chromaticも、Self Approveを行えるため、厳密に強制することはできません

chromatic-ci

Chromaticを導入して感じた恩恵

まずVRTの恩恵として、やはりリグレッションに強いというのが大きな利点です。

これはreg-suitでも同様の恩恵を受けることができますが、UIの修正による影響範囲を特定しやすく、思わぬ影響に気づくことができます。
実際に共通箇所の修正を行った際に、思いもよらぬ部分に影響が出ていることに気づくことができて、リリース前にデザインバグを修正することができました。

また、リグレッションテストがあることによって、リファクタリングの心理的安全性がとても高い状態を保てており、リファクタリングの習慣が作れています。

もうひとつの恩恵としては、デザイナーのコンポーネント管理の意識の向上があります。

弊社ではデザインシステム(のようなもの)を運用しているのですが、FigmaとStorybookの連携に関して、デザイナーから積極的に提案があったり、Storybookの運用に関しても、デザイナーと連携して改善を行っています。
Chromaticを運用することによって、デザイナーがStorybookにも接する機会が増え、よりデザインとプロダクトをうまく連携させるためにUIコンポーネント管理を意識する習慣づくりができました。

Chromaticの運用で気をつける点

とても便利でいいとこづくめなChromaticですが、気をつける点もあります。

ひとつは料金面です。
Chromaticは様々なプランが存在しますが、基本的にはスナップショット単位で課金されます。
TurboSnapという差分のみをスナップショットとして計上する仕組みを用意してくれてはいますが、プロダクトの拡大によりStorybookのStory数が増えてくるにつれてスナップショットも増加していきます。
※TurboSnapはpackage.jsonの変更などプロダクト全体に関わる修正を検知するとフルでスナップショットを作成するため、ライブラリのアップデートなどでフルスナップが走ってしまいます。

予算が十二分に取れていない場合は、デザイナー確認が不要なStoryに関してはスナップショットを除外する設定をするなどの工夫が必要です。
それか、予算を取れるようにしっかりと交渉しましょう。

また前提として、デザイナーの理解と密な連携が運用には必要不可欠です。

所属組織や風土、プロダクトのフェーズなど、様々な要因を加味した上で必要であれば導入するようにしましょう。
運用するためには初期のコミュニケーション設計などのコストを多大に払う必要があるため、便利だから入れてみようと軽い気持ちで運用を初めて、後々使われないという悲しい状況にはならないように気をつけましょう。

まとめ

Chromaticを半年間運用してみましたが、結果として大満足しています。

それなりにコストは払いましたが、その分しっかりとペイできている実感もありますし、今後より運用を強化できる手応えも感じています。

今後は、よりデザインシステムを充実させ、StorybookとFigmaとの連携を強め再利用性の高いUIコンポーネントを構築していきたいと考えています。
そのためにChromaticをより使い倒していきたいなと思っています。

この記事を読んで導入してみたいなと思った方がいてくれたら幸いです。
一緒に楽しいChromaticライフを楽しみましょう。

ここまで読んでいただいてありがとうございました!

GitHubで編集を提案

Discussion

ログインするとコメントできます