DeNA TechCon 2018に行ってきました

DeNA TechCon 2018に行ってきました。
聴講したセッションは以下の通りです。

内容を改めて振り返りつつ、レポートとしてまとめていきたいと思います。
※あくまで自分がメモした内容を書き連ねているものであり、 各タイトル下のリンクにあるスライドの内容が正しいものとなります。

Keynote - エンジニアが引っ張るDeNAの"モノづくり"

エンジニアが引っ張るDeNAの"モノづくり"

概要

DeNAの歴史を振り返り、それぞれのシーンでエンジニアがどのような挑戦をしてきたかという話。
また、掲げているミッション・ビジョンに合せてエンジニアのあり方、モノづくりをどう捉えているか語られていた。

  • ミッション
    • Delight & Impact the World 世界に喜びと驚きを
  • ビジョン
    • インターネットやAIを活用し、永久ベンチャーとして世の中にデライトを届ける

DeNAの歴史を大きく分けると以下の3つ

  1. 1999~ : EC, SNS
  2. 2009~ : モバイルゲーム,ゲームPF
  3. 2013~ : 事業多角化

EC, SNS

  • ビッターズ、モバオクの開発
    • ネットオークションに参入するもヤフオクが先行していたため苦戦
    • ヤフー以外のポータルサイトと協業し、流入を確保する
    • そしてモバイルが次に来るということでモバイルオークションへ参入

モバイルゲーム,ゲームPF

  • Mobageの開発

    • エンジニアがサービス設計を主導
    • 使いやすさに拘り抜いて開発
    • 川崎氏が1人で3ヶ月で開発
      • 1人のエンジニアがサービスを考え抜いて開発をしていくことが理にかなっている
      • 要件定義から実装まで、1人で考えながら手を動かすことでスピードも出る
      • もちろんサービスの規模が大きくなれば1人ではカバーしきれなくなるが、
        最初に動くものを作る上では1人で考え抜く方が早くちゃんとしたものが作れる
  • Mobageの負荷分散

  • グラブル

事業多角化

  • タクベルの開発

    • タクシー配車システムを支えるハードウェアの開発
    • コネクテッドカー向けの新しいアーキテクチャ
      • 車載端末からユーザー向けアプリまで幅広く開発
    • AIを駆使した移動需要予測と供給の最適化
      • 配車の指示に関係なく、通常運行において乗車時間・客数のアップを図る
  • 自動車事故削減に向けたCV技術を活用

    • Deep LearningベースのCV技術
      • CVをエッジ(車載端末)で動作させる組み込み
    • 運転行動指標を算出するデータサイエンス

まとめ

  • サービスづくりをエンジニアが引っ張る
    • いいモノづくり = Delight につながる
  • サービスの課題を高い技術力で解決
    • サービスの拡大 = Impact につながる

感想

  • 市場において先行する、あるいは他にない規模のサービスを展開する上で技術的な挑戦は不可欠。
  • いかなるサービスも最初はプロトタイプ開発からであり、エンジニアが主体となりスピード感とこだわりを持って開発するべき。
  • サービスの種類やフェーズによって問われる技術やエンジニアとしてのスタンスは少し異なるが、
    いずれにしても技術によって課題解決を図ること、サービスを考えながら開発に取り組むことが重要なのだと思った。

SWETの取り組むImage Based Testing

SWETの取り組むImage Based Testing

概要

DeNA社内でテストの自動化やエンジニアの生産性向上のためのツールの開発・導入などを行うチームであるSWETが、 どのような技術開発を行ったかについての事例紹介。 以前からDeNA TechConなど社外発表の場において技術開発事例紹介をしてきたが、 今回はWeb ApplicationとMobile Game(Native Game)におけるImage Based Testingについての紹介。

SWETのミッション

  • DeNAのサービス全般の品質向上
  • エンジニアの開発生産性向上

