Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

協業アプリ開発を推進するテクニカルコンサルタントの挑戦 〜『歌マクロス』を成功に導く技術支援〜

29,922 views

Published on

DeNA TechCon 2018の登壇資料です。

Published in: Technology
  • Be the first to comment

協業アプリ開発を推進するテクニカルコンサルタントの挑戦 〜『歌マクロス』を成功に導く技術支援〜

  1. 1. 協業アプリ開発を推進する テクニカルコンサルタントの挑戦 〜『歌マクロス』を成功に導く技術支援〜 ゲーム・エンターテインメント事業本部 Japanリージョンゲーム事業部開発基盤部 Wataru Takahashi
  2. 2. 自己紹介 ■ 高橋 渉(Takahashi Wataru) – 開発基盤部所属 – 経歴 • SIer – インフラ系の大規模システム開発 – B to Cをやりたくなる • DeNA – 最初は広告系サービス – ゲーム事業の盛り上がりを受けてゲーム事業部に異動 – 複数タイトルのリードエンジニアを経験 – 数年前から協業開発のテクニカルコンサルタントに携わる – 歌マクロスなど、複数のアプリ開発をサポート 1
  3. 3. 歌マクロスをPVでご紹介 2 https://youtu.be/EwS0sYXZ_Bk
  4. 4. 歌マクロスについて • 2017年8月3日リリース • パブリッシュはDeNA • 開発は株式会社XEENとの協業 3
  5. 5. 今日お話すること 1. DeNAのゲーム開発体制 – 内製開発 – 協業開発 2. 過去の協業開発体制の課題 3. テックコンサルの役割 4. まとめ 4 © ’82,’84,’92,’94,’95,’97,’02,’15 BW © ’07 BW/MFP・M © ’09,’11 BW/MFP © DeNA
  6. 6. DeNAの開発体制 5
  7. 7. 内製開発体制 • DeNA社内メンバーのみ で企画、開発、運用 • 開発規模によってはメン バー数が多くなってしま うので開発ライン数は限 られている • ブラウザゲーム時代は全 てこの体制 6
  8. 8. 内製開発体制図 7 プランナーA プランナーB : 2Dデザイナー 3Dデザイナー : エンジニアA エンジニアB : 協力会社C 協力会社D 5 プロデューサー ディレクター メインプランナー メインデザイナー メインエンジニア 協力会社B 協力会社A DeNA QA・CS 分析・マーケ
  9. 9. 協業開発体制 8 • コンテンツがリッチ化するこ とで開発期間が長くなり、内 製だけでさばけなくなってき た • コンソールゲーム開発で実績 のある会社と協業 • 企画概要の立案、パブリッ シュは基本的にDeNA • 詳細仕様の作成、実装、運用 は開発会社 • 開発ライン数は多くできる © ’82,’84,’92,’94,’95,’97,’02,’15 BW © ’07 BW/MFP・M © ’09,’11 BW/MFP © DeNA
  10. 10. 一般的な協業開発体制図 DeNA 開発会社 プランナーA プランナーB : 2Dデザイナー 3Dデザイナー : エンジニアA エンジニアB : 協力会社B 協力会社C 協力会社D 5 メインプランナー QA・CS 分析・マーケ クリエイティブ ディレクター プロデューサー プロデューサー ディレクター メインプランナー メインデザイナー メインエンジニア 協力会社A
  11. 11. 10 過去の協業開発タイトルでは うまくいかないことがありました.. © ’82,’84,’92,’94,’95,’97,’02,’15 BW © ’07 BW/MFP・M © ’09,’11 BW/MFP © DeNA
  12. 12. 過去の協業開発体制の課題 11
  13. 13. 過去のタイトルで見つかった課題 • ゲームサーバでエラーが頻発 • アプリのパフォーマンスが悪い • リリース後の安定した運用ができない – 障害が多い&同じ障害を繰り返す – 開発スピードが上がらない – 運用を続けていける体制・実装ができていない • ガイドライン違反でアプリ申請がリジェクトされる など 12
  14. 14. どうして起きたのか 13
  15. 15. 協業体制での両者の傾向 DeNA • ソーシャルゲームの運用ノウ ハウがある • 分析やマーケティング • ソーシャルゲーム開発に必要 な技術基盤を持っている (Sakashoや汎用ライブラリ) • 企画メンバーが中心で技術的 視点が足りない 開発会社 • コンソールゲーム開発で培っ た高い技術力がある • サーバと連携するゲーム開発 の経験が少ない • ソーシャルゲームの開発・運 用ノウハウが少ない 14
  16. 16. 担当ごとの人数割合のイメージ 15 プランナー マーケ・分析・QA・CS デザイナー ディレクター 実装 DeNA 役務分担 DeNA 開発会社 開発会社 開発会社 DeNA DeNA 開発会社
  17. 17. 課題を整理 DeNA 企画寄りのメンバーが中心で技術的課題やリスクに気づきにくい 開発会社 ソーシャルゲーム開発・運用における技術的課題やリスクの ノウハウが少ない 全体 技術的な課題やリスクに責任を持って対応する担当者が不在または 不足 16
  18. 18. テックコンサル 17
  19. 19. テックコンサルが参加 18 DeNA 開発会社 プランナーA プランナーB : 2Dデザイナー 3Dデザイナー : エンジニアA エンジニアB : 協力会社B 協力会社C 協力会社D メインプランナー QA・CS 分析・マーケ クリエイティブ ディレクター プロデューサー プロデューサー ディレクター メインプランナー メインデザイナー メインエンジニア 協力会社A テックコンサル
  20. 20. テックコンサルの仕事 - 歌マクロスの事例 - 19
  21. 21. 目指すゴール • ゲーム自体が面白い • 操作性が良い • 魅力的なグラフィック • 快適に遊べるパフォーマンス • 安定した運用 – 不具合が少ない/不具合への迅速な対応 – コンテンツや新機能の適切な追加 • 各種ガイドラインや法令の遵守 など 20
  22. 22. テックコンサルの仕事 1. ゲームサーバの安定化 2. クライアントのパフォーマンス対応 3. アセットダウンロードの最適化 4. 運用を見据えた設計・準備 5. 障害振り返りと再発防止 6. 企画リスクの把握 7. 要望や課題のフィードバック 8. 各種ガイドラインへの対応 9. 開発会社とのチームワーク強化 10. その他 21
  23. 23. 1. ゲームサーバの安定化 22
  24. 24. ゲームサーバ 一般的なゲームサーバの構成 23 クライアント ロ ー ド バ ラ ン サ ー API サーバ API サーバ API サーバ DB1 DB2 Cache 独自実装した APIで通信
  25. 25. 過去のタイトルで起きた問題 • 負荷問題/エラー – リリース直後に高負荷でエラー • 負荷試験不足 • DBやキャッシュの設計が悪く簡単にスケールできない • プレイヤーデータ作成時に大量のインサートが走っていた – 機能改修したら高負荷/エラー • DBやキャッシュの設計が悪い/Index張り忘れ • 大量のクエリーが流れていた • テーブルロックがかかっていた • 実装ミス • サーバコスト – 設計が悪く、リソース効率が悪い – 台数が多くなり高コスト 24
  26. 26. 一般的なサポート内容 • レビュー – アーキテクチャ – インフラ構成 – DB・テーブル設計 – クエリー・ソースコード • 負荷試験の実施 – 負荷想定の見積もり – テストシナリオレビュー – 試験方法のレビュー • 負荷のボトルネック調査 • 負荷に合わせたサーバの増減管理 • サーバコストの管理 • 各種モニタリングツールの導入 25
  27. 27. Sakashoを使う 26
  28. 28. Sakasho? 概要 • アプリゲーム開発に必要 とされる汎用的な機能を 提供するゲームプラット フォーム • 標準的なゲームサーバの 代わりになる • ボタン一つで開発環境を いくつでも作れる Sakashoの機能例 • ログイン機能 • ユーザデータ管理 • ガチャ • ランキング • お知らせ • お問い合わせ • 課金処理 • マスタ配信 • アセット配信など 27
  29. 29. 歌マクロスのサーバ構成 28 クライアント Sakasho SDK 独自の機能 • ミッション • イベントなど Sakashoサーバ • ユーザデータ管理 • ガチャ • ランキング • お知らせ • お問い合わせ • 課金処理 • マスタ配信 • アセット配信など Sakasho APIの通信
  30. 30. Sakashoのサポートは必要 • 使い方を間違えないようにするサポート • 実装のベストプラクティスの提供 • 質問を受け付ける窓口 • 運用フローのサポート • 必要な追加機能要件をまとめてSakashoチーム へ依頼 29
  31. 31. 2. クライアントの パフォーマンス対策 30
  32. 32. なぜテックコンサルが対応? • 開発中に企画から何度も仕様追加・変更が入る – 当初のパフォーマンスが出なくなる – 仕様追加・変更により開発工数が圧迫される – パフォーマンス対策が後回しにされがちに • 後回しにすると – ロースペック端末で期待通りに動かなくなる – 手戻りが大きい • 手遅れになる前にテックコンサルがチェック • DeNAは日本で発売されている殆ど全ての端末を揃えている – 外部QA会社に依頼することもできる 31
  33. 33. 注目した主なポイント 1. リズムゲームがスムーズに動く 2. 起動・画面間のロード時間が短い 3. 端末が熱くなりすぎない この範囲内で可能な限りクオリティを高める 32
  34. 34. やってきたこと 1. 対象端末の選定 2. パフォーマンス目標の設定 3. パフォーマンス試験 4. ボトルネックの調査・対応 33
  35. 35. 対象端末の選定 • 最低動作保証端末の選定 – 端末の普及状況 – タイトルで実現したいこと • 開発中に動作確認する端末 – ロースペック – ミドルスペック – ハイスペック端末 • 本格的な開発が始まる前に決める 34
  36. 36. 目標設定 • 描画 – リズムゲーム中は60FPS安定 – 瞬間的なカクつきがない • 各画面間の遷移のロード時間 – 各画面遷移ごとに設定 – 端末を絞って設定 – 他タイトルの実績や体感を元に決定 35
  37. 37. パフォーマンス試験 • 開発初期から多端末でのパフォーマンス試験を 実施 • 着目点は主にFPS、ロード時間、温度 • 実装が進み、機能が増えていくとパフォーマン スは落ちていく • 開発進捗に合わせて繰り返し実施 36
  38. 38. ボトルネックの調査・対応 • 基本的には開発会社が行う • よりパフォーマンスをあげるためにDeNAのパ フォーマンス専門チームへも調査依頼 • 後回しにせず、随時対応 • リリース後にも継続してチューニング 37
  39. 39. 3. アセットダウンロードの最適化 38
  40. 40. ストレスを最小限に • ダウンロードされるトータル容量 – 端末ストレージの圧迫 – 通信量・通信制限 – 最悪、即アンインストール • 一度にダウンロードする容量 – ダウンロード時間の長時間化 – 待ちきれずに中断/離脱 • ダウンロードが発生するタイミング – 頻繁すぎるとストレス 39
  41. 41. 歌マクロスのアセットダウンロード • 楽曲、動画、3Dモデルなどで容量が大きくなる • リリース時から2年後までの容量目標を設定 • 各アセットのサイズはは全体クオリティと総容量を元に定義 • アセットダウンロードタイミングは細かく制御 – 初回起動直後(少) – チュートリアル終了後(中) – 都度ダウンロード • ダウンロード中に簡単なアンケートを入れる – 体感的な待ち時間の軽減 – ユーザの属性も収集 40
  42. 42. 4. 運用を見据えた設計・準備 41
  43. 43. 運用中の開発状況の例 42 クライアント更新1 クライアント更新2 データ更新1 データ更新2 データ更新3 データ準備 QA 公開 データ準備 QA 公開 QA アプリ申請 公開実装 データ準備 QA 公開 実装 QA アプリ申請 公開 時間軸
  44. 44. 他タイトルでよく起きた問題 • 修正したはずのデータが元に戻っていた • 修正したバグが復活した • アセットやマスタの本番反映が漏れていた • リリース予定日より早く反映された • QAした内容と本番に反映された内容が異なる など 43
  45. 45. 早くから運用を想定して準備 • 適切なブランチ管理 – マスタ・アセット – ソースコード – マージしやすいデータ構造 • 体制の整備 – 開発体制 – QA体制 • フローの整理 – マージ手順 – 本番反映 44
  46. 46. 5. 障害振り返りと再発防止 45
  47. 47. 障害振り返りと再発防止 • 障害は全て記録に残す • 開発会社との障害振り返り会 – 定例として開催 – 両社で発生原因の認識を合わせる – 現実的な再発防止策を決める • 可能な限りシステム化して防止 – 「次から十分に注意します」はNG – 難しい場合はチェックリストや体制でカバー • 開発会社と一緒に現実的な方法を考える – 現実的でない対策は形骸化/逆効果 46
  48. 48. 障害事例の蓄積と共有 協業案件はタイトルごとに開発会社が異なる • タイトル間のつながりがない • ノウハウや事例が共有されづらい 47 タイトルA タイトルB タイトルC 事例 事例
  49. 49. テックコンサルが事例を集約して共有 48 • テックコンサルは複数のタイト ルを掛け持ちしている • タイトル横断の課題やノウハウ を把握できる • 社内にいるので内製の情報も把 握できる • 蓄積した課題やノウハウを各タ イトルへ共有 タイトルA タイトルB タイトルC テックコンサル 事例やノウハウ
  50. 50. 6. 要望や課題のフィードバック 49
  51. 51. DeNAが持つ共通ライブラリなど • 多くは内製タイトル の要件・要望に基づ き作成 • 協業案件の開発会社 にも提供 • 協業案件の要望機 能・仕様も追加して いく必要がある 50 ライブラリ など 概要 Sakasho 汎用ゲームプラットフォーム IRIS リアルタイム通信プラット フォーム DeAL サウンド再生エンジン SecureLib セキュリティパッケージ : など多数
  52. 52. マスタデータB マスタデータC マスタデータA クライアント 内製で起動が長時間化した事例 51 Sakashoサーバ上の マスタデータ(JSON) マスタデータB マスタデータC アセットデータ マスタデータAマスタデータA マスタデータB マスタデータC 1. アプリ起動
  53. 53. マスタデータB マスタデータC マスタデータA クライアント 内製で起動が長時間化した事例 52 Sakashoサーバ上の マスタデータ(JSON) マスタデータB マスタデータC アセットデータ マスタデータAマスタデータA マスタデータB マスタデータC 1. アプリ起動 2. マスタデータロード 3. JSONパース マスタデータA マスタデータB マスタデータC
  54. 54. マスタデータB マスタデータC マスタデータA クライアント 内製で起動が長時間化した事例 53 Sakashoサーバ上の マスタデータ(JSON) マスタデータB マスタデータC アセットデータ マスタデータAマスタデータA マスタデータB マスタデータC マスタが肥大化していると ロードやパースに時間がかかり 結果、起動が長時間化する 1. アプリ起動 2. マスタデータロード 3. JSONパース 4. アプリ終了 ・クライアントのマスタは消失
  55. 55. 1. 一部マスタをアセット化し暗号化 2. アセットとしてクライアントにダウ ンロード 3. 残ったマスタは従来通り起動時 にロード 暗号化した マスタデータB/C マスタデータB マスタデータC マスタデータA クライアント その事例の解決方法 54 Sakashoサーバ上の マスタデータ(JSON) マスタデータB マスタデータC アセットデータ マスタデータAマスタデータA 暗号化した マスタデータB/C 起動の高速化を実現 暗号化した マスタデータB/C マスタデータA
  56. 56. マスタをアセット化し 暗号化するツールクライアント 歌マクロスではライブラリを開発 Sakashoサーバ上の マスタデータ(JSON) 55 アセットデータ 1. マスタをアセット化し暗号化する ツール開発 2. クライアントでデコードするライ ブラリ開発 デコードライブラリ マスタデータB マスタデータA
  57. 57. マスタをアセット化し 暗号化するツールクライアント 歌マクロスではライブラリを開発 Sakashoサーバ上の マスタデータ(JSON) 56 アセットデータ 1. マスタをアセット化し暗号化する ツール開発 2. クライアントでデコードするライ ブラリ開発 3. ツールを使ってマスタをアセット 化・暗号化 4. アセット化したマスタをクライア ントにダウンロード デコードライブラリ マスタデータB マスタデータA アセット化し暗号化 したマスタA/B • ライブラリ/ツール化することで 確実な実装ができる • 他のサービスでも利用可能 アセット化し暗号化 したマスタA/B
  58. 58. 7. 企画リスクの把握 57
  59. 59. 企画リスクの把握 • リスクに気づかずに企画が進んでしまう事がある • 難易度などを含めた取捨選択ができない事がある • 進めようとしている企画や実現方法に対する妥当性 の判断が必要 • テックコンサルが企画を把握して課題を洗い出し、 必要に応じて代替案の提案や方向修正 58
  60. 60. 59 8. 各種ガイドラインへの対応
  61. 61. 各種ガイドライン • いろいろなガイドライン – Apple/Googleのガイドライン – CESAガイドライン – DeNAのガイドライン • 必要なガイドラインを取りまとめて開発会社に提供 – やってはいけないことを規制 – やらなければいけないことを明確化 – 知らない故の不安を無くす – 迷わず進むことができる 60
  62. 62. ガイドライン違反? 61※実際のアプリ画面とは異なります
  63. 63. 9. 開発会社とのチームワーク強化 62
  64. 64. 開発会社とのチームワーク強化 • 日々のコミュニケーション – 開発会社とは物理的な距離が離れている – 普段は専用のSlackチャンネルでやり取り • エンジニア定例 – 開発会社のエンジニアとテックコンサルの会議 – ディレクターやプランナーも参加 – 企画会議とは別枠で定期開催 – 課題や質問を持ち寄って議論 • 開発会社も含めて一つのチーム 63
  65. 65. 10. その他業務 64
  66. 66. 10. その他業務 • 各種ライセンス管理 • OSSの利用可否判断 • チート・セキュリティ 対策サポート • 脆弱性情報の共有 • 各種規約変更のキャッ チアップと共有 • 使用機材の選定 • 開発会社の選定 • ノウハウ共有資料作成 • 各種ライブラリの実装 サポート • アプリサイズチェック • テスト方法のサポート • 障害対応サポート • リリースサポート など 65
  67. 67. テックコンサル それぞれの強みが集結 66 開発会社の 技術力 DeNAの分析 マーケティング力 両社の 企画・運用力 マクロスの IPの力
  68. 68. 歌マクロスは高い評価を獲得 • Google Playレビュー評価:4.6(1/31時点累積) • App Storeレビュー評価:4.5(1/31時点累積) • Google Play 「ベスト オブ 2017」 20タイト ルにノミネート 67 © ’82,’84,’92,’94,’95,’97,’02,’15 BW © ’07 BW/MFP・M © ’09,’11 BW/MFP © DeNA
  69. 69. まとめ • 協業アプリゲーム開発では様々な技術的課題、問題が起こる • テックコンサルが技術に関連する全般に責任を持ち、マネジ メントする • 課題やノウハウを蓄積して他サービスに共有することも重要 68 これからも、さまざまな技術的課題への取り組みやフローの 整備を進めていくことで、開発会社・DeNA双方の力が最大 限に発揮できるようサポートし、より魅力的なゲームをお客 様に提供できるよう、全力で挑戦を続けていきます。
  70. 70. ご清聴ありがとうございました 69

×