【DGT特集Vol.3】大切なのは言語やスキルではなく"おもしろさに関与する"姿勢…技術部部長が語るゲーム運営エンジニアに必要なこと
ディー・エヌ・エー（DeNA）<2432>グループとしてゲーム事業のさらなる強化を目指し、ゲーム運営力をより一層高めるため、2015年に設立されたDeNA Games Tokyo（略称DGT）。
そこで「DGT特集」と題し、DeNA Games Tokyoのキーマン達へのインタビューを実施する。Vol.1の代表取締役社長・川口俊氏、Vol.2の採用・広報チーム マネージャー徳田悠輔氏に続き、今回のインタビューは技術部 部長の平岡洋祐氏だ。
ゲーム運営エンジニアを統括する立場から、この職種に求められる条件や必要なスキルを身に付けるための育成の仕組みなど、DGTがゲーム運営エンジニアに対してどのような環境を用意しているのか、お話を伺った。
![]()
株式会社DeNA Games Tokyo
技術部 部長
平岡 洋祐 氏
――：まず、平岡さんのこれまでの経歴についてお聞かせください。
2011年に新卒でDeNAに入社しまして、4ヶ月程度の研修を経て、アプリタイトルを開発しているチームに配属されました。最初は何もわからず、ググったり質問したりを繰り返しながら、エンジニアとして本当に基礎的な部分から少しずつ学んでいました。アプリタイトルに配属されて4ヶ月ほど経った頃、事前登録だけで数十万人という超大型のブラウザタイトルがリリースされるタイミングがあり、会社としても人員を厚くしようということでそのタイトルへ異動することになります。
そこからの2年間はブラウザタイトルの運営を行っていく中で、「おもしろくするにはどうすれば良いのか」、「どういう設計にすれば長期運営に耐えられるのか」、など試行錯誤しながら、ゲームづくりの基礎を磨いていく期間だったように思います。
その後は新規タイトル開発のリーダーとして、企画書1枚からのプロジェクトに参画しました。ゼロベースで新たなゲームを作るという経験をする中で、ゲーム運営で培ったものをフルに活かして、「次の時代の"おもしろい"を定義してやる」という意気込みで取り組んでいました。結果は全く流行らず大失敗でした（笑）。プロジェクト自体は失敗だったのですが、次の時代を作ろうと動く中で試行錯誤した経験は今でも自分の財産となっています。
この新規タイトルが落ち着いたタイミングで、もう一度ゲーム運営のプロジェクトに戻りました。『怪盗ロワイヤル』の運営チームだったんですが、そのチームは若いメンバーが中心でしたので、僕自身にシニアな立場での振る舞いを求められるのと同時に、マネージャーとしてのキャリアもスタートしました。
――：DGTと関わるきっかけはいつだったのですか？
僕が『怪盗ロワイヤル』の運営チームに配属されたタイミングです。DGTの規模が大きくなりつつあった時期で、『怪盗ロワイヤル』の運営をDGTに移管することになり、このときがDGTと初めての関わりになりました。
DeNAのマネージャーとしてDGTと関わっていく中で、『怪盗ロワイヤル』の運営移管だけではなく、DGTの組織開発にも積極的に入っていきました。当時のDGTは組織拡大期特有のカオスな状況が多くあり、一つずつDeNA側のマネージャーとDGT側のマネージャーで一緒に解決していくという感じでした。
ただ、自分の明確なミッションとしてDGTの組織開発や事業戦略に関わっていたわけではなく、あくまでDeNAのマネージャーの立場として提案する、という外野的な関わり方だったので、権限は何も持っていませんでした。また、それが「自分自身のコミットメントの低さに対する言い訳になってるな」とぼんやり考えていました。
そこで、自分自身の逃げ道を無くす意味でも、濁りなくDGTの未来にコミットするためにも、覚悟を決めて技術部の部長に就任し、今に至ります。
――：ご自身もエンジニアとして活躍されてきた中で、DGTのゲーム運営エンジニアはどのようなスキルが求められるのでしょうか。
「この言語ができないとダメ」というものはありません。スキルに関しては後から覚えられますから。求めたいのは、「おもしろさにちゃんと関与しようとすること」です。
おもしろさに関与できないエンジニアは言われたものを作るだけになってしまいます。システム上の制約を頭に入れた上でいかにおもしろさに迫れるかという部分は、エンジニアだからこそできる仕事ですし、そこまでエンジニアがやってこそ、本当の意味でのものづくりの実感を得られるのだと思います。
――：実際、DGTのゲーム運営エンジニアは、提案する意志を持った方が多いのでしょうか？
"ゲームをおもしろくしていくために何をすべきか"という気持ちはみんなが共通して持っていますし、プランナーに対してすごくものを言っています（笑）。基本的にはそういう気持ちを持ち合わせたメンバーで構成されていますね。
![]()
――：ゲームエンジニアとして、新規タイトル開発と運営タイトル開発の両方に関わってきた平岡さんから見た、それぞれの魅力を教えてください。
新規タイトル開発ってお祭り前夜のような、みんなを驚かせるものを仕込んでいるワクワク感を持ってやれるから楽しいんです。一方で運営タイトル開発は自分が作っているゲームを電車の中で実際に遊んでくれている人を目にしたり、世の中の人達の日々の楽しみを提供しているという実感の部分が強くて、そこが魅力だと思います。
新規タイトル開発の場合、おもしろさが作れずリリースされないこともあったり、リリースされてもプレイヤーが少なかったりプレイヤーからの反応がないということもあります。
ただ、運営タイトル開発はそれがない。少なくともDGTが運営しているタイトルは数十万〜数百万人規模のプレイヤーが常に遊んでいて、常にフィードバックが返ってくるという環境にあり大きなやりがいにつながると思います。
ここまでは職種に寄らない、サービス全般の話です。エンジニア視点で言うと、やはり自分が作ったものが良い構造なのか、悪い構造なのかがわかるタイミングに差があります。
新規だと実際に定量的なフィードバックが返ってくるのは、タイトルのリリース後なので、開発してから2年くらい必要です。運営だと新しい設計を作った翌月には、パフォーマンスが落ちた、バグが出た、プレイヤーからお問い合わせがあったなど、自分が作ったものに対してすぐにフィードバックが返ってくる。「じゃあ次はこう設計しよう」と直すことができるので、まさにプレイヤーと会話をしているような感覚。ですので設計していく上での学びのサイクルも早いと思います。そういったところが運営において特徴的かつ魅力的な部分ですね。
――：では、逆にゲーム運営エンジニアは大変だと感じることや苦労することなどは？
やはりスピードです。どんな業界でも受注に対して納期があります。ゲーム運営はブラウザだと毎月、アプリなら3ヵ月くらいのサイクルになりますが、そこで何かを出さなければならないので、納期に対して求められるスピード感はかなり早いです。
例えば金融システムと比べてゲーム運営はおそらくシステムの安定性のようなところは落ちると思いますが、その分、意思決定と開発のスピードが求められます。
ゲーム運営は基本的に自社で何を作るか決めて、自社で開発も行うので、仕様を変えたり、実装ボリュームは適宜コントロールできます。「ずっと残業しないと作れない！」といったようなことはないのですが、そのコントロールもそれぞれのメンバーに任されているので、適切な判断とそれに合った開発スピードを自分で設計していかなくてはいけないのは、やりがいにもなりますし、大変でもあります。
――：そういう部分で苦労しながらゲーム運営エンジニアとして鍛えられて育っていく。DGTではゲーム運営エンジニアの人材を育てるためにどのような取り込みをしているのでしょうか。
新卒採用は行っていないので、中途採用のメンバーに対しての話になりますが、入社時にエンジニア研修をしています。その研修は座学的に教える事はせず、ゲーム開発に必要な技術トピックに対してお題を設定をして、それを全てクリアできれば卒業という設計になっています。
早い人だと大体3週間程度、遅い人だと数ヶ月、中には半年以上研修していた人もいます。定められたクオリティーバーに達するまで研修が終わらないという設定の仕方なので、特徴的な研修制度かなと思っています。
――：研修自体に期限はあるんですか？ 例えば半年経っても課題がクリアできない人はどうなってしまうのでしょうか。
期限はなく、クリアするまで基本的にはずっと研修してもらいます。ただ、周囲が付きっ切りで見るような研修ではありません。
なぜこのような研修にしているかというと、実際にチームに入ってタイトルやプロダクトのリーダーになった場合、誰に聞いてもわからない課題を解いていかなければなりません。自分で調べてどこまでやれるかというものがベースとして問われる環境というものが、今後その人たちには訪れるはずなので、研修時からそういう部分を意識してもらっています。
研修の進捗や課題の回答に関しては、1日1回、GitHub上でPull Requestを飛ばしてもらって、それに対して自分や研修担当者がレビューして答えていくという流れになっています。もし課題がクリアできなければ、また明日提出してください、というような流れを続けます。
これをクリアすればOKというラインは提示するので、後は自分で調べて課題をクリアしてもらうというスタンスです。もちろん「こういう考え方ですよ」といったアドバイスはします。
![]()
――：研修のほかに育成に関して意識されていることはありますか？
間接的ではありますが、アサインの面でも育成を意識しています。例えばあるメンバーの成長に関して、現在担当しているタイトルを続けてもまだ成長の余地があったり、この要素は今のタイトルで学べるという場合は残ったほうが良いと判断します。
逆に大体のことは何でもできるようになったメンバーに関して、これ以上今のタイトル、今のポジションを続けても成長が遅いなと思ったら別のチームやポジションにアサインすることもありますね。
もちろん各チームの状況なども見ながらなので常にタイムリーに実行できているわけではありませんが、成長を考慮したメンバーのアサインはしています。
――：メンバーから「このタイトルに移りたい」等の申し出があった場合はどう判断されるんですか？
自分自身がやりたいことをちゃんと伝えるというのはポジティブなことなので、まずなぜ移りたいのか話を聞いた上で検討します。
例えば、今はブラウザタイトルだけどアプリタイトルに行きたいという話があったとします。しっかりと話を聞いた上で、ブラウザタイトルで学ぶべきことが無かったり、本人の今後進みたい道にその能力が必要ないというような場合は、次のタイトルへの配属の検討に入ります。
――：平岡さんがマネジメントされている中で、いま課題に感じていることはありますか？
マネージャーをやりたいというエンジニアが少ないというところは課題かなと思っています。本来なら、マネージャー1人に対し、8人くらいのメンバーを見てもらうのが理想かなと思っているのですが、現状だとマネージャーの数とメンバーの数が釣り合っていないというか。マネージャーは一定数必要なんですけど、マネージャーというキャリアを歩んでいこうと思っている人が少ない気がしています。
もし自分からメンバーに対してマネジメントをお願いする場合、マネージャーになることを嫌がらない人で、かつマネジメントができる人を選ぶんですけど、マネジメント能力が高くても固辞する人が多いかなと思ってます。だからそういう人たちには、残念ですがマネージャーをお願いしません。嫌々マネジメントをしているマネージャーってメンバーにとってもネガティブだと思うので、そこはバランスを見ていかなければなりません。
――：エンジニアはマネジメントよりもエンジニアリングの方に志向性があるのでしょうか。
エンジニアってエンジニアリングしていく中で自分の能力がスタックしていく実感があると思うんですけど、おそらくマネジメントのキャリアはスキルがスタックしている実感が得づらいからだと思います。だから、メンバーを管理することに対して"面倒を見ている時間"みたいな捉え方をしている気はしていて、それよりも開発現場にいてちゃんと自分の能力がスタックすることに時間を使いたいと思ってしまう。
その気持ちはもちろん理解できますが、実際にマネジメントをすれば、マネジメントのスキルが自分にスタックしている。マネジメントスキル自体、一つの汎用的なスキルだと思います。あと、マネジメントの立場で見える景色に触れることで、たぶん事業的な観点での視野の広がりが生まれます。
そういう意味ではポジティブに自分自身に返ってくるとは思うんですけど、それはマネージャーになってみないと得られないものだし、説明しても伝わり切らないのが難しいところです。
とはいえ、エンジニアとしてのキャリアを重ねていきたいという方もいるので、そういう方にはプレイヤーとしてがんばってもらいます。DGTの話ですが、マネージャーになったから評価が上がる組織ではありません。エンジニアとしてマネージャーよりも高いプレゼンスを出し、会社に対して高い貢献をしていればマネージャーよりも給料が高いこともある組織ではあるので、それぞれが自分で高いパフォーマンスを出せる領域を選んだ方が良いと思っています…。が、マネージャーの人員拡充という意味でもう少しいてほしいですね（笑）。
――：ちなみに今いるメンバーの中でマネージャーになって欲しいと思った人に対して、どんな魅力付けをして提案しているんですか？
マネジメントというものをどう捉えるかは人それぞれで、これは僕の主観になりますが、"ゲームを作ることも、組織を作ることも、本質的にはあまり変わらない"と思っています。どういう状態のゴールを理想としたいのか、それに対してどういうHowで成し遂げていくのかというところは似ているんです。
なので、タイトルでリーダーを務め、そういうことが全てできるようになっている方に対しては、「それを組織作りで挑戦してみたくない？」という伝え方をします。それは本質的な部分は変えず、テーマを変えるという意味なんです。こういう方って、今担当しているタイトルが別タイトルになってもあまり見える景色が変わらなかったりする。「違ったフィールドで試してみるのは良い経験だと思いますよ」という事を伝えた上で提案しています。
![]()
――：平岡さんが今後、DGTでチャレンジしたいことはありますか？
基本的にチャレンジしたい取り組みは思いついたらすぐに動いているので、現状で今後こうしたいという具体的な話はありませんが、エンジニア発信でしっかり事業を作っていきたいということは広い意味で考えています。やはりスケールするビジネスの形を持ちたいですし、それをエンジニア発信でやれたら強いなと。
もちろんゲームを作っていくというところはメインの軸足なので今後も変わらず続けていきますが、その上で何か新しいものを起こすようなことをしたいと思っています。
――：良いアイデアや取り組みを思いついたら、すぐに実行に移すんですね。
そうですね。先程お話した研修制度だったり、エンジニアの技術研鑽のサポートをしたいなと思ったらそういった制度を作ったり。何かやろうと思ってそれに対するアウトプットとして、どういうゴールイメージにするのかを考えたら、後はもうやるだけです。DGTにとって必要だなと思うことに対しては動いていくスタンスです。
僕だけじゃなくメンバーからも色々な意見が挙がっています。例えば外部に向けてもうちょっとエンジニアとしての発信をしていきたかったとして、メンバーから「じゃあどんな感じにしようか」という話し合いや提案をしてくれるんです。
実際に動くかどうかのジャッジは僕がしています。割に合うか合わないか、効果があるのかどうかも大切ですが、効果があるわけではないけど「こういうことをしている組織でいたいよね」という意思があればやります。効果と意思、その両方をブレンドしてやるやらないを判断しています。
――：ゲーム運営エンジニアチームの将来のビジョンはどのように考えていますか？
掲げている事として、DGTのエンジニアは「サービスリードエンジニア集団でいよう」、というスタンスをメンバー全員に伝えています。読んで字の如くなのですが、サービスをリードするエンジニア像を目指しています。エンジニアの領域だけに止まらず、できることは全部やりましょう、と。
それはどんなサービスを作るということに対してもそうですし、やると決めたらそれをちゃんと実現させる。しっかりとものを作っていって、サービスを先導するようなエンジニア集団になろうと思っています。その対極にあるのが、言われたことだけを作るエンジニアですね。
このビジョンに対して、現状は、ある部分では理想に近づいているところもあります。おそらくビジョンに共感してくれたりマインドが近しいメンバーを採用できていることもあるので、その流れが今後より色濃くなっていくのが理想かなと思っています。
もちろん現時点で完全に満ち足りているわけではありませんし、まだまだ足りないという感じですが、目指す理想像はそこにあります。
![]()
――：将来的にゲーム運営エンジニアのチームも規模が大きくなっていくと思いますが、今後どのような人と一緒に働きたいですか？
第一に挙げるとすると、自走する方です。先ほどお話した通りですが、企画に対する提案だったり僕に対する提案など、意見を出してくれるようなタイプが望ましいですね。
そういうタイプじゃなくても構わないんですが、それだとシンプルにサービスリードエンジニアとして仕上がるまでの時間が長くなっちゃうなと思うし、仕上がらないパターンもあり得る。だから根本には自走する部分を持ってほしい。
何が足りないのかを自分で考えて、自分で学ぼうというスタンスを持っている人は、勝手に学んでいくタイプだと思います。それが「全部教えてください」というスタンスだと、たぶんその後、成長できないかなと。
実際にDGTでは、最終的な仕上がりが高い地点まで行けるというイメージを持てる方を採用しています。だから現時点での能力はあまり問わなくて、それよりもスタンスの部分を重視しています。
過去にもエンジニア未経験者を採用したこともあるので、本当に現在地は関係ないと考えています。ただ誤解していただきたくないのは、我々は素人集団でいようとは思っていませんし、しっかりプロであるべきだと思っています。その上で、入口としてのスタート地点は関係ない、ということです。
――：それでは最後に読者へのメッセージをお願いいたします。
DGTは、エンジニアに対してクライアントエンジニア、サーバーエンジニアという垣根を作っていません。基本的に業務をする際には何かしらの枠にはハマるんですが、エンジニアそのものをラベル付けしていません。
DGTのエンジニアはエンジニアというスタンスの元、サーバーもクライアントも経験できるというキャリアの積み方ができます。かつ、ゲーム運営の事業特性として、現状はDeNAからゲームを移管するビジネスですので、ゲームごとにテーマも変わって色々なものに取り組める。しかも、DeNAのタイトルポートフォリオにはさまざまなゲーム性のタイトルがあり、それぞれのタイトルが中〜大規模というのは、そうそうできない経験かなと思っています。
IPのゲームの制作スケジュールはこんな感じなのかとか、2Dのゲームってこうすれば効率的になるのかとか、3Dアクションで使う技術はこうなのかと、色々と試すためのSandbox環境が豊富にあります。
僕としてはエンジニアにとってはおもしろいし、良い環境かなと思います。ゲーム業界の中でも特徴的なプロダクトの性質を持った会社だと思っていますし、ゲーム運営に特化しているので、自分が関わったものがちゃんと世の中に出るというのもDGTの特徴です。すごく気持ちを込めて作ったのにリリースされずに終わってしまい、悲しい想いをしているゲームクリエイターって世の中に多い気がしています。
自分が作ったものがプレイヤーの目に触れ、遊んでもらえる、というのは大きいなと思っています。そういうものを抱えている方がいれば、一つのキャリアの中でDGTでチャレンジすることを考えてもらえたらうれしいです。
▼DGT特集バックナンバー▼
・【DGT特集Vol.1】ゲーム運営に特化したDeNAの子会社"DeNA Games Tokyo"…ユーザーファーストな運営を実現するための"おもしろさの創出×仕組み化"とは？
・【DGT特集Vol.2】ゲームトレンドの変化に適応できる人材を採用・育成するための取り組み…採用マネージャーが語るDGTの人材戦略
・【DGT特集Vol.3】大切なのは言語やスキルではなく"おもしろさに関与する"姿勢…技術部部長が語るゲーム運営エンジニアに必要なこと
・【DGT特集Vol.4】いいプランナーの条件は「おもしろい体験作り」と「プレイヤーと真剣に向き合う姿勢」…優秀なプランナーを育成するためのDGTの取り組みと環境に迫る
そこで「DGT特集」と題し、DeNA Games Tokyoのキーマン達へのインタビューを実施する。Vol.1の代表取締役社長・川口俊氏、Vol.2の採用・広報チーム マネージャー徳田悠輔氏に続き、今回のインタビューは技術部 部長の平岡洋祐氏だ。
ゲーム運営エンジニアを統括する立場から、この職種に求められる条件や必要なスキルを身に付けるための育成の仕組みなど、DGTがゲーム運営エンジニアに対してどのような環境を用意しているのか、お話を伺った。
株式会社DeNA Games Tokyo
技術部 部長
平岡 洋祐 氏
■DGTの未来ため、覚悟を決めて技術部 部長に就任
――：まず、平岡さんのこれまでの経歴についてお聞かせください。
2011年に新卒でDeNAに入社しまして、4ヶ月程度の研修を経て、アプリタイトルを開発しているチームに配属されました。最初は何もわからず、ググったり質問したりを繰り返しながら、エンジニアとして本当に基礎的な部分から少しずつ学んでいました。アプリタイトルに配属されて4ヶ月ほど経った頃、事前登録だけで数十万人という超大型のブラウザタイトルがリリースされるタイミングがあり、会社としても人員を厚くしようということでそのタイトルへ異動することになります。
そこからの2年間はブラウザタイトルの運営を行っていく中で、「おもしろくするにはどうすれば良いのか」、「どういう設計にすれば長期運営に耐えられるのか」、など試行錯誤しながら、ゲームづくりの基礎を磨いていく期間だったように思います。
その後は新規タイトル開発のリーダーとして、企画書1枚からのプロジェクトに参画しました。ゼロベースで新たなゲームを作るという経験をする中で、ゲーム運営で培ったものをフルに活かして、「次の時代の"おもしろい"を定義してやる」という意気込みで取り組んでいました。結果は全く流行らず大失敗でした（笑）。プロジェクト自体は失敗だったのですが、次の時代を作ろうと動く中で試行錯誤した経験は今でも自分の財産となっています。
この新規タイトルが落ち着いたタイミングで、もう一度ゲーム運営のプロジェクトに戻りました。『怪盗ロワイヤル』の運営チームだったんですが、そのチームは若いメンバーが中心でしたので、僕自身にシニアな立場での振る舞いを求められるのと同時に、マネージャーとしてのキャリアもスタートしました。
――：DGTと関わるきっかけはいつだったのですか？
僕が『怪盗ロワイヤル』の運営チームに配属されたタイミングです。DGTの規模が大きくなりつつあった時期で、『怪盗ロワイヤル』の運営をDGTに移管することになり、このときがDGTと初めての関わりになりました。
DeNAのマネージャーとしてDGTと関わっていく中で、『怪盗ロワイヤル』の運営移管だけではなく、DGTの組織開発にも積極的に入っていきました。当時のDGTは組織拡大期特有のカオスな状況が多くあり、一つずつDeNA側のマネージャーとDGT側のマネージャーで一緒に解決していくという感じでした。
ただ、自分の明確なミッションとしてDGTの組織開発や事業戦略に関わっていたわけではなく、あくまでDeNAのマネージャーの立場として提案する、という外野的な関わり方だったので、権限は何も持っていませんでした。また、それが「自分自身のコミットメントの低さに対する言い訳になってるな」とぼんやり考えていました。
そこで、自分自身の逃げ道を無くす意味でも、濁りなくDGTの未来にコミットするためにも、覚悟を決めて技術部の部長に就任し、今に至ります。
■エンジニアに必要なのは"おもしろさに関与すること"
――：ご自身もエンジニアとして活躍されてきた中で、DGTのゲーム運営エンジニアはどのようなスキルが求められるのでしょうか。
「この言語ができないとダメ」というものはありません。スキルに関しては後から覚えられますから。求めたいのは、「おもしろさにちゃんと関与しようとすること」です。
おもしろさに関与できないエンジニアは言われたものを作るだけになってしまいます。システム上の制約を頭に入れた上でいかにおもしろさに迫れるかという部分は、エンジニアだからこそできる仕事ですし、そこまでエンジニアがやってこそ、本当の意味でのものづくりの実感を得られるのだと思います。
――：実際、DGTのゲーム運営エンジニアは、提案する意志を持った方が多いのでしょうか？
"ゲームをおもしろくしていくために何をすべきか"という気持ちはみんなが共通して持っていますし、プランナーに対してすごくものを言っています（笑）。基本的にはそういう気持ちを持ち合わせたメンバーで構成されていますね。
――：ゲームエンジニアとして、新規タイトル開発と運営タイトル開発の両方に関わってきた平岡さんから見た、それぞれの魅力を教えてください。
新規タイトル開発ってお祭り前夜のような、みんなを驚かせるものを仕込んでいるワクワク感を持ってやれるから楽しいんです。一方で運営タイトル開発は自分が作っているゲームを電車の中で実際に遊んでくれている人を目にしたり、世の中の人達の日々の楽しみを提供しているという実感の部分が強くて、そこが魅力だと思います。
新規タイトル開発の場合、おもしろさが作れずリリースされないこともあったり、リリースされてもプレイヤーが少なかったりプレイヤーからの反応がないということもあります。
ただ、運営タイトル開発はそれがない。少なくともDGTが運営しているタイトルは数十万〜数百万人規模のプレイヤーが常に遊んでいて、常にフィードバックが返ってくるという環境にあり大きなやりがいにつながると思います。
ここまでは職種に寄らない、サービス全般の話です。エンジニア視点で言うと、やはり自分が作ったものが良い構造なのか、悪い構造なのかがわかるタイミングに差があります。
新規だと実際に定量的なフィードバックが返ってくるのは、タイトルのリリース後なので、開発してから2年くらい必要です。運営だと新しい設計を作った翌月には、パフォーマンスが落ちた、バグが出た、プレイヤーからお問い合わせがあったなど、自分が作ったものに対してすぐにフィードバックが返ってくる。「じゃあ次はこう設計しよう」と直すことができるので、まさにプレイヤーと会話をしているような感覚。ですので設計していく上での学びのサイクルも早いと思います。そういったところが運営において特徴的かつ魅力的な部分ですね。
――：では、逆にゲーム運営エンジニアは大変だと感じることや苦労することなどは？
やはりスピードです。どんな業界でも受注に対して納期があります。ゲーム運営はブラウザだと毎月、アプリなら3ヵ月くらいのサイクルになりますが、そこで何かを出さなければならないので、納期に対して求められるスピード感はかなり早いです。
例えば金融システムと比べてゲーム運営はおそらくシステムの安定性のようなところは落ちると思いますが、その分、意思決定と開発のスピードが求められます。
ゲーム運営は基本的に自社で何を作るか決めて、自社で開発も行うので、仕様を変えたり、実装ボリュームは適宜コントロールできます。「ずっと残業しないと作れない！」といったようなことはないのですが、そのコントロールもそれぞれのメンバーに任されているので、適切な判断とそれに合った開発スピードを自分で設計していかなくてはいけないのは、やりがいにもなりますし、大変でもあります。
■プロダクトのリーダーになることを見越した研修設計
――：そういう部分で苦労しながらゲーム運営エンジニアとして鍛えられて育っていく。DGTではゲーム運営エンジニアの人材を育てるためにどのような取り込みをしているのでしょうか。
新卒採用は行っていないので、中途採用のメンバーに対しての話になりますが、入社時にエンジニア研修をしています。その研修は座学的に教える事はせず、ゲーム開発に必要な技術トピックに対してお題を設定をして、それを全てクリアできれば卒業という設計になっています。
早い人だと大体3週間程度、遅い人だと数ヶ月、中には半年以上研修していた人もいます。定められたクオリティーバーに達するまで研修が終わらないという設定の仕方なので、特徴的な研修制度かなと思っています。
――：研修自体に期限はあるんですか？ 例えば半年経っても課題がクリアできない人はどうなってしまうのでしょうか。
期限はなく、クリアするまで基本的にはずっと研修してもらいます。ただ、周囲が付きっ切りで見るような研修ではありません。
なぜこのような研修にしているかというと、実際にチームに入ってタイトルやプロダクトのリーダーになった場合、誰に聞いてもわからない課題を解いていかなければなりません。自分で調べてどこまでやれるかというものがベースとして問われる環境というものが、今後その人たちには訪れるはずなので、研修時からそういう部分を意識してもらっています。
研修の進捗や課題の回答に関しては、1日1回、GitHub上でPull Requestを飛ばしてもらって、それに対して自分や研修担当者がレビューして答えていくという流れになっています。もし課題がクリアできなければ、また明日提出してください、というような流れを続けます。
これをクリアすればOKというラインは提示するので、後は自分で調べて課題をクリアしてもらうというスタンスです。もちろん「こういう考え方ですよ」といったアドバイスはします。
――：研修のほかに育成に関して意識されていることはありますか？
間接的ではありますが、アサインの面でも育成を意識しています。例えばあるメンバーの成長に関して、現在担当しているタイトルを続けてもまだ成長の余地があったり、この要素は今のタイトルで学べるという場合は残ったほうが良いと判断します。
逆に大体のことは何でもできるようになったメンバーに関して、これ以上今のタイトル、今のポジションを続けても成長が遅いなと思ったら別のチームやポジションにアサインすることもありますね。
もちろん各チームの状況なども見ながらなので常にタイムリーに実行できているわけではありませんが、成長を考慮したメンバーのアサインはしています。
――：メンバーから「このタイトルに移りたい」等の申し出があった場合はどう判断されるんですか？
自分自身がやりたいことをちゃんと伝えるというのはポジティブなことなので、まずなぜ移りたいのか話を聞いた上で検討します。
例えば、今はブラウザタイトルだけどアプリタイトルに行きたいという話があったとします。しっかりと話を聞いた上で、ブラウザタイトルで学ぶべきことが無かったり、本人の今後進みたい道にその能力が必要ないというような場合は、次のタイトルへの配属の検討に入ります。
■ゲーム作りも組織作りも、本質的には変わらない
――：平岡さんがマネジメントされている中で、いま課題に感じていることはありますか？
マネージャーをやりたいというエンジニアが少ないというところは課題かなと思っています。本来なら、マネージャー1人に対し、8人くらいのメンバーを見てもらうのが理想かなと思っているのですが、現状だとマネージャーの数とメンバーの数が釣り合っていないというか。マネージャーは一定数必要なんですけど、マネージャーというキャリアを歩んでいこうと思っている人が少ない気がしています。
もし自分からメンバーに対してマネジメントをお願いする場合、マネージャーになることを嫌がらない人で、かつマネジメントができる人を選ぶんですけど、マネジメント能力が高くても固辞する人が多いかなと思ってます。だからそういう人たちには、残念ですがマネージャーをお願いしません。嫌々マネジメントをしているマネージャーってメンバーにとってもネガティブだと思うので、そこはバランスを見ていかなければなりません。
――：エンジニアはマネジメントよりもエンジニアリングの方に志向性があるのでしょうか。
エンジニアってエンジニアリングしていく中で自分の能力がスタックしていく実感があると思うんですけど、おそらくマネジメントのキャリアはスキルがスタックしている実感が得づらいからだと思います。だから、メンバーを管理することに対して"面倒を見ている時間"みたいな捉え方をしている気はしていて、それよりも開発現場にいてちゃんと自分の能力がスタックすることに時間を使いたいと思ってしまう。
その気持ちはもちろん理解できますが、実際にマネジメントをすれば、マネジメントのスキルが自分にスタックしている。マネジメントスキル自体、一つの汎用的なスキルだと思います。あと、マネジメントの立場で見える景色に触れることで、たぶん事業的な観点での視野の広がりが生まれます。
そういう意味ではポジティブに自分自身に返ってくるとは思うんですけど、それはマネージャーになってみないと得られないものだし、説明しても伝わり切らないのが難しいところです。
とはいえ、エンジニアとしてのキャリアを重ねていきたいという方もいるので、そういう方にはプレイヤーとしてがんばってもらいます。DGTの話ですが、マネージャーになったから評価が上がる組織ではありません。エンジニアとしてマネージャーよりも高いプレゼンスを出し、会社に対して高い貢献をしていればマネージャーよりも給料が高いこともある組織ではあるので、それぞれが自分で高いパフォーマンスを出せる領域を選んだ方が良いと思っています…。が、マネージャーの人員拡充という意味でもう少しいてほしいですね（笑）。
――：ちなみに今いるメンバーの中でマネージャーになって欲しいと思った人に対して、どんな魅力付けをして提案しているんですか？
マネジメントというものをどう捉えるかは人それぞれで、これは僕の主観になりますが、"ゲームを作ることも、組織を作ることも、本質的にはあまり変わらない"と思っています。どういう状態のゴールを理想としたいのか、それに対してどういうHowで成し遂げていくのかというところは似ているんです。
なので、タイトルでリーダーを務め、そういうことが全てできるようになっている方に対しては、「それを組織作りで挑戦してみたくない？」という伝え方をします。それは本質的な部分は変えず、テーマを変えるという意味なんです。こういう方って、今担当しているタイトルが別タイトルになってもあまり見える景色が変わらなかったりする。「違ったフィールドで試してみるのは良い経験だと思いますよ」という事を伝えた上で提案しています。
■DGTのゲーム運営エンジニアが目指すのは「サービスリードエンジニア集団」
――：平岡さんが今後、DGTでチャレンジしたいことはありますか？
基本的にチャレンジしたい取り組みは思いついたらすぐに動いているので、現状で今後こうしたいという具体的な話はありませんが、エンジニア発信でしっかり事業を作っていきたいということは広い意味で考えています。やはりスケールするビジネスの形を持ちたいですし、それをエンジニア発信でやれたら強いなと。
もちろんゲームを作っていくというところはメインの軸足なので今後も変わらず続けていきますが、その上で何か新しいものを起こすようなことをしたいと思っています。
――：良いアイデアや取り組みを思いついたら、すぐに実行に移すんですね。
そうですね。先程お話した研修制度だったり、エンジニアの技術研鑽のサポートをしたいなと思ったらそういった制度を作ったり。何かやろうと思ってそれに対するアウトプットとして、どういうゴールイメージにするのかを考えたら、後はもうやるだけです。DGTにとって必要だなと思うことに対しては動いていくスタンスです。
僕だけじゃなくメンバーからも色々な意見が挙がっています。例えば外部に向けてもうちょっとエンジニアとしての発信をしていきたかったとして、メンバーから「じゃあどんな感じにしようか」という話し合いや提案をしてくれるんです。
実際に動くかどうかのジャッジは僕がしています。割に合うか合わないか、効果があるのかどうかも大切ですが、効果があるわけではないけど「こういうことをしている組織でいたいよね」という意思があればやります。効果と意思、その両方をブレンドしてやるやらないを判断しています。
――：ゲーム運営エンジニアチームの将来のビジョンはどのように考えていますか？
掲げている事として、DGTのエンジニアは「サービスリードエンジニア集団でいよう」、というスタンスをメンバー全員に伝えています。読んで字の如くなのですが、サービスをリードするエンジニア像を目指しています。エンジニアの領域だけに止まらず、できることは全部やりましょう、と。
それはどんなサービスを作るということに対してもそうですし、やると決めたらそれをちゃんと実現させる。しっかりとものを作っていって、サービスを先導するようなエンジニア集団になろうと思っています。その対極にあるのが、言われたことだけを作るエンジニアですね。
このビジョンに対して、現状は、ある部分では理想に近づいているところもあります。おそらくビジョンに共感してくれたりマインドが近しいメンバーを採用できていることもあるので、その流れが今後より色濃くなっていくのが理想かなと思っています。
もちろん現時点で完全に満ち足りているわけではありませんし、まだまだ足りないという感じですが、目指す理想像はそこにあります。
――：将来的にゲーム運営エンジニアのチームも規模が大きくなっていくと思いますが、今後どのような人と一緒に働きたいですか？
第一に挙げるとすると、自走する方です。先ほどお話した通りですが、企画に対する提案だったり僕に対する提案など、意見を出してくれるようなタイプが望ましいですね。
そういうタイプじゃなくても構わないんですが、それだとシンプルにサービスリードエンジニアとして仕上がるまでの時間が長くなっちゃうなと思うし、仕上がらないパターンもあり得る。だから根本には自走する部分を持ってほしい。
何が足りないのかを自分で考えて、自分で学ぼうというスタンスを持っている人は、勝手に学んでいくタイプだと思います。それが「全部教えてください」というスタンスだと、たぶんその後、成長できないかなと。
実際にDGTでは、最終的な仕上がりが高い地点まで行けるというイメージを持てる方を採用しています。だから現時点での能力はあまり問わなくて、それよりもスタンスの部分を重視しています。
過去にもエンジニア未経験者を採用したこともあるので、本当に現在地は関係ないと考えています。ただ誤解していただきたくないのは、我々は素人集団でいようとは思っていませんし、しっかりプロであるべきだと思っています。その上で、入口としてのスタート地点は関係ない、ということです。
――：それでは最後に読者へのメッセージをお願いいたします。
DGTは、エンジニアに対してクライアントエンジニア、サーバーエンジニアという垣根を作っていません。基本的に業務をする際には何かしらの枠にはハマるんですが、エンジニアそのものをラベル付けしていません。
DGTのエンジニアはエンジニアというスタンスの元、サーバーもクライアントも経験できるというキャリアの積み方ができます。かつ、ゲーム運営の事業特性として、現状はDeNAからゲームを移管するビジネスですので、ゲームごとにテーマも変わって色々なものに取り組める。しかも、DeNAのタイトルポートフォリオにはさまざまなゲーム性のタイトルがあり、それぞれのタイトルが中〜大規模というのは、そうそうできない経験かなと思っています。
IPのゲームの制作スケジュールはこんな感じなのかとか、2Dのゲームってこうすれば効率的になるのかとか、3Dアクションで使う技術はこうなのかと、色々と試すためのSandbox環境が豊富にあります。
僕としてはエンジニアにとってはおもしろいし、良い環境かなと思います。ゲーム業界の中でも特徴的なプロダクトの性質を持った会社だと思っていますし、ゲーム運営に特化しているので、自分が関わったものがちゃんと世の中に出るというのもDGTの特徴です。すごく気持ちを込めて作ったのにリリースされずに終わってしまい、悲しい想いをしているゲームクリエイターって世の中に多い気がしています。
自分が作ったものがプレイヤーの目に触れ、遊んでもらえる、というのは大きいなと思っています。そういうものを抱えている方がいれば、一つのキャリアの中でDGTでチャレンジすることを考えてもらえたらうれしいです。
▼DGT特集バックナンバー▼
・【DGT特集Vol.1】ゲーム運営に特化したDeNAの子会社"DeNA Games Tokyo"…ユーザーファーストな運営を実現するための"おもしろさの創出×仕組み化"とは？
・【DGT特集Vol.2】ゲームトレンドの変化に適応できる人材を採用・育成するための取り組み…採用マネージャーが語るDGTの人材戦略
・【DGT特集Vol.3】大切なのは言語やスキルではなく"おもしろさに関与する"姿勢…技術部部長が語るゲーム運営エンジニアに必要なこと
・【DGT特集Vol.4】いいプランナーの条件は「おもしろい体験作り」と「プレイヤーと真剣に向き合う姿勢」…優秀なプランナーを育成するためのDGTの取り組みと環境に迫る
