はじめに

こんにちは！
株式会社BlankrでTechLeadをしている原田です。

弊社では、『ライドリ』というクリエイターの活動を支援するプラットフォームを運営しています。

2021年からライドリの前身となるサービスの運用を開始し、「オンライン握手会」「SNS」「ファンクラブ」機能など、様々な機能の追加を行ってきました。

今回は、サービス開始から3年が経過した2023年に、メンバー3名で1年かけてサービスを全てリプレイスしたことについて紹介します。

リプレイス後、チームの生産性が向上・バグの問い合わせ数が減少・ページの読み込み速度が向上するなど、様々な効果が得られました。

ぜひ最後までご覧いただけたらと思います。

目次

はじめに
目次
ライドリとは
なぜリプレイスすることになったのか
何をやったのか
- ドメインの再設計
- ユビキタス言語の統一
- データベーステーブル、バックエンド、フロントエンドの再設計
- バックエンドのGraphQL化
- Nuxt 2からNuxt 3への移行
- 画像最適化
- 画像ストレージをCloud StorageからCloudflare R2に変更
- デザイナーさんと連携しFigma運用ルールを作成
結果どうなったのか
まとめ
エンジニア募集中！

ライドリとは

ライドリでは、現在4つの機能を提供しています。

オンライン握手会機能
SNS機能
メッセージレター機能
ファンクラブ機能

オンライン握手会機能

オンライン握手会機能では、Web上でクリエイターとファンが1対1で会話を行うことができます。

「通常握手会」「限定握手会」「ファンクラブ握手会」の3つの種類に分かれており、それぞれクリエイターに還元される報酬やファンの参加費用、参加できる条件などが異なっています。

SNS機能

ライドリを利用することで、クリエイターは活動の記録を残し、ファンは推し活動の記録を残すことができます。

SNS機能では、活動の記録や推し活動の思い出を投稿することができ、ユーザーはコメントやいいねを行うことができます。

メッセージレター機能

メッセージレター機能では、ファンがクリエイターに対し、感謝の気持ちや応援メッセージを送ることができ、クリエイターに報酬が還元されます。

ファンクラブ機能

ファンクラブ機能では、クリエイターが自由にファンクラブを開催することができます。

記事の投稿や、ファンクラブ加入者限定で握手会の開催を行うことなどが可能です。

なぜリプレイスすることになったのか

2023年時点で、「3種類のオンライン握手会機能」「SNS機能」「メッセージレター機能」が存在し、「報酬機能」「決済機能」などサービス運営に必須な機能を含むとデータベースのテーブル数は80を超えている状況でした。

そんな中、以下の理由をもとにリプレイスを決断しました。

ドメイン要素が大幅に増えることになった

上記の機能に加えて、新たに「ファンクラブ機能」を追加することになりました。

ファンクラブ機能では下記のような機能の提供が決まっており、これに伴いドメイン要素が大幅に増えることになりました。

プラン管理機能
サブスクリプション決済関連機能
記事機能
加入者専用握手会機能
ファンクラブ報酬支払い機能
SNS機能にファンクラブ関連の投稿を表示する機能

3年分の技術負債が蓄積していた

サービス開始時は、「オンライン握手会機能」、かつ現在は3種類ある中の通常握手会のみの提供でした。

3年の間で「2種類の握手会機能」「SNS機能」「メッセージレター機能」が新しく追加されましたが、
メンバーもフルコミットメンバー2名、副業メンバー1名の3名で開発を行っていたため、
設計レベルからのリファクタリングは行えず、技術負債が蓄積していました。

ドメイン設計が適切ではないことにより、データベース・バックエンド・フロントエンドまで影響が及んでいました。

Nuxt 2のサポート終了

サービス開始時から使用していたNuxt 2のサポートが2023年末に終了することが決まっていました。

Nuxt 3ではComposition APIが導入され、Nuxt 2のOption APIとは記載方法が異なるため、完全な移行には時間がかかることが予測されていました。

「ファンクラブ機能」追加に伴い、Nuxt 2での開発を行ったとしてもNuxt 3移行時に再実装の必要があるため、このタイミングでのNuxt 3への移行を検討することになりました。

デザイン通りの実装ができていなかった

開発速度を重視していたことや、技術負債が原因でリグレッションバグが発生し、デザイン通りの実装ができていないことが多くありました。

UX向上のため、技術負債の解消とデザイナーさんとの連携強化が必要な状況でした。

ページの読み込み速度が遅かった

画像の最適化不足やバックエンドのリクエスト効率が悪く、ページの読み込み速度が遅い状況でした。

これを改善するため、バックエンドの再設計が必要な状況でした。

エンジニアのキャッチアップ速度が遅い

技術負債により、今後参画する新規メンバーのキャッチアップに時間がかかると予想されました。

プロダクトのスケールや機能追加を考慮し、早期に技術負債の解消が必要と判断しました。

何をやったのか

サービスを全てリプレイスするために、以下の項目を実施しました。

