コンテンツへスキップ

QualiArtsengineer blog

IDOLY PRIDEにおけるゲームAPIの開発

IDOLY PRIDEにおけるゲームAPIの開発

7 min read

はじめに

株式会社QualiArtsでバックエンドエンジニアをしている末吉です。 2021年6月リリースの「IDOLY PRIDE」（以降、アイプラ）の開発に携わり、主にゲームAPIの開発やインフラの運用を担当しています。

本記事ではアイプラの機能開発を例にして、どのようなフローでゲームAPIが開発されているかをまとめようと思います。

全体的なフロー

アイプラでは、下記のフローでゲームAPIの開発を行っております。

  1. 企画オリエンテーション
  2. API、DBの設計
  3. API、DBの設計レビュー会
  4. 実装スケジュール作成
  5. コード実装
  6. テストプレイ
  7. バグ修正
  8. 機能リリース
  9. 監視

順番に説明していきます。

1. 企画オリエンテーション

企画オリエンテーションとはその名の通り、プランナーが「新しく企画している機能がどのような機能なのか」をエンジニアに説明するミーティングを指します。

例えば、

  • 世界観(例: アイドルをマネージメントし、ライブで成功させる)
  • 概要(例: マスを進めてゴールを目指す)
  • 画面構成

などをこの企画オリエンテーションで把握します。

プランナーからの説明だけではなく、「こういう機能もあった方が楽しいのではないか」「今回の機能が技術的に実現可能か」という議論をプランナーと交わすこともあります。

上記のような議論をする場合、仕様を理解した上で交わす事が大切なので、私の場合は事前にプランナーが作った資料を読み込んで、質問や懸念点などをまとめた上で企画オリエンテーションに参加するようにしています。

2. API、DBの設計

企画オリエンテーションが終わったら設計に入ります。

盤石な設計は、精度の高い工数の見積もりと実装に繋がるので、1番力を入れて取り組むようにしています。

主に、APIとDBの単位で設計を分けています。

DB

ゲームにはマスタデータ、ユーザーデータという概念があり、これらのデータ設計をdraw.ioなどのサービスでER図を書いて設計する事が多いです。

前者はキャラクターの名前など、全ユーザーで情報が変わらない静的なデータの事です。アイプラではサーバー起動時にキャッシュとして保存しています。

後者はユーザーが所持するカードのレベルなど、ユーザーごとによって異なる動的なデータの事です。アイプラではGoogle Cloud Spannerにデータを保存しています。

Google Cloud Spannerについての詳しい内容は、下記の記事を参考にしてみて下さい。

「IDOLY PRIDE」におけるGoogle Cloud Spannerの活用

マスタデータ

マスタデータはサーバーのキャッシュとして参照されるので、一般的なDB設計でのベストプラクティス(負荷やインデックス、正規化など)に厳密に従う必要はなく、柔軟に設計を行う事が出来ます。

しかし、ゲームの場合設定する項目が非常に多く、1機能につき15 ~ 20テーブル必要になる事が多いです。

さらに、マスタデータを入力するのはエンジニアではなくプランナーなので、非エンジニア職でも入力しやすい形にしなければなりません。

これらは適宜プランナーにヒアリングを行い、お互いの認識をすり合わせながら最適な設計を模索していきます。

ユーザーデータ

ユーザーデータはユーザーの個々のデータを管理するという用途の為、マスタデータと比較するとテーブル数は少なくなります。(1機能につき、3 ~ 4テーブルほど)

ただし、ユーザーによってレコードが作成、更新されるので、検索する際のクエリの負荷などを慎重に考慮しつつスキーマを設計しなければなりません。

余談ですが、アイプラではGoogle Cloud Spannerを使用しているので

  • テーブルのインターリーブ
  • セカンダリインデックス

などを意識して、設計を行なっています。

API

アイプラでは、基本的にバックエンドエンジニアがAPIの設計を行なっております。

プランナーが作った資料の画面構成や仕様を見ながら、

  • どの画面でどのAPIをコールする必要があるか
  • リクエストでクライアントから送られてくるパラメータは何が必要か
  • レスポンスでクライアントに返すパラメータは何が必要か

を決めていきます。

当然、クライアントエンジニアと上記の意思疎通を行なっておくのが重要になってくるので、適宜相談したり、設計後にAPIの内容をまとめたドキュメントを共有したりしています。

ちなみにアイプラではAPIの定義にProtocol Buffersを採用しており、protoファイルを元にドキュメントが自動生成する仕組みを構築しています。

3. API、DBの設計レビュー

設計が終わったら、バックエンドメンバー全員の予定を押さえて設計レビュー会を開きます。

設計時に作成したER図を元に、メンバー全員に設計の説明を行い、「運用しやすい設計になっているか」「負荷に問題はないか」などの指摘をもらいます。

