フロントエンド開発の領域拡大──「濃密に深いファンダム」を支える技術基盤とAI活用の実践

── お二人のエンジニアとしてのバックグラウンドをお聞かせください。

中川：2021年にサイバーエージェントに新卒入社し、FANBASE事業部でWebフロントエンドのチームリーダーを務めています。Webフロント全般の機能開発や継続的な開発環境の構築を担当し、現在はサーバーやインフラ領域にも担当範囲を広げています。

林：2023年入社で新卒からFANBASE事業部に所属しています。プロデューサーやコミュニティマネージャー、クリエイティブディレクターといった、ファンとアーティストをつなぐ職種の方々と近い距離感でエンジニアリングしたいと考え、FANBASE事業部を配属先に選びました。現在は中川さんからWebチームリーダーの役割を引き継ぎ、プロダクトの開発効率化やAI活用による生産性向上に取り組んでいます。

── FANBASE事業部について、事業特性と技術的な取り組みを教えてください。

中川：FANBASE事業部は、多様なアーティストやアイドル、タレントの方々それぞれが求める独自のファンコミュニティのニーズを集約し、それを実現するプラットフォーム「FANBASE」を運営しています。

従来の幅広いファン層獲得に加え、アーティストに深く共感する「濃密で深いファンダム」の育成を重視しており、各アーティストの世界観や特色を活かしたサービス展開を行っています。

── 「FANBASE」に共通基盤がありつつも、各アーティストサイトの特色は異なります。品質を担保しつつスケーラブルなものを維持するために、フロントエンドではどのような工夫をされているのでしょうか。

林：まず、各アーティストで求められる世界観やブランドイメージが根本的に異なることです。例えば、あるアーティストは力強く情熱的な世界観を表現したいが、別のアーティストは温かみのある親しみやすさを重視するといった具合に、同じUIコンポーネントでも表現したい雰囲気が全く違います。

そこで独自のカラーシステムを採用しています。それぞれのサービスの特徴に合った色を同じ形式で定義することで、一つのソースコードで同じキーを参照した時に、サービスごとに異なる色が自動的に割り当てられる仕組みです。この仕組みのおかげで、サービスごとにコンポーネントを作り分けずに共通化できます。これにより、アクセシビリティやデザイン品質も同時に担保できる構造になっています。

中川：コンテンツレベルでの違いも加味する必要がありました。同じ「トップページ」でも、あるアーティストはファン同士の交流を重視してコミュニティ機能を中心に配置したい一方、別のアーティストは最新情報の発信を重視してニュース機能をメインにしたいといった要望があります。従来の設計では、こうした要望に対してプログラムによる条件分岐が増え、処理が複雑化してしまう問題がありました。

これを解決するために、条件分岐を多用せず、インターフェースで状態を出し分ける設計を重視しています。また、状態を出し分ける環境変数は最低限の数だけ使うように制限した上で、サービス毎の全ての状態は TypeScript 上の型システムに集約していたりと、様々な工夫を施しています。

こういったサービス毎の「最適化」を実現するための設計によって、同じページでも表示するコンテンツが根本的に異なるケースでも処理が複雑にならず、サスティナブルに開発し続けられます。また、より多くのサービスを展開するシチュエーションでも開発スピードを下げることなく事業の成長を加速させることが可能になっています。

── 複数のサービスを並行して運用する中で、開発生産性の面ではどのような課題に直面されましたか。

中川：開発を進めた結果、いくつかの新たな課題が生まれました。例えば、複雑な機能を提供するコンポーネント・モジュールの数が増えた影響で、開発に伴うサービスに対する変更を把握しきれなくなって行ったことが挙げられます。1つのサービスならまだしも、複数サービスでそれぞれカラーテーマ・文言・UIが異なるので手作業で変更を追うのは時間を要します。これを解決するため、テストに注力しFeature Flag ごとにE2E テストを実行したり、サービス毎にVRT（Visual Regression Test）を実行するなどのいくつかの工夫を施しています。

加えて、そこでさらに発生した課題は、新しいサービスが増えるたびにCI/CDでの実行時間が延びてしまうことです。例えばVRT（Visual Regression Test）では、全てのプロセスが完了するまでに30分もかかる状態でした。そこで、Pull Requestによって変更された必要な差分だけを検査する最適化を行うなどをして、現在では4分程度で実行できるようになり、開発生産性を大幅に向上させています。

