エンジン戦略におけるブリッジエンジニアの役割

by gree_tech

Slide 1

Slide 1 text

エンジン戦略におけるブリッジエンジニアの役割 2019/6/6 吉本誠也

Slide 2

Slide 2 text

吉本誠也 • 前職 • ウェブゲーム開発 • 2013年グリー入社 • ネイティブゲーム配属 • ハコニワ、天と大地と女神の魔法、武器よさらば等自己紹介

Slide 3

Slide 3 text

• 2013年頃、グリーとしてもネイティブゲームシフトしていく序盤に作成していたアプリ • unity • Flash→lwf • SMY(StateMachine written in YAML) • サーバEN ハコニワ

Slide 4

Slide 4 text

• マルチプレイRTS • unity • 2014年頃のスマホでも動くようにバトルの経路探索等ロジック全般C++のバイナリをUnityで読み込んで使用 • UI、バトルロジック天と大地と女神の魔法

Slide 5

Slide 5 text

• ごりごりのアクションゲーム • Unity • バトルロジック、バトルUI 武器よさらば

Slide 6

Slide 6 text

同一エンジンなのです！実はこれ・・・

Slide 7

Slide 7 text

同一のエンジンを使うことで多くの開発人員が必要開発工数の圧縮多くの開発人員が必要注力領域にフォーカスグリーには複数の自社エンジンが存在

Slide 8

Slide 8 text

だがしかし ©️ WFS

Slide 9

Slide 9 text

• 日々生まれ続けているゲームアプリ • 長年運用されクオリティを上げ続けてきたアプリ • 高いクオリティ、多くのコンテンツを有する状態でリリースしないとヒットは生まれないアプリ開発レッドオーシャン時代

Slide 10

Slide 10 text

• プロトタイプ8人で3ヶ月やって・・・ • アルファ期間20人で半年やって・・・ • ベータ期間30人で半年やって・・ • QA期間40人で1ヶ月やって・・やっとリリース(1例) レッドオーシャン時代のアプリ開発は

Slide 11

Slide 11 text

レッドオーシャン時代のアプリ開発は多くの開発人員が必要多くの開発人員多くの開発人員が必要柔軟な人数増強他社様の力をお借りしましょう注 1例です動ける人員がすぐに確保できない・・・

Slide 12

Slide 12 text

共同事業モデル A社グリー最近の某開発事例

Slide 13

Slide 13 text

共同事業モデル A社：グリー最近の某開発事例共同事業モデル A社：パブリッシャー、CS業務、版元交渉(IP監修) グリー：ゲーム開発責任、プロトタイプ作成、QA、コンサルタント及び実務サポート

Slide 14

Slide 14 text

共同事業モデル A社：グリー最近の某開発事例共同事業モデル A社：パブリッシャー、CS業務、版元交渉(IP監修) グリー：ゲーム開発責任、プロトタイプ作成、QA、コンサルタント及び実務サポートグリー側では社内スタッフ、外部開発会社との開発体制の構築

Slide 15

Slide 15 text

最近の某開発事例 • プロトタイプ3ヶ月 • アルファ期間2ヶ月 • ベータ期間7ヶ月 • QA期間2ヶ月開発会社B社様グリーグリー A社様 A社様開発11ヶ月でリリースグリーの技術資産を活用しつつ円滑な開発でリリースさせる全職制での本開発

Slide 16

Slide 16 text

最近の某開発事例他所の技術を使って11ヶ月でリリース？グリー(ゲーム開発責任、QA、コンサルタント及び実務サポート) A社様(パブリッシャー、CS業務、版元交渉) 考えた企画は実装できるのか？ B社様(全職制での本開発) 実装方法は他社特許にひっかからない？

Slide 17

Slide 17 text

この座組みで問題になりやすいこと • グリーだけで企画を詰め切ることができない • 開発会社が既存技術の解読に時間が取られてしまう • パブリッシャーからへの返答に即答できない

Slide 18

Slide 18 text

この座組みで問題になりやすいこと • グリーだけで企画を詰め切ることができない • 開発会社が既存技術の解読に時間が取られてしまう • パブリッシャーからへの返答に即答できない • 開発会社の技術的課題でのコミュニケーションコストブリッジエンジニアを入れましょう！

Slide 19

Slide 19 text

ブリッジエンジニアが入ることで • 企画速度UP：既存のエンジンで何ができて、何ができないのか瞬時にわかる • 実装速度UP：既存のデバッグ機能、マスタ構造、既存の実装に精通していることでどこをどうすればすぐ実装できるかわかる。開発会社の躓きポイントに気づきいち早く対策を講じることができる。

Slide 20

Slide 20 text

アルファ期間の業務例 • B社様会議室にてマスターデータ、デバッグ方法説明会 • B社様オフィスに吉本の席を用意してもらい、週2〜3作業 • B社様の開発にあたってひっかかる箇所のヘルプ簡単に聞ける関係づくりの構築

Slide 21

Slide 21 text

アルファ期間の業務例 • グリーアートチームの表情差分書き出しを簡略化したい →どういう形でやれば良いか社内で話しながらルール作成 →jsxで表情グループ以下の表情差分を切り出して配置

Slide 22

Slide 22 text

アルファ期間の業務例 • グリーアートチームで作った地図をゲーム中に出したい →psdからjsxでpngとjsonを吐き出してUnity側で読み込み会社間のやりとりを極力省く

Slide 23

Slide 23 text

その結果 • 2ヶ月でアルファビルドの完成 • ホーム、クエスト、バトル、リザルトがさし代わり、別ゲームに生まれ変わる

Slide 24

Slide 24 text

ベータ期間の業務例 • 何にどれくらいメモリを使えるのかわからない →ベースエンジンのメモリ管理を参考に

Slide 25

Slide 25 text

ベータ期間の業務例 • 特許問題でA社、グリー共に実装観点で問題ないかの確認を求められる →資料を作成して説明し問題ないことを確認

Slide 26

Slide 26 text

ベータ期間の業務例 • 開発会社のENに1機能の開発に2ヶ月の工数が必要と言われる →既存の機構を利用することで、一ヶ月でできることを説明し、ヘルプにも入った • UIの組み込み要員が足りなくなった →prefabいじり続ける(便利機能の開発) • 開発会社から納期までに入れられない機能があると言われる →自ら実装

Slide 27

Slide 27 text

Slide 28

Slide 28 text

なんだかんだで多くの開発人員が必要無事リリース！

Slide 29

Slide 29 text

総じて • 自社だけでは開発コストがどうしても高くつく時代 • 自社の蓄積を活かしつつ、他社と共同して新しいプロダクトを効率よく生み出していきたい様々な人や技術をつなぐブリッジエンジニアが重要です