「やりたい」を形に!基盤チーム

リーダーのこれまでとこれからの目標

ゲームの裏側を支える基盤開発チームのエンジニアリーダーへインタビュー!
20年のゲーム業界キャリアはミドルウェア開発から始まり、KPIツールや社内評価システムまで様々な基盤を整備しています。プロダクト成功のための姿勢、今後の目標まで詳しくお話します。

話者紹介

  • K.H

    2011年中途入社 。事業支援部 基盤チームのチームリーダー兼エンジニア。Aiming入社前から様々な言語に触れており、特定の技術領域に縛られない広範な知識を持つ。現在はチームリーダーとして自ら開発を手掛けつつ、他部署との要件ヒアリングからチームメンバーの技術サポートまで幅広く牽引している。

  • R.T

    2023年中途入社。事業支援部 基盤チーム所属のWebエンジニア。ゲームの基盤開発から社内システム開発まで幅広く担当。Ruby on Railsを中心としつつ、NuxtやGoなど目的に応じた様々な技術に触れながら、フルスタックな開発ができるよう日々挑戦している。

1.自己紹介

R.T

では、インタビューということで自己紹介からお願いします。

K.H

はい。面接を受ける気分です、逆の立場ですね(笑)
基盤開発チームのチームリーダーをやっています。よろしくお願いします。マネージャーもしてますが、エンジニアとしてのキャリアの方が長いです。ゲーム業界は20年程度です。
ゲーム業界と言っても最初は、ゲーム開発が全くなかったわけではないですが、メインとしてゲームのミドルウェアやライブラリ等、今でいう、基盤開発に繋がるようなものを開発する会社に在籍していました。

R.T

具体的にどういった開発を担当されていたんでしょうか?

K.H

ミドルウェアのパッケージ化、マニュアル作成、バージョン管理、リリース、コンサルティング、納品を繰り返し行っていました。プロジェクトマネジメントも担当していました。
開発でいうと、ウェブアプリケーションやゲームのライブラリ、オンラインゲームサービスのサーバー側の開発を担当しました。当時流行っていたアバターゲームサービスのようなものですね。

R.T

当時はアバターサービスが流行ってたんですか?

K.H

流行ってましたね。自分そっくりのアバターを作って、仮想空間で誰かと交流するwebサービスです。
15年くらい前の話ですかね(笑)
当時の営業先の担当者や社員と、Aiming入社後に同じプロジェクトで関わることもあり、ゲーム業界の狭さを実感しました。Aimingで再会するとは思っていなかった方々との関わりも多かったですね。

R.T

ゲーム業界は狭いといろんな記事で見ますけど、やっぱり今でも繋がってる方は多いですか?

K.H

多いと思いますね、他社に行った人と再会することとか結構あると思います。

R.T

その後、2010年頃にAimingの前身の会社に在籍されたんでしょうか。

K.H

はい。ミドルウェア等を開発していた会社の後、社長の椎葉が立ち上げたONE-UPという会社に移りました。
当時ONE-UPはブラウザ三国志がヒットした直後で、開発規模を拡大するタイミングでした。僕が入ったのは丁度その頃で、ミドルウェア開発をしていた会社から10人程度一緒に入社しました。

2.技術キャリアの変遷

R.T

元々ミドルウェアやライブラリ等を開発をされていたとのことですが、今はRailsでの開発をメインにされていると思います。Railsやweb系の開発はONE-UP入社後に経験されたんですか?

K.H

入社より前から、RailsでのWebサービス開発は行っていました。元々Webサービスを作ることに興味があり、個人的にゲームの攻略支援ツールのようなものをRailsで作成し、一般公開していました。当時は複数人のユーザーがいましたね。このWebサービスのソースコードを、最初のミドルウェア開発会社に応募する際に提出しました。当時のRailsは、Ruby on Rails 1.0とRuby 1.8くらいで書いていたと思います。

R.T

そんなに古くですか。1.0の時代から…。

K.H

