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

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

ユーザー数が大規模なゲームで負荷試験と改善をした話

はじめまして、7月5日から7月30日までアカツキのサーバーサイドでインターンをさせていただいた光枝と申します。 本記事では私が今回のインターンで取り組んだことについて共有させていただきます。

自己紹介

神戸大学理学部の学部3年生です。 普段は主にWebアプリケーションの開発をやっていて、サーバーは Ruby on Rails、フロントは React/Next (TypeScript) を書くことが多いです。 最近は Go や Kubernetes の勉強などもしています。

インターンの題材

今回のインターンで取り組んだ題材は「負荷試験」です。

私が携わらせていただいたサービスはユーザー数が非常に多いゲームでイベントや新しいガチャが実装された際にはサーバーにかなりの負荷がかかります。

そんな中で当ゲームはメジャーバージョンアップを控えています。 その際に

  • 今までの機能が重くなっていないか
  • 新機能が重くないか

を検証する必要があり、そのタスクにアサインいただきました。

検証方法

検証にはAWS上に構築した本番環境の数十分の1スケール(以後stress環境と呼びます)を使用しました。 手順は以下の通りです。

1. シナリオの準備

負荷試験には LOCUST という負荷試験ツールを使用しました。 LOCUST は locustfile.py というファイルにシナリオを書くことで、その通りに負荷をかけてくれるツールです。 (他にもアクセスするユーザー数や Hatch rate を設定し、結果を確認するためのGUIを提供しています。)

シナリオは例えば

ログイン → お知らせ確認 → ログインボーナス取得 → ...

のようにユーザーの動きを再現するように、各APIを順番に叩く処理を記述します。

バージョンアップに際して今回着目した新APIを叩く処理をシナリオに追記しました。 (ここではそのエンドポイントを POST /hoge として置きます。)

2. ローカル環境での実行

まず新バージョンがすでに動いている環境のデータベースをコピーしてきて、LOCUST をローカルで実行します。 ここで失敗し続けているAPIがないか確認します。

(例えば特定のAPIが失敗していた場合、そこで処理が止まってしまい想定していた負荷をかけることができなくなったり、その後に続く処理が実行されなくなってしまうのでここで確認する必要があります。)

3. AWS の stress環境に反映して実行

手元で確認が取れたら実際にstress環境で実行します。 stress環境にかかる負荷は

インフラの負荷 → Amazon CloudWatch

アプリケーションの負荷 → New Relic, LOCUST

で確認します。

実行結果

上記の 1 ~ 3 で負荷試験を実施してデータをみたところ、新APIに問題が見つかりました。

平均レスポンスタイム (ms)
POST /hoge 2090
1リクエストあたりのSQL実行回数
ActiveRecord Model2 find 396
ActiveRecord Model3 find 396
ActiveRecord Model4 find 18.3

これは N + 1 問題が起きていると考えられます。 なのでこれを修正して再度負荷試験を行い、どの程度改善されたかを計測します。

実は負荷試験を実施するまでにもいくつか苦労したところ (e.g. 「外部API のモック。これをやらないと外部サービスに対して負荷をかけてしまう」) がありましたが、今回は負荷試験の結果と改善に焦点を当ててお話させていただきます。

発生している問題

まず 「N + 1 問題とは何か」を簡単に説明します。

例えばユーザー(User)というモデルがあり、ユーザーがユーザーHoge (UserHoge)というモデルと関連があるとします。 また1ユーザーにつき、通常複数の UserHoge が関連しているとすると以下の図のような関係になります。

f:id:itsuki_mi:20210730180407p:plain

これらのデータが全て必要な場合にUserHoge が N 個あるとすると、このデータを取得するためにデータベースに N + 1 回 (1回は最初に User を取ってくるため) 問い合わせてしまうことを N + 1 問題と呼びます。

これらは本来、工夫することで 2 回の問い合わせですべてのデータを取得することができます。

今回の POST /hoge の問題も N + 1 問題だと予想されます。

調査

まず実際にローカル環境で API を実行して発生したクエリを再現し、該当コード部を読みました。 その結果以下のような構造になっていることが判明しました。

f:id:itsuki_mi:20210730181502p:plain

