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


PHP+jQueryをReact+Next.jsに移行。出前館Webが選択したリプレイス戦略

「Loglass 経営管理」「Loglass IT投資管理」などを運営する株式会社ログラスは、成長著しいスタートアップ企業のひとつです。「Loglass 経営管理」は2023年7月に3周年を迎え、サービスの実績としてはARR前年比3.2倍を実現しました。ログラスVPoEである伊藤博志さんに、過去に行った技術的意思決定のなかで印象に残るものを聞きました。


プロジェクトやキャリアを成功させる必須要素「3つのP」とは。ログラスVPoEに聞く開発体制改善の秘訣

DIGGLE株式会社でエンジニアリングマネージャーをしている岡崎と申します。普段はエンジニアチーム全体のマネジメントを担いつつ、開発業務も行っています。DIGGLEは予実管理クラウドサービス「<a href="https://diggle.jp/" target="_blank" rel="noopener noreferrer nofollow">DIGGLE（ディグル）</a>」を提供するスタートアップであり、「<a href="https://rubykaigi.org/2023/" target="_blank" rel="noopener noreferrer nofollow">RubyKaigi 2023</a>」の<a href="https://rubykaigi.org/2023/sponsors/#sponsor-498" target="_blank" rel="noopener noreferrer nofollow">スポンサー</a>を担うなどテクノロジーやそのコミュニティへの投資を積極的に行っています。本記事ではDIGGLEのエンジニアチームが、どのように技術的負債解消を行っているかについてご紹介します。<h2 id="h48ed43c917">工数の何%を負債解消に充てるかを四半期ごとに経営と合意する</h2>技術的負債解消は、エンジニアチーム単体でやり切るにも限界があり、経営陣の理解を得ることが重要です。弊社はCTOが共同創業者であるため、エンジニアの意見が経営陣へダイレクトに届き、経営陣の技術に対する理解度が非常に高いのが特徴となっています。CTOから技術的負債がビジネスに及ぼす影響を経営陣に説明することで、技術的負債解消の重要性を経営陣も理解し、技術的負債解消に対して一定の工数を割くことができる状態になっています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/90021b12fa5c4ad2b95ae2b93b342a63/image4.jpg" alt="" width="1920" height="1290"><figcaption>CTOがProductチームと経営陣のハブとなっている</figcaption></figure>実際にどの程度の工数を割くかについては、四半期ごとに、私とCTOで技術的負債解消に割り当てられる工数の目安を相談して決めています（おおよそ20%程度に収まることが多いです）。このような仕組みにすることで、技術的負債を会社全体の関心事として捉え対応することが可能となり、「日々の作業が忙しくて技術的負債解消を行うことができない」という状態に陥らないようにしています。実際に、技術的負債解消の中で解決した問題を弊社のエンジニアブログで取り上げていますのでご紹介します。<a href="https://diggle.engineer/entry/fixed-issue-railsapp-caused-by-updating-ruby31-to-ruby32" target="_blank" rel="noopener noreferrer nofollow">Ruby のバージョンを 3.1 系から 3.2 系にアップデートしたら Ruby on Rails アプリの動きが変わったのを解決した話</a>DIGGLEでは経営陣に技術に対する理解があるためこうした体制を実現できていますが、読者の中には「なかなか経営陣に技術的負債解消の重要性を理解してもらえない」という環境の方もいらっしゃるかもしれません。その場合は、臨機応変に可能な限り権限が高い方（CTO、部長、リーダーなど）と技術的負債解消の重要性を共有し、組織やチームで継続的に技術的負債に対応できるように働きかけていくことから始めると良いと思います。そして、技術的負債の解消により得た実績（工数が削減した、バグが減少したなど）を収集することで、技術的負債解消がどのような好影響を与えたかを定量的に測れる仕組みを作ることが肝要となります。そうして計測した数値を基に、経営陣と根気強く対話をし、ゆくゆくは会社全体で技術的負債に立ち向かえる環境にしていきましょう。参考までに、弊社で計測している数値をご紹介します。弊社では以下の数値などを四半期ごとに計測し、CTOを含む開発チーム全体で状況を共有する仕組みを作っています。<ul><li>どの作業にどのくらいの工数が掛かったか（新規機能開発 / 既存機能改善 / 技術的負債解消 など）</li><li>本番環境でどのようなバグが発生したのか（インシデント / デザイン崩れ / 軽微なバグ など）</li><li>上記のバグ対応でどのくらいの工数が掛かったか</li></ul><h2 id="h374361b6fc">開発作業の終わりにリファクタリングを行う文化</h2>弊社のエンジニアチームには、開発作業が終わったタイミングでリファクタリングを行う文化があります。これは私が社員3人目として入社した2019年当時から存在しているのですが、開発作業が終わってPull Requestを投げる前に、リファクタリング用のタスクを切って、コードの整理やテストコードのバリエーション追加などの対応を各エンジニアの裁量で行う文化です。これにより、常日頃から各エンジニアが個人レベルで意識を持って作業し、「そもそも技術的負債がたまりにくい土壌」が作られています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b13cf930af924a2a8cbdcef3f932f86e/image8.jpg" alt="" width="1417" height="643"></figure><h2 id="hfea3fe6791">TODOやFIXMEを放置しない仕組み</h2>エンジニアの皆さんは共感してくださると思うのですが、ついつい書いておきたくなってしまうTODOやFIXMEは、時間が経って数が多くなってくると以下のような問題が起こります。<ul><li>多過ぎてどこから手をつけてよいかわからず、結局放置する</li><li>時間が経ち過ぎて、書いた本人すらどんな内容だったかを覚えていない</li><li>コメント量が少なくて、そもそも何に対するTODO / FIXMEなのかがわからない</li></ul>弊社では、これらの解決策として「TODOやFIXMEを書く場合はJIRAにタスクとして挙げ、TODOコメントにはJIRAのリンクを記載する」というルールを作っています。これにより、先ほどの問題点は以下のように解決することができます。<ul><li>多過ぎてどこから手をつけてよいかわからず、結局放置する→常日頃使っているJIRA上でタスクとして確認することが可能になる</li><li>時間が経ち過ぎて、書いた本人すらどんな内容だったかを覚えていない</li><li>コメント量が少なくて、そもそも何に対するTODO / FIXMEなのかがわからない→JIRAの本文に背景・内容を記載することで把握ができる→バックログリファインメントで新規JIRAタスクを確認する際に、背景・内容が理解できるものになっているかチェックすることができる</li></ul>上記運用に際して、Pull Requestレビュー時に目視でチェックすることは難しいため、TODOやFIXMEにJIRAリンクを付けていないとエラーになるようにCIを組んでいます。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/fa06a9c72c4042138f0afb4a685dce92/image5.png" alt="" width="1207" height="218"></figure>参考までにrubocopのソースコードを添付します。<pre><code class="language-ruby">class TodoComment &lt; RuboCop::Cop::Base
 include RuboCop::Cop::RangeHelp

 MESSAGE = &apos;Annotation comment, with keyword `%&lt;keyword&gt;s`, should have JIRA TASK (ex: DEV-N).&apos;.freeze

 def on_new_investigation
 processed_source.comments.each_with_index do |comment, index|
 next unless first_comment_line?(processed_source.comments, index) ||
 inline_comment?(comment)
 annotation = RuboCop::Cop::AnnotationComment.new(comment, keywords)
 next unless annotation.annotation?
 next if jira_task?(annotation)

 register_offense(annotation)
 end
 end

 private

 def register_offense(annotation)
 range = annotation_range(annotation)
 add_offense(range, message: format(MESSAGE, keyword: annotation.keyword))
 end

 def first_comment_line?(comments, index)
 index.zero? || comments[index - 1].loc.line &lt; comments[index].loc.line - 1
 end

 def inline_comment?(comment)
 !comment_line?(comment.loc.expression.source_line)
 end

 def annotation_range(annotation)
 range_between(*annotation.bounds)
 end

 def jira_task?(annotation)
 annotation.comment.text.match?(/DEV-\d+/)
 end

 def keywords
 %w[TODO FIXME]
 end
