大規模JSプロジェクト ロードオブナイツの管理手法紹介 2012-11-06

大規模 JS プロジェクトロードオブナイツの管理手法紹介 (+α)

株式会社 Aiming東京開発グループ ゼネラルマネージャ

小林 俊仁 (@toshi_k)2012年11月6日 / Aiming Study #7

About: 小林 俊仁

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

About: 小林 俊仁

• Community Engine でオンラインゲーム作って (2001～2003)

• → 中国でオンラインゲーム＆周辺のシステム開発の子会社作って (2003～2007)

• → 子会社を閉じて日本に帰ってきて、ゲームのサーバ書いたり技術コンサルしたり (2007～2010)

• → チームごと ONE-UP へ (2010)

• → チームごと Aiming へ (2011～)

最近書いた本（共著）

昨日発売！

About: Aiming

Games

ロードオブナイツ 剣と魔法のログレス

Blade Chronicle

Games

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

ロードオブナイツ

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

今日の話:

• ロードオブナイツを、 JS + HTML5 アプリとしてスマートフォンと PC ブラウザに移植し、両方同時にリリースする際の実例（苦労話）紹介

• 私はスクラムマスター的な立場• ここと大体一緒

http://developer.aiming-inc.com/management/lok-html-management-history/

目次: 4つの時代

• 1) マスターストーリーリスト期• 2-1) 黎明期• 2-2) ポストイット期• 3) ストーリーカード期• 4) Redmine チケット期

1) マスターストーリーリスト期

2月～3ヶ月程度

時代背景

• 他社に開発を委託し、本体アプリ側メンバーが片手間でサポートして進めていた

• UI は本体同様横持ち前提

この頃の測定と共有

• タスクの共有: Google Docs• 測定対象: ストーリー（本体アプリでユーザができることを抽出したもの）

• 測定単位: ストーリーの個数• 測定結果の共有: Google Docs でバーンダウン

こんなかんじで

しかし、大きな前提変化が

• 7月中頃にスマフォと PC のブラウザ版を同時にリリース。〆切最優先。

• UI• スマフォ版は縦持ちに変更• PC 版は専用の別デザイン

体制組み換え

• クライアント開発者は、協力会社含め全員社内に常駐化。

• 他プロジェクト 2 つを一時停止して人員確保。全部で 12 人くらいになった。

• Ruby や Haskell で KPI 集積ツールを書いてたチームと、3D ゲームを作ってたチーム

• サーバ人員も増やしてもらった

2-1) 黎明期スパイク~準備期間

5月中～1週間程度

チーム開発の環境整備

• 社内で席替えして全員を1つの場所に• コードレビューの導入• レビューのしやすさを考慮し、レポジトリを gerrit から GitHub に移行

• ペアプロ導入

チーム開発の環境整備• PC web 版は Unity web player で手を抜けるか検証したが、やっぱり JS で。

• コードの構造化、メンテナンス性の向上• CoffeeScript 化• テストをちゃんと• Jenkins CI 動かした• JavaScript: The Good Parts 読書会

変化したこと• ◯ 朝会 (daily scrum)• ◯ 振り返り• ◯ タスクボード• △ スプリント計画・レビュー

• △ プロダクトバックログ - 既存

• △ バーンダウンチャート• ☓→◯ TDD

• ☓→◯ ペアプロ

• ☓→◯ コードレビュー

2-2) ポストイット期

5月末～7月中2ヶ月弱

内政あれ

• まるで工数の見当がつかない• → とりあえずユーザ価値の大きい内政を作ってみて、作業負荷を見積もろう

• 後から考えると、最も複雑な部分から着手することになってしまった

スプリント

• スプリント #1 開始。• スプリントゴール:「来週 6/8 (金) までに内政を動かす」

• 問題: 自分たちの進み具合がよく分からない• 見える化するため、ポストイット＋タスクボードを導入

タスクボードの運用

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

この頃の測定と共有

• タスクの共有:タスクボード

• 測定対象: なし• 測定単位: なし• 測定結果の共有: なし

2週間回してみて問題

• Sprint #2 のゴール「内政・デッキが完全に動く」は中途半端にしか完成しなかった。

• 作業負荷の見当がつかない状況は変わらず。

超大雑把に見積もってみた

