1. 大規模 JS プロジェクト
ロードオブナイツの
管理手法紹介 (+α)
株式会社 Aiming
東京開発グループ ゼネラルマネージャ
小林 俊仁 (@toshi_k)
2012年11月6日 / Aiming Study #7

2. About: 小林 俊仁
• http://about.me/toshi_k
• オンラインゲームを作って早10年
• 根は web っ子のつもり

3. About: 小林 俊仁
• Community Engine でオンラインゲーム作って (2001∼2003)
• → 中国でオンラインゲーム＆周辺のシステム開発の子会社作って
(2003∼2007)
• → 子会社を閉じて日本に帰ってきて、ゲームのサーバ書いたり技術
コンサルしたり (2007∼2010)
• → チームごと ONE-UP へ (2010)
• → チームごと Aiming へ (2011∼)

4. 最近書いた本（共著）
昨日発売！

5. About: Aiming

6. Games
ロードオブナイツ 剣と魔法の
ログレス
Blade Chronicle

7. Games
クイーンズブレイド RPG三国志
THE CONQUEST

8. ロードオブナイツ
• iOS の RPG/ストラテジー。ブラ三タイプ。
• クライアントは C# + Unity （結構リッチ）
• サーバは PHP。 API と view のあるページの
両方。 札幌の infiniteloop さんに外部委託。

9. 今日の話:
• ロードオブナイツを、 JS + HTML5 アプリ
としてスマートフォンと PC ブラウザに移植
し、両方同時にリリースする際の実例（苦労
話）紹介
• 私はスクラムマスター的な立場
• ここと大体一緒
http://developer.aiming-inc.com/management/lok-html-management-history/

10. 目次: 4つの時代
• 1) マスターストーリーリスト期
• 2-1) 黎明期
• 2-2) ポストイット期
• 3) ストーリーカード期
• 4) Redmine チケット期

11. 1) マスターストーリー
リスト期
2月∼
3ヶ月程度

12. 時代背景
• 他社に開発を委託し、本体アプリ側メンバー
が片手間でサポートして進めていた
• UI は本体同様横持ち前提

13. この頃の測定と共有
• タスクの共有: Google Docs
• 測定対象: ストーリー（本体アプリでユーザが
できることを抽出したもの）
• 測定単位: ストーリーの個数
• 測定結果の共有: Google Docs でバーンダウン

14. こんなかんじで

15. しかし、大きな前提変化が
• 7月中頃にスマフォと PC の
ブラウザ版を同時にリリー
ス。〆切最優先。
• UI
• スマフォ版は縦持ちに変更
• PC 版は専用の別デザイン

16. 体制組み換え
• クライアント開発者は、協力会社含め全員社
内に常駐化。
• 他プロジェクト 2 つを一時停止して人員確
保。全部で 12 人くらいになった。
• Ruby や Haskell で KPI 集積ツールを書い
てたチームと、3D ゲームを作ってたチーム
• サーバ人員も増やしてもらった

17. 2-1) 黎明期
スパイク 準備期間
5月中∼
1週間程度

18. チーム開発の環境整備
• 社内で席替えして全員を1つの場所に
• コードレビューの導入
• レビューのしやすさを考慮し、レポジトリ
を gerrit から GitHub に移行
• ペアプロ導入

19. チーム開発の環境整備
• PC web 版は Unity web player で手を抜け
るか検証したが、やっぱり JS で。
• コードの構造化、メンテナンス性の向上
• CoffeeScript 化
• テストをちゃんと
• Jenkins CI 動かした
• JavaScript: The Good Parts 読書会

20. 変化したこと
• ⃝ 朝会 (daily scrum) • △ バーンダウンチャート
• ⃝ 振り返り • ☓→⃝ TDD
• ⃝ タスクボード • ☓→⃝ ペアプロ
• △ スプリント計画・レ • ☓→⃝ コードレビュー
ビュー
• △ プロダクトバックログ
- 既存

21. 2-2) ポストイット期
5月末∼7月中
2ヶ月弱

22. 内政あれ
• まるで工数の見当がつかない
• → とりあえずユーザ価値
の大きい内政を作ってみ
て、作業負荷を見積もろう
• 後から考えると、最も複雑
な部分から着手することに
なってしまった

23. スプリント
• スプリント #1 開始。
• スプリントゴール:「来週 6/8 (金) までに内
政を動かす」
• 問題: 自分たちの進み具合がよく分からない
• 見える化するため、ポストイット＋タスク
ボードを導入

24. タスクボードの運用
• 思いついた端からポストイットに書いて貼る
• 着手中 → Doing、 完了 → Done
• ストーリーとタスクの結びつきは薄い
• どんどん増えてカオス化したが敢えて継続
• 理由:
• 「チームが前進している感」が出ていた
• 設計変更が多くまだ手探りだった

25. この頃の測定と共有
• タスクの共有:
タスクボード
• 測定対象: なし
• 測定単位: なし
• 測定結果の共有: なし

