【ナカノヒトTalk #003:データエンジニア岩尾一優】自分に、そしてメンバーにいつも正直であること。プライベートでは子育てに奮闘中!

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

今回の「ナカノヒトTalk #003」では、分析部データエンジニアリンググループのマネージャーとして活躍する岩尾一優にインタビュー。

マネージャーを務めながら採用活動にも積極的に取り組んでおり、岩尾との面接が決め手で入社を決めたメンバーも多いのだそう。そこで、彼のコミュニケーション能力の秘密に迫りながら、普段の働き方で心がけていることや、プライベートの過ごし方についても、根掘り葉掘り聞いてきました。

全社横断の分析組織を兼務

――本日はよろしくお願いします! それでは最初に、最近のお仕事について教えてください。

こちらこそ、よろしくお願いします。まず、仕事面で最近大きく変化があったのは、全社の機能を支えるシステム本部の分析推進部と兼務になったことですね。これまでと同じく、楽しく業務をしながらも、考えなければいけないことも増えました。

特に、これまでゲーム事業部の中で行ってきた分析業務の効率化・高度化を全社にいかに伝播していくかなど、どうやって全社のデータ活用水準を高めていくかを考える機会が増えたかな、と思います。

また、全社内でオンプレミスで動いている機能を、すべてクラウドに移行するプロジェクトに関わっていることは自分にとって、大きなチャレンジです。

※オンプレミス:企業などが情報システムの設備を自社で保有、運用すること。

オンプレミスに強みをもつDeNAはなぜクラウド化を決めたのか? その舞台裏と今後の展望

今回のクラウド移行は、全社的にも大規模なプロジェクトで難易度も高く、分析部のデータエンジニアリンググループが環境移行を担当する部分も大きいんです。

新たなインフラ部分は専門部署が用意してくれますが、その他にもデータ移行やデータパイプラインの移行など、本来のアナリストのスキルセットとはかけ離れた技術も必要とされるので、データエンジニアとして、手厚く介入するようにしています。

面接では一緒に働くことを強くイメージ

――それでは本題なんですが、最近は面接官としても大活躍されているという噂を耳にしたんですが……!?

そうなんですか!? 自分がまず面接のときに重要視するのは「自分と働きたいと思ってほしい」ということです。

候補者の方は、DeNAだけでなく複数の会社を受けているはずですし、自分が「ぜひ入社して欲しい」と思えるような方は、他社でも必要とされる人材だと思うので、多くの会社の中から自分(DeNA)を選んでもらえるように意識しています。

そのためにも、面接の前準備については、事前に共有されるレジュメ(履歴書/経歴書)も丁寧に読み込みながら、どの部分を深く質問していくかなど、ある程度シナリオを考えています。

――面接時の会話で心がけていることなどありますか?

その人の特化した部分を探すようにしています。エンジニアリングに強みを持っている方には、アーキテクチャ設計図をホワイトボードに描いてもらうなどした上で「この部分、こういう設計も考えられますが、どうしてこの設計を選択したのでしょうか?」というような聞き方をするなど、ディスカッションに近い面接をしています。

また、ビジネスマンとして動くのが得意な人は、システム構築だけでなく、当時の導入や展開について話してくれる傾向が強いので、社内でどんな摩擦が起きたかなど、苦労した部分の質問に切り替えるときもあります。

――面接ではどの点を重視されているのでしょうか?

まず、DeNAという会社の文化にマッチできるのかを考えます。具体的には、DeNAの行動指針であるDQ(DeNA Quality)を理解・体現できることがマストだと思っています。そして、課題解決に関する質問に対しての「回答の目線の高さ」で差がつくこともありますね。

※DQ(DeNA Quality):チームとして最大限のパフォーマンスを発揮するために掲げられた、全社員に必要な共通の姿勢や意識(「こと」に向かう・全力コミット・2ランクアップ・透明性・発言責任)

また、課題にぶつかったときに「上司に報告して終わり」ではなく、メンバーを巻き込んだり、解決するためのプロトタイプを作って提案するなど、未来を見据えて動ける人は強いと思いますよ。

