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

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

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

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

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に関するタスクでした。普段から開発する中で、自分の中に課題としてあったので取り組めたら良いなと思っていました。

 

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

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

 

その三つとは

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

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

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

です。

 

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

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

 

f:id:iidatakuya:20200911172337p:plain

 

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

 

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

 

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

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

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

 

最初少し驚きました笑

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

 

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

 

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

 

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

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

 

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

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

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

 

f:id:iidatakuya:20200911182028p:plain

 

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

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

 

 

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

 

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

 

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

 

f:id:iidatakuya:20200911182818p:plain

 

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

 

f:id:iidatakuya:20200911182953p:plain


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

 

f:id:iidatakuya:20200911191043p:plain

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

インターンを終えて

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

 

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

 

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

 

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

 

 

 

 

Akatsuki GAME JAM 2020 オンライン開催レポート

こんにちは、エンジニア採用担当の橋本です。

去る9月12日(土)〜13日(日)に2022年新卒エンジニア向けインターンシップ「Akatsuki GAME JAM」を開催いたしました。今年で第6回となる当インターンシップですが、今年は初のオンライン開催。

オンラインでの難しさもありながら、全チームがゲームを作りきり、参加者から非常に高い満足度を得た今回のインターンシップの様子をご紹介致します!

 

はじめに

#「Akatsuki GAME JAM」とは・・・

2日間を通して、ゲームアイデアの企画から開発までを行い、その制作物の結果を競い合うという内容です。今回のテーマはアカツキが創業10周年を迎えたこともあり「10」。計17名の参加者が5チームに分かれ、Unityで開発を行いました。 

f:id:kana_hashimoto:20201011222727p:plain

#なぜこのようなインターンシップをアカツキが実施するのか

「IPの世界観を深く理解したゲームを開発し、ファンとの長期的な関係を構築すること」を強みとするアカツキでは参加者の皆さんに「ゲーム開発を通して、世の中をワクワクさせるようなプロダクトづくりを体験をしてもらいたい!」という想いを持っています。

もちろん、参加者の中には多数のハッカソン参加経験のある方や、サークルなどでチーム開発を経験している方もいらっしゃいます。一方で、多くの学生とお話をする中で、ゲーム開発への情熱や個人でのプロダクト開発経験はあっても、プロのエンジニアから近い距離でアドバイスをもらいながら、チームで開発を進める経験をしたことがある学生は少なく、その機会を創出したいと思い開催しています。

 #参加を通じて得られる経験
・最速で最大の価値を出す経験
・プロジェクトマネジメント、コミニュケーション等のチーム開発力
・各チームの専属メンターからのコードレビューを含む個別サポート
・発想力、技術力、プレゼン能力

 #参加者と開催方法

今回の参加者は、イベントや直接GAME JAMの応募ページから応募いただいた方の中から複数回の面談・面接を経て、17名にご参加いただきました。中には学部の時に初めてお会いした学生が院生となり応募してくれたケースもあり、非常に嬉しい再会となりました。

元々は9月に例年通りオフラインでの開催を予定していましたが、コロナ禍の影響を顧みて、全国各地から参加いただく学生の方も多いことから7月末にオンラインでの開催に切り替えました。

オンライン開催による変更点・工夫

#参加者全員の『9マス自己紹介』を実施

9マス自己紹介とは、その名の通り自分に関わるキーワード(なんでもOK!真ん中には自分の名前を入れます。)を9つ書き出して紹介するというものです。通常の自己紹介より準備に時間がかからずに非常に盛り上がるため、オススメの自己紹介方法です。

全員で初日の午前中に一人3分ずつ行い、更にこれをZoom背景として設定することで、今回メインのコミュニケーションツールの一つとなったZoomでの会話時にも相互理解が深まり、アイデアのきっかけにも繋がっていたようでした。

f:id:kana_hashimoto:20201011223102p:plain

▲メンターメンバーの9マス自己紹介例

