新規サービスにスケーラビリティは必要？
興味深いことに、エンターテインメント事業本部では特に決まったサーバーアプリケーション構成はなく、リードエンジニアが使いたいフレームワークやミドルウェアを好きに決定しているという。また、通信プロトコルに関しては、JSON-RPCの採用が多いというが、このあたりもリードエンジニアの好みに任されているのだそう。インフラは基本的には自社のデータセンターを使用。ただし、コスト優位な部分ではAWSを積極的に活用している。
当たるかどうかわからない新規サービス。そのスケーラビリティについてどこまで考慮すべきか、迷う人も多いだろう。しかし、沖津氏は「スモールスタートであろうとも、スケーラビリティの確保は必須だ」と力強く語る。
それを裏付けるかのように、エンターテインメント事業本部のサービスやプロダクトが使用するインフラでは、あらゆるコンポーネントが疎結合化、多重化されている。インフラの基本構成は、データベースがマスター／スレーブ／バックアップ構成。キューイングによる非同期化を行い、MyDNSによるDNSラウンドロビンであらゆる向きを分散している。
そのほか、データベースの垂直分割や水平分割（シャーディング）に、ローンチ前から対応するかどうかについては、サービスの性質や規模を鑑み、インフラチームと相談して決定。また、DeNA独自のインフラ特化型共通モジュール（通称Baranモジュール）により、スケーラビリティ確保の効率化を実現している。このモジュールには、DeNAが蓄積してきた大規模運用ノウハウが詰め込まれているという。
「これらのノウハウを有効活用するからこそ、スピード重視のスモールスタートでありながら、スケーラブルなサービス開発が実現できている」（沖津氏）
分析とプロモーション、そしてひたすら前に進む
沖津氏の話はサービス、プロダクトのKPI（重要業績評価指標）に及んだ。DeNAでは、分析をかなり重要視しており、優先度も高いという。分析は、自社製の分析プラットフォームを利用して行われる。「DeNAに入ってびっくりしたのが、エンジニア以外のプロデューサーやプランナーがHue（Hadoop用GUIツール）を使い、HiveQLを駆使してサービスなどの分析を行っていること。その結果をデイリースタンドアップ（朝礼）でエンジニアに見せ、よく議論している。とにかく、数字に強いプロデューサーやプランナーが多い。そこが当社の強みでもある」（沖津氏）
DeNAでは、全APIのアクセスログをHDFS（Hadoopの分散ファイルシステム）に格納している。アプリの起動ログ（アクティブユーザーやリターンレートの計測に必要）や画面ごとの表示ログ（画面遷移や離脱ポイントの確認）を基本として、その他のログはサービスごとに必要な場所で取るようにしているという。特に、アプリの入会に関しては初めから細かくログを埋め込んで、離脱ポイントを分析。「ローンチ前にここまで最低限準備しておき、あとは数字を見ながら、みんなでひたすらフィードバックを繰り返していく」（沖津氏）。
加えて、沖津氏はプロモーションの重要性も強調した。「基本的にリリースして何もしなければ、何も起こらない」（沖津氏）。ストアからのオーガニックの流入は、良くてデイリー30～40ダウンロード。ダウンロード数が1桁ということも珍しくないという。
ユーザーがいないと検証ができないため、そういった場合には広告経由で意図的に一定量のユーザーを流入させて効果測定を実施する。最近、比較的よく使っているのはFacebookAdやTwitterAdで、双方とも「ユーザー属性を絞り込める上に低コストで流入させやすい」（沖津氏）というのが理由とのこと。また、一部のアプリでは、オンラインだけでなくオフラインプロモーションも実験的に実施し、効果測定を行っている。どのような方法を使うかは、サービスに応じてチョイスしていると沖津氏は説明する。
このようにエンターテインメント事業本部では、開発から運用、プロモーションまで、新規事業開発に必要な業務に何でも取り組んできた。「1年経って言えるのは、とにかく余計なことを考えずにチームや自分の目標に集中し、コトに向かうのが最も重要だということ。ひたすらフィードバックループを回して、こつこつと前に進むしかない」（沖津氏）。
最後に沖津氏は会場に次のように訴えかけ、セッションを締めた。「我々の目標は一つ。みんなで世界で勝つこと。面白そうだなと思った人がいたら、ぜひ一緒に頑張りましょう」
