1. ソーシャルアプリ
開発における
チーム開発戦略
「HTML5×スマートフォン」時代の
ソーシャルゲーム戦略
2011/12/03
株式会社gumi 執行役員
技術開発部長 田村祐樹

2. about: gumi
2007年6月に設立。モバイルSNSの会社。
２００９年に４人でソーシャルアプリ開発。
２０１１年現在１３０人超。
ゲームやWeb、SI、様々な経験のある開発チーム
ヒットアプリに関わった企画チーム
高品質なFlashや絵を作り出すデザインチーム
一緒にエンターテイメントを創っていく会社

3. 開発アプリ（一部）

4. 会社の規模感は？
月に数億円の売上げを出すアプリが複数本
８本以上のアプリを運営中
数百万人のユーザーを保持
サーバーは数百台存在しています（Amazon
EC2）
続々、アプリをリリース予定です

5. 技術キーワード
Python
Django
EC2、RDS、SQS
TokyoTyrant
などなど……
ただ、これは固定ではなく変えていきます

6. about: self
やってきたことと言えば
コンシューマゲーム開発（Wii、NDSなど）
Web開発（動画共有サイト）
システム構築（システム会社基盤）
そして、2010/07 gumi
2011/07 開発部長をやってます

7. アジェンダ
HTML5xスマートフォンの規模問題
規模問題を解決するには？
どうしたらいいの、結局のところ

8. 注意点
例えばFlashからHTML5といった具体的な技術手
法はでてきません
自動コンバートツールや手で書くといったケース
もあり、一長一短だからです
技術的にコアな話を期待されたらごめんなさい
HTML5の仕様がどうこうというのもないです

9. HTML5xスマートフォン
の規模問題

10. スマホがもたらす恩恵
圧倒的な表現力
ボタンに変わる自由なインターフェイス
GPUを利用できるグラフィック性能
etc...

11. 得られるリスク
開発規模の増大
開発期間の増大
開発費の増大
etc...
多くの問題は、人、時間、金

12. この変化はどこかで
見たことがある

16. ゲーム業界だ！？

17. この失敗は既に通ったもの
ゲーム業界はSFC→PS→PS2→PS3への変節で
同じように失敗をした
開発規模は増大し、開発者は疲弊し、やっつけで
出したゲームに顧客は不満を持った
失敗した原因の一つはずっと同じような開発を貫
いたため

18. ゲーム業界は
人を大切にしなかった
不眠不休＆安い賃金で働かせたり
残業代や休日出勤手当を出さなかったり
とにかく不実な会社が多かった
（大切にする会社もあるとは思いますよ）

19. ゲーム業界は古いやり方を
捨てられなかった
昔ながらの根性、根性、根性の開発
効率無視の徹夜で頑張るだけ
身体を壊したら他の奴が頑張る
ワンマンチームもたくさん
若手は育たず、老害化する一方

20. じゃ、
ソーシャルアプリ業界は
どうするの？

21. よく耳にするのは、
ミドルウェア、
ゲームエンジン
ゲーム業界では、
とにかく導入が遅かったよね

22. 人も
コストも
時間も
小さくできますよって
言われたりしますが

23. 違います

24. なぜならツールは
万能の道具ではない

25. ゲームエンジンは、
何をもたらすか？
Unreal Engine 3 (Epic Games)
CryEngine (Crytek)
Gamebryo LightSpeed (Emergent Game Technologies)
Torque Game Engine (Garage Games)
Source Engine (Valve)
Unity (Unity Technologies)
コンシューマゲームで有名なエンジンたち

26. 何ももたらさない

27. いいすぎました

28. が、ツールが
ただそこにあっても
幸せにはなれない

29. 銀の弾丸ではない
ゲームエンジンは万能ではない
ゲームエンジンは面白いものをつくるわけではな
い
エンジンの有用性は多くの場合、初期開発速度に
あるだけ
開発を最適化しないと逆に無駄が多くなる

30. 大事なのは
ツールより
使う人間

31. ミドルウェアとは
ミドルウェアは特定の問題を解決するもの
物理計算とか、３Dサウンドとか、ある特化した
問題を解決するためのもの
例えば、Flash→HTML5の動的変換をするものも
ミドルウェアに近い
問題解決の手助けはしてくれるが問題は解決しな
い

32. ゲームエンジンとは
ゲームエンジンは全てを提供するもの
ゲームの「作り方＝フロー」を提供する
逆に言えばゲームエンジンを採用するならそれに
従わなければならない

33. ゲームエンジンは
リッチすぎる事も
逆に何でも創れる訳でもない
最大のメリットは創って壊せるサイクルの速度
デメリットとしては使いこなせない事も
ゲームエンジンの会社が倒産することもあるし

34. Web業界で言えば
intra-martのようなWebアプリフレームワークは
ゲームエンジンのようなもの
CakePHP、Rails、Djangoといった包括的なWeb
フレームワークはゲームエンジン寄り
Smarty、Velocity、iBatis、Strutsといった限定
的なフレームワークやライブラリはミドルウェア
寄り