そうですね。1.0の時に公開したので。
webサービスはずっとやってますね。Ruby on Rails歴は20年くらいあると思います。
1社目に入る際には言語では特にRubyを使用していましたが、入社後の仕事はPythonで作ったり、ゲームのプログラムはCやC++を使っており、言語にこだわらずに仕事をしていました。それ以前のフリーランスでは、PHPやJava、Perlも使ってましたね。あと、基本的にインフラもやっていて、コードは全部Cで、Apacheのモジュールも書いたりしていました。とにかく色々な言語で色々なことをしていましたね。

R.T

今も、何か開発する際はRailsに限らず目的に合わせて使用言語を変えたりするじゃないですか。その辺は、これまでの経験則として開発目的に合わせて言語を選ぶという考えがあるのかなと、お話を聞いて思いました。

K.H

まあ、そうですね。状況に合わせてって感じですかね。

R.T

ONE-UPではどんなことをされていたんですか?

K.H

最初はサーバーエンジニアが僕と合わせて数人しか在籍しておらず、開発環境のインフラ等を全部作ったりしていました。何にでも取り組む人たちばかりだったので、大きな区切りとかないですが、インフラもやっていました。Gitを導入したり、Tracというものを使っていて、運営・管理をやっていました。当時はGitHubは使用していなかったので、ローカルのGitサーバーを管理していましたね。

また、公式サイトや、ブラウザゲームのログインや決済含めたプラットフォームなど、Web 関連のサービスの作成も行っていました。

R.T

担当されていたことは今より、もっと広い基盤みたいな感じですね。

K.H

そうですね。社員も少なかったので、このときは全体を見れたんです。あとは今みたいにやり方が確立しておらず、とにかく必要なものから手をつける、という進め方でした。会社が拡大する初期の頃でしたので、何もないところから、道を作ることをひたすらやっていました。

R.T

決済プラットフォームの話が出たと思いますが、これは今開発している LINK(※社内開発の認証決済ミドルウェア)とは別のものでしょうか?

K.H

LINKも長く開発していますが、LINKじゃないです。
ONE-UPに所属していた時は、ゲームの歴史としてブラウザゲームが全盛期の時代でした。2010年代の頃ですね。どこの会社もゲームといえばブラウザゲームでした。Facebookでゲームが流行って、mixiでゲームが流行って。各社ブラウザゲームのプラットフォームを作っていた時期なんです。
その頃にONE-UPではブラウザ三国志というゲームを作っており、自社で運営するためのプラットフォームのニーズがあって、そちらの開発を担当しました。

R.T

ブラウザ三国志を自社で運営するプラットフォーム…。

K.H

今みたいにストア等がないため、裏側に自社でアイテムを用意する必要があり、決済の部分も繋いでおかないといけないってことですね。
そうそう。ブラウザ三国志は色々なところで展開をしていて、ありとあらゆる場所でワールドを作る感じの運営方針でして。そこで自社版として、MooG Gamesというサービスを作りました。その中で、認証と、ポイントを買ってゲーム内で決済する仕組みを作りました。この時は、3人くらいで僕と今マネージャーのCさんと相当苦労しながらつくりました。リリース前は徹夜したりとか……。今から思えば分からないことばかりでしたし、いろんなところに迷惑かけたなと思ってます。

3.Aiming入社後の新たなスタート

R.T

Aiming入社前のお話を伺ってきましたが、入社後についても伺いたく思います。

K.H

Aiming入社後すぐに何か新しいことに取り掛かったというよりは、Aimingの基盤を作ったり、ONE-UP時代に作成していたツールで新しいバージョンのものが欲しいという要望がありました。
その先で、Aiming Smartict という、今でいうIDシステムを作成しました。もう存在していませんが、引継ぎのときにはIDを使ってログインし、そのアカウントを使ってスマホで遊べる仕組みです。
この頃は、いわゆるガラケーのアプリから、スマートフォンのアプリケーションへの移行時期だったんですよね。ガラケーのころは、端末情報でログインができていた時代がありまして。

R.T

端末情報?

K.H