User が複数の Model1 と関連していて、Model1 は複数の Model2 と Model3 と関連があります。Model3 は 1 対 1 で Model4 と関連があります。 またこのサービスはデータベースを水平分散しており、「User, Model1, Model2, Model3」は同一のデータベース(Shard1)にありますが、Model4 だけは別のデータベース(Shard2)に保存されています。

これらのデータをすべて取得してくる必要があったため対策がない場合は

  • 1 ユーザーあたり N1 個の Model1 と関連
  • Model1 は N2 個の Model2・N3 個の Model3 と関連
  • Model3 は N4 個の Model4 と関連

としたとき合計で

N1 × (N2 + N3 + N4) 回

のSQLクエリを発行することになります。(ただし N1 個の Model1 はすでに取得済みとします。)

これが原因で POST /hoge は非常に重くなっていました。

修正に当たっての問題 その1

本サービスのサーバーサイドは Ruby on Rails で書かれています。 通常の N + 1 問題であれば includes メソッドを使うなどで解決できますが、今回の Model4 はシャードが異なるためワンライナーで取ってくることはできません。 Model3 から関連する Model4 を取る際にシャードを変更する必要があります。

この部分は以下のようにして解決しました。

Octoball.using(shard1) do
  ActiveRecord::Associations::Preloader.new.preload(model1s, [:model2s, :model3s])
end

model3s = model1s.flat_map(&:model3s)

Octoball.using(shard2) do
  ActiveRecord::Associations::Preloader.new.preload(model3s, :model4)
end

まず Octoball の部分でシャードを切り替えています。 以下のように記述することで #block の部分を指定の shard に接続した状態で実行することができます。

Octoball.using(shard) do
  # block
end

そこでまず Model2, Model3 まで shard1 に接続した状態で preload (ActiveRecord::Associations::Preloader.new.preload(model1s, [:model2s, :model3s])) しておきます。 そして preload した model3s だけ変数に参照渡しして、shard2 に切り替えてから残りの Model4 も ActiveRecord::Associations::Preloader.new.preload(model3s, :model4) で読みます。

このように記述することでシャードを跨いだ関連に対しても N + 1 を回避させることができます。

修正に当たっての問題 その2

全データの取得はこれで問題ありませんでしたが、それでも model4 だけ N + 1 問題が解決しませんでした。 理由としては、その後の model4 を使用する箇所で model3 のアソシエーションを使用していなかったためです。 実装は model4_id を用いて model4find_by するコードになっていました。

class Model3 < ApplicationRecord
  belongs_to :model4
.
.
.

  def model4
    unless defined? @model4
      @model4 = 
        if model4_id
          Model4.using(shard2).find_by(id: model4_id)
        end
    end
  end
end

なお model4 の関連付けがあるのに model4 メソッドが用意されているのは、毎回シャードを指定しなくてもよくするためです。 (また shard2 は動的に決まっています。shard2 は master/slave 構造を取っており、環境変数のAZを見て最適な slave を返すようになっています。)

上記の記述だとアソーシエーションを利用せずに model4 を取得するため preload したデータを使いません。 そこで以下のように条件を書き加えました。

class Model3 < ApplicationRecord
  belongs_to :model4
.
.
.

  def model4
    unless defined? @model4
      @model4 = 
        if model4_id
          if association(:model4).loaded?
            association(:model4).target
          else
            Model4.using(shard2).find_by(id: model4_id)
          end
        end
    end
  end
end

association(:model4).loaded? ですでに読み込まれているか確認して、true だった場合はその中身 association(:model4).target を返すようにしました。

改善後の結果

上記の改善を入れて、再度負荷試験を実施したところ以下のようになりました。

改善前の平均レスポンスタイム (ms) 改善後の平均レスポンスタイム (ms)
POST /hoge 2090 296
改善前の1リクエストあたりのSQL実行回数 改善後の1リクエストあたりのSQL実行回数
ActiveRecord Model2 find 396 1
ActiveRecord Model3 find 396 1
ActiveRecord Model4 find 18.3 1

完全に N + 1 が消えて、各 Model がそれぞれ1クエリで取れるようになったのがわかります。 また POST /hoge 自体もかなり高速化されました。

インターンでの学び & 感想

インターンに参加する前は負荷試験について言葉だけ知っている状態でした。

しかし実際に

負荷試験の準備(シナリオ作成、APIの失敗がないかのチェック及び修正、ローカル実行で確認)

