【イベントレポ】「DeNA GAME Techtalk #1」DeNAのゲームを支えるバックエンドシステムにフォーカスした4種のLightning Talkを披露

ソーシャルゲームにおいてネイティブゲームが主流になっている昨今、それを支えるバックエンドシステムに求められる要件の高さや、技術的難易度は高くなっています。

3月15日に初の開催となった「DeNA GAME Techtalk #1」では、DeNAのゲームを支えるバックエンドシステムにフォーカスした4つのLightning Talkを実施しました。

Mobage時代からネイティブシフトを経験したDeNAだからこそ語れる、これまでのゲーム開発と現在のネイティブゲーム開発の違いや、今後のバックエンドシステムに求められる要件を元に、現在DeNAがチャレンジしている内容について語られたトークをレポートします。

LT1. DeNA BaaS戦略に関して

まずは「DeNAのゲーム向け共通基盤の戦略」と題したセッションが行われ、菅原賢太(ゲーム事業部 Publish統括部 共通基盤部 部長)が登壇。

DeNA入社後、同社サンフランシスコオフィスで働き、ゲーム向けバックエンドサービスの開発を行っていたという菅原から、DeNAがゲーム事業に対してバックエンドサービスの部分でどのように取り組んでいるか語られた。

DeNA菅原賢太DeNA 菅原賢太

タイトルにある”共通基盤”だが、その定義について「実はDeNAでは、かなり広い意味で使われている」と菅原が言うように、ゲームエンジン(Liftエンジン)やUnity向けの共通ライブラリ、ローカライゼーションツール、マスターデータ管理ツールなど、様々なプロダクトを共通基盤として提供している。

その中で今回、菅原がフォーカスしたのが、アプリゲーム向けの基盤サービス。DeNAでは、アプリゲーム向けの基盤サービスを大きく2つのカテゴリに分類しているそうだ。

1つはログインボーナスなどゲームサービスに依存するビジネスロジックを提供する機能群。そしてもう1つがゲームシステムに依らない、Google/Apple等のプラットフォームやバックエンド業務と連携する機能群”MBaaS”。

菅原は「ゲームを作る側は、あまり配信先やプラットフォームの種別による違いを気にしたくないので、極力ゲームはゲーム開発にフォーカスできるようにという形で」と分類されている理由を説明した。

そしてDeNAでのアプリゲーム事業におけるMBaaSについて、「実はそんなに機能はなくシンプルです」と菅原。ユーザー管理(アプリユーザー認証、MBaaS利用ユーザー管理)、仮想通貨管理(ゲーム内通貨の残高や取引履歴の管理、決済レポート作成)、プッシュ通知、アナリティクス(ゲーム内で発生した各種アクティビティのログをイベントとして蓄積し分析を可能に)、NGワードチェック、問い合わせ管理といった提供機能を紹介した。

次に「DeNAはグローバルを意識しています。MBaaSの話をする上で、今回戦略というのが私の中にありますので、中国の話をさせてください」と、中国でのアプリ配信事情およびDeNAでの中国ゲーム事情について話を進めた。

「知っている方はご存知の通りですが、中国のゲーム配信は政府での所定の手続きを行った上でライセンスを取得しないと出すことができません」と、まず中国でのアプリ配信事業について触れた菅原。

「だからゲームを開発しても配信までに2~3ヵ月かかったり、ライセンスを取るために例えば中国国内にサーバーを置かなければならなかったり」と、様々な制約があるという。

また、「AppleのAppStoreでの配信であったとしても、ライセンスを保持していないと配信できない。中国にはGoogle Playは存在しておらず、その代わり20~30くらいのAndroidマーケットが存在しており、それぞれに対応する必要がある」と続けた。

そんな制約がある中で、菅原は「DeNAの中国でのゲーム事業の側面で言うと、弊社には中国オフィスがあり、そこが配信ライセンスを保有しています。中国国内においては、そのライセンスを保持した中国オフィスを拠点に、開発されたゲームを中国オフィスがパブリッシャーとなって配信している形です」と、DeNAが中国でアプリゲーム配信を行っている唯一の日本企業であると明かした。

「日本のゲームデベロッパーさんの中でも中国に拠点を持って配信できているところはなく、中国の会社、アライアンスパートナーを経由して配信するケースがほとんどだと思います」と、中国ゲーム事業において同社は強みを持っているとした。

ちなみに中国で配信しているゲームアプリも、MBaaSのようなプロダクト”LCM”を用意し、ゲームアプリを配信しているとのことだ。

LCMのほかにも、DeNAではこれまで様々なMBaaSがあったことも紹介された。

このように、色々なMBaaSが乱立していることを踏まえ、「やはりグローバルで勝てるアプリを、なるべく多く配信したいという思いがあります。日本の市場がなかなか厳しくなった状況で、少し整理する必要がある」と、菅原は今後の展望を明かした。

菅原によると、「先程お話した通り、ゲームサービスとMBaaSは切り離して考えるんですが、MBaaSの部分については、日本及び中国を除く世界向けに配信するアプリは日本で開発運営を行うLCDを、中国向けに配信するゲームは中国にて開発運用を行うLCMを使っていく想定でいる」とのことだ。

