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

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

アカツキゲームスでクライアントサイドエンジニアのインターンとして参加しました

こんにちは。8/16〜9/3の3週間、フルリモートでアカツキゲームスのサマーインターンに参加させていただきましたSKと申します。今回はインターンで取り組んだこと、学んだことについてまとめさせていただきます。

 

自己紹介

大阪府立大学に通う学部3回です。普段はUnity、C#を使ってゲーム開発を行ったり、アルバイトでPythonを使ったりしております。ゲーム業界に興味があり、実際に働いて体験してみたいという思いから参加を志望いたしました。

 

取り組んだこと

今回参加させていただいたのは「八月のシンデレラナイン」(以後ハチナイ)というゲームの現場でした。その中で3つのタスクを行いました。

キャンペーンミッションにて報酬を受け取ったとき、ナインスターの値が更新されるタイミングを調整する

最初のタスクはヘッダーのナインスターの個数を更新するタイミングを調整する機能です。

f:id:Ksyota:20210903172949p:plain

本来であれば達成ボタンを押すとアニメーションが走り、アニメーションが終わった後にナインスターが更新されるはずです。しかしミッションでは達成ボタンを押すとすぐにナインスターが更新され、アニメーションがその後に走ってしまう状況でした。これではユーザーさんはナインスターが増えたことに気づきにくく、本当にナインスターが増えているのかと不安を抱かせることになります。

対応方法としてはナインスターを更新するかを管理するFlagがあり、Flagを切り替えるタイミングを早めることで対応いたしました。

最初のタスクということもあり、どこにどの処理があるのかを探すことに苦労したため完了するまでに少し時間がかかってしまいました。

練習選手選択画面で選手アイコンを長押しした時その選手の詳細を見れるようにする機能

続いて練習選手選択画面で選手アイコンを長押しした時、その選手の詳細を見れるようにする機能を実装いたしました。

f:id:Ksyota:20210903174152p:plain

ハチナイをプレイしていて練習選手を選択する際、その選手の詳細を確認したいという場面がありました。しかし、現状練習選手選択画面から詳細は確認することはできず、シーン選択ボタンを押してシーン選択画面から選手の詳細を確認しておりました。このワンクッションが手間と感じておりました。

また、インターン参加にあたって事前に改修案があれば考えといてというタスクもありましたので、この際に提案してみたところすんなりと対応することに決まりました。

提案してから数日検討されるかと思っていたのですが、すぐに決まったのでこの速さにとても驚きました。

対応方法としては練習選手選択画面では長押しが無効になっていたので、それを有効にするだけでした。想像以上に簡単に実現できたのでよかったです。

条件で絞り込んだ選手を自動で移籍選手として選択する機能

移籍時にダイアログから条件を指定し、その条件に基づいて移籍選手を自動で選択するという機能で、今回のインターンではメインのタスクでした。

しかし、選手保管庫と選手管理をまたいで同シーンの状況を見るためには読み込みの負荷軽減や比較のしやすさにおいて課題が残り、デザイン面も完成に至らなかったため結果的にリリースしないこととなりました。

このタスクは私主導で行うタスクであり、着手した当初は仕様の段階でした。そのため私主導でMTGを設定し、プランナーの方とデザイナーの方とコミュニケーションを取りました。

初期の仕様は今回実装した内容とは異なるものでした。最初のMTGで初期の仕様に指摘が入り、今回実装した内容に近い仕様となりました。

実装ではダイアログ機能の実装や条件で絞り込む機能、絞り込んだ選手を選択する機能の実装を行いました。実装自体はそこまで重たくはなかったです。

今回のタスクは話し合って決まったことを元にプロトタイプを作成し、それを元に再度意見を交わすということを繰り返して実装面を完成することはできました。しかし、デザインまで含めて完成することはできなかったため残念です。

このタスクを通してコミュニケーションの難しさを感じました。MTGでは全員でそのMTGの目的を共有できておらずスムーズに話し合うことができなかったり、チャットのやり取りでも相手の意思を汲み取れなかったり、自分の意見をうまく伝えられなかったりとオンラインでのコミュニケーションに難しさを感じました。この辺りをうまくできればデザインまで含めて完成できたのかもしれません。

