見出し画像

ミイダスのフロントエンド開発環境について

miidas_tech

こんにちは。ミイダスのフロントエンド開発を担当している眞下です。

2016年にフロントエンドエンジニアとしてミイダスにジョインし、現在はフロントエンドの実装方針や技術選定に関わるほか、チーム運営やプロジェクト管理などを行っています。
今回は2021年現在のミイダスのフロントエンド開発環境について紹介します。

利用している言語やフレームワーク

まず、ミイダスのフロントエンドで採用している技術ですが、図 [*1] のような変遷を経て、現在は以下の通りです。
*1: イメージを掴みやすくするために一部バックエンドの技術も記載しています

スクリーンショット 2021-09-21 8.47.12

・React
・Redux
・Immutable.js
・Next.js
・PWA


導入の背景

この記事では主にプロダクトや開発組織フェーズとその変化などにフォーカスしながら、技術選定した理由について話していきたいと思います。
技術的な側面からのライブラリやフレームワーク、アーキテクチャの有用性については為になる良質な記事が既にネット上に多く存在しているので解説はそれらにお任せして、、

サービス立ち上げ期の技術スタックと狙い
ミイダスの初期開発においてはとにかく「リリースまでのスピード」を最優先にしていたため、リリース後の保守性や拡張性といった面は二の次にして（勿論実際には最低限は考慮していましたが）「とにかく動くものを最速で作る」という部分にフォーカスして技術選定を行いました。結果として、参画したエンジニアが採用している技術を素早くキャッチアップし、少しでも早くフロントエンド開発に入って実装を進められるように、当時普及していたFuelPHP+JQueryの構成を採用しました。そのうえで、マイクロサービスで言うところの”所謂モノリシック”なアーキテクチャで開発を行っていました。

リリース後の事業フェーズと開発の悩み
サービスの初期リリース後、（予想通りではありましたが）事業はすぐに凄いスピード感で改善サイクルを回すフェーズに入りました。
前述したように、そもそもあまり拡張性や保守性を考慮できていないコードベースに対して多くの改修や機能追加が入る状況になります。そして割と早い段階で、その時点で採用していた技術では、求められる品質的にも、開発速度的にも、無理が出てくることが想定されました。
一番深刻だったのは、元々難解な仕様を実現するために、なかなか複雑な作りになっていたコードに対して度重なる改修が入ってしまうことです。それにより、コードを1箇所修正すると意図しないような部分にも影響が及んでしまうような状況になりつつありました。。
これについては、コードのつくりもそうですが、ライブラリの特性上の問題もありました。フロントエンドの状態による画面やUIの複雑な表示制御を、JQueryで全て行うこと自体に表現力の限界があったと思います。
そこで、そういった課題を解決すべく、リファクタリングや新たな技術の導入と言ったいくつかの方針を検討しました。そのひとつとしてあがってきたのがReactの採用です。

React
表現力における課題において、Reactはまさにそれを解決するためのビューライブラリでしたし、開発にFacebookが関わっていて、Facebook自身でも使用していたことと、LTS（Long-term support）があるということも選定理由としては大きかったと思います。

リリース後すぐの段階にあったミイダスにとって、採用した技術の開発が止まることによって生じるコスト、そういったリスクを気にかけながら開発を進めるストレスは、迅速に改善を回したいという当時のビジネス面での要求において大きな影響を及ぼしかねません。その点で、同じ技術を使用してある程度長期的な見通しで安定して開発していけるというのは魅力的でした。

React採用後は、JQueryベースの従来の技術スタックでの開発と並行しながら、なるべくサービスのコアな機能とは疎結合な部分から試験的に導入を始めました。そしてプロダクト内でのある程度のプラクティスが確立されたタイミングで、主要な機能においてもReactでの移植を進めていきました。

サービス拡大期と開発の課題
Reduxの導入を本格的に検討し始めた頃、サービスとしては更なる拡大期に入りました。開発組織としてもそれに応じて、少数精鋭の体制からもっと拡大した規模で複数の要件を並行で開発できるような体制（改善のサイクルを回しつつ、新規機能の開発ラインも複数確保するイメージ）になっていこうとしていました。また、そういったサービスの流れに応じてミイダスのシステム構成を見直すことになります。既存のモノリシックなアーキテクチャから、全体的にGoのAPI+ReactでSPAな作りにして、バックエンドとフロントエンドを疎結合にしていく方向に舵を切りました。フロントエンドとしても、保守性や運用性を保ちつつ拡張性の高いコードベースにするという更なる必要性に迫られます。Reactを採用した時点で「Fluxの思想に則る」という大枠の方針はあったにせよ、状態管理についてはその具体的な方法として（ベストやベターなものでなかったとしても）コード上である程度（厳し過ぎず甘過ぎず）の規律にまで落とす必要があると感じていました。

