「FanTechで日本の閉塞感を打破する」サーバーサイドエンジニアの開発思想

3つ目ですが、ランニングコストの最適化を意識しています。

エンジニアだからこそ、あえて「技術はあくまでも手段」という側面を忘れないように意識しています。システムのランニングコストが膨らんで事業を逼迫するという状況は好ましくなく、エンジニアとして意識しなければならない重要なポイントだと思います。

コスト最適化を意識して作り込んだ機能の事例としては、CyberFightの「WRESTLE UNIVERSE」におけるレコメンド機能が挙げられます。機械学習を活用して、類似コンテンツをユーザーに訴求する機能です。学習と推論は事前に行い、結果をデータベースに格納しています。そのため、ユーザーリクエストに対して都度推論するのではなく、予めまとめて結果を用意しておくため、推論用のサーバーを常に起動する必要がありません。また、学習はクラウド上のサーバーで時間単価の安価な海外リージョンで動かしているため、月々のランニングコストを抑えた運用が実現できました。

2つ目のポイントとして取り上げたローコードな仕組みも用いているため、管理するコード量も削減した状態で運用ができています。

当社のFanTechサービスは共通のプラットフォームで動いているのではなく、全てが独立したサーバーリソースで立ち上がっています。社内の共通基盤を活用しながらも、それぞれのプロダクトは専用の環境で動き、機能を取捨選択することができます。


ここまではサーバーサイドの話がメインでしたが、Webもアプリも複数プロダクトを同時に運用できる作りになっているため、サーバー等の申請の待ち時間を除けば、数日から1週間ほどで開発環境を用意できます。もちろん、クリエイティブなどは専用に用意する時間がかかりますが、機能面にフォーカスすると主要なコンポーネント管理はモジュール化しているので、新たなプロダクトを構築する場合でも複雑な手順なく準備ができます。主要なコンポーネント管理はモジュール化しているので、新たなプロダクトを構築する場合でも複雑な手順なく準備ができます。これは、稼働するシステムの構築に留まらず、サーバーの監視ダッシュボードやコスト監視にも半自動的に反映される仕組みになっており、新しく構築したプロダクトでも運用品質を低下させないように留意しています。統合されたダッシュボードを用いて、サーバーサイドエンジニアが隔日でモニタリングを行っており、品質面で懸念があればすぐに修正する習慣が付いています。

これは、今後管理するプロダクトが増えていっても、特別な意識をせずとも、品質管理まで含めた環境構築が可能ということです。

このスピード感と品質管理は、事業の成長スピードに沿った開発効率を目指したチームの大きな成果と言えます。

ー 事業やプロダクトの長期的な成長に伴い、ソースコードがレガシーになるなどの技術的負債に関して、どのような対応をしていますか？

事業が始まってから約4年経つ事業ですから、開発したけど使われなくなった機能や、複雑化してしまった処理が残っているのも確かです。

これらが今後の開発速度を低下させないように、新機能を開発する時に、障壁となる技術的負債を先に解消してから新規開発に着手する事を続けていて、一定の効果を発揮しています。

先日も「WRESTLE UNIVERSE」のPPV(ペイ・パー・ビュー)機能を追加する際に、過去に実装していた決済機能とそれに関するソースコードで、削除可能なものは全て削除し、今見えている事業の今後を見据えた形でメンバーに再設計してもらいました。

また、こういったリファクタリングは日常的に行っており、チームメンバーも常に何かが改善されている状況を作り続けています。

もちろん、開発のベロシティは一時的に落ちてしまうのですが、普段からそれを徹底することによって、トータルで見た時にアウトプットの量や質は上がっていると考えています。

処理が複雑化して認知負荷やメンテナンスコストが高くなったコードは、生産性の低下につながります。「いつか直さなきゃ」と思いはするものの、目の前のタスクやToDoを考えると気持ちも前向きになりにくいです。

チームの雰囲気づくりという意味でも、「技術的負債をクリアして、常に自分たちのプロダクトをブラッシュアップしている」という空気感が、エンジニアとしての成長実感にもつながるので、チームビルディング的にも大切な事だと思っています。

ー 最近取り組んでいる技術的チャレンジについて教えてください。

リリース中のサービスにおける、特定機能のON/OFFを容易に切り替えられるフィーチャーフラグ（Feature Flags）の手法を取り入れています。フィーチャーフラグを実現するシステムはいくつか存在していますが、私のチームでは海外展開をしているプロダクトがあり、その点でのパフォーマンス要件を満たせるものが存在していませんでした。

そこで、私のチームではマルチリージョンで低レイテンシーである要件を満たすフィーチャーフラグの機構を作り、低コストで運用しています。


それによって、新機能の検証や安定した運用を実現することができます。

例えば、運用中のサービスに実装した新機能で不具合が発生したとしても、フィーチャーフラグを活用して該当する機能を即座にオフにすることができます。開発チームに所属しているユーザーにはデバッグ用に機能をオンにするなど、柔軟な条件に対応することで、技術的なチャレンジやその検証に有効活用できると考えています。

また、その機構は単純な機能のON/OFFに限らず、動的に返す値を変更するデータ配信サーバーとして構築しました。先述したサーバーの台数を時間帯に応じて変動させる機構でも応用しています。
 

ー 開発環境が充実し、時にはノーコード、ローコードでアプリが開発できる時代になってきました。そんな時代の中で、今エンジニアを目指している学生に、アドバイスがあればお願いします。

そんな時代に逆行するようで恐縮ですが(笑)、学生のうちから、とにかく手を動かしてコードをたくさん書くことをおすすめします。それこそ、呼吸するぐらいあたりまえの感覚でコードを書けるようになっていないと、本質的でないところで時間を使ってしまいます。

最近のサイバーエージェントの事業を見ていても感じるのは、「インターネット × ○○業界」のような、掛け算のインパクトで社会の課題を解決するようなものです。

"新しい未来のテレビ"を目指す「ABEMA」のような、大規模プロダクトに参画したとして、コードを書く以外のことに意識を向けられないと、サービスの本質や複雑なビジネス要件を読み解くことができなくなってしまいます。

私自身は、学生時代にゲームをフルスクラッチで作った経験があって、入社後「ABEMA」での開発時にその恩恵を感じましたし、より多くの技術課題に向き合うようになった今でもそれを感じています。それこそ、日本語を書くように、呼吸をするかのようにコードを書けると、技術的なチャレンジの数やPDCAも増えますし、技術的な課題に直面した時も、速いテンポでTry & Errorを繰り返す事ができます。

学生のうちにコーディング力や実装スピードを身に付けた上で、社会人になってそのスキルをビジネス課題の解決に集中できるようになれば、世の中にインパクトを与えられるプロダクトを自らの手で生み出せるようになるはずです。