一方で印象的であったことは仕様決めのMTGでデザイナーの方やプランナーの方、他のエンジニアの方がそれぞれの立場から意見をぶつけ合っていたことです。バチバチでした。しかしそれだけいいものを作り上げていこうという思いが一人一人にあり、見習うべき点であると感じました。

まとめ

運営中のゲームの開発に携わることができた

実際に運営されているゲームに携わることができたのは非常に貴重な体験でした。実際に開発に携わったことで、UnityのScene管理の方法など参考になる処理を知ることができたのはとても良い経験でした。自分の開発でも取り入れていきたいです。

エンジニアはコミュニケーションも大事

このことは適当な技術系の記事を見ていればよく見かけることですが、それを痛感いたしました。正確にコミュニケーションを取ることでスムーズに開発できるとメインのタスクを通して感じました。

会社の雰囲気

社員の方々は一人一人が自立しており、お互いを信頼しあって働いておられるという印象です。また社内もいい意味で上下関係はなく雰囲気はとても良いように思えます。

最後に

3週間という短い期間でしたが、手厚いサポートに支えられ非常にいい経験を積むことができました。本当にありがとうございました。

 

 

 

 

Akatsuki Games Internship 2022 Go/GCPコースでアラートを改善した話

こんにちは。東北大学 情報科学研究科 M1の近藤 智文です。Twitterでは@tomokon_0314で活動しています。大学ではネットワーク、SDNの研究をしており、趣味は自宅インフラやリアル脱出ゲーム、ボードゲーム等です。最近は火星から脱出したりしてます 🚀

今回、「Akatsuki Games Internship 2022 Go/GCPコース」に参加し、株式会社アカツキゲームスのATLASチームにて2022/08/01〜2022/08/19の期間で3週間のインターンをさせていただきました!

インターン中に取り組んだタスクやそこで学んだことについて紹介しようと思います。

ATLASの通貨管理基盤について

ATLASにはアカツキゲームス社内のさまざまなタイトルのゲームから利用されている共通の通貨管理基盤があり、クライアント側で動作するライブラリと、課金や通貨の残高管理機能を提供するAPI Serverから成ります。今回私が関わったのは後者のAPI Serverの方でした。イメージとしては以下の図の感じです。

通貨管理基盤


上図の下部の紫の枠で囲まれた「通貨管理基盤」と書かれているAPI ServerはGoで実装されており、GCP のGoogle App Engine (GAE) 上で動かされています。メインのAPIとは別に社内用管理アプリケーションをCloud Run上で動かしたりもしています。インフラの構成は以下のような感じです。

通貨管理基盤のAPI Serverのインフラ構成

インターンで取り組んだタスク

今回のインターンではATLASの通貨管理基盤のAPI Serverに関する2つのタスクに取り組みました。一つずつ紹介していきます。

APIのレスポンスにおけるステータスコードの修正

通貨管理基盤で扱う通貨には2種類あります。プレイヤーさんが課金によって得た通貨である有償通貨と、それ以外の例えばイベントやログインボーナスで得た通貨である無償通貨です。後者の無償通貨をチャージするためのAPIのエンドポイントにおいて、クライアントからのリクエストとデータベースの情報が不整合を起こして場合にはエラーを示すステータスコードを含むHTTPレスポンスを返すようになっていたのですが、そのステータスコードが本来400であるべきはずであるのに実際には500になっているという問題が生じていました。

HTTPのステータスコードについて簡単におさらいですが、HTTPのステータスコードは3桁の整数で表され、最上位の桁が大まかなレスポンスの種類を示しています。例えば2xxであればリクエストが成功したことを、3xxであればリダイレクトを、4xxであればクライアントエラーを、5xxであればサーバーエラーであることを示します。詳しくは以下のドキュメントを見てみてください。

developer.mozilla.org

