ボッチだけれど CEDEC 2018 1日目潜入レポ

お久しぶりのgracetory_yamaです。

今年もCEDECに行って来ました。

弊社で1日目に行ったのは私だけだったので、気合を入れて講演内容についてまとめさせていただければと思います。

(※スライドが公開されたら追記する予定です)

ちなみにですが、去年のレポはこちら

ヘッポコだけれど CEDEC 2017(8/31) 潜入レポ - gracetory’s blog

今年の他のメンバーのレポはこちらです

CEDEC2018 2日目行ってきました。 - gracetory’s blog

はじめての「CEDEC2018」Day.2レポート - gracetory’s blog

ゲーム開発者の祭典CEDEC2018 3日目に行ってきたよレポート - gracetory’s blog

CEDECに行くといつも雨が降る(2018/3日目) - gracetory’s blog

ベトナムオフショアによるソーシャルゲーム開発・運用事例の紹介 〜15プロダクトを4年間運用して見えてきた利点と課題〜

GREVO Co., Ltd. CEO 山本 浩樹 様 / グリー株式会社 Japan Game 事業本部 Manager 桝田 清史 様

概要

• 日本とベトナムの文化の差
  • オフショアした当初はベトナムにソシャゲの文化がなく、ガチャなどの概念も通訳担当がわからない状態だった
    • セミナーとかを実施したが、結局はプレイしてもらうのが一番理解につながる。中心メンバーに広まれば、あとは伝搬して行く
  • ベトナムのITは縦割りで、例えばエンジニアはテストをしようとしない
    • これといった正解はないが、日本のやり方に合わせた。担当を超えた働きを賞賛する制度の導入
• 日本とベトナムのコミュニケーション
  • 言語は日本語を選択
  • クオリティがベトナム側のBSE(BridgeSE)依存になる
    • 確保が大変なので、育成プログラムを作成
  • グリーの仕様書がわかりづらい
    • 仕様書グランプリを開催、投票してもらう。他のタイトルでも活かせる
• ベトナムからのセキュリティ
  • グリーから見て、GREVOは外の会社だから公開できないツールもある。商用環境へのアクセスもグリー本社の人間のみ
  • 代替手段として、Jenkinsのジョブを用意して(ジョブ作成の権限は日本のみ)、そちらを操作してもらうように
    • ベトナムからも任意のタイミングで商用環境でのオペレーションが可能に
  • 本番のログはSumologicから見られるように
• 教育・評価・育成
  • ベトナム側はクライアント企業(グリー)に帰属意識があるが、実際の評価はGREVOが行う
  • ここで評価にズレが出たので、互いの評価担当者で事細かに情報共有
• オフショアすることの利点とは？
  • 定型業務委託先としてはベスト。新規開発ではプランナーとのコミュニケーションコストがあるから、ベターな選択。
  • 委託担当の人間も大きく成長
  • 将来的には既存の業務は全て委託して、新規の事業に集中したい(グリー)
• デメリット
  • ベトナム側の年収コストが上がっていく

感想

ここまで円滑に進められるようになるまでに4年かかったとのこと。

ある程度余裕がないと、オフショアをするのも危険なんじゃないかと思った次第です。

結局作業を投げるための労力や修正するための労力が必要になるので、お互いスムーズに進められるようになるまでのコストはかなりかかる気がしました。

逆に、一度スムーズに回るようになれば、ベトナム側の開発力は高いとのこと。

エンジニア不足が叫ばれる昨今ですが、安易にオフショアをするのでなく、自分の会社の都合と合わせて慎重に選択しなければならないですね。

アプリ改善を深化するデータ分析 〜現場で使えるデータを片っ端から可視化するコツ〜

株式会社 gumi Technical Strategy & Development Manager 松浦 遼 様

スライドは以下からダウンロードできます

アプリ改善を深化するデータ分析 〜現場で使えるデータを片っ端から可視化するコツ〜

概要

• SNSでの公開が禁止されていたので割愛させていただきます

感想

会場は立ち見でも埋まるほどの人気ぶりでした。

同社のゲーム「ガールズオーダー」を参考にした説明だったのですが、運営する上でどんなログを残すようにしているのかがとても参考になりました。

