2017 01 Dec

変化するゲーム作りの現場 サーバーエンジニアの立ち位置とは

変化するゲーム作りの現場 サーバーエンジニアの立ち位置とは

  • このエントリーをはてなブックマークに追加

2017.12.01

  • Facebookでシェアする!
  • Twitterでツイートする!
  • はてなブックマークでブクマする!

ブラウザゲームから始まり、アプリゲームへと領域を広げてきたDeNAのゲーム事業。
その中ではアプリ開発のみならず、アプリゲームを作るうえで必要なサーバー機能を提供するプラットフォームの開発も行っています。
時代を追うにつれゲーム作りの形が移り変わっていく中、エンジニアたちはどのように開発に取り組んできたのでしょうか。
今回は、プラットフォームの開発・運用を手掛けているサーバーエンジニア、栗山万樹と越智琢正の2名に話を聞きました。

栗山 万樹 | Kazuki Kuriyama

2013年新卒入社。『三国志ロワイヤル』の運用を担当した後、アプリゲームのプラットフォーム開発に携わる。

越智 琢正 | Takumasa Ochi

2013年新卒入社。WEBフレームワークの開発やメンテナンスなどを担当。その後、『FINAL FANTASY Record Keeper』海外版をリードエンジニアとして立ち上げ、その後はアプリゲームのプラットフォーム開発に携わる。

Japanリージョンゲーム事業部 サーバーエンジニア 栗山

 

――現在、お二人が担当している業務について教えてください。

栗山:
アプリゲームにフォーカスしたプラットフォームの開発・運用をしています。
今関わっているプラットフォームは、多くのゲームに共通するサーバー機能を一括提供し、開発から運営までをサポートするものです。
アカウント管理や課金処理、プレイヤーに紐づくセーブデータ管理、アセット管理などの役割を担っています。

このプラットフォームを利用しているタイトルは複数あり、自分たち二人はそれぞれ異なるタイトルをメインで担当しています。
タイトルのゲーム性に応じて機能を作りたいという要望もあるので、それぞれにプランナーやクライアントエンジニアと相談しながら機能を設計・開発しています。
異なるタイトルを担当しているサーバーエンジニア同士でソースコードのレビューをすることもありますし、設計方針の擦り合わせもします。

越智:
アプリケーションレイヤーでの具体的な機能開発はもちろんですが、既存の技術スタックで不可能なことも発生するので、その際には技術選定などまでおこないます。
既成のソリューションで要件を満たすことが出来るのかを判断しつつ、適したものが無い場合は自分たちで新しいシステムを作ることもあります。

――サーバーエンジニアとして、どのようなことを意識して業務に取り組んでいますか?

栗山:
複数のタイトルを抱えるプラットフォームを取り扱っているので、「絶対にバグを起こしてはいけない」ということは肝に銘じており、きちんとレビューする体制の構築と、自動テストの整備はチームとして大事にしています。
それと、“互換性”ですね。多くのタイトルが利用しているので、仕様変更による影響は非常に大きいです。
なので、初期の設計をしっかり検討して、後から互換性を保ったまま拡張しやすい設計・実装にすることを重視しています。
どうしても互換性を崩す必要がある場合は、どのように利用者に移行をしてもらうか、移行プランまで意識して、開発を行っています。

越智:
また、サーバーエンジニアとクライアントエンジニアに限らず、QA(Quality Assurance)やCS(Customer Support)も含めた一つのプロジェクトチームとして、いかにスムーズに良いシステムを提供できるかも考えています。
例えば、リリース後にお問い合わせが発生しにくい、万が一発生した場合でもスムーズな調査・対応ができるようなシステム設計を行っています。
開発を進めるにあたっては、サーバー開発の進捗がクライアント開発に影響しにくい状態にできるよう気をつけています。
例えば、クライアント-サーバー間のインタフェースの定義を最優先でおこない、その後サーバーの内部実装とクライアント開発者の実装を並行で進められるようにするといった感じです。

Japanリージョンゲーム事業部 サーバーエンジニア 越智

 

――ゲームの主流は、ブラウザゲームからネイティブアプリへと移り変わっていきました。ブラウザゲームに携わった経験もあるお二人は、どのような変化を意識してゲーム開発に取り組んできたのでしょうか?

栗山:
僕が携わった『三国志ロワイヤル』は、アプリゲームとして配信していますが、実は内部的にはブラウザゲームとあまり変わらないシステムで、ゲームロジックもデータもすべてサーバー側にある状態でした。
また、プレイヤーが何か操作をするたびに通信が発生するような構造でした。
それに対して直近担当しているようなアプリタイトルでは、クライアント側にゲームロジックやデータ管理を寄せることでプレイヤーの体感を向上させています。
一方で、クライアント側のロジックは、どうしても不正行為に弱いため、重要な部分はサーバー側で管理しています。
設計する段階から、クライアント側で管理する領域と、サーバー側で担保する領域を意識するようにしています。

越智:
僕が携わった『FINAL FANTASY Record Keeper』は、ブラウザからアプリにシフトしつつある頃に作られたゲームでした。
ネイティブアプリとして配信されていますが、WebViewとネイティブレイヤーを組合せたハイブリッドなアーキテクチャで構成されています。
ハイブリッドな仕組みは『三国志ロワイヤル』と共通ですが、API呼び出し回数を抑え、クライアント上へのロジックの移行を進めた、より、現在のネイティブアプリの形態に近づいたアプリでした。

その中で特徴的だった変化としては、データの管理です。
イベント毎にデータとロジックを量産していたブラウザゲームの世界から、お互いを分離しデータ駆動の運用が出来るような世界へと変化してきました。
また、データのライフサイクルも、サーバーだけで完結せず、クライアント上のメモリやローカルストレージなどを意識することが必要になります。

