2012年08月29日 12時00分取材

日本から世界へ、ゲームで世界展開を実行するポイントとGREEの戦略

CEDEC2012で行われた「10億ユーザーへ。ソーシャルゲームで世界に感動を！」の講演で、GREEのエミリオ・ガジェゴさんと松倉友樹さんから、GREEが提供しているソーシャルゲームを例に、具体的に日本のゲームをどのように世界の市場に配信しているのか、そしてソーシャルゲームのグローバル化ならではの技術的なことについての紹介がありました。

エミリオ・ガジェゴ：
モバイルゲームの市場は、大体2015年までに、6億端末から12億端末まで市場が伸び、マーケットの売り上げは35億ドルから40億ドルを見込んでいます。

モバイルを使った各地域（ラテンアメリカ・北米・アジア・ヨーロッパ）からの今後のアクセス伸び率は、ラテンアメリカで約400％になるなど、コンシューマ業界で届かなかった市場で、モバイルゲームとソーシャルゲームの配信が可能になります。

また、これまで日本で培った運営ノウハウとプラットフォーム向けの企画と開発を一緒にして、日本から全世界にアプリケーションゲームを配信できるGREEのグローバルプラットフォームを始動させています。

GREEのグローバルプラットフォームには、ゲームバイナリをローカライズさせることで、全世界にコンテンツを配信でき、1つのプラットフォームで多言語対応することにより、時間・費用・人力が削減ができ、日本以外の市場に商品を届けられるメリットがあります。

プラットフォームとして強化していく点として、1つ目がアプリ回遊導線の確保。これからのプロモーションの基盤開発をして、海外でも日本と同じようにアプリが売れるような基盤を作ります。2つ目がソーシャルグラフの拡大。3つ目はコミュニケーション機能の強化です。バイラル（口コミ）効果でインストールが増える仕組みを作っていく予定です。

次は、各国市場の分析です。市場はどれぐらいの規模なのかというと、一番大きいマーケットはアメリカ北米で約4500億円の規模になります。続いて日本は1600億円、ドイツは800億円です。どの言語が主要市場に要求されているかというと、英語、日本、ドイツ、中国語、フランス語、イタリア語、ポルトガル語、スペイン語の順になっています。

そもそもローカル化する必要があるのか、と皆さんが疑問に思うところだと思います。各国のランキング分析で得られた情報では、大体スペインで93％売れているアプリがスペイン語にローカライズされています。イタリアでは80％のアプリがローカライズされていて、フランスでは73％、ドイツ67％、ロシア66％、スウェーデンでは45％です。よって、海外に配信するアプリはローカライズされていないと、市場を獲得できないという可能性があるということです。

ただしローカライズするためには、考えることが多くあります。たとえば中国語にローカライズする場合、簡体文字と繁体文字の両方バージョンを作成するのかしないのか。繁体文字の場合は端末によってメモリー不足、文字が崩れる問題があります。また、日本語より必要となるスペースが増えるので、UI全体を先に考える必要があります。ポルトガル語にローカライズする場合、進出したい市場はブラジルかポルトガルかによって、若干異なります。スペイン語も同じように、ラテンアメリカとスペインどっちらに進出するのか、中立版にするのか、バージョンを分けてスペインのバージョンにするのか、といったことを決定する必要があります。フランス語もカナダフランス語圏とフランスでバージョンを分けるのか、統一するのかという問題点があります。あとは、費用対効果でどこまでローカライズして、どこまで費用を使ってローカライズすればいいのか、ということです。まず、システムの構築からは始まりますが、ローカルライズする環境を最初から考えていれば、かなりの部分のローカライズはマシンベースで進められます。費用対効果を得るために、テクスチャーテキストを極端に減らし、性と数を必要とする仕様を避けることを考えるべきです。最終的な目的は、スペインの人であろうと、ドイツの人であろうと、ゲームを遊んでいるときに自国で作られたかのようなユーザーエクスペリエンスを提供することです。

