ビジネス環境の変化に俊敏に応えるソフトウェア開発 - ipa · 2020-07-01 ·...

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

第5回要求シンポジウム

ビジネス環境の変化に俊敏に応えるソフトウェア開発

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

2011/3/8

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

システム統括本部

稲村直穂子


目次

1. ＤｅＮＡの紹介

2. エンジニアへの期待とシステムの考え方

3. アジャストさせる開発手法

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

5. 今後にむけて


1.DeNAの紹介


会社概要

商号

所在地

設立

資本金

株式

従業員数

売上高営業利益

：

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

：

東京都渋谷区代々木4-30-3

新宿MIDWESTビル

：

1999年3月4日

：

103億8137万円

：

東証一部

2005年2月16日上場

：

連結：839名（単体：499名)

(2010年12月31日現在)

：

48,105百万円

：

21,265百万円

(2010年3月期）


事業ドメインと成長


売上高の推移

(億円)

28 64141

297376

481x4

0

500

1000

FY2004 FY2005 FY2006 FY2007 FY2008 FY2009 FY2010

2423 months

1000超

の見通し


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

システムの考え方


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

• 多様なサービス海外向け事業も

エンジニア自身が「何を作るか」考える

企画やビジネスに関与

• 高トラフィック mbga:

23.9億PV/日（※2010年7月公表時）

2448万人にさくさく届ける負荷分散技術や性能対策が

重要


エンジニアへの期待

リリース＝スタートライン

サービス運用の開始


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

システムの考え方

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

＜


3.アジャストさせる開発手法

＊２分化された歴史＊大きめアジャイルの登場


開発案件：工数別案件分布（1年前）

100人日以下の案件がほとんど

モバイル①では、10人日以下の細かい案件が頻発

0.0

100.0

200.0

300.0

400.0

500.0

600.0

700.0

800.0

0 50 100 150 200 250 300 350

開発案件数

工数

（人

日）

モバイル①(Perl)

モバイル②(Perl)

モバイル③(Perl)

モバイル④(Perl)

EC①(Java)

EC②(Java)

100over はゲーム開発

200over はマイルストン開発 ※同一期間内の各サービス開発案件


開発案件：工数別実ボリューム（1年前）

工数では60d（3人月）以上の占める割合に開き EC（Java）系サービスではマイルストン開発が中心

モバイル（Perl）系サービスでは小案件の積み上げ

※同一期間内の各サービス開発案件

0% 20% 40% 60% 80% 100%

モバイル①(Perl)

モバイル②(Perl)

モバイル③(Perl)

モバイル④(Perl)

EC①(Java)

EC②(Java)

～5d

～10d

～20d

～40d

～60d

60d以上


主なサービスと開発の特徴（1年前）

開発の流れは二分化されている

モバイル系

スピードと機動力がポイント、ユーザビリティが生命線

EC系

ステークホルダー、お金・個人情報の取り扱いの多さ

基本WFAPロジック、データ構造が複雑3ヶ月ごとのマイルストン

企画部主導型開発

小案件多数頻発APロジック、データ構造がシンプル

エンジニア共同企画型開発


0

200

400

600

800

1000

1200

1400

1600

1800

2000

0 20 40 60 80 100 120 140 160 180

開発案件数

工数

（人

日）モバイル系

EC(Java)系

モバゲー①

モバゲー②

開発案件：工数別案件分布（最近）

大きめ案件の件数増大プラットフォーム開発、大型提携案件、リファクタリング等

モバイルに加え、PC,スマートフォン向け新規開発

60人日以下の小規模改修案件多数


従来モバ系で少なかった大きめ案件複数登場

機能追加・改修多発


開発案件：工数別実ボリューム（最近）

同サービスでも開発の新規性、新デバイスにより規模感に差

大きめアジャイル開発期


0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

モバゲー②

モバゲー①

EC（Java）系

モバイル系

～5D

～10D

～20D

～40D

～60D

60D～


アジャストさせる開発手法

サービスや案件により内容、体制、優先すべき事項が異なる

S-in後に事業を成長させるための改修・運用が続く

スピーディな意思決定により開発計画はよく変わる

画一的に枠にあてはめる開発ではロスが多い人材の流動性必要インフラ技術、Quality Assurance、CSなど共通基盤カバー

細かい案件が同時並行で頻発、作りきり案件も

上流から下流まで全て1人でこなせるエンジニアが主役そのための育成環境がmust

ペアプログラミング、レビュー文化企画から開発、運用までの一貫したアサイン

管理簡素化＋情報共有が重要


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

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


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

【

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

アバター販売

成果報酬型広告

生み出す

育て上げる


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

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

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

+ Flash

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

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


ＳＧ開発：生み出すフェーズ

【初期要求】ゲームテーマ

＋

売り上げ規模

【開発プロセスの特徴】＊企画1名＋エンジニア1名でチーム発足

＊要件・仕様は、最後までブラッシュアップされる＊メンバー提案のゲームテーマ採用もあり

＊ｎ回のCI＋段階的リリース＋ＫＰＴ振り返り＊非機能要求（インフラ性能、セキュリティ対策等）の実現は、

既存共通基盤技術を活用

【ポイント】＊どのフェーズでも作ったものを捨てる勇気必要

＊新規サービスはとことん練り上げる＊スケジュール厳守して妥協リリースしても成功は見えない


生み出すフェーズ：体制と役割

エンジニア

・ゲーム構造決定・大枠の課題整理と

解決策決定・システム開発

＜怪盗チーム＞企画

・策の詳細落とし込み・各種調査・文言作成・外部クリエータ管理・社内調整（法務、CS、QA）

ＰＬ

・進捗の確認（週１）

事業本部長

・Ｐｒｊ開始当初

：方針確認

・Ｐｒｊ中盤

：課題と進捗の確認

・リリース前

：クオリティの確認


生み出すフェーズ：進め方

• 企画start～全開放S-inまで4-5ヶ月• エンジニア1名＋企画1名でstart

途中で各1名、後半に協力会社1名追加• 約20,000step

企画

練り込み

プロトタイプ⇒α版

▲社内グルイン

▲社外グルイン

α版改修

β版開発

▲クローズドβ

β版改修

▲全展開

改版


生み出すフェーズ：開発の特徴

コミュニケーションオーバーヘッド

≒

０振り向けば話せる座席

チームでstand meeting 【開けた作業空間】

管理工数

≒

０企画：エンジニア

＝

１：１アイデアは複数、決めるのは一人

【責任の受け入れ】

ｎ回のプロトタイピング＆フィードバック（ｎ≧4）

納得いくまでサービス品質を高める実装が淘汰され、メンテナンス性の高いコードになる

【反復・回顧・短期リリース】


ＳＧゲーム：育て上げるフェーズ

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

＝

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

【運用（≒開発）プロセスの特徴】＊２チーム体制、秩序だった大きめチーム体制にシフト

＊要件出しは、主に２系統サービス関係者から広く提案（Redmineへ）

客観性、即時性をもつデータ分析による施策立案＊案件出しとプランニングを小まめに定期的に実施

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

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


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

実装/テスト

企画、要件定義

イベント開催期間

サブチームA

実装/テスト


イベント開催期間

サブチームB

実装/テスト


サブチームA

育て上げるフェーズ：進め方＜２チーム体制の例＞

チームリーダー（１名）

＋メンバー（３名）

┗サブチームA

：

Xさん、Yさん

┗サブチームB

：

Xさん、Zさん

• チームリーダーは、開発案件はアサインせず、

レビュ、支援に徹する

• Xさんは、開発し続ける

• Yさんは、イベントの障害対応、データ分析、

小改修しつつ、新イベント開発へ


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

チーム内の役割を問わず、誰でもアイデアをひとまず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


5.今後に向けて


スマートフォン市場の拡大・普及


世界のソーシャルゲーム市場の伸び

Virtual Goods Revenue Estimates

265621

1,0871,547

2,0192,462

1,060

1,598

2,020

2,523

3,028

3,644

0

1,000

2,000

3,000

4,000

5,000

6,000

7,000

2008 2009 2010 2011 2012 2013

$ M

M

出展：Virtual Goods News


ソーシャルゲーム業界の世界リーダー比較

※※出展：株式会社ディー・エヌ・エー：平成出展：株式会社ディー・エヌ・エー：平成2323年年33月期月期

第第22四半期決算説明会資料四半期決算説明会資料

独自の位置づけと高い収益性を誇る

http://www.c-direct.ne.jp/public/japanese/uj/pdf/10110213/20101031190470.pdf


ＤｅＮＡの海外戦略

× ×スマートフォンVirtual

CommunitySocialGame

・iPhone･Android

1-2年はアプリ中心その後Web(html5)中心か？


DeNAのポジション

端末

OS

アプリ

Blackberryi OS oviwindows

mobileAndroid ・・

・・

platform


国内外に、PC/携帯/Smartphone一気通貫でのサービス展開を実施

PCPC

モバイルモバイル

スマートフォン

スマートフォン

中国中国日本日本 US（英語圏）US（英語圏）

Yahoo!モバゲー

for Smartphone


まとめ

ビジネス要件の明確化世界を見て戦える目的やポジション、目標数値の明確化

（出展）

ITmediaNEWSより抜粋

システム要件は少数で決定ビジネス要件を腹落ちさせ、システムに具現化できるエンジニア

開発プロセスはどこまでも手戻りある前提機動力のある組織＝スピーディに作れる技術＋動ける体制

品質は共通基盤化しビジネス成長のスピードを落とさない非機能要求の実現、システムリスク対策は共通体制で盤石化


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

体制、開発手法は、ビジネス要件に合わせチューニング、アジャストさせていくことが重要

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


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

ご覧ください！

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

dena_techblog

ビジネス環境の変化に 俊敏に応えるソフトウェア開発 - ipa · 2020-07-01 ·...

Documents

ビジネス環境の変化に俊敏に応えるソフトウェア開発 - ipa · 2020-07-01 ·...