Web Applicationにおける事例紹介

  • WebApplicationにおけるVisual Regression Testingの紹介

    • Visual Regression Testingとは
      • Web Applicationのキャプチャを取得し、見た目のデグレーションを検出する自動テストの手法
      • 正しいキャプチャ画像と現在のサイトの差分比較
        • レンダリング結果の崩れ
          • 表示されない、文字化け、レイアウト崩れ
  • 既存のVisual Regression Testingに関するサービス

  • Visual Regression Testingの課題

    • キャプチャ取得ロジックの実装コスト
      • Seleniumの学習コスト
      • 非同期処理・リトライ処理の扱い
      • テスト対象ページに関する知識
    • 管理コストが高い
    • サービス側にUIテストへの理解がある人がいないと厳しい
      →汎化するためにスクリーンショットクローラを活用
  • スクリーンショットクローラ

    • 自律的にサイト内を巡回・テスト対象ページを見つけ出す
  • モチベーション
    • UIテストに詳しくなくても自動テスト管理できるようにしたい
  • クローラ利用の流れ

    1. 設定ファイルの設定 (対象ドメイン、キャプチャに関するパラメータ、ブラウザの指定)
    2. 自動キャプチャ、スクリーンショットをストレージに保存
    3. テスト
  • 並列化

    • スクリーンショットを撮るのは時間がかかる
    • 幅優先検索 + グローバルなタスクキューで並列化の実装
      • 排他ロックはとらず、たまにある重複は許容する
  • クローラ部分のシステム構成

  • 画像差分の確認

    • githubの利用
    • masterブランチに正解データを入れ、masterとの差分を目視で確認
  • まとめ

  • 課題

    • フォーム入力
      • サイトごとにカスタムロジックをかく→最初の問題に逆戻り
      • フォームを検出して自動で埋める技術が必要
    • 同一ページ内の状態変化
      • 取得したいキャプチャは1ページ1枚とは限らない
      • レンダリング結果の違いを自動で検出する
  • 展望
    • 機械学習によるUIの意味認識

      • 意味に基づくエレメント取得
    • Webページの意味解析技術

      • 先行研究 Using Semantic Similarity in crawling-based web application testing
      • HTMLをパターン認識して、UIエレメントの意味やページ状態を推定する
    • 会員登録フォーム意味推定

      • 精度としては大体100%近くから50%くらいまで
      • 全結合三層のNN
        • 深層学習ではない
      • トピックごとに精度の差があり
        • 生年月日はselect boxなので判別しやすい
        • userIDはサービスの名前が入ってきたりもして判別しづらい、など
      • ポップアップなどのパーツへの拡張
      • 学習データの拡張と深層学習の適用予定

Mobile Gameにおける事例紹介

※ ゲームアプリ = Mobile Game(Native Game)

  • ゲームアプリのUIテスト自動化の現状

    • web/ネイティブアプリはテスティングツール・ライブラリやノウハウが整備されており、UIテストの実装を行いやすい
    • ゲームアプリに対してはそういったデファクトのツールやプラクティスが整っていない
  • ゲームアプリのUIテスト自動化の難しさ

    • web/ネイティブアプリでは画面の構成情報をxmlやhtmlから取得可能
    • ゲームアプリだとOpenGLなどで描画されるため、構成要素の情報をセマンティックな形で取得できない →画像情報のみで状態や構成要素の情報を取らなければならない
  • 画像処理技術を使って自動化

    • Open CVのテンプレートマッチング
  • テンプレートマッチングとは

    • 特定の画像パターン(テンプレート)が存在するかを判定
  • 画像処理を使った自動化へのハードル

    • 画像処理および画像処理ライブラリに関する知識の習得
    • 画像処理に向いた言語の習得
    • イメージアセットの管理
    • 閾値のチューニング →これらの面倒なところを省力化するためExMachinaを開発
  • Exmachina

    • テスト用イメージアセットの管理
      • ページ単位、ページ情報という形で管理する
      • 識別子(Identifier)とどのような操作が可能か(Action)を管理
    • ページの判定機能
      • 画像データをインプットとしてそれがどのページに該当するのかを判定
      • セマンティックな情報を使ったテストが可能
    • ページ判定機能を使ったテストシナリオの自動化
      • テストシナリオは簡易に記述できるようにしてある
      • 画像処理やAction実行といった複雑な処理はバックエンドで吸収
  • シナリオテストの自動化からクローラへの応用

    • テスト用イメージアセットの管理(Identifier, Action)から、現在どのページにいるか、どのようなアクションが行えるかを取得可能
    • クローリング結果の比較
      • 画面遷移の差分と、ページの画像的な差分を取れる
    • 意図せぬUIの変更や、エラークラッシュの検出が容易になる
  • まとめ

    • アプリのページ情報を管理する
    • セマンティックな情報に基づいたテストを実現
    • バックエンドで画像処理など複雑な処理を吸収するため、画像処理を意識せずにテストプログラムを組める
    • ゲームアプリに対してもVisual Regression Testができる
  • 課題

    • ページ登録作業(テスト用イメージアセットの情報登録作業)の省力化
    • 複数解像度への対応
  • 対応

全体まとめ

  • Web ApplicationとMobile GameそれぞれにおいてImage Based TestingによるUIテストの自動化を行った
  • 今後、さらなる自動化・省力化のために機械学習を活用していく

感想

  • それぞれの事例において個別のプロダクトに依存しない汎用的な形、かつ利用者にとって導入コストが低くなるように作られていて素晴らしかった
  • 品質・生産性の向上を図る上で自動テストの存在はもはや欠かせないものだが、その維持コストを極小化するために機械学習の導入というアプローチが取られるのは手段としても技術的にも興味深い話だと思った

大規模ゲーム開発におけるBuild高速化と安定化

大規模ゲーム開発における build 高速化と安定化

概要