リリースフローについて。日本の場合は法務チェック、次にFAQを行います。ここまでで、リリースの準備は終わっていますが、グローバル版を制作する場合に限って、倫理チェックが必要となり、使っているモチーフは海外の文化・法律に違反していないか、国別で考えていかなければなりません。法務チェックでは、システムで使っているグラフィックは海外の法律を違反してないかチェックします。その他、言語選定、プラットフォーム選定、ターゲット選定などをします。市場にある端末の留意点として、ヨーロッパで使っている端末とアメリカで使っている端末は若干異なっているので、システムの最適化をどこまでやっていかないといけないか、結構大きな課題となります。先ほどお伝えした通り、多言語化システムを最初から考えておく必要があるということです。あとはデータセンターをどこに置くのか。日本に1つのデータセンターを置くのか、地域別でアメリカに1つ、ヨーロッパに1つ、アジアに1つ置くのかといったことがあります。ここまでで分かるように、海外でリリースするには、かなり複雑なプロセスが必要となりますが、かなりのメリットがあります。

次にデザインの面について。ソーシャルゲームを海外に出す場合、特にアメリカの場合は、ゲームをアートとして解釈しているという人たちが多く、ビジュアルの面では洗練されたものが求められます。例としては「Sword & Sworcery」と「LIMBO」です。もう一つのデザイン面で考えないといけない点は、大体ヨーロッパとアメリカでは、FP（Feature Phone）文化がないので、画面のスクロールにかなりの違和感を感じます。よって1つの画面に情報が収まるようなデザインが必要です。そこで、これからグローバルな市場を視野にいれたGREEの取り組みを紹介したいと思います。

海賊王国コロンブスのTOPページはグラフィックを変えて海外に合った絵柄にしました。

このマイページの色合いも変えています。日本のカードは全てアニメタッチのものですが、海外版のカードはリアルなものにしました。

クエスト進行は、ダイナミックな演出にして、変化を実感できるようなパラメーターのバーを使って表示しています。

ガチャのモチーフは、両方とも宝箱ですが、足が付いてる宝箱はあまり海外で見たことがなく、違和感を感じるので変更しました。

メインのキャラクターは、アニメ系のキャラクターからリアル系のキャラクターに変更されました。

また、これはキャラクターカードですが、元のカードで新しいイラストを作りました。なるべく正確にグローバル版の雰囲気にあったイラストにしました。名前は日本版と同じものもあれば、違うものもあります。翻訳プロセスで、このキャラクターを見たときにどのような名前が合うのか、ということを中心に、海外版の名前を決めています。

次に聖戦ケルベロスです。まずランディングページをなるべくキャラクターを中心にし、ゲームの内容が分かりやすく伝わる取り組みをして、何回もUI改善を行いました。

なるべく汎用性を重視したHeader構成とUI全体のクオリティーUPを重ねました。

バナーの制作では、毎回バナーを作るためにCTR、CVRを分析してどれが海外向けなのかを調べました。モンスターが多いものと、女の子が多いものが良い結果を出しています。

次は釣り★スタです。釣り★スタのガチャのモチーフについて、アメリカのテキサス州のおじいちゃんとおばあちゃんが釣りスタを遊んだ場合に、お寺とおみくじに違和感を感じるので、社内で考え、最終的にラッキーポイントみたいなものに変更しました。

女の子は、魚系のキャラクターに変更しました。こちらの方が、どこのひとが見ても違和感がなく遊べる感じなので、こういう形にしています。

イベントを考えるときに、なるべくどこでも通用するモチーフを中心に展開していきます。たとえば、「safari Island」「Arabian Island」の普遍的な世界観が分かりやすいです。

次は探検ドリランドです。先ほどの倫理チェックの話しになります。このようなカードを使ってもいいのかどうかを社内で考えます。GREEのグローバルプラットフォーム版では「そのまま使う」、「修正して使う」、「使わない」という3つの可能性があります。この2つのカードに関しては、十字架を使っているので、宗教的な理由から避けた方がいいので不採用にしました。また、子どもの肌の露出があるので不採用に。他にもドクロやユーザーに銃を向けるなども留意する必要があります。

