|
セッション：[A-1] 宝探しAgileゲーム スピーカー：安井 力 さん |
こんにちは！
いやー勉強会っていいですね。
今回は、Ultimate Agilist Tokyoの「宝探しAgileゲーム」についてレポートします。
このゲームは、プレゼンターの安井 (@yattom) さんが独自に考えたゲームです。（ゲームの企画自体をどこかに売りたいと言っていました。）
ゲームの説明をする安井さん
■宝はどこに！？
このゲームは、チームに分かれて、100ポイントに制限されたマーケットシェアを奪い合い、最後に一番多いポイントを獲得していたチームが勝ちになります。ですから、宝＝マーケットという見方もできます。
しかし私は、このゲームを通して安井さんが言いたいのは
宝＝ビジネスサイドと開発サイドのコミュニケーションとチームワーク
ではないかと解釈しました。
どうしてそう思ったか、まずはルールの説明、続いて私たちのチームがどうやって勝利を勝ち取ったかを紹介します。
■ルール
このゲームは、市販のボードゲームに近く、普通のワークショップよりルールが少し複雑です。一つ一つ紹介していきます。
チーム分け
まず、1チーム4人程度 × 数チームに分かれます。
今回は、南北チーム、カニチーム、Hチームの3チームでした。私は南北チーム所属（南北線利用者がいたため、このネーミング）。
参加者はこんな感じです。皆マジです。
ビジネス担当と開発担当
チーム内でビジネス担当と開発担当に分かれます。実際の仕事と同様に、それぞれの担当業務が違います。ビジネス担当は、マーケットのシェアを予測してどの機能を開発するかを決め、開発担当は、その機能をどうやってリリースするかを考えます。
マーケットのシェア予測とその開発・リリースを1イテレーションとして、全部で6イテレーションまわし、最終的にマーケットシェアを一番獲得したチームの勝ちです。
各担当の詳細ルールは以下です。
ビジネス担当のルール
Copyright@安井さん
開発担当のルール
Copyright@安井さん
マーケット
マーケットは4つにモデル化されています。
（「MECEにはなっていませんが」by 安井さん）
- ビジネス（スペード）
- 外出時（ダイヤ）
- 女性（ハート）
- 中高年（クローバ）
その周りに、マーケットの規模を表した数字を配置します。
数字が大きいほど、マーケットが大きくなります。マイナスの場合もあります。
各イテレーションごとに、リリースした機能に応じてこれをめくっていきます。それぞれのマーケットのシェアは、めくった時点でのマーケットの周りの数字の合計になります。リリースすると、その時点での合計値のメダルを獲得できます。メダルは合計で100枚しかなく、全部なくなった場合は他チームから奪うことができます。
ビジネス担当の業務
ビジネス担当は、マーケットの数字をみて、どの分野に機能をリリースするかを判断します。
リリースする機能をモデル化したタグ
タグの右下には、スペード、ダイヤ、ハート、クローバのマークが付いています。このマークは、どのマーケットに対する機能かを表しています。
赤い線は、開発の難易度を表します。
タグ左上の＄は、その機能をリリースした後の売上を表します。難易度が高い機能ほど、売上も大きくなります。
ビジネス担当は、マーケットの状況を見て、どの分野が一番シェア（数字の合計）が大きいかを判断し、リリースする機能のバックログを作ります。
バックログを並べた様子。
上から優先度が高い順に並べました。ここでは、難易度が低いものから早くリリースするポリシーのため、赤い線が少ないものが上になっています。
開発担当の業務
開発担当は、ビジネス担当のバックログを見て、優先度の高い機能をどうやって開発するかを考えます。
開発の実現は、こちらのボードに機能のタグを埋め込んでいくことで表現します。
開発担当もタグを持っていて、写真左側のタグが開発担当が使うタグです。
（右側は、ビジネス担当が作った機能のバックログ）
機能を実装した様子。赤い線と青い線をつなげる形で開発ができたことを表します。
各イテレーションで、開発担当は原則、2枚のタグしか使えません。赤い線が多いほど開発が難しいのは、つなげなくてはならない開発タグが増えるからです。開発担当は、どうやって機能を実現していくかを手持ちのタグの組み合わせで考えます。
イテレーション
マーケットの判断、バックログ作成、開発とリリースする機能の決定を1イテレーションとします。各イテレーションが終わると、マーケットにどの機能をリリースするかを各チームが持ち寄ります。
マーケットにリリースする機能のタグを見せ合う様子。
リリースする機能の赤い線の合計が多いチームから、対応するマーケットの数字をめくり、シェアのメダルを獲得します。上の写真では、外出時（ダイヤ）マーケットにリリースを行い、シェアが合計+5なのでメダルを5枚獲得しています。
イテレーションが終わると収入と支出を計算し、ボードの下の欄にイテレーションごとに収支を記入します。
6イテレーション終わった時点で、最終的にメダルを多く持っていたチームが勝ちます。収支がマイナスになったチームは、その時点で負けです。
■チームの良かった点
私たちのチームの良かった点は、ビジネス担当と開発担当が立場に関係なく、良いと思える意見を出し合って全員で方針を決めたところです。その結果、全マーケットシェアの半分ほどを勝ち取ることができました。
各イテレーションでポイントになったエピソードを紹介します。
システムリスクを負って高機能を実現
2イテレーションめで「どうしてもビジネス（スペード）マーケットのシェアを取りたい」ということになりました。このとき開発担当から「リスクを負って実現しましょう」という提案がありました。
リスクテイクは、Dというタグを2枚使うとできます。
- メリット
- 1イテレーションで使える開発タグが、2枚から4枚に増える。
- デメリット
- Dタグの周りには、開発タグがはれない。
- 各機能のリリースに対して毎回サイコロを振るが、Dタグ2枚の場合、1か2の目が出ると、その機能はそのイテレーションではリリースできない。
Dタグを使って左下の3本赤い線があるビジネス（スペード）マーケットの機能を開発した様子。開発タグを4枚使っています。
このときチームは、ビジネス担当、開発担当というお互いの担当を演じながらも、どうするか真剣に悩みました。結果、賭けに出ることに。
このイテレーションでは見事、サイコロで1、2以外の目が出ました。
リリースを我慢してリファクタリング
しかし、3イテレーションめではサイコロの目がふるわず、リリースできませんでした。その結果、3機能のリリースが遅延しました。
そこで「リスクを減らしましょう」という話し合いをしました。
Dタグは、1イテレーションをかけて、1枚外すことができます。Dタグがボード上に1枚の場合は、サイコロの目が1以外のときに各機能をリリースできます。しかしDタグを外す場合は、そのイテレーションではリリース自体ができなくなります。
私たちは、4、5イテレーションの2回をかけてリスクを全部なくし、最後に確実にリリースしようと決めました。
4イテレーションめでDタグを1枚外したところ。赤いピンが立っているのがリリース待ちの機能です。
結果
結果として、全マーケットの半分くらいのシェアを獲得できました。
手前が私たちのチーム。
ルールも手探り状態だったので、運にも恵まれました。
■まとめ
このゲームの醍醐味は、ビジネスと開発のドラマを短時間で味わえるところです。
実際に、職場のビジネス担当と開発担当とで定期的にチーム別の大会を行うと、かなりのアイスブレイク効果があるのではないでしょうか！？
最後にまとめる安井さん。
皆さまもぜひ、チャンスがあれば体験してみてください。
参考
Ultimate Agilist Tokyoをもっと知るには
公認レポーター 松田 敦義