また、グローバル市場向けアプリ配信の基本ポリシーについては、「やはりゲーム側からすると、ワンソースコードでパブリッシュしたいところはあるが、そこでパブリッシュパイプラインの中でバンドルIDを中国向けと世界向けで変えることで、1つのアプリから複数のマーケットに対して対応していきたい」とのこと。

その他、MBaaSのインターフェースの互換についても触れられた。

LT2. DeNAでのグローバルBaaS

続いて登壇したのは、ゲーム事業部 Publish統括部 共通基盤部の小原裕(Hiro Obara) 。

「LCD DeNA Global BaaS」と題し、グローバル配信であるが故に発生する要件や課題について紹介すると共に、それらに対してどのように取り組んでいるかを、タイトルの状況や開発ロードマップを含めて語られた。

DeNA 小原裕

「菅原からMBaaSについて話がありましたが、私からは”LCD”というMBaaSについてお話させていただければと思います」と切り出した小原は、まずLCDがどのようなものなのか説明。

LCDはMBaaSの一種で、ゲームシステムに依らないGoogle Play/Apple等の配信プラットフォームや、バックエンド業務と連携する機能群を提供するゲームアプリ基盤サービスとのこと。LCDはLowest Common Denominatorという英語の略で、2014年9月から運用を開始している。

また、LCDは「数多く配信しているゲームアプリに必要な最小の機能を提供することで、ゲームやサードパーティのアプリなどの依存性を無くして、ゲーム開発をしやすくすること」(小原)を目的に作られたもので、中国、韓国を除く全世界でアプリが配信されているとのこと。

次に、LCDというグローバルなMBaaSを提供する上で必要な機能、サービス要件について。

まずサービスを提供する上での要件として挙げられたのが、24時間営業。「日本だけでの配信なら日本のプレイヤーの生活のパターンに合わせられるが、世界各地での配信となると時差の関係があるため、24時間プレイヤーに対応する状態」と小原。

また、世界各国の100以上の通貨に対応する必要があり、購入された課金&仮想通貨の管理やレポーティングも必要だとした。

ローカライゼーションについても、「LCDのシステムメッセージは、日本語や英語だけでなく、使っているプレイヤーが理解しやすいように11ヵ国語に訳して提供している」(小原)とのこと。

その他、「e.g. GDPR、COPPA、特定商取引法、資金決済法など、各国の法律や規則をきちんと把握しなければならない」ことや、「タイトル数が増えてくると、開発チームや会社もアメリカや日本、中国、フランス、イギリスなど各国にまたがります。彼らからのLCDに関する問い合わせにも対応しています」と、小原は法律的な要件やデベロッパーズサポートについても触れた。

LCDがどのようなものかを簡単に示した図。

そして、現在LCDで提供されているサービスについて、「菅原の話にあったMBaaSの機能とほとんど一緒ですが」(小原)とした上で、ユーザー管理、ゲーム内仮装通貨管理、アナリティクス、NGワードチェック、CSツールといった特徴を紹介していった。

最後に小原から、LCDが今後の展望について語られた。

まず、DeNAがグローバル配信を重要視している側面から、「ゲーム側のほうではアメリカだったり、日本、中国など配信先のマーケットを気にすることなくゲーム開発を行い、そのまま希望のマーケットへ配信していけるように、LCDのほうでそういったマーケットの差を吸収していこうと思っている」とのこと。

また、ゲームエンジンに関しては、「昔はUnityなども持っていましたが、現状はゲームの数も少なくiOS、AndroidのSDKしか提供していません。ですので、今後はまたUnityのSDKも再開する予定です」とした。

他にもLCDシステム関連について、

・マルチテナント型システムからシングルテナント型システムへの変更
・LCD5周年を機に改めてシステムの見直しを図る
・LCDに限らずDeNA全体として新しい技術を積極的に開拓

といった展望を掲げた小原。最後に「今後LCDは世界に向けて配信する予定です」とメッセージを送った。

LT3. DeNAのゲームサーバ技術の変遷とこれから

かつてはオンプレ、Perl、MySQLのイメージが強かったDeNAだが、ソーシャルゲーム黎明期から今日に至るまでに、ゲームサーバを構成する要素技術も移り変わってきた。

そこで、同セッションでは、​「DeNAのゲームサーバの変遷とこれから」と題し、ゲーム事業部 Publish統括部 副統括部長の北澤慶郎が、DeNAの今までのゲームサーバを構成する要素技術の変遷と、これから目指していく未来像について紹介していった。

DeNA 北澤慶郎

「先程までは事業や戦略の話など色々ありましたが、技術面に絞ったお話をします」と切り出した北澤は、これまでのゲームサーバ技術の変遷を「振り返ると大体こんな感じで4分割できます」と、以下のように分類し、各時期に活用した技術を紹介していった。

まずはブラウザ~ネイティブアプリ黎明期。どういう技術が使われていたかというと、Perl、MySQL、Server Side Rendering HTML。

