【ハチナイ】完全リモートでクライアントエンジニアインターン【１５日間】

こんにちは。イオジンと申します。７月２０日〜８月１２日まで、１５日間インターンをしました。

日本に来て、半年引きこもり生活をしていて、アカツキに内定をもらってインターンを始めました！外国人の中でアカツキにインターンをしてみたいとかアカツキに興味がある人に、有益な文章になってほしいです。

目次

自己紹介

韓国の東国大学でComputerVisionとか映像処理を勉強しました。

数学とかプログラミングも好きて、学生の時はRayTracing Renderingを作ったりVoxel Renderingを作ったりしました。

Ray Tracing Rendering

Voxel Rendering

私は小学校からずっとツクルでゲームを作りました。そしてゲームはストーリーが大事な日本のゲームをモチーフにしているので、将来日本でゲーム開発をしたいと思っていました。

趣味はゲームと昔のJPOPを聞いたり、Netflixでアニメを見たりします。結構、レトロな事が好きなのでゲームとかアニメとか映画も昔のことが好きな変人です。

インターンに参加した経緯

まずは、私は韓国で大学を卒業して日本に来ました。去年の12月に来て就活を始めました。韓国ではほぼ卒業した後、新卒として就活するのが普通だったので、日本に来てびっくりしました。

そして、コロナが出て私は3月からはずっと自粛生活、でも、就活をずっと続けました。そして、アカツキで内定をもらいました。でも、その時は他の会社でバイトしていたのでそれが終わってアカツキのインターンを始めました。私はハチナイのチームで働くことになりました。

実装

 

インターンを始めて私がもらった課題は機能を改修する仕事でした。

システムボイスを鳴らす機能を見直す

鳴らす対象の選手番号が飛び番になった場合に対応できていなかったのが問題でした。

簡単に鳴らす対象を指定できるように、Scriptable Objectを利用して改修しました。

スキットの話者を選手番号指定にする 

スキットではセリフを言う選手は選手の名前に依存していて、選手が同姓同名の場合問題が発生していました。なので、選手の名前の代わりに選手番号を使うようにしました。

そして、変換を誰でも簡単にできるようにするため、UnityのEditor拡張を行いました。

スペシャルログボのオブジェクトを見直す 

(画面は開発中のものであり、実際の仕様とは異なる場合があります)

スペシャルログボのアイテムアイコンが称号、トロフィー、TPを表示出来ない問題がありました。

(画面は開発中のものであり、実際の仕様とは異なる場合があります)

ノーマルログボでは、その問題がなかったので同じオブジェクトにしました。

SDキャラの配置アルゴリズムを見直す

そして、私がハチナイで気になった部分がありました。SDキャラの配置の部分がずっと気になってその部分のロジックを見直したいと言いました。結構細かいところだったが試しに実装をしてみようということになりました。

キャラがランダムに配置されたので、配置がよくない場合がありました。その場合はキャラをクリックするのも不便だし、見た目にも良くないと思って色々アルゴリズムを考えてみました。

(画面は開発中のものであり、実際の仕様とは異なる場合があります)

ガウシアン分布を用いた確率的配置がいいかなと最初は考えましたが、確率に頼るのは完璧な解決方法ではないと思っていました。 そこで毎回配置を確認して最適な位置を探すアルゴリズムを設計して実装しました。

固定の配置場所にしか対応しなかったので採用されませんでしが、問題提起から解決までを自分でやった特別な経験でした。

苦労した事

外国人として、日本で働き始めた人はみんな同じと思います。時々日本語が聞こえない時があります。リモートではそれはもっと大変になります。

日本語聞き取れない

Nativeなら、一つの単語とかは聞こえなくても文章を理解する事には何も問題がないですね。でも、私みたいにまだ日本語がNativeレベルじゃない人にとっては地獄です。リモートの環境では時々ネットの問題とかスピーカーやマイクの問題でよく聞こえない場合があります。結構かなりあります。なんかの単語が聞こえなかったらパニックになる時がありました。その時はまた質問するしかなかったです。その時、やっぱり相手には失礼なので、とても申し訳ないと思いました。

現場に初めて飛び込んだ初心者として、苦労した事もあります。学生の時、GitHubを学べる授業もあんまりないし、学生はGitHubを自分のポートフォリオ·サイトとして使えるんじゃないですか？（私はそうでした。笑）

だから簡単な使い方とか簡単な機能しか分からないまま卒業する人が多いと思います。私もそうして、インターンを初めて色々困る時がありました。

提言

全般的に見たら、就活で私はかなり珍しいケースと思いますが、今後アカツキにEntryすることになる外国人にとって、私の経験が誰かの手伝いになったらいいなと思う気持ちで伝えたいことがあります。

Design Pattern

学校でよく勉強したDesign Patternとかが力になったと思います。MVC Patternで作られたと思って分析すれば、コードレベルではあんまり難しいことは無いと思います。そして、Abstract Factory Pattern（これは明確ではなかった気がします）とかBuilder Patternを使ったコードも見えました。

多分、みなさんが知っていると思いますが、少なくでも、MVC Patternを勉強するためにはStrategy PatternとObserver PatternとComposite Patternの勉強が必要ですね。個人的おすすめ本、二つです。

一番有名なGOF Design Patternsです。

Design Patterns: Elements of Reusable Object-Oriented Software (English Edition)

個人的にはこちの方がもっとおすすめです。分かりやすいし、Javaを基にDesignの説明があったのでC#で実装するUnityのエンジニアはコッチがもっと楽と思います。そしてこれを先に見てGOFを見たら改めて見える部分もたくさんありました。 

Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本

C# Convention

「ハチナイ」 ではC#のStandard ConventionでCodeが出来上がっていますが、前の会社で働く時は、かなり特別なConventionを使って、そのCoventionに慣れて、変な規則のコードをよく書きました。それがちょっと恥ずかしかったので、皆さんはC# Standard Conventionに慣れてください。

本当の日本語

本当の日本語？それは何？なら今まで私が学んだ日本語は偽物？？と思う人がよくいると思います。本と本当の日本語はちょっと違うと思いました。本ではあんまり説明されてない単語とか文法がたくさんあります。そして、省略と不完全な発音です。

その壁を越える方法は色々あると思いますが、私のおすすめは日本の番組です。