• ベロシティ: 3pt/週• スマフォ版: 31pt → 10週間 → 8/末完了

• PC 版: 半分とするとさらに 5週間 → 10月完了

• 全然間に合わない

4天王と調整

•本体アプリ版の開発を縮小し、仕様理解度の高いメンバーが参加。

• PC 版デザインをスマフォと同じに

• IE8 を切る© Rasmusson Software Consulting

この頃の自分振り返り

• Problem: ワーニングを経営層に事前に出せていなかった

• Try: 見積もれていないこと、全く間に合わないことをストレートに公言しよう

• これが言えない程度に自分を守っていた。

小田レビューの導入

• ユーザが遊べる系のタスクは、どこまで作りこめば終わりなのか？ Done の定義が曖昧。

• Doing → 小田レビュー → Done• 担保すべき品質の目線を合わせる＆上げる

ペアプロ表の導入

• 見積もれない/進みが遅い の原因:1. JS や CoffeeScript に不慣れ

2. 本体アプリ仕様の把握不足

3. 既存 JS コードの把握不足

• 上記の理解度が高い人にフラグを立て、朝会でペアを決める→ 効率的なノウハウ共有が可能に

3) ストーリーカード期

7月中～末2週間程度

問題

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

• 手っ取り早く全体を定量化する手法が必要

SML 見積り

• 皆で集まって、大中小で大雑把に見積もり、合意にする• 上手くいった点:• 見積りポーカーに比べて手間いらず• 「全部」を定義できた → バーンダウンチャートの作成が可能に

• M は 2.5 理想人日くらい？的な感覚が共有できた• 見積もる対象が、「ケズれる」粒度に落ちた

こんなかんじ

ストーリーカード化

この頃の測定と共有• タスクの共有:タスクボード

• 測定対象:ストーリー

• 測定単位:ストーリーポイント

• 測定結果の共有:紙バーンダウンチャート

サーバ開発との連携

• このプロジェクトが最優先であり、危機感を持っていることを infinite loop さんにちゃんと伝えられていなかった

• → 他プロジェクトの作業を止めて、これに全力投球してもらうことにした。

• 札幌-東京で週例のビデオ会議を開始

4) Redmine チケット期

7月末～リリースまで3週間程度

理由

• 問題:• ストーリーの実装完了よりも、個々のバグが直ったかどうかが重要な進捗の指標になってきた

• デバッグチームが大阪にあり、開発チームが東京と札幌にあった。 これら全体でやり取りができる必要があった。

• Skype チャットだと話が流れる → やりとりをチケットにしよう → バグもチケットにしよう

この頃の測定と共有

• 測定対象:バグ

• 測定単位:個数

• 共有方法:バーンダウンチャート

その後

スマフォブラウザ版

• ストーリーカード期に見積もった 8/3 の mobage 審査提出には間に合わせることができた

• 審査にn回落ちた後、8/24 には正式にリリース

[] 8/3 が出てこないんじゃ

PCブラウザ版

• 削減された PC 版専用デザインは、リリース後に開発を再開し、10/頭にリリース

[] PC版リニューアル前のSSある？

できた。

まとめ

変化を受け入れる

• どんな手法であれ、固定的な方法論や指標にしがみつくのは非常に危険。

• フェーズによって計測したいものが変わる• 管理手法はそれに伴って何度でも変える• 開発手法を変更をしやすくする土壌:• 朝会、夕会、スプリント会議、振り返り

管理手法の変化まとめ

タスクの共有 測定対象 測定単位 測定結果の共有

1) マスターストーリーリスト期

2) ポストイット期

3) ストーリーカード期

4) Redmine チケット期

Google Docs ストーリー 個数 Google Docs

ポストイット +タスクボード

- - -

ストーリーカード + タスクボード

ストーリー ストーリー pt (SML)

紙バーンダウンチャート

Redmine チケット バグ 個数 紙バーンダウンチャート

やってることの本質

1. 期間内にやることの「全部」は何かを明確にし、チームのコミットメントとする

2. 進捗を定量化して計測するために最適な指標を考える

3. バーンダウンチャートとして計測する

ありがとうございました株式会社 Aiming

東京開発グループ ゼネラルマネージャ小林 俊仁 (@toshi_k)

2012年11月6日 / Aiming Study #7