── 開発生産性を高める取り組みをお聞きしましたが、運用の効率化においてどんな工夫をしていますか？

中川：「FANBASE」のサーバーはFanTechで開発している共通基盤を利用しています。そのため、管理画面もすべて一つのソースコードで構築しており、それを複数の事業部で利用している状況です。これを円滑に運用するため、インナーソースという仕組みを活用しています。オープンソース開発の知見を社内開発に取り入れることで、異なる事業部が同じ方向に向かってコントリビュートし、組織のサイロ化を防いでいます。

また、3事業部での並行開発を効率化するため、トランクベース開発を導入し、基本的に一つのブランチにマージを継続する構成で、コントリビュートしやすさと認知コスト削減を実現しています。

── 基盤開発におけるトランクベース開発を行う際のコツや工夫について教えてください。

中川：良かった点はFeature Flagを活用したことです。各事業部が有効化したい機能を自由にカスタマイズできるよう、Feature Flagを抽象化したものを管理しています。開発環境では機能を表示したいが本番環境ではまだリリースしたくないといった細かいカスタマイズが可能な設計にすることで、複数事業部の異なる開発ペースに対応できています。

Feature Flagシステムは自社開発していて、こちらも同様にTypeScriptで管理する設計にしています。誤った設定を行うとコンパイル自体が失敗し、誤ったデータ入力もできない堅牢なシステムにすることで、大規模運用でも安全性を保てています。

林：ユーザー向け機能でも活用しており、各サービスごとにFeature Flagファイルを整理しているため、将来の改修コストとなる技術的負債を生むことなく、「このサービスではこの機能をリリースしたいが、別のサービスでは導入したくない」といったサービスごとの細かいニーズに柔軟に対応できます。

中川：もう一つの工夫として、reminder-lint という linter を使ってソースコード上にあるTODOコメントに期日を設けて、それを超過すると通知が飛ぶ仕組みを活用しています。複数事業部のコンテキストが混在する中でもタスクの抜け漏れがないように開発体制の品質を高める工夫を様々な角度から注力しています。

── これまで開発生産性の向上についてお聞きしましたが、最近注目されているAI活用についてはいかがでしょうか。

林：AI活用による生産性向上にも積極的に取り組んでいて、特にデータ取得の効率化に向けて様々な検証を進めています。例えば、Googleアナリティクスのデータ可視化や分析です。

これまではデータチームに依頼してレポート作成してもらっていましたが、スポット分析が必要な場合も、データチームに「こういうデータが欲しい」「何のために必要か」といった詳細を整理して依頼する必要がありました。

そのワークフローも現在では、Slackをインターフェースとして、自然言語でGoogleアナリティクスのデータを取得できるAIアプリケーションを開発して職種問わず組織全体に提供しています。

これにより、コミュニケーションパスが削減され、意思決定における開発全体の流れを加速できます。例えば、レポート作成コスト無しで、ビジネス職種の方が必要な時にSlackで質問してデータを取得できる点で、まさに生産性向上を実現する仕組みとして非常に価値があります。

── 生成AIがプロダクト開発に浸透した現在、FANBASEではどんなエンジニアが求められてきそうですか？

中川：職種や所属を横断して課題解決できる方ですね。AIを活用する時代とFANBASE事業部の少数精鋭という組織特性との相性が非常に良いと思います。FANBASE事業部で言えば、技術だけでなくアーティストとファンの関係性を深める仕組みづくりに興味を持ってもらえると嬉しいですね。技術においても、Webフロントエンドだけでなくクラウドなど他の領域にもチャレンジできる方は、影響力や事業を加速する力があるので、頼もしいと感じます。

新しい技術を恐れず、常に学び続ける姿勢があれば、アーティストとファンをつなぐ新しい体験を一緒に作り上げられると思います。

林：一つの技術にこだわらず柔軟に対応できるエンジニア、視野を広げてキャリアアップしていきたいという方と一緒に働きたいです。一緒にエンターテインメントの未来を作っていけたら嬉しいですね。