――チームメンバーとの相性の組み合わせも考慮しますか?

もちろん。最近入社が決まったメンバーは、バランス感覚に優れてどっしりと構えるタイプの人で、これまでチームにいなかったタイプです。サッカーで例えるとセンターバックやキーパーのような役割を期待しています。

ちなみに、よくチーム編成について話す時に「そういえばこのチームって、キーパーいないよね」というようにサッカーのポジション、フォーメーションに例えて話すことが多いんですよ(笑)。

――過去に出演したインタビュー記事の反響についてはどうですか?

紹介した記事を読み込んで来てくれている方も多いです。ありがたいことに、これから入社する方も自分の記事を読んでくれていたそうです。最近では逆に、こちらから私の登場している記事を事前に紹介し、一定の理解をしていただいた上で面接に臨んでいただくこともあります。

【DeNA分析部特集Vol.3】データエンジニアリンググループ発足の狙いとは?MLOps導入や新技術によるコスト削減などで事業貢献を目指す

また、両親には自分が載った記事を必ず報告しています。親は「有名人になっちゃって!」と無条件に喜んでくれていますね(笑)。

あとこれは余談ですが、某BIツールの会社から「GeNOMの記事見ました!」と連絡を受け、実際に社内のデータ活用水準を高めるためにそのツールを導入して、一緒にPoCを始めようと考えています。それを考えると、記事の反響も大きく、少しずつ活用ができていると思いますね。

自分に、そしてメンバーに常に正直であれ

――マネージャーとして、普段からメンバーとのコミュニケーションで心がけていることはありますか?

常に、自分の意見を正直に話すことを心がけています。多少の議論に発展して、仮にちょっと気まずい雰囲気になったとしても、自分の考えとその理由は率直に、相手が誰であろうと伝えるようにしています。

また、メンバーへの期待レベルについては、当人と入念にすり合わせていて、チームがどう成長していくべきか、大きなビジョンと整合して、本人のWILLと合致させることを徹底しています。

現在はチームが拡大フェーズに入っており、自分がすべてをチェックすることができないため、間接マネジメントをしないと、組織も発展していかないと感じています。メンバー自身が、誰とどのような調整をして進めていくのかを考えて、自走してほしいですね。

――グループの課題はありますか?

今期はPM(プロジェクトマネージャー)的なスキルが足りていないと感じています。技術的には長けているメンバーは多いのですが、全体を俯瞰して見て、適切に優先順位をつけることができれば、もっと広範囲を任せることができますね。

スキルレベルは明確に数値化できるわけではないので、どんな行動や習慣ができているか、など可視化できる部分と、未来像を定義しながら1on1でフォローアップしています。

あとは、暇を見つけてコーヒーブレイクをしていますね。自分がメンバーに対して何でも言えるのは、日頃から仲良くて、仕事のことだけじゃなく、家族やプライベートなことを話しているからなんです。周囲には先輩メンバーもいますが、気軽に言い合える関係を築けています。

社内外のイベントにも積極的に登壇

――Google Cloud Nextにも登壇されましたね!

はい。おかげさまで500名ほどの会場が満席でした。最初は大きい会場をアサインされたので、不安でしたが、練習の甲斐もあり、無事に乗り切ることができました。応援にかけつけてくれたメンバーもいて大変心強かったです。

――岩尾さんって、緊張します? 「TechCon2019」でも堂々とプレゼンをしていた印象が。

もちろん、しますよ(笑)。始まってしまえば平気なんですが、登壇直前が一番緊張します。とにかく練習をしまくって、チームメンバーに参加者役をしてもらって裏で何度もリハーサルしていました。「DeNA TechCon 2019」のときは、空いていたセミナールームでギリギリまで練習していました(笑)。

プレゼンでは、バックグラウンドが違う人にどう伝えるか、そもそも誰に向けて伝えるのかを考えて、資料を何度も修正し、実際にしゃべりながら細かくチューニングしていますね。

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

――普段から仕事の効率やメンタル面のコントロールでやっていることはありますか?

