技術本部 Strategic Products Engineering Unit Contract One Devグループの井上です。

Sansanに入社してから早いもので二年が経ちました。振り返ってみると、さまざまな経験を積むことができました。

入社当時と比較して、バックエンドとフロントエンド、どちらもContract Oneの開発効率が向上していると感じます。今回はフロントエンドに焦点を当て、現在の開発環境とこれまでの改善活動、そしてこれからの改善活動について紹介したいと思います。

なお、本記事は【Strategic Products Engineering Unitブログリレー】という連載記事のひとつです。
buildersbox.corp-sansan.com

現在の開発環境とこれまでの改善活動

ライブラリのバージョン

昨年、Reactのバージョンを18.2.0に引き上げました。以前はバージョンの低さが開発環境の改善のボトルネックとなっていましたが、ReactやNode.jsのバージョンを上げることで改善の動きが加速していきました。

ビルドツールにViteを採用

以前はビルドにCreate React Appを使用していましたが、ビルド時間や開発サーバーの起動時間、Hot Module Replacementの速度に課題感があったためViteに移行しました。

また、Viteへの移行に伴い、テストフレームワークもJestからVitestに移行しました。VitestはJestとほぼ同様にテストを記述できますが、テストの実行速度が格段に速いのが特徴です。

Mock Service Workerの導入

Contract Oneには、さまざまな手順を踏まないと表示されない画面もあり、そのような画面に手を入れるのは大変で手間もかかっていました。そこで、Mock Service Workerを用いて、モックを差し込んだ状態で簡単に画面が確認できるように改善しました。

Storybookの導入

リポジトリにコンポーネントの数が何百とあり、利用可能なコンポーネントはあるのか、何が利用可能なコンポーネントなのか、判断するのは容易ではありませんでした。
そこで、Storybookを導入し、コンポーネントのカタログを整備していきました。これにより、すでにコンポーネントがある場合には再利用し、重複したコンポーネントを作ってしまうことがなくなりました。

また、scaffdogを用いて、Storybookを簡単に生成できるような仕組みも導入しており、開発スピードにプラスの影響を及ぼしています。

そのほか

上記に挙げた以外にも、Stylelintを導入する・ESLintの設定を見直す、などの活動で少しずつ品質を上げていきました。

これからの改善活動

改善の進め方

技術改善は各開発メンバーによるボトムアップ形式の活動で進めています。期(クォーター)ごとに、互いに課題間を持ち寄り優先度をすりあわせた上、OKRに技術改善の項目を組みこんでいます。こうすることで、組織の方向性を統一し、異なるメンバーが1つの目標に向かうことができます。
ときには専門の改善チームが発足することもあり、メンバーはOKRにアラインする形で主体的に動いています。

VRTの導入

アプリが大きくなってくると、共通で参照しているコンポーネントのテストが大変になっていきます。1つのコンポーネントに手を加えたときに、さまざまな画面に影響がでますが、それをすべて手動で確認するのは非常に骨の折れる作業です。そこで、Visual Regression Testing（VRT）を導入する運びとなりました。VRTのサービスはChormaticを選択しました。

現在、各画面に対して画面全体をカバーするStoryを作成しているところです。それをChromaticのVRTの対象とすることで、予期せぬUIの変更を自動で検知し、コンポーネントに安心して手を加えることが可能になります。また、ChromaticにホスティングしたStorybookを実際にデザイナーさんに触ってもらうことで、デザインレビューの解像度が上がるという恩恵もあります。

ChromaticについてはBill Oneでも採用しており、次のSansan Tech Blog記事も秀逸なのでよろしければ併せてお読みください。

ライブラリのバージョンアップ

先述の通り、Contract Oneでは昨年ライブラリのバージョンアップを行いましたが、より高い頻度で継続的にバージョンアップができる体制を目指して取り組んでいます。
以前はテストが充実していなかったため、バージョンアップの際にはすべて手動で動作確認を行っていました。しかし、現在は徐々にテストも充実し、少ない工数でアップデートすることが可能になってきています。

バージョンが低いと、新しく追加された機能の恩恵を享受できず、開発効率にダメージを与えてしまいます。必要に迫られたときにアップデートする方法もありますが、それだとベロシティも安定しません。
そこで現在は、VRTと並行してRenovateの導入も進めており、今後は依存関係の更新をしっかりと開発サイクルに組み込んでいきます。

デザインシステムの開発と普及

最後に、現在Contract Oneで利用しているUIコンポーネントライブラリSemantic UI Reactの課題感と、それに代わるデザインシステムについて書きます。

Semantic UI Reactは、DOM構造に強く依存したスタイリングであり、スタイルの上書きには詳細度との戦いが必要です。ライブラリ自体が!importantを使用しているため、我々も随所で !importantを書かざるを得ません。これではスタイルの保守性が低く、Contract Oneで使用しているEmotionとも親和性が良くありません。

もちろんSemantic UI React自体は、コンポーネントの数や機能も豊富で、悪いライブラリではありません。しかし、上記に挙げた課題以外にも、アクセシビリティ・型安全性・テストのしやすさなどの面で課題があることは事実です。そこで、将来的にはSemantic UI Reactから脱却したいと考えています。

上記の理由で、最初はContract Oneの中でSemantic UIに代わる共通のUIコンポーネントを作っていました。しかし、開発を進めていくうちに他の部署も同じような課題感を持っていることがわかりました。
そこで、意見を擦り合わせていった結果、Bill One・Contract Oneが共同で改善していくことになりました。

現在、Oneの名がつくプロダクト群全体で共通して使えるものを目指して、デザインシステムの定義とUIコンポーネントライブラリの開発を進めています。

今後はVRTを活用しながら、Semantic UI Reactから社内共通のコンポーネントライブラリへの段階的な移行を進めていきます。