2018年4月27日（金）19時30分より、「【20-30代のエンジニア向け】数百万人超のプレイヤーを抱えるゲーム運営ノウハウを大公開！ー長期運営を見越したシステム設計から、タイトル運営における落し穴の回避策、裏話までー」が開催されました。 

本イベントは、モバイルゲームの「運営」を専門とするDeNA Games Tokyoが主催しています。数々の人気タイトルを運営する同社のノウハウが公開されるとのことで、参加申し込みは即座に定員に到達。当日は、当選した130名以上の方が参加されました。

イベントは、DeNA Games Tokyoの代表取締役社長である井口徹也さんのカンパイから幕を開けました。

登壇者と講演のテーマは次の通りです。

「なぜ私たちは『効率化』を目指すのか」
株式会社 DeNA Games Tokyo 岡井和之さん

「タイトル移管の裏話」
株式会社 DeNA Games Tokyo 高野純知さん

「運営によくある落とし穴とは？」
株式会社 DeNA Games Tokyo 加藤惇樹さん

「長期運用に耐えるための設計とリファクタリング」
株式会社 DeNA Games Tokyo 廣橋俊昭さん

「サービスをリードしていけるエンジニア集団の作り方」
株式会社 DeNA Games Tokyo 平岡洋祐さん

それでは内容をご紹介します！

なぜ私たちは『効率化』を目指すのか

まず1人目は、岡井さんが登壇します。

岡井和之（おかい・かずゆき）／株式会社 DeNA Games Tokyo エンジニア。 モバイルゲームのエンジニアやPMなどの経験を経て、2015年にDeNA Games Tokyoへ入社。

岡井さんの講演のテーマは「効率化との付き合い方」。岡井さんがまず挙げたのは「効率化対象の発見」についてです。「顕在化した問題を解決するのではなく、効率化できるのに無駄を自覚できていないタスクを発見することが大切」と岡井さんは指摘します。

では、その効率化の対象をどのように探せばいいのでしょうか？ 岡井さんは、次の4つの観点から事例と対策などを紹介します。

1. 繰り返し

• いつも同じ作業をしている
  →5回やる、5回以上やりそうだと感じたらスクリプト化を検討する
  →「Excel」「Photoshop」などマクロが使えるツールならマクロ化する
  →画像素材のレギュレーションを決める

• いつも同じレビューをしている
  →コーディングルールを明文化して、全てチェックしてからレビューに出すルールを作る
  →いつも同じ内容のレビューをしているならば、自動生成してそもそもレビューを不要にする

• いつも同じことを聞かれる
  →マニュアルをつくったり、botをつくったりする。botの導入には、コミュニケーションが増えたり、和んだりする効果も

2. 慣習
長期運営になると、昔からやっていることを疑いもせずに続ける、移管したてのタイトルにある

• MTGがやたら多い
  →「Slack」やメールで済ませるなどMTGがいらないフローをつくる →MTGに参加するメンバーを厳選する

• モジュールをコピーして使い回す
  →同じイベントを開催するだけなのにファイルコピーや過去モジュールを落とす作業を毎回しているようならば、マスタを変更するだけで動くようにする

• エンジニアが間に入らないと作業が進まない
  →エンジニアに頼らなくても、「Jenkins」などを活用し、誰でもできるレベルに簡易化する

• 「謎のボタン」を押している
  →突発的なトラブルに対応できなくなるので、謎作業は明らかにする

3. 過剰な汎用性
変更の予定もない機能を汎用化し、作業が増えることがありがち。不要な作業をなくすために、汎用性をつぶしたほうがいい場合もある

4. 属人化
可能な限り、マニュアル化、簡易化、自動化を進める

最後に岡井さんは「なぜ効率化するのか」という問いに、次のように語って講演を終了しました。

「そもそも、効率化を行うことはゲームプレイヤーには全く関係がありませんよね。なぜ私たちが効率化を行うのかといえば、ゲームづくりにかける時間を増やして、おもしろいゲームをプレイヤーに届けるために他なりません。

是非、みなさんもプレイヤーのためにおもしろいゲームがつくれるよう、効率化を進めてください」（岡井さん）