朝の時間を使って、最優先でやることを集中して作業するようにしています。昼過ぎからはランチを外で食べつつ、ちょっと社内をウロウロして考え事をしたりしますね。個人的に仕事にコーヒーは欠かせません。

忙しい中でも、人と話すことが気分転換にもなりますし、気軽に課題を話しているうちに解決の糸口が見つかることもあるので、個人的にメンタル面を大きく崩すことはないですね。怒ることもほとんどないですよ。

2人の娘の子育て真っ最中!

――最後に、プライベートについて教えてください。

3歳と0歳の娘がいます。平日の日中は妻が見てくれているのですが、それでも毎日大変です(笑)。特に上の子は活発で、休みの日はほとんど外に連れて行って遊んでいます。

でも、外でたっぷり遊んで帰ってきても全然お昼寝してくれなくて、室内でジャングルジムやトランポリンで遊ばせています。お父さんの体力はいつもゼロに近いです……(笑)。

また、最近ではひらがなや数字などの勉強もはじめました。基本は横に座って教えているのですが、ほうっておくと、教えてない他のページの問題を解いてたり、大人が思っているより、成長が早いので驚きますよ。

――もちろん、まだゲームに興味はないですよね?

さすがにまだゲームは遊ばせてないですが、映像配信の画面にあるリモコン操作を覚えて使っているのを見かけました(笑)。

最近は活発な上の子にかかりっきりなんで、まだ小さな下の子はおとなしくて、ちょっとかわいがるとニッコリ笑ってくれるんです。子どもたちは本当に癒やしの存在ですね。

――家庭では良きパパのようですね。今日はありがとうございました!

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

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

GeNOM(ゲノム)とは

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

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

[/su_note]

【DeNA分析部特集Vol.3】データエンジニアリンググループ発足の狙いとは?MLOps導入や新技術によるコスト削減などで事業貢献を目指す

DeNAが運営するゲームはプロデューサーやディレクター、プランナーなど様々な職種によって支えられていますが、分析の役割もゲームの開発・運営にとって重要な存在と言えます。

今回は、分析部内に新たに組織されたデータエンジニアリンググループにスポットを当て、同グループ発起人である岩尾一優と、前回に続いて吉川正晃にインタビューを実施。

データエンジニアリンググループ立ち上げの背景や目的、DeNAの中でデータエンジニアとしてどのように貢献しているかなど語っていただきました。

データエンジニアリンググループ立ち上げの背景

――まずはこれまでの経歴についてお聞かせください。