番組が一番いいところは単語を省略したり発音をはっきり言わない時がよくあるからです。その環境が一番実戦に近い環境と思います。私もまだまだ足りないですけど、一緒に頑張ってみましょう！

チームプロジェクト

一人でゲームを作る事とチームでゲームを作るのは全然違います。一番いいのはチームで作業しながら個人のプロジェクトを続けることがBestです。自分の後を考えて自分が学びたいのを個人プロジェクトにして、チームプロジェクトでは協業ツールの使い方やコミュニケーションの方法と協働してコードを組む方法を勉強すればいいと思います。学校以外で機会は絶対色々あります。

そして、出来ればGitHubをTerminalで作業してみてください。

私もSourceTreeに慣れて、またTerminalに慣れるように勉強しています。SourceTreeでは出来ないし、ちょっと使い辛いのがTerminalで簡単にできる場合が多いと思いました。

大きいプロジェクトを触ると他の人のコードを見る機会とかが良くあるからそれを見るだけで、自分のコード力が上がると思います。本当に難しい課題は、会社が私たちに任せてくれません。難易度よりコードの綺麗さが色々問題になると思います。（私も問題です。。悲）

さいごに

私も色々足りないですが皆さんに色々これしてこれして言って恥ずかしいです。これを読む皆さんは私よりもっと実力あるエンジニアと思いますが、でも、なるべく皆さんの成長に私のインターン経験が役に立ったらいいなと思って書きました。

自分の足りないところが見えて、成長の為の良い基盤になったインターンでした。そして優しい皆さんが手伝ってくれるので、不安なくフルリモート環境でインターンをすることができました。ハチナイのインターン楽しかったです❗️ 

読んでくれてありがとうございます。

開発エンジニアとQAの心理の違いとは何か？

この記事は Akatsuki Advent Calendar 2020 3日目の記事です。

はじめに

アカツキでエンジニアをやっている tomotaka-yamasaki です。
この記事では、エンジニアとQAがどのように協力しあってソフトウェアを開発していけば良さそうか、をJSTQBの内容を取り上げつつ書いています。去年のアドベントカレンダーではゲームプログラミングのHP計算システムアンチパターンという記事を書いていました。
hackerslab.aktsk.jp

現在、私はアカツキの子会社であるアカツキ福岡に在籍しており、QA業務の効率化やテスト自動化などを行うチームを立ち上げて、活動しています。私自身、エンジニアとして手は動かしたいので、効率化、自動化を行いながら、QA組織がより良い方向に向かうための手助けも行っています。

この記事を書こうと思った理由

QA組織に直接関わるようになってからテスト関連の知識をメインに取り入れていました。その中で特に印象深かったのは JSTQB*1 です。JSTQBはテスト技術者資格の名称ですが、公開されているシラバスや公認書籍である ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応 に書かれている内容はソフトウェアテストの原理原則です。
www.shoeisha.co.jp

ゲーム開発を経験していた私はその中身を読んで、分かる分かる！と頷きまくっていました。資格試験のシラバスや書籍なので内容はお堅めなのですが、人に紹介するときは、あるある本、と言っています。

この記事は ｢QAが普段考えていること、思っていること、大切にしていることを開発エンジニアにも知ってもらいたい｣ という想いで書きました。
弊社の話ではなく一例ですが、
｢QAチームのAさん、いつも細かい不具合ばかりを指摘してきて辛いんだよなぁ…｣
や、
｢開発エンジニアのBさんに不具合報告すると機嫌悪くなるから言いたくないなぁ…｣
など、開発エンジニアとQAメンバーですれ違いが起きているケースは少なからずあると思います。なぜすれ違いは起きるのか、理由は様々なのでこれだ！という解決策を提示することはできませんが、JSTQBを勉強してみて、開発チームが目指した方が良い方向は見えてきた気がしました。

まとめのような話を最初に書きますが、開発エンジニアとQAメンバーはお互いを理解し、尊重することが開発プロセスを円滑に進めるための第一歩だと思います。不具合を出さないためのテスト計画、テスト技法などの具体的な話も重要ですが、それらは良いスタンスの上に積み上がるものだと私は考えています。

前置きが長くなってきたので、そろそろ本題に入ります。｢何｣を理解すればいいのか、読んでいただける皆様に新しい気付きがあれば幸いです。

この記事のターゲット

• ソフトウェア開発を行っているエンジニア
• 開発エンジニアとQAメンバーがなぜかよくぶつかるなぁと思っている方
• エンジニアは何考えているかよく分からないなと思っているQA関係の方

QAチームを｢テストの7原則｣から理解してみる

ソフトウェア業界では様々な原理原則が存在しますが、JSTQBの元となっている ISTQB*2 では テストの7原則 として定義されています。普段開発に関わっているエンジニアやQAメンバーは、感覚や経験により理解しているかもしれません。とはいえ、言語化されていることは大変ありがたいことです。この7原則で語られている内容はテスト計画の基盤であり、QAメンバーがテストをする上で大切にしていることです。テストを語る際の共通言語にもなり得ると思っています。

テストの7原則

1. テストは欠陥があることは示せるが、欠陥がないことは示せない
2. 全数テストは不可能
3. 早期テストで時間とコストを節約
4. 欠陥の偏在
5. 殺虫剤のパラドックスにご用心
6. テストは状況次第
7. ｢バグゼロ｣の落とし穴

私の意見も交えながら順番に説明していきます。

1. テストは欠陥があることは示せるが、欠陥がないことは示せない

テストにより、欠陥があることは示せるが、欠陥がないことは証明できない。テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはならない。*3

欠陥とはバグのことだと思ってください。欠陥が無いことの証明は、いわゆる悪魔の証明です。一定のテスト期間を経て欠陥が全て修正され、1週間欠陥が見つからなかったとしてもプロダクトの品質が高いことの証明にはなりません。なぜならテスト自体に不備があり、欠陥を発見できていないパターンを排除できないためです。
なので、QAチームはテストに不備がないかどうかを、発見した欠陥数を見て判断したりします。欠陥は必ず出るものだと認識し、テスト実行数と欠陥発見数を比較します。これまでの実績があることが前提になりますが、テスト実行数のわりに欠陥数が不足している場合はテストの不備を疑います。

