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

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

クライアントサイドインターンinアカツキ

この記事は、株式会社アカツキさん(以下敬称略)で約1ヶ月の就業型インターンに参加した際の体験記になります。

はじめに

4月5日〜4月28日までアカツキで「八月のシンデレラナイン」(以下ハチナイ)の開発チームにクライアントサイドエンジニアとして参加させていただきました。

inアカツキと題につけましたが、オンラインでのインターンだったので、正確にはoutsideアカツキとかでしょうか?

自己紹介

地方国立大学大学院の修士2年です。

CGが好きでゲーム業界への就職を目指し就活中です。

趣味は読書とゲーム。ミステリ、SFが好きです。FPSをよくやります。

タスク内容

インターンに参加する1ヶ月ほど前に、メンターの方と相談してタスクの内容を決めていただいていました。比較的早く終わる細々としたタスクをたくさんやるか、インターン中に終わるかどうかわからないタスクをやるか、どちらがいいかという話で、自分は目に見える成果が欲しい業突く張りだったので、細々タスクをやらせてもらえることになりました。

以下、細々タスクの内容です。

  • 利用規約画面のUI変更
  • チュートリアル突破後のステージ上のアイコンの位置変更
  • 選手管理画面のデフォルトのソート種類の変更
  • フレームレート設定画面のボタンの文字変更
  • 選手プロフィールへの遷移誘導の削除

また、上記のタスクが予定よりも早く終わってしまったため、自分の方からいくつかハチナイのUI周りで改善できそうなところを拾ってきて改善案として、提案させてもらいました。

その中で、通った案が下記になります。

  • タウンマップにおけるキャラのセリフの表示タイミングのランダム化
  • タウンマップにおけるスクロールできる範囲の変更

改善前のキャラのセリフは、タウンマップに入った際にすでに表示されていて、キャラをタップして次のセリフを表示するまで消えないという仕様になっていました。これでは、後ろのキャラが隠れてしまって見えなくなる時間が多くなってしまいます。そこで、キャラのセリフをランダムなタイミングで表示し、一定時間経過後に非表示にするという手段をとることでこれを解決しようとしました。

また、タウンマップではキャラが画面の端っこに移動した時に見切れてしまうという問題がありました。これはスクロールできる範囲が、デバイスのアスペクト比に依存しているため、機種によって見える範囲が違うのではないかということで、スクロールできる範囲をデバイスに依存しないような作りに変更することで、見切れ問題を解決しようとしました。

感想

このインターンを通して様々なことを学びましたし感じました。

チーム開発の大変さ

大変でした。自分にそれほどコーディングの経験がないことが原因ではあると思いますが、何よりも他人の書いたコードを読むのが大変でした。最初に着手した細々としたタスクも、終えてみれば30分もかからないような内容に思えるのですが、どれも一日はかかってしまいました。直すべき内容は頭でイメージできているのに、肝心の直す場所が見つからず気づけば30分、そして1時間とだんだんと時間が経っていきます。そしてようやく改修する箇所を見つけたら今度は、直した後に悪影響がないか考慮して...初めての環境で緊張し焦る心に、大量のコードを目にして混乱する頭......落ち着かせるためにロングブレスダイエットかなと思うくらいには深呼吸しました。本当に大変でした。もっと普段からコーディングして経験積みます。お疲れ様でした自分。

アカツキの雰囲気の良さ

人が優しかったです。朝に業務始める旨をslackに投稿すればいろんな人たちがスタンプなどで反応してくれるし、わからないことをslackに投稿すればすぐに回答してくれたりと空気がそれはもう温かい。タスクを終えてプルリク出した報告をすれば褒めてもらえるので、鼻の伸びが止まるところを知りませんでした。ただ優しすぎるだけじゃなく、指摘するところはズバッと指摘してもらえるので、エンジニアとしても成長できたんじゃないかなと思っています。

おわりに