Redux
そうした流れのなかで状態管理の具体的な方法としてReduxやMobXといったものの採用を検討するに到った訳ですが、最終的にReduxを採用しました。理由としては、その時点でもっとも採用事例や情報が多く、導入においてもトラブルシューティングにおいても困ることが少なそうだったのはひとつあげられると思います。
前述したような状況下で迅速な決定や導入が求められるなかで、この点は大きかったです。

また、前述したとおり開発組織としても体制が変わっていく方向性があったため、サービスにジョインするエンジニアのスキルレベルも、これまでより多岐に分かれる可能性が高まります。
Reduxを導入することで得られる規律とデータの流れの分かり易さによって、メンバーの能力の差によるコード品質の違いも少なくできるのではという点も期待していました。また、その時点では「多少の冗長さであれば、スマートより分かり易さをとる」という実装方針をとっていた点からも、Reduxにおいて定形のようなコードが一定発生するところも十分許容できると判断しました。

開発組織のこれから
ここからが比較的近年のミイダスの状況になりますが、開発組織を拡大することによってビジネスの要求（改善サイクルを回しつつ新機能開発のラインも確保する）にある程度応えつつも、書籍やネット記事でもちらほら見かけるように「エンジニアを増やせば開発速度も上がる」という構図が限界を迎えるというのはミイダスでも割と早い段階で何となく見えていました。そして開発組織を一定の規模まで拡大した後は、如何に効率や生産性を上げるかという方向で組織を考え直すフェーズに入っています。

それに伴いアーキテクチャやコードベースもそれに耐えうる状態にしていくために、単に「大規模な組織で開発を行えること」以外の面でも考慮すべき点が出てきています。例えば、前述したような課題感に対してマイクロフロントエンド的なアプローチで解決を図りたい場合には [*2] 、最低限バックエンドとフロントエンドは疎結合な状態にしておくとか、フロントエンドのなかでも機能分割やシステム分割し易いコードベースにしておこうとか、そういう側面への対応ができるようにしていこうというのが現状のフェーズに近いと思います。
*2: ミイダスでマイクロサービスやマイクロフロントエンドの考え方を素直にそのまま採用しようということではありません

Next.js
Next.jsの採用にあたってはパフォーマンス [*3] やSEO [*4] の観点からの選定理由も当然あったのですが、前述したような「組織編成の変化に適したコードベースにしてしていく」という、来たるべきアーキテクチャへの準備のような観点も大きい理由でした。

具体的には、Redux導入後にSPA化自体は順調に進んでいたので、一定はバックエンドとフロントエンドは疎結合にはなっていたのですが、サービス立ち上げ期に採用されたFuelPHPがほぼSPAの基点となるNodeを返すというのみの役割において生き残っています。「ほぼ」というのが味噌なんですが、主となる役割はどうにしろFuelPHP自体は生きているのでやはり一部バックエンド管轄になるようなロジックもFuelPHPにあったりします。よって、開発における責務としてはバックエンドとフロントエンドの領域が曖昧な部分も残っていたため、Next.jsを採用することでやや強制的に”FuelPHPとお別れ”して、その辺を明確にしておきたいという意図もありました。

*3: これまではレンダリングの方式としてCSRの一択で開発していました。サービスの成長とともに機能の拡大と複雑化も進み、JavaScriptによる処理もかなりの速度で増えていくなかで、画面の初期描画までの時間や操作性（CPUやメモリを食うので）といった要因はクライアント端末の性能に依る部分が大きくなってしまっています。パフォーマンスの観点から実装する各画面・機能の要件や特性に合わせてケースバイケースでCSR/SSR/SSG/ISRといった方式を選択することが可能となることによって、開発側の制御下（クライアント環境に依存しないという意味）において打てる解決策のベースとしてNext.jsの導入は有用だと捉えていました。