また、この原則が存在するため、｢テストの終了基準は欠陥がなくなること｣にすることはできません。どうすればテスト終了なのかを定義することはQAチームの役割です。ISO/IEC 9126で規格されている品質特性を満たす、という定義も考えられます。いずれにしても、定義への合意は開発チーム全体で行うことだと思います。

2. 全数テストは不可能

すべてをテストすること(入力と事前条件の全組み合わせ)は、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、リスク分析、テスト技法、および優先度によりテストにかける労力を集中すべきである。*4

おそらく原則2を満たすことができれば原則1の証明になるんですが、現実はそこまで優しくできてはいません。電卓のようなアプリケーションですら全ての入力と計算を網羅することはできません。ゲームアプリケーションはもっともっと複雑です。スキルの組み合わせ爆発が起きている、なんて話を色んな所で耳にします。
同値分割というテスト技法のように組み合わせを減らす考えも重要ですが、ここで私が一番重要だと思うことは、テストには実行優先度があるということです。優先度をつけると以下のようなケースで役に立ちます。

• リリースタイミングが迫っていて、工数が足りない場合
• リグレッションテストの工数がテストスケジュールを圧迫している場合

どのテストから行うべきかを予め決めておくことで、いざというときに即時対応できます。更に、テストケースを削減するタイミングで、どの程度品質が落ちるのかを明言できると素敵です。リスク分析は実行優先度を決めるための手段の一つであるとも言えます。

また、作り手である開発エンジニアの方が優先度を付けやすいケースもあると思います。ユニットテストである程度品質が担保されている箇所や、同じ関数を使用している箇所があれば優先度を下げることもできるはずです。開発エンジニアが協力して、テストにかける労力を減らせると良いなと思います。

3. 早期テストで時間とコストを節約

早い段階で欠陥を見つけるために、静的テスト活動と動的テスト活動の両方をソフトウェア開発ライフサイクルのなるべく早い時期に開始すべきである。早期テストは、シフトレフトとも呼ばれる。ソフトウェア開発ライフサイクルの早い時期にテストを行うことにより、コストを低減または削減できる。*5

QAを｢最後の砦｣と呼ぶこともありますが、私はそう呼ばれないようになるのが本来のQAの在り方だと考えます。砦ではあるけど、最後ではなく、出来ているところから見ていくような、開発と同時並行で検証できるのが理想です。

テストはテスト対象が完成してから始まるものではありません。開発エンジニアが設計を行う前、ディレクターが仕様書を作り始めるところからテストは始まっています。QAメンバーが仕様書をレビューし、仕様の抜け漏れをチェックする、ゲームであれば面白いものなのかをチェックする、などの行為もテストに該当します。
最後の最後に検証すると、欠陥が見つかったときのコストが早期発見したときと比べ、2,3倍にも膨れ上がります。テスト工数にいくらバッファを積んでもスケジュールを圧迫してしまうのは、このような影響要素が多すぎるからです。従って、シフトレフトによってできる限り早期にテストし、テストプロセスに影響する不確定要素を排除することができます。

アカツキのQAメンバーは、仕様書ができた段階でテスト観点を洗い出し、その仕様を実装するメンバーで観点をレビューしています。そうすることで膨大なテストケースを作る前にテストの抜け漏れを発見することができ、欠陥の早期発見に繋がっています。

一方で、開発エンジニアはCIによってPull Requestごとに自動テストを回せるようにしています。ソースコードが本流にマージされる前に欠陥を見つけることは大変効果的です。
このように、開発エンジニアとQAの双方がシフトレフトの概念を理解し、実施していくことが大切だと思います。

4. 欠陥の偏在

リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリスク分析を行う。(原則2で触れたことと同様)。*6

ゲームアプリケーションだと、インゲームのような複雑な処理を行うコードは欠陥が混入しやすい箇所だと思います。開発エンジニアはソースコードを読むことができるため、｢複雑な処理を行うことでコードが複雑になっていたり、場当たり的な対応を行っている箇所だったり、に欠陥の偏在があるだろう｣、と推測することができますが、QAメンバーは過去の欠陥の傾向などから偏在を推測するケースが多いと思います。欠陥の偏在箇所を特定することは、テストの優先度を決定することに繋がります。そこを優先的にテストすることで早期に欠陥を見つけることができます。

欠陥の偏在を見つけるためにはエンジニア的な視点が必要だと考えています。エンジニア的視点とは、システムの概要を理解する、データ構造を理解する、ソースコードを読み複雑度を理解する、などです。発生する欠陥を推測するテスト技法はエラー推測とも呼ばれますが、偏在箇所を合理的に推測することができれば効果的にテストを行うことができます。QAチーム側でエンジニア的視点があるメンバーがいれば良いですが、それは稀有なので開発エンジニアがQAチームにエラー推測の観点を伝えることが重要だと考えます。

また、Aさんは開発スピードは早いが欠陥は多い、などの開発エンジニアの特性を伝えることも一定効果はあると思います。ただし、そこでAさんを批判するべきではありません。欠陥が多い、という事実にフォーカスして非難にならないように伝えることが大切です。

5. 殺虫剤のパラドックスにご用心

同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この「殺虫剤のパラドックス」を回避するため、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりする必要がある(殺虫剤を繰り返し使用すると効果が低減するのと同様に、テストにおいても欠陥を見つける能力は低減する)。ただし、自動化されたリグレッションテストの場合は、同じテストを繰り返すことでリグレッションが低減しているという有益な結果を示すことができる。*7

同じシステムに対して、同じテストを繰り返していても新しい欠陥を見つけることができないことは理解できます。ただ、ゲームアプリケーションは高い頻度でアップデートを行っているため、同じシステムで動き続ける期間は短めです。コードの変更によるデグレード(リグレッション)を防ぐために行うテストがリグレッションテストですが、この場合に限り、殺虫剤のパラドックスは有益なものとなります。リグレッションテストは繰り返すことで初めて効果を発揮します。これまでと同じ挙動をしているかどうか、認識しているコード修正の影響範囲以外の箇所で欠陥が残っていないかなどを網羅的にテストすることが可能です。

しかしながら、リグレッションテストは広範囲を網羅的にテストしがちなので、手動で、繰り返し行うと工数が膨れ上がります。そのため、アプリケーションのアップデートごとに1周だけテストするのみ、という場合も多いと思います。