オンラインでのインターンは初めてだったので、はじめは社員の方々とどう接したものかと悩んでいましたが、ランチの時間に社員の方と話す機会をいただいたり、社員の方からゲームに誘っていただいたりと楽しく過ごすことができました。そういった機会を用意していただいたメンターの方や人事の方には感謝し尽くしてもしたりないです。また、参加させていただいたチームの方々や、ミーティング時にお世話になった方々、ランチでお話させていただいた方々、その他いろいろお世話になった方々、貴重な機会をありがとうございました。いずれまた、お会いできる日がくることを祈っています。

本当にありがとうございました。

アカツキで「ハチナイ」のサーバーサイドインターンに参加してきた。

はじめまして。3/15~26の10日間、アカツキでサーバーサイドインターンをさせていただきました、いわみと申します。

今回は、モバイルゲーム「八月のシンデレラナイン」のサーバーサイドにおける機能改善などの業務に関わらせていただきました。

ここでは、そこで学んだことや感じたことを書いていこうと思います。 

はじめに

何者?

現在大学院1年で、航空宇宙を専攻しています。しかしながら、インターンなどを通じてWEB業界に魅了され、現在はIT業界を中心に就職活動をしています。

アカツキにはご縁がありまして内定をいただき、その後内定者インターンという形で参加させていただきました。

やったこと

 今回取り組んだタスクは次のものです。

  • 特定のアイテムを没収し、代わりに別のアイテムプレゼントする

概要 

イベントなどでゲットできる、期間限定アイテムなどは、その期間が終了すると使い道がなくなってしまうものがあります。そういったアイテムを普段から利用できるアイテムに変換したいというニーズは前からあり、今までも何度か行ってきました。

f:id:biwashi:20210326192744p:plain

期間限定アイテム変換

 

問題点・改善点

従来この処理は、変換元のアイテムや変換先のアイテム、また変換レートなどの情報をもとに、毎回エンジニアがスクリプトを書いて本番環境で実行しているというものでした。しかし、この操作はパラメータ以外の部分は共通化できるため、今回はこの処理をRakeタスクで実装しました。

また、パラメータの入力に関しては、できればエンジニアではない職種の方でもできると今後実施しやすいと考えたため、今回はJenkinsのJobという形で実装しました。 

再利用可能にするために

先述した通り、従来は変換時に必要なパラメータをスクリプト内に記載する形でした。そのため、今回はRakeに対してパラメータを環境変数として指定して渡してあげました。

これにより、大元の.rakeファイルは同じものを使い、時々により変わるパラメータは変更するという汎用性を実現しました。

パラメータ多すぎ問題

この状態で、

$ bundle exec rake hoge:task {環境変数} {環境変数} {環境変数} ...

という形で実行すると、環境変数の部分が多いため非常にレビューがしづらいです。

今までであれば、実行するスクリプトをレビューし、承認が出れば実行という形でしたが、それがよりやりづらくなりミスの原因となります。

そこで、この入力(及び実行)を Jenkins の Job により実装しました。 

JenkinsでGUIにする

Jenkin はJobを実行する際にパラメータを渡すことができます。そこで、今回使用するような変換アイテムの情報や変換レートなどを入力できるようにし、その入力をRakeに対して環境変数として渡しました。 

これにより、ターミナルなどに関与せずとも、入力フォームにパラメータを打ち込んで実行するだけで、アイテムの変換ができるようになりました。

実用可能なのかどうか検証する

さて、実際にJenkinsで動作するということは確かめられましたが、もう一つ最後に考えなくてはならない項目があります。それが実用性です。今回は以下の項目を考えました。

  1. 「ユーザーのアイテムを0にする」という破壊的な動作を含むため、ミスは許されない
  2. 普段ゲームでは起こり得ない操作であるため、実施は基本的にメンテナンス中である。そのため実行速度や終了時刻のある程度の予測ができなくてはならない。
1:Validationの実装

