Akatsuki Games Internship 2022のRuby on Rails / AWS コースに参加しました

自己紹介

同志社大学大学院M1の赤沢聖斗です。大学ではブレインマシーンインタフェースの研究をしており、アルバイトや趣味でWebアプリの開発をしています。

作業内容

今回のタスク内容はお知らせツールの改善というタスクを行いました。

お知らせツールとは？

ゲームでは、開催中のイベントなどをお知らせを通してユーザに表示しています。お知らせツールとはこれらのお知らせを作成するために利用する社内ツールのことです。今回のインターンではそのお知らせツールを使いやすくするように改善しました。

お知らせツールの使い方

簡単にお知らせツールの使い方を説明したいと思います。

お知らせツールでは下記のテキストエリアに、実際にお知らせで表示させる文言を入力していきます。

お知らせの文言を入力するテキストエリア

このお知らせツールでは文字の大きさや色を変更するために独自のマークアップ表現を使っています。例えば、下記のように"{size: 50}{size}"などのタグで囲むことで文字サイズや、色などを指定することができます。

お知らせツールでの文字の入力方法

そして、このタグを組み合わせて本格的な文を作ると下記のようになります。

お知らせの例

作業手順

インターンは3週間という短い期間なので、期間内に結果を残せるようにスケジュールを立てました。作業手順としては、

1. 現状のお知らせツールの課題の洗い出し
2. タスクの優先順位の決定
3. お知らせツールのコードを読む
4. 改善案の検討と実装
5. お知らせツールを使っている方々にフィードバックをもらう
6. フィードバックを元に修正

1. 現状のお知らせツールの課題の洗い出し

まず、お知らせツールの使いにくい箇所の洗い出しから始めました。方法としては、実際に自分で使ってみて、使いにくいと感じた箇所の抽出と、実際にお知らせツールを使っている方々にヒアリングを行いました。

課題の洗い出しの様子

ヒアリングした結果下記のような課題が出てきました。

• 文字の大きさ/色等の独自タグを毎回入力するのが大変
• マークアップのプレビューがリアルタイムではなく、都度保存しないと確認することができないのが大変
• 添付画像を検索する際に、今の検索機能だと機能不足で使いにくい
• 検索結果が重複されて表示されることが稀にあるので不便

2. タスクの優先順位の決定

洗い出した課題から、作業工数や需要をもとに優先順位を決めました。そして、今回のインターンでは「文字の大きさ/色等の独自タグを毎回入力するのが大変」という課題を解決することにしました。

3. お知らせツールのコードを読む

実際に着手する前に、既存のお知らせツールの実装や処理の流れを確認しました。しかし、ファイル数が多くファイルの関係性が複雑だということもあり、直接コードを読むのが難しいと感じたので、miroというツールを使って各ファイルがどのようにつながっているかを可視化しながら読み進めました。

ファイルの関係性をmiroに書き出している様子（一部隠しています）

4. 改善案の検討と実装

お知らせツールの文字の入力の利便化を行うためにどのように実装するかを検討しました。今回は、独自タグを挿入してくれるボタンを用意することが一番楽に課題を解決することができ、使いやすいのではないかと考えました。

そして、ボタンを配置するためにJavaScriptを使って既存のDOMに対してボタンの追加や修正を加えて、CSSを使ってスタイルを整えました。下記に記したものがお知らせツール第一号です。テキストエリアの上部にタグを挿入するボタンとプルダウンメニューを配置しました。

お知らせツール第一号（一部隠しています）

5. お知らせツールを使っている方々にフィードバックをもらう

次に、改善したお知らせツール第一号に対して、実際に普段使っている方々にフィードバックをいただきました。フィードバックでは、こういうボタンが欲しいなどの要望や、改善することに対して感謝の言葉などをいただくことができました。

フィードバックの様子（一部隠しています）

6. フィードバックを元に修正

最後に、頂いたフィードバックをもとに修正を行いました。今回のインターンで改善することができなかった課題はまだ残っているので、今後もサーバーチームでツールの改善を継続する予定です。

修正版お知らせツール（一部隠しています）

インターンで心掛けていたこと

今回インターンをするにあたって、心がけていたことを紹介させていただきます。

slackに自分の作業ログを残す

フルリモートでの作業だったので、メンターさんに自分が何をしていたのか、何で詰まっているのかが把握しやすいように、独り言のようにslackのチャンネルに作業内容などを投稿していました。

ユーザー目線での開発

今回はお知らせツールの改善をおこなっていたので、お知らせを作成する方々がユーザーとして、どのように実装したら使いやすくなるのかということと、ヒアリングやフィードバックでは色々と意見が引き出しやすいように資料を作成するなどの準備を行いました。

余裕を持って作業

インターン期間の終了直前に焦らないように、スケジュールを立てること。先にできることは着手し、余裕を持って作業をすることを心がけました。