これについて北澤は、「DeNAと言えば、昔はPerlという感じでしたが、それがまさにこの頃。MySQLもお馴染みですし、HTMLもサーバーサイドでいわゆるテンプレートエンジンに変数を突っ込んで開発するといった、よくあるWebの技術です」と紹介した。

その中で、「PerlやHTMLの部分はそれほど特殊なことはないのですが、やばいのがここです」とピックアップしたのがMySQL。

「MySQLはどういうことをやっていたかというと、いわゆるMaster-Slave構成からの垂直、水平分割を全てやり、Shardingと言われる1つのゲームタイトルで複数のデータベースを分割して、それをアプリケーションレイヤーで全部振り分けて複数DBを扱います。さらに厳密なトランザクションも守りながら、Shardまたぎをどうコミットするかというのをやっていました」と北澤。

「このブラウザ全盛期の頃、会社としても色々な経験になりました」と振り返った。

続いてネイティブアプリ(第1世代)で使われていた技術について。ネイティブアプリに入った時期に、どういうことをしていたのか? 北澤は「さっきとあまり変わらないですが」と、MySQLはそのままに、Perl→Rubyに、Server Side Rendering HTML→RESTful APIに代わったことを紹介。

Perlに代わって使われたRubyに関して、北澤は「WebのシステムでRubyならRailsだろうと普通は思うけど、実際には表側のいわゆるクライアントから直接受けるAPIはSinatraで、管理画面はRailsでやってた」ことを明かした。

ちなみに、なぜ両方使っていたかというと、「2012年~13年はやはりブラウザ全盛期で、すごいトラフィックを捌いていたわけですが、同じことをRailsでやるのは無理だろうと思い、表側はSinatraで、管理画面についてはRailsが最適だろうということで分けていた」とその理由を説明した。

ブラウザ~ネイティブアプリ黎明期から使われているMySQLは、やっていることも、苦労の仕方も一緒ながら、「ここで新たな難しさに直面した」と北澤。

「表側はSinatra、裏側はRailsと両方あり、それぞれで難しいことをする。さらにRailsやアクティブレコードで、当時の2012年〜2013年のActiveRecordでアプリケーションレイヤーで複数DBみたいなのがかなり難易度の高いところにありました」(北澤)と、最終的にはActiveRecordという非常に高機能なものを使うのでさらに難しくなったそうだ。

そしてRESTful APIについて。データフォーマットはJSONだが、「IDLは独自のIDLを勝手に定義して、その中でJSON Schemaを内包。クライアントだけIDLからの自動生成みたいなことをしています」(北澤)とのことだ。

次に、2015年~2016年あたりを指すネイティブアプリ(第2世代)。第1世代から大きく変わらず、Ruby、MySQL、RESTful APIが使われている。

ただし変わった部分もある。

「皆さんもご存知であろう、グローバル大ヒットタイトルはすごいインストール数なんですけど、それも全てRailsでさばいています。この頃だとRailsもまあまあ重い部分を自分で外せたりできていたので、何とかできています」と、Rubyは表側のAPIもRailsになったという。

MySQLは昔から変わらずやっていることは同じだが、「この頃になると少し傾向が変わってきた」と北澤。

「昔のブラウザのソーシャルゲーム全盛期って、かなりソーシャル要素が強く、基本システムとしては非同期だけど、マルチプレイみたいにお互いに影響を受けるものだった。それがこの頃からゲーム全体がいわゆるシングルプレイの割合が増えてきて、Shardingでお互いに影響し合うみたいな難しさは量としては減ってきた。その分、単純にグローバル化が進む中で規模がどんどん大きくなったという難しさがあった」と振り返った。

RESTful APIも大体一緒とのこと。データフォーマットがProtocol Buffersになっているが、IDLは独自のIDLで、「この独自IDLはJSON」と北澤。「IDLって、大体作ったら自動生成したくなるけど、クライアントとサーバーの一部を自動生成みたいにしている」と説明した。

ゲームサーバの変遷を振り返ったところで、ここからは今後の展望について。北澤は「まだリリースしておらず開発中ですが」と前置きし、次の世代でどんな技術を活用していくのかを明かした。

まず、Google App Engine / Golangについて、北澤は「他社の方がよく発信しているものです。弊社だとAndAppというサービスがあり、その辺が結構同じGoogle App Engineで行っている」とし「大体普通のAPIサーバーだったらこれで問題ないです。問題ないどころかRails等と比べて実行効率は段違いに良さそうだし、オートスケールの性能とかもかなり良さそうなので、基本これで良いのではと考えています」と続けた。

次にGoogle Cloud Spanner。これは、アプリケーションレイヤーで複数DBを扱う必要がなく「相当楽です」と北澤。さらに「Spannerって勝手に内部的にShardっぽいものを持って、勝手にShardを分割してくれるんですけど、さらに減ってきたら勝手にShardを統合してくれる……そこは最高過ぎて、使えるなら使った方が良い」とした。

ただし、導入する上での固有のノウハウがかなり多いそうで、「MySQL時代に鍛えられた猛者でも、このノウハウをまた覚えないといけないという所が大変。それでもShardingなどをアプリケーションレイヤーで管理しなくて良いのはすごくメリットだと思う」と北澤は述べた。

