こんにちは。 東京工科大学のコンピュータサイエンス学部というところの3年生をやっております（就職するなら23卒ということになります）。 宮川です。
この度、アカツキのインターンを受けましたのでその記録を残します。 ブログ執筆経験が浅くつたない文章になると思いますがご容赦下さい。
エントリーと選考
アカツキのインターンを知ったのは就活サイトがきっかけです。
プログラミングのインターンを受けたい。でも1day仕事体験とかではなく数週間にわたってやりたい。あとお給料出ると嬉しい。そんな欲張りな条件で探した結果アカツキのインターンに出会いました。 ゲーム開発のインターンということで、私はゲーム開発に興味があるので良さげと思いました。
でもUnityなんだろうな...。私はゲーム制作に興味はあるもののUnityはあまり得意ではないのです。 ですが募集要項を見てみると..... Cocos2d-x & C++！？ 私はそれに一目惚れして、アカツキのインターン選考が非常に厳しいらしいことも知らず、募集人数1人程度の「ヤバいインターン」にダメ元でエントリーしました。
────そして何故か選考に合格してしまったのです。（めちゃくちゃ嬉しかったです。）
やったこと
9月。ついに始まった人生初のインターン。 様々なオリエンテーションに出席しつつ、メンターさんと今後やることを相談しました。 そして最初に出された課題がオンボーディングも兼ねた練習問題です。
練習問題
私の配属されたプロジェクトには、開発者用メニューというものがあります。 各々の開発者の名前が登録されており、開発者が試したい機能を自分の開発者用メニューで試すことができるというものです。 ...言葉で説明するのは難しいですが、開発者の名前が書かれた「扉」がズラっと並んでいて、それぞれの「部屋」で好き勝手に機能を試せるといった感じです。
そこに自分の「扉」と「部屋」を作り、その中に「メインメニューに戻るボタン」を作るというのが今回の練習問題です。
コードを見てみると「アカツキ太郎」さんの部屋がいかにもテンプレートっぽく置いてあったので、安直にコピペして必要な箇所を変更して....。 最初は当たり前のようにやってしまいましたが、これでは駄目ですね。
今回のように簡単な問題ならまだしも、こうやってコピペする癖がついてしまうのは良くない。既存のコードをコピーする時は１行１行理解しながら写す必要があるのです。
じゃあそうしないとどうなるか？コピペして表面上問題なく動作したからといって、別の箇所に影響範囲が出ないとも限らないのです。そして、ただコピペしたコードについて「この関数はなんですか？」と聞かれても答えられないといよいよまずいのです。「おまじないです」なんて言うわけには行きません。
だからコードをちゃんと理解しながら書くことが大事なんですね。至極当然のことですが、私はこんな基礎のことまでできていなかったということです...。 巨大なプロジェクトにcommitするというのはこういうことです。
さて、何だかんだコードが完成し動作確認も済んだのでPRを発行する時が来ました。 git statusしてみると色々なファイルが変更されている。これはIDEのプロジェクトファイルっぽいし必要なんだろう。とりあえず git add -A。 結果は...当然駄目です。addする必要のあるファイルもありますが、ほとんどはaddする必要の無いファイルでした。 そう、大規模なプロジェクトにおいてはどのファイルをサーバーにアップロードするかも見極める必要があるのです。
このように、個人開発では適当にやっていたことでも、細かな配慮をもってやらなければならないので中々大変な作業でした。 ただ、やっとのことでPRが承認されたときの達成感は大きかったです。
クライアント改善課題
ここからがインターンの本番です。 私のインターン課題は「開発メンバーが喜ぶデバッグ機能を開発する」です。 これを開発者用機能の改修というタスクをもって達成します。 クライアント改善というと顧客満足度向上のような響きですが、「サーバークライアントモデル」における「クライアント」というニュアンスです。
メンターさんが事前に改善依頼を集めてくださったので、そこから1つ選び、依頼者にヒアリングを行い、そして実装するという流れです。 私が取り組んだのは、ゲームを効率的にすすめるデバッグ機能の改修でした。 デバッグ機能をONにしてもアプリ再起動によってOFFに戻ってしまうのが不便なので、最初からONにしてほしいという依頼内容です。
まずは依頼者にヒアリングを行い、依頼者の目的（なぜその機能が欲しいのか）を聞き出しました。 これは非常に重要な工程で、依頼者と実装者の間に認識のズレがあると良くない結果を招いてしまいます。 例えば、完成したものを依頼者に見せても「なんかこれじゃない...」といった反応をされてしまったり、「そういう目的なら別のアプローチがあったのに」と後から気づいてしまったり...。 このようなトラブルで手戻りをしないようにするため、依頼者から目的を聞き出すことが重要なのです。
ヒアリングの結果、他の開発メンバー（検証・運用さん等）にも確認を取る必要が出てきました。 そこで、我々のプロジェクトメンバー全員が入っているSlackチャンネルに文章を送ることになりました。 この時はまだ文章作成に2営業日費やすとは思ってもみなかったのです...。
Slackに投稿する前にメンターさんにFBをもらうことになっていたのですが、最初に作成した文章は
- 文字がびっしり
- 用語の表記ゆれがある
- 参考図が無い
という中々ひどい有様でした。 言ってしまえば見るだけで億劫になる活字の塊です。 これでも不足なく、分かりやすく説明しようと頑張ったんですけどね...。
数回のFBを受けてようやく文章と3つの参考図が完成しました。 ここで如何に最初の文章が酷かったのかを認識することになりました。 そして、自分の書く文章の悪い癖も知ることができました。
そう、私は分かりやすくて不足なく書こうとして長ったらしい文章を作ってしまいましたが、真に分かりやすい文章とは「簡潔で」「視覚的に整理されていて」「必要に応じて図で補足する」ようなものだったのです。
そしてついに300人以上のチャンネルにメッセージを投下し、なんとすぐにFBが届きました。 インターン生の私を相手にして下さったことが嬉しかったし、何よりメンターさんでも気づけなかった意見を得ることができて驚きでした。 依頼者のみが得をするのではなく、他のメンバーが損をしてしまうことも考える。 つまり、一人の主観で決めるのではなく他者の意見も取り入れる必要があるということですね。 考えてみればこれも至極当然のことですが、実際一人の意見だけ過信するとかやってしまいそうなので肝に命じておきたいです。
ヒアリング、全体への確認も終わりいよいよ方向性が決まりました。 あとは実装するだけです。
実装は割と簡単でした。 C++の専門知識がある程度要求されたので楽しかったですが、基本的には既存の仕組みを利用するものでした。 あっさりと実装も終わり、PR発行。 一回目のようなトラブルも起きず、素直に承認されました。 大分ここでのGitHubの扱いについても慣れてきていたと思います。
新規機能実装
インターンのメイン課題が終わった後は、一週間ほど別のインターンに行っていました。 祝日というのもあり、アカツキに来るのは久々でした。
メインの課題は達成しましたが、成果発表会の準備をするにはまだ時間が余っていたので、新機能の実装を体験させて頂くことになりました。
当たり前ですが、私はインターン生でプロジェクトに関する知識が浅い為、新しいことをするには多くのキャッチアップが必要になります。 しかし、インターンが始まってからずっとそうでしたが、アカツキの構造化されたドキュメントは非常に便利です。 検索機能を使えば欲しい情報は割とすぐ見つかるし、ビルド待ちの時間などには階層構造をなす項目から興味深い記事を見つけることができます。 このきっちりしたドキュメントは素晴らしいですし、今後の企業研究の際にも基準の一つとして考えたいと思いました。
新規機能の実装はモブプログラミングによって行いました。 これは、調べごとをしながら指示を出す「ナビゲーター」とナビゲーターに従ってコードを打つ「ドライバー」に分かれて共同作業をする手法です。 これは1~複数人のナビゲーターと1人のドライバーで構成されます。
一般的には一定時間でドライバーとナビゲーターを交代するようですが、インターンということでずっと私がドライバーを務めました。 Zoomの画面共有を使用しているとはいえ、ずっと誰かに見られながら作業していることになるので、始終落ち着けませんでした。 しかしモブプログラミングにはその弱点を超える数々の利点がありました。
まず、分からなかったらすぐナビゲーターに聞ける事。これによって、コーディング中にブラウザを開いて検索して...という手間がなくなります。 今回はかなり前からこのプロジェクトにいるベテランの方がナビゲーターをして下さったので、調べるどころか大体即答です。効率がえぐいです。 そしてプログラミング以外のスキルも継承できること。 例えばIDEの知らなかった機能や会社の知識など。 コーディングの片手間に知識が共有できるので便利です。
このように、モブプログラミングにはたくさんの利点がある為、いい加減誰かに見られながらの作業も克服したいなと思いました...。
モブプログラミングはPRの作成においても威力を発揮します。 （この場合はモブワークに該当しそうですね。） PRを作成している最中にコードレビューが大体できてしまうようなものですから、非常に合理的です。 また、大きな事故になりかねないような誤操作も起きにくいので安全とも言えます。
安全に作業できる環境、素晴らしいですよね。
何を得たか
今回のインターンを通して学んだこと、つまりどのようなスキルを入手したかについてまとめさせて頂きます。
コミュニケーションスキル
ヒアリングやSlackでの文章作成、そしてモブプログラミング...。 日常的な会話などに加えて上記を含め様々なコミュニケーションが要求される職業。それがエンジニアでした。 コーディングと同じくらい、もしかしたらコーディング以上に開発現場のコミュニケーションについて知ることができました。
作業を管理するスキル
インターン中は常に別画面でGoogleカレンダーを開きながら作業をしていました。 「〇〇時までにこの作業を終わらせる必要がある」という都合や、そもそも定時というものが存在するので、しっかりと作業を管理する必要がありました。 というかそうしないとやっていけません。
あとこれは私が勝手に始めたことですが行動ログというものを付けてみました。 何時にアレを初めて、何時にコレが終わったという記録を延々付けるだけのものです。 これを作ると何が良いかというと、後々振り返りをする時に役に立ちます。 また副次的にですが、「14:03 〇〇を開始」と打った後は脱線せず作業を遂行できることが多いです。
行動ログを付けていることをメンターさんに言ってみたところ、なんとメンターさんも同じようなものを作っていました。 行動ログと違うところは、一日の始まりにざっくりとした予定を考え、それを遵守できたかどうかも含めて後々振り返りをしているところでした。 私も真似しようとしましたが、如何せんインターンでやることは初めてのことだらけなので作業時間の目処がつかない...。 なので一日の始めにTODOリストを作るに留まりましたが、今後は作業時間の目処を立てることを意識していきたいです。
目的を意識するということ
これは今回のインターンにおいて最も重要な教訓です。 目的を意識することは、あらゆる仕事・作業において役に立ちます。
例えば今回私も行ったヒアリングについて。 ヒアリングで「依頼者は何故これを実現して欲しいのか？」つまり「依頼者の目的は何か？」を追求することで、課題解決に向けて共通の認識を持つことができます。
逆に依頼者の目的をよく聞かずに実装を進めてしまうとどうなってしまうか。 実装した結果「欲しかったのはこれじゃない」と言われてしまい、実装をやり直すという手戻りのコストが掛かってしまう可能性があります。
目的を意識することは最適解に近づく為の非常に有効な手段といえます。
また、目的を考えることは「あれ？今何やってるんだっけ？」と道に迷ってしまった場合にも有効です。 何の目的でこの仕事をしているのかを考えることで、目的が見つかれば作業に集中できますし、あるいは別の方法を検討することも可能です。
このように、「目的を意識すること」は私にとって万能な教訓となりました。 今後も日常的に意識していきたいと思います。
感想
今回のインターンが人生上初となりましたが、アカツキでのインターンが初で本当に良かったです。 エンジニアのインターンということで、プログラミングのスキルも当然身につきましたが、それ以上に身についたのは上に挙げたような「エンジニアに必要なスキル」の数々です。 そしてこれらのスキルの多くはポータブルスキルであり、今後の他のインターンや就活、実際に就職した後でさえ約に立ちます。
昨日メンターさんに「この枠にどのくらいエントリーがあったんですか？」と勇気を出して聞いてみたところ、腰を抜かしました（メンターさんも具体的な数は把握していませんでしたが、恐らく私にとっては信じられない数です）。 私は悪魔のような技術力をもった人材ではありません。 では何故採用してくれたのか聞いたところ、採用側とエントリーした側の「こうなりたい」というビジョンが一致したからと教えて下さいました。
このような理由で採用して下さったことがとても嬉しかったです。 同時に、今後就活をする上でも「私が将来どうなりたいか」というビジョンを大切にしたいと思いました。 これも「目的」ですね。
まとめると、非常に実践的なスキルも身につく、かつ将来を見据えたものの考え方まで身についてしまう、やはり「ヤバいインターン」でした。 毎(営業)日新しい発見ばかりでとっても楽しかったです。
メンターの伊藤さん、そしてインターン生の私を暖かく受け入れて下さったアカツキの皆様、本当に有り難うございました！！