35. 他にもスマホなら
Titanium Mobile
Corona
Unity
Cocos2D
etc...

36. ツールは必要な時
必要なものを選べば良い
なら大事なのは
それを使える開発体制

37. 大事にすべきもの
効率的な開発体制
柔軟な開発は柔軟な意識に繋がり
柔軟な意識は柔軟な組織を創る
どんな挑戦も苦難も達成する事は力になる
でも、開発体制がしっかりしてなければ耐えられ
ない

38. ならどうする？

39. アジャイル開発？
Webでも
よく言われましたが

40. アジャイルの心の
再確認
アジャイルソフトウェア開発宣言
より引用

41. 顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、
お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。

42. 意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼しま
す。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを
継続的に維持できるようにしなければなりません。

43. 技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
シンプルさ
（ムダなく作れる量を最大限にすること）
が本質です。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを
定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。

44. でも、
それって
単なる理想でしょ？

45. 理想です
でも、理想がなければ
現実は変わらない

46. 考えてみよう

47. 人間は最もコストが高い

48. 良いアプリを
創るのは
人間

49. なら、人間を大事にしたら
勝てるんじゃない？

50. じゃ、人間を
大事にするって？

51. 違います

52. 即ち、
人間を尊重する事
人間の問題を重んじること

53. 人間の問題？
世界は常に変化が起きている
なので人間がついていけないこともある
特にソーシャルアプリは今までにないくらい高速
に時間が過ぎていく
その中で自分たちは問題を解決し、成長していか
なければならない

54. 変化を愛せよ
変化は愛おしいものだ、何故なら停滞はつまらな
いから
ソーシャルアプリは日々進化し続ける
進化し続けるものに完璧はない
なら、完璧を求めず変化を愛せよ
人間だって変化するものなのだから

55. リスクを愉しむ
例えばトム・デマルコ著「熊とワルツを」の言葉
「リスクのないプロジェクトには手をつけるな」
リスクが大きい程チャンスも大きい
リスクは心配するものではなく管理するもの
リスクがない人間も存在しない

56. ユーザーを重んじる
ユーザーも勿論人間
ソーシャルアプリは反応がダイレクト
コミュニティでの反応や問い合わせでのレスポン
スがあまりに高速
ユーザーの為に日々楽しさを提供していくために
何が最善かを考える

57. 自由と軽量な開発は違う
自由な開発は野放図なだけ
責任の所在が曖昧で、ゴールの見えない開発を繰
り返す
軽量な開発はイテレーション（繰り返し）により
実測に基づいた開発サイクルを形成
責任の所在も曖昧ではなく整理されている

58. 予測可能なプロジェクト
なんてものは存在しない
これは理想に過ぎない

59. でも人は決めたがる
この開発なら2000万でできます
三ヶ月で完成させられます
１０人いれば完璧です
お任せ下さい！（キリッ

60. 現実はそんなに甘くない

61. だって人間だもの
メインエンジニアが病気で……＝人はサイボーグ
でも交換可能なツールでもない
想定していたよりもずっと難しいことだったので
＝難易度が不明なのに見積もれる訳がない
要求が増えたので2000万じゃおさまりません
＝最初から要求がFIXしてることなんてありえな
い

62. 現実は実測に基づくべき
いくつかの明確な目標と
優先順位の高い要件を達成するために
振り返りは不可欠

63. GOALへ向かってる筈が
そこはゴールじゃないかも
GOLE

64. じゃ、どうするの？

65. アジャイル開発
やってみよう

66. 基本的な考え
曖昧な時点で確定させず、適切な時期にそれを確
定させよ、曖昧なら曖昧で良い事もある
計画は不確実なのが当然、なら観測しそれを適時
修正せよ
変化する事は確実、ならその変化に対応できる意
識でいればいい

67. 価値のあるもの
駄目な現実：物事が会議やドキュメントによって
決定し、それが動かせない、または意思決定が見
えないところで行われる
解決するには：実際に動いているものこそが大
事、動くものこそが価値のあるものでそれが変わ
る理由は見えるべきで納得できるべき

68. 計画は顧客とする
駄目な現実：丸投げしたら……できてない！
解決するには：短い繰り返しを確実にやる。見積
もりは開発者、優先順位は顧客がする
諦められるものは諦めよう。全部が全部できるわ
けじゃないし、選択と集中が一番
YAGNI（You ain't gonna need it）、機能は必要
となるまでつくらないべき

69. 思いつきで行動しない
あとで使うだろう思って作ったら殆ど使われな
かった（費やした時間の殆どが無駄）
余計な機能をつけるために大事な機能へのリソー
スを失う
予期しない変更に対応するために不必要な複雑さ
は持ち込まない
人生の時間は貴重、なのでいるかわからないもの
より、現実の問題を解決しよう

