GCM#4 ※当日の講義資料を再編集した資料を公開しております。

1. Shuichiro Matsuo
2 0 1 6 年 5 月 1 7 日
過去の変遷から考える
ＤｅｖＯｐｓ型大規模ゲーム開発

2. 1
自己紹介
松尾 秀⼀郎
■2000年付近 フリーランスとして活動
■2007年10月 バンダイナムコゲームスにエンジニアとして入社
■2012年4月 バンダイナムコスタジオに転籍
■2012年4月 転籍後にＰＭ課（現経営企画部）に異動
■2015年4月 ＮＥ技術部（現技術統括本部）へ異動

3. 2
今日のお話
①ゲーム市場の変化
②市場の要求のために変化した開発プロセス
③運営型に適した開発プロセス（アジャイルとＤｅｖＯｐｓ）
④ＤｅｖＯｐｓ型の大規模ゲーム開発をどうやるか？

4. 3
前置き
今日の話は歴史を多分に含んでいますが、歴史の見方は
様々あるので、今日の話はあくまでも「そういう見方をした時
にどうか」に終始した内容です。
当事者によってさまざまな見方があるからこそ、一つの見方
として聞いてもらいたいです。
モバイル開発の今のシーンが、コンソールと同じ局面に立た
されている今だからこそ、歴史を振り返りながら話をしてみる。

5. 4
今日話す「ゲーム」の定義
ゲーム
コンピュータ
ゲーム
アナログ
ゲーム
ＰＣゲーム
業務用ゲーム
家庭用ゲーム
（携帯型含む）
携帯電話ゲーム
（スマホ含む）
ＰＣと表記
アーケードと表記
コンソールと表記
モバイルと表記

6. 5
ゲーム市場の変化

7. 6
0
1000
2000
3000
4000
5000
0
10000
20000
30000
40000
50000
60000
70000
80000
198619871988198919901991199219931994199519961997199819992000200120022003200420052006200720082009201020112012
アミューズメント施設の営業所数
営業所数 設置台数
アーケード市場【営業所数と設置台数】
Resource:アミューズメントジャーナル

8. 7
0
100000
200000
300000
400000
500000
600000
700000
1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012
年度別売上高
アーケード市場【売上高】
Resource:アミューズメントジャーナル

9. 8
0
100000
200000
300000
400000
500000
600000
700000
2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014
国内コンソール市場規模（2000～2012）
国内コンソール市場
Resource:CESA調べ。Winkipediaより

10. 9
0
2000
4000
6000
8000
10000
12000
14000
2011 2012 2013 2014 2015 2016 2017 2018
国内モバイル市場規模(2011〜2018)※2016以降は予測
GREE/DeNA Android/iOS
Resource：AppAnnie2014, CyberZ 2014の情報を元に分析
国内モバイル市場の変化

11. 10
ゲーム市場の変化による作り方への影響
2000年のＰＳ２発売以降、市場規模の拡⼤、マルチプラットフォームへの同
時展開などによって、開発規模が拡⼤。
（→開発の大規模化）
市場規模の拡⼤により、⼤規模開発を短期化させる事で製品の市場投入速
度を上げて利益を短期間で回収する⽅向へ。
（→開発の短期化）
それ以前もあったが、2006年以降のソーシャルゲームの台頭によって、ユーザー
がより⻑く遊んでもらうためのアップデート対応は常態化する。
（→開発後のアップデート必須化）
ＨＱよりもモビリティが重要視される時代へ。
手軽＝短時間でor場所を選ばず。市場のニーズが変化した。
（→これによりアーケード、コンソール離れは加速）

12. 11
市場の変化からくる
作り方の変化

13. 12
【参考】各カテゴリにおける工程の違い
アーケード
企画立案
市場調査
収益計画立案
プロトタイプ制作
ロケテスト
改修
ＱＡ＆Ｄｅｂｕｇ
社内リリース承認
筐体量産
出荷（リリース）
コンソール
企画立案
市場調査
収益計画立案
本制作
ＱＡ＆Ｄｅｂｕｇ
社内リリース承認
社外承認
出荷（リリース）
モバイル
企画立案
市場調査
収益計画立案
本制作
ＱＡ＆Ｄｅｂｕｇ
社内リリース承認
社外承認
運営フェーズへ