stress環境で負荷試験実施

CloudWatch, New Relic, LOCUST でメトリクスなどを確認

問題があった場合は改善

再度負荷試験を実施して改善効果を検証

という一連の流れを体感することができました。

またシャードを跨いだ関連付けの取得やActiveRecord 内部の仕様についても理解を深めることができました。

実は事前面談で「インフラ系のタスクをやってみたい」とお話していてこのタスクを用意していただきました。

なので私がやりたいと言ったことをやらせていただき、また手厚いサポートのもとたくさんのことを学ばせていただきました。

約3週間本当にお世話になりました。ありがとうございました!!!

アカツキのサマーインターンに参加したお話

こんにちは。 7/5〜7/27までの3週間、アカツキのサマーインターンに参加させていただきました、あおやまと申します。 このインターンでは、「八月のシンデレラナイン」のサーバーサイドの機能改修・運用改善などの業務に携わりました。

ここでは、このインターンで取り組んだこと、学んだことについてまとめていこうと思います。

はじめに

自己紹介

通信制の大学に通う学部3年生です。 大学ではCS系のことを学んでいます。 普段はWebの開発をしており、インターン参加前はサーバーサイドというよりはフロントエンドよりのことをやっていました。

スペック

Ruby/Ruby on Railsは3週間ほどしか経験がなく、超基本的なことしか理解していない状態でした。(普段はPHPやTypeScriptを書いています)
自己紹介でも書きましたが、普段はWebの開発ばかりやっているので、ゲーム開発は初めてでした。

インターンで取り組んだこと

新規機能開発(断念)

雑談で上がっていた新規機能が面白そうだったので、ディレクターさんやプランナーさんにその機能を開発したいと相談しました。 その話し合いの中で、その機能を作る目的について聞かれました。 しかしながら、私はユーザーに対する目的しか浮かびませんでした。そこで、他にどのような目的が考えられるかを尋ねたところ以下のような回答をいただきました。

  • 実装に関するコスパが他のタスクを比較して良い(実装工数・検証工数が小さい)
  • キャンペーン・マーケティングに使える(実装タイミングでお祭り感を出せる)
  • 使える工数がある(そもそも手が空いてるのでなんかしたい)
  • チームの育成に役立つ(難易度が適切なので、チームの練度向上に使える)

「ほぇ〜〜」
実装に対するコスパ、マーケティング、チームの育成など今まで考えたことがないばかりだったのでとても学びになりました。

これを元にプランナーさんと話し合いをした結果、現状はこの機能は現実的ではないということで断念しました。

作戦変更

上記の新規機能開発は早い段階で断念する決断ができたため、その後は作戦を変更することにしました。

その作戦名は、

運用改善タスクを数こなしてみんなに感謝されよう作戦

です。 私が配属されたチームでは、手のつけられていない運用改善タスクが山ほどありました。そこで、それらを1つずつ片付けていきました。
運用改善タスクは、仕様が決まっているものもあれば、あやふやなものもありました。仕様があやふやな場合は依頼者に、「なぜこの機能が必要か」「この機能で検証したい部分はどこか」などの聞き込みが必要でした。そのような聞き込みをするのが初めてだったので、最初は何を聞いたら良いか分かりませんでしたが、複数タスクをこなすうちに、依頼者はどのような機能が欲しいかなどを感じたり、うまく聞き込みをしたりすることができるようになりました。(成長!)
結果、サーバーサイドの運用改善タスクはほぼやり切ることができ、数としては6つこなすことができました。

まとめ

良かった点

新規機能開発の一部を体験できたこと
断念してしまいましたが、話し合いを通じてたくさんの学びがありました。

運用改善でチームに貢献できたこと
運用改善チームの方から感謝されました^^

ゲームのサーバーサイドの中身を知ることができた
機能改修タスクや一部の運用改善タスクはゲームのロジックの理解が必要だったので、そこを理解しレビュアーとしっかり議論することができました。

エンジニアとして技術以外のことをたくさん学ぶことができた
ただ作るだけでなくなぜ作るかやどう作るかという考えや、エンジニア以外の方とのコミュニケーションなど個人では体験できないことを実際に体験し、そこからたくさんのことを学ぶことができた。

自走力が成長した
いい意味でメンターさんが私を放置してくれたので、自分からエンジニアやディレクター、プランナーさんたちにコミュニケーションを仕掛けたりと自走する力が成長しました。