end</code></pre><h2 id="h92a239a3a7">ライブラリのアップデートを、SaaSを使って自動で行う</h2>弊社プロダクトは主にRuby on RailsとReactで構成しているのですが、gemやnpmなどのアップデートは<a href="https://depfu.com/" target="_blank" rel="noopener noreferrer nofollow">depfu</a>というサービスを使って、自動でPull Requestを作成する仕組みにしています。depfuで作成されたPull Requestについては、逐次対応するのは大変なので（後述のセキュリティアップデートは異なります）、3カ月に1回、エンジニアチーム全体で分担してdepfuが作成したPull Requestの確認と、必要に応じた修正をしています。セキュリティアップデートについては、即対応が求められるものとなりますので、毎朝Slackに通知を飛ばします。アップデートがある場合は、デイリースクラムで担当者を割り当てて即日中にリリースするような仕組みとなっています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/8f995f55d8f143b2b0aec5cd37ef86f6/image7.jpg" alt="" width="565" height="225"><figcaption>Slack上でのセキュリティアップデートの通知キャプチャ</figcaption></figure><h2 id="h447e0f8f3a">OSのミドルウェアアップデートは週次で自動実行する</h2>次にサーバーのOSミドルウェアのアップデートについてですが、弊社ではAWS Fargateを利用し、Docker imageを使ってリリースしていますので、Docker image内でのライブラリアップデートをどのように行っているかについてご説明します。各サーバーが利用しているDocker imageに関しては、CIにより週次でライブラリのアップデートを行っており、各エンジニアが意識することなく、日々のデプロイを行うタイミングで最新のライブラリが自動適用されるようになっています（もちろん、試験環境で動作検証を実施してからリリースを行っています）。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/009be8374642472984c853378494c3c4/image2.png" alt="" width="1067" height="674"><figcaption>週次でDocker imageを更新しているGithub Actionの図</figcaption></figure><h2 id="h27325700b4">バグやSlow Queryを自動検知する</h2>弊社では<a href="https://www.bugsnag.com/" target="_blank" rel="noopener noreferrer nofollow">Bugsnag</a>というサービスを使って、バグが起きた際にSlackへ通知を飛ばす仕組みを作っています。バグについては、営業時間内であれば即時、営業時間外であれば次の営業開始時に確認します。そして、この仕組みに相乗りする形で、Slow QueryについてもBugsnag経由でSlackに通知が飛ぶように設定しているので、同じフローで確認ができるようになっています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b3dd7aa7c2884c3abdcd593a2d983e8d/image6.png" alt="" width="814" height="396"></figure><h2 id="h97864f4768">積極的に自動化やシステム化をする</h2>技術的負債解消に限ったことではありませんが、弊社では、前述したように自動化できるものは積極的に自動化しています。そして、自動化できないものについてもスクリプトを組むなど、なるべく人が行わなくて済むような仕組みを構築することを重要視しています。自動化・スクリプト化する理由としては、工数削減と、ルール化・仕組み化の抑止の2つが挙げられます。<h3 id="h905af46c97">工数削減</h3>こちらは想像しやすいと思いますが、自動化することにより手作業で実施するよりも工数を削減することができます。これにより、エンジニアの対応が必要な技術的負債解消に注力することが可能となります。<h3 id="h2e318cd4ca">ルール化・仕組み化の抑止</h3>定常的に何かをチェックしたり、対応したりする必要があるものについて、手作業で対応を行う場合、チェック表であったり、手順書であったりを作成することになると思います。そういった資料を用いつつ、ルールや仕組みを作って運用していくのですが、1つ2つであれば問題ないものも、数が多くなってくると把握が難しく、窮屈に感じるようになってしまいます。そのため、弊社では可能なものについては自動化・スクリプト化し、ルールや仕組みをなるべく増やさないように心がけています。上記2点の結果として、余分なところに貴重なエンジニアのリソースが割かれてしまうことを抑止できます。効率よく必要な箇所へ工数を注入することができるようになり、それが日々増えていく技術的負債に対する特効薬となります。<h2 id="h3bcda3e6b0">最後に</h2>以上、DIGGLEにおける技術的負債解消方法を、いろいろな切り口でご紹介しました。技術的負債はエンジニアを苦しめる問題であり、技術的負債が多ければ、それだけエンジニアの職場環境は悪いと言えます。そして逆に言えば、技術的負債の解消はエンジニアの職場環境改善の一助となります。この記事が、読んでくださった方の職場環境改善の一助となることを願い、本記事を締めさせていただきます。編集：中薗昴提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a>

予実管理クラウドサービス「DIGGLE（ディグル）」を提供するスタートアップ企業DIGGLEのエンジニアチームが、どのように技術的負債解消を行っているかについてご紹介します。

「技術的負債の解消」の記事一覧