急拡大するエンタメテックを加速させるバックエンド開発とDevOps、インナーソースのあり方

── 現在のお仕事や役割について教えて下さい。

私が所属するFANTECH本部は「ABEMA」等で培ったライブ配信のノウハウや技術を活かし、新たなエンターテインメント体験を提供するサービスを展開しています。

日本をはじめとしたアジアのエンターテインメントを海外からでも楽しめるグローバル向けオンラインライブプラットフォーム「ABEMA Live」、LDHのコンテンツを楽しめるコミュニケーションサービス「CL」、定額音楽配信サービス「AWA」、芸能プロダクション・IPホルダー向けアプリを提供する「FANBASE ARENA」、そしてプロレス動画配信サービス「WRESTLE UNIVERSE」など、多彩なプロダクトの開発・運用をしています。

特に、音楽ライブやスポーツ分野においては、デジタル配信、ペイパービュー、多言語対応のファンコミュニティといったニーズが急速に拡大しています。

私は、FANTECH本部における開発組織FanTech Studioで「FANBASE ARENA」が提供する複数の協業プロダクトに加え、「ABEMA Live」と「WRESTLE UNIVERSE」を合わせた7プロダクトの開発責任者をしています。

FanTech Studioの特徴の1つに、複数のサービスを運用することを前提とした、柔軟性の高いバックエンド開発が挙げられます。現在、FanTech Studioでは計7つのプロダクトのバックエンドを3人で同時に開発・運用しています。

── 開発生産性の向上や工数確保という点ではどんな工夫をしましたか？

視聴傾向やマーケットの移り変わりが早い事業ドメインでは、新機能の追加やビジネスモデルの変化対応を急ぐあまり、ソースコードのメンテナンス不足やテスト不足、開発資産の肥大化やレガシー化が課題となりがちです。これらを放置すると、技術的負債やセキュリティリスクが生じ、システムがビジネスニーズに対応できなくなる可能性があるばかりか、セキュリティインシデントや致命的な障害の発生で、ビジネス継続すら危うくなるケースも多々あります。

事業的には攻めている裏側で、システム的には後手に回っている状況は、開発者としては何としても避けたい気持ちです。

特にライブ配信のような、その日その場限りの体験に価値があるケースの場合、障害が発生すればユーザーに多大な影響を及ぼすため、システムの堅牢性や安全性は事業継続にとって不可欠になります。

そういった課題に対して、FanTech Studioで特に意識しているのは「コードベースを小さく保ち、モダンな作りに変更できる状態を作り続ける」ことです。

既存のコードに機能を追加する場合、コードの可読性低下やテストの煩雑化など、副次的な弊害も発生しがちです。FanTech Studioでは、拡張性を意識した設計をしているため、複雑な依存関係を持つ処理などは少ないです。しかし、十分にメンテナンスされていないソースコードは、新規メンバーのオンボーディングコストや認知負荷が上がってしまったり、不要なテストによるCIの実行時間増加やバグの温床になったりもします。

大きな機能開発やチームの開発思想がアップデートされるタイミングで、関係する処理に不要になった要素があれば、積極的に捨ててから、新規に設計・開発に着手することを重視しています。

こういったプロセスを経ることで、システム的な制約やリスクをクリアな状態にし、ビジネスニーズへの柔軟な対応だけでなく、システム基盤自体に拡張性や汎用性をもたらす結果になっています。

また、バックエンドエンジニアにとっては、既存の設計やソースコードに縛られず、ゼロベースでアーキテクチャを考え直す機会にもなっています。

── 開発生産性についてはどうですか？

何度も実行するようなCI/CDに関連する繰り返し作業は、特に重要になってくると考えています。複数のコミットを1度にまとめてリリースする場合は、複数の開発者にリリースして問題ないかを確認するコミュニケーションが発生します。実装から時間が経過していると、実装者であっても処理を思い出すのに時間がかかるものです。

一方で、FanTech Studioでは、プルリクエストをマージ後に即本番環境にデプロイする戦略を採っていますが、テスト不足によるバグの混入や、設定ミスを含んだ状態でデプロイが行われた際、速やかに正常系へロールバックできる開発体制が整っていないと、本番環境でのインシデント発生のリスクが高まります。

FanTech Studioでは7つのプロダクトを運営していて、1つの変更による不具合が複数プロダクトに波及してしまう可能性があり、事業全体の損失が大きくなるリスクがあります。また、複数プロダクトでインシデントが発生すると、ロールバック作業に多くの工数を割く必要があるばかりか、再発防止のために、本番環境へのデプロイに対して慎重になり過ぎてしまい、どんどん守りの姿勢が強くなってしまいます。

こういった問題を予防するために、Feature Flagsや環境変数を用いて、特定のプロダクトだけ機能を有効化・無効化することを行っています。また、これらの一時的なフラグは削除漏れが発生しやすいため、コードの消し忘れを予防する自作のlinterを用いて削除漏れを防止しています。このツールを使用することで、脳で記憶しておく必要のないことを積極的に忘れることができ、開発生産性を向上させてくれています。

さらに、ブランチの構造をシンプルに保つことや、テストコードである必要のない品質チェックトリガーは実装しないように、品質担保の手法を最適化することにも取り組んでいます。これにより、コードを把握するための工数を下げ、デプロイまでに必要な人的コストを極力減らすことで、エンジニアが本来の開発に集中できる環境を整えることを目指しています。

── 2024年8月には「InnerSource Gathering Tokyo 2024」という技術組織に関するカンファレンスに登壇しています。開発組織においてどんな課題が背景にあり、どんな課題解決が模索されているのでしょうか？

インナーソースへの機運は、会社や組織を超えて世の中に浸透しつつあります。これは社内の開発組織に、オープンソースソフトウェア(OSS)のプラクティスを適用し、車輪の再発明の防止などを目的とした社内コラボレーションを目指すアプローチです。私のチームでは、OSSとして開発されている高品質なシステムに対して、自分の組織に特化した小規模なプラグインをインナーソースとして開発することで、運用の工数を低く維持しつつ課題解決を行っています。

例えば、GrafanaやTerraformなどのOSSプロダクトは、プラグインを作成して自社の運用スタイルに合わせて拡張することが可能です。FanTech Studioでも、いくつかTerraform Providerを開発し、運用の効率化を図っています。

その一例として「PipeCD」のTerraform Providerの開発があります。FanTech Studioでは、アプリケーションのデプロイにPipeCDを利用していますが、当時はデプロイ設定を手動で行う必要がありました。複数のプロダクトを同時に開発・運用する私のチームでは、サービスを提供する国が増えた場合や、運用するプロダクトが増えた場合に、PipeCDの設定を追加する必要があり、手動での設定によるミスも発生していました。そこで、Terraformを利用してデプロイ設定に再現性を持たせることを提案し、PipeCDにコミットしながら、Terraform Providerの開発を主導しました。同様の課題を持つ社内のエンジニアとインナーソーシング活動を行い、私のチームに留まらず、社内での課題解決につなげることができました。

Terraform Providerの開発は一例ですが、サイバーエージェント社内でインナーソース文化が浸透していくと、事業部やプロダクトの壁を超えた透明性の高いコラボレーションが発生し、ソフトウェアの堅牢性や品質の向上、車輪の再発明の防止により、レバレッジの高い開発が期待できます。 

── インナーソースの考え方は事業プロダクトにも適用されますか？

インナーソースは、共通ライブラリやプラグインの領域に留まりません。