できるだけ細かいログを残してそこから分析を行わなければ、分析のサイクルを回せられない、といった印象でしたが、

自社のコンテンツの運営で「ヒットさせる分析」をするにはそれくらいしなきゃダメということですね。

BI(Business Intelligence)ツールの作成だけでゲーム一本作るくらいの労力をかけてもいいのかもしれません。

Vtuberのビジネスの最新動向と必要とされる技術について

株式会社スパーク/株式会社スパーククリエイティブ 代表取締役 岡村 雄一郎 様 / 株式会社CyberV 兵頭 陽 様 / 株式会社CyberV 岩﨑 謙汰 様 / 株式会社SPARK 広本 則行 様

概要

正直申し上げまして、想定していたより実践的な内容だったため、よくわかってない部分が多いですがご容赦を...

• 10代20代のVtuberの認知度は過半数を突破。全年代だと40%程度
• 認知している人の内訳：男80%:女20%
  • 逆に言うと女性向けはまだチャンスが眠っている
  • youtuber自体の認知度は、80%の女性が知っている
• 寝る前に動画を視聴する人が多い
• 中国など、日本のアニメなどのカルチャーを受け入れてくれる国では、Vtuberの受け入れも早い
• 制作
  • フルスクラッチだと期間的に厳しい、UE4は詳しい人が不足、結果的にUnity
• トラッキングはMVNとOptiTrackを使い分けている
• イベントRAGEの時に、ステージでVtuberを同時に出した時は1PCにつき1キャラ
  • サーバでキャラの同期を取り、画面に出していた
• 今後の課題
  • 声(音)しか、現実と同等の価値を持てない
  • 罰ゲームは可能になるのか

感想

会場はかなりの人気で、人が入り切らないで打ち切りになるほどでした。

講演の題名からこれからVtuberを始める人向けの講演だと勘違いしていたので、実践的な話にはついていけない部分もありました。

ただ、企業としてVtuberビジネスを行う際にどのような技術的アプローチをしているのかを聴けた点は大変興味深かったです。

企業としてVtuerを始めることは自分でメディアを持つことと同じ覚悟が必要になりそうですね。

データを分析する文化を作る-開発運営が自分でデータを分析してもらうためにしたこと-

株式会社 Aiming 開発グループ リードソフトウェアエンジニア 芝尾 幸一郎 様

スライドは以下からダウンロードできます

データを分析する文化を作る-開発運営が自分でデータを分析してもらうためにしたこと-

概要

• 運営側だけでなく、開発側も分析を見るために行なった施策
• データ分析をする目的とは
  • PDCAサイクルを回すため
    • C(Check)のためのデータ分析。P(Plan)のためじゃない。仮説無くして検証なし。
  • 開発メンバー間のコミュニケーションの促進
    • メンバーの情報共有が「共通言語」を生み、生産性が上がる
• 統計の専門家を入れてもうまくいかない理由
  • P(Plan)D(Do)を繰り返し、C(Check)がない
• コンシューマ全盛期時代ゲーム業界にはデータ分析の業務フローがなかった
  • 運営型になって初めて必要になった
• 開発運営自身でデータ分析を行うメリット・デメリット
  • ゲームへのドメイン知識がある
  • 「肌感覚」がある(ゲームとデータとの整合性がなんとなくわかる)
  • 統計やコンピューティングに弱い
  • プロジェクト間の共有が薄い
• データ分析の文化を根付かせるためにやったこと
  • BIツールの作成など、内製キャラクターコンテスト
  • バイトのデバッガーも含め、できるだけ多くの人が見られる権限を
  • 使い勝手が悪くなりがちなUIへのこだわり
    • ユーザビリティテストの実施
  • 勉強会や講座の実施
    • データは運営終了したタイトルのものを使って、本番同様のデータを使う
  • 分析社内報の発行
• 文化を作るのには時間がかかる

感想

「アプリ改善を深化するデータ分析 〜現場で使えるデータを片っ端から可視化するコツ〜」と言っていることは共通する部分が多かったですが、

こちらは誰でも分析結果を共有するための施策が中心でした。

