こんにちは。Wantedly で Frontend Chapter Lead をしている原 剛士(@chloe463)です。この記事では、Wantedly のフロントエンドが抱える課題とそれを解決するための戦略や方針について紹介します。先日開催された JSConf JP 2022 のスポンサーLTでざっくりと同じような話をしたのですが、5分という短い発表時間では伝えきれなかった詳細まで踏み込んで説明しようと思います。
Wantedly は10年以上運営しているサービスです。サービス開始当初は Ruby on Rails で作られたWebサービスでした。haml を使って HTML を記述し、jQuery を使って少し動きをつける、といったものでした。 振り返ってみると「Web ページ」と呼べるものだったと思います。
その後、時代の流れとともにWeb のフロントエンド部分を開発する技術スタックも進化してきました。JavaScript を使ったビューライブラリやフレームワークを使ったフロントエンド開発が世間的にも主流になってきたことを受け Wantedly でも 2015 年頃から React を使ったフロントエンド開発がスタートしています。React を使うようになったことで、Web ページから進化してもう少し複雑なことができるようになってきました。しかしながら Ruby on Rails とは強く結びついたままで、独立してテストしたりデプロイしたりということはできない状態でした。
大別すると下記のようになります。
それぞれの中は実はもっと細かい分類があるのですが、今回の本質ではないのでざっくり大きく2つに分けられのだ、という理解をしていただければと思います。
お察しの通り、このような状況においては様々な課題が存在します。次の節からは現在抱えている課題とそれを解決するための戦略などについて紹介します。
結論を先に提示すると、Wantedly のフロントエンドが目指すべき理想郷は現時点では下記のように定義できます。
前章で紹介したように Wantedly のフロントエンドは Ruby on Rails との結びつきが強い状態です。このような状態は、ユーザーに継続的に価値を提供していくソフトウェアデリバリーのパフォーマンスが低い状態です。Ruby on Rails と強く癒着していることにより具体的には下記のような問題があります。
そこでこのような状況を解決するため、3年ほど前から Ruby on Rails から分離した基盤での Web アプリ開発を始めています。初期は Create React App ベースでしたが昨年 Next.js に移行されました。また GraphQL が導入され、バックエンドシステムとの通信は GraphQL サーバーを経由するようになりました。
これにより、上記であげた Ruby on Rails と癒着していたことによる課題が解決されました。
新たに Ruby on Rails から分離された Web アプリが誕生したことにより、Wantedly のフロントエンドの技術は前節で紹介した2つと合わせて下記の3つに分類されることになります。
このように大きく3つに分かれる構成のうち、基本的には最新スタックの (c) Next.js 環境で開発していくことが今の Wantedly においてはベストの環境であると考えています。
現時点の React を Ruby on Rails の view の一部として使っている状態でも、技術的には React は使えているので「部分的な画面書き換えが頻繁に起こるような複雑な機能を作れる」ようにはなってはいますが「サービス価値の継続的な向上に繋がるような、高いパフォーマンスのソフトウェア・デリバリーの獲得」 は上記の理由であまり達成できていない、というのが問題という認識です。
継続的に高いパフォーマンスでのソフトウェアデリバリーを実現していくためには、やはり現状の Ruby on Rails と癒着した状況を脱し、独立した Web アプリを開発していく必要があると考えています。
よって、この章のはじめに書いたものの再掲ですが、Wantedly のフロントエンドが目指すべき理想郷は次のようになります。
次の章からはこの状況を解決するための戦略について紹介します。
上記までに、Wantedly のフロントエンドには色々な課題があることが紹介できたかと思います。もちろん、これまでにさまざまな箇所で小さく改善は行われてきました。それをいくつか紹介します。具体的には直近3年間で下記のような改善が行われました。
2020年〜2021年にかけて行われたフロントエンド刷新プロジェクトの一貫でスタイリングが css modules から styled-components に移行完了しました。React を使っている箇所において初期は css modules を使ってきましたが、直近は styled-components を採用しています。この移行によって、React 使用箇所においてはすべて styled-components が使われるようになりました。
その後も Developer eXperience Squad の取り組みにより、もともと JavaScript で書かれていた箇所が TypeScript 化されたり、haml 箇所で使用されていた CoffeeScript が JavaScript 化されたりしました。また、最新の Web アプリに関しても Create React App ベースだったコードベースを Next.js に移行しています。
このようにすべての地層において、漸進的に改善を重ねています。詳細は下記のブログをご参照ください。
前節までに、現状と理想郷の紹介をしました。では、理想郷にどう至るのかについて説明します。
理想郷と現在地のギャップを課題と捉えると、1つめの大きな課題は「Wantedly の多くの主要機能の多くが、未だ Ruby on Rails に残されていること」です。また Web アプリ化されたら完了というわけではありません。その上で生産性高く開発を行うために「デザインシステムやテスト基盤の整備すること」が必要となります。まとめると下記になります。
Ruby on Rails から分離した Web アプリでは、バックエンドシステムとの通信を GraphQL サーバーを介する必要があります。しかしながら現状 GraphQL のスキーマ定義はいまのところ部分的で、移行に必要なための機能がすべて整備されている状態ではありません。まずはここを整備していきます。
またこの整備により、Web アプリ開発だけではなく、Mobile アプリの開発へも大きな影響を与えると考えています。Wantedly Engineering Handbook にも記載がある全体のアーキテクチャ図にもある通り、Wantedly のアプリ (Web, iOS, Android) はバックエンドシステムとの通信に GraphQL を使うことを大きな方針としています。Web アプリへの移行のために GraphQL gateway が整備されることにより、副次的に Mobile アプリの GraphQL を使った開発が促進されることになり開発組織全体としてのメリットとなります。
https://docs.wantedly.dev/introduction/technical-overview
※ GraphQL Gateway についての詳細なドキュメントはこちら: GraphQL Gateway - アプリ向けにAPIを公開する
GraphQL gateway を整備しつつ、Ruby on Rails に載っている機能を段階的に Web アプリへと移行していきます。プロフィール機能をはじめ、すでにいくつかの機能は Web アプリへと移行しており、現在も機能移行のプロジェクトが進行中です。移行するべき機能はまだまだ残っているので一つずつ確実に移行していきます。
ここからは、独立した Web アプリに移行したあとでも生産性高い状態で開発を進めるための基盤改善ついて紹介します。前述のとおりいくつかの機能が Web アプリ化が完了しており、その移行に際していくつか基盤整備をしているため、まったくゼロというわけではありません。ただしそれでもいくか課題はあるため、改善のための取り組みを進める予定です。
ご存知の方もいるかもしれませんが、Wantedly ではデザインシステムの整備に力を入れています。デザインシステムとは単なる UI コンポーネントセットではなく、プロダクトの UI を構築する際の基本的な考え方です。デザインシステムについてはこちらの記事に詳しく解説があります。
Web (React) の実装整備ももちろん進めていますが、こちらも課題がないわけではありません。
過去数年に渡って、Wantedly デザインシステムの React 実装が試みられてきました。その過程でデザインシステムの React実装もいくつか世代が生まれてしまっています。
このようにデザインシステムの React 実装についても地層ができてしまっている状態です。また最新世代においても、いくつか足りていない (いまのところユースケースがないので用意していない) 状態です。フルパッケージとして整備し、旧世代からの移行がさらに促進されるようにしたいと考えています。
Developer eXperience squad の取り組みにより基盤が整備されて来ているものの、テストケースはいまだ少なくカバレッジも低いままです。堅牢な Web アプリにするためにできるところからコツコツやっていきたいと思います。
もともと Storybook と Storyshots を使ったテストはありましたが、あまりヒューマンフレンドリーではないこともあり、UI 崩れになかなか気づきづらい状況がありました。そこで Chromatic を使った Visual regression test (VRT) を導入しています。しかしこれも Storybook をしっかり整備しておかないと無用の長物になってしまいます。守っていきたい部分をしっかり Storybook として用意していつの間にか崩れている、ということがないようにしていきたいです。
もちろん VRT 以外にもコンポーネントのユニットテストや、E2E テストといったものも整えていきたいです。
以上をまとめると下記のようになるかと思います。
先述の通り、分離した Web アプリ上でもさらなる改善は行っていく予定です。しかしながら、再度まったく新しい基盤を作り、また地層が重なるという選択はしない方針です。マイナーバージョンが上がるような変更は戦略的に行っていく予定ですが、メジャーバージョンが上がるような破壊的な変更をアーキテクチャレベルで行うということはしません。
さいごに、Wantedly では上記課題を一緒に解決してくれるフロントエンドエンジニアを探しています。まずはカジュアル面談に来てください！Wantedly では転職意欲がなくてもカジュアル面談を実施しています。気軽な情報交換をしたいといったモチベーションでも構いません。是非お話しをしましょう！
そのほかレガシーフロントエンドの改善について知見共有したい、勉強会開催したいといった方いらっしゃいましたらお声がけください。
これからもシゴトでココロオドル人をふやすために改善を進めていきます！
/assets/images/7052304/original/49100b17-5866-4cec-b50b-a37ea73565e9?1638782149)
/assets/images/7052304/original/49100b17-5866-4cec-b50b-a37ea73565e9?1638782149)
/assets/images/11122077/original/ca49ffdb-4612-4648-8b59-05bb99e47336?1708915970)
/assets/images/7053725/original/28d1b135-13b4-4f46-895f-d5f5fb5ae243?1624246858)