フロントエンド未経験のSREエンジニアが挑んだ技術選定のリアル体験

こんにちは！株式会社ラクスの@kzak_24と申します。
インフラ開発部 SRE課に所属しております。

さて今回は、現在アサインされている新規システムの開発プロジェクトにて、フロントエンドの技術選定を担当した時の経験をまとめようと思います。

フロントエンドは未経験だった為、色々と試行錯誤を行いました。
未経験なりにどのような基準を設けて技術選定を行なったか、皆さまの意思決定の参考になれば幸いです。

目次

• SREチームの紹介
• 前提
  • チームの背景
• 検討内容と採用理由
  • 言語 / FW
  • 状態管理
  • スタイル
  • テスト
• まとめ
• 最後に

SREチームの紹介

まず始めに、少しだけSREチームについて紹介させてください。
ラクスのSREチームは2021年に発足した比較的新しい組織であり、下記の2つのチームに分かれています。

• BP(Business Platform)チーム
  • 社内業務システムの開発/保守/運用をメインに担当するチーム
• DevOpsチーム
  • プロダクトを横断した自動化や運用改善をメインに担当するチーム

現在BPチームは4名、DevOpsチーム1名で構成されています。
私はBPチームに所属しており、このチームで今回のプロジェクトをスタートさせました。

ラクスのSREチームにご興味ある方は、以下もご参考になさってください。
・SREエンジニア | エンジニア職種紹介 | 株式会社ラクス 中途採用
・Webアプリケーションエンジニア／Go, TypeScript | エンジニア職種紹介 | 株式会社ラクス 中途採用

前提

今回は、以下のような前提の元で技術選定を行いました。

• 新規システムとして過去の負債がないまっさらな状態から開発をスタートできる
• できるだけモダンな技術を使用する（社内のベンチマーク的な意味を込めて）
• 開発するアプリケーションは SPA（Single Page Application） の構成にする
• 一部ページでSSR（Server Side Rendering）が必要になる

チームの背景

• バックエンド専門メンバーのみで、フロントエンドの経験は乏しい
• モダンなフロントエンドの開発経験は、ほぼない

これらの前提を踏まえて、今回のプロジェクトにおけるフロントエンドの技術選定については、経験値の低さをカバーすることを重要視し、情報収集のしやすさや学習モチベーションの維持を含めた「学習コスト」を最優先することとしました。

また次点で以下の3点を優先することとしました。

• 社内の利用実績
• トレンド
• 保守性

※ 2022年 8月 24日 追記

SREチームでフロントエンドの技術選定をしている理由についてのコメントを頂いたので、SREチームの背景を交えて経緯について補足させていただきます。

SREチームの紹介に記載した通り、BPチームは社内向けの共通基盤の開発・運用を担当しており、アプリケーションエンジニアとしても活動しています。

SREにアプリケーションエンジニアがいる理由は、SREチームが新たなノウハウを各サービスへ展開することをミッションの1つとしている為です。

ラクスではサービスごとに開発チームが存在しており、技術導入なども各チームで判断していますが以下のような課題もあります。

• サービスの機能開発と並行稼働の為、導入が思うように進まない

そこで、SREチームが社内向けの共通基盤の開発・運用を通し、先行して新しい技術の調査・導入を行うことで、そのノウハウを各サービスに展開し、技術導入を推進するという動きをしています。

その際、以下のように役割分担しています。

• BPチーム：技術調査・導入
• DevOpsチーム：各サービスへの展開

こういった背景からアプリケーションの開発知識が必要になるので、SREチームにアプリケーションエンジニアが在籍しています。

今回ご紹介するフロントエンドの技術選定は、BPチームの技術調査・導入の活動についての事例となります。

チームの背景に記載した通り、バックエンド専門のメンバーのみだったので、フロントエンドはフロントエンド専門チームに任せるか？といった議論もありましたが、「過去事例に囚われず、フラットに検討すべき」という判断と「フロントエンドにもチャレンジしたい」という思いから、敢えて自分たちで担当することにしました。

検討内容と採用理由

今回は、以下4つを検討しました。

• 言語 / FW
• 状態管理
• スタイル
• テスト

言語 / FW

