Akatsuki Summer Internship 2020 成果報告

こんにちは、はじめまして！🙋‍♂️

Akatsuki Summer Internship 2020 にサーバーサイドエンジニアとして参加させていただいた kimujun です。この記事ではインターンの活動報告をまとめます。

ちなみに Summer Internship といいつつ、参加したのは 10 月初旬~中旬の三週間でした。ギリ夏ですね (？)

活動内容

アカツキはモバイルゲームの会社として有名です。私も例に漏れずアカツキの提供するモバイルゲームの開発に携わらせていただきました。

いろいろな開発を経験させていただきましたが、主にゲームの新規機能開発とアプリケーションの性能改善の二軸の活動となりました。この記事では以下のような章立てで活動報告をします。

1. ゲームの新規機能開発
2. アプリケーションの性能改善 ~ボトルネック発見編~
3. アプリケーションの性能改善 ~実際の性能改善編~

なお、自分が参加したプロジェクトではサーバーサイドの言語として Ruby on Rails を採用していました。

 1. ゲームの新規機能開発

すでに何年か運用実績があり、アプリケーションコードがかなり大きなプロジェクトに新規参入 & 新規機能を開発していくにあたって、以下のような点が難しいと感じました。

• ドメイン知識不足により、影響範囲が分からない
• コードベースに対する理解が乏しく、どこにどのような処理が書いてあるか分からない

1点目について、仕様書を読めばある程度は背景がつかめますが、影響範囲については理解するのが難しいです。例えば新規機能に必要な新しいデータをクライアントに送りたい場合、テーブルにカラムを追加するのはいいですが、それに伴う影響範囲をソースコードから全て洗い出すのは至難の技です。

これを解決するために、テストを修正しながら影響範囲を一つ一つ潰していくという作戦をとりました。

細かく分割されたテストを書いている場合、カラムを追加したことでアプリケーションに影響がでる部分についてはテストがちゃんと落ちてくれます。どのように落ちているかを見ながらアプリケーションを直すことによって影響範囲を洗い出すことができました。

開発に慣れてくれば、メインの変更箇所を見ながら他の修正箇所の当たりをつけて見にいくことができると思いますが、開発初期段階ではかなり有効な手だと思います。変更に強いアプリケーションのためのテストはこういう面でも有用ですね 😉

2点目について、幸いにも Rails にはスタンダードなディレクトリ構成があるので、大体どこにどのレイヤーのソースコードがあるかは見れば分かります。一方で、例えばたくさんある Model の中でどのような処理が共通部分として切り出されてるか、といったような処理レベルの分離方針についてはパッと見ただけでは把握が難しいです。

これを解決するために、メインフローの処理について一度隅から隅まで目を通すという作戦をとりました。アプリケーションの核となるメインフローの処理については綺麗な処理が書いてると信じて読んだ結果、コードベースに対する理解がかなり深まりました 😎

これらの内容をメンターさんと一緒に進めながら開発をすすめ、無事新規機能を最初から最後まで作りきることができました！ここでその内容を話せないのはちょっと残念ですが、実際にリリースされるまで楽しみに待っていようと思っているところです。

2. アプリケーションの性能改善 ~ボトルネック発見編~

Rails の大きな特徴として Active Record があります。Rails では Active Record を用いることによって DB 操作を意識することなく Model レイヤーの処理をサクサク書いていくことができます。

一方で Rails アプリケーションで起こりがちな問題として N+1 問題があります。N+1問題の詳しい解説は他に譲りますが、簡単に言うと不要なクエリが大量に発行されてしまう問題です。

この問題を放置するとリクエストのレイテンシが大きくなり、性能が悪化していきます。見つけ次第駆除したいです。

参加したプロジェクトでは N+1 問題の発見に New Relic を用いていました。New Relic はアプリケーションやデータベースのトランザクション性能をモニタリングできるツールです。

アプリケーションコードのなかで SDK を読み込めば、リクエストごとにどのような SQL が何回呼ばれているかが手に取るように分かります (これはまじですごい)。N+1 問題が発生している箇所は不自然に大量のクエリが発行されていることが見て取れます。

インターン中に行った N+1 問題改善タスクでもこの New Relic を活用し、どのような内容の N+1 問題が発生しているかを理解することができました ✌

3. アプリケーションの性能改善 ~実際の性能改善編~

 Rails において、N+1 問題は事前に必要なデータを読み込んでおくことで解決することが多いです。

前述のような不要なクエリを発生させてしまうコードは以下のようなものです。

Active Record の preload や eager_load を用いて事前に cats をロードし、N+1 問題の発生を解消することができます。

実際にアプリケーション内部でこのような実装を行い、N+1 問題を解決することができました ✌

インターンの感想

今回のインターンは全てオンラインで活動を行いました。全てリモートの環境でチームの人等と気軽に話せるようになるか心配でしたが、ホストチームのみなさんや人事の方々の (かなり) 手厚いサポートのおかげで、ほとんど不自由を感じずにインターンを終えることができました。ありがとうございました！

開発を通じて、Rails のコードに関する考え方やインフラのリソースに関する考え方から、技術面の細かい Tips やスクラムをうまくやっていくための Tips に至るまで本当に様々なことを学ぶことができました。

