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化」

<a href="https://identify.co.jp/" target="_blank" rel="noopener noreferrer nofollow">identify株式会社</a>は、個人が販売した動画素材を企業が購入して、マーケティングへ活用することを支援する「DeLMO」というクリエイタープラットフォームを運営しています。その「DeLMO」では、クリエイターがスキマ時間に動画を撮影・販売し、報酬を得ることができる複業支援サービス「<a href="https://www.delm0.jp/" target="_blank" rel="noopener noreferrer nofollow">DeLMO for creator</a>」と、企業が縦型ショート動画素材を簡単に収集し、クリエイティブ制作に活用できるサービス「<a href="https://biz.delm0.jp/" target="_blank" rel="noopener noreferrer nofollow">DeLMO for advertiser</a>」の2つを提供しているのです。同社の取締役CTOを務めるのが岩崎 裕馬さん。彼は水天宮前（茅場町、人形町、日本橋）にあるレストラン「<a href="https://winenabe.jp/" target="_blank" rel="noopener noreferrer nofollow">ワインと鍋</a>」のオーナーでもあるという変わった経歴の持ち主です。これまで岩崎さんは、CTOとしてどのような技術選定を行ってきたのでしょうか。<h2 id="h540e03485e">GoやNext.jsを採用。“攻めた”技術選定をした意図とは</h2>――このインタビューでは、岩崎さんがidentifyで取り組んできた技術的意思決定の事例について伺います。「DeLMO」の技術選定においては、「長期的に見た場合のプロダクト開発効率」「エンジニアの採用難易度」「自分自身にとっての面白さ」という3つの観点を大切にしました。まず、サーバーサイドの言語としてGoを採用したことについて話します。私がソフトウェア開発において大切にしているのは、改善をスピーディーにくり返せることです。プロダクトを作る際には、自分たちの立てた仮説がそもそも本当に正しいのかわからない状態で開発を進めることが多いです。もし仮説が誤っていたり、方向性を変えるべきだったりする場合には、柔軟に軌道修正することが必要になります。その際、Goではある程度の型の支援があるため作り直しやリファクタリングが容易なんです。何か問題があっても、ビルドが失敗するためすぐに気づけます。それから、コードベースの規模が小さくても大きくても、かけたエネルギーに対して書けるコードの量が一定であるのがGoの良いところです。Goでは、プロダクトの規模が小さいフェーズでも、大きくなってからも、エンジニアが1のエネルギーを使ったら1のコードを書けます。言語やフレームワークによっては、プロダクトの規模が小さいうちは1のエネルギーで10のコードを書けるけれど、規模が大きくなったら10のエネルギーでようやく1のコードが書けるといったように徐々に開発生産性が落ちるものもあります。Goの場合はそれがないですね。開発効率という観点で言えば採用技術としてRuby on Railsなども候補に挙がりましたが、現代のWebアプリケーションはSPAを取り入れていることによってフロントエンドとバックエンドが分離されることが多く、バックエンドはJSONを返却する役割に徹することがほとんどです。そこで、「Goを使ってもそこまで開発効率が変わらないのではないか」と考えました。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/c5c092a0ac6c4139b58adeb1be058d32/image4.jpg" alt="" width="1999" height="1334"></figure>「エンジニアの採用難易度」についても話すと、RubyやPHPなどは採用候補者がたくさんいる言語であるものの、初学者のエンジニアの割合も高いため、スキルの高いエンジニアかどうかの判断が難しいかもしれないと感じていたんです。反面、当時Goをやっていたのは技術的好奇心の強いエンジニアが多かったため、Goを採用することでスキルの高い方と出会いやすくなるのではないかという感覚を持っていました。また、「自分自身にとっての面白さ」については、私は個人的に新しい技術を使うのが好きなので、そういった点からもGoを面白いと感じています。それに、Goは使用できる文法が良い意味で限られているため、コードを書く際に迷いが少ないです。仮にモチベーションが低いときであっても、一定の開発生産性をキープできます。――フロントエンドに関してはいかがですか？フロントエンドはNext.js＋TypeScriptを採用しています。私がidentifyに参画してプロダクトを開発し始めたのが2019年7月なのですが、当時はVue.jsとNuxt.jsが全盛期でした。でも、「フロントエンドにおいてもいずれは型安全性が重視されるようになるため、Vue.jsとNuxt.jsではなく、TypeScriptフレンドリーなフレームワークが流行するだろう」と予想していました。そして、私はモダンなフロントエンド開発のスキルがそれほど高くないため、何か大きめのフレームワークのエコシステムに乗って開発を進めたいという思いもありました。そんなタイミングで、2019年7月にNext.js 9がリリースされ、Dynamic Routingがサポートされたんです。これなら実戦投入できると思い、採用を決めました。当時、フロントエンドのスペシャリストである<a href="https://twitter.com/mizchi">mizchiさん</a>が「Next.jsを使うといい」という話をしていたのも、導入する理由になりました。結果的に、サーバーサイドはGoでフロントエンドはNext.jsという構成はスタートアップでは当たり前に使われる構成になりました。これによって、エンジニアの採用にもかなりプラスの影響が出ています。それから、フロントエンドとサーバーサイドの両方に関係する話として、GraphQLを使いたかったためgqlgenのライブラリを採用しています。知人であるgfxさんから「GraphQLはいいぞ」という話を聞いていて、きっと今後流行するだろうなという予想をしていました。私はgfxさんの技術的な審美眼を信頼しており、実際に調べてみると利点が大きかったため、採用を決めました。<h2 id="hea581b21e4">CIや単体テストなどを初期フェーズから整備しておくべきだった</h2>――ここまでは技術選定のポジティブな点ですが、その逆に反省点はありますか？事業を立ち上げた当時は、売れるプロダクトを作ることが第一だと考えて、機能開発を優先して技術的負債を蓄積してしまいました。ですが、それらを後から解消するのにかなり苦労したため、もっと早めのフェーズから課題に向き合っていくべきだったと思います。――この記事を読まれる方のなかにも、同じようにアーリーフェーズのスタートアップで働いており、なるべく早急に売れるプロダクトを作らなければならない状況のエンジニアもいるかと思います。その方々に、ご自身の経験を踏まえてアドバイスはありますか？アプリケーション開発の定石を理解したうえで、100点は無理でも70点くらいの開発環境の整備を目指すのがいいと思います。“70点くらいの状態”の具体例を挙げると、1つ目はCI環境を構築して、Lintや単体テストなどが自動実行される状態を作ることです。2つ目は単体テストを書いておくこと。決してすべての分岐を通るようにする必要はなくて、特定メソッドの1つの分岐しか通らないテストだとしても構いません。テストが全くない状態のアプリケーションにテストを足していくのと、最低限のテストが書かれている状態のアプリケーションを改善していくのとでは、労力がまるで違います。3つ目は、インフラの環境をなるべくマネージドサービスに切り替えること。私たちはかつて、Jenkinsを用いてジョブの実行などを行っていました。でも、サーバーの管理作業を自分たちで行う必要があるため運用の工数がかかるとか、ミドルウェアやインストールされている言語のバージョンを上げづらい、スケーラビリティに難があるなどの問題が生じていたんです。現在はJenkinsを脱却して、すべてのジョブをCloud Run jobsとBatch for Google Cloudで動かしています。これによりシステムのポータビリティが向上し並列実行も容易になりました。「DeLMO」では事業の特性上、1日あたり数百件から数千件の動画の変換処理が発生します。そうした処理をBatch for Google Cloudで動かせるようにしたことで、変換がスピーディーに終わるようになりビジネス改善やコスト削減につながりました。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/da876eed70a74f6caaa52c84060d5df9/image1.jpg" alt="" width="1999" height="1334"><figcaption>インタビュー取材は、岩崎さんがオーナーを務める「ワインと鍋」にて実施した。「クオリティの高い料理やワインを手頃な価格帯で提供したい」という思いから、岩崎さんは同店をオープン。「ワインと鍋」はITコミュニティ内で知名度の高い店舗であり、来店する顧客の8割以上はソフトウェアエンジニアやプロダクトマネージャー、デザイナーなのだという。</figcaption></figure><h2 id="hbdd0849bab">採用するライブラリを“取り替え容易な状態”にしておく</h2>――他の技術選定の事例はあるでしょうか？これは失敗談なのですが、社内向けの管理画面を作る際に、「UIライブラリを使って楽ができないだろうか」と思ってAnt DesignやHeadless UIを採用しました。Ant Designは、中国のAlibaba社が開発した、UIを作成する際に役立つ多数のコンポーネントを備えたUIフレームワークです。また、Headless UIについては私たちが用いているTailwind CSSとの親和性から選択肢に上がりました。素早く管理画面を作っていく必要があったことや、社内向けの管理画面だから3年くらい経てば作り変えればいいという思いもあり、これらのライブラリの導入を決めたんです。Ant Designはとても便利なライブラリなのですが、Reactのバージョン18との相性が悪く、特定のコンポーネントがかなりCPUを消費するようになってしまいました。Ant DesignのISSUEなどを追ってみたところ、その問題が解消される見込みはありませんでした。また、思っていたよりもAnt DesignやHeadless UIでの開発がしづらかったこともあり、当初の予想よりも早めに別のライブラリに切り替える必要性が生じてしまったんです。――この事例を踏まえての学びはあるでしょうか？これはUnix哲学にも通じる部分ですが、なるべく特定の役割だけを担うような薄いライブラリを使って、交換が容易な状態を維持しておくべきだと思いました。Ant Designはライブラリの担っている役割が広くて、UIに関する機能とFormの操作に関する機能をどちらも持っているんですよね。それもあり、React Hook Formを入れづらかったり、TypeScriptによる型の支援が受けづらかったりしました。幸い、管理画面の一部でしか使ってないライブラリなので、多くの苦労をせずに取り除けると予想しています。今後、Headless UIはshadcn/uiなどに切り替えていく予定です。余談ですが、これからのフロントエンドのUIライブラリにおいて大事なのは、「AIフレンドリーであること」だと私は思っているんですよ。基本的に、デザインのトレンドは数年スパンで変わりますから、どれだけ優れたライブラリであっても絶対に技術的負債になります。今後はそうした技術的負債を、人間ではなくAIが返済するような世界になっていくと予想しています。だから採用するUIライブラリも「AIが理解しやすいコードかどうか」を重要な判断軸にすべきだと思っていますね。<h2 id="h610163f11c">副業のメンバーに「わかりやすい正解がある仕事」をお願いする</h2>――それ以外の工夫はあるでしょうか？ライブラリのアップデートや型定義・単体テストの追加、技術的負債の解消といったタスクは「必ずやる必要があるが緊急度は低い仕事」です。そういった業務の多くを副業のエンジニアにお願いしているのは、identifyの開発組織の特徴だと思います。――副業のメンバーにうまくワークしてもらうために重要なことはありますか？まずは先ほどの説明にも通じますが、Lintや単体テスト、CI環境をきちんと整備することが大事だと思っています。私は副業や業務委託で参画した方に「既存コードを壊していいですよ」と言っているんですよ。要するに、機能が壊れることを恐れず、どんどんリファクタリングをやってほしいんです。仮に既存機能が壊れてしまったとしても、CIで守っているからすぐに気づけます。それから、「わかりやすい正解がある仕事」をお願いすることですね。たとえば「○○のライブラリのバージョンを○○に上げて、その状態ですべての機能が動く状態にしてほしい」とか「テストのカバレッジが○○％だけれど、これを○○％まで上げてほしい」などの要望であれば、目指すべき成果が明確なんですよね。認識の齟齬が生まれにくいので、副業のメンバーにも任せやすいです。<h2 id="h89ce011cd0">「すべてがアイデンティティになる時代をつくろう」</h2>――今後、岩崎さんがidentifyで実現したいことについても教えてください。identifyは「すべてがアイデンティティになる時代をつくろう」というビジョンを掲げていて、この状態に1歩でも近づけるように尽力していきたいと思っています。個人的な話をすると、私はもともと家が貧しかったのと低学歴だったため、いざ働くとなったときに就職先の選択肢が少なかったことを覚えています。そういった方々の選択肢を広げることに協力できたらと考えています。これまでどんなキャリアを歩んできた人でも、自分の個性を発揮して生きていける世界を作れたらいい。テクノロジーを活用することで生活や仕事のマイナスを取り除いて、みんなが楽しく生きられるような状態にしていきたいです。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/efa3a7ec2d094da1856bd0b3e08c5c3e/image3.jpg" alt="" width="1999" height="1334"></figure>――すてきなビジョンだと思います。最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？「何の技術を採用すべきか」に、わかりやすい正解はないと思っているんですよね。でも、技術的意思決定において「何を考慮すべきか」については、方法論がパターン化されていると思うんですよ。そういった知識を持っておくと、自分自身も明確な判断基準に基づいて決断できますし、他の人たちにも納得感を持ってもらいやすいと思います。特定の事例を学ぶというよりも、事例の裏側にある“技術的な意思決定の意図や背景”を学ぶことが大切です。そして、その意思決定に用いる変数は事業の状況や世の中のトレンドによっても変化します。たとえば、最近では生成系AIが流行しており、それが技術選定にも影響を与えています。数年前までの自分であれば、“AIフレンドリー”という言葉は絶対に使っていなかったと思うんですよね。だからこそ、適切な意思決定ができるように、技術選定の方法論やその判断材料となる情報などを、常に学んでいくことをおすすめします。取材・執筆：中薗昴撮影：山辺恵美子取材協力：<a href="https://winenabe.jp/" target="_blank" rel="noopener noreferrer nofollow">ワインと鍋</a>提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a>

identify株式会社は、個人が販売した動画素材を企業が購入して、マーケティングへ活用することを支援する「DeLMO」というクリエイタープラットフォームを運営しています。同社の取締役CTOを務めるのが岩崎 裕馬さん。彼は水天宮前にあるレストラン「ワインと鍋」のオーナーでもあります。これまで岩崎さんは、CTOとしてどのような技術選定を行ってきたのでしょうか。


identify CTO兼「ワインと鍋」オーナー岩崎さんに聞く。過去の技術選定とそこから得た学び

こんにちは、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ヤフー株式会社の児玉さんが解説しました。


「Next.js」の記事一覧