岡井さんのスライドはこちらに公開されています。

タイトル移管の裏話

次に高野さんが2人目として登壇します。

高野純知（たかの・まさとも）／株式会社 DeNA Games Tokyo エンジニア。1985年生まれ。SIer、ゲーム開発企業での勤務を経て、2017年にDeNA Games Tokyoへ入社。趣味はゲームづくり。

高野さんの講演テーマは「タイトル移管」について。「タイトル移管」とは、ゲームの運営を他社に移すことですが、「DeNA Games Tokyoでは、移管後に開発するところまでをタイトル移管のゴールにしています」と高野さん。

このタイトル移管の流れを、高野さんは次のように説明します。

1. 移管元の別会社と、移管後のオーナーでゴールなどをすり合わせる
2. ゴール定義する
3. 人員計画を作成して、移管に取り掛かる

高野さんはDeNA本社からの移管案件の事例を紹介します。
「DeNAからの移管案件では、エンジニアとしての移管ゴールは開発難易度を目安に定義されました」と高野さん。この「開発レベル」は具体的には次の通りです。

C: 既存機能の改修がサポートありで可能
B: 既存機能の改修が自力で可能
A: ゲームサイクルが変わるレベルの新規機能追加が可能
S: Aレベルの難易度で、Aレベル以上に規模感が大きいもの

「当初は、この開発レベルを目安として『B、Cレベルの開発ができること』、さらに『運用部分のリリースができること』と、プロデューサーからエンジニアの移管ゴールが定義されました。

ある程度期間もありましたし、イベントさえリリースできればOKですから、『余裕があるな』と当初は感じましたね」（高野さん）

しかし、高野さんは「これでいいんだっけ？」と考えを直します。それは「Bレベル」「Cレベル」の捉え方がメンバーによって異なり、移管終了後、レベル感に差異が出そうだと思ったからです。

そこで高野さんは、移管後にどうあるべきか、理想のゴールを設定してからやるべきことを定義し、より具体的に移管ゴールを明確化します。

「全体として目指すべきは『移管前とクオリティを変えず、プレイヤーに楽しんでもらえるゲームを提供し続ける』ということです。それを達成するためには、『プレイヤーを飽きさせないようにマンネリ化を避ける術が身についていること』『イベントを移管前と変わらずリリースできること』『何か問題が発生した際に修正できること』が必要です」（高野さん）

このように考えた高野さんは、具体的に下記をエンジニアの移管ゴールに置き換えます。

■移管ゴール

• 既存機能を改修できる開発力を身につける
• 既存機能の延長で新しい機能を加えられるくらいの開発力を身につける
• 安定した運営ができる
• Android/iOSのログが追える
• 修正による影響調査ができる

移管ゴールを明確化した高野さんは、さらにこの移管ゴールから下記のようにタスクまで落とし込みを行います。

■移管タスク

• 各機能について実装が理解でき、修正する
• マスタ、プレイヤーデータの定義追加ができる
• 運営におけるエンジニアの作業の洗い出しができる
• 各作業における手順がわかる
• 各運営業務ツールの内容を把握し、修正することができる
• 「Xcode」の使い方がわかる

次に高野さんは「作業手順書の作成と整理」について紹介します。

「この移管案件は、今でも多くの新規機能開発を行っています。そのため、移管前の各メンバーに開発・運用のナレッジが属人化しているような状況でした」（高野さん）

この状況での課題とアクションを、高野さんは次の通り説明します。

＜課題1＞
開発が優先され、機能を理解するための資料がほぼ存在しない

■アクション

• 自分の理解を深めるための資料を作り、学んだことを移管メンバーにシェア。全体のレベルアップを図る
• 後からアサインされた人でも理解できる書き方、レベル感で記載する

＜課題2＞
開発・運用のナレッジが各メンバーに溜まっている（最低限の資料はあるが、散財しているためにどこにどの手順があるのかがわかりにくい）

■アクション

• 「Confluence」のページ階層を見直す
• 問い合わせ単位、工数単位などでインデックスとなるページを作成
• 各移管メンバーが疑問に思ったこと、詰まった点を手順書に追記作成することを徹底