大規模化するゲーム開発においてビルドの高速化、安定化には大きな価値がある。 ビルドの高速化、安定化のためのUnity、Jenkinsにおけるプラクティスの紹介と、 その他自動化、ワークフロー改善事例の紹介。

大規模複雑化するスマートフォンゲーム開発の課題

  • 高品質かつ多機能
  • 短いスパンでの機能、イベントの提供
  • 特にアセットの容量が肥大化、ビルド時間が膨大に
  • ライトからコアユーザーも遊べる複雑なゲームスキーム
  • グラフィックスも2Dから3Dへより高品質へ
  • 複数のGameイベントを週替わりでリリース →お客様を飽きさせないために様々な取り組みを並行で走らせなければならない

  • 生じる問題

    • コンテンツ・Asset大容量化→ビルド時間が膨大→毎日QAを回せない→品質が悪い→お客様に満足してゲームをPlayしてもらえない
  • Build高速化は非常に価値がある

    • try and errorを回しやすくする
    • QAを回しやすくする

Buildを高速化して課題を解決(Unity・Jenkins)

  1. Unityプロジェクトのリポジトリをキャッシュ
  2. AssetBundleの差分Build
  3. 分散・並列Build(プラットフォーム、開発案件ごと)
  4. その他

    • スペックが高いマシンでbuildしているか
    • 対象ノードでウィルススキャンが実行されていないか
      2,3についてUnity/Jenkinsの実践を交えて紹介
  5. 最大のボトルネックはUnity AssetBundle Build 差分buildで高速化しよう

    • Unity AssetBundle Build高速化方法
      1. 一度buildしたAssetBundleファイルと同時に生成されるManifestファイルをgitで管理する
        Unity側でManifestファイルをみて高速化してくれる
      2. Assetは更新すべきファイルだけ、差分でbuildする
      3. フォルダの差分を検出するのは単純ではない
        フォルダに含まれるアセットが別フォルダの共有アセットへ依存している
      4. 共有アセットを含めフォルダの差分を検出したい
  6. EditorUtility.CollectDependencies()を使うことで共有Assetも差分検出できる
    (AssetBundle 対象のフォルダついて、Asset の依存関係も含めて実ファイルのハッシュ値を計算する · GitHub)

    • AssetBundle対象フォルダは以下の各種Asset + Assetが依存するすべてのアセットファイル → フォルダ内のすべての実ファイルハッシュ値が計算できる
  7. このようにあらゆる高速化を組み合わせる必要がある

  8. Jenkinsを活用した分散・並列Build

    • Jenkins Master/Slave全体構成
      1. Jenkins masterへの命令通知
      2. 各Slaveでの処理
        Client Build, AssetBundle Build, Master validation, preprocess, migration, deploy, etc...
      3. アプリのupload, githubへの自動コミット, BaaSのデプロイ
    • 並列開発をしていると、キューが詰まるため、案件・ブランチごとにslave nodeを分ける
  9. Jenkins - Platformごとに分散Build

    • Build Flow pluginのparallelブロックを使うことでノードごとに分散・並列実行できる NodeLabel Parameter Pluginを利用
    • Nodeごとに同じJobは同時に一つだけ実行できるようにしたい場合はThrottle Concurrent Builds Pluginが使える
  10. Jenkins - 同一開発ブランチで排他制御

DeNAのゲーム開発はSakashoを使いサーバレスアーキテクチャが主流に

  • Baasを用いると開発効率は上がるが、migrationについては別アプローチが必要

    • 手動オペレーションが入ると障害が発生する
    • データマイグレーションの最適化・徹底した自動化が必要
      • 4つのフェーズでマイグレーションを最適化、自動化を徹底
        merge → validation/build → migration → deploy
    • 手動でmergeコンフリクト解消も大変
      • merge祭りjob導入
        • merge作業を自動化、人為的なコンフリクト以外は自動的に解消
        • ほぼコンフリクトの内容は自動で解消できる、現在のブランチを正とする
    • 手動でデータ更新は不整合が起こる
      • データMigrationを徹底して自動化
      • 先々起きるわからない問題は考えず、手動が入ることでの事故を防止するために徹底的に自動化
        • 極力シンプルなJobで設計する必要がある
  • マイグレーションを自動化するJobインターフェース

    • Configuration / Run に分離
    • パラメータを設定するだけで使い回せるよう共通化
    • コケたjobから容易に再実行
      その際に省略可能なjobのチェックを外す
    • cronで時間起動する

大規模開発に適したgitワークフロー 1. エンジニア以外も全員gitを使う 2. エンジニアを介さずにpull requestをmerge出来るまでワークフローを熟考する
危険なデータがマージされない仕組みを考え抜く
すべてのAssetはimportする際にチェックして所定の場所に配置
キャラクタ、マップ、クエストはパラメータから自動生成
MasterはJenkins JOBでスプレッドシートから自動pull request 3. 事故が起きたらエンジニアが責任を持って振り返る覚悟でやる