ドメインの再設計

既存のドメイン・新たに追加されるドメインを整理し、依存関係を再設計しました。

具体的には、Notionを使用し、すべてのドメインとドメインに紐づくActionを全て書き出しました。

書き出した内容をもとに、Mermaidで依存関係を可視化し、設計をしました。

ユビキタス言語の統一

サービス内で使用される用語を統一し、可読性向上やコミュニケーションを円滑にするため、ユビキタス言語の統一を行いました。

こちらもNotionのデータベースを使用し、用語・意味・コード上の表現・ドメインカテゴリーをまとめました。

データベーステーブル、バックエンド、フロントエンドの再設計

ドメインやユビキタス言語の統一をもとに、再設計を行いました。

メンバー全員がフルスタックエンジニアである強みを生かし、各ドメインごとにデータベース、バックエンド、フロントエンドの一連の実装をイメージしながら、最適な設計を行いました。

バックエンドのGraphQL化

今まではREST APIを使用していましたが、GraphQLを使用することにしました。

ドメインが増えたことにより、フロントエンドでの型の扱いや通信のオーバーヘッドが気になっていたため、GraphQLを導入することで、フロントエンドの開発効率を向上させることができると考えました。

ディレクトリを既存のREST APIのものと、GraphQLのものに分け、GraphQLディレクトリにて再実装を行いました。

Nuxt 2からNuxt 3への移行

Nuxt 3のComposition APIを使用し実装を行いました。

vueファイルとは別に、.logic.ts ファイルを作成し、ロジックを切り出すことで、コンポーネントの見通しを良くしました。

（詳しくは別の記事で紹介予定です）

画像最適化

ページの読み込み速度を向上のため、CloudFlareのImage Resizing機能を使用し、画像のキャッシュおよび、必要なサイズへリサイズしてデータ取得を行いました。

画像ストレージをCloud StorageからCloudflare R2に変更

ストレージコスト削減のため、画像ストレージをCloud StorageからCloudflare R2に変更しました。

Cloud Storageの際は、バックエンドに画像データを送りバックエンドにてアップロードを行っていました。

Cloudflare R2では、署名付きURLを使用し、フロントエンドから直接アップロードを行いました。

デザイナーさんと連携しFigma運用ルールを作成

命名ルールやFigma上でのコンポーネントルールを作成し、実装をFigmaに合わせることで、デザイナーさんが想定するデザイン通りの実装を行えるようにしました。

結果どうなったのか

サービスの運用を行う傍ら、1年かけて全てリプレイスした結果、以下のような効果がありました。

可読性・保守性の向上

最適な設計になったことにより、可読性・保守性が大幅に向上しました。

リプレイス後、4名のエンジニアが参画してくれましたが、理解しやすいとのフィードバックを受け、迅速に開発に参加していただくことができました。

メンバーのインタビュー記事はこちらからご覧ください。

バグの問い合わせ数の減少

技術負債を解消し、コードがシンプルになったことで、バグの問い合わせ数が減少しました。

リプレイス前と後で比較した際に、月平均20%問い合わせ数が減少しました。

ページの読み込み速度の向上

Google PageSpeed Insightsで計測した結果、リプレイス前と後で比較した際に、パフォーマンススコアが22向上しました。

リプレイス前

リプレイス後

こちらは一番読み込みに時間がかかるTOPページを計測した結果ですが、TOPページの画像はまだ最適化されていないため、さらにスコアの向上が見込まれます。

UIデザイン崩れの解消やリグレッションバグの減少

コンポーネントの設計の最適化や、デザイナーさんとの連携を強化したことにより、UIデザイン崩れの解消やリグレッションバグの減少が確認されました。

まとめ

今回の大規模改修により、技術負債を解消し、コードがシンプルになったことで、UXの改善や開発効率の向上を実現できました。

日常的なリファクタリングは行われていたものの、設計レベルの改修は隙間時間に行うことはできないため、エンジニア以外のメンバーの理解と協力を得ながら、1年かけて改修を行いました。

上記の結果を踏まえ、弊社では新しいドメインが追加されるタイミングに、関連するドメインの整理や設計の見直しを行うことで、技術負債の蓄積を防ぐようにしています。

今回、開発メンバー全員が可読性・保守性向上の重要性を再認識し、日頃のコードレビューや設計レビューにおいて、その観点を意識するようになった点は大きな成果と考えています。

大規模改修フローやドメインレベルからの最適化することによって得られる効果など、ぜひ参考にしていただけたらと思います！

（詳しい内容は需要があれば別記事でまとめたいと思います〜）

エンジニア募集中！

株式会社Blankrでは、ライドリの開発に携わっていただけるエンジニアを募集しています！

Go言語、Nuxt 3、GraphQLなどの実務経験がある方大歓迎です。

下記に各種リンクを記載していますので、ぜひご覧ください！

求人

正社員募集

業務委託募集

インタビュー記事

サービス