3つ目に、RESTful APIに代わるRPCについて。RPCは、データフォーマットがProtocol Buffers、そしてIDLは独自IDLではなくProtobuf Schemaになっている。

「これってgRPCじゃんという感じですが、Protobuf Schemaの書き方等はgRPCとほぼ同じです。そこからgRPCと同様にサーバーコード、クライアントコードを自動生成しています。自動生成の仕方は参考にしているgRPCにかなり近いです」と北澤。ただ、「ちょっと自前実装しまくっているので、さっさとどこかでgRPCに置き換えたいと考えているとのことだった。

最後に北澤は、「ざっといままでの変遷をまとめましたが、昔を思い出しながらスライドを作る中で、結構その時代ごとに使う武器が変わっていて、適切な判断だったかというと100点ではないかなと思いますが、市場の進化に合わせてちょっと遅れてたり、先取っていたりしているなと感じました。歴史を辿ると、どんどん変わっているけど、意外と市場と同じことをやっていて、何となくみんなが同じ方向を見ている。これからも市場の進化を見ながら流れについていけるんじゃないかなと思っています」とまとめた。

LT4. ゲームローカライズフローを支える基盤ツール開発

この日、最後に登壇したのは、立浪千尋(ゲーム事業部 Publish統括部 共通基板部 オペレーションサービスグループ)。「ゲームローカライズフローを支える基盤ツール開発」と題したセッションを行い、アプリのグローバル展開において避けて通れないローカライズフローを支援するためのDeNAのローカライズ支援ツール「LION」において、どのような課題に取り組んでいるかを紹介していった。

DeNA 立浪千尋

まずは”ゲームの制作とローカライズフロー”について。「エンジニアやプランナーを始め、各職種がそれぞれのフローに則って制作が進んでいきます」とゲーム制作フローについて説明した立浪。

各職種の中で、実際にグローバル展開していく場合においては、「プランナーが実際にゲームの言語で作ったテキストはたくさんあって、それを修正していくわけですが、まずはローカライゼーションコーディネーターが翻訳のスケジュールを出したり、誰に翻訳をお願いするかというところをコントロールします」と立浪。

そこから実際に様々な言語に翻訳する翻訳者に依頼が行き、翻訳が回ってさらに言語QAなどを重ねるなど品質を上げていくのが、ローカライズでは一般的とのことだ。

さらに詳しく見ると、「ゲームのローカライズフローはテキストを言語で作るといいましたが、ローカライズは全ての文字列に対してユニークなID、ラベルを付与して日本語でデータを作成します。それを元に各言語に翻訳していく」(立浪)ようだ。

その中で、言語によっては「日本語から直接翻訳するのが難しい」という立浪は、翻訳者の手配が簡単ではない言語があると明かした。

例としては、日本語を英語に訳す場合は比較的多くの翻訳者が対応できるが、「日本語からフランス語、ドイツ語などに訳すとなるとできる人がなかなかいない」(立浪)。そこで良く行われるのが、まず日本語を英語に訳し、そこから各言語に翻訳するという手法とのこと。

これがいわゆるゲームのローカライズフローとなっているが、モバイルゲームの事情が絡まってくると、ここからさらに運用というフェーズが始まるという。

運用が始まると、そのゲームでイベント開発だったり大きなUI回収等があると、先ほど説明された事と同様のフローがそこでまた発生。モバイルゲームの運用においては、ずっと繰り返していくイメージだ。

「それぞれの開発で同じフローを繰り返し、開発や翻訳が並行して進むタイミングでオーバーラップしていきます。こうしてモバイルゲームのローカライズにおける開発では、そもそも繰り返されることでどんどんテキストデータが増えていきます」と立浪。ここで、まずどの文字列が追加、更新されたか管理するだけでも相当大変であるとした。

加えて、「増え続ける各テキスト間の整合性を担保しなければいけないところ」「関わる職種が多岐に渡りることによるコミュニケーションコスト」も難しいと語った。

その他、モバイルゲームのローカライズにおける課題を紹介。

これら課題を解決するために開発されたのが、ローカライズ支援ツール「LION」だった。LIONとは、Webアプリケーションのローカライズフロー支援ツール。

機能としては、いわゆるデータ管理が主で、テキストデータをしっかり一元管理してデータベースにしている。「翻訳メモリというのは、すでに翻訳されている別の文字列から、似たような言葉を翻訳しようとしている時にしっかりピックアップできること」と立浪。

「LION」は、文字列での管理がしっかりとIDと言語に従って差分抽出できるようになっており、利用タイトルはそのテキストを「LION」に置いておけば、後は翻訳されたものを取り出すだけでゲームに反映できるという。

また、各種集計作業や翻訳の提出・差し戻し・受け入れ、メールベースコミュニケーションからの脱却など、各職種をまたいだワークフローをシステム化している。これにより翻訳作業と品質の管理に集中できるようにすることでのコミュニケーションコストの削減を図った。他にも、翻訳ツールとしての一般的な機能も備わっているという。