リグレッションテストは繰り返し行うことで効果を発揮するため、最も自動化に向いていると言われています。このテストをうまく自動化し、CIに組み込むことができれば原則3の早期テストに大きく貢献することができ、QAの工数を削減することができるはずです。自動化はQAだけでは実現困難なので開発エンジニアの手が必要になります。SETと呼ばれるテスト自動化を専門とするエンジニアに依頼するのも一つの手段だと思います。

6. テストは状況次第

状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテストは、eコマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシャルライフサイクルプロジェクトでは、テストの実行方法が異なる。*8

ここで得られる重要な示唆は、全てのテストには目的が存在する、ということです。状況が異なれば、テストの目的も変わり、それによってテストの方法も変わります。JSTQBにはテストプロセスの原理原則は書かれていますが、それは単なる武器に過ぎません。何を、どのように使用するかを計画することがQAの役割です。開発エンジニアがテストに関心を持ち、QAメンバーとテストの目的について議論することはとても有意義だと思います。自ら書いているユニットテストの目的について考えてみてもいいかもしれません。

7. ｢バグゼロ｣の落とし穴

テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則2と原則1により、これは不可能である。また、大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。*9

欠陥を全て見つけること、そして全てを修正することを目的に置いてはいけません。欠陥を修正した結果、システムにどういう影響が発生するのかを認識しないといけません。欠陥は修正できるが、操作性が失われる、ソースコードのメンテナンス性が失われるなどデメリットが大きければ第三の案を考える必要性も出てきます。

しかしながら、QAメンバー全員が欠陥の修正方針を考えられるわけではありません。システムの内部構造まで理解していないと修正方針は立てられないからです。修正することでどのような影響があるのかを考えることは開発エンジニアの役割です。欠陥に対して、開発エンジニアとQAメンバーは真剣に向き合わなければなりません。そのために、最高品質のプロダクトをリリースする、といった共通の目的を設定すると良いと思います。

開発エンジニアとテスターの心理の違い

開発エンジニアの確証バイアス

人には ｢確証バイアス｣ と呼ばれる心理的要素が存在します。

確証バイアスと呼ばれる人の心理の要素は、持っている信念に合わない情報を受け入れがたくする。例えば、開発担当者は、コードは正しいという思い込みがあるので、確証バイアスにより、コードが正しくないということを受け入れがたい。*10

開発エンジニアは確証バイアスによって自分のコードに自信を持っているケースがあります。ここでいう自信は、｢私の書くコードにバグなんてありえない！｣というものではありません。自分で作ったから内部構造も分かる、Pull Requestを出しコードレビューも行った、更に自分で入念に動作チェックもしたから問題ない、その過程で出たバグは潰したからもう他には存在しないだろう、という論理ありきの自信です。しかし、その努力、行動の結果、確証バイアスが生まれると思っています。

自分を客観視しないと確証バイアスは無くなりません。自分以外のエンジニアがコードレビューすることによって下がりますが、それでもエンジニアとしての確証バイアスがあるため、0にはならないと思います。確証バイアスがあると、欠陥報告が自分への非難と捉えてしまう場合があります。

確証バイアスがあることを前提に、QAメンバーはJSTQBで定義されている以下のスタンス*11 でテストに臨みます。

• 対決ではなく、協調姿勢で開始する
  • 全員のゴールは、高品質のシステムであることを再認識するとよい。
• テストの利点を強調する
  • 例えば、開発担当者に対しては、欠陥情報は、作業成果物の品質向上と開発担当者のスキル向上に役立つ。組織に対しては、欠陥をテストで検出して修正すると、時間と経費の節約になり、プロダクト品質の全体的なリスクも減る。
• テスト結果や他の発見事項は、中立な立場で、事実に焦点をあてて伝え、欠陥を作りこんだ担当者を非難しないようにする
  • 客観的かつ事実に基づいた欠陥レポートを書いたり、発見事項をレビューしたりする。
• 他人の気持ちや、他人が情報に対して否定的に反応した理由を理解するように努力する
• 自分の言ったことを他人が理解し、他人の言ったことを自分が理解していることを確認する

開発エンジニアとQAのマインドセットの違いを理解する

開発エンジニアとQAの仲が悪い、という話を聞いたことはありませんか？

開発担当者とテスト担当者は、異なった考え方をすることが多い。開発担当者の主目的は、プロダクトを設計して構築することである。テストの目的は、これまでに説明しているように、プロダクトの検証と妥当性確認、リリース前の欠陥の検出などである。このように目的が異なっており、異なるマインドセットを必要とする。両者のマインドセットを組み合わせることで、より高いレベルのプロダクト品質を達成できる。*12

仲が悪くなってしまう原因として、開発エンジニアとQAでマインドセットが異なるから、ということが考えられます。お互いに興味関心ごとが違うため、意志決定と問題解決において前提とするものと優先する方法が異なり、それが両者の壁になります。

開発エンジニアのマインド

解決策の設計と構築に大きな関心があります。また、確証バイアスが自分自身の作業中に犯した誤りを見つけることを困難にしています。

QAのマインド

好奇心、プロとしての悲観的な考え、批判的な視点、細部まで見逃さない注意力、良好で建設的なコミュニケーションと関係を保つことに関心があります。また、テスト担当者のマインドセットは経験を積むに従って成長し成熟する傾向があります。

重要なことは、まず、開発エンジニアとQAがお互いに持っているマインドの専門性を理解し、不足している部分を補完し合うことだと思います。そしてプロダクト品質を向上させる、といった共通の目的を軸に議論することが大切だと考えています。この内容は、TeamGeekで紹介されている HRT(謙虚、尊敬、信頼)*13 と似たものを感じました。

まとめ

冒頭でもお話しましたが、この記事は、QAが普段考えていること、思っていること、大切にしていることを開発エンジニアにも知ってもらいたい、という想いで書きました。QAが大切にしていることは、テストの基盤となる考え方であるテストの7原則や、相手を非難せず協調姿勢でいる、といったヒトではなくコトに向かうスタンスです。そして、開発エンジニアとQAのマインドの違いについても紹介しました。互いに理解し、共通の目的を持つことでエンジニアとQAのシナジーが生まれ、健全な開発が行えると信じています。