70. 朝会は
立ってるだけじゃないよ
毎日、１５分位内でスタンダップミーティング
確認するのは、昨日やったこと、今日やること、
問題点の確認
問題点を共有する時間ができ、お互いの１日タス
クが明確になる
チームの意識が高まるのが実感できる

71. 見える化の具体例

72. 全体のタスクの具体化
全体のタスクのボリュームが見えない……
タスクを拾ったりしようにも何が残ってるのやら
さっぱり……
なら、タスクかんばんで見える化しよう
現在の状況のスナップショット！

73. タスクかんばん
タスクの進捗の見える化

74. 日々のズレの具体化
いまどれくらい進んでいるのか、はたまた遅れて
いるのが実感が持てない
リリース直前になって「間に合ってない！！」と
急に騒ぎ出す
なら、バーンダウンチャートで進捗の見える化
残作業時間が見えるようになり、リリース直前で
はなく、事前にリスクに気がつける

75. バーンダウンチャート
日々のズレや終わるかどうかの見える化

76. 見積もりの具体化
スケジュールを切るのがリーダーで自分で勝手に
自分がやったら、で見積もってしまう
見積もりが下手な人に任せて、明らかに短すぎる
見積もり、長すぎる見積もりを立ててしまう
なら、プランニング・ポーカーでみんなで一緒に
見積もろう
ズレが大きい場合、問題点の洗い出しにもなりま
す

77. プランニング・ポーカー
各々の見積もりの見える化

78. お互いを良く知ろう
開発 企画
デザイン

79. 部署毎に座ることはしない
技術開発部、企画制作部といったくくりで座り始
めると軋轢が生じる
チームは必ずひとかたまりになるべき
そうでなければ、お互いの事を良く知る事もでき
ないし、目的を共有できない
コミュニケーション超重要

80. 適材適所の重視
よくある失敗：とりあえず人が足りないので突っ
込んで爆死
人には得意不得意がある、なので、得意なところ
は得意なアサインをしたい
でも、それしか出来ないのも駄目
なら、全体の底上げの為に勉強会などを実施
変化を恐れなければ、蓄積を捨てる力が身につく

81. 忘れないで
プロジェクトが抱える多くの問題は、プロセスや
技術ではなく人に依存する
アジャイルは、開発に有効な抽象的な解決策は存
在しないと仮定し、実測によって答えを求める
なぜなら実測しなければそのチームや組織にとっ
て最適に近い答えは見つからないから

82. ゲーム業界と近い事
本当に欲しいものは最初には見えない
本当に面白いもの、という抽象的な目的にしかな
りえないから
なら、創って壊すをちゃんと繰り返す
駄目な創って壊すは賽の河原の積み石と変わらな
い

83. 目的を具体化しよう
目標達成を具体化するために検証と適応を繰り返
す
検証と適応を繰り返すためには透明性が必須
透明性は評価や報酬の見直しと変化する勇気が必
要

84. 人に基づく
ありがちな組織問題
「○○を使いましょう！」というと検討するだけ
で三ヶ月とか、半年とか1年かかり、しかも駄目
何かを変えようとすると「今までこうやってきた
から」という理由で猛烈に反発される
「こうしたら良くなりますよ」という意見はすべ
て封殺
どうしてそうなるのか？

85. 勇気がないからだよ

86. 君だけで硬質な組織を
変えることはできない
殆どの会社は少しずつ腐っていく
1人で硬質な組織を変えるためには１０年や２０
年といった長い月日がかかる
その１０年をかけて変える価値はあるか？
1人じゃなく、みんなでなら一気に会社は変わる
し、柔軟さを保つこともできる

87. でも、
大変なんでしょ？

88. 大変です

89. 大変だからこそ
達成感がある

90. 大変だからこそ
心が沸き立つ瞬間がある

91. それは世界が
変わるような体験で

92. 組織だけでなく
世界は変えられる
自分たちの手によって

93. まず必要なのは勇気だけ

94. これからgumiが
挑戦してくこと

95. 世界戦略

96. 世界戦略？
EA社（Electronic Arts）との共同開発でゲーム
をリリースしたりしています
海外戦略の一環として、社内に英語の教師を呼び
クラス別授業を行っています
これから目指していくのはFacebook
今日話したことは世界を狙っていくための一つの
手段です

97. なぜ開発体制が
世界戦略の一環なのか
世界の規模は日本の数十倍 数百倍
想定しきれない規模のものを完璧に開発すること
は難しい
なら、繰り返しでそれをクリアしていくしかない
ツールだけでは世界に通用しない、なら体制を世
界に向けて整えていく
ローカライズなんかも必要だしね

98. 世界に挑むにも
勇気がいるからね！

99. まとめ
勝つための組織、勝つためのチーム造りが重要で
す
良いツールは時代によって変わるけど、良い組
織、良いチームは時代では変わらない
業界を良くするためにも良いアプリ、良いチーム
を作っていきましょう！

100. 技術的な課題も沢山
簡単じゃないよ

101. でも、
挑戦するなら今しかない
頑張りましょう！

102. ご静聴
有り難うございました