アイテムを変換するということは、そのユーザーの変換前のアイテムを0にするということです。これはユーザーの資産に関わる重要な操作になるので、非常に慎重に行わなくてはなりません。

そこで、Rake内にパラメータに関するバリデーションを設定することにより、パラメータ入力の人為的ミスを弾くようにしました。

また、Jenkins の Job には Rebuild という、以前に実行した Job と同じパラメータを流用したまま再び実行できる機能があります。テスト環境でこのタスクを試し、問題がなかった場合は本番でも運用するという流れですが、その際、Rebuild の実行環境のパラメータのみ置き換えることによって、テストしたものと同じパラメータで実行することができます。

2:処理速度と終了時間予測

実際の運用を想定し、テスト環境にダミーデータを用意し速度検証を行いました。これにより大まかな処理速度の把握をすることができ、本番環境で起こりうるデータ量でも今のところ問題ないことを確認しました。

また、終了時間予測は、対象となる総アイテム数に対して現在変換済のアイテムの割合と、ここまでの処理時間をもとに試算した時間を、ある一定のアイテム数を変換するごとにLogとして表示するようにしました。これにより、処理中の変換があとどれくらいかかるのかが把握しやすくなり、メンテナンス時間のコントロールに利用できるようにしました。

振り返り

技術的な点と体験(感情系)に分けて述べていきます。

技術

ゲームならではの色々なものに触れられた

実はゲーム開発を実務としてやるのは初めてで、色々とWEB開発とは違う部分を体感し、面白かったです。

特に、DBへのアクセスの最適化などは、ダイレクトにユーザー体験関わる部分なので、みなさん気を使って開発されているようでした。また、これはゲーム内で常に動いている機能に限らず、全ユーザーに対するメンテナンス中の処理なども、時間という制約があるということを体感しました。

技術的な質問にたくさん答えていだける

環境構築をはじめとし、実務を行っていく上でわからない事への質問などに対して、いつも真摯に素早く助言いただき、非常に勉強になりました。

動けば終わりではない

コードが汚かったり遅かったりしても、とりあえず望みの処理ができていればヨシ!としてしまうことがたまにありますが、今回は「メンテ時間内に終わるのか?」「静的解析のCIを突破しているのか」「このパラメータはなくてもいけるんじゃないか」といった、コードの品質まで踏み込んだレビューをしていただけました。

体験

会社の雰囲気がすごくいい

とにかく2週間過ごしやすかったです。特にSlackの times_xxx という、各個人のオープンチャンネルを作る文化があるのですが、そこでは普段のTwitterのような雑談から、時にはかなり踏み込んだ技術の話まで、色々な会話が展開されていました。こういった、オンラインでありながらもオフラインに近いようなコミュニケーションスペースがあるのは非常にいいと思いました。

オフィスがめちゃ綺麗でテンションあがる

以前から、「いつか噂のオフィスを見てみたい!」と言っていたこともあり、今回念願のオフィスツアーをしていただきました。

各所かなり力が入れられており、かつ新しい集中スペース「Concentration Booth -Zen-」が増設されていました。

f:id:megumimorishima:20210506173904j:plain

これからの時代、「全ての仕事が基本的にオンラインで出来るため、そもそもオフィスはいらないのではないか?」といった意見があります。しかしアカツキでは、仕事を家でも出来る中でも、オフィスに来たいと思えるような環境を作りたいとのことでした。エンタメ企業においては、普段の雑談や対面のコミュニケーション、それこそ遊びから生まれるようなクリエイティブなアイデア大事にしていきたいとのことでした。

まとめ

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

ゲーム開発とはなんぞやといった部分からアカツキのかなり踏み込んだところまで肌で感じることができました。

学んだ技術も、改めてもう一度時間を取って復習してみたいと思います。

ありがとうございました!

 

アカツキのサーバサイドインターンに参加しました。

こんにちは。シュウと申します。

この度、3/1〜3/31の一ヶ月間、アカツキのサーバサイド就業型インターンに参加しました。

