こんにちは、Webエンジニアの平井です。この記事は Enigmo Advent Calendar 2021 の16日目の記事です。

現在、私はBUYMAのSellチームに所属していて出品者関連システムの実装を担当しています。今季最も注力した受注リストページのRails化プロジェクトについて、プロジェクトの概要、プロジェクトを進める上で工夫した点、失敗した点について書きたいと思います。

Rails化プロジェクトとは

もともとBUYMAはPHPで実装されたシステムで、その実装をRuby on Railsで書き換えるのを弊社ではRails化と呼んでいます。 Rails化する目的は以下になります。

PHPの古いフレームワークで書かれた手続き的なコードをオブジェクト指向なコードに書き換えて可読性、可用性を上げる。
不要な処理を無くし、レスポンスタイムをあげる。

受注リストページについて

受注リストページはBUYMAで発生した受注が一覧で表示されていて、出品者がその受注情報を確認したり、受注に対して発送通知などのアクションを実施するために用意されたページです。

出品者にとって利用頻度が高いページで、施策で修正する頻度が高いもののPHPの古いフレームワークで実装されているため修正のコストがかかるのがネックでした。

また、絞り込み機能が乏しく、出品者が目的に沿った取引を絞り込めずに各アクションを実施するのが大変という企画サイドの要望も有りました。ですので、今回はRails化に加えて、検索機能の充実化も開発スコープに含めてプロジェクトを進めました。

システム概要

クライアントサイド

クライアントサイドは、実装スピードを上げるため大部分はerbで実装しました。ただ、検索フォームに関しては共通コンポーネントを利用したかったため Reactを使いました。

サーバーサイド

すべてRuby on Railsです。また、BUYMAでは検索サーバーにSolrを利用していて、この受注リストでも例外なく受注の検索はSolrを使っています。ただ、旧受注リストではSolrを直接利用していたためSolr特有のパラメーター生成処理なども実装されていました。そこで、検索エンジニアの方にAPIを開発してもらい新受注リストからはそのAPIを利用して検索処理を実装しています。 APIを利用したため、Solrの専門的な知識が不要でアプリケーション側の実装の負担がかなり減りました。

工夫した点

ドキュメントの作成

Rails化プロジェクトの難しいところは、PHPで書かれたソースコードを読み正しく仕様を理解することです。旧受注リストには、出品者が利用する様々な機能が実装されていますがまとまったドキュメントがなかったのでソースコードを呼んで仕様を理解する必要があります。ドキュメントがあれば非エンジニアとのコニュニケーションがスムーズに進むのでこのタイミングでドキュメントを作成しました。また、実装とドキュメント作成を別々で行うとどうしてもドキュメント作成が後回しになってしまうため、実装しながらドキュメントも同時に作成するように工夫しました。

ドキュメントを作成した事で、デザイナーやQA担当の方とのコニュニケーションがスムーズに進んだと思います。

フィーチャーフラグの利用

リリースの負担を減らすために、フィーチャーフラグを利用しました。リリースブランチに受注リストRails化に関わる修正をマージし、該当ブランチを毎週リリースすることで新受注リスト公開時のリリース負担を減らすことが出来ました。

追加機能の優先度付け

リリーススケジュールに関しては、12月のセール時期より前に新受注リストをリリースしたいという企画側の要望が有りました。そこで、企画サイドとコニュニケーションを取り追加機能の優先度を決めて、リリース目標日までに実装すべき機能とそうでない機能を切り分けました。優先度を決めたのが功を奏し、目標としていたスケジュール日通りに基本的な機能をリリースすることが出来ました。

ユーザーインタビュー

企画的な内容になりますが、企画サイドの担当者の方が、新しく実装する機能やデザインについて多くの出品者に対してインタビューを実施してくれました。リリース後に追加機能に関してネガティブな意見がほとんどなかったのもこのインタビューのおかげだと思います。

失敗した点

テスト環境でのパフォーマンス監視

そもそもRails化プロジェクトの目的としてレスポンスタイムの向上があるのですが、テスト環境でのパフォーマンス監視が不十分だっため旧受注リストよりも、新受注リストのほうがレスポンスタイムが遅くなってしまいました。原因としては, N+1とerb上でのrenderメソッドの多用です。現在、絶賛修正中です。