【データサイエンスの競技者”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]

TechCon2018ゲーム系登壇まとめてみた!〜ひとこと感想付き〜

2月7日(水)に大盛況のうちに幕を下ろしたDeNA TechCon2018。今回はTechCon2018のレポートとして、ゲームに関連する登壇の資料をまとめました!
当日登壇を聞いたDeNAメンバーによる感想メモ付きなので、「全部見るのはちょっと時間ない!」という方は、メモを参考にしつつ興味のある資料をチェックしてみて下さい。

尚、TechCon2018の全登壇分の資料はTechCon公式サイトにアップされています。合わせてご覧ください。
※公開不可の資料は掲載しておりません。ご了承ください。

 

【『逆転オセロニア』における運用効率化支援〜デッキログのデータマイニング〜】

田中 一樹(システム&デザイン本部AIシステム部AI研究開発グループ)

▼ひとこと感想(HN:KOU/デザイナー より)

膨大なデッキログを分析して、流行のデッキ構成をリアルタイムに自動抽出・可視化するという内容。
リアルタイムにデッキの流行を把握できるので、デッキが固定化してゲームが停滞していないかなどを定量的に確認することができるということでした。
運営を続けていく上で増え続けるゲームリソースのバランスを取るのは非常に難しいことですが、こうした手法によって、感覚に頼らずユーザーの状況を把握できるのはとても有用なことだと感じます。
同じく田中による「ゲーム体験を支える強化学習もリソースのバランスをとるための取り組みの話なので、合わせて見ると面白いと思います。

 

 

【ゲーム体験を支える強化学習】

奥村 純(システム&デザイン本部AIシステム部AI研究開発グループ)
田中 一樹(システム&デザイン本部AIシステム部AI研究開発グループ)

▼ひとこと感想(HN:うに/サーバーサイドエンジニア より)
運用を長く続ければ続けるほどパラメータ調整は大変になっていき、調整にかかるコストも増加していく。そこを強化学習によって補おうという取り組みの紹介。
段階的にどのように研究開発していったのかが説明されているので、強化学習の導入を検討している人にはいいヒントになるのではないかと思います。

 

 

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

田辺 哲(ゲーム・エンターテインメント事業本部Japanリージョンゲーム事業部第二開発部技術第四グループ)

▼ひとこと感想(HN:まきえびスペシャル/アプリエンジニア より)
実際の業務に即した話であったこと、高速化のためにどういったフローを行ってきたのか、またどのように結果にコミットしたのかが簡潔かつ詳細にまとめられていて面白かったです。
聞いていて「これは業務に活かすことができるな」と感じさせられる部分も多々ありました。サンプルコードも用意されていて至れり尽くせり。
今後開発と運用を続けていく上でとても大切なテーマだと思うので、運用をやっている、かつ巨大なタイトルを担当されている方に是非見てほしい内容でした。

 


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

立浪 千尋(ゲーム・エンターテインメント事業本部Japanリージョンゲーム事業部開発基盤部第二グループ)
中本 瑞枝(ゲーム・エンターテインメント事業本部グローバル推進部タイトル推進グループ)

▼ひとこと感想(HN:うに/サーバーサイドエンジニア より)
ローカライズのワークフローや効率を改善するために作られた内製ツールの解説。
想像してた以上にローカライズチームの担当領域が多く驚きました。
ただシステム化するだけでなく、ローカライズ担当者が使いやすいようにも配慮されているので、ローカライズに限らずワークフローのシステム化を考える際に役立つ内容だと思います。
ローカライズの工程と作業者の実務についてもコンパクトにまとめらています。
多言語化において、欧州言語は英語から二次翻訳されているといった話もあり、カルチャライズも含めクオリティ管理をどうしているのか、登壇時に脱線して出た話までもっと聞きたくなりました。
こういったツールを用いることで多言語対応の低コスト化が実現すれば、業界全体の成長にも寄与するのではないでしょうか。

 

 

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

北澤 慶郎(ゲーム・エンターテインメント事業本部Japanリージョンゲーム事業部開発基盤部)

▼ひとこと感想(HN:ぬた/サーバーサイドエンジニア より)
DeNAにおけるゲーム開発の歴史、また、ネイティブゲーム開発におけるサーバーサイドエンジニアがいったいどのような役割を果たしているか、という話から、DeNA内製のオリジナルネイティブゲーム特化BaaS『Sakasho』がどのように生まれ設計されて行ったのか。
そしてその結果、DeNAのネイティブゲーム開発はどのように変わっていったのかを解説した登壇内容でした。
クライアントサイドのエンジニアが、よりクライアントの開発に注力するためにいかに工夫されているか、またネイティブゲーム開発の土台が整った今現在、『Sakasho』はどういった課題を持ち、この後どうあっていくべきか、DeNAにおけるゲーム開発をささえるサーバーサイドの熱量が伝わる熱い内容

▼北澤さんの話がもっと聞きたい方はコチラもオススメ:
【特集】ゲーム開発基盤部を大解剖!〜DeNAゲームクリエイターが開発に集中できる秘訣とは〜

 

 

【AndAppにおけるGCP活用事例】

鈴木 大介(ゲーム・エンターテインメント事業本部オープンプラットフォーム事業部システム開発部オープングループ)


▼ひとこと感想(HN:まきえびスペシャル/アプリエンジニア より)
AndApp開発の中でのGCPの活用事例を通して、AndAppがどういった成り立ちで出来たかについても知れる内容でした。普段ゲーム開発チームにおり、自社サービスながらAndAppの事をよく知らなかったので、「うちってこういうこともやってたんだな」ということを知れたよい機会でした。
本来スマホアプリはスマホでしか遊べませんが、PCでできるようになるというコンセプトはとてもいいと思います。
それらをどのようにして実現したかがよくわかる登壇でした!

 


【内製ツールを使ったチート診断・脆弱性診断】

汐田 徹也(システム&デザイン本部セキュリティ部セキュリティ技術グループ)

 

▼ひとこと感想(HN:うに/サーバーサイドエンジニア より)
DeNAでどのようにチート診断・脆弱性診断を行っているのかをタイプ別に紹介しています。攻撃者が実際どのようにチートを行うかといったデモもあるので、チート対策をする際のヒントになるところが多くあります。でもここで紹介された内容を真似してチートするのはダメです。ダメ、絶対。

 

【おまけ】

当日の様子を少しだけお届け!たくさんの方にご来場頂きました!


△メイン会場。でっかいスクリーンがどーん!

△守安によるKeynote発表の模様。DeNA創業時の写真も!

△ゲームに関する発表の会場となっていたORANGE Stage。照明がカラフルです。

△発表時の様子。PCでメモをとりながら熱心に聞き入る参加者さまで会場は満員でした。

△毎回恒例のグラフィックレコーディングも!メインステージの登壇をリアルタイムで絵に起こし、エントランス付近に掲示しています。別会場にいた方や途中から来られた方も、これを見ればどんな発表があったかがわかりますね。

△講演のあとは、毎年恒例の懇親会が開催されました。乾杯の音頭を取る執行役員システム&デザイン本部長の木村秀夫。

△かんぱ〜〜〜い!

△ベイスターズエールも振る舞われました!

△登壇者とお話したり、参加者のみなさんで交流したりと、会場内は熱気に包まれておりました!

DeNA TechCon2018、お楽しみ頂けましたでしょうか?来年はどんな内容になるのか楽しみです。
最後までお読み頂きありがとうございました!来年のTechConをお楽しみに!