こんにちは。PR TIMES の開発本部でフロントエンドエンジニアをしている鈴木雄大(@szkyudi)です。
2021年10月に2020年新卒の僕と2021年新卒の2人の計3人で企業ページのフロントエンドをレガシーなコードから React.js にリプレイスしたものをリリースしたので、そのお話をしようと思います。
企業ページがどういったページかについては下記の PR TIMES MAGAZINE の記事をご覧ください。
リプレイスに至った背景
リプレイス前の企業ページのフロントエンドの技術スタックは以下のようになっていました。
- jQuery
- JavaScript (ES5以前)
- JavaScript (ES6以降)
- Vue.js
- SCSS
このようにひとつのページの中でも複数の技術が混在していました。また、ディレクトリ構造や記述ルールも整備されていませんでした。
そのために、コードのキャッチアップが容易ではないことに加え、機能拡張にも想定よりも工数がかかってしまうという状態に陥っていました。
そこで、保守性と拡張性を高める目的で React.js を使って企業ページをリプレイスすることになりました。
リプレイス後のフロントエンド技術
リプレイス後に使用している主なフロントエンドの技術は下記のようになっています。
- React.js + TypeScript 環境で実装
- Emotion を使ったスタイリング
- Recoil を使った State 管理
- Jest と Cypress によるテスト環境
- ESLint と Prettier によるコードの整備
弊社で React.js を導入するのは初めてということもあり、使える技術に大きな制約はなかったので、今回のプロジェクトでは Emotion や Recoil といった最近注目されている強力なライブラリを選定しました。
また、メンバー同士で相談をしながら様々なライブラリの導入も検討しました。その中で一部で採用した技術は下記のようなものになっています。
- Reach UI を使ったコンポーネント実装
- Framer Motion を使ったアニメーション
- React Query を使ったデータフェッチ
どのようにリプレイスしたか
続いて、どのような方針でリプレイスを進めたかについて紹介したいと思います。
様々なルールの明確化
技術選定の他に、記述ルールやコンポーネント設計、ディレクトリ構成などを明確化しました。
一方で、曖昧でもいい部分はどこかというのも決めました。この背景として、まずは実装を完了してリリースするという目的があったことに加え、単一ページのリプレイスということもあり、初期段階では課題が見えづらい状態にあったからです。
具体的には下記のようなルールを設定しました。
- 関数コンポーネントで記述する
- 命名規則を統一する
- CSS は Emotion の The css Prop で記述する
- コンポーネントの粒度は気にしすぎない
他にも細かいルールはありましたが、時期尚早なルール決めを避け、メンバーと連携を取りつつ、適材適所でルールを定めていきました。
スキーマ駆動開発
また、今回はバックエンドも既存のテンプレートエンジンをほぼ捨ててAPIベースで新規実装することになったので、スキーマ駆動開発を行いました。
スキーマ駆動開発とは、 API のスキーマをあらかじめ定義して、そのスキーマを元にバックエンドとフロントエンドがそれぞれで開発をする開発手法です。
今回のプロジェクトでは、 OpenAPI を使ったスキーマ駆動開発を行いました。これにより、フロントエンドとバックエンドが分業することができたり、様々なことを自動化することができました。
実際に今回のプロジェクトで OpenAPI を使うことによって実現できたことは下記のようなことがあります。
- API ドキュメントの自動生成
- モックサーバーの起動
- TypeScript の型の自動生成
- フェッチ関数の自動生成
- API の自動テスト
これらの詳細については、同プロジェクトメンバーの柳さんがOpenAPIの活用についての記事を書いてくれています。
エンジニア主体のプロジェクト進行
リプレイスということもあり、仕様も固まっていて大きな仕様の変更もなかったので、エンジニアが主体となってプロジェクトを進行しました。
そこで、今回は下記のような手法でプロジェクトを進行しました。
必要なタスクを最初に洗い出す-
- プロジェクトの進捗を見える化する
- 各メンバーが自らタスクをピックして実装する
-
- 自分に合ったタスクに着手できる
- モチベーションのアップ
- 不足しているタスクや改善案は全員で起案する
-
- 仕様の漏れがなくなる
- 議論が活発になる
- 全員の知見をフルに活用できる
- 全員でコードレビューをする
-
- 全員がコードの全容を把握できる
- コードの不明点を誰に聞けばいいか明確になる
- エンジニアだけの定例を行う
-
- 技術的により深いレベルの議論ができる
- メンバーの技術レベルや思考がわかることによりコミュニケーションが円滑になる
これらのプロジェクト進行は自主性があるメンバーが揃ってないと難しい部分もありますが、この進行ができると大きな好循環が生まれると思います。
試験環境を使って細かくリプレイスする
コンポーネントの実装が完了したら、PR TIMES で導入している試験環境に小まめにリリースしました。小まめにリリースすることで、小さな単位で本番での動作確認ができるので、リリース時の確認項目が大幅に減り、リリース時に問題が発生する可能性を減らすことができました。
以前までは、大きな変更を加えるときはリリースの粒度も大きくなってしまい、バグを見落としがちな状況でしたが、この機能によりコンポーネント単位でリリースできたので、リリースのリスクを最小限に抑えることができました。
さらに、開発本部のメンバー以外でも PR TIMES の社員であれば試験環境を閲覧できる状態にあるので、開発本部以外からのフィードバックも受けることができ、その結果としていくつかのバグや仕様漏れを防ぐことができました。
リプレイス後に残された課題
よかった部分も多かったものの、いくつか課題もあります。今後の実装で解決していきたい課題も紹介したいと思います。
コンポーネント設計の改善
今回は1ページのリプレイスということもあり、流用されるコンポーネントが多くありませんでした。そのため、コンポーネント設計はそれほど厳格にせずに、ある程度曖昧さを残して実装をしていました。
今後コンポーネントが増えていくことが想定されるので、 Atomic Design などを参考にしながら、各コンポーネントの責務を明確化させ、より依存性を下げた拡張性の高いコンポーネント設計にしていきたいと思っています。
テスト環境の整備
Jest による Unit テストと Cypress による E2E テストを導入しているものの、それぞれの責務や実装方針を明確に定義しておらず曖昧なままテストコードを実装しているので、テストに関するルールや方針を定めていきたいと思っています。
これらの背景として、テストに関する知見が深いメンバーがいなかったことも原因の一つなので、今後は様々な人を巻き込んで、より効率的で意義のあるテストを実装していきたいと思っています。
まとめ
今回、 弊社として初めての React.js の導入やスキーマ駆動開発、フロントエンドのテスト、エンジニア主体のプロジェクト進行など、様々な新しいことに挑戦しました。
また、 React.js の導入をきっかけに今まで他の現場で React.js を扱ったことのある社員の方々から興味を持っていただいたり、知見を共有していただいたりしています。
新卒1年目と2年目のメンバーとして貴重な経験をさせていただきました。今回の企業ページのリプレイスを皮切りに、プロダクトとしても開発本部としても成長していけたらと思っていますので、これからもよろしくお願いいたします。
