Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

Akatsuki Hackers Labは株式会社アカツキが運営しています。

アカツキのクライアントサイドインターンで何を学んだか

この記事は、アカツキで3週間の就業型インターンに参加して得た所見をまとめた体験記になります。

インターンについて

今回のインターンでは、スマホゲームのクライアントサイドのチームで3週間お世話になりました。

新型コロナウイルスの影響で、インターンはフルリモートで行われました。やりとりにはZoomやSlackを使うことになるので、実際のオフィスでの雰囲気などが掴めなかったのは残念に思います。

ありがたいことに、実際にオフィスに行って見学などをさせていただくというお話もいただいたのですが、残念ながら都合が合わず参加できませんでした。

インターン前の流れとしては、開始1ヶ月前にメンターになる方との面談、1週間前に入社オリエンを行い、それから3週間のインターンに参加するという形式でした。

やったこと

今回私はクライアントサイドのチームで「開発メンバーが喜ぶデバッグ機能を開発する」というテーマのもと、インターンを行いました。

課題設定

"開発メンバーが喜ぶ"ということで、実際にどのような機能が求められているのかを開発に携わっているメンバーにヒアリングしました。今回は一から課題を探していくのではなく、改善要望のリストから選んだものについて深掘りしていきます。

ここでは「なぜ」その機能が必要なのかを聞いて、場合によっては別の提案をしていくことが重要になります。エンジニアの目的は課題解決でありプログラミングは手段でしかないため、課題の根本的な原因を突き詰めることで解決に導いていきます。

今回は画面に描画されたデバッグ用のボタンが邪魔なので設定から消せるようにしたいという要望でしたが、「なぜ」を聞いていった結果、本番環境に近い画面が欲しいということがわかりました。

設計

設計ではプレゼンと同じように流れが重要になります。

私は初めは概要→目的→使い方の順で書いていたのですが、設計をレビューしていただいた結果、目的→概要→使い方→実現方法→今後の展望という流れになりました。

はじめに目的を持ってくることで、読んでいる人がなぜこの機能を作っているのかを知ることができます。

また、レビューで追加された実現方法ですが、これを書かないとエンジニア間で認識の違いが起きてしまうことが考えられます。さらにここでは複数の解を想定し、どういった理由でどの案を採用したのかを書くことで、より説得力を持たせられます。

実装

いよいよ実装になりますが、設計をしっかりやったことや機能自体はかなり単純だったこともあり一瞬で終わりました。

確認

実装が終わったのでプルリクを送ってマージしてもらいたいところですが、その前に必要な工程が一つあります。機能の依頼者に実装したものを確認してもらいます。

もし実装したものが依頼者の想像と違った場合、マージしてから修正するのは非常に手間がかかるのであらかじめ確認を取ることになります。

実装したものについては問題ないと確認が取れたのですが、実装した画面をよく見るとデバッグ表示のような数値が描画されていることに気づきました。

今回の目的は本番環境に近い画面が欲しいということなので、これも消したほうがいいのではないでしょうか。依頼者の方に確認したところ消して欲しいと言われたので、こちらについても消していくことになりました。

課題設定の際に「なぜ」を掘り下げたことで、ここで新しい課題を発見することができました。

追加の実装

デバッグ表示が残っている箇所を調査すると、いくつかの箇所のデバッグ表示が残っていることがわかったため、すべて非表示にできるように実装を進めていきます。

プルリク&マージ

追加の実装が終わったら今度こそプルリクとマージです。今回は大きな修正点もなかったのですんなりマージされました。

機能がマージされたので、これで依頼者の方が当該ブランチで機能を使えるようになりました。

学んだこと

3週間という短い期間のインターンではありましたが、多くのことを学ぶことができました。

GitHubを使ったチーム開発の流れ

これまでチーム開発の経験が少なかったので、とても勉強になりました。

ブランチ周りの機能も一人で開発するときは面倒で使っていなかったのですが、今回はその辺りも学ぶいい機会になりました。

既存のコードをちゃんと読む

チームでの実装となると、既存のコードのほとんどは他の人が書いたものになります。そのためコードをいまいち理解しないまま利用してしまうと、エラーが起きた際にどこが原因なのかがわかりにくくなってしまいます。

また、同じことができる機能が複数あったりもするので、そのときはコードを読むことでどちらがより適切なのかを判断する必要が出てきます。

ただ、既存のコードを読んで理解することは大切ですが、それを信頼するのはまた話が変わってきます。もっと良い実装方法があるかもしれないので、飽くまで既存のコードは参考程度ということになります。

コードに限らず命名は大事

コードを書くとき、変数名や関数名を適切につけることは非常に大切です。しかし、コードだけでなく仕様書やプルリクでもこれは大切になってきます。

いろんな意味にとれる書き方をしてしまうと、読む人に不親切なだけでなく後々認識の違いから問題が起きる可能性もあります。

ちゃんとした日本語を使うことを心がけることで、チームでの連携がより取りやすくなっていきます。

エンジニアの仕事はコーディングだけじゃない

今回のインターンに参加するまで、エンジニア職はコードを書く時間がほとんどなんだろうと思っていたのですが、実際は話し合いや設計の比重が大きいようです。

そのため、技術力はもちろんですがコミュニケーション能力も重要になるでしょう。

まとめ

インターンに参加する前の自分と比較して、かなり成長することができたのではないかと思います。

フルリモートという環境ではありましたが、アカツキの空気を感じることができた3週間でした。ありがとうございました。