こんにちは。株式会社ペライチ のフロントエンドエンジニアの荒瀬です。
私が入社して 1 年が経ち、入社当初からフロントエンド開発環境を Nuxt へリプレイスする作業を進めています。
リプレイスしたものがリリースされ、第一歩がようやく踏み出せたこともあり、これまでの過程とこれからの課題についてお話させていただきます。
背景
ペライチにはいくつかのサービスがありますが、基本的にはこのような技術スタックでフロントエンドの開発しています。
- CakePHP
- サービスによっては Ruby on Rails
- jQuery
- Backbone.js
- scss
- gulp
- webpack
- Karma
今となってはかなりレガシーな開発環境になっていて、大きな課題をいくつも抱えてしまっています。
今までの課題
プロダクトがスケールするほど複雑になっていく
jQuery 主体でフロントエンド開発していくと必ず行き着く問題ですよね。
肥大化していくモジュール、肥大化していくスタイルと向き合うだけで消耗してしまいます。
これは機能追加・改修に対する瞬発力がどんどん落ちていくことに直結します。
プロダクトの要件に対して実現する難しさ
プロダクトを成長させていくと、ニーズに合わせ UI も改善していく必要が出てきます。
こういうことをできるようにしたい、作りたいとなった時に現状のままだと実現するまでの工数・品質がどうしても気になってしまい、中々踏み切ったことができずにどこかで妥協しなくていけないことが多分にあります。
こういったことは、複雑になってしまったフロントエンド環境の現状を維持したまま改善だけを行っていくだけでは、費用対効果は思った以上に見込めないでしょう。
フロントエンドの開発が消極的になる
前述したことと被る点がありますが、複雑に絡み合ったコードをやりくりしていくのは、労力的、精神的に大変です。
機能の追加や改善に無意識に、消極的になってしまいがちです。
すぐに解決できる問題でもない、しかし開発は止められない。こういったジレンマを感じることもあります。
また、現在のフロントエンド開発の主流から外れてしまった技術スタックで開発し続けるというのもモチベーションが上がらない要因ではあります。
jQuery や Backbone.js が良い悪いという話ではなく、作りたいものに対してマッチしなくなっただけなのでしょう。
開発環境を刷新するためのこれまでの過程
ありきたりな話ではありますが、これらの問題を解決すべくフロントエンドの開発環境を刷新する方針で舵を切ることとなりました。
モダンな環境にすることですべての問題を解決できるわけでもなく、また新たな問題も出てくることもあります。
それでもそれらを考慮しても現状より大きな恩恵を得られるという結論に至りました。
リプレイスの範囲
最終的な目標は刷新したフロントエンド環境でペライチの全てのマイクロサービス化されたサービス（機能）を開発できるようにすることです。しかし、ペライチ自体が成長期にあり、さまざまな開発・改善が日々行われています。
サービスによって規模と歴史が異なるため、自ずと部分的な段階リプレイスとする方針になりました。
また、フロントエンドだけに焦点を絞り、極力バックエンドやインフラに影響の少ないサービスから始めるという点も考慮しています。
最初にリプレイス対象となったサービスもリリースしてから比較的あたらしく、規模(ここでは画面数としました)も大きくはないものとしました。
フレームワークの選定
今までフロントエンドは jQuery と Backbone.js 主体で開発していたわけですから、
「今日から違うもので開発していきます！」というのも現実的ではありません。
しかし、このままではいけないという問題意識は共通してあったので、それらを考慮してフレームワークの選定しました。
フロントエンドの開発環境を独立させるという点で、最終的にNuxtを採用することとなりました。
大まかな理由としては以下となります。
- ベースとなる Vue.js がメンバーのスキルセットと比較して親和性が高そうだった
- 規約が整備されていてる
- 開発支援のライブラリが予めパッケージされている
- 既存の CSS をそのまま流用、もしくは分解するのに手間が少ない
- インフラが整うまでは SSG でフロントエンド環境だけを刷新できる
コンポーネント指向のフレームワークを採用することで、これまで抱えていた問題がある程度まで解消するのと複雑なアプリケーション側の要求に応えてくれるという点で候補はすぐに挙がりました。
その中から開発メンバーのスキルセットと比較して一番親和性が高そうな Vue を選択しました。
同じコンポーネント指向のフレームワークである React との二択にはなったのですが、開発メンバーはリプレイス作業にフルコミットできたわけではありませんでした。
既存の環境で日々のサービス運用・改善と並行して開発していたため、学習コストが比較的低いがコンポーネント指向の開発ができる Vue にしようという決断に至りました。
CSS に関しても、スタイルは scss で作られていたこともあり、モジュールごとにファイルが分割されている状態でした。
Vue なら、これらのリソースを各コンポーネントで読み込むだけで scoped な状態にでき、グローバルな CSS としてバンドルしてしまう選択もできます。これらの理由で、少ない労力で解決できるという点も適していました。
また、リプレイス作業に注力できる人数も限られていました。そのため、Node.js が稼働するサーバーの準備、インフラ周りの整備などこれらの作業が完了するまでは SSG で開発して先行してリリースできるという点も大きいです。
リプレイスまでの準備
ある程度の方針が固まった後、すぐにリプレイス作業に取り掛かるのではなく、モック制作から開始してフロントエンドエンジニアが新環境での開発に馴染んでもらう期間を設けました。
親和性が高そうだったとはいえ、フロントエンドエンジニアのほとんどが Vue (Nuxt)で開発すること自体が初めてだったりと、まずは足並みを揃えることから始めることとしました。
モック制作を通したNuxtでの開発体験
最初の移行対象のサービスは画面数でいうと少ない部類だったので、CakePHP の View と jQuery で作られた画面を Nuxt で作り直してみるといった感じでモック制作から開始しました。
少し打算的ではありましたが、モック制作から開始した意図としてはこのようになります。
- 既存ページを差し替えるのでドメイン知識などが有る前提で作業が開始できる
- モックなのでまずは Vue 及びコンポーネント指向に慣れてもらえる
- 画面が出来上がっているのでリプレイスにあたっての API の整備も準備がスムーズに行える
1 人 1 画面を担当してもらいフロントエンドエンジニア全員が Nuxt での開発に触れてもらいましたが、これは想像以上にスムーズに馴染んでもらえた感触はありました。
Vue もしくは Nuxt 特有のお作法だったり、細かいルールなどは対面レビュー等を通してカバーすることで今後の開発イメージを固めていきました。
結果的にリプレイス作業よりもこの期間の方が時間を割いていました。
Nuxt開発におけるルール設定
モック制作期間中に生まれた開発時の戸惑いのようなものを解消し、それぞれの認識の差異を極力減らしいくために実装ルールを並行して決定していきました。
予め決めていたこともありましたが、以下のように調整しています。
Composition APIとTypeScriptについて
Vue 3 からの記法である Composition API で実装していく想定でした。しかし、まずは Vue 2 までのスタンダードな記法である Options API で実装してみることに変更しました。
遠回りではありますが、Options API で Vue の基本部分を体感し、Composition API でより理解を深め設計に意識を向けるという工程を踏むこととしました。
効率が悪いように思えますが、困った時、ドキュメントや事例を検索した時に Options API の方がヒットするものも多く、Vue を初めて触る人にとっては理解しやすいのではと感じました。
Options API に関しては、現時点では、今後非推奨になるというわけでもないため不要となる知識ではないと考えました。
とはいえ、TypeScript との相性を考慮すると Composition API で開発していこうという方針ではあります。
TypeScript については、Vue 同様に触れるのが初めてというメンバーが大半でしたが、こちらは比較的問題なく切り替えることができた印象です。
コンポーネント設計について
ここがつまづきポイントになるだろうと予測はしていました...。
当初は当たり前のようにAtomic Desginによるコンポーネント設計を計画していました。
jQuery でゴリゴリと開発していて、ある日突然コンポーネント指向のフレームワークで開発しますと言われ、Atomic Desgin の設計手法を詰め込まれる。こうなってしまうと、コンポーネントという概念を理解していたとしても戸惑いが生じるのは当然であります。
実際、Molecules と Organisms の違いなんかは個人差が生まれてしまいそうという声もありました。
ペライチのフロントエンド開発環境刷新の取っ掛かりとしてはこのあたりのコストを減らしたいことから、Atomic Desgin よりもう少しシンプルな設計手法の導入を検討しました。
そこで参考にしたのが、Predix Design Systemです。
これはアメリカのゼネラル・エレクトリックという大きな企業で採用されているものです。GE(ゼネラル・エレクトリック)も Atomic Design に悩まされた結果、代わりのデザインシステムを作っています。
Predix Design System の採用は、実験的ではありましたが最初の一歩目でつまづいてしまうことを回避することが出来ました。
ただ、少し自由度が高い状態にはなっているので、このあたりはペライチに適した調整を継続的に進めていく予定です。
本格的なリプレイス作業 ~ リリース
モック制作を経て、2021 年夏の終りに本格的に Nuxt での開発を開始することが出来ました。
基本的には画面自体はモック制作で完了はしているものの残課題として以下のようなものがありました。
- バックエンドでの API 調整
- フロントエンドの API 組み込み
- Nuxt のユニットテスト
- モック制作期間中に追加された機能の実装
- インフラ周りの整備
これらを解決したあとに QA テストの実施 ⇒ リリースという流れです。
この時期にはフロントエンド・バックエンド含め 4 名ほどの体制でスクラムを組んで取り組みました。
QAテスト完了まで2021年の年末までに完了させ、2022年の年始に無事リプレイスしたのものをリリースすることが出来ました。
インフラ周りの整備については、簡単なご紹介記事があるので合わせてお読み頂けますと幸いです。
これからの課題
無事リリースはできたものの、まだまだ初めの第一歩という印象が強いです。
最短でのリリースに焦点を絞り、その過程で諦めていたものや、リプレイス作業で新たに生まれた課題も出てきています。
Nuxtのバージョンアップ
次期バージョンである Nuxt 3 がリプレイス作業の過程で発表され、ベータ版が公開されてしまいました。
遠くない将来、対応に迫られることは認識しているため、これに合わせて Options API で作られたコンポーネントも Composition API へ移植したいと考えています。
バージョンアップに向けて全体的なリファクタリングが必要であるという課題があります。
テスト関連
@vue/test-utils によるコンポーネントのユニットテストは行われています。しかし、Storybook によるコンポーネント管理とスナップショットテスト、ビジュアルリグレッションテストなどのテストの自動化は残課題として多くあります。
特に Storybook の整備に関しては、別のサービスのリプレイス作業が開始されている状態なので優先的に進めています。
Backbone.jsで作られた画面のリプレイス
今回は Cake PHP の View と jQuery で作られたサービスだったので、比較的リプレイスは大きな問題なく行うことができました。
しかし、Backbone.js で作られた画面は肥大化しすぎて複雑に絡み合っており、全てを一気にリプレイスすることが困難な状態です。
こちらも段階的なリプレイスを計画しておりますが、より長期的なプロジェクトとなりそうです。
最初のリリースを終えて
まずはサービスの 1 つだけではありますが、フロントエンド開発環境を Nuxt 環境へ刷新することが出来ました。
サービスのリニューアルではないため、見た目の変化や機能が増えた、使いやすくなったということはありません。
しかし、今回フロントエンドを切り離されたことは、影響範囲を限定できることや機能の拡張・追加における品質の担保は向上が見込めます。
まだ小さな更新しか行われていませんが、開発体験が改善されたことは実感しています。
また、大きな機能改善の計画もされており、UX 向上により踏み込んだ UI の実装も現実的になりました。
そして、現在では次のサービスのリプレイス作業、今回は機能のリニューアルも同時に行っており、デザインも刷新される予定です。
少しづつではありますが、フロントエンド開発環境を刷新するプロジェクトは継続中です。
まだまだ未整備の部分もあったり、改善できることもたくさんあります。
ペライチのフロントエンド開発環境を全て刷新するためには、まだまだ課題は山積みです。
ですが、より良い開発環境を作るためのチャレンジがしやすい環境ではあります！
興味を持たれた方はぜひ下記からご連絡ください！
採用情報
現在エンジニア募集しています！
▼ 選考をご希望の方はこちら（募集職種一覧）。
▼ まずはカジュアル面談をご希望の方はこちら
募集中の職種についてご興味がある方は、お気軽にお申し込みください（CTO がお会いします）。
Discussion