14. 13
【参考】各カテゴリにおける工程の違い
アーケード
企画立案
市場調査
収益計画立案
プロトタイプ制作
ロケテスト
改修
ＱＡ＆Ｄｅｂｕｇ
社内リリース承認
筐体量産
出荷（リリース）
コンソール
企画立案
市場調査
収益計画立案
本制作
ＱＡ＆Ｄｅｂｕｇ
社内リリース承認
社外承認
出荷（リリース）
モバイル
企画立案
市場調査
収益計画立案
本制作
ＱＡ＆Ｄｅｂｕｇ
社内リリース承認
社外承認
運営フェーズへ

15. 14
PL
VA
SND
ENG
計画⽴案 スケジュール管理や
詳細仕様の確定と調整）
各セクションで
調整しながら
詳細実装
計画に基づいて量産
計画の検証を
⾏いながら
量産準備
デバッグ
ＱＡ
コンソール開発プロセス
技術検証
提供素材を
元に
システムの構築
修正等
微調整
他PJTへ
（必要に応じてデバッグ）
前PJTの
残務とか
リリース
詳細仕様整合
ボリューム調整等

16. 15
売り切り型【パッケージ開発】とは
基本的に出荷した時点ですべての素材、機能が実装されている。
もし遊べなかった場合は返品も普通にある。→⼤打撃。
「本当のデータ締めはいつですか？」
アート素材などは量産⼯程で遅延が無いよう計画初期段階で⾛る。
仮にアップデートがかからなかったとしても、⼀連のゲームを遊べる状態にする。
これによって、マスターアップは絶対中の絶対に。
デッドライン死守のためならどんなことでもするという開発。
上記を踏まえたうえで、ゲームバランスについても調整済みになっている。
これでうまくバランスできたゲームが「良ゲー」と呼ばれる。

17. 16
PL
VA
SND
ENG
計画⽴案 スケジュール管理や
詳細仕様の確定と調整）
各セクションで
調整しながら
詳細実装
計画に基づいて量産
計画の検証を
⾏いながら
量産準備
デバッグ
ＱＡ
技術検証
提供素材を
元に
システムの構築
修正等
微調整
他PJTへ
（必要に応じてデバッグ）
前PJTの
残務とか
リリース
詳細仕様整合
ボリューム調整等
コンソール開発プロセスの変化【①大規模化】
逆算⻑期化型

18. 17
PL
VA
SND
ENG
計画⽴案 スケジュール管理や
詳細仕様の確定と調整）
各セクションで
調整しながら
詳細実装
計画に基づいて量産
計画の検証を
⾏いながら
量産準備
デバッグ
ＱＡ
コンソール開発プロセスの変化【①大規模化】
技術検証
提供素材を
元に
システムの構築
修正等
微調整
他PJTへ
（必要に応じてデバッグ）
前PJTの
残務とか
リリース
詳細仕様整合
ボリューム調整等
逆算⻑期化型

19. 18
PL
VA
SND
ENG
計画⽴案 スケジュール管理や
詳細仕様の確定と調整）
各セクションで
調整しながら
詳細実装
計画に基づいて量産
計画の検証を
⾏いながら
量産準備
デバッグ
ＱＡ
技術検証
提供素材を
元に
システムの構築
修正等
微調整
他PJTへ
（必要に応じてデバッグ）
前PJTの
残務とか
リリース
詳細仕様整合
ボリューム調整等
コンソール開発プロセスの変化【①大規模化】
⼤量投入型

20. 19
PL
VA
SND
ENG
計画⽴案 スケジュール管理や
詳細仕様の確定と調整）
各セクションで
調整しながら
詳細実装
計画に基づいて量産
計画の検証を
⾏いながら
量産準備
デバッグ
ＱＡ
技術検証
提供素材を
元に
システムの構築
修正等
微調整
他PJTへ
（必要に応じてデバッグ）
リリース
詳細仕様整合
ボリューム調整等
コンソール開発プロセスの変化【①大規模化】
計画に基づいて量産計画に基づいて量産
スケジュール管理や
詳細仕様の確定と調整）
スケジュール管理や
詳細仕様の確定と調整）
技術検証技術検証
前PJTの
残務とか
修正等
微調整
修正等
微調整
詳細仕様整合
ボリューム調整等
詳細仕様整合
ボリューム調整等
詳細仕様整合
ボリューム調整等
提供素材を
元に
システムの構築
提供素材を
元に
システムの構築
各セクションで
調整しながら
詳細実装
各セクションで
調整しながら
詳細実装
各セクションで
調整しながら
詳細実装
各セクションで
調整しながら
詳細実装
各セクションで
調整しながら
詳細実装
⼤量投入型