ではなぜ本来は400で返すべきものを500で返すことが問題になるかと言うと、主に二つの理由があります。

一つ目は、レスポンスのステータスコードによってクライアントの対応が異なる場合があるからです。例えば400エラーであればクライアントは自信が送信したリクエストに何らかの間違いがあることに気づき、間違いを修正して再度リクエストを送り直すことになります。対して500エラーの場合は、クライアントはサーバー側の一時的な不具合かもしれないと思い、時間を置いて何度もリトライ処理をするかもしれません。しかし、実際にはリクエストに間違いがあるため何度リクエストを送信しても成功することはなく、不要なリクエストが何度も発生してしまったり、クライアントが自身の間違いに気づくのが遅くなってしまうという問題につながるかもしれません。

二つ目は、API Server側のエラーレートの誤検知に繋がるからです。例えばAPI Serverで5xxエラーの割合を計測してそれをn%に抑えようという取り組みをしていた場合に、本来は400エラーであるべきものが500エラーとしてカウントされてしまうと、適切なエラーレートの集計ができなくなってしまいます。

そこで、無償通貨チャージのエンドポイントの実装に該当するエラーハンドリングを追加し、クライアントからのリクエストに間違いがある場合は400エラーを返すように修正しました。また各エンドポイントに対するレスポンスのステータスコードはインテグレーションテストによって検証されていたため、テストコードにも修正を加え、無事意図通りに動作していることを確認できました。

アラートの改善

続いてのタスクとして、通貨管理基盤 API Serverにおけるアラートの改善に取り組みました。

タスクに取り組んだ理由は、既存のアラートでは頻繁に (一日に何度も) 通知が飛んでくるのに実際には対応が必要になるような問題が生じておらず、不要なアラートの対応に労力や集中力が奪われてしまっていたからです。また、不要なアラートが頻繁に発生することで「アラート慣れ」してしまい、アラートが起きても「何だ、またアラートの誤作動か」と思ってしまうようになります。そうなると、もし本当に対応が必要なアラートが発生したときにもそのように軽く考えてしまい、対応が遅れて障害の影響が大きくなってしまうという危険性があります。いわゆる「オオカミ少年アラート」というやつです。

このタスクに取り組むために、まずは情報収集に取り組みました。メンターさんやチームメンバからお薦めしてもらった Google - Site Reliability Engineering の資料や家にあって積読していた O'Reilly Japan - 入門 監視 、O'Reilly Japan - SRE サイトリライアビリティエンジニアリング などの書籍を参考に、Service Level Indicator (SLI)、Service Level Objective (SLO)、Error-budget、Burn-rateなど、SREにおけるモニタリングやアラートの考え方やプラクティスについて学びました。調べる前は「SLOとかError-budgetとか聞いたことある!」くらいのレベルだったので、それらの意味や具体的な算出方法、それらをアラートにどう利用するかなどをしっかりと理解することができて非常にためになりました。

そして、収集した情報を元に通貨管理基盤 API ServerのSLOの見直しを行い、決定したSLOを元にFast-burn、Slow-burn (気になる方は上記リンクを調べてみてください) の2種類の条件からなるアラートを策定しました。下図は実際にGitHubのコメント上で提案したアラートの条件で、上行がFast-burn、下行がSlow-burnとなっています。

SLOに基づくアラートの条件

あとは策定したアラートをTerraformで記述することで本番環境のGCPプロジェクトに反映し、意図通りに動作することが確認できました。

学んだこと

今回のインターンでは初めて本番環境のGCPに触れ、特にGAEやCloud Monitoringの仕様や使い方について学ぶことができました。特に本番環境のCloud Monitoringのメトリクスやログ等を自由に見させていただくことで、実サービスのリクエストのトラフィックを体感できてワクワクしました。また、Cloud MonitoringのMetrics Explorerでメトリクスを集計してカスタマイズしたグラフを作成する方法や、SLOやアラートの定義の方法など、GCPのドキュメントをじっくり読む時間をいただいたおかげでかなり詳しく知ることができました。また、GCPに限らずSREにおけるモニタリングの考え方・プラクティスについてもさまざまな資料を読み、今まで曖昧な理解だったものをより深く理解することができました。インターン期間の半分、もしかしたらそれ以上の時間を調査に使っていたような気がしますが、じっくりと調査して考える時間をいただけたおかげで最終的に自分もチームメンバも納得のいく形で結果を出すことができたと感じています。