具体的な例としてもう一つ挙げるとすれば、前述のようにデータが分散して管理されるので、通信障害があった時のための仕組み作りが必要になったことです。
電波の届かないトンネルの中や、Wi-Fiから3G通信へに切り替えた時など、通信エラーは日常的に起こりうるものです。
通信エラーが発生するたびにデータ不整合が発生するのは論外ですし、また、見た目上だけの不具合であっても、プレイヤーの体感としてはよくありません。

栗山:
通信エラーが起きた時、サーバー上ではデータを更新したのに、クライアントはそのことを知らない、というケースはよくありますからね。
そのような場合を考慮すると、サーバー側のAPIには冪等性を持たせておいて、クライアントがエラーを受け取ったときはただリトライすれば正しく動作するようにすることで、クライアント開発者にとっては単純な実装で、クライアント-サーバーのシステム全体としてデータの整合性を保つことができると考えています。
サーバーエンジニアの立場ですが、クライアント側の動きまで考慮したうえで設計していかなければならないのはあります。

――ネイティブアプリの時代において、サーバーエンジニアとしての考え方や立ち位置はどのようなものだと捉えていますか?

越智:
言われたものを作るだけじゃなく、自分自身でプロジェクトをドライビングしていく姿勢は求められていると思います。
「こういう機能を作ってほしい」という依頼に対して、なぜ必要なのか、何に困っているのかをヒアリングし、より良い解決策を模索する。
職種を超えて積極的に関わっていかないと、良いゲームは作れないのではないでしょうか。

栗山:
そうですね。一つの機能を作るにしても、どんなプレイを想定しているのか?、画面は?、プレイ人数は?、といった細かいところまで、要件に応じてクライアントエンジニアやプランナーにヒアリングを行って、課題の本質を汲み取るようにしています。
場合によっては、エンジニアが企画を提案することもありますし。

越智:
加えて、サーバーは複数のタイトルを支えていますから、個々の意見を汲み上げつつ、全体にとって最適なプラットフォームのありかたを考えることも必要です。
そこはサーバーエンジニアの特徴的な役割で、時にはクライアント開発者からの要望に対して、こうあるべきというフィードバックをすることもあります。

また、複数タイトルをサポートしているという面以外にも、タイトルに関わる多職種のメンバーの業務を支えているという点も大きいです。
サーバーを直接利用するクライアントエンジニアに限らず、プランナーやQA・CSといった各領域の業務についても必要に応じてヒアリングを行い、お互いが本業以外の部分に煩わされることなく本質的なことに注力できるよう、仕組みづくりをサポートしています。

――ゲームプログラマーだけでなく、他の開発者を支える土台になっているんですね! それでは、DeNAならではのゲーム開発の強みはどこでしょうか?

栗山:
同じ技術を使い続けるのではなく、必要に応じて技術を比較しメリットがあると示せれば、ちゃんと新しい技術へ乗り換えていける点は強みだと思います。

越智:
開発段階だけでなく、運用段階になっても改良を続けられることが強みですよね。
既存の機能がパフォーマンスに見合わなくなってきたとき、普通だと動いている機能を止めることに抵抗があります。
でもDeNAでは、きちんと理由があれば正常に動いているシステムのバックエンドを丸ごと変えることもします。
パフォーマンスやデータ整合性を鑑みてしっかりと対処しているので、大規模な変更をエンドプレイヤーまでスムーズに提供することが出来ています。

栗山:
何か課題が見つかった場合もすぐに運用を見直して改良していきますから開発速度とも両立ができていますよね。
それと、働いている一人ひとりの知識量が幅広い。例えば、アプリエンジニアとインフラエンジニアといった異なる職種でも、システムのコストと効果までわかったうえで話し合うことができる。
お互いの知識の領域がきちんとクロスしてるから、後になってバグが見つかって……などといった穴も防げていると思います。
現場では、数人で技術に関する相談をしていたら周りからワーッと人が集まってディベートに発展していったり、自然とそういう交流ができる環境でもあります。

――DeNAで働くうえで良い点は?

栗山:
仕事を任せてもらえる環境ですね。
時には大きな案件がドーンときたりもしますが(笑)、その分やりがいを感じますし、エンジニアとしては難しい案件を考えてロジックを作っていくのは楽しいんですよね。

越智:
裁量を与えてくれるという点は、僕も同じです。任されたら当然やりとげる責任が生まれますが、その過程で実力が身についていくという部分は大きいですね。
仕事の自由度も高くて、エンジニアじゃない領域も含めてビジネス判断を任せてもらえます。
「システムがもたらすメリットに対してコストが高いから、そもそもの手段を変えよう」とか、より深く入り込んだところまで考えて仕事ができる。
もちろん、最終的な判断はプロデューサーがしますが、実感をもってプロジェクトを動かしていくことができます。

栗山:
それと、自分も含め、皆さん自分が関わったゲームをやり込んでいます!ゲーム好きな人が多いですね。
実際に自分でプレイしていると、仕様の良し悪しや挙動の違和感にすぐに気付くこともできますし。

越智:
自分で対処できるのはいいですよね。
以前、開発に携わっていたゲームをプレイしていた時にサーバーとクライアントの間で通信ラグを感じて、通信経路を改善したことがありました。
インフラ構成の変更をしてから再度プレイしてみて「おー、早くなった!」って感動(笑)。

栗山:
プレイヤーさんの反応も良かったし、自分も嬉しい(笑)。
趣味と仕事の両立ができる環境だと思います。


プロジェクトの全体像を見ながら、新しい技術を取り入れていくというサーバーエンジニアのお二人。

DeNAのゲーム作りを支えるのは広い視野を持つ一人ひとり、そんな現場の様子が伺えるお話でした!