ガラケーって、型番というか個々にIDが振られてるわけです。当時、iモードとかなんですけど、iモード知らないですよね。
個人を認証する時に、iモードのID等、各社のIDを用いる状態で、そのIDさえあればOKな時代があったんですよ。今だと考えられませんが。
その時代があり、スマホに変わったときにログインについてどういうルールにするか、という話になりまして。最初ブラウザゲームと同じようにメールとパスワードを用いたログインを必須にしたら、椎葉にとても怒られました。そのタイミングでログイン処理とかありえないでしょうと。ゲームの体験と自分の作っているものがリンクしている自覚が足りていなかったと思います。
その後、どうすべきかを研究をしました。いわゆるゲームをスタートするときに、ゲームスタートボタンをポチッと押すだけで始められる。そのあと引き継ぎが必要だったら、パスワードとユーザーID等でログインする方式を採用しました。当時は各社試行錯誤をしていた時期で、ログインを絶対に必須とするタイトルも実際のところ結構ありましたね。

R.T

なるほど。本当にいろんなサービスを作っては試して、リリースしてみたいな感じなんですね。

K.H

そうですね。今、完全に影も形も残ってないものがありますが、残ってるものでいうと、Aimingではmonolithという、各プロジェクトのKPIを見るためのツールがありますが、実はこれは3代目くらいです。

R.T

今社内で使用しているツールで基盤チームが開発したもので一番長いサービスはなんでしょうか?

K.H

改修がたまに入ってますが、Aimingの査定で使用している360度評価システムですね。
あれは最初に作成してから12年くらい経っていますね。

R.T

講演会等で聞く基盤チームは、ゲーム開発チームの中から出来上がったりすることをよく聞きます。Aimingの基盤チームも、もちろんゲームの基盤作ったり課金周りとか作っていますが、社内評価システム等にも携わってるのは不思議だと思っていました。

K.H

そうですね。講演などで聞く基盤チームのイメージとAimingの基盤チームは少し違うかもしれません。今の基盤チームでは課金系はSDKの形で対応していますが、他のゲーム本体のミドルウェアはあまりやっておらず、Unityなどのトレンドやタイトルごとのニーズがすぐ変わるので、僕らがやる意義はあまり強く感じていません。ただ、社内のビジネスモデルや社内事情に基づいた、僕らでしか作れないものはしっかり作っています。Aimingはオンラインゲームの会社です。オンラインで何かすること、ネットワークに関わること、そしてWebのことをきちんと担当するチームは重要ですから、基盤は外してはいけないと考えています。

R.T

K.Hさんはサービスツール等を作成されていることがメインだと思いますが、ゲーム開発も担当されていますよね?

K.H

そうですね、いくつかのプロジェクトでは開発側に回ってました。あるプロジェクトでは、プロトコル設計とゲームのAPIの実装を担当していました。プロトコル設計ではプロトコルジェネレーターを用いて対応していました。例えば今だと Protocol Buffers や OpenAPI などを使って、仕様からクライアントとサーバーのコードを生成したりすることがあると思いますが、その部分のルールを決めて、そのルールからコードを生成する部分のジェネレーターを自作したりしました。

また、大きな「反省」が残っているプロジェクトがあります。 かなり昔ですが、Web開発の流儀を開発に持ち込もうとして、進め方やスケジュール管理、見積もりといった「プロセス」にこだわりすぎてしまったんです。しかし作り方は綺麗でも、肝心の「中身」を作る力が足りなかった。この時の失敗は現在の進め方にも影響を与えていますね。

R.T

やり方が良いことと成功するかは別の話だと。

4.エンジニアキャリアとマネジメント視点

R.T

K.Hさんはご自身で作業もしつつ、マネジメントもする、プレイングマネージャーだと思いますが、モノづくりに対して、エンジニア視点とマネージャー視点が混ざってるというか。切り離して考えていないのかなと感じました。

K.H

僕がエンジニアとしてプロダクトを扱う上でマネジメントの観点があるのは、20代前半で『飯が食えない』ということを学んだ経験があるからです。就職活動に失敗し、Webでプログラムを書いて生計を立てようとしていた頃、自分の技術をどうお金に換えるか、どうやってお金が発生するかを考え続けた時期がありました。