夏のインターンに参加することを考えている学生さんにはとてもおすすめです。

以上活動報告でした。改めて、アカツキのみなさまありがとうございました！

株式会社アカツキでのインターンを終えて

はじめに

初めまして。アカツキでのインターンシップに参加させていただいた東正太と言います。

関西の大学３年生で、中二くらいからゲーム開発を趣味で行っています。

今回のインターンシップについて 

今回はC++とcocos2dxを使うプロジェクトでクライアントエンジニアとして３週間のインターンシップに参加させていただきました。

僕の目論見としては、C++をせっかく触るならつよつよエンジニアになろう！と考えていました。 

今回のインターンはテーマは「開発メンバーが喜ぶデバッグ機能を作ろう！」という、非常にざっくりしたテーマでした。

今回のインターンシップでやったこと

・デバッグ機能の改善要望を聞くため検証チームと会議を行いました。

・会議で出た要望を課題とし、解決方法を模索、検討し仕様を決めました。

・仕様や設計をエンジニアさんたちに共有しレビューしてもらいました。

・機能を実装しプルリクエストを出してブランチにマージしてもらいました。

こういう流れで３つのデバッグ機能を作成・改善しました。

客観的なまとめ

実際に開発メンバーが使える機能を３つ開発できたのはとても良かったと思います。

また、リモートながらエンジニア以外の人やインターン生など多くの人と関わることができました。

個人的な今回のインターンの感想

具体的な指標がなかったため、自分で課題設定を行い、スケジューリングを行い、課題を解決していく必要がありました。

そのため悩みや選択が多かったですが、解決することで多くのことを学べたと感じています。

起こった問題

・実機ビルドが動かない　・自己肯定感　・進め方がわからない　・タスクを同時並行で進めてしまった　・会議の内容が理解できなかった　・相談するのが遅くなってしまう　・できないタスクに執着してしまった　・見積もりで実装しすぎてしまった　・発表がうまくできない　・朝からスピーディに仕事ができない　・偉い人が誰かわからない　・共有のための資料を不必要な箇所まで作ってしまう

多くの問題が起こりました。この後でいくつか紹介します。

会議の内容理解できなかった問題について

僕がエンジニアとして検証チームのデバッグ機能改善要望を聞き、返事をする会議がインターン３日目にありました。

しかし、僕は開発体制が整っておらず、デバッグ機能に関しての知識がほぼありませんでした。そのため、要望に対してエンジニアとして回答ができない状態にありました。

ここで要望に対して自分の頭で意図を読み取って作業を進めていくことが大事だということを学びました。

また、会議では理解できなかったところを後から質問して解決しました。

メンターさん神話について

会議中にメンターさんから機能を変更しようと考えていた一つの要望に関して提案

「機能を変更するではなく元の機能を使っている人もいるかも知れないから追加でいくといい感じだと思う」

個人的には両方の機能はいらないと感じていたのですが、メンターさんのいうことなので従いました。

仕様書を書き、エンジニアさんに共有したところ、エンジニアさんが

「いや、片方で十分じゃない？」

との発言でした。

僕はどっちに従えばいいかわからなくなってしまい自分の中で意見が右往左往しました。

ここで、気付いたことがあります。

仕事をしていく上で、メンターさんなど人の意見にそのまま従うのではなく、意見を参考にしながら最終的には自分で考えて判断しなければといけないということです。

僕は「前の機能が消えると困る人がいるか」を確認し、いなければ機能を変更することを決め、検証チームに質問したところ困る人がいませんでした。

その結果、実装範囲とスケジュールを決めて自分で実装することができました。

タスク同時並行問題

４日目から、会議で要望が出たものに対して改善案を見積もりする工程に入りました。タスクがどれだけかかるのか、どの方法なら仕様を満たす機能を実現できるのかを見積りました。

実装部分のコードを見たり追加しながら実現難易度や実装にかかりそうな日数を考えました。

僕は一つのブランチで見積もりを行いました。これが、後々問題を引き起こしてしまいます。

仕様書とブランチの失敗

見積もりの段階である程度実装の目処が立ったため、実装がほぼできたところで次に仕様書を書き始めることにしました。

実装がほぼできている機能に対して仕様書を書いたのですが、スクリーンショットがあるとより説明がしやすいと感じたため、３つ中２つの機能の実装を完成させてしまいました。

仕様書を共有し、仕様変更を行いながら実装を始めました。

しかし、先ほど一つのブランチで作業していたため、見積もりが終わっていないタスクと仕様書の実装を始めたいタスクの内容が同じ場所にありました。

そのため、スタッシュを知らない僕は全部を別のブランチで切り替えることでしかブランチの移動ができませんでした。

その結果、見積もりが終わっていないタスクが残ってしまうため、実装したい内容自体は完成しているのにコミットやプルリクエストが全然できない人になってしまいました。

PR、そして見積もり２つを同時並行で行う

なんとかプルリクエストを出し、見積もりとPRの修正タスクを同時並行で行いました。