さいごに

3週間という短い期間でしたが、タスクを通してさまざまなことを学ぶことができ、充実したインターンになりました!

メンターの nakahiko さんを始めとしたATLASのチームの皆さんには色々とアドバイスをいただいたりとお世話になりました。本当にありがとうございました 🙇‍♂️

さいごに出社日に食べたランチの写真を載せておきます 🍽

私が食べたサラダボウル on レモンライス

メンターさんが食べたお肉とかレモンライスとかのやつ

 

Akatsuki Games Internship 2022のRuby on Rails / AWS コースに参加してきました!

はじめまして!アカツキゲームスのサーバーサイドエンジニアインターンシップに参加した石島と申します。

本記事では、私がインターンシップで学んだことについてご紹介します!

筆者について

筑波大学大学院人間総合科学学術院人間総合科学研究群情報学学位プログラム所属、修士1年の学生です。

開発経験としてはインターンシップやアルバイトでRuby on Railsを使用したアプリケーションの開発に携わっていました。
そのため、同じくRailsを利用するサーバーサイドのインターンシップに今回参加しようと思いました。あとは、元々ゲームが好きなので、ゲーム業界の裏側が見てみたい!という気持ちでエントリーをしました。

インターンシップについて

3週間の就業型インターンシップとなっており、私は8/1〜8/19の期間で参加しました。

詳しいインターンシップの情報については下記のリンクから見ることができます。

aktsk.jp

3週間の流れ・過ごし方

最初の3日間で各種オリエンテーションを受けます。

アカツキゲームスにおけるルールや勤怠などの事務的な話、インターンシップ期間中の過ごし方及び配属されるプロジェクトとその開発体制についての話など…3日目になるにつれて徐々に人事の方から配属されるプロジェクトでの関わりが増えていく感じになります。

私が配属されたプロジェクトはスクラムを採用した開発体制になっていたので、毎日のスクラムイベントに沿った形で進捗報告をしつつ、自分が担当するタスクに取り組んでいました。

インターン中に取り組んだこと

ゲーム内文言の表記揺れ検出ツールの実装

今回のタスクはひらたく言うと、検証チームのメンバー向けの社内ツールの開発になります。

検証って?

一般的なゲームの開発では、「検証」という役職の方々がいます。この検証さんという方々は、エンジニアが実装したものにバグや不具合がないかどうかをチェックする業務をしています。

ゲーム中のスキルの効果文言の中には「攻撃力が○%UP」などのワードが多く存在しています。これらの効果文言と、実際の効果内容が一致しているかどうかといった検証を行っています。

検証さんの業務での困りごと

このようなスキル文言のチェック中に、「新しく追加された効果の説明文と既存の効果の説明文とで表記の揺れが発生する」ことがありました。
例えば、「味方の攻撃力を○%上げる」→「味方の攻撃力○%UP」といった細かいフレーズが異なっているようなものです。

そこで、上記の困りごとを改善するタスクを私が受け持つことになり、困りごとに対する解像度を上げつつ解決方法(not実装方法)を探すところから検討を始めました。

背景知識を社内のドキュメントから探したり、検証さんに直接ヒアリングした結果、「説明文の表記に関する包括的なレギュレーションが存在しておらず、表記揺れ整理&文言統一作業中」という状態でした。

また、「既存の説明文の表記揺れを発見するより新しい説明文に間違いを含まないようにする方を優先したい」という検証さんの要望があり、「発見済みの表記揺れをまとめ、新規の文言を検討する際にすでに統一した表記のレギュレーションに則しているかチェックできるようにする」という方針で解決することにしました。

その結果、表記揺れ検出ツールを実装することにしました。

