はじめに
どうもnamekosiruです。今回は7月11日~7月29日(３週間)の期間にアカツキのクライアントエンジニアのインターンに参加してきたのでそれについてのブログを書いていこうと思います！！
目次
Who are you?
私は現在奈良先端科学技術大学院大学に所属する修士1年の学生です。開発経験としてはインターンやアルバイトでデータ分析、ML*1開発を中心に行っていました。その裏で細々とサーバーサイドの開発もやっていたような経歴になります。 今年の4月ごろから就活を考え始め、幼い頃から今までずっとやっていたゲームの開発に携わりたいと思いゲーム業界を中心に就活をしています。
エントリーしようと思ったきっかけ
アカツキさんのインターンに参加しようと思った経緯について話します。
夏のインターンではゲーム業界の開発を学べるようなインターンを探していました。
また、私はインターンを探す上で以下の２つの軸を中心に探していきました。
- 「ユーザーに新しい体験を届けられる」
- 「チーム開発がしやすい環境が浸透しているか」(後にHRT*2という考え方だと知ります)
探しているうちに逆求人などでお会いしたアカツキさんの社風やインターン内容に惹かれました。アカツキさんではコアバリューとしていくつか掲げている原則がありますがその中に
- 謙虚・尊敬・信頼を大切にする
- 関わる人すべてを驚かせる
という原則があります。この部分が自分の軸と非常にマッチしていると感じインターンシップに応募する形になりました。面接を通じてチーム開発に対する考えやゲームに対する思いを話したところ採用という形になりました。
インターン中の取り組み
インターン中に何に取り組んだかを話します。
インターンではあるタイトルのクライアントチームにクライアントエンジニアとしてジョインさせていただくことになりました。インターンでは「開発者が喜ぶデバッグ機能の開発」に取り組みました。具体的な内容は以下の通りです。
- 音量ボタン調整画面の実装
- ゲームUIの修正
上記の内容を以下の4つの流れで取り組みました
- 工数見積
- ヒアリング
- 実装
- レビュー
工数見積
始めに工数見積では改善要望シート*3から自分の取り組むべき課題を選定しました。ここでは以下の３つの観点で選定を行いました。
- 開発日数
- 技術力
- 改善要望の優先度
開発日数では実際のその機能を開発するのにどのくらいの日数がかかるかを考慮します。ゲーム開発は機能やタイトルのリリースに締め切りが設けられていることが多々あります。そのため「どの機能をいつまでに」開発するかを見積もることは非常に重要になります。そのため機能開発を始める際に無計画に開発するのではなく、マイルストーンを要所ごとに設けて開発を進めていく必要があります。
技術力では今回のインターンに限った話ではありますが３週間という短い期間で最大限のアウトプットを出さなければなりません。そのため「自身の技術力で本当に実装ができるのか」、「実装が期間内で終わるのか」などの要素を考慮しなければなりません。
改善要望の優先度では「その機能がどの程度必要とされているのか」を考慮します。優先度が低いものよりも優先度が高いものの方が重要度が高いの至極当然です。そのため優先度を考慮して本当に必要とされている機能を選定する必要があります。
上記のような観点で工数の見積を行いました。技術力の観点では正しく見積をできなかったので後々にモブワークという方法で機能の開発をしました。
ヒアリング
さて実際に取り組む課題を選定した後は要望者に実際にヒアリングします。
始めにヒアリングをする際に必ずすることは要望の背景・目的を聞くことです。これを行うことで前提をお互いの認識の誤差を減らすことができます。また、自らアイデアを提案する場合でも背景や目的を知っていることでより良いアイデアを提案しやすくなります。加えて、画面共有や動画などを用意して相手にわかりやすく伝えることも非常に重要です。
実装
そしてお待ちかねの実装です。さあ書くぞという意気込みでコーディングに取り組みました。しかし、私の場合機能の実装が難しく一人ではできなかったです。そこで他のクライアントメンバーに協力を要請してモブワーク*4を行いました。モブワークでは自分がドライバーを務め、他のメンバーからの指示をもとに機能の開発を行いました。モブワークでは普段知ることがない 暗黙知*5を知ることができたのが非常に新鮮でした。エンジニアの視点や考え方、細かいTipsなどはドキュメント上に中々書き起こすことができません。そのため他のエンジニアの考え方を学ぶ機会としてモブワークは非常に有効です。
レビュー
最後にコードの品質を保つためにレビューを行います。レビューでは機能の実装方法や変数名などを細かく見られます。印象に残った言葉として「命名をつけにくいのは設計そのものが良くない」が挙げられます。個人開発やチームのハッカソン開発で命名をつけにくいことがしばしばありました。この当時は自分が命名をうまくつけられないだけと考えていました。しかし、本当の原因は設計そのものが良くなかったことにありました。普段から命名を意識することで設計全体の良し悪しも図ることができるのには非常に驚きました。
また、作った機能を要望者の方に画像や動画を用いて確認をしてもらいます。作った機能を再度確認してもらうことで本当にその機能が要望者の要求を満たしているか確認できます。実際に作った機能は作って終わりにするのではなく、作った機能に対して確認＆フィードバックもらい更により良いものにしていく必要があります。
インターンからの学び
可読性
実際の運用されているゲームの大量のソースコードの読むことには面くらいました。普段インターンで読むことも多くあるのですがそれと比にならないくらいすごい量のソースコードが管理されていることがわかりました。インターンの課題に取り組む際も取り組むべき場所をその膨大な量のコードから見つけてこなければならず非常に困難でした。しかし、私の参加したプロジェクトでは非常に命名にこだわってコーディングされているので読み込む上でそれらの名前が非常に助けになりました。
そのため複雑なシステムになるほど名前にこだわっていくことは大切だと感じました。また、この話はソースコードに限った話ではありません。プルリクエスト、コミットメッセージ、Slackでの文章あらゆる場面でこの可読性を意識しなければなりません。常に自分のメッセージを読んで「適切な量の情報を適切な相手にわかりやすく伝えることができているか」を意識し続けることが可読性の向上に繋がっていくのだと強く感じました。
スケジュールの管理
膨大な量のソースコードを読んでいるとついつい時間が過ぎてしまうことがありました。そのためインターン始めの方は非常に作業効率が悪かったです。そこで私はタスクごとに時間を見積何をしなければならないのかを週単位と日単位でスケジューリングしました。これらを行うことでついつい眺めているだけになりがちなコードリーディングを効率よく行うことができました。また、その日ごとにTODOを設けて課題に取り組めた点も非常によかったのでこれからも続けていきたいなと思いました。
学びの抽象化
インターン期間中によく言われたのが「たくさん学ぶ」ことでした。この学び方については二つの学び方があると思います。一つ目は単純に学びの量を増やす。二つ目は学びを抽象化して他のことに応用する。この二つ目を特にインターンで得られました。社会人になると自由に使える時間が減り一つ目の「学びの量を増やす」のは難しくなります。しかし、エンジニアの職業柄たくさん学ばなければなりません。時間が少ない状況で学ぶことを実現するためにこの学びの抽象化は非常に重要です。日常的に経験することからその経験を抽象化して新たな物事に応用することが「たくさん学ぶ」ことに繋がります。この「学びの抽象化」はエンジニアに限らずに行えるのでこれからも積極的に行っていこうと思います。
まとめ
メンターの伊藤さん、クライアントメンバーのみなさん、プロジェクトの皆さんのおかげで多くのことを学ぶことができました。３週間という短い間でしたが本当にありがとうございました！