補足: 所属チームの取り組みについて

現在は、A4というチームに所属し、今回書いた内容などを基にQA組織の在り方を再構築しています。他にも業務効率化やテスト自動化なども行っていますが、アカツキ福岡でA4チームが大切にしていることは以下にまとめています。
fukuoka.aktsk.jp

A4チームの取り組みについて、記事を書いてもらいました。せっかくなので紹介させてください。
www.wantedly.com

長々と書いてしまいましたが、ここまで読んでいただいた方、本当にありがとうございます。
この記事が新しい気づきになりましたら幸いです。

===

*1:JSTQBとは、日本におけるソフトウェアテスト技術者資格認定の運営組織で、 各国のテスト技術者認定組織が参加しているISTQB(International Software Testing Qualifications Board)の加盟組織として2005年4月に認定されています。 JSTQB認定テスト技術者資格-JSTQBについて-

*2:ISTQB® has created the world's most successful scheme for certifying software testers. As of October 2019, ISTQB® has administered over 920,000 exams and issued more than 673,000 certifications in over 120 countries world-wide. The scheme relies on a Body of Knowledge (Syllabi and Glossary) and exam rules that are applied consistently all over the world, with exams and supporting material being available in many languages. Certifying Software Testers Worldwide - ISTQB® International Software Testing Qualifications Board

*3:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 概要 Version 2018.J01”. JSTQB 認定テスト技術者資格. 2019-04-05. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf, (アクセス日 2020-12-03). p.17

*4:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 概要 Version 2018.J01”. JSTQB 認定テスト技術者資格. 2019-04-05. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf, (アクセス日 2020-12-03). p.17

*5:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 概要 Version 2018.J01”. JSTQB 認定テスト技術者資格. 2019-04-05. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf, (アクセス日 2020-12-03). p.17

*6:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 概要 Version 2018.J01”. JSTQB 認定テスト技術者資格. 2019-04-05. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf, (アクセス日 2020-12-03). pp.17-18

*7:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 概要 Version 2018.J01”. JSTQB 認定テスト技術者資格. 2019-04-05. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf, (アクセス日 2020-12-03). p.18

*8:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 概要 Version 2018.J01”. JSTQB 認定テスト技術者資格. 2019-04-05. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf, (アクセス日 2020-12-03). p.18

*9:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 概要 Version 2018.J01”. JSTQB 認定テスト技術者資格. 2019-04-05. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf, (アクセス日 2020-12-03). p.18

*10:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 概要 Version 2018.J01”. JSTQB 認定テスト技術者資格. 2019-04-05. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf, (アクセス日 2020-12-03). p.25

*11:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 概要 Version 2018.J01”. JSTQB 認定テスト技術者資格. 2019-04-05. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf, (アクセス日 2020-12-03). p.26

*12:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 概要 Version 2018.J01”. JSTQB 認定テスト技術者資格. 2019-04-05. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf, (アクセス日 2020-12-03). p.26

*13:Brian W. Fitzpatrick, Ben Collins-Sussman, 角 征典 (2013). Team Geek ―Googleのギークたちはいかにしてチームを作るのか オライリージャパン pp.15-18.

Akatsuki Summer Internship 2020 成果報告

こんにちは、はじめまして！🙋‍♂️

Akatsuki Summer Internship 2020 にサーバーサイドエンジニアとして参加させていただいた kimujun です。この記事ではインターンの活動報告をまとめます。

ちなみに Summer Internship といいつつ、参加したのは 10 月初旬~中旬の三週間でした。ギリ夏ですね (？)

活動内容

アカツキはモバイルゲームの会社として有名です。私も例に漏れずアカツキの提供するモバイルゲームの開発に携わらせていただきました。

いろいろな開発を経験させていただきましたが、主にゲームの新規機能開発とアプリケーションの性能改善の二軸の活動となりました。この記事では以下のような章立てで活動報告をします。

1. ゲームの新規機能開発
2. アプリケーションの性能改善 ~ボトルネック発見編~
3. アプリケーションの性能改善 ~実際の性能改善編~

なお、自分が参加したプロジェクトではサーバーサイドの言語として Ruby on Rails を採用していました。

 1. ゲームの新規機能開発

すでに何年か運用実績があり、アプリケーションコードがかなり大きなプロジェクトに新規参入 & 新規機能を開発していくにあたって、以下のような点が難しいと感じました。

• ドメイン知識不足により、影響範囲が分からない
• コードベースに対する理解が乏しく、どこにどのような処理が書いてあるか分からない

1点目について、仕様書を読めばある程度は背景がつかめますが、影響範囲については理解するのが難しいです。例えば新規機能に必要な新しいデータをクライアントに送りたい場合、テーブルにカラムを追加するのはいいですが、それに伴う影響範囲をソースコードから全て洗い出すのは至難の技です。

これを解決するために、テストを修正しながら影響範囲を一つ一つ潰していくという作戦をとりました。

細かく分割されたテストを書いている場合、カラムを追加したことでアプリケーションに影響がでる部分についてはテストがちゃんと落ちてくれます。どのように落ちているかを見ながらアプリケーションを直すことによって影響範囲を洗い出すことができました。

開発に慣れてくれば、メインの変更箇所を見ながら他の修正箇所の当たりをつけて見にいくことができると思いますが、開発初期段階ではかなり有効な手だと思います。変更に強いアプリケーションのためのテストはこういう面でも有用ですね 😉

2点目について、幸いにも Rails にはスタンダードなディレクトリ構成があるので、大体どこにどのレイヤーのソースコードがあるかは見れば分かります。一方で、例えばたくさんある Model の中でどのような処理が共通部分として切り出されてるか、といったような処理レベルの分離方針についてはパッと見ただけでは把握が難しいです。

これを解決するために、メインフローの処理について一度隅から隅まで目を通すという作戦をとりました。アプリケーションの核となるメインフローの処理については綺麗な処理が書いてると信じて読んだ結果、コードベースに対する理解がかなり深まりました 😎

これらの内容をメンターさんと一緒に進めながら開発をすすめ、無事新規機能を最初から最後まで作りきることができました！ここでその内容を話せないのはちょっと残念ですが、実際にリリースされるまで楽しみに待っていようと思っているところです。

2. アプリケーションの性能改善 ~ボトルネック発見編~