この短い一ヶ月間で沢山のことを体験し、勉強しましたので、実際に取り組んだタスクや所感を共有させていただきたいと思います。

はじめに

自己紹介

私は現在専門学校の三年生で、ゲームプログラミングを専攻しています。台湾で文系の学科を卒業しましたが、昔からずっとプログラミング、特にサーバサイドに興味があり、留学生として今の学校に入って、ゲームのサーバサイドを中心に就職活動をしています。

アカツキの文化や雰囲気、ゲーム業界の実際の現場の仕事を詳しく知るために、今回のインターンに参加いたしました。

インターンの実施内容

今回のインターンは「八月のシンデレラナイン」のサーバサイドインターンでした。私の実際に取り組んだタスクは以下の通りです。

  1. 管理サイトUIの小規模修正
  2. セットアップガイドに対してのフィードバック
  3. 新規ミッションの実装
  4. デバッグ用コマンドラインツールの作成

各タスクの概要は以下となります。

管理サイトUIの小規模修正

デバッグ用にキャラクターを追加する際、選択肢にプレイヤーがプレイできないキャラも混じっていたので、プランナーにとってとても不便でした。そのため、選択肢の中にプレイできないキャラが入らないように改善するという改修を行いました。

セットアップガイドに対してのフィードバック

アカツキには、インターン生や新入社員を対象にして、開発環境をより早く、より便利にセットアップするためのガイドがあります。このガイドの最初のバージョンは、既にセットアップされた開発環境を前提に書かれたものでしたので、何も入っていない状態のパソコンにインストール及びダウンロードするツールについての説明に漏れがありました。

もともと用意されたタスクではありませんでしたが、自分の苦労したところを、今後他の人が再び苦労しないよう、ガイドへのフィードバックを文章化して書いてみました。

新規ミッションの実装

「八月のシンデレラナイン」では、初心者のために、既に様々なミッションを用意していますが、プレイヤーにより沢山のゲームの機能を体験してもらうため、新規ミッションが作られ続けています。

このタスクではそれらのミッションのうち、いくつかの処理を実装しました。

デバッグ用コマンドラインツールの作成

スマホゲームは、クライアントとサーバの通信が多いです。ゲームのデータなどを取得するため、毎回HTTPリクエストをサーバに送り、サーバから戻った応答を解析するのはごく自然なことですが、開発中にサーバに対してデータを送信する際に、毎回特殊な処理をする必要がありとても不便でした。

このタスクの目標は、開発中により便利にHTTPリクエストをサーバに送ったり、レスポンスを受けたりするためのコマンドラインツールの開発でした。

振り返り

ゲームプログラミングを専攻しているものの、今回のインターンを通じて改めて認識及び学んだことは以下の通りです。

ゲーム作りは一人ではできない、「チーム」で!

仕様の確認は、決して自分ひとりで決めることではなく、チームメンバーと確認した上で進めなくてはなりません。また、ユーザーに最高の体験を提供するため、実装された機能を検証する人も沢山います。したがって、コードを書けるだけでエンジニアになれるとは限らず、コミュニケーションも大事だということを実感しました。

意図的にコードを書くこと

学生時代に就職活動用の作品を作っても、実際のプロダクションコードとは比べ物になりません。自分の作品であれば、他の人に自分の書いたコードが分からなくてもあまり気にすることはありませんが、実際の現場でそんなコードを書いてしまうと、チームワークに支障をきたしてしまいます。今回のインターンでは、意図的にコードを書く重要性を学びました。

ゲーム作りにはみんなそれぞれの役割がある

分からないところ、つまっているところ、自分の伝えたいこと、今までの流れや試したこと、可能の解決方法など、自分の伝えたいことをきちんと文章化することは大事です。現場のチームメンバーは忙しく、学校の先生みたいにずっと自分のやっていることをフォローしてくれるわけではありません。

プラスアルファで一歩先を考えること

