ファインディにおけるフロントエンド技術選定の歴史

by puku0x

Slide 1

Slide 1 text

ファインディにおけるフロントエンド技術選定の歴史 1 2026/01/13 フロントエンドの技術選定〜ピクシブ×ファインディの事例に学ぶ〜ファインディ株式会社フロントエンドテックリード新福宜侑 @puku0x

Slide 2

Slide 2 text

2 今年で９歳！転職サービスの「Findy」

Slide 3

Slide 3 text

3 Findyのフロントエンド ● Next.js + TypeScript + GraphQL ● Jest、Testing Library、Playwright ● Prettier、ESLint、Stylelint、Commitlint ● Storybook、Style Dictionary、Figma ● Nx（モノレポ管理ツール）、pnpm ● GitHub Actions ● GitHub Copilot、Claude Code

Slide 4

Slide 4 text

以前のフロントエンド構成 4

Slide 5

Slide 5 text

5 以前（〜2020年）のフロントエンド構成 ● Railsモノリス上のReact ○ React 16 ○ バージョンの古いツール‧ライブラリ多数 ○ クラスコンポーネント ○ 型（Flow）はある、テストは無い ○ スケールし⾟い設計、ディレクトリ構成、etc. .. ● モノリスのデメリット ○ 軽微な修正でも⻑時間のCI待ちが発⽣ → 開発スピード低下

Slide 6

Slide 6 text

6 1. 開発スピード

Slide 7

Slide 7 text

7 モノリス解体

Slide 8

Slide 8 text

8 解体後のフロントエンドはNext.jsを採⽤ https://nextjs.org/

Slide 9

Slide 9 text

9 Next.jsの採⽤理由 ● 既存のReactの資産を活かしたい ● 複雑な部分をフレームワークに任せて開発スピードを上げる ○ SSRの仕組み ○ ビルド設定 ○ パフォーマンス最適化

Slide 10

Slide 10 text

モノリス解体完了！（〜2021年5⽉） 10

Slide 11

Slide 11 text

11 GitHub上のアクティビティ数: 4倍リリース回数: 9.1倍 PRクローズまでの速度: 35倍 Findyがモノリス環境をやめて得られたユーザへの爆速価値提供 https://note.com/ma3tk/n/na502374b6ad6 モノリス解体の成果

Slide 12

Slide 12 text

モノリス解体でフロントエンドが最⾼になっ... 12

Slide 13

Slide 13 text

...てない！ 13

Slide 14

Slide 14 text

14 モノリス解体後のフロントエンドの課題 ● バージョンの古いツール‧ライブラリ多数 ● 型（Flow）はあるが、うまく動いていない ● テストが無い → 持続的な開発が困難

Slide 15

Slide 15 text

15 2. 持続的な開発

Slide 16

Slide 16 text

16 開発基盤の刷新

Slide 17

Slide 17 text

17 持続的に開発できる仕組みを整える ● 定期的なアップデートの⾃動化 ● ⾃動テストの拡充 ● 不要なパッケージの削除 ○ styled-components + classnames → Emotionに統⼀ ○ Redux関連 → @reduxjs/toolkit → に統⼀

Slide 18

Slide 18 text

18 開発基盤にNxを採⽤ https://nx.dev/

Slide 19

Slide 19 text

19 Nxの採⽤理由 ● 持続的な開発基盤 ○ ESLintやJestなどがすぐに使える ○ nx migrate による⾃動更新 ● 今後の⼤規模化に備える ○ nx aﬀected による変更検知 → CI⾼速化 ○ リモートキャッシュの活⽤で更に⾼速化できる

Slide 20

Slide 20 text

20 Flow → TypeScript に移⾏ Flowの型注釈を削除 ↓ TypeScript（allowJs: true） ↓ TypeScript（strict: true）

Slide 21

Slide 21 text

21 TypeScriptの採⽤理由 ● 型が欲しい ● JavaScriptからの移⾏のしやすさ ● エディタとの相性 ● 情報の豊富さ ● デファクトスタンダード

Slide 22

Slide 22 text

開発基盤の刷新でフロントエンドが最⾼になっ... 22

Slide 23

Slide 23 text

...てない！ 23

Slide 24

Slide 24 text

24 REST API → GraphQL ● パフォーマンスの課題を解決したい ○ 当時のREST APIはページに使うデータが全てレスポンスに含まれていた ● 型が欲しい ○ データ構造が⼀定でない場合もあり、⼿動での型付けが困難だった社内ツールに導⼊‧検証 ↓ プロダクトを⼀部GraphQL化 ↓ プロダクトを全GraphQL化 ↓ 他のプロダクトに展開 → GraphQLに移⾏

Slide 25

Slide 25 text

25 Emotion → CSS Modules ● App Router（React Server Components）の登場 ○ 新しいコンポーネント設計の模索 ○ ランタイム CSS-in-JS からの脱却が議論されるようになる ● さまざまな⽅法を検討し、CSS Modulesを採⽤ ○ チーム要件や将来的な他ライブラリへの移⾏も加味して ○ 2026年1⽉時点でほぼ移⾏完了 EmotionからCSS Modulesへの移⾏！React Server ComponentsのCSS対応 https://tech.ﬁndy.co.jp/entry/2024/09/09/090000

Slide 26

Slide 26 text

26 3. 常に繰り返す

Slide 27

Slide 27 text

27 現在のファインディのフロントエンド共通の技術スタック ※SSRの要件の有無により使い分けています ※

Slide 28

Slide 28 text

28 まとめ ● 技術選定のポイント 1. 開発スピード 2. 持続的な開発 3. 常に繰り返す ● リスペクトを持つ →「当時はそれが正解だった」 ● 新しく導⼊するもの →「⼩さくはじめる」

Slide 29

Slide 29 text

技術選定って⼤変😂 29

Slide 30

Slide 30 text

リスペクトを忘れずに😉 30

Slide 31

Slide 31 text

31 ツール選定といえば...

Slide 32

Slide 32 text

ツール選定のお供に 32 各種ツールの活⽤事例や、様々なサービスのインフラアーキテクチャなど実⽤的な情報を多数掲載 https://ﬁndy-tools.io/

Slide 33

Slide 33 text

We’re hiring! https://careers.ﬁndy.co.jp/ 33