Rails の大きな特徴として Active Record があります。Rails では Active Record を用いることによって DB 操作を意識することなく Model レイヤーの処理をサクサク書いていくことができます。

一方で Rails アプリケーションで起こりがちな問題として N+1 問題があります。N+1問題の詳しい解説は他に譲りますが、簡単に言うと不要なクエリが大量に発行されてしまう問題です。

この問題を放置するとリクエストのレイテンシが大きくなり、性能が悪化していきます。見つけ次第駆除したいです。

参加したプロジェクトでは N+1 問題の発見に New Relic を用いていました。New Relic はアプリケーションやデータベースのトランザクション性能をモニタリングできるツールです。

アプリケーションコードのなかで SDK を読み込めば、リクエストごとにどのような SQL が何回呼ばれているかが手に取るように分かります (これはまじですごい)。N+1 問題が発生している箇所は不自然に大量のクエリが発行されていることが見て取れます。

インターン中に行った N+1 問題改善タスクでもこの New Relic を活用し、どのような内容の N+1 問題が発生しているかを理解することができました ✌

3. アプリケーションの性能改善 ~実際の性能改善編~

 Rails において、N+1 問題は事前に必要なデータを読み込んでおくことで解決することが多いです。

前述のような不要なクエリを発生させてしまうコードは以下のようなものです。

Active Record の preload や eager_load を用いて事前に cats をロードし、N+1 問題の発生を解消することができます。

実際にアプリケーション内部でこのような実装を行い、N+1 問題を解決することができました ✌

インターンの感想

今回のインターンは全てオンラインで活動を行いました。全てリモートの環境でチームの人等と気軽に話せるようになるか心配でしたが、ホストチームのみなさんや人事の方々の (かなり) 手厚いサポートのおかげで、ほとんど不自由を感じずにインターンを終えることができました。ありがとうございました！

開発を通じて、Rails のコードに関する考え方やインフラのリソースに関する考え方から、技術面の細かい Tips やスクラムをうまくやっていくための Tips に至るまで本当に様々なことを学ぶことができました。

夏のインターンに参加することを考えている学生さんにはとてもおすすめです。

以上活動報告でした。改めて、アカツキのみなさまありがとうございました！

株式会社アカツキでのインターンを終えて

はじめに

初めまして。アカツキでのインターンシップに参加させていただいた東正太と言います。

関西の大学３年生で、中二くらいからゲーム開発を趣味で行っています。

今回のインターンシップについて 

今回はC++とcocos2dxを使うプロジェクトでクライアントエンジニアとして３週間のインターンシップに参加させていただきました。

僕の目論見としては、C++をせっかく触るならつよつよエンジニアになろう！と考えていました。 

今回のインターンはテーマは「開発メンバーが喜ぶデバッグ機能を作ろう！」という、非常にざっくりしたテーマでした。

今回のインターンシップでやったこと

・デバッグ機能の改善要望を聞くため検証チームと会議を行いました。

・会議で出た要望を課題とし、解決方法を模索、検討し仕様を決めました。

・仕様や設計をエンジニアさんたちに共有しレビューしてもらいました。

・機能を実装しプルリクエストを出してブランチにマージしてもらいました。

こういう流れで３つのデバッグ機能を作成・改善しました。

客観的なまとめ

実際に開発メンバーが使える機能を３つ開発できたのはとても良かったと思います。

また、リモートながらエンジニア以外の人やインターン生など多くの人と関わることができました。

個人的な今回のインターンの感想

具体的な指標がなかったため、自分で課題設定を行い、スケジューリングを行い、課題を解決していく必要がありました。

そのため悩みや選択が多かったですが、解決することで多くのことを学べたと感じています。

起こった問題

・実機ビルドが動かない　・自己肯定感　・進め方がわからない　・タスクを同時並行で進めてしまった　・会議の内容が理解できなかった　・相談するのが遅くなってしまう　・できないタスクに執着してしまった　・見積もりで実装しすぎてしまった　・発表がうまくできない　・朝からスピーディに仕事ができない　・偉い人が誰かわからない　・共有のための資料を不必要な箇所まで作ってしまう

多くの問題が起こりました。この後でいくつか紹介します。

会議の内容理解できなかった問題について

僕がエンジニアとして検証チームのデバッグ機能改善要望を聞き、返事をする会議がインターン３日目にありました。

しかし、僕は開発体制が整っておらず、デバッグ機能に関しての知識がほぼありませんでした。そのため、要望に対してエンジニアとして回答ができない状態にありました。

ここで要望に対して自分の頭で意図を読み取って作業を進めていくことが大事だということを学びました。

また、会議では理解できなかったところを後から質問して解決しました。

メンターさん神話について

会議中にメンターさんから機能を変更しようと考えていた一つの要望に関して提案

「機能を変更するではなく元の機能を使っている人もいるかも知れないから追加でいくといい感じだと思う」

個人的には両方の機能はいらないと感じていたのですが、メンターさんのいうことなので従いました。

仕様書を書き、エンジニアさんに共有したところ、エンジニアさんが

「いや、片方で十分じゃない？」

との発言でした。

僕はどっちに従えばいいかわからなくなってしまい自分の中で意見が右往左往しました。

ここで、気付いたことがあります。

仕事をしていく上で、メンターさんなど人の意見にそのまま従うのではなく、意見を参考にしながら最終的には自分で考えて判断しなければといけないということです。

僕は「前の機能が消えると困る人がいるか」を確認し、いなければ機能を変更することを決め、検証チームに質問したところ困る人がいませんでした。

その結果、実装範囲とスケジュールを決めて自分で実装することができました。

タスク同時並行問題

４日目から、会議で要望が出たものに対して改善案を見積もりする工程に入りました。タスクがどれだけかかるのか、どの方法なら仕様を満たす機能を実現できるのかを見積りました。

実装部分のコードを見たり追加しながら実現難易度や実装にかかりそうな日数を考えました。

僕は一つのブランチで見積もりを行いました。これが、後々問題を引き起こしてしまいます。

仕様書とブランチの失敗

見積もりの段階である程度実装の目処が立ったため、実装がほぼできたところで次に仕様書を書き始めることにしました。

実装がほぼできている機能に対して仕様書を書いたのですが、スクリーンショットがあるとより説明がしやすいと感じたため、３つ中２つの機能の実装を完成させてしまいました。

