Vue.js?React?フレームワーク選びの7つの選定基準、大規模ECサイトのフロント刷新プロジェクト

こんにちは。モノタロウでフロントエンド寄りの開発をしている、陳です。

今回はモノタロウの新フロントエンドのメインフレームワーク選定についてお話しします。

選定結果から言うと、モノタロウ独自の7つの選定基準をもとに、Reactを選ぶことになりました。

背景

まず、モノタロウの現フロントエンドについてざっくり説明します。

モノタロウは2002年から、PythonとJavaScriptでECサイトを開発してきました。

基本構成として、サーバサイドのPythonでHTMLを生成し、クライアントサイドのJavaScriptでカートインなどの動的処理を補完する形ですが、実はこの構成で違うアーキテクチャのものが2系統(以下系統A、系統B)あります。

f:id:maskraft:20211004103114p:plain
モノタロウECサイトの構成イメージ

長年にわたり開発していく中で、色々な課題が出ており、利用者/開発者目線別に抜粋しました。

利用者目線で見ると

  • 画面操作後の表示更新が遅いし、シームレス感がない
  • 高度でモダンなインタラクティブ体験ができない

開発者目線で見ると

  • 現フロントエンドを構成する2系統は、ビジネスロジック的に近いのに、それぞれが違う社内独自フレームワークを使っている
    • 系統Aが独自フレームワークAを利用
    • 系統Bが独自フレームワークBを利用

f:id:maskraft:20211004103116p:plain
2系統の管轄範囲がややこしい

  • UIコンポーネント作成など似た処理が違う言語(Python、JavaScript)でサーバ側とクライアント側にあるし、コーディングスタイルも微妙に違う

そこで、「社内フレームワークの特徴と特徴による問題」の表を作ってみたら、挙げた課題の中、社内独自フレームワークによるのが大きいとわかりました。

社内独自フレームワークA・Bの特徴 その特徴による問題
画面操作時は基本ページ全体をリロード
  • 必要以上にデータ送受信が発生する
  • 画面表示更新が遅くなる
Python(サーバ側)とJavaScript(クライアント側)によるUIコンポーネント実装
  • 二重管理で影響範囲により気を付ける必要があり、生産性が低い
  • 二つの言語を覚えないといけないので、学習コストが倍
jQueryと生のJavaScriptによるインタラクティブ処理実装
  • 高度なインタラクティブ処理を実現しにくい
  • 文字列連結でHTMLを生成しており、書きにくく可読性も低い

また、「中途入社した人が戦力になるまで時間がかかる」など採用・コミュニティの観点でも、今後は社内独自フレームワークを使い続けたくない意見が多いです。

というわけで、

フロントエンドを刷新したい!

既存2系統のフレームワークも世間一般的なものに統一したい!

と社内キーマンの多くが共通の認識を持つようになりました。

新フロントエンドプロジェクトの立ち上がり

フロントエンドを刷新するため、新フロントエンドプロジェクト(新FE PJ)が立ち上げられました。

最初のプロジェクト関係メンバーが、まずフロントエンドの最新技術動向について調べました。

主流なフレームワークはVue.js, React, Angularの3つとわかったのですが、どれが良いのかわからないので、比較と選定を行うことになります。

プロジェクトメンバーが手分けして、Vue.js, React, Angularそれぞれを使ったTodo Listデモを作り、比べてみました。

Angularの学習コストが高く、癖が強いと感じるエンジニアが多いので早期脱落し、そこでVue.jsとReactの対決になりました。

f:id:maskraft:20211021110920p:plain
Vue.jsとReactの対決

Vue.jsとReactの比較検討をしてみた

私はこの時点で当PJに参加し、メインフレームワーク選定を任せられます。

着手当初の印象は、「Vue.jsは直感的に書きやすい」「ReactはTypeScriptと相性がいい」くらいだけでした。

何もわからなかったので、とりあえず資料などをいろいろ漁りました。

  • 公式サイトから仕様を確認
  • 他社での事例や個人使用感を調査
  • Vue.jsとReactそれぞれのデモアプリを作成

手当たり次第に得た結論を比較表とレポートにまとめました。こんな感じです。

f:id:maskraft:20211004103105p:plain
比較表v1

比較表v1の大小分類の詳細は以下:

  • 機能要件面
    • 既存システムの移植
    • これからの開発
    • 開発効率
  • 非機能要件面
    • ユーザビリティ
    • 性能
    • 拡張性
    • セキュリティ
    • テスタビリティ
  • 社内既存エンジニアとの相性
  • TypeScriptとの相性
  • 採用・育成のしやすさ
  • コミュニティ・バックアップ

しかし、比較表v1をPJ関係メンバーに見せたら、「ボトムアップで整理しただけ」「網羅性が足りない」「粒度もまちまち」と、皆さんに納得してもらえませんでした。

俯瞰して改めて選定基準を考えた

皆さんに納得してもらえなかったので、それを機に新しい観点であるSEOも考慮し、SEO対策のサーバサイドレンダリングができるVue.jsベースのNuxt.js・ReactベースのNext.jsを比較対象に追加し、考え直すことにしました。

一般的なソフトウェア品質特性やVue.js/Nuxt.js・React/Next.js自体の懸念点などを議論しながら、社内事情を考慮した上で俯瞰的に選定基準を決めます。

一般的な視点

  • ソフトウェア品質特性(JIS X 25010) *1
  • Vue.js/Nuxt.js・React/Next.js自体の懸念点 *2