学生時代からずっとそうですが、技術だけを突き詰められたことがないんです。一つのことを突き詰めるタイプではなく、何にしても良くて上位には行けてもそれ以上は難しい。学生時代にゲームを作った時も、プログラム本体以外を全部やっていました。スコアアタックのサーバー、Web管理、納品、お金の管理、マップのレベルデザインなど、プログラム以外のあらゆることをやっていました。

ものを作るのは好きでしたし、プログラムも好きで作っていましたが、ゲームのプログラムを書くことにこだわるのかと言われると別問題で。プロジェクトとして上手くいくようにひたすら動くということをしていました。それが結局、今でも似たような感じです。今は専門の人がいますが、自分が関わっている部分で、ゲームが上手く完成できるように『できることは全部やる』。この先が、プロダクトに対してコードを書く以外が見える、ということだと思っています。

R.T

普段K.Hさんと一緒に働いてるからこそ、かなりしっくりきました。
開発の中でレビューなど色々してもらっていますが、指摘の内容は、大きい規模で言うと役に立つのかというプロダクトの話で、小さい話になると他の人から見て整理されてるとか今後動かしやすいか等です。それが先ほどの話に関わってくるのかなと思いました。

それではK.Hさんの現在の業務内容について伺っていきたいと思います。現在の業務内容について教えてください。

K.H

事業支援部のミッションは「各プロジェクト・部門が担当業務での価値創出に集中できるよう、様々なサービス提供やサポートを通じて、業務を支援すること」です 。その中でも基盤チームでは、ゲーム開発の現場からバックオフィスまで多くの方々の業務を支援する、システムの開発・運営を行っています。特に重要と考えているものは、ゲーム開発に必要なものを作ることですね。開発期間を短くしたり、開発時のストレスを減らしたり、という点はきわめて重要だと思っています。

またゲーム体験に直接関わるものでは、『CARAVAN STORIES マスターズサイト』のようなWebサービスも担当しています。また、AI関連のように研究が必要な分野などがあれば、積極的に関わっていきたいと考えています。
また試行錯誤が必要な開発も進めていきたいですね。工数のかからないちょっとしたプロトタイプなどは、隙間時間を利用して作っていきたいと思っています。

R.T

依頼もあればこちら(基盤チーム)から提案することもありますよね?

K.H

はい。現時点では他部署からの依頼が多い状況です。他のチームの事情や会社の方針等も考慮して内容を検討しています。要望に応えるだけではなく、その背景にあるマーケティング戦略や全体像に合わせたものを作るように意識しています。

5.リーダーとして意識していること

R.T

チームのリーダーとして基盤チームに対してどういうことを考えられてますか?チームの人に求めていることが明確になってきたのかな?と感じる場面があって、具体的な例をあげると、なんでこういうツールを開発するのか、何故開発する必要があるのかの説明が増えた気がしています。

K.H

リーダーとしてどうあるべきかについては、まだ全然できていないと感じています。この分野は苦手で、自分でもできているとは思っていません。

初期は今ほど自分に権限がなく、チームメンバーも全員年齢が近くて、良く言えばノリで、言い換えれば個々が頑張ればなんとかなるという雰囲気でした。しかし、今は状況が全く違います。
今では、僕はチームの中で年齢が離れていて、かつ自分が管理者です。僕がやりすぎるとあまりにトップダウンになってしまい、『はい、わかりました!』となってしまうのがすごく嫌なんです。僕は、そういう組織ではなく、やりたいことをやれる組織が良いと思っています。ただ、どうしたら良いかという部分までまだ明確な形になっていないので、まだまだこれからだと感じています。

また、会社の規模が大きくなり、コンプライアンスなども考慮する必要があるため、10年前にできたことが今はできません。例えば、簡単に外部のWebツールを作ろう、といったこともできなくなっています。今後は、チームの雰囲気や、意見を言い合える環境をどう作るか、そして1on1などを通じて、このチームをどうしたいのかをもっと話していく必要があると考えています。

トップダウンは安心感があるかもしれませんが、上からの指示だけをこなしていても面白くないですし、良い発想も生まれません。自分で考えるタイミングがなくなり、『言われた通りにやる』だけで成立している状態は良くないと考えています。

R.T

それに関連してですが、今後基盤チームの人数が増えたらこんなことやりたいとかありますか?