授業のように、与えられた仕様の通り実装するだけではなく、それぞれ担当する分野を問わず、一歩先を見据え、他の人が考えていなかったことを考えて提案をすれば、チームメンバーの負荷も軽減することができます。

アカツキの文化・環境

風通しがいい

自分の考えと言いたいことを遠慮せずに言えるのはとても素敵で働きやすい環境です。また、インターン生が来る度に、そのインターン生のSlackチャンネルを用意して、問題があっても素早く対応してくれるので大変助かりました。フルリモートインターンなので、参加する前はコミュニケーションがうまく取れるのかどうか心配していましたが、こういう文化のおかげで、一ヶ月間にコミュニケーションの問題は一切ありませんでした。

感情と心を重視しながら、論理性も重視

コードを書く時も、何かを提案する時も、アカツキでは心や感情を重視しつつも、同時に論理性も重視しています。自分の伝えたいことや自分が思うことを文章化するのは大事ですが、自分の考えが理論的に筋が通っているかを考えることも重要だと感じました。

成長しやすい環境

メンターや現場のチームメンバーは、いきなり答えを提示するのではなく、いつもヒントを出しながら、自分で考えて答えを見つけることをサポートしてくれます。こういう環境だからこそ、未知への挑戦も乗り越えることができるのだと思います。

おしゃれ・面白いオフィス環境

「ゲームを作る前に、まず自分たちが楽しく働けるのかどうかが大事」というのを多くの企業も謳っていますが、アカツキのオフィス見学を通じて、アカツキはそういう考えを体現しているなと改めて感じました。プレッシャーがなく居心地がいい、落ち着いている環境でありながらもっとオフィスを面白くするための工夫があちこちに見られます。また、社員たちが持ってきた面白い物が多く、自分の好きな形で自分の席を飾るのも見られたので、とても個性と人が重視されている会社のイメージが強いです。

まとめ

一ヶ月の間にたくさんサポートをいただいて本当にお世話になりました。あまりにも学生としてやっていることと違っており、色々なチャレンジがありました。みなさんのおかげでいろいろなチャレンジを乗り越えて、エンジニアの仕事の醍醐味を感じました。学びを応援する文化だからこそ、一ヶ月間、最初から最後まで楽しくインターンをすることができました!

それに、最後は念願のオフィス見学ができて、正直自分はすごく感動しました!

一ヶ月間、ありがとうございました!

アカツキのクライアントサイドインターンで何を学んだか

この記事は、アカツキで3週間の就業型インターンに参加して得た所見をまとめた体験記になります。

インターンについて

今回のインターンでは、スマホゲームのクライアントサイドのチームで3週間お世話になりました。

新型コロナウイルスの影響で、インターンはフルリモートで行われました。やりとりにはZoomやSlackを使うことになるので、実際のオフィスでの雰囲気などが掴めなかったのは残念に思います。

ありがたいことに、実際にオフィスに行って見学などをさせていただくというお話もいただいたのですが、残念ながら都合が合わず参加できませんでした。

インターン前の流れとしては、開始1ヶ月前にメンターになる方との面談、1週間前に入社オリエンを行い、それから3週間のインターンに参加するという形式でした。

やったこと

今回私はクライアントサイドのチームで「開発メンバーが喜ぶデバッグ機能を開発する」というテーマのもと、インターンを行いました。

課題設定

"開発メンバーが喜ぶ"ということで、実際にどのような機能が求められているのかを開発に携わっているメンバーにヒアリングしました。今回は一から課題を探していくのではなく、改善要望のリストから選んだものについて深掘りしていきます。

ここでは「なぜ」その機能が必要なのかを聞いて、場合によっては別の提案をしていくことが重要になります。エンジニアの目的は課題解決でありプログラミングは手段でしかないため、課題の根本的な原因を突き詰めることで解決に導いていきます。

今回は画面に描画されたデバッグ用のボタンが邪魔なので設定から消せるようにしたいという要望でしたが、「なぜ」を聞いていった結果、本番環境に近い画面が欲しいということがわかりました。