#アイデアソンの事前準備
今回、オンラインでのアイデアソンの難易度を考慮し、参加者には事前課題として「ペライチアイデアシート」を準備してもらいました。
事前対応事項が増えてしまったにも関わらず、すぐに多くの素敵なアイデアが集まっていく様子を見て、開催前にも関わらず運営陣はすでに感動で胸がいっぱいに・・!笑

▼ペライチアイデアシート 

f:id:kana_hashimoto:20201016190434p:plain

画面/プレイイメージがあるためオンラインでも視覚的にコミュニケーションが取りやすく、節約した時間を開発時間に充てることができました。当日はさらに、このアイデアシートを元に他チームのメンバーとペアになりアイデア発表&相互フィードバックを行うことで、様々な視点からアイデアが磨かれていきました。

上記2点のほかにも、予め全員の開発環境を統一するなど、参加者の協力を得ながら無事オンラインで開催することができました。

当日の様子(開発〜成果発表、結果発表まで)

#開発

アイデアソンを終えて企画が決まったところで、いよいよ開発開始です。

開発中は、各チームのメンターが基本的に常時チームとZoomを繋ぎながらコミュニケーションをとっていたのですが、オンラインながらも例年通り白熱する議論や笑い声が飛び交い、非常に熱量の高い空間でした。段々と、チームを引っ張っていくリーダー、落ちているタスクを拾い適宜サポートする方など各々の役割が見え始めていきます。

   開発中の様子 初めは緊張していたメンバーからも次第に笑みが溢れます。

f:id:kana_hashimoto:20201016190703p:plain

今回はイラストが描ける強者も多く、キャラクターや武器のデザインを行うチームもありました。ハイクオリティ・・・!

 キャラクターデザインの様子

f:id:kana_hashimoto:20201012001107p:plain

#成果発表会

開発時間はあっという間に過ぎ、いよいよ2日目の成果物のプレゼンテーションへ。各チーム着実にプレゼンの練習を行い、各々が制作したゲームのこだわりや面白みを伝えてくれました。特に今回のテーマである「10」との関わり方は、10を武器にして闘う、体の大きさが10倍になる、など各チームとてもユニークでした。発表に対しては、メンターを務めたアカツキメンバーや参加者からも多くの質問が飛び交い、非常に盛り上がりました。

▼成果発表会の様子

f:id:kana_hashimoto:20201012202431p:plain

#試遊会

発表後には、各チームのゲームを体験できる試遊会を実施。通常であれば、ヘッドマウントディスプレイを貸与しVRゲームを開発するチームもありますが、今回はリモートで全員の開発環境が揃えることが難しいため、Unityのエディタ上で遊べるゲームに限定させてもらいました。

アカツキのメンター陣と運営チームは、ソーシャルディスタンスを守りながらオフィスに集まり、参加者のみなさんが開発したゲームを楽しみました。どのチームのゲームも本当におもしろく、GAME OVERになると「もう一回やらせて!」とかなりハマっている様子でした。

▼試遊会(アカツキメンバー)

f:id:kana_hashimoto:20201012003309p:plain

※撮影時のみマスクを外しています。

#結果発表

いよいよ運命の結果発表。

準優勝チームはなんと....同点で2チーム!「TEN倍ヤー」というタイトルを開発したチーム「Akebono」と「1 by One」を開発した君のAirPodsProをたべたい」の2チームが受賞しました。ユニークなアイデアと、細部のエフェクトや操作性・ゲーム性を備えた作品に審査員の評価が集まりました!

▼「TEN倍ヤー」by Team Akebono

f:id:kana_hashimoto:20201012202324p:plain

▼「1 by One」by Team 君のAirPodsProをたべたい

f:id:kana_hashimoto:20201016190906p:plain

そして、栄えある優勝は...「PLUSLIME」というゲームを開発したチーム「ネコヤムクン」でした!独自のゲームルールを採用しつつもシンプルでわかりやすく、何よりも完成度が突出していたことが高い評価を受けていました。また、ゲームバランスも工夫されており、何度も挑戦したくなるような夢中になれる素晴らしいゲームでした!

