Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

Akatsuki Hackers Labは株式会社アカツキが運営しています。

アカツキゲームスのインターンに参加して

はじめに

初めまして、アカツキゲームスのクライアントサイドのインターンに参加させていただいた斎藤と申します。

開発には2021/10/4~2021/10/27の期間、参加させていただいたきました。取り組んだことや感想などについて書いていこうと思います。

自己紹介

自分は、広島大学の修士1年で分散処理についての研究を行なっています。

趣味はゲーム&ゲーム制作です。サークル活動や個人などでUnityを使ってゲーム制作を行なっています。

趣味や研究での開発は行ったことはあるのですが、バイトなどの経験はなく業務での開発は今回が初体験でした。

行ったこと

自分は『八月のシンデレラナイン』(以下ハチナイ)の開発に参加しました。以下行ったタスクについて説明していきます。

放送部の一括既読機能

ハチナイには放送部というハチナイ関連のYouTubeのコンテンツや漫画などを紹介する機能があるのですが、そこに一括既読機能をつけたいというものでした。

放送部に類似した機能にお知らせという機能があり、そちらにはすでに一括既読機能がついているため、そちらの機能をこちらにも実装したいという需要です。

f:id:Aojilu08:20211027110941p:plain

f:id:Aojilu08:20211027110925p:plain

 

初めてのタスクだったので、最初は手探り状態で他人のコードを読むことに慣れていないものありコードを理解するのにかなり苦労しました。

ただ、お知らせの内容を放送部に移植すればよかったため、実装はあまり苦労せず実装できたかなと感じています。

このタスクは次の放送部の通知数タスクと一緒に行ったため状態についてはそちらで言及します

放送部の通知数と未読の数が異なっている件の対応

マイページには放送部のお知らせの中でまだ読んでいないものの数を表示する機能があります。この表示されている通知の数と、放送部の未読コンテンツの数が合ってないので合わせたいというのが課題でした。

f:id:Aojilu08:20211027111945p:plain

調査を開始し、未読数を取得する関数の処理を確認したのですが、未読の中で配信7日以内のものを通知数としてカウントするという処理になっていることがわかりました。

挙動を確かめてみると確かにそうなっていてちょっと感動...

意図のある実装であるためプランナーの方に報告して相談を行いました。

相談の結果、今回は通知数の挙動は変えずに未読数の方に合わせるという対応にすることになりました。言い換えると、配信後7日経過したものは読んでなくても既読をつけるということです。

実装自体はすぐに終わるものでしたが、仕様の決め方だったり、コミュニケーション面などでいい経験になったなと感じるタスクでした。

こちらの放送部系のタスク2種はレビューまで済んでおり検証待ちの状態です。

スカウトCMのテンポ改善

2つ目(実質3つ目?)のタスクはスカウトCMのテンポ改善を行いました。

新しいスカウトが追加されると、ログイン時に宣伝のアニメーションが流れるスカウトCMという機能があるんですが、このスカウトCMが複数存在する場合にテンポが悪くなってしまうのでそれを改善したいというのが課題でした。

スカウトの流れは以下のようになっています

「新選手登場!」→選手のセリフ→スカウトの紹介→ロード(複数ある場合は繰り返す)

今回具体的に行うこととしては

  • 「新選手登場!」を最初だけ表示するようにする
  • CMの合間にロードが入らないようにする

でした。

関連コードを読み進めたところ、スカウトCMを再生する機能にスカウトCMのデータを一つずつ渡していることが原因のようでした。

そのため、実装方針は以下のようにすることにしました。

  • スカウトCM再生機能にデータを一括で渡す
  • スカウトCM再生機能にもらったデータがなくなるまで再生を続ける機能をつける必要があるので、そこに2つ目以降はスキップする機能も追加する

そして実装。実装内容自体はそこまで複雑ではなかったため苦労せずに実装できました。ちょっとスキップの挙動が変になったりもしましたので修正もしました。

