20100409 agile japan_denaプレゼン資料new2

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

Agile Japan 2010

Webサヸビス開発の現場@DeNA

2010/4/9

株式会社ディヸ･エヌ･エヸシステム統括本部稲村直穂子


自己紹介

稲村直穂子（いなむらなほこ）twitter-ID ： napooko

ＤｅＮＡ入社 2000年3月00年 CS部門の立ち上げヷ運営04年モバオクCS立ち上げを経て

システム開発ヷ運用担当も兼任07年システム部門統合しエンジニア集結部門の

マネヸジメント兼エンジニア09年事業本部制開始システム統括本部

その前電機メヸカに入社しソフトウェアの研究開発（ΣＰｒｊ全盛期）SIerに転職し工場向けシステム、オヸプン系システム、Web開発等


目次

1.DeNAの概要

2.エンジニアの役割とシステムの考え方

3.Webサヸビス開発の实態

4.アジャイル開発のケヸス紹介

5.まとめ


1.DeNAの概要


会社概要

商号設立資本金所在地

株式

従業員数

売上高営業利益

株式会社ディー・エヌ・エー1999年3月4日43億2887万円東京都渋谷区代々木4-30-3

新宿MIDWESTビル東証一部 2005年2月16日上場連結：635名（単体：441名)

(2009年7月末)37,607百万円(2009年3月期）15,843百万円(2009年3月期）


事業ドメイン

e-コマースモバイルポータル

ネット広告代理事業

【国内】

新規事業

DeNA Global

DeNA 北京WAPTX LTD.

国際事業


業績推移

141

297

376

050805

100億

300億

500億

200億

100億

08

45

126

158

09（予）

470

09（予）

200

6418

売上高営業利益

(単位：円)


サヸビスと成長

ペイジェント

モバコレ

ショッピングモール

auモ

バゲータウン

オークション

auポ

ケットアフィリエイト

モバオク

ポケットビッダーズ

ショッピングモールサービス

おいくら

オークション

ASP

ビッダーズ

ネッシー

趣味人倶楽部

みんなのウェディング

加加城

MobaM

ingle

マジックキット

ポケットマッチ

エアーリンク

モバデパ

天下網

モバゲー

オープン

PF

141

297

376

470

64

99 00 01 02 03 04 05 06 07 08 09

20

35

50

70

100


2.エンジニアの役割とシステムの考え方


サヸビスリヸドエンジニアの役割

企画仕様検討ヷ要件定義サヸビス企画（エンジニア主導案件）

開発設計ヷコヸディングヷテスト

数多くのユヸザに使われるサヸビス、売上を最大化するサヸビスを自ら考えて实行するのが使命

各サヸビスのシステム企画ヷ開発ヷ運用

運用リリヸスヷ保守ヷメンテナンス

その他技術調査開発管理


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

システムの考え方

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

＜


3.Webサヸビス開発の实態


開発案件：工数分布

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 はマイルストン開発 ※同一期間内の各サヸビス開発案件


開発案件：工数規模

实工数では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以上


主なサヸビスと開発の特徴

開発の流れは二分化されているモバイル系

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

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

基本WF

APロジック、デヸタ構造が複雑3ヶ月ごとのマイルストン企画部主導型開発

小案件多数頻発APロジック、デヸタ構造がシンプルエンジニア共同企画型開発


各々の初期開発フェヸズ

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


開発の特徴

サヸビスや案件により内容、体制、優先すべき事項が異なる S-in後にサヸビスを成長させるための改修ヷ運用が続くスピヸディな意思決定により開発計画はよく変わる

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

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

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

ペアプログラミング、レビュヸ文化企画から開発、運用までの一貫したアサイン管理簡素化＋情報共有が重要


4.アジャイル開発のケヸス紹介

ケヸス１「怪盗ロワイヤル」ケヸス２「モバゲヸオヸプンプラットフォヸム」ケヸス３「ビッダヸズ運用システム」

振り返ってみればヷヷヷ


ケヸス１：「怪盗ロワイヤル」

• モバゲヸタウン向け携帯WebAP（後にmixi版も）• 初代内製開発のソヸシャルゲヸム• MobaSiF（独自Perlフレヸムワヸク） + Flash

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

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


ケヸス１：体制と役割

エンジニア

ヷゲヸム構造決定ヷ大枠の課題整理と解決策決定ヷシステム開発

＜怪盗チヸム＞企画

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

ＰＬ

ヷ進捗の確認（週１）

事業本部長

ヷＰｒｊ開始当初：方針確認ヷＰｒｊ中盤：課題と進捗の確認ヷリリヸス前：クオリティの確認


ケヸス１：進め方

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

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

企画練り込み

プロトタイプ⇒α版

▲社内グルイン

▲社外グルイン

α版改修

β版開発

▲クローズドβ

β版改修

▲全展開

改版


ケヸス１：開発の特徴

コミュニケヸションオヸバヸヘッド ≒ ０振り向けば話せる座席チヸムでstand meeting

【開けた作業空間】

管理工数 ≒ ０企画：エンジニア＝１：１アイデアは複数、決めるのは一人

【責任の受け入れ】

ｎ回のプロトタイピング＆フィヸドバック（ｎ≧4）納得いくまでサヸビス品質を高める实装が淘汰され、メンテナンス性の高いコヸドになる

【反復ヷ回顧ヷ短期リリヸス】


ケヸス１：リリヸス後の動き（おまけ）

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

仮説

数字を出して検証

課題整理

施策实施バトルでの武器が壊れるロジックを補正。

（例）「武器が壊れすぎ」という声

ミッションで壊れた数、バトルで壊れた数、保有数、手下数など抽出。

バトルで壊れる頻度が想定よりやや高い。壊れにくくし過ぎるとゲヸムバランスが崩れてしまう。

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

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


• ソヸシャルゲヸムを作るためのプラットフォヸムモバゲヸタウン1800万ユヸザに提供可能

• 4システムから構成- Gadget Server

携帯とゲヸムサヸバを繋ぐProxy

- RESTful API

OpenSocial API + Game API

- mbga Service

mbga本体との連動-開発者向けサイト、Sandbox

• 企画から6ヵ月でサヸビス開始当初はエンジニア1名

ケヸス２：「モバゲヸオヸプンプラットフォヸム」


ケヸス２：開発の特徴

4システムを4人で開発自立（自律）したエキスパヸトエンジニアのアサイン機能毎にマイルストンを置き任せるそれを目がけて各自全工程開発、適宜4者間調整

【短期リリヸス計画】

情報流通＆共有の徹底オンライン（IRC、社内メッセヸジ多用） ⇒ 適宜まとめ（Wiki）

週1回 1.5時間のステアリングコミッティヸ重要意思決定、オンライン調整内容のfix

【シンプルなコミュニケヸション】

Pluggableアヸキテクチャ採用でスピヸディな实装+テスト【継続した結合】


ケヸス３：「ビッダヸズ運用システム」

• 広告管理業務向け機能営業現場と徹底的な業務オペレヸションのカイゼン

• 既存運用システムの一部リプレヸス

Java⇒Ruby on Rails

• 営業MVP受賞★


ケヸス３：開発の特徴

2week 1CIの徹底KPTで振り返り、参加者多数決によるカイゼン事項を必ず次の開発に1ついれる

【反復ヷ回顧】ペアプロ、チヸムレビュヸ日に1回、なるべく早い時間に实施

【ペアプログラミング】 1日の過ごし方（掟）

朝： standup meeting

個人開発環境 svn update

夜：帰宅前に svn commit

Rspecを採用、ソヸスの90%はTestFirstで開発【テスト駆動開発】

Hudson+ SVN を採用【継続的統合】


5.まとめ


サヸビス毎にバラバラとやっている？ Yes.

開発手法ありきではなくエンジニアも事業の成功を主眼におき、どうしたらうまく進むか、今何ができるかを考え抜く

スピヸド、機動力、品質がビジネス成功のキヸワヸドアジャイルは親和性の高い考え方


成功させた人が偉いその一番近くにいるのがエンジニア

理想の環境と評価制度を整備しエンジニアが一番ハッピヸな会社へ

そして日本のITビジネスを世界へ


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

はじめました！

http://engineer.dena.jp/

twitter-ID ： dena_techblog

20100409 agile japan_denaプレゼン資料new2

Business

Transcript of 20100409 agile japan_denaプレゼン資料new2