今後の展望

オーナーシップを育てる
今回のインターンでは、自分がタスクのオーナー(それについて一番詳しい)になることが多々ありました。しかし、まだまだ自分がオーナーだという自覚が足りない場面がありました。これからたくさんの経験を積んで1つのプロジェクトを見れるくらいのオーナーシップを育てていきたいと思います。

リアルタイムのゲーム開発
参加前はゲームはするのは好きだけど、自分で開発するということは考えていませんでした。しかし、自分の好きなもの(ゲーム)を開発することはとても楽しかったので、もっとゲーム開発をしたいと思うようになりました。次はリアルタイムでやりとりが行われるようなゲームの開発もしてみたいです。

最後に

参加前はフルリモートで若干不安でしたが、参加してみると毎日メンターさんが1on1を開いてくれたり、朝会・夕会があったり、定期的に社内の方とランチ会があったりととても楽しくインターンを過ごすことができました。
とても充実した3週間を過ごすことができました!!

アカツキで「ハチナイ」のサーバーサイドインターンを体験しました。

はじめまして!ハチナイのサーバーサイドエンジニアとしてインターンを体験させていただきました、堀崎と申します。7/5〜7/27の15日間お世話になりました。

今回のインターンで開発したものとそこから得た学びを書いていこうと思います。 

自己紹介

名古屋大学に通う学部3年生です。

アプリ開発サークルに所属しており、普段はWebアプリを開発しています。サーバーサイドとしてRails、フロントエンドとしてVueを主に使っています。

今回はRailsでの開発がメインでしたが、普段使っていることもあり技術に対する不安はそこまでなかったです。

やったこと

管理画面の開発

最初は簡単なタスクとして、管理画面の機能追加を行いました。管理画面はActive AdminというGemを利用して作られており、初めて触りましたがすでにあるコードを参考にして難なく実装が出来ました。

ゲーム機能の改善

管理画面のタスクを終えてコードの全容が見えてきたところで、ゲームAPIの速度改善のタスクを引き受けました。改善点が明らかになっていなかったため、まずはログの調査から始めて改善策を練ることにしました。

ログの調査結果

以下の問題が判明しました。

  • N+1問題
  • 大量のdeleteクエリ

N+1問題に対する対策としてeager_loadすることにしました。そしてdeleteクエリに関しては一括で削除するメソッドを自前で用意することになりました。

改善結果

改善前はレスポンスを返すまでに約5.5秒かかっていた処理を約1秒まで短縮することができ、約80%の速度改善に成功しました。

運用改善

最後のタスクとしてプルリク作成時にファイル名をチェックするCIを追加しました。こちらはGithub Actionsに新たにjobを追加するだけだったので比較的速くこなすことができました。

インターンを終えて

3週間という短い期間でしたが、色々なことを学ばさせていただきました。

技術的な成長

今回のインターンでは、調査タスクを多く経験させていただきました。その中で公式のドキュメントを読み込んだり、GithubのIssueを探索したりとコードを深く追っていく力を養うことができました。

また、これまでに触れたことのないGemやCI/CD関連のツールにも触れることができ、保守性の高いシステムに関しても新たに学びを得ることができました。

チーム開発におけるコミュニケーションの難しさ

このインターンで一番苦しんだのがコミュニケーションだと言ってしまっても過言ではありません。これまで小規模の開発しか経験してこなかった僕にとって、自分の思っている実装方法を人に伝えることは非常に困難に感じました。言葉足らずで自分の意思が正確に伝わらず、メンターさんを困惑させてしまうことが何度かありました。自分で改善することが難しかったコミュニケーション能力に関して、ご指導してくださったメンターさんにはとても感謝しています。まさかエンジニアインターンでコミュニケーション能力が養われるとは思ってもいませんでした。

おわりに

15日間あっという間に過ぎてしまいましたが、非常に有意義な時間を過ごすことができました。メンターさんをはじめ、たくさんのサポートを本当にありがとうございました。

アカツキ社内の雰囲気について、皆さんが楽しそうに話されている姿からアカツキという会社がより一層魅力的に見えました!

短い期間でしたが、本当にお世話になりました!

アカツキのクライアントサイドインターンに参加しました