仕事でプログラマーをやっているとあんまりコードの量を書かないみたいな話を聞いたことがあったんですが、まさにそんな感じで、やっているタスクの消費時間だと調査>実装だと感じました。

ただ、実装が簡単に済んだのは設計が上手いことされていたからというのも感じました。ミーティングの際に、データを一括で渡すように変更するために根本の設計をいじらないといけないかも...みたいな話が出てたんですが、いざやってみると影響範囲が小さく済ませることができました。

このタスクの状態としては、検証まで完了しており10/29のアップデートに含まれるそうです。やったー!

実はスカウトCMのテンポは自分がゲームを遊んでいる時にも気になっていた箇所でした。なので担当できるのが嬉しかったんですが、実装されるともっと嬉しい...ゲーム会社で働くと楽しそうだなと感じるポイントでした。

Extraボイス入手時に何を手に入れたかわからない問題の改善

3つ目のタスクはExtraボイス入手時に何を手に入れたかわからない問題の改善です。

選手交流のページに選手ごとにミッションがあり、ミッションの達成報酬でボイスがもらえるという機能があります。このボイスについてはもらう前、もらった時ともにアイコンの表示しかないためなんのボイスをもらったのかわからないという問題がありました。

f:id:Aojilu08:20211027131051p:plain

f:id:Aojilu08:20211027131117p:plain

このタスクに関しては、最初は仕様が決まっていませんでした。そのため、まずはシンプルにアイコンの隣に名前を併記するという実装を行なってみて、それを確認して仕様を決めるという方針になりました。

実装として行うことは、新しいダイアログを追加することと各アイテムの名前を取得することでした。

新しいダイアログの追加は既存のダイアログ機能を参考にすることで実装することができました。ここでも追加のダイアログを追加しやすい設計になっていて、実装はスムーズにいきました。

アイテム名の取得の方はちょっと手間取りました。データの種類がたくさんあって、どれを取得すればいいのかわからないかったです。

ここはメンターの方に相談して、マスターデータ的なものがあるということを教えてもらいました。そのあたりを探索していると、プレゼントボックスの処理に各アイテムの名前の取得処理というまさに欲しい処理を発見できたため、それを真似ながら実装しました。

ということでアイコンにアイテム名を併記するという機能は実装できたんですが、確認したところ微妙でした。一度にみられるアイコンの数が少なくなってしまうなどの問題がありました。

仕様決定ミーティング

この実装が完了したところで仕様を決定するためのミーティングを行いました。ミーティングで話したこととしては、ボイス取得前の確認については今後実装予定の機能で対応できそうだということを話しました。そして今回の実装では、ボイスを取得した後に取得したボイスを確認できるように、ボイス一覧にnewアイコンをつけるという対応をすることに決まりました。

ミーティングの結果決まった実装内容は以下の通りです。

  • ボイス一覧にnewアイコンを表示
  • 既読セーブデータを消去するデバッグ機能の追加
  • データ引き継ぎの際に既読セーブデータが引き継がれるようにする

f:id:Aojilu08:20211027132926p:plain

まず、newアイコンの表示を行うために既読セーブデータを作成し、ボイス一覧の画面でそれを扱うという実装を行いました。ここは放送部の実装などでやったこととにていたためあまり苦労せずに実装することができました。

次にデバッグ機能の実装を行いました。デバッグ機能用のシステムを作成し、デバッグ機能の設定ファイルに追記するという実装を行いました。ここはとても追加しやすく作られておりかなり簡単に実装できました。

最後にデータ引き継ぎへの対応を行いました。こちらも変更は設定リストに1行追加するだけでした。ただ、引き継ぎコードに関しては少し懸念点がありました。

懸念点は、変更を加える前(=ボイス既読セーブデータ作成前)に作成された引き継ぎデータが引き継げなくなってしまうのではないか?という点でした。

コードを確認する限り大丈夫そうだったんですが、もし引き継ぎできなくなると大変なことなので実機での確認も行いました。ここで初めてjenkinsを利用したビルドなどを行いました。