この設計レビュー会で余りにも指摘が多かった場合、「2. API、DBの設計」をやり直して、もう一度このレビュー会を開くこともあります。

4. 実装スケジュール作成

設計レビュー会が終わり、地盤が固まったら次にバックエンド側の工数を見積もります。

「どの実装にどれくらいかかる」「何月何日にどのゲームAPIが完成している」という情報は、バックエンドエンジニアだけではなく、

  • プランナー
  • クライアントエンジニア
  • 開発ディレクター

など、他セクションのメンバーにとっても重要なので、工数の見積もりと共有は欠かさず行います。

全てのAPIの工数を共有しても分かりにくいので、私の場合だと下記のようにそれぞれマイルストーンを立ててSlackで共有しています。

クライアント側でmockAPIを叩けるようにする
→ 10/8(金)

メインループのAPI実装終了
→ 10/26(火)

それ以外のサーバー側APIの実装終了
→ 11/2(火)

ログやバッチ処理等のAPI以外の実装
→ 11/16(火) ← ここが開発完了日

5. コード実装

実際にコードを書いて、プログラムを作成していきます。

「xx API実装」というタスクがある場合

  • コードを書く
  • プルリクを投げる
  • バックエンドメンバーにレビューしてもらう
  • 2人からApproveがもらえたらマージする
  • ビルドを行い、開発環境にデプロイする

という流れで進めています。

実装中にクライアントエンジニアがサーバーとの繋ぎ込みを行うので、デプロイされたら連絡する等、進捗は都度報告する事が大切です。

6. テストプレイ

アイプラでは、開発途中のプロトタイプの状態を、プロジェクトメンバー全員でテストプレイする事が多いです。

(弊社ではおさわり会と呼んでいます)

ユーザー目線になって、「ここにxxを表示した方が良い」など意見を交わす事はゲームの質を高める上で重要になってくるので、バックエンドエンジニアである自分も積極的に意見を出すようにしてます。

ここで出た意見は、今後のアップデートでの改善内容になったり、優先度が高いものであれば追加で実装したりします。

7. バグ修正

開発が完了したら、開発完了日 ~ リリース日まではデバッグ期間となります。

  • デバッガーの方にデバッグをしてもらう
  • バグが見つかったらチケットを発行してもらう
  • 開発メンバーでバグを修正する

という流れでひたすらバグを潰していきます。

私の場合だとこの期間は機能開発とは関係ない他のタスクをやっている事が多いのですが、チケットが飛んできたら最優先で取りかかるようにしてます。

8. 機能リリース

デバッグ期間が終わったら、遂にリリースです！

プランナーと事前にタイミングをすり合わせて、出来上がったAPIを本番環境にデプロイします。

9. 監視

リリース後は、実際にユーザーがその機能をリアルタイムで使うことになります。

もし不具合や障害が発生した場合、迅速に動いて解決しなければならないので、監視は重要な業務となってきます。

「xxをタップすると進行不能になる」などの明確な不具合だけでなく、

  • バッチ処理
  • Datadogのダッシュボード (APIのレイテンシ、エラーなど)
  • Spannerなどの各リソースのメトリクス (CPU使用率など)

など、様々な情報を見るようにしてます。

勿論、四六時中監視を行なっている訳ではなく

  • リリース直後
  • バッチ処理の開始

など、何かしらの出来事が起こる時に監視を行っています。

リリースした機能が不具合なく動作するのを確認したら、、晴れて開発完了となります！

おわりに

今回はアイプラでの機能開発を例にして、ゲームAPIの開発フローについて紹介をさせて頂きました。

  1. 企画オリエンテーション
  2. API、DBの設計
  3. API、DBの設計レビュー会
  4. 実装スケジュール作成
  5. コード実装
  6. テストプレイ
  7. バグ修正
  8. 機能リリース
  9. 監視

「プランナーとマスタデータをすり合わせる」「スケジュールのマイルストーンを建ててSlackで共有する」など、コードを書く以外にやる事が多いように感じるかもしれません。

しかし、前提として開発はバックエンドエンジニアだけでは成り立ちません。 他セクションと意思疎通を行わないと、本番環境で意図しないバグが発生し、最終的にはユーザー離れに繋がってしまいます。 その為、報告、連絡、相談を能動的に行う事は必要不可欠となってきます。

また、個人的には 「4.実装スケジュール作成 」までを最速で終わらせる事が重要だと感じています。 多めに実装の工数を確保する事が出来るので、急な体調不良や、ユーザーからのお問い合わせ調査などが発生しても進捗に遅れが生じにくくなるからです。

本記事を通してアイプラにおいて、バックエンドエンジニアがどのように開発を行っているのか、少しでも伝われば幸いです。

2020年に株式会社QualiArtsにサーバーサイドエンジニアとして新卒入社。『IDOLY PRIDE』では複数の機能開発やインフラ構築を担当。現在はサーバーサイドチームのリーダーを担当。