まとめ

今回のタスクでは、オンラインでの作業、異なるチームとのコミュニケーションが必要ということもあり、非同期のコミュニケーションが増え、欲しい情報をすぐに得ることができないということの難しさを感じました。しかし、いろいろな方にサポートしていただけたおかげで、目標としていたところまでの作業ができました。

また、アカツキゲームスで実際に働いてみて、個人の裁量権が多く、自由度が高いという印象でした。さらに、技術のレベルが高く、すごく良い環境だと感じました。本当に学ぶことが多く、あっという間にインターンが終わってしまいました。短い間でしたが、ありがとうございました。

株式会社アカツキゲームスのインターンにクライアントエンジニアとして参加した話

はじめに

9月1日から9月22日の間クライアントエンジニアとしてインターンに参加してきたのでそれについてのブログを書こうと思います。

自己紹介

某専門学校でゲーム制作を学んでいる３回生の学生です。

学校ではUnityやUnrealEngineなどのゲームエンジンやDirectX11でゲーム開発をしています。ゲームで遊ぶことはもちろん、ゲームを作ることが好きで１クリエイターとしてゲーム業界を盛り上げる1人になりたいその一心で日々ゲーム開発に向き合っています。

　開発末期の苦しさもまた快感　

目次

取り組んだこと

クライアントエンジニアのインターンではモバイルゲームのタイトルに携わらせていただきました。そこで「実際にリリースされる新規機能の開発」を行いました。業務は以下の流れで取り組みました。

• 新規機能の仕様説明
• スケジュール作成
• 実装
• 挙動チェック
• レビュー

私は「一部画面UIレイアウトの変更」を担当しました。

新規機能の仕様説明

実際の仕様書を頂いて、担当のプランナーの方に説明をしてもらいます。ここの段階で不明なところや仕様の意図を聞いてすり合わせを行います。この工程を入れることでプランナーの方との認識のずれを無くすことや、仕様の意図を聞いてより良い案があれば提案することでゲームをより良くしていきます。エンジニアもゲームを良くするために意見を出すことが大切ということを学びました。仕様の意図や現時点の問題点を詳しく教えて頂いたので、初めての新規開発でもスムーズに行うことができました。

スケジュール作成

仕様を確認したらスケジュールを作成します。必ず納期があるので計画的に進めることが大切です。(ゲーム開発は納期がないとずっとこだわり続けてしまいます) 新規機能に必要なタスクを分解して、正しい順序で無理のないスケジュールになってるかを確認して実装に入ります。

実装

早速実装に入ります。デザインを指定通りに組み込むことや仕様通りの挙動になっているかを気をつけながら実装を行います。初めての大規模開発に苦戦し難航したため、クライアントエンジニアの方々に要請をしてモブワーク*1を行いました。実際にプロのエンジニアとして働いている方々とのモブワークを行うことで経験値の差を感じたのと、開発者としてのテクニックや技術を直々に教えていただきました。成長するきっかけにもなりましたし、何よりもっと技術を磨きたいというモチベーションアップにもなりました。

挙動チェック

実装が完了したら挙動の確認を行います。まず正常に動いているか確認をしてプランナーの方とデザイナーの方に見ていただきます。ここで仕様通りに動いているか、正しくデザインが反映されているかを確認していきます。最初のフェーズの打ち合わせを疎かにするとここのフェーズで大きな手戻りになる可能性があるので最初の打ち合わせと最後の確認は丁寧に行います。ゲーム開発は様々な人で行います。コミュニケーションは非常に大事です。

コードレビュー

最後にコードレビューを行います。これはコードの品質を保つために行います。出したプルリクエストに対して複数人で正しい実装になっているか、コメントは適切に書かれているか、無駄な処理はないかなどをチェックしていただきます。関数名や変数名で用途が分かるように付けることで別の人が開発する際にスムーズに開発できるようにします。

学んだこと

コミュニケーション

当たり前と思うかもしれませんが、当たり前ではないのです。「面白い」という抽象的なコンテンツを開発する以上かなり気をつける必要があります。仕様に対しても分かった気になるのではなく、何度も何度も確認やすり合わせをします。実際に開発の現場に入ることでタスクの進捗や問題に対しての確認と対策などチャット上で頻繁にコミュニケーションを行なっていました。（基本的に通知が0の瞬間はないです）　当たり前のことではありますが、そのコミュニケーションの精度を高めることができました。

コーディング

PR*2上でのコードレビューで命名規則やコメントの付け方など、他者に見てもらう意識がかなりつきました。大規模な開発になればなるほど独りよがりなコードを書くべきではないと感じました。クラス名や関数名、変数名で機能が分かるようにすること、誤解のないように正しく丁寧にコメントをつけることが実務で学べたことは非常に良い経験ができたと思います。細かいことですが大規模開発に直面すると重要性に気づくと思います。1人でも他者に見てもらうことを意識していこうと思います。