モノタロウの社内事情

まず大前提が3つあります。

  • 大量のアクセスがつねに発生している
  • 数十人規模での複数チーム同時開発
  • システムのソースコード量が膨大

それから、社内の色々な事情を考慮していました。

  • 系統Aで使っているフレームワークAはNuxt.jsと似ており、Vue.js/Nuxt.jsにする場合は系統Aの資産使える可能性があるため、系統Aも系統BもフレームワークAに統一する案があった
    • しかし、多分簡単にはいかないだろうし、スタイルガイド適用(デザイン統一のための社内別PJ)と関わってくると、既存のUIコンポーネントも結局使わなくなる懸念があるため、系統Aも系統BもフレームワークAに統一するのが良い策ではなさそう
  • Next.jsはNuxt.jsより軽量でカスタマイズ性が高く、疎結合なサービスが作りやすく、将来新技術への移行もよりスムーズになりそう
    • 社内でシステムの疎結合・マイクロサービス化も企画しているため、React/Next.jsに加点する
  • 生産性においては、モノタロウの規模だとTypeScriptでReactの方が総合的に良い
    • React with TypeScriptはデータの単方向性やタイプチェックによって、テスタビリティが高く、品質を保ちやすく堅牢性が高い
    • Vue.jsの簡易さは諸刃の剣であり、スケールにつれてデバッグとテストが困難になりがち
  • デザイナーは直接TSXファイルではなく、別のCSSファイルを編集するので、今より開発ハードルは上がらない(モノタロウでは、デザイナーもHTML・CSSを中心にコードを書いているため)
    • Reactで採用しているTSXファイル形式はデメリットにならない
  • npmなどのデータから見ると、日本を含む世界的にNext.jsのほうがトレンドになっている(採用面でも問題なさそう)
    • npmでのWeekly downloads
      • Next.js 568k downloads
      • Nuxt.js 230k downloads
    • Googleトレンド

f:id:maskraft:20211004103057p:plain
nextjsとnuxtjsの被検索趨勢グラフ

7つの選定基準

一連のプロセスを経て、最終的に出したのが以下7つの選定基準です。

  • ユーザー体験
    • ページ間の遷移はパラメータを引き継ぎながらシームレスに
    • 検索結果、レコメンドやクーポン、購入履歴などをパーソナライズ
    • レスポンスタイム短縮などにより体感速度の向上
  • SEO
    • サーバサイドレンダリング
    • Core Web Vitalsなどの計測
  • 性能
    • 大量なアクセスに耐えられる
    • コンポーネントが多い複雑なページでも動作が軽快
  • 品質
    • 世間一般のコーディング規約がある
    • ユニットテスト・受入テスト
    • 今後のメンテナンス
  • 生産性・開発者体験
    • チームでのアジャイル開発
    • 一定品質以上の開発スピード・しやすさ
    • レビュー・リリース
  • コミュニティ
    • 日本語ドキュメント
    • サポート企業
    • コミュニティの活発度
  • 採用・育成
    • 日本で採用のしやすさ
    • 社内既存エンジニアの育成しやすさ

この7つの選定基準に基づいて比較表v2とレーダーチャートを作りました。

f:id:maskraft:20211004103100p:plain
比較表v2

f:id:maskraft:20211004103111p:plain
7つの選定基準に基づいたレーダーチャート

ご覧のように、SEO, 性能, 品質, 生産性・開発者体験の面でReactが勝ち、ユーザー体験, コミュニティではReactとVue.jsが同点、採用・育成の面ではVue.jsが勝つという結果になります。

選定結果

結論、モノタロウは性能, 品質, 生産性・開発者体験をより重視するので、Reactを選びました。

なぜ性能, 品質, 生産性・開発者体験をより重視するのかというと、理由は以下です:

  • ユーザー数が多い
    • 大量アクセスをさばける能力が必要
    • (自動テストなどで)一定以上の品質を担保したい
  • システム規模が大きくて複雑、開発者も多い
    • コンポーネントが多い複雑なページの場合、Vue.jsは描画速度が遅く動作も重い
    • 複数チームでの並行アジャイル開発をしているためメンテナンス性が重要、一定以上品質の開発スピード・しやすさも求められる
  • 社内エンジニアを大事にする
    • 既存エンジニアの学習コストを考慮する
    • エンジニアと非エンジニア(デザイナー等)との協業の観点

技術選定を通して得た3つの学び

今回のメインフレームワーク選定を通して、私は3つの学びを得ました:

  • 選定基準
    • フロントエンドにおいて注目すべき軸
  • 選定基準の決め方・考え方
    • 結論に納得してもらう前に、基準の合意が必要
    • 基準の網羅性を高め、粒度を揃える
  • 選定基準の運用方法
    • 軸ごとに状況に応じてウェイトをつける(この方法で、社内基幹系システムのフロントエンド技術選定にも役に立った)

特に、「結論に納得してもらう前に、基準の合意が必要」は、今後ほかの色々な分野にも応用できそうと思っています。

モノタロウは、Reactを含めた新しいフレームワークやソフトウェア基盤への移行を進めており、いま絶賛開発中です。ソフトウェアの刷新や移行に興味がある方はぜひご応募ください!

*1:機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性

*2:TypeScriptのコンパイルスピードが遅いと言われている → 今のプロトでは気にならない;Vue.jsは選定当時Ver2からVer3への大幅アップデートがあり、Vue.js3ベースのNuxt.jsはしばらく安定稼働しなさそう