続いても探検ドリランドについて、情報の配置はかなり変わっています。ロゴの真下にメッセージがあるんですけど、グローバルプラットフォーム版にはありません。また、ロゴを大きくしたりして、なるべく違和感なく遊べるように改善しています。

次はクリノッペ。ブラウザ向けのゲームだったので、たくさんの絵文字がありました。日本は漢字がある文化なので、文章の中に絵文字が混ざっていても違和感はありませんが、ローマ字系の文化からすると、文字と絵文字は別物で、文章の中に絵文字を入れると、かなり読みにくくなるので、絵文字を削除する形にしました。

もう1つ、日本では箸で食べていたものを、スプーンに変えました。

テキスト管理について。ブラウザゲームは、テキスト管理をPO、DOCファイルで管理することが多いですが、多言語に向いていないので、多言語版を作るときにシステムの再構築をしないといけません。なるべくエクセルファイルで、管理することをオススメします。コンシューマーゲームでは、普通のやり方なんですけど、ブラウザゲームとソーシャルゲームではまだDOCファイルで管理をしていることがあります。なるべくエクセルで管理したほうがいいです。

LQA（言語品質保証）を詳しく説明します。どれぐらい翻訳するための期間と予算が必要になるのか、把握するのが難しいところです。平均的な10万文字のプロダクトであれば、1日に1人の翻訳家が出せるアウトプットは3000文字から5000文字になるので、10万文字であれば、20営業日が必要になります。20営業日でも、チェックなどする作業もあるので、1ヶ月ちょっとかかります。1文字10円から20円ぐらい掛かるので、費用の目安としては、10万文字あたり約100万円ほどになります。LQAは、Linguistic TestingとローカライズQAの2つに分かれます。Linguistic Testingは基本的に、翻訳が合っているのか、誤字脱字があるのかというチェックになります。ローカライズQAは海外版の機能チェックで、時間の表記があっているのか、配信機能が合っているのか、全般的なチェックをします。その他、多言語管理として、グロッサリの制作、単語統一、システムメッセージ統一をする必要があります。

変数からどのような問題が出てくるかというと、日本語版で自分の王様をお選び下さいという選択肢には、王様も女王様も含まれています。それを欧米のローカライズする場合には、男性名詞と女性名詞でもつかえる「monarch」という単語を使って避けましたが、「王様がポーションを渡した」というメッセージの場合は、選んだ王様によって「king」「queen」なのか、メッセージIDを分ける必要があります。これはシステムのバックエンドで行わないと、かなり不自然なローカライズになってしまいます。

もう1つは、「ポーションを1つもらいました」「ポーションを2つもらいました」を英語にすると、「Your receive 1 portion」「Your receive 2 portion」となり、どちらも複数形がないので不自然なまま残ってしまうことになります。そこで複数の変数を導入するか、ローカライズ側で問題を避ける必要があります。最終的に言いたかったことは、グローバル市場で成功するには、なるべく海外のローカルユーザーが自分の国で作られたかのように遊べる、ユーザーエクスペリエンスを提供することが1つの鍵です。

松倉友樹：
後半を始めさせて頂きます。後半はソーシャルゲームを国際化するにあたってのエンジニアリングについて話します。大きく2つのパートに分かれています。前半はシステムデザインについて、後半は実装について、話して行きたいと思います。

まず、国際化と地域化という言葉の整理です。最初にこの定義をしっかり学習していきましょう。分かりやすい図があったので、国際化と地域化とはどういうことなのか概念図で説明したいと思います。下の部分が国際化の部分で、システム自体を色んな言語で表示できるようにするというシステムの土台設計部分です。その土台ができた上で、地域化と呼ばれる上の部分、各国、各地域に適したメッセージだとか通貨の単位を表示する部分です。よって、言語国際化、世界展開するにあたって、まず国際化部分を行った上で、地域化部分をやっていく必要があります。

よく国際化部分をI18n、インターナショナライゼーションと呼ばれていて、上の地域化に関してはL10n、ローカリゼーションと呼ばれています。G10nはグローバリゼーションというような言葉がありこれ、全体を表しています。

