📝

【フロントエンドエンジニア0人スタート】組織におけるライブラリ選定と移行理由〜さよならMUI〜

tsujiro

2023/12/25に公開

はじめに

はじめまして、損保ジャパンDX推進部の辻です。普段はフロントエンドでリードを担当させていただいています。
弊部は約3年前に生まれた新しい組織であり、積極的に内製開発の取り組みを行っています。そんな3年間という短い間でも、MUIを採用して乗り換えるという事象が発生しており、ライブラリ選定における失敗について振り返っていきます。
組織におけるライブラリ採用の参考にしていただければと思います。

ライブラリ調査方法

ライブラリは基本的に以下の方法で調査していきますが、今回後述するのは以下では不足していたものとなります。

npm trendsでダウンロード数比較
githubのstar数比較
ライブラリが現在も更新されているか（update確認）
ググった際にドキュメントや使用記事が出やすいか
github検索でライブラリがどのように使われているか分かるか

組織の開発体制と特徴

まずライブラリ選定の前に、弊部の開発体制と特徴を紹介します。
弊部はプロジェクトごとにチームを組成し（当初はベンダー中心）、チームごとに独自のテクノロジーを使ってました。新しいものを試しながら、だんだんと組織内のデファクト・スタンダードが定まってきているという現状です。
また、弊部の特徴として、以下のようなグループで構成されています（エンジニア視点で大きく分割）。
プロジェクト参画の際も、ビジネスや商品に詳しい人とエンジニアが一緒のチームになってアジャイル開発に取り組みます（正確には、現場に近い別部署の方も一緒のチームとして参画します）。
アジャイル開発の特性上、仕様や欲しい機能が決まっていない状態で走り始め、欲しい機能が出たタイミングでライブラリを追加します。

ちなみにエンジニアの人数は段々増えてきて（2023年12月現在）18人程所属していますが、当初は10人もいませんでした。そして、当時フロントエンドエンジニアは不在で、私含めバックエンドを主とする人が多かったです。

Vue.jsかReact

私は設立後約1年経過後に組織へ加わりましたが、当時は内製とは別にVue.jsでプロジェクトが走っていました。
しかし、初の本格的な内製開発をするにあたり、リードエンジニアとフロントエンド担当の私がReactを多少触ったことがあり、Reactが採用されました。
今はReactを選択して良かったと思っています（組織内に学習意欲の高い人間が多く、技術進展も早く、習熟すればよりシンプルに書けるため）が、この点は組織や扱うプロジェクトを考慮してもっとよく考えるべきだったと思います。

現時点で改めて考えるなら、外注（所謂下請け）へ流すことが多くフロントエンドに慣れていないエンジニアの参画が多い場合はVue.jsの方が適していると思います。反対に、一から育てる余裕があったり、中途採用でフロントエンドエンジニア取りたいならReact一択かなと考えています。

テンプレート生成(+ビルドツール)

最初の開発では、以前までデファクト・スタンダードかつ利用経験があったことに加えて、公式提供ということでcreate-react-appを利用しました（当時すでにViteへ乗り換える人が多い印象でしたが、チャレンジを恐れて古く枯れた技術を採用する意識でした）。
2022年4月が最後のリリースのcreate-react-appを今から利用しようとは思いませんが（メンテナンスされておらず、依存関係で警告が出る）、当時も使ったことがあるからという安直な理由で使うべきでなかったです。また、create-react-appの場合はWebpackを内部採用しているという意識を持つべきでした。公式(Meta社)が作っているからと言って、中身を理解せずに魔法の呪文のまま始めると余計なタスクが発生することになります。create-react-appで作成したテンプレートでは、Webpackが内部に隠されていることで設定をカスタマイズしづらかったです。

さらに、理想的にはプロジェクト開始時（開始前）に絶対必要なライブラリ（ツール）周りについて、今後もメンテナンスされるかよく調査して採用すべきです。create-react-appに関しては現在も広く利用されているWebpackが組み込まれるだけなので、幸いにも乗り換えの大きな手間は発生しませんでした。今回は助かったものの、公式だからといってメンテナンスされ続けるとは限らず、仕事で扱うことを理由に古く枯れた技術を選択すると、本当に枯れて余計な乗り換えコストが発生することになります。
次のプロジェクトですぐにVite(Rollup)へ変えるなら、最初から調査・検証してテンプレートやビルドツールを統一しておけると良かったですね。