初めまして、アカツキのクライアントサイドのインターンに参加させて頂いた植村と申します。

 

今回、7/12〜7/30の13日間、開発に参加させていただいたので、取り組んだことや思ったことについて書いていこうと思います。

 

はじめに

自己紹介をします。

私は今、早稲田大学修士1年でVRについて研究しています。

趣味はゲームをプレイすること、制作すること、それからロボットです。

将来はゲーム開発に関わる仕事を志望しており、今回はUnityエンジニアとして参加させていただきました。

 

取り組んだこと

僕が参加したのは、「八月のシンデレラナイン」(以下ハチナイ)の現場でした。

そこでメンターの方と話し合い、主に選手交流周りの改修を任せてもらえることになりました。

それぞれタスクについて書いていきます。

 

選手交流で悩み解消前のテキストを読めるようにしたい

インターンで初めて取り組んだタスクです。この悩み解消前テキストというのは、選手育成から解消してしまうとゲーム内で見る手段がなくなってしまうものでした。それに対し、選手交流における悩み解消時再生エピソードに付随させられるようにするというタスクです。

f:id:utaishi:20210730182734p:plain

まず最初に行ったのはデザイナーさんとプランナーさんとの会議です。そこで仕様を決め、実装に移りました。

実装をする中で現場で作られてきたコードに触れながら、理解を深めました。

コードの意味や実行速度について、ここまで深くやったことはなかったのでとても良い経験になりました。

 

この機能の中で特に苦労したのは、ストーリーのエピソードのIDから悩み解消前テキストをマスターデータから検索してもってくるところでした。

結果としては

エピソードのIDに一致する悩み解消時エピソードを持つシーンのスキルを検索

→そのシーンのスキルを持つ悩みを検索する

→悩みが持つテキストを取得

という流れだったのですが、マスターデータの関係が複雑で、どこにどの情報が入っているのかを理解するのに時間がかかりました。

 

ここで思ったのは、自分が欲しい情報、データがどこにあるのかをコードから予想して見つけてくる力がとても重要なんだな、ということでした。

他の人が書いたコードを読むときの考え方というものをこのインターンを通じて知ることができました。

 

その後も一度会議をして、アイコンの追加などが決まりました。

自分からは表示するダイアログのタイトルを悩み解消前のスキル名にすることを提案し、実装することになりました。

 

実装してPR→レビューの流れを何度か繰り返し、実機確認もしてなんとか終えることができました。

 

f:id:utaishi:20210730182658p:plain



最後に検証さんの方に機能の検証依頼を出して終了です。

仕様決定から検証依頼までの流れを一通り体験できてよかったと思います。

 

選手交流の詳細で、隣の選手に移動したい

次のタスクは、選手交流の各選手に遷移した時、そのまま別の選手に移動したいというものでした。

プランナーさん、デザイナーさんと会議をした結果、ボタンとスワイプで移動すること、選手の並びは選手交流トップに倣う形にすることが決まりました。 

f:id:utaishi:20210730182821p:plain

まず最初にやったのは、隣の選手へのスワイプ機能、ボタンの機能の実装です。

ハチナイにおいて、似た形のスクロール処理はいくつかあり、今回はその中からデレストのオーダー選択と選手交流トップのスクロールを参考に作ることにしました。

 

機能について理解しながら、基本となる部分は実装できました。

が、気になる問題点がいくつか見えてきました

 選手の切り替えで読み込み時に、選手とメニューが一瞬消えてから表示されるのを改善

もともと動かすことを優先してシーンが開始する時の処理を毎回呼び出していたが、必要なものだけに絞って、メニューが消えるのを阻止しました。

 

スクロール完了と共に、スクロールを中心に戻しつつ、選手を表示するGameObjectの位置を交換することで更新時、選手の読み込みを新たに増えた一人分だけにするようにしました。

これにより、選手の更新は画面外のみで起こるようになったので、選手が消える問題も解決しました。

 

隣の選手へ遷移するのに必要なスワイプの移動量の調整

もともと参考にしていたスクロール処理では隣の選手との距離の半分を超えてドラッグしていたら移動という感じだったのを、距離に対するスワイプの移動量の割合を、あらかじめ設定した閾値を超えるかどうかで判定するようにしました。調整をできるようにするとともに、閾値を大幅に下げました。

 

選手交流の円環リストに対応する