「LION」の概要、機能を紹介したところで、次に「LION」の開発における取り組みについて。「まず一番は、ローカライズ部門の悩みをしっかり吸い上げるというところ。実務者に徹底的にヒアリングすること」と立浪。

それでも、後になって必要な要件が発覚することも多々あるとし、「立ち戻って考えることは必要かなと思ってやっています」とコメントした。

他にも、SPA化したスプレッドシートUI、翻訳メモリや重複文字列の簡単なピックアップなどフロントの作り込みによる翻訳作業の効率化や、ゲームアプリ側の作りについても「これは「LION」開発というより、ローカライズフレンドリーな作りになっているかを考えていかなければいけないよねというところで、弊社ローカライズ推進部と一緒にチェックシートを作り、これを満たしているとローカライズしやすいという指針を整理しています」と、立浪は語った。

そして今後の展望については、「そもそも運用タイトルのつなぎ込みの検証中なので、現状バンバン回しているというより、これからやっと使っていくというタイミングです」(立浪)。

機能としては、「まず文字列のチェック系の機能を拡充していきたいと思っています。例えば文字数、行数はツール上ですぐチェックできるだとか、UIからはみ出していても言語QAに回る前に翻訳中に検知できたりするであったり、また基本的なスペルチェックなどの部分もも拡充していきたい」とした。

そしてアプリのデバック機能との連携に関して「実機で見たときに表示が崩れているという場合、実際どの文字列が崩れているのかを実機で確認できる状態を作りたいです」と立浪。続けて最終的に将来目指したいこととして、「いわゆる実機プレイしながら翻訳者が翻訳できる状態。これが実現できたら本当に良いなという夢みたいな話ですが、いつか実現さえたいと思っています。あとは昨今機械翻訳の精度も上がってきているので、そことの連携も視野に入れて今後も開発していきたい」と述べた。

最後に立浪は、「世界各地でおもしろいゲームを届けるためのローカライズは、さまざまな手作業、課題が存在していて、モバイルアプリの運用も合わさるとさらに複雑化しています。

そこで発生する手作業や課題を克服するために、いま「LION」を開発しています。この改題解消のための機能を提供していきますが、まだまだ必要な機能もあります。今後も「LION」を使ってローカライズの品質向上、効率化を実現して、グローバルにアプリを配信していきたいと思っています」とメッセージを送った。

取材・文・撮影:細谷亮介

※本記事は2019年3月時点の情報です。
※本記事は、SocialGameinfoに掲載された内容を一部構成を変更して掲載しています。

