2013/3/9 NADECで講演した内容です。 都合上、やったみた結果の一部内容は省きました。 何かあればTwitterで @arimamoto までお願いします (^^)/

1. 2013/3/9 有馬もと
NADEC
スクラムはもうだめぽよ!
新しい開発手法『パワープレイ』を
お姉さんが教えてあげちゃう!

2. 「有馬もと」の自己紹介
● @arimamoto
● 渋谷ではたらくゲームプログラマやさん
● とある会社のプログラマのマネージャ。
● ゲーム開発歴20年近くいっちゃった。ぎゃー。GBAと
かDSとかパチスロ関係とかいろいろやってた。
● いまはソーシャルゲームやさん。
● ゲーム業界の高田純次を目指していたり。どーん!

3. 「有馬もと」の自己紹介
■有馬のアジャイル歴
● アジャイル宣言が出る前、XPの頃から実地に生かしてい
る。最初の理由は「自分の仕事を楽にしたかった」。何しろ
次から次にやってくる仕事をフローごと改善したかった。
● アジャイルのえらい人であるアリスター・コーバーンさんと
膝つけて話す機会があり、どうしたらいいのか聞いてみた
ら「経済の原理原則的に早くてうまいプログラマは何やっ
ても忙しいよ、ハハハ」と言われてしまい目からウロコ。は
なから「自分が忙しくなること前提」で開発手法を取り入
れ、サーバントリーダーシップやらファシリテーションやら
何でもやる。
● 現会社ではソーシャルゲームのプログラマのリーダーとし
てひとつまかせてもらった機会を得られたので、頭から
しっぽまでアジャイルしてみた。ただ当人たちにはアジャイ
ルだなんて一言も言わなかった(←ここがミソ)。

4. さて。えらい人がよく言うこと。
「別にドラクエとかは、アジャイルで作ってい
ないよね?」
…え、うん、はい。

5. 確かに一理ある
● 一般的なスクラムなどアジャイル開発手法と、すごい売り上げ
を立てた伝説的タイトルとの「開発方法の差」はどこだろう?
● 一方で最近スクラムなどのゲーム開発への活用事例を見て
いると、どうももんにゃりすることがある。
バーンダウンチャートを使うことで「もっと楽しませる要素を作り込む」ことを阻害し
ていないか? ホワイトボードにタスクを書くことで「自分が仕事していることに安心」
していないか? スクラムの定期的なイテレータにより「来週のログに書けばいいや」
とかになっていないか? 全体的な作業量の平均化を進めてしまっているのではな
いのか? プログラマはゲーム開発にのめりこめる、コーディングハイに勝手になれ
る開発手法となっているのか? たんにリーダーの手抜きの方法になっていて、
チームによい影響がでていないか? 良い物ができない言い訳に使ってないか?
もうこれはだめぽよ～ではないか?
ゲーム開発についての新しい開発手法が必要!

6. そこで「パワープレイ」
● チーム内にいる伸び盛りの人(スタープレイヤー)を
前面に押し立てて、それをチーム全体で支えること
で、危機をチームで乗り切ってしまおう、という手法
● 期間を短めに設定したり、日常的な作業リズムを
あえてぶちこわして「危機感」をチーム内に持たせ
ることが特徴
●
リリースを乗り越え、「やりきる」ことに主眼を置く。
そのときに壮絶な発明品が次々と生まれ、どんど
んコンテンツのクオリティを高めていくのが目的
● パワープレイとはアイスホッケー用語。反則で敵の人数が少なくなったときの得
点チャンスのこと。チーム全員でいっせいにゴールを狙うというアイスホッケーの
見せ場。スクラムの元ネタはラグビーなので、そこに対抗してみた(笑)
●
有馬の発明品。外部発表していないけど、会社内で開いた勉強会で好評だった。

7. 「パワープレイ」のプラティクス
● チームにパワープレイを宣言する(非常事態宣言)
● スタープレイヤーの選出と人員配置
ベテラン的な人や伸び盛りな技術者を選出する。だいたい1～3名ぐらい。他はそ
れを補佐するような人員配置にする。
● スタープレイヤーが行う対応
スタープレイヤーには現在チームが抱えるもっとも難解な問題に取りかかる。一
心不乱に短期間で問題を解決していく。そのためには何をしてもよいとチーム内
で合意しておく。
● スタープレイヤーへの支援
様々な面で支援をする。ツールが必要であれば調達したり、他部署の信頼できる
人の支援を受けさせたりする。めげそうになっていたら話を聞いて問題を分解し
てあげる。細かい仕事はチームリーダーが拾って、スタープレイヤーの突進に邪
魔にならないように徹する。
● 危機感を生み出す
朝会など定期的な物があればすっとばす。場合によってはUnitTestなどの安全
策も外す。非日常なパワープレイ中なんだとチームが理解できておすすめ。