岩尾一優(以下、岩尾 私は昨年7月にDeNAに入社しました。それまでは富士ゼロックスでコンビニのネットプリントサービスのアーキテクト設計を担当していました。前職でもデータ分析基盤の立ち上げをしていたことがあって、DeNAに入ってからはデータエンジニア担当として、主に分析の効率化や高度化を推進するようなことをやっています。

2月からデータエンジニアリンググループを立ち上げ、マネジメントも担当しています。

吉川正晃(以下、吉川 DeNAには7年間在籍していて、最初の4年間はセキュリティー技術、その後3年間は分析を担当し、直近1年は分析グループのマネジメントに力を入れています。岩尾さんが入社当時は、私のグループに在籍していたんですよ。

――岩尾さんは2018年7月の入社から半年が経ちましたが、DeNAの印象はいかがですか?

岩尾: エンジニア天国という印象です(笑)。PCや椅子など、職場環境が良いと感じています。社風も良い意味で自由な所があり、自分でパフォーマンスをコントロールしやすい職場だと感じています。

――ゲーム業界外から転職された岩尾さんは元々ゲームがお好きだったんですか? また分析部の皆さんは普段からゲームをプレイされているのでしょうか。

岩尾: ゲームは小さい頃から遊んでいます。コンソールではRPGや洋ゲーが好きでプレイしています。スマホでは『メギド72』をプレイしていますよ。

吉川: 僕はかなりやりますね。最近はコンソールはあまりやっていないんですが、普段からスマホゲームは他社さんのアプリも含めてやっています。その他のメンバーもゲーム好きが多いです。

――分析部に新たに組織されたデータエンジニアリンググループですが、どのような背景で立ち上がったのでしょうか。

岩尾: 私が入社する以前から、DeNAはデータ分析費用にかなりの金額がかかっていたことが背景としてあります。入社後、それって本当に必要な額になのか調べたところ、いろいろ改善の余地があることがわかってきました。

その中で、コスト最適化もそうですし、コードの保守性や一部業務の属人化など、エンジニアリング周辺で、色々と課題があると感じていて。その度に上長だった吉川さんに相談したり、1on1の場で改善の提案をしてきました。

そして実際に改善に力を入れ始めてみると、目に見えてコスト削減ができ、本格的に1度本来のあるべき役割や何をやるべきかを整理して、組織化することでそこの部分を改善していこうと考えました。

吉川: そもそも分析部としてコスト管理の部分がしっかり定義されないまま運用していた部分も正直ありました。分析部として、コスト改善をしっかりやっていこうというフェーズになっていたところに、ちょうど岩尾さんの入社が重なったんです。

そこからコスト削減という活動が目に見えて実績として生まれてきて、それを推進してくれる岩尾さんに組織を立ち上げてもらいました。

――吉川さん自身も以前からコスト削減は課題として感じていたんですか。

吉川: 正直に言うと、一番の課題とは思っていませんでした。恥ずかしながら、できるメンバーが対応している体制だったので、まさに属人化の状態でした。

分析部の元々のミッションであるデータ基盤を安定的に運用するところは、あくまでもミッション達成の一過程でしかないという考えで組織で取り組む優先度を下げていましたが、今後クラウドにシフトしていくことを踏まえ、優先度を上げていかなければならないということで認識を改めました。

岩尾: これはエンジニアのあるある話ですが、事業に向けた開発や作業は優先されるけど、保守や改善がどうしてもおろそかになりがちなんです。それを放置しておくと、ある時に何かちょっとした変更をするにしても、どこに影響が出るかわからないという状況に陥ってしまいます。

そうなる前に一度、保守や改善をすることで事業開発の工数を削減できれば、全体のキャパも上がっていくと考えて今回取り組みました。

吉川: そうなった背景としては、元々分析部のミッションが事業の最重要課題を抽出して解決することで事業に貢献するというところにフォーカスされていて、スピード感を持って取り組むことを優先している文化にあります。

事業の意思決定に必要な動きを優先してしまっていたことは反省しています。ただ、人員が足りずどうしようもなかったことも事実です。そこで岩尾さんに入社していただき、魅力的な提案もあって、一気に動きが加速できた、ということで非常に感謝しています。

――データエンジニアリンググループ立ち上げの実現に向けて、実際にどのようなことをされましたか?

岩尾: まず足りていない役割、あるべき役割を設定しました。例えばGoogleやAmazonのデータエンジニアが何を持っているのかを調べて、我々ができているところ、できていないところを見つめ直しました。

できていない部分は保守もそうですが、ML系とかシステムに載せていくという所が分析部としてちょっと弱いと感じたので、週次でマネージャー陣とレビューなどを行いました。次にミッションについて、もうちょっと短期の目標からどうすべきかを壁打ちしながら磨いていきました。

吉川: その過程で、実際に今の分析部と将来の分析部にどれくらいのエンジニア力を持った人材が必要なのかも含めて、設計してもらったのはかなり大きかったです。

――実際に昨年7月に入社して組織立ち上げを相談したタイミングは?

岩尾: 入社して3ヶ月後の10月です。コスト削減の成果がだいぶ出ていたくらいの時期でした。

吉川: その成果は誰が見てもすぐわかるもので衝撃的でした。かなり早い段階から岩尾さんの力が発揮されていたのも、データエンジニアの組織化に向けた意思決定のスピードにつながったと思います。

新たな技術を使った挑戦

――現在データエンジニアリンググループで取り組んでいることについて教えてください。

岩尾: 1つはMLOpsの導入です。機械学習って、例えばデータサイエンティストがデータ分析して、マーケティングや事業部に分析結果を説明して、理解を得てプロジェクトにつなげていくことがあると思います。ただ、事業部の立場からすると、朝出社したら分析データの計算が終わったものを確認できるという状態が一番理想的ではないでしょうか。

MLOpsはそれをシステム化するということなんですが、そこまではまだできていない状況です。一部ゲームにはAIが組み込まれていますが、ゲームの機能としてではなく、分析を目的としたMLのシステム化みたいな部分はまだできていなかったので、そこは我々データエンジニアリンググループの役割と考え注力しています。

今は全てのモデルで動いているわけではないですが、一部のモデルで導入して動かしているという状態で、これからどんどん載せ替えていくところを本格化させていきます。

――MLOps導入は、分析の工数を削減することが目的なんですか?

岩尾: 主な目的として、「工数の削減」と「機械学習について高い専門性のない人でも使えるようにすること」があげられます。

特に後者はシステム化することでハードルがグッと下がります。機械学習って、はじめの環境構築が難しくて、知識も必要になってきます。高い専門性も必要であるため機械学習モデルを作れる人ってどうしても限られるんですが、それを配布して誰でも使えるようにする、という仕組みを作ることでハードルを下げて、専門知識がないアナリストでも使えるようにしようと考えています。

――そのMLOps導入で苦労されていることはありますか。

岩尾: 苦労としては、DeNAは色々なサービスを運営している会社なので、それらにどう伝播させていくかを前提として考えているというところが大きいです。

単一のサービスであればそれに特化したシステムを作れば良いですが、我々は複数のサービスを走らせているので、そこに適用できる形のシステムがどうあるべきか考える必要があります。

吉川: そこのハードルはかなり高いかなと思いますが、それを乗り越えて実現できたときの効果は絶大だと思います。

――MLOpsのほかに、新しい技術を使った取り組みや事例はありますか?

岩尾: Googleのクラウド系はシステムアップデートが結構頻繁に行われるので、そういうところをウォッチしながら取り入れるものは随時ピックアップするようにしています。

BigQueryというデータ分析基盤では、それ1つとっても新しい機能が毎月のように出ているので、β版からどんどん検証して、我々にとって良いなと思えるものならβ版であっても導入するくらいのスピード感でやっていきたいと思っています。

――今後データエンジニアリンググループとして取り組んでいこう、進めていこうと考えていることはありますか?

吉川: アイデアベースですが、機械学習が増えていくことにより、一人ひとりのプレイヤーにフォーカスすることや、カスタマイズした分析が今後は必要になってくるというところで、データウェアハウスそのものもプレイヤー単位で持てるのが理想だと考えています。

岩尾: あとはクラウド移行ですね。これは全社の意向もありつつですが、元々物理のサーバーを使って大きなサーバーストレージを使いながらやっているんですが、それをすべてGoogleであったりAWSのサービスに載せて、クラウドで管理するように分析基盤も移管する予定です。

GCPやAWSにシステムが集約されることで、GoogleやAWSが新しく機能を出したときに、我々もすぐにキャッチアップできる体制が常にできているという状態が実現できますし、コスト削減の面でも物理サーバーを持つよりも、より安価にデータ分析の環境を維持できます。その部分に対して遅れを取らないような体制を今後作っていきたいです。

――新しい機能が出たときの技術のキャッチアップについて、具体的にどのようなことをしているんですか?

岩尾: Google社の方と頻繁にお会いして話をしています。手を動かしてみると設計段階の構想と違うと感じることがあったので、そういうところは積極的に聞いています。

あとは我々自身も国内外のカンファレンスに参加して、世界の事例を見て良い所は取り入れるようにしています。先日もラスベガスで開催された「AWS re:Invent」に参加しました。どんなことが行われているかとか、我々がやろうとしていることは世間と比べてどのくらいのレベルなのか、ということを認識することも欠かさないようにしています。

――技術をキャッチアップしつつ、今後は分析基盤のクラウド移管をしていくということですが、結構大変な作業になるのでしょうか?

岩尾: かなり大変ですね。BigQueryに載っていないものがまだまだあって、それを全て載せ替えようということになります。関連するドキュメントの書き直しや、あるいは我々で取捨選択をして必要ないものをちゃんと伝えてあげて、アナリストに影響のないような形でなるべく本業に集中できる形のデータ基盤の移管を進めていかなければなりません。

「この業務って本当にまだ必要?」「意味があるんだっけ?」という業務の棚卸をして、最適なシステムをもう1回組むということはやりたいと考えています。

――アナリストへの影響なども考慮して移管を進める必要があると。ところで岩尾さんはアナリストとどのように連携して仕事をしているんでしょうか。

岩尾: DeNAは、分析部内にアナリスト、リサーチャー、サイエンティスト、エンジニアがいるところが強みかなと思っています。データエンジニアって開発側に属している会社が多いと思いますが、我々はビジネス部門である分析部の中にいます。だからこそゲームのドメイン知識も持っているので、そういったことを活かしつつエンジニアリングを発揮できる良い体制になっています。

その中でアナリストとの連携の仕方は色々ありますが、例えばゲーム内でイベント用の分析が必要になったときに、どういうデータの持ち方をすると最も効率的かという所をアドバイスしたりします。

吉川: 同じような作業を繰り返しているチームの相談もあって、そこの効率化など横断的にデータ基盤を見る機会が多いので、我々からのインプットをアナリスト全員にシェアしていくという動き方がメインですね。

岩尾: あとアナリストやカスタマーサポートの方は、結構SQLをたたけるんですけど、その際に良いSQLと最適ではないSQLがあるんです。BigQueryは何ギガ、何テラ検索したかで料金が発生する従量課金が特徴としてあるので、やはり最適にQueryを書く必要があります。

ですから、そこで最適ではないQueryを書いてしまったときに、slackで通知してわかるようになっていて、みんなでこのQueryはどこが悪かったか議論できるようにしています。

DeNAは失敗を活かす文化があるので、我々はデータエンジニアリンググループとして最適でないQueryが発行されてしまったときにslackに通知するシステムを裏で開発して、要は気付きを与えてみんなで改善していく狙いで実施しています。

もちろん、何ギガ以上のQueryを投げたらシステム的にガードすることもできるんですが、それをやってしまうととメンバーを信頼していないと感じられてしまいますし、本当に必要なQueryだった場合に実行してエラーだったらストレスにもなると思います。

それよりも、仮に失敗したとしてもみんなで改善していったほうが学びにもなるし、長期的に見ても良い組織になるのではないかという理由でそのようなアプローチを続けています。

吉川: データエンジニアリンググループは単純なティーチングだけでなく、コーチングも組織として取り組んでいるんです。

岩尾: それって同じ部内にエンジニアもアナリストも一緒にいて、お互いに信頼関係があるからできることだと思います。

アナリストから「こういう分析がしたいんだけど、今のテーブル構成ではどうしても1回で1テラ以上検索してしまってお金がかかってしまう」と相談を受けたときには、そのテーブル設計を見てアナリスト側からの要求を受けて「テーブル構成を効率化しましょう」という働きもあります。お互いに意見を出し合って最適化を目指している組織ですね。

働きやすく挑戦しやすい環境

――データエンジニアリンググループはまだ立ち上げ期ですが、業務的に大変ではないですか?

岩尾: そこは皆ちゃんと定時に帰れています(笑)。というのも仕事の優先順位をしっかりつけているので、普通に19時には帰宅できます。あと私事ですが、先日2人目の子どもが生まれたんです。最近、分析部自体もベビーラッシュで、私に限らずみんな早く帰っていますね。

吉川: 手分けしてちゃんと仕事ができていると思います。今はグループと各メンバーのタスクを管理していて、1人に負荷がかかったり、チーム全体で負荷が高くなるという状況がなるべくないような状態を維持しています。

岩尾: あとは重要かつ緊急の仕事を持たないように意識することが大切です。緊急だけど「それって本当に緊急なのか?」を考え、そこまで実は緊急じゃない案件についてはスケジュールをきちんと引き直すなどの工夫をしながら仕事をしているので、残業はほとんどありません。

我々は本質的に重要なことに集中したいと思っていて、そうできるようにがんばっています。この2ヶ月くらいでタスクすべてを棚卸して、優先順位を付け直し、さらに優先順位を付けるためのルールも作成してみんなで作業しています。

吉川: また、関係している部署に対しては定例などをしっかりと設けて、その仕事が重要なのかどうかをタスクが発生する前に事前にキャッチできるような関係値を作り、重要な仕事は緊急になる前に依頼してもらうようなリマインドができる体制になっています。

岩尾: これは前職から気をつけていたことですが、エンジニアって仕事ばかりしているとそればかりになってしまうんです。だらだら仕事するよりも切り替えて、早く帰って勉強したり、最近のトレンドをキャッチアップしたり。もちろんリフレッシュしたりと、そのほうが全然良いと思っています。我々の職種は知識をアップデートしないといけないのでそこは意識しています。

――コスト最適化に向けた組織化の提案が、入社後半年で実現したという事例は面白いですね。

吉川: しっかりとした目的を持ってロジカルに提案すれば、きちんと受け止めてくれるというところはDeNAらしさなのかなと思います。

岩尾: そうですね。あとは提案していく中でも逆風みたいなものはなくて、そこはやはり皆ぼんやりとした課題感はあったと思います。

それを言語化できて論理的に説明できれば、部長やマネージャー陣も含め、むしろ全員でそのロジックを詰めていくみたいな流れが生まれて、意思決定も立ち上げもかなり早かったですね。

吉川: 課題の提案がすごく前向きだったところも大きな要因で、これはイケてないと思うんです……で止まる提案と、イケてない……だからこうしたい!という提案は全然違うなと感じました。岩尾さんは後者の提案だったので、もし提案を100%実現できなかったとしても組織として前進できる内容だったので、すごく良い提案をしてくれたなとうれしく思いました。

岩尾: 個人的に常に意識しているのは、ちょっとでも良いから成果を出して、これが完成したときのイメージの解像度を上げるという所。できるだけ不確実性を下げた状態で提案できるように意識しています。

――:データエンジニアリンググループは、コスト削減などの保守的な部分と、MLOpsのような改善の部分、攻守のバランスが絶妙だなと感じました。

岩尾: ゲーム中の用語に例えると、当初から「攻撃力」「防御力」という表現をしていて、その部分は意識しています。メンバーと関わる中でも、この人はこの領域をやるのが好きなんだなとか、それぞれの価値観というものがあって。コスト削減が得意な人もいれば、MLOpsのような新しい技術に触れたいという人もいるので、各メンバーがやりたいことも意識して、全体を組み立てるようにしています。

――:今後、データエンジニアリンググループではどんな人材を求めていくのでしょうか?

岩尾: 個人的には、アーキテクチャ設計ができる人が良いかなと思っています。ビジネス要件をどうやって技術に落とし込むかを噛み砕ける人といったところでしょうか。

もちろんビジネス要件自体も我々エンジニアは意識する必要はあると思いますが、それを技術に落とすとき世の中にはいろいろな選択肢があります。それらを広く知って比較して、チョイスしたものがどういう理由で最適なのか論理的に説明できる人が理想ですね。あと、できればゲームに興味があれば(笑)。

吉川: 今は立ち上げ期で、課題や新しい取り組みがたくさんあります。そこを一緒になって動いて埋めてくれるような、特に岩尾さんと並走できるシニアの方にはおもしろいと思います。

岩尾: そうですね。課題自体も、自分自身で発見して実装できるのが理想的。それから組織を立ち上げていきたいという野望を持っている方も適任なんじゃないかなと思います。DeNAは自分の力を伸び伸び発揮できる環境だと思っているので、自分の経験をもっと発揮したい人には向いている気がします。

★あわせて読みたい
【後編】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ゲーム事業におけるデータエンジニアの貢献」と題したセッションの後編をレポートします。

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

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]