まとめ

  • 大規模化されていくゲーム開発に対して改善を積み重ねていくことが大事、絶えず改善することで安定化できる
  • 様々な改善策は毎日考え続けることである日パッと思い浮かぶ
  • スマートフォンゲームはまだまだ大規模化する

感想

  • ゲーム全体のアーキテクチャや更新データ入稿の頻度などによって具体的なプラクティスは異なりそうだが、どのような環境においても通じる考え方を聞くことができてよかった
  • 特に並列開発におけるフロー整備やJobの切り分けについては最初から完璧にできるものではないが、常に改善を続けることでやがて品質の底上げにつながるということを実感しているので、非常に参考になり面白かった

DeNA TechCon2018 ゲーム体験を支えるための強化学習

DeNA TechCon2018 ゲーム体験を支えるための強化学習

概要

逆転オセロニアにおけるAI開発の取り組みについて現状の開発事例と今後の展望についての紹介

ゲーム領域におけるAI開発の背景

  • 逆転オセロニアについて
    • 戦略に応じてバランスよくデッキを構築する必要がある
    • ルールはシンプル、戦い方は多様で奥深い
    • キャラクタースキルの微妙なバランスや流行によってゲーム環境が日々変化している
  • キャラクタースキルのバランス調整をミスなく、効率的に行いたい
    • 絶妙なバランスを保つ難易度が高い
    • ゲーム環境はどんどん複雑になるので調整コストも爆発していく
    • ミスをするとゲームの品質を落とす、ゲームバランスの毀損
  • 解決したい運用課題
    • 新しいスキルの評価が正確にできない
    • キャラクターの性能テストにかかる工数が大きい
    • チューニングを続けても見落としリスクがある
      • すべてのユーザーセグメントの体感を検証するのは難しい
  • 実現できたら嬉しいこと
    1. リリース前の新しいスキルでも検証ができること
      自律的なキャラクター運用の学習
    2. 大量の検証によって性能を評価できること
      シミュレータを使った大量の自己対戦の実現
    3. 壊れケースを効率的に検知できること
      人間のようなリテラシーで合理的に探索する方法の実現
  • 新環境でも柔軟に運用方法を獲得する強いAIの実現

  • 強化学習を使ったアプローチ
    強化学習とは
    ある環境下で、目的とする利益を最大化するための戦略(行動系列)を獲得する機械学習の一種

    • 未知の環境(新しいゲーム環境)に対しても学習が可能
    • 試行錯誤を繰り返しながら自律的に学習ができる
  • 強化学習とゲームタスク

    • 近年の強化学習技術の進展によって様々なゲームにおいて高いパフォーマンスを出した研究が報告されている
    • オセロニアではランダム性や不完全情報も取り扱うためチャレンジング
  • 研究開発ロードマップ
    4つの技術を組み合わせ環境に柔軟に対応する強いAIを作る

    1. 教師あり学習
      そもそも学習ができるのか検証(プレイヤーの対戦ログを使用)
      大量の棋譜ログを活用し人間が実際に打つような打ち手を学習
    2. 表現学習
      キャラクター運用の特徴を学習
      キャラを拡張できるか検証
    3. 強化学習
      自己対戦による自律的な学習
    4. 先読み機能
      数手先を読むことによる推論的な学習、強化学習時の学習サポート