仕様書を共有し、仕様変更を行いながら実装を始めました。

しかし、先ほど一つのブランチで作業していたため、見積もりが終わっていないタスクと仕様書の実装を始めたいタスクの内容が同じ場所にありました。

そのため、スタッシュを知らない僕は全部を別のブランチで切り替えることでしかブランチの移動ができませんでした。

その結果、見積もりが終わっていないタスクが残ってしまうため、実装したい内容自体は完成しているのにコミットやプルリクエストが全然できない人になってしまいました。

PR、そして見積もり２つを同時並行で行う

なんとかプルリクエストを出し、見積もりとPRの修正タスクを同時並行で行いました。

PRの修正タスクのプッシュが終わったと同時にブランチを切り替え、見積もりを行ってビルドを行う、そうするとまたPRの修正が届いている・・・

ブランチを切り替えるたびにビルドが約20分かかるのもあって、暇な時間が増えてしまいました。

暇な時間をなんとか無くそうと、さらに実機でのデータダウンロードと新たなタスクの見積もりを始めました。

こうすることで４つのことを同時並行でやることになってしまい、頭が回らないまま数日が過ぎてしまいました。

ようやく解決へ

行き詰まった僕はメンターさんと話し、いくつかのことを教えてもらいました。

まず、同時に複数のことをしないこと。集中力や理解が必要な作業ほど、頭を切り替えるのに時間や気力などのコストを必要とします。このコストが大きくなり過ぎてしまうと、仕事の効率が大きく下がってしまいます。

次に、ブランチ運用について。複数の仕事をする際にはブランチを分け、スタッシュやリベースなどと言った運用で切り替えをしやすくすること。Gitを使用するメリットを意識して作業をしていくべきです。

また、実装できたということはタスクができたということではありません。単に動作確認ができただけで、自分が見積もりの段階でできたことなのに時間を使っていると少し落ち込んでたことは必要ないことだとわかりました。

問題を乗り越えた結果

僕はこうしてほぼ全ての問題を解決したことで、失敗したように思えた多くの出来事から成長を重ねることができました。自分で考えたり時にメンターさんや社員さんに気づかせてもらったことも多かったです。

多くの問題を解決し、成長を感じられた理由として大きいなと感じたのは

・メンターさんの毎日の1on1で質問や相談をさせてもらったこと

・他の部署の社員さんともランチなどのタイミングで交流が多くできたこと

・リモートでの労働環境や雰囲気に関して社員とかなり似た条件で働かせてもらえたため、イメージがつきやすかったこと

・機能を使ってもらえる人とコミュニケーションがとりやすくてFBや意見がもらえやすかったこと

でした。

しかし、

・リモートオンリーだったので直接話せなかったことだけでなくオフィスの雰囲気を掴むことができなかったこと

・他の人とコミュニケーションの取り方にコストがかかったこと（「画面をパッとに見せて会話」などができない、雑談が難しいなど）

・作った機能で開発メンバーが喜ぶ顔が見れなかったこと

などが心残りでこれらが実現されればもっと成長につなげることができたのかなと考えています。

これからやってくこと

今回のインターンで学ばせてもらった知識やツール、技術などを自分の開発にも生かしたいと考えています。

また、就活においてもゲームエンジニアとして働くことのイメージがついたので、もっと他の会社と比較して良い企業を見つけていきたいと考えています。

Akatsuki Summer Internship 2020に参加してきました

こんにちは！初めまして。にー兄さんです。

この度、8/3～8/21の3週間でアカツキのAkatsuki Summer Internship 2020に参加して参りましたので、その報告をしたいと思います！

概要・インターン参加以前

インターン業務の具体的な内容説明に入る前に、ちょっと前置きを挟みたいと思います。

インターンの概要

アカツキのインターンには、3週間の就業型インターンである「Akatsuki Summer Internship」と 2日間で行われるゲームジャム形式の「Akatsuki GAME JAM」があります。 今回私が参加したのは、ゲーム開発の就業型インターンで、実際にリリースされている、またはリリースされるサービスの開発に携わることができます。

インターン応募時の自分

私がインターンを探し始めたのは2020年の4月頃でした。 以前からインターンに参加してみたいという漠然とした思いがあり、コロナ禍で少し心配ではありましたが、とりあえずインターンに応募してみることにしました。 インターンに参加するにあたり、参加の目的を以下のように設定することにしました。

• (Unityを使った)実践的な開発を体験する
• 大規模なチーム開発に参加する
• 自分の実力がどこまで通用するかを試す

合わせて、この時点での私の経験・スキルを以下に示します。

• プログラミングは9年目？
• Unity 6年目
• 2Dゲーム開発経験、一切なし
• GitやGitHubなどは基本的なことは知ってる(一応業務で使ったこともある)
• チーム開発は、ぼちぼちという感じ

私は以前からUnityを使うことが多かったので、今回はUnityに絞ってインターンを探してみました。

インターン参加までのスケジュール

アカツキのインターンの応募のきっかけになったのは、4月に開催された某面談イベントの参加でした。その面談イベントでは色々な企業の採用担当の方とお話ができ、 その中にアカツキも入っていました。

実はアカツキの存在自体は知っていて、実際にイベントの会場としてオフィスに行ったこともありましたので、ゲームを開発している会社であるという認識がありました。そこでUnityを使ったインターンができるのでは？ と思い頑張ってアピールしたのを覚えています。そこから面接のご案内をしていただき、無事合格することができました。 アカツキの就業型インターンには選考の工程が2つあり、自分の場合は一つ目のWebコーディングテストの結果が5月の中旬くらいに出て、そのあとの面接の結果が5月の下旬くらいに出ました。

インターンへの参加

私が配属されたのは、『八月のシンデレラナイン』というスマートフォン用ゲームアプリのチームでした。 そこでクライアントサイドの開発業務を行うことになりました。

インターンの課題

インターンの初日、入社の手続きが終わった後にメンターさんとのミーティングでインターンで取り組む課題の決定をしました。 元々チームの中で上がっていた課題をいくつか提案していただき、その中で3週間で実現できそうな課題を選ぶ、という感じになりました。