21. 20
PL
VA
SND
ENG
計画⽴案 スケジュール管理や
詳細仕様の確定と調整）
各セクションで
調整しながら
詳細実装
計画に基づいて量産
計画の検証を
⾏いながら
量産準備
デバッグ
ＱＡ
コンソール開発プロセスの変化【②短期化】
技術検証
提供素材を
元に
システムの構築
修正等
微調整
他PJTへ
（必要に応じてデバッグ）
前PJTの
残務とか
リリース
詳細仕様整合
ボリューム調整等

22. 21
PL
VA
SND
ENG
計画⽴案
スケジュール管理や
詳細仕様の確定と調整）
計画に基づいて量産
計画の検証を
⾏いながら
量産準備
デバッグ
ＱＡ
コンソール開発プロセスの変化【②短期化】
技術検証
提供素材を
元に
システムの構築
修正等
微調整
他PJTへ
（必要に応じてデバッグ）
前PJTの残務とか
リリース
詳細仕様整合
ボリューム調整等前PJTの
残務とかやりながら対応
外部 計画に基づいて量産
外部会社のハンドリング
外部 計画に基づいて実装
外部会社のハンドリング
外部会社のハンドリング
各セクションで
調整しながら
詳細実装

23. 22
PL
VA
SND
ENG
計画⽴案
スケジュール管理や
詳細仕様の確定と調整）
計画に基づいて量産
計画の検証を
⾏いながら
量産準備
デバッグ
ＱＡ
コンソール開発プロセスの変化【③アップデート型化】
技術検証
提供素材を
元に
システムの構築
修正等
微調整
他PJTへ
（必要に応じてデバッグ）
前PJTの残務とか
リリース
詳細仕様整合
ボリューム調整等前PJTの
残務とかやりながら対応
外部 計画に基づいて量産
外部会社のハンドリング
外部 計画に基づいて実装
外部会社のハンドリング
外部会社のハンドリング
各セクションで
調整しながら
詳細実装

24. 23
PL
VA
SND
ENG
計画⽴案
スケジュール管理や
詳細仕様の確定と調整）
計画に基づいて量産
計画の検証を
⾏いながら
量産準備
デバッグ
ＱＡ
コンソール開発プロセスの変化【③アップデート型化】
技術検証
提供素材を
元に
システムの構築
修正等
微調整 他PJTへ
（必要に応じてデバッグ）
前PJTの
残務とか
リリース
詳細仕様整合
ボリューム調整等前PJTの
残務とかやりながら対応
外部 計画に基づいて量産
外部会社のハンドリング
外部 計画に基づいて実装
外部会社のハンドリング
外部会社のハンドリング
各セクションで
調整しながら
詳細実装
アップデート用作業
外部会社のハンドリング
外部会社のハンドリング
外部会社のハンドリング
アップデート用作業
Update用実装
Update毎にQA
追加修正等
Update用実装

25. 24
起きたことまとめ【人材面】
専属化・属人化は加速
→〇スペシャルなプレイヤーを生んだ。
（神がかった各種対応など）
→×他の人でなんとかできないレベルへと昇華した。
必然的に対応できる人材は限られるor枯渇しがちに。
人材育成するにも育成法が特殊すぎ＆大量育成不可
→年月をかけて経験させる or 突然変異を待つ。
→→けど求められる市場投入速度は短期化。
→→→同じ人が作らざるを得ない。

26. 25
起きたことまとめ【技術面】
如何に安定した技術かが最優先
→〇特定の技術をとにかく磨くスタイルが加速。
（一番安定しているのはｔｘｔで1～10まで書いたスクリプトとか）
→×特定条件下のナレッジのみ人に溜まる。
必然的に対応できる人材は限られるor枯渇しがちに。
技術を育成するにも新しい技術投入はリスクがつきもの
→ある程度ライブラリなどしっかりした形まで作る。
→→けど求められる技術が日に日に高度化。
→→→とりあえず安定している技術で作らざるを得ない。

27. 26
起きたことまとめ【プロセス面】
プロセスの複雑化は加速
→〇スペシャルなセクションリーダーを生んだ。
（なんでも知っている神みたいなエンジニアリーダーとか）
→×関係者の増加による決定スピードは低下。
必然的に対応できる人材は限られるor枯渇しがちに。
変更するにも複雑すぎて個別のセクションでは変えられない
→年月をかけて少しづつかえる or トップダウンで変える
→→少し筒変えても効果が薄いのでまた戻る。トップダウンで変
えた場合はプロジェクトチームが壊れる場合も多くある。
→→→今やれている人たちにうまくやってもらうしかない。