次に、ソーシャルゲームを国際化するにあたり、単純に英語化だけで、世界にゲームを配信できると安易に考えてしまいがちですが、実はエンジニアリングにあたっては結構意思決定していかなければならないことや設計しないといけないことがたくさんあります。これについて、議論する必要があるところを整理して、これから説明していこうと思います。

まず、ワールド分割について、ワールド分割はMMORPGとかではよく行われていると思いますが、アメリカだったり、日本だったり、完全にワールドを分割してしまって、その間でユーザー交流ができないようにします。ワールド分割の利点として、リリース地域に最適化できることです。たとえばアメリカに向けて、ゲームを配信するのであれば、アメリカに向けて、アメリカのデータセンターに置いておけば、レイテンシーが少ないですし、アメリカのユーザーだけで、特にコミュにケーションについても意識せずにいけるということがあります。欠点としては、たとえばアメリカと日本のユーザーが交流できなかったり、初心者が途中から参加してくるような状態になってしまい、あまり最適化できないという、課題があったりします。

ソーシャルゲームを国際化するにあたって、まずどのような配信形態を取らないといけないのか、ということもあります。大きく分けて、Webで出すかNativeで出すかという対比があります。それぞれ利点と欠点があります。Webの場合はWebブラウザで遊べるゲームを指し、Nativeというのは、iOS・Android向けのNativeアプリのことです。まず比較対象として、マーケティングです。マーケティングに対して、Webではインターネット全体、Webページ上からとなり、Nativeではマーケットプレイス、GooglePlayやAppleのiTunesストアから購入するという流れになります。レベニューについては、Webでは100％の売り上げがありますが、マーケットプレイスを利用すると手数料などが取られてしまします。次にオフラインデータなんですけど、基本的にコンテンツはキャッシュできるものをローカルに持っていた方がレスポンスが早いので、キャッシュの方法について違いがあります。WebではLocal StrageとかHTTPでExpires設定をしたりだとかいう方法があります。Nativeの場合は、細かく自分の好きなようにキャッシュが設定できます。開発のしやすさについて、Webについては高速に開発もできますし、将来のアーキテクチャもさほど変わらないので、永続可能です。Nativeについてはエンジニアの獲得コストが高かったりSDKのAPI変更について行けなかったりして、メンテナンスコストもかかったりします。更新のしやすさについては、WebはWebのコンテンツを変えてしまえば、すぐに新しいゲームをユーザーさんは遊べますが、Nativeの場合、例えばiOSでは2週間とか3週間リリースの審査に時間が掛かり新しい機能をすぐにリリースできません。

一応、WebとNativeアプリのいいとこ取りをした形態として、NativeアプリをWebViewの中で動かすという方法があります。基本的にGREEは、日本ではWebベースのソーシャルアプリの展開をしているので、それにNativeアプリの便利な要素を加えて、リリースしています。マーケティングについては、やっぱり、赤線が引いてあるところにメリットがあるんですけれども、マーケットプレイスが利用可能。オフラインデータはLocal StrageとNative API両方使えるので、コンテンツの都合のいい方を使うことができます。開発のしやすさも中身はWebなので、PDCを高速に回せる利点があります。更新のしやすさも容易です。

6月にE3がLAで行われたんですけど、そこで実際にユーザーさんが使っているところを見て感じたところがあります。1つ目はスクロールが認知されていない点です。日本ではフィーチャー・フォンからスマートフォンになった流れがあり、アプリを表示してボタンがなかったときにスクロールするんですけど、欧米ユーザーはスクロールしません。下の方にボタンがあるということが全然分からないということがあるので、UIの改善が重要だと思いました。2つ目はバックボタンが認知されていない点です。基本的に欧米ユーザーはNaitiveアプリだと思って、WebViewのアプリも使うので、バックボタンを用意していても、それをバックボタンだと気付きません。UI上で戻るボタンを表示したりだとか、次へボタンを用意していないといけません。3つ目がボタンをクリック連打するという点です。基本的にNativeアプリだとクリックしたらすぐにレスポンスがあって、すぐに分かるのですが、Webの場合は裏で読み込みを行っているので、1回1回ボタンにエフェクトをかけないと、反応がないと思って、ボタンを連打し、裏のコネクションが切れて、次のページが表示されないということがあります。ちゃんとJava Scriptとかでボタンがクリックされたら、ローディングの表示をする必要があります。ここら辺をチュートリアルとかで、学習させないといけないと感じました。それに近いもので、Macのインストールで、一番最初にツーフィンガーのスワイプをやらないとチュートリアルが完了しないというものがあるんですけど、それに近いものが必要かなと。

