ソーシャルゲームの開発現場 - ipa · 2020-01-17 ·...

Copyright(c) 2011 DeNA Co.,Ltd.All rights reserved. 1

ソーシャルゲームの開発現場

～ＤｅＮＡのソーシャルゲーム開発における事例～

2011/7/8

株式会社ディー･エヌ･エー

システム統括本部稲村直穂子


目次

1.ＤｅＮＡの紹介

2.エンジニアへの期待とそれを支える環境作り

3.ソーシャルゲーム開発事例

4.まとめ


1.DeNAの紹介


会社概要

商号

所在地

設立

資本金

株式

従業員数

売上高営業利益

：株式会社ディー・エヌ・エー

：東京都渋谷区代々木4-30-3新宿MIDWESTビル

： 1999年3月4日

： 103億92百万円

：東証一部 2005年2月16日上場

：連結：1080名（単体：515名)(2011年3月31日現在)

： 112,728百万円： 56,096百万円

(2011年3月期）


事業ドメインと成長


売上高の推移

(億円)

28 64141

297376

481

0

500

1000

FY2004 FY2005 FY2006 FY2007 FY2008 FY2009 FY2010

1,127


Mobage Yahoo!MobageMobage

忍者ロワイヤルアクアコレクション

etc..

怪盗ロワイヤルガンダムロワイヤル農園ホッコリーナ

etc..

怪盗ロワイヤル Zeroetc..

FeaturePhone PCSmartPhone

プラットフォーム

内製ゲーム

DeNAのビジネス領域(Mobage)

プラットフォーム事業SP、FP、PC向けの mobageプラットフォームを運用

内製ソーシャルゲーム事業自社開発のソーシャルゲームを各デバイス上で展開


2014年に向けた長期ビジョン

「グローバルNo.1ソーシャルゲームプラットフォーム」としてのポジションを確立する


グローバルスマートフォンサービス戦略の構造


スマートフォン向けゲームエンジン「ngCore」


Quiz：ngCoreでできるのは？


Quiz：ngCoreでできるのは？

すべて作成可能（下段は実際にngCoreを利用したゲーム）

ngCore

Not ngCore Not ngCore

ngCore

NowAvailable


◎ 「忍者ロワイヤル」に見る ngCore の外面的なスペック

◎ Client-side は JavaScript ワンソースで開発

◎ Android では高速にアップデート可能

◎ 30fps以上の２D グラフィックス描画

◎ HTML + CSS ではできなかった、

シームレスな映像表現（≠ページ遷移）

◎ 効果音、BGM の再生

◎ アバター表示など、ソーシャル API

◎ スマフォならではのタッチ処理

（タップ / スワイプ / マルチタッチ）

◎ ngCore は「スマートフォンでソーシャルゲームを作る」のに最適

◎ 従来の Webライクな開発スタイルを残しつつ、

◎ 表現の幅が広がったので、様々なアイディアが実現できる

ngCoreの外面的スペック


スマートフォン市場の可能性

国内ゲーム市場におけるスマートフォンの可能性


売上高成長のイメージ


2.エンジニアへの期待と

それを支える環境作り


ネットサービス企業の分類

• 多様なサービス海外向け事業もエンジニア自身が「何を作るか」考える企画やビジネスに関与

• 高トラフィックmbga: 23.9億PV/日（※2010年7月公表時）

2714万人にさくさく届ける

負荷分散技術や性能対策が重要


エンジニアへの期待

リリース＝スタートラインサービス運用の開始


• 自分たちで決める• 作りながら考える• 多くのユーザに届く• 少数精鋭でスピード重視• 全体を見渡しながら• 成長させてなんぼ• コードが武器• 成功させた人が偉い• ビジネスへの挑戦

システムの考え方

• 顧客企業が決める• 決められた通りに作る• 社内業務システム中心• 人月規模重視• 分割・工程別• 作って終わり• ドキュメント重視• マネージャが偉い

＜


組織としてエンジニアを支える環境作り

各自が自分のミッションに集中できる組織を作る• 専門性を集約した組織構成• 適切な権限委譲

• 現場のグループリーダー、チームリーダーが決定権を持つ• 支援のための管理

• チームの状況に応じて管理の濃淡を変える• メンバー自らが課題に気づけるための可視化

• コミュニケーションの仕組みを作る• DailyMTGの定着、チーム間では日次/週次で情報交換

自走できるエンジニアの育成、確保• 企画から開発、運用までの一貫したアサイン

俊敏な対応、リリース• 顧客（ユーザの反応）の示唆を逃さない仕組みづくり• 修正、リリースを迅速にできる体制作り


QualityAssurance

Infrastructure

SocialGame

Data Mining

Platform

SocialGame(SmartPhone)

各ゲームタイトルチーム

特徴）専門性を集約した組織構成

各ゲームタイトルチーム

・各専門性を持った人材をそれぞれの部署に集約しノウハウ蓄積・開発プロセスの中でそれぞれの専門家が有機的に支援

mobage

CustomerService



Common

Team

Designer /

Art Director

Game Team

システム

リーダー

企画

リーダー・方針決定権限・全体の確認、調整

・共通部分・ライブラリ作成

・UIデザイン等相談・素材の決定

・各ゲームの企画、製作・仕様決定

特徴）適切な権限委譲・決定権限は現場に委譲され、リーダー/各チームが握る

⇒各自の裁量範囲が大きく、迅速な意思決定が可能



＊生み出すフェーズ＊育て上げるフェーズ


内製ソーシャルゲームのビジネスインパクト

【 2009年第4四半期（内製ソーシャルゲーム開始～半年）】

*1 広告関連：純広、タイアップ、検索・コンテンツ連動型広告等*2 ゲーム等： mixアプリモバイルのアド/ペイメントプログラムの売上を含む（mixiモバイルからの売上7.0億円）

会員数月間ページビュー（万人）（億PV）

広告関連*1

ゲーム等*2

2009年度

6161,813

売上高

794

1,727

233

376 439

10,068

1,938

1,029 1,038 1,125 1,139

907720

1,131

863

1,8391,441

1,754

2,073

3,577

4Q 1Q 2Q 3Q 4Q

(百万円)

5,375

4,041 4,026

2008年度 2009年度

6,866

0

200

400

600

800

1,000

1,200

1,400

1,600

1,800

4月 7月 10月 1月 3月 4月 7月 10月 1月 3月

2009年度

13,910600

100

200

300

400

500

1,800

600

1,200

アバター販売

成果報酬型広告

生み出す

育て上げる


内製ソーシャルゲーム「忍者ロワイヤル」

• 2011年5月に公開したスマートフォン向けソーシャルゲーム• タップ、スワイプなどスマフォならではのUIとゲーム性• ngCoreエンジンを利用し、JavaScriptで実装

ケータイWebでは出来なかった新しいUI/UXを提供


生み出すフェーズ：スマフォ向けＳＧ開発

【開発の概要】＊企画Start～S-inまで5-6ヶ月＊企画1.5名＋エンジニア3名(うち2名新卒)でチーム発足

【ポイント】① エンジニアが自ら考え自ら作る

・新卒含め全員がアイデア出し、仕様策定に積極的に関与・小回りの効くチームサイズで、各自が裁量権を持って開発

② 開発効率化へのこだわり・複数のスマフォ向け内製SG開発が同時進行しているため、

共通機能の開発はCommonチームが担当・各チームではシェア会を毎日実施

③ エンジニアを活かすディレクション・開発進捗を可視化し状況に応じ適切なディレクションを実施


生み出すフェーズ：①エンジニアが自ら考え自ら作る

＊自走できるエンジニアにより効率良く開発＊仕様を考える人 ≒ 決める人 ≒ 作る人

・新卒でも裁量権をもち、サービスを考えるチャンス・企画とともにエンジニアも仕組みを考え実装する・UIもデザイナー任せではなく、エンジニアも積極的に関与

→仕様は他の誰かによって与えられるものではない

＊クリエイティブな開発・自分の提案がゲームの質に直結し、改善が目で見える

→モチベーションを維持しやすい→自分の課題意識≒仕様変更のため、

変化に対しても前向きな対応

高いモチベーションの維持最大限のパフォーマンスを発揮

サービスの質が向上好循環が生まれる


生み出すフェーズ：②開発効率化

＊開発効率化へのこだわり＊共通機能開発を担うCommonチームの存在

・ngCoreフレームワーク上での初の開発を支える部隊・開発成果の一部は一般公開も（DnLib等）

＊チーム間のシェア会は毎日開催・緊密なコミュニケーション・必要な情報共有は適切に

＊情報共有ツール・バックログ管理：Excel・チケット管理：JIRA・情報共有：trac/Wiki/IRC



Common

Team

Designer /

Art Director

Game Team

System

Leader

Planning

Leader

生み出すフェーズ：③ディレクション

＊進捗90%から進まないなど、隠れた遅延を生まない

＊マイルストンの明確化・何が出来たら完了か、完全Doneの定義を明確に・実装に集中しすぎて本来必要な項目が漏れないよう、残作業を事前に可視化

・メンバーが自己管理しやすい状況を作り出す

＊適切な権限委譲により、各レイヤーですばやい意思決定が可能＊バックログの優先度はグループリーダーに決定権＊決定→実装→評価を素早く繰り返しサービスを練り上げる

＊エンジニアの自主性を引き出すマネジメント＊必要な方針はシェア、その後の進め方はチーム次第＊任せてうまくいかない部分は入り込んで整理


内製ソーシャルゲーム「怪盗ロワイヤル」

• mobage向け携帯WebAP（その後、mixi版，ヤバゲー版、スマフォ版も）

• 初代内製開発のソーシャルゲーム• MobaSiF（独自Perlフレームワーク） + Flash

仲間と一緒に世界のお宝を集める！

ミッションをこなし、悪者をやっつける！


育て上げるフェーズ：ＳＧ開発

【ミッション】売り上げの拡大（ゲームの位置づけによっては要求異なる）

＝ユーザがゲームに飽きない新しい要素を定期的に提供（イベント開催、データ分析、ゲームパラメータ調整が中心。追加機能やリニューアルも）

【運用（≒開発）プロセスの特徴】＊３～４チーム体制、秩序だった大きめチーム体制にシフト＊要件出しは、主に２系統

サービス関係者から広く提案（Redmineへ）客観性、即時性をもつデータ分析による施策立案

＊案件出しとプランニングを小まめに定期的に実施

【ポイント】＊成功タイトルほどリリース後の体制は大きくなっていく

（システムが枯れていくわけではない）＊オペレーション向けのツール開発、共通化を推進


2w 3w1w 4w 5w 6w 7w 8w

育て上げるフェーズ：進め方

＜３チーム体制の例＞

チームリーダー（１名）

┗サブチームA

┗サブチームB

┗サブチームC

• チームリーダーは、開発案件はアサインせず、レビュ、支援に徹する

• 各サブチームはイベント開発を続ける

• イベントの障害対応、データ分析、小改修しつつ、新イベント開発へ

実装/テスト

企画、要件定義

イベント開催期間

サブチームA前回の反応をイベント設計にフィードバック

リアルタイムに反応をフィードバック

実装/テスト


サブチームC 前回の反応をイベント設計にフィードバック

データ分析で得られた

気づきは次回の

イベント設計時も活用

実装/テスト


イベント開催期間

サブチームB前回の反応をイベント設計にフィードバック

リアルタイムに反応をフィードバック


育て上げるフェーズ：案件出しと管理

チーム内の役割を問わず、誰でもアイデアをひとまずRedmineにチケットとして登録

イベント、追加機能、システム保守系タスク、CS部門からの要望、バグ対応など

案件計画会議を2w毎に実施優先順位付け、スケジュール、担当決め


育て上げるフェーズ：施策のPDCA

・自身のプレイ感覚・KPI （お宝流通量、コンプ成功率、バトル数等）・ご意見BOX （ユーザからの意見）

仮説

数字を出して検証

課題整理

施策実施お宝流通量を微増させるよう調整

（例）「お宝が出なさ過ぎてコンプ出来ない」という声

ミッション実施数、お宝バトル数、コンプ済みユーザー数など抽出

お宝の流通量が少なすぎてバトル数≒盛り上がりが低調ただし流通量を増やしすぎると簡単になりすぎる

仮説を立てて数字を見てすぐに動く。エンジニア自身が仮説を整理して、DB抽出や

ログ解析をしたほうが速い。


育て上げるフェーズ：データ分析の活用

【目的】ユーザの反応を分析し、客観性、即時性をもったフィードバックを行う

ｰ KPI定常算出・共有によるビジネス・サービス変化を検知ｰ経営判断・サービス洗練を行うためのデータマイニング実行

【データ分析基盤】Hadoopに分析基盤を構築し、全行動ログ/サービスデータを投入

ｰ行動分析、複数ゲーム間分析、固有ゲーム分析など（従来）ＡｐａｃｈｅログやＤＢ集計が中心。ＰＶ、ＵＵ、機能単位利用度など

ｰマーケティング効果測定（ＴＶＣＭ投下地域）

ｰゲーム設計、イベント設計など新しい仕組みを行う際

分析の仕組みと蓄積されたデータは強力な武器となる

＜参考＞2/22 Hadoop Conference Japan 2011『モバゲーの大規模データマイニング基盤におけるHadoop活用』http://www.slideshare.net/hamadakoichi/hadoop-hadoop-conference-japan-2011-hcj2011


4.まとめ


まとめ：DeNA版アジャイル開発宣言

プロセスやツールより個人との対話を・個人を信頼し、各エンジニアを活かす組織風土・役割の組織化と、チーム間での活発なコミュニケーション

包括的なドキュメントよりも動くソフトウェアを・自走できるエンジニアにより決定→実装→評価を素早く回す・客観性のあるフィードバックを早く得られる仕組みを持つことで

PDCAサイクルを早め、リリースを反復して品質を高められる

契約交渉よりも顧客との強調を・ユーザーのフィードバックは厳密に分析・リアルタイムな反応を見ながら毎日改善を行う

契約に従うことよりも変化への対応を・システムのフェーズに応じて体制を最適化・各自が自身の課題意識に基づき、自然に変化に対応する


最後に：課題意識

画一的なルールの適用がやりにくい面もある・具体的な進め方は各チームに委任している・アジャイルのベストプラクティスを活用できているかは

各チームリーダーのノウハウに依存している部分あり

エンジニアの能力が極めて重要・基準を満たすエンジニアの採用が難しい・ビジネス規模の拡大ペース＞増員ペース

・メンバーは放っておくと目の前の業務に忙殺されてしまいがち・業務上交わりが無いエンジニアとの交流が薄くなりがち

とはいえ・・・教育施策 → 社内勉強会、Hackathon、開発合宿 etc..・交流施策 → DeNA TechTalk (≒LT大会) etc..・同僚エンジニアの目線の高さ → 自然にモチベーションup


引き続き、スピード、機動力を保ち、世の中にインパクトのあるサービス展開を目指す

「人間中心」の考え方で、ビジネス環境の変化に順応しながら

チューニング、アジャストさせていくことが重要

ビジネス成功をエンジニア一人一人も自分自身の目標ととらえ主体的に動き続ける


ご清聴ありがとうございました。

ご覧ください！

http://engineer.dena.jp/twitter-ID ： dena_techblog

ソーシャルゲームの開発現場 - ipa · 2020-01-17 ·...

Documents