AI技術の紹介

  • 教師あり学習

    • 上位プレイヤーの対戦棋譜を用いて作成
      • 入力データ(特徴量)
        • ステータス
        • 手駒・デッキ情報
        • 選択可能な行動
        • 盤面情報
      • 出力データ(教師信号)
        • プレイヤーが選択したかいなかのバイナリ変数
  • アーキテクチャ概要

  • 実験結果

    • 既存NPC(ルールベースAI)に対して高い勝率が出せている
    • AIはチューニングによって既存ルールベースAIより大幅に強くなる
      • 意味のある戦術を学んでいることが示唆できる
  • 設定と工夫点

    • 選択・非選択を教師信号として再利用
      • 人間のようにプレイするAIを獲得したい
      • 上位プレイヤーの負けた情報も有効活用
    • ネットワーク・学習の詳細
      • Batch Normalizationは有効、Dropoutは弱め
      • 活性化情報:ELU(ReLUよりも有効だった)
      • 損失関数:Cross Entropy
    • 大量の棋譜があるためデータ読み込みを効率化
      • 並列化、キューなどを駆使してデータ読み込みを効率化
  • 表現学習

    • 何ができるのか
      • キャラクターを低次元のベクトルで表現できる
        • キャラクター数分の次元から固定次元に削減できる
        • モデルサイズ削減、学習速度向上が期待できる
      • 運用方法が似たキャラクターは同じような表現になる
  • アーキテクチャ

    • 低次元ベクトルを獲得する埋め込み層を行動入力の後に導入
    • マルチタスク学習としてモデルを訓練する
  • 獲得した表現の可視化

    • キャラ表現を2次元に削減しプロット
      • 戦略に応じた表現が得られる
    • 低次元ベクトルを活用して教師あり学習・強化学習を効率化
  • 強化学習

    • 自己対戦による自律的な学習
  • アーキテクチャ

    • 通常のDQNは出力が前もって行動の数だけ固定されている
      • オセロニアでは潜在的な行動空間が膨大なため現実的ではない
    • 動的に変わる行動を扱えるネットワーク構造を採用
  • 自己対戦による成長

    • 強化学習エージェントは自分自身と対戦して自律的に戦略を学ぶ
      • 対戦相手も自分と同様に成長
    • 過去バージョンを使用
      • 実際は様々なAIエージェントを相手として用いる(教師あり学習エージェント、ルールベースAI、etc...)
        • いろんな対戦相手に対応するため
  • 実験結果

    • ある特定の状況ではゼロからミドルレベルのプレイヤー並みまで成長することが確認できている
  • 難しさと対策
    オセロニアへの強化学習の適用には複数の難しさがある

    • 毎ターン取れる行動の種類が変わる(可変長行動)
      • 可変長行動を扱うネットワーク構造の使用+表現学習
    • 豊富な計算資源を使っても実験に時間がかかる
      • 教師あり学習の結果を強化学習の初期化に一部使用した効率化
    • いろんな戦術の相手 + 不完全情報
      • 様々な戦略を持つAIエージェントとの自己対戦
  • 先読み機能

    • 先読みを行いながら木構造としていろんなの系盤面の系列を表現
      • 大量のシミュレーションを行い、ある局面での最善手を決定
      • モンテカルロ木探索を使用
    • 現在の局面から次にとりうる行動を試す
    • 行動後は敵ターン含めてバトル終了までランダムなプレイを行う
    • 終了時の勝敗を行動の評価値とする、これを大量に繰り返し取るべき行動を決める
  • オセロニアでの活用案

    • 強化学習との組み合わせによるAIの強化
      • 推論サポート
      • ミスが許されない勝ち筋を見つけやすくなる
    • 先読み機能だけでも教師あり学習・強化学習と同じような強さが確認できている
      • 不利なデッキ同士の対戦でも高い勝率
      • シミュレータの計算速度に依存した課題も存在
  • まとめ

    • オセロニアにおけるAI開発では課題を細かく分解し、柔軟に既存技術の改造と新規技術の発案をしている
      • ドメインごとに異なる性質を深く理解する事が大事
      • 複雑なゲームに既存技術を単純に適用するだけではうまくいかない
    • 今後の見通し
  • Webツールを活用したチューニング

    • AIの戦いを可視化するWebツールを使用してチューニングをサポート
      • 統計量の可視化
      • AIの人間らしさを検証

今後に向けて

  • プロジェクト観点で難しい点、嬉しい点

    • 学習環境をゼロベースで作る必要がある
      • 強化学習研究で使われるゲームは扱いやすい学習環境が既に存在
    • シミュレータ速度がボトルネックになる
      • 多くの試行をするために、応答をどれだけ高速化できるかが鍵
    • ドメイン固有の情報を扱うため特徴両エンジニアリングが複雑
    • ゲームの構造に応じたアルゴリズムの開発が必要
      • 最新研究を実装するだけではうまくいかない
    • ユースケースの要件定義
      • 成果をどのような形で実現させるかは自明ではない
      • ゲームにとって必要なこと、ユーザーのニーズを論理的に分解して明示する事が必要
  • AI活用を見越してやっておいたほうがいいこと

    • 高速なシミュレータ開発
      • 描画ロジックとバトルロジックを切り離しやすいような設計
    • AIの学習を念頭に置いたログ設計
      • プレイヤー分析のためのログ以外にもAI学習用のログ設計が必要
    • 最新技術に追従する体制づくり
    • 現場との密なコミュニケーション
      • 課題を適切に定義する、企画提案するためのサービス理解
      • どれほどの成果が出るかがわからない、期待値のすり合わせが必要
  • 研究開発観点のやりがい

  • 今後の可能性

    • 今後ゲーム業界全体においてAI活用が活発化してくるのではないか
    • 実用化を加速させるために会社の枠を超えた知見共有を行いたい

感想

  • 様々な事例が紹介され、特に表現学習における獲得した表現の可視化の部分が良かったと思った
  • ゲームの運用面から考えると人による判断が最終的に方向性を決定しているため、ゲームにおけるAI活用の取り組みとは何か奇抜な新しいゲームの仕組みを作り出すためのものではなく、人が参照できる情報とその分析の幅を広げ、多角的にゲームの状態を判断するための取り組みだと再認識させられる
    (ユーザーが自らAIクライアントを育てて何かするようなゲームにおけるAI活用、みたいなものは除く)
  • 運用されているゲームにとってバランス調整は肝でありそれを補助するという時点ですでに成果を出していると個人的には思うが、さらなる成果を追求していった結果として運用タイトルを遊ぶユーザーの未来の行動全体を予測する仕組みができて、ゲームバランスだけでなく事業面に対しても優位な示唆が得られるものが出来上がるのではないかと思った

