業務内容について

前職ではどのようなことをしていましたか?

前職はビジネス帳票を扱う印刷会社で、顧客企業から頂いたデータを、どのように加工して、紙などの印刷物のどこに出力するかを示す仕様書を書くのが主な業務でした。また、工場の印刷物をデータセンターから確認できるようなシステムを半分勝手に作ったりしていました。

入社して1年半程度経ってから、もともとやりたかったゲーム開発に挑戦したいと思い転職を決意しました。
Aimingは当時よく遊んでいた『ブラウザ三国志』を制作したメンバーがいる会社という記事を読んで、興味を持ち志望しました。

今のお仕事内容を教えてください!

主に、『ドラゴンクエストタクト』のバックエンドAPIの設計や実装を行っています。また、プロジェクトのやりたいことと追加したい機能のヒアリングを定期的に行い、最善のゴールへと向かう認識のすりあわせなどもしています。
また、他のプロジェクトとの知見共有にも積極的に取り組んでおり、日々新しい発見があります。開発相談では、実装は担当しませんが、最適な技術スタックの選定や実装上の注意点など、これまでの経験に基づいたアドバイスを提供しています。

技術スペシャリストについて

どうしたらスペシャリストになれるんですか?

特に意識しているわけではありませんが、スペシャリストとして重要な要素だと考えていることがあります。それは、自分の特性を理解し、それを活かすということです。例えば、学習スタイル一つとっても、先に答えを知りたいタイプなのか、体系的に学びたいタイプなのかなど、人それぞれです。このような自分の特性を把握することで、より効率的にスキルアップできると思っています。
自分の場合は、まず動くものを作って、難しいことは後で調べて解決する形が一番合っています。これは他のパターンに優劣があるという話ではなく、単に自分にとって最も適切な方法であるかという話です。

プロダクトへの興味も、開発者にとって重要な要素だと考えています。。開発するゲームに強い興味を持つことでモチベーションが向上し、より良い成果が出るタイプの人もいますし、どんなジャンルでも常に安定したパフォーマンスを出す人もいます。もちろんどちらが良いという話ではなく、チームには様々なタイプのメンバーがバランスよくいるのが理想的かと思います。ちなみに自分は前者です。

他には、自分が実装したコードは、書いた時点で、すべての行においてなぜそう書いたかを説明できることです。
完全に理解しているという意味ではなく、どうしてそう書いたかさえ説明できればOKくらいの温度感です。例えば、「参考にした公式リファレンスのサンプルコードを真似して書いた」でもいいし、「既存のコードのままだと可読性が低いので新しい視点で書き直した」でもいいです。
とにかく、同じタイミングで、同じ要件で、自身にインプットした場合、同じアウトプットが得られる再現性の高いコードが、少なくとも自分の中には必要だと考えています。他者と一致している必要はありませんが、チーム内である程度一致していると、より高いチームパワーを期待できます。

また、全てにおいて説明できるようになっていると、あとになってコードを見返した際に、当時の気持ちを思い出すことができます。
完全に記憶する必要はなく、何を考えて書いていたのかを何処かに書いておくのが良いと思っており、slackの個人窓に思考ログを書き残す方法をよくとっています。簡単に書いたArchitecture Decision Record（ADR）のようなものですね。

当然、当時の判断が実はあまり良くない選択であったこともありますが、なぜその選択に至ったかを遡ることができるので、今後似たような過ちを起こしにくくなります。

スペシャリストの大変なところと面白さを感じるところを教えてください

スペシャリストを意識して活動したような記憶はあまりないので回答が難しいですね。
この会社に入社した当時、上司から「日々学習しないとついてこれなくなるけど、覚悟はある?」というようなことを言われ、若干の不安や恐怖を感じたのを覚えています。(この方には開発者としての考え方や振る舞いなど、多くのことを教えてもらい、今も尊敬しています)

