新規プロダクトと大規模プロダクトを通じて見えてきたフロントエンド戦略

リリースから15年、当社を代表するプロダクト「Rtoaster action+」と、新たに開発された「Rtoaster reach+」を支える開発エンジニアが、フロントエンド戦略をご紹介するインタビュー記事です。大規模プロダクト・新規プロダクトそれぞれの面白みや苦悩などを赤裸々に語ってもらいました！

こんにちは。ブレインパッド人事部の見谷です。
ブレインパッドは、企業のデータ活用・DXやデジタルマーケティングを支援する
データビジネス・プラットフォーム「Rtoaster（アールトースター）」をはじめとした、様々なプロダクトを開発・提供しています。

今回はリリースから15年の歴史がある大規模プロダクト「Rtoaster action+」と、新規プロダクト「Rtoaster reach+」のフロントエンド戦略を紹介します。
「大規模プロダクト」と「新規プロダクト」、それぞれの面白みや苦悩に迫っていきたいと思います。


高橋聡プロダクトビジネス本部開発部 reach+フロント開発エンジニア	田中康平プロダクトビジネス本部開発部 action+フロント開発エンジニア

ーー今日はよろしくお願いします！まずはじめに田中さん・高橋さんが現在担当されているお仕事を簡単にご紹介いただけますでしょうか。

田中：
「Rtoaster action+（以下、action+）」のフロントエンドとして、アーキテクチャのリファクタリングを行っています。これと並行して「Rtoaster」ファミリー全体の開発効率を上げるための共通コンポーネントの開発も担当しています。

高橋：
「Rtoaster reach+（以下、reach+）」というLINEやアプリ等のマルチチャネルでメッセージを配信できるプロダクトを開発しています。現在は新規機能の開発も進めつつ、機能改善も担当しています。

大規模と新規、それぞれの醍醐味や苦労とは

ーーではまず高橋さんからお話をお伺いします。「新規プロダクト」というと、柔軟に開発を進められる印象を持ちますが、実際に新規プロダクトを経験されて感じたやりがいや苦労した点を教えてください。

高橋：
やはり新規ということもあり、「市場から何が求められているか」から考え、プロダクト自体をどうしていくかを話し合いながら開発できたのはやりがいに感じました。一方で新規プロダクトのためスピードを優先したことで、可読性や保守性の問題が出てきて、リファクタリングで改善に取り組んでいますが、苦労しているところです。
現在は機能を拡張するフェーズですが、正直なところ拡張に適したアーキテクチャではなかったんですよね。例えば既存のAPI通信を利用しようとしても、mixinの不適切な利用により不要なAPIを呼び出すような実装になっていたり、既存のコードを再利用するにもコードの理解に時間がかかり沢山のコストがかかってしまう状況にありました。

ーースピードを優先した結果の代償もあったのですね…。これらの課題はどのように解決していこうとしているのでしょうか？

高橋：
まずは、独自の実装を減らしていくことです。当時はVue 2 のライブラリで適切なものがなかったため、モーダルを独自で開発していましたが、Vue 3 へとバージョンを上げてモーダルを含む独自の実装をなくすことで、可読性を上げられたと思っています。加えてTypeScriptへ移行し、型をつけることでさらに可読性の向上を図っています。

Rtoaster reach+の実際のUI

ーー田中さんは大規模プロダクト「action+」の開発に携わられていますが、面白みや苦悩という点ではいかがでしょうか？

田中：
「Rtoaster」は、200を超えるウェブサイト、1日あたり1億超のアクセスがあるプロダクトなので、このように非常に多くのお客様に利用いただけているプロダクトに携われるのは貴重な経験だと思います。またレガシーな部分を改善していくことで、目に見えてコードが綺麗に、メンテナンス性が良くなっていくのは気持ちが良いですね。一方で、全体のコードや仕様を理解するのは大変です。また古いフレームワークを使っていたりと、歴史のあるプロダクトならではの苦労もあります。

ーー「action+」はモダナイズに取り組まれているとお聞きしてますが、フロントエンドにおいてはどのような取り組みをされているのでしょうか。

田中：
現場の課題としては、Riot.jsを採用していたことにより開発の効率が良くない面があり、脆弱性の課題やメンテナンス工数が増大していたのでフレームワークを置き換えることから検討をはじめました。フレームワークの選定としてはReactとVueが候補としてありましたが、Vue3のComposition APIによりロジックが切り出しやすく再利用がしやすくなること、TypeScriptとの相性が良いこと、そして何より兄弟プロダクト（reach+、insight+）がVueを使用していたので、Vueを採用しました。

ーー他の開発チームが同じくVueを活用していたことも意思決定の背景としてあったのですね。

田中：
はい。他の開発チームと同じフレームワークを採用することで、リソースの融通もしやすいということも意思決定の背景としてありました。意思決定した当時、NuxtにVue3が対応していなかったため、「action+」はVue2を採用しました。Vue2 でも Composition API を利用できることから、規約を持たせるメリットがあり、今後のVue3化も見据えた上で Nuxt + Vue2 + Composition APIを採用することにしたのです。

ーー採択するフレームワークの選定も開発チームが主体的に行えるのですね！

Rtoaster action+の実際のUI

フェーズが違うプロダクトが隣り合わせにあることで生まれるシナジーとは

ーーフェーズが全く違うプロダクトを開発するチームが隣にいることは、ブレインパッドのプロダクト開発の特徴でもあると思いますが、フロントエンドの領域において互いに意見交換・ナレッジシェアなどはしているのでしょうか？

田中：
各チームのフロントエンド担当が集まる機会は、定期的にあります。その取り組みの一環で「共通コンポーネント化プロジェクト」というものもあります。Rtoasterのaction+、reach+、insight+の社内ライブラリを開発する取り組みで、デザイナーやエンジニアリングマネージャーを含めた5名で行っており、そのためにAtomic Designの導入を進めています。ただこれは読者の方も共感いただけるかもしれませんが、Atomic Designは人・プロダクトによってそれぞれの定義・認識が違ったりするので認識合わせが結構大変です。笑

高橋：
チーム内でも認識を揃えるのが大変なところ、3チームの認識を揃える必要があるので、個人的に1番苦労していることでもあります。笑

ーー想像するだけでも大変そうですね。他にも社内ライブラリ開発の工夫やチーム間で連携していることはありますか？

田中：
現在はaction+とinsight+がVue2でreach+がVue3へ移行中ということで、両方のバージョンで対応できるライブラリを開発しています。バージョンが異なるとビルド方法が違ったりAPIの差分が出たりするので、この部分を吸収できるようにして二重管理にならないようにしています。

高橋：
reach+で新しい画面を開発した際に、田中さんにレビューをしていただいたことなどもありますね。他チームにレビューしてもらうのは設計が偏らなくなるので、とても助かります。

田中：
こういった取り組みは私自身も気づきを得られましたし、もっと実施していきたいですね。