はじめに
初めまして。アカツキでのインターンシップに参加させていただいた東正太と言います。
関西の大学３年生で、中二くらいからゲーム開発を趣味で行っています。
今回のインターンシップについて
今回はC++とcocos2dxを使うプロジェクトでクライアントエンジニアとして３週間のインターンシップに参加させていただきました。
僕の目論見としては、C++をせっかく触るならつよつよエンジニアになろう！と考えていました。
今回のインターンはテーマは「開発メンバーが喜ぶデバッグ機能を作ろう！」という、非常にざっくりしたテーマでした。
今回のインターンシップでやったこと
・デバッグ機能の改善要望を聞くため検証チームと会議を行いました。
・会議で出た要望を課題とし、解決方法を模索、検討し仕様を決めました。
・仕様や設計をエンジニアさんたちに共有しレビューしてもらいました。
・機能を実装しプルリクエストを出してブランチにマージしてもらいました。
こういう流れで３つのデバッグ機能を作成・改善しました。
客観的なまとめ
実際に開発メンバーが使える機能を３つ開発できたのはとても良かったと思います。
また、リモートながらエンジニア以外の人やインターン生など多くの人と関わることができました。
個人的な今回のインターンの感想
具体的な指標がなかったため、自分で課題設定を行い、スケジューリングを行い、課題を解決していく必要がありました。
そのため悩みや選択が多かったですが、解決することで多くのことを学べたと感じています。
起こった問題
・実機ビルドが動かない ・自己肯定感 ・進め方がわからない ・タスクを同時並行で進めてしまった ・会議の内容が理解できなかった ・相談するのが遅くなってしまう ・できないタスクに執着してしまった ・見積もりで実装しすぎてしまった ・発表がうまくできない ・朝からスピーディに仕事ができない ・偉い人が誰かわからない ・共有のための資料を不必要な箇所まで作ってしまう
多くの問題が起こりました。この後でいくつか紹介します。
会議の内容理解できなかった問題について
僕がエンジニアとして検証チームのデバッグ機能改善要望を聞き、返事をする会議がインターン３日目にありました。
しかし、僕は開発体制が整っておらず、デバッグ機能に関しての知識がほぼありませんでした。そのため、要望に対してエンジニアとして回答ができない状態にありました。
ここで要望に対して自分の頭で意図を読み取って作業を進めていくことが大事だということを学びました。
また、会議では理解できなかったところを後から質問して解決しました。
メンターさん神話について
会議中にメンターさんから機能を変更しようと考えていた一つの要望に関して提案
「機能を変更するではなく元の機能を使っている人もいるかも知れないから追加でいくといい感じだと思う」
個人的には両方の機能はいらないと感じていたのですが、メンターさんのいうことなので従いました。
仕様書を書き、エンジニアさんに共有したところ、エンジニアさんが
「いや、片方で十分じゃない？」
との発言でした。
僕はどっちに従えばいいかわからなくなってしまい自分の中で意見が右往左往しました。
ここで、気付いたことがあります。
仕事をしていく上で、メンターさんなど人の意見にそのまま従うのではなく、意見を参考にしながら最終的には自分で考えて判断しなければといけないということです。
僕は「前の機能が消えると困る人がいるか」を確認し、いなければ機能を変更することを決め、検証チームに質問したところ困る人がいませんでした。
その結果、実装範囲とスケジュールを決めて自分で実装することができました。
タスク同時並行問題
４日目から、会議で要望が出たものに対して改善案を見積もりする工程に入りました。タスクがどれだけかかるのか、どの方法なら仕様を満たす機能を実現できるのかを見積りました。
実装部分のコードを見たり追加しながら実現難易度や実装にかかりそうな日数を考えました。
僕は一つのブランチで見積もりを行いました。これが、後々問題を引き起こしてしまいます。
仕様書とブランチの失敗
見積もりの段階である程度実装の目処が立ったため、実装がほぼできたところで次に仕様書を書き始めることにしました。
実装がほぼできている機能に対して仕様書を書いたのですが、スクリーンショットがあるとより説明がしやすいと感じたため、３つ中２つの機能の実装を完成させてしまいました。
仕様書を共有し、仕様変更を行いながら実装を始めました。
しかし、先ほど一つのブランチで作業していたため、見積もりが終わっていないタスクと仕様書の実装を始めたいタスクの内容が同じ場所にありました。
そのため、スタッシュを知らない僕は全部を別のブランチで切り替えることでしかブランチの移動ができませんでした。
その結果、見積もりが終わっていないタスクが残ってしまうため、実装したい内容自体は完成しているのにコミットやプルリクエストが全然できない人になってしまいました。
PR、そして見積もり２つを同時並行で行う
なんとかプルリクエストを出し、見積もりとPRの修正タスクを同時並行で行いました。
PRの修正タスクのプッシュが終わったと同時にブランチを切り替え、見積もりを行ってビルドを行う、そうするとまたPRの修正が届いている・・・
ブランチを切り替えるたびにビルドが約20分かかるのもあって、暇な時間が増えてしまいました。
暇な時間をなんとか無くそうと、さらに実機でのデータダウンロードと新たなタスクの見積もりを始めました。
こうすることで４つのことを同時並行でやることになってしまい、頭が回らないまま数日が過ぎてしまいました。
ようやく解決へ
行き詰まった僕はメンターさんと話し、いくつかのことを教えてもらいました。
まず、同時に複数のことをしないこと。集中力や理解が必要な作業ほど、頭を切り替えるのに時間や気力などのコストを必要とします。このコストが大きくなり過ぎてしまうと、仕事の効率が大きく下がってしまいます。
次に、ブランチ運用について。複数の仕事をする際にはブランチを分け、スタッシュやリベースなどと言った運用で切り替えをしやすくすること。Gitを使用するメリットを意識して作業をしていくべきです。
また、実装できたということはタスクができたということではありません。単に動作確認ができただけで、自分が見積もりの段階でできたことなのに時間を使っていると少し落ち込んでたことは必要ないことだとわかりました。
問題を乗り越えた結果
僕はこうしてほぼ全ての問題を解決したことで、失敗したように思えた多くの出来事から成長を重ねることができました。自分で考えたり時にメンターさんや社員さんに気づかせてもらったことも多かったです。
多くの問題を解決し、成長を感じられた理由として大きいなと感じたのは
・メンターさんの毎日の1on1で質問や相談をさせてもらったこと
・他の部署の社員さんともランチなどのタイミングで交流が多くできたこと
・リモートでの労働環境や雰囲気に関して社員とかなり似た条件で働かせてもらえたため、イメージがつきやすかったこと
・機能を使ってもらえる人とコミュニケーションがとりやすくてFBや意見がもらえやすかったこと
でした。
しかし、
・リモートオンリーだったので直接話せなかったことだけでなくオフィスの雰囲気を掴むことができなかったこと
・他の人とコミュニケーションの取り方にコストがかかったこと（「画面をパッとに見せて会話」などができない、雑談が難しいなど）
・作った機能で開発メンバーが喜ぶ顔が見れなかったこと
などが心残りでこれらが実現されればもっと成長につなげることができたのかなと考えています。
これからやってくこと
今回のインターンで学ばせてもらった知識やツール、技術などを自分の開発にも生かしたいと考えています。
また、就活においてもゲームエンジニアとして働くことのイメージがついたので、もっと他の会社と比較して良い企業を見つけていきたいと考えています。
