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

はじめまして！アカツキのクライアントサイドのインターンに参加させて頂いた伊藤と申します。

今回5/17 〜 5/28までの十日間クライアントの機能実装に関わり、やったことやどう思ったかを書きたいと思います！

インターンについて

 私は以前から、アカツキが主宰するLTでの発表やハッカソンの参加などでご縁があり、今回選考の一環としてこのインターンに参加していました。

今回のインターンは完全リモートで、私は関西にいながら参加していました。対面できない、会社の風景が見られないというのはデメリットですが、全く別の場所からインターンに参加できるというのは大きなメリットと思います。

事前面談でメンターとなる方とコミュニケーションを取って参加するプロジェクトが決まり、インターン前日にMacなどの備品が郵送され初日開始という流れでインターンが始まりました。

解決した課題

私が配属されたのは「八月のシンデレラナイン」を開発しているチームで、主に新機能開発の課題に取り組むことになりました。私が担当していたものはおそらく今リリースされているハチナイには入っている機能だと思います。

私は今回、2つの機能の改善や実装を行いました。

メニューのカスタム画面の改善

この課題は私のPCのセットアップが何とか終わった初日の翌日、火曜日から始まりました。

右上の[MENU]をタップで出てくるメニュー画面内には、左上にメニュー画面そのものをカスタマイズするボタンがあります。(私は気付いていませんでした。そこそこやってたのに…)
この画面ではメニューのカスタマイズが出来るのですが、これを保存する時にフィードバックがなく、また、保存せずに戻ると変更内容が破棄されるという仕様でした。
そこで、これにフィードバックを付けよう　というのが私が最初に取り組んだ課題になります。

やったこと

まずどのような仕様、デザインにするかを決めなければなりません。そのため、火曜日早々に私主宰でデザイナー/企画の方とMTGを組むことになりました。大変緊張しました。
すぐにMTGを組むつもりだったのですが、メンターの方に主催者は実装の方針をある程度固めた状態で始めた方が良いと教わり、夕方からのMTGに設定しました。
その間に私はコードを読み、おそらくオーダー編成画面が参考になるだろうと思い、MTGでここの表現(機能)を使うつもりでいますと話しました。皆さんからありがたくも賛同いただき、この方向での実装に決まりました。
決まった仕様は、変更を保存するときは[保存しました]と中心に出し、変更があるまま戻る時は確認のダイアログを表示する　というものになりました。

ダイアログ表示の実装自体はそこそこ順調に進んだのですが、連続して保存するとおかしくなるケースやそもそも保存できないケースがあるなどいくつかの問題点があり、それらを解決しきったのが結局木曜日になりました。中々苦労しました。あとGitでいろいろやらかしブランチがたくさん生まれ消えて行きました。
木曜夜に修正が終わったPRを出し、一旦はこのタスクが終了しました。レビュー待ちをしている間に次の課題に取り掛かりました。

思ったこと

MTGではデザイナー/企画の方を交え、なぜここがこういう挙動なのか、ここはどうして行くべきかといった話ができたのがとても面白かったです。例えば、既存の保存ボタンは殆どのユーザーさん達が頻繁に押すボタンではないだろうから同時に閉じた方が操作の手間が減るだったり、これからの実装でオーダー編成画面を参考にするのであればその挙動に合わせた方が良いだったり、そういった仕様の部分からのお話ができるとは思っていなかったので嬉しかったです。
そして、仕様通りに作ることの難しさも感じました。単に実装すると仕様と異なる挙動をする〜みたいなケースが結構起こり、なかなか思った通りの操作をさせるのが難しいなと思いました。

キズナレベルアップ演出の改善

私が取り組んだもう一つの課題は、キズナレベルアップの演出をよりリッチでかわいいものに変更する　というものでした。
既存のキズナレベルアップ演出は左右からキャラクターの立ち絵が出てきてレベルアップの表示が行われるというものでしたが、それをSDキャラがカットインアニメーションをした後ハイタッチしてレベルアップの表示が行われるというアニメーションに変える　というものです。
アニメーションはデザイナーの方が作って頂いていたのですが、最初のMTGでアニメーションを見た時めっちゃ可愛いですねーという話をしたのを覚えています。非常に可愛いアニメーションです。

やったこと

まずは1つ目の課題と同様、MTGを設定しデザイナーの方と課題を確認しました。今回はアニメーションの変更だけなので企画の方はいませんでした。
その後デザイナーの方からデータをいただき、それをキズナレベルアップ時にちゃんと再生されるように実装を進めました。
この時は既存コードがどのように練習しているキャラクターのデータを流しているのかを追い、その流れに乗せてアニメーションが再生されるように実装しました。

アニメーションを動かす実装をしている間に、スキップ機能が必要ではないかという話になりました。これを実装し始めた時点ではスキップは考えていなかったのですが、アニメーション全体が長くなったため、画面タップで適切なタイミングまでアニメーションを飛ばせないとユーザーさん達の待ち時間が長くなってしまうという問題がありました。そこでデザイナー/企画の方とコミュニケーションをとり、必要そうだという結論に至ったのでこの機能を追加で実装することになりました。

スキップ機能はやりたいこととしては単純で、画面上をタップされたらアニメーションを特定の地点に飛ばす　といったものです。しかし、これを綺麗に実装するのは中々大変で、デザイナーの方と何度もお話をしながらアニメーションデータそのものの変更もしてもらい、その上で実装を進めました。
水曜日にこの機能の実装が何とか終わり、PRを出してレビューしてもらいました。