26. 2週間回してみて問題
• Sprint #2 のゴール「内政・デッキが完全に
動く」は中途半端にしか完成しなかった。
• 作業負荷の見当がつかない状況は変わらず。

27. 超大雑把に見積もってみた
• ベロシティ: 3pt/週
• スマフォ版: 31pt → 10
週間 → 8/末完了
• PC 版: 半分とするとさ
らに 5週間 → 10月完了
• 全然間に合わない

28. 4天王と調整
• 本体アプリ版の開発 • PC 版デザインをス
を縮小し、仕様理解 マフォと同じに
度の高いメンバーが
参加。 • IE8 を切る
© Rasmusson Software Consulting

29. この頃の自分振り返り
• Problem: ワーニングを経営層に事前に出せて
いなかった
• Try: 見積もれていないこと、全く間に合わ
ないことをストレートに公言しよう
• これが言えない程度に自分を守っていた。

30. 小田レビューの導入
• ユーザが遊べる系のタスクは、どこまで作り
こめば終わりなのか？ Done の定義が曖昧。
• Doing → 小田レビュー → Done
• 担保すべき品質の目線を合わせる＆上げる

31. ペアプロ表の導入
• 見積もれない/進みが遅い の原因:
1. JS や CoffeeScript に不慣れ
2. 本体アプリ仕様の把握不足
3. 既存 JS コードの把握不足
• 上記の理解度が高い人にフラグを
立て、朝会でペアを決める
→ 効率的なノウハウ共有が可能に

32. 3) ストーリーカード期
7月中∼末
2週間程度

33. 問題
• このままだと8月のリリースも無理っぽい
• 「全体」が適切な粒度で定量化されておら
ず、「間に合うの？」「間に合わないなら何
をケズればいいの？」という質問に答えられ
ない。
• 手っ取り早く全体を定量化する手法が必要

34. SML 見積り
• 皆で集まって、大中小で大雑把に見積もり、合意にする
• 上手くいった点:
• 見積りポーカーに比べて手間いらず
• 「全部」を定義できた → バーンダウンチャートの作
成が可能に
• M は 2.5 理想人日くらい？的な感覚が共有できた
• 見積もる対象が、「ケズれる」粒度に落ちた

35. こんなかんじ

36. ストーリーカード化

37. この頃の測定と共有
• タスクの共有:
タスクボード
• 測定対象:
ストーリー
• 測定単位:
ストーリーポイント
• 測定結果の共有:
紙バーンダウンチャート

38. サーバ開発との連携
• このプロジェクトが最優先であり、危機感を
持っていることを infinite loop さんにちゃんと
伝えられていなかった
• → 他プロジェクトの作業を止めて、これに全
力投球してもらうことにした。
• 札幌-東京で週例のビデオ会議を開始

39. 4) Redmine チケット期
7月末∼リリースまで
3週間程度

40. 理由
• 問題:
• ストーリーの実装完了よりも、個々のバグが直っ
たかどうかが重要な進捗の指標になってきた
• デバッグチームが大阪にあり、開発チームが東京
と札幌にあった。 これら全体でやり取りができ
る必要があった。
• Skype チャットだと話が流れる → やりとりをチ
ケットにしよう → バグもチケットにしよう

41. この頃の測定と共有
• 測定対象:
バグ
• 測定単位:
個数
• 共有方法:
バーンダウンチャート

42. その後

43. スマフォブラウザ版
• ストーリーカード期に見積
もった 8/3 の mobage
審査提出には間に合わせる
ことができた
• 審査にn回落ちた後、8/24
には正式にリリース
[] 8/3 が出てこないんじゃ

44. PCブラウザ版
[] PC版リニューアル前のSSある？
• 削減された PC 版専用デザインは、リリース
後に開発を再開し、10/頭にリリース

45. できた。

46. まとめ

47. 変化を受け入れる
• どんな手法であれ、固定的な方法論や指標に
しがみつくのは非常に危険。
• フェーズによって計測したいものが変わる
• 管理手法はそれに伴って何度でも変える
• 開発手法を変更をしやすくする土壌:
• 朝会、夕会、スプリント会議、振り返り

48. 管理手法の変化まとめ
タスクの共有 測定対象 測定単位 測定結果の共有
1) マスターストー
Google Docs ストーリー 個数 Google Docs
リーリスト期
ポストイット +
2) ポストイット期 - - -
タスクボード
3) ストーリーカー ストーリーカード ストーリー pt 紙バーンダウン
ストーリー
ド期 + タスクボード (SML) チャート
4) Redmine チ 紙バーンダウン
Redmine チケット バグ 個数
ケット期 チャート

49. やってることの本質
1. 期間内にやることの「全部」は何かを明確に
し、チームのコミットメントとする
2. 進捗を定量化して計測するために最適な指標
を考える
3. バーンダウンチャートとして計測する

50. ありがとうございました
株式会社 Aiming
東京開発グループ ゼネラルマネージャ
小林 俊仁 (@toshi_k)
2012年11月6日 / Aiming Study #7