現在は公式のドキュメントからもcreate-react-app消えています

create-react-appを捨てるのをきっかけにViteを採用しています。採用理由は以下です。

簡単にテンプレートを生成できる
開発サーバが高速
広く実績もある（ドキュメントも豊富）
しばらくはメンテナンスされそう

一部Next.jsを利用しているプロジェクトではTurbopackもといWebpackを利用しています。

グローバルなState管理

Redux：弊部で扱うアプリケーションの規模（ページ数）は比較的小規模であり、大きなシステムに向くReduxは過剰でした。良い意味で使い古されており業務で採用されやすいのですが、上記理由から採用しませんでした。

Recoil：一生experimentalのまま変わらなそうです。公式(Meta社)ですが、すでにメンテナンスされていないように見えるため、採用できませんでした。未完の大器です！

Zustand：Reduxの不採用と同じ理由です。

Jotai：軽くて使いやすく、一部プロジェクトで利用しています。しかし、今後デファクト・スタンダードとなってメンテナンスが続くか分からず、現段階では本格的な採用は見送りました。

消去法的な結論として、リスクのないuseContextと（いずれにせよ利用する）TanStack Queryをストアとして使うのがベターと考えています。
以下の記事を参考にしています。

グローバルなstoreライブラリは戦国時代なため、新しいものに飛びつくと火傷する可能性があります。古く枯れきった（メンテナンスされない）ライブラリも駄目ですが、まだ将来が安定していないライブラリにも同様のリスクがあります。使いやすさ、アプリケーション規模、メンテナンスリスクを考慮して組織に適したライブラリを選定するのが良いと思います。また、どのライブラリを選んでも変更リスクはあるため、ラッパー作成でライブラリ変更を可能な限り吸収できるようにしておくのも大事ですね。

UIコンポーネントライブラリ

おまたせしました。タイトルにある通り、MUIを採用して開発しています。有名なUIコンポーネントライブラリかつドキュメントや事例も多く、今後もメンテナンスされることを見越して採用しました。MUIはマテリアルデザインが組み込まれており、特に何もしなくても統一感のあるデザインを生み出すことができました。

しかし、マテリアルデザインが最初から当たっていることが問題となってしまいました。弊部がデザイナーの採用に成功し、独自のデザインを作成することができるようになったためです。MUIもある程度カスタマイズはできますが、オリジナルのデザインを当てようと思うと、MUIのデザインを剥がす方が手間になってしまいます（デザインの制約も出てきてしまうため）。特にMUIはChakra UIやAnt Designと比較してもデザインが濃い印象です。
エンジニアの制約を押し付けてしまうと、多くのデザイナーさんはやりづらい（楽しさも半減）ので、その観点からも自由にデザインを当てられる方が健全だと思います。

そこで、候補となるのがヘッドレスUIコンポーネントです。最近の多くのUIコンポーネントライブラリはこの流れですね。
候補としたのは以下のライブラリでした。理想としては今後もメンテナンスされるであろうMUIのBase UIを使えると良かったですが、MUIのBase UIの正式提供はv6からです。Headless UIは提供機能が足りません。独自のデザインコンポーネントを作成していくとなると、消去法的にRadix UIが良いと思います。

Radix UIは各機能ごとにライブラリの提供が分かれているため、必要な機能だけインストールできるのも良いところです。まだMUIをすべて外すことはできていないため、部分的に置き換えていくのに適しています。

ちなみにRadix UIをもとにTailwind CSSでスタイルを当てたshadcn/uiがありますが、より柔軟にできるのでRadix UIをひとまず使っていきます。

組織で新しくフロントエンドに取り組む際、気をつけた方が良いことまとめ

業務で安心してライブラリを使いたいという理由で、公式という権威を信用しすぎない
人気やドキュメントが多いかだけでなく、組織に適しているか考慮してライブラリ選定する
独自のデザインを作成する場合、ヘッドレスUIコンポーネントライブラリの利用が望ましい

損害保険ジャパン　DX推進部Publication

損害保険ジャパン株式会社　DX推進部によるテックブログです。