「なぜ？」の重要性

今回のインターンで一番学んだことです。この「なぜ？」には「認識の共通化」と「自己成長の切り口」二つの効果があると思います。仕様や実装に対して「なぜ？」を聞くこと、伝えることで相手と自分の認識を確認することができます。また、自分が得意とすること、苦手とすること、他者との差に「なぜ？」を問うことで成長の糸口になります。「なぜ？」上手く使い根本的な原因と向き合うことや一歩先を見た行動や考えを持つことが大切だと思います。

まとめ

今回インターンを受け入れてくださり本当にありがとうございました。エンジニアとしての技術はもちろん、クリエイターを志す１人としても多くの学びを得ることができました。このインターンで学んだことを生涯のゲーム開発に活かしていきたいと思います！

*1:複数人で作業を行う

*2:プルリクエスト

Akatsuki Games Internship 2022のRuby on Rails / AWS コースに参加しました！

はじめまして！2022年の9/1~9/22の3週間、アカツキゲームスのサーバーサイドインターンに参加させていただいた伊藤といいます。この記事では、僕が取り組んだタスクや学んだことについて書かせていただきます！

自己紹介

豊田高専情報工学科4年の伊藤大輝です。普段は学校でコンピュータについて勉強していたり、コンテストやインターンなどで開発したりしています。

参加動機

普段できないような大規模開発をしたいと思ったのと、パフォーマンス改善についてのお仕事をさせていただけるというお話を事前に聞いていたので参加したいと思いました。

インターン中に取り組んだこと

インターンでやらせていただいたタスクは大きく分けて二つです。

1. Ruby3.1 & Rails7.0.2へのアップデート
2. YJITを有効化してのパフォーマンス調査

Ruby3.1 & Rails7.0.2へのアップデート

今回はRuby2.7系、Rails6.1系からの更新だったのでかなり変更点が多く、テストを全て通すことを目標として始めました。

Ruby3.1 で出会った変更点

Ruby3.0の変更点ですがキーワード引数と位置引数の分離というのがあります。

def foo(k: 1)
  p k
end

foo(k: 2) - > OK
foo({k: 40}) - > NG

Ruby3.0以前ではNGコードのようにキーワード引数を定義されたメソッドでもハッシュを引数に渡せば暗黙的にキーワード引数に変換されていましたが、それがなくなりました。このように明確に位置引数とキーワード引数を分ける変更がなされました。

Rails7.0.2で出会った変更点

Rails7.0.2にアップデートする上で出会った変更点はかなり多く全てを解説するのは時間が足りないのでリストアップするとともに一番詰まった点を紹介します。

• MemcacheStoreの :raw value読み込みnilになる問題
• ActionController::Parameter, CacheStore への保存できない問題
• notice,alert Action Not Found Error (flash)
• アプリケーションの initializer
• 各種非推奨項目
• redis-object
• unicode-emoji
• kosi
• pry関連
• mysql2
• newrelic_rpm
• oj

この中で僕が一番詰まったのは MemcacheStore の変更点です。

Rails.cache.increment(key, 1)
Rails.cache.read(key) - > 1

Rails.cache.increment(key, 1)
Rails.cache.read(key) - > nil

Rails6系ではMemcacheStoreに対する :raw value の書き込みでオプション raw: trueで読み込みしなくても値は返ってきたのですが、Rails7からは :raw valueの書き込みにはオプション raw: trueで読み込まないと nil が返ってくるという変更点がありました。しかしここまでの変更点についてCHANGELOGやReleae Noteで見当たらずかなり苦労しました。PRやDiscussionを探す中で見つかり修正に至ることが出来ました。

YJITを有効化してのパフォーマンス調査

Ruby3.1 から実験的な機能としてYJITが導入されました。Shopifyのベンチマークを見ると、本番Rails環境でもRubyインタプリタよりも約6％速くなっていることがあるとされています。ただし本番環境では必ずしも速くなるということはないとあり、実際のところどれくらい上がるのかということで負荷試験調査を行うことになりました。

YJITって何？

YJIT 説明 雑な図ですみません

今までのRubyの実行環境ではRubyのソースコードをRubyVMのためのバイトコードに翻訳して、それをRubyVM上のインタプリタで実行していました。YJITではバイトコードを生成した後、インタプリタで実行しつつ必要な時(Just In Time)にそれからさらに機械語を生成してコンピュータが直接実行するようになっています。

負荷試験結果

not YJIT

YJIT