出来上がったツールについて

効果の文言を入力すると、文言に色をつけて出力するものを実装しました。
スプレッドシートに正しいor誤りフレーズを登録しておいて、それぞれ緑、赤で色つけすることで、どんなレギュレーションが関係するかを見せることができます。加えて、これらのフレーズには「攻撃力(\d+)%UP」などの正規表現を用いることが出来ます。

チェックツールのイメージ図

要望をいただいた検証さんにお見せしたところ、すごく喜んでいただけて作った甲斐があったと思いました!

このツールを実装するにあたって、検証さんには都度フィードバックをもらうことを心がけました。それにより、自分のイメージ先行で機能を開発することなく、しっかり使う人の意見を取り入れたツールにすることが出来たかなと思っています。

このツールが運用されるところまで時間的に今回見届けることができませんでしたが、ぜひ上手く活用されてくれたら嬉しいです。

インターンを終えて

ここまで私がインターンで取り組んだ内容について書いてきました。
ここからは個人的にこれが面白かった!という点についてご紹介したいと思います。

ちゃんとしたスクラムが見られる

前半でも少し触れたんですが、今回私が配属されたプロジェクトはスクラムという開発体制を採用しています。
元々、自分は開発プロセスの改善やチームの運営手法に興味が強いタイプであったため、実際の業務においてうまくスクラムが機能している様子を見ることができて、とても興味深かったです。アカツキゲームスでは、全てのチームがスクラムを採用しているわけではないため、自分がここに配属してもらえたのはすごく幸運でした。

プロジェクトへの受け入れフローがしっかりしていてちっとも不安にならない

最初に怒涛のオリエンテーションがあり、この内容で困ったらここ、そもそも誰に聞くのか分からないときはここに連絡、という人事の方の厚いサポートがあり、何をしたら良いかわからなくなることはちっともありませんでした。

また、毎日メンターさんとの1on1があったり、チームメンバーの方々とお昼休みにZoomでおしゃべりしたり、私が不安になる前に話を聞いてもらう機会があるのでとても安心して過ごすことができました。特に自分が面白いな〜と思ったのは、オリエンテーションもチームでのオンボーディングも同じ日にジョインした業務委託のエンジニアの方とほぼ一緒だったことです。

インターンシップ用に特別に用意したフローではなく、通常の新メンバーの受け入れフローそのまんまなんだ!っていう。もし自分が新卒でジョインするとしたらこんな感じ、という働き始めのイメージがしっかり持ててとっても良かったです。

かなり自由に開発させてもらった

検証さんとのヒアリングは自分で検証さんにコンタクト取って予定押さえて、その後はフィードバックもらいながら実装、フィードバック、実装、フィードバック…という感じで必要とされる仕様を都度コミュニケーション取りながら決めていました。

今回のタスクでは、他職種とのコミュニケーションを強く感じられてとても楽しかったです。詰まったときはメンターさんに助けてもらいつつ、基本は見守ってもらって自由に開発させてもらいました。

自分が話してみたいと思った人と面談する機会をもらえる

インターン期間中、自分が話してみたい人とお話する機会を積極的にセッティングしてもらえます。こういう特徴を持った人と話してみたい、というのがあれば人事の方が社内で合致する人にコンタクトを取ってくれて、お話することができます。
私の場合は、主にキャリア相談を中心に、なりたいキャリアに近い人にお話が聞けたので、とても参考になりました。

まとめ

3週間長いなぁ…と始まる前まで思っていたんですが、いざ始まったら一瞬でした。

メンターの方をはじめとして、関わってくださった人全員がとても温かく接してくださったので、本当に楽しく過ごすことができました。
短い期間ではありましたが、お世話になりました!

【LT会】7/7_Akatsuki Games Geek Live 開催レポート!

こんにちは。アカツキゲームス新卒採用担当の藤元です。

先月7/7(木)、七夕の日にアカツキゲームスではエンジニアを志す学生さま向けにLT会を実施しました!

※ LTとは:Lightning Talkの略で短いプレゼンテーションのこと

 