PRの修正タスクのプッシュが終わったと同時にブランチを切り替え、見積もりを行ってビルドを行う、そうするとまたPRの修正が届いている・・・

ブランチを切り替えるたびにビルドが約20分かかるのもあって、暇な時間が増えてしまいました。

暇な時間をなんとか無くそうと、さらに実機でのデータダウンロードと新たなタスクの見積もりを始めました。

こうすることで４つのことを同時並行でやることになってしまい、頭が回らないまま数日が過ぎてしまいました。

ようやく解決へ

行き詰まった僕はメンターさんと話し、いくつかのことを教えてもらいました。

まず、同時に複数のことをしないこと。集中力や理解が必要な作業ほど、頭を切り替えるのに時間や気力などのコストを必要とします。このコストが大きくなり過ぎてしまうと、仕事の効率が大きく下がってしまいます。

次に、ブランチ運用について。複数の仕事をする際にはブランチを分け、スタッシュやリベースなどと言った運用で切り替えをしやすくすること。Gitを使用するメリットを意識して作業をしていくべきです。

また、実装できたということはタスクができたということではありません。単に動作確認ができただけで、自分が見積もりの段階でできたことなのに時間を使っていると少し落ち込んでたことは必要ないことだとわかりました。

問題を乗り越えた結果

僕はこうしてほぼ全ての問題を解決したことで、失敗したように思えた多くの出来事から成長を重ねることができました。自分で考えたり時にメンターさんや社員さんに気づかせてもらったことも多かったです。

多くの問題を解決し、成長を感じられた理由として大きいなと感じたのは

・メンターさんの毎日の1on1で質問や相談をさせてもらったこと

・他の部署の社員さんともランチなどのタイミングで交流が多くできたこと

・リモートでの労働環境や雰囲気に関して社員とかなり似た条件で働かせてもらえたため、イメージがつきやすかったこと

・機能を使ってもらえる人とコミュニケーションがとりやすくてFBや意見がもらえやすかったこと

でした。

しかし、

・リモートオンリーだったので直接話せなかったことだけでなくオフィスの雰囲気を掴むことができなかったこと

・他の人とコミュニケーションの取り方にコストがかかったこと（「画面をパッとに見せて会話」などができない、雑談が難しいなど）

・作った機能で開発メンバーが喜ぶ顔が見れなかったこと

などが心残りでこれらが実現されればもっと成長につなげることができたのかなと考えています。

これからやってくこと

今回のインターンで学ばせてもらった知識やツール、技術などを自分の開発にも生かしたいと考えています。

また、就活においてもゲームエンジニアとして働くことのイメージがついたので、もっと他の会社と比較して良い企業を見つけていきたいと考えています。

Akatsuki Summer Internship 2020に参加してきました

こんにちは！初めまして。にー兄さんです。

この度、8/3～8/21の3週間でアカツキのAkatsuki Summer Internship 2020に参加して参りましたので、その報告をしたいと思います！

概要・インターン参加以前

インターン業務の具体的な内容説明に入る前に、ちょっと前置きを挟みたいと思います。

インターンの概要

アカツキのインターンには、3週間の就業型インターンである「Akatsuki Summer Internship」と 2日間で行われるゲームジャム形式の「Akatsuki GAME JAM」があります。 今回私が参加したのは、ゲーム開発の就業型インターンで、実際にリリースされている、またはリリースされるサービスの開発に携わることができます。

インターン応募時の自分

私がインターンを探し始めたのは2020年の4月頃でした。 以前からインターンに参加してみたいという漠然とした思いがあり、コロナ禍で少し心配ではありましたが、とりあえずインターンに応募してみることにしました。 インターンに参加するにあたり、参加の目的を以下のように設定することにしました。

• (Unityを使った)実践的な開発を体験する
• 大規模なチーム開発に参加する
• 自分の実力がどこまで通用するかを試す

合わせて、この時点での私の経験・スキルを以下に示します。

• プログラミングは9年目？
• Unity 6年目
• 2Dゲーム開発経験、一切なし
• GitやGitHubなどは基本的なことは知ってる(一応業務で使ったこともある)
• チーム開発は、ぼちぼちという感じ

私は以前からUnityを使うことが多かったので、今回はUnityに絞ってインターンを探してみました。

インターン参加までのスケジュール

アカツキのインターンの応募のきっかけになったのは、4月に開催された某面談イベントの参加でした。その面談イベントでは色々な企業の採用担当の方とお話ができ、 その中にアカツキも入っていました。

実はアカツキの存在自体は知っていて、実際にイベントの会場としてオフィスに行ったこともありましたので、ゲームを開発している会社であるという認識がありました。そこでUnityを使ったインターンができるのでは？ と思い頑張ってアピールしたのを覚えています。そこから面接のご案内をしていただき、無事合格することができました。 アカツキの就業型インターンには選考の工程が2つあり、自分の場合は一つ目のWebコーディングテストの結果が5月の中旬くらいに出て、そのあとの面接の結果が5月の下旬くらいに出ました。

インターンへの参加

私が配属されたのは、『八月のシンデレラナイン』というスマートフォン用ゲームアプリのチームでした。 そこでクライアントサイドの開発業務を行うことになりました。