世界へ向けたゲーム開発 ローカライズ支援ツールLION

世界へ向けたゲーム開発 〜ローカライズ支援ツール『LION』〜

概要

モバイルゲームの海外同時配信・運用におけるローカライズ支援ツールとして開発されたLIONが実際にどのような課題を解決しているかについての紹介

モバイルアプリ運用時代のローカライズ事情

  • ゲーム事業部が目指している事

    • 日本で評価されているゲームを世界中に発信する事
    • そのために
  • ゲームのローカライズとは

    • ゲーム内外で使用するすべての言語に関するコンテンツを多言語化する
      • ゲーム内、公式サイト、SNSWiki、Store文言、etc...
  • 多言語化のフロー

    • ローカライズすべき文字列のすべてに対してユニークなIDラベルをつける
    • すべてのIDに対し日本語でデータ作成後、それを元に各言語へ翻訳していく
      • 言語によってはどの言語からどの言語に翻訳できるかに制約があるため、2段階に分けて翻訳を進める必要がある
        ex)日本語→英語→フランス語、イタリア語、etc...
  • ローカライズタイトルのスケジュール

    • 企画が決まり、日本語テキストが準備できたら翻訳開始
    • 翻訳完了後は、テキストバグがなくなるまで修正、反映を繰り返す
  • 運用フェーズに入ると

    • データ更新の際にテキストの追加や更新も同時に発生
    • それぞれの開発で同じフローを繰り返し実施
      →運用を考慮したローカライズフロー構築が重要となる
  • 翻訳開始から完了までの作業と役割

    • 翻訳のために必要な作業
      • 翻訳ファイル準備
      • 各種スケジュール調整
      • 翻訳者への翻訳ファイル発注
      • 翻訳ファイルの納品確認
        ここまではコーディネーターの作業
      • 翻訳作業(間違い修正含む)
        翻訳者の作業
  • コーディネーターの作業詳細

    • 翻訳対象の抽出
      • 新規翻訳及び更新などによる変更部分に判別して翻訳依頼する
    • 補足情報の追加
    • 重複している文字列の排除
    • 文字カウント
      • スケジュール、費用検討
    • 翻訳依頼ファイルを作成する
    • 翻訳の進捗管理
  • 翻訳者の作業詳細

    • 翻訳者は依頼ファイル内のテキストを翻訳
    • コーディネーターが準備した補助情報が正確な翻訳の鍵となる
  • これらが手作業だと何が起きるか

    • 翻訳発注ファイル作成の準備効率低下
      • 作業時間を要する
      • ミスが発生しやすい
    • 用語統一の困難が発生
      • 適切な管理をしないと多大な時間を要する
  • 運用タイトルにおけるローカライズの課題

    • 手作業を可能な限り自動化し、効率化して困難をなくすと運用タイトルの同時ローカライズでも品質を高くできる

ローカライズ支援ツールLION

  • ローカライズで発生する様々な手作業
    →システムに落とし効率化、標準化する

  • LIONとは

    • Webアプリケーションベースのローカライズ支援ツール
    • 開発要件
      • テキストの追加、途中変更機能は運用を想定したものとする
        • 複数の文字列がバラバラの翻訳ラインに乗る
      • 無駄な翻訳作業を発生させない
      • テキストのコンテキスト情報をシェアする
      • 役割に従ったアクセスコントロールが適切に行われる
  • LIONの機能

  • プロジェクト設定
    • 複数タイトルで同時利用
      • 他のタイトルに関する情報は見れてはいけない
    • ローカライズフローでは様々な役割のメンバーが作業
    • 各役割に最適化したUIが必要