そして木曜日にはレビューが返ってきたのですが、アニメーション遷移のより良い方法があること、スキップするためのボタンの配置の場所があまり良くなかったこと、そしてアニメーション終了の処理にUniRxが使えるということを教えて頂きました。
UniRxは私がインターン中に学びたいことの1つとして挙げていて、それを学べる機会をここで作って頂けました。なのでこの日一日はUniRxのことを調べ、コード内に使われている部分を参考にしつつ実装を進めました。
何とか木曜の夜に実装が終わり、完全な形のPRを出し切り、私のこの十日間のインターンでの実装が終了しました。

思ったこと

適切な粒度でのコミュニケーションの難しさというのをすごく感じました。この課題では1つ目のものより多くのコミュニケーションを取ったのですが、私が十分に伝えきれなかったり解釈を間違えたりで手戻りをさせてしまうことがありました。みんな自分の考えや思いを持っているので、それを適切に表現できる、汲み取る力の重要さを感じました。
ボタン関連の処理やアニメーションを扱うにあたり、UniRxは非常に使いやすいと思いました。学んでいる最中では同じ意味の処理を無駄に長いコードで書いてしまったりしていましたが、それも含めて非常に良い経験をさせてもらったと思っています。

業務を通じて学んだこと

チームでの開発がどのように進んでいくのか

今回得られた知見の中で最も大きなものがこれだと思っています。
クライアントエンジニアは機能開発を行う時どのようにデザイナー/プランナーの方とコミュニケーションをとり、どのように業務を進めていくのか。私は特に企画やデザインとも多く関われる方が好きなので、アカツキでは実際そういう風に開発が進んでいくというのを感じられたのは非常によかったと思っています。

UniRx

技術的な知識として、私が前々から付けたいと思っていたものがこのUniRxでした。今回のインターンではほぼ1日かけてUniRxについて調べ、実際の業務レベルのコードも読めるといった非常に良い環境で学ばせてもらい、知識がとても深まりました。
これまでは正直ほぼ使えないぐらいの知識しかなかったのですが、今回で多少使えるようになったと思っています。

Git (Github)

集団開発においては必須のツールですが、これまでは趣味での開発や個人開発がほとんどだったのでまともなレベルで使っていませんでした。しかし今回のインターンでは1つ目の課題からGitを(当然ですが)使うことになり、分からないことが多いながらもとても勉強になりました。
ただもう少しGitの基本的な使い方に慣れておくべきだったなぁという後悔もあります。少なくとも今回インターンで使った機能は忘れず、使っていこうと思います。

直接の業務以外のこと

課題解決の実装を主にやっていましたが、ランチで先輩社員とお話したり1on1を毎日設けてもらったりとかなり充実したインターンを設定して頂けました。

ランチ

基本的には私がこんな人に会いたい！と事前にリクエストして、それにマッチした方とお話しする　という流れでした。LTで既に面識のある先輩社員の方に助けてもらったおかげで、私は十日間のインターンにも関わらずランチが5回もあり、ものすごくいろんなことを伺うことができました。どのランチでのお話も面白く、いろいろなことを知れました。

1on1

メンターの方と毎日朝夕2回の1on1を設定して頂きました。これのおかげで自分が今日何をやるのか、何ができたのかがより明確になりとても業務が進めやすかったです。

朝会夕会

私が所属していたチームは朝会と夕会があり、毎日アイスブレイクということで誰かが適当なトピックを5分ぐらい話すという場がありました。チーム自体の雰囲気が非常に良いというのが伝わってきましたし、話も毎日別のトピックで面白かったです。もちろんアイスブレイク後には共有するべきことも話していました。

アップデート

私がいる間にハチナイのアプデがあり、中でどういったことが起こっているのか、運用チームやサーバー側はどんなことをしているのを横から眺めることができました。空き時間にこういうことをやっているという説明もして頂き、(横から見ているだけの私は)とても楽しかったです。実際担当するとヒヤヒヤするだろうなぁと思います。

コードリーディング

UniRxでもそうですが、私は既存のコードを読むのが結構好きで、今回はいろいろな場面でコードを読めて面白かったです。特に業務レベルのコードだと、こうすればよかったのか！みたいな発見が結構あるので、非常に勉強になりました。

テキストベースコミュニケーション

私はこれまであまりSlackなどを活用していなかったので、今回のインターンでのテキストベースのコミュニケーションは中々慣れないものがありました。最後メンターの方からそれほど悪くなかったよと言われたのがすごく嬉しかったです。テキストベースだと非同期的にコミュニケーションが取れ、また後々ログが残るという良さもあり、今回の経験も含めて慣れて行きたいと思います。

まとめ

非常に短期のインターンでしたが、十日間とは思えない充実ぶりでした。会社の空気感や業務の進め方、雰囲気、そして技術的な知見ととても多くのことを学ぶことができました。
短い間でしたが、本当に皆さんお世話になりました。ありがとうございました！！

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

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

はじめに

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

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

自己紹介

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

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

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

タスク内容

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

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

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

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

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

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

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

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

感想

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

チーム開発の大変さ

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

アカツキの雰囲気の良さ

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

おわりに

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

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

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

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

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

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

はじめに

何者？

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

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

やったこと

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

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

概要 

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

期間限定アイテム変換

問題点・改善点

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

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

まとめ

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

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

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

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

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

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

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

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

はじめに

自己紹介

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

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

インターンの実施内容

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

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

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

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

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

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

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

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

新規ミッションの実装

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

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

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

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

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

振り返り

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

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

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

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

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

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

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

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

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

アカツキの文化・環境

風通しがいい

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

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

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

成長しやすい環境

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

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

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

まとめ

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

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

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

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

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

インターンについて

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

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

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

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

やったこと

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

課題設定

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

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

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

設計

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

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

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

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

実装

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

確認

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

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

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

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

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

追加の実装

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

プルリク&マージ

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

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

学んだこと

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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