言語に関しては、近年デファクトスタンダードになりつつあることと、バックエンド専門で静的型付け言語に慣れているメンバーが多いということで、TypeScriptに決定しました。
また、FWは次の2つから検討しました。

• React
• Vue.js

検討にあたり、判断材料とする為に次のようなことを実施しました。

• フロントエンド専門チームへのヒアリング
• チュートリアルの実践

その結果、今回の選定方針をもとに以下のような比較をすることができました。

React

• Pros
  • JSX記法のメンバー受けがよく、学習モチベーションが保てそう
  • 関数コンポーネント主体で宣言的にかけるので、コードが読みやすく、保守性が高い
  • 直近でリリースした社内の他プロダクトで利用実績がある
• Cons
  • Vue.jsと比べると学習コストはやや高い
  • ドキュメントの充実度は低い

Vue.js

• Pros
  • 利用者が多く、情報が得られやすいので学習コストが低い
  • 日本語ドキュメントが多い
  • シンプルな設計で拡張性が高い
  • 社内での利用実績がReactより多い
• Cons
  • SFC記法のメンバー受けがよくなく、学習モチベーションは低い
  • 世界的なトレンドはReactに劣る

決定内容と理由

決定内容

Reactを採用する

理由

チーム内での評判がよく、モチベーション高く学習を続けていくことができると考えました。
また、保守性の高さやコンポーネントの再利用性もReactの方がチーム内での評価が良かったことも理由です。
Reactを採用するにあたり、SSRの実現の為にNext.jsも採用しました。

状態管理

状態管理に関しては、Reactを使用することを前提として代表的なライブラリである下記の3つから検討しました。

• Redux
• Recoil
• React Context

状態管理のライブラリについては、主に公式ドキュメントやWebの記事などから情報を収集し、比較検討を行いました。

Redux

Fluxベースの状態管理ライブラリです。

• Pros
  • 柔軟性が高い
  • Reduxが定めるベストプラクティスのRedux ToolKitがある
  • 1つのグローバルなストアにStateを保持するので管理が容易
• Cons
  • 学習コストが高い
  • 今回のプロジェクトで開発するアプリケーションにはToo Muchである

Recoil

Meta社製の状態管理ライブラリです。

• Pros
  • Atomという単位で一意なキーをもったグローバルStateを保持するので、理解しやすい
  • 学習コストが低い割に、機能的には十分
• Cons
  • Atomが増えすぎると管理が難しくなる
  • まだメジャーバージョンリリースしていない（執筆時点でのLatestはv0.7.5）

React Context

Reactが標準で提供しているContext APIです。

• Pros
  • React標準なので、導入ハードルが低い
  • Hooks（useContext）が提供されているので、使い勝手が良い
• Cons
  • 管理するStateが増えてくるとProviderのネストが深くなり、視認性が悪くなる
  • 祖先コンポーネントまで辿ってツリーを更新する為、頻繁にレンダリングが発生してしまう

決定内容と理由

決定内容

Recoilを採用する

理由

今回開発するアプリケーションの規模から、ReduxではToo Much、React Contextでは若干不足と考えたので、Recoilを採用しました。
また、基本的にAtomをHooksで操作するだけのシンプルさや学習コストの低さも魅力的でした。
メジャーバージョンのリリースはまだでしたが、実際にプロダクション利用している他社事例もあった為、その点に関しては問題なしと判断しました。

スタイル

スタイルに関しては、まずCSSの管理方法について、次のような思いがありました。

• CSSに詳しいメンバーがいない為、なるべくCSSファイルの管理は避けたい
• スコープはできるだけローカルに閉じて、堅牢性をあげたい

上記の思いを踏まえつつ、方針を考慮した結果、下記の2つから検討しました。

• CSS Module
• styled-components（CSS in JS）

簡単なプロトタイプを実装し、使い勝手や学習コストを比較検討しました。

CSS Modules

CSSファイルをJSからimportしてスタイルを当てる手法です。
Next.jsでは標準でサポートされています。

• Pros
  • Next.jsに標準でサポートされている為、導入コストが低い
  • コンポーネント単位でスコープを閉じられる
• Cons
  • CSSファイルを管理することになる
  • 社内に利用実績がない

styled-components

CSS in JSのライブラリです。

