ドリコム的railsアプリ開発流儀

Copyright © DRECOM Co., Ltd All Rights Reserved.

ドリコム的 Railsアプリ開発流儀

2012/02/16 エンジニアカフェEvent

ソーシャルゲーム事業本部制作2部大仲能史 a.k.a. onk


2

大仲能史

@onk

自己紹介

ソーシャルゲーム事業本部制作2部


3

アプリケーションエンジニア

自己紹介


4

自己紹介

開発環境

vim

Firefox Nightly (13.0a1)


5

先月の実績

自己紹介


6

Rails歴

約3年

Rails 2.2以降

自己紹介


7

今日の話

今日の話


8

ドリコム的 Railsアプリ開発流儀

今日の話


9

ドリコムで仕事をした気になる

のをゴール

今日の話


10

よろしくお願いいたします

今日の話


11

ドリコムの事業



12

ソーシャルゲーム

広告

ラーニング



13

ソーシャルゲームを運営する

ソーシャルゲーム事業


14

ビジネスモデル



15

毎日ユーザが

訪れて



16

ゲームをプレイして



17

お金を落とす



18

ユーザが飽きたら



19

売上激減



20

飽きさせない



21

至上命題



22

そのための施策

飽きさせないために


23

ユーザ間インタラクションの

強化？



24

毎日の地道な修正/更新？



25

もちろん大事だけど



26

定期的なイベントやキャンペーンが有効



27

期間限定の

アイテム



28

期間限定の

ダンジョン



29

期間限定の

ボス



30

通常のゲームはゴールがない

ので



31

イベントで近くのゴールを提示する



32

コミュニケーションの盛り上がりを作る



33

そんなイベントを月2回実施



34



35

月2回中規模リリース

必須

大事なことなのでもう一度


36

どのぐらいの開発が必要な

のか



37

イベント開発工程を実際に体験してみます



イベント開発

企画

画面遷移図

画面詳細

ER図

38

製造

作りこみ

テスト

リリース


39

画面数20弱

イベント開発


40

Railsエンジニア2～4名で開

発します

イベント開発


41

1アプリにつき10～20名

イベント開発


42

まずは概要説明ミーティング (通称：腹落ちMTG)

イベント開発 – 企画


43

このイベントを選んだ背景社会の状況

ユーザへの想定負荷

KPIへの影響/目標

スケジュール



44

イベントの根幹を一番表しているペラ1資料



45

どこの会社にもある壁一面のホワイトボード

イベント開発 – 画面遷移


46

さっきの画面をまず書いて、ここから遷移を考えていきます



47

勝ったとき、負けたときに演出が必要→swfで表現結果画面は表示項目多そう→HTMLで表現



48

そもそもボスの出現条件は？出現時にインパクトを与えたい→ボス出現swfが必要



49

そもそもイベントの存在を認識させるためのランディングページが必要



50

イベント詳細は必要だよね


ランキングある？報酬とか一覧ページ要るよね


51

複数人で戦うなら一覧画面要るよね

履歴あるなら「もっとみる」要るよね



52

仲間が参戦するためにはまず呼ばなきゃいけない



53

呼ばれた人が参加する導線が要る



54

課金導線



55

画面遷移図完成

イベント開発


56

ここからエンジニアの

ターン

レールに乗る


57

僕らの基本原則

レールに乗る


58

Ride on Rails?

レールに乗る


59

レールに乗るということ

レールに乗る


60

Railsは哲学的な基盤 Opinionated Software

レールに乗る


61

DRY

CoC

MVC

Generator / Scaffold

Write Less Code

RESTful

レールに乗る


62

REST

REST


63

必読

REST


64

Webアプリケーションの機能をリソースに対するCRUD操作

とみなす考え方

REST


65

すべてのリソースはURIで表現される一意なアドレスを持つ

REST


66

Webページの表示

＝

リソースに対するGET操作

REST


67

操作はHTTPの

メソッドで表現可能