*4: 導入を検討するきっかけとしてSEOの観点がありました。現在の主要な検索エンジンのクローラーはJavaScriptを解釈するためにCSRであってもシンプルなページを実装する分には何か特別に検索エンジン向け対策をする必要はないという見解もありつつ、決定打にはならなかったと認識しています。そうした見解に否定的ということは特にない（むしろそうなって欲しい）のですが、ただ、いくらクローラーが優秀になっているとはいえ外部要因である以上は最終的に何があるか分からない（詳細な内部実装は分かり得ないので「これで100%OK」な保証はない）というのは昔から変わらずかと思います。また、クロールして欲しいのがJavaScriptを解釈できる主要な検索エンジンのクローラーとは限らない（各種SNS用のOGP対応など）という点で、SEO対応という意味合いは残ったと思います。

スクリーンショット 2021-09-27 23.29.39

技術選定で意識する3つのポイント

これはエンジニア（個人や組織）ごとの役割（所属している会社や業種、エンジニア組織の特性、何を制作するかなど）によって変わってくるところだと思います。あくまで"ミイダスのフロントエンドの場合"ということを前置きしたうえで、細かく挙げると多岐に渡るので大きな点を三つ挙げたいと思います。

サービスの成長につながるか
これは技術選定に限らずですが、僕たちはサービスの開発・運営をしていますので大きな目的のひとつに「サービスの成長」があると考えていて、技術選定においてもサービスの成長につながるものであるかという視点は意識しています。
いかに新しく優れた技術であってもそこにつながらないのであれば採用には至らないと思います。

現在と少し先 [*5] のサービス（事業）や開発組織のステージにフィットするか
その時点のサービスや開発組織のステージと、少し先の予想できる範囲での展開に採用する技術がフィットするかという点も割と意識しています。
例えば、サービスやサイトがこれから大きく拡大していこうというステージにあって、有用だが開発者に非常に高い専門性が求められる技術を採用するのは、エンジニアを増員するであろう組織の方向性とは、必ずしも全てのケースで相性が良いとは言えないと思います。
（それだけのエンジニアを多数採用できる採用力が企業にあれば話は別ですが）

*5: "少し先"としているのは、ミイダスでは状況に応じて短期的な予定はすぐ変わるからです。1,2年後までの確実なロードマップが引ける環境であれば、それに応じて検討するのが良いと思います。

「ビジネスからの要求」「システムの保守性や拡張性」「エンジニアの興味・欲求」のバランス
前述してきた2つを満たしたうえで、「ビジネスからの要求」「システムの保守性や拡張性」「エンジニアの興味・欲求」という三つの側面のバランス感をとるというのも重要だと思います。
「ビジネスの要求」と「システムの保守性や拡張性」という点は前述してきた観点に含まれるかもしれませんが、エンジニアの成長やモチベーションが少なからず開発の速度や品質に影響するという意味では「エンジニアの興味・欲求」というところも開発組織としては大きい側面だと考えています。当然それのみが目的で技術選定することは基本的にないですが、前述してきたようなところでもメリットがあるものについては、常時とまではいかないまでも定期的にフロントエンドエンジニアとして業務している人に新たな学びがあるように、意図的に新しい技術の採用を検討しています。


まとめ

これまで使ってきた技術は様々な背景から検討し導入を進めていきました。しかし、flowtypeやTypeScript、Jest + Enzymeなどの導入の検討はしたものの、その時々の事業のステージにおけるビジネスからの要求の優先順位とリソースの都合の関係で導入に至らなかった技術も多々あります。

現在ではシステムも肥大化・複雑化してきていますし、開発組織も大きくなりました。
当時とは状況が違うので、それに応じて再度導入を検討することも当然あると思います。
一度採用を見送ったからといって二度と使わないという訳ではもちろんないので、前であげたような以前に一度採用を検討した技術もそのときには選択肢に上がるのではないかと思います。

今回ご紹介した導入の背景や技術選定は、私たち組織ならではの取り組みかもしれませんが、同じようなフェーズの組織やチームの参考に少しでもなると嬉しいです。

ミイダスのフロントエンド技術は、組織とシステムの規模の拡大に伴い、常に「ビジネスからの要求」「システムの保守性や拡張性」「エンジニアの興味・欲求」のバランスを考え選定を進めています。
組織の課題に向き合いながら、一緒に開発を進めていくフロントエンドの仲間を募集しているので、興味がある方はぜひ私たちのチームで開発をしてみませんか。

関連する採用情報


この記事が気に入ったらサポートをしてみませんか？