今回はそのなかでお話しした、noteのデザインシステムの取り組みについて、内容を振り返りつつ、補足できるポイントも合わせてのまとめです。 イベント全体がまとまったレポートは、こちらの記事に書いていただいています👇🏻 デザインシステムを始めたきっかけとチームビルディングnoteでデザインシステムを始めたきっかけは、事業とサービスのスタートから年月が経ち、技術的・デザイン的な負債がたまって、開発にとってつらいポイントが増えてきたこと。デザインの一貫性のなさや、コードベースの複雑さと肥大化などが大きく課題になっていました。それに、マークアップやスタイリングを担当していたデザイナーの退職もあり、エンジニアがコーディングしやすい環境やツールが必要になりました。 現在は、ぼく（@uto-usui）が専任でUXエンジニアとして実装やデザインの相談事を、業務委託のデザイナーが専任でFigmaコンポーネ

今回はPlaywrightのスクショ撮影を、Storybookに登録したStoryにおこなって、ビジュアルリグレッションテスト（VRT）をPull Request（PR）に対して実行して、コメントとして変更を通知する話です。 はじめに新しい機能の追加や既存のコードのリファクタリングなど、開発の過程でUIに予期しない副作用が発生することがあります。VRTはそういった副作用のうち見た目上の変化を確認でき、自動化すると有用なブロッカーになります。 noteでは一部のプロジェクトにChromaticを導入してVRTを実施しています。Chromaticのインターフェースはわかりやすく多機能ですが、よりライトな形（コスト・運用面）で実装したいと思いました。そこで、StorybookとPlaywrightを使ってPR上で実施し、変更があればコメントとして投稿するようにしました。 （Chromaticは最