インターンの課題

インターンの初日、入社の手続きが終わった後にメンターさんとのミーティングでインターンで取り組む課題の決定をしました。 元々チームの中で上がっていた課題をいくつか提案していただき、その中で3週間で実現できそうな課題を選ぶ、という感じになりました。

その中で私が取り組んだ課題は「選手専用クリスタルベアマックスの実装」というタスクでした。 八月のシンデレラナインには、キャラクターを成長させるための強化素材となる「ベアマックス」というキャラがいるのですが、 その中でも「限界突破」という機能に使えるベアマックスを「クリスタルベアマックス」といい、さらにその中でも特定のキャラクター(選手)にのみ効果があるクリスタルべマックスを 「選手専用クリスタルベアマックス」と呼んでいました。以下クリスタルベアマックスををクリベアと略します。

私の場合は既存の問題をインターンの課題としましたが、人によっては自分で提案した課題を進めることもできるといった感じでした。 私も、自分の課題としては進められませんでしたが、いくつか機能の提案をさせていただきました。

インターンの成果

前述のとおり、自分は選手専用クリベアのクライアント実装を担当することになったのですが、 このタスクをもう少し細分化すると以下のようになります。

• 選手専用クリベアに関するマスターデータの定義
• 選手専用クリベアの選手詳細画面の実装
• 選手専用クリベアのクリベア一覧における表示

マスターデータの定義

選手専用クリベアという新しいキャラを作るために、サーバーサイドで新しいマスターテーブルが作成されたので、まずはそのマスターテーブルの定義をクライアントでも同期しなければいけませんでした。 具体的には、「選手専用クリベアがどの選手に対して効果があるのか」という情報を持ったマスターテーブルでした。 八月のシンデレラナインでは、サーバーで新しく定義されたマスターデータをCIによってC#のクラスがクライアントに作成されるという仕組みになっていました。 そしてそのクラスのPartialに対してクライアントで使う処理を実装していく、ということをしました。 

選手専用クリベアの選手詳細画面の実装

八月のシンデレラナインには選手育成ができ、選手一覧の画面で選手アイコンを長押しすることでその選手の詳細なステータスを見ることができます。 この機能についてはベアマックスにもあり、選手専用クリベアを実装するにあたり、選手専用クリベア選手詳細画面を実装することになりました。

まず、そもそも選手専用クリベアの選手詳細画面デザイン自体が決まっていませんでしたので、 さっそくプランナーさんとデザイナーさんを交えてのデザイン案の検討ミーティングが行われました。 大学生の自分にとっては、プロのプランナーさんとデザイナーさんと一緒に会議をするという経験がなかったので少し緊張しました。 会議を通して、以下の画像のようなデザインに決まりました。

選手詳細画面のデザイン案

ここから選手詳細画面の実装をしていくことになります。選手専用クリベアの選手詳細画面はクリベア像の後ろに選手の立ち絵が回り込むという構造上、背景画像・選手の立ち絵・クリベア像という3層構造にする必要がありました。 他のベアマックスに関しては、ベアマックス像と背景が一緒になった画像が使われており、またシーン専用クリベアに関しては、背景画像と選手のイラストがシェーダによって合成されているという仕様になっており、選手専用クリベアでは他と違った実装をする必要がありました。

当初はシーン専用クリベアのように立ち絵と背景をシェーダを使って合成する案で実装しようと思っていましたが、立ち絵を表示する際にプレハブが用いられていることから、 今回の実装では既存の立ち絵のプレハブと、新たにベアマックス像をプレハブ化したものをInstantiateする形にしました。

実装されたデザイン

選手専用クリベアのベアマックス一覧における表示

アイコンデザインに関しても、デザイナーさんとプランナーさんとミーティングをし、選手専用クリベアとしてどういうアイコンにすれば良いのか、協議をしました。 しかし残念ながら、選手専用クリベアの選手一覧画面における実装は今回は取り掛かることができませんでした。 スケジュールとしてはここまで終わらせたかったのですが、３週間という時間の中では終わらせることができませんでした。とても悔しいです。

インターンを終えて

インターンで得た学び

今回のインターン学んだことはとても多かったと感じています。

まずは、今回のインターンの目標の一つである、「実践的な開発を体験する」という面において、 今まで携わったことのない大きな規模のサービスの中で、Unityのシーンやアセット、サーバー連携などがどのように運用されているのか 体験することができました。 自分は２Dゲームの開発経験が全くなかったので、Unityシーンの中でどういうヒエラルキーを使っているのか、どういうアーキテクチャを使っているのかのプラクティスを学べたことや、 なかなか個人開発では体験しにくいアセットバンドルについての知見を得ることができたこと、サーバーのマスターデータをどういう風にクライアントで使われているのかを学べたことが とてもよかったと思います。

次に、自分の弱みを知ることができました。私の場合は、プロジェクトの全体像がある程度見えないと、コーディングを始められないという、プログラマとしての臆病さというのが顕著に出てしまい、 前半１週間は満足にコーディングができず、コードリーディングに多くの時間を使ってしまいました。 メンターさんには「試し書きをしながら全体を把握していくのが良い」というアドバイスをいただきましたので、次のインターンや今後の開発においてそれを意識してやっていきたいと思いました。

