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

この記事は Akatsuki Advent Calendar 2020 3日目の記事です。
前回は bluexxsun さんの スプレッドシートの関数では "" を使うな！ でした。

はじめに

アカツキでエンジニアをやっている 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 25010で規格されている品質特性を満たす、という定義も考えられます。いずれにしても、定義への合意は開発チーム全体で行うことだと思います。

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 2018V3.1.J02”. JSTQB 認定テスト技術者資格. 2019-11-11. http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018.J02.pdf , (アクセス日 2020-12-03). p.17

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

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

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

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

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

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

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

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

*12:ISTQB. “ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02”. JSTQB 認定テスト技術者資格. 2019-11-11. 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シーンの中でどういうヒエラルキーを使っているのか、どういうアーキテクチャを使っているのかのプラクティスを学べたことや、 なかなか個人開発では体験しにくいアセットバンドルについての知見を得ることができたこと、サーバーのマスターデータをどういう風にクライアントで使われているのかを学べたことが とてもよかったと思います。

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

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

全体の感想

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

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

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

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

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

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週間という短い間でしたがありがとうございました。