▼「PLUSLIME」by Team ネコヤムクン

f:id:kana_hashimoto:20201016191148p:plain

#オンライン懇親会

結果発表の後は、Zoomのブレイクアウトルームで分かれて懇親会を行いました。「もっとこうしていたら...この機能を実装できていたら..!」など悔しい気持ちもありつつも参加者のみなさん全員「本当に全力でやり切った!」という清々しい達成感にあふれていたのが印象的でした。2日間の開発の疲労を全く感じさせない盛り上がりで、1時間の懇親会はあっという間に終了。

実は今回、突然のオンライン開催への切り替えによりオフィスの紹介ができなくなってしまったこと、そしてキラキラしたみなさんの姿を見ていたら何か記憶に残る思い出を残したい!と思いこの2日間の思い出ムービー(オフィスツアー付き)を作らせてもらいました。「こんなサプライズは初めて!」と喜んでいただき、運営陣も感無量でした。

▼Zoom画面越しにみんなで乾杯!

f:id:kana_hashimoto:20201016192548p:plain

f:id:kana_hashimoto:20201016192612p:plain

最後に

本当にあっという間の2日間でした。是非、今回のインターンシップが一つの学びとなり、みなさんの次なる挑戦に繋がれば幸いです!そして、この出会いをこの場限りで終わらせるのではなく、また次の機会で参加者のみなさんにお会いできることを楽しみにしています。

▼嬉しいことに、参加者の方がブログを書いてくださいました^^!タイムライン毎の詳しい紹介に加え、自身の振り返りもあり読み応えのある内容です。是非ご覧ください。

 

 それでは、また来年のGame Jamでお会いしましょう!

アカツキでAWS ECS Capacity Providerと格闘して

こんにちは!

この度サーバサイドエンジニアとしてインターンシップで勤務させていただきました、髙津と申します。

本記事では、インターンシップ期間 (2020年7月6日〜7月31日) 中に取り組んだこと、感じたことなどを書いていきます。似たような技術課題に直面している方々、これからインターンシップを受けようと考えている方などの手助けになれば幸いです。

具体的には

  • インターンシップで取り組んだこと
    • 知見
      • Capacity Providerの具体的な設定項目
      • Auto Scalingの仕組みのおさらいと設定項目一覧
    • 検証
      • 懸念事項
      • 1. 動作の上で最適な設定は何か?
        • 1.1. SSPタイプはどちらが良いのか?
        • 1.2. Scalingトリガーとして適切なメトリクスは何か?
        • 2. Scalingは十分に速いか?
        • 3. 安全にScale Inできるか?
    • まとめ
  • インターンシップを通じて感じたこと
    • 取り組んだ課題に関連して感じたこと
    • 課題以外の面で感じたこと
  • 最後に
  • 参考資料

の構成でお伝えしていきます。

続きを読む

出社0回!これが完全リモートインターンシップのリアルだ!

こんにちは!2020年7月にアカツキでサマーインターンシップを行いました栁です!

COVID-19(新型コロナウイルス感染症)、世の中は本当に大変なことになりました。僕のインターンシップ活動も例外ではありません。 なんせ、インターンシップが完全リモートで開催されました。 出社は0回、メンターはおろかアカツキの社員さんと1回も直接顔を見ることなく終わります。

「それじゃインターンシップの意味なくない?」「ちゃんと仕事できるのか心配……」

僕も開始前はそう思いました。でもインターンシップで就職前に一足先に完全リモート勤務を体験できてよかったと今ははっきりと言えます。 インターンシップだったからこそ、完全リモート勤務のいいところと、意識して気をつけるべきところをかなり明確化することができたのです。

3週間の完全リモートインターンシップで自分がどのような活動をしたのか、何に気をつけたのか、皆様に共有します。

はじめに