そして、コミュニケーションの大切さを改めて痛感しました。 私はインターン期間中に何度か非エンジニアの方とミーティングをする機会がありましたが、 そこで自分が思っていることを言語化するというプロセスでかなり時間と体力を消耗しました。 メンターさんとの会話をする場面においても、自分がなぜこれができなかったのか、どうやって解決すれば良いのかを話し合うことが多く、 そこでもちゃんと理論立てて話し、相手に伝えるということの難しさを身をもって体感しました。

全体の感想

インターンを３週間終えて、まず思ったのは「働くってこんなに疲れるのか……」でした。 実際業務中は業務のことで頭がパンパンですし、業務が終わってからは疲れてしまってほぼ何もできませんでした。 本当に、働きながら＋αで何かできる人ってすごいんだな、と思いました。

今回のインターンでは自分の苦手分野だったということもあり、ずっとヒーヒー言いながら開発になったと思いますが、 その環境に自分がいるということにある種の心地よさを感じていました。 そのおかげで色々なことを学べたし、普段できない体験もできたので、本当に濃い３週間を過ごせたと思います。 今回のインターンは本当に参加して良かったと思いました。 インターンでお世話になったアカツキ のメンターさん、デザイナーさん、プランナーさん、チームの皆さん、人事の方には感謝してもしきれません。本当にお世話になりました。

以上で自分のインターン参加報告を締めたいと思います。 最後まで読んでいただきありがとうございました。

アカツキのインターンで初めてサーバーサイドのチーム開発を経験した話

アカツキインターン体験記

9月頭から3週間、アカツキでサーバーサイドエンジニアとしてインターンに参加した体験記です。

目次

1. 自己紹介
2. インターン参加の経緯
3. インターンで取り組んだこと
4. インターンを振り返って

1. 自己紹介

　私は普段、大学院の博士課程で哲学の研究をやっており、それも、何百年も前に書かれたドイツ語の本を読んで解釈するという、プログラミングにはおよそ関係のなさそうなことが専門です。そんな私ですが、主に金銭的事情から就職を迫られています。

　哲学の大学院からエンジニアというルートはまあ多くの人が通る道ではありません。私がエンジニアを志望するようになった経緯はもはやあまり覚えていないのですが、人に分かりやすくアピールできる技術を何かひとつ持ちたいという動機があったのは間違いないです。ただ、プログラミングを始めたのは修士課程の終わりのあたり（2X歳）で、今回のインターンまでは開発経験も無く、Twitterとかを見ていると中高生ですごい人もいくらでも見つかるので、自分の能力や適性にやや不安を感じています。

2. インターン参加の経緯

　とあるエンジニア向け就職サイトに私は登録していたのですが、そのサイトでは企業の方からお声掛けいただけることもあり、なんとなく受動的に就活をやっていました。今年に入って、ある時期からそのサイト経由でインターンのお知らせが来るようになったので、そろそろインターンというのを受けてみようかなという気になりました。動機としては、開発経験が圧倒的に足りない（皆無）なので、とにかくどこかでチーム開発を実際に経験したいというのがありました。

　それである日、「アカツキ」という名前の企業からインターン面接のお誘いをいただきました。アカツキはスマホゲームなどで有名な企業なのですが、古のスマホ(2011年購入)を使っていた私はスマホゲーと無縁で、その時点では会社名はおろか「八月のシンデレラナイン」（以下、「ハチナイ」）というゲームタイトルも知りませんでした。でもゲームづくりって面白そうだしとりあえず受けてみるかと思い、面接に臨みました。

　面接は割とトントン拍子で進んで、「私のような技術力のない人間をインターンとはいえこんなに簡単に採っていいのだろうか」とも思いましたが、ともあれインターンが内定し、9月頭から3週間アカツキでお世話になることになりました。正直、インターン内定時には開発に必要な知識をほぼ身に付けていなかったので、「インターンまでに勉強しなきゃ……」となりました。また、スマホゲーをやったことが無かったので、これを機に最新のスマホを買い、ハチナイをコツコツプレイしてスマホゲームのなんたるかを学びました（インターン参加時までにチーム評価はB+1になりました）。

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