実機での確認でも大丈夫だったためこれで実装完了となりました。

このタスクは始める前はあんまり大変そうじゃないと思っていたんですが終わってみると変更箇所が結構あってギャップを感じました。最初と比べると機能把握が早くなった感覚もありちょっと成長したかも?とか感じました。

このタスクは現在レビュー待ちの状態ですが、最終的に動作を確認して仕様に問題がなければリリースされると聞いています。

振り返り

インターンを終えての感想などを書いていこうこと思います。

学び

初めての経験が多く、学びになったことがたくさんあったなと感じています。

設計

自分はインターン前は設計の勉強をちらほらしてはいたんですがあんまり上達しないな...という状態でした。今回のインターンでは実際に運用されている設計をたくさんみることができたためすごく勉強になって、個人で作っていたゲームで早速真似してみたりしました。また、実際に使ってみた感想を持てるというのもいい経験だと感じました。実際に使うと、新しいものの追加がしやすくていい、機能が分離されていたから影響箇所が少なく済んだ、どこに機能を追加するのかわかりやすいなどの良かったポイントの感想を得ることができ、自分で設計する時に活きそうだと感じました。

良い設計ってなんですか?と言われると、今までは勉強した具体的でないものの例しか出せなかったんですが、今回の経験でこのインターンでやったあれです!みたいのことが言えそうだなと感じました。

また、どこまで設計するのかみたいな観点も学びでした。ハチナイのコードは似た処理でも実装が揃っていないこともあって、完璧なコードだ!という感じではなかったんですが、要所はちゃんとしているなと感じました。プロジェクトが破綻しない範囲でここまではちゃんと設計する。ここからはある程度勝手に実装するみたいな線引きがあるな〜と思いました。

責任

今までは、よくわからずにコピペで解決することがちょくちょくあったんですが、インターン中はそれをやるとやばいと感じ、自分が書いたコードは全て理解するようにしました。

レビューや検証でチェックはしてもらえますが、一番厳密にチェックできるのは自分なので責任を持たないといけないというのを感じました。

コミュニケーション

プランナーの方とのミーティングをすることがあり、プログラミングがわからない人とのコミュニケーションを体験することができました。

よく発生する観点として、機能の実現が可能か、どれくらいの期間がかかるのかなどの観点があること、何度もミーティングを組むと時間のロスになるのでできるだけ1回で仕様を詰めきること、タスクキルなどの抜けやすい細かい観点 などなど...色々学びがありました。

組織構造

アジャイル開発について勉強したことがあり、こういう状態が理想だ!こういう状態になるべきだ!みたいな話を理屈として知っていましたが、運用されているチームに入ることで、達成されている点とされていない点、達成が現実的でない点とできる点、達成が効果的な点とそうでない点みたいなところがちょっと感じられたかなと感じました。

と同時に経験値の不足も感じました。1つのチームを見ただけなのでデータ不足だよなとか、そもそもたくさんのチーム見るのは大変であるとか。

自分のやりたいこと

色んな人と関わることもできたため、自分がどんなことをやりたいか興味があるのかという点も理解が深まったと感じました。とりあえず興味あるかもと思った点を列挙。

  • ゲームの内容、企画職の仕事の一部
  • コードの品質とか設計
  • 効率的な組織構造
足りないもの

自分の足りない点も見えたなと感じます。コードを理解する速度が遅いとか、リファクタリングしたほうがいい気もするけど具体的にいいコードがどんなものなのか判断できないとか、設計能力不足とか...

また、就活とかでよく聞かれる得意な点というやつがあると便利なんだなというのも感じました。人より得意な分野があればそれだけ貢献できたりするみたいな...そういうのも伸ばしたい...

まとめ

とても学びの多いインターンで参加して良かったと感じています。

今回のことをこれからの活動にちゃんと生かしていきたいです。

3週間受け入れていただきありがとうございました!