プロデューサーや専門家らと共に、UX向上を目指す。“ゲーム✕AI”を推進する「ハブ役」の正体とは?

「インターネットやAIを活用し、永久ベンチャーとして世の中にデライトを届ける」をビジョンに掲げるDeNAでは、AIをゲームに積極的に導入・活用していくため[su_highlight background=”#fcff99″]ゲーム事業部内に「AI推進部」が新設[/su_highlight]されました。

これまでもDeNAの運営タイトルにはAIが活用されてきたケースがありますが、AI推進部の誕生によって今までと何が異なるのでしょうか? 今回、AI推進部の部長である小東祥、そして所属メンバーの佐藤勝彦と河合安甲子に、部のビジョンや目指す姿などを聞いてみました。

“ゲーム✕AI”を推進する専門部署

――まずはAI推進部の取り組みについて教えてください。

小東祥(以下、小東:AI推進部はその名の通り、AIを活用したゲーム開発を推進するために発足した部署でして、[su_highlight background=”#fcff99″]「AIを活用して構造的強みを構築する」[/su_highlight]というビジョンを掲げています。

社内では2017年頃からIPタイトルにおけるAI活用をきっかけにし、これまで『逆転オセロニア』で多くの事例を生み出してきました。

ただ、これまでのAIに関する取り組みは、「AIを活用したい」という意思を持ったメンバーが個々でAI本部に所属するリサーチャーなどに相談し、独力でAI活用を模索してきた背景があります。

ただその場合ですと、以下のようなさまざまなデメリットが発生するケースもありました。

・最後までやりきる事自体が非常に難しい
・成果が出るまでに時間が必要になる
・役割分担がうまくできない
・ゲーム開発における優先順位が下がりがち(ボトムアップの取り組みになるため)

そこで今回、ゲーム事業部内に専門部署を立ち上げることで、[su_highlight background=”#fcff99″]ゲームにおけるAI導入のスピードアップ[/su_highlight]や、[su_highlight background=”#fcff99″]AIの有効活用によるUX(ユーザー体験)向上[/su_highlight]を目指していきたいと考えています。

小東 祥 | AI推進部 部長
2012年新卒でDeNA入社。入社以来一貫してゲーム事業領域でのプラットフォーム/ゲームタイトル分析を担当。 分析部の部長、『逆転オセロニア』や『メギド72』など自社オリジナルゲームの運営部門の部長を経て、2019年4月よりAI推進部の部長に就任。ユーザーインテリジェンス部の部長と兼務。

社内のAI専門家を繋ぐハブとなる

――AI推進部の役割や、部内の体制など詳しく教えてください。

小東:AI推進部は[su_highlight background=”#fcff99″]部署間の「ハブ」になる役割[/su_highlight]を持っています。

そのため下図のように、社内のAI専門家(Kagglerやリサーチャーなど)と、タイトル開発チームのサポート役として、要件定義や計画立案、導入サポートなどを橋渡ししていくイメージです。

AIに関する情報を集約し、AI機能の企画から実装まで、社内各部署との架け渡しを担っている

小東:この体制を実現するためには、AI推進部内にさまざまな経験を持ったメンバーが必要となります。単純に機械学習に得意な人だけではうまくハブになることもできませんし、ビジネスだけだと、ソリューションが十分に理解できないなどの懸念が出てきます。

そのような不足点を補完するために[su_highlight background=”#fcff99″]職種混合チーム[/su_highlight]を作り、課題解決に向けてチームとして柔軟に推進していくことが大事です。タイトル開発チーム単体ではAI施策の推進がやりきれない時には、チーム外から我々というリソースを補強し、AI施策を迅速に推進できると理想ですね。

他にも、部全体の役割として、ゲームに限らずAI領域にはどのような最新技術があり、どんなユースケースがあるのかなど、幅広く知見を収集する役割も担っています。

最新知見を蓄積し、現状の各開発チームの課題に対する解決策(=技術)が判明してきたら、それを実現するための要件定義や推進をしていくのも我々の役目です。決して受け身にならず、[su_highlight background=”#fcff99″]AI推進部が起点となって、各部署と一緒に“ゲーム✕AI”の理想形を追求[/su_highlight]できればと考えています。

――ハブになるだけでなく、AIのプロフェッショナル集団でもなければいけないと?

小東:そうですね。社内のAI専門家を適切に巻き込むことが必要なので、彼らが何を得意としているのか、技術がどの分野で役立つのかを見極めるためには、我々もある一定の専門性を持たねばなりません。

ただ、AIの学術的な知見などは専門家に任せつつ、我々は対象となる技術が[su_highlight background=”#fcff99″]どのように事業価値を生み出せるのかを考え、実現に向けて推進していくことが大切[/su_highlight]だと考えています。

――各関係者をつなぐには、AI推進部のメンバーもゲームのドメイン知識など、一定の広い知識が必要になりそうですね。

小東:そうですね。取り組む領域によっても変わりますが、例えばQAの効率化ならQAの実作業、デザインのアセットをAIで動かすにはデザイナー、ゲームAIを作るならクライアントサイドの作り方を、それぞれ知らなければなりません。

すべての知識や技術をひとりでカバーするのはとても難しいので、メンバー同士で得意・不得意を補い合い、チームとして機能するようにバランス調整をしていく予定です。

――現在、開発中のプロジェクトとも連携はしているのでしょうか?

小東:はい、詳しくはお話できませんが、すでに動き始めています。DeNAでは[su_highlight background=”#fcff99″]今後も新規タイトルの開発を進めていきます[/su_highlight]ので、AI推進部の存在感をさらに発揮していきたいと考えています。

――新規タイトル開発の際には、プロデューサー陣とはどのように連携していくのでしょうか?

小東:初期の企画段階からプロデューサーとは密に連携していきます。

プロデューサーは事業責任者であり、AIを含めた施策が実現したときに、それが本当に費用対効果に見合うのか、そして望む価値が競争力につながるのかなど、さまざまな視点で状況を把握していきます。我々はそのような[su_highlight background=”#fcff99″]プロデューサーの一助になるべく、AIを軸にサポート[/su_highlight]できればと思います。

もちろん新規タイトル・運用中タイトル問わず、「面白いからやってみよう!」というスピード感のある取り組みも存在しますが、AI導入時は費用やリソース、開発期間も大幅に必要になるため、事前にプロデューサーと期待値を含めて入念にすり合わせをしています。

その後、マーケターやディレクター、プランナー、デザイナー、エンジニアなど、開発フェーズに応じて、各職種との連携も進めていきます。特にゲーム内にAI機能を組み込む場合には、プレイヤーへの伝わり方などについて、プロデューサーをはじめとした開発メンバーとも密に連携します。

武器商人のような支援部門に

――同じく新設された「ユーザーインテリジェンス部」と目的が似ている部分も多い印象ですね。

小東:そうですね。開発チームに対して、足りない視点を補ったり、蓄積している知見を横展開する、という側面は似ていると思いますね。

AI関連の技術を扱うのがAI推進部で、マーケティングリサーチなどで分析する強みを持つのが、ユーザーインテリジェンス部です。お互い持つ武器が違うだけで、目的とするミッションはほとんど変わらないと思っています。

ヒットの確率を1%でも高く!ゲームの“面白さ”を科学する、DeNAの新たな挑戦【ユーザーインテリジェンス部 小東祥】

――プロデューサー陣にとっては、心強い武器になっていきそうですね。

小東:そうなってくれたら、嬉しいですね。RPGで例えると、僕らは勇者に強い武器を与える「武器職人」のような役割だと思っています。ドラゴンに勝つにはこの武器がオススメ!みたいな(笑)。

――ちなみに内製や協業など、開発体制の違いによって動き方はどう変わるんでしょうか?

小東:意思決定や推進においては、関連する人間が多ければ多いほど複雑になります。特に協業や複数のパートナー会社様と開発を進める場合は、お互いの担当範囲などもあるので、推進していく難易度は上がると思われます。

ただ、最終的な目的は変わらないはずですので、そこはうまく[su_highlight background=”#fcff99″]AI推進部がリード[/su_highlight]できればと考えています。

――知見やユースケースを蓄積していけば、新規IPの獲得もできるかもしれませんね。

小東:我々がAIによって構造的な強みを作り、それが業界における優位性となる。その結果として[su_highlight background=”#fcff99″]新規IP獲得に繋がる、という流れは理想[/su_highlight]ですね。

DeNAという会社自体では「AI」に強みがあると認知いただけている方も多いと思いますが、“ゲーム✕AI”も世間にもっと認知されていけば、他のIPホルダー様もDeNAを魅力あるパートナーとして注目してくれるかもしれません。

【データサイエンスの競技者”Kaggler”が活躍する職場】社内での立ち回りやエンジニアやアナリストとの関わり方、今後のビジョンが語られた

そして結果的に我々が目指す「AIを活用して構造的強みを構築する」の実現(パブリッシャー戦略への貢献)にもつながると思っています。

――他社でAI推進部のような機能を持つ部門はあるのでしょうか?

佐藤勝彦(以下、佐藤:ゲーム業界の国内企業ではほとんど聞かないですね。

AI研究が活発な会社は数社あると個人的に認識していますが、R&Dとタイトルの内部をつないで有機的に推進する部署というのは、[su_highlight background=”#fcff99″]おそらくDeNAがはじめて[/su_highlight]だと思います。

小東:AIリサーチ部門に関しては各社でも展開していますが、それをきちんと事業に落とし込むには、推進部のような部署が必要だと思います。他社ではちょうど着手しはじめたくらいかもしれませんね。

佐藤 勝彦
フロムソフトウェア、CygamesResearch、ドリコムを経て、2019年7月にDeNAに入社。ゲームxAIを軸足に、タイトルの開発運用と技術研究に従事。エンジニア・リサーチャー・企画・ディレクターと職域を広げながら、知見共有や、タイトル・R&D部署間のシナジーの向上に注力。

<講演歴>
『ShadowverseのゲームデザインにおけるAIの活用事例、 及び、モバイルTCGのための高速柔軟な思考エンジンについて』(CEDEC2016)

十人十色の強み

――AI推進部にはどんな経歴・スキルをもったメンバーがいるのでしょうか?

佐藤:私は今年7月に入社したばかりですが、[su_highlight background=”#fcff99″]何らかの専門性を持った方がすごく多い印象[/su_highlight]があります。河合さんもそうですが、横断組織として、タイトルや各部署に寄り添ってシナジーを高められるよう、豊富な経験を持ったメンバーが集まっていると感じています。

――河合さんは、部発足時のメンバーだと事前に聞いていますが。

河合安甲子(以下、河合:そうですね。私はもともと社内の開発基盤部に所属していたのですが、個人的にAIに興味があって、AIに関するセミナーに足を運んだりなど、独学で勉強していました。

当時の上長に「AI研究者がゲーム開発チームと直接連携するのは大変なので、その橋渡しをできる人が必要かもしれません」と話したタイミングで、AI推進部を立ち上げることを聞かされました。

河合 安甲子
コンシューマ向けゲーム開発/ゲームエンジン開発に携わり、2017年にDeNAに入社。ゲーム基盤部に配属された後、AI推進部に異動。

小東:あの時はかなりタイムリーでしたね(笑)。

――河合さんはすでに、このような機能を持つ部署は必要だと感じていたのですか?

河合:はい。当時は関係者ではなかったため、遠目でしか見ていなかったのですが、現場の大変さは感じていました。(設立について)急いで小東さんに話を聞きに行きましたよ。

小東:河合さんがAI推進部の一番最初のメンバーなんです。

河合:小東さんと2人からのスタートでしたね。今はメンバーは増えていますが(笑)。

小東:河合さんは、ゲーム開発におけるスキルや知識などを持っていることが強みなんです。ゲーム開発にAIを組み込んでいくことが、AI推進部のコアな目的ですので、[su_highlight background=”#fcff99″]ゲーム開発のことを理解していることは重要[/su_highlight]ですからね。

さらに、今まで自分が経験したことがない領域にも、積極的にキャッチアップしてくれますし、開発チームのエンジニアと連携して、着実に実装へと進めてくれるので本当に助かっています。

――ちなみに佐藤さんは2019年7月に入社されましたが、どのような経緯でAI推進部にジョインしたのでしょうか?

佐藤:私はもともとコンシューマゲームの開発会社で、ゲームエンジンの開発や技術研究、タイトルのAI実装などを手がけるエンジニアからキャリアをスタートしました。その後も、研究部署とタイトル開発の双方をまたいだ「ゲームAIのリサーチャー」として活動する中で、いろいろな課題を目の当たりにしてきたんです。

――いろいろな課題とは?

佐藤:冒頭で小東さんが話していたような、立場や目線の食い違いによるトラブルや、場合によってはプロジェクトが途中で消えてしまうなどの課題を見てきました。そこで[su_highlight background=”#fcff99″]「横断的な目線でゲームとAIに触れる人材がいれば、プロジェクトは進みやすくなるのでは?」[/su_highlight]と感じていました。

それからは、企画やディレクターとしてゲーム業界で職域を広げながら、橋渡しになれるような役割を模索していたときに、小東さんからDeNAでAIの横断推進に注力することを聞いて、「これは乗るっきゃない!」と共感して入社を決めました。

小東:佐藤さんのスゴいところは、経験に裏付けされた「引き出しの多さ」です。さらに引き出したものをうまくデリバリーする気遣いも細かいですね。

彼はエンジニアからキャリアスタートして企画やAI推進、PM的な動きもしてきました。業務を多角的に見てきているからこそ、AIの活用方法や、AI導入時にトラブルが発生しやすい箇所などを嗅ぎ分ける能力も持っていると感じたので、私が熱烈に口説いて入社してもらいました。

それに一般的に分析者って、比較的堅苦しかったり、データばかり見ていて話しかけづらいイメージがあると思うのですが、佐藤さんは物腰柔らかで、しっかり物事を前に進めるコミュニケーションができる人ですね。


AI推進部の人員体制。多彩な知見を持つメンバーで構成されている。

(社内資料より抜粋)

――そのような経緯があったんですね。ちなみに佐藤さん、河合さんは入社前にDeNAという会社を外から見てどんな印象でしたか?

佐藤:最近ではゲーム業界を含めて、「CEDEC2019」の公開セッションを見てもわかるように、AIに関して実際のデリバリーを意識した取り組みが、各社で増え続けています。

【CEDEC2019】DeNAゲーム事業部関連のセッション内容をチェック

その中でもDeNAは特にモバイルの領域において0→1の先行事例をいち早く発表しています。課題解決の苦労を経験した上で、[su_highlight background=”#fcff99″]1→100にスケーリングするためにはどうしたら良いか[/su_highlight]という目線での取り組みを推進されていて、良い意味で異色な会社だと感じました。

河合:私も丁寧にゲーム運営している部分は、外部から見ても感じていましたね。

佐藤:分析に真摯に向かい合っている姿勢もすごく感じていました。

分析の本質は、数字とにらめっこすることにあるわけではなく、サービスに関わる方々やプレイヤーにとって価値ある時間をより高めていくにはどうすればいいか、[su_highlight background=”#fcff99″]割と生々しい部分に真剣に向き合う必要がある[/su_highlight]と思っています。

『逆転オセロニア』や『メギド72』の立ち上がり時から改善を重ねて、どんどん愛されるサービスに変わっていった過程を、外から見ていても非常に感銘を受けましたし、分析に強みを持った会社だからこそ、再現性やスケーリングが実現できているのかな、と感じていました。

【DeNA分析部特集Vol.1】『逆転オセロニア』を支え続けるDeNAゲーム分析の強さとアナリストに求められる役割とは?

【DeNA分析部特集Vol.5(前編)】未来を予測し、最適解を導き出し続ける組織 〜分析の高度化に向けた次のチャレンジとは〜

――プロジェクトに寄り添うことで、提案をし合ったり、他の部署と横断して施策を考えることもできますよね。

佐藤:部署・職種を問わず皆さん本当に多くの知見を持っているので、仲立ちを通じて、色んなアイディアに触れられるのは非常に刺激的ですね。

相談にも真摯にも乗っていただけますし、「このようなユースケースで技術を使えないか?」「この部分を改善できるともっと開発が楽になる、 サービスの改善・開拓に繋がるのでは?」といった提案も数多くいただけます。

佐藤:それにDeNAの特徴的なところは、ゴールベースで話をする、[su_highlight background=”#fcff99″]コトに向かう目線[/su_highlight]があります。目線が揃っているので部署の壁も感じませんし、相談もしやすいですね。

実際にサーベイするときに分析部のメンバーと一緒に取り組めたり、アイデアが上がってから検討が始まるまでもタイムラグが本当に少ないです。小東さんに相談すると「すぐ検討しちゃってください!」って快諾してくれます(笑)。

河合:NOと言われたことはほとんどないです!とても動きやすいですね。

小東:褒められると、ちょっと照れますね……(笑)。

個のチカラを活かした推進力

――少し話は逸れますが、佐藤さんと河合さんのお互いの印象などを教えてください。

小東:おっ、それは聞いたことないかも……(笑)。

河合:私はもともと開発基盤部に所属していました。前職もゲームエンジンを手がける部署でしたので、AIについては正直まだまだ勉強中の身です。

AIに関しての一般的なセオリーについては、この部署で佐藤さんに教えてもらうことが多いですし、目指すべきプロセスが明確に可視化された気がします。

もちろんみんな実現したいことは描けるんですが、AI導入のメリットや意図、手順を開発側に伝えたり、地道に布教していくことを教えてくれたのも佐藤さんです。自分の作業も含めて、進む方向がすごくクリアになった感じです。

佐藤:ありがとうございます……(照)。河合さんは、エンジニアとして並外れた実力を持っているのは当然なんですが、それ以上に話しやすく、いろんな人をコミュニケーションで結ぶ「足」がめちゃくちゃ速いと感じています。巻き込みたい人に対して、次の日にはランチの予定が組まれているのは驚きです(笑)。

また、人柄が柔らかく、相手の目線に寄り添って話をするので、ミーティングでも全体の雰囲気が和やかになりやすいんです。しかもエンジニアとして課題感の理解も早く、タイトルの経験も多いので、河合さんがいるととにかく話が早くなります。

河合:そんな風に言っていただけるなんて……ありがとうございます。もっと頑張ります……!

“ゲーム✕AI”とQAのさらなる可能性

――それでは最後に、AI推進部の今後の取り組みなどについて教えてください。

小東:『逆転オセロニア』のように直接ゲーム内のAIがプレイヤーに触れられて、UX(ユーザー体験)を向上させていくような機能を作っていくのが、ゲーム開発において一番コアな部分です。AI推進部としても、このような事例を数多く生み出していけるように注力していきたいですね。

もうひとつは[su_highlight background=”#fcff99″]QA(品質保証)[/su_highlight]です。

世の中のAI活用はコストカット目的の側面が強く、QAはそれを担うイメージが強いですが、開発メンバーが膨大な時間を費やしているバグチェックや修正などをAIが肩代わりできれば、空いた工数をゲームの面白さを考える時間に当てられると思っています。

それが実現すれば、UX(ユーザー体験)もよりリッチになっていく可能性があるので、QAに関しても今後は注力していきたいですね。

課題点については、まだメンバーが少ないので、同じように動けるメンバーが増えてくれると嬉しいですね。その中でもデリバリーを担う、クライアントエンジニアが増えてくれると助かります。

特にエンジニアリングの部分は、ゲームタイトルごとの開発環境や使用ツールなどを把握して推進するのはとても大変ですし、施策を増やす上でボトルネックになる部分だと感じています。

――9月に開催された「Unite Tokyo 2019」にてシステム本部のSWET(Software Engineer in Test)グループとも連携するセッションが公開されていましたが?

小東:そうなんです。あの施策はAI推進部が旗振りをしており、QAの領域に注力していく中で、SWETのような専門家やタイトルの開発メンバーを巻き込んで進んでいったひとつの事例になります。今後はあのような取り組みをどんどん増やしていこうと思っています。

【Unite Tokyo 2019】「Unity Test Runnerを活用して内部品質を向上しよう」セッションレポート

――ありがとうございました。

インタビュー・執筆:細谷亮介
編集:佐藤剛史
撮影:齋藤暁経

※本記事掲載の情報は、公開日時点のものです。

【CEDEC2019】DeNAゲーム事業部関連のセッション内容をチェック

CEDEC2019

2019年9月4日(水)~9月6日(金)の3日間で開催された「CEDEC2019」では、DeNAゲーム事業に関する7つのセッションが行われました。編集部では、今回はその7セッションをピックアップしましたのでぜひご確認ください!

登壇情報(9月4日)

ゲーム開発者とゲームメディアの理想の関係とは?

■セッション内容
リアルイベントやコミュニティの醸成、企業が独自のオウンドメディアを展開するなど、ゲーム開発者がSNSなどで自ら発信することも増えてきた昨今、ゲーム開発者とゲームメディアの理想の関係とは何か? DeNAのゲーム事業部を率いる佐々木悠と、2019年7月より、まったく新しいメディアの形を模索して完全独立系のメディアとして再スタートをした電ファミニコゲーマー編集長のTAITAIこと平信一によるディスカッションです。(開始時間/14:50〜)

■登壇者
佐々木 悠(株式会社ディー・エヌ・エー)
平 信一(株式会社マレ)

[su_note note_color=”#ffffff” radius=”2″]
[su_row][su_column size=”1/6″ center=”no” class=””]
[/su_column] [su_column size=”5/6″ center=”no” class=””]
■DeNA登壇者プロフィール

佐々木 悠
執行役員 ゲーム・エンターテインメント事業本部 ゲーム事業部長

慶應義塾大学卒、2009年DeNA新卒入社。入社後はモバイルオークションのサイト運営、広告営業の経験を経て、2010年にゲーム事業に異動。住み着き妖精セトルリンの運営、有名IPゲームの立ち上げを行いつつ、組織マネジメントに従事。アプリ開発部署の部長として『三国志ロワイヤル』、『FINAL FANTASY Record Keeper』の立ち上げ後、職能組織長として部署の立ち上げとマネジメントを実施。その後、専門役員として協業案件に従事して新規ゲームの立ち上げに尽力。2019年4月からゲーム・エンターテインメント事業本部ゲーム事業部長に就任。

■受講者へのメッセージ

新しいメディアの形を模索し続ける電ファミニコゲーマー様と、ゲームの文化を伝えていくために開発者とメディアがどう向き合い語り合うのがよいか?情報発信の選択肢が多様化している今だからこそ改めて検討していければと思います。

【CEDEC2019】「ゲーム開発者とゲームメディアの理想の関係とは?」セッションレポート

[/su_column][/su_row][/su_note]


組織的に Game x AI を推進していくための方法論
〜『逆転オセロニア』 の一歩先へ〜

■セッション内容
私たちは運用中のモバイルゲーム『逆転オセロニア』においてデッキ編成をする AI、人間のような戦いをする AI をリリースしました。まず今回は、AI をうまく活用することができた開発プロセスなどを整理し、リリースまでの軌跡を振り返ってみます。

その中で技術検証からリリースまで一貫して行った経験から、AI 活用を成功させるために重要な要素がいくつか見えてきました。過去事例の収集、自社の個別ゲームタイトルの要望の把握、投資領域の選定、課題設定への落とし込み、AI開発をスムーズにするような周辺ツールやデータの整備、そしてそれを可能にするための部署横断での体制の整備……。

本セッションでは、これらの「AI 開発のあるべき」を検討します。その中でも技術的に重要になってくるシミュレータについては具体的な設計を交えてお話しします。(開始時間/17:50〜)

[su_note note_color=”#ffffff” radius=”2″]
[su_row][su_column size=”1/6″ center=”no” class=””]

[/su_column] [su_column size=”5/6″ center=”no” class=””]
■登壇者プロフィール

田中 一樹
AI本部 AIシステム部 データサイエンス第一グループ
データサイエンティスト

2017年に DeNA 入社後、データサイエンティストとしてアプリゲーム『逆転オセロニア』に関する AI 機能の開発に従事し、機械学習、強化学習、データサイエンス技術の研究開発 / 設計から実応用に携わる。現在は、多様な事業へのデータサイエンス活用を目指した研究開発や課題発掘に従事。大学時代は電力系統に関する数理計画や統計的機械学習の工学的応用を研究。『速習 強化学習 −基礎理論とアルゴリズム−』(共著)を執筆。データ分析の大会に没頭し複数大会で入賞。Kaggle Master。

■受講者へのメッセージ

AIをモバイルゲームに活用するのはとても面白くもありますが、大変な面もあります。特に、AIの不確実性や、どんなAI機能がプレイヤーさんに価値を提供できるのか、真摯に向き合って考えなければいけないことは多くあります。

本セッションでは、現在AI機能を開発しているまたは将来に開発をしたいと考えている皆様のお役に立つ情報を発信できればと思います。[/su_column][/su_row][/su_note]

[su_note note_color=”#ffffff” radius=”2″]
[su_row][su_column size=”1/6″ center=”no” class=””]

[/su_column] [su_column size=”5/6″ center=”no” class=””]
■登壇者プロフィール

岡田 健
AI本部 AIシステム部 MLエンジニアリンググループ
MLエンジニア

DeNA所属のエンジニア。元数学徒。ゲーム『FINAL FANTASY Record Keeper』を開発 / 運用していたが、2018 年からはその経験を生かして AI によってゲームのおもしろさの軸を増やしたり、ゲーム作りの方法を変革する側に。『逆転オセロニア』への AI 導入では学習高速化、学習管理の仕組み作り、実サービスのためのアーキテクチャ設計と実装などを担当。

■受講者へのメッセージ

AI は、言うなれば魔法です。便利な半面、それなりにコストがかかりますし、専門家が必要なことが多いです。準備が不完全であれば、不発になるときだってあります。敵の弱点を突けなければ、費用対効果に合わないこともあります。

魔法使いを上手く既存のパーティーに組み込んで、より難易度の高いことをなしたり、今まで行けなかったところに行くためにはどうするべきか? 我々のケースを通じてお伝えできればと思います。

【CEDEC2019】「組織的にGame x AIを推進していくための方法論~『逆転オセロニア』のAIの一歩先へ~」セッションレポート

[/su_column][/su_row][/su_note]

登壇情報(9月5日)

自由に移動できるVRゲームにおけるプレイヤーの誘導、こうやってみました

■セッション内容
このセッションでは、VR空間内を自由に移動できるタイプのゲームにおいて、いかにプレイヤーの行動を制御しゴールまで導くかという課題をどのように解決したか、実例をもとに説明します。加えて、VRゲームに没入するために必要な『没入感』や『納得感』を上げるために行った、世界観を含めた演出についても取り上げます。

カテゴリはAC分野としていますが、ゲームデザインやサウンドまで幅広く演出のお話をする予定です。今回はDeNAが研究開発しTGS2018やLAVAL VIRTUAL 2018にも出展した謎解きアドベンチャーVRゲーム『VoxEl(ボクセル)』を実例としてご紹介します。(開始時間/14:50〜)

■登壇者
永田 峰弘(株式会社ディー・エヌ・エー)
高橋 宏典(あまた株式会社)

[su_note note_color=”#ffffff” radius=”2″]
[su_row][su_column size=”1/6″ center=”no” class=””]

[/su_column] [su_column size=”5/6″ center=”no” class=””]
■DeNA登壇者プロフィール

永田 峰弘
ゲーム事業部Publish統括部第四プロデュース部
ゲームデザイナー

サウンドクリエイターを経てゲーム業界にプランナーとして入り、2011年にDeNAに入社。モバイル、スマートフォン向けタイトルを中心に企画、ディレクションを担当。

複数タイトルの企画面を横断でサポートしつつVRの研究開発に着手。2018年にハイエンド向けVRゲーム『VoxEl』を開発、TGS018やLAVAL VIRTUAL 2018に参考出展。本タイトルではプロデューサー、企画、シナリオ、サウンドを担当。酒粕から作った甘酒がすきです。

■受講者へのメッセージ

『VoxEl』開発中に試行錯誤したこと、またTGS2018などで試遊していただいた際に得られた知見を元に、VR開発の初歩的な注意点から、VR空間内でのプレイヤー誘導、また納得感や没入感を高めるために実装した内容をご紹介します。
受講していただく皆様にとって、より楽しいVR体験を作るための手助けになればと思います。

【CEDEC2019】「自由に移動できるVRゲームにおけるプレイヤーの誘導、こうやってみました」セッションレポート

[/su_column][/su_row][/su_note]


『逆転オセロニア』における、機械学習モデルを用いたデッキのアーキタイプ抽出とゲーム運用への活用

■セッション内容
プレイヤーが構築したデッキを用いて対戦する PvP ゲームにおいて、代表的なデッキ構築パターン (アーキタイプ)、そして各アーキタイプの使用頻度、 総合勝率、 対戦成績などの KPI を継続して観測することは、 現状のゲームバランスを把握し、 プレイヤーのゲーム体験を向上させる上で有用である。

本講演では、 『逆転オセロニア』における、 機械学習モデル (トピックモデル) を用いた、 大規模データからのデッキアーキタイプの抽出、 アーキタイプに関連する KPI の可視化、 これらを用いたゲーム運用への活用について紹介する。(開始時間/16:30〜)

[su_note note_color=”#ffffff” radius=”2″]
[su_row][su_column size=”1/6″ center=”no” class=””]

[/su_column] [su_column size=”5/6″ center=”no” class=””]
■登壇者プロフィール

安達 涼
ゲーム事業部Publish統括部分析部
アナリスト

人間の意思決定プロセスの数理モデル化と、その神経基盤を解明する研究に従事し、カリフォルニア工科大学PhD(計算論的神経科学)を取得。2018年3月にデータアナリストとしてDeNA入社。機械学習の手法のみならず、行動経済学の知見などを用い、人間のゲーム内外での行動データを包括的に理解することで、ゲームタイトルの運営力・UX向上を目指している。

■受講者へのメッセージ

モデル構築から実運用まで幅広い内容をカバーしますので、みなさまお気軽にお越しください。

[/su_column][/su_row][/su_note]

[su_note note_color=”#ffffff” radius=”2″]
[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]
■登壇者プロフィール

岩城 惇
ゲーム事業部Develop統括部企画部
プランナー

大学卒業後、ゲーム制作の道へ。アクションゲームやRPGの開発に携わる。『逆転オセロニア』では運用プランナーとして機械学習を用いたキャラクターのレベルデザインに携わっている。

■受講者へのメッセージ

機械学習が実際に運用の現場で活用されている「生」の様子をお伝えできればと考えております。

【CEDEC2019】「『逆転オセロニア』における、機械学習モデルを用いたデッキのアーキタイプ抽出とゲーム運用への活用」セッションレポート

[/su_column][/su_row][/su_note]

登壇情報(9月6日)

ゲームと機械学習の最前線
〜現状と未来を正しく捉えるために〜

■セッション内容
近年の機械学習研究の進捗は目覚ましく、ゲーム産業でも様々な活用事例が報告されてきています。一方で、これらの技術に対する加熱した期待値も成熟を迎え、「ゲーム開発・体験にどの程度インパクトを与えるか」「どのように戦略的な活用を目指していくべきか」といった論点に注目が集まっています。

本セッションでは、ゲームと「機械学習」の関わりについて認識を深めていきます。パネリストとしては、機械学習導入を実際に成功させ、ゲーム開発やUXへの影響について見通しを持つメンバーを集めました。国内外で発表されている多くの事例を整理し、2019年時点で出来ること・不足している要素、中長期的な戦略について、現実的な目線で議論を展開します。(開始時間/11:20〜)

■登壇者
奥村 純(株式会社ディー・エヌ・エー)
三宅陽一郎(株式会社スクウェア・エニックス)
長谷 洋平(株式会社バンダイナムコスタジオ)

[su_note note_color=”#ffffff” radius=”2″]
[su_row][su_column size=”1/6″ center=”no” class=””]

[/su_column] [su_column size=”5/6″ center=”no” class=””]
■DeNA登壇者プロフィール

奥村 純
AIシステム部 AI研究開発グループ
AI研究開発エンジニア

国内外の研究機関で観測的宇宙論の研究に従事し、京都大学理学研究科宇宙物理学専攻にて博士号取得。DeNAではデータアナリストとしてユーザー体験や事業推進をデータからサポートすることを目指し、主にゲーム領域のデータ分析・パラメータ設計の経験を積む。2017年よりAI研究開発エンジニアに転身しゲームAIの研究開発を推進、 複数のAI施策をリリース。機械学習の実ビジネス適用や、UXデザインに興味を持っている。

著書:
『データサイエンティスト養成読本 ビジネス活用編』
講演:
『次世代QAとAI 』(CEDEC2018)
『一周年で爆発した「逆転オセロニア」における、ゲーム分析の貢献事例』(CEDEC2017)

■受講者へのメッセージ

昨年は『次世代QAとAI』というテーマで、QA文脈にフォーカスして機械学習の活用方法や見通しを議論しました。その後も技術は様々な形で進展しており、ゲーム開発の多くの領域で機械学習導入のトライアルが行われたり、学術業界によるゲームAI研究も進んだりしています。

本セッションではより広い観点から「ゲーム」と「機械学習」の関係を考えます。国内外の最新事例の紹介から現在の状況を俯瞰し、現実的な目線で今後の見通しについて議論を広げていけたら嬉しいです。

【CEDEC2019】「ゲームと機械学習の最前線~現状と未来を正しく捉えるために~」パネルディスカッションレポート

[/su_column][/su_row][/su_note]


サービス終了寸前だったタイトルが、CMを使わずにDAUを増やして九死に一生を得たSNSプロモーション術

■セッション内容
本セッションでは、SNSでの情報の伝播を戦略的に盛り込んだコミュニケーションの手法を紹介します。
主にtwitterを通してゲームの情報が伝わったり、SNSでの盛り上がりによって「いまこのゲームがアツい」といった雰囲気を作り出すことで、新規のプレイヤーを呼び込んだり、ゲームから離れていたプレイヤーに復帰していただいたりすることが可能です。

ゲームリリース1周年のタイミングを機にプロモーション戦略の柱の1つに「SNSでの盛り上がり」を設定し、サービス終了の危機を脱することができた「天華百剣 -斬-」の事例と共にその手法を紹介します。(開始時間/13:30〜)

[su_note note_color=”#ffffff” radius=”2″]
[su_row][su_column size=”1/6″ center=”no” class=””]

[/su_column] [su_column size=”5/6″ center=”no” class=””]
■登壇者プロフィール

ナカムラ ケンタロウ
ゲーム事業部Publish統括部第四プロデュース部
「天華百剣 -斬-」プロデューサー

2013年に株式会社DeNA Games Osakaに入社。
プランナーとして社内の運用タイトル、新規タイトルを担当。
2014年の夏頃より金髪になる。
2017年11月より「天華百剣 -斬-」にディレクターとして参加。
2018年1月に株式会社ディー・エヌ・エーに転籍。
2018年4月「天華百剣 -斬-」の1周年のタイミングでプロデューサーに就任。

■受講者へのメッセージ

リリース1周年のタイミングで多くの方から応援をいただけたこと。自分自身がオタク、サブカル厨であることと前職の広告業界で制作をやっていた知見が上手く融合したこと。それらが上手く合わさった結果、1つのゲームが生き長らえることができました。

その時に得られたあれやこれやがみなさんの何かのお役に立てば幸いです。

【CEDEC2019】「サービス終了寸前だったタイトルが、CMを使わずにDAUを増やして九死に一生を得たSNSプロモーション術」セッションレポート

[/su_column][/su_row][/su_note]


大規模モバイルゲーム運用におけるマスタデータ管理事例

■セッション内容
DeNA はこれまで様々なゲームをリリース・運用してきました。その中には100名を超えるメンバーで運用しているタイトルもあれば、運用10周年を迎えるタイトルもあります。

本セッションでは、モバイルゲーム運用におけるマスタデータの管理で、特に大規模なチーム人数や、長期運用で発生してきた課題や失敗事例をご紹介します。その上で、それらの課題解決のために開発した共通マスタデータ管理システムの概要と、その機能や運用ワークフローを説明します。

そして実際のゲームの開発・運用にそのシステムを導入してみて、どのような効果があったかをお話します。(開始時間/16:30〜)

[su_note note_color=”#ffffff” radius=”2″]
[su_row][su_column size=”1/6″ center=”no” class=””]

[/su_column] [su_column size=”5/6″ center=”no” class=””]
■登壇者プロフィール

人西 聖樹
ゲーム事業部Publish統括部共通基盤部
ゲームデベロッパーライブラリグループ エンジニアリングリード

DeNAの大規模mobageタイトルの開発・運用のリードエンジニアを経て、現在はゲーム横断の開発基盤の部署にて、マスタデータ管理システムの開発リーダーを担当。

■受講者へのメッセージ

モバイルゲーム特有のマスタデータの運用周りの苦労や、それに対してどのようなアプローチをしていったかをお伝えできればいいなと思っております。

【CEDEC2019】「大規模モバイルゲーム運用におけるマスタデータ管理事例」セッションレポート

[/su_column][/su_row][/su_note]

 

[su_note note_color=”#ffffff” radius=”10″]
GeNOM(ゲノム)とは

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

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

[/su_note]

引用:「CEDEC2019」公式サイト

※掲載内容は、公開日時点の情報です。セッション内容等は当日変更になる可能性もありますので、ご了承ください。

【イベントレポ&インタビュー】GDMエンジニア向け勉強会Vol.34~今だからこそ「Unreal Engine」を学ぼう (初級編)~

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

2019年7月26日に開催された「vol.34 エンジニア向け勉強会~今だからこそ「Unreal Engine」を学ぼう (初級編)~」では、Epic Games Japan サポートエンジニア 岡田和也氏を招いて、これからUnreal Engineを触ろうと考えている初心者に向けて、Unreal Engine 4の強みや、各種機能の紹介がされました。

本記事では当日のイベントレポートに加え、GDM運営を務めるDeNA藤村と岡田氏とのちょっとした対談の様子もお届けします。

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

岡田 和也(おかだ かずや)|Epic Games Japan
関西の大手ゲーム会社にてゲームエンジン開発をした後に、2016年にEpic Games Japanにサポートエンジニアとして入社。ライセンシ向けのQ&AサイトであるUDNでの回答、 直接会社に訪問してのサポート、 そして各地での勉強会などでの講演が主なお仕事。

[/su_note]

Unreal Engine 4について

Unreal Engineは比較的歴史は古く、20年前にEpic Gamesが開発したFPSゲーム『Unreal』で実装されたMODエディターが元になっているエンジンで、現在では「Unreal Engine 4」(以下、UE4)まで進化しています。

UE4は2014年には一般公開、2015年には無料化をしており、Epic Gamesアカウントを無料登録して取得すれば、誰でもダウンロードして利用することが可能です。GitHubからエンジンコード(プラットフォーム以外)を閲覧することも可能なので、学生でもプロでも同じ環境で開発や学習をすることができます。

国内でのUE4採用プロジェクトについて、現在ではコンソールだけでなくモバイルゲームやVR・ARなどのタイトルも増加しています。

Unreal Engine 4の強み

UE4の大きな特長として「高品質なリアルタイムグラフィック」が挙げられますが、UE4が目指すこと、大事にしていることは「大規模開発に耐えられるほどに高い開発効率」です。

Epic Games Japan 岡田和也氏Epic Games Japan サポートエンジニア 岡田和也氏

昨今のゲーム開発現場では、求められるクオリティは上がる一方、開発期間や予算はなかなか上がらないのが現状になっています。その中で、採用するツールに求められているのは、同じ時間、同じ人数でよりクオリティが高いものを、早く作れることになります。

従来の開発環境では、プランナーが企画を思いついてアーティストに依頼しても、エンジニアが不在だと「試す」「実装する」ことができず、チーム全体の開発スピードや、イテレーション速度の低下を招きます。

その状況を打開するために、UE4を利用して、非エンジニアが自身のアイデアを自分で実装できる環境を提供します。プランナーやアーティストが実装している時間に、エンジニアがより複雑な作業や、根本の作業効率をアップする業務に専念することができます。

このような理念を実現するための機能や取り組みとして、従来の言語を用いた開発に比べて「箱と箱を線でつなぐ」だけでアルゴリズムやシェーダーを組める「ノードベースエディタ」や、直感的でわかりやすい形式、プログラミングなどの複雑な作業を必要としないアーティストフレンドリーなUIも実装しています。

また、製品レベルの事例を参考にしながら学習が可能な機能別サンプルも豊富で、コストをかけずにプロトタイプを早く作成し「より早く遊びを研究し、早く失敗できること」が大きな魅力となっています。エディタ・ドキュメントなどの日本語化も進んでいます。

その他の強みとしては、ソースコードの公開をしており、ブラックボックス化の回避を実現しています。プロジェクトに応じたカスタマイズや最適化が可能になり、不具合による手詰まりの可能性を削減することも可能です。

また、Github経由で一般のユーザーにもコードを公開しているので、リリース直後から世界中のユーザーを通じて一斉デバッグされ、改善案を参考にしながら、さらなる安定化、新規機能を随時追加することができます。ちなみに現時点で最新のUE4.22では、数百の追加・修正項目のうち174個がコミュニティから寄せられたものになります。

このようにEpic Gamesでは、個人開発者だけでなく、大規模プロジェクトに関わる開発者がノウハウをオープンにすることを推奨しており、大型勉強会「アンリアルフェス」やSlideshare、Youtubeなどで資料や動画を公開しています。

エンジンに標準装備されているゲーム開発に必要な機能は、外部アセットやプラグインによるコストやリスクを回避するために実装されています。自社開発の『Fortnite(フォートナイト)』をはじめとしたタイトルの運用実績、コンテンツ開発を経て必要とされる機能が組み込まれています。

さらに、1つのプロジェクトがさまざまなプラットフォームで動作するように、基本的に同じようなアセット・コードで動くような対応をしており、ここ1年ほどの『Fortnite』での運用フィードバックが大きく活用されています。

Unreal Engine 4の各機能

プログラミング

Blueprint

ノードベースだけではなく、コンポーネントの階層構造を含めたもので、各パラメータやノードによるアルゴリズムの集合体です。

Blueprintの長所は、従来のプログラミング言語よりもハードルが低く、非エンジニアでも組むことが可能なところです。線を伸ばした先で右クリックすれば、その時点で使用可能なノードだけを選択することが可能で、単純な関数の誤りなど、ヒューマンエラーを回避することが可能です。

コンパイル、イテレーションも高速化され、各パラメータをリアルタイムに編集・反映が可能です。ゲームを実装しなくても処理を走らせることができる「Construction Script」機能を使えば、メッシュの数やマテリアルを変更したり、プロシージャルなワークフローも構築できます。

Unreal C++

従来のC++をUE4向けに拡張したもので、C++11ベースのモダンな言語、Blueprintとの連携も可能、エンジンのコア部分へのアクセスもできます。

短所としては、非エンジニアにはハードルが高く、Blueprintと比較するとイテレーションの速度は落ちてしまいます。もちろんヒューマンエラーの可能性も高くなります。

両機能の戦略としては、Blueprintではイテレーションの速度を求められ、かつ非エンジニアが触る部分を、Unreal C++ではシステム寄りの複雑な部分、非エンジニアにとってブラックボックスでも構わない実装部分に使用することが推奨されます。

レンダリング

UE4のレンダリングは物理ベースレンダリング(PBR)を採用しており、DesktopではDeferred Render、Clusterd Forward Renderer for VR、MobileではMobile Forward Rendererだけでなく、iOS向けに、よりリッチなレンダリングが可能なDesktop Forward/Deferred Rendererも登場しています(開発中なので2019年7月時点ではバグ発生の可能性あり)。

UE4ではギラギラした金属のようなレンダリングが想像されると思いますが、それだけではなくフォトリアルからNPR表現まで多彩な表現が可能です。

Material Editor

Blueprintと同じく、ノードを線でつなぐだけで、簡単にシェーダーを作ることが可能です。マテリアルインスタンスを使用すれば、シェーダーをコンパイルしなくてもパラメータの変更をリアルタイムで反映できます。

TA(テクニカルアーティスト)がベースとなるマテリアルを作り、実際に絵作りをするアーティストがマテリアルインスタンスで待ち時間なしで調整していくのが、基本的な戦略になると考えられます。

Post Process

標準で数多くの機能を提供しており、Materialと同様にノードベースで組むことが可能です。NPR表現ではPost Processで加工を施すことも多いと思われます。

Realtime Ray Tracing

標準機能として実装しており、最新Ver.は4.22、ある程度のGeForceグラボがあればすぐに試用することが可能です。

アニメーション

Persona

Personaエディターでは、アニメーションの調整やアルゴリズムの組成などすべての作業を実行することが可能です。一般的なステートマシンなどリアルタイムでプレビューすることも可能です。Blueprintと同じくノードベースで作業できます。

足音やエフェクトをアニメーション側に仕込んだり、複数のアニメーションをブレンドすることも可能です。量産に向けたアニメーションの使い回し「アニメーションリターゲット」も使用可能で、対象と同じスケルトン構造をベースが持っていれば流用ができます。

LiveLink

Maya、MotionBuilderなどのDCCツールとリアルタイムに連携したり、iPhone Xのフェイシャルキャプチャー機能と通信することで、エディター上でアニメーション化することもでき、簡易モーションキャプチャーのような役割を果たすことも可能です。

UI

UMG(Unreal Motion Graphics)

インゲーム用のUIエディターであり、一般的な平面UI、3D空間に浮かぶようなUIも作成することが可能です。

UMGでは、タイムラインでアニメーションを付けるなど、さまざまな機能が揃っています。Blueprintで処理を組めるため、一度覚えてしまえば学習コストも少なくて済むのが特長です。

UIのパーツであるウィジェットを、ドラッグ&ドロップで簡単に配置することができ、エディタ拡張もUMGで可能です。Pythonを使った自動化もかなり進んでいます。

エフェクト

Cascade

UE3から導入されたシステムで、エミッタ(火・煙・火花など)と呼ばれる各パーツを組み合わせてエフェクトを作成します。マテリアルと連携することで、シンプル、複雑、トゥーン描画のようなエフェクトが自由自在に作れます。

Niagara

現在開発中の新たなエフェクトシステムで、Cascadeに比べて高速かつさまざまな表現が可能になっています。スケルタル制御のメッシュに沿ったエフェクト、カールノイズ、タイムライン制御などさまざまな機能が組み込まれています。現時点では、本システムの正式リリース時期は未定です。

カットシーン

Sequencer

シネマティックカットシーンツールで、SequencerからBlueprintで作ったアルゴリズムを呼び出せるので、ゲーム中のギミックの制御などにも活用できます。現在発売、公開されている製品にも多数使用されています。

その他

Landscape

地形の作成機能です。粘土をこねるように山や谷を作成することができ、マテリアルを併用すれば高い部分に雪を積もらせ、低い部分は海に加工することもできます。

また木や草、石などをオブジェクトを自動で配置する機能は、ただ置くだけでなくカリングなどもされるので、処理負荷軽減にも役立つ仕様になっています。

Behavior Tree

イベント駆動型のAIシステムを作成するシステムです。Blueprintとは少し違うUIですが、ノードベースでアルゴリズムを組むことができます。「敵が近くにいれば右の処理、いなければ左の処理」というような分岐を経て、最終的な処理を決定する仕組みです。実際にゲームを動かしながらデバッグをすることも可能です。

Chaos

NVIDIA製「PhysX」から自社製の物理エンジンに置き換え中の、新たなシステムです。PhysXは外部のライブラリであり、不具合時の最適化が不可能だったため、ライセンシーから指摘をもらっていたことが主な置き換えの理由となります。UE4.23にて非破壊メッシュ機能がリリースしています。

プロファイリング機能

レンダリングする上でさまざまなバッファを作りますが、それを可視化したり、実機上でプロファイリングのデータを表示することも可能です。UE4.23ではUnreal Insightという機能が実装されています。

特にゲーム開発において、プロファイリングは重要視してほしい分野です。なるべく完成度の高いゲームを世に出すため、日頃からプロファイリングの作業を心がけてもらいたいと考えています。

オススメの学習方法

UEはプランナーやアーティストだけでモノづくりができるように、ほぼすべての機能がコード不要で使用でき、グラフィカルでわかりやすいUIを使用、日本語にも対応しています。

また、学習用に公式ドキュメントやサンプルも用意されており、用語の説明だけでなくプロ向けのコアな解説も記載しています。Epic Games製のサンプルも多数収録、アセットは商用利用可能で、機能別のサンプルには、UE4を学ぶ上で非常に役立つものが数多く収録されています。

Marketplaceでは、無料アセットやコミュニティが販売している高品質なアセットが多数登場しています。販売アセットは商用利用・改変可能でライセンス明記不要、再配布はNGです。別ゲームエンジン・ツールでも利用可能です。

公式動画チュートリアルサイトでは、エディターの基本操作やリッチなレンダリングについてなど、段階を分けてチュートリアルが収録されています。日本語字幕もあります。

参考書については、「Unreal Engine 4で極めるゲーム開発:サンプルデータと動画で学ぶUE4ゲーム制作プロジェクト」「作れる!学べる!Unreal Engine 4 ゲーム開発入門 第2版」「Unreal Engine 4 マテリアルデザイン入門[第2版] 」の3冊をオススメします。非公式の動画チュートリアルサイト「Udemy」では、初心者向けの動画も販売されています。

学習する上で一番大事なのは「はじめからすべての機能を理解しようとしない」ことです。UE4はハードルが低いとはいえ、初心者向けだけでなくプロ向けのツールでもあるので、ドキュメントを参照した後に、標準のテンプレートをベースに小規模なコンテンツを作ってみましょう。オススメはTPSテンプレートです。

困ったときは、公式Q&Aサイト「UE4 Answerhub」を活用してください。ここではコミュニティ同士が質問や回答している場所なので、初心者がつまづく内容については、ここで検索すると簡単に解決することが多いです。

さらに、より高度なことを学びたくなったら、SlideshareYoutube公式チャンネルで公開されている国内の勉強会における講演資料やアーカイブ動画などを参考にしてください。

また、エンジンコードを見ながら、実際に手を動かして、触ってみることが成長の秘訣です。

また、最後にお金に関わる説明ですが、ゲームの場合(一般ユーザー)、4半期(3ヶ月)毎の総売上が3,000ドルを超えた場合、その超えた分に関して5%のロイヤリティが発生します。

Epic Gamesからの有償のサポートを受ける場合はカスタムライセンスを結ぶ必要があります。なお、映像・建築などのノンゲームの場合は、ロイヤリティはありません。

GDM運営の藤村と対談

イベント直前に、今回登壇いただいたEpic Games Japan 岡田和也氏と、GDM運営を仕切るDeNA 藤村幹雄にいろいろと聞いてみました。

――今回のGDM登壇のきっかけ、経緯を教えてください。

藤村:きっかけは、20年くらいお付き合いのある、Epic Gamesの杉山明さんに相談したことです。杉山さんは、ゲーム業界や映画などエンタメの分野において「Softimage3D」を日本で広めた有名な方なんですよ。

岡田氏:それで杉山さんから直接オファーをもらったんです。もともと自分はセミナーなどに登壇する機会も多く、すぐに了承させていただきました。現在、杉山さんは映像や建築などのノンゲーム周りの業務を担当しており、ゲーム関連は自分が登壇することが多いです。

――岡田さんの普段のお仕事内容を教えてください。

岡田氏:サポートエンジニアとして、ライセンスを結んでいる方のみログインできるクローズドなQ&Aサイト「UDN(Unreal Developers Network)」で質問をいただいて回答する、会社などに直接お伺いしてパフォーマンスの計測や不具合の調査する、そして講演に登壇する、という3つの業務が主な担当になります。

――今回の勉強会の内容を初心者向けにしたのはなぜですか?

岡田氏:関東圏で実施しているEpic Games主催の勉強会は、初心者向けの内容はあまり求められておらず、すでに仕事でバリバリ使っている人向けの内容が多くなっています。今後、未経験者や初心者に向けてどのような展開にするか悩んでいたときに、今回のお誘いを受けたので、さっそくこのお題に決めました。

藤村:DeNA社内のゲーム開発現場にとっても、このようなUE初心者向けの勉強会をきっかけに新しいチャレンジや、今後の開発タイトルへのエンジン採用についても役立つとと考えました。

昨今のモバイルゲーム開発では、UEの採用も選択肢の一つとなりつつあるので、「これからUEを勉強したい」と感じている社内のゲームクリエイターが、一歩踏み出して興味を持って実際に触れるような機会になればと思っています。

GDMを立ち上げた時期は、ゲーム業界の中にプランナーの勉強会が少なく、若手向けの勉強会もあまり実施されていなかったため、あえてプランナー向けのお題を中心に実施してきました。

約1年ほど開催を続けたときに、さらにいろいろな職種を扱いたいと考え、デザイナーやエンジニア向け勉強会を実施しました。最近では内容の幅も広がってきたので、今回のような初級、中級とレベル別のお題にすることにしたんです。

――初心者向けの勉強会用の資料を作る上での工夫はありますか?

岡田氏:自分自身、前職のゲーム会社でもUEを使用していたので、当時を思い出しながら実際につまづいたところや、まとまっていたら便利かもしれないトピックスを、まずは広く紹介しようと考えて作りました。

――今後、GDMでUE中級、上級編なども実施の予定はありますか?

藤村:もし、やっていただけるのであれば!

岡田氏:ぜひ、お声がけいただければ!

――ちなみに『Fortnite』マルチプラットフォーム化の際のノウハウはかなり蓄積していますか?

岡田氏:ええ、そのノウハウがUE側に続々とフィードバックされています。モバイル最適化のシステムや、チェックの自動テストなど、より効率を上げるような機能の導入も始まっています。やはり自社開発しているゲームタイトルがあることは、大きなメリットになっていますね。

――最近ではモバイルゲームにUEが導入されることが多くなってきていますが、業界でも技術的な広がりを感じていますか?

岡田氏:先ほど話したようなQ&Aサイトでの他社・他人同士の助け合いも盛んですし、最近では質問の質が高くなってきたのを感じます。ガッツリ業務で使用した上で「技術をもっと深堀りしたい!」と思うモバイルゲームのクリエイターが増えてきたのかもしれませんね。

――使う側もかなり慣れてきたようですね。

岡田氏:確かにそう感じています。自分たちも「その問題は認識していないので、これからすぐ調べます!」と、焦ることも多くなりました

――今後UEはどのように進化していくと考えていますか?

岡田氏:ここ1年ほどで思うのは、ゲームだけじゃなく映像やバーチャルカメラ、モーションキャプチャーとエンジンの連携が強くなってきて、何でも実現できるツールに進化したと実感しています。

弊社のティム・スウィーニーも「Epic Gamesは今後もゲーム会社としてゲームを生み出していく」と強く話していますし、ゲーム開発を大きな軸にしながらも、他分野のテクノロジーの進歩にも深く関わっていきたいと考えています。

また、『Fortnite』のトレンドの勢いがすごくて、ゲームプレイだけじゃないコミュニティツールとして楽しまれている部分も含め、来年はもっとおもしろいことが起きる気がしています。

――さらなる進化が楽しみですね! 本日はありがとうございました。

アンケートに寄せられたコメントを紹介

今回のGDMに参加した方から頂いたコメントを一部抜粋して紹介します。内容はすべて運営チームが目を通しており、今後の運用に活用していきます。

[su_quote]岡田さんの説明がわかりやすく、面白かったです。(ディレクター)[/su_quote]

[su_quote]Unreal Engineおよびwiseを使用したサウンド実装の初心者向け講習会や、ワークショップ的なものがあれば是非参加したいです。(サウンド開発)[/su_quote]

[su_quote]関西でもたまにやっていただけると、大変ありがたいです。(プログラマー)[/su_quote]

[su_quote]岡田さんの講演はよく聞きに行くのですが、このような初心者向けのものはレアで良かったです。缶バッジも嬉しかったです!(経営者)[/su_quote]

岡田氏のご厚意により、来場者全員に配られたUEのステッカーと缶バッジ

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

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

GeNOM(ゲノム)とは

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

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

[/su_note]

【イベントレポ:第2回DeNA×CA勉強会】両社のエンジニアが推進する技術的アプローチとは?

2019年3月27日、DeNA本社にて、DeNAとサイバーエージェントの二社合同でゲーム開発・運用技術に関する、若手向けのクローズドな勉強会&交流会が開催されました。

第二回目となる本勉強会のコンセプトは「若手のエンジニアが発表しやすい雰囲気の勉強会」となっており、DeNAとサイバーエージェント関連会社のエンジニアが2名ずつ、それぞれ約15分ほどのプレゼンテーションを実施しました。本記事ではその発表内容の一部をレポートします。

▼前回の勉強会の模様はこちら!

【イベントレポ】DeNA×サイバーエージェントのエンジニア合同勉強会に潜入!

DeNAマスタデータ管理システムOyakataの全容

DeNA開発基盤部の人西 聖樹から、マスタデータの編集・管理システム「Oyakata」の機能を中心に紹介するプレゼンが実施されました。

DeNA人西 聖樹DeNA 人西 聖樹

マスタデータについて

マスタデータとは、ゲームプランナーが主に編集する、ゲームのパラメータを設定するデータのことで、本勉強会ではレベルデザインに関するものはマスタデータと呼ばないことにすると、冒頭で人西は話しました。

DeNAの今のマスタデータ運用

DeNAの運用中タイトルについて、ゲームはUnity製、マスタデータの管理はGoogle Spread Sheet、Jenkins上でSpread Sheet->ゲームデータ(JSON)に変換、バージョン管理はgitおよびGithubをそれぞれ利用しており、主な制作フローも公開されました。そして、現状のフローでの課題点として、以下の3点が挙げられました。

課題1:並行での開発に対応できていない

現在のフローでは、複数のイベントを並行開発する際に、イベント間での編集の影響範囲が切り分けられず、前段でシート編集中の場合、後続の作業も影響を受けてエラーになっていまいます。

同じく、前段のイベント作業でエラーが出るような値を入力していると、後続も影響を受けてエラーになってしまいます。

課題2:実機確認までに時間がかかる

並行での開発に対応できないと、以下のような弊害が発生します。

・マスタデータのゲームデータへの変換がjenkins頼みになる
・jenkinsのビルドを長時間待たないと、入力したマスタをゲーム実機で確認できない

課題3:差分が見にくい

マスタデータの変更レビュー時や、変換後のデータをgithub上で差分の確認の際、JSONやCSVでのテキスト差分を肉眼で確認するのはとても見づらく、誤った編集の見落としの原因にもなっています。

Oyakataのおもな機能

上記で説明したような課題の解決のために、DeNAでは「Oyakata」というマスタデータの編集・管理システムを開発しています。構成するコンポーネントの機能の詳細は以下の通りです。

ビューワー(viewer)

Webアプリケーションでマスタデータを一覧で表示できる機能を持ち、テーブルを複数に分割して表示、分割したテーブルをまとめて表示。オーソドックスな検索機能で絞り込みも可能です。

編集履歴表示機能では、git likeなコミット単位でのバージョン管理が可能で、編集差分、リリースブランチの差分や、ブランチ間の編集の影響範囲の切り分けなどの表示が可能です。

エディター(editor)

マスタデータを編集する機能で、マスタデータのスキーマの作成・変更・削除ができます。マスタデータはWebおよびExcel上で作成・変更・削除ができ、編集したデータはゲーム上のデータに変換することが可能です。

編集したマスタデータをレビューする機能(いわゆるGithubのPull Request)では、見やすく、人間の目に優しい差分表示ができます。

コンバーター(converter)

マスタデータをゲーム用のデータに変換する機能で、CLIツールとして提供。今後JSONやFlatBuffers Protocol Buffersなど一通りのデータやフォーマットに対応する予定です。

この機能はプランナーのローカルPC上で実行できるので、実機確認をjenkinsを介さないで実施することが可能です。

バリデーター(validator)

マスタデータが正しいのかをチェックする機能で、CLIツールとして提供します。外部テーブルが存在するかを確認する「リレーションチェック」や、タイトル固有の数値を確認する「バリデーションチェック」などが可能です。

Excel上での入力規則チェック、およびチェックスクリプトでの2種類のチェックが可能。タイトル固有でのカスタマイズも可能です。

Oyakataはこれまでの仕組みと何が違う?

大きな違いは「ブランチ管理」をサポートしていることです。他の人の作業の影響を受けなくなり、エンジニアがgitで当たり前のように受けている恩恵を、プランナーも享受することができます。

また、ゲームデータへの変換が個々のローカルPCで可能なため、jenkinsの処理を待たずに実機確認がすばやくできます。さらに、マスタデータ形式に特化した差分表示で、見やすい表示が可能になりました。

まとめと課題

DeNAではこれまでGoogle Spread Sheet、Jenkinsでマスタデータ管理の仕組みを構築し続けたため、並行開発の切り分けやjenkinsに依存した管理と順番待ちの時間が発生していました。さらに人間の目を悩ますcsvやJSONの目視確認もつらかったとのことです。

そのような課題をすべて解決する、マスタデータ管理の共通基盤としてOyakataを開発しています。

質疑応答

Q:Oyakataは開発完了後、社内ツールとしてクローズドで使うのでしょうか?

A:まずは、社内と協力している外部の開発会社さんに導入することを目指しています。Oyakataはあまり他にはないマスタデータ管理システムなので、他社で使えるようなOSSや技術サポートのように、将来的に他のモバイルゲーム開発会社で当たり前に使用できるようなツールになればいいと考えています。

『逆転オセロニア』対戦型AIのバックエンドの実装

続いては、DeNAエンジニア宮下 奨平より、『逆転オセロニア』において対戦型AIのバックエンドの実装についてプレゼンを行いました。

DeNA宮下 奨平DeNA 宮下 奨平

『逆転オセロニア』とAIプロジェクト

『逆転オセロニア』は通常の「オセロ」と同じく、黒と白の駒ではさんでひっくりかえすルールで対戦していきます。プレイヤーは、それぞれHPや攻撃力、さまざまなスキルが設定されたキャラクター駒をデッキを組みます。相手のHPをゼロにすれば勝利となるため盤面を有利に取っていくだけではない、戦略的な立ち回りが必要です。

一般的なボードゲーム「オセロ」については、すでに人間の頭脳を上回るAIが開発されていますが、『逆転オセロニア』ではオセロよりも複雑なルールであり、手駒の置き方などで状況は変わっていくため、一般的なゲームAIの構築手法では強いCPUの実装が困難になっていました。そこで深層学習を利用して『逆転オセロニア』のAIを構築することになりました。

このAIプロジェクトのスケジュールとして、2017年4月から深層学習を用いたAIの研究開発を行い、その後、2018年4月頃からAIが本当に十分な強さを持っているかの検証、さらに2018年9月にAIをゲーム内で利用するための実装を開始し、2019年3月に代表的なデッキタイプのAIと戦える「オセロニア道場」がリリースされました。

『逆転オセロニア』深層学習AI

ゲーム内のPvPにおける大量の棋譜の中から、ランクが高いプレイヤーの棋譜を抽出し、学習用データとして利用します。このデータでAIは特徴量から「強いプレイヤーが打ちそうな手」を推測できるようになり、人間レベルのAIを作ることが可能になりました。前処理はPythonで実装しています。

※棋譜とは:ボードゲームなどで、お互いの対局者の手を順番に記録したデータのこと

盤面、手駒の状況やお互いのデッキなどの情報など、ゲームのすべての情報はJSONファイルで管理し、棋譜には同じ状況を再現できるすべての情報を持っています。

ただし、AIは棋譜(JSON)をそのまま理解することはできないため、テンソル(数字だけの多次元配列)に変換する必要があります。その工程を特徴量の抽出と呼びます。

学習の全体像として、プレイヤー同士の対戦で集まる棋譜を特徴量抽出器(Python)で特徴量に変換、それをAIが読み取って学習していきます。

つまり、とある盤面を再現できる十分な情報を持った棋譜をAIを通して、すべての打ち手に対する盤面を考慮した打ちての良さを「評価値」として算出できるということです。

『逆転オセロニア』AIサーバー

ゲームと深層学習AIをつなげる方法について、サーバー側の実装で、クライアントから都度、推論対象の棋譜をリクエストとして送ってもらう形を採用しました。

プラットフォームは「Google Cloud Platform」を使用、AIモデルをデプロイするシステムを持っている、AI研究の段階でも使用していたことが採用の大きな理由となります。

AIのデプロイについて、Google Cloud Machine Learning Engineに学習済みAIモデルをデプロイすると、APIを通じて推論が可能になり、かつ、負荷に応じてクラスタをオートスケールしてくれるため、構築しやすいのが利点です。

AI APIサーバを実装した要件は「クライアントから棋譜を受け取り、評価値を返す」こと、RPS(秒間リクエスト)1000に耐えること(過去のPvEイベントからあり得る最大のRPSを見積もり)です。この部分はかなり苦労したとのことです。

原因を究明したところ、盤面の特徴量がかなり大量のデータであり抽出にCPUリソースを使ってしまうこと、Google Cloud Machine Learning Engineのレスポンスを平均3秒ほど待つ必要が出ることがわかりました。

Google App Engine(GAE)は、ソースコードをデプロイするだけでさまざまな恩恵を受けることができますが、その中で並列リクエスト数の上限に引っかかってしまったことが原因となったようです。

解決策として、Google Cloud Machine Learning Engine APIや特徴量抽出を待つためのサーバーと特徴量を抽出するためにサーバーを区別します。

特徴量抽出サーバーは、学習時に作ったPythonのプログラムをサーバー化、Google Cloud Machine Learning Engineとは関わらず特徴量の抽出だけをするサーバーとしてGAEをデプロイしています。

またフロントエンドでAPIサーバー(Go)として、Google Kubernetes Engineにデプロイし、処理を待つためだけのクライアントと直接繋がるAPIサーバーを作成しました。

この結果完成したGoogle Cloud Platformの大まかな構成は、クライアントからまずLoad BalencerからGoogle Kubernetes Engineの内部APIサーバーを通り、棋譜を受け取り、それを特徴量抽出サーバーで抽出。そのデータをGoogle Cloud Machine Learning Engineに投げて評価値を算出する、となっています。

この構成なら秒間リクエスト1000に耐えることができるようになりました。

まとめ

Google Cloud Platformは、Google App Engine(GAE)やGoogle Kubernetes Engine(GKE)など多彩なサービスが用意されているため、AIコンテンツを実装しやすいが、実装してみると思わぬ落とし穴があるので、それに負けない強い心が必要だと感じたと、宮下は締めくくりました。

質疑応答

Q:APIサーバーにGoを選定した理由は?

A:Pythonでは、シングルセットで動く場合に並列を待ち受けるワーカーの仕組みでは、あらかじめ固定数で指定する必要があり、それを超えて並列で待つとレスポンスが結構遅くなります。

それに比べてGoなら、リクエストの数に応じてそのたびにGoルーチンを発行して待つことが得意だったため、Goを選びました。

横軸技術組織の成果と学び

最後のプレゼンは、QualiArtsおよびSGE Unity代表責任者の住田 直樹氏より、「横軸技術組織の成果と学び」について発表されました。

QualiArts Unityクライアントエンジニア 住田 直樹QualiArts Unityクライアントエンジニア 住田 直樹氏

SGEとは

Smartphone Game&Entertainment(SGE)は、サイバーエージェントのゲーム事業をメインとした13社が集まった子会社群のことです。また、SGE Unityとは、SGE全体でUnityの技術共有や活性化を図るコミュニティ組織になります。メンバーは、新卒者やボードメンバーなどさまざまな役職の人間で構成されています。

主な活動内容は、勉強会の運営・技術施策の運用などで、週1回のMTGで相談をしています。目的としては、SGE全体においてUnityの技術力の向上、プロジェクトのスピードやクオリティの向上を目指し、会社間の技術的な隔たりをなくして助け合えるように、それぞれが持っているノウハウや失敗例やライブラリの共有をしています。

活動内容

各種勉強会の企画と運営について、さまざまな軸で勉強会を運用しています。特にCygamesやUnityなど外部との合同勉強会に注力し、特別講演などでクリエイターとの繋がりを作っています。

そのほか、外部カンファレンス参加による知見の獲得と共有をする「Unite報告会」、Zenjectなど独自ツールのハンズオンをプロジェクトのエンジニアを呼んで講演する「勉強会」や、Cygames・Unity・SGEの3社合同の勉強会などを実施しました。

最近では勉強会などの参加人数も増えていて、講演の模様は録画と社内動画ストリーミングで配信しており、参加できない人も後日チェックすることが可能です。

また、イベント開催による技術発信の促進のため、それぞれのプロジェクト事例を文章化して蓄積・共有する社内Qiita Teamが存在し、各職種のエンジニアやクリエイターが自由に投稿ができます。

技術書の作成では、有志を募ってUnityの開発に役立つTips集「UniTips」を作成、個人開発や業務で得た知見をまとめて文書化しています。シリーズを通して住田氏も執筆に参加しているとのこと。

技術書典では、学生やフリーランスなどさまざまなエンジニア、クリエイターが多数来場しているようです。

組織としての成果

大きな成果は「ナレッジの蓄積」で、約1年で1,000件を超える数を持つSGE Qiitaの記事では、個々のプロジェクトを踏まえた特有のケースなども多数収録されています。

SGE内の動画配信媒体「SGETube」を活用し、参加できなかった人も後日に閲覧が可能になっています。

また、会社間のノウハウ共有による開発の効率化も実現でき、それぞれの分野の知見を活かし各社の不足している部分を補填でき、技術組織の底上げができています。

さらに、Unityに関する勉強会や懇親会などの施策実施について、相談窓口の存在となっており、外部との交流を深め、インプットとアウトプットを通しての組織力の向上が図れました。

個人としての学び

住田氏が自身の学びとして強く感じたことは、技術者としての視野の拡張だと話し、多くのエンジニアやプロジェクトと交流したことで、ノウハウを学びながら、どのような技術施策が組織開発の活性化に繋がるか、技術的にどのような挑戦をしていくかを経験ができたことと、嬉しそうに話しました。

また、何よりも技術組織の責任者を経験したことも良いプレッシャーとなり、さらに良い技術者になるためのエネルギー源にもなったと語っています。

まとめ

技術組織を活性化させることによる、幅広い知見の共有と獲得
さまざまな得意分野・技術・開発体型を持つ子会社群のノウハウの有効活用。動画や文書などによる知的財産の蓄積

横軸規模の技術組織を運営することによる技術者としての成長
多くのエンジニアとの交流や技術施策の運営を通した知見の獲得、業界的な技術挑戦に対するアプローチの検討

技術者としての目線上げ
組織的にどう貢献するか、技術者としてどう成長していくか?

質疑応答

Q:SGE Unityの活動について、ゲームタイトル開発側の評価はいかがでしょうか?

A:詳細なヒアリングをしていないのですが、個人的に活動についてのポジティブな反応をさまざまな職種の人から聞いています。

エンジニア同士で盛り上がる懇親会

各社エンジニアのプレゼンテーション後は、懇親会が開催され、会社の垣根を超えて積極的に親睦を深めていました。このような勉強会は今後も定期的に開催していくとのことです。

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

※本記事は2019年3月時点の情報です。

オセロ・Othelloは登録商標です。TM&© Othello,Co. and MegaHouse
© 2016 DeNA Co.,Ltd.

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

GeNOM(ゲノム)とは

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

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

[/su_note]

【イベントレポ】「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]

【データサイエンスの競技者”Kaggler”が活躍する職場】社内での立ち回りやエンジニアやアナリストとの関わり方、今後のビジョンが語られた

2019年2月6日、渋谷ヒカリエにて技術者向けの大規模イベント「DeNA Technology Conference 2019」が開催されました。

本記事では、DeNAゲームサービス事業部の分析部に所属する山川要一も参加した、「パネルディスカッション:データサイエンスの競技者、Kagglerたちが活躍する職場とは」と題したセッションをレポートします。

※記事の最後にはセッション時に投影した資料を掲載していますので、そちらもご覧ください。

Kaggle、そしてDeNAのKagglerとは?

「データサイエンスの競技者、Kagglerたちが活躍する職場とは」と題した本パネルディスカッション。

登壇者は、データサイエンスグループのマネージャーとしてKaggler達を率いる原田慧、データサイエンス競技「Kaggle」のトッププレイヤーで構成されるAIシステム部のデータサイエンスグループでKagglerとして活躍する加納龍一と小野寺和樹。

さらに、システム本部AIシステム部のMLエンジニアとして鈴木翔太、ゲームエンターテインメント事業本部に属する分析部のメンバーとして山川要一が別の立場から、一緒に働くKagglerについて紹介するため本セッションに参加した。

左から原田、鈴木、加納、小野寺、山川
今回、ホワイトボードでパネルディスカッションの模様がリアルタイムで描かれていた

本題に入る前に、モデレーターを務める原田がKaggleの概要を紹介。Kaggleは機械学習モデルを構築するコンペティションのプラットフォームで、スポンサーが出したデータと問題に世界中のKagglerたちが挑み、提出した予測結果の良し悪しで順位付けされる。上位者には賞金が出たり、Kaggle上でメダルが付与され、メダルが貯まるとKaggleでのランクが上がり、MasterやGrandmasterといった称号が与えられるとのこと。

原田によれば、Grandmasterは世界でおよそ100名しかおらず、国内でも5人程度だという。また、Masterについては国内に約40名おり、その内の10名がアルバイトも含めるとDeNAに所属。原田自身もKaggleMasterだそうだ。

DeNAでも2018年4月からAI技術開発の横断部門であるAIシステム部のデータサイエンスグループにおいて、Kaggle社内ランク制度(データサイエンスチームのメンバーに対して、業務時間を使ったKaggleへの参加を認める)を導入していることにも触れ、同社のKaggleである小野寺と加納を含むチームが、昨年8月に行われた過去最大規模のKaggleコンペで第2位に入る実績を残した。

Kagglerの一人である加納は、次世代タクシー配車アプリ「MOV」の中の機械学習の応用をメイン業務としてアサインされながら、「残った業務時間をKaggleに費やしています」(加納)と、社内Kaggle制度の実例を紹介した。

DeNAのKagglerである加納(左)と小野寺(右)

また原田は「MOVやオートモーティブなどの大きな案件に関わることもあれば、Kagglerが中心となって案件を達成することもある」とし、先日発表されたDeNAと関西電力による石炭火力発電所のスケジューリングを効率化するというプロジェクトでも、中心となったKagglerが3名いることを明かした。

実際、Kaggle上でこれら案件のような問題が出ることはないそうだが、Kaggleの中で日々勉強をしているため、その応用として変わった仕事であっても対応は可能だという。

このようにKagglerにより回っていくプロジェクトもあれば、「DeNAはAIを使って色々な事業を立ち上げていこうという会社」と原田。全社的にAI技術を使ってサービスを良くしていくことが根幹にあるとし、その中でKagglerに期待される役割について説明した。

Kagglerは、システム本部AIシステム部内の、AI研究開発エンジニア、MLエンジニア、データサイエンティストという3タイプのメンバーの中の、データサイエンティストに分類される。データサイエンティストは、Kaggleで様々な事をやっているので引き出しが豊富で、色々な経験も持っておりスピードが速い。

これはサービスや事業、使う技術に強いこだわりがあるわけではなく、データがあって課題があれば何でもやろうというスタンスとのこと。

データサイエンティスト協会の”データサイエンティストに求められるスキルセット”の図を例に、Kagglerはデータサイエンス領域の中のさらに特殊なところに属すると原田

Kagglerはどのように仕事をしているのか?

ここから本題のパネルディスカッションがスタート。DeNAには様々な職種のメンバーが仕事をしているが、実際どのようにKagglerと仕事をしているのか?

「基本的にはアナリストと事業部とKagglerは三者三様の形で働いています」とは山川。アナリストの立場としては、Kagglerはデータサイエンスに特化しており、一方で事業部は常にビジネス課題で頭を悩ませている。

どうすればビジネス課題を、データサイエンスの問題に落とし込めるかというところでアナリストが間に入ってデスカッションして、問題設定をしているという。

事業部とアナリストで”こういう課題を解いていきたい”という戦略を固めつつ、「どうやって解いていくかをアナリストがKagglerでディスカッションし、モデルを作って製品として出すこともあれば運用に必要な基盤みたいなものを作ってもらうことがある」(山川)そうだ。

その意見を聞いて、「すごく難しいことがある」と原田。事業が抱える課題をどんなデータサイエンスの問題に落とし込むかは簡単ではないという。データサイエンスの問題の形、それこそKaggleで出題されるような問題の形で事業部が用意することはあまり期待できないという。

その問題に対して山川は「そもそも何がしたいのか、常に自分が事業責任者だという気持ちで実際の事業責任者やプロデューサーとディスカッションをして問題を作る」などの工夫をしているそうで「最初にこういう問題を解きたい、これくらいの精度の向上、利益率の向上を目指しているといった指標を事前にすり合わせて進めるようにしている」とした。

逆にKagglerから見て、実際に事業部の抱える問題がKaggleの問題と同じようにおもしろいかという問いに「Kaggleの問題の方がおもしろい」と小野寺。

補足する形で原田も「もちろん例えばKaggleって3ヵ月間でがんばって結果を出すということがあるんですが、Kaggleの上位層が競っているのは0.000いくつの世界の話で、そこまで事業部の方が興味があるのかというとそうではなく、大抵の場合当たり前のこと」と説明。

「もちろん我々としては大きな予算が動いている中で、ちょっとでも効率化して売上に貢献できるような仕事もやりたいですが、小さい分析となるとどうしても事業にあったものをKagglerがパッと作る形で力を発揮することがあります」(原田)と続けた。

また、最近ではKaggleのクローンを作成し、Kaggleの問題を解いているかのように仕事ができる地盤を整えているという。

山川も「アナリストもKagglerと同じレベル、とまではいかないまでも、自分でもある程度実装してこれくらいのベースラインのモデルになるだろうとか、どれくらいの精度だったら見込めるだろうという肌感を知っておきたい」とし、事業部で設定した問題を触れる環境として、自身でベンチマークモデルを作って検証するなどしているそうだ。

一方、鈴木はエンジニアとしてどのようにKagglerと仕事しているのか。現状は、「Kaggler数名と一緒にオートモーティブ系のプロジェクトに入り、彼らの実験や学習をする環境作りや必要なデータの収集、Kagglerが作ったモデルを本番にどう組み込んで配信するか」(鈴木)など、モデル作り以外の様々なところのエンジニアリングを幅広くやっているという。

また、Kagglerと仕事する上で苦労することはないのかとの原田に問いに鈴木は、「エンジニアスキルが人によってまちまちなところがあり、エンジニアなら普段から使っているであろうものでも教えてあげたりサポートする必要がある」と語った。

逆に、Kaggler陣は、アナリストやエンジニアとどう接しているのか?

「普段はアナリストやMLエンジニアと仕事する」と加納。半年前にDeNAに転職してきたという自身の経歴に触れ、「それまではずっと研究していましたが、会社に入って周りの方々が色々教えてくれます。それがなければやっていけなかったと思います。MLエンジニアリングやアナリティクスなど、その強い専門性を持った方々が周りにいるので、自分たちも吸収できるし、Kagglerとして今までない環境、良い職場だなと感じています」と話した。

また、「結構1人で完結する仕事が多い」という小野寺のような働き方もあるようで、「1人でということであればそういうパターンもあります。加納さんが色々な方と仕事できると言っていましたが、これはDeNAの仕事の仕方の1つの魅力」と原田。

1人で何でもできることもすばらしいが、これなら世界の誰にも負けないという気概を持ったメンバーが集まっているのがデータサイエンスグループであり、「DeNAが全社的にサービス実現に向け全員で一丸となって取り組むという考え方の元、色々なメンバーが色々な苦労をしながら成り立っている」(原田)とした。

Kagglerの存在によってDeNAはどう変わったのか?

DeNAでKaggler枠が正式に組織されたのは2018年2月。そこからこの1年で多くのKagglerがやってきたが、これによってDeNAとしてどのような変化が生まれたのか?

「今まではデータはあってもどうやって使えばいいかとか、こういうことできたらもっと意思決定に役立つのに、というビジネス側で議論することがありました。それがKagglerの技術的なサポートを受けることで、より高度な問題解決ができるようになり、より効率的に運営に負担をかけない運用方法や、ここは気を付けようという発見がノウハウとして貯まってきた」と、山川はできることが広がったという印象のようだ。

それを聞いた原田から、「Kagglerはモデルの精度を高めるのが本職。簡単なモデルを作るだけなら山川さんでもできると思います。その状況の中で、最低限の分析をする上で間に合っていた中で、Kagglerがやってきたことでの価値」という質問が。

山川は「プレイヤーにどれくらい継続的にプレイしてもらえるのかを予測するのは、ゲームを運用する上でとても大事なこと。小野寺さんに作っていただいた予測モデルで、この精度がかなりあがりました。それが会社としても、意思決定する上で定量的にわかるようになったのは大きな意味があります」とし、そういう部分でKagglerのバリューがとくに大きかったとコメントした。

一方の鈴木は、一度辞めて1年前に再びDeNAに戻ってきたという経歴を持つ。その立場から「昔はデータサイエンスに尖った人材って、社内では少なかったイメージでした。でも戻ってきたらたくさんいた」との印象を述べた。

また、「山川さんと意見が近いですが」と前置きし、「できる仕事の範囲、幅が広がりました。関西電力との案件も、以前はDeNAがやれるとは個人的に思っていなかったので、そういったところでデータサイエンスがアプローチして、色々できるようになったところがおもしろい」(鈴木)と語った。

それに対し、原田は「僕らからすると、おもしろそうな案件があるからやってやろうと思っているだけなので、楽しく過ごしている」とKaggler側の意見を述べた。

では、Kagglerは転職してきたDeNAに対してどういう印象を持っているのか?

昨年6月に転職した加納は、「原田さんは数学、小野寺さんは経済学、僕は天文学と、みんなバックグラウンドが違ってすごく個性的でユニークだと思う」とのこと。また「Kaggleって画像系や言語処理だったり色々やるけど、1人1人得意な手法が全然違って、幅広い能力を持ったメンバーたちが集まっている。みんなが持っている強みを少しずつ幅広く吸収できる」ところがデータサイエンスグループ、そしてDeNAのおもしろさであり魅力と語った。

「私はチームのマネジメントをしていますが、多様なメンバーがいるから大変そうに見えてある意味楽なんです」とは原田。つまり「みんなKagle好きという価値観の元、考え方が全く違うということがない。もちろんどんなスキルがあって、どんな事業が好きという細かい部分の違いはあるけど、我々がチームとしてどうありたいかということに関しては、みんなの意見がブレることはあまりなく、一体感がある」とのこと。

そして小野寺はDeNAについて、「色々な会社を転職してきたが、DeNAは働き方が良い意味で自由」という印象を持っているという。

これについて原田は「裁量労働制がほとんどの社員に適用されていて、10時半には出社しようというルールはあります」と補足。ただし、メンバーの働き方に関しては小野寺に言うようにかなりの自由度を与えているとし、「管理しても仕方がないし、管理コストの問題もあります。各メンバーの専門性だったりプロ意識への信頼」(原田)がDeNAの自由な職場環境に表れていると説明した。

また、Kagglerを束ねる原田は、自身が昨年2月にDeNAに転職した動機について大きく2点あると切り出した。1つは「Kaggler枠という制度におもしろさを感じ、DeNAのKaggleに対する本気度を感じた」(原田)こと。

もう1つは、それまでゲーム会社だと思っていたDeNAが「いざ話を詳しく聞いてみると、色々な事業をやっている。色々な事業をやるという部分が、色々な会社の色々な問題を解決していくKaggleに近いものがあった」(原田)と、同社の多様さに魅力を感じたことが転職の決め手だったと話した。

今後Kagglerはどうなっていくべきか?

DeNAにKaggler達が集い始めてから、ちょうど1年が経ったが、今後Kaggler達はどうなっていくべきか? これが本パネルディスカッションの最後のテーマとなった。

まずKaggler側の意見として、「自分たちは仕事の時間を割いてKaggleをやっていますが、遊びではないという前提の元で、今後もKaggleにチャレンジし続けるということをまず1つ突き詰めていきたい」と加納。Kaggleの勉強をしながらその上で得られるスキルなどを蓄え、自分自身の幅を広げて間接的に会社に貢献することで実績を出していきたいとした。

過去3度、Kaggleのコンペで世界2位に輝いた小野寺は、「Kaggleのコンペで一回くらいは優勝したい。今まで準優勝しかないので世界一になりたい」とその目標を語った。

対して、エンジニアやアナリストがKagglerに今後期待するのはどのようなところなのか?

まず鈴木。「社内でエンジニアとして機械学習に興味を持っているメンバーがたくさんいるので、そういった人たちに教えてもらったり、何らかの機会で社内全体のデータサイエンス力の基礎力を上げる取り組みをしてくれるといいなと思います」と今後のKagglerに期待を寄せた。

また「エンジニア側として取り組んでいきたいこともあります」と鈴木。

「チームで成果を出すというところを意識しているので、Kagglerがもっと高速に分析、実験を行える環境を用意したい。もっと色々なところでモデルがデプロイされて動いていくと思うので、デプロイの仕組みをより効率化して、MLOpsもしっかりやっていきたいと思っています。あと最近の分析環境は大体AWSなどに構築することが多いので、その辺にしっかりキャッチアップして、Kagglerに提示してあげたい」(鈴木)と、自身の今後についても触れた。

山川は「今は全社的にAIが使われていますが、Kagglerがメインで関わっているのはオートモーティブ事業。一方でゲームエンターテインメント事業も解ける問題、解きたい問題がたくさんありますし、ヘルスケアなどその以外の事業もある」と、今後Kagglerにそれらの領域にもどんどん出て行ってほしいとコメント。

そして自身の今後については、「サービスからの課題に対する要求水準がどんどん上がっていく中で、アナリストとして事業部とデータサイエンスグループの間に入り、自分でも事業者視点で問題設定ができて、なおかつどうしたら問題として最適にデータサイエンティストと一緒にやれるかというところを考えられるよう、アナリストとしてもう少し力をつけていきたい」と語った。

最後に原田は、「Kagglerは結局のところ専門性を持った集団。それがどうやったら上手く活きて、どうすれば全社の役に立つのか? 色々な方にお世話になりながら今後も進んでいくのかなと思っています」と本セッションをまとめた。

セッション中、描かれ続けたパネルディスカッションの流れをまとめたパネルも完成した

セッション時の投影資料はこちら

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

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

GeNOM(ゲノム)とは

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

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

[/su_note]

【後編】DeNAゲーム事業におけるデータエンジニアの貢献〜客観性を担保したLTV予測やBigQuery運用におけるコスト最適化、そしてMLOpsへの挑戦〜

2019年2月6日、渋谷ヒカリエにて、技術者向けの大規模イベント「DeNA Technology Conference 2019」が開催されました。

本記事では、DeNAゲームサービス事業部の分析部に所属する岩尾と石川による「DeNAゲーム事業におけるデータエンジニアの貢献」と題したセッションの後編をレポートします。

前編はコチラをご覧ください。
※記事の最後にはセッション時に投影した資料を掲載していますので、そちらもご覧ください。

BigQuery運用のコスト最適化、その事例に迫る

第2部”システム運用の改善”は、分析部の3つの役割の中の改善系がテーマ。BigQueryの運用におけるコスト最適化やMLOpsへの挑戦といった裏で動いているシステム、特に運用周りにおける課題とその解決策について、岩尾が解説していった。

分析部データエンジニアリンググループ グループリーダー:岩尾一優

昨年7月にDeNAにジョインした岩尾は、「入社以来、ずっとBigQuery周りのコストの事が気になっていた」と、ただ規模が大きいだけでなく秩序が乱れているように感じたそうで、現在”BQ警察”としてコスト最適化に注力している。

始めに岩尾は、DeNAゲーム事業でどれくらいの規模のデータを扱っているか数値で示し、BigQueryのストレージ容量が2PB以上、BigQueryのコスト(2018年9月時点)が月680万円かかっていると説明。「これはかなり大きい部類のデータとコスト」(岩尾)だが、それが12月の時点で420万円になったという。

その3ヵ月間でコストを削減した過程で何を行ったのか? 岩尾は大きく分けて3つあるとし、その1つが現状の可視化。請求データを使って全体を見た後に、BigQueryのメタデータを見て何にどれくらいかかっているのかを可視化したそうだ。

可視化によって攻め所がわかってきたので、次にシステム的な改善に着手。ここで岩尾は、「BigQueryはスキャンしたデータ量によって従量課金である」という特徴を紹介し、この点が重要なトピックスとした。

3点目は運用の改善。そもそも巨大なクエリを投げてしまったときに気づく仕組みがこれまでなかったという背景があり、そこを気付ける仕組みを導入し、気づきの後にメンバー間で改善するマインド醸成に取り組んだという。

採用した主な技術を紹介

現状の可視化(請求データ)について、2018年1月~9月の期間、どのようにコストが推移しているのか現したグラフが提示され、「ストレージもクエリ検索もコスト増加傾向で、3ヵ月ごとに月額で100万円ほど伸びている」と解説した岩尾。

その詳細を確認するために利用されたのが、Stackdriver Monitoring。これは専門的な知識がなくても簡単な操作でGCPやAWSのリソースと連携してメタデータを可視化できるという。「我々の使い方では、BigQueryのメタデータ(ストレージ容量やクエリ検索量)の見える化に利用している」(岩尾)とのこと。

ストレージ容量の内訳を確認する際、あるゲームでは特定のデータセットがストレージの大半を占めていることなどがわかるという。その部分を削減することができれば「ストレージ容量が大幅に削減できそうだなというあたりを付けることができる」と岩尾は語った。

そしてクエリについては、ゲームごとのクエリ検索量を色分けして明確化した。これで、ある部分が全体の大部分を占めていることがわかる。

「ゲーム自体は十数タイトル管理しているが、その中でもいくつかのタイトルだけに集中していることが見てとれます。もちろんデータの保存量自体バラつきはあり、これで一概に良い悪いは言えません。利用者によるスキルのバラつきや、そもそも検索対象となっている中間テーブルの設計に問題があるのかも」という部分にも踏み込んだと岩尾は語った。

また、別の切り口として、ある日、クエリが1日に50TBくらい投げられた事件が発生した事例を紹介。これも可視化することにより、担当者が意図していたクエリかどうか、その原因を調べることができるなど対策の検討がしやすいという。

ここまでが現状の可視化について。次に岩尾は5つの改善事例を紹介。

1つ目は、データライフサイクルの定義することでストレージ容量を削減した改善事例。データ分析は本来1日だけ保存しておけばいい場合や、ずっと残しておきたいなど、必要な保存期間が異なる。ただ、「リリース時にそれが確実にわかるかと言えばいえばそうではない」と岩尾。

そこで重要なのが定期的な棚卸。「我々はデータアナリストと同じ部内にいるので、連携しながらこれは消していいのかどうか棚卸しながら設計しました」(岩尾)とし、必要な保存期間に応じてローテーションさせる仕組みを導入した。

そして設定ファイル上で、どのプロジェクト、どのデータセットでどのテーブルを何日間保存したいのかを一元管理した。一つのプロジェクトだけではなく、全体でどんな感じで設定されているか一元管理することで、検討漏れがなくなる。あるゲームタイトルでは約60%のストレージ容量を削減できたそうだ。

※一部AWSを利用しているのはシステム移行中のため

2点目の改善策は、Clusterd Tables(β版)を導入したクエリ検索量の削減。これまでBigQueryは分割テーブルを使って検索量を抑えていたがそうだが、一方で日付レベルよりさらに絞り込む方法はなかったという。

そこで、「他のカラムについてもインデックス付与することにより、ある程度検索範囲を絞れる機能を導入した」と岩尾。実際にこれまで1回で2TB検索しなければいけなかったものが、2GBまで抑えられたという例もあったそうだ。

また、移行については新規テーブルを作成し、既存テーブルからレコードをコピーするので面倒ながらも、「そこさえ乗り越えればかなりの恩恵がある」(岩尾)とのこと。

3点目はjsonペイロードのparseによるクエリ検索量削減。ユーザーが保持しているアイテムの1~100から1だけを抜き出したい場合でも、これまではjsonペイロード全体を検索してしまい、クエリ検索量の増加につながってしまっていた。そこで、よく使うデータはparseして別のカラムとして保持して検索するのがクエリ検索量削減になるそうだ。

4点目は、BIツールの不要な定期実行機能を停止することでのクエリ検索量の削減。岩尾は「我々は、使っているBIツールをcron形式で行っていたので、それに慣れていないデータアナリストであれば、不用意に週末だったり夜間を実行してしまうことがあった」と説明し、その点も改善した。

最後の改善事例は、巨大クエリ実行時にSlack通知をする仕組みを作ったこと。

岩尾によると、システム的にガードをかけることも可能だそうだが、「本当に必要なクエリをたたくときにエラーが返ってきたら、イラっとすると思う。システム的ガードではなく敢えてメンバーを信頼し、巨大クエリを投げてしまっても通知を見て皆でどうすれば良かったか話し合える文化をつくりたかった」とのこと。

そして岩尾は、紹介した改善事例にって、結果的に月260万円のコストを削減し、ストレージは40%、クエリ検索は41%改善したことを明かした。

MLOpsへの挑戦、今後のデータエンジニアリンググループの展望

最後にMLOpsへの取り組みについて紹介した岩尾。

伝えたいこととして、「初心者にとってMLモデルの実行はハードルが高いです。部内のデータサイエンティストがJupyter Notebookで作成したMLモデルをgithubなどで経由してやり取りしていたが、それだと自分の環境だけ動かないみたいなことも発生してします。環境構築ほどイライラする作業はないと思っている」とそれを解決したいと考えたのが取り組みへのキッカケだそうだ。

従来のシステムは、VM上にMLモデルの設置、実行をしていたが、この構成だと環境構築が面倒で、今後の移行も困難だという。そこでBigQuery、Dockerに加え、ContainerRegistryという主な技術を活かし、「dockerコンテナで起動するよう変更した」(岩尾)という。

それによる新しいシステム構成では、EC2上でdockerコンテナを起動する方式を採用。Container Registryから必要なDockerイメージをpullして使うだけで環境構築が簡単で、GCP移行時もGCEでdocker runするだけの容易さがメリットのようだ。

※一部AWSを利用しているのはシステム移行中のため

岩尾は、「これまでデータ分析におけるMLの導入は環境構築や移行の手間に悩まされてきたが、MLモデルをdockerコンテナを入れたことで解決に向かっている」とML Opsの現状に触れたが、「まだまだ未解決な部分もある」とし、今後の展開として、現在ローカルで行っているDockerイメージのビルドを自動化したり、もしくは学習・推論でモジュールを分割すること、モデルのバージョン管理、ロギングについて、「現在対応をしている最中」とコメントした。

そして最後に、「データエンジニアリンググループは2月から出来たばかりの組織です。本日お話した内容以外にも色々行っています。現在立ち上げ期ですので、我こそはというデータエンジニアの方はジョインして一緒に盛り上げていきましょう」とメッセージを送った。

前編を読む
【前編】DeNAゲーム事業におけるデータエンジニアの貢献……客観性を担保したLTV予測やBigQuery運用におけるコスト最適化、そしてMLOpsへの挑戦

セッション時の投影資料はこちら

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

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

GeNOM(ゲノム)とは

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

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

[/su_note]

【前編】DeNAゲーム事業におけるデータエンジニアの貢献〜客観性を担保したLTV予測やBigQuery運用におけるコスト最適化、そしてMLOpsへの挑戦〜

2019年2月6日、渋谷ヒカリエにて技術者向けの大規模イベント「DeNA Technology Conference 2019」が開催されました。

本記事では、DeNAゲームサービス事業部の分析部に所属する岩尾一優、石川勇による「DeNAゲーム事業におけるデータエンジニアの貢献」と題したセッションをレポートします。

※記事の最後にはセッション時に投影した資料を掲載していますので、そちらもご覧ください。

分析部とデータエンジニアの紹介

DeNAの分析部は、事業における意思決定の質を最大限に高めるための部門で、より高度な分析を低コストで実現するために、BigQueryを中心としたデータ分析基盤を活用している。

「DeNAゲーム事業におけるデータエンジニアの貢献」と題した本セッションでは、“DeNAのゲーム事業における意思決定を分析部がどのように支えているか”“データ分析基盤を運用する中でぶつかった課題をどのように乗り越えてきたか”について、分析部の岩尾、石川が、技術的な側面から実例を交えて紹介していった。

まず、ゲームサービス事業部 分析部について岩尾が紹介。分析部はゲーム事業における意思決定の支援をするのが役割で、例えばゲーム内施策の立案のサポートや振り返り、それから事業計画立案のサポートを行う組織とのこと。

意思決定の支援という意味合いでは、主にデータアナリストが役割を担うが、我々データエンジニア、データサイエンティストも所属しており、同じ分析部内にこれらの役割が所属するというところで効率的に活動を進めているという。

そして、DeNA分析部の特徴について、「データエンジニアはアナリストと仕事することでゲームのドメイン知識も自然と溜まる。逆にアナリスト、サイエンティストもエンジニアと仕事することで技術力の強化ができている」(岩尾)と紹介した。

岩尾曰く、データエンジニアの役割を細分化すると、事業に対して直接付加価値を与えるような活動をする事業系の役割、そして作成したシステムを保守、改善していくという役割もあるという。そこで本セッションは[su_highlight background=”#d5ff99″]第1部で事業系と保守系[/su_highlight]、そして[su_highlight background=”#99fffd”]第2部で改善系[/su_highlight]の2部構成で行われた。

 

客観性を担保し、安定的に利便性高くLTV予測を提供する手法とは

まず第1部では、石川が登壇し、”LTV予測による事業への貢献~エンジニアによるビジネス意思決定サポート事例~”をテーマに話を進めた。

分析部の石川勇

始めにLTVの重要性について触れた石川。一般的なLTVの定義は、顧客生涯価値、平たく言うとサービスと関係する中で顧客が支払うお金の総額となる。

これをゲーム事業に当てはめると、サービス開始から終了までにプレイヤーが支払う総額という定義だ。ただ「1人あたりの金額、というのが曲者」と石川。ゲーム事業では、「月額購入や都度課金など商品の買いかたなど多種多様。また、商品を買わなくても楽しんでもらいたいという無料サービスの側面もあり、1人あたりの平均金額というものはかなり予測しずらい」(石川)という。

石川は「LTVの数字は、広告やCMにいくらかけるかを判断する直接の数字となっており、計算する必要性がある」として、一例としてゲーム事業における宣伝広告費で、DeNAでは3ヵ月間で30憶円程度になるとのことだ。

LTVの事業的な重要性を説明したところで、実際どのようにLTVが使われているかを石川が説明。



まずは仮のケースとして、LTVを用いたCMの投資判断・効果測定例の図(上)を元に、1つのCMで数億円を使った投資判断について、LTV予測を極端に外した例を紹介した石川。

CM費用が3憶円かかるとして、その投資判断する場合に売上の見込みを計算するのが通例。このケースではCMで20万人がゲームを開始して、LTVが3000円と予測している。つまり6憶円の売上増加が見込めるという予測だ。

ところが蓋を開ければ20万人がゲームに入ってきたが、想定に反して実際は売上が2憶円しか増えておらず、CMとしては1憶円の損失という例だ。

石川は「実際のLTVが1000円だったため、3000円の予測が高すぎた」ことがこの例での失敗の要因と説明。このように特定の機会に流入してくる顧客のLTVを予測するニーズは高く、予測を外したときに事業に与えるインパクトが大きいことがわかった。

このように重要な事業判断の要素となるLTVだが、これまでどのような課題があったのか? まずLTV予測では、インストール時期ごとにプレイヤーの熱量やゲームの仕様が異なるため、インストール時期を起点に算出していた。また、顧客生涯価値としながらも一律に比較するために180日など一定の期間で区切っていた。以下がその具体的な手順。

このように、180日LTVを予測したい場合、まずは月ごとに登録したプレイヤーのLTVの平均値、現在が8月だとしたら最も最近のゲーム仕様のLTVを参照したいためまずは、3月~6月のプレイヤーのデータを実績として算出していた。ここで気づくのが、どの期間のプレイヤーも180日間遊んでいない点。これはこの後をどう予測するのか?

「従来は過去の30日LTV実績を、180日LTV相当に伸ばす作業がまず必要だった」(石川)そうだ。

最後にCM対象月と近い条件の月などからCM時の予測LTVとして出していた。この予測された180日LTVを1年以上経過した後に、本当の実績と比較しながら、予測手法について振り返ることになる。

では、なぜこのような予測方法なのか? 実はそこがLTV予測の難しさを表していた。

ゲーム事業ではプレイヤーの平均像というのもがなく、石川は「過去の実績を元に未来を予測する際、未来のプレイヤーが過去と同じであればもっと色々な方法があるが、過去と異なる可能性が非常に高い」と語る。また、ゲーム側もその内容が変わってくる場合もある。

「運用計画はあっても、実現の程度がよくわからなかったり、臨機応変な運用をするために未来の情報はないと考えて良い状態。そういったものを考慮項目としているが、プレイヤーもゲームコンテンツも変わる中で、さらに金曜日や年末に入ったプレイヤーはじっくり遊んでくれそうといった、時期に関連した考慮項目が過去の手法では区別できていなかった」(石川)。それがLTV予測の本質的な難しさになっているのこと。

続いて石川は、予測の改善サイクルについて紹介。実は予測LTVについて、DeNAで過去に何度かプロジェクトが立ち上がっていたそうで、対策してきた中で周辺の課題自体は見えていたという。



1つ目の課題は恣意性。実はトータルで過去の色々なCMを振り返ってみたとき、「予測LTVがなぜか高く見積もられる傾向があった」と石川。「先程話にあった年末や金曜日のLTVが高いというトレンドを考慮項目としながらも、実はわからないと言われていた運用項目や、運用予定の希望的観測も予測に含まれがちになるのが原因だった」と続けた。

このような定義できない考慮項目を選択するしかない手順が課題としてあり、LTVの見積もりが高くなってしまう傾向は判断を見誤ることにつながるため、恣意性を排除する必要がある。



次の課題は予測モデル更新の負荷。これまで伸び率を算出する方法として累乗近似などのモデルが用いられていたが、係数はフィッティングした後もしばらくは使えるが半年後、1年後になると段々外れてきてレガシー化してくるため予測モデルの再開発、再フィッティングが必要だがそれが大きな負担となっていた。



3つ目の課題は、予実評価の難しさ。予測LTVは担当者に依頼しないと手に入らなかったが、実績が出るのが半年~1年後のため、その間に予測担当者が異動や退職する場合もあり、過去のサンプリ期間や考慮項目、予測モデルのバージョンの組み合わせがわからなくなることが頻繁にあった。

そして石川は、これらの課題を1つ1つ解決していった。

まず、予測LTV作成に恣意性が入り得るという課題については、サンプリング期間、考慮項目(トレンドと周期)を固定し、まずどこかの月を選ぶという作業をしないこと、すべての数字、データを使うことに決めたという。それから考慮する項目についても予測で使う項目は限定し、考慮の難しい顧客の傾向やゲーム内施策を選択しなくて済むようにしたとのこと。

この2点を決めたうえで予測改善プロジェクトを立ち上げ、データサイエンティストとチームを組んで、ほかの業務を進めながら2ヶ月でプロジェクトを完成。石川はその過程について触れ、Prophetという既存の時系列取得モデルについて紹介した。

Prophetはpythonで利用できる簡単なライブラリ。ライブラリ側でモデルの学習が行われ、学習したモデルが将来のLTV予測値を出力。これにより実際に恣意性を排除した予測を完成させた。

予測モデル更新の運用が手間という課題については、MLモデル on VM+Jenkinsで「モデルの更新+推論」を自動化して解決。予測モデルのタスクは開発(Prophetというモデルを選定、検証解釈する)、更新(Ptophetのモデルを学習する、またはしなおす)、適用(学習済みモデルで実際の予測をする)の3つに分類されている。

これにより、過去の累乗近似では更新が面倒だったが、Prophetで時系列予測に置き換えたことで更新、適用が高速化され、毎朝最新の予測を算出できるなど完全な自動化に成功した。

3つ目の予測LTV提供に時間がかかる予測と実績の評価ができないという課題については、BIツールで最新の予測結果を提供、過去の予測と実績も一括で提供でき、改善・効率化された。

最後に石川は、「過去のプロジェクトが抱えた課題を解決し、これにより客観性が担保され、安定的に利便性高く予測を提供できるようになった」と第一部をまとめ、全社的なクラウド移行が予定されていることなど、今後の展望について紹介した。

後編へ続く
【後編】DeNAゲーム事業におけるデータエンジニアの貢献……客観性を担保したLTV予測やBigQuery運用におけるコスト最適化、そしてMLOpsへの挑戦

セッション時の投影資料はこちら

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

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

GeNOM(ゲノム)とは

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

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

[/su_note]

【プロトタイプ開発の裏側】独自フレームワーク「Chimera」の利点と今後の展望、そして”ものづくり”に対するスタンスをエンジニアが語る

大型メジャーゲームタイトル開発を担うDeNAの「ゲームコンテンツ事業部 第二開発部」は、プレイヤーの期待値を大きく超える、高品質で魅力にあふれたゲームを生み出すことをミッションとしています。

そのプロトタイプ開発のベースを支える基盤[su_highlight background=”#99ffe6″]「Chimera(キメラ)フレームワーク」[/su_highlight]を独自で構築した、エンジニアの宇塚貴紀と大久保新樹に、機能や特徴、導入する利点などについて聞いてきました。

[su_note note_color=”#ffffff” radius=”10″]
[su_row][su_column size=”1/4″ center=”no” class=””]
[/su_column] [su_column size=”3/4″ center=”no” class=””]宇塚貴紀
ゲームコンテンツ事業部第二開発部企画開発グループ

2014年新卒入社。プロトタイプ向けのゲーム開発、大規模なシミュレーションRPGや3Dマルチプレイアクションゲームの開発を経て、現在はリードエンジニアとして新規タイトルの開発に従事。[/su_column][/su_row]
[su_row][su_column size=”1/4″ center=”no” class=””]
[/su_column] [su_column size=”3/4″ center=”no” class=””]
大久保新樹
ゲームコンテンツ事業部第二開発部技術第二グループ

2015年にDeNAに入社。20年ほど前から家庭用ゲーム機向けのゲーム開発に携わっており、現在はアプリや基盤の開発を担当。[/su_column][/su_row]

[/su_note]

丁寧な設計よりもシンプルかつスピーディーなプロトタイプ開発

――まずは、お二人が所属されている第二開発部のミッションについて教えてください。

宇塚貴紀(以下、宇塚):第二開発部は、メジャータイトルを手がけるプロフェッショナル集団として、プレイヤーが求める期待を真っ向から超えられるよう、魅力的で品質も高い大規模タイトルを内製で開発する、というのが主なミッションです。

大久保新樹(以下、大久保):そのようなタイトルは大規模になるので、数打つわけではなく、1つ1つ注力して開発しています。

――その中でお二人の役割は?

宇塚私はコアロジックからUIや演出などまで、フロント全般を開発しています。いかにプレイヤーが気持ち良くゲームに触れるか、リードエンジニアとしてチームのデザイナー、プランナーと相談しながら、私達が目指すおもしろさやカッコ良さを実現させていくことが、主な仕事になります。

大久保:最近は主にゲーム開発のベースとなる部分の開発をしていることが多いです。後ほど紹介するDeNA独自のフレームワーク「Chimera(キメラ)」(以下、「Chimera」)も、プロトタイプを早く組み上げるためのフレームワークです。

――ゲームのプロトタイプ開発で心がけていることを教えてください。

宇塚長期的に利用する機能や運用ツールは、機能を足したくなったときのために拡張性を作っておこうという、先を見据えた準備が必要だと思っています。

そこができていないと、開発メンバーが使いにくかったり、時代の流れに合わせた付加価値を出すことができなくなり、修正コストも大きくなって、自分以外のメンバーに迷惑をかけてしまいます。

私自身、1~2年以上開発した大規模なプロジェクトや個人でゲームを開発してきた経験の中で、先を見据えた拡張性が本当に問題だと感じています。プロトタイプ開発の場合でも、以前は先を見越して丁寧に作ることを良しとしてきました。

ですが、プロトタイプ開発って「こういう風に切り替えたほうが面白いよね」とか「この機能作ったけど全部必要なかった」といった想定外の変更が頻繁に入るんです。

あるメンバーのアイデアを試した結果、またそれにより全く新しい別のアイデアが生まれるということもよくありました。そういう場合、1つ目のアイデアを実装するときに組み立てた設計やクラス構造通りでは、2つ目のアイデアを実現しにくい、というケースも頻繁にありました。


でも、そうなった時にエンジニア側が勝手に考えたレールによって、良いアイデアを捨ててしまうのはもったいないことです。
だからプロトタイプ開発では、あまり先のことを想定しすぎず、現時点で作った部分が不必要になったときにすっきり消せるようにして、大きな変更があったときに置き換えしやすいようにすることを心がけています。

そうは言いつつ、大久保さんからは「ここ作り過ぎじゃない?」と言われたこともあります(笑)。

大久保:結構みんなプロトタイプ開発なのに、本格的に作るクセが付いている気がしています。
プロトタイプ開発では、シンプルに作って試してみてダメだったら消して、良かったら後から丁寧に作り直すほうが良いんです。おもしろさを試すという意味では、やり過ぎなくらいシンプルに作ったほうがスピードも上がりますから。

独自フレームワーク「Chimera」がプロト開発にもたらす利点

――そのような背景もあり、DeNA独自のフレームワーク「Chimera」が生まれたのですね。

大久保はい、「Chimera」はゲームのプロトタイプをすばやく作るための、アクション性のあるゲームを主な対象としたフレームワークです。


――改めて、なぜ「Chimera」を作ることになったのでしょうか?

大久保:「Chimera」が生まれたのは、新しいゲームのプロトタイプをすばやく作り、アイデアをたくさん試せるようにためです。プロトタイプを作り始めるときに、ゲームとして本当に基本となるような機能だけを作るとしても、一定の開発工数が必要になります。

ただ、それぞれのプロトタイプチームが別々に基本機能を作った際に、似た機能の開発に時間を割くのはもったいないので、どんなタイプのゲームであっても基礎部分として使えるフレームワークを用意し、アイデアを試す部分により時間を使えることを目指して、僕がイチから作りました。

――「Chimera」の主な機能や特徴は?

大久保主な機能や特徴ですが、ゲームを開発する上で必要そうな細かい機能(下記参照)がまとまっています。
[su_box title=”「Chimera」の主な機能” box_color=”#9caac1″]
・当たり判定とそれに伴う汎用ダメージ処理
・エンティティ管理
・エンティティ間のメッセージのやり取り
・キャラクターの行動制御
・キャラクターのAnimation制御
・キャラクターのステータス変化の制御
・カメラ制御
・開発確認やDebugをしやすくするコンポーネント
・その他便利なコンポーネント[/su_box]

また、別パッケージでは「Photon Unity Networking をChimera上で使う仕組み」「Photon Bolt をChimera上で使う仕組み」「シンプルなUI要素」などがあります。

――実際に「Chimera」を使ってみていかがでしたか?

宇塚「Chimera」のコードはシンプルで使いやすく、流れがパッとわかるんです。ゲーム開発の歴史のいろいろなものが積み上がった知識が詰まっているので、理解しやすく自由度も高くて、どんなプロトタイプ開発でも使いやすいと感じました。

もちろん、始めて使ったときは今までの作り方とのクセの違いに少し苦労しましたが、そこを乗り越えてからは開発スピードはものすごく上がりました。自分がプロト開発をゼロから始めたら、基本的な機能を整えるのにずっと長い時間が必要だっただろう、と感じています。



――その他、「Chimera」の利点などはありますか?

宇塚ゲームで実現したいアイデアや機能って、実は他チームのゲームと似通っていることも多いんです。

例えば「キャラクターが走ってジャンプしてアイテムを取る」というようなゲームでよくある機能を作るとき、「Chimera」を使っているタイトル同士であれば、当たり判定やキャラクターの動作の処理が類似しているので、他のタイトルで実装済みの処理を利用することができます。

基盤や設計思想が違う場合は、考え方を参考にする程度でほとんどの処理を自分のタイトルに合わせて書き直さなければならないですが、共通の基盤に乗っているとその無駄を省くことができます。

また、自分自身で複数のプロトタイプを作るときも、1作目で使ったダメージ数値を表示する機能を、2作目を作るときにそのまま引用できましたし、ミニマップのUIや、キャラのHP・MPと当たり判定をつなぐ部分なども使い回せました。

1回作った機能は後でまた使いたいときにスムーズに導入できるので、「Chimera」を使っての開発は進めば進むほど、次の開発スピードが上がっていく感覚があります。

「Chimera」が広いゲームジャンルで使えることにより、多くのプロトタイプで機能の再利用ができることも利点だと思っています。

――結果的にプロト開発のスピードは上がったと。ちなみにどれだけ生産性が上がったのでしょうか?

宇塚成果を言葉や数字にするのは難しいですが、仮に多くのゲームで実装するような当たり判定を、本やネットのコードだけ参考にしてゼロから作るとすると、バグ取りも含めて1~2週間はかかると思います。

「Chimera」を使えば、拡張しやすい当たり判定をスルッと再利用できるので、10営業日くらいのコストダウンにはなります。当たり判定以外にもよく使う基本的な要素を整った形で導入できることを考えると、慣れている人がやらなければいけないタスクの数ヶ月分がスッと手に入るイメージでしょうか。

大久保その分、初めて使うときの学習コストが2週間程度かかりますが、結果的にコストを縮めることでより多くのアイデアを試す時間に使えて、ゲームをさらに改良できると思います。

宇塚どのゲームでも同じように動けばOKという部分は絶対にあるので、同じ機能をわざわざ毎回作るという無駄なコストをかけなくて良いのはありがたいですね

――実際に使っている宇塚さんは「Chimera」に対して何か要望はありますか?

宇塚「Chimera」はUnityでの開発に利用できるフレームワークです。Unityはグラフィカルなインターフェースを使ってさまざまな設定ができること、またそのエディタを拡張しやすいことが強みだと感じています。

一方で、特に初期の「Chimera」はGUIを使わずにコード上であらゆるものを設定する思想になっていたため、作り方は大きく隔たっていましたGUI上での設定をよく利用していた私からすると、全てをコードで定義しなければならないのは辛いな、と思った部分はありました。

ただ、慣れてくると全てがコード上に残っているので、コントロールはしやすいことがわかりましたし、グラフィカルにする部分も自分で作ろうと思えば作れるので、解決はできました。

今後の展望としては、例えばデザイナーと一緒に開発する運用期にGUI的なツールと「Chimera」が組み合わせやすくなっていると、初めて触る人でもあまり困らないかなと思っています。

――「Chimera」の改善点や今後の展望はありますか?

大久保「Chimera」自体はプロトタイプ開発での使用を想定したものなので、開発効率を優先していて、CPUコストやメモリ使用率などは気を使って作られていません。

そのため、製品に出す場合は「Chimera」はクオリティ的に使えないので、今後はプロトタイプ開発でも製品版でも使える「Chimera2」を開発中です。

宇塚いま「Chimera」でプロジェクトを動かしていますが、大規模で多くのキャラクターを出す場合に、パフォーマンスより拡張性を重視した仕様が起点となって負荷が高まってしまったり、開発していて「Chimera」側で調整してくれたら助かるということが、少しずつ出てきています。

その部分を改善した「Chimera2」のようなバージョンを、大久保さんが作ってくれています

――社内のプロト開発全体に好影響をもたらす「Chimera」がエンジニアにもたらしたことを改めて教えてください。

宇塚新規プロジェクト始動時メンバーがゼロからスタートして、バラバラに部品を作ることによる再発明の多さや工数の無駄遣い、クオリティのバラつきをなくすという意味で共通的なものが生まれて、エンジニアとしては非常に助かっています。社内でさらに有効に使える人が増えていくと良いなと思っています。

大久保Chimera」がゲーム開発の参考になっていると思います。

宇塚:あと、「Chimera」のコード自体は全社公開されているので、社内でゲームの基礎部分を開発しようとする人には、とても参考になっていると思います。

――現状、DeNAのエンジニアはみんな「Chimera」を活用しているんですか?

大久保社内全体で使われているわけではなく、以前からあるプロトタイプチームと、今僕と宇塚さんでやっている新しいゲームの開発で主に使用しています。

「Chimera」を使った開発の現状についても、当たり判定やキャラの基本的な行動制御などは、過去のゲーム開発で積み上げた知見を活かして、すばやく実現することができましたし、それによって、ゲーム特有のロジックやネットワーク制御といった機能に集中して開発を進められています。

宇塚:プロトタイプを作るいくつかの部署で使われており、「Chimera」を利用する中でどんどん大きくなっているプロジェクトもあるので、効果は出ていると感じています。

DeNAエンジニアの”ものづくり”に対する姿勢

――お二人が所属する第二開発部にはどのようなタイプのエンジニアが多いですか?

宇塚DeNAは会社全体としてロジカルな考え方をしながら、ゲーム開発に対して情熱的な思いを持つタイプのエンジニアが多い気がします。

大久保確かにそうですね。ロジカルでパッションを持ったエンジニアというイメージが強いと思います。

宇塚:以前、私が担当していたアクションゲームの開発チームメンバーに若手が多かったこともあり、自分たちが作ったものに対して「良いよね!」「これすごいじゃないですか」と自画自賛するエンジニアもいたりと、ゲーム開発という”ものづくり”において情熱的なメンバーが揃っていると思います。

――お二人のエンジニアとしての”ものづくり”に対するスタンスは?

大久保自分自身がものを作っているのが好きで、楽しみながらゲーム開発のエンジニアをやっています。なので、自分が楽しんで作ったものを他の人たちも楽しんでくれる、お互いにハッピーになれたら良いというスタンスでものを作っています。

宇塚驚くようなおもしろさや、心を動かすようなものがゲームの世界なら作ることができると思っています。

自分でもゲームをプレイしていて、ビックリするくらいハマっちゃうこともあります。そういう人の心を揺り動かしたり、泣いたり喜んだりする感情を、自分たちが作るゲームで周りの人にも体験してもらいたいと考えています。「最高だよね!」という感動をみんなと共有して、本当にすごいものを作ったと言いたいです。

ゲームは今やれることがどんどん増えていて、今後20年、30年と時代が進んだときに、「ゲームなんて子どもの遊びでしょ」と言っていた人たちでさえ、「感服しました、ゲーム最高です!」と思わせてしまうようなすごい体験を提供できるんじゃないかと思っています。

今の段階でも、それにどんどん近づけるくらい、おもしろいものはできていると感じていますし、そこを目指して日々楽しみながらものづくりに取り組んでいます。

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

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

GeNOM(ゲノム)とは

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

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

[/su_note]

【ナカノヒトTalk #001:エンジニア山浦大輔】不確実性と向き合い「DeNAだからこそ、作れる」仕組みを構築していきたい

DeNAのゲーム開発の現場には、どんな人が働いていて、どのような思いを持って仕事に取り組んでいるのかーー「ナカノヒトTalk」は、社内のさまざまな職種の人へのインタビューを通して「人となり」をお伝えする特集です。

記念すべき第1回はエンジニアの「山浦大輔」さん! 山浦さんは新規ゲームタイトルを開発する部署に所属し、たくさんのエンジニアをまとめる親分的マネージャー。彼のデスクのまわりでは、いつでもチームメンバーのにぎやかな声が飛び交っています。

――記念すべき第1回です。よろしくお願いします! それではまず最初に、現在携わっている仕事内容を教えてください。

山浦:お願いします! 自分は2017年にDeNAに入社後、オリジナルの新規ゲームタイトルを開発する部署に配属になり、現在はエンジニア組織を横断するマネージャーをしています。

――マネージャーの立場として、どんな活動をしていますか?

山浦:最近では[su_highlight background=”#f7ff99″]「エンジニア同士の横のつながりを強化する試み」[/su_highlight]を積極的に行っており、技術分野別の分科会を作ってみたり、気楽に交流できる食事会を実施しています。そのおかげでチーム内での自発的なコミュニケーションも、ちょっとずつ増えているのを実感しています。

あわせて、自部門で新しいアプリケーションを開発する土台となる、エンジニアメンバーの思想をぶらさないための共通言語として、社内に蓄積された多彩なノウハウを集約して、共有可能なフレームワークの構築を進めている最中です。

――チーム全体を幅広く見る動きが多いんですね。では、DeNAでの仕事の面白さや大変さを教えて下さい。

山浦:不確実性が非常に高いゲーム事業において、素早くトライ&エラーできるような環境を整えるため、エンジニアリングの基盤を固めて「DeNAだからこそ、作れる」仕組みを構築することを目標として、日々動いています。もちろん大変なことも多いですが、やりがいがあるので楽しいです。

また、DeNAは社員の平均年齢が若く、その中でも若手社員に求める責任や役割が結構大きいんです。力が有り余った彼らが、時に必要以上に深掘りしていたり、難しく考えすぎているように感じられることもあるので、間違った局所最適にならないように俯瞰して見たり、シンプルに考えたりすることを心がけています。

――DeNAに入社する前は、どのような仕事をしていましたか?

山浦:前職は大手コンシューマゲーム会社で、家庭用やアーケードなど数多くのゲームタイトルに携わっていました。

その後、数年にわたり運用されているモバイルゲームの開発初期メンバーとして、プロトタイプ製作から携わり、リードプログラマー、開発ディレクターを経て、最終的にプログラマー組織のマネジメントを兼任していました。

当時培ったマネジメント経験を活かしながら、チーム全員と進むべき方向を一緒に見つけることができれば、もっと強いエンジニア組織になるだろうと信じて進んでいます!

――過去のマネジメント経験が現在の部署で役立っているわけですね。ちなみにDeNAに入社してから感じたことって、ありますか?

山浦:実は、もっとちゃんとした開発現場だと思ってたんです(笑)。入ってみたら、なんだかとっ散らかってるっていうか……。ちょっとした物事を決めるときも、複雑に考えすぎな部分も感じましたね。

ですが、[su_highlight background=”#f7ff99″]「面白いゲームをどんどん生み出していこう!」[/su_highlight]という運営チームの姿勢、分析方法や数字に対するロジカルな考え方は、スゴく学ぶところが多いです。

――他に「DeNA」っぽい出来事とかありましたか?

山浦:少し前の出来事ですが、新規プロジェクトで使用したいと思った新技術について、必死にネットを探してようやくたどり着いた記事は、実は社内の非ゲーム部門のエンジニアが書いていた、というエピソードがあります。

その時は全く面識のなかった他部署のエンジニアのカレンダーに登録してMTGを設定させてもらい、課題に対するアプローチ方法や関連技術など、いろいろ相談することができたんです。

他分野のエンジニアと話すことで、ゲーム開発における固定観念を超えた提案を得られたのは、まさに目からウロコでした。

――確かにDeNAにはスピーディーな動きができる人が多い印象です。続いてはプライベートをちょっとだけ。休みの日の過ごし方や趣味を教えて下さい。

山浦:以前、駅伝のイベントに参加したことをきっかけに、年末にはハーフマラソンに参加してきました(おかげで入社前より体重が20kg減りました!)。

最近ではFacebookで料理の写真をアップしまくって、友人に「飯テロ」と言われています(笑)。美味しいものに目がないので、普段から食べたり飲んだりすることが多いので、業界の人と飲みの席で仲良くなることも多々あります。

趣味といえば、車が好きですね。自慢の愛車はかれこれ17年くらい乗っています。昔からドライビングゲームも大好きなんですよ。

――Facebookで拝見しました! 車をいじるのも乗るのも好きなんですね。

山浦:そうなんです。実は、車関連のゲームが作りたくて前の職場を選んだ、っていう裏話もあるんです。

DeNAは、オートモーティブやヘルスケアなど他の事業にも力を入れているので、将来的にひょっとしたら「ゲーム×オートモーティブ」「ゲーム×ヘルスケア」のように他事業と結びつくことで、これまでにない新たな試みでヒット作品が生まれるかもしれませんね。

――まだまだ限りない可能性がありそうですね。ありがとうございました!

過去のマネジメントの経験を生かして、シニアだからこそできることがあると体現している、まさしくオッサン希望の星、山浦さんのお話を紹介しました。次回をお楽しみに!

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

GeNOM(ゲノム)とは

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

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

[/su_note]

※本記事は2019年1月時点での情報です。

VRゲーム『VoxEl』開発メンバーが語る技術的な試行錯誤

『VoxEl(ボクセル)』開発メンバーにインタビュー

DeNAのR&Dの一環として開発が始まり、まだプロトタイプながら国内外の展示会で話題となった、『VoxEl(ボクセル)』。本作は少女「エル」に託された不思議なワンド(杖)を駆使して、仮想世界のギミックを解いていくVR専用の謎解きアドベンチャーゲームです。

今回、開発パートナーのあまた社を迎えて、開発中の苦労話や技術的なエピソードを交えながら、両社にお話を伺いました。

[su_note note_color=”#ffffff”]

Profile
[su_row][su_column size=”1/5″ center=”no” class=””][/su_column] [su_column size=”4/5″ center=”no” class=””]

永田峰弘
株式会社ディー・エヌ・エー プロデューサー(兼ゲームデザイナー・サウンドクリエイター)[/su_column][/su_row]

[su_row][su_column size=”1/5″ center=”no” class=””][/su_column] [su_column size=”4/5″ center=”no” class=””]

髙橋宏典
あまた株式会社 代表取締役社長[/su_column][/su_row]

[su_row][su_column size=”1/5″ center=”no” class=””][/su_column] [su_column size=”4/5″ center=”no” class=””]

渡邉哲也
あまた株式会社 シニアプロデューサー兼ディレクター[/su_column][/su_row]

[/su_note]

研究開発目的で始まったVRゲームプロジェクト

――はじめに、『VoxEl(ボクセル)』の開発が始まったきっかけを教えてください。

永田:自分が前年度にVRタイトルを開発していて、その流れでVRゲームのR&D目的のプロジェクトが始まりました。あまたさんとは、『天華百剣 -斬-』の開発でもお付き合いがあり、別ラインでVRゲーム開発実績を持っていたことから、今回の取り組みがスタートしたのが経緯となります。

株式会社ディー・エヌ・エー プロデューサー(兼ゲームデザイナー・サウンドクリエイター)永田峰弘

――『VoxEl』にはあまた社で開発しているVRゲーム『ラストラビリンス』の技術的ノウハウが使われているのでしょうか?

髙橋:キャラクター表現ではノウハウが生きている箇所もあります。ですが、『ラストラビリンス』は閉鎖された空間からの脱出がテーマで、広い世界で旅するというコンセプトの『VoxEl』とはレベルデザイン的に方向性が真逆なため、描画負荷対策を含めて試行錯誤の連続でした。技術的には、ノウハウを活用しつつ大きく挑戦しています。

あまた株式会社 代表取締役社長 髙橋宏典氏

――開発に両社のスマホゲームのノウハウは生かされているのでしょうか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:正直あまり関係はなかったです。スマートフォンのゲームでは小さな画面の中でバトル、強化や育成など、いかにプレイヤーに楽しんでもらえるかというプレイサイクルを中心に考えて開発していますが、VRではその空間で没入できるコンテンツが重要視されるので、ほぼセロベースからの検討になったといえますね。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:ただ、Unity開発なので、3D表示部分などはゲームのノウハウを使用しています。とはいえ、本作はモバイルではなくハイエンド向けタイトルなので、シェーダーや画作りなどはまったく違う工程になってます。[/su_column][/su_row]

――なるほど。では、挑戦した部分や開発中に試行錯誤した点を教えてください。

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:VR対応のアドベンチャーゲームは、本格的に作ろうとするとコストがかかるため、あまり市場に出ていません。そのため、毎日が挑戦の連続でした。また、今回の取り組みにおいても、リソースや開発期間、予算などは限られていますので、その中で最終計画を念頭に置きながら両社で話し合いながら進めていきました。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

渡邉:試行錯誤した点と言えば、VRゲームでは強制的に視点を固定しにくいので、視線誘導で変化が起きた箇所を注視する仕組みを永田さんにチェックしてもらい、フィードバックを受けながら調整を重ねたことですね。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:特に、VR空間内での「サイズによる見え方の違い」のチェックは大変でしたね。プレイヤーがターゲットできるオブジェクトの大きさ、動かせるサイズがどのくらいあれば認識可能なのか、その確認から入っていきます。

現実の空間で50cmくらいあれば認識できるものでも、VR空間にポツンと置くと意外と分かりにくいんですよ。同時にテーブル程の広さなのか、広大な世界にするのか、謎解きの舞台となる空間の規模感も悩みました。[/su_column][/su_row]

――実際にオブジェクトをVR空間内に配置して開発を進めていくんですか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:ええ、そうです。配置パターンを複数用意して、プレイ確認しながら進めます。オブジェクトの質感によって印象も変わるので、何度も調整しました。[/su_column][/su_row]

チームメンバーからの意見・要望を新アイデアに生かす

――両社のやりとりにはどんなものがありましたか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

渡邉:例えばプロトタイプの段階で「超巨大な鉄球を25mプールのような場所で風で飛ばす」というデカいギミックが企画で上がってきましたが、実際に作ってみた結果ボツになったものもあります。個人的にはおもしろかったんですが。

他のVRゲームでは、比較的小さな空間でパズルやキャラクターとコミュニケーションを楽しむ作品が多かったため、『VoxEl』ではあえて広い空間を使うアドベンチャーに挑戦しました。

なので、永田さんからは広大なスペースを使ったギミックの提案が多かったように感じます。一方、髙橋はこじんまりとしたギミックが好きなようで……。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:こじんまりというか、広すぎると影響範囲がわかりにくくなって、エルが相対的に小さくなり存在感が薄くなっちゃうなって。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:いくつかギミックを試作した結果、広い空間を設定してしまうと、エルの存在感が薄くなり、彼女が単純なコミュニケーションキャラクターになってしまうのが課題でしたので、ステージの規模やギミックのサイズ感など改めて修正して開発にフィードバックしました。[/su_column][/su_row]

あまた株式会社 シニアプロデューサー兼ディレクター
渡邉哲也氏

――開発メンバーからどのような意見・要望が出ましたか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:開発現場では、アーティストやレベルデザイナーなどのいろんな職種がフラットに意見を出しながら、既存のVRゲームには実装されていないようなアイデアを盛り込んでいきました。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

渡邉:Primitiveで作ったレベルデザイン周りも、一旦は社内全員にプレイしてもらって、意見を吸い上げた後に永田さんとさらに調整していく、というフローにしました。

企画内容プレビューについては、「ユーザー目線ならどんなことを言ってもOKルール」を採用したので、意外にみんなが好き放題感じたことを言っていたのを覚えています(笑)。[/su_column][/su_row]

VR機器に合わせた操作性の調整とボイスの有効性

――操作周りに関する質問です。本作のプレイはコントローラ1つのみでしょうか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:ですね。実は開発途中では2つ使って、片方はエルと手をつなぐ設定だったんですよ。ですが操作が複雑になってしまうため、現在の仕様になりました。[/su_column][/su_row]

VRコントローラをゲームの中で「ワンド」として使用。トリガーを押してエレメントを吸収します

――操作感に関する調整は大変でしたか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

渡邉:異なった設定パターンを複数作り、微調整をしつつ全員で実際に操作して決めていきました。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:両社でプレイして悩みながら「操作していて気持ちいい」設定を探していきましたよね。[/su_column][/su_row]

――エレメント(※1)吸収中はずっとトリガーを押しっぱなし(※2)だと思っていました。

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

渡邉:おっ!そっちの操作のほうが良かったかもしれませんね。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:いや~、そこは迷ったんです……。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

渡邉:開発の段階でその操作感は試したような気がします。なんでボツになったんでしたっけ?[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:(押しっぱなしだと)単純に指が疲れると思います。エレメントの吸収も、当初のアイデアだと他の属性も同時にワンドにストックできて、属性を選んで自由に使えるようにしてたので、その時の名残かも……。[/su_column][/su_row]

操作を含めたワンドのグラフィック案は、かなりのパターンが考えられたようです。
 

編集部注釈(※1)エレメントとはゲーム内の謎解きに使用する各属性のエネルギーで、点在する属性ブロックからワンド(杖)に吸収して発射することでギミックを作動できます。

編集部注釈(※2)本来はエレメント吸収後にトリガーを離しても大丈夫。もう一度押し込むと発射します。

――プレイ中の「疲れ」に関する調整はありますか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:そんなに疲れは気にせず、遊べるようになっています。ギミックが出現するタイミング、エルとの会話シーンなど、ゲームのテンポ感も考えています。チャプターを細分化してバランスを取れば、たくさんの謎を組み込むことができると思います。[/su_column][/su_row]

――エルのボイス実装で、UI/UXにおける影響はありましたか?

ゲーム中は彼女がナビゲートをしてくれます。たまに謎解きのヒントを話すことも
ゴシック&クールな雰囲気が漂う、エルの初期デザインアイデアの一部です。
 

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:VRではゲーム説明やルール解説を担う「チュートリアル」や「ガイド」の表現が難しく、いきなりメニューが表示されてしまうと、一気に興ざめする恐れがあります。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:突然宙に浮いてきた文字はなんなんだ、って。せっかく仮想空間で楽しんでいたのに、急に現実に引き戻されてしまう感覚です。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:そこで、エルにボイスを追加し、要所要所で会話をさせるナビゲート役にすることで、チュートリアルなどを組み込まなくても、基本的な操作などを学べるようにしました。

さらに、謎解きのヒントを語らせたり、単純にプレイヤーとコミュニケーションを取るなど、使い方のバリエーションも増えたので、UIの開発はほとんど必要なくなりましたね。[/su_column][/su_row]

Unityでは可能、しかしVRでは苦手な「水の表現」

――技術的にボツになったものはありますか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:VRでは、水の表現が難しいのです。VRは立体視なので、水の屈折を左右両目用に別々にレンダリングする必要がありますが、謎解きやギミックで広範囲に水が出てきたら確実にフレーム落ちします。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:ゲーム内に出てくるエレメントが火・風・土だけで「水」が出てこなかったのは、こういった理由でもあります。実は、火+水で水蒸気になる、火+火で爆発が大きくなる、みたいな夢が詰まったアイデアもたくさんあったんですよ![/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:正攻法で作るだけだと、かなり厳しいですね。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:どうしても実装できずに外した機能はあります。ただ、現時点で限られた期間内で作るのは無理だと判断しただけで、今後グラフィックカードが進化したり、ゲームエンジンが発達すれば実装できる機能もあるはずです。[/su_column][/su_row]

――他にUnityでは可能で、VRでは表現しにくいものってあります?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:粉じんや霧などは難しいですね。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:通常の3Dゲームでも炎や霧、煙など自然現象の複雑な動き、光の屈折などで処理は重くなるのですが、VRになるとそれを複数同時に描画しているので、さらに重くなる傾向があります。[/su_column][/su_row]

――ギミックの爆発やシールドの表現はダイナミックでしたよ!

 

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:爆発には、ちょっとしたテクニックを使っています。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

渡邉:でも、燃えている炎など、VR空間でじっくり見ると怪しい箇所がわかるかもしれません。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:当初は「木を火で燃やす」などの複雑なギミックも考えていたんですが、残念ながら実装していません。[/su_column][/su_row]

――VRでの表現の限界を考えてギミックも変更していくんですね。

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:はい。もちろん開発期間もふまえて考えています。研究開発をもっと進められるようなら、今後最新技術も試してみたいですね。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:ただ、表現の開発だけに注力するわけにもいかないので、全体の進捗バランスやトータルコストも考えています。[/su_column][/su_row]

イメージしたものをイメージ通りに作れた喜び

――開発が進むにつれて、仕様はどのように変化していきましたか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:VRで3D酔いしないようにするため、開発途中で、移動の仕様を変更したことがありました。一度VRで酔った経験をしてしまうと、次は絶対に遊ぶのがイヤになります。それは避けたくて、移動方式を根本から見直しました。また、移動関連の仕様の変更で、世界観の見せ方もだんだんと変わっていきました。[/su_column][/su_row]

――本作の開発を通して、これまでにない「得たもの」を教えてください。

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:VRに関しては、資料で学んだり他のVRゲームをプレイしたときに得た推論の答え合わせができたことが、ひとつの成果だと感じています。

サウンドに関しては他のゲームを作る際とあまり大差なかったため、こだわったのは立体音響の部分くらいです。イメージしていたものが、イメージ通りに作れているのが何より嬉しいことです。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

渡邉:やはりVRではボイスの存在が大きいと感じました。ボイスがなかったときは、エルの存在が空気になってましたが、永田さんが書いたセリフをエルが場面ごとに話すようになってから、プレゼンスがグッと上がりましたね。[/su_column][/su_row]

――VRゲームの研究開発を続ける中で、技術的にも成長し、両社のこだわりが詰まった作品に昇華していったようですね。本日はありがとうございました。

 



R&Dを目的としてスタートしたVR『VoxEl(ボクセル)』プロジェクト。試行錯誤を繰り返しながら、技術的に数多くの「学び」を得たことを感じられるインタビューとなりました。本研究の成果がDeNAの他の事業にも生かされていく可能性があるかもしれませんね。

※本作はプロトタイプのため、今後の販売や配信などは一切未定となっています。

※本記事は2018年12月時点での情報です。

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

GeNOM(ゲノム)とは

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

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

[/su_note]

【イベントレポ】DeNA×サイバーエージェントのエンジニア合同勉強会に潜入!

初の試みとなった”若手エンジニアが主役の勉強会”

2018年10月29日、東京・グラスシティ渋谷にて、DeNAとサイバーエージェントの二社合同でゲーム開発・運用技術に関するクローズド勉強会&交流会が開催されました。

コンセプトは「若手のエンジニアが発表しやすい勉強会」。DeNAとサイバーエージェントのエンジニアが2名ずつ、それぞれ約15分ほどのプレゼンテーションを実施、40名を超える参加者の中には、若いエンジニアが多く見られました。

この勉強会は、5月7~9日に開催された「Unite Tokyo 2018」の懇親会の会場で両社のエンジニアが知り合い、その際に「一緒に勉強会したら面白そうだね!」といった話がきっかけで、実現されたとのことです。

ちなみに両社のエンジニアとも、普段から他社とのコミュニケーションを積極的に取っており、今後もさまざまな勉強会や、気軽に参加できるカジュアルな交流イベントなどを企画・予定しているようです。

まずはDeNAセッションからスタート

「3DアクションゲームにおけるUnity2018アップデート対応」

太田垣八雲氏

登壇者:ゲームエンジニア 太田垣八雲

機能開発・周辺環境整備を担うエンジニアの太田垣八雲から、現在サービス中の共闘型3Dアクションゲームを題材に、Unity2018のアップデート対応について発表されました。

ブラックボックスとされていた箇所に対して、拡張に開かれたAPI/構造に変更してオープン化することをテーマとし、それに伴う新機能やアップデート、バグ修正対応などに関しての詳細が紹介されています。

「開発基盤部のおしごと~開発を支える技術~」

関慎太郎氏

登壇者:開発基盤エンジニア 関慎太郎

ゲーム事業を横断的にサポートする、開発基盤エンジニアの関慎太郎より、ゲーム開発を支えるためにどんな取り組みをしているのか、共通コンポーネントの提供と、開発力・運営力を促進するための活動といった、2つのテーマで発表されました。

以前までの開発基盤部の体制や、関係性の遷移イメージ、実際の事例を使って原因と改善の方法などを詳しく紹介しています。

続いて、サイバーエージェントセッション

「バトルアクションをもっと見やすく!~ロックオンのカメラワーク研究~」

川辺兼嗣氏

登壇者:グレンジ プログラマー 川辺兼嗣氏

サイバーエージェントグループのグレンジが2019年に配信予定の新作『Kick-Flight』を題材に、プログラマーの川辺兼嗣氏がカメラについての研究結果を共有しました。

川辺氏は現在、バトルアクション・FPS&TPS、アスレチックアクションの3ジャンルのカメラを研究しており、プレイヤーがより遊びやすく、ロックオン中の敵が見やすい位置関係の微調整など、自身が生み出した理論を公開しました。

「『リンクスリングス』におけるZenjectの活用事例」

二宮章太氏

登壇者:サムザップ 二宮章太氏

同じくサイバーエージェントグループのサムザップが2019年に配信予定のスマホ向け新作タイトル『リンクスリングス』について、二宮章太氏がZenjectの活用事例を紹介しました。

Zenjectの概要から基本的な使用方法、「参照の受け渡しの楽さ」「開発用環境の構築の簡単さ」などさまざまな利用シーンでの対応法や、注意する点などを具体的に紹介しました。

※Zenjectとは、オープンソースのUnity向けDI(Dependency Injection)フレームワークのこと。

情報交換で盛り上がる交流会

プレゼンテーション後は、お寿司&ドリンクが用意された交流会が実施され、登壇者と参加者が親睦を深めました。

今回は、二社の関連社員のみ参加が可能なクローズド勉強会のため、残念ながら一般の参加はできませんでしたが、このような複数の企業を横断しての、若手メインとなる勉強会は定期的に開催予定とのことです。

 

Copyright(C)DeNA Co., Ltd. All rights reserved.
Copyright(C)CyberAgent, Inc.

※本記事は2018年10月時点での情報です。