[su_note note_color=”#ffffff” radius=”10″]

GeNOM(ゲノム)とは

DeNAのゲームクリエイターを様々な切り口で紹介するメディア(運営:株式会社ディー・エヌ・エー)です。ゲーム開発の現場で生まれる様々なエピソードや、クリエイター紹介、イベント紹介などを通して、DeNAで働くメンバーの”ありのまま”をお伝えしていきます。

GeNOMの最新情報は、公式Twitter アカウントにて確認いただけます。ぜひフォローをお願いします!

[/su_note]

【イベントレポ】GDM ローカライズ勉強会Vol.1 ~多種多様なゲームタイトルに対応する為のローカライゼーションとは?~

毎回様々なゲストをお招きして、最新の技術や情報をシェアするDeNA主催のゲームクリエイター向け勉強会の【Game Developers Meeting】(以下、GDM)。

今回初の開催となるローカライズ勉強会では、 「多種多様なゲームタイトルに対応する為のローカライゼーションとは? 」 と題し、登壇者が考えるゲームローカライズのあるべき論と、攻めのグローバル展開に必要なローカライズ業務について、DeNAにてローカライズ業務を担当する「藤村 弘也」よりセッションが公開されました。本稿ではそのレポートをお届けします。

ほぼ満席となった会場で実施された今回の勉強会。冒頭では司会を務めるDeNAの「藤村 幹雄」より、セッション時の注意事項や、GDMに関連した告知がなされました。

DeNA藤村幹雄DeNA藤村幹雄

自分たちが取り組むローカライゼーションの本質

続いて登壇した藤村弘也から、簡単な自己紹介として、元ロックギタリストでロンドンでバンド活動をしていたり、音楽プロデューサーとして楽曲制作に携わってきた、ちょっと異色な経歴を明かされました。

セッションを始める前に、日本の会社でよく聞く「お疲れ様」という挨拶について、来場者に向けて「英語ではどのように伝えると思いますか?」との質問が投げかけられました。

会場には、気持ちの良い静けさがスーッと広がります。

実は、過去に海外スタッフとの会話のやりとりで実際に体験したことで、当時藤村はその答えとして

「Thank you very much for attending the conference.」
「Thank you for coming.」

と翻訳して答えたところ相手に、

「英語で疲れたって言ってないじゃないですか!? 」

とツッコまれたとのこと。日本ではお疲れ様という言葉は、ねぎらいと感謝をこめて使われていることが、うまく海外の人には伝わらなかったのかもしれません。

このような「言葉文化のズレ」をコントロールしてゲームに仕込んでいく、それが自分たちが取り組むローカライゼーションの本質だと、藤村はセッションの前段として話しました。

DeNA藤村弘也

DeNAゲーム事業の特色とグループのミッション

現在のDeNAのゲーム事業は、タイトルのすべてがモバイル向けのゲームであり、リリース後も運営していくことを前提に開発がされています。ジャンルは多種多様で、運用のスキームも複雑になっています。

藤村が考えるゲームのローカライゼーションとは、ゲームの楽しさ・面白さを損なわず、作り手の演出や狙いを、言語が違う国でも現地のプレイヤーに正しく伝えることと述べています。

そして、ローカライズグループのミッションを、

「攻めのグローバル展開をサポートする、強いローカライズグループ」

と掲げました。

強いローカライズグループに成長するための課題

先に述べたミッションを達成するためには、ローカライズの業務が体系化されている必要があり、DeNA社内での現状の問題点を挙げ、あわせて解決策を紹介しました。

【問題点】開発環境がローカライズ仕様になっていない

文字列のID管理されていない、テキストがプログラムに直打ち、ファイルフォーマットがまちまちになっている、などローカライズ仕様になっていないのが現状です。

【解決策】開発環境がローカライズ仕様になっていない

この問題に関しての解決案は「ローカライズTRCの導入」。

ローカライズTRC(Technical Requirements Checklist)とは、社内ルールやガイドラインとなるチェックリスト(仕様書)ツールのことで、DeNAゲーム開発における独自のローカライズ規格を策定し、このTRCを開発タイトルすべてに標準導入することを検討しています。

※TRC(Technical Requirements Checklist):Play Stationプラットフォームでリリースする際のSIEマスター規格チェックリストのこと。

DeNAローカライズTRCを導入すれば、文字列のID管理や命名規則などをまとめてチェックすることが可能になり、ストレスがないローカライズフレンドリーな開発環境が整います。

【問題点】文字列が一元管理されていない

マスターテキストが各プロダクトごとに点在していることで、該当テキストの検索の不便さ、表記ゆれの管理、過去の翻訳との整合性が取れないなどの問題が起こっています。

このような状態が続くと、テキストの品質コントロールが不可能になり、業務推進がマンパワー依存になってしまいます。

すると、手作業によるミスの多発、バグの見逃し、余計な工数……それが重なって慢性的に残業状態になり現場スタッフは疲弊していきます。このような状態では、品質の担保もできず到底ミッションをクリアすることはできません。この課題の解決は急務だと判断できます。

【解決策】文字列が一元管理されていない

この問題に関しての解決案は「LIONの導入」。

「DeNA TechCon 2018」にて紹介された社内ローカライズ支援ツール「LION」を導入、現在開発・調整中のため、詳細は公開されませんでしたが、このツールを使うと文字列単位の管理や、翻訳業務の進捗管理、用語集などを一括管理可能になるとのこと。

※LION:DeNAにてローカライズ業務用に開発している社内ローカライズ支援ツール

さらに同プロジェクトを開発チーム・ローカライズチーム・翻訳会社とそれぞれ職種別に操作できるようになります。

上記の課題解決策で、現場作業の煩雑さに改善効果が生まれてきます。

ここで重要な働きをするのが、責任者として現場で業務に取り組む「ローカライズコーディネーター」の存在です。

ローカライズコーディネーターとは

コーディネーターとは、開発チーム内のテキストローカライズの責任者、外部翻訳会社と連携してローカライズ業務を推進するスタッフのことを指します。

彼らに求められることとして、ある一定レベルは必要で、それに加えてゲームというエンタメ開発に携わるからには、おもしろい発想や多彩な感性を持つ人が必要だと藤村は話しました。

また、過去に藤村がロックバンドでギターを担当していたときの経験で、グループマネジメントは、バンドがギターを弾いていい音を出すことに似ていると語ります。

ギターは頑張って弾くのではなく、ギター自身が気持ち良くなるように触れてあげなければならないとのこと。

なので「こんなに練習したぜ! 」と気合いを入れて頑張って弾いても、ギターはうまく鳴らず、バンド全体の音もめちゃくちゃになってしまい、音楽として成り立たなくなります。

ですが、各パートの楽器の音が気持ちよく共鳴しだすと、お互いの響きを活かすようになり、全体の音楽のクオリティが足し算ではなく掛け算になっていくということ、つまり「それぞれが気持ちよくパフォーマンス(仕事)ができる」ことが大切だと、バンド時代に気づいたと語っています。

欧州・米州・中国などのリリース地域ごとにおける課題

ここからは、事前にフォームにて投稿された質問について、藤村からの回答が公開されました。

体験談をもとにした文化的な違いについて

ここで、藤村がロンドン在住時代、ニューヨークに旅行をしたときの「言葉と文化の違い」についての体験談が語られました。

「便器を貸してください」

藤村がハンバーガーショップでオーダー待ちをしていたときのこと。アメリカ人が「バスルームを貸してください」と店員さんに頼んでいるのを聞いて、驚きました。

ですが、店員さんは何事もないように「そちらの奥にあるのでどうぞ」と案内をしました。

アメリカでは、トイレを貸してほしい時に「バスルームを使わせてください」と言うようで、日本のように「トイレを貸してください」とは言わないのです。アメリカではトイレ(Toilet)は便器そのものだけを指す様です。ちなみにイギリスでは「トイレを貸してください」が普通とのことです。

「熱くないラーメン」

異文化体験のお話。藤村がロンドンでイギリス人の友人と話題のラーメン屋に行ったとき、先に友人に運ばれてきたラーメンを、すぐに食べ始めている様子を見て、違和感を感じたと言います。

続いて藤村の元に運ばれてきたラーメンの器を触ってみると……なぜか人肌の温度、つまり、熱くないラーメンだったのです。

すぐにウェイターを呼んで抗議するも、ウェイターは真顔で「熱かったら食べられないじゃないか」と不思議そうに答えたそうです。

もちろん、冷めたラーメンを出されたわけではなく、人肌で食べやすくというサービス心からなのです。

上記の経験のような、日本では考えられない、異文化の違いが毎日のように起こったそうです。通用しないことは通用しないと、自分の習慣だけにこだわるのをやめて、まずは「異文化を面白がる」ことが大切だと藤村は話しています。

現在主流になっているローカライズフローで良いのか?

標準的なワークフロー

現在のDeNAでのローカライズ業務に関する、大まかなワークフローは以下になります。

1.開発チームからの翻訳依頼
2.依頼とりまとめ発注
3.翻訳会社で翻訳
4.納品テキストの検品
5.ゲームへ実装
6.LQA ※言語実機テスト
7.バグ修正
8.マスターアップ

ローカライズTRCとLIONの運用効果が出るフェーズ

今回の課題解決として提案したローカライズTRCおよびLIONを導入すると、上記1.2.4.5.7.8について作業工数の削減が期待できます。

ローカライズTRCとLIONの運用効果が多くないフェーズ

逆に、上記「3.翻訳会社での翻訳」と「6.LQA」の作業については、翻訳の品質そのものを扱うフェーズになるため、ローカライズTRCおよびLIONを導入しても、「煩雑になる業務を整理する」観点としては、大きな効果は出ません。

改善課題についてさらに考えてみる

上記「3.翻訳会社での翻訳」と「6.LQA」について、3で翻訳作業を完成させているはずなのに、6でバグが発生します。

それはなぜでしょうか?

理由は、「3.翻訳会社での翻訳」のフェーズで、開発側から翻訳会社へ必要な情報を「すべて」提出できていないため、翻訳者がすべての仕事を明確にチェックできず、翻訳が完了した後に仕様変更が入り、再翻訳が必要になってしまうからです。

開発中のため、資料などが揃わずに仕様変更も仕方ないことではありますが、環境が揃わない中での完成度の高い翻訳をするのは至難の業です。

さらに、翻訳テキストの品質担保を「6.LQA」フェーズに全依存しているので、テスターからの修正案をコーディネーターが受付後、修正案を翻訳者に確認してからテキスト修正して実装する手間がさらにかかります。

ならば、翻訳者が実機でゲームプレイをしながら仕様を確認して作業できたら良いのではないでしょうか? そこで機械翻訳を導入することを考慮していきます。

機械翻訳の導入で効果的にコストを減らす

広く知られているニューラルマシントランスレーション(NMT)とは、ディープラーニングと呼ばれる人工知能(AI)に自動学習させる機械翻訳のことです。この機械翻訳をどのように使用すれば、効果的に課題を解決できるのかを、フローに組み込みながら考えていきます。

標準フローの「3.翻訳会社で翻訳」にまず機械翻訳を導入、「6.LQA」実機テストでのフェーズで翻訳者はテスターと協力して翻訳作業を行います。ここで翻訳者は最初の翻訳になりますが、すでに機械翻訳したテキスト参照を、実機ですぐにできることが強みになります。

さらに、仕様もすべて確認できる状態で作業ができることもメリットに。

機械翻訳を入れる効果と翻訳者の作業環境

標準フローの「3.翻訳会社で翻訳」では、翻訳コストが大幅に削減され、社内の対応コストも最低限に、スケジュールの短縮も可能になります。

標準フローの「6.LQA ※言語実機テスト」では、LQA開始が早くなり、テスト期間を長く取ることができ、品質担保が効率的になり、バグも減っていきます。

すると、現場のコーディネーターの対応コストが減って、負担も少なくなっていきます。

今後の課題

・機械翻訳の翻訳精度は十分か
・自動学習させるために翻訳データベースの確保はできるのか
・仕様確認のためのデバッグコマンドを実装できるか
・そもそも開発スケジュールに落とし込めるか

など、今後もこれらの課題について、藤村をはじめとしたローカライズグループがひとつずつ、課題に向き合って解決いくとのことです。

また、次回以降の勉強会などで進捗を公開していくとともに、これから一緒に議論を繰り返して、ゲーム業界におけるローカライゼーションの価値を上げていきたいと、セッションを締めくくりの言葉としました。

懇親会の様子

参加人数が多かったため、急遽会場を拡大して実施された懇親会では、お寿司とピザや軽食を楽しみながら、来場者がさかんに交流しました。登壇した藤村には次々と質問が飛び交い、かなりの盛り上がりを見せていたのが印象的でした。

登壇した藤村にインタビューを敢行

セッション終了後に、登壇した藤村弘也にイベントの感想や、次回以降の展望などのお話を聞くことができました。

――セッションを終えての感想と手応えを教えてください。

第一回となる今回は、あまり深く掘り下げないようなお話をしたのですが、刺さった部分はみなさん違ったみたいで良かったです。もともと自分はTech系エンジニアではないため、LIONやローカライズTRCなどツールに関しても、概要を話しただけなので、リクエストがあれば次回以降で各担当者にお願いして、さらに細かい粒度のセッションにしてもいいかなと感じました。

まずは、DeNAゲーム事業部が、内製でローカライゼーショングループを新設して、今後グローバルに攻めていく姿勢を伝えることを大切にしました。

※LION:DeNAにてローカライズ業務用に開発している社内ローカライズ支援ツール
※TRC(Technical Requirements Checklist):Play Stationプラットフォームでリリースする際のSIEマスター規格チェックリストのこと。

――懇親会はかなり盛り上がっていましたが、来場者さんとどのようなお話ができましたか?

かなり盛り上がりましたね! 特に質問が多かったのは機械翻訳の部分です。自身の会社でも試して失敗した経緯をお話ししている方もいましたし、これから導入を検討している方もいました。また、開発中のLIONの進捗についても注目されていたようです。

LIONに関して、基本の機能自体はどこにでもあるものなんですが、DeNA社内では、多くの運営中タイトルに対して汎用的なカスタマイズが可能になるような開発・調整を続けています。それを内製で作り上げる意味を理解してくれる方も多かったですね。

また、文化的な表現の違い(ラーメンのお話)に反応してくれる方もいました。国ごとの表現のズレは思っているより大きく、海外のシナリオを担当している方は「なんでこんな文章の展開になってしまうんだろう? 」と深刻に悩んでいる方もいましたね。

――でも、そんな異文化も「楽しむ」ことがエンタメ開発には大事な要素なんですよね。

そうですね。世界にはいろいろな感性を持つ人がいますので、その「違い」を楽しみながら仕事をしてもらいたいです。自分が音楽をやっていたときの経験は、今の仕事にかなり活かせていることはウソじゃないですよ。

――懇親会でお話ししたのはどのような業界・職種の方でしたか?

ゲーム業界の方はもちろん、ローカライズエンジニアや、ゲーム系の翻訳者さんが多かったですね。セッション内で「作業環境があまり良くない」といった話をしたときに「すごくよく分かる! 」と共感してくださる方もいたようです。やはり段階的に作業環境を改善することが、いい仕事をするポイントだと思います。

今回のセッションでも触れましたが、機械翻訳の進化によって「将来的に翻訳の仕事がなくなる」わけではありません。最終的な品質を担保できるのは翻訳者の腕にかかっていますし、ただこの先、仕事の手法が少しずつ変わっていくのかもしれませんね。

もちろん、スゴイ技術を持った翻訳者が120%のクオリティーで作業することは、貴重でありがたいことなのですが、どうしても属人化の問題も出てきます。それとは違う、ある程度の質を保って、もっと工数を少なく作れるような方法を模索していきたいですね。

――次回以降のセッションの展望はありますか?

今回のフィードバックの結果にもよりますが、LIONとローカライズTRCの開発進捗、機械翻訳の試用結果などをそれぞれの担当者に報告してもらえるといいかもしれませんね。数値周りはどこまで話せるかはわかりませんが……(笑)。

――新設のローカライズチームのメンバーとは、今回のGDM参加についてなにか話しましたか?

今回のセッションのリハーサルを見に来てくれていました。グループが新設したのは2018年6月で、人数も関わるタイトルも増えているので、自分の思いも含めて、これから体系的にきちんと整理していかなければ、と感じています。

――新設のローカライズチームのこれからの展望はありますか?

今回セッションで話したミッションを基礎として、グループ全体で攻めの姿勢と、強いローカライズチームを育成していくことを目指したいと思っています。

――ありがとうございます!本日はお疲れ様でした。

運営チームオススメのデザート

GDMと言えば、運営スタッフが力を入れている軽食。仕事の疲れをホッと癒やしてくれる今回のデザートには、季節の素材を使ったタルトをご用意。食べやすいサイズということで、テイクアウトする来場者の姿も。

取材・インタビュー・文・撮影:細谷亮介

[su_note note_color=”#ffffff” radius=”10″]

GeNOM(ゲノム)とは

DeNAのゲームクリエイターを様々な切り口で紹介するメディア(運営:株式会社ディー・エヌ・エー)です。ゲーム開発の現場で生まれる様々なエピソードや、クリエイター紹介、イベント紹介などを通して、DeNAで働くメンバーの”ありのまま”をお伝えしていきます。

GeNOMの最新情報は、公式Twitter アカウントにて確認いただけます。ぜひフォローをお願いします!

[/su_note]