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