次に、システムのバックエンド周りの話しです。国内サービスを国際化させる場合、システムのバックエンドについて、あまり議論せずに、これでいいよねっていちいち議論しないことがあるんですけど、そこも議論しなくてはいけない部分があります。例えば、DBに対して、primary keyでユーザーIDとかを作ると思うんですけど、その際のunsigned integer 32bit空間を使ってしまうと、約43億がIDの上限になってしまいます。43億だと、もし海外にゲームを展開をして流行ったりすると、重複登録などがあった場合に、IDを使い切る可能性があります。そこで、1つ上のbigintにして、将来の拡張性を確保した方がいいと感じます。あとで、換える手段もありますが、無駄な時間が掛かるので、拡張性を先に確保していた方が安全だと思います。プログラミング言語に関しては、OSとかアーキテクチャによって変わりますが、基本的に64bitでサポートしてあるもので構築しておいた方がいいです。Javascriptについては、Javascriptにもブラウザ依存がありますが、53bit以上だと数字が使えないので、ユーザーIDが64bit空間の場合、そこら辺は文字列で扱ったりとかして、数値計算に使わないようにしないといけません。

次に、MySQLの文字エンコードについて、MySQLの文字コードにちょっとトリッキーなところがありまして、utf8を使うとUnicode 3.0までしか対応していなくて、約5万文字までしかサポートしていません。なので、最新のUnicodeを 3.1以降の新しいものにも対応していくには、MySQL5.5.3以降のutf8mb4を使わなくてはいけません。例えば、Utf8を普通に使ってしまうと、4バイトの文字列とかが、保存できない状態になってしまいます。

次に、Unicodeと広く言われていますが、Unicodeとは何かということをお話すると、国際的に文字セットを統一しましょうという規格の団体で、国際化するときに、Unicodeのセットを使います。Unicodeにはバージョンがあって、最新が6.1.3になります。大きな変化として、バージョン6.0.0で絵文字が追加され、バージョン3.1で文字数が大きく増えました。

Unicodeを設定している団体のプレゼンが約90枚ぐらいあります。その90枚ぐらいを読むと、Unicodeと文字コードの理解が深まるんですけど、そのサマリーにこのように書いてあります。「Webの場合はUTF-8を使っとけ」とあるのでUTF-8を使っておけば問題ありません。

それでは、ユーザー間コミュニケーションの設計について。基本的にソーシャルゲームではユーザー間のコミュニケーションが重要なファクターになってきます。人とどうコミュニケーションをとらせるかということも重要になります。今までだと、日本語同士で気にする必要がなかったものを気にする必要があります。フリーテキストのなればなるほど自由度は高くなります。その代わりに多言語間でのコミュケーションが取れなくなったりするリスクがあります。定型文の場合、PS3のゲームでよく見かけますが、日本だったら「こんにちは」というものを選ぶと、相手に届くときにはローカライズされた言葉で届きます。新たな方法として、機械翻訳というものがあります。フリーテキストを入力したら、その国に適した言葉に翻訳されるものです。翻訳は適当かもしれませんが、大体意味が通じるというアプローチがあります。ゲームの特性に応じて、そこら辺のコミュニケーションを選ぶ必要があります。

国際化した場合に、大陸間のレイテンシーを考慮しなくてはなりません。これは実際にデータセンターで取ったベンチマークの結果です。日本から西海岸まで0.15秒、西海岸からヨーロッパまで0.15秒とか、日本から欧州まで0.3秒掛かります。経路によって変わったりするんですけど、大体手元で測った感じだと、このようになりました。