　ゲーム開発のサーバーサイドエンジニアとして私は今回のインターンに参加しました。サーバーサイドは皆さんがプレイ中に触れるゲーム画面を作ったりするのではなく(これはクライアントサイド）、キャラやアイテムなどのデータを管理するコードを書くのが主なお仕事です。

　ゲームに関して欲しい機能があればそれを自分で実装してみてもいいと言われていたので、いくつか用意していたネタを初日にメンターさんに話しました。しかし、それらはすべてクライアント案件とのことでしたので、既に挙げられていた運用改善系のタスクに着手することになりました。

　運用改善系のタスクとは、ゲームの新しい機能を開発するといった、ユーザーの目に届くような変化をもたらすものではなく、開発者側がスムーズに開発できるようにサーバーのコードを改善するものです。これに関して私は以下の3つのタスクを手掛けました。

1. デバッグプレイにおいては初めから強いキャラが一式手持ちにいるようにする
2. 「開放不可能なステージ」という不適切なデータが入り込まないよう、自動的にチェックする仕組みを作る
3. 外部サービスとのアカウントの紐付け対応をエンジニア以外もできるようにする

3.1 デバッグプレイにおいては初めから強いキャラが一式手持ちにいるようにする

ゲームバランスを検証するのでない場合、デバッグプレイにおいてゲームの攻略にいちいち躓くようなことがあれば不便です。なので、デバッグプレイにおいては強いキャラやアイテムを追加するといった、通常プレイではできないようなことができるようになっています。

この作業は手動なので、このキャラを追加して、次はこのキャラを追加して……、といちいちやることになり、少し面倒です。どうせなら初めから強いキャラが一式手持ちにいるようにしたい！　というのが最初のタスクの内容でした。

実装は開発環境サーバーのコードを少し書き換えることでできました。ユーザーの目に届くことのないデバッグプレイ限定とはいえ、自分が書いた通りにゲームの挙動が変化していくのが面白かったです。

3.2 「開放不可能なステージ」という不適切なデータが入り込まないよう、自動的にチェックする仕組みを作る

ゲームのステージは普通、最初登場するときにはロックされており、様々な条件をクリアすることで次第に開放されていきます。しかし、データの値によってはそもそも開放不可能なステージが生じてしまうことがあります。このようなステージのデータが紛れ込んでいると色々とよくないことが起きるので、できればデータを投入する段階で自動チェックを行って弾きたいです。この自動チェックの仕組みを作るのが次のタスクでした。

実装自体は比較的スムーズにできましたが、加えたチェック項目が既存データと衝突しないかなどをチェックするなどの対応が結構大変でした。

3.3 外部サービスとのアカウントの紐付け対応をエンジニア以外もできるようにする

ゲームのアカウントはしばしば外部サービスのアカウントと紐付けられます。このような紐付けは基本ユーザー側でできるものですが、たまに何らかの事情によって運営側が紐付け情報を変更しなければならないときがあります。

私の所属していたチームでは、この紐付け対応をエンジニアがいちいちコードを書いて行う必要がありました。この作業は手間ですし、GUIでエンジニア以外の人も操作できた方が便利です。というわけで、エンジニアでなくても簡単に紐付け情報を変更できるような管理画面の機能を作ることになりました。

ページを作ること自体は簡単だったのですが、そのページから不正なデータを登録できないようにするための工夫が手間でした。無理やりデータを書き換える機能は往々にして危険なので、入力されるデータをしっかり検証できる必要があります。また、現状のデータにまずいところが無いかなどの調査も必要です。失敗したときの影響が大きな作業なので慎重に行う必要があり、検討を重ねた結果、安全な管理画面を作ることができました。

4. インターンを振り返って

まず、まともな開発経験も無く、ましてや業務でのチーム開発の経験も無かった私としては、現在プレイされている（運用サイドの改善とはいえ）ゲームの開発に関わるというのは何もかもが初めての経験で、あらゆることが勉強になりました。コードの書き方などの技術的なところもそうですし、問題が生じたときにどのように対処するかとか、人と話し合うべきときにどのように情報を共有するかなどについても、実際のチーム開発ならではの経験を通じて様々なことを学ぶことができました。

アカツキという会社については、非常に雰囲気がよく、社内での情報共有の仕方なども洗練されており、何かと人に相談しやすい環境だったと思います。今回は人類がこれまでほとんど経験してこなかったリモートでのインターンということで、「困ったときに誰も助けてくれなかったらどうしよう」という不安があったのですが、メンターの方は常に相談に乗ってくださり、メンター以外の方も何かと見守ってくださりました。また、各人にあったタスクに取り組ませてもらえ、場合によっては自分が提案した新機能の実装などにも取り組ませてもらえるので、新しいことに挑戦しやすい会社という印象を受けました。

これから就活本番に入るわけですが、これで「チーム開発経験あり」と言えるし、インターンを通じて今後どういう勉強をしていけば良いのかなども具体的に見えてきたので、エンジニアになれるよう引き続き頑張ろうと思います。アカツキさん、3週間という短い間でしたがありがとうございました。

Akatsukiサーバーエンジニアインターンを経験して

こんにちはAkatsukiのサーバーエンジニアとして8月24日から9月11日までの3週間参加させていただきました、飯田です。私がこの3週間でどのような事に取り組み、何を学んだのか、振り返りを書く事になりました。

Akatsukiのサーバーエンジニアってどんな事しているのか、またどういう環境なのか興味がある方はぜひ読んでいただけたらと思います。よろしくお願いします。 

インターンの参加理由

まずインターン参加の理由から話していきます。

私がアカツキのインターン参加を決めた理由は「実際に業務をやりながら学べる」という事にありました。私は働いている環境を知りたいという思いがあり、 実際に社員のエンジニアの方と業務を通してやりとりできるというのは大変嬉しい事でした。

 そしてもう一つ大きな理由としては、「やりたい事に取り組ませてもらえる」という事です。事前に何がやりたいかを何度も聞かれ、自分が関わりたい領域をきちんと話せば、それができるように取り計らってくださいます。面接の時からそんな感じで、ご縁があり参加させていただく事になりました。

ちなみに私がやりたいことは仕様の検討や設計をゼロから考えること、AWSに関するタスクでした。普段から開発する中で、自分の中に課題としてあったので取り組めたら良いなと思っていました。

インターンで取り組んだ事

私は「八月のシンデレラナイン」というゲームタイトルのサーバーエンジニアチームに配属され業務を行うことになりました。インターンでは合計５つのタスクに取り組みました。そのうち特に沢山学びがあった３つを紹介したいと思います。

その三つとは

・チーム評価ログを取りやすくする実装

・ECSデプロイ完了時に通知を送る仕組み

・デレストキャンペーン時のプランナー作業自動化の実装

です。

チームスキル評価込みのチーム評価を容易に取れるログの実装

 最初にチーム評価に関して簡単に説明しますと、ハチナイにはチームを組んだときに４つの評価値をもとに総合値であるチーム評価というのを計算します。（画面下部）

ハチナイの分析チームはユーザーのチーム評価の値を分析に利用しているそうなのですが、チーム評価を取得するには、クライアント側との連携が必要になり、チームスキル評価の部分のみ独立して取得するというやや複雑なロジックが必要になっていました。そこでこのチーム評価のログデータを簡単に取れると、よりログの分析が簡単でやりやすくなるというのがチームからの要望でした。

クライアント側との連携があることから、クライアントエンジニアの方と相談し、容易に取れるような方法を新たに考え、より簡単に一括でチーム評価ログを取れるように実装してレビューしていただいた段階で沢山の質問が飛んできました。

・既存の実装にはログはログデータとして送信しているので、ログ専用のデータベースのカラムはない。その辺りはどう考えてますか？

・なぜその実装が良いと判断したのですか？

・他の実装案はどうだったのですか？

最初少し驚きました笑

確かに実装方法はいろいろありますがどうしてそれに決めたのか、何を判断根拠にしたのかなどをしっかりと考え抜いて言語化出来るかを見ているようでした。言語化を大切にされている文化なのだと感じました。考えていたこと・自分の中に持った明確な判断基準をきっちりと説明して、納得してもらえるようにして初めてOKをもらえることになります。

普段個人開発をしている人は何となくこっちの方が良いよね、みたいな感じで実装することもありがちだと思うんですが、実装方針に関してきちんと言語化することは非常に大事なことだなと気づきました。レビューする人や他の人が見ても、別の実装方法とのメリットデメリットの比較やなぜそういう実装に至ったのかを理解できますし、曖昧な部分をなくすことで考慮漏れも起こりにくくなります。きちんと説明できることは学びにもなりますし良いことしかありません。もちろん時間がかかるので、常にこういうことをしているわけではないそうですが、いつ聞かれても答えられるようにしっかり考えて自分の判断基準を持っておくというのは非常に大切な事だと思います。

質問は沢山飛んできますが、非常に優しい感じで、「良いとか悪いとかではなくなぜそうしたのか」という事をわざわざ強調して聞いてきてくださるぐらいなので圧迫感とかは皆無で非常にやりやすかったのも良かったです。

ECSデプロイ完了時に通知を送る仕組み

次に紹介する取り組んだタスクは、「ECSデプロイ完了時に通知を送る仕組み」です。ハチナイの開発にはAWSのECSが利用されています。現状は、機能を開発してデプロイを行ってから完了したかどうかをいつもAWSコンソールを見に行って確認して、正常に動いている事を確認してから検証をしているという状況になっていました。ECSのデプロイは、行ってから完了するまでの時間が起動しているインスタンスの数によって変わり、環境によって時間がかかる事もよくあり、いつ終わったかを確認するのは手間になります。これを普段チームでやりとりしているSlackでわかるようにしたい、という要望がありました。

実装に関する内容としては、AWS SDKというAWSから用意されているプログラムからAWSを操作できるライブラリを利用してECSのクラスターの状態を確認することができるので、それでデプロイが行われたらリビジョン番号が変わる事を利用してSlackに通知を送るという仕組み作りです。これ関しては良い感じのライブラリがあったのでそれを改良する事で対応をしました。

実装ベースの話まで落とすと、一定周期でAWSのAPIを叩いてECSクラスターの状態を取得し、リビジョン番号に新しい番号が出来て、一定時間内に現在のリビジョン番号が新しいリビジョン番号に遷移していればデプロイ成功の通知を、新しいリビジョン番号ができても一定時間内に遷移できていないならデプロイ失敗の通知を送るという感じです。

一定周期でAPIを叩くというように、常に起動させておく必要があるので、ハチナイで使われているEC2のサーバーの中にデーモンのプロセスとして登録し、インスタンスを立ち上げたときに自動で実行されるようにする事で、人手を一切介さないで良いようにしました。

ずっと正常に動いてくれていて良い感じです。好きなSlackの絵文字を設定して良いとのことだったのでこんな風になりましたが、もうちょっと普通のにしたら良かったなと後で思いました（反省）

 AWSのIAMの権限に関することや、クラスター周りのことを調べる良い機会となり、結構詳しくなれたように思います。

デレストキャンペーン時のプランナー作業自動化の実装 

 最後に紹介するのは、「デレストキャンペーン時のプランナー作業自動化の実装」です。ハチナイのデレストには、定期的にキャンペーンがあり、キャンペーンによって主に次の3つ内容が変化します。

・消費元気が1/2になり、紹介文にキャンペーン中の文言が追加される

・ソウルストーンのドロップ量が増える

 ・秘奥義が取得できるようになる

現状これらの対応を行うために、プランナー陣の工数が大きくかかっているという事でした。どうやら作業手順が煩雑で、特定のプランナーに作業が属人化してしまっているということにもなっているようで、これらのキャンペーンによる変更をサーバー側のロジックで自動化しようということになりました。

これに関しては仕様もなにもなく要望でしかなかったので、まずはヒアリングを徹底的に行いました。プランナーの方が実際にどういう形で実現できると嬉しいのか、というところをもとに社内で使われている企画などを書くページに仕様書/設計書を作り、それをもとにプランナーの方と検証チームの方にも確認していただき、「要望通りの実現ができる仕様となっているか」「検証する際の問題はないか」というところを見ていただきました。

しかしここで問題が発生しました。確認が取れて仕様が決定した段階で、このキャンペーンによる表示の変更はサーバー側で全部生成しているわけではなく、一部クライアント側で保持して出しているということが判明しました。(自分の確認漏れです)

これによってクライアントエンジニアの方にも協力をお願いすることになります。と言っても仕様は自分が考えているので、クライアント側でどういう事をすれば実現できるかをちゃんと調べて設計して提案する形で相談をしていただきました。しかしその確認の途中、さらに問題が発生しました...(問題起こりすぎ)

秘奥義の表示部分が他のゲーム画面にも跨っており、影響範囲の見積もりが完全に誤っていたことが発覚。さらにこれによって他の問題も見つかることになります。

「このままでは実装に進めない」という状況になり、色々打開策を考えるも出てこず、他のエンジニアやプランナーの方に向けてヘルプを頼むことにし、皆さんの協力のおかげでなんとかインターン期間内での実現が可能そうな落とし所が見つかりました。

実装方針の修正ができたので、仕様書を再度作り直して、今度はプランナー・検証チーム・クライアントエンジニアの方々に見ていただきました。（10人近く見て頂いて確認を取るので、結構頑張りました。ページの枚数も凄いことに。）

各チームの方が見るに当たって、何が分かれば良いのか、どこを見たらすぐわかるのかなどをしっかりと考慮して作ったおかげあってか、一発でOKが出て分からないと突っ込まれる事も特になく、ようやく実装に着手できるようになり、この時点でインターンの終わりが目前に迫っていて大分焦って実装に取り組んでいました。なんとかテストまで書き終えてPRを出してレビューをもらうところまではできたのですが、時間が足りず完遂することまではできなかったので引き継ぎをお願いすることに...（悔しい）

途中で問題が起こったり、関わる人が沢山いて考慮すべきことが沢山あってひたすら考え続けていたという感じで、非常に多くの学びがありました。これはやはり業務をしているからこそならでは、というところもあると思うので、実装を完璧に仕上げることまではかないませんでしたが、自分で一からヒアリングして仕様を作って設計してというところを色んなチームが関わる中で、しっかりと考えて取り組めたのは凄く良い経験をさせてもらえたとなと思います。

このタスクでは沢山の学びを得られました。最初のタスクであったような言語化が必要なことはもちろん、仕様の検討に関して、「要求された方針だけで考えるのは”検討”とは言わない、全ての可能性を考えて最適なのを探すのが検討」という指摘があったことは深く印象に残っています。

インターンを終えて

まずは、3週間本当にお世話になりました！毎日が本当に学びの連続で、技術に関することだけでなく、エンジニアの姿勢というところまで沢山勉強させていただきました。上の話の中では出てこなかったですが、メンターについて下さった方が、私が困ったときに的確なヒントをくださり、教えてもらうのではなく、基本的に自分で考えて動き続けることができて本当に楽しく取り組み続けることができました。本当メンターの方の推察力と言語化力が凄すぎました。（どうしたらそんなに風になれるんだろう）

また、最初はヒアリングをあまり上手くできておらず、自己判断が多いところもありましたが、指摘をいただいて自覚でき、途中から直して取り組むことができました。インターン中での成長がはっきりと目に見えてわかるのが凄かったという風に仰っていただけたのも嬉しかったです。

本当に手取り足取り教えるのとは対極で、自分で考えて出したアウトプットに対するサポートという感じで接して下さって、自分には凄くあっていてよかったです。皆さんもとても優しくて、心理的なハードルを一切感じる事もなく気軽にきける環境で、リモートというのが全く気にならないぐらいでした。働いていて凄く楽しかったです。本当に素晴らしい環境で学べたことを嬉しく思います。アカツキの良さを沢山知ることができました。

最後になりますが、本当に3週間という長い間お世話になりました。ありがとうございました！