設計

設計ではプレゼンと同じように流れが重要になります。

私は初めは概要→目的→使い方の順で書いていたのですが、設計をレビューしていただいた結果、目的→概要→使い方→実現方法→今後の展望という流れになりました。

はじめに目的を持ってくることで、読んでいる人がなぜこの機能を作っているのかを知ることができます。

また、レビューで追加された実現方法ですが、これを書かないとエンジニア間で認識の違いが起きてしまうことが考えられます。さらにここでは複数の解を想定し、どういった理由でどの案を採用したのかを書くことで、より説得力を持たせられます。

実装

いよいよ実装になりますが、設計をしっかりやったことや機能自体はかなり単純だったこともあり一瞬で終わりました。

確認

実装が終わったのでプルリクを送ってマージしてもらいたいところですが、その前に必要な工程が一つあります。機能の依頼者に実装したものを確認してもらいます。

もし実装したものが依頼者の想像と違った場合、マージしてから修正するのは非常に手間がかかるのであらかじめ確認を取ることになります。

実装したものについては問題ないと確認が取れたのですが、実装した画面をよく見るとデバッグ表示のような数値が描画されていることに気づきました。

今回の目的は本番環境に近い画面が欲しいということなので、これも消したほうがいいのではないでしょうか。依頼者の方に確認したところ消して欲しいと言われたので、こちらについても消していくことになりました。

課題設定の際に「なぜ」を掘り下げたことで、ここで新しい課題を発見することができました。

追加の実装

デバッグ表示が残っている箇所を調査すると、いくつかの箇所のデバッグ表示が残っていることがわかったため、すべて非表示にできるように実装を進めていきます。

プルリク&マージ

追加の実装が終わったら今度こそプルリクとマージです。今回は大きな修正点もなかったのですんなりマージされました。

機能がマージされたので、これで依頼者の方が当該ブランチで機能を使えるようになりました。

学んだこと

3週間という短い期間のインターンではありましたが、多くのことを学ぶことができました。

GitHubを使ったチーム開発の流れ

これまでチーム開発の経験が少なかったので、とても勉強になりました。

ブランチ周りの機能も一人で開発するときは面倒で使っていなかったのですが、今回はその辺りも学ぶいい機会になりました。

既存のコードをちゃんと読む

チームでの実装となると、既存のコードのほとんどは他の人が書いたものになります。そのためコードをいまいち理解しないまま利用してしまうと、エラーが起きた際にどこが原因なのかがわかりにくくなってしまいます。

また、同じことができる機能が複数あったりもするので、そのときはコードを読むことでどちらがより適切なのかを判断する必要が出てきます。

ただ、既存のコードを読んで理解することは大切ですが、それを信頼するのはまた話が変わってきます。もっと良い実装方法があるかもしれないので、飽くまで既存のコードは参考程度ということになります。

コードに限らず命名は大事

コードを書くとき、変数名や関数名を適切につけることは非常に大切です。しかし、コードだけでなく仕様書やプルリクでもこれは大切になってきます。

いろんな意味にとれる書き方をしてしまうと、読む人に不親切なだけでなく後々認識の違いから問題が起きる可能性もあります。

ちゃんとした日本語を使うことを心がけることで、チームでの連携がより取りやすくなっていきます。

エンジニアの仕事はコーディングだけじゃない

今回のインターンに参加するまで、エンジニア職はコードを書く時間がほとんどなんだろうと思っていたのですが、実際は話し合いや設計の比重が大きいようです。

そのため、技術力はもちろんですがコミュニケーション能力も重要になるでしょう。

まとめ

インターンに参加する前の自分と比較して、かなり成長することができたのではないかと思います。

フルリモートという環境ではありましたが、アカツキの空気を感じることができた3週間でした。ありがとうございました。

What is サーバーサイドの10日間