選手交流トップにおいて、本校では有原と草刈がつながる形の円環のリストとなっています。対して、コラボ選手、ライバル校は手に入れない限り人数が少ないので、その場合同じ選手が画面に並んでしまう事になります。

それを避けるため、本校以外のカテゴリーには端があります。

 

このようにカテゴリーから対応を変える処理をするためにプレイヤーが所持しているカテゴリー別の選手のリストを作る必要がありました。

選手リストはマスターデータから持ってくることになりますが、コラボとライバル校のどの選手を表示出来るかを知るには、APIを叩く必要がありました。

選手交流トップの方でこの処理をしてカテゴリー別所持選手リストは生成されている上に、選手交流詳細では選手交流トップで使うリストと同じ選手の並びを使いたいということもありました。なので、もうあるのならばそれを使わせてもらおうということで、円環リストは選手交流からシーンの遷移時に渡してもらうことにしました。

 

選手交流詳細から絆アルバムと信頼度のページに行った後、戻るボタンで戻ると正しい選手に戻らないことがある問題の改善

スワイプでの移動は関係なく、選手交流詳細のページに入った時の選手になるので、戻るボタンに選手交流詳細から来た時のみ、どの選手に帰るか指定する関数を渡しました。

円環リストを生成する中で、リストも渡さなくてはいけなくなりましたので、シーン遷移時にリストを持っていない場合、APIを叩いてリストを生成するようにしました。

 

その他にも作業する中で、確認していると、気になる点や機能の追加によって動かなくなる点をいくつか見つけました。ページのスワイプがボイスや課題メニューの時に出来てしまうことや、スワイプ後に表情がリセットされていないことを発見し、メンターの方に報告して修正を行なっていきました

 

この機能では、機能実装→レビューなどで問題点を発見→修正を多く繰り返しました。

最初はコードを見て、仕様通りになるように実装するのが精一杯といった感じでしたが、繰り返すうちにだんだん自分で問題点を見つけて、共有し、修正するということが出来る様になって成長を感じることが出来ました。

 

振り返り

インターン中に思ったことや感想について書いていきたいと思います。

 

開発が進んだ現場に入るという体験

朝会、夕会は雑談から入るのですが、毎回様々な話題で盛り上がっていて雰囲気が良いな、と思いました。その後は、共有事項などについてしっかりと話し合っていてメリハリがあるなと感じました。和気藹々としながらもやるべきことはちゃんとやって、全員がゲーム開発チームの一員だと思って仕事をしているのを見て、こういう風に働きたいなぁと思ったりしました。

 

Gitの使い方(PRの出し方やブランチの分け方など)やリポジトリの使い方など小規模開発では、意識しない所で数多くの工夫が見られ、驚きました。

他者が書いたコードを読み込むという経験をあまりしてこなかったのですが、他者のコードを読む際には、ただ漠然と理解しようとするのではなく、自分が今何を知りたくて、その情報はどこにあるのかを考えながらコードを読むことが、大事なのだと気づかされました。

 

現場の雰囲気や大規模開発のコードの読み方は、このインターンに参加しなければ得られなかった貴重な学びとなりました。

 

他の職種の方との会議

ゲーム開発においては、各職種が連携して作り上げて行くというのはもちろん知っていましたが、どのようにそれを成すのかは、あまりイメージができていませんでした。

今回インターンに参加してみて、そのことについて実感が湧きました。これも参加してみないと分からない点だと思うので実感できたのはとても良い経験になりました。

 

大きなゲームの中の機能を作る楽しさ

私のゲーム開発の経験は大体が半年後に向けて動くゲームを作るといった短いスパンのものでした。そうした場合まずは最低限動くものを目指すこととなり、小さな、完成度を高めるための開発の経験が積めていませんでした。

こういう経験を積めるのは、もう既に動き出しているプロジェクトに参加したからこそなので、知ることが出来て良かったです。

 

大きな一つのゲームの中で、自分の実装した機能が動いているという喜びは初体験でしたが、とても良いものでした。

 

反省点

もともと用意されていた課題のうち一つを達成できなかったことです。これの原因は、必要な情報がどこにあるのかを予測し、調べるのに手間取ったことと自分が今何で詰まっているのかをメンターさんに上手く共有できなかったことだと思っています。