0.15秒というのはWebで考えるとそれ程大きな時間ではないと考えてしまいますが、実際にWebページで表示させた場合のプロファイリングはこんな感じです。1つのWebページを表示するにあたって複数のコンテンツをロードしなくてはいけない場合が多くあります。その場合にレーテンシーが徐々に蓄積されて大きく影響してきます。最初の1つのコネクションであれば0.15秒であれば気になりませんが、トータルとして蓄積されていってしまうということがあります。コンテンツのロードを少なくするとか、キャッシュを用意するというのは、日本以上に考えなければなりません。特に日本で生活していると、日本の回線速度はレイテンシーが少ないですし、帯域も広いので、あまり意識しないかもしれませんが、アメリカとかでは、回線状況が悪かったりするので、シビアにベンチマークを取る必要があります。ベンチマークを取るために、現地の動画撮影するのが一番いい方法です。日本でやっていて、これぐらい出るだろうと思っていたものが、全然出なかったり、本当に現地でやるのが重要だと思いました。

先ほどコンテンツのキャッシュが大事だと言いましたが、どのようにやるかというと、大きく分けて、プリロードとダイナミックロードという考え方があります。プリロードはアプリを立ち上げたときに、最初に全部ダウンロードしておく手法で、ダイナミックロードはゲームをやるにつれて、ついでにダウンロードしたものをキャッシュしておくという手法です。

Web系アプリだとこれだけのキャッシュの手法があると考えていて、上にいけばプリロード、下にいけばダイナミックロードなアプローチになると思います。使えるものとして、Nativeアプリ側で、アプリをプリロードして、キャッシュしておく方法です。ダイナミックロードとして、HTTPのExpireヘッダにいつExpireするのかを決めて、ブラウザのほうに全てキャッシュを任せてしまうという方法があります。場合によってはハイブリッドに使えることもできるので、それをうまく使って、アプリケーション構築をします。

HTMLコンテンツデリバリーについてまとめると、まずリダイレクトを控えます。リダイレクトもレイテンシーに響きます。静的なファイルはクライアントでキャッシュします。静的コンテンツについてはCDNをできるだけ使いましょう。問い合わせは最低限に、Webを作っていれば当たり前のことですが、当たり前のことを1つ1つやっていくことが、海外の場合は特に重要になってきます。

国際化になったときに重要になるものが言語の抽象化になります。細かいところでいうとタイムゾーンによる時間の出し分け。コンテンツの最適化とかあるんですけど、言語の抽象化は大変で、のちのち運用のときに重要になってきたりします。言語の抽象化について深く考える必要があります。

言語の抽象化の成熟度を簡単にまとめました。レベル1は英語対応しておけば、マーケットが広がるので、英語対応するといったものです。レベル2で複数のメジャーな言語に対応したり、よりローカライズしていくような対応。まず、レベル1、レベル2を目指す必要があります。

色んな国際化の手法が存在していて、オープンソースのものを調べてみたんですけど、デファクトスタンダードになりそうなものは存在していませんでした。とりあえず、ベンチマークを取った結果、gettextが早かったので、gettextで実装してみました。

gettextのベンチマークは他と比べて一番早かったです。

コードはこんな感じで、日本語の前後にgettextの関数を入れ込んで、言語を抽象化しています。

HTMLに関しても同じように、オリジナルのファンクションを定義してマークアップしていきます。

最終的にgettextの適応ファイルにこのように落ちていきます。

参考までに1プロダクトに使った言語の数です。上の方は1プロダクトのワード数2216、下の方はマルチバイトで計算すると、1プロダクトに4万5000文字ぐらいありました。

一応gettextを実行した結果、いろいろ課題がありました。PHPで作っている場合、Apacheがgettextの言語テキストをキャッシュするので、もし言語のキーを変えたり、翻訳を変えたりすると、Smartyのテンプレートの削除やApacheの再起動が必要となる点。また、日本語は同じだが、英語の表記を変えたいところに対応できない点などがありました。