2/22(月) ~ 3/8(月)の10日間、アカツキさん(以下敬称略)のサーバーサイドエンジニアとしてインターンに参加したBapliscaです。 

はじめに

アカツキが開発しているゲームの中で、「八月のシンデレラナイン」(以下ハチナイ)のチームに配属されました。

インターンに参加する前からハチナイをプレイしていたので、現場でどのように開発しているか非常に興味がありました。

自己紹介

地方国立大学の修士1年生です。

大学のゲーム制作サークルでゲーム制作をしています。

制作したゲームの中で、最近だと大学3年〜4年にかけて制作した音声認識を使ったゲーム「ボイストラベラー」があります(宣伝)。

youtu.be

 

学生のゲーム制作はクライアント側で完結するような小規模なものであり、サーバーサイド開発をしてみたいと思いました。

縁あって、アカツキでインターンする機会をいただけました。

インターン前

人事の方とメンターの方とそれぞれお話ししました。

人事の方とは、インターンのランチ中に話したい人や、インターン前の悩みごとなどを聞いていただけました。

メンターの方とは、やる or やりたいタスクについて話しました。

また、サーバーサイドで用いるRuby on Railsの経験がなかったため、事前にRubyの基本文法とRailsの勉強をしていました。

タスク内容

「同じ期間限定キャラのシーンスカウトが近い間隔でスケジューリングされているのを事前に効率的に察知できる機能」について取り組みました。

このタスクの背景について説明させていただきます。

期間限定ガチャを実施した翌日に、同ガチャを復刻(再開)することは、一般消費者に表示された期間における取引の有利性を誤認させることになるため有利誤認表示にあたる場合があります。

これを防ぐためにハチナイの検証チームでは、チェックシートで対応していました。

そこで、自動化できないかというのが今回のタスクになります。

 

具体的には、マスターデータにスカウト情報を入れる際に検知する機能を作ります。

方針として、既存のデータベースのテーブルのアソシエーションを把握し、適切なテーブルから探索する策を取りました。

また今まで手動で行っていた検証をコードに落とすにあたりハチナイの企画・検証の方にヒアリングを行いました。

ヒアリングの結果、期間限定キャラと恒常キャラの管理が、マスタデータの処理的に扱いやすい形ではなかったので、他に手段を探しました。

 

具体的にはガチャ同士の集合を用いて、期間限定キャラの集合を取っています。

この手段でカラム追加を回避しました。

タスクについての難易度はそれほど高くないのですが、エンジニアだけでなく、企画・検証チームとの連携や提案をする必要があったため要件定義に時間を要しました。

要件定義についてのやりとりで、Slackのスレッドで50件を超える会話になりました。

また、実装した結果から再度要件定義する場合があったので、そこは柔軟で良かったと感じています。

要件定義の後は、コードを書きプルリクをする一般的な流れでした。

最後にRSpec を用いたテストコードを書きました。

インターンを通して感想

ランチ

インターンのランチでチームメンバー方や同時期のインターン生とお話しする機会がありました。

また、運良くチームディナーに招待いただき、業務外の交流ができたのは新鮮でした。特にamong usをプレイできて感動しております。

Slackのチャンネルにたくさん招待していただき、いくつもの会話が見える状態だったので、オンラインであっても閉塞感を覚えることはなく、リモートの制約はなかったかなと思います。

コミュニケーション

オンラインのため、文字ベースでの会話がメインになっています。

そのためSlackで作業ログを残すようにしていました。

また業務を通じて分からない際にはSlack or プルリクコメント or zoomの画面共有を通して、かつ詳しいことを聞く前に前提などをしっかり伝えるように心がけました。

上記を心がけた結果コミュニケーションは上手く取れたかなと思います。

 

おわりに

10日間という短い間でしたが、実務を通してこれまでの経験を生かせる点や、課題・不足点を感じ取ることができました。

学びが多い充実したインターンだったと感じています!

メンターを始めとした関係者の皆さま、大変お世話になりました。