8. 「パワープレイ」のスケジュール感と進捗確認
● 「パワープレイ」の開始時期と期間
リリースの2～3週間前が目安。長めには取らない。
● パワープレイのゴール
目的はひとつのみ。直近の期日に重要な物が完成することをゴールとする。
● タスク確認
前提として「大きなタスク(リリース日はここ)」と「小さいタスク(個人が受け持つ仕
事)」の管理が分離していること。小さいタスクは元から自己管理に徹してもらう。
基本的に「できた物」だけを見せてもらうことだけにする。数字管理だめ。
● みんなで見る日
ゴールの2日前ぐらいにして、そこで関係者全員で見る(みんなで見る日)。そのと
き生まれたログは、その場で整理して重要度に応じて調整し、こなしてもらう。
元々スケジュールは短めなので、これぐらいでよい。みんなで心配になったら、再
度みんなで見る日を設定する。
2～3日
2～3週間
スクラムか何かでも可
パワープレイ! みんなで見る日 リリース!

9. 「パワープレイ」中のチーム状況
● リーダーが取るべき雰囲気作り
スタープレイヤーからぐっと来る物ができたときに、リーダーは「彼は何か持って
るね!」と絶賛してあげる。どよめくオーディエンスにスタープレイヤーもいい気分
になり、チーム内にも「すげー」「がんばらんと」という方向に勝手になっていく。そ
こに神も生まれる
● 「パワープレイ」の成功
うまくいっている間は、もう細かいことを言う
人はいない。とにかく物がどんどん生産され
る。リーダーは、物が全部できるまでは支援
に徹し、できた物には「こうしたらいい」と建
設的指導を与え、完璧な物ができたらみん
なの前で褒め称える。こうしてリリースを
チーム全員で乗り越える
● 「パワープレイ」が失敗
何度もパワープレイを強要する。同じような
失敗を繰り返す(またこの人かよ、的な)こと
があるといけない。やばげな問題は育たな
いうちにあらかじめリーダーが片付け、ス
タープレイヤーに近づけないようにすると、
確実に成功する

10. 実際にやってみた
●
とあるタイトルのソーシャルゲームで適用してみた
● それまでは期間不定のスクラムで回していた。ゴールは誰かに見せ
るなど何かしらのタイミングに向けてのものだった。
●
一度ちゃぶ台返しに合うなど、プログラマ的にはやさぐれてもおかし
くない状況
● リリース2週間ぐらい前から適用してみた。
● スタープレイヤーとしては、目玉となる機能の開発をしていた人2名
ぐらい。ひとりは業界1年未満の若手。ほかの人はその人たちの補
佐(リスト表示部分など誰でもできそうなところ)を徹底してもらった。
● 結果「ここは俺が食い止めるから、おまえは先に行け!」とかチーム
内で言われてた。
● それでもリリースが諸事情で当初予定より2週間ほど伸びてしまっ
た。さらにベテラン助っ人を呼ぶなど、いろいろした。
● リリースはほぼ成功。わーい(^^)/

11. ふりかえり
● 大量の発明品ができた。たとえば開発した目玉機能はエンジ
ニア由来で落ちたことがない。わりとオリジナル部分が多い。
これは担当したプログラマのいくつかの発明に支えられてい
る。
● 課金関連のバグをリリース前につぶせたり(しかもすごい低い
確率のがたまたま出せた)、いろいろ神がかり的なことが起き、
それがテンションあがることになった。
●
それまでよくでていた文句や不満などは、この期間中はほんと
に目立たなくなった。
● 社内で評価されたり、一部の機能が社内の他タイトルに入った
り、それなりによかったのかなと。
● 人はめちゃくちゃ育った。何しろチームの雰囲気がよいことで
社内的に有名になった

12. よく言われたこと
● スタープレイヤーがチーム内にいません
– いやいやいや…。君の目は節穴かい?
– みんな何かの特技を必ず持っている。別にベテランじゃなくても
よい(実際そうだった)。平均的なプログラマしかいないと感じてい
るのなら、誰かに役割を与えて祭り上げることも重要。
● これは開発手法なのか…?
– はい。アジャイルの思想にのっとっているので問題ないかと。
● いわゆるバンデッドな開発になってしまうのではないのか?
– ある意味ではそこを目指している。統制されたカウボーイプログ
ラミングになればよい。プログラマがやんちゃしないと発明品が
生まれないため。
– また開発に理解がある人をスタープレイヤーとしてしまえばよ
い。そんなにひどくはならない

13. 最後に
● ゲーム開発は本来属人的なものです。攻殻機動隊の名言の
ように「我々の間には、チームプレーなどという都合のよい言
い訳は存在せん。あるとすればスタンドプレーから生じる、
チームワークだけだ」というのがゲーム開発です。開発手法を
選ぶときは、そこをはき違えてはいけません。
● パワープレイは荒ぶりたいときに利用できます。リリースが近
づいてチームがごたごたしてきたときに使ってみてください。ま
た問題が多いチームの立て直しにも利用できます。
● アジャイルは手法ではありません。アジャイルは「思想」です。
スクラムなどの手法をありがたがるよりも、自分たちで「思想」
を学び、そこから「最適な手法」を作り上げることにいますぐ着
手してください。日本発のソフトウェア開発手法をぜひ世界へ!
れっつじっせーん!
ありがとうございました～(^^)/