最後に高野さんは「移管時に行ったことは、あくまで『作業の把握』に過ぎません。現在は、自動化の範囲を検討し、半自動化と手順の見直しを進めています。将来的には、全自動化を達成できればと思います」と講演をまとめました。

当日の高野さんの登壇資料はこちらに公開されています。

運営によくある落とし穴とは？

続いて3人目は、加藤さんが登壇します。

加藤惇樹（かとう・じゅんき）／株式会社 DeNA Games Tokyo エンジニア。1991年生まれ。SEとしての経験を経て、2015年にDeNA Games Tokyoへ入社。趣味は「スプラトゥーン」と「ぷよぷよ」。

「運営によくある落とし穴」と題してスタートした加藤さんの講演。加藤さんはまず前提として「運営が何を行っているのか」を説明します。

「私が担当しているのは、運営8年目になるブラウザゲームです。このタイトルでは、簡単に言えば1ヶ月に1回イベントをリリースするのが運営の役割です。

イベントオーナーは、企画が出たらまず1ヶ月で実装できるかどうかの見積もりを行います。1ヶ月で実装できそうならα開発に入り、β開発、QAチェックを経てリリースです。

もちろん、モバイルゲームは毎日運営していますので、その間にサービス監視をするのも運営の役割です。

イベントオーナーは、このサイクルを毎月繰り返し行うわけですが、1ヶ月という期間ではできることも限られていますよね。そのため、同じイベントを再利用することも多くあります。モジュールのコピーによってイベントを開催したり、マスタによる開催制御を行っているわけです」（加藤さん）

続いて加藤さんは、「運営の落とし穴」としての「あるある」を6点挙げます。具体的には次の通りです。

■あるある1
モジュールをコピーして運用した結果、デザインが変わってしまった

「モジュールをコピーし、event_id を、例えば『123』から『124』に書き換えて運用していたんです。すると、CSS内の『123』という値まで『124』に変わってしまい、デザインが崩れてしまいました」（加藤さん）

■あるある2
event開催マスタで制御していたら負荷が高くなった

「モジュールをコピーして、event開催をデータベースで制御していたんです。しかし、8年にもわたって運営しているタイトルなのでイベントの数が貯まってしまいます。その結果、『event_id 123を開催しますか？』『event_id 124を開催しますか？』のように毎回チェックが入り、全てのページの負荷が高くなってしまいました」（加藤さん）

■あるある3
乱数でつくったKeyを使用してvalu管理していたら、乱数がかぶってしまった

「通常、乱数がかぶることはほとんどないと思います。この場合の乱数では0.001％の確率です。しかし、8年という長期の運用をしている中でその0.001％が起きてしまったんです」（加藤さん）

■あるある4
ログインボーナスが2000日までしか用意されていなかった

「これも長期運用ならではの『あるある』ですね」（加藤さん）

■あるある5
毎月開催のイベントを作ったら次月リセットされずに前月のデータが残ったままだった

「これはかなりの『あるある』だと思います。今月開催したイベントを、また翌月に開催することがあると思いますが、そのときに前月のランキングが残ったままになっていたりします」（加藤さん）

■あるある6
既存イベント改修の反映作業中、既存イベントでエラーが大量に発生した

最後に加藤さんは、こうした運営上の「落とし穴」を回避するのための「考え方・動き方」を次のように話して、講演をまとめました。

「大切なことのひとつは、削除まで考えた設計をすることです。自分が書いたコードがどのようになくなるのかを想定して設計する必要があるわけです。

例えば、『マスタをリセットして再利用するのか？ それともレコードを増やすならばどのタイミングで消すのか？』『同じモジュールを再利用するのか？ それともコピーして使うのであればどのタイミングで消すのか？』といったことですね。

求められるのは、ライフサイクルを意識した運用設計とコード設計です。もちろん、様々な事例を知ることも勉強になりますので、今日の話が少しでも役立てばうれしいです」（加藤さん）

加藤さんの当日のスライドはこちらに公開されています。