28. 27
運営型開発の考え方へのシフト
市場はモバイルにシフト
アップデートされつづける事はＡＣでもＣＳでも常識になる。
→つまりリリースは何度もおきるものだという前提で開発を進め
ていく必要性がでてくる。
今までの考え方や常識（文化）を変えていく必要性にせまられる。

29. 28
運営型に適した開発プロセス
（アジャイルとDevOps）

30. 29
運営型開発の考え方
そもそもリリースはどこでも起きるものだと思え
アップデートは常にされるものであるという考え方に。
ユーザーに価値を届けられる量とその届ける速さを増やすにはど
うしたらいいかという事を常に第１に考えるということ。
→だってゲームは「面白い」を皆で積み重ねたものだから
ただゲーム開発で大事になるのはコンソール開発で鍛えられた
「開発、運営、ぜんぶ自分たちがやる」の考え。

31. 30
PL
VA
SND
ENG
運営するための開発
外部
外部
くぎり くぎり くぎりくぎりくぎり くぎり くぎり くぎり くぎり

32. アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発⽅法を⾒つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
31

33. アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発⽅法を⾒つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
32

34. 33
プロセスやツールよりも個人との対話を
開発プロセスはツールに過ぎない。ツールはチームで取捨選択するもの。
⼀番必要なのはチームメンバー同士での対話の積み重ねであるということ。
ドキュメントよりも動くソフトウェア
ドキュメントは必要なものをつくればよい。いらないものまで作る必要はない。
必要なものの条件は「動くソフトウェアを作るために必要なもの」
そもそも動くソフトウェアこそが進捗そのものであるということ。
契約よりも顧客との交渉を
契約内容に従うことより、顧客の要求に近いソフトウェアを作るための対話が⼤事。
イテレーション単位での評価とフィードバックを元に、要求に近いソフトウェアを開発する事に
価値は存在する。
計画よりも変化への対応を
最初に⽴てた計画は、その時々に応じて必ず変化するもの。
最初にすべての計画を精密に⽴てるのではなく、必要に応じて計画と⾒積もりをする事で
様々な変化に対応できる計画をし続けることが重要であるということ。

35. 34
DevOpsとは、開発（Development）と運用（Operations）が協⼒し、ビジネス要求に対して、
より柔軟に、スピーディに対応できるシステムを作り上げるためのプラクティス
ＤｅｖＯｐｓとは

36. 35
DevOps
ツール
カルチャー
共有
測定
自動化
コラボレーション
開発と運用の役割の違いからの衝突を解消するためには
共有、測定、自動化、コラボレーション、そしてカルチャーが必要。
ＢＴＳやＩＲＣによる関係者
との円滑な対策検討
Ｊｅｎｋｉｎｓなどのツールに
よる徹底的な自動化
パフォーマンス数値分析
FPSや処理速度解析
ポータルなどの情報発信、
集約場所の構築
ＤｅｖＯｐｓを実現する要素

37. 36
DevOps
ツール
カルチャー
共有
測定
自動化
コラボレーション
開発と運用の役割の違いからの衝突を解消するためには
共有、測定、自動化、コラボレーション、そしてカルチャーが必要。
ＢＴＳやＩＲＣによる関係者
との円滑な対策検討
Ｊｅｎｋｉｎｓなどのツールに
よる徹底的な自動化
パフォーマンス数値分析
FPSや処理速度解析
ポータルなどの情報発信、
集約場所の構築
ＤｅｖＯｐｓを実現する要素

38. 37
ＤｅｖＯｐｓにおけるツールの実情はもはや差異がない。
→すでにその領域にある程度達している。もしくはあまり時
間を追わずにゲーム開発は達する。
→コラボレーションについてはもはや自明の理
大規模になればなるほど人の結びつきを薄くする。
→大企業病に代表されるように。
ゲームというのは、「面白い」を皆で積み重ねたもの。
だから積み重ねるための対話が必要。
面白いを積み重ねていく文化をつくるにはどうしたらいいか

39. 38
DevOps型大規模ゲーム開発を
どうやるか

40. 39
どうやるか
結局はカルチャーをどうするかという問題のみになる
つまりお互いの文化を「理解」して新しい文化を「共創」する。
→個人の文化は変えることはできないが、
相互の関係者との対話の間に新しい文化は生成される。
「この人の考えは自分とは違うが言いたいことはわかる」
→この数の総量を増やす活動こそ実は超大事。