## プロジェクト概要
すみっコぐらし IP の農園系ゲームのサーバーサイド開発, 問い合わせに対するログ調査, 管理画面開発をした。
使用した技術は言語としては Go, TypeScript。Go は API サーバーとして使用しており、echo というフレームワークを使用していた。ORM には sqlboiler というライブラリを使用していた。API の形式としては REST 系の JSON を返す API になっており、REST 系の API を開発するのに必要な程度のコーディングは特に問題なくできる。また、テストも日常的に書いていたので、Goの標準的なテストの書き方 (TDT, サブテスト) も慣れている。テストで使用していたフレームワークは testify。
TypeScript を使った管理画面の開発では、Vue.js を使っていた。TypeScript やフロントエンドの技術・知識には Go に比較すると苦手意識を持っていて、コードを読んだり・一定の編集をするのは問題ないが、一から画面を構築する能力はあまりなかった。OpenAPI から TypeScript のコードを生成して管理画面側で使用するような開発を行っていたので、スキーマ駆動開発には慣れている。
## 開発チームの構成
- Unity エンジニア 2人
- サーバーサイドエンジニア 1人
- インフラエンジニア 1人
# 開発・実装内容 (ゲームタイトルの Google Play Pass 対応)
## どのような機能の開発・実装か
Google Play Pass というスマホゲームのサブスクリプションに本タイトルも参加することになり、サーバー側で Google Play Pass のサブスクリプションの状態を Google の API に対して問い合わせすることで確認してから、ログイン後のゲーム内機能を切り替えるような実装を行った。具体的にはアプリ内課金の機能を制限してアプリ内ストアでは日次,月次のアイテム受け取りのみを可能にするなど。
基本要件・機能要件はある程度チームリーダーが決めていたが、Google Developer API の挙動については自分で確認する必要があり、実際に開発用のアカウントを Google Play Pass に登録して API を叩いたり、Google 公式のライブラリのコードを読んで調査した。以上の調査に基づいて Google Developer API の挙動を十分に確認した上で機能実装を行ったため、新規の開発だったがリリース後の不具合は発生しなかった。
なお、開発時には外部 API への依存部分を mock してテストコードを書くようにしたかったため、自分で技術選定をして moq というライブラリを使用するようにした。moq は以前使用して非常に簡単に使えることを知っていた・また比較的有名なライブラリなので、プロジェクトに導入する際に抵抗感はなく、他の開発者にも受け入れてもらえた。
# 開発・実装内容 (ゲーム内施設の壁に配置するデコに関する機能開発)
## どのような機能の開発・実装か
ゲーム内では施設内、施設外でそれぞれ地面にデコを配置する機能がすでにあった。新規機能として壁にデコを配置することでユーザーの購買意欲を上げることができるという仮説をチームで立てて、ゲーム内の機能として実装した。
これも基本要件・機能要件はある程度チームリーダーが決めた状態で開発をした。壁に配置するデコには、壁紙と壁掛けの二種類のデコがあり、同じ種類のデコ同士では重なって配置することはできないが、壁紙の上に壁掛けのデコの配置は可能という要件があった。
DB のレコードとしては layer というカラムを追加して管理した。壁の境界や、左右の壁の切り替わる箇所があって、重なりの判定のロジックが複雑だったが、単体テストを書きながら実装することで、バグが発生しないように段階的に開発を行い、無事に障害なく機能をリリースすることができた。
# 改善活動
## 内容 (Changelogから差分を print するスクリプト)
サーバー側のコードを一定開発した後に、クライアントエンジニアにプログラムのパッケージを共有する作業があった。前回共有したコードとの差分も合わせて伝える必要があったが、他の開発者の内容も合わせて把握する必要があったため、差分を調べるのに少し手間がかかっていた。
この問題を解決するために、PR をマージするたびに編集していた Changelog を使って、前回のパッケージとの差分を出力する GitHub Actions のワークフローを作成した。
具体的には、サーバーのパッケージングも GitHub Actions で行っていたため、そのワークフローが実行されたタイミングで日時をGitHub Actions の変数として保持して、次回にもう一度実行した時にその日時の差分を見て Git で差分を取得するようにした。以上の開発によって、繰り返しのタスクのボトルネックを削減することができた。
改善活動なので、プロダクト開発の工数には計上しないで、隙間の時間でで簡単にスクリプトを書いた。GitHub Actions の機能として変数を使うために、GitHub App 設定が必要だったため、リポジトリーオーナーに依頼して設定依頼して最終的にスクリプトを実行できるように調整した。