その中で私が取り組んだ課題は「選手専用クリスタルベアマックスの実装」というタスクでした。 八月のシンデレラナインには、キャラクターを成長させるための強化素材となる「ベアマックス」というキャラがいるのですが、 その中でも「限界突破」という機能に使えるベアマックスを「クリスタルベアマックス」といい、さらにその中でも特定のキャラクター(選手)にのみ効果があるクリスタルべマックスを 「選手専用クリスタルベアマックス」と呼んでいました。以下クリスタルベアマックスををクリベアと略します。

私の場合は既存の問題をインターンの課題としましたが、人によっては自分で提案した課題を進めることもできるといった感じでした。 私も、自分の課題としては進められませんでしたが、いくつか機能の提案をさせていただきました。

インターンの成果

前述のとおり、自分は選手専用クリベアのクライアント実装を担当することになったのですが、 このタスクをもう少し細分化すると以下のようになります。

• 選手専用クリベアに関するマスターデータの定義
• 選手専用クリベアの選手詳細画面の実装
• 選手専用クリベアのクリベア一覧における表示

マスターデータの定義

選手専用クリベアという新しいキャラを作るために、サーバーサイドで新しいマスターテーブルが作成されたので、まずはそのマスターテーブルの定義をクライアントでも同期しなければいけませんでした。 具体的には、「選手専用クリベアがどの選手に対して効果があるのか」という情報を持ったマスターテーブルでした。 八月のシンデレラナインでは、サーバーで新しく定義されたマスターデータをCIによってC#のクラスがクライアントに作成されるという仕組みになっていました。 そしてそのクラスのPartialに対してクライアントで使う処理を実装していく、ということをしました。 

選手専用クリベアの選手詳細画面の実装

八月のシンデレラナインには選手育成ができ、選手一覧の画面で選手アイコンを長押しすることでその選手の詳細なステータスを見ることができます。 この機能についてはベアマックスにもあり、選手専用クリベアを実装するにあたり、選手専用クリベア選手詳細画面を実装することになりました。

まず、そもそも選手専用クリベアの選手詳細画面デザイン自体が決まっていませんでしたので、 さっそくプランナーさんとデザイナーさんを交えてのデザイン案の検討ミーティングが行われました。 大学生の自分にとっては、プロのプランナーさんとデザイナーさんと一緒に会議をするという経験がなかったので少し緊張しました。 会議を通して、以下の画像のようなデザインに決まりました。

選手詳細画面のデザイン案

ここから選手詳細画面の実装をしていくことになります。選手専用クリベアの選手詳細画面はクリベア像の後ろに選手の立ち絵が回り込むという構造上、背景画像・選手の立ち絵・クリベア像という3層構造にする必要がありました。 他のベアマックスに関しては、ベアマックス像と背景が一緒になった画像が使われており、またシーン専用クリベアに関しては、背景画像と選手のイラストがシェーダによって合成されているという仕様になっており、選手専用クリベアでは他と違った実装をする必要がありました。

当初はシーン専用クリベアのように立ち絵と背景をシェーダを使って合成する案で実装しようと思っていましたが、立ち絵を表示する際にプレハブが用いられていることから、 今回の実装では既存の立ち絵のプレハブと、新たにベアマックス像をプレハブ化したものをInstantiateする形にしました。

実装されたデザイン

選手専用クリベアのベアマックス一覧における表示

アイコンデザインに関しても、デザイナーさんとプランナーさんとミーティングをし、選手専用クリベアとしてどういうアイコンにすれば良いのか、協議をしました。 しかし残念ながら、選手専用クリベアの選手一覧画面における実装は今回は取り掛かることができませんでした。 スケジュールとしてはここまで終わらせたかったのですが、３週間という時間の中では終わらせることができませんでした。とても悔しいです。

インターンを終えて

インターンで得た学び

今回のインターン学んだことはとても多かったと感じています。

まずは、今回のインターンの目標の一つである、「実践的な開発を体験する」という面において、 今まで携わったことのない大きな規模のサービスの中で、Unityのシーンやアセット、サーバー連携などがどのように運用されているのか 体験することができました。 自分は２Dゲームの開発経験が全くなかったので、Unityシーンの中でどういうヒエラルキーを使っているのか、どういうアーキテクチャを使っているのかのプラクティスを学べたことや、 なかなか個人開発では体験しにくいアセットバンドルについての知見を得ることができたこと、サーバーのマスターデータをどういう風にクライアントで使われているのかを学べたことが とてもよかったと思います。

次に、自分の弱みを知ることができました。私の場合は、プロジェクトの全体像がある程度見えないと、コーディングを始められないという、プログラマとしての臆病さというのが顕著に出てしまい、 前半１週間は満足にコーディングができず、コードリーディングに多くの時間を使ってしまいました。 メンターさんには「試し書きをしながら全体を把握していくのが良い」というアドバイスをいただきましたので、次のインターンや今後の開発においてそれを意識してやっていきたいと思いました。

そして、コミュニケーションの大切さを改めて痛感しました。 私はインターン期間中に何度か非エンジニアの方とミーティングをする機会がありましたが、 そこで自分が思っていることを言語化するというプロセスでかなり時間と体力を消耗しました。 メンターさんとの会話をする場面においても、自分がなぜこれができなかったのか、どうやって解決すれば良いのかを話し合うことが多く、 そこでもちゃんと理論立てて話し、相手に伝えるということの難しさを身をもって体感しました。

全体の感想

インターンを３週間終えて、まず思ったのは「働くってこんなに疲れるのか……」でした。 実際業務中は業務のことで頭がパンパンですし、業務が終わってからは疲れてしまってほぼ何もできませんでした。 本当に、働きながら＋αで何かできる人ってすごいんだな、と思いました。

今回のインターンでは自分の苦手分野だったということもあり、ずっとヒーヒー言いながら開発になったと思いますが、 その環境に自分がいるということにある種の心地よさを感じていました。 そのおかげで色々なことを学べたし、普段できない体験もできたので、本当に濃い３週間を過ごせたと思います。 今回のインターンは本当に参加して良かったと思いました。 インターンでお世話になったアカツキ のメンターさん、デザイナーさん、プランナーさん、チームの皆さん、人事の方には感謝してもしきれません。本当にお世話になりました。

以上で自分のインターン参加報告を締めたいと思います。 最後まで読んでいただきありがとうございました。