普段は電気通信大学院の修士2年としてSNS上からフェイクニュースを自動で検出するAIモデルの研究開発を行う傍ら、株式会社justInCase Technologies(jICT)にて少額短期保険サービスのバックエンド開発を行っています。 「修士2年だから21卒じゃないの?」と思う人もいるかもしれません。実は8月から1年間の研究留学を行うために卒業を1年送らせて22卒となる予定でした。コロナのせいで22卒のプランは破綻寸前になってしまいましたが……

そして同じく予定されていたインターンシップはフルリモートに。限られた期間で最初から最後まで完全リモートで活動するのはこれが初めてでした。

このエントリーでは、

  • なぜアカツキのインターンシップに参加したのか
  • インターンシップの内容と環境
  • 実際に活動において気をつけたポイント
  • 全体の所感と提言

をまとめました。「コロナの影響でインターンがフルリモートになってしまった……」な学生さんはもちろん、初めてメンターを行うはずがフルリモートとなり不安を覚えるエンジニアの方にも大きなヒントになるでしょう。是非ご一読ください。

アカツキのインターンシップに参加した理由

僕がアカツキの名前を知ったのは自分が学部1年だった頃(2015年)に、アカツキのエンジニアが大学に講演会に訪れたことでした。 そこから時代は流れ、本格的にインターンシップを検討し始めたのは今年開催された逆求人イベントでした。

当時自分はjICTにてバックエンド開発の経験こそあれ、規模の大きいシステムに触れる経験が足りていないのを実感していました。 そのため、大規模システムに触れることができる完全就業形インターンシップで、(留学の影響もあったため)8月までで完了するものを探していました。 アカツキが提供しているゲームはいずれも規模の大きいものが多く、またゲームという性質上ユーザからのリクエスト数も瞬間的に多くなるシチュエーションがあり、そういった状況下でも安定してサービスを提供しているシステムはどのような形で開発・運用されているのか、非常に強い興味を持っていました。

また、事前にインターンシップが完全リモートになることは告げられていましたが、リモートワーク自体はjICTで既にある程度経験していました。 最初から最後までリモートでやるのは初めてでしたが、これまでの経験を活かせば十分出社と同じバリューを提供できると考えました。

以上より、僕はアカツキの完全就業形インターンシップに参加することにしたのです。

実際の活動内容と環境

この章では、完全リモートとなったインターンシップで自分がやったことと、活動の環境を紹介します。

技術的に行った作業

今回はスマートフォン向けゲームアプリのAPIサーバを対象に、以下の実装を行いました。

  1. 実装予定の新モードと既存モードのアップデートとのすり合わせ
  2. 既存コードのリファクタリング

前者では、既存機能のアップデートにより新たに追加された機能が、まだ実装前の新モードと矛盾を起こさないように開発中の新モードの手直しを行いました。後者では、自分のメンターがプロジェクトにjoinする前から存在する古いテストコード(いわゆるレガシーコード)のリファクタリングなどを行いました。

勤務環境の紹介

