Embed Size (px)
Citation preview
オンラインゲーム開発におけるアジャイルなチームビルディングの
具体的手法
2011年9月6日 於 CEDEC 2011
株式会社 Aiming 東京開発グループジェネラルマネージャ / テクニカルディレクター
小林 俊仁@toshi_k
About: 小林 俊仁
• @toshi_k
• http://about.me/toshi_k
• オンラインゲームを作り続けて早10年
• だけど心は Web っ子
• Community Engine (CE) 日本 → CE 中国 →CE 日本 → ONE-UP → Aiming
About: Aiming
• 2011年5月 に成立。 今 130人超。
• Game + Web + リアルタイム通信 の技術を核にいろいろ作れる開発チームと
• ブラウザ三国志等の実績がある企画チームと
• 経験豊富な運営チーム。
About: Aiming の開発チーム
• Community Engine
• MMOG, MOG のサーバシステム開発、通信ミドルウェア開発など
• 2010.05～ ONE-UP に開発コアメンバーが移動
• ブラウザゲームや課金 P/F の開発、PS3 MOG のサーバ開発など
• 2011.06～ Aiming に開発チーム全員が移動
• スマフォゲーム x 2、Flash ゲーム x 3、携帯ソーシャルゲーム x 1、ブラウザゲーム x 1 など開発中
会社は移ろえど、チームは脈々と。（以下、主に東京）
裏の問題意識
• 勉強会の量は Web 界隈 > Game 界隈
• GDC ではポストモーテムの公開とかしてるのに。羨ましい。
• 「心はWebっ子なゲーム開発者」として、諸々公開してみよう
今日の趣旨
• Agile 開発って何？
• Agile 開発手法とAiming における実例
• 何から始めればいいのか？私的 Agile 史
Agile 開発って何？
Agile 開発って何？
• ムダと失敗とケンカを最小化し、ソフトウェア開発で幸せになるための手法
• 「早すぎる完璧」に対する防御
早すぎる完璧とは？
• 「5000万でできます」
• 8月までにできます
• あれとこれは実現可能です
時間、予算、スコープ（そして暗黙の品質）を初めにえいやと決めたはいいものの…
現実
テキスト
それでも人は決めたがる
• 「5000万で作る言うてたやん」「いや、あんたがあれもこれも作れ言うたんやん」
• → スコープが曖昧なのに予算決めすぎ
• 「8月までにできる言うてたやん」「いや、新基軸のゲームをスマフォで出そう言うてるのに無茶ですわ」
• → 難易度が不明なのに期間決めすぎ
そんなあなたに Agile 開発
• SCRUM, XP (eXtreme Programming) 等
• 私はいつも前もって予言をするのは避けることにしている。なぜなら、事が起こった後に予言する方が優れたやり方だからである。 by
by ウィンストン・チャーチル
Agile 手法が置いた前提
• 初めから完璧に計画し尽くすことは不可能
• 変化をプロセス化しよう
• 動くソフトウェアを提供しよう
Agile 手法が取った解決策• 曖昧な段階で約束するなさせるな。適切な時に決めよ。
• でも「意識的に決めないでおく」のや「曖昧さを合意する」のは結構大変
• 計画は、はじめはあてずっぽうである。進行に従って不確実性が減るので、定期的に修正せよ。
• でもステークホルダと「計画の変化を合意する」のは結構大変
• 顧客を巻き込んで情報を公開せよ。誠実であれ。そうすれば変化の理由は納得してもらえる。
• でも「顧客に内情を全てさらけ出す勇気を持つ」のは結構大変
Agile 開発手法とAiming における実例
動くソフトウェアを届ける
• よくある現実 : 顧客に会議やドキュメントを届けたりしちゃう
• Agile の解法: ソフトウェアを通じて顧客やユーザが実際に触れるフィーチャこそが価値。これを毎回顧客に届けましょう
• タスクの完了＝フィーチャのリリースに必要なものが全て揃った状態
計画の修正に顧客をコミットさせる
• よくある現実 : 丸投げ → 3カ月後「ギャー！」
• Agile の解法 : タイムボックス化して顧客と一緒に計画を修正する。
• スプリント or イテレーション（Aimingの場合1,2週）
• 見積もりは開発者が決める。優先順位は顧客が決める。
• 恩恵 : 何かを諦めないといけないことが明確になること。
• 1個入れたら1個諦める。両方入れるなら期日か予算か品質を諦める。
• YAGNI (You Ain’t Gonna Need It) - 要件？それは本当に必要か？
朝会をする
• 一番小さい単位のタイムボックス化
• 毎朝立ったまま15分以内で終わらす
• コミットメントの共有（将来の計画は変化するが、今日終わらせることのレベルであればコミット可能）
• 問題の顕在化
• チームが支えてくれてる感
• さらなる恩恵 : チームの自己組織化
規模と期間の見積もりを分離する
• よくある現実 : 人月、人日など
• (全部で120単位のプロジェクトの場合)
はじめ消化工数は20人日/週だと予想したが、実際は15人日/週だった→ 全ての工数見積もりを 1.3倍にして、160人日を20人日/週で消化するから…
→ 修正が超めんどくさくて状態が update されなくなる → Fail
• Agile の解法 : 「規模を見積もり、期間は導出する」
• 規模は、理想工数 or ストーリーポイント (SP) で。
• 分離の恩恵:
• はじめベロシティは20SP/週だと予想したが、実際は15SP/週だった→ 全部で 120 SP なので、6週じゃなくて8週かかる。 （各タスクの見積もりは変わらず、消化速度が修正されるだけ。）
バーンダウンチャートとベロシティによる期日予測
見積もりにチームでコミットする
• よくある現実
• 「お前1日でできるって言うたやん」→ 他人のせいの連鎖 → Fail
• 技術リーダーがつい「自分がやったら何日か」で見積もる → Fail
• Agile の解法 : 見積もりポーカーで、開発チーム全員の意見にする
• さらなる恩恵:
• 人による見積もりの差異を吸収できる
• 見積もる際に議論があるので要求や設計への理解が深まる
見積もりポーカーの様子
見積精度を上げる期間を取る
• 経験が浅くて見積もれない。何か書いて技術的方向性を掴みたい。
• → スパイク期間を取って検証。終わったらコードは全部捨てる。
• 企画や仕様の落とし穴を見つけたい。開発チームがちゃんと成果を出せるのか見極めたい。見積もりの精度を上げ、スコープや投資額はこのままでいいのか見極めたい。
• → プリプロ期間を取って検証。終わったら計画の修正を行ってから、本開発に着手する。
振り返りでチーム運営を改善する
• 問題と改善点の分析会 （≠反省会）
• チーム運営における、PDCA の C。
• 「チーム対問題」の原則
• 「お前のあれがダメだった」は、人対人なので絶対にダメ
• KPT 法（Keep, Problem, Try）
KPT による振り返りの様子
コードをチームのものにする
• よくある現実 :
• 「お前のコードが腐ってるんやろ」全体が動かないと成立しないのに、人のせいにしても意味がない
• コードレビュー
• Aiming では gerrit でやっている。
• 更なる恩恵 : 教育的効果、品質向上
Output に自信を持てる状態を作る 1
• よくある現実 : 直し壊し、怖くて引き継げない先任者のコード
• Agile の解法 : TDD, BDD で、動く保障を得る
• テストを書く → 中身を書く → 通る状態のままリファクタリング
• 更なる恩恵:
• バグの特定が容易になる
• 使いづらい設計に気づく（自分のコードの最初のユーザとなる）
• コードベースが大きくなっても変更コストを小さく保てる
Output に自信を持てる状態を作る 2
• Agile の解法 : CI (Continuous Integration)
• Jenkins (Hudson)
• 毎日ビルド、毎日テスト → プログラムの問題発見の早期化
• 更なる恩恵 : 常に遊べる → 企画や仕様の問題発見の早期化
• (ちと外れるけど) Online Game 的な practice : クライアントだけ先に作るのは成功した試しがない
目的指向の席配置にする
• よくある現実
• 機能で組織を分割 like 企画部、開発部…
→ 失敗の原因を求めやすいあちら側→ 試行錯誤ができずクソゲー完成
• 常に試行錯誤できる状態にする
• チームは目的が一緒。職種も上下も無く一カ所に集まって、会話と気づきを増やす
自己組織的なチームを作る
• よくある失敗 :
• 強すぎる分業がスキマを生む。「僕の仕事じゃないので気にかけませんでした」→ 割れ窓
• Aiming で気にかけていること:
• やれる奴が、やれることをやる。
• Interdisciplinarity
T型スキルを重視する
• よくある失敗 :
• 「DB 設計のせいだ」 → ケンカ
• Aiming の Practice :
• 「メッセージングは丸っと誰」のように、サーバもクライアントも含めてフィーチャを1人の担当としたい。が、普通無理。
• 他人が言っていることを分かるくらいには広く浅い知識を皆が持てるような環境を作りたい → 勉強会による機会提供
• さらなる恩恵: 好奇心 = 変化を楽しむ能力 = 蓄積を捨てる能力 = 組織のスキルセットの陳腐化に対する耐性
勉強会の様子
ツッコミビリティを保つ
• よくある失敗 :
• トップダウンすぎる組織でチームと製品が大規模化 → 一人の人間が把握することが困難に → 裸の王様と、諦めちゃった部下
• Aiming の Practice : ツッコミビリティの確保
• → 問題に気づいた人がツッコミを入れられるような、適度なユルさ。「これそもそもおもんなくね？」を含む
• 問題の findability をチームで担保する、という考え方
• メールよりチャット
ドッグフードを食う
• よくある現実:
• 仕様通りに作ったけど、クソなものができたので作った人が使わない
• Aiming での practice:
• はじめの output はクソ。みんなで使って試行錯誤して改善せよ。
• 開発チームの中に重課金者がいたりする
自問すべきこと
• 開発者として:
• 顧客が信頼するに足る情報を提供できているか？ Accountability を果たしているか？価値を生み出していない言い訳をしていないか？自分たちが判断し、実行するに足る権限や環境はあるか？ 無いならそれを早い段階で要求したか？ 安請け合いをして、過度な期待を抱かせてしまっていないか？
• 顧客として:
• ソフトウェア開発者を信頼するに足る情報は得られているか？ 得られてないならそれは何か早い段階で伝えたか？ 逆に 開発者に十分な情報を与えられているか？ あるフィーチャの優先順位を上げるために何かを諦めることができているか？ 予算・品質・期間・スコープのうちどれか1つは柔軟か？ その報告やドキュメント作業をさせるよりも動くソフトウェアを作ってもらった方がいいのではないか？
何から始めればいいのか？私的 Agile 史
私的 Agile 史• 2002,3年頃
• プログラマだった。周囲で XP が流行ってたのでペアプロとかしてみた。サーバとクライアントは絶対にはじめから両方接続しながら作る、とかやっていた。
• 2004年頃～
• 中国にて。経営しつつ PM。課金とか作ったのでさすがにテストを書いた。
• 2008年頃～ - 某オンラインゲームの管理ツールの開発＆PM
• SCRUM 勉強し出した。Rails 使ったので自分でも少しテストとか書いてみた。「理想日」による規模の見積もりを導入したが、”実際 / 理想”の係数は変化しなかった。はじめはタスクカードを客先に持って行ったりしていたが、リモートなので結局 xls 管理になった。バーンダウンチャートを作って壁に貼ってみた。 フィーチャによる見積もりや
CI はしてなかった。 終了後にC++の別プロジェクトをはじめたが、テスト書いてない状態に逆戻り。ツール大事。
私的 Agile 史 2
• 2008,9年頃 - 某 Flash MMO 仮想空間プロジェクトの PM
• 「フィーチャ」によるプロダクトバックログを作ってみた。肌感覚の％じゃなくて
0-50-100 法で進捗を出してみた。週例の会議で絶対に動くものをデモろうと気合いを入れた。発注元のリーダー格を巻き込めたので、一緒にフィーチャの優先付けができたのはラッキーだった。開発の状態が分かるようになり信頼は得られたが、雲の上の事情でプロジェクトは中止。
• 2009年頃 - 某 Flash MMO 仮想空間の開発アドバイザリー
• 隣のチームがタスクカードとか Hudson とか導入しはじめた。チームにノウハウが溜まっていってそうで羨ましかった。
• 2010年頃
• 社内で SCRUM だ Agile だと大々的に騒ぎ始めた。
どこから Agile 化するか
• どっかのチームに急に入ったら、僕も Agile するのは無理。
• チームの共通体験が必要。 特に失敗体験に便乗してみるとよい。
• 例:
• 直し壊した → テスト書こうよ
• 「設計 60% 完了、テスト20%完了」とか意味無い数字を上げるのイヤ → 作業じゃなくてフィーチャを計画しようよ
塞翁が馬
• 明かに分かる失敗なら乗っかりやすいが、通常は業務プロセスの「失敗」が共有化されることは少ない
• なので、お勧めは KPT あたりから。
• あんまり Agile っぽい言葉を使いすぎない
• 「毎週動くものを出すから、それを見て残タスクの優先順位付けしようよ」とか
• 「タスクリストは『ユーザが何ができるようになるのか』って視点で作りましょうよ」とか
ありがとうございました。
2011年9月6日 於 CEDEC 2011
株式会社 Aiming 東京開発グループジェネラルマネージャ / テクニカルディレクター
小林 俊仁@toshi_k
