はじめに

株式会社QualiArtsで内定者バイトとして働いている、24新卒ゲームクライアントエンジニアの初野広夢です。 「IDOLY PRIDE」（以下アイプラ）の開発には今年の2月から携わっています。

先日、2023年4月1日にアイプラ内にて実施されたエイプリルフール施策で、私が開発を担当した機能がリリースされました。 今回は、はじめてチームでのモバイルゲーム開発を通して学んだ事や感じた事を書こうと思います。　　

エイプリルフール施策の概要

アイプラのエイプリルフール施策では、「さとみアイドルデビュー」という施策を実施しました。 実装した部分に触れていく前に、まずはこの「さとみアイドルデビュー」について説明します。

さとみアイドルデビューとは？

さとみとは、アイプラに登場するアイドル達が所属する星見プロダクションという事務所の新米マネージャーです。

さとみアイドルデビューでは、星見プロダクションに所属する新米マネージャーのさとみが5人に分裂して、アイドルグループを結成するというお話になっています。

さとみの撮影機能

さとみの撮影機能とはその名の通り、さとみを撮影できる機能です。

アイプラにはアイドルたちを撮影し、「フォト」というアイテムとして写真を収める機能があります。 アイプラの撮影機能に関しては、本ブログより自分だけの写真がゲームで使える！ IDOLY PRIDE におけるフォト機能の仕組みにて詳しく解説されております。

さとみはアイドルではないため普段は撮影できないのですが、今回のエイプリルフールでは期間限定で撮影できるようになり、多くのユーザーに撮影していただきました。 私はさとみの撮影機能の内、「撮影したフォトを選択し、外部SNSへ投稿する」機能の実装を担当させていただきました。

実装

私は過去に個人ではゲームを開発した経験がありました。 モバイルゲームの開発はこれがはじめてでしたが、これまでの経験を活かしてより良いゲームにしようという思いで実装に取り掛かりました。

実装を始めて、QualiArtsの基盤周りの充実度は非常に高いと感じました。最初にソースコードを見た時は、その充実度に驚かされました。
たとえば、実装に入る前は画面を同時にタップすることの対策を取る事を想定していましたが、ボタンを簡単に実装できる基盤が存在し、実装者が対策を考える必要のない設計になっていました。
他にも、長押しなどゼロから実装すると少し手間のかかる要素も基盤化されており、簡単に実装することができました。

また、アイプラのUnity開発のソースコードではMVPパターンという設計思想を採用しています。
自分にとってMVPパターンはQualiArtsに所属してはじめて知る設計思想でした。ですが、本ブログのWeb出身のUnityエンジニアによる大規模ゲームの基盤設計を読むことでMVPパターンの概要を理解することができました。

そこから1~2日で基盤周りや設計思想に対する理解が進んだので、早速実装に移りました。
さとみの撮影機能は既存の撮影機能と類似した部分が多くありました。そのため元の実装を使い回せることも多かったのですが、既存機能との差分として次の機能を実現する必要がありました。

• 既存の撮影機能では、撮影した写真に写っているアイドルの信頼度が上がりそれに伴った演出が組み込まれているが、さとみは元々アイドルではないため演出が不要
• 撮影したさとみの写真をSNSに投稿できる機能（SNSへの投稿機能は元々別の場所で実装されているのでそれを利用できる）
• 写真が複数ある場合、タップした画像に選択中と表示する機能

少ない実装で済みそうで、簡単そうに感じる方もいるかもしれません。ですが、大規模開発は多くのメンバーが関わりかつメンバーの入れ替わりも発生するため、少量の実装でも自分勝手なソースコードを書いてしまうと、後々負債としてチームに悪影響を及ぼします。 私自身も2023年4月末で内定者アルバイトの就業期間が終わり、QualiArtsから離れることになります。そのため、ソースコードに関しても既存の設計思想に合わせる必要がありました。

実装に着手した段階では、これらのことを完全に理解してソースコードを書けてはいませんでした。その状態ながらも、既存のソースコードから不必要なものを削除したり、必要なものは付けて加えていくことで、とりあえず動く実装を組み立ててみました。ここまで環境を整えてから6営業日で完了しました。

プルリクエストレビュー

ひととおり撮影機能が動作するところまで実装を完了した段階で、プルリクエストを出しました。今までレビューを受けた経験も少なかったので、現場のエンジニアさん達からソースコードを読んでもらうのは非常に贅沢な経験でした。

アイプラのUnity開発ではGitHubでソースコード管理を行い、GitHub上でプルリクエストのレビューを行います。レビューでは2Approve制を採用しており、同じチームのエンジニア2人以上から許可をもらわないと、プルリクエストがマージされる事はありません。

プルリクエストを出した当初は大量のご指摘を頂きました。レビューを通じて、私が作成した「とりあえず動く実装」ではいけない事を理解し、処理を共通化して新しくMVPパターンでクラスを作成したり、設計思想に従った実装の再設計などを行いました。

何度も直してはご指摘を頂くことを繰り返したことで、Unityエンジニアとして大きく成長することができました。
実際に下記の画像が1つの機能についたコメント数（76件）なのですが、非常に多くのご指摘を頂きながらより良いコードへと改善していきました。

if文をコンパクトにすると良いという簡単な指摘からMVPパターンの設計思想に関する指摘まで、さまざまなコメントをいただきました。

これらの簡単な指摘から設計思想に関する指摘まで多くのご指摘を頂いたことで、技術力がとても向上した事を実感しました。 プルリクエストの修正対応は6営業日と十分な時間をいただいたので、これらの修正に専念して作業を行うことができました。私自身の成長にも繋がりましたし、今後新しいメンバーが使う上でも問題ない設計の実装をする事ができました。

バグ修正

実装がマージされたら、次はバグ修正に移ります。バグ修正では、デバッガーさんが発見して下さったバグを再現して、バグが発生しなくなるまで実装を直します。 ソースコード一行の修正で済むようなバグもあれば、修正に数時間を要するバグもあります。アイプラの開発ではバグの調査はデバッガーさんが行い、Redmineというツールで報告します。

Redmineから発行されるチケットにはバグの再現手順や再現動画などの情報が含まれているため、効率よくバグを修正できました。バグ修正に入った段階で次のタスクと同時並行になりましたが、ペースを落とす事なく、順調にタスクをこなすことができました。

リリース当日

リリースの瞬間までは、私の作った機能が多くのユーザーに触れて頂ける期待と、バグなく動くかどうかという少しの不安がありました。

当日を迎えてみると、私が作成した機能を使って多くのユーザーが「さとみアイドルデビュー」の感想をSNSに投稿されていました。その時、期待は喜びに変わり少しの不安も無くなりました。

当日の夜からユーザーの感想をSNS上で確認して、開発時には難しい実装なども多く苦労することも多かったですが、頑張った甲斐があったなと感じました。

おわりに

ゲーム会社に入るまでは、ユーザーの声をどの程度参考にして開発を行っているのかが気になっていました。 実際に現場で働いてみると、多くのユーザーの声を参考にしながら開発を行っていることを再確認できました。

ゲーム開発は大変なことも多いですが、多くの方に喜んで貰えるように、今後も頑張っていきます。