K.H

そうですね、変なものを作りたいですね。一見無駄に見えそうな、ちょっと変わったもの。そこからアイディアの種になりそうなものとか、20%ルールみたいなものを作りたいです。この時間は何をしてもいいんだよ、という時間ですね。新しい技術を作る・使う、新しいアイディアを作るとか、やってみたいことを実現することが力の源だと思っているので、それができる環境を作りたいです。基盤チームはゲームっぽくない物を作ることが多いと思うけど、Aimingはゲーム会社なんだし、面白いものを作れた方がいいじゃないですか。

R.T

自分から進んで何かに取り組んでいる人に優先して依頼がいくというか。趣味でAIやってる、ゲーム開発してるという人には、そういった本人が興味のあるタスクが振られると思っていて、自分の面白いと思っているものに進んで取り組むのは大事だなと思っています。

K.H

そうですね。新しいことややりたいことは、この仕事が面白いとアピールすることが大切です。

6.最後に

R.T

一緒に働きたい人はどんな人ですか?

K.H

自分がどんなものを作りたいとか、そういったアイディアを持っている人ですね。技術ももちろんそうですが、自分で作りたいものがある、そして、それを作る行動をしている、ということが大事です。熱量があって、行動できている人。会社としてもそういう人を積極的に採用しています。

ゲームでなくても、Webサービスでなくてもいいです。作ったものがゲームであれば、事業部側で採用するという可能性もあると思いますが。
基盤チームとしてもう少し踏み込むと、ゲームの裏側に興味が持てる人。どうやって動いているのかを考えられる人というか。

R.T

基盤開発もゲームの裏側ですもんね。

K.H

そうです。裏側だけでなくゲームの管理ツールとか、ユーザーが直接使うサービスなど、ゲーム体験に直接関わるツール開発をすることも多いので、ゲームの本体の仕事が一度できるととても解像度が上がるのでいいとは思います。
一方で、基盤チームは必ずしもゲーム制作経験そのものを重視してはいないです。ゲームの作り方とゲームの裏側を作るのは全然違うので。

R.T

読者へのメッセージ、最後に一言お願いします。

K.H

ゲーム制作に関わる分野は、全体で見るとゲームそのもの以外にも色々あります。ゲームに関わりたいけどゲーム本体は作ったことがないという人に対して、ゲームの裏側から、あるいはゲームのツールを作るという形でも関われる、ということを伝えたいです。
基盤チームはゲーム制作未経験から関わり始めたメンバーが多いチームです。しかし、それでいて実は様々なゲームタイトルに関わっていき、貢献できるチームになっています。
それだけでなく、一見変なものや新しい技術を使ったプロダクトへの挑戦をどんどん形にすることを歓迎しています。
あなたの好奇心やアイディアを、ぜひゲーム開発の現場で形にしてください。一緒にゲームの裏側から、新しい面白さに挑戦してみませんか。

編集後記

R.T

実は、K.Hさんは僕がAimingに入社を決めたきっかけの方でもあり、今回1対1で様々なエピソードを聞けてとてもワクワクしました。K.Hさん個人のエンジニアとしてのルーツや「目的のためなら泥臭く何でもやる」という姿勢を深掘りしていく中で、同時にAimingという会社の歴史や変遷まで知ることができ、非常に面白く貴重な体験でした。

僕が所属する基盤チームの最大の魅力は、特定のタイトルに留まらず、ゲームの裏側から社内ツールまで多種多様な領域へフィードバックを受けながら横断的に関われる点です。K.Hさんのように「目的のための手段」として技術を選べる環境があり、僕自身もRuby on Railsを中心としつつ、プロジェクトに合わせてNuxtを使ったり、Goに触れてみたりと、様々な技術を用いたフルスタックな開発に挑戦しています。

気付けば少し長くなってしまいました!それくらい僕自身にとって刺激的で学びの多い時間でした。この記事を読んで「ゲームの裏側を支えたい」「色々な領域に関わりたい」「面白いものを作りたい」と感じていただけた方、ぜひ基盤チームで一緒に働きましょう。編集の皆さんもありがとうございました!