ALGO ARTISは「社会基盤の最適化」というコーポレートミッションを掲げ、複雑で高度な運用計画策定業務の最適化を行う企業です。今回はALGO ARTISの取締役VPoEである武藤悠輔さんにインタビュー。「Startup CTO of the year 2023」の受賞者でもある武藤さんは、これまでどのような決断をして開発組織をけん引してきたのでしょうか。


「Startup CTO of the year 2023」獲得。世界トップクラスの最適化技術を有するALGO ARTISの開発思想

ENECHANGE株式会社でフロントエンドエンジニアおよびテックリードを務めている小野と申します。私が所属しているエネチェンジ事業部では、電気とガスの料金シミュレーションサービス「エネチェンジ」を開発しています。この記事では、長年の開発によって積み重なったフロントエンドの技術負債をどのように解消しているのかについてご紹介します。<h2 id="h47a2082ce8">リプレース前の技術スタック</h2>リプレース前の「エネチェンジ」のフロントエンドは、jQueryがメインで使われていました。たまに、HTML（正確にはRailsのerbテンプレート）に直接scriptタグで記述されていることもあり、ルールが整備されておらず、既存のコードを読み解くのが大変な状況でした。加えて、Vueの2系を一部導入しており、同じページの中にjQueryで制御している部分とVueのコンポーネントで記述されている部分が混在していました。それも、コードを難解にする大きな要因でした。<h2 id="h6e4c81a0fd">リプレースに向けた技術選定</h2>最初、Vue2を使っていると聞いたときは、Vue3への移行に気持ちが傾きました。しかし、実際のコードを見てみると、そもそもVue2が使われているのはごく一部であり、Vueの資産を活かすことはほとんど考える必要がないと判明しました。そのため、フラットな視点で、今導入するならReactとVue3どちらが良いかを検討することになりました。調査する前から、明らかにReactが良いだろうとは思っていたのですが、技術選定にあたっては自分や周りの人を納得させられるだけの根拠が必要です。そこで、ライブラリのダウンロード数や、他社の事例などを調査しました。ReactやVueを拡張したフレームワークであるNext.jsやNuxtも併せて調査しました。2022年4月当時、npm trendsでダウンロード数を比較した結果、React + Next.jsがVue + Nuxtに圧倒的な差をつけて使用されていることが判明しました。↓当時の React と Vue の npm trends のグラフ<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/5fd95a4d4db14d538f7ab47dae8099ae/image%20(1).png" alt="" width="2048" height="742"></figure>↓当時の Next と Nuxt の npm trends のグラフ<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/3fbfbfd1acd24bcc983322789bbc1dc5/image.png" alt="" width="2048" height="744"></figure>また、リプレースの事例を調査したところ、Vue→Reactに移行したという記事はたくさん見つかりましたが、その逆は一つも見つかりませんでした。もうこの時点でReactが良さそうに思えましたが、単にReactの方が多く使われているというだけであり、なぜReactまたはVueを使うのかについてはまだ調べられていません。そこで、数多くの技術記事を読み込み、また、自分自身が両方触った経験も踏まえ、それぞれの特徴をまとめました。React + Next.jsの特徴<ul><li>TypeScriptとの相性が良い</li><li>Vueに比べ、品質の担保や開発者体験に優れている</li><li>Nuxtは覚えることが多いのに対し、Next.jsはシンプルで覚えることが少ない</li></ul>Vue + Nuxtの特徴<ul><li>マークアップを直感的に書ける。ReactのJSX記法に比べてとっつきやすい</li><li>コンポーネント単位のCSSがデフォルトでサポートされている</li><li>Vue3 + Nuxt3の登場によりTypeScriptのサポートが手厚くなった<ul><li>逆に言えば当時は過渡期で、主要ライブラリのVue3対応が終わらないと手を出しづらかった</li></ul></li></ul>このようにまとめることによって、どちらを選ぶべきかの方針が見えてきました。一言で言うと、品質や開発者体験を優先するならReact、新人育成のしやすさを優先するならVueという方針で選ぶと良さそうです。当時の社内ではジュニアレベルのエンジニアを育成するということはあまりなく、品質や開発者体験を優先するという判断で、Reactを選択することになりました。付け加えると、Reactで開発したいエンジニアが増えていることから、採用にも良い影響がありそうというのも一つの理由となっています。<h2 id="h64ba7c16c2">どのようにリプレースしたか</h2><h3 id="h80f1e5b496">静的なページはNext.jsで</h3>React化を進めるにあたり、まずはLPなどの静的なページから移行を始めることにしました。なぜなら、LPは以前から速度を改善したいという要望があり、リプレースするにはちょうどよかったためです。大きな方針としてはReactを使うことになっていましたが、リプレースするページが決まったところで、さらに詳細な技術選定をする必要が出てきました。そこで、表示速度やSEO面で有利になり、かつ開発者体験も良いNext.jsのSSGを使うことにしました。また、CSSの書き方についてもいろいろ調べたり実際に触ってみたりした結果、使いやすくて利用者も多いEmotionを使うことにしました。詳細な技術スタックは下記のようになりました。<ul><li>Next.js</li><li>TypeScript</li><li>Emotion</li><li>Jest</li><li>ESLint</li><li>Prettier</li><li>Storybook</li></ul>最初の1ページは、ほぼ私一人で開発を進めていき、基盤作りもかねてリプレースをしました。正直、思っていたよりも大変でした。ページ内のすべての要素をNext.jsで実装し直す必要がありましたし、一部Railsから電力会社のプランなどのデータを引っ張ってきて表示する必要もありました。そのために、Rails側にAPIを実装しなければならないのですが、そのAPIも私が開発しました。また、インフラの構成としてはAWSのCodeBuildでビルドし、それをS3にアップロードするという形をとりました。インフラの構築自体はインフラチームにお任せしましたが、構成を考えるところや、ビルド設定ファイルの作成は私が行いました。CodeBuildを使うのは初めてだったので、ビルドが成功するまで設定をいろいろと変えながら試行錯誤をくり返しました。最初の1ページを完成させるのに大体4カ月ぐらいかかりました。苦労したかいがあり、ページ速度はPageSpeed Insightsのスコアが40点台だったのが、70点台にまで大幅に改善しました。それに自分自身のスキルアップにもつながる貴重な経験でした。その後は、他のフロントエンドエンジニアにも協力してもらいながら、さらに各ページのリプレースを進めました。半年ぐらいかけて、ページ数でいうと1000ページ以上のリプレースに成功しました（ページの種類でいうと4種類ほどです）。リプレース後のページは表示速度が改善したとともに、ソースコードも読みやすくなり、保守しやすくなったと思います。<h3 id="h08794f3c7e">「マイエネルギー」の開発でReactの導入が進んだ</h3>2023年10月にスマートメーターのCルート開放が実施されることが決定し、我々もスマートメーターのデータにアクセスできるようになりました。それに向けて、そのデータを活用するサービス「マイエネルギー」を開発することになりました。新規開発ということで、当然フロントエンドはReactを使用しました。ただ一つ問題があり、それはスケジュールがタイトだということです。ENECHANGEは「電力データを活用した機能を日本で一番早くリリースする」という方針を掲げていたので、2023年10月のリリースが決まっていました。また、諸事情により開発に入る前の工程（企画・デザインなど）が遅れていたため、2カ月ちょっとでリリースできる状態まで持っていく必要がありました。そこで、今回はページ全体をリプレースするという方法ではなく、新規要素のみをReactで実装し、共通パーツ（ヘッダーやサイドバーなど）はRails上の既存のものをそのまま使うという方針で進めました。これにより、工数を最小限に抑えることができたと思います。なお、それを実現するには、Rails上でReactのアプリケーションを読み込む必要があります。それの基盤作りも苦労したので少しお話ししたいと思います。今までのフロントエンドの構成は、Vueのソースコードがwebpackでビルドされる仕組みになっていました。このwebpackが非常に遅く、開発サーバーの起動やビルドに1分近くかかっていました。この仕組みをそのまま流用すれば楽に開発環境を構築できますが、これだけ遅いと開発スピードに支障をきたしてしまいます。そこで、チームで話し合った結果、Viteを使うことにしました。その結果、一瞬で開発サーバーが起動するようになり、ソースコードの変更も一瞬で反映されるので、かなり開発者体験が良くなりました。なお、Viteで構築したものをRails側で読み込めるようにするのも苦労しました。調べたところ、vite_railsというGemを使うのが一般的らしく、逆にGemを使わずに自力でRailsとViteを連携させた事例は一つも見つかりませんでした。しかし、実際にvite_railsを使ってみたところ、以下のような問題が発覚しました。<ul><li>Viteの設定ファイルやpackage.jsonなどがRailsのルートディレクトリに置かれてしまう<ul><li>上記はreactディレクトリに置きたいのに、それができず、ファイルが散らばってしまう</li><li>設定ファイルの場所を変更するオプションもなさそう</li></ul></li><li>そもそも、フロントエンドのためにGemに依存するのはあまりやりたくなかった</li></ul>念のため、他のフロントエンドのメンバーにも意見を聞いてみたのですが、やはりvite_railsは使いたくないという意見で一致したので、Gemを使わずに自力でRailsとViteの連携を実装することにしました。<a href="https://ja.vitejs.dev/guide/backend-integration.html" target="_blank" rel="noopener noreferrer nofollow">https://ja.vitejs.dev/guide/backend-integration.html</a> を参考にしながら、実装を進めました。これも試行錯誤のくり返しでしたが、バックエンドエンジニアにも相談しながら、なんとか実装できました。今回、バックエンドの実装が終わる前にフロントエンドの開発が始まりました。そこで、バックエンドのAPIが完成しなくても進められるように、OpenAPI（Swagger）のファイルを作成し、そのAPI定義をもとにフロントエンドとバックエンドの開発を並行して進めました。おかげで、なんとかスケジュール通りにリリースすることができました。<h2 id="h28b62bc2c0">今後の課題</h2>このように1年半にわたる「React化」の結果、モダンなフロントエンド開発が進んだとはいえ、まだまだレガシーなコードがたくさん残っています。特にVueで書かれた箇所が結構読みにくくて管理コストがかかっているので、その部分を優先的にReact化していきたいなと考えています。また、「マイエネルギー」の開発で、フロントエンドとバックエンドの連携に関する課題が見えてきました。APIスキーマをあらかじめ共有することによりうまくいった部分もありますが、時間がなかったこともあって、どのような値を入れてほしいのかについての意思疎通が十分にできていませんでした。結果として、意図したものとは異なる動きになっている箇所が出てしまいました。今後は、APIスキーマの説明をできる限り詳細に書くことや、必要に応じてフロントエンドとバックエンドですり合わせのミーティングを実施するなどの工夫をしていきたいです。<h2 id="ha214098e44">まとめ</h2>ENECHANGEにおけるフロントエンドのリプレースプロジェクト「React化」について紹介しました。フロントエンドのリプレースは決して簡単なことではありません。既存のレガシーなコードを読み解きながら、最新の技術で実装し直す必要があり、高度なスキルが求められます。だからこそ、リプレースは、エンジニアがスキルアップするチャンスです。私もこのプロジェクトを通して、エンジニアとしてのスキルに磨きがかかった実感があります。また、React化は、開発組織の士気を高めることにもつながったと思います。メンバーからは「新しいコードは読みやすくて修正しやすい」と言ってもらえました。本当にやってよかったなと思いました。最近は弊社だけでなく、さまざまな現場でフロントエンドのリプレースを進めていたり、検討していたりすると思います。スキルアップしたいエンジニアのみなさん、チャンスがあれば、ぜひチャレンジしてみてはいかがでしょうか。編集：中薗昴提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a>

