【レポート】ゲーム運営のプロフェッショナルが、数百万人超のプレイヤーを抱えるゲーム運営ノウハウを大公開！

イベント公開日: 2018/07/17

ブックマーク

#キャリア, #ゲーム, #チームビルディング

長期運用に耐えるための設計とリファクタリング

4人目は廣橋さんの登壇です。

廣橋俊昭（ひろはし・としあき）／株式会社 DeNA Games Tokyo エンジニア。2013年、新卒で株式会社ディー・エヌ・エーへ入社。2017年にDeNA Games Tokyoへ参画。趣味はダーツ。

廣橋さんはまず、どのようにゲームを運用しているのかを話します。

「先程の加藤の話とも重なりますが、ゲームの運用には2つの要素があります。それは『イベントの開催』と『新機能のリリース』です。

まず、『イベントの開催』については、定期的に行っているため、基本的に機能を大きく変えることはありません。具体的にはカードデータなどのマスターデータの追加、新たな演出の追加などを行います。

もうひとつの『新機能のリリース』に関しては、例えばキャラクターに装備することで強化できる素材の追加などが該当します。この場合には、テーブルやコードをまるっと新たに追加するため大変な作業です。

エンジニアの役割とは、これらをミスなく運用するためにきちんとした設計をすることだと考えています」（廣橋さん）

エンジニアの役割は運用を見据えた設計を行うことだと指摘した廣橋さんは、そのためには「正規化が重要である」と続けます。そして、次の事例を元に正規化の重要性について説明します。

■イベントの内容
キャラクター3人をデッキに編成して敵を倒す。

■キャラクターの基礎パラメータ

キャラクターID
名前
HP
攻撃力
防御力

■特殊効果
キャラクターはそれぞれ特殊効果を持つ。特殊効果は戦闘中に1回発動できる。

キャラA
稀に自分の攻撃力の3倍のダメージを与える（失敗した場合は1倍）
キャラB
5連続攻撃を行う
キャラC
自分の攻撃力の1.5倍のダメージを与える

「この事例でのデータの持ち方を考えると、シンプルにひとつのテーブルにまとめる方法がありますよね。もちろん、機能的には問題がなさそうです。

ただし、ここに『5連続攻撃を行う』特殊効果を持った新たなDというキャラクターを追加するときに、『特殊効果説明』を再び書く必要があります。

そこで、有効なのが『正規化』です。正規化とは、簡単に申しあげれば『冗長部分を省こと』を指します。この事例では『特殊効果説明』ですね。

ひとつだったテーブルを『キャラクター』と『特殊効果』のふたつにわけてみましょう。すると、キャラクター側から、特殊効果はIDで参照することができます。その結果、特殊効果説明を何度も書く必要はなくなりますよね。

正規化はテーブル設計によくあるテクニックですが、長期で運用するうえでは欠かすことができないと私は思います」（廣橋さん）

さらに廣橋さんは同じ事例から「機能単位でのコード分割」の重要性を説きます。

「実装において、『特殊効果』と『キャラクター情報』からダメージ値を計算する箇所があります。さきほどは3つの特殊効果を紹介しましたので、if文で分岐させれば問題ないと感じるかもしれません。

しかし、長期にわたって運営すると特殊効果もどんどん追加され、ダメージ値を計算するコードが数百行に及んでしまう可能性があります。すると、コードの流れを追うのがむずかしくなり、新たな効果を追加する難易度が高くなってしまいます。

そこで、特殊効果のIDごとに分割する方法を採用しています。分割を行うことで特殊効果ごとの挙動が明確になり、追加が容易になりました。また、エラーの発生時にも対象が絞れますので、迅速に対応することが可能です」（廣橋さん）

続いて廣橋さんは、正規化やコード分割を行ってもなおリファクタリングが必要になる例を次の通り紹介します。

「同じタイトルにおいて、『これまで1人だった敵を複数に増やす』という仕様の追加がありました。

実装期間が短かったり、大きくリファクタリングするほどでもない仕様の追加であったりすれば、エンジニアとしては既存で動いている部分に影響なく追加したい心理が働きますよね。そこで、極端な例ではありますが、if文で分岐させてしまうやり方をとってしまったりします。

そこにさらに『デッキ内の自分のキャラクターをランダムに回復させたい』という仕様の追加が入ったとしましょう。すると、条件分岐が非常に複雑でわかりにくいものとなってしまうわけです」（廣橋さん）

「実際のリファクタリングにあたっては、やはり機能単位で分割するという基本方針をとりました」と廣橋さん。

最後に「長期運用においては、『テーブル構造をできるかぎり正規化する』『機能単位でコードを分割する』というふたつの設計観点が必要です。

ただし、気をつけて設計してもリファクタリングは必要になるものです。それでもサービスの未来を見据えて企画とエンジニアが話すことで、回避できる可能性もあると認識することも大切です」と講演をまとめました。