REST


68

GET＝副作用なし

GET以外＝副作用あり

REST


69

Railsでは？

REST


70

$ rails g scaffold ¥

entry ¥ title body:text

REST


71

config/routes.rb

REST

resources :entries


72

$ rake routes

entries GET /entries(.:format) entries#index

POST /entries(.:format) entries#create

new_entry GET /entries/new(.:format) entries#new

edit_entry GET /entries/:id/edit(.:format) entries#edit

entry GET /entries/:id(.:format) entries#show

PUT /entries/:id(.:format) entries#update

DELETE /entries/:id(.:format) entries#destroy

REST


73

これが基本形

REST


74

RESTを意識することでURLが自

然と決まる

REST


75

更に Rails特有の文化

REST


76

ModelとControllerが

1:1対応 (異論は認める)

REST


77

RouteとActionとDBが

協調動作

Railsでは


78

URLを見ればどのテーブルにアクセスするか分かる

REST


79

閑話休題

REST


80

画面遷移図

イベント開発


81

画面仕様から ER図を作成

イベント開発 – ER図


82

ユーザがボスを呼び出す



83

参戦者と攻撃履歴



84

参戦依頼



85

ランキング



86

テーブル名は Railsの規則に従う

(habtmは複数形をアルファベット順で繋げる等)



87

カラムは開発中に変更/追加されるので深追いしない



88

関連さえ記載されていれば大体どこにあるか分かる



89

foreign_keyもRailsの規則に従う

ので記載不要 (belongs_to => [model]_id)



90

レールに乗るとドキュメントがシンプルになる



91

Modelが決まり

画面表示内容が決まれば

URLが決まる

イベント開発 – URL設計


92

RESTの原則に従う



93

副作用を与えるActionは Post -> Redirect -> Get



94

攻撃する

=> 攻撃履歴リソースを作る



95

どちらのリソースを操作するかはフィーリングで決める

(URLの対象性を意識することが多い)



96

全画面についてURLを考える



97

開発開始

イベント開発 – 開発


98

決定した

Action、Model

をGenerate



99

$ rails g model RaidBoss ¥

event_id:integer name

$ rails g controller raids show



100

Railsの思想に従いGeneratorで開発

をDrivenする



101

画面間を繋ぐ



102

あとはほぼModelを書く

だけ



103

Skinny Controller, Fat Model

の原則に従う



104

1Actionあたり30min～8h



105

3日ぐらいで最低限遊べる状態を作る



106

リリースまで

あと7日



107

残りの期間を作りこみに当

てる

イベント開発 – 作りこみ


イベント開発

企画

画面遷移図

画面詳細

ER図

108

製造

作りこみ

テスト

リリース


109

ユーザの動きを想像する



110

不要な遷移を

取り除く



111

不要な機能を

取り除く



112

よりイベントが盛り上がるような機能追加



113

前日はまるまるテスト

(が理想)

イベント開発 – テスト


114

社員に対してリリースして遊んでもらう



115

不満を改善



116

リリース

イベント開発 – リリース


117

ログと2chとコミュニティに

張り付き



118

ユーザの声やデータの声を

聴きながら



119

即修正

即deploy



120

打ち上げ！



121

を2週間単位で繰り返す運営スケジュール

次のイテレーションへ


122

繰り返す



123

PDCAサイクル



124

の話はこの後のセッションで



125

おさらい

まとめ


126

レールに乗ることで共通認識が得られる

まとめ


127

1枚の企画書からすぐに行動に移れる

画面遷移とER図、URLさえあれば開発可能

Railsの規約・原則を意識する

まとめ


128

開発は最速で行い、データをもとに改善を回す

まとめ


129

それがドリコム的Railsアプリ開発流儀

まとめ


130

ドリコムでは一緒のレールに乗れるエンジニアを募集

しています

仲間募集


131

ご清聴

ありがとう

ございました

おしまい

ドリコム的railsアプリ開発流儀

Documents