勤務はすべて自宅から行いました。使用するPCは事前にアカツキから送付されたPC(MBP 13")を使いました。 また、自分は実家暮らしでインターネット環境は予め整っていましたが、そうでない人を対象にWi-Fiの貸与も行っていました。

開発においては多くの外部サービス(GitHub, JIRA, Confluence, etc.)を使用しており、一部はVPNを経由する必要はありますが、OneLoginによってシームレスに使えるようにされていました。

社内コミュニケーションは基本Slackを使っており、プロジェクト毎にワークスペースが区切られており、細かくチャンネルは目的別に分けられていました。 また対面での会話を行いたい場合は、Zoomを使用していました。 自分が配属されたチームでは、任意で常時接続用のZoomルームも用意されていて(カメラやマイクの有無はもちろん任意)、朝会や夕会もその部屋で行われました。

気をつけたポイント

この章では、実際の勤務において気をつけたポイントを共有します。

初めてrailsを扱った

自分のメイン言語はPythonであり、railsを扱うのはこれが初めてでした。 勤務開始前にrailsチュートリアルで重要な章を列挙して頂き、事前に一通り読んでおくことで比較的スムーズに勤務を進めることができました。 また技術的にもわからない部分は気軽にメンターの方へ質問ができる状態でした。

アンチパターンとの格闘

技術的な部分では最も手を焼いた部分でした。 例えばrequestを送って挙動を確認するテストコードを例に取ると、既存のものはresponseの構造と対応する値の型のみを確認して、DB内のレコードの変化を一切確認しておらず、だいぶ緩い形をとっていました。これでは起きうる障害を早い段階で捉えることは難しくなってしまいます。

最初は自分は既存テストコードをリスペクトしてその意図を忠実に反映した形にしていましたが、リスペクトすべきは実装の部分であってテストコードではないのを痛感しました。 それを実現するためにテスト上でDBレコードを発行し、request送付後の変化を調べる処理を追加することで対処しました。

やはり規模が大きいのも相まってコードの数も非常に多く、中にはメンターですら首を傾げるような処理もあり、読解の難易度が少し高かったです。 こういったサービスに今後関わるにはこういったアンチパターンを孕んだレガシーコードとの格闘は必須であるため、インターンが終わった後には "レガシーコードからの脱却" を読むことにします。

対面でのコミュニケーションが封じられた

完全リモートは即ち直接面と向かって相談することができないことを意味します。 実際に自分がとったコミュニケーションを調べてみると、大まかにSlack9割Zoom1割でした。

円滑なコミュニケーションのため、Slack上ではこれから実装するトピックのスレッドを立て、そこへのレスポンスで"どんなコードを入れたか"・"どんな結果が返されたか"・"何が原因として考えられるか"・"対策でどんなコードを入れたか"・……といったサイクルをとにかく仔細に入れることを意識しました。 こうすれば、メンターの手が空いた時に読んでもらえる上に、急を要する際はメンションを飛ばすことで手軽に相談できるような環境を整えました。 そしてそれをメンターはもちろんワークスペースのエンジニア達から見える場所に書き記すことで、時にはメンター以外の人からの助力を得ることにも繋がりますし、後から自分が見返してこのようなエントリーを作る際にも役立ちます。 それでも解決が難しければ、Zoom部屋を立ててメンターの方と画面共有でリアルタイムで会話しながら問題解決を目指しました。

これは是非リモートワークの際には試してみて欲しいです。

全体の所感

大規模サービスのコードに触れられた

当初の目的として掲げていた規模の大きいサービスの内情を知ることができたのは非常に大きかったです。 常に多くのチームがそれぞれの目標やタスクに向けて動くことで、発生した問題に対処しつつ新たな要素の追加を実現していることを肌で感じることができました。

完全リモートをいち早く体験できた

1度も出社しない勤務を就職前に行うことで、今後の自分の働き方がどのような形になりうるかを具体化することができました。 情報共有のやり方はこれまでとは大きく違うフォーマットが求められるので、早いうちにそれに慣れる機会となりました。

多くの人々と知り合うことは難しかった

基本的には会話する相手が配属先のチームに限られるので、他の部署の人と会う機会は出社する場合と比べて少なくなりました。 一応人事の方とはリモート昼ごはんで合うことはできましたが、こういった機会を事前にちゃんと用意する必要があり、偶然の出会いが生まれにくいのは少しアカツキの文化を知る際に障壁となりました。

提言

  • 完全リモート勤務はタスクをこなす分にはあまり障壁にならないので心配は無用
  • 多くの人と知り合う機会は減るので、積極的にコミュニケーションを仕掛けておいて損はない

さいごに

短い期間でイレギュラーとなる勤務の形となりましたが、実際のサービス運営の現場で活動することで、今後の働く形と自分の技術力を磨く大きな経験をさせて頂きました。間違いなく自分の今後を考える上で大きな財産となりました。本当にありがとうございました。