▼イベント概要はこちらから

https://aktsk.connpass.com/event/239674/

続きを読む

アカツキの学生インターンに参加してきた!

はじめに

どうもnamekosiruです。今回は7月11日~7月29日(3週間)の期間にアカツキのクライアントエンジニアのインターンに参加してきたのでそれについてのブログを書いていこうと思います!!

目次

Who are you?

私は現在奈良先端科学技術大学院大学に所属する修士1年の学生です。開発経験としてはインターンやアルバイトでデータ分析、ML*1開発を中心に行っていました。その裏で細々とサーバーサイドの開発もやっていたような経歴になります。 今年の4月ごろから就活を考え始め、幼い頃から今までずっとやっていたゲームの開発に携わりたいと思いゲーム業界を中心に就活をしています。

エントリーしようと思ったきっかけ

アカツキさんのインターンに参加しようと思った経緯について話します。
夏のインターンではゲーム業界の開発を学べるようなインターンを探していました。 また、私はインターンを探す上で以下の2つの軸を中心に探していきました。

  • ユーザーに新しい体験を届けられる
  • チーム開発がしやすい環境が浸透しているか」(後にHRT*2という考え方だと知ります)

探しているうちに逆求人などでお会いしたアカツキさんの社風やインターン内容に惹かれました。アカツキさんではコアバリューとしていくつか掲げている原則がありますがその中に

  • 謙虚・尊敬・信頼を大切にする
  • 関わる人すべてを驚かせる

という原則があります。この部分が自分の軸と非常にマッチしていると感じインターンシップに応募する形になりました。面接を通じてチーム開発に対する考えやゲームに対する思いを話したところ採用という形になりました。

インターン中の取り組み

インターン中に何に取り組んだかを話します。

インターンではあるタイトルのクライアントチームにクライアントエンジニアとしてジョインさせていただくことになりました。インターンでは「開発者が喜ぶデバッグ機能の開発」に取り組みました。具体的な内容は以下の通りです。

  • 音量ボタン調整画面の実装
  • ゲームUIの修正

上記の内容を以下の4つの流れで取り組みました

  • 工数見積
  • ヒアリング
  • 実装
  • レビュー

工数見積

始めに工数見積では改善要望シート*3から自分の取り組むべき課題を選定しました。ここでは以下の3つの観点で選定を行いました。

  • 開発日数
  • 技術力
  • 改善要望の優先度

開発日数では実際のその機能を開発するのにどのくらいの日数がかかるかを考慮します。ゲーム開発は機能やタイトルのリリースに締め切りが設けられていることが多々あります。そのため「どの機能をいつまでに」開発するかを見積もることは非常に重要になります。そのため機能開発を始める際に無計画に開発するのではなく、マイルストーンを要所ごとに設けて開発を進めていく必要があります。

技術力では今回のインターンに限った話ではありますが3週間という短い期間で最大限のアウトプットを出さなければなりません。そのため「自身の技術力で本当に実装ができるのか」、「実装が期間内で終わるのか」などの要素を考慮しなければなりません。

改善要望の優先度では「その機能がどの程度必要とされているのか」を考慮します。優先度が低いものよりも優先度が高いものの方が重要度が高いの至極当然です。そのため優先度を考慮して本当に必要とされている機能を選定する必要があります。

上記のような観点で工数の見積を行いました。技術力の観点では正しく見積をできなかったので後々にモブワークという方法で機能の開発をしました。

ヒアリング

さて実際に取り組む課題を選定した後は要望者に実際にヒアリングします。

始めにヒアリングをする際に必ずすることは要望の背景・目的を聞くことです。これを行うことで前提をお互いの認識の誤差を減らすことができます。また、自らアイデアを提案する場合でも背景や目的を知っていることでより良いアイデアを提案しやすくなります。加えて、画面共有や動画などを用意して相手にわかりやすく伝えることも非常に重要です。

実装