画像はレスポンスタイムにおけるレスポンス数の分布図になります。YJITを無効化している方が低いレスポンスタイムを出していることがわかります。ただ有効化するだけでは高いパフォーマンスを出すことはおろか無効化している時よりも性能が劣化してしまいました。ここで僕はドキュメントを読み込み、--yjit-exec-mem-sizeが小さいのではと思いました。--yjit-exec-mem-size はYJITが生成した機械語を格納しておく場所のサイズを指定するためのオプションです。YJITには生成された機械語に対してのGCがありません。つまり今回の問題はサーバを実行している間に --yjit-exec-mem-size の値が足りずコード生成が止まってしまうためだと考えました。そして --yjit-exec-mem-size の値をデフォルトよりも大きくして実行しました。すると、さらなる性能劣化が見られました。

パラメータ別実行結果

上記の結果を受けて他のパラメータで実行することにしました。

128MiB

512MiB

900MiB

上記の図から--yjit-exec-mem-sizeの値が大きいほど性能劣化が確認できるかと思います。僕の仮説は間違っていました。そもそも上記の仮説を踏むと性能劣化する原因自体を特定することは出来ません。機械語生成が止まれば通常のインタプリタでの実行に移るだけなので性能劣化することはないからです。そしてここでさらにドキュメントを読み込むとこの現象のヒントとなる情報に出会いました。「YJIT のコード生成は特定の処理を10回実行すると行われるが、予期しないコードやサポートしていないコードにあうと、インタプリンタに戻り通常のインタプリタより遅くなる」この情報を正しいと仮定すると、上記の各パラメータごとの性能評価を説明することができると考えます。なぜ --yjit-exec-mem-size の値がより大きいとより性能劣化が見られるのかというと、あくまで予想ですが、より値が大きい方が生成できる機械語が多くなり、上記の実行が遅くなる問題に直面し続けるからだと思います。

なぜYJITで性能劣化が見られたのか考察

上記の結果を踏まえると性能劣化の原因は、プロジェクト内のYJITにとって予期しないあるいはサポートしないコードにあると考えます。そのコードを起因としてYJITインタプリタ開始終了問題に直面して性能劣化が見られるのではないかと思いました。

やり残したこと

考察の裏付けまでやり切ることが出来ませんでした。YJITのデバック機能を使い最後の原因の特定まで行いたかったです。

学んだこと

• 詰まったら自分の中に溜め込みすぎず、他の人に聞いてみる
• 説明しやすい文を作ることは難しい
• ドキュメントを読み正しい情報の理解を得ることは難しい
• times chは素晴らしい

感想

今回は個人や小さいプロジェクトでは中々関わることのない大規模ソフトウェアの言語アップデートと負荷試験調査というタスクをさせていただきました。ドキュメントを読みながら落ちているテストのエラーと照らし合わせたり、負荷試験を回してnew relicと睨めっこしたりと新鮮なことばかりでとても楽しかったです！またyasu-sanをはじめとしたサーバチームの方々には詰まった際にサポートしていただきました。そのおかげでスムーズに作業が進んだと思います。ありがとうございました！

こんな時代なので、社内オンリーの100人規模の技術カンファレンスを開催しました

こんにちは、アカツキゲームスのVPoEのゆのん (id:yunon_phys)です。社内エンジニアリングカンファレンスAkatsuki Dev Meetupを9/13に開催したので、その運営側のレポートを書きます。

社内オンリーにしたのは登壇者への配慮

いきなりタイトルの話に入っていくわけですが、今回は社内の人に限定したカンファレンスにしました。せっかくやるなら社外の人も呼べば良いのにという声も上がるだろうなとは思ったのですが*1、あえて公開範囲を狭めました。僕らがこのカンファレンスを何のためにやるのか、でいうと、社内の情報の流通量を上げることが第一目的だったからです。

社内の情報の流通量を上げたいのは、アカツキで抱えている課題がそもそも出発点としてあります。現在アカツキは様々なゲームタイトルを開発・運用していて、そのタイトル内のチームでは密度の濃いディスカッションが出来ています。一方で、タイトル間でこういうのをやっているよ、こういうのがうまくいったよ、これはだめだったよ、といった情報交換については、どうしても日々の業務から比較すると優先度が下がってしまいます。他のチームのSlackのWorkspaceを見えるようにするといった工夫は可能な限りしているものの、それは個人の裁量に依存してしまうところもあり、正直成果は上げられていないという感覚があります。

ただ、他のタイトルでやっていることは隣のチームでも参考になるケースは勿論あります。実際に、メンバーが異動することによって、前のチームからのノウハウが伝承されて、開発が良い方向に向かっていくというケースを何度も見てきました。つまり、社内の情報の流通量を上げることは、プロダクト品質を上げることにつながると考えているわけです。

*1:事実、終わった後に社内からそういう声が上がった。それはそれで嬉しいコメント

RubyKaigi2022に協賛します

アカツキは 2022年9月に開催されるRubyKaigi2022 にプラチナスポンサーとして協賛します。