• Pros
  • コンポーネントのコードと同居させられるので、スコープについてほぼ考えなくて良い
  • 直近でリリースした社内の他プロダクトで利用実績がある
• Cons
  • コンポーネントに依存したカスタマイズをするので、移行が難しい
  • 静的なCSSよりもパフォーマンスが低い

決定内容と理由

決定内容

styled-components（CSS in JS）を採用する

理由

JSファイル内にCSSを記述できるため、以下の通り前提の思いを2つともクリアできる点が決め手でした。

• スコープについてほぼ考えなくて良くなる
• CSSファイルを作成しなくても良い

また、社内でも利用実績があり、情報収集の容易さという点でもメリットがありました。

テスト

最後にテストに関してですが、まずフロントエンドのテスト方針をどのように設定すべきか全く知識がなかった為、社内のフロントエンドチームにヒアリングしました。
そこでTesting Trophyの考え方を教えていただきました。

Testing TrophyとはReact Testing Libraryの作者であるKent C. Dodds氏が提唱するJavaScriptのテスト方針です。
今回はその考えに則り、Unit Test及びIntegration Testの層を厚くする方針としました。

その前提の元、テストライブラリは下記の2つを検討しました。

• React Testing Library
• Enzyme

テストランナーについては、ほぼデファクトスタンダードになってきていると思われることと、Next.jsに標準で組み込まれていることから、Jestを採用しました。
テストは、スタイルの検討の際に実装していたプロトタイプの中で使用し、使い勝手や学習コストを比較検討しました。

React Testing Library

Kent C. Dodds氏によるReactテストライブラリです。

• Pros
  • Next.jsの公式ドキュメントでJestと合わせた構成が推奨されている
  • 実際にユーザーにどう見えるかを基準にしたBDD寄りの考え方がチーム内で評判が良い
  • スナップショットテストを実施でき、改修時のリスクを減らせる
  • 直近でリリースした他プロダクトで利用実績がある
• Cons
  • Enzymeに比べるとコードの記述量が多い

Enzyme

Airbnb社製のReactテストライブラリです。

• Pros
  • shallow renderのテストは書きやすい
  • コードの記述量は比較的少なくできる
  • コンポーネントのpropsやstateに直接アクセスできる
• Cons
  • ユーザー目線ではないテストができ上がりがち

決定内容と理由

決定内容

React Testing Libraryを採用する

理由

ユーザーにどう見えるかを基準にしたBDD寄りの方針で作られています。
そのため、本質的なテストをすることができる点に関して、チーム内で評価されたことが決め手でした。
また、関数などのUnit TestはJestで、コンポーネント同士のIntegration TestはReact Testing Libraryでという明確な使い分けができ、Unit Test、Integration Testを充実させるテスト方針とマッチすると考えました。

まとめ

最終的に今回採用した技術は以下になります。

言語 / FW	状態管理	スタイル	テスト
・TypeScript ・React ・Next.js	・Recoil	・styled-components（CSS in JS）	・Jest ・React Testing Library

最後に

最後までご覧いただきありがとうございます。
今回は、フロントエンド未経験のSREエンジニアが技術選定を担当した経験についてご紹介しました。
技術選定はシステム要件、チームの背景、スケジュールなど様々な要因を考慮する必要があり、非常に良い経験となりました。

SREチームではフロントエンドだけではなく、バックエンドではGoを使用したフルスクラッチ開発や、AWS EKSを使用したKubernetes基盤の構築など様々な取り組みを進めております。
今回紹介したこと以外にもたくさんの情報を発信していけるように、今後も取り組んで参ります。

◆ 直近で開催予定の採用イベントをご紹介！
career-recruit.rakus.co.jp
career-recruit.rakus.co.jp

---

• エンジニア中途採用サイト
  ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
  ご興味ありましたら是非ご確認をお願いします。
  
  https://career-recruit.rakus.co.jp/career_engineer/

• カジュアル面談お申込みフォーム
  どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
  以下フォームよりお申込みください。
  https://rakus.hubspotpagebuilder.com/visit_engineer/rakus.hubspotpagebuilder.com

• ラクスDevelopers登録フォーム
  
  https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/

• イベント情報
  会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！

◆TECH PLAY
techplay.jp

◆connpass
rakus.connpass.com