開発者はどうしても目の前のタスクに追われて継続的に分析結果を見る習慣が途絶えがちなのでしょうが(私もそうです)、

習慣としてゲームの現状がどうなっているかを知らないと結果として何のための開発をしているかわかりません。

自戒も込めて、改めてデータ分析に取り組もうと思います。

オートプレイによる最適なパラメータシミュレーション〜自動化時代のゲームフレームワークに求められること〜

グリー株式会社 開発本部 エンジニア 尾崎 嘉彦 様 / グリー株式会社 Wright Flyer Studios事業本部 シニアゲームデザイナー 細谷 伊佐武 様

スライドは以下からダウンロードできます

オートプレイによる最適なパラメータシミュレーション〜自動化時代のゲームフレームワークに求められること〜

概要

• ダンメモを例に、各バトルコンテンツのレベルデザインの効率化を後から自動化した
• 各コンテンツで、テストの段階で作業時間の多くを取られている状況だった
• ステージバトル(いわゆるクエスト)
  • 最初はログから機械学習で最適なレベルデザインを探ろうとしたが、ログが機械学習向けのログでないなど、機械学習には不適切だった
    • 新コンテンツの追加など、後から足されると機械学習のコードを改修する必要もあった
  • テスト用のゲームシミュレータを改造、自動でステージの周回をするように
    • これならこれから入れる予定のコンテンツもテスト可能
  • Jenkinsで簡単な項目を選ぶだけでテストができる環境構築
  • 結果をエクセルなどで出力し、以上がないか可視化
• PvP
  • ステージと同様にやろうとしたが、先頭パーティの設定が環境によって変わるので、設定が膨大に
  • ランキングを取得して自動でパーティを作るようにできたが、シミュレータでテストするためにはある程度ゲームを進めたユーザデータを作る必要があった
    • Appium, Python, OpenCVを組み合わせて、画面から自動で判断してシミュレータを動かそうとした
    • キャプチャが遅い、並列化できない、UIの変更が入ると動かない、失敗率が高い、画面の解像度でも失敗することがある、などの問題が発生
  • cocos2d-consoleの利用で目標を達成
    • API化する必要があったが、CUIから実行でき、Jenkinsにも組み込め、並列化可能
• PvB(Player versus BOSS)
  • マニュアルのコマンド選択で高スコアを狙う必要がある
  • 機械学習の本領発揮。ベイズ最適化でコマンド探索を実行
    • 最初のスコアは933,480だが、ある程度の探索後は15,199,704までスコアが伸びた。人力だと24,278,700なので、時間をかければまだ伸ばせるか
• 適切なユーズケースの設定。自動化をしたいなら、初めからそれありきで実装する必要がある(ログなど)
• 自動化による出力は意味まで語ってはくれない。プランナーは、均質化しない独自の質(個性)の上げ方が求められる時代になる

感想

この日拝聴した講演の中で一番感動しました。

自動化を使ってプランナーのレベルデザインの負担を軽減させることがここまでできる時代になっていることを恥ずかしながら初めて知りました。

またJenkisについては必修レベルだと感じました。面倒なことをどこまで自動化して、本来の目的である「楽しさの探求」に時間を費やせるかが大事ですね。

機械学習はやってみたいと思いつつ手が伸びていない分野だったのですが、実務で役立たせるためにもしっかり学ばないといけないと再認識しました。

一度自動化するフレームワーク的なものを作ってしまえば他のタイトルでも応用できるはずなので、今後はそういった方向の勉強をしていきたいです。

今年のCEDECを振り返ってみて

来場者数、増えました？立ち見の講演がかなり多かったような...

それはともかく、今年も各社の取り組みや工夫を知ることができる大変貴重なイベントでした。

聴きたかったけど涙を呑んで諦めた講演も、タイムシフトパスで聴けるのはありがたいですね。

各メディアの講演をまとめた記事がたくさんあるので、こういう企業のブログとしてどんなことを書けばいいのかをもっと意識したいと思います。

個人的には、今の仕事を楽にするツールを作りたいと思っているので、今回の講演を元に気を引き締めて学び直そうと再決意しました。