→適切なアクセスコントロール
→プロジェクトごと、アカウントごとのロール設定

  • 翻訳テキストの依存関係を考慮した適切なバージョニングが必要
  • 翻訳者ごとに表示すべき翻訳元言語が違う

  • 文字列ID/ラベル管理

    • 各テキストをユニークなID/ラベルで管理
    • 言語ごとのバージョン管理
    • どのバージョンのテキストをどの言語に翻訳したのか正しく追跡できるようにする
  • xlsxによるアップロード

    • 慣れたアプリケーションを使用してデータ作成したい
      • webのUIを使って一つずつ入力するのはとても面倒
      • 更新内容は目視しやすくしたい
        →xlsxファイル形式での一括入力をサポート →アップロード時の差分自動抽出
  • 柔軟な文字列検索

    • 様々なケースで検索が必要
      • ソース言語の更新が反映されていない文字列
      • 単語自体が間違っていた文字列
    • データベース化によって各検索用途に対応
  • 検索結果に対して一括操作

    • 大量データの更新を一括で行えるように作り込み
  • リリース制御

    • 運用においてデータ更新は何度もある
      • 更新タイミング
        • イベント、機能追加、UI改修、etc...
      • 並行して開発されているデータに同じ文字列が含まれることもある
    • リリーススケジュール設定管理
      • リリース名
      • 公開順を決める通し番号
    • ID/言語/バージョン単位でスケジュール設定可能
    • これらによりリリース時の事故を防止している
  • 翻訳サポート

    • 翻訳対象の選定時・翻訳時に必要な情報
    • 翻訳メモリ
      • 翻訳済みデータとの類似率表示
      • 含有文字列
      • 用語集
      • コメント・ファイル添付
  • 発注フローのシステム化

    • 複数の発注が同時並行で処理される
      • コーディネーターの役割である発注管理の負担大
    • 一つの発注に関連する情報を保持するオーダー
      • ピックアップした文字列のリスト
      • 文字カウント
      • スケジュール
      • アサイ
    • LIONがオーダー管理をサポート
  • バックエンドのAPI

    • 使いやすいUI→SPA化
      • SPA化のためにAPIが必要
    • アプリのビルド環境への組み込みにも必要
      • Jenkinsなど

LIONの技術コンポーネント * サーバー * Ruby on Rails + MySQL + Elasticsearch * API

  • フロント

    • Mithril.js, Handsontable
    • SPA
  • CI

    • サーバ、フロントの自動テスト/ビルド
    • 開発環境への自動デプロイ
  • LIONの運用

    • 運用タイトル、開発タイトルそれぞれで使い始めるための準備中
    • 運用からの組み込みと開発時からの組み込み→大きく違う
    • 組み込みに当たって見えてくる課題は今後解消・最適化していく予定
  • 今後の展開

    • 便利機能
      • 各操作手順をできるだけ減らすための最適化
      • UI情報の保持
        • 文字数/行数制限
      • 通知の最適化
    • タイトル側で使うためのコンポーネント
      • コンバータやランタイム提供
    • 自動翻訳?
      • 没入感を損なわないレベルの自動翻訳が前提

まとめ

  • ローカライズ作業には様々な手作業や課題が存在
  • 運用も合わさるとさらに複雑化
  • 高品質・効率的に行う必要
    →各手作業・課題を克服するためにローカライズツールLIONを開発し機能を提供

感想

  • ゲームタイトルの運用において煩雑な手作業の数々を一つのシステムにまとめるというのは、作業リソースの削減だけでなく障害の元となる入稿ミスやデータの不備を防ぐことにもつながるので、単純な効率化に収まらない大きなメリットがあると思う
  • LIONの事例においても翻訳サポートツールとしての機能に限らず、アプリのビルド環境への組み込みやリリース制御の機能まで含まれているのは、ゲームタイトル運用での翻訳にまつわるコストやリスクを最小限に抑えるための有効な手段だと思った
  • 翻訳に限らずゲームにまつわる各種データ、ファイルについて汎化された編集・入稿ツールがあるか、開発できるかというのは開発組織としての長期的な資産に関わってくるのではないかと思った

DeNAのネイティブアプリにおけるサーバー開発の現在と未来

DeNAのネイティブアプリにおけるサーバ開発の現在と未来

概要

ネイティブアプリ向け内製BaasのSakashoを開発しこれまでどのような戦略でサーバーサイド開発をしてきたのか、そして今後どのように展開していくのかについての紹介

これまで

  • 現在
    • 内製開発6タイトルリリース
    • 多数のタイトルを新規開発中
    • 協業開発でも多数のタイトルを開発・運用中
  • どういう戦略でここまで来たのか?

    • Sakasho
      • 内製Baasであり汎用ゲームサーバ
      • 特徴
        • Sakashoサーバー+クライアントアプリで完結
        • 多数のタイトルのサーバを一手に引き受ける
          • 同一アプリケーション
          • 一つのチーム
        • タイトルチームはクライアントエンジニアだけ
          • サーバー開発は一切していない
        • 一般的なソーシャルゲームの機能をほぼ実装
          • 何故このようなことが可能か
            • 豊富な機能量、一般的なネイティブゲームに必要な機能は大体網羅
            • GoogleのFirebaseに近いイメージ
            • クライアント主導のセーブデータ管理、Stateはクライアント管理
          • 各タイトル開発チームにとっては完全にブラックボックス
          • サーバーでできることはある程度最初に決まっている
          • 最適化の対象外
            • クライアント+サーバのタイトル独自の機能に関しては最適化の対象外となる
  • なぜそうしたか

    • 選択と集中
      • Webブラウザゲームでは単縦な表現力について一定の制限がある
      • その中で様々なゲームシステムやサーバー技術が生まれた
      • ネイティブアプリにおいてはその表現力を存分に発揮しないといけない
      • 強みのある領域に集中するのではなく、強みを生むための領域に集中
    • アーキテクチャの統一
      • サーバーで何をやるかクライアントで何をやるかという設計
        • キリがない話
      • 一度間違うとかなり痛い目を見るポイント
      • 最適かはわからないが間違いではないラインで全体を統一
      • かなりクライアントに主導権を寄せている
    • 運用ポリシーの集中
      • ゲームの外の世界だが、サービス運営には必要な要素群
        • お客様対応
        • 配信プラットフォームに関連する諸々
    • サーバー技術の集約
      • いわゆる大規模サービスを支える技術
      • ネイティブアプリゲーム特有の傾向(やってみてわかったこと)
  • 結果

    • サーバー開発・運用は1チームで同時並行で多数のタイトルを展開できた
    • アーキテクチャはある程度統一され、同じノウハウを適用できた
    • 各タイトルチームはクライアント側の開発に注力できた
    • サービス運用はある程度均質化された
    • サーバー負荷に関連するトラブルはかなり少なかった
      →戦略が結果につながった

