直感的な文法や生産性の高さから、世界中の人々に愛されるオブジェクト指向スクリプト言語Ruby。この言語には継続的に新しい機能や文法が追加されており、利便性が向上し続けています。コミッターの方々による日々の努力が、Rubyの改善を支えているのです。
コミッターのなかでも、とりわけRubyに大きな貢献をしてきたのがアカツキでフルタイムRubyコミッターを務める中田伸悦さん。(アカツキのCSRの取組みについてを記事下部参照)
github.com
中田さんはRubyへのコミット数が全コミッターのなかで最多であり、通称“パッチモンスターと”呼ばれています。
今回のインタビューでは、中田さんがRubyへのコントリビューションを始めたきっかけや、印象に残る機能改修について解説してもらいました。「Rubyのことをもっと詳しく知りたい」「オープンソースソフトウェア（以下、OSS）へのコントリビューションを続ける秘訣を知りたい」と思う方には必見の内容です！
※ 本インタビューはアカツキ所属ではない中薗昴様にインタビューいただきました。
※ インタビューはリモートにて実施しています。
こんにちは。さんたろと申します。
この度、12/1〜12/24までの間、就業型インターンに参加させていただきました。
大学の講義があったため、フルタイムでの勤務10日分ほどの勤務時間でしたが、とても充実した内容でした。 この記事を通して少しでも学んだこと・感じたことをお伝えできたら幸いです。
私が配属されたのは『八月のシンデレラナイン』(以下ハチナイ)というゲームのチームでした。
私はハチナイをプレイしたことがそれまでなかったのでインターンが始まる前に遊び、20個ほど改善案を出させていただきました。
最終的には提案した中から1つ、提案以外から1つの課題に取り組みました。
課題に対する取り組みはインターン最終日におこなわれた成果発表会の資料にまとめています。
1つ目の課題である「共通ヘッダーの修正」は検証待ちの状態まで進めましたが、2つ目の課題である「ScrollView用のハチナイ独自のクラスへの機能追加」はまだ改善が必要という状態で終了しました。
ただ実装するだけでなく、パフォーマンスの計測や.unityファイルでのデータの持ち方の調査などさせていただきました。
以下発表会で使用したスライド資料です。
成果発表のスライドにも書かれていますが、インターンを通して学んだことはとても大きかったです。
そもそも大規模なチーム開発が初めてで、自分の視野の狭さ故の考慮漏れが多かったです。 コード単位の影響ばかり気にして、Prefab・Scene単位の影響にまで目を向けることがあまりできませんでした。 全体が見えないまま実装をしても、それが今後の開発も考慮した最適であるかわかりません。 まずは影響範囲と周辺の実装をしっかりと把握して、構造を理解した上でどのように実装するべきか考える必要がありました。
調査をおこなうとき、今回の調査とは関係のない部分による影響に惑わされることがありました。 大きなプロダクト、把握している範囲が小さい機能に関する調査では特に問題の本質を見失いがちです。 実際に使われているものではなく、自分で小さいサンプルを利用することで問題だけに集中できるほか、何か共通点など新しい発見があるかもしれません。 今回のインターンでは、.unityファイルへの書き込まれ方の調査、ScrollViewのハチナイ独自クラスの挙動確認と開発した機能のデバッグで非常に役に立ちました。
リアルタイムの会話では情報の取捨選択ができず、長引くほど参加者全員の時間を奪ってしまいます。 インターンではメンターの方と進捗状況の確認や相談のための面談をする機会が多くありました。 最初は「何をしたのか」「その結果どうなったのか」をすぐに答えられないことがありました。 こまめに作業ログをとるようにし、情報伝達が迅速かつ正確になっただけでなく、過去の作業内容を思い出すこともできるようになりました。
プランナーやデザイナーの方とのMTGでは、予め資料や参考画像をまとめ、議題に集中できる準備をしました。 結果としてMTGの参加者全員が、現在の状況と議論すべきことが明確な状態でスムーズに進めることができました。
今回のインターンがフルリモートだったこともあり、非同期コミュニケーションはとても大事なものでした。 非同期コミュニケーションの欠点として、「誤解されやすい」「ニュアンスが伝わりにくい」という部分があり、今回のインターンでもそういった問題が発生しました。 違う捉え方ができないか、一番言いたいことが明確になっているか、使用する単語ひとつひとつにも気を配る姿勢が大切だと感じました。 また、「〜ということですか」と自分の解釈を伝えることは認識のズレを減らす手段で、今後も意識して利用していきたいです。
リモートワークだと自分が今何をしているのかメンターの方やチームメンバーに伝わりにくいです。 今回のインターンでは「自分で調べて問題を解決する」ということを重視されていましたが、それでも助言を受けるか判断するのではなく、助言をするか判断してもらうべきでした。 インターン後半では「自分は今〜しています」と意識して報告することで自身の状況を伝えるように心がけました。
業務としてのゲーム開発をすることが初めてでしたので楽しめるか不安でした。 いざ始まれば、覚えることが多く大変でもありましたが、「楽しい」という感情が一番強かったです。
最後まで楽しく働けたのは、暖かく迎えてくださったチームメンバー・人事・総務の方々、常に的確な指摘をしてくださる一方で私なりの結論が出るまで見守ってくださったメンターの方、そのほか支えてくださった社員のみなさんのおかげです。 この場をお借りして改めてお礼申し上げます。
以上、私のインターン参加報告でした。
最後まで読んでいただきありがとうございます。
こんにちは。Nと申します。
この度、1/18 ~ 2/5までの15日間、就業型インターンに参加しました。
私は、『八月のシンデレラナイン』(以下ハチナイ)のサーバーサイドエンジニアのチームに配属され、次のタスクに取り組みました。
開発環境でアイテムを付与することがあります。これまでは、アイテムのidを資料から探してきてそれを手入力する必要がありました。
そこで、私は「手作業でアイテムのidを確認して入力する」こと自体が大変な作業だと考えたため、プルダウンに全てのアイテムを表示するように実装しました。しかしながらアイテムの数は膨大です。この実装はかえって逆効果でした。
そこで、次に個数が多いグループのアイテムをリストから削除する実装にしましたが、今度はそもそも選択できないアイテムが発生するのは良くないということになりました。
最終的な結論として落ち着いたのは、アイテムの所属するグループのプルダウンの値が変更されたタイミングをフックとして関連するアイテムだけを表示するという実装でした。ほぼ理想的な形が実現できたと共通認識が取れたので良かったです。
ハチナイにはマスターデータが存在します。マスターデータを簡単に説明すると、ゲームが動いている間は固定値として扱うデータのことです。このデータ群は「正しいデータ」としてプログラムが設計されているので、正しいことが保証されていなければなりませんでした。そこで、今後改修されることで変更されうる値が正しいことを保証するプログラムを追加しました。
今回のインターンではフルリモートによるものでした。ZoomとSlack、GitHubのPRでのやりとりが多かったのですが、
これらが特に難しそうだなと感じました。しかしながら、今回のインターン中では、比較的返信を早くいただけたのでスムーズに作業できました。
レビュワーの方からインターンを通して「何を伝えたいか」がよく伝わってありがたいという評価をいただきました。うまく伝えるに際して、
を心がけていました。
その上で、「書き方」も意識するとより伝わりやすいことに気がつきました。具体的には、リスト化して視覚的に見やすくしたり、Markdownの「---」を使って区切りを使ったりすることが有効でした。
また、クライアントサイドエンジニアとサーバーサイドエンジニアでAPIのインターフェースについて議論する際実際にJSONの形式で提示している方がいて伝わりやすいと思いました。
きちんと理解した上で話すことを心がけていました。実装の仕様のすり合わせにおいても、「理解しきれなかったのでもう一度この部分の説明をお願いします」などとお願いして「自分が書くコードはこうなるはず」という自分の中での理解をするようにしました。
その結果、「実装方針をこのようにしてはどうか？」という提案をすることができました。それだけでなく、レビューの際、「ここは認識違う」との指摘をいただいても「自分はこう考えてた」と伝えることでどこで食い違いが起こっているのかを特定するのが簡単になりました。成果報告会で、レビュワーの方からも「言語やフレームワークによらないプログラム設計がしっかりしていてロジックレベルでは指摘するところがほとんどない」と褒めていただくことができました。
15日間最初から最後まで楽しく働くことができました。これはメンターの方をはじめとするたくさんの方のサポートに依るところが大きいです。
ゲーム開発は初めてだったので、「Webアプリケーションの開発とはこういうところが違う」など差異を感じることができて有意義なインターンになりました。特にマスターデータの運用を感じることができて良かったです。
こんにちは．9月1日〜9月18日までアカツキのクライアントエンジニアインターンに参加しました，高橋と申します．今回は大人気スマホゲーム「八月のシンデレラナイン（以下ハチナイ ）」のプロジェクトでUnityを用いたUI関連の機能の追加や改修の業務に関わらせていただきました．本記事ではその際に取り組んだことや感じたことなどを書いていきたいと思います．
私は現在修士1年生で，普段はヒューマンインタフェースの研究室で電気刺激（神経に電気を流して感覚を作る技術）の研究をしています．もともと趣味でUnityを使ったゲーム開発などをしていましたが，就活を始めるにあたって仕事としてのゲーム開発を体験してみたいと考え，今回のインターンに参加させていただきました．
冒頭でも述べましたが，私は今回ハチナイのプロジェクトでUI関連のいくつかの業務に関わらせていただきました．具体的な内容としては主に次の３点になります．
以下ではそれぞれの項目について詳しく説明していきたいと思います．
インターンが始まって私が最初に取り組むことになったのは選手育成画面で溢れた経験値を表示する機能の開発でした．ハチナイでは選手のレベルを上げる際に強化相手を選択して経験値を与えるということをするのですが，選手のレベルには当然上限があるため，必要以上の経験値を与えると経験値が溢れてしまいます．ところが現状ではこの溢れた経験値を画面に表示する仕組みが存在せず，ユーザさんは気づくことができません．そのため，何らかの方法でこれをユーザさんに知らせようというのが今回の目的でした．
この機能についてはまだ仕様など何も決まっていなかったため，まずデザイナさん，プランナさんと詳しい仕様について話し合うところから始めました．この頃はまだ開発の進め方などよく分かっていない事が多かったのですが，デザイナさんの方からミーティングを設定してくれたり，ゲームの仕様について説明してくれたりなどとサポートをしていただいたおかげでスムーズに議論を進める事ができたと思います．話し合いの結果，溢れた経験値を数字で表示すると同時にその程度をゲージで表す機能を実装することに決まりました．
仕様が決定したため，次はそれに従って実装をしていきます．実装を行うには，まず選手育成のための経験値の表示がどのオブジェクトで行われており，その値はどのクラスのどの位置で計算されているのかを把握した上で，必要な処理を追加する必要があります．複雑な計算をするわけではないし比較的簡単に終わるだろうと楽観的な気持ちでプロジェクトを開いたところ，とにかくファイルが多い，オブジェクトの階層が深い，そしてクラスがでかい．普段個人で作っているようなゲームとはスケールが全く違い，まず該当する処理を探し当てる段階で苦戦してしまいました．やっとの思いで位置を特定しても他人が書いて動作しているプログラムに手を加えるのは緊張感を伴うもので，なかなか思い切った改変を加える事ができませんでした．そうは言いつつも，溢れた経験値を計算する処理自体は最初に言った通り比較的シンプルなものであったため，大きな問題にぶつかることもなく実装を終え，レビューをいただく事ができました．終わってみれば，プロジェクトの概要を把握しつつ，仕様の決定→実装→レビューという開発の1サイクルを回す事ができたという点で入門編として最適な課題だったと思います．
1つ目の課題が終わり，次に取り組むことになったのはスカウト画面のピックアップ選手のサムネイル表示数削減でした．ハチナイにはスカウトという仕組みが存在し，スカウト画面でナインスターなどのアイテムを消費することで新しい選手を手に入れる事ができます．スカウトには複数の種類がありますが，それぞれのスカウトにおいて手に入る可能性のある選手の一部をピックアップ選手として一覧で表示する機能があります．このピックアップ選手は1画面中に5~7枚程度がサムネイルとして表示され，スワイプによって他の選手を見る事ができる仕組みになっています．つまりスワイプが起こるまでは今現在画面に表示されているピックアップ以外はオブジェクトとして生成しなくても良い訳ですが，現状では表示をする予定の全ピックアップ選手のサムネイルがオブジェクトとして生成され，画面外で待機しているという状態でした．見えないオブジェクトをわざわざ生成して画面外で待機させておくのは無駄でしかないため，どうにかしたいというのがこの課題の趣旨ということになります．
同じような問題の解決方法としてよくあるのは，最初に一度に画面内に見える分だけ画像を表示するオブジェクトを生成しておき，スワイプに従って画像の差し替えと位置の再調整を行うというものです．今回は画像だけでなく画像がタップされた時の処理も差し替える必要がありますが，大まかにこの方針で実装を進めることにしました．
方針が決まり，それに沿って実装を始めましたが，そこで早速問題にぶつかってしまいました．現状のコードではUnity側が用意しているGridLayoutGroupというオブジェクトの整列を自動で行なってくれるクラスによってピックアップ画像を並べていたのですが，この自動整列機能のおかげで今回の実装の肝である画像位置の再調整をする事ができません．なんとかしようとあの手この手を使って工夫を重ねた結果目的の動作を実現する事ができたものの，非常に複雑で可読性に欠けるプログラムが出来上がってしまいました．これは良くないと思いメンターさんに相談したところ，画像の一覧表示を最小限のオブジェクト数で実現する機能を提供するまさに今回の目的にうってつけのクラスが存在することを教えていただきました．このクラスを仮にクラスAとしておきます．クラスAには一覧表示のスタート地点や画像間の空白を設定する仕組みが無かったため，それらを実装した上でピックアップ画像の表示方法をGridLayoutGroupからクラスAに置き換えることで無事ピックアップ選手の表示数削減に成功する事ができました．GridLayoutGroupを使った実装方法を考えるのに多くの時間を費やしてしまったこともあり，目的を達成するのに適切なアプローチを取れているかを立ち止まって考えてみることの大切さに気づかされた課題だったと思います．
私がインターン中最後に取り組んだ課題はダイアログ外タップ機能の実装についての検討でした．ダイアログとはアイテムの受け取りや選手の育成など何らかの確認や意思決定が必要となる場面で選択肢とともに表示されるウィンドウのことです．
ハチナイでは，一部の例外を除いてダイアログ内のいずれかのボタンをタップすることによってのみ次の画面に移る事ができるようになっていますが，実質選択肢が1つしかない場合や間違えてダイアログを開いてしまった場合などに簡単にダイアログを閉じる事ができると便利です．その方法としてダイアログ外の領域をタップすることでキャンセル等の処理が行われるようにしよう，というのが本課題の概要です．「実装についての検討」と言ったことからも分かるようにインターン期間中に実装まで漕ぎ着けることはできなかったのですが，以下では実際に私が調査・検討した内容について簡単にまとめようと思います．
このダイアログ外タップ機能ですが，存在する全てのダイアログに適用すれば良いというわけではありません．というのも，ダイアログによっては意図しない画面外タップによってダイアログが閉じられてしまう事が望ましくない場合もあるからです．そのため，実装の前にプランナさんと相談してどういったタイプのダイアログに対してこの機能を適用するかを決めました．
方針を決めるにあたって，まずダイアログの表示やボタンのコールバックイベントの設定がどのように行われているのかを調べました．その結果，ダイアログの種類毎にクラスが用意されており，その内部でそれぞれのボタンのコールバックが設定されているようでした．また，これらのクラスはそれぞれの背景となるオブジェクトへの参照も持っていたため，この背景に対して他のボタンと同じようにタップ時のコールバックを設定してあげればダイアログ外タップ機能を実現できそうだという事が分かりました．通常であればこの処理をそれぞれのダイアログのクラスに加えて作業終了なのですが，今回の場合ダイアログの種類が全部で200種類近くあったため，手作業で全てのクラスを変更するのは現実的ではありません．幸いなことにこれらのクラスは全て共通のクラスを継承していたため，この基底クラスを編集することでなるべく少ない労力でダイアログ外タップ機能を実現する方法について検討することにしました．色々と考えた結果，基底クラスにボタンの参照を1つ追加し，ダイアログ外がタップされた時にこのボタンに登録されているコールバックを呼び出す方法をとることにしました．このようにすれば，派生クラスに対する変更は要らなくなります．インスペクタからそれぞれのクラスに対してボタンの参照を登録する作業は必要になりますが，これについてはコードの編集とは違ってある程度自動化できると考えました．
ボタンに登録されているコールバックを呼び出す，という説明をしましたが，どうやってそれを行うかが大きな問題でした．ハチナイでは独自の方法でボタンのコールバックの設定をしているため，例えばButton.onClick.Invoke()などのようにしてコールバックを取り出す事ができません．この問題の解決方法として1つ目に考えたのはExecuteEventsクラスを使ってボタンをプログラムからタップし間接的にコールバックを呼び出す方法です．最初は名案だと思ったのですが，これをやるとボタンタップ時のアニメーション等まで再生されてしまうのと，力技な感じが否めなかったため見送りました．2つ目は独自に実装されているボタンのコールバックを設定する関数の内部にコールバックを取り出す処理を加えてしまう方法です．このようにすればコールバックのみをきれいに取り出す事ができますが，代わりにプロジェクトの至る所で使われている関数をダイアログ周りでしか使わない処理で汚してしまうことになります．どうしようかと悩んでいる内にインターン最終日を迎えてしまい，ダイアログ外タップ機能を実装する事はできませんでした．結論としては，素直に全ダイアログクラスを編集するのが良いということになりました（もっと良い方法があったかもしれないけど私には思いつけなかったです）．実装までたどり着かなかったのは残念ですが，変更点の多さが実装うの障害になるという大規模なプロジェクトならではの問題に取り組む事ができ，良い経験になったと感じました．
インターン中に取り組んだ課題については大体紹介したと思うので，以下では今回のインターンで感じた「会社の印象」，「良かったこと」，「反省点」について述べていきたいと思います．
一番印象に残ったのは何よりもこれでした．会社と聞くと僕は厳しいとか忙しいという言葉を一番最初に思い浮かべてしまいます．もちろんアカツキの皆さんも真剣に仕事に取り組んでいるのですが，ミーティングの雰囲気や何気ない雑談からも社員の皆さんがリラックスして仕事をしている様子が伝わってきました．私の場合は今回が人生初のインターンで，さらにオンライン開催だったこともありうまくやっていけるか心配しながら初日を迎えたのですが，いざ仕事を初めてみるとそんな心配もすぐに無くなりました．
若干語弊があるかもしれませんが，やりたいことをやらせてくれる会社だと感じました．例えば今回最初に取り組んだ溢れた経験値の表示機能は元々私がハチナイをプレイした感想をもとにメンターさんに提案したものでした．正直提案をしても取り入れられることはないかと思っていたので，提案をした翌日に「やってみましょう」と言われた時には私の方が驚いていました．インターンの課題として丁度良い内容だったということもあるかと思いますが，熱意を持って提案をすればきちんと評価してくれる会社だと思います．
インターンの動機でもあった仕事としてのゲーム開発をしっかり体験できた点はとても良かったです．新しい機能の仕様についてデザイナさんやプランナさんと相談したり，初めてみる巨大なクラスを解読したり，書いたコードをレビューしてもらったりといった個人開発ではすることのない経験をたくさんする事ができました．
恥ずかしい話ですが，私は今までGitをほとんど使った事がありませんでした．チーム開発においては必須のスキルであるため，今回のインターンに参加する事が決まってからの1ヶ月間で急いで勉強しました．それでも分からないことは多くメンターさんに初歩的な質問ばかりしてしまいましたが，３週間の業務を通して以前よりも理解が深まったと思います．
うまく一言で言い表せなかったためこのような見出しになりましたが，共通する処理は一箇所にまとめるなどといったプログラミングの原則を意識したコーディングができなかったと感じました．もちろん知識としては持っていましたが，機能をどのようにして実装するかに意識が集中してしまったので今後は機能だけでなく可読性・拡張性なども意識したコーディングを心がけていきたいと思います．
反省点などもありましたが，アカツキという会社についてよく知る事ができ，ゲーム開発の楽しさを肌で感じることができた3週間だったと思います．ありがとうございました！
こんにちは。2020/8/17~9/4の3週間Akatsukiのインターンに参加していました、弘部と申します。この記事では私が3週間何をやっていたのか、そしてその感想を書かせていただきます。
どこか良いインターンが無いかと探している方、Akatsukiのインターンに興味がある方の参考になれば嬉しいです。
目次です。
今回私が配属されたのは「八月のシンデレラナイン」というスマートフォンゲームのクライアントサイドでした。
八月のシンデレラナインは通称ハチナイと呼ばれ、女子高生達が甲子園を目指し野球に打ち込むという可愛さと熱さを兼ね備えたゲームです。私が最後に野球をしたのは小学校の体育ですが、そんな私でも気付いたらストーリーを最新のところまで進めてしまうほどハマってしまいました。野球が好きな方はもちろん、そうでない方も是非プレイしてみてください！
記事を執筆している現在、世界的なCOVID-19の流行のため不要不急の外出が出来なくなっています。ですのでインターンのために地方から東京へ出てくるということも出来ず、自宅からのフルリモートという形で行われました。
実際にオフィスへお邪魔して、社員の方と顔を合わせてお話して、ということが出来なかったのは非常に残念ですが仕方がありません。
それにリモートワークにも良い点はあって、何と言ってもドアtoドア0分です。インターンの始業時刻は10:00なのですが、一度9:40に起床した日がありました。しかし起床した時点で出勤は完了している訳ですから、余裕で朝食を取ることすら出来ました。実際に通勤していたとしたら朝から大慌てだったでしょう。今後も出社するかリモートワークにするかを都合よく選べるようになると良いですね！
インターンに参加するまでには2度の面談がありました(人事の方との面談とエンジニアの方との面談)。参加確定後も再度エンジニアの方との事前面談があり、そこで配属チームなどを伝えられる、という形でした。特別必要な事前知識等は無く、Unityとgitが一通り使えれば問題はないと思います。UniRxを使用しているのでその辺りも少し触っていると役に立つと思います。後は配属先のゲームをしっかり遊んでおくのが大事だと思います。
さて、肝心のインターンで取り組んだことですが、
の5つの課題に取り組みました。
以下順を追って各課題についてお話していきたいと思います。
これが私がインターンで最初に取り組んだ課題でした。デレストというのは選手達にスキルを取得させることができるゲームモードのことです。
デレストにはいくつかのストーリーがあり、ストーリー毎に選手が取得できるスキルが異なります。当然プレイしたいストーリーを選んでプレイすることもできるのですが、どの選手にどのスキルを習得させたいかを選んで、そのスキルを取得可能なストーリーをプレイすることもできるようになっています。そしてストーリー毎にオーダーが保存されるようになっているので、選手からストーリーを選ぶと、その選手をオーダーに入れるために入れ替えが発生します。その際の画面がこちらです。
明るく表示されている8人の選手の中から交代したい選手を選ぶ、という画面です。しかしこれは少し不親切で、初見のプレイヤーがこの画面を表示されてもすぐには何をすればいのか分からないのではないでしょうか？
そこで以下のように何をすればいいのかをプレイヤーに促すUIを追加する、というのが本課題の内容です。
要はある画面にUIを1つ追加したいということですね！何だか簡単そうじゃないですか...
実際にUIを追加する作業自体はすぐに完了しました。しかしこの表示は既存のUIを使い回していたのですが、デザイナーさんから既存の物よりも表示時間を伸ばして欲しい、という要望が入りました。
このUIの表示時間はアニメーションとして設定されており、エンジニアが触る領域ではありません。ですから表示時間を伸ばすためにはデザイナーさんにアニメーションの作成を依頼する必要があります。
しかし配属されて間もない私はそれをお願いするのに気後れしてしまい、プログラム側で対応します！と安請負いをしてしまったのです。
ですが本来アニメーションで制御すべきものをプログラムから制御しようとすると、どうしても無理な実装になります。結局、やっぱりアニメーションを作ってください、と後から依頼をし、二度手間となってしまいました。
他にもこのUIを追加するにあたって既存のUIの表示タイミングも変更することになったのですが、仕様の確認をする際に私が曖昧な言い方をしたせいで、どのUIの話をしているのか齟齬が生じる、ということがありました。
そしてオンラインでの会話というのは数分や数十分越しになってしまうこともしばしばで、やり取りが増えていった結果、最初の一週間は本タスクに費やされてしまいました。
チーム開発を行う上でコミュニケーションは大切だ、何てことは私も知っていました。しかしコミュニケーションの何たるかが分かっていなかったのです。コミュニケーションとは意思疎通な訳ですから、アニメーションを作って欲しいという意思、自分がどのUIを話題にしているのかという意思を伝えられなかった時点でコミュニケーションに失敗していたのです。
このような失敗は個人で開発をしていては決して味わえるものではありません。チームとして誰か他の人と一緒に同じものを作るからこそ、この失敗ができたのであり、その点でこれはインターンの大きな成果と言えます。
これまで個人開発でやってきたぜ、という方は是非Akatsukiでチーム開発を体験されてみてはいかがでしょうか？きっと新たな気づきがあると思います。
続いてはプレゼントボックスの改修作業をしました。
私がこれを執筆している現在(2020/09/04)ではプレゼントボックスの「アイテム」タブの中にしおり系のアイテム(URキャラクターの強化に使うやつ)が入っていません。ですが、しおり系のアイテムもアイテムなので「アイテム」タブの中に入っていて欲しいですね。その改修を行いました。
プレゼントボックスの仕様はリスト方式になっており、ナインスターは「スター」タブに、選手は「選手」タブに、というような事が記載されたリストがあり、この件はしおり系のアイテムがリストから漏れていたために「すべて」以外のタブに含まれないようになってしまっていたのです。
ですので、リストの中にしおり系アイテムを含めてやる、という作業でした。
こちらは意図していない挙動なので上の課題よりも先にアプリに入れ込まれることになりました。私のインターン期間中には間に合いませんでしたが何月何日のアップデートに入れます、と聞いた時はとても嬉しく、早速その日の夜にプレゼントボックスにしおりを用意しました。
続いてスカウト画面の改修作業です。スカウト画面にはたくさんのスカウト達が並んでいました。これは比喩表現ではなく、文字通りスカウト画面にはスカウト達が並んでいたのです。
このようにスカウト画面には、見えないところでスカウトの背景画像がずらっと並んでいました。そしてこのように一列に並んでいるせいで、端のスカウトから端のスカウトへの移動は間のスカウトを高速でめくることで実現していました。見えないところに画像を配置しても無駄ですし、端のスカウト間の移動はもっとスムーズにしたいですね。
そこで以下のように改善を行いました。
画面外に配置するのは必要最低限に留め、端のスカウト同士はループするように隣りに配置することでスムーズに移動できるようにしています。
この課題が今回のインターンの中で最大規模のもので、スカウトの表示周りの処理をかなり大幅に変更することになりました。
Akatsukiのインターンではこのような割と規模の大きな課題にも取り組ませてもらえます。メンターの方もサポートをしてくださるので自分の実力を試す良い機会だと思います。
スカウト画面の次はピックアップ画面の改修を行いました。ピックアップ画面とはそのスカウトの注目選手のステータスやスキルを確認できる画面のことです。
この画面では下のサムネイルや矢印ボタンを押すと表示する選手を切り替えることができるのですが、その切り替え処理が非常に重たかったのです。
でっかいスパイクが立っている部分が切り替え処理をした際の負荷です。見切れていますが15FPSを優に割っていることが分かります。これを解消するというのが本課題の内容です。
さて、重たいと言っても、なぜ、何がそんなに重たいのでしょうか？
ピックアップ画面の下部には注目選手のサムネイルが並んでいますが、これはスカウトと同様に画面外にまで並んでいました。
選手の切り替え時にはその選手のサムネイルが画面中央に来るようにサムネイル群を動かしていました。ピックアップ選手は、多いスカウトでは数十人にも及ぶのでこれだけのサムネイルを一斉に動かせば確かに重くなりそうです。
と思っていたのですが処理が重たくなっている部分の負荷の内訳を確認してみると以下のようになっていました。
GC.MarkDependenciesという処理が最大の負荷のようです。UIを動かしてGCがどうにかなるというのは少し考えづらいですね。更に言えばスカウトによっては注目選手が2,3人しかいない場合もあるのですが、数十人でも2,3人でも同じぐらいの負荷がかかっていました。UIを動かすことが原因では無いのでしょうか？
調査を進めたところ、原因は「習得可能スキル」や「才能」の表示にあることが分かりました。これらの表示に含まれるUIはキャラクターを切り替えるごとに全て破棄されて生成され直すようになっていたのです。その際のメモリの開放、もしくは確保に起因してGCが働いていた、というのが負荷の原因でした。よって、UIを一々作り直すのではなく既にあるものを再利用するようにした結果、負荷は以下のようになりました。
水色のスパイクが立ち上がっている部分が選手切り替え時の負荷です。上の巨大なスパイクに比べれば遥かにマシですね。実際に動作は非常に軽快になっており、無事最適化に成功しました。
他の誰かが作ったものを最適化するというのは意外な所に原因があったりして非常に面白く、これも決して個人開発では味わえない経験でした。
最後の課題はスカウト結果から戻ってくる際の挙動の改善でした。
挙動の改善とはつまりどういうことかと言うと、スカウト結果から戻ってくる際、OKボタンを押して戻ってくる方法と、左上の戻るボタンを押して戻ってくる方法があります。
どちらも押すとスカウト画面に戻ってくるのですが、戻るボタンで戻った場合、最後に引いたスカウトと異なるスカウトが表示されることがある、ということがスカウト画面の改修中にメンターさんによって発見されました。なのでついでにそこも直してしまおうということになったのです。
どこを直せばいいのかはすぐに分かったのですが、問題はどう直せばいいかでした。そもそも戻るボタンとOKボタンの挙動は同じであるべきなのか、OKボタンを押した場合にはレビューのお願いが表示されるが戻るボタンを押した場合には表示されないのは意図しているのか、その辺りの仕様が問題でした。最初の課題と同じ轍は踏むまいと、自分から、そして齟齬の無いよう言葉と表現を選びプランナーの方に質問すると「戻るボタンの挙動をokボタンに合わせるでお願いします！」とあっさり答えが帰ってきました。のでスムーズに作業を進める事ができました。3週間の中で成長できたということだと思います。
Akatsukiの3週間のインターンは気づきと学びの連続でした。
大規模なプロジェクトに携わるということ、チームで開発するということは一人でゲームを作っていては決して経験することができません。特にAkatsukiのインターンはメンターの方の指示にただ従う、というような事は無く、基本的には自分で作業をして分からないところは質問する、もしくは結果的に間違っていれば指摘していただく、という形なので実際の業務に比較的近いと思いますし、その分身につく物も多いと思います。
書籍購入制度というのもあり、これはメンターの方の許可が必要ですが、技術書等を経費で購入してもらえるという太っ腹制度です。私も技術書を2冊購入していただきました。技術書って結構高いので非常にありがたいです。こういう風に就職活動の場だけでなく、学生の学びの場としてもインターンを提供しているのはAkatsukiのいい所だと思います。
また、今回はフルリモートでのインターンでしたが、このような状況下でもインターン生を受け入れるという事は、インターンにかなり力を入れている企業であると言えると思います。実際に事前の面談やインターン参加直後の受け入れなどもリモートでありながら非常にスムーズで、困るような事は一切ありませんでした。ですので就業型のインターンが初めて、という方も是非Akatsukiで初挑戦してみてはいかがでしょうか？僕もこのインターンが初めての就業型でした。
最後になりましたが、3週間お世話になったAkatsukiの皆様、大変ありがとうございました。