そしてお待ちかねの実装です。さあ書くぞという意気込みでコーディングに取り組みました。しかし、私の場合機能の実装が難しく一人ではできなかったです。そこで他のクライアントメンバーに協力を要請してモブワーク*4を行いました。モブワークでは自分がドライバーを務め、他のメンバーからの指示をもとに機能の開発を行いました。モブワークでは普段知ることがない 暗黙知*5を知ることができたのが非常に新鮮でした。エンジニアの視点や考え方、細かいTipsなどはドキュメント上に中々書き起こすことができません。そのため他のエンジニアの考え方を学ぶ機会としてモブワークは非常に有効です。

レビュー

最後にコードの品質を保つためにレビューを行います。レビューでは機能の実装方法や変数名などを細かく見られます。印象に残った言葉として「命名をつけにくいのは設計そのものが良くない」が挙げられます。個人開発やチームのハッカソン開発で命名をつけにくいことがしばしばありました。この当時は自分が命名をうまくつけられないだけと考えていました。しかし、本当の原因は設計そのものが良くなかったことにありました。普段から命名を意識することで設計全体の良し悪しも図ることができるのには非常に驚きました。

また、作った機能を要望者の方に画像や動画を用いて確認をしてもらいます。作った機能を再度確認してもらうことで本当にその機能が要望者の要求を満たしているか確認できます。実際に作った機能は作って終わりにするのではなく、作った機能に対して確認&フィードバックもらい更により良いものにしていく必要があります。

インターンからの学び

可読性

実際の運用されているゲームの大量のソースコードの読むことには面くらいました。普段インターンで読むことも多くあるのですがそれと比にならないくらいすごい量のソースコードが管理されていることがわかりました。インターンの課題に取り組む際も取り組むべき場所をその膨大な量のコードから見つけてこなければならず非常に困難でした。しかし、私の参加したプロジェクトでは非常に命名にこだわってコーディングされているので読み込む上でそれらの名前が非常に助けになりました。

そのため複雑なシステムになるほど名前にこだわっていくことは大切だと感じました。また、この話はソースコードに限った話ではありません。プルリクエスト、コミットメッセージ、Slackでの文章あらゆる場面でこの可読性を意識しなければなりません。常に自分のメッセージを読んで「適切な量の情報を適切な相手にわかりやすく伝えることができているか」を意識し続けることが可読性の向上に繋がっていくのだと強く感じました。

スケジュールの管理

膨大な量のソースコードを読んでいるとついつい時間が過ぎてしまうことがありました。そのためインターン始めの方は非常に作業効率が悪かったです。そこで私はタスクごとに時間を見積何をしなければならないのかを週単位と日単位でスケジューリングしました。これらを行うことでついつい眺めているだけになりがちなコードリーディングを効率よく行うことができました。また、その日ごとにTODOを設けて課題に取り組めた点も非常によかったのでこれからも続けていきたいなと思いました。

学びの抽象化

インターン期間中によく言われたのが「たくさん学ぶ」ことでした。この学び方については二つの学び方があると思います。一つ目は単純に学びの量を増やす。二つ目は学びを抽象化して他のことに応用する。この二つ目を特にインターンで得られました。社会人になると自由に使える時間が減り一つ目の「学びの量を増やす」のは難しくなります。しかし、エンジニアの職業柄たくさん学ばなければなりません。時間が少ない状況で学ぶことを実現するためにこの学びの抽象化は非常に重要です。日常的に経験することからその経験を抽象化して新たな物事に応用することが「たくさん学ぶ」ことに繋がります。この「学びの抽象化」はエンジニアに限らずに行えるのでこれからも積極的に行っていこうと思います。

まとめ

メンターの伊藤さん、クライアントメンバーのみなさん、プロジェクトの皆さんのおかげで多くのことを学ぶことができました。3週間という短い間でしたが本当にありがとうございました!

*1:Machine Learning

*2:謙虚(Humility)、尊敬(Respect)、信頼(Trust)

*3:現場のデバッグ機能関連で欲しい機能や直してほしいバグなどが列挙されているシート

*4:複数人で一つのことを行う作業

*5:経験や勘に基づいた知識