これから

  • 現状を振り返り

    • 良い点
      (Sakashoの枠組みを超えなければ)
      • サーバ開発を全くしなくても新規タイトルを開発・リリースできる
      • タイトルの数だけサーバ運用しなくて良い
      • タイトルチームはサーバで用意された機能をそのまま使うだけで良い
    • 課題点
      • タイトルチーム
        • 制約が強く、自由度が小さい
        • 独自のカスタマイズや最適化が困難
        • 意思決定がチーム内で完結しない
      • 共通基盤チーム
        • どんな変更も直接的に全体に影響を与えうる
        • 常に先手を取って全体最適になるような意思決定が必要
          →難しい
          各タイトルの優先順位、状況を知った上で意志決定しなければならない
        • ボトルネックになりがち
        • これらは元々トレードオフとして選択したこと、想定内
  • どうすべきか

    • 良い点:可能な限り残したい
      • 独自のカスタマイズをしないなら開発が不要
      • サーバー運用できるだけ省力化したい
    • 課題点:全て解決したい
      • 独自のカスタマイズや最適化を可能にしたい
        • ホワイトボックス化
      • 意志決定をチーム内で完結させたい
        • 少数の組織が独自に意志決定できるように
  • 具体的にどうすれば良いか

    • 中央集権ではなく地方分権
      • BaaSではなく、シンプルなサバクラ構成
      • 各チームにサーバーエンジニアがいる
        • ホワイトボックス化
      • サーバー運用は出来るだけ省力化したい
        • サーバーインフラはフルマネージドなクラウドに寄せる
          • GCP GAE/SE Go
        • この層ではタイトルごとの最適化はしない
        • ここはブラックボックスと割り切る
  • ネイティブアプリ開発の未来

    • ブラックボックスではなくホワイトボックス
    • 独自のカスタマイズをしないなら開発が不要
      • 基本的な機能はライブラリとして用意
      • 用意はするが、差し替え可能・改変可能
      • 独自の機能を追加しやすいつくり
      • 引き続き、共通基盤チームは作る
      • タイトルを跨いだ最適化や再利用は行う
      • 現在新規開発中のタイトル開発に合わせて取り組み中
  • まとめ

    • 魅力的な面白いゲームを開発し、世界にDelightを届ける
    • そのために
      • より自由度高く、作りたいゲームが作れるように
      • より開発効率よく、作りたいゲームに集中できるように
      • この二つを両立できるような開発・運用体制を整えていく

感想

  • 共通基盤としてネイティブアプリに必要なサーバー機能を網羅するように取り組み積み上げてきたからこそ独自カスタマイズも視野に入れて開発できるようにライブラリとして切り出すことが可能であり、これは当たり外れもあるゲーム開発においても大きく変わらないもの(サーバー機能)を共通で提供できるように固めて資産化してきたことの非常に大きなメリットだと思った
  • 今後独自カスタマイズをするとしてもサーバー機能は一通り実装が揃っている状態でスタートできるのであれば、一から機能開発をするのではなくインフラ面で新しい取り組みをしたりログ収集・分析基盤開発に開発リソースを割くことができるので、より新しい挑戦がしやすいのではないかと思った

全体的な感想

  • 全体を通してビジネス面での必要性に応じた各方面での自動化・効率化・集約化の話が多く、その上でどのような技術を使っているのかどういった設計にしているのかという考え方を学ぶことができた会だったと思う
  • 主にネイティブゲーム開発に関わるセッションを受講したが、どれも大規模化していくネイティブゲーム開発に対して技術とその使い方で勝負しているので、今後より開発リソースに対するアウトプットのコスパが良い(良い意味で)開発ができるようになっていくのではないかと思った