廣橋さんの当日の資料はこちらに公開されています。

サービスをリードしていけるエンジニア集団の作り方

最後はDeNA Games Tokyoで技術部部長を勤める平岡さんの登壇です。

平岡洋祐（ひらおかようすけ）／株式会社 DeNA Games Tokyo 技術部 部長。1988年生まれ。和歌山県出身。和歌山大学卒。2011年、新卒で株式会社ディー・エヌ・エーへ入社。2016年にDeNA Games Tokyoへ参画。趣味は「スプラトゥーン2」。

平岡さんのテーマは「サービスをリードしていけるエンジニア集団の作り方」について。そもそも、どのようなエンジニアがサービスをリードできるのでしょうか？平岡さんは次のような特徴を並べます。

プランナーの視点を持っている
事業観点を持っている
何を作るのかに責任を持てる
「おもしろい」を作れる

「サービスをリードすることが、全てのエンジニアに必要であるとは私は考えていません。ただ、DeNA Games Tokyoでゲームを運営するという事業には、サービスリードエンジニアが必要なんです。

例えば、どのようなエンジニアでも気を抜いてしまうと、プランナーから降りてきた要件を開発するだけの構造になりがちですよね。これでは『どのように作るのか』考えるエンジニアの知見が、『何を作るのか』を考えるプランナーに還元されてないため、プロダクトへ反映されないんです。

エンジニアは、情報の整理をして、データを設計して、仕様を切り、プログラムを書きます。この過程は施策のプランニングにも役立つと私は思います。だからこそ、エンジニアが整理した内容をプランナーに還元していくべきなのです。

プランナーと一緒にサイクルを回しながら、『何をつくるのか』へ還元していくことがひとつの方法です。また、『プッシュ通知を送りたい』『リアルタイムランキングがほしい』など、できるかどうかプランナーに判断できないこともあります。エンジニアだけが企画できることもあるわけです」（平岡さん）

それでは、サービスをリードするエンジニア集団をつくるにはどのようにすればいいのでしょうか？平岡さんは、人材を採用するまでの「採用戦略」、採用した人材を育てる「組織戦略」、そしてその人材を評価する「評価戦略」の3つのフェーズから、DeNA Games Tokyoで実践している方法を紹介します。

1. 採用戦略（どのような人物を採用するか）

「サービスリードに限ったことではありませんが、組織として目指していきたい方向性と合わない人は採用しないということが大切です。ここに尽きると言っても過言ではありません。

これは当たり前のように感じるかもしれませんが、実践するのはとても大変です。スキルが高く、例えば『Qiita』でスターをたくさん集めているような人材が応募してきたとしても、マインドが組織に合わなければ採用するべきではありません」（平岡さん）

2. 組織戦略（どのように採用した人と接するか）

「組織として求める行動をメンバーにもとってもえるように、採用した人材にはいかに接すればいいのでしょうか。もちろん、ただ採用するだけではいけないわけです。

マインドを醸成するために必要なことは『何度も伝えること』だと考えています。当たり前すぎてピンとこないかもしれません。しかし、心理学の研究によれば、人間は『日々話す言葉』『日々聞く言葉』によって思考が少しずつ変わっていくのだそうです。

そこで、マネージャーは『いまの施策はおもしろいですか？』『ゲームをおもしろくしたいと考えていますか？』など、組織としてのあるべき姿を何度も何度もメンバーへ伝えることが大切です。それにより、メンバーの行動が日々変わっていくのです」（平岡さん）

3. 評価戦略（どのように評価するのか）

「メンバーに求めるだけで還元をしなければ、当然人材は去っていきます。ですから、適切に評価することが大切なのですが、『適切な評価』は非常にむずかしいものですよね。

私たちDeNA Games Tokyoでは、『Job Grade』という基準を設定しています。そして、全てのジョブに対して『こういうことができていれば、このJob Gradeだ』とわかる早見表のようなものを作っています。

なぜ、この『Job Grade』と早見表を作ったのかといえば、評価における『人依存』を削減するためです。私は人が人を評価する以上『完璧な評価』を実現することは不可能だと考えています。とはいえ、それに近い評価を目指さなければいけませんよね。

そのためには、マネージャー間で確かな共通認識を持って、それぞれの『Job Grade』を定義する必要があると考えています。

マネージャーも人間ですから、メンバーの『頑張り』を評価したくなるものです。しかし、『頑張り』を評価してしまうと、そのメンバーのできることと評価が乖離してしまう結果となります。なぜかというと、頑張りで評価してしまうと、本当に評価すべき能力が伸びた後に評価しにくくなるので、それは誰にとってもいい結果ではありません。

ですから、『成果と能力』をきちんと評価するために、『Job Grade』のような細かな基準が有用だと感じています」（平岡さん）

以上で平岡さんの講演は終了です。当日のスライドはこちらに公開されています。