学習というと義務的な印象を受けがちですが、自身の興味のあるものだとすんなり受け入れられます。プライベートなどで作りたいものが決まっていて、それに必要な技術スタックであれば喜んで調べたり動かしたりすることができます。これは面白さを感じるところといえます。一方で、業務に必要なものの、興味のない技術スタックを吸収しないといけないときは結構ストレスですね。
ただ、普段からいろんな社員とコミュニケーションをとっているので、その技術スタックに興味のある社員にお願いしたり、協力したりして進めています。

最近経験した技術的に大変だったものはありますか?

技術的に大変だったというか、貴重な経験をしたものならあります。
ブログとしても執筆したのですが、うるう年バグですね。
日付に関する特殊な実装は一切していないのですが、2/29のメンテ開けにごく一部でエラーが発生し始め、翌日の3/1には減るどころか徐々にそのエラー範囲が広がっていく、複雑なものが絡み合ってバグが発生したものがありました。
急いで調査をして原因にたどり着けたときはとても達成感がありましたね。
詳細は是非ブログを読んでいただければと思いますが、Rubyコミュニティでの情報提供のおかげで解決の糸口が掴めました。

業務でAIは使用しますか?

Github Copilot AgentやJetbrains Junieなどのコーディングエージェントをいくつか使用しています。
特に、コンテキストの小さい、状態に依存しない関数を実装するときには重宝しています。
Devinなどの自立型を使っているプロジェクトもあるようです。

コーディングエージェントを含む、様々な生成ツールが普及し、アイデアを形にするまでのスピードが劇的に速くなっている一方で、置いていかれないようにという焦燥感が少なからずあります。
作りたいものが明確にあり、それを実際にアウトプットできる人ほど、この恩恵を強く実感できる時代だと感じています。

Aimingの好きなところについて

Aimingの推しポイントを教えてください!

非常にフラットな環境で、技術やゲームに関して意見を言ったり聞いたりする機会が多い点がとても良いと思っています。
構造化された上下関係のようなものはほとんどなく、簡単に言えば社会人サークルのようなイメージでしょうか。
自分が入社した当時から上下の壁はなく、とにかく言ってみることができる環境が整っているのが魅力だと思っています。新卒や若手社員だと、どうしても経験や技術スタックが少ないため表面的な考えになることは多いですが、その考えについて、こう考えると良いとかアドバイスを気軽に受けられ、その考えの補正をまたさらにアウトプットすることによって改善されていくプロセスが開発の現場では自然にできています。
組織としてとてもフラットなため、社内外で付き合いのある社員が多いです。元社員と一緒にオンラインゲームをプレイしたり脱出ゲームに行ったりもしています。

今後の目標

これからの目標を教えてください!

最近機械学習系の話題が尽きませんが、知識的に全然追いついていません。一応動くものはいくつか作ったのですが、学習に使うパラメータの値が妥当かどうか、事前にどう加工すべきか、この設定値は何？......などわからないことがたくさんあります。
よりまともに動くものを作るためには、内部的にどう動いているかを知る必要があります。スクラッチから実装して学ぶ機械学習本があったはずなので、手を動かしながら学んでいきたいです。

ゲーム開発の視点では、機能提案をもっと積極的に行いたいと思っています。
年に数回、「こういうのやりたいね〜」と話す機会はあるのですが、ほとんどの場合そこで終わってしまい、別のアプローチも必要だなと考えるようになりました。例えば「こういう風に動く新コンテンツ、面白くないですか？」みたいな動くものを見せられると、より説得力が増します。
ただ、自分はバックエンド側のスキルセットが多く、フロント(Aimingにおいては主にUnityを使って開発する)を実装する根気とセンスが絶望的にないので、やりたいなあ〜と思ってるだけです。
(黒い画面で謎のコマンドを叩くと表示が切り替わるのを見せて、「ほら、面白いでしょう？」と説得するのはなかなかむずかしそうです)

一緒に働きたい人について

どんな方と一緒に働きたいですか?

洗練された考え方を持っている人と是非一緒に働きたいです。いろいろなものを作って様々な経験をされている方は、意思決定をする上での危険性や妥当性、分岐を全部把握したうえで、適切な選択をする確固たる意思を持っており、魅力的です。
そういった方と一緒に切磋琢磨していきたいですね。