ENECHANGE株式会社でフロントエンドエンジニアおよびテックリードを務めている小野さんが、長年の開発によって積み重なったフロントエンドの技術負債をどのように解消しているのかについてご紹介します。

レガシーなフロントエンドをリプレースするプラクティス。エネチェンジが挑む「React化」

こんにちは、LINEヤフー株式会社の児玉です。現在は出前館に出向し、主にコンシューマ向けアプリケーションのフロントエンド開発を担当しています。現在、出前館フロントエンドはWebの画面単位でのリプレイスを進めており、あと少しで完了予定となっています。もともとリプレイスした経緯としては、レガシーな技術で保守が難しいコードベースが、だんだんと負債になっているのを感じていたことからです。たとえば、新しく加わったエンジニアにとって理解しにくいコードベースや開発スピードの低下といった問題があったため、モダンな技術を使ってリプレイスすることにしました。しかし、モダンな技術にリプレイスしたからといって負債がゼロになるわけではなく、新たな課題などが見つかります。出前館Webでもリプレイスを進める中で技術的な課題に何度か直面し、アーキテクチャなどの大きな変更も行いました。本記事では出前館Webでのリプレイスとリアーキテクトの取り組みについてご紹介したいと思います。<h2 id="had005982f7">PHP + jQueryで作られていたWebをリプレイス</h2>出前館はPHPのCodeIgniterというフレームワークで開発されていましたが、以前はQAや開発体制が整っていなかったため、以下の問題がありました。<ul><li>巨大な1ファイルにロジックが集約されていたため、コードベースの可読性が低く、メンテナンスが難しい状態になっていた。</li><li>本来サーバーサイドにあるべきロジックがフロントエンドに寄せられていたため、WebとAppで同じようなロジックが多数存在していた。そのため修正や改善を行う際にWebとAppの両方を直す必要が多々あり、開発スピードも落ちていた。</li><li>フロントエンドチームにPHPが得意なエンジニアがいない。</li></ul>これらの理由から、既存のシステムを引き継ぐのではなく、全面的にリプレイスすることにしたのです。新しい技術スタックは、開発コミュニティが大きくエコシステムも充実しているReactを採用しました。また出前館アプリがReact Nativeで開発されているなど、出前館全社としても採用が進んでいる技術です。WebのフレームワークはCSR（Client Side Rendering）やSSR（Server Side Rendering）、SSG（Static Site Generation）などのさまざまなレンダリング手法をページ単位で適用できるNext.jsを採用し、Next.jsのAPI Routesを使いBFF（Backend for Frontend）の層を設けることにしました。BFFのモデルとして、クライアントごとにBFFを持つこともありますが、出前館ではWebとAppで別々のサーバーを立てて運用するとコストが高くなると考え、WebとAppで1つのBFFを使うことにしました。またWeb/AppとBFF間のプロトコルにGraphQLを採用し、クライアントから柔軟な形でクエリできる構成としました。さらにサーバー側はマイクロサービス化を進めていることもあり、BFFは複数のマイクロサービスからデータ取得しそれらを集約してクライアントに返すAggregation Gatewayの役割も担っています。ざっくりとした構成は下記の通りです。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/825a0c92763145a0bb850cdf5d0d38f0/image2.png" alt="" width="977" height="518"></figure><h2 id="h2ce2a72a8c">WebとBFFの分離</h2>上記で述べたリプレイスでは全画面を一気にリプレイスするのではなく、画面単位でのリプレイスをする戦略をとりました。 しかし、何画面かのリプレイス後に気付いたのですが、Next.jsのAPI RoutesをBFFとして使っているとWebとBFFは同じサーバーかつ同じコードベースになることから、以下の問題が出てきました。<ul><li>コードベースのメンテナンス性の低下：WebとBFFのコードが混在してわかりにくくなっていた。Webはさらにクライアントとサーバー側に分かれており、実際は3つの異なる役割のコードが存在していた。そのせいもあって、新しくエンジニアが参画するたびにコードベースについて質問され、説明していた。</li><li>サーバーの柔軟性：Webの負荷は主にSSRで、BFFはWebとAppの両方からのリクエストをさばいているため、Webよりも高負荷になる。1つのサーバーで管理していると柔軟性がなく最適化などが難しい状態だった。</li><li>デプロイの分離：デプロイやロールバックでWebとBFFの切り離しができなかった。たとえば、デプロイ後にWebで不具合があってロールバックをする際にBFFも一緒にロールバックする必要があった。さらに、場合によってはBFFを呼んでいるAppも戻す必要があった。</li></ul>こうした問題を解決するために、Next.jsのAPI RoutesをBFFとして使うのをやめ、WebとBFFのサーバーとコードベースを分けることにしました。BFF用のサーバーを別で立てることにより、サーバーの台数調整、デプロイとロールバックの切り離しも柔軟に行えるようなりました。また、コードベースもMonorepo化し、パッケージ単位でWebとBFFを切り分けることができたのでわかりやすくなりました。ざっくりとした構成は下記の通りです。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b63ec121302d40009d141458a554845e/image3.png" alt="" width="977" height="522"></figure><h2 id="h0313e6d6f3">リプレイス・リアーキテクトの改善点</h2>Next.jsのAPI RoutesをBFFとして使うのを途中でやめたように、技術を新しくしたからといって、課題や負債がなくなるわけではありません。実際に、出前館でもリプレイスしていく中で他にも改善したい点はいくつかあります。たとえば次のようなことがあります。<ul><li>Webのコンポーネントのディレクトリ構成：当初はコンポーネントのディレクトリ構成にAtomic Designを採用しており、コンポーネントの責務が明確になるなどのメリットもあったが、そこまで細かくコンポーネントを分けるメリットを感じなかった。</li><li>GraphQL Client選定：Apollo Clientを採用しているが、SSR時の負荷が高いことや、メモリリークの問題などに直面。</li><li>GraphQL  Server選定：コミュニティが大きいなどの理由からApollo Serverを採用しているが、他のGraphQL Serverに比べてパフォーマンスが劣る。</li><li>Monorepoの採用：リリース時のブランチとmainブランチの差分が大きくなりがち。共通パッケージなどはなく、Monorepoを有効活用できていない。</li><li>エラー設計：エラーの表現やハンドリングの仕方に統一性がない。GraphQLスキーマでエラーを表現する方法やエラーをスローする方法など、チーム全体で共通の理解を事前に確立すべき。</li><li>ログ設計：ログのフォーマットやログレベルに統一性がない。</li></ul>このようにリプレイス途中でも多くの課題が見つかり、今も継続的な改善を実施しています。改善を施してもビジネスや技術の変化や考慮不足から負債は生まれるもので、それとどう向き合うかが大事だと思っています。<h2 id="h9be0c3393d">おわりに</h2>この記事では、出前館Webにおけるリプレイス・リアーキテクトによる技術負債の解消への試みについてご紹介しました。技術やアーキテクチャはより良いプロダクトを作るために、状況に応じて常に変化し続けるもので、最初から完璧なアーキテクチャや技術選定をするのは不可能です。重要なのは、問題や負債を蓄積せず、継続的な改善を行うためのチームや仕組みを築くことだと思います。出前館では、リリース前には自動でのリグレッションテストを実施したり、GitHub Discussionsやミーティングで新しい取り組みへ前向きに議論する場を設けたりし、継続的な改善を積極的に行っています。今後も、より良いプロダクトを作るためにこの姿勢で改善を続けていきます。またどこかで別の改善などをご紹介できればと思います。編集：中薗昴提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a>

出前館フロントエンドはWebの画面単位でのリプレイスを進めています。その事例について、LINEヤフー株式会社の児玉さんが解説しました。


「React」の記事一覧