エンジニアインターンとして二週間アカツキで就業したstalagmiteさんの体験記をお届けします。「自分の理想とするエンジニア」を意識して働いたインターン、どのような経験をされたのでしょうか。その様子をレポートいただきます。
自己紹介
この度アカツキのもとで内定後インターンをさせていただきました。その時のことについて、主に自分が何を考えながら動いたかを書きたいと思います。 とても自分語りが多くなるかもしれませんが、多分アカツキの社風的に大丈夫だと踏みました。
所属当初の背景
大学では情報系の専攻をしていた。
大学での研究はOpenStreetMapのことについてやってる。
ゲーム製作サークルに所属していて、学祭でゲームの展示をしたりしていた。
プログラミング経験
C++,Haskell,C#,Unity,GLSL
隙間時間で調べてること
数学(圏論、集合論、確率論)
シェーダ
VR
普段やっていること
DxLibやOpenSiv3Dを触りつつゲームの部品を作ったりモックを考えたりしている
（しかし完成したものはないという地獄）
所属時の話と自分語り
大学でプログラムの勉強をしていると、プログラマーというのは「厳密に仕様を決めて高い水準で要求に答える」みたいな、専門家としてのSE像があった。
ただ、もともと大雑把な性格で緻密なことが苦手な自分は、「そういうイメージのプログラマになれるのか」という漠然とした不安があった。（もちろん、ある程度のコード力はあると自負はしているけれども、その専門家としての価値と自分の性格って合わないような気がしていた)
就職活動をしている中の、そんな漠然とした不安のを抱えているときに、アカツキとの面談や、会社の説明を聞く中で、
「うちで働いているエンジニアはそれぞれ違う部分で価値を出し働いている。」
「インフラのことについての専門性で貢献しているエンジニアもいれば、プランナーなどの別職と連携をとったり、自分で案を出しつつ実装までするエンジニアもいる」
「全員が自分で考えていて、受け身なだけの人はいない」
という社風に興味をひかれ、アカツキの入社を希望した。
インターンの目標
インターン初日、メンターの方に言われたのは、
「このインターンでの目標を決めましょう」
という抽象的なものだった。
働き方も、目指すものも、全部自分で決めて良い。
具体的な課題をひたすら潰すもよし、実際のプロダクトの小さい機能を設計から作ってもよし、「 インターンで僕が何か良いものが得られたと感じられる、それがこのインターンの意義です」と説明してくださった。
僕は、大手のゲーム業界でたまに、規模は大きいのにゲーム性そのものがイマイチなゲームというのがあるのが嫌だった。
これは入社前から持っていた偏見であるが、「イマイチになってしまうのは、プランナーが仕様を考えてエンジニアが実装して、それをプランナーに戻してまたフィードバックして、というサイクルが重いのが原因なんじゃないか」と思っていた。だから、僕はこのインターンの目標として
「プランナーの考えている抽象度の高い案をとっととモックを作って実現して改善する、というプロセスをぶん回すエンジニアになりたいです」
と答えた。
一つ重大な問題がある。僕は自分の「ゲームエンジニア」としての像をここに置いた。この作業はいわゆる「ヒアリングから問題点を聞き出し解決策に落とし込む」というまさにSEとしての分野であり、
僕は大学でこの内容の授業の単位を落としているのである。
ついでに言うともともと僕はコミュ障であって、就活中にも自己嫌悪で大変なことになっていたほどだ。もう不安しかない
最初の1週間
目標を決めた後、ソーシャルゲームの開発（クライアント）チームに配属された。このチームでは、プランナーエンジニア問わず、Trelloに
「何か改善すべき問題」
「さらにゲームを面白くするためのコンテンツ案」
「UIUXの改善案」
など、色々な抽象段階の案を共有することができることを教えてもらった。
ここから自分が面白そうな案、実現できそうな案を拾い、話を聞きに行く。
プランナーがしたいことを、現在実装がどうなっているかを把握できるエンジニアが聞き、仮設計を考え形にする
これは結構自分がやりたい立ち回りに近いものだと思えた。
ここで色々な意見を聞いていく中で、「ゲーム内のキャラクターの編成を組むときの、画面遷移を伴う操作が煩雑であり、それを改善したい」という意見をプランナーSさんに頂き、これは手を付ける影響も少なくて済みそうだし、いい感じに抽象的だったので、担当することにした。
幸い、個人的にプログラムのバイトの経験があったので、さほど時間を取られずに自力で規模の大きいコードを読みつつ、既存コード内のでのゲームデータの扱い方や簡単な画面遷移の処理を頭に入れ、最初の1週間のほとんどをヒアリングに使った。
ここで最初の山を迎えた。最初の実装、設計案を考えたときに、「これは難しい。既存の画面遷移の中にどうUIUXをいじっても、複雑な操作が発生してしまい、意味がなくなってしまう」という結論になってしまった。このことをプランナーSさんに相談しにいくと、
「もっと根本から考えてみたほうが良い。本当は、編成なんて１タップでできるんじゃないか？それが実現できたら、最も便利なんじゃないか？」
僕は仕事として、与えられた役割としてプログラマを引き受ける時に、どうしても今確実にできることベースで物事を考えてしまう癖がある。それは情報系プログラマ、エンジニアとして大事な要素ではあるが、何かを解決したいときの思考方法ではない。なまじコードが読めるから、設計案が頭に浮かぶから、わかる範囲で片付けようとしてしまっていた。
なので僕は「1タップで自動編成」を一番上に置いて、それにもっとも近づくように、要求を分析することにした。これは、他のエンジニアに相談すると、「完全に自動編成するためには、キャラごとに編成する際の評価値を計算する必要があるが、その厳密な計算は難しい」
ということになってしまったのだが、
「他ユーザの編成を分析してそれを元に評価値を作れば、厳密な計算はいらないし、信頼性も高いのではないか」
という案が浮かび、既存の資産も活かせるということで、落とし所として、
「同レベル帯で成績の良い他ユーザの編成(=クリアログ)を自分の手持ちキャラなるべく似せて自動編成できる機能を作る」
とういことになった。(プランナーとエンジニアを行ったり来たりして解決案をだすというムーブ、これがしたかった)
これが決まった後、既存のコードを利用した設計と実装案、ドキュメントを書くことができた。
ここまで来るのに二度提案を練り直した。
この時点のドキュメントで
関数の影響範囲
この提案で操作が便利になるユーザー層の想定
までは書くことができた。ここまでは、いいペースだったと思う。
次の1週間
手をつけた課題についてドキュメントを書き、仮のコードも書いて、最初のプルリクエストを飛ばした。
当初の予想では、もっと議論が活発になると予想していた。というのも、僕が担当したのはロジックで、仮提案であり、現状のコードや設計により詳しい人にコメントがもらえるだろうと予測していた。ロジックだけでなく、本実装する際はUIUXの話も絡んでくるだろうと思っていたので、正直なところ「あれ、ウケが悪いな」と思った。
この時、元々の提案を出してくれたプランナーSさんが別の部署に行ってしまい、次にやることも含めて自分で考える必要が出てきて、３日ほど右往左往してしまった。
その後なんとか僕は、「現時点での提案の「自動編成の精度」が、どの程度良いのか分析できていないから、皆現在の提案の進捗が想像が難しいんだ」、と考えた。それは部分的には真で、自分でも「じゃあこの自動編成を使うと、どう便利になるの？具体的にどのユーザがどのように便利になるの?」という風に疑問に思っていた。なので次は、
「既存のユーザの分析」
「この提案で便利になるユーザとはどのような状況の人間か」
を調べることにした。
最後の1週間
mysqlをいじってアプリで使われているデータから、ユーザの手持ちキャラ、自動編成の通してみた結果を比較したデータを用意し、分析した。具体的には、自動編成後の編成のスコアの分布ごとに、
「編成結果のスコアがここのユーザたちは、ゲーム内ではこのコンテンツをするためにこの操作をすると考えられる」
「編成結果の低いここのユーザ層は、そもそもここのコンテンツを触らないな。より良いコンテンツへの推奨はUIUXでこう解決できるな」
というところを分析し、ドキュメント化した。
また、このデータを他のエンジニアが検証できるよう、デバッグメニューの実装し、プルリクエストを飛ばした。
これによって、2回目のコメントもらい、時間的にも区切り的にもちょうど良いので本インターンでの作業を終了した。
総評
一応、ヒアリング、提案、実装、分析、デバッグメニューで他者に検証してもらうフロー、今後の展望のドキュメント、までを、いろんな人に話を聴きながら作り上げることができたので、最初の目標である、
「プランナーの考えている抽象度の高い案をとっととモックを作って実現して改善する、というプロセスをぶん回すエンジニアになりたいです」
という動きはできたのではないかと思う。
ただ反省点として、
「プランナーSさんがいなくなったタイミングで、この提案の実現の進路を考える人が自分以外にいなくなったことに気づかず、失速していた」
というのがあげられる。
本来これにすぐに気づき、次に決めるべき内容、この提案について本腰を入れて一緒に考えてくれる(自分以外の)人間を巻き込む必要があった。 (ずっとメンターにも相談していたのだが,いつも「次どうすればいいですかね」と聞いてしまった。僕が考えるべきだったことなのに)
確かに、僕はプルリクを飛ばしてエンジニアとしてコードを書いてドキュメントを書いて分析もできたが、じゃあこれが何かの役にたったのかというと、正直よくわからない。なぜなら
提案の進路、実現の持っていき方を考えていなかった
or
それを考えてくれる人間の確保が必要なことに気づかなかった
からだ。
「プランナーの考えている抽象度の高い案をとっととモックを作って実現して改善する、というプロセスをぶん回すエンジニア」
のそれっぽい動きはできたけれども、そういう立ち回りののオリジナルな価値を生み出せたかというと、それは少なかったように思う。
そもそも僕がやりたいこの動きって、「プランナー<->エンジニア間で速度の速いフィードバックをして、抽象から具体に落とし込む」というのをやりたかったのだ。
しかしそもそも、
「抽象的な目標、提案をチームの内側から通すって時は、具体的な設計、方針が決まるまでその提案の立ち位置、自分の立ち位置、他人の立ち位置をよく把握しなければならない」
、そうでなければ、空中分解しかねないという基本を、僕は知っておくべきだった。
これはものを考えるプランナーだけでなく、何かを作るという当事者全員が意識すべきことだったことに気づいた。
三週間のインターンなので、大きい規模を実現することはできないという前提があったなかで、最大限のことをしようと覚悟をしたはずなのに、その覚悟がまだ足りなかったように思う。
インターンが終わったらまた日常生活に戻る。そこには、大学でも、個人ゲーム制作チームでも、やり残していることがある。
来年アカツキに入社するまでに、それらにケリをつけて成長して出直そうと思った。
