新規開発案件でのデータ管理ツール開発運用

名古屋のサーバーエンジニアの加藤です。前回から引き続き、主にプロダクトの運用や開発をサポートする管理ツールの開発・運用を行っています。

今回は、数年前に開発中の新規プロジェクトにアサインされ、ゼロから管理ツールを立ち上げ、リリースに至るまでの間の状況や要求の変化と対応の事例を挙げます。

特にデータフローについては悩ましい点かと思いますので、一例として参考になれば幸いです。

環境について

今回参加したプロジェクトのツールはPHP(Laravel) + Vueで構築しました。

選定理由は学習コストの低さと社内のノウハウの蓄積、研究という意味合いが強いです。

DBはAPI同様にMySQL、認証はGoogleアカウントで行い、EC2で起動したDockerで動作させています。

Laravel、Vueともに初の案件でありましたが、最初の1ヶ月程度で実装と試行錯誤を並行して十分に習熟できました。

主な要件

最終的な要件は、前回の記事と同様、以下のようになります。

1. マスタ及びユーザデータの視認性や検索性を考慮した検索機能
2. プランナーやエンジニアによるマスタデータの投入や更新
3. 本番環境へのデータのデプロイ
4. その他、売上などKPIの可視化など

特に今回はリリース前ということもあり、データの投入やデプロイの要件については試行錯誤が繰り返されました。

また開発中であるため、以下の要件も加わりました。

5. データ操作、開発サポート用のデバッグ機能

これは主にプレイヤーデータに対して、パラメータの変更や特定のAPIを叩くなどの機能で、プランナーやクライアント開発者が利用します。

クライアント側でしか持っていないデータに関してはクライアント側でデバッグ機能を実装する必要がありますが、サーバ側で完結するものは開発コストの低いWeb側で実装することで細かい要件に対応しつつ実装速度や柔軟性を持った開発を行えました。

開発中だからこその課題

リリース前のサービスに対するツールを開発するにあたり、以下の点が課題となりました。

• リリース後の運用の考慮とデバッグ機能の拡充

  デバッグ機能は開発QAとクライアントチームから要望が多く、利用頻度も多かったです。運用中のコンテンツでは要望はあまりなかった、あるいは別の手段で対応していたのですが、リリース後にこれらのデバッグ機能が本番のプレイヤーデータでカスタマー担当者などが利用できないよう、切り分けを前提として設計する必要がありました。

  こちらはあらかじめ想定して設計していたため、リリース前には機能や権限の分離を問題なく行えました。

• 更新頻度の高い仕様、データ構成

  開発中であるがゆえ、仕様やDB構成の変更が高頻度で発生し、これに対するツール側の対応の遅れや仕様変更の漏れにより、開発やQAに影響を与えることもありました。

  大きめの機能の追加についてはキャッチアップしやすいのですが対応に時間を取られ、細かい仕様変更やDBへのカラム追加や構造の変更はキャッチしきれないこともたびたびありました。

最も苦労した点

• 複数の環境の使い分け

  開発が終盤に近づくにつれ、環境がいくつも増えて行きました。
  ツールでの環境の追加の対応自体は、設定の追加だけで済むよう設計しましたが、各環境の用途、特にデータフローに関わる部分については試行錯誤を必要としました。

  複数のラインのデータQAを、それぞれどの環境でおこなうか？
  可能な限りリスクの少ないデータフローを如何に構築するか？
  リリース日ごとに分割されたデータの反映をどのように行うか？

  これらは開発終盤まで何度も議論が繰り返され、何度も改修が行われました。

  最終的にはすべてのマスタデータへリリース日と紐付いたキーを持たせ、それを条件に各QA環境へ反映することで対応しました。クライアントへダウンロードするデータやアセットファイルもこのキーを元に生成や紐付けを行い、リリースする仕組みを構築しました。

  データを管理するプランナーは、ツールを利用して環境間コピーを行うデータやアセット、リリース日をキーから選択してデータ差分を確認することで、リスクを下げつつ容易に作業を行えます。

まとめ

個人的な経歴では、運用開始の数年前からソーシャルゲームプロジェクトに関わるのは今回が初の経験であったことに加え、LaravelとVueを利用した案件が初めてであったこと、運用中のツールへの改修でなくほぼゼロからの構築であったことなどから、苦労する点も多くありました。

特にデータフローの要件はジョインした当初からプロデューサー、ディレクター、データ管理者だけでなく、アセットの管理も絡むためクライアントからも要望が出てくるため、何度も変遷を繰り返し、ほぼ作り直しになることも数回ありました。

一方、開発初期に用意した環境間でのデータコピー、差分の確認機能は最初期に開発したものをほぼそのまま最後まで利用できており、そもそも他プロジェクトで利用していた機能の流用であるため、再利用性は高いものになっていました。

他のいくつかの機能も同様に他プロジェクトから流用してきたものもあり、ソーシャルゲームの開発運用において基本的な機能やデータの操作、必要なフローを体系化していくことで、今後もプロジェクト間で再利用できるツール機能を拡充、改善していければと思います。