自分で調べることはとても重要なのですが、実はちょっとしたことで詰まっているということがインターン中に結構ありました。

悩んでいることをただ書いておいて、手が空いている人が見てアドバイスをする、という場所がちゃんと用意されていたのに上手く使えていなかったなという反省点があります。

これからは作業に没頭するのではなくて考えをアウトプットするのをもっと意識して開発したいと思います。

 

まとめ

反省点はあるものの、ゲーム開発の現場についてよく知ることができ、チームで一つのゲームを作るとはどういうことかを知ることができました。

現場で使われているコードに触れたおかげで、コードを読む力、書く力共に大きく成長できたと思います。

やはりゲーム開発は楽しいです!

 

たくさんの収穫を得られた良いインターンでした、3週間受け入れてくださりありがとうございました!

【LT会】Akatsuki Geek Live 2021 開催レポート!Vol.1

みなさまこんにちは!アカツキ新卒採用担当のこさだです。

7/12(月)に、23年卒業の学生さま向けイベントの第1回目として「Akatsuki Geek Live2021 Vol.1」を開催しました!

前回は2月に開催をしたのですが、卒年が変わって今年度としては初開催!どれくらいの方にお集まりいただけるだろう・・・と不安に思っていたのですが、なんと前回を大きく上回る約90名の方にご参加いただきました〜!(888888888)

コロナ禍のため今回もオンラインでの開催です。オフィスに来ていただけないのは残念ですが、こうやって気軽にご参加いただけるのは良いところかもしれません!

当日はアカツキのメンバーだけではなく、内定者や一般の学生さんもご登壇いただき、イベント名の通り、非常にギークで濃い、技術の話が飛び交う会だったので、ご視聴いただいた方も楽しんでいただけたのではないでしょうか?

今回の投稿は、イベント当日の様子をレポートしたいと思います!
当日使用した発表資料も閲覧できるようにしていますので、少しでも雰囲気を味わっていただけると嬉しいです!

「Akatsuki Geek Live」とは?

エンジニアを志す学生さんと、アカツキエンジニアが登壇するLT会です。フリーテーマで7分間のLTを実施、その後懇親会を実施し、交流の場を設けています。楽しみながらアカツキのことを知れる場、そして学生さん同士の横のつながりも作れる場として実施しております。

 

▼イベント概要はこちらから

aktsk.connpass.com

「Historie(ヒストリエ)」と名付けられたオフィス内の図書スペースより、WEB配信の形式でお届けしました。

f:id:megumikosada:20210305123234j:plain

Historie

(こちらが会場です。詳しくはHPに掲載しています!)

 

司会は採用担当の「もりしま」と、エンジニアの「しまむら」が担当しました!しまむらさんは最早レギュラー出演で、前年度からパーソナリティーとして盛り上げていただいています。もりしまさんは今回が初出演。発表もあり、とっても緊張していたようです^^

そんなもりしまさんからのアカツキの紹介発表、アカツキのエンジニア4名、学生4名の合計9名が登壇するLT会が始まりました!

ここからは当日の発表資料も交えてご紹介します。

 

当日の様子

@もりしまさん(アカツキ/採用担当)
なるほどよくわかる!アカツキ理解のヒント 

トップバッターはエンジニアの採用を担当しているもりしまさん。
アカツキの会社説明に加えて、就活についてやインターンシップが多数行われている夏の過ごし方についての発表でした!ただ過ごすのではなく仮説検証を、というのが印象的でしたね!とっても緊張した〜と後日談で話していましたが、私には全然そんな風に見えなかった・・・!
【登壇資料】

 

▼@JPさん(アカツキ/クライアントエンジニア)
ハイパーカジュアルゲームの企画から全世界リリースまで

エンジニアのトップバッターはアカツキでクライアントエンジニアをしているJPさんです。
HCG(ハイパーカジュアルゲーム)ってなんぞや?というところから始まりましたが
「ゲームジャンル」ではなく、「ビジネスモデル」だ。という話が興味をそそる内容でした。利益を最大化するために企画、分析検証、実装を爆速で回していくので、エンジニアとして企画できると最高のものができるという熱いメッセージがとっても素敵でした〜!

【登壇資料】

 

▼@すぎやんさん(アカツキ/サーバーエンジニア)
サーバエンジニアが新卒研修でUnity使ってHCG作った話

年度違いのHCG繋がりです!すぎやんさんは2021年の4月入社。6月に研修を終えたばかりでしたので、その研修でのお話をしていただきました。先輩後輩、サーバーサイドとクライアントサイド、違った目線でのお話で面白かったですね!研修とはいえ、実際に予算をかけてリリースまで行うことで、「ものづくり」を経験していただくための研修。素敵に研修について発表していただいたので、きっと研修担当チームは喜んでいたと思います(涙)

【登壇資料】

 

▼@白狐さん(学生/アカツキ22卒内定者)
タイピングガチ勢、タイピングゲームを自作する

お次は学生から、白狐さんに発表していただきました。まずは、社会人に混じっての登壇に手を挙げてくださったことに感謝感謝です!(888888888888)
そして、自分が好きだから、作ってしまうという、その情熱に感服しました。当日は実際に公開しているゲームのURLもお伝えいただき、大いに盛り上がりました!

【登壇資料】

 

▼@たむさん(学生/アカツキ22年卒内定者)
Houdiniによるツタの動的生成

続いても内定者である学生のたむさんに発表していただきました!
連続して作りたい、だから簡単に、でもリアルにできたらいいのにな・・・という要望を叶える技術の紹介でした。「こんなこといいな、できたらいいな」からいろんな技術は生まれているんだろうな、と想像してしまいました。

【登壇資料】

 

▼@ふじさん(一般学生)
ディープラーニングで作るバッハの音楽

休憩を挟んで後半戦です。アカツキのLT会は就活サイトなどで告知をさせていただき、視聴者と登壇者を募っているのですが、いつも登壇者は現れず・・・なんと今回、一般応募からふじさんが手を挙げてくださいました!
内容も、自分が幼い頃から触れてきた「音楽」と技術を掛け合わせたもので、視聴者のみなさんからもチャットで質問や感想が飛び交っていました!
【登壇資料】

 

▼@ゆーゆーさん(アカツキ21年秋入社予定)
mXparserとInternalsVisibleToを駆使して超便利なUnityエディタ拡張を作った話

続いては、あと数ヶ月後に入社が決まっているゆーゆーさん。アカツキメンバーからもチャットで質問が飛んでいましたね!私はエンジニアではないのですが、「こうなったら便利なのになあ」と日々思うことがあって、それを「まあいいか」で終わらせるのではなく、技術の力でどうにかできるのでは?さらに、途中で壁があっても、なんとかなるのでは?と試行錯誤して実現させたゆーゆーさんの行動力や探究心、見習いたいなあ、と思いました!

【登壇資料】

 

▼@やすさん(アカツキ/サーバーエンジニア)
公衆無線LANを構築してみた話

司会のしまむらさんからもコメントがありましたが、普段何気なく使っている技術に疑問を持って、分解して作ってみるってすごく素敵な心意気だなあ。と思いました。もちろん技術はどんどん進んでいるのですが、当たり前のように受け取っていると気が付かないこともたくさんあるんだ、と改めて感じました!

【登壇資料】

 

▼@いたみんさん(アカツキ/クライアントエンジニア)
プロジェクトでの運用改善について

最後にいたみんさんより発表です。技術!という話ではなく、アカツキのクライアントエンジニアがプロジェクト内でどんなことを考えながら仕事をしているのか、実際にどんな業務をしているのか、という内部のお話を聞かせていただきました。参加いただいた学生さんは会社で働くということがどういうことなのか、イメージがかなり膨らんだのではないでしょうか?

【登壇資料】

 

 

 #最後に懇親会!(質問受付会)

今回は登壇者が多かったこともあり、中身の濃いLT会になりました!少しお疲れ気味かな・・・と心配したのですが、エンジニアの皆さん、やはり技術の話となるとそんなこともなかったようで、登壇者への質問もたくさんいただき、LT会後の懇親タイムも大いに盛り上がりました!

オンライン配信だったので、少し一方的になってしまい、意見を交わすことや、直接お話することができなかったのは残念ですが、今回のLT会が、エンジニアの皆さん、エンジニアを目指す皆さんの新たな発見や、一歩踏み出すきっかけになっていればとても嬉しいです! 

世の中に平穏が戻り、次